5 ms·

> This idea of replacing traditional but not very friendly ways of delivering Linux desktop apps, such as DEB What? :-) Apt is by far the easiest way o instal

> This idea of replacing traditional but not very friendly ways of delivering Linux desktop apps, such as DEB What? :-) Apt is by far the easiest way o install and keep software updated. Compared to app-store, homebrew, and toy like solutions for Windows.

dmonitor 4y ago
There’s often inconsistency with how .deb files are treated by the desktop environment. I have some systems where clicking them just opens like an archive. They should just launch an installer, but the fact that the installer can be reassigned makes the behavior inconsistent. I just use dpkg -i but that’s not exactly something you can find out without dedicated research.
- pxc 4y ago
  > I just use dpkg -i but that’s not exactly something you can find out without dedicated research. Downloading individual DEB files is not a great way to go, but if you must, you're better off using something like gdebi than dpkg to install them. If you use gdebi, apt will still try to resolve dependencies when installing the package for you. With dpkg, you have to do all of that manually, so dpkg is only useful for installing the worst kinds of DEB files (ones that ignore the real packaging system and bundle all of their dependencies). If you only want the command line utility instead of the GUI DEB file handler, grab gdebi-core. I also wanna return to this, briefly: > not exactly something you can find out without dedicated research. It bugs the hell out of me that some distros (like the Debian that comes on WSL, for example) does not include absolutely basic Unix essentials like the man command and friends. Because this shouldn't be something that takes extended research. The old Unix tools for documenting the system internally can handle this perfectly! If you run apropos deb you will get a nice short list of things used for working with DEB files, including dpkg. So even if it's not the best tool it should be at least enough to find something for working with those files, without having to Google around for a long time or install any new software.
- hulitu 4y ago
  > They should just launch an installer The organization of Windows malware creators would like to thank you for your idea. /s. DEB is an archive format.
  - pxc 4y ago
    A bit more charitably: sometimes you might want to open up a DEB file and poke around in it in a system which is not Debian-based. AUR package authors do this on Arch, for example, as do the maintainers of the Nixpkgs entries for some proprietary software which is only distributed upstream as DEB files. So the Linux desktop ecosystem as a whole doesn't necessarily know ahead of time which way you want to use a DEB file. Of course, an archive manager which can detect whether you're on a Debian-based system or not, and appropriately choose whether or not to show you an 'install' button after opening the archive, is very much possible and would be quite nice.
  - dmonitor 4y ago
    That's kind of the point on .deb not being the best format for distributing packages. Having it be treated by the OS as both an archive format and an application is unnecessarily confusing. MacOS applications are secretly just folders, but most users don't even know that. It might be obvious to someone like you or I, but most people don't want to do more than just click the app and type their password to launch/install it. I have more than a handful of gripes about Windows, but I can at least say that clicking an .exe has a very clearly defined and understandable behavior.
- VTimofeenko 4y ago
  That's probably stemming from different configurations of MIME database on different distros.
pengaru 4y ago
> Apt is by far the easiest way o install and keep software updated. The main issue with distro-centric package formats like deb/rpm is they come from a pre-containers/pre-sandboxing era. Their most ergonomic usage is installing distro-blessed software system-wide, where you trust the distributor to have ensured it's not some malware or other nefarious junk. When it comes to installing software directly provided by third-parties, open or closed, there's a strong need for sandboxing integration at the package level. And once you're sandboxing instances of software, you start needing things like portals to access your files and devices outside the sandbox. If a third-party has provided you with a .deb or .rpm, what's to prevent that package's privileged hooks from doing harm when you install it via dpkg/apt/rpm as root? Let alone the installed software potentially being malicious, the packaging itself can do serious damage. This is a big part of why stuff like flatpak exists today.
- hulitu 4y ago
  And flatpak is preventing this how ?
  - pxc 4y ago
    Flatpak doesn't prevent anything, but it does provide a way for users to avoid those bad things. The format is likely to give Linux users a slightly more BSD-ish separation between core system software and third-party applications, going forward. So 'avoid mucking about with third-party DEB and RPM files' is likely to become a rule of thumb for end users.
  - pengaru 4y ago
    AIUI Flatpak attempts to sandbox everything as much as possible. I'm no flatpak dev, nor am I intimately familiar with its implementation. But with little effort glancing at the code one can confirm there's clearly effort to even sandbox triggers: https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpak-dir.c#L7124 https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpa... Note that flatpak builds upon bubblewrap, which descends from linux-user-chroot, a project specifically focused on preventing things like host contamination during package builds over tools like jhbuild. The devs are aware of these issues and aspire to address them. I doubt it's perfect though, and I'm sure there are insecure modes for flatpaks where everything just occurs in the host namespace. But hopefully that's made clear to the end-user before proceeding. I recall there being some brouhaha over flathub misrepresenting some apps as totally secure/sandboxed which shouldn't have been, because they were still running in the host namespace or something like that. I believe that got fixed though.
