home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.linux.mint      Looks pretty on the outside, thats it!      30,566 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 30,163 of 30,566   
   RonB to Paul   
   Re: [RESOLVED]: Where is firefox 'execut   
   05 Jan 26 21:00:07   
   
   From: ronb02NOSPAM@gmail.com   
      
   On 2026-01-05, Paul  wrote:   
   > On Sun, 1/4/2026 11:32 PM, RonB wrote:   
   >> On 2026-01-04, Paul  wrote:   
   >>> On Sun, 1/4/2026 4:30 AM, Heinz Schmitz wrote:   
   >>>> Paul     wrote:   
   >>>>   
   >>>>> Note that, on Ubuntu, a lot of executables are packaged in SNAP packages,   
   >>>>> making it a lot harder to edit a .desktop file and define a menu entry   
   properly.   
   >>>>> For the end user, a SNAP is extra work.   
   >>>>   
   >>>> SNAP is like a government inside a government.   
   >>>> If you happen to have set up your system while they had snap already   
   >>>> within, you just need a larger hard disk.   
   >>>> If you are caught with a system while they make the transition to snap   
   >>>> you are fu...d.   
   >>>>   
   >>>> Does any of the ubuntu programmers do use their system themselves?   
   >>>>   
   >>>> Regards,   
   >>>> H.   
   >>>   
   >>> I suppose the staff at Canonical work there... because they are being paid.   
   >>>   
   >>> That is about the most charitable thing I can say.   
   >>>   
   >>> Modularity has known benefits. Who battles against modularity and why ???   
   >>>   
   >>>    Paul   
   >>   
   >> Modularity also has drawbacks, I use Flatpaks and AppImages only when I need   
   >> the newest version of an application and there is no other choice.   
   >>   
   >> I don't like redundancy and bloat.   
   >>   
   >   
   > The .deb scheme works fine. It does not need another layer of nonsense   
   > on top of it.   
   >   
   > When you wrap something like Gnome up as a SNAP, any program   
   > which needs to refer to one of the GNOME internal debs, has to   
   > download the debs it needs separately. This basically doubles   
   > the downloads for graphical things (you paid for a SNAP but   
   > cannot reuse any of the contents).   
   >   
   >            +------------------------+ The Gnome SNAP   
   >            | Internal dependencies  |   
   >            | are included inside    |   
   >            | the SNAP and cannot    |   
   >            | be accessed            |   
   >            | externally.            |   
   >            | 1.deb 2.deb 3.deb      | Access to the file system is   
   "controlled"   
   >            +------------------------+ for the executable in here.   
   >   
   >              graphical-program   
   >                 1.deb           (dependency, need to download)   
   >                 2.deb           (dependency, need to download)   
   >                 3.deb           (dependency, need to download)   
   >   
   > It's just a make work project.   
   >   
   > Debian seems to work fine without that. I download the dependency once.   
   > That's what I mean by modular. Shared libraries .so, we load them once   
   > and everybody can use them. Each of those .deb could have a library .so   
   > we need.   
   >   
   >              some-gnome-thing   
   >                 1.deb           (dependency, need to download)   
   >                 2.deb           (dependency, need to download)   
   >                 3.deb           (dependency, need to download)   
   >   
   >              graphical-program  (1.deb 2.deb 3.deb already on disk)   
   >   
   >    Paul   
      
   I misunderstood. I was thinking of "modularity" as "modules" and applying   
   that to Snaps, Flatpaks or AppImages.   
      
   Sorry for my ignorance on the correct use of terms. I agree with you.   
      
   --   
   "Not just stupid... Trump stupid."   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca