Announcement

Collapse
No announcement yet.

Ubuntu Delays Transition To Snap'ed CUPS Print Server

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

  • #21
    Originally posted by cynic View Post

    I guess this is to better integrate with upstart, Mir, Unity and all the other great Canonical products
    They want vendor lock-in.

    Comment


    • #22
      Originally posted by ed31337 View Post
      I hate snaps. They take up more disk space, take longer to start up, and they take up a lot more memory than if you just used the Debian deb's of the same. Back when I was using Ubuntu, I de-snapified everything and it was so much better.
      The purpose of snaps is vendor lock-in. No other distro uses them. Also AMD and Intel make faster processors with larger memory support. The purpose of faster hardware is to run the same software as fast as it used to run few years ago.

      Comment


      • #23
        Originally posted by sarmad View Post

        The main advantage is to be able to push updates to the print stack independently from the OS. This will be helpful in keeping the system up to date with newer print drivers.
        With the small downside of unpatched vulnerabilities in system libraries being more likely to persist on the system.

        Comment


        • #24
          Originally posted by phoronix View Post
          Phoronix: Ubuntu Delays Transition To Snap'ed CUPS Print Server

          Since 2021 among other Snap'ing efforts for converting formerly Ubuntu DEB packages to Canonical's Snap sandboxed app packaging format has been the CUPS print server. The plan was to replace the Debian-packaged CUPS with the Snap-based CUPS for Ubuntu 23.10 but now that is being pushed back to next year...

          https://www.phoronix.com/news/Ubuntu-Delays-Snap-CUPS
          A rough guess is that the printing stack is always vulnerable to security issues. Containerising the printing stack can make it more secure and avoid many attack vectors.

          Personally, though, the most I'm looking forward to the Ubuntu 24 Core Desktop. While on mixed systems (APT/RPM + Snap/Flatpak) Snap is often at a disadvantage compared to Flatpak in the desktop area, where on a pure snap-based desktop snap can show its full strengths . When fully Snap is used, it is superior to Flatpak-based immutable systems.

          With Fedora Silverblue, all libraries are installed in triplicate for normal usage (base system libs + Fedora Flatpak Libs + Flathub Flatpak Libs). The libraries have also been installed at least twice on other immutable OSes, e.g. openSUSE Aeon (base system libs + flathub libs)

          With the ubuntu Core Desktop, on the other hand, the entire system is based on Snap. All libraries are only installed once (Gnome, Mesa, etc.), which saves storage space since APT is completely eliminated. Since all snap libraries are preloaded when the system is started, the disadvantage of long start-up times for snap-based apps is also eliminated. On the current Core Desktop dev preview (found on Github), app load times are as fast or less than on a regular Ubuntu desktop or Flathub-based system.​

          Comment


          • #25
            Originally posted by Malsabku View Post
            With the ubuntu Core Desktop, on the other hand, the entire system is based on Snap. All libraries are only installed once (Gnome, Mesa, etc.), which saves storage space since APT is completely eliminated. Since all snap libraries are preloaded when the system is started, the disadvantage of long start-up times for snap-based apps is also eliminated. On the current Core Desktop dev preview (found on Github), app load times are as fast or less than on a regular Ubuntu desktop or Flathub-based system.​
            Benchmark opportunity right here

            Comment


            • #26
              I really just don't understand why printers require a driver at all when we could just remotely mount to ~/printers and simply copy a file to
              PHP Code:
              ~/printers/my-printer/queue 
              and then it can be moved to
              PHP Code:
              ~/printers/my-printer/completed 
              on completion.

              If additional settings are required to be inputted, the printer is typically literally a device with a touch screen where you can input additional specifications with a 100% success rate -- no dicking around with Win, Mac Linux, Legacy drivers, no drivers or anything.

              Why do we literally not do this.
              Last edited by ElectricPrism; 25 August 2023, 04:18 PM.

              Comment


              • #27
                Originally posted by ElectricPrism View Post
                I really just don't understand why printers require a driver at all when we could just remotely mount to ~/printers and simply copy a file to
                PHP Code:
                ~/printers/my-printer/queue 
                and then it can be moved to
                PHP Code:
                ~/printers/my-printer/completed 
                on completion.

                If additional settings are required to be inputted, the printer is typically literally a device with a touch screen where you can input additional specifications with a 100% success rate -- no dicking around with Win, Mac Linux, Legacy drivers, no drivers or anything.

                Why do we literally not do this.
                this is pretty much what cups does.
                the drivers/cups tell the system how to actually talk to "my-printer", charge your printing account, and do all that other fun administrative stuff.

                Comment


                • #28
                  Originally posted by Malsabku View Post

                  With Fedora Silverblue, all libraries are installed in triplicate for normal usage (base system libs + Fedora Flatpak Libs + Flathub Flatpak Libs). The libraries have also been installed at least twice on other immutable OSes, e.g. openSUSE Aeon (base system libs + flathub libs)

                  With the ubuntu Core Desktop, on the other hand, the entire system is based on Snap. All libraries are only installed once (Gnome, Mesa, etc.), which saves storage space since APT is completely eliminated. Since all snap libraries are preloaded when the system is started, the disadvantage of long start-up times for snap-based apps is also eliminated. On the current Core Desktop dev preview (found on Github), app load times are as fast or less than on a regular Ubuntu desktop or Flathub-based system.​
                  Are you working for the marketing department of Canonical? With Silverblue the base system is very basic. So updates are easy and there is no need for LTS versions anymore. And with flatpak you have so many different libraries like you have runtime except the files have the same sha. If ubuntu is sharing the libraries then you get the same problem as with traditional systems.

                  Comment


                  • #29
                    Originally posted by spyke View Post
                    I hope there will be something similar for Flatpak as well.
                    There is no need to turn flatpak into something for services. Flatpak is for desktop apps only.

                    The analogue of flatpak for services is called docker (or one of it's variants).
                    Last edited by oleid; 26 August 2023, 01:23 AM.

                    Comment


                    • #30
                      Originally posted by ssokolow View Post
                      The clock ticks ever closer to me dumping Kubuntu for something else. Thankfully, progress marches forward on getting everything I don't mind being Debian stale packaged into Flatpaks.
                      I did drop Kubuntu years ago in the time Canonical did make deal with Microsoft what makes ubuntu part of the evil microsoft empire. also KDE is evil CLA-WAR...

                      you better install Fedora 38 cinnamon Editon. cinnamon i similar to KDE but is based on GTK/Gnome.
                      Phantom circuit Sequence Reducer Dyslexia

                      Comment

                      Working...
                      X