3np 4y ago
The quote is talking about the experience from the perspective of a software publisher, while you're talking from the software user perspective. Very different.

dmonitor 4y ago

There’s often inconsistency with how .deb files are treated by the desktop environment. I have some systems where clicking them just opens like an archive. They should just launch an installer, but the fact that the installer can be reassigned makes the behavior inconsistent. I just use dpkg -i but that’s not exactly something you can find out without dedicated research.

pxc 4y ago
> I just use dpkg -i but that’s not exactly something you can find out without dedicated research. Downloading individual DEB files is not a great way to go, but if you must, you're better off using something like gdebi than dpkg to install them. If you use gdebi, apt will still try to resolve dependencies when installing the package for you. With dpkg, you have to do all of that manually, so dpkg is only useful for installing the worst kinds of DEB files (ones that ignore the real packaging system and bundle all of their dependencies). If you only want the command line utility instead of the GUI DEB file handler, grab gdebi-core. I also wanna return to this, briefly: > not exactly something you can find out without dedicated research. It bugs the hell out of me that some distros (like the Debian that comes on WSL, for example) does not include absolutely basic Unix essentials like the man command and friends. Because this shouldn't be something that takes extended research. The old Unix tools for documenting the system internally can handle this perfectly! If you run apropos deb you will get a nice short list of things used for working with DEB files, including dpkg. So even if it's not the best tool it should be at least enough to find something for working with those files, without having to Google around for a long time or install any new software.
hulitu 4y ago
> They should just launch an installer The organization of Windows malware creators would like to thank you for your idea. /s. DEB is an archive format.
- pxc 4y ago
  A bit more charitably: sometimes you might want to open up a DEB file and poke around in it in a system which is not Debian-based. AUR package authors do this on Arch, for example, as do the maintainers of the Nixpkgs entries for some proprietary software which is only distributed upstream as DEB files. So the Linux desktop ecosystem as a whole doesn't necessarily know ahead of time which way you want to use a DEB file. Of course, an archive manager which can detect whether you're on a Debian-based system or not, and appropriately choose whether or not to show you an 'install' button after opening the archive, is very much possible and would be quite nice.
- dmonitor 4y ago
  That's kind of the point on .deb not being the best format for distributing packages. Having it be treated by the OS as both an archive format and an application is unnecessarily confusing. MacOS applications are secretly just folders, but most users don't even know that. It might be obvious to someone like you or I, but most people don't want to do more than just click the app and type their password to launch/install it. I have more than a handful of gripes about Windows, but I can at least say that clicking an .exe has a very clearly defined and understandable behavior.
VTimofeenko 4y ago
That's probably stemming from different configurations of MIME database on different distros.

pengaru 4y ago

> Apt is by far the easiest way o install and keep software updated. The main issue with distro-centric package formats like deb/rpm is they come from a pre-containers/pre-sandboxing era. Their most ergonomic usage is installing distro-blessed software system-wide, where you trust the distributor to have ensured it's not some malware or other nefarious junk. When it comes to installing software directly provided by third-parties, open or closed, there's a strong need for sandboxing integration at the package level. And once you're sandboxing instances of software, you start needing things like portals to access your files and devices outside the sandbox. If a third-party has provided you with a .deb or .rpm, what's to prevent that package's privileged hooks from doing harm when you install it via dpkg/apt/rpm as root? Let alone the installed software potentially being malicious, the packaging itself can do serious damage. This is a big part of why stuff like flatpak exists today.

hulitu 4y ago
And flatpak is preventing this how ?
- pxc 4y ago
  Flatpak doesn't prevent anything, but it does provide a way for users to avoid those bad things. The format is likely to give Linux users a slightly more BSD-ish separation between core system software and third-party applications, going forward. So 'avoid mucking about with third-party DEB and RPM files' is likely to become a rule of thumb for end users.
- pengaru 4y ago
  AIUI Flatpak attempts to sandbox everything as much as possible. I'm no flatpak dev, nor am I intimately familiar with its implementation. But with little effort glancing at the code one can confirm there's clearly effort to even sandbox triggers: https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpak-dir.c#L7124 https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpa... Note that flatpak builds upon bubblewrap, which descends from linux-user-chroot, a project specifically focused on preventing things like host contamination during package builds over tools like jhbuild. The devs are aware of these issues and aspire to address them. I doubt it's perfect though, and I'm sure there are insecure modes for flatpaks where everything just occurs in the host namespace. But hopefully that's made clear to the end-user before proceeding. I recall there being some brouhaha over flathub misrepresenting some apps as totally secure/sandboxed which shouldn't have been, because they were still running in the host namespace or something like that. I believe that got fixed though.

3np 4y ago

The quote is talking about the experience from the perspective of a software publisher, while you're talking from the software user perspective. Very different.