Canonical Formulates The 32-Bit Support Strategy For Ubuntu 20.04 LTS

[jo-erlend]

Stop defending closed-source software.

Having a proprietary backend for a website is normal. Is Red Hats subscription backend open to the public or do you condem Fedora for its use of rpm packages? Nonsensical question, right? Because your use of snaps or rpms doesn't depend on those specific backend services. You can just put your snaps on a public web server if you want to. Or distribute them with bit torrent if you feel like it. Or via floppies. Have fun. It is entirely up to you, because, you know, it is open source.

It works like this:
1) You download a file app.snap.
2) You download a file app.assert.
3) You run "snap install app.snap".

Tell me which part of this process requires a proprietary service? The idea that all website system internals must be shared with the public, is far beyond even what Stallman would require on a bad day. There is absolutely no requirement that other users of snaps have to use a store that's identical to Canonical's.

[CochainComplex]

Having a proprietary backend for a website is normal. Is Red Hats subscription backend open to the public or do you condem Fedora for its use of rpm packages? Nonsensical question, right? Because your use of snaps or rpms doesn't depend on those specific backend services. You can just put your snaps on a public web server if you want to. Or distribute them with bit torrent if you feel like it. Or via floppies. Have fun. It is entirely up to you, because, you know, it is open source.

It works like this:
1) You download a file app.snap.
2) You download a file app.assert.
3) You run "snap install app.snap".

Tell me which part of this process requires a proprietary service? The idea that all website system internals must be shared with the public, is far beyond even what Stallman would require on a bad day. There is absolutely no requirement that other users of snaps have to use a store that's identical to Canonical's.

https://www.maketecheasier.com/snap-packages-vs-flatpacks/

quote:
....The differences between Snap packages and Flatpaks aren’t really that numerous. Snap was created in-house by Canonical – the company behind Ubuntu – and the technology is hard-coded to use the Snap package store. Some may be nervous of this, as Ubuntu has total control, and in fact in order to make a Snap package you’ll need to sign a Contributor License Agreement (something that some people are very much against).....

ok...@jo-erlend how is that open ?

[jo-erlend]

https://www.maketecheasier.com/snap-...-vs-flatpacks/
quote:
....The differences between Snap packages and Flatpaks aren’t really that numerous. Snap was created in-house by Canonical – the company behind Ubuntu – and the technology is hard-coded to use the Snap package store. Some may be nervous of this, as Ubuntu has total control, and in fact in order to make a Snap package you’ll need to sign a Contributor License Agreement (something that some people are very much against).....

ok...@jo-erlend how is that open ?

1) It doesn't "in fact" require you to sign a CLA. Just saying that something is a fact, doesn't make it a fact. If you want to distribute your software through their store, then you have to agree to some terms and conditions that are reasonable: https://ubuntu.com/legal/developer-terms-and-conditions

2) You don't have to use their store in order to use snap packages at all.

3) Do you think that every other Linux distro just allows people to upload their software directly into the archives without any kind of control?

4) The snap system is open because it is GPL, so it's open the same way the Linux kernel is open; you get to change it, compile it, share it and use it in your own distro without seeking any kind of special permissions. But like Linux, you don't necessarily get to mainline your changes.

5) The article you're referring to is a little strange. For instance, it says that snappy is a server technology that was adapted to desktop, when in fact it was originally designed for desktop and then redesigned in order to also allow other things, like servers. Snapd is used to distribute whole systems. Flatpak is just for app delivery. That's more than just a little different.

6) Personally, I think it's a bad idea to allow anonymous people to share software using your servers, under your name, making you legally responsible for their actions, without some kind of contract. Keep an open mind, but not so open that your brain falls out.

[CochainComplex]

1) It doesn't "in fact" require you to sign a CLA. Just saying that something is a fact, doesn't make it a fact. If you want to distribute your software through their store, then you have to agree to some terms and conditions that are reasonable: https://ubuntu.com/legal/developer-terms-and-conditions

https://ubuntu.com/legal/contributors

There it says "sign"

And snap* is in the list of projects requiring this

https://canonical.com/projects/directory

I would consider this a fact - Proof me wrong.

2) You don't have to use their store in order to use snap packages at all.

But you might need a server to distribute it and according to wiki
https://en.wikipedia.org/wiki/Snappy_(package_manager)
the server is proprietary

