Re: What is Portal and pipewire and Why Did They Start?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 17 Jul 2020 at 11:14, stan via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 16 Jul 2020 14:15:01 -0400
"Garry T. Williams" <gtwilliams@xxxxxxxxx> wrote:

> Hmmm.  I used to be in charge of what got updated and when it got
> updated on my own machine.  You indicate that there's another path
> with which to install software that I am no longer in charge of.
> That's alarming.  Especially since I didn't ask for it.

I think Gnome is moving to a multi update source model.  They use
binary rpms, modules, and flatpaks.  I'm not convinced this is a step
forward, but they do the work, so they make the rules.  :-)

> Well, there's the odd thing, isn't it.  Before, dnf would always solve
> dependencies and install them when a package was installed.  Now there
> seems to be another path used for software installation and it doesn't
> know how to handle dependencies.  I don't guess I need this stuff, for
> sure.

Yes, that is why I have restricted all updates on my system to binary
rpm only.  I'll wait to see how things shake out, but this new system
seems to leave conflicts in coverage, and opportunities for security
breakage.

I think these new methods are a mitigation for a lack of package
maintainers.  By using flatpaks, they hope to offload the maintenance
of those programs to someone else.  Outsourcing if you will.  I'm not
sure what being a distribution means under that model.  My experience
is that the people who package software in Fedora are exceptional, and
that is part of what I think of as the distribution of Fedora.

There is a worldwide shortage of exceptional people, so you want them
focusing on the core system and services.   Many workgroups now ( and
even before COVID-19) consist of people with physical locations scattered
across the globe and subject to varying enterprise IT policies.   Flatpaks 
(when they work) offer consistency across distributions.   Conda is 
another approach driven by the need to provide consistent environments
across distros and even for Windows.   

I'm not sure the model holds up well for all use cases.  Certainly there are 
problems with apps that use audio or video input devices that rely on binary 
blobs and/or have licenses that aren't universally acceptable to all distos.   

Conda is another approach
 

--
George N. White III

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux