GNOME OS Is Taking Shape But Its To Serve For Testing The Desktop

[Giovanni Fabbro]

I disagree.
Red Hat employees do their own projects to benefit themselves and their position more than anything else. They don't care if the community picks it or not. It's just a happenstance, not an intention.
They usually have debatable benefit (at best) for the users. Which is why they might benefit the community but not necessarily the Linux ecosystem as a whole.
Canonical do their own projects to benefit users, which is why they greatly contribute to the Linux ecosystem in a very different way.

In the end, there could be a balance and mutual benefits if Red Hat wasn't so arrogant and narrow minded. Red Hat could bring their dev-centric expertise and Canonical their understanding of the users. If Red Hat could be more pragmatic about users, and listen to Canonical (which has a proven track of successfully breaking entry barriers to Linux), Canonical would probably have no reason to develop their own thing as they could satisfy their users without going their own way.

When you clearly understand the users better, but are not listened to, why would you take the path that is not focused towards users at the risk of pushing them away? It makes no sense. Canonical have valid reasons to follow their ideas.

Red Hat employees are the developers of KVM, virtio, GNOME, Flatpak, Cockpit, and a whole other host of Linux components that are available in other distros.

Canonical made Snap, their subscription-based system management platform Landscape, and modified GNOME into this garish thing with a clashing colour scheme that breaks GTK apps.

Care to argue those merits again?

One more thing: Canonical had to use the third-party Debian code to start with. Fedora didn't.

[RahulSundaram]

Try looking up the build process for Silverblue. The discussion started around that.

I don't see any evidence here still. Where is the direct link?

[Giovanni Fabbro]

I don't see any evidence here still. Where is the direct link?

Comments aren't searchable. Blame the web designers.

[RahulSundaram]

Comments aren't searchable. Blame the web designers.

So in summary, your made several statements which either were incorrect or not verifiable

1) Red Hat uses CLA and CentOS website/packagers say RHEL has proprietary software - Incorrect
2) Flatpak doesn't publish server side software - Incorrect
3) Fedora Infrastructure uses proprietary software - Incorrect
4) Red Hat developers said "trust us" - Incorrect or unverifiable

[Giovanni Fabbro]

So in summary, your made several statements which either were incorrect or not verifiable

1) Red Hat uses CLA and CentOS website/packagers say RHEL has proprietary software - Incorrect
2) Flatpak doesn't publish server side software - Incorrect
3) Fedora Infrastructure uses proprietary software - Incorrect
4) Red Hat developers said "trust us" - Incorrect or unverifiable

Wrong.

I never mentioned CLA. Not even once. Go back and read my comments. There's stuff in RHEL related to some of their subscription connections as well as some crypto packages for regulated industries not included in CentOS. It's not provided in the upstream repos either, so CentOS is not exactly the same as RHEL. I don't know if you can get a Red Hat subscription license to avail yourself to those technologies for use in CentOS, but I think I can safely assume that's a 'no', considering that those are tied to support options.

