Hacker News Reader

Comment by AnIdiotOnTheNet | Hacker News Reader

> Joking aside, I know the package manager was somehow a sticking point for people when it was merged in a pretty unpolished state, but at this point I'm not sure what the complaints are.

Package management is an awful paradigm for application management. I'm not familiar with Haiku's implementation, but the only reason anyone needs a package manager is if they intend on having a complex web of dependencies and spreading an application's files all over the hierarchy. In other words, they're a UNIX system. Implementations are almost always reliant on a centrally managed appstore-like repository that developers have to deal with to distribute software in the "official" way, often don't allow multiple concurrent instance of the same application to be install (different versions, for instance), are completely inflexible in regards to where applications are installed (so portability is right out), etc.

Many of the problems I have with package managers were expressed by parts of the Haiku community when it introduced one. It appears that the developers disregarded these concerns because they like package management in Linux. Fine, they're the one's working on it, they can do what they want, but I don't have to like or praise that decision.

> And I also note the people who did the most work on the LibreOffice port say they would not even have attempted it without the package manager, so there's that.

Says a lot about the system then doesn't it? Windows has a portable LibreOffice, even Linux has an AppImage.

View on HN

>> ...are completely inflexible in regards to where applications are installed...

Why users want to install programs willy-nilly in various random places is beyond me. Having standard installation locations makes inter-operability easier. This isn't so much a thing for applications as it is for libraries, but it does come up for apps too.

With standard installations it should be possible to simply list the dependencies an application has, but then you'll still want a central repository to get them from to make it easy and keep compatible versions around.

It's not great, but it works and I have yet to see a good alternative.

> Why users want to install programs willy-nilly in various random places is beyond me.

Maybe I want some applications on my SSD and others on slower media? Maybe I want to have it on a thumbdrive I can carry around with me and run on whatever computer is nearby (and obviously running the same OS)? Maybe I just want to organize my file tree in a way that makes more sense to me? Just because your imagination is limited doesn't mean there aren't reasons people might want to do other things.

AnIdiotOnTheNet, I couldn't agree more. Which is why I've started the AppImage project roughly a decade ago. Would you like to join, even if only as an evangelist? Please get in touch with us via GitHub. It's important to spread the word.

I'm a fan of AppImage, a lone island of sanity in the ocean of bad ideas on the Linux Desktop. You were involved with Klik before that right? So it has been more than a decade. And you're not the only one, there's also been efforts like GoboLinux and RoxOS, both of which have been more or less completely ignored by the community, which is why I think the Linux Desktop is unsalvageable.

The Linux Desktop community is simply not culturally ever going to accept a desktop that actually works like a desktop. I can't put my finger on why. Is it dogma? Do they just prefer needless complexity? Do they simply lack the experience to know how awful the system is? I don't know.

Point is, I think the only real way forward is to do what Google did with Android: take the kernel, which is actually pretty reasonable, and put a completely new userland on top of it. Forking some currently existing software may be acceptable in some cases, but the new system should separate itself as much as it possibly can from the currently existing Linux Desktop community. It won't be a Linux distribution, and I think it'd be best to not even mention Linux.

I have done some preliminary work regarding the design of such a system, how its applications would work, completely re-imagining how the filesystem tree works and even what it is for, that sort of thing. But the more discussion I have about ideas in that vein the more I realize that nobody really wants that, they all just want their over-engineered web-kiosk with 1970s-era tooling and sensibilities.

Yes, I started klik about a decade ago, over time evolved and simplified the concept and renamed it to AppImage. Thanks for calling it a "lone island of sanity in the ocean of bad ideas on the Linux Desktop" ;-)

After having heard that "this is not how Linux works", I was about to give up when Linus Torvalds himself gave me the impression that maybe the idea wasn't entirely insane altogether.

As for what should be done, I don't think that doing the 1.001st distribution will make any significant difference. Building a system on top of the Linux kernel that is intended to be a platform might.

But then, building something entirely from scratch would require resources I clearly don't have. So how about this:

1. Take the most popular distribution as the basis (that would be Debian/Ubuntu probably) 2. Determine a set of "Core OS" functionality that is comparable to what Windows and macOS do out of the box, and decide that this will be shipped by the Core OS 3. Use distribution packages to install that Core OS into a filesystem image 4. Uninstall the package manager (because it is a tool for the maintainers of the Core OS, not meant for users) 5. Guarantee that only new APIs/ABIs will be added to the system, existing ones can be considered stable and will deprecated only after 5 years (or so) prior warning 6. Release the Core OS once a year (Core OS 2018, 2019, ...) 7. Apps come as bundles (e.g., Rox-style AppDirs or AppImages) 8. Maybe call the loader (ld-linux.so) differently to intentionally only run applications specifically crafted for this system (debatable) 9. Guarantee 5 years of support for each yearly release 10. Developers are advised to always develop against the oldest still-supported Core OS (e.g., the 5 year old one); i.e., if we introduce a new API today then developers can assume it is "there" for everyone 5 years from now; or else they must privately bundle it (similar to how Android works) 11. Address the Desktop Linux Platform Issues https://gitlab.com/probono/platformissues in this system 12. Address the Desktop Linux Usability Challenges https://medium.com/@probonopd/make-it-simple-linux-desktop-u... in this system (possibly modify a desktop environment like XFCE to be more like the Mac/NextStep in philosophy - without copying it verbatim)

Who wants to do it?

Most of that is similar to what I had in mind. My thought was to go a step further than what could be achieved by simply choosing a base set of packages from an existing distro:

Consider what we currently consider the "filesystem" tree to instead be a "namespace" tree. /dev (device namespace), /proc (process namespace), and /sys (kernel namespace) remain where they are and two new namespaces are introduced: /file (filesystem namespaces), and /app (application namespace). Under /file, volumes are mounted to directories named after them, e.g. '/file/Primary', '/file/Vacation Photos', '/file/Windows', etc. The namespace hierarchy is a tmpfs, real disk space only exists under volumes mounted in /file. /app is any application's own AppDir.

See, each application has it's own namespace like Plan9. When an AppDir is launched, it immediately has its view of the filesystem unshared and a new namespace hierarchy is built for it under /app according to a combination of its own specifications and those imposed by the user. For instance, it may not require /proc, /dev, or /sys, and the user may have restricted it to read-only access to /file, so the new hierarchy under /app is setup accordingly. /app/app is bind-mounted to the AppDir itself, and then the actual application is launched with a chroot into /app (the new namespace we set up for it). Now it can always refer to its own AppDir relative files using /app/* (conveniently the same number of characters as /usr/, for reasons I know you've thought of). Obviously, other Linux namespaces (ipc, network, even user I suppose) can similarly be configured. The isolation portion of this plan is not entirely unlike how firejail can be used with AppImage, but it's the way the system works by default.

This allows a lot of flexibility for compatibility. An AppDir could specify that it uses the (legacy) GNU library set, so it gets a /lib in its namespace that is a bind mount to the system provided GNU libraries (/file/Primary/System/Libraries/GNU, for instance). In fact, you could run an entire linux distribution inside an AppDir this way, and you could setup its net namespace such that it displays in an Xephyr or XWayland window (or some other X server on whatever display system ends up being used). And hey, why not do the same thing for Windows with WINE? Now you have Windows and Linux compatibility layers and they're isolated as much or little as you want.

The AppDirs could also contain multiple binaries. For instance, they could be like "fat" binaries were for MacOS and NeXT where the application came with a binary for each architecture and the appropriate one was launched. Or imagine an office suite, where double-clicking the AppDir might launch the "pick the tool" window, or you could right-click and get a context menu letting you choose which tool you want to run. I was a fan of the old-school Windows Start Menu that was just a menuized view of a folder structure, so lets say that was part of your GUI, then AppDirs with the context menu show those menu items as subitems of the AppDir.

Anyways, that's a sample of the lines of thinking I have on the subject. Like you said, it's a lot of resources for one person to muster. I've gone as far as writing the code to configure application namespaces and launch them, which was shockingly easy, and I started to lay out how the init system would have to work (since it'd be responsible for automounting volumes in /file, setting up networks, feeding firmware blobs to the kernel (ugh), and launching applications at a minimum). But I find it hard to feel motivated because whenever I talk about these ideas I get into long arguments with people who think things are better as they are. I think I'd totally be enthusiastic about working on this system, or something close enough to it, if only I could find the community that actually wants something like that.

App availability makes or breaks every platform. App developers only release stuff for platforms with a large user base, and "Desktop Linux" as a whole is at a mere 2-3 percent at this point. So I think the new system would need to ensure that whatever energy an app developer invests into developing for this platform could be re-used to have the same app run on regular Linux distributions. This is something that would need to be solved...

Also, a large brand name behind it (not necessarily a commercial company and in no case a Linux distribution company) would probably help adoption.

In theory most AppDirs could be run on a normal linux distro with a wrapper script and a package of the base system libraries if certain choices were made (like using wayland instead of a new display server). I'm not opposed to practical compromises, but part of my design goal was to get rid of legacy stuff that doesn't make sense anymore (like the way UNIX handles the file tree) and build a better (and simpler) mousetrap where it was reasonable.

I disagree that it needs to have its applications be runnable on Linux Desktop to work. I think that if you build a system people actually want to use then the applications will come. After all, Linux is a tiny percent of the desktop using population and it still gets targeted just because people are getting kind of sick of the behavior of the companies behind the proprietary OSs. Imagine if people actually wanted to use the Linux Desktop instead of just put up with it.

I think compatibility in the opposite direction is much more important. Like how MS included an XP VM in 7, or Apple included a MacOS Classic VM in OSX, the new system could offer ways of running "legacy" Linux applications to make the switch easier (also Windows via WINE, though with a much lower success rate, and possibly Android via something like Anbox).

> but the only reason anyone needs a package manager is if they intend on having a complex web of dependencies and spreading an application's files all over the hierarchy.

Well, guess what? LibreOffice has a complex web of dependencies, and getting all those couple dozen dependencies patched, built, and then properly installed so the build system & compiler can find and use them is not trivial. If you've got a Haiku install, try installing LibreOffice; you'll see it brings about 20-30 packages with it!

> In other words, they're a UNIX system.

Haiku is a POSIX system, yes. Why is that an issue?

> Implementations are almost always reliant on a centrally managed appstore-like repository that developers have to deal with to distribute software in the "official" way

Well, Haiku packages can be installed without a repository. If all your package depends on are is base system itself, you can still ship it to users without a repository. Or you can run your own repository; it's quite easy to do, and multiple third-parties already are. Or you can submit recipes to HaikuPorts, which feeds the base "ports" repository, which multiple third-parties have also already done, in addition to our own proactive porting effort.

> often don't allow multiple concurrent instance of the same application to be install (different versions, for instance)

On Haiku, you can install packages in either `system` or in your local `home` directory, so you could have one version of the package in each of those. Or you could extract the package and run the app outside the package (if the app supports it; not all do.)

> are completely inflexible in regards to where applications are installed (so portability is right out), etc.

Indeed this is a common complaint, but as I noted above on Haiku you can install packages in `home`. Not sure what that has to do with portability, though?

> It appears that the developers disregarded these concerns because they like package management in Linux

We don't particularly like a number of aspects of package management in Linux, which is why we went with a very different solution than Linux did: packages are essentially filesystem images which are "mounted" into a pseudo-unionfs. That means installation/uninstallation time is virtually nothing, it's trivial to install packages in `home` as well as `system`, you can boot into old states, etc.

> Says a lot about the system then doesn't it? Windows has a portable LibreOffice, even Linux has an AppImage.

Windows has LibreOffice because everyone uses Windows, and so people are willing to put the time in to deal with having to patch and compile all LibreOffice's dependencies specially for Windows because there is no real "ports" tree for Windows.

AppImages are just 'packages' with all the dependencies in the package. You could make those for Haiku, too, if you wanted. The system package manager isn't stopping you. You could also install software the "old way" of unzipping archives and then copying them somewhere, we also aren't stopping that. This is a new paradigm that hopefully will replace the old ones, but it doesn't necessarily, not if people continue to use the old ways.

> Many of the problems I have with package managers were expressed by parts of the Haiku community when it introduced one.

And a good number of those users have come around on that as we've ironed out issues or made changes to accommodate their concerns.

> Well, guess what? LibreOffice has a complex web of dependencies, and getting all those couple dozen dependencies patched, built, and then properly installed so the build system & compiler can find and use them is not trivial. If you've got a Haiku install, try installing LibreOffice; you'll see it brings about 20-30 packages with it!

Kind of my point really. Why does how LibreOffice is compiled matter to the end user who is installing LibreOffice?

Most of what you're saying is agreeing that all the reasons I personally don't like package managers are indeed true, we just disagree about whether or not those are good things. I don't think they are.

> AppImages are just 'packages' with all the dependencies in the package.

If that's true, then what isn't a package in your world? A single statically compiled executable could be called a package by this logic.

