No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by CochainComplex View Post
    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.



    • #62
      Originally posted by jo-erlend View Post

      Having a proprietary backend for a website is normal. Is Red Hats subscription backend open to the public or do you condemn 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.
      Websites are not traditional packages, are neither Snap or Flatpak, for reasons all details of a website are not relevant to an ecosystem. In isolated fashion, the scripts are relevant, (says RMS) and if the web stopped working well because all of them are hosted at Google, then likewise the web 2 would be worse than the web 1. That the underlying technology of the web is good in both cases, and allows for mitigation, does not change that. Part of the point is being sleek. If RPMs have feature parity with Debs, it doesn't matter what RedHat does, similar to end-result of efforts re-implementing web 2 type functionality from Google.

      Your logical shortcuts are: "Could make", "is normal", and "~extensions"", when the argument is whether functionality is present or not. Required is beside the point. Canonical made functionality for Snap which is similar to what Flatpak has, closed source.

      "Could" means don't have to, normality is just as likely _less normal being good_, and what amounts to extensions are relevant, but not part of the picture.


      • #63
        Originally posted by kingu View Post
        Websites are not traditional packages, are neither Snap or Flatpak, for reasons all details of a website are not relevant to an ecosystem. …
        You're confused. We are not talking about packages or package systems here. The package system is GPL. Nobody's claiming this is not FOSS. Like apt, the snap system uses HTTP to deliver packages to the end user. An apt repository is a web site and so is a snap repository. The criticism is that Canonical's internal web server setup is not open to the public, hence it's a proprietary setup. This is a technical truth, because all software is proprietary and closed source until you share it under an Open Source license. The moment you write a script for your personal use and don't share it, you're running proprietary software. I have lots of scripts that I haven't shared. Don't you? This is what I mean by "normal". It is something all users should do and something all advanced Linux users do on a regular basis. There isn't anything wrong with it, but it is technically true that this makes them proprietary software developers. It is just a very strange use of language. It's deceptive.

        The snap client is undoubtedly Open Source and the server is any webserver. The thing that's "proprietary" is the script that implements the Open Source REST API. This is also the part that would be implemented differently by all repository owners, simply because they wouldn't have the exact same network setup as Canonical has.