Announcement

Collapse
No announcement yet.

Canonical Releases "Ubuntu on Windows Community Preview"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by Mez' View Post

    Also Charlie68
    I see sandboxing leading to different issues (theming, save locations or thumbnails). Issue I don't have otherwise. I'm not obsessed with security and the trade-off is not worth it for me. Plus, I haven't had one security issue with PPAs in 15 years, not a single one.
    I see several versions of the same libraries multiplying over time (not in the short term as packages can reuse a version already present when possible) depending on the frequency of app updates, and on which versions they are relying. This will go in many directions and bloat the system somehow. Storage costs being lower (yet quite high) is no excuse to stop mutualizing and to do something less clean. Even if "clean" means a bit more difficult to maintain.
    It has worked for 20+ years, I don't see why all of a sudden when more tools are available to reduce packaging time or manual intervention, we should go back to a mediocre one size fits all Windows approach. It's the same as that trend to progressively reduce speed limits on roads everywhere when technology has evolved. It's a regression to a previous state that entirely denies everything has changed in the meantime and can be done faster and with less intervention. Like going back in time.

    There is such thing as a theme, even as a hack, given how ugly adwaita is (the GTK part). It's the lamest default theme there is, the Citro├źn CX or the Fiat Multipla of GTK themes, it already was 15-20 years ago (Gnome 2), still was 10 years ago (Gnome 3), and is even more so today (Gnome 40). Anything is better basically and justifies hacking. Every time I use it for 10 seconds to refresh a modification I made to another (modern) theme, I feel like going from a mid-segment 2020's Mercedes/Volvo to a 15 years old Dacia, suddenly I get a rough edges and cheap feeling, as if there were no finishing touches, no attention to details. The typical Red Hat half-baked design.
    User themes is typically your first extension, although most distros already do that job for you.



    Red Hat is worse than Canonical to me because they impose you their stuff (that they designed unilaterally, with no user feedback taken into account). They give you no choice, no alternative and even discourage them. If that's not your usual way of executing your workflow or use case, you're screwed and have to do stuff in a counter-intuitive (and/or less productive) way for you because they don't empower you to pick your own preferred way. It's an arrogant mindset (we know better than yourself) and I don't want to be trapped in that, because tomorrow they will force me again to change something else and be less productive with their different way. I'm really not against change, but I like to decide and weigh in if and when it's worth changing my way for a different one. I want to make the change because I think it's better for me, not because I was forced to. The Red Hat way works for good soldiers, yes men, obedient unquestioning followers, but people who decide for themselves and have better ways for them to satisfy their workflow are often left without the possibility to decide anything (except through 3rd party unsupported extensions).
    Although Canonical and Ubuntu are much more user-centric and focused on satisfying the variety of workflows and use cases, they might sometimes force you into something as well, and to get back (slightly) to the topic, snap is indeed an example of that, as they try to blur the frontier and to install snap without you always being aware of it. Which is why I have used "apt-mark hold snapd" so as not to be bothered. It might seem paradoxical with what I said above, but I stress this because I'm not always in line with what they do, I'm not following them blindly. Never have, never will. I'm not convinced by their every move. Yet, in general (beside some exceptions) they try to empower their users and offer them options so that they can decide for themselves. I've never felt trapped with them the way I am when using Gnome or wayland (both RH babies).
    It's not about big corporations in my case. It really is about the Red Hat mindset. It's contrary to my principles (everyone should be empowered to decide what is best for him/her, even if I don't like something, e.g. desktop icons, I still expect others who need it to have it). That's also why I like Canonical, they're the only ones standing up against the Red Hat dictatorship tendencies. They don't have the same financial means, so they can't completely oppose. But at least they have the balls to take a different path and pull their design from users when Red Hat is not being pragmatic and is trying to push their dev-centric approach to everyone.


    I could agree with these if Red Hat was giving a choice. They don't. At some point you will have no choice but to do things their way, because they're gonna cut down everything standing in the way, disregarding entirely what users would have preferred.
    You raise a lot of interesting points, some are a matter of preference, others are legitimate concerns (eg. systemd, wayland). One distro that lets you avoid both of these is Void Linux, which I need to look into more myself. I think you are right that Canonical are more user centric, although the Linux desktop has become less and less of a priority for them. IoT, container technologies, cloud based services seem to be where their business has been focused - this could of course change. They do serve as a good counterbalance to Red Hat though, and they have contributed a lot to Gnome usability and optimiztion.

    My hope is that flatpak/snap/appimage etc. will iron out these kinks and also allow packagers to control the degree of sandboxing. This could mean I could stay on Debian XFCE or Gnome and still be able to have recent versions of apps like Libreoffice, Firefox etc. Perhaps all of these package formats will simply co-exist the way different installers do on Windows. Either way, I suspect our concerns with Flatpak/Snap will somewhat vanish over time as they mature.

    Another area to pay attention is to ElementaryOS as they are perhaps the one of if not the only distribution that are close to delivering a cohesive experience. As always, Debian remain important for the ecosystem as well.

    Comment


    • #72
      Originally posted by nado View Post

      With that mind set we might as well just stick to Windows and other proprietary solutions that aren't open for review. No thanks, if I'm using Linux I don't want to support a centralized back-end solution that's propietary. There is a trade off of course, but that's will be the case with anything.
      It's a web server with an open source API. You really think it's critical for you to have access to Canonical's internal server systems for using an open source package system? I will never understand why people are so obsessed with that. The reason we have public protocols is that you are not supposed to care about the inside of a server, but only the outside. Do you have access to prove that Debian or other distros aren't using any scripts on the server side that they haven't released to the public?

      You have to be totally fanatic to compare this to Windows.

      Comment


      • #73
        Originally posted by jo-erlend View Post

        It's a web server with an open source API. You really think it's critical for you to have access to Canonical's internal server systems for using an open source package system? I will never understand why people are so obsessed with that. The reason we have public protocols is that you are not supposed to care about the inside of a server, but only the outside. Do you have access to prove that Debian or other distros aren't using any scripts on the server side that they haven't released to the public?

        You have to be totally fanatic to compare this to Windows.
        Yea you're right, that was a bit of an exaggeration from my side. I've given it some thought and I realize that Flatpak/Snap/AppImage can coexist without issue. What I would hope though is that they work together in the future... format wars are ridiculous. Also, what you say about Debian is a good point, I'll just have to give Canonical the benefit of the doubt.

        On a different note though, why are all Snaps compressed? I can understand wanting to conserve space and bandwidth on mobile/IoT, but for desktops it doesn't make sense to me. Is this an optional or mandatory feature?

        Comment


        • #74
          Originally posted by nado View Post
          Also, what you say about Debian is a good point, I'll just have to give Canonical the benefit of the doubt.
          You don't actually have to give them the benefit of the doubt. The fact is that even if they had released their internal system, you wouldn't be able to use it, because it's coded for their use and you won't be using their internal setup. It's like not publishing your backup scripts because they have hardcoded paths that aren't useful to anyone other than you. You could call that proprietary software, I guess, but I don't think that's what most people mean by proprietary software.

          On a different note though, why are all Snaps compressed? I can understand wanting to conserve space and bandwidth on mobile/IoT, but for desktops it doesn't make sense to me. Is this an optional or mandatory feature?
          The files are compressed, but they're replacing the decompression algorithm with one that's much faster than the old one, which AIUI was used for compatibility with Android, which was important to Ubuntu Phone. They could of course decompress the files on install on desktops, but I think they have more important things to worry about than that.

          Comment


          • #75
            Originally posted by nado View Post

            My hope is that flatpak/snap/appimage etc. will iron out these kinks and also allow packagers to control the degree of sandboxing.
            AppImage doesn't have sandboxing. It's just a self-contained filesystem that happens to allow for execution, sort of like autorun on a CD-ROM. In the case of snaps, you have interfaces for reusable escapes from the sandbox. I'm on more shaky grounds now, but I also think that snaps allow for bind mounting stuff, which obviously escapes the sandbox as well, buf if you try to bind mount something that's dangerous to the user, then you need to go through a manual validation process to confirm that you're not doing anything harmful to the user.

            What am I missing?

            Comment


            • #76
              Originally posted by jo-erlend View Post

              The files are compressed, but they're replacing the decompression algorithm with one that's much faster than the old one, which AIUI was used for compatibility with Android, which was important to Ubuntu Phone. They could of course decompress the files on install on desktops, but I think they have more important things to worry about than that.
              You're probably right about that. The fact that they're currently compressed makes me more inclined to use Flatpaks for desktop apps though, the launch times are much faster. Do Snaps decompress once to local storage and persist across reboots, or do they just store the decompressed data in RAM?

              Originally posted by jo-erlend View Post

              AppImage doesn't have sandboxing. It's just a self-contained filesystem that happens to allow for execution, sort of like autorun on a CD-ROM. In the case of snaps, you have interfaces for reusable escapes from the sandbox. I'm on more shaky grounds now, but I also think that snaps allow for bind mounting stuff, which obviously escapes the sandbox as well, buf if you try to bind mount something that's dangerous to the user, then you need to go through a manual validation process to confirm that you're not doing anything harmful to the user.

              What am I missing?
              Seems you can run appimage with sandboxing via firejail, though I honestly don't know much about appimage. https://firejail.wordpress.com/docum...support/#usage

              Comment


              • #77
                Originally posted by nado View Post

                You're probably right about that. The fact that they're currently compressed makes me more inclined to use Flatpaks for desktop apps though, the launch times are much faster. Do Snaps decompress once to local storage and persist across reboots, or do they just store the decompressed data in RAM?
                I don't fully understand the question, I think. Snaps use SquashFS, like AppImage does. Would any compressed filesystem ever require you to either load everything to RAM or not load them at all? Sounds like a pretty horrible filesystem in that case.

                Seems you can run appimage with sandboxing via firejail, though I honestly don't know much about appimage. https://firejail.wordpress.com/docum...support/#usage
                As a Linux user, you're free to jail anything you want to jail. The difference between SELinux and AppArmor is that SELinux requires the filesystem to allow you to add some tags to things, whereas AppArmor only requires paths. So, for instance, AppArmor has been able to granulate access to NFS for more than a decade, whereas SELinux is just getting it now, by altering NFS.

                Why should a package manager make assumptions on what choices you've made earlier in your life? Seems a bit presumptuous, does it not?

                Comment


                • #78
                  Originally posted by jo-erlend View Post

                  I don't fully understand the question, I think. Snaps use SquashFS, like AppImage does. Would any compressed filesystem ever require you to either load everything to RAM or not load them at all? Sounds like a pretty horrible filesystem in that case.
                  Seems a bit condescending... I'm not going to argue, it was just a question. I think I'm starting to understand why people say the Linux community is toxic.

                  As a Linux user, you're free to jail anything you want to jail. The difference between SELinux and AppArmor is that SELinux requires the filesystem to allow you to add some tags to things, whereas AppArmor only requires paths. So, for instance, AppArmor has been able to granulate access to NFS for more than a decade, whereas SELinux is just getting it now, by altering NFS.

                  Why should a package manager make assumptions on what choices you've made earlier in your life? Seems a bit presumptuous, does it not?
                  I don't know, you asked and I just recalled that it had this form of sandboxing....

                  Comment


                  • #79
                    Originally posted by nado View Post

                    Seems a bit condescending... I'm not going to argue, it was just a question. I think I'm starting to understand why people say the Linux community is toxic.
                    This is an asynchronous environment. There is no guarantee that I will ever see your response. Given that premise, would you rather have me overestimate you or underestimate you? If I underestimate you, then you will get the data, but if I overestimate you, then you will be left with questions you don't know how to ask and might never get a response to.

                    I'm aware that I know nothing about you and I'm conscious of the fact that I probably know more than you do. I'm not trying to affect your emotions at all, because I don't know who you are. What I am trying to do, is to speak to those who know less than I do so that if they don't understand, then they can ask questions. If I say things that they don't understand, then they will be unable to ask questions, because they don't know what to ask.

                    I'm not here to care about your emotions at all. You buy my knowledge with your ignorance and vice versa. That's how it works. If you think that's toxic, then you're on the wrong scene. Why do you think I'm writing to you at all if it isn't to learn from you? I have no time to hold your hand.

                    I'm not here to fight. You are of absolutely no importance to me. I only care about what I can learn and what I can teach.

                    Comment


                    • #80
                      Originally posted by jo-erlend View Post

                      This is an asynchronous environment. There is no guarantee that I will ever see your response. Given that premise, would you rather have me overestimate you or underestimate you? If I underestimate you, then you will get the data, but if I overestimate you, then you will be left with questions you don't know how to ask and might never get a response to.

                      I'm aware that I know nothing about you and I'm conscious of the fact that I probably know more than you do. I'm not trying to affect your emotions at all, because I don't know who you are. What I am trying to do, is to speak to those who know less than I do so that if they don't understand, then they can ask questions. If I say things that they don't understand, then they will be unable to ask questions, because they don't know what to ask.

                      I'm not here to care about your emotions at all. You buy my knowledge with your ignorance and vice versa. That's how it works. If you think that's toxic, then you're on the wrong scene. Why do you think I'm writing to you at all if it isn't to learn from you? I have no time to hold your hand.

                      I'm not here to fight. You are of absolutely no importance to me. I only care about what I can learn and what I can teach.
                      Fair enough, it was more the way you worded yourself that was less than optimal and seemed derogative. I may have also simply misinterpreted it, if so I apologize. Either way, I understand now that wasn't your intent, thanks your honesty and clearing it up.

                      Getting back to the subject though, I don't know as much about Snaps as you do, and I am always open to learn more so I can understand better. What my initial question was is quite simple: When you launch a Snap for the first time I am under the impression it deompresses and therefore takes longer to launch, but subsequent launches will be faster - does this process have to be repeated after you reboot or is it cached indefinitely to the disk?
                      Last edited by nado; 08 April 2021, 09:44 AM.

                      Comment

                      Working...
                      X