[HN Gopher] Linux desktop powers consider uniting for an app store
___________________________________________________________________
Linux desktop powers consider uniting for an app store
Author : CrankyBear
Score : 28 points
Date : 2023-03-02 17:34 UTC (5 hours ago)
(HTM) web link (www.zdnet.com)
(TXT) w3m dump (www.zdnet.com)
| Mindwipe wrote:
| Seems a weird decision given even Apple do not seem able to get a
| desktop app store to work.
| pxc wrote:
| On macOS, it's a lot easier to ship highly compatible
| applications on your own website, that anyone can just download
| and then run on their Mac. So Apple's App Store is competing
| with that paradigm as well.
|
| On Linux, the runtimes apps need vary too much from distro to
| distro, or even OS install to OS install, for that to be
| equally viable. So Flatpak here isn't just an alternative
| distribution model in a commercial sense, but a technical one--
| it's genuinely more portable than most previous options.
|
| A Flatpak-based store also need not be concerned with taking
| over the world-- Flatpak itself supports configurable
| repositories, so indie developers are totally free to publish
| their own apps via Flatpak on their own, or perhaps even on
| their choice of a range of _competing_ Flatpak-based app
| stores, should such a field arise.
|
| The point in the Linux case is not to corral users into using a
| single source for all their apps, but rather to provide a
| broadly compatible option, and also to make commercial
| development of proprietary software for Linux desktops more
| viable by allowing vendors to target more users with less
| effort.
|
| If a universal Flatpak store for Linux desktops comes to be, it
| would probably still be fair to call it a success even if most
| users prefer to get most of our software elsewhere.
| mistrial9 wrote:
| Canonical is fishing for an IPO ; stores make money and deliver
| control. signed "Ubuntu is a word in the Debian language
| meaning we dont care about whatever you are trying to do this
| week"
| sho_hn wrote:
| The situation on Linux is a little bit different in that each
| individual distro (say, Ubuntu, Fedora, etc.) have always
| worked with a "desktop app store" (package repository, which
| you interact with e.g. with GUI store frontends or CLI
| commands) as the one way to get apps from.
|
| What's different here is having one that's portable across the
| distros, enabled by the Flatpak package format.
| smackeyacky wrote:
| Might simply be the death throes of desktop applications
| themselves. What else does anybody (other than developers)
| install any more other than Chrome?
| AnIdiotOnTheNet wrote:
| Games, audio mixing software, media editing software, control
| interfaces for hobbiest equipment, piracy tools, video
| capture software, and literally anything that needs to work
| when the internet is down.
| lbwtaylor wrote:
| Why would I want google controlling how I interact with my
| software?
|
| Maybe it doesn't seem like it, but it's an honest question. I
| don't find the browser first approach attractive at all.
| brimstedt wrote:
| > 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 wrote:
| 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.
| hulitu wrote:
| > 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.
| dmonitor wrote:
| 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.
| pxc wrote:
| 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.
| pxc wrote:
| > 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.
| pengaru wrote:
| > 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 wrote:
| And flatpak is preventing this how ?
| pxc wrote:
| 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 wrote:
| 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/flatp
| a...
|
| 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.
| oynqr wrote:
| Most of the crappy proprietary apps on Flathub still have
| very broad permissions that make sandbox escape trivial.
| smackeyacky wrote:
| Getting some serious Unix Wars[0] vibes from this. I'm not a huge
| fan of flatpak but the anti-Snap/Ubuntu movement appears to be
| gathering pace and I think that is a good thing.
|
| [0]https://en.wikipedia.org/wiki/Unix_wars
| ClapperHeid wrote:
| They do realise this is Linux, don't they?
|
| This week; a Unified Linux App store.
|
| Next week; 25 rival forked Unified Linux App stores.
| [deleted]
| pxc wrote:
| Not a problem if they all use the same package format! Flatpak
| can potentially support competition without imposing
| fragmentation here.
| tlhunter wrote:
| I would argue that Linux was the first OS to implement an app
| store and that it predates the other major operating systems by
| over a decade. It's just that the Linux apps were free.
| tredre3 wrote:
| And iOS was the first OS to implement a good app store,
| allowing for easy discovery of new software, auto updating, and
| a proper review process.
| tstrimple wrote:
| Here we go again.
|
| https://xkcd.com/927/
___________________________________________________________________
(page generated 2023-03-02 23:02 UTC)