I couldn't find any howto for setting up a snap package repo - please show me one.

3) Do you think that every other Linux distro just allows people to upload their software directly into the archives without any kind of control?

nope but thats not the point - the point is ..the software (server included) is open.
And if it is opensource everyone can review the code and check if there is some malicious intention. eg any project on github without blobs.
And there is always the possibility of a fork. How can I fork the Snap Server and host my own Snap Store?

And because of this very reason there are people against snap as a new defacto standard. You can not do it the linux way. And once more like with Mir - people are putting workhours into an ideological "canonicial" project which will be dumped if it is not turning out like it was desired by canonical. Time and money is wasted which would have been needed in other places e.g. Wayland.

Dont get me wrong I m an ubuntu user but I m sure that by now I would have a tearfree Wayland desktop running perfectly fine if Canonical would have contributed to Wayland instead of wasting time on Mir.

4) The snap system is open because it is GPL, so it's open the same way the Linux kernel is open; you get to change it, compile it, share it and use it in your own distro without seeking any kind of special permissions. But like Linux, you don't necessarily get to mainline your changes.

No, but I can create a kernel fork on my self-hosted git whatever repo. So that everyone out there can pull it like from the official github.

5) The article you're referring to is a little strange. For instance, it says that snappy is a server technology that was adapted to desktop, when in fact it was originally designed for desktop and then redesigned in order to also allow other things, like servers. Snapd is used to distribute whole systems. Flatpak is just for app delivery. That's more than just a little different.

The ubuntu wiki says https://wiki.ubuntuusers.de/snap/ the same at the beginning:

...Ursprünglich war es vor allem für den Einsatz im Server- bzw. Cloud-Umfeld, also auch für das Internet of Things gedacht, inzwischen ist es aber auch in den "normalen" Desktop-Distributionen zu finden...

(my native tongue is german) If you dont believe me use your favourite translator.

6) Personally, I think it's a bad idea to allow anonymous people to share software using your servers, under your name, making you legally responsible for their actions, without some kind of contract. Keep an open mind, but not so open that your brain falls out.

Well thats the point: I can not setup my own snapd Server for distributing snaps under my name.

Aside of this even if there is only one distribution channel - like github or gitlab? I never thought of making gitlab or github responsible for code projects. But If you put the Canonical logo on each package and present it like Google Appstore or the Apple thing yes. Because Canonical wants to be seen as the distributor.
How about launchpad? Nobody thinks Canonical is responsible for each package - everybodies knows launchpad is just away to distribute packages but only for ubuntu.

It is clear that canonical wants to use the snapcraft thing to build up a commercial app store in the linux world and everyone should contribute so that their store is going to be the monopoly in the linux app distribution world? well no - thats why i will stay with flatpak.

[CochainComplex]

It works like this:
1) You download a file app.snap.
2) You download a file app.assert.
3) You run "snap install app.snap".

ok understood ...and to keep it updated

4) You run "snap refresh"

..ah wait ..it needs some server or doesn't it?

[jo-erlend]

ok understood ...and to keep it updated

4) You run "snap refresh"

..ah wait ..it needs some server or doesn't it?

I don't know. I think it should support refreshing from file, like snap refresh app.snap, but I don't know if it does. If it doesn't, then you could add it if you wanted to. Because, again, it's open source. But if you do want to start a Linux distro, you probably should get yourself a web server. If you consider that to be an obstacle, I think you may want to reconsider your decision to start a new Linux distro.

[CochainComplex]

I don't know. I think it should support refreshing from file, like snap refresh app.snap, but I don't know if it does. If it doesn't, then you could add it if you wanted to. Because, again, it's open source. But if you do want to start a Linux distro, you probably should get yourself a web server. If you consider that to be an obstacle, I think you may want to reconsider your decision to start a new Linux distro.

No I want somthing like this.

1) snap add-repo XYZ
2) snap refresh --list
3) snap install XYZ.snap

...few weeks later

4) snap refresh

software updated....but because there is no snap add-repo I have to write some script to pull it manually from a server...etc I think writing some bashscript with calling multiple git updates and running make prefix=/localbla/ install will have the same amount of work.

in contradiction:
flatpak

1)flatpak remote-add XYZ
2)flatpak update --appstream
3)flatpak install XYZ

...few weeks later

4)flatpak update

software updated....im pleased