> You could make those for Haiku, too, if you wanted. The system package manager isn't stopping you. You could also install software the "old way" of unzipping archives and then copying them somewhere, we also aren't stopping that. This is a new paradigm that hopefully will replace the old ones, but it doesn't necessarily, not if people continue to use the old ways.

And that's the problem: The system is pushing the new paradigm. Package management will be the rule and simple application directories will be the outlier. That's not a convincing argument for me to use the system.

I get that you disagree with my conception of how things should be done. That's fine, do whatever you want. But for me, personally, I don't see any reason to subject myself to an application management paradigm that I disagree with to use Haiku. If I were going to do that, I'd just use Linux because it has much better hardware and software support.

> Kind of my point really. Why does how LibreOffice is compiled matter to the end user who is installing LibreOffice?

It doesn't, and so indeed most users like the package manager because it makes installing software easier.

> Most of what you're saying is agreeing that all the reasons I personally don't like package managers are indeed true, we just disagree about whether or not those are good things. I don't think they are.

I suppose that's one way of looking at it, yes. But you must be a rather alienated individual: you can't use virtually any Linux distribution, nor most of the *BSDs, and macOS has an App Store so that's out the window too, ...

> And that's the problem: The system is pushing the new paradigm. Package management will be the rule and simple application directories will be the outlier. That's not a convincing argument for me to use the system.

No, I mean you could make "appimage" style HPKGs, that installed with no dependencies and no repositories. Would anyone use those when they can already do one-click-installs of any application they want? I dunno, probably not.

I'm glad you think "simple" application directories are really that "simple." What happens when one library, used by 6 of your installed applications, has a security flaw? You need to update all 6. Or if you have a system package manager, you need to run one command and it will update the 1 package for you.

> If I were going to do that, I'd just use Linux because it has much better hardware and software support.

Well, the "copy directory to install" was never really the reason Haiku existed, and if you think in losing that we've lost some huge part of our identity ... I really think you're mistaken.

> I suppose that's one way of looking at it, yes. But you must be a rather alienated individual: you can't use virtually any Linux distribution, nor most of the *BSDs, and macOS has an App Store so that's out the window too,

Yeah, so alienated over here with the 90% of desktop users not using one of those. Don't see why you're taking this so personally that you feel the need to resort to some kind of personal attack.

> What happens when one library, used by 6 of your installed applications, has a security flaw? You need to update all 6.

Yep. It's a tradeoff. I prefer the simplicity, flexibility, and non-conflicting nature of appdirs.

> Well, the "copy directory to install" was never really the reason Haiku existed, and if you think in losing that we've lost some huge part of our identity ... I really think you're mistaken.

As I understand it, Haiku wants to be a desktop OS. That's its identity. I think that package management has no place in a desktop OS, so when Haiku added one I lost interest. That's it really.

> Yeah, so alienated over here with the 90% of desktop users not using one of those. Don't see why you're taking this so personally that you feel the need to resort to some kind of personal attack.

I'm sorry, I didn't intend it as an attack, just a remark that you seem to be asking for something that very few in the open source world are providing.

Yes, 90% of desktop users use Windows. But Linux is not Windows, and neither is Haiku, and so I'm not sure why you're upset that we've decided to go a route more Linuxy than Windowsy here.

And I also note that Windows has an app store now, and more and more apps are showing up on it. So there's that.

> I prefer the simplicity, flexibility, and non-conflicting nature of appdirs.

And as an OS developer and package maintainer, I prefer the tradeoff the other way. You are of course more than free to create AppImage-style HPKGs on your own. :)

> I think that package management has no place in a desktop OS, so when Haiku added one I lost interest.

Well, it seems most of the open source world disagrees with you very much, then.

> I'm sorry, I didn't intend it as an attack, just a remark that you seem to be asking for something that very few in the open source world are providing.

Yes, this is a continual source of frustration for me. Every time someone starts a new desktop OS project they just keep making the same mistakes (at least I think they are mistakes) and we end up with what is essentially another Linux distro.

> Yes, 90% of desktop users use Windows. But Linux is not Windows, and neither is Haiku, and so I'm not sure why you're upset that we've decided to go a route more Linuxy than Windowsy here.

Because there are approximately 200 Linux distributions that already went that route and they're not particularly useful dekstop OSs either. Haiku already had an uphill battle in lack of software and hardware support, but the more it makes itself like a Linux distro the less reason I see to choose it over a Linux distro.

> And as an OS developer and package maintainer, I prefer the tradeoff the other way.

Yes, exactly. You like package management because it makes your life easier, not because it makes the system simpler, and not because it provides more flexibility for the user.

> You are of course more than free to create AppImage-style HPKGs on your own. :)

I could do that in Linux or Windows, why bother doing it for an OS with even less hardware and software support? If an OS wants me to use it over something else then I need compelling reasons.

> Well, it seems most of the open source world disagrees with you very much, then.

Perhaps that's part of the reason they have so few desktop users. I can only speak for myself here.

> (at least I think they are mistakes) > Because there are approximately 200 Linux distributions that already went that route and they're not particularly useful dekstop OSs either

I think the mistakes of Linux are having a system that "stacks up" components without any overall design philosophy or any sort of vertical integration. In my days before Haiku, I used Linux a lot, and was continually frustrated with how every upgrade audio would break, or the video codecs wouldn't play audio, or ... well, a lot of other issues that were fixable, but every time I had to edit a config file or rebuild something myself was very annoying. That's why Linux isn't a useful desktop OS for me, not because of the package manager, which actually makes it somewhat tolerable.

Haiku doesn't have those issues: if something doesn't work, it's our fault, not the kernel team's fault, or the X11 team's fault, or the alsa team's fault, etc. And that also means we can design the interconnections between these systems to be slimmer and more efficient than Linux did, since they need to support "component swapping."

> Yes, exactly. You like package management because it makes your life easier, not because it makes the system simpler, and not because it provides more flexibility for the user.

Yes, it makes my life easier as a developer. But it also makes my life easier as a user: Why am I going to go search a website I barely trust for a zip file that I extract and then add symlinks to? I much prefer the one-click-install model, thanks, and I know a lot of users that do too.

I don't know what flexibility I've lost that. As I've said above, I can still install packages in `~`, and extract them if I really did want to put it somewhere besides that. So what can I not do now that I could before?

> If an OS wants me to use it over something else then I need compelling reasons. > Perhaps that's part of the reason they have so few desktop users. I can only speak for myself here.

For me at least, as well as most Haiku users I know, the reasons are the ones I outlined above, not the package manager.

> I think the mistakes of Linux are having a system that "stacks up" components without any overall design philosophy or any sort of vertical integration. [...] That's why Linux isn't a useful desktop OS for me, not because of the package manager, which actually makes it somewhat tolerable.

I agree, but I think the reason Linux is this way, where everything depends on multiple other things even while they frequently break and have no integration, is at least in part because of the reliance on package management. If Linux had a stable base set of shared libraries developers could depend on and applications were distributed as appdirs, then developers are disincentivised towards non-base-system dependencies because they'd have to include them. You could then use what few advantages shared libraries offer (security updates, slightly less wasted space) for the most important things in the system while still allowing the simplicity and flexibility offered by applications just being a folder.

> Yes, it makes my life easier as a developer. But it also makes my life easier as a user.

Sure, as long as you only ever want to work within the confines of what is provided by the package manager. There's a difference between "easy" and "simple". I prefer "simple" because it can be understood and reasoned about and conformed to my use case. "Easy" requires the system to try and understand what I want, and we know how well that works for youtube, netflix, and amazon recommendations.

> I don't know what flexibility I've lost that. As I've said above, I can still install packages in `~`, and extract them if I really did want to put it somewhere besides that.

Can you put an application on a USB drive, take it to another Haiku system, and run it from the USB drive without installation? Can I have 3 different versions of the same application, each on a different volume? Can I created a folder hierarchy and place applications in it according to my own organizational criteria? If so, maybe Haiku's packaging system isn't so awful. I expect that isn't the case except for a handful of applications though based on what you've said previously.

> is at least in part because of the reliance on package management. If Linux had a stable base set of shared libraries developers could depend on

Except in saying that, you're completely ignoring the fact that X11 by itself requires how many different projects, all of which have different teams, goals, etc.? Just attempting to even get that would wind up in bikesheds at so many levels that it'd be impossible to do. But this has been Linux's problem since the 90s, it's not new at all.

And Linux has always been "just a kernel." Even FreeBSD still has disagreements about what to put in the base system, and they did get along without a true package manager for a while, but not anymore.

> Sure, as long as you only ever want to work within the confines of what is provided by the package manager.