I didn't say Flatpak doesn't publish server side software - I said FlatHUB doesn't post information on their website on how their hosted project's build process is set up for their site. In fact, all I see is a "just put stuff on Github and send us a note and we'll do it for you". The reason I pointed this out is because someone brought up that supposedly Canonical does the same thing, I guess (I didn't follow into Canonical's processes, but that's what they were inferring). I pointed out that Flathub seems to have a similar procedure. Also, Flathub will publish closed-source projects. Flathub is supposed to be the go-to destination for Flatpaks, considering that Fedora, run by Red Hatters, is pushing the format, and their own Flatpak support is limited at best (even some GNOME projects made by Red Hat employees aren't in the Fedora Flatpak repo when they're already on Flathub).

I didn't say Fedora Infrastructure uses proprietary software - I said that Fedora didn't publish build information for certain back end processes - like the building process for Silverblue images. This was a contention not brought up by me, but was brought up by others in FedMag. I have yet to see information about image-building process for this kind of stuff. If you can find it, please let us know where it's hiding.

I also said that Fedora people, who happen to be Red Hatters, not only confirmed the previous on Fedora Magazine, but also tried to pawn it off with a whole argument about "you have to put some trust in your repo maintainers, yadda yadda". If you can't find that information, it's not my problem - it's in the comments, which can't easily be searched.

[Giovanni Fabbro]

Really you are being a fool who has not done homework.
https://github.com/flathub/buildbot and there is the buildbot-config that contains the configuration files.

Flathub for their back end build services is using buildbot with a few custom patches. This is being used todo so much automatic CI.

https://docs.flatpak.org/en/latest/hosting-a-repository.html

The flathub repos themselves are run by upstream flat-manager.

Even the flathub website is up in the flathub github account under linux-store-frontend.

All the parts are there to setup up your own clone of flathub just there is not a nice unified instruction manual todo it.

The core server stuff mostly does not have manifest because flatpak is not really for services.

None of this explains how closed-source applications end up on the site, since the code for those projects aren't going to be on Github. This is why I say that there's some kind of back-end manual interaction happening that they aren't documenting.

[oiaohm]

None of this explains how closed-source applications end up on the site, since the code for those projects aren't going to be on Github. This is why I say that there's some kind of back-end manual interaction happening that they aren't documenting.

https://github.com/flathub/com.spoti...fy.Client.json

Nothing about being completely wrong. How closed source applications are repackaged for flathub is documented in code going up on github. Each closed source applications build into flatpak is different so you cannot really write 100 percent generic documentation other than the flatpak builder documentation.

The spotify example is pulling in
"url": "http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_1.1.26.501.gbe11e53b-15_amd64.deb"

Yes a deb from spotify own web the unpacking the deb and making it into a flatpak install file. Flatpak builder files are not only restricted to source stuff from github can in fact source stuff from any URL.

Following is the code out the flatpak build file that does the undo debian packaging for spotify.

"ar x spotify.deb",
"rm -f spotify.deb",
"tar xf data.tar.gz",
"rm -f control.tar.gz data.tar.gz debian-binary",
"mv usr/* .",
"rmdir usr",
"rm -r share/spotify/apt-keys share/spotify/spotify.desktop share/spotify/icons share/doc"

Turns out unpacking something like a deb or rpm file manually is not hard. The trick is providing a compatible runtime.

The source code used for the package conversion to flatpak that flathub is using to convert closed source applications that is going up on flathub and its a normal flatpak builder files nothing really that special going on here. Yes buildbot is running flatpak builder so running the conversion. So it is 100 percent correct to say flathub builds all the flatpak packages they host. Of course building a flatpak package does not mean you build all the parts inside the package just like any other packaging format.

The process used convert closed source applications could be used to convert any prebuilt binary be it open source or closed source to flatpak.

[RahulSundaram]

I don't know if you can get a Red Hat subscription license to avail yourself to those technologies for use in CentOS, but I think I can safely assume that's a 'no', considering that those are tied to support options.

I didn't say Flatpak doesn't publish server side software - I said FlatHUB doesn't post information on their website on how their hosted project's build process is set up for their site. In fact, all I see is a "just put stuff on Github and send us a note and we'll do it for you". The reason I pointed this out is because someone brought up that supposedly Canonical does the same thing, I guess (I didn't follow into Canonical's processes, but that's what they were inferring). I pointed out that Flathub seems to have a similar procedure. Also, Flathub will publish closed-source projects. Flathub is supposed to be the go-to destination for Flatpaks, considering that Fedora, run by Red Hatters, is pushing the format, and their own Flatpak support is limited at best (even some GNOME projects made by Red Hat employees aren't in the Fedora Flatpak repo when they're already on Flathub).

I didn't say Fedora Infrastructure uses proprietary software - I said that Fedora didn't publish build information for certain back end processes - like the building process for Silverblue images. This was a contention not brought up by me, but was brought up by others in FedMag. I have yet to see information about image-building process for this kind of stuff. If you can find it, please let us know where it's hiding.

I also said that Fedora people, who happen to be Red Hatters, not only confirmed the previous on Fedora Magazine, but also tried to pawn it off with a whole argument about "you have to put some trust in your repo maintainers, yadda yadda". If you can't find that information, it's not my problem - it's in the comments, which can't easily be searched.

1) You haven't named any crypto packages that are RHEL only. If what you are claiming is true, feel free to name the specific packages. If there are no trademarks in the packages, nothing is stopping you from using any RHEL package on CentOS. So such an assumption is incorrect

2) What you said about Flathub is incorrect, everything is in the github project site and I and others have already linked to it and explained it you already. So you are entirely wrong about it.

3) Your claims about Fedora, you have shown no evidence for at all either. Others in the community have been building silverblue variations with KDE, XFCE etc

https://pagure.io/workstation-ostree-config

https://discussion.fedoraproject.org/t/kinoite-a-kde-and-now-xfce-version-of-fedora-silverblue/147

This is all readily available information easily searchable. Your inability to back up any of your claims with any specific evidence at all is your problem

