LibreOffice is now available for Haiku(discuss.haiku-os.org)
discuss.haiku-os.org
LibreOffice is now available for Haiku
https://discuss.haiku-os.org/t/libreoffice-is-now-available-for-haiku/6917
150 comments
What makes Haiku better for personal computing, from the end-user perspective? Or to put it in another perspective, who is the eventual target user for Haiku? I'd like to find an excuse to test it out even knowing it's in alpha stages, but this seems to be missing from the FAQs. The only noteworthy statement is that it is fast, efficient, and easy to use. I'm not sure if those are sticking points for most users.
In its time, BeOS (which Haiku intends to clone) was super fast and had a minimalistic UI that was very joyful to use compared to Windows and Linux back then.
I wasn't too familiar with C++ or filesystems to comment on the veracity of the claims, but my understanding is they also exposed some seriously good APIs for the time and a neat filesystem. But as an end-user I would raise that there were a few very avant-garde apps - to me at least.
But that was over 15 years ago... Everything has been moving forward fast since. Hardware (an iPhone 4 was as powerful as Deep Blue), software, languages, libraries, network speeds, computing paradigms, etc.
Put another way, it's basically ... cool, but meh.
As a former BeOS user for a while, I've been looking every now and then at Haiku out of curiosity, hoping it would soon come out and pick up momentum. But in all honesty, and as much as I respect the impressive work the team poured into it, progress has been so slow and there has been so much to catch up with since that I suspect it'll be too little too late to make any difference by the time there's a stable release. Then again, who knows...
I wasn't too familiar with C++ or filesystems to comment on the veracity of the claims, but my understanding is they also exposed some seriously good APIs for the time and a neat filesystem. But as an end-user I would raise that there were a few very avant-garde apps - to me at least.
But that was over 15 years ago... Everything has been moving forward fast since. Hardware (an iPhone 4 was as powerful as Deep Blue), software, languages, libraries, network speeds, computing paradigms, etc.
Put another way, it's basically ... cool, but meh.
As a former BeOS user for a while, I've been looking every now and then at Haiku out of curiosity, hoping it would soon come out and pick up momentum. But in all honesty, and as much as I respect the impressive work the team poured into it, progress has been so slow and there has been so much to catch up with since that I suspect it'll be too little too late to make any difference by the time there's a stable release. Then again, who knows...
> What makes Haiku better for personal computing, from the end-user perspective?
It is a clone of BeOS which was much faster/responsive than Linux or Windows at the time (probably due to its use of multithreading).
It is an OS which target desktops, so it's a bit more integrated and coherent than the collection of software that Linux has. But they decided to not use Linux/*BSD as their base kernel so they are in perpetual alpha/beta..
It is a clone of BeOS which was much faster/responsive than Linux or Windows at the time (probably due to its use of multithreading).
It is an OS which target desktops, so it's a bit more integrated and coherent than the collection of software that Linux has. But they decided to not use Linux/*BSD as their base kernel so they are in perpetual alpha/beta..
That wouldn't be BeOS anymore.
The world already has enough UNIX clones.
The world already has enough UNIX clones.
You're conflating Linux and GNU/Linux: if you just use Linux, you could create a non-UNIX like system.
No, I also mean the kernel design.
We don't need yet another UNIX kernel clone written in C, replicating POSIX APIs.
Modern OSes should explore safer architecture models with modern programming languages, not replicate 70's designs from AT&T world.
We don't need yet another UNIX kernel clone written in C, replicating POSIX APIs.
Modern OSes should explore safer architecture models with modern programming languages, not replicate 70's designs from AT&T world.
NewOS is written in C/C++ instead of C only..
People who really, really miss BeOS.
I guess the "Why not Linux?" part of our FAQ is as much of an excuse as one can make, besides pure curiosity of course: https://www.haiku-os.org/about/faq#why-not-linux
> Linux-based distributions stack up software – the Linux kernel, the X Window System, and various DEs with disparate toolkits such as GTK+ and Qt – that do not necessarily share the same guidelines and/or goals. This lack of consistency and overall vision manifests itself in increased complexity, insufficient integration, and inefficient solutions, making the use of your computer more complicated than it should actually be.
> Instead, Haiku has a single focus on personal computing and is driven by a unified vision for the whole OS. That, we believe, enables Haiku to provide a leaner, cleaner and more efficient system capable of providing a better user experience that is simple and uniform throughout.
> Linux-based distributions stack up software – the Linux kernel, the X Window System, and various DEs with disparate toolkits such as GTK+ and Qt – that do not necessarily share the same guidelines and/or goals. This lack of consistency and overall vision manifests itself in increased complexity, insufficient integration, and inefficient solutions, making the use of your computer more complicated than it should actually be.
> Instead, Haiku has a single focus on personal computing and is driven by a unified vision for the whole OS. That, we believe, enables Haiku to provide a leaner, cleaner and more efficient system capable of providing a better user experience that is simple and uniform throughout.
Bah this standard answer is just wrong: nobody will force you to use X11 (for example) if you only want to use Linux..
Why not *BSD?
BSD only has one less layer as an "external" system (the initial userland libraries and utilities). X11, the desktop environment, etc. are still "stacked up."
I love it’s old school interface. It’s C++ API is old-school, for better or worse, so developing for it isn’t as nice as I would prefer, but for computing — documents, personal information management, and so on, I find it very enjoyable to use. And damned snappy, too.
Would I prefer a Linux distribution with a window manager/desktop based on Haiku/BeOS? Probably. A modern one that supported HiDPI would be amazing. One can dream...
If more and more software continues to be ported though, I’m not wedded to any one kernel. If I could do my entire job in Haiku, I would. It’s amazing to watch it get better and better as the years go on!
Would I prefer a Linux distribution with a window manager/desktop based on Haiku/BeOS? Probably. A modern one that supported HiDPI would be amazing. One can dream...
If more and more software continues to be ported though, I’m not wedded to any one kernel. If I could do my entire job in Haiku, I would. It’s amazing to watch it get better and better as the years go on!
I think the UI is cool. I like the way that windows can dock together. The application APIs are (reportedly) very good. Still destined to be a curiosity.
TIL: Haiku OS is still around.
DeathArrow(1)
This is a massive achievement. Being able to run a modern browser and an Office Suite makes it a viable desktop alternative in the coming future. I'm happy to see variety in the desktop OS space once again!
anyone notice real lag on an otherwise fastish Mac OSX build? Or perhaps add some insight to why that happens?
what's in haiku OS that's not in Linux? Is it like a bundled linux OS?
Haiku is a recreation of BeOS built on the NewOS kernel (not Linux). BeOS (and therefore Haiku) had some neat features like a database built into the FS, was designed to take advantage of multiprocessor systems, and put a lot of effort into providing great multimedia capabilities.
From my perspective, the project seemed to have been taken over by Linux Desktop people, introduced a package manager, and I completely lost interest in it. In that respect, it's basically a much less functional Linux distro.
From my perspective, the project seemed to have been taken over by Linux Desktop people, introduced a package manager, and I completely lost interest in it. In that respect, it's basically a much less functional Linux distro.
Yes, we've been taken over by "Linux Desktop" people so much, a majority of the team is still opposed to using the Linux kernel, dislikes ported software, and actively works to not use GPL code when we can!
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. Even most of the regular errors or problem states people associate with package managers don't occur all that often on Haiku.
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.
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. Even most of the regular errors or problem states people associate with package managers don't occur all that often on Haiku.
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.
> 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.
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.
>> ...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. 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.
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.
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?
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.
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.
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).
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!
> 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?
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.
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.
> 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, 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.
> 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.
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.
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'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.
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. 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.
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.
> 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.
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.
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).
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.
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.
[deleted]
Well by not introducing some sort of package manager would make Haiku even less functional. How would you manage all of the dependencies that LibreOffice requires to even run? (Especially updating Qt and WebKit), let alone update the OS itself which BeOS didn't have any of this. I'm pretty sure that nearly every modern OS out there has some sort of package manager.
So I would say that by introducing this package manager has actually helped the project gain many usable applications which Haiku previously didn't have for some time.
So I would say that by introducing this package manager has actually helped the project gain many usable applications which Haiku previously didn't have for some time.
> How would you manage all of the dependencies that LibreOffice requires to even run
The same way the portable Windows version does, or the Linux AppImage does. It isn't rocket science.
The same way the portable Windows version does, or the Linux AppImage does. It isn't rocket science.
I interpreted your post as implying that the introduction of a package manager as the turning point where you lost interest. Did I get that wrong or are there arguments against package managers that I've missed out on? I understand the dislike or particular implementations, but I had thought that the general idea of automated package management was generally considered a net positive.
Some of it is that all the implementations suck, but I think that's just a symptom of the root problem: package managers are the opposite of simple. They take control away from users and developers and put them into the hands of whoever is managing repositories. They don't let you decide where applications get stored, often won't let you have multiple versions, add an unnecessary layer between the developer and the user, and generally put you up the creek without a paddle if something goes wrong. There are a lot of reasons to not like package managers if you look around.
> generally put you up the creek without a paddle if something goes wrong
I would very much like to hear some anecdotes to back this one up, instead of a general accusation.
I would very much like to hear some anecdotes to back this one up, instead of a general accusation.
You've never had your apt database get corrupted? It's an experience you remember, because it means you can never install or uninstall anything ever again. Maybe they've improved on that somehow since it has last happened to me.
Nope, I never have.
Haiku's package manager makes that problem impossible, though, because there is no "installed files" database; whatever packages are in the "activated-packages" file get mounted on startup. If that file doesn't exist, it mounts everything in `/system/packages`. And if that's in an inconsistent state, you can boot into a previous state from the bootloader menu. And if that still doesn't work, you can copy a working `packages` directory from another Haiku install.
Haiku's package manager makes that problem impossible, though, because there is no "installed files" database; whatever packages are in the "activated-packages" file get mounted on startup. If that file doesn't exist, it mounts everything in `/system/packages`. And if that's in an inconsistent state, you can boot into a previous state from the bootloader menu. And if that still doesn't work, you can copy a working `packages` directory from another Haiku install.
This is the first time in my life that I've heard negative words about package managers in general. What's the downside? You can always just download and compile from source yourself if your so against it right
[deleted]
> What's the downside?
It didn't come from the Apple gods. The same ones who made two attempts to rewrite an OS with preemption and protected memory support before punting and buying one instead. Clearly they know best about how to structure an OS.
It didn't come from the Apple gods. The same ones who made two attempts to rewrite an OS with preemption and protected memory support before punting and buying one instead. Clearly they know best about how to structure an OS.
In a post about the non-Apple-related open source clone of the non-Apple-related BeOS, someone starts a thread about how much they don't like the style of package managers that come from Linux, which I am fairly sure is, again, not related to Apple, this is relevant how?
For context re: Haiku OS (I had not heard of it before)
From the project home page [0]:
> Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
From the wiki page [1]:
> Haiku is a free and open-source operating system compatible with the now discontinued BeOS. Its development began in 2001, and the operating system became self-hosting in 2008. The first alpha release was made in September 2009, and the most recent was November 2012; development is ongoing as of 2018 with nightly releases.
[0] https://www.haiku-os.org/
[1] https://en.wikipedia.org/wiki/Haiku_(operating_system)
From the project home page [0]:
> Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
From the wiki page [1]:
> Haiku is a free and open-source operating system compatible with the now discontinued BeOS. Its development began in 2001, and the operating system became self-hosting in 2008. The first alpha release was made in September 2009, and the most recent was November 2012; development is ongoing as of 2018 with nightly releases.
[0] https://www.haiku-os.org/
[1] https://en.wikipedia.org/wiki/Haiku_(operating_system)
It's called "Haiku" not "Haiku OS". :)
And see also our FAQ, since a lot of these questions wind up getting asked on these HN threads: https://www.haiku-os.org/about/faq/
And see also our FAQ, since a lot of these questions wind up getting asked on these HN threads: https://www.haiku-os.org/about/faq/
Sorry about that! Reminds me of Tor not TOR. :)
Bravo guys.
Man, Haiku grew a lot since I tried to use it last time! Neat!
a killer app would be docker
For a desktop operating system? I don't see why. Are there any use-cases of docker on the desktop I'm not seeing?
Maybe the idea is that once you have docker, you have all the environments (ubuntu, wordpress or anything else).
Is that how it works?
Is that how it works?
Still doesn't answer GP's question - what's the point of Docker on a desktop OS? Why would you run WordPress on the desktop? The only real reason I can think of would be for developers.
Well if you run Ubuntu, you would get Ubuntu desktop (Gnome or Unity or whatever it is now), right?
But yes, I was thinking developers.
But yes, I was thinking developers.
At that point I may just be running Ubuntu, no?
you can run your toolchain whether or not it already works on haiku
Well, it probably won't anyway; we don't have Linux syscalls. So you wouldn't be saving any time trying to use containers.
i means you can use it as a development machine and not have to rely on haiku team releasing every programming language and db version.
buzzword compliance
Tried Haiku recently and was much impressed with speed and stability but without being able to scale to 1920x1080 and having no multi-user capacity it's hard to see how this fits into modern computing environment.. still, one can hope the project sees improvements - I've tracked Haiku along with ReactOS for potential real world usage for years now.. so.. any day now.
EDIT: congratulations with LibreOffice port, that does make a difference in terms of usability.
EDIT: congratulations with LibreOffice port, that does make a difference in terms of usability.
> having no multi-user capacity it's hard to see how this fits into modern computing environment
Depends on what you mean by "modern computing environment". I mean, my computers are mine, an no-one else uses them. I know very few people that share their computer with other users (but maybe it's just my bubble).
Another story entirely for those who use a smartphone/tablet for their personal computing (the target use of Haiku).
Depends on what you mean by "modern computing environment". I mean, my computers are mine, an no-one else uses them. I know very few people that share their computer with other users (but maybe it's just my bubble).
Another story entirely for those who use a smartphone/tablet for their personal computing (the target use of Haiku).
>I mean, my computers are mine, an no-one else uses them.
That's only half of what a multi-user system does though. The other half is about fine-grained privilege management.
One of the reasons (not the only reason by any stretch but a contributing factor certainly) why Windows has so many more problems with viruses than other OS's is that under windows you're basically either a user or an admin, there's no in between. Crucially, there's also nothing lower.
Under linux[1] systems, it's totally possible to define a user that can read and write from one specific folder in the file system tree but not it's ancestor nodes, read from the keyboard but not the mouse and absolutely nothing else. All of those problems that windows has with random programs being keyloggers are eminently solvable on linux because you can make a custom user that cannot use networking or listen to the keyboard as appropriate, and then launch the process using that user.
Anyway, how well used all these capabilities are depends a lot on the person administering the linux system, but windows is extremely reactive in this fashion. Desktop linux users tend not to run outgoing firewalls, for example, they just don't allow software that they don't trust to access the network.
[1] anyone know how to write star-nix on hacker news without it making everything italics?
That's only half of what a multi-user system does though. The other half is about fine-grained privilege management.
One of the reasons (not the only reason by any stretch but a contributing factor certainly) why Windows has so many more problems with viruses than other OS's is that under windows you're basically either a user or an admin, there's no in between. Crucially, there's also nothing lower.
Under linux[1] systems, it's totally possible to define a user that can read and write from one specific folder in the file system tree but not it's ancestor nodes, read from the keyboard but not the mouse and absolutely nothing else. All of those problems that windows has with random programs being keyloggers are eminently solvable on linux because you can make a custom user that cannot use networking or listen to the keyboard as appropriate, and then launch the process using that user.
Anyway, how well used all these capabilities are depends a lot on the person administering the linux system, but windows is extremely reactive in this fashion. Desktop linux users tend not to run outgoing firewalls, for example, they just don't allow software that they don't trust to access the network.
[1] anyone know how to write star-nix on hacker news without it making everything italics?
> [1] anyone know how to write star-nix on hacker news without it making everything italics?
Only have one single * in the entire post.
[X] Not sane
[X] Already complained
[X] Issue acknowledged
[X] Complaint filed probably over a year ago at this point
[X] Given up; incentivized to build alternative to HN (know what I want, but currently have no time unfortunately)
EDIT: I added Unicode checkmarks to my post, and they got eaten. [X] Cherry+icing on cake - seriously, wow.
Only have one single * in the entire post.
[X] Not sane
[X] Already complained
[X] Issue acknowledged
[X] Complaint filed probably over a year ago at this point
[X] Given up; incentivized to build alternative to HN (know what I want, but currently have no time unfortunately)
EDIT: I added Unicode checkmarks to my post, and they got eaten. [X] Cherry+icing on cake - seriously, wow.
[deleted]
You can do that stuff on Windows too, it is just that nobody bothers to. Although stuff like disallowing users to use the network seem to only be available in Windows Pro, for some reason (although it might just be that only the GUI is lacking from the Home edition and you need to use the console or some 3rd party program, but i'm not sure).
But i disagree with the part about how Linux users behave: from my experience Linux users, at least home/desktop Linux users, behave pretty much the same way as Windows users.
But i disagree with the part about how Linux users behave: from my experience Linux users, at least home/desktop Linux users, behave pretty much the same way as Windows users.
> That's only half of what a multi-user system does though. The other half is about fine-grained privilege management.
Useful in a networked corporate environment, a lot less so on a personal computer.
> All of those problems that windows has with random programs being keyloggers are eminently solvable on linux because you can make a custom user that cannot use networking or listen to the keyboard as appropriate, and then launch the process using that user.
You can do that on Windows and have been able to since at least Vista. the only reason I disqualify XP is that I wrote a keylogger for it so I know for a fact that you can grab raw keyboard input from any user session. Even before that though NTFS offered a fine grained access control mechanism for files and folders.
> Desktop linux users tend not to run outgoing firewalls, for example, they just don't allow software that they don't trust to access the network.
My experience is that they just don't run software that wasn't sourced from their distribution's package repositories. That is certainly an advantage of the appstore model, but you have to admit it is significantly more limiting that being able to get the latest version of something by downloading it from the vendor's website.
Useful in a networked corporate environment, a lot less so on a personal computer.
> All of those problems that windows has with random programs being keyloggers are eminently solvable on linux because you can make a custom user that cannot use networking or listen to the keyboard as appropriate, and then launch the process using that user.
You can do that on Windows and have been able to since at least Vista. the only reason I disqualify XP is that I wrote a keylogger for it so I know for a fact that you can grab raw keyboard input from any user session. Even before that though NTFS offered a fine grained access control mechanism for files and folders.
> Desktop linux users tend not to run outgoing firewalls, for example, they just don't allow software that they don't trust to access the network.
My experience is that they just don't run software that wasn't sourced from their distribution's package repositories. That is certainly an advantage of the appstore model, but you have to admit it is significantly more limiting that being able to get the latest version of something by downloading it from the vendor's website.
>My experience is that they just don't run software that wasn't sourced from their distribution's package repositories. That is certainly an advantage of the appstore model, but you have to admit it is significantly more limiting that being able to get the latest version of something by downloading it from the vendor's website.
It would be very limiting if it were reality, yes. I frequently download packages that aren't part of the default distro repo though. There's lots of PPA's, and I also install a lot of software just by extracting it into a directory in my home folder and running it.
It would be very limiting if it were reality, yes. I frequently download packages that aren't part of the default distro repo though. There's lots of PPA's, and I also install a lot of software just by extracting it into a directory in my home folder and running it.
I keep hearing this and I'm thinking its a generational difference.
When I grew up having a computer was a big thing and we certainly didn't have one for each person in my home we had a family computer which i think cost around 1K in 1995 or around 1700 adjusted for inflation.
I think that as computers have gotten progressively cheaper it ought to be increasingly likely to have a computer per person but I feel like the family computer ought to still to some degree to be a thing but have no stats to back this intuition.
However even with one user it would be good to have a login to protect data from at least casual snooping. Ideally since laptops have become more common than desktops full disk encryption ought to be sort of a minimum requirement. Maybe someone can port luks.
Harder but zfs would also be neat as well as it includes encryption.
When I grew up having a computer was a big thing and we certainly didn't have one for each person in my home we had a family computer which i think cost around 1K in 1995 or around 1700 adjusted for inflation.
I think that as computers have gotten progressively cheaper it ought to be increasingly likely to have a computer per person but I feel like the family computer ought to still to some degree to be a thing but have no stats to back this intuition.
However even with one user it would be good to have a login to protect data from at least casual snooping. Ideally since laptops have become more common than desktops full disk encryption ought to be sort of a minimum requirement. Maybe someone can port luks.
Harder but zfs would also be neat as well as it includes encryption.
> When I grew up having a computer was a big thing and we certainly didn't have one for each person in my home we had a family computer which i think cost around 1K in 1995 or around 1700 adjusted for inflation.
Fair enough, and I see your point. The first computer we got arrived in my house the same year, but we used to run windows 3.1 on that thing, and it certainly didn't have different user for different members of the family :)
also, my father was so scared of me and my brother screwing up, that, when given the opportunity to have Windows 95 he installed it on a different partition and we dual-booted windows 95 and 3.11. Me and brother were only allowed on dos/win3.11. I doubt it was a sound idea, technologically-wise,but at the time I was like 8-9 years old, and was mostly interested in starting doom 2
So that was how my father implemented users at the time.
Fair enough, and I see your point. The first computer we got arrived in my house the same year, but we used to run windows 3.1 on that thing, and it certainly didn't have different user for different members of the family :)
also, my father was so scared of me and my brother screwing up, that, when given the opportunity to have Windows 95 he installed it on a different partition and we dual-booted windows 95 and 3.11. Me and brother were only allowed on dos/win3.11. I doubt it was a sound idea, technologically-wise,but at the time I was like 8-9 years old, and was mostly interested in starting doom 2
So that was how my father implemented users at the time.
I suppose GP meant not physical users, but user accounts used for isolation and compartmentalization.
I think it depends on how your office is organized.
I've worked places where the roles of people was more important than the people, themselves. So if you were performing a particular role you'd sit in a different seat/at a different computer. We all had out specialties, but knew enough about each other's work to pop in and out.
This is often the case in time-sensitive operations, or when the computers are merely controlling something else larger or more important (mining operations machinery, steel mills, television stations, etc...)
In a more traditional office environment, your computer is your own; like your desk or your red stapler. IT can log in to a shell remotely. This is the scenario that Haiku seems to be focused on.
One is not necessarily better than the other. Just different. Different environments require different methods.
I've worked places where the roles of people was more important than the people, themselves. So if you were performing a particular role you'd sit in a different seat/at a different computer. We all had out specialties, but knew enough about each other's work to pop in and out.
This is often the case in time-sensitive operations, or when the computers are merely controlling something else larger or more important (mining operations machinery, steel mills, television stations, etc...)
In a more traditional office environment, your computer is your own; like your desk or your red stapler. IT can log in to a shell remotely. This is the scenario that Haiku seems to be focused on.
One is not necessarily better than the other. Just different. Different environments require different methods.
One is still forced to wonder how multiple user support is useful in that environment, all you really want is to be able to authenticate and audit access to the workstation for multiple users via a centralized system.
I believe Haiku is targeted at personal computing, not enterprise.
I find multi user capability a mixed bag. On one hand, I'm sick of typing my password(*nix)/allow(NT) for every trivial thing on modern systems. If I'm going to run as administrator, I might as well run on a single user system.
On the other hand, when I let someone else use my PC (wife/child/friend), I would like them to run in another environment. Also when trying random downloaded applications. In this scenario, multi user makes sense.
Multiuser is on the agenda for Haiku R2, and seeing how well they resolved the package management system, I expect multiuser R2 will be a thing of beauty.
On the other hand, when I let someone else use my PC (wife/child/friend), I would like them to run in another environment. Also when trying random downloaded applications. In this scenario, multi user makes sense.
Multiuser is on the agenda for Haiku R2, and seeing how well they resolved the package management system, I expect multiuser R2 will be a thing of beauty.
The use case for ReactOS is going to occur soon, or already is. And that's supporting older peripherals on new machines that cannot run Windows XP. Right now I've got a failing computer with an audio interface that doesn't have Windows 10 drivers. Upgrading to a new machine would require a new audio interface. But with ReactOS I'd probably be able to keep using the existing drivers. (As it is, the card is still supported on Windows 7 so I'm using that.)
> but without being able to scale to 1920x1080
Probably because you're on the VESA driver, which can only use whatever resolutions are embedded in your GPU. The `radeon_hd` driver works best, and on those you can scale to a lot more resolutions; I know some users who run at 1440p.
> and having no multi-user capacity
That's not quite true; we have POSIX multiuser already, so you can `useradd`, `chown`, ssh in to other users, etc. The GUI does not support multiuser yet, but that's partially for BeOS compatibility (on 32-bit), and partially because nobody has had any time to work on it (all other platforms.)
Probably because you're on the VESA driver, which can only use whatever resolutions are embedded in your GPU. The `radeon_hd` driver works best, and on those you can scale to a lot more resolutions; I know some users who run at 1440p.
> and having no multi-user capacity
That's not quite true; we have POSIX multiuser already, so you can `useradd`, `chown`, ssh in to other users, etc. The GUI does not support multiuser yet, but that's partially for BeOS compatibility (on 32-bit), and partially because nobody has had any time to work on it (all other platforms.)
Thanks for update re. 'radeon_hd' driver - would it work on anything else like internal Intel graphics or does that require hunting for other specialized drivers?
As to multi-user without GUI on Haiku, while I can see that this would technically work (and it's nice to know the capacity is there) it also leaves behind the strongest asset of Haiku which I think is the UI.
As to multi-user without GUI on Haiku, while I can see that this would technically work (and it's nice to know the capacity is there) it also leaves behind the strongest asset of Haiku which I think is the UI.
As the name suggests, it's for ATI/AMD Radeon HD cards & chipsets :)
We do have an intel_extreme driver, but it's not as mature than the radeon_hd driver, mostly because Intel's graphics hardware is a lot more complex to handle than AMD's. It works on most chipsets up to Haswell and then the Atom SoCs, but anything after that (Broadwell and beyond), it's doesn't really. I have a Broadwell device it doesn't work properly on, and was trying to fix it, but haven't really gotten anywhere yet.
Patches wanted & accepted...
We do have an intel_extreme driver, but it's not as mature than the radeon_hd driver, mostly because Intel's graphics hardware is a lot more complex to handle than AMD's. It works on most chipsets up to Haswell and then the Atom SoCs, but anything after that (Broadwell and beyond), it's doesn't really. I have a Broadwell device it doesn't work properly on, and was trying to fix it, but haven't really gotten anywhere yet.
Patches wanted & accepted...
You can do 1920x1080. You just need to modify your VM
Last time I heard about this OS was when it was mentioned in XKCD[0]. Out of curiosity I downloaded the image, installed it on a VM and played around a little. Later I forgot about it almost completely.
Nice to see that this project didn't die and is making some decent progress.
[0]https://3d.xkcd.com/806/
Nice to see that this project didn't die and is making some decent progress.
[0]https://3d.xkcd.com/806/
You mean to tell me
LibreOffice is on Haiku
Haiku is complete
LibreOffice is on Haiku
Haiku is complete
Almost, you got one too many syllables in the second sentence.
How about 'haiku runs libreoffice'?
Don't think I didn't wrestle long and hard on whether Libre is one syllable or two.
How does one pronounce it anyway? Is it lib-rey or liber (like liver)
I just anglicize the french.
So in french Leeb-grre (kind of like a throaty r, sounds a bit "gruh" but short)
and in enlish Leeb-ru' (kind of like a very short "ruh"). More like Libra truncated.
Its half way between a consonant and a vowel so I was torn. Glad we're facing the big issues here.
So in french Leeb-grre (kind of like a throaty r, sounds a bit "gruh" but short)
and in enlish Leeb-ru' (kind of like a very short "ruh"). More like Libra truncated.
Its half way between a consonant and a vowel so I was torn. Glad we're facing the big issues here.
[deleted]
Agree. Libre is a french word.
And Spanish :) https://en.wiktionary.org/wiki/libre#Etymology
I wrote a thing about Haiku a bit ago
https://navjack27.netlify.com/post/a-modern-os-haikuos-/
https://navjack27.netlify.com/post/a-modern-os-haikuos-/
> A big issue with Haiku is that there really isn’t a modern web browser available right now.
The web browsers available to Haiku are all based on a recent version of WebKit (As of now we have merged commits from upstream dating from 2018), the same engine in Safari and it also allowed QtWebKit-based apps to run, previously Otto browser and Qupzilla until they migrated to QtWebEngine (based on the Blink engine which we don't have yet). So to me, that seems to be modern for a web browser that has HTML5 and can also play YouTube videos.
Also, I have just replied to your comment on a recent 64 bit Haiku nightly in WebPositive.
The web browsers available to Haiku are all based on a recent version of WebKit (As of now we have merged commits from upstream dating from 2018), the same engine in Safari and it also allowed QtWebKit-based apps to run, previously Otto browser and Qupzilla until they migrated to QtWebEngine (based on the Blink engine which we don't have yet). So to me, that seems to be modern for a web browser that has HTML5 and can also play YouTube videos.
Also, I have just replied to your comment on a recent 64 bit Haiku nightly in WebPositive.
As much as I wanted to love Libre Office I just couldn't stand the UI. Menus behind menus and bazillion buttons everywhere. Craved in and got an office license.
I totally get you, because for me it is the other way 'round - I despise the ribbon bar vigorously, and when all the other applications picked it up, I felt like some higher power was mocking me. ;-)
At least as of version 6, LibreOffice actually has a ribbon bar-mode, but enabling it was non-trivial, and disabling it was even harder. I hated it even more than the MS Office ribbon bar; but I am obviously biased. It would be interesting to hear from someone who likes the ribbon bar how LibreOffice's version compares against MS?
At least as of version 6, LibreOffice actually has a ribbon bar-mode, but enabling it was non-trivial, and disabling it was even harder. I hated it even more than the MS Office ribbon bar; but I am obviously biased. It would be interesting to hear from someone who likes the ribbon bar how LibreOffice's version compares against MS?
Some day there will be a backlash against UX design that fetishizes minimalism, hiding features, and rearranging the deck chairs every six months. And on that day, when the masses go searching for a simple, organic interface that has logical menus and often used functionality exposed by buttons, I like to imagine that Haiku will be waiting there to salve the weary souls of my fellow travers.
If you don't like modern UIs, I'd recommend Linux today. The main Ubuntu has all the crazy UI changes that I stopped following long time ago, but all the old stuff is still in repos.
For example, this is blackbox 0.60.0 window manager, released around 2000: https://www.linux.org.ru/gallery/screenshots/19788
Almost 20 years later, the "blackbox" package is still around: https://packages.ubuntu.com/bionic/blackbox . You can install it, choose it in the dropdown from the login screen and start using it. Or get a version of Ubuntu with this stuff pre-configured (like xubuntu or lubuntu)
And the best part? You have all the modern software -- browsers, editors, compilers. You can be fully productive and enjoy the stable UI
For example, this is blackbox 0.60.0 window manager, released around 2000: https://www.linux.org.ru/gallery/screenshots/19788
Almost 20 years later, the "blackbox" package is still around: https://packages.ubuntu.com/bionic/blackbox . You can install it, choose it in the dropdown from the login screen and start using it. Or get a version of Ubuntu with this stuff pre-configured (like xubuntu or lubuntu)
And the best part? You have all the modern software -- browsers, editors, compilers. You can be fully productive and enjoy the stable UI
Personally, the linux UI is a little too weird for me to recommend (and I work 100% on linux intentionally!)—things like keybindings using ctrl rather than cmd/super, the insert functionality (I know zero people who intentionally use this), the crazy window management, and the middle-click-means paste hardwired into applications. Stable, sure, but stably very old and difficult to alter to your preferences. MacOS is clearly thought out on a level that hasn’t been seen on linux since, I dunno, window maker?
I loved Window Maker back in the day, but macOS consistency (other flaws not withstanding, macOS is exceptionally consistent) goes a lot deeper than what a window manager can do. The consistency in macOS derives directly from the NeXT APIs.
GNUStep is my grandest regret for Linux. If I could wave a magic wand, all the mindshare spent on the early KDE vs. Gnome wars would have been dedicated to making a first class NeXT-like desktop environment and applications with display Postscript and the whole nine yards.
GNUStep is my grandest regret for Linux. If I could wave a magic wand, all the mindshare spent on the early KDE vs. Gnome wars would have been dedicated to making a first class NeXT-like desktop environment and applications with display Postscript and the whole nine yards.
I would love to run gnome exactly like it looked before they switched to unity. I know they switched back to gnome but the default shell still looks like belongs on a tablet (which is a great device and all, but my Linux machine is a workstation, not an internet/communication device), with most (if not everything) hidden instead of being showed in menus.
I tried I3WM at one point, but even with the ability to have tabs I just didn't end up with enough pixel space.
I tried I3WM at one point, but even with the ability to have tabs I just didn't end up with enough pixel space.
MATE
I'm running bits and pieces of XFCE (via Xubuntu) with XMonad and dmenu :-)
That said, what document viewer do I use when I want to read a PDF? Evince was the standard GTK/Gnome option, but it has hamburgerized everything to a state of being unusable. I recently discovered Atril, but I literally have to search DuckDuckGo for "evince xfce mate" every time I need to remember what it's called.
Both Firefox and Chromium have buried everything in hamburger obfuscation land as well. I could name more.
In short, even with my significantly customized Linux desktop, UX-ism still bites me. Yes I can find alternatives for a lot of things. No, I don't imagine Haiku being productive for me in the near term. But... Haiku does offer something of a complete thesis of how desktop UI should work. That desktop UI is firmly situated in the 1990s, but I'm increasingly of the opinion that is a good thing.
That said, what document viewer do I use when I want to read a PDF? Evince was the standard GTK/Gnome option, but it has hamburgerized everything to a state of being unusable. I recently discovered Atril, but I literally have to search DuckDuckGo for "evince xfce mate" every time I need to remember what it's called.
Both Firefox and Chromium have buried everything in hamburger obfuscation land as well. I could name more.
In short, even with my significantly customized Linux desktop, UX-ism still bites me. Yes I can find alternatives for a lot of things. No, I don't imagine Haiku being productive for me in the near term. But... Haiku does offer something of a complete thesis of how desktop UI should work. That desktop UI is firmly situated in the 1990s, but I'm increasingly of the opinion that is a good thing.
For PDF, try qpdfview or xpdf (you cannot get any more old-style than that!)
For images, you can always try feh or imagemagic's "display". Or if you want a bit more UI, "geeque" (which is based on gimageview, and still has not changed the design much)
For web browsers, I am afraid you don't have many options if you want to use modern web apps. The web evolves too fast for that. There are still independent browsers (like netsurf), but I gave up on them and just use chrome.
I doubt that Haiku can ever be practical, unless you live completely offline. Even PDF format keeps evolving -- version 2.0 was released in 2017 -- so you cannot keep maintaining versions just for a single OS.
And once you start porting entire programs from different platforms (like LibreOffice), the platform's unique UI traits will slowly disappear. Who will notice the unique kernel if it has POSIX compat layer and GTK?
For images, you can always try feh or imagemagic's "display". Or if you want a bit more UI, "geeque" (which is based on gimageview, and still has not changed the design much)
For web browsers, I am afraid you don't have many options if you want to use modern web apps. The web evolves too fast for that. There are still independent browsers (like netsurf), but I gave up on them and just use chrome.
I doubt that Haiku can ever be practical, unless you live completely offline. Even PDF format keeps evolving -- version 2.0 was released in 2017 -- so you cannot keep maintaining versions just for a single OS.
And once you start porting entire programs from different platforms (like LibreOffice), the platform's unique UI traits will slowly disappear. Who will notice the unique kernel if it has POSIX compat layer and GTK?
> I doubt that Haiku can ever be practical, unless you live completely offline. Even PDF format keeps evolving -- version 2.0 was released in 2017 -- so you cannot keep maintaining versions just for a single OS.
There have been platform-independent PDF handling libraries for over a decade now. The Haiku-native PDF viewer, BePDF, uses one internally to handle PDF files. So that's not a problem, really.
> And once you start porting entire programs from different platforms (like LibreOffice), the platform's unique UI traits will slowly disappear. Who will notice the unique kernel if it has POSIX compat layer and GTK?
BeOS was roughly POSIX compliant, and Haiku is even more so.
Yes, we would greatly prefer native apps to ports (we're not all that different from the macOS fanatics in that way), but we don't have the critical mass for that at the moment. But the kernel isn't and was never the truly "unique" bit; it was built to disappear behind the UI, really.
There have been platform-independent PDF handling libraries for over a decade now. The Haiku-native PDF viewer, BePDF, uses one internally to handle PDF files. So that's not a problem, really.
> And once you start porting entire programs from different platforms (like LibreOffice), the platform's unique UI traits will slowly disappear. Who will notice the unique kernel if it has POSIX compat layer and GTK?
BeOS was roughly POSIX compliant, and Haiku is even more so.
Yes, we would greatly prefer native apps to ports (we're not all that different from the macOS fanatics in that way), but we don't have the critical mass for that at the moment. But the kernel isn't and was never the truly "unique" bit; it was built to disappear behind the UI, really.
> Both Firefox and Chromium have buried everything in hamburger obfuscation land as well.
By default, sure. With Firefox it's trivial to permanently enable a traditional menu bar. Though that's not, I suppose, trivially-discoverable.
By default, sure. With Firefox it's trivial to permanently enable a traditional menu bar. Though that's not, I suppose, trivially-discoverable.
1990s? Nah, we're at 2003/2004 or so, especially considering how many gradients and saturated colors the UI uses.
>That said, what document viewer do I use when I want to read a PDF?
You should give Zathura a try :)
You should give Zathura a try :)
I use it, but it's a big buggy on big/complex PDF.
For those I just use evince.
For those I just use evince.
May I suggest Chromium :)
I'm only half joking, I find the browser built-in PDF viewer better than most, and convenient because I already have it. The PDF viewer in Firefox seems to work nicely, too.
I always used xpdf and never had an issue, although i use the Motif versions (xpdf4 seems to have switched to Qt).
As for a browser with a normal UI, Firefox comes hamburgerized out of the box but you can easily bring it back to relative sanity by making the menubar always visible and choosing the "compact" mode from the density option.
As for a browser with a normal UI, Firefox comes hamburgerized out of the box but you can easily bring it back to relative sanity by making the menubar always visible and choosing the "compact" mode from the density option.
I recommend replacing dmenu with rofi and checking out zathura for pdfs. With the mupdf backend it supports both pdfs and epubs it has almost no ui configurable vim like keybindings for navigation and search opens instantly and doesn't use much ram.
I've always used xpdf[1].
1: https://www.xpdfreader.com/
1: https://www.xpdfreader.com/
If that happens, people will most likely switch their desktop environments, not their OSes.
I think we see some of that already, given the persistence of XFCE and Mate.
Still, for the vast majority of people trying Linux, the recommendation is "use Ubuntu" which means "use Gnome." And the number of people trying Linux is relatively small.
If Haiku's implementation was complete, and ran on the range of hardware people want to use, and ran the apps people want (a lot of ifs in that statement), I could see "use Haiku" being a viable option for a lot of folks. I remember non-technical and technical people alike being very excited when encountering BeOS back in the day.
To be clear, I think the most likely future is crappier desktops for the masses. Windows is downright baffling to use with the unified start menu / advertising billboard / hide-the-control-panel interface. With every release, macOS makes at least one regression in terms of stability, security, usability, or performance and gives us some new useless feature to "defaults write NSGlobalDomain NSPleaseJustLetMeWorkInPeace -bool true." And Linux == Ubuntu == Gnome, which is the Philip Glass of interfaces.
I realize I'm ranting now. BeOS was a happy place for me. I just like to fantasize that Haiku could be such a place again. :-)
Still, for the vast majority of people trying Linux, the recommendation is "use Ubuntu" which means "use Gnome." And the number of people trying Linux is relatively small.
If Haiku's implementation was complete, and ran on the range of hardware people want to use, and ran the apps people want (a lot of ifs in that statement), I could see "use Haiku" being a viable option for a lot of folks. I remember non-technical and technical people alike being very excited when encountering BeOS back in the day.
To be clear, I think the most likely future is crappier desktops for the masses. Windows is downright baffling to use with the unified start menu / advertising billboard / hide-the-control-panel interface. With every release, macOS makes at least one regression in terms of stability, security, usability, or performance and gives us some new useless feature to "defaults write NSGlobalDomain NSPleaseJustLetMeWorkInPeace -bool true." And Linux == Ubuntu == Gnome, which is the Philip Glass of interfaces.
I realize I'm ranting now. BeOS was a happy place for me. I just like to fantasize that Haiku could be such a place again. :-)
You can try Enlightenment for non technical users. It's closer to MacOS, but with the full-fat Linux goodies underneath.
To be clear, I don't want to / don't have time to personally support the non-technical users. I'd just wish there were a better default answer than Gnome.
As a long time Gnome user... Yeah, where did they go wrong?
The upper left "hot corner"? That's a 1990's concept that violates so much.
The weird way everything changes when you hit that corner? I mean really, I want the launcher to be there all the time. And if it is hidden, why should all my windows shrink and rearrange just because I want to launch a different program? And why would the workspace switcher swing in on the right too? It's so jarring and unnecessary. Neat features, poor implementation. And and and....
The upper left "hot corner"? That's a 1990's concept that violates so much.
The weird way everything changes when you hit that corner? I mean really, I want the launcher to be there all the time. And if it is hidden, why should all my windows shrink and rearrange just because I want to launch a different program? And why would the workspace switcher swing in on the right too? It's so jarring and unnecessary. Neat features, poor implementation. And and and....
KDE
Plasma 5 is great
Plasma 5 is great
I learned about the Haiku project in 2009, when I was in college. I was impressed by the community and I'm still a little sad that the hardware we wanted to use for prototyping (a tablet PC) got stuck in customs for a long time, so that we couldn't build the prototype we wanted (based on the Haiku OS).
I'm still very impressed by the community, and I wish you all the best!
I'm still very impressed by the community, and I wish you all the best!
Out of curiosity, does anyone run Haiku full time? I remember seeing a video on it a few years ago, but wasn't sure if it would do everything I wanted.
I used to run BeOS R5 full time for 3 years or so (and only boot to WinXP for games)
A few developers do, and I know of one company that deploys Haiku commercially (TuneTracker: http://tunetrackersystems.com/).
I haven't reached that point myself; I'm still missing WiFi support on my laptop (hence why there's so many commits from me working on that area of the system recently ;) But I'm getting close.
I haven't reached that point myself; I'm still missing WiFi support on my laptop (hence why there's so many commits from me working on that area of the system recently ;) But I'm getting close.
I'm interested in this; how much work is it typically to port a package over?
EDIT: I'm asking specifically a command-line package.
EDIT: I'm asking specifically a command-line package.
Depends on the package. CLI tools that already work both Linux and some *BSD usually are pretty easy to port, often requiring only a small set of patches. GUI tools that use Qt shouldn't be too tricky either (the LibreOffice port is based on the Qt backend.) Other than that, it varies greatly by application.
HaikuPorts (https://github.com/haikuports/haikuports) is what handles the bulk of the work to get applications up and running. I guess the Ninja recipe (https://github.com/haikuports/haikuports/blob/master/dev-uti...) and patchset (https://github.com/haikuports/haikuports/blob/master/dev-uti...) are pretty typical for a CLI app, and the Qupzilla recipe (https://github.com/haikuports/haikuports/blob/master/www-cli...) and patchset (https://github.com/haikuports/haikuports/blob/master/www-cli...) are roughly typical for a Qt app.
If you have some specific application you're trying to port, joining Freenode#haiku and then asking around may be worth your time. :)
HaikuPorts (https://github.com/haikuports/haikuports) is what handles the bulk of the work to get applications up and running. I guess the Ninja recipe (https://github.com/haikuports/haikuports/blob/master/dev-uti...) and patchset (https://github.com/haikuports/haikuports/blob/master/dev-uti...) are pretty typical for a CLI app, and the Qupzilla recipe (https://github.com/haikuports/haikuports/blob/master/www-cli...) and patchset (https://github.com/haikuports/haikuports/blob/master/www-cli...) are roughly typical for a Qt app.
If you have some specific application you're trying to port, joining Freenode#haiku and then asking around may be worth your time. :)
So, I looked into NewOS, the kernel that Haiku is based off of. It hasn't been updated in 10 years (I gather that Haiku's fork has taken most of the attention, so that's neither here or there). That said, I found this amusing:
> The system currently can be built to run on the follwing systems: > Intel IA-32 (x86) - Tested on desktops through 4-way servers > Sega Dreamcast - Hitachi SH-4 > PPC based machines - G3/G4 Macs, Pegasos
Sega Dreamcast!
> The system currently can be built to run on the follwing systems: > Intel IA-32 (x86) - Tested on desktops through 4-way servers > Sega Dreamcast - Hitachi SH-4 > PPC based machines - G3/G4 Macs, Pegasos
Sega Dreamcast!
The author of NewOS is also the key developer behind Google's Fuschia (with Brian Swetland, both ex BeOS engineers).
The SH-4 is actually still supported by mainline GCC
It's still supported by OpenBSD and QNX as well. It's actually not really dead and is moderately popular in embedded systems. Also, the patents are expiring and the http://j-core.org/ project is working on an open-source reimplementation (they've already done SH-2).
All currently produced CASIO graphing calculators have SH4 CPUs.
Almost everything is still supported by mainline GCC. I don't know, it's a weird choice to me, given that BeOS never AFAICT supported Dreamcast either.
The Dreamcast has a pretty big homebrew scene because it was super trivial to run your own code on an unmodded console and it also ran some form of Windows CE. It was probably low-hanging fruit to add it and someone thought it'd be cool, though actually doing testing on the DC will give you a good idea of how much your changes are affecting the performance and resource utilization.
Renesas also still sells SH2/4 chips
https://www.renesas.com/en-us/products/microcontrollers-micr...
https://www.renesas.com/en-us/products/microcontrollers-micr...
This is amazing news!
Somewhat off-topic: does anyone know how to make that BeOS/Haiku window decoration (B Ⅱ) work in KDE5?
https://cn.pling.com/img/hive/content-pre2/5965-2.png
https://discuss.haiku-os.org/uploads/default/original/2X/e/e...
https://cn.pling.com/img/hive/content-pre2/5965-2.png
https://discuss.haiku-os.org/uploads/default/original/2X/e/e...
I don't know about KWin, but there is a BeOS-like XFCE theme [1] so you might be able to swap KWin with XFWM and use that.
[1] https://i.imgur.com/emP3Jk4.png (not my shot)
[1] https://i.imgur.com/emP3Jk4.png (not my shot)