A few weeks ago I needed something the package manager didn't have. So I ported and made another package for it. I also ran into a BeOS app that still used the "appdir" model because nobody updated it, and it still worked.

The package manager isn't "old magic" which must be "appeased" and "worked around." If it doesn't work, or it's missing something, we fix it.

> "Easy" requires the system to try and understand what I want, and we know how well that works for youtube, netflix, and amazon recommendations.

I've reiterated multiple times that you can forego the package manager and use the still-existing "easy" route if you'd like. Why does the package manager's mere existence cause a problem?

> Can you put an application on a USB drive, take it to another Haiku system, and run it from the USB drive without installation? ...

Yes. The executable bit still exists outside of packages, you know ;)

You will need to manually extract said packages, and then set up the `lib` folder properly (just as app developers did for appdirs); and then this relies on the application using relative paths for loading data (which all should, because they can be installed in `~` as well, but I'm not sure we check for conformance on this point just yet.)

You of course loose all the benefits of the package manager -- updates, etc. -- by doing this. But I guess that's what you want.

I don't think we're disagreeing on the problem with Linux Desktop here. The whole system is a patchwork of projects by different groups with disparate goals.

> I've reiterated multiple times that you can forego the package manager and use the still-existing "easy" route if you'd like. Why does the package manager's mere existence cause a problem?

Because when it is the official "way things are done", that will be relied upon and anyone not doing things "the way things are done" will be ignored and told to do things "the way things are done". See: any question on a Linux Desktop forum where the user wanted to do something out of the ordinary.

Example: Try installing Visual Studio Build Tools to somewhere other than Program Files. It can't be done. It will install a few things to wherever you pointed it, but because "Program Files is where the programs go" someone at Microsoft hardcoded paths so it just dumps the majority of it in Program Files anyway.

Another example: Try to get apt to download a package you already have installed, and all its dependencies, onto a USB drive so you can install them on a computer that doesn't have the internet. The developers never considered the possibility that someone would want to download software for a different computer.

> Yes. The executable bit still exists outside of packages, you know ;)

It isn't about the executable bit, it's about expectations. Someone hardcodes a path to something because that's where the package manager puts it and I'm SOL.

> You will need to manually extract said packages, and then set up the `lib` folder properly (just as app developers did for appdirs);

The difference of course being that the developers do it for an appdir, whereas now that is something I have to do as the user.

