> what do you mean you wanted to install applications to an external disk?
Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there.
> if you have a separate OS on the external drive, you could chroot in and install it.
No thanks. I'd just like to have the application stored on an external disk, and execute it on the OS I have installed.
> If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed.
Not really, because Linux likes to have an application spread its files all over the hierarchy, so in reality I need to either use some form of union-mounting, and/or simlinks. Of course that is only sufficient if there are no library conflicts between what the application wants and what the system uses, in that case I need to use LD_LIBRARY_PATH and other tricks. In some cases I'll need to use a launch script that calls a different ld.so.
That's a lot of hoops compared to how sane operating systems do it.
> LVM to share disk space between the disks
System breaks when disk is removed. No good.
> Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead.
Which is pretty much what I want, because the alternative is dealing with the bullshit I mentioned above whenever you step outside the package manager's sandbox.
> why are your file systems sensitive to disk drives?
A couple of systems I have at home have a 16GB primary disk, so it is useful to be able to put things on an external disk. I have yet to see any package manager that can actually handle that.
> Use a layer (or more) of indirection through LVM and RAID...
Yeah, that's a great idea, just introduce more complication and abstraction to make up for a shortcoming in how Linux developers think about applications.
Or, just have your programs be self contained in a single file or folder and put them wherever it makes sense.
> Again, you are disagreeing from a theoretical standpoint here, not a practical one
Call me when I can put an application on a thumbdrive and take it to another system and run it without having to worry about dependencies or being connected to the internet. I can do this with AppImage, MacOS App Bundles, and quite a lot of Windows programs and I can do it today, not some "maybe we'll implement it" future. Oh yeah, and there's no magic, they are single files or folders and can be manipulated as such without any special magic from the OS. My understanding is that even if Haiku was modified to accommodate this kind of thing, it would require magic handling to do so because dependencies.
Also, you want to talk practicality? In part 4 Probono had to install Haiku to a larger disk because he was outgrowing the one it was installed on. Here's a question: why could't he keep his install where it is and just put new applications on a different partition? Like you can do on a Mac, or on Windows (usually), or with AppImage?
There are practical limitations imposed by hpkg. You think they're reasonable trade-offs, I disagree.
I really don't understand why you seem so intent on convincing me that my opinion is incorrect. This is a real limitation of your system that actually exists, the complexity behind it is real. You're of the opinion that those are not significant, and I am of the opinion that they are. Your constant attempts to convince me otherwise, mostly by telling me I'm in the minority, or my usecase is wrong and invalid, are not and never will be well received. Frankly, they remind me far too much of Linux Desktop evangelists.
> You can mount a package file from anywhere, to anywhere, with the `mount` command as with any other disk image.
Which I can only assume means I must manually mount any dependencies not in a blessed path first before I mount the application that is also not in a blessed path, since the convention is not to package non-base system dependencies with applications.
> Why would I care whether my program is on one disk or another?
A lot of reasons. Maybe your OS disk is on a ludicrously fast SSD but is space-limited and you don't want to waste that space on applications that don't need it.
> Why would I even "install" something, instead of dragging/dropping a single "file" (yes I know it's a directory) like I usually do.
Agree wholeheartedly. It makes perfect intuitive sense: the application is exactly where I think it is, and if I move it somewhere else then it is exactly there, and if I delete it then it is exactly gone.
> 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.
> Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them.
Linux desktops can do this. Flatpak maybe can't (Idk, I don't use them that often, but I'd be surprised if they couldn't), but even before AppImage, Flatpak, Snap, etc you could always just run an application from wherever you want. You could do that 20 years ago, and you can do it today.
Desktops in the 80s didn't have sandboxing, but modern Linux desktops do. You can either implement sandboxing yourself through syscalls, use something like Systemd, or use the significantly more user friendly Flatpaks.
...Or don't use sandboxing at all, and do whatever you want. Download a (hopefully statically-linked) ELF from the internet, chmod +x it, then execute.
> standard in Linux Desktop application distribution
There is no such thing. There never has been, and there never will be :P
> If you’re building a kiosk, it’s hopefully obvious to avoid having any read-write mounted filesystems at all costs.
I wish there was support for this out of the box in linux distributions. Either by providing a (sub)set of software that doesn't need to write, and/or adding an overlay. Even for rasperries which are often used in a way where they would benefit it requires some work to set things up.
Having that kernel parameter set automatically when in that mode would be nice, too.
Or maybe I'm just not aware that distributions for this specific use-case exist.
> The Linux way of installing the apps is merely a convenient tradition. You can still put the app files anywhere and run. It will put its configuration files wherever the developer wanted them (conventionally the app dir is meant to be immutable and the files are meant to be stored under the user's home dir though). In fact many apps (incl. Chrome and PyCharm actually are installed the Windows way under /opt which is an equivalent to C:\Program Files\).
I don't think he was disputing the technical possibility of it. It doesn't help him from a user perspective though to know that this is merely a convention and not a technical limitation.
Funny. I've been using Linux for 10 (?) years and I still don't know what mounting means. I just know it's something that needs to happen in order for me to access the contents of a disk. I don't really care about it either, I only care about accessing the data. Why isn't it automatic anyway? Windows does it automatically whenever possible, why can't Linux?
>On a server, sure, but on a PC? It's their computer, they should be able to do that.
A user-writable location should never be used to load kernel modules. This is a privilege escalation vulnerability.
>You're confused because permission systems on Desktop OSs are currently based around user accounts, which is silly. If they were based around applications instead it wouldn't be a problem.
I prefer to deal with the real world design of operating systems rather than imagined ones.
>If you don't, then why is your application using it?
Using an API doesn't give you distribution rights. Copyright law assigns that to the creator of the application/shared library/. Depending on the license you will get different rights to either include a copy of the library, include a separate installer of the library, let the user install it separately, etc.
In other cases, patent law can disallow distribution. To give you an example off the top of my head - MP3 encoding is under US patent law and Audacity (an audio editing software that I use) does not allow you to save to the MP3 format till you install the shared library separately and point the software to its location.
>Apparently not one you're willing to elaborate on.
What is there to elaborate on? Are you not aware that millions of computers used in schools, colleges, corporate offices, server farms, homes, etc rely on multi-user features?
Solving a general problem involves solving it seamlessly for a large number of usecases. Otherwise you end up with a fragmented system that is confusing.
I would prefer they solve it in a perfect manner with perfect compatibility and perfect code with zero bugs, but they wouldn't listen to me. ;)
> I believe there are better and simpler solutions to the problem than package management.
Okay?
In any case, your folder based idea doesn't solve many of the real problems that users and creators face w.r.t. distributing, installing, and updating software. Before you reject them, its worth thinking about them. Bye!
> Case in point: Haiku applications appear to be files, but if you try to move them then you get told you can't modify a read only file system.
It's not an illusion, though. They really are files on a read-only file-system. The message is entirely correct. AppImages would do the same.
> I have other criticisms of Haiku, but we seem to be stuck on this one so I haven't brought them up.
Well, I am interested in those, too, of course. And despite how antagonistic this apparently is to you (sorry), I really am taking notes here.
> Why do you insist on making this appeals to the majority all the time?
Because the general case is the one that should be optimized for first, and other ones come later.
> If it is developers, then, well, it's kind of a feedback loop isn't it? Keep going that way and if you're not careful you become Gnome.
If you are trying to protect software from the developers making it, you are going to have a bad time.
> Besides, as I keep saying, I don't really care what the "majority" thinks.
That's fine if you are just you. Obviously people creating products have to think about it.
> Fair enough, but why does it need to have applications installed on the same partition?
Nothing "needs" that, this is just how it is set up; the current default as it were.
> Of course, right now that would mean recompiling Haiku if I wanted to run something off a thumb drive.
Because there is no GUI, yes. Or you know, like I've said before, the executable bit still exists and you can use it, too.
> Linux doesn't need to do things the way it does either, but culturally it is impossible to do something else at this point.
Yes, indeed...
> If what you're saying is true, then no, it's just a cultural one. That's almost worse.
No, it is not. Linux has created in everyone the fear of the culture above all else, to the point where elaborate technical solutions are crafted to cultural problems. Haiku has, and will continue to, change its "culture" when it becomes clear the time has come for that.
> Surely [...] dragging an app to the applications folder is more sane than every program needing a installer program to put all the files in the right places?
Yes. It was more sane, when:
1. The Applications folder lived on the Dock, so users actually knew it was there.
2. Many applications (much more than today) were distributed via DMG's with instructions that an app should be dragged to the Applications folder.
Without either of these things, a lot of users end up just running an application from their Downloads folder.
Worse, doing it the right way involves on a non-trivial number of steps. You have to (1) open the Finder, (2) navigate to the Applications folder, and (3) then drag the app from Downloads into Applications.
>So the modern version of that could just be dropping a folder into a special location there kernel knows to search for drivers, and include a control panel app.
Do you mean the kernel is going to load random files from a user writable location? That sounds like a security nightmare TBH. Also, then you can't safely lazy-load kernel drivers because you never know what the user has done to the folder. Or if the OS has to lock access to the folder then the user has no feedback as to why they can't "uninstall" stuff by simply deleting folders, etc, etc. There are dozens of problems. Turns out, people have already thought over those problems and proposed solutions :)
>otherwise you get DLL hell and require something like a package manager and all its associated limitations for basically no benefit at all.
You claiming there is no benefit to being able to install/remove/update third party shared libraries doesn't solve anything.
>just include a copy in the app folder, secure in the knowledge that it will never cause a conflict or break your application due to an update or some other application replacing it.
That assumes you have the rights to distribute the library and that the library is small enough.
>Desktops, a.k.a "Personal Computers", don't really have much of a multi-user use case.
Maybe not for you. For millions of other users, its a very important use case.
>None of this is anywhere near as complicated as the people who promote it like to pretend it is.
Well its certainly not complicated if you re-define the problems as non-problems.
> Every application install should be a union fs. This union fs should be entirely user-mode, so that if an application has 10,000 files, it doesn't take 10,000 round-trips to the OS kernel with the Intel mitigations, context switches, and cache flushes that all brings with it.
I disagree with this, as you've already over-complicated it by assuming some kind of unix-like-scatter-everything-all-over-the-file-tree-for-no-good-reason application installation. Just do what MacOS, RiscOS, DOS, etc did and have applications be a single file (or folder). There, install is just copy, can place it on any media you want, can carry it around with you, keep multiple versions, etc. It even keeps the abstraction of the application actually existing where it appears to exist.
overlayfs and iso9660 are not magic. So is mounting two ISOs in an overlayfs on Linux magic? Or on macOS? I guess I really do not understand how or why you quantify things "magic" at all.
> AppImages don't pretend to be somewhere they're not.
The entire concept of "filesystem mounts" means data pretends to be somewhere it is not. Haiku has used the concept in a slightly unorthodox way, but it is fully within the bounds of the concept, and we could do the same on Linux without modifying the kernel.
> I have to say, having my only interaction with the community be arguing with you has notably soured me on it
Once again, I am not trying to change your opinions; I am trying to understand and then correct your misinformed understandings of how this all works under the hood. If your objection to Haiku is "I don't want a package manager", point blank, then I can tell you why people like them and why we do, but obviously there is nothing for me to argue with there.
> there's just too much magic in it for all the limitations it still has
I would really, really appreciate it if you could explain to me your understanding of the word "magic", and how it applies so frequently to technology...
> Probono also wants it, he said as much in this very article, and he is an enthusiastic user of Haiku right now.
So then that is one. He has also only used Haiku for a week now. Maybe he'll change his mind; maybe he won't and the feature will get implemented. But either way, the stuff we are focused on right now impacts the whole userbase (system stability, optimizations, porting more apps), and so we are going to keep that as the focus.
> I'm not saying you should, I'm just saying you're being a bit presumptuous when you claim to speak for 95% of users, whom you've not only never polled but also can't even measure.
I speak for and about the users who have spoken up. Perhaps I'm wrong; but if there are people with strong opinions, I would expect them to express them somewhere in some fashion. I haven't seen anyone do so on this topic for some time.
> Not to mention that such claims sound a lot like the "99% of users just want Chrome" excuses of Linux Desktop evangelists.
But are they right? 99% of people who tell me they want to use Haiku more but don't, say "if it had Firefox or Chrome..."
> This is why I keep saying that what you really mean is 95% of Haiku developers, the parts of the community you have frequent contact with.
The Haiku forums and mailing lists are active enough that concerns and comments very often show up there. We have had more than one major feature or bugfix made because people chimed in there... In fact, one of the features probono noted as missing (word-wise-delete in text editors) was implemented last week as a result of that. We definitely do listen to the community.
> hpkgs are not simple and employ "magic"
What is "magic"?!? All of the major behavior of them is documented at various levels and depends on no "hacks" or undefined behavior.
> they are not bundled with their dependencies
If their dependencies are merely Haiku itself (i.e., as native apps should), they have nothing to be bundled with. If they are non-native apps that use Qt or the like, yes, they are not bundled, because a 100MB Qt package + 5 1MB apps is much smaller than 5x100MB bundled Qt apps, etc. But yes, you are correct here.
> they cannot (today) work from arbitrary locations without jumping through hoops
Yes, there is no GUI yet.
> and recompiling
That is only needed if you want the paths to be "blessed" with the dependency solver. But if you are only using native and not ported apps, you have no need for dependency solving...
> The only disagreement seems to be how much this matters.
And about the nature of "magic", it seems. But indeed we seem to have fewer points of misunderstanding by now..
> I'm surprised no one thought to make it a configuration option already. It seems like such a simple thing to look at a hardcoded path and say "maybe I shouldn't hardcode this path".
Haiku's philosophy is "sane defaults and minimal configuration where necessary." We have a "pseudo-test" that we generally go through before adding new options to the GUI (1. Did you ever change this setting? 2. Did changing it make you happier?)
We do have the find_paths() API for applications to not hard-code paths, but, you know, somewhere there has to be a hard-coded path for find_paths to return.
> UNIX baggage, etc.
Well, I certainly am not the biggest fan of the "everything is a file" philosophy indeed; but I also think if you took a poll among Haiku users and developers about `/dev/` you would not get a majority concensus to hide it more (it already does not appear in the GUI), and most would either be neutral or opposed to removing it (in favor of handles.) So if you are opposed to even `/dev`, then I think your philosophy and Haiku's are much more irreconcilable than I realized.
> Ideally there is no "system" partition, no "/boot" as I understand it to be called in Haiku
You are misinformed. `/boot` just refers to the partition Haiku is currently booted from. So `/boot/home` is where the normal home directory is (unless one has moved it). So there is no "system partition" segmented from the "data partition" as such, no.
Essentially, `/` on Haiku is not existent in any real location; but is rather the root mount point for filesystems. So `/boot` is the boot partition, I might attach a thumb drive and it will appear as `/waddlesplash thumb` or whatever else its name is, etc. In the GUI, navigating to `/` shows the nominal names of the partitions (with /dev/ and other such dirs hidden, usually.)
> The system is a file
But this is what Haiku does; the system is `haiku.hpkg`, and we just also have those files appear in `/system/, too, because to us hiding them completely would be much more "magical" (or more properly, opaque).
> But really, that's still a far cry from "all applications must be installed on the same volume as the system or otherwise in a list of blessed paths".
Which is a decision that is, as I noted already, open to change. There is no technical reason it has not been done.
Nooo. There's the problem. GUIs have always been a shitshow w.r.t. compatibility. I've pretty much come to the conclusion at this point that, if we want simple, we have to give up on wanting it with GUIs. Vendors just aren't going to ever agree. There's too much vision and financial incentive to compete. However terminals, are boring, and operating systems no longer have any reason to engineer incompatibilities. As of last year, they've all pretty much been like, yeah, we'll implement vt100 because we don't care anymore. Even Windows CMD prompt! It's great. This new consensus is going to make so much toil go away.
For example, here's an app I wrote a few months ago. It's a single file TUI application. The binary runs on all the different operating systems and looks exactly the same. Truly build-once run-anywhere. It literally looks the same on Linux as it does in Windows command prompt and Mac too etc. It doesn't have any dependencies. It's about 200kb. https://justine.storage.googleapis.com/blinkenlights/index.h...
I've been using it lately testing tool, because I want these single file programs to boot from BIOS on bare metal too. I've got it working for stdio so far. So once I add a virtio ethernet driver it'll be golden. Especially for cloud deploys. Every program you compile is its own operating system which runs on all the other ones too. I call it the Cosmopolitan C Library (NOTE: this page is work in progress!) https://justine.storage.googleapis.com/cosmopolitan/index.ht...
> Why in the world would I ever not want the software I install to read files in the Desktop and Documents folders? It doesn’t make sense!
Every now and then I'm reminded that different people have vastly different expectations. Of course I DON'T want software I install to read arbitrary files. Not just files in Desktop and Documents directories. Ideally each application would be completely isolated from the rest of the system, being able to only read and write in its little dedicated sandbox. Access to anything outside should require explicit confirmation (sort of like Little Snitch's dialog for network access). Delete the application and it completely disappears, leaving no trash behind anywhere on the file system. Sort of like iOS meets Qubes.
> e.g. not have 10e7 files in a single folder, which is something that Linux has some opinions (none of them good) about.
I keep running in to this as a common anti-pattern in software, even with software developers that should know better (having fallen afoul of it before).
I ran in to it with some semi-bespoke software once, used by a remarkable number of state departments across the country. It was one of many, many things wrong with that godawful thing. Worse, not only were they dumping files in a single directory, almost any time they went to do something with the directory they'd request a directory listing too. Like many of the bizarre things the app did, it never actually used the information it acquired that way.
Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there.
> if you have a separate OS on the external drive, you could chroot in and install it.
No thanks. I'd just like to have the application stored on an external disk, and execute it on the OS I have installed.
> If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed.
Not really, because Linux likes to have an application spread its files all over the hierarchy, so in reality I need to either use some form of union-mounting, and/or simlinks. Of course that is only sufficient if there are no library conflicts between what the application wants and what the system uses, in that case I need to use LD_LIBRARY_PATH and other tricks. In some cases I'll need to use a launch script that calls a different ld.so.
That's a lot of hoops compared to how sane operating systems do it.
> LVM to share disk space between the disks
System breaks when disk is removed. No good.
> Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead.
Which is pretty much what I want, because the alternative is dealing with the bullshit I mentioned above whenever you step outside the package manager's sandbox.
reply