Whats wrong with repos and Flatpaks approach?

http://docs.flatpak.org/en/latest/repositories.html

...Flatpak repositories are similar to Git repositories, in that they store every version of an application by keeping a record of the difference between each version. This makes updating efficient, since only the difference (or “delta”) between two versions needs to be downloaded when an update is performed.
When a new version of an application is added to a repository, it immediately becomes available to users. Software centers are able to automatically check for and install new versions. Those who are using the command line have to manually run flatpak update to check for and install new versions of any applications they have installed....


I tell you why Canonical doesnt want other snap repos:

Providing all snaps through one channel makes it as "open/close-source" as Googles Android is.
Yes, Android per se is open source but it is almost useless if you dont have the google services (see Lineage OS).

For me it seems like Canonical wants to create the very same just with their snap store and then of course money flows - sure they need to make money I dont blame them for this. But you cant sell this as an FOSS solution thats simply bogus. The code is opensource but the surrounding ecosystem is closed as Googles Appstore, Apples Store or Microsofts Marketplace ....name it as you want.

....If this Canonical vendor-lock-in strategy continues I will have to search another distro - there are plenty enough good alternatives

[jo-erlend]

So, because every distro can have their own stores without having anything to do with Canonical, and that you can install packages from anywhere you want and add your flatpak stores, etc, this all means it's a vendor lock-in system. It's a vendor lock-in system because the distro has a special place in the OS and then you can add other sources for other software. And the system is proprietary software, you say, because it's only the software that's Open Source.

You're inventing your own language. You can't just disagree with a decision without the disinformation?

[CochainComplex]

So, because every distro can have their own stores without having anything to do with Canonical, and that you can install packages from anywhere you want and add your flatpak stores, etc, this all means it's a vendor lock-in system. It's a vendor lock-in system because the distro has a special place in the OS and then you can add other sources for other software. And the system is proprietary software, you say, because it's only the software that's Open Source.

You're inventing your own language. You can't just disagree with a decision without the disinformation?

It is a vendor lock-in system because if you really want to use snap as it has been designed with a repo to pull all the latest stuff you have to rely on the only valid existing repo which is closed source and in the hand of canonical. That is the crucial point why it is not suitable for the linux world.

What you have described in your latest post is freedom of choice thats something different. If I m able to choose between Android, iOS or windows phone that is freedom of choice but this does not make any of them a FOSS system.
So snap might be opensource on client side but on ecosystem side it is closed and even if I have the freedom to use flatpak does not make snap an open ecosystem. Besides if snap would have been designed with the intention to be real FOSS, canonical would have encouraged devs to setup their own repos like in the case of git or like flatpak - so please don't fool me or others.

Snap is as open as Android is. period.

[jo-erlend]

So snap might be opensource on client side but on ecosystem side it is closed and even if I have the freedom to use flatpak does not make snap an open ecosystem. Besides if snap would have been designed with the intention to be real FOSS, canonical would have encouraged devs to setup their own repos like in the case of git or like flatpak - so please don't fool me or others.

Debian as a distribution isn't an open ecosystem either. Neither is Fedora. These are closed systems requiring membership to upload packages. When Red Hat created rpm, nobody accused them of having created a new vendor lock-in system because it was the first distro to use rpm packages or that people didn't have access to their internal server systems. It was open source and could be used by others, but that's the end of it. As it should be.

Where can I read about this "RealFOSS" that you keep referring to? I'm used to Free Software and Open Source to be used according to their definitions, which never for a moment states that a client must support multiple server connections or anything remotely similar to that. The idea that an OS distribution must be open to third-party package injection or else be considered a proprietary lock-in OS, is crazy to me.

Why is the snap system specifically designed to not conflict with other package systems if the real intent is to create a vendor lock-in system to make it impossible to use other software? Why does it support installing packages from other sources if the intention is to enforce a single source of all software? Your conspiracy theory doesn't make any sense and you know it doesn't.

As I've said several times, I would also prefer it if the system supported the use of different stores, although there should be some kind of control with who are allowed to push new versions of the kernel, etc.

There is nothing evil or proprietary about a closed community maintaining a distro. I think that's how most people actually think about the distro they use. You disagree with the design. That's fine. Just stick to the facts. The fact is that the system is 100% Open Source and Free Software. Another fact is that it in no way blocks access to other vendors, as you claim.

EOF.