> and then this relies on the application using relative paths for loading data (which all should, because they can be installed in `~` as well, but I'm not sure we check for conformance on this point just yet.)

Precisely. It isn't the way things are done, so no one cares.

It sounds like the hoops I'd have to jump through to make appdirs on Haiku might be less than what I'd have to do on Linux, which is nice, but isn't going to make Haiku any more attractive to me. After all, if I'm going to jump through those hoops I may as well do it on an OS with better hardware and software support.

> I don't think we're disagreeing on the problem with Linux Desktop here. The whole system is a patchwork of projects by different groups with disparate goals.

Indeed we agree on that.

> See: any question on a Linux Desktop forum where the user wanted to do something out of the ordinary.

That is a community problem, not a technical problem then. We should fix those, too.

> onto a USB drive so you can install them on a computer that doesn't have the internet. The developers never considered the possibility that someone would want to download software for a different computer.

Haiku's `pkgman` doesn't have this feature built-in yet, but it would be easy enough to add. Already you can just copy `hpkg` files out of /system/packages to anywhere you want, and then run `pkgman install <files>` to install those HPKGs elsewhere (assuming you grabbed all the right ones.)

Actually, since you can already dump package info (including dependencies) using `pkgman`, writing a script to do this would be pretty easy.

It looks like there's a way to do this in apt, anyway: https://stackoverflow.com/a/27469489

> After all, if I'm going to jump through those hoops I may as well do it on an OS with better hardware and software support.

If that's all you want, then sure, go ahead. Again, this wasn't some integral part of Haiku's identity in our minds.

I'm aware of the script for apt, actually, precisely because I needed to do this once. That's a hack though, apt clearly wasn't built with the idea that anyone might ever want to do something with packages other than install them on their local system.

It's fine that Haiku's goals and mine don't align, really it is. I'm just not going to go out of my way to use it because I don't feel it offers advantages that outweigh the disadvantages.

"It wasn't built with the idea", but yet you can do that, because of the UNIX philosophy of chaining commands together. So I think if you're calling it a "hack", then you fundamentally disagree with the UNIX philosophy.

I mean, I have my issues with it, but I wouldn't go so far as to say that kind of command chaining is a "hack".

> "It wasn't built with the idea", but yet you can do that, because of the UNIX philosophy of chaining commands together. So I think if you're calling it a "hack", then you fundamentally disagree with the UNIX philosophy.

I disagree with the fact that the unix philosophy hasn't been updated since the 70s and text parsing is still considered the height of chianing applications together. I call it a hack because that's exactly what it is.

There's also this artificial distinction between the uninstalled and the installed form of the same software. Once you have installed it, it is married into a system that makes it very hard to get it out of the running system again and transfer it to another system (unless you kept the debs or hope that they are still online in some repo).

A better system is one in which the archive/installer and the installed instance of a software is one and the same. Such as a Mac .app bundle or an AppImage for Linux.

> Another example: Try to get apt to download a package you already have installed, and all its dependencies, onto a USB drive so you can install them on a computer that doesn't have the internet. The developers never considered the possibility that someone would want to download software for a different computer.

This is not true of all package managers. DNF (for Fedora, Mageia, and soon OpenMandriva) and YUM (for RHEL and CentOS) have a download subcommand that lets you resolve the full chain of dependencies without considering what's on the computer to be able to have everything for installing it offline somewhere else.

AnIdiotOnTheNet, did you know the https://gitlab.com/probono/platformissues project? It is describing the Desktop Linux Platform Issues and what should be done to overcome them. I invite you (and everyone else interested in this topic) to contribute.

> Yes, 90% of desktop users use Windows.

Windows has both a consumer-focussed App store and a developer-focussed package manager [0].

[0] well, okay, the latter is for .NET rather than Windows per se.

Yes, among many other hateable things MS has done to Windows lately, they've started adopting the bad ideas from OSS.

But, Windows also has the best hardware and software support of any desktop operating system by a wide margin, so if I'm going to use an OS I don't like I may as well use the one that lets me run the software I want on the hardware I have.

And almost no one uses them. Or did you get your Photoshop in the Windows Store?

> I think that package management has no place in a desktop OS

Why? Is this from a developer or an end-user perspective? From an end-user perspective, why does it matter?

For any sufficiently complicated application, most developers are going to rely on existing libraries and other components. So either you have a centralised way of managing this (i.e. a package manager) or you have every app with its own packaged (and thus potentially duplicated) dependencies and hope that every developer pushes out a new version whenever there's a security vulnerability in one of the dependent components. Whatever the drawbacks of package managers, that seems like the only sustainable model if you remotely care about security.

From an end user perspective I want control over what I have installed, and where it is installed. I want to be able to install multiple versions of an application, I want to be able to put that application on any volume, I want to be able to put that application on a thumb drive and run it on a different PC, I want to be able to install the latest version without having to wait for the repo to be updated, I want to be able to install applications that aren't in the repo, and I want to be able to do it without library conflicts and version mismatches. I have never in my life seen a package manager that can do those things.

From a developer perspective I just make appdirs anyway, because to me part of what makes personal computing great is being able to make an application and distribute it myself without having to kowtow to 200 different package repositories.

>Whatever the drawbacks of package managers, that seems like the only sustainable model if you remotely care about security.

If your OS doesn't give you any application sandboxing features whatsoever because its stuck in the idea that permissions apply only to users, then maybe. Most of the shared libraries you'd care about security patches for should be part of the base system so appdirs don't have to include them. Of course, that means actually having a stable and well defined base system. On the whole, however, I think people who make this argument should probably be using OpenBSD if they claim to care about security so much. Like I said, it's a tradeoff, you don't have to agree.

> I want to be able to install applications that aren't in the repo, and I want to be able to do it without library conflicts and version mismatches. I have never in my life seen a package manager that can do those things.

Well, you're generally not limited to the repos. You can pull down a git repo and build from source (which is generally a one-liner command).

Arch's AUR is pretty good for packages not in the official repos, including, in some cases, earlier versions.

> From a developer perspective I just make appdirs anyway, because to me part of what makes personal computing great is being able to make an application and distribute it myself without having to kowtow to 200 different package repositories.

Right. And will you keep checking on your appdir-bundled components to make sure they're updated when necessary? This is what seems to me the real drawback of this method.

>>Whatever the drawbacks of package managers, that seems like the only sustainable model if you remotely care about security.

>If your OS doesn't give you any application sandboxing features whatsoever because its stuck in the idea that permissions apply only to users, then maybe. Most of the shared libraries you'd care about security patches for should be part of the base system so appdirs don't have to include them. Of course, that means actually having a stable and well defined base system.

Sandboxing is a separate issue.

Probably the BSD-model is better in some ways than the Linux model for having a well-defined base system.

> On the whole, however, I think people who make this argument should probably be using OpenBSD if they claim to care about security so much. Like I said, it's a tradeoff, you don't have to agree.

Perhaps, but there a lots of intermediate positions in the tradeoff. I myself settle for Linux-level usability and Linux-level security (because Windows-level security is unacceptable).

> Well, you're generally not limited to the repos. You can pull down a git repo and build from source (which is generally a one-liner command).

Yeah, it says a lot that this is the standard fallback. No thanks.

> Right. And will you keep checking on your appdir-bundled components to make sure they're updated when necessary? This is what seems to me the real drawback of this method.

I disagree that it is a big deal. For one, applications can check for updates on their own, they don't need the package manager/repository model to do that. AppImage has an alternative method where the AppImage provides a URI that the system can check for updates.

> because Windows-level security is unacceptable

Have you not used Windows since 98? There really isn't a single security feature Linux has that Windows doesn't. The biggest threat you face is ransomware, where Linux has the advantage only because it's such a pain to install software that doesn't come from the repository.

> Have you not used Windows since 98? There really isn't a single security feature Linux has that Windows doesn't. The biggest threat you face is ransomware, where Linux has the advantage only because it's such a pain to install software that doesn't come from the repository.

I have used Windows off and on from 3.11 to 10. Yes, I understand that what you say is true in theory. However, it is not true in practice. In Windows 10 I tried installing an app directly from the official Windows app store. Within 30 minutes that app had pulled down some sort of horrible malware that I couldn't get official Microsoft Tools to scrub, and even 3rd party ones had trouble. I think I ended up reinstalling, I can't remember. I do remember it sucked several hours of my life.

Crap like that wouldn't make it into a Linux repo; but apparently is fine for Microsoft's official app store. You can keep that security model.

And, as for the typical Windows program installing method, which is navigating to some website and downloading an installer, that is even more ripe for this sort of chicanery. No thanks. I'll stick to curated repos.

Those aren't security models, they're application distribution models, but besides that, the best you can do is an anecdote about "some software" you don't remember at all?

Yeah, installers suck, I think they don't quite suck as bad as repositories because at least you don't have to rely on a third party maintainer, but I can understand that if you don't draw outside the lines very often then they're probably fine.

What we should be doing is what Android does, but simpler (that is, without the store and the part where a user account is assigned). Applications should be directories, and they should be launched in their own namespace by default and sandboxed until you give them permission to do things.

They're application distribution models that have a great impact on security.

> the best you can do is an anecdote about "some software" you don't remember at all?

It was a wallpaper changer, and it was 3-5 years ago and I didn't keep a detailed journal of my Windows experiences. But it tells you something if you can be infected with malware from the official Microsoft apps store. That's not a platform I want to be doing banking or even email on.

I like Android for lots of things, but a model of safe and responsible software distribution it is NOT.

Anyway, if you like the separate namespaced app model, Linux offers that possibility too, you can use something like Cockpit [ https://cockpit-project.org/ ] to manage apps running in containers.

I'm aware that you can jump through a bunch of hoops to make something like that work on Linux, for ever single application individually, but I don't want to jump through a bunch of hoops so I'll just keep using Windows because it works and has much better hardware and software support. Linux desktops have had decades to convince the world that their way of doing things is better and part of the reason they haven't managed it, I think, is because they never listen to criticism and insist that their backwards and ancient unix ways of doing things are better like it's some kind of religion.

> I like Android for lots of things, but a model of safe and responsible software distribution it is NOT.

Bull. Every application you download from the appstore is sandboxed by default and there is effort put in to verifying that software isn't malicious. It doesn't always work for two reasons: Unlike Linux desktops, Android isn't actively hostile to proprietary non-opensource software, and people actually use it.

Linux repositories can, and have, had malware. Check google, it happened to Gentoo in 2010 (interestingly someone also recently put some into Gentoo's GitHub mirror) for instance. That's because it isn't essentially different from any other appstore, except that a whole lot more people use a much broader range of software from Android and iOS appstores, which also have a whole lot more desktop software.

Reply on news.ycombinator.com