Re: ubuntu/snap future
On 4/7/21, Dan Ritter wrote: >> riveravaldez wrote: >> >> Hi, I was under the impression that (besides being fully open) Flatpak >> had >> better confinement method that Canonical's Snap, anybody knows if this is >> correct? > > "Two years ago I wrote about then heavily-pushed Flatpak, > self-proclaimed "Future of Apps on Linux". The article > criticized the following three major flows in Flatpak: > > Most of the apps have full access to the host system but > users are misled to believe the apps are sandboxed > The flatpak runtimes and apps do not get security updates > Flatpak breaks many aspects of desktop integration" > > -- https://flatkill.org/2020/ > > (the article then says that they fixed some desktop integration > issues) Hi, just in case anyone is interested in the following of this, I've asked at Flatpak's mail-list about the issues mentioned in that article and someone from GNOME pointed me to this post[0], which I still didn't read. So, at the moment, just reporting. ;) Best regards. [0] https://ramcq.net/2018/10/15/flatpak-sandbox-security/
Re: ubuntu/snap future
On 4/9/21 9:26 PM, Brian wrote: In response to this well-argued post: which is less risky when not installing a package from the archives? * Install the vendor .deb. * Install from the snap store. Both are providing about the same level of isolation. One can make more bad things with your system files, but... https://xkcd.com/1200/ If you need to run more-or-less trusted proprietary vendor, use VM. If you need to run untrusted blob, use separate machine.
Re: ubuntu/snap future
On 4/6/21 2:49 PM, Brian wrote: On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote: Hello everybody out there! On 2021/04/06 at 01:53 am, Paul Johnson wrote: There's nothing user-unfriendly about .debs. They just don't want to maintain their software and are looking for a "fire and forget" solution. I can't see this as anything but a bad thing, something the world can live without. Well, I do not like the way Ubuntu uses snaps, but there are some good reasons to use something like snaps or flatpacks. Even with a less careful procedure to integrate and update packages than the one of Debian (which I like), create a new package and update one take some time. There are several examples when a user needs a bug fix or some functionality that packages in distributions do not provide. In such a case, without snaps or flatpacks, the user has to compile the program, which need some technical skills and can be sometimes really tricky. Appimages are less interesting, as you have to update them manually. Use parsimoniously, packages like snaps or flatpacks are something very useful, which improve user experience even for power users. The problem with Ubuntu is it uses way too much snaps and I do not think it is a matter of laziness. I had occasion to install Zoom a few weeks ago;'snap install zoom-client'. Everything went smoothly and I quite like having this proprietary package strictly confined. To the respect of the producer of the Zoom, they don't try to install rootkit stuff like Chrome does. But I would argue that at X/Pulseaudio landscape it's impossible to confine desktop application for real. pulseaudio allows to load plugins, and that is remote code execution. X does not block application from interacting with random stuff on screen (including screensaver and password manager) so desktop isolation is fiction. ... And here the main part. I really don't want to see Linux desktop walking Android path. Do we really need to protect address book from a image editor or calculator? I really trust GIMP not doing anything nasty under the hood. I don't need heavy and slow jails for it. I prefer cooperation and trust (is Debian all about trust?).
Re: ubuntu/snap future
On Fri, 09 Apr 2021 21:30:45 +0200 Linux-Fan wrote: > Celejar writes: > > > On Fri, 9 Apr 2021 20:48:01 +0300 > > Andrei POPESCU wrote: > > > > > On Vi, 09 apr 21, 08:02:46, Celejar wrote: > > > > What about cases where the software simply isn't in Debian at all? > > > > Recently, I've used IntelliJ IDEA and Android Studio, and I'd like to > > > > set up an OwnCloud server when I get a chance. These, and many other > > > > complex / fast-changing applications aren't in Debian, but are > > > > available in containerized app formats. > > [...] > > > Have the packages I'm interested in not been in unstable because > > potential maintainers knew they couldn't make it into stable (and now > > that there's fasttrack, they'll get into unstable), or is there some > > other reason they can't be in unstable (and hence can't make it to > > fasttrack either)? > > I do not know it for the excact packages you mentioned but to me it seems > quite plausible that there are modern open source applications which cannot > be easily included in Debian (not even in unstable). AFAICT it boils down to > the fact that some of that applications' build processes do not meet > Debian's high quality standards (formally: Debian Policy). For NextCloud, see this thread (there's some discussion of the fasttrack option as well): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835086 Celejar
Re: ubuntu/snap future
Celejar writes: On Fri, 9 Apr 2021 20:48:01 +0300 Andrei POPESCU wrote: > On Vi, 09 apr 21, 08:02:46, Celejar wrote: > > What about cases where the software simply isn't in Debian at all? > > Recently, I've used IntelliJ IDEA and Android Studio, and I'd like to > > set up an OwnCloud server when I get a chance. These, and many other > > complex / fast-changing applications aren't in Debian, but are > > available in containerized app formats. [...] Have the packages I'm interested in not been in unstable because potential maintainers knew they couldn't make it into stable (and now that there's fasttrack, they'll get into unstable), or is there some other reason they can't be in unstable (and hence can't make it to fasttrack either)? I do not know it for the excact packages you mentioned but to me it seems quite plausible that there are modern open source applications which cannot be easily included in Debian (not even in unstable). AFAICT it boils down to the fact that some of that applications' build processes do not meet Debian's high quality standards (formally: Debian Policy). See, for instance: * https://lists.debian.org/debian-user/2020/04/msg01281.html * https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ * https://lwn.net/Articles/842319/ * https://xkcd.com/2347/ I do not think that the solution to these issues has been found yet -- they run quite deeply and affect (at least) multiple Linux distributions. HTH Linux-Fan öö [...] pgp7hIfVnNYt5.pgp Description: PGP signature
Re: ubuntu/snap future
On Fri, 9 Apr 2021 20:48:01 +0300 Andrei POPESCU wrote: > On Vi, 09 apr 21, 08:02:46, Celejar wrote: > > > > What about cases where the software simply isn't in Debian at all? > > Recently, I've used IntelliJ IDEA and Android Studio, and I'd like to > > set up an OwnCloud server when I get a chance. These, and many other > > complex / fast-changing applications aren't in Debian, but are > > available in containerized app formats. > > https://fasttrack.debian.net/ > > (it's still an experiment, hence the .net TLD) Interesting, thanks! "the package has to be in unstable" Have the packages I'm interested in not been in unstable because potential maintainers knew they couldn't make it into stable (and now that there's fasttrack, they'll get into unstable), or is there some other reason they can't be in unstable (and hence can't make it to fasttrack either)? Celejar
Re: ubuntu/snap future
On Fri 09 Apr 2021 at 20:43:58 +0300, Andrei POPESCU wrote: > On Vi, 09 apr 21, 06:34:32, riveravaldez wrote: > > On 4/9/21, to...@tuxteam.de wrote: > > > > > > Is it really unavoidable? Or just a tad less convenient? > > > > Well, that's a pretty subjective issue, to be honest... ;) > > > > > Can you pose one concrete use case where it is unavoidable? > > > > Not sure if *unavoidable* but I didn't found a better solution at the > > time: > > A client for which laptop I'd installed Debian was in job-need of > > using Skype and Zoom. Her employers wouldn't use anything > > else, so, I was looking for the better/safer way to install such damn > > closed-source pieces of soft (in particular I hate Zoom, but that's > > another subjective issue...) in a for anything else fully libre/secure > > perfectly working Debian system. > > I have no idea what the official .deb packages from Skype/Zoom > > do, so, to minimize exposition and control-lost looked for an easy > > way to 'enclose' what those programs could do, and opted finally > > for Flatpak just to avoid any Canonical late-inconvenience... > > Just a general reminder: dpkg will execute all maintainer scripts > contained in the package as root. > > Packages can also contain various other files that can have a big impact > on system security, like system .service files, cron jobs/timers running > as root, SUID binaries, etc., even if the program itself is (meant to > be) run only as a regular user. > > If you care about the security of your system inspecting the .deb before > 'dpkg -i' is always a good idea (e.g. with mc or so). > > If you are adding foreign repositories you are also trusting them for > all package updates, for *any* package on your system. > > By default APT doesn't care from which repository a particular package > is coming from, as long as it has the higher version, and that is easy > enough to manipulate (e.g. with an epoch). A trusted repository could > then easily substitute *any* package on your system (kernel, init, > shell, etc.) via package upgrades. > > The repository doesn't even have to be evil, as it could always be > hijacked by a bad actor. In response to this well-argued post: which is less risky when not installing a package from the archives? * Install the vendor .deb. * Install from the snap store. -- Brian.
Re: ubuntu/snap future
On Vi, 09 apr 21, 08:02:46, Celejar wrote: > > What about cases where the software simply isn't in Debian at all? > Recently, I've used IntelliJ IDEA and Android Studio, and I'd like to > set up an OwnCloud server when I get a chance. These, and many other > complex / fast-changing applications aren't in Debian, but are > available in containerized app formats. https://fasttrack.debian.net/ (it's still an experiment, hence the .net TLD) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: ubuntu/snap future
On Vi, 09 apr 21, 06:34:32, riveravaldez wrote: > On 4/9/21, to...@tuxteam.de wrote: > > > > Is it really unavoidable? Or just a tad less convenient? > > Well, that's a pretty subjective issue, to be honest... ;) > > > Can you pose one concrete use case where it is unavoidable? > > Not sure if *unavoidable* but I didn't found a better solution at the > time: > A client for which laptop I'd installed Debian was in job-need of > using Skype and Zoom. Her employers wouldn't use anything > else, so, I was looking for the better/safer way to install such damn > closed-source pieces of soft (in particular I hate Zoom, but that's > another subjective issue...) in a for anything else fully libre/secure > perfectly working Debian system. > I have no idea what the official .deb packages from Skype/Zoom > do, so, to minimize exposition and control-lost looked for an easy > way to 'enclose' what those programs could do, and opted finally > for Flatpak just to avoid any Canonical late-inconvenience... Just a general reminder: dpkg will execute all maintainer scripts contained in the package as root. Packages can also contain various other files that can have a big impact on system security, like system .service files, cron jobs/timers running as root, SUID binaries, etc., even if the program itself is (meant to be) run only as a regular user. If you care about the security of your system inspecting the .deb before 'dpkg -i' is always a good idea (e.g. with mc or so). If you are adding foreign repositories you are also trusting them for all package updates, for *any* package on your system. By default APT doesn't care from which repository a particular package is coming from, as long as it has the higher version, and that is easy enough to manipulate (e.g. with an epoch). A trusted repository could then easily substitute *any* package on your system (kernel, init, shell, etc.) via package upgrades. The repository doesn't even have to be evil, as it could always be hijacked by a bad actor. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 08:23:59PM +0300, Andrei POPESCU wrote: > On Vi, 09 apr 21, 13:39:27, to...@tuxteam.de wrote: > > On Fri, Apr 09, 2021 at 01:09:31PM +0200, Yoann LE BARS wrote: > > > > > > Now, I have develop a few small applications who do not have much users > > > and are not in the position to integrate the distribution. For the few > > > users of these programs, it is way easier for them that I give an > > > Appimage or a Flatpak. > > > > Those last data points are a bit concerning. It'd be interesting what a > > project like Debian could do to mitigate that. > > Make packaging easier? > > As far as I understand dh is pretty good and many packages can get away > with a minimal debian/rules. Yay for dh, yes. But there's some learning curve, nevertheless. Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On Vi, 09 apr 21, 13:39:27, to...@tuxteam.de wrote: > On Fri, Apr 09, 2021 at 01:09:31PM +0200, Yoann LE BARS wrote: > > > > Now, I have develop a few small applications who do not have much users > > and are not in the position to integrate the distribution. For the few > > users of these programs, it is way easier for them that I give an > > Appimage or a Flatpak. > > Those last data points are a bit concerning. It'd be interesting what a > project like Debian could do to mitigate that. Make packaging easier? As far as I understand dh is pretty good and many packages can get away with a minimal debian/rules. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 11:01:13AM -0400, Stefan Monnier wrote: > > But I'll bitch and moan loudly to my interlocutor. > > Good. > > > Perhaps I'll lie and say that I've got just a telephone or something. > > Better not: better tell them clearly why you refuse to use that tool. I forgot the tongue-in-cheek ;-P But people already put an incredulous look when I say I have no smartphone. Perhaps I'm considered a "computer guy", dunno why. I often have to whip up my dumbphone to prove it ;-) > We have a duty to educate, I think. That's basically what I try. Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
Hello everybody out there! On 2021/04/09 at 2:51 pm, to...@tuxteam.de wrote: > I still love the classical distro model: a stable base which doesn't > move too quickly (and thus doesn't require much of my attention), > which is well-vetted by maintainers (*thank you so much*), and a > couple of apps I particularly care about which I do build myself > from time to time. > > I understand that my "model" won't be everyone's, though. For instance, I have users that are not that familiar with compilation. Just some example. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: ubuntu/snap future
Hello everybody out there! On 2021/04/09 at 2:45 pm, to...@tuxteam.de wrote: > But that only really works out when the customer is nearly all-Debian, > which this one is. Like I said: not all the users are on Debian. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: ubuntu/snap future
> But I'll bitch and moan loudly to my interlocutor. Good. > Perhaps I'll lie and say that I've got just a telephone or something. Better not: better tell them clearly why you refuse to use that tool. We have a duty to educate, I think. Stefan
Re: ubuntu/snap future
On Fri, 9 Apr 2021 08:12:35 -0600 Charles Curley wrote: > On Fri, 9 Apr 2021 15:39:23 +0200 > to...@tuxteam.de wrote: > > > > Sorry, I meant NextCloud > > > > I see. I kept myself confusing those two for a while. > > > > AFAIK it's packaged in Debian? Too old? > > I use the zip package from the NextCloud web site. Once you do the > manual install, it will update itself from time to time. It's no deb > package, but I've had no problems updating. I use the stable update > channel. Yes. To be clear, NextCloud offers three official installation methods: * Archive file / source tarball, which, IIUC, requires you to configure a LAMP stack yourself (they'll walk you through it, but in my experience, this sort of thing is always tougher for non-experts than the directions make it sound) * Web installer, "the easiest way to install Nextcloud on a web space" * Appliance, i.e., a pre-built VM, "designed to be an easy way for less technical users to get Nextcloud up and running or to test it out" (so perhaps only one level of containerization, not Docker on top of a VM, as per another part of this thread) Celejar
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 09:43:47AM -0400, The Wanderer wrote: > On 2021-04-09 at 09:39, to...@tuxteam.de wrote: > > > On Fri, Apr 09, 2021 at 09:28:15AM -0400, Celejar wrote: > > > > [...] > > > >> Sorry, I meant NextCloud > > > > I see. I kept myself confusing those two for a while. > > > > AFAIK it's packaged in Debian? Too old? > > What package are you thinking of? Oops. I stand corrected. Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On Fri, 9 Apr 2021 15:39:23 +0200 to...@tuxteam.de wrote: > On Fri, Apr 09, 2021 at 09:28:15AM -0400, Celejar wrote: > > [...] > > > Sorry, I meant NextCloud > > I see. I kept myself confusing those two for a while. > > AFAIK it's packaged in Debian? Too old? The client is, but the server isn't: https://wiki.debian.org/Nextcloud#Status_of_packaging > > > I still love the classical distro model [...] > > > I fully agree, but the fact is that some really useful software just > > doesn't fit into the classic distro model. In addition to the examples > > I've given, there are also the main FLOSS Zoom alternatives we've > > discussed in previous threads: Jitsi, BigBlueButton, etc. > > Yeah. Those are said to be The Horrors, by people who tried. But they > ended up just setting up a whole VM off a docker image, so they > ditched Frankenstein and went with Godzilla ;-) And so we're back to square one: containerization. But now we're up to at least two levels: VM, Docker, etc. ;) Celejar
Re: ubuntu/snap future
On Fri, 9 Apr 2021 15:39:23 +0200 to...@tuxteam.de wrote: > > Sorry, I meant NextCloud > > I see. I kept myself confusing those two for a while. > > AFAIK it's packaged in Debian? Too old? I use the zip package from the NextCloud web site. Once you do the manual install, it will update itself from time to time. It's no deb package, but I've had no problems updating. I use the stable update channel. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/ pgppPD5tHkMCU.pgp Description: OpenPGP digital signature
Re: ubuntu/snap future
On 2021-04-09 at 09:39, to...@tuxteam.de wrote: > On Fri, Apr 09, 2021 at 09:28:15AM -0400, Celejar wrote: > > [...] > >> Sorry, I meant NextCloud > > I see. I kept myself confusing those two for a while. > > AFAIK it's packaged in Debian? Too old? What package are you thinking of? When I 'apt-cache search nextcloud' against current stable / testing, all the hits I get seem to be for clients or integration tools or the like; I don't see anything that looks like a server. (I haven't taken the trouble to check more generally, via Web interfaces.) Unless this is currently only in sid (in which case it'd be unlikely to be too old) and probably won't make it into the upcoming stable release, it doesn't look to me like it's in Debian. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 09:28:15AM -0400, Celejar wrote: [...] > Sorry, I meant NextCloud I see. I kept myself confusing those two for a while. AFAIK it's packaged in Debian? Too old? > > I still love the classical distro model [...] > I fully agree, but the fact is that some really useful software just > doesn't fit into the classic distro model. In addition to the examples > I've given, there are also the main FLOSS Zoom alternatives we've > discussed in previous threads: Jitsi, BigBlueButton, etc. Yeah. Those are said to be The Horrors, by people who tried. But they ended up just setting up a whole VM off a docker image, so they ditched Frankenstein and went with Godzilla ;-) Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 02:07:33PM +0100, Joe wrote: [...] > There's a lot to be said for web applications [...] Not my cup of tea. As a user, I downright *hate* them. As a devel (I'm currently working on such a PHP/Javascript nightmare myself), I pity the users. But there must be cup-of-teas for everyone :) Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On Fri, 9 Apr 2021 14:51:29 +0200 wrote: > On Fri, Apr 09, 2021 at 08:02:46AM -0400, Celejar wrote: > > On Fri, 9 Apr 2021 09:21:49 +0200 > > wrote: > > [...] > > > > Can you pose one concrete use case where it is unavoidable? > > > > What about cases where the software simply isn't in Debian at all? > > Recently, I've used IntelliJ IDEA and Android Studio [...] > > I see. I'm more of an Emacs guy, so I lack some experience in > that department, I admit. > > > and I'd like to > > set up an OwnCloud server when I get a chance. > > Why not NextCloud? It seems that it is there where the action is > taking place these days. Sorry, I meant NextCloud - I sometimes forget which was the original and which is the later and greater version. I suppose that the word "next" should make it easy to remember ;) > > These, and many other > > complex / fast-changing applications aren't in Debian, but are > > available in containerized app formats. > > Yes, fast-changing is a bad match for the "classical distro" model. > > I still love the classical distro model: a stable base which doesn't > move too quickly (and thus doesn't require much of my attention), > which is well-vetted by maintainers (*thank you so much*), and a > couple of apps I particularly care about which I do build myself > from time to time. I fully agree, but the fact is that some really useful software just doesn't fit into the classic distro model. In addition to the examples I've given, there are also the main FLOSS Zoom alternatives we've discussed in previous threads: Jitsi, BigBlueButton, etc. > I understand that my "model" won't be everyone's, though. > > That's why I asked for other people's experiences. Celejar
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 01:55:21PM +0100, Joe wrote: > On Fri, 9 Apr 2021 12:51:14 +0200 > wrote: > > > > > > Capitalists are like that. > > > > Non-capitalists (i.e. governments) don't need to be [...] (responded in private, to avoid starting an OT flood :) > > Up to now, I've avoided the problem. I think I'd try to go with a VM, > > or, if possible, with a small and nearly-disposable thingy, like a > > Raspberry Pi. > > > > Indeed. The Pi4 is quite powerful. Yep :-) Cheers -- t signature.asc Description: Digital signature
Re: ubuntu/snap future
On Fri, 9 Apr 2021 14:45:31 +0200 wrote: > On Fri, Apr 09, 2021 at 01:48:44PM +0200, Yoann LE BARS wrote: > > [...] > > > Concerning my own applications (they use a free licence), > > really, it is better not to engage any integration into Debian: it > > is not worth the effort nor for me, my users and the distribution. > > You cannot integrate an application that is use by something like > > ten people, including the developer. Also, some of them use Open > > Suze … > > Hm. Myself, i have one small application "out there" for just one > customer (Gtk2, C, GPL3+, although it has more ideological than > practical value, since it is really tailor-made to fit). I actually > went all the way to wrap proper Debian packaging around it. Nowadays > it's a charm, because I can leverage all of the Debian goodness (you > want a port to Raspi? No problem, just cross-build. You want it > running on that old Squeeze box [hey, didn't I tell you to upgrade?] > -- cross-build again). > > But that only really works out when the customer is nearly all-Debian, > which this one is. > There's a lot to be said for web applications, particularly when so many people use toy computers. In my house, there are Windows and Linux computers, two Androids and an iPad (not mine). I can operate my juke box and other software from any of them. Once you're running an SQL server 24/7, it's by far the easiest way to go. And my feeble little netbook has no trouble running MariaDB and Apache with PHP7 for out-of-network operation. I wasn't able to persuade an Android device to do that, even though the ports are available. -- Joe
Re: ubuntu/snap future
On Fri, 9 Apr 2021 12:51:14 +0200 wrote: > > Capitalists are like that. > Non-capitalists (i.e. governments) don't need to be, they simply imprison you if you don't do things their way. I still have a choice whether to use Zoom, etc., or at least a choice whether to install it on a computer I value. I don't have a choice about using government software. > Up to now, I've avoided the problem. I think I'd try to go with a VM, > or, if possible, with a small and nearly-disposable thingy, like a > Raspberry Pi. > Indeed. The Pi4 is quite powerful. -- Joe
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 08:02:46AM -0400, Celejar wrote: > On Fri, 9 Apr 2021 09:21:49 +0200 > wrote: [...] > > Can you pose one concrete use case where it is unavoidable? > > What about cases where the software simply isn't in Debian at all? > Recently, I've used IntelliJ IDEA and Android Studio [...] I see. I'm more of an Emacs guy, so I lack some experience in that department, I admit. > and I'd like to > set up an OwnCloud server when I get a chance. Why not NextCloud? It seems that it is there where the action is taking place these days. > These, and many other > complex / fast-changing applications aren't in Debian, but are > available in containerized app formats. Yes, fast-changing is a bad match for the "classical distro" model. I still love the classical distro model: a stable base which doesn't move too quickly (and thus doesn't require much of my attention), which is well-vetted by maintainers (*thank you so much*), and a couple of apps I particularly care about which I do build myself from time to time. I understand that my "model" won't be everyone's, though. That's why I asked for other people's experiences. Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 01:48:44PM +0200, Yoann LE BARS wrote: [...] > Concerning my own applications (they use a free licence), really, it is > better not to engage any integration into Debian: it is not worth the > effort nor for me, my users and the distribution. You cannot integrate > an application that is use by something like ten people, including the > developer. Also, some of them use Open Suze … Hm. Myself, i have one small application "out there" for just one customer (Gtk2, C, GPL3+, although it has more ideological than practical value, since it is really tailor-made to fit). I actually went all the way to wrap proper Debian packaging around it. Nowadays it's a charm, because I can leverage all of the Debian goodness (you want a port to Raspi? No problem, just cross-build. You want it running on that old Squeeze box [hey, didn't I tell you to upgrade?] -- cross-build again). But that only really works out when the customer is nearly all-Debian, which this one is. > Concerning proprietary applications, I am afraid editors are not really > willing to collaborate. Clearly, they want to to everything by their self. Of course: they will collaborate whenever it's convenient to them (the "embrace" phase). For example, Zoom does offer Debian packages. Would I install that? No way! I'd prefer the browser version, and I'll use a fresh, separate profile, and at the end, I'll soak that profile with gasoline and put a match to it (well, OK, maybe just "rm -Rf" might do ;-) But I'll bitch and moan loudly to my interlocutor. Perhaps I'll lie and say that I've got just a telephone or something. Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On Fri, 9 Apr 2021 04:15:07 -0300 riveravaldez wrote: ... > I'm still with the doubt. Even considering all this: which has better > (or less-worse) confinement, Flatpak or Snap (or AppImage)? > > Trying to decide which is less-worse in a scenario of unavoidable > use of some of these. A third solution to consider: firejail (I use Zoom firejailed) Celejar
Re: ubuntu/snap future
On Fri, 9 Apr 2021 09:21:49 +0200 wrote: > On Fri, Apr 09, 2021 at 04:15:07AM -0300, riveravaldez wrote: > > [...] > > > Trying to decide which is less-worse in a scenario of unavoidable > > use of some of these. > > Is it really unavoidable? Or just a tad less convenient? > > Can you pose one concrete use case where it is unavoidable? What about cases where the software simply isn't in Debian at all? Recently, I've used IntelliJ IDEA and Android Studio, and I'd like to set up an OwnCloud server when I get a chance. These, and many other complex / fast-changing applications aren't in Debian, but are available in containerized app formats. Some are also available in deb packages from upstream, but I'm not sure which is worse: installing a random deb from upstream, or a containerized version of the app. The deb will / may rely upon system libraries and other dependencies, which is good, insofar as everything works, but it will also have more of a chance to mess with the system (even if only accidentally). Celejar
Re: ubuntu/snap future
Hello everybody out there! On 2021/04/09 at 1:39 pm, to...@tuxteam.de wrote: >> I have found some bugs in Musescore that are corrected on a higher >> version than the one available in stable. >> >> I need some functionalities available in Ardour 6, which is not >> available in stable. > > In those cases, would a backport help? It would. >> Now, I need Discord and the only version which works after an update is >> the one available as a snap. >> >> I have also been asked to use Microsoft Teams. Well, this one never >> really works, either as a deb, a snap or a flatpak… >> >> Concerning the few proprietary softwares I use, I think I rather use >> something like snap or flatpak—I have no preferences, save the fact I >> rather have the possibility to set up y own server. >> >> Now, I have develop a few small applications who do not have much users >> and are not in the position to integrate the distribution. For the few >> users of these programs, it is way easier for them that I give an >> Appimage or a Flatpak. > > Those last data points are a bit concerning. It'd be interesting what a > project like Debian could do to mitigate that. Concerning my own applications (they use a free licence), really, it is better not to engage any integration into Debian: it is not worth the effort nor for me, my users and the distribution. You cannot integrate an application that is use by something like ten people, including the developer. Also, some of them use Open Suze … Concerning proprietary applications, I am afraid editors are not really willing to collaborate. Clearly, they want to to everything by their self. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 01:09:31PM +0200, Yoann LE BARS wrote: > > Hello everybody out there! > > On 2021/04/09 at 09:21 am, to...@tuxteam.de wrote: > > Can you pose one concrete use case where it is unavoidable? > > I have found some bugs in Musescore that are corrected on a higher > version than the one available in stable. > > I need some functionalities available in Ardour 6, which is not > available in stable. In those cases, would a backport help? What I try to do is to download the source and try to build it on stable. Kind of "poor person's backport". Sometimes it "just works", sometimes the build dependencies are too hard to fulfill. > > For example: would a more broad availability of backports reduce > > the need for snaps, flats or how they may be called? > > If those two where available in backports, I definitively would use > these versions. I see. > Now, I need Discord and the only version which works after an update is > the one available as a snap. > > I have also been asked to use Microsoft Teams. Well, this one never > really works, either as a deb, a snap or a flatpak… > > Concerning the few proprietary softwares I use, I think I rather use > something like snap or flatpak—I have no preferences, save the fact I > rather have the possibility to set up y own server. > > Now, I have develop a few small applications who do not have much users > and are not in the position to integrate the distribution. For the few > users of these programs, it is way easier for them that I give an > Appimage or a Flatpak. Those last data points are a bit concerning. It'd be interesting what a project like Debian could do to mitigate that. Thanks for the data points! Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
Hello everybody out there! On 2021/04/09 at 09:21 am, to...@tuxteam.de wrote: > Can you pose one concrete use case where it is unavoidable? I have found some bugs in Musescore that are corrected on a higher version than the one available in stable. I need some functionalities available in Ardour 6, which is not available in stable. > For example: would a more broad availability of backports reduce > the need for snaps, flats or how they may be called? If those two where available in backports, I definitively would use these versions. Now, I need Discord and the only version which works after an update is the one available as a snap. I have also been asked to use Microsoft Teams. Well, this one never really works, either as a deb, a snap or a flatpak… Concerning the few proprietary softwares I use, I think I rather use something like snap or flatpak—I have no preferences, save the fact I rather have the possibility to set up y own server. Now, I have develop a few small applications who do not have much users and are not in the position to integrate the distribution. For the few users of these programs, it is way easier for them that I give an Appimage or a Flatpak. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 06:34:32AM -0300, riveravaldez wrote: > On 4/9/21, to...@tuxteam.de wrote: > > On Fri, Apr 09, 2021 at 04:15:07AM -0300, riveravaldez wrote: > > > > [...] > > > >> Trying to decide which is less-worse in a scenario of unavoidable > >> use of some of these. > > > > Is it really unavoidable? Or just a tad less convenient? > > Well, that's a pretty subjective issue, to be honest... ;) Of course. > > > Can you pose one concrete use case where it is unavoidable? > > Not sure if *unavoidable* but I didn't found a better solution at the > time: > A client for which laptop I'd installed Debian was in job-need of > using Skype and Zoom. Thanks for the example. > Her employers wouldn't use anything > else, so, I was looking for the better/safer way to install such damn > closed-source pieces of soft (in particular I hate Zoom, but that's > another subjective issue...) in a for anything else fully libre/secure > perfectly working Debian system. [...] Makes sense. Of course, some VM deployment could be even a tad more secure, but if you look deep down, all security is moot when you give the app direct access to, say, the GPU. And even assuming a video app could work satisfactorily with a virtualised GPU (I never tried!), I don't think current implementations are remotely secure. But I'm no expert in there. > While typing this I've checked and found that both Zoom and Skype > seem to offer through-browser video-call right now (Skype only for > Chrome, and I'm not sure if it works for Chromium). So, right now > this case only would be relevant for Skype let's say. (Anyway, I've > found that specific-application performance is usually superior that > through-browser performance when using video-calls, specially > notorious in old boxes.) Yes, Zoom has a web client, I helped a friend of mine through her steps with that. What I noticed was that it has less features than the native client: this was at times confusing, because her peer told her to push this-and-that button on the UI, which weren't in the web version. I think this is intentional on Zoom's part. They're in the "embrace" phase: suck in people even if they are reluctant to commit to the whole gorilla (aka the "native app"). Whenever they think there's enough fish securely in their net, they'll start the "squeeze" phase. Capitalists are like that. > > This may sound as an attempt to troll. > > Not coming from you, obviously. ^_^ Thanks ♥ But I'm human, too, and I do horrible things from time to time. > As any gentle and very intelligent person would do. Naturally. This is nearly too kind of you. Thanks, again. > > For example: would a more broad availability of backports reduce > > the need for snaps, flats or how they may be called? > > > > Such kind of questions. > > Well, that's an excellent point, and I think that, in general, the answer > will be 'yes', at least thinking in the use of newer packages in Stable. > But I'm a Testing user, so, not sure if this assumption has any value. > > In the other hand, for proprietary software -when unavoidable- what > would be better/simpler way to have it under control (if such thing is > somehow possible)? Up to now, I've avoided the problem. I think I'd try to go with a VM, or, if possible, with a small and nearly-disposable thingy, like a Raspberry Pi. A setup I'd like to see is a Raspi or similar, with a minimal boot "drive" (SD card) having its image on my "main" computer (the Pi 4 can even boot off the net natively), via NBD or some network file system, where I can pick and choose what to boot. A kind of externalised VM, if you like. Ah, projects :) > Thanks a lot for your answers and help. Regards! Thank you, cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On 4/9/21, to...@tuxteam.de wrote: > On Fri, Apr 09, 2021 at 04:15:07AM -0300, riveravaldez wrote: > > [...] > >> Trying to decide which is less-worse in a scenario of unavoidable >> use of some of these. > > Is it really unavoidable? Or just a tad less convenient? Well, that's a pretty subjective issue, to be honest... ;) > Can you pose one concrete use case where it is unavoidable? Not sure if *unavoidable* but I didn't found a better solution at the time: A client for which laptop I'd installed Debian was in job-need of using Skype and Zoom. Her employers wouldn't use anything else, so, I was looking for the better/safer way to install such damn closed-source pieces of soft (in particular I hate Zoom, but that's another subjective issue...) in a for anything else fully libre/secure perfectly working Debian system. I have no idea what the official .deb packages from Skype/Zoom do, so, to minimize exposition and control-lost looked for an easy way to 'enclose' what those programs could do, and opted finally for Flatpak just to avoid any Canonical late-inconvenience... While typing this I've checked and found that both Zoom and Skype seem to offer through-browser video-call right now (Skype only for Chrome, and I'm not sure if it works for Chromium). So, right now this case only would be relevant for Skype let's say. (Anyway, I've found that specific-application performance is usually superior that through-browser performance when using video-calls, specially notorious in old boxes.) > This may sound as an attempt to troll. Not coming from you, obviously. ^_^ > This is (by far) not my intention. I'd rather like to try to analyse > the trade-offs based on that use case. As any gentle and very intelligent person would do. Naturally. > For example: would a more broad availability of backports reduce > the need for snaps, flats or how they may be called? > > Such kind of questions. Well, that's an excellent point, and I think that, in general, the answer will be 'yes', at least thinking in the use of newer packages in Stable. But I'm a Testing user, so, not sure if this assumption has any value. In the other hand, for proprietary software -when unavoidable- what would be better/simpler way to have it under control (if such thing is somehow possible)? > Cheers > - t Thanks a lot for your answers and help. Regards!
Re: ubuntu/snap future
On Fri, Apr 09, 2021 at 04:15:07AM -0300, riveravaldez wrote: [...] > Trying to decide which is less-worse in a scenario of unavoidable > use of some of these. Is it really unavoidable? Or just a tad less convenient? Can you pose one concrete use case where it is unavoidable? This may sound as an attempt to troll. This is (by far) not my intention. I'd rather like to try to analyse the trade-offs based on that use case. For example: would a more broad availability of backports reduce the need for snaps, flats or how they may be called? Such kind of questions. Cheers - t signature.asc Description: Digital signature
Re: ubuntu/snap future
On 4/7/21, Dan Ritter wrote: > riveravaldez wrote: >> On Tuesday, April 6, 2021, Brian wrote: >> > On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote: >> > >> > I had occasion to install Zoom a few weeks ago;'snap install >> > zoom-client'. >> > Everything went smoothly and I quite like having this proprietary >> > package >> > strictly confined. >> >> Hi, I was under the impression that (besides being fully open) Flatpak >> had >> better confinement method that Canonical's Snap, anybody knows if this is >> correct? > > > "Two years ago I wrote about then heavily-pushed Flatpak, > self-proclaimed "Future of Apps on Linux". The article > criticized the following three major flows in Flatpak: > > Most of the apps have full access to the host system but > users are misled to believe the apps are sandboxed > The flatpak runtimes and apps do not get security updates > Flatpak breaks many aspects of desktop integration" > > -- https://flatkill.org/2020/ > > (the article then says that they fixed some desktop integration > issues) Thanks a lot for the link and info, Dan, very informative. I'm still with the doubt. Even considering all this: which has better (or less-worse) confinement, Flatpak or Snap (or AppImage)? Trying to decide which is less-worse in a scenario of unavoidable use of some of these. Thanks again!
Re: ubuntu/snap future
riveravaldez wrote: > On Tuesday, April 6, 2021, Brian wrote: > > On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote: > > > > I had occasion to install Zoom a few weeks ago;'snap install zoom-client'. > > Everything went smoothly and I quite like having this proprietary package > > strictly confined. > > Hi, I was under the impression that (besides being fully open) Flatpack had > better confinement method that Canonical's Snap, anybody knows if this is > correct? "Two years ago I wrote about then heavily-pushed Flatpak, self-proclaimed "Future of Apps on Linux". The article criticized the following three major flows in Flatpak: Most of the apps have full access to the host system but users are misled to believe the apps are sandboxed The flatpak runtimes and apps do not get security updates Flatpak breaks many aspects of desktop integration" -- https://flatkill.org/2020/ (the article then says that they fixed some desktop integration issues) -dsr-
ubuntu/snap future
On Tuesday, April 6, 2021, Brian wrote: > On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote: > > I had occasion to install Zoom a few weeks ago;'snap install zoom-client'. > Everything went smoothly and I quite like having this proprietary package > strictly confined. Hi, I was under the impression that (besides being fully open) Flatpack had better confinement method that Canonical's Snap, anybody knows if this is correct? Kind regards.
Re: ubuntu/snap future
On Tue, 6 Apr 2021 12:49:14 +0100 Brian wrote: > On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote: > > > > > Hello everybody out there! > > > > On 2021/04/06 at 01:53 am, Paul Johnson wrote: > > > There's nothing user-unfriendly about .debs. They just don't want to > > > maintain their software and are looking for a "fire and forget" > > > solution. I can't see this as anything but a bad thing, something the > > > world can live without. > > > > Well, I do not like the way Ubuntu uses snaps, but there are some good > > reasons to use something like snaps or flatpacks. > > > > Even with a less careful procedure to integrate and update packages > > than the one of Debian (which I like), create a new package and update > > one take some time. There are several examples when a user needs a bug > > fix or some functionality that packages in distributions do not provide. > > In such a case, without snaps or flatpacks, the user has to compile the > > program, which need some technical skills and can be sometimes really > > tricky. Appimages are less interesting, as you have to update them manually. > > > > Use parsimoniously, packages like snaps or flatpacks are something very > > useful, which improve user experience even for power users. The problem > > with Ubuntu is it uses way too much snaps and I do not think it is a > > matter of laziness. > > I had occasion to install Zoom a few weeks ago;'snap install zoom-client'. > Everything went smoothly and I quite like having this proprietary package > strictly confined. 'apt install zoom_amd64.deb' goes smoothly as well. Confinement is certainly a good thing - I'll have to look into whether the snap route is preferable to the firejail solution that I currently use. Celejar
Re: ubuntu/snap future
On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote: > > Hello everybody out there! > > On 2021/04/06 at 01:53 am, Paul Johnson wrote: > > There's nothing user-unfriendly about .debs. They just don't want to > > maintain their software and are looking for a "fire and forget" > > solution. I can't see this as anything but a bad thing, something the > > world can live without. > > Well, I do not like the way Ubuntu uses snaps, but there are some good > reasons to use something like snaps or flatpacks. > > Even with a less careful procedure to integrate and update packages > than the one of Debian (which I like), create a new package and update > one take some time. There are several examples when a user needs a bug > fix or some functionality that packages in distributions do not provide. > In such a case, without snaps or flatpacks, the user has to compile the > program, which need some technical skills and can be sometimes really > tricky. Appimages are less interesting, as you have to update them manually. > > Use parsimoniously, packages like snaps or flatpacks are something very > useful, which improve user experience even for power users. The problem > with Ubuntu is it uses way too much snaps and I do not think it is a > matter of laziness. I had occasion to install Zoom a few weeks ago;'snap install zoom-client'. Everything went smoothly and I quite like having this proprietary package strictly confined. -- Brian.
Re: ubuntu/snap future
Hello everybody out there! On 2021/04/06 at 01:53 am, Paul Johnson wrote: > There's nothing user-unfriendly about .debs. They just don't want to > maintain their software and are looking for a "fire and forget" > solution. I can't see this as anything but a bad thing, something the > world can live without. Well, I do not like the way Ubuntu uses snaps, but there are some good reasons to use something like snaps or flatpacks. Even with a less careful procedure to integrate and update packages than the one of Debian (which I like), create a new package and update one take some time. There are several examples when a user needs a bug fix or some functionality that packages in distributions do not provide. In such a case, without snaps or flatpacks, the user has to compile the program, which need some technical skills and can be sometimes really tricky. Appimages are less interesting, as you have to update them manually. Use parsimoniously, packages like snaps or flatpacks are something very useful, which improve user experience even for power users. The problem with Ubuntu is it uses way too much snaps and I do not think it is a matter of laziness. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: ubuntu/snap future
On 4/5/21 4:53 PM, Paul Johnson wrote: On Sat, Apr 3, 2021 at 11:39 AM George Shuklin mailto:george.shuk...@gmail.com>> wrote: It looks to me like they desperately want to jump away from debs into 'vendor friendly packaging' There's nothing user-unfriendly about .debs. They just don't want to maintain their software and are looking for a "fire and forget" solution. I can't see this as anything but a bad thing, something the world can live without. +1
Re: ubuntu/snap future
On Sat, Apr 3, 2021 at 11:39 AM George Shuklin wrote: > It looks to me like they desperately want to jump away from debs into > 'vendor friendly packaging' > There's nothing user-unfriendly about .debs. They just don't want to maintain their software and are looking for a "fire and forget" solution. I can't see this as anything but a bad thing, something the world can live without.
Re: ubuntu/snap future
On Sat, Apr 03, 2021 at 07:38:53PM +0300, George Shuklin wrote: > I'd like to stir some debates. > > Ubuntu (which is 'enterprise friendly Debian with ambivalent feeling about > free software') started to push snaps onto servers for real. It looks to me > like they desperately want to jump away from debs into 'vendor friendly > packaging'. Is it so? > Yes, I think it might be. The problem with some packages is that they're impossible to keep up to date in the traditional way, seemingly, and Ubuntu want to use snaps to make things easier to manage / quicker to update. Lots of different ways to make a distribution: Ubuntu / MXlinux and all sorts of others, each with their own ideas, Debian with theirs - lots of shades of opinion dividing the pool of Linux users and Linux development talent. Ubuntu is a commercial distribution with its own viewpoint - though when I first came across it (before it first released in 2005 - when it was still a quiet discussion) it was described to me by one of the very first participants "If we could have got away with calling it Debian for desktops, we would have done" - so stuff has quietly changed in tha last 16 years as has the overall profile of the distribution. All best, Andy C.
ubuntu/snap future
I'd like to stir some debates. Ubuntu (which is 'enterprise friendly Debian with ambivalent feeling about free software') started to push snaps onto servers for real. It looks to me like they desperately want to jump away from debs into 'vendor friendly packaging'. Is it so?