[bregma]

BSD gives the user the freedom to do whatever the hell they want with the software, including being able to make modifications closed-source as they see fit.

You have confused the user and the developer. The developer develops the software. The user uses the software. It's not a coincidence that the nouns and the verbs have the same root.

GPL limits what a user can and can't do with the software, thus maintaining credit to the original developer under the same source code, including modifications as per GPLv3. That's IS NOT a freedom unto the user. This is why BSD is known as a "permissive" open source license, while GPL is known as restrictive. It's right there on Wikipedia.

Full credit is required to go to the developer in the BSD case. It's right there in the words of the license. One of the conditions of distributing software under a BSD license is that credit must be given to the copyright owner(s). Going too far with that requirement is what made the 4-clause BSD license incompatible with the GPL.

The GPLv3 does not dictate what can and can not be done with software, only how it can be distributed. In fact, if an alternative distribution license does put restraints on the purpose, use, or functionality of the software it is incompatible with Free software and the GPL.

The GPL does not require that copyright of source code be transferred to some other entity. Modifications to source code of software licensed under the GPL belong to the author of those modifications, not the original author of the source code. This is covered by copyright law, not the software distribution license.

The ability to examine, stufy, modify, or replace their software is definitely a freedom granted to the user by the GPL that is not offered by a BSD (or similar) license. It is the fundamental reason for the GPL, and the fundamental difference between the GPL and non-copyleft licenses like BSD. A BSD license gives greater freedom for a developer to deny a user freedom. That's why many developers prefer the BSD license and why commercial entities whose economic model is based on increasing revenue by driving up price through restricted supply prefer BSD-licensed software.

BSD is a more "permissive" software distribution license, yes. For the software distributor, not for the software user. The GPL is far more permissive for the software user, but that's not how certain interests spin it because there's potentially money to be made and excess wealth to be extracted from the system.

You can choose BSD licensing if you like. Just don't do it because you think it's giving the end user more freedom. In fact it does the opposite.

I would not rely on effectively anonymous articles on WIkipedia for legal advice.

[Mez']

GNOME OS targets developers - the GNOME developers made that clear.

Gnome targets developers, they've also made that clear along the years.

One more thing: Canonical had to use the third-party Debian code to start with. Fedora didn't.

They didn't reinvent the wheel. Isn't that a good thing? Everyone is always complaining that Ubuntu has the NIH syndrome, but here they didn't and yet you are complaining. The typical lack of consistency of Fedora cultists. Ecofascists display the same kind of inconsistency of ideas and eventually contradict themselves too.

Canonical made debian accessible to everyone while debian couldn't. Just as Manjaro did with Arch.
I bet you want to keep Linux for a certain (and presumed) IT-litterate elite, only compiling stuff, using tiling managers and keyboard shortcuts-centric workflow. The more accessible it is the less you like it. Well, I can do all that, but my workflow would be awfully slowed down. Not sure you can envision knowledgeable people preferring simplicity though...
Still, I'm happy it's a choice people with different use cases can make. I embrace the variety of possibilities so that everyone can find something that suits their workflow. Fortunately, other leaders in FOSS have similarly pragmatic visions.

Red Hat employees are the developers of KVM, virtio, GNOME, Flatpak, Cockpit, and a whole other host of Linux components that are available in other distros.

Canonical made Snap, their subscription-based system management platform Landscape,

I only use Gnome in your list.

Flatpak is the same crap as snap, and the rest is pro-oriented and as such has little interest to me and to users in general.

and modified GNOME into this garish thing with a clashing colour scheme that breaks GTK apps.

Care to argue those merits again?

You mean that modified Gnome that most individual users adopted massively because it's much more user-friendly than any other Linux OS? And I'm not just talking about Ubuntu, most Gnome users have tweaked it in a way that is closer to the Ubuntu set up than to Vanilla Gnome. For good reasons.
Again, they understand their user better. This is the ultimate merit in an OS for individuals.

What is typical of above mentioned Fedora cultists is the lack of consideration for the different workflows, tastes and choices. Even their fans adopted the dictatorship mindset. You don't like Ubuntu colors so you have to belittle them. The usual narrow-mindedness.

I'm not using the Yaru theme, I'm using a CSS-customized version of the Matcha-Aliz theme (Manjaro theme in red, based on Arc). Yet, I made heavy use of orange and aubergine because they go along well and are joyful, which is a positive change from the dull blue, black and grey (dark or light).
Your blinkers will probably not allow you to acknowledge that different users have different tastes, though...