I am always in awe of these guys just for the sheer dedication. This is what, 12 years? And at least as far as I've seen they've been consistently active through it or at least it's never seemed dead. Yet they're still a good chunk away from an initial release milestone. I remember some folks used to rave about BeOS that's seldom been matched, but daaamn it had to have really been something to keep people going 12 years and several more to ship.
I wonder who owns the intellectual property rights these days, or if there is something unsolvable about the licensed components. I know Jean-Louis Gassée is a notorious asshole at times, but it really seems like somebody should just give the code to these guys. It's not like they're ever going to market it again.
AFAIK, the intellectual property rights are owned by a Japanese company called Access.
The IP isn't needed anymore. There's only one key feature holding back the first beta release, and that's a stable set of package management tools. Every other key component is in place.
It's absolutely bizarre that the developers have adopted the Linux idea of package management, including shared library dependency hell that requires maintaining the dependency graph in lockstep.
You only need a traditional UNIX package manager if you have traditional UNIX packages -- splatting files all over the file system, providing unstable ABI/API, etc.
The OS is basically ready to release now, and instead of focusing on polish, they're bringing over one of the worst features of Linux. You'd think they'd at least borrow from the modern app store idea of "packages".
They're actually implementing package management as a paid project. I'm seriously annoyed that my donation to Haiku is being spent on that, rather than on things that would actually matter to existing desktop users coming from Mac OS X. It seems that Haiku has floundered, largely due to the take-over of Linux-centric developers after the original project leader (Michael Phipps) left in 2009. Michael kept the project very focused on BeOS R1, and now it's all over the map and pulling in the very ideas from Linux that BeOS and MacOS were built in opposition to.
> The OS is basically ready to release now, and instead of focusing on polish, they're bringing over one of the worst features of Linux.
Frankly, I've always thought of package managers (both at the OS and library / dependency level) to be among my favorite features in any ecosystem, be it Arch, Ubuntu, Ruby or Node.js. Even in a world where spatting files all over the system, managing complex PATH variables & dependency graphs is unnecessary, some manner of centralized package manager / installer has a very real place.
Even something as fairly straightforward as pulling down a set of binaries can be made simpler when handled by a package manager, and doubly so when compiling from source. Futzing around with make files is certainly very, very low on my to-do list.
It's possible I'm missing something fundamental, here, in which case please help me out. What is your ideal-world vision of how an OS should handle installing & managing binaries & dependencies?
> It's possible I'm missing something fundamental, here, in which case please help me out. What is your ideal-world vision of how an OS should handle installing & managing binaries & dependencies?
Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day.
This doesn't work for software build/distributed via the UNIX model, but that's the whole point -- if you don't use the UNIX approach to distributing end-user software, you don't create a problem that requires a package manager to solve.
> Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day.
So, that's obviously the approach Apple's taken, and it has numerous strengths. "Installing" & removing .app files is quite simple, but that's of course not the whole story. Both application support files as well as (IIRC) cache files linger around the OS until removed manually. This is typically NBD (well, no huge deal), but it deserves mention. Managing remnant traces of .app files requires either manually navigating the OS and deleting files, or using 3rd party apps. It's worth noting that these 3rd party apps basically do what package managers do, except only at the uninstall stage.
More importantly, when I use OSX, I most certainly am also variously using brew & make to install various pieces of software not packaged as .app binaries. While in a somewhat ideal world it's possible to envision a scenario where all necessary binaries for a given OS are neatly packaged in a preferred format, that seems unrealistic. If I'm still, in 2013, installing really standard tools with a Linux-style package manager on OSX, it's safe to say there's no way I could expect all my requisite applications to be available for a nascent OS with a fraction of its userbase like Haiku.
Lastly, even assuming all binaries that could possibly be executed on a given system are packaged as .app file (equivalents), I frankly wouldn't mind having a package manager available to install (copy), manage, organize & remove my binaries (including support files). A package manager is a ultimately a tool of convenience, it's simply more convenient when dealing with a more classical *nix path / dependency model.
> This is typically NBD (well, no huge deal), but it deserves mention. Managing remnant traces of .app files requires either manually navigating the OS and deleting files, or using 3rd party apps.
Apple has moved to solve this problem in iOS (and the Mac App Store) by maintaining per-app metadata directories. I think this is ideal, and it's not necessary to attach it to the app store model.
> More importantly, when I use OSX, I most certainly am also variously using brew & make to install various pieces of software not packaged as .app binaries.
Yes, UNIX software.
> Lastly, even assuming all binaries that could possibly be executed on a given system are packaged as .app file (equivalents), I frankly wouldn't mind having a package manager available to install (copy), manage, organize & remove my binaries (including support files).
That's what the file system is on a system that manages applications sanely.
There is one good thing in UNIX shared library + package management model: security updates. You don't have to depend on some weird ISV to update his own copy of buggy openssl code in his own "app" in the Unix world. Good for sysadmins. Inconvenient for users. Doh.
The solution is to provide sufficiently broad set of tightly integrated base system libraries; there are few, if any, duplicate dependencies across most applications.
To use OpenSSL as an example, on OS X applications all make use of SecureTransport and CommonCrypto. This brings other advantages, such as automatic integration with keychain-managed certificates and certificate authorities.
> Drag (anywhere) to install. Drag to the trash remove.
Either not have shared libraries at all, and lose when someone finds a bug in something and you have to reinstall everything to get the fix in everything, or have shared libraries that you have to manage by hand because your system lacks dependency tracking. (Your libraries probably aren't versioned, either, so welcome to 1990s-era DLL Hell.)
A peer commentator already mentioned this. I already explained:
The solution is to provide sufficiently broad set of tightly integrated base system libraries; there are few, if any, duplicate dependencies across most applications.
The advantage is that you have broad, comprehensive, consistent libraries that integrate with the base system, rather than a mash-up of inconsistent library interfaces and shell scripts -- for example, see how Linux distributions manage OpenSSL and certificate authorities, versus how OS X and Windows both integrate their crypto libraries into the system certificate stores and UIs.
> The solution is to provide sufficiently broad set of tightly integrated base system libraries
So... when you find a bug in one, the only thing to do is an OS upgrade?
And what about new APIs that come along? Will third-party libraries exist at all, or will users have to wait for an OS upgrade to have applications that can take advantage of them?
> So... when you find a bug in one, the only thing to do is an OS upgrade?
Yes. Which, ideally, is cheap and easy to do.
> And what about new APIs that come along? Will third-party libraries exist at all, or will users have to wait for an OS upgrade to have applications that can take advantage of them?
We can see how this works today. Third-party libraries exist, application authors benefit from being able to version them at-will (and not be tied to the same version everybody else uses), and if anything grows sufficiently popular/necessary/duplicated, the functionality can be integrated into the OS (an occurrence of which there are numerous examples).
It might be true on a OS that lacks a good file notification API. Haiku on the other hand has a very good notification system, so the package manager will step in and take care of unpacking, mounting, managing and download dependencies. Same for uninstalling.
Package management will make OS upgrades easier.
Dependencies as opposed to static linking will allow the CPU to run and cache used code better instead of reading and discarding the same code from different parts of memory.
Compression will make the handling less IO bound and a bit more CPU intensive, but disks are slow and CPU's are faaaast!
If you think it will be slow and complicated, I think you will be in for a pleasant surprise later on.
> Package management will make OS upgrades easier.
You don't need a UNIX package manager for this. See also: every modern OS, ever.
> Dependencies as opposed to static linking will allow the CPU to run and cache used code better instead of reading and discarding the same code from different parts of memory.
You achieve this by having comprehensive base system libraries. See also Android, Mac OS X, iOS.
> Compression will make the handling less IO bound and a bit more CPU intensive, but disks are slow and CPU's are faaaast!
This doesn't need to exist in the package manager. See also HFS+ compression. Bonus: it works without hauling in a huge packaging system.
> If you think it will be slow and complicated, I think you will be in for a pleasant surprise later on.
No, I'll be in for dealing with OSS dependency hell (except that now I can be assured that I'll never use Haiku, because they're actively working to throw away what made the Mac and BeOS designs of that era attractive to begin with, and what they spent 10 years trying to achieve).
It's actually embarrassing that Haiku came so far, only to lose sight of the BeOS R5 target, actively destroying what made BeOS interesting compared to Linux -- especially when modern examples of how to do it right (Android, iOS, Mac OS X) are right in front of them.
This is what happens when Linux kernel engineers wind up in charge of a consumer OS project.
I'm familiar with the proposal -- it has all the same problems of Linux package managers, but then they bolted on an even more complex, error prone, and high-overhead virtual file system to present different views of the package graph.
The problem is the legacy UNIX practice of splatting files all over the drive and having an unstable dependency graph. Fix that, and you don't need a UNIX package manager.
High-overhead based on what, the compressed packages? I'm guessing you're a fan of the OSX .dmg approach... which also supports file compression.
The 'unstable dependency graph' is anything but, instead it's quite straightforward to manage. To explain, think of PATH variables in most modern operating systems. You have a bunch of paths to folders that state where to find your applications, libraries, image assets, etc... Programs that rely on dependencies search through these folders for what they need. This also allows flexibility for file system layout, as you can add additional 'watched folders'. Furthermore, you don't need to install or uninstall a program in the same way, so this 'splatting files all over the drive' can also be avoided.
> High-overhead based on what, the compressed packages? I'm guessing you're a fan of the OSX .dmg approach... which also supports file compression.
DMG is an archive distribution format. The packaging pseudo-filesystem is going to be sitting between the user/kernel, interdicted through a file, and then through a file system, for all access to all installed software.
Think FUSE.
> The 'unstable dependency graph' is anything but, instead it's quite straightforward to manage. To explain, think of PATH variables in most modern operating systems.
First of all, you just called PATH straight-forward. Try explaining PATH to the average desktop or mobile OS user, and then try explaining why this is better than the App Store or drag-installs.
Second of all, the problem isn't the PATH thing. The problem is a huge dependency graph of non-ABI stable libraries and packages that are comprised of a ton of files splatted over the disk.
If you get rid of the non-ABI-stable libraries, and don't splat your files everywhere, you don't need some crazy pseudofs-based package manager to manage your software.
Problem solved. No package management (in the Linux sense) required. Isn't it a good thing to remove unneeded, reducible complexity?
>The packaging pseudo-filesystem is going to be sitting between the user/kernel, interdicted through a file, and then through a file system, for all access to all installed software.
A pseudo-filesystem is not high-overhead, unless you believe symlinks and pointers are high-overhead.
>First of all, you just called PATH straight-forward. Try explaining PATH to the average desktop or mobile OS user, and then try explaining why this is better than the App Store or drag-installs.
Here's the thing: an 'average user' doesn't care about 'a ton of files splatted over the disk' either. How many Windows users bother even looking in the Windows directory or Program Files directory? The 'a ton of files splatted over the disk' issue is only an issue for power users, who like to feel in complete control of their system.
As for App Stores, they're just like a traditional package manager but with a simpler UI and the option to buy software before downloading it. If you're familiar with Ubuntu, compare Synaptic with the Ubuntu Software Centre? See a difference beyond the cosmetic layer? Now compare the Ubuntu Software Centre with the Apple App Store, can you see a difference beyond the cosmetic layer?
I've got a strong feeling of déjà-vu discussing this, are you a Haiku-OS.org forum member?
> A pseudo-filesystem is not high-overhead, unless you believe symlinks and pointers are high-overhead.
Retrieving data from multiple on-disk compressed package archives and presenting them as a union pseudofs is a heck of a lot more overhead than hitting the file system directly.
> As for App Stores, they're just like a traditional package manager but with a simpler UI and the option to buy software before downloading it.
Actually, they're nothing like a traditional UNIX package manager, because they don't handle dependencies. They're application bundles (ala Mac OS X) with a store front-end.
The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all.
It's really depressing to see Haiku come so close to completion, only to have project direction taken over at the very end by Linux developers (literally, that's their day job), who are bringing Linux ideals to a system that was originally built as a successor to the original Mac OS.
>Retrieving data from multiple on-disk compressed package archives and presenting them as a union pseudofs is a heck of a lot more overhead than hitting the file system directly.
It's really not. Imagine a file system where all the "real" file locations are hidden, and the visible file structure just symlinks to these "real" locations. Practically no overhead at all. There will be a minor performance hit with uncompressing files before starting a program, but that's about all.
> Actually, they're nothing like a traditional UNIX package manager, because they don't handle dependencies. They're application bundles (ala Mac OS X) with a store front-end.
My point was in terms of usability. The average user does not care about dependencies, nor do they need to care about them, even when using a package manager.
> The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all.
That only works when all applications are written using those standard libraries, and that doesn't always happen, even on OSX. Why punish software developers for wanting to use libraries that better suit their needs?
>a system that was originally built as a successor to the original Mac OS.
The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted, but when it came to OS design they took ideas from many places, not just MacOS. As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past.
> It's really not. Imagine a file system where all the "real" file locations are hidden, and the visible file structure just symlinks to these "real" locations. Practically no overhead at all. There will be a minor performance hit with uncompressing files before starting a program, but that's about all.
Are we talking about the same thing? It's a:
- pseudofs
- in userspace (IIRC)
- which parses multiple archive files
- and vends their contents as unionfs
If this bought you anything at all useful, then maybe it would be worth all the complexity involved ... but it doesn't.
> That only works when all applications are written using those standard libraries, and that doesn't always happen, even on OSX. Why punish software developers for wanting to use libraries that better suit their needs?
It's not punishing developers. I've shipped software for Mac OS, Mac OS X and iOS for 15+ years, and believe me, being able to ship custom versions of libraries without having to deal with a package manager, library incompatibilities across applications, et, al, is an advantage.
> The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted ...
Led by ex-Mac people, including the former CEO of Apple. Targeted at the BeBox (PPC) and PPC Macs. Shopped to Apple for purchase. It was intended to be the successor to MacOS that Copland wasn't.
> As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past.
Then maybe the new Haiku leadership should stop blindly copying what they're familiar with from Linux.
Admittedly I stopped following the development of Haiku and other alt operating systems over a year ago, so I couldn't say for sure whether the file system is in userspace. Doesn't seem like a good idea in the long run, hopefully it's just a temporary measure.
> being able to ship custom versions of libraries without having to deal with a package manager, library incompatibilities across applications, et, al, is an advantage.
But it's not always an advantage. Library duplication has a cost in terms of storage, plus the mechanism for program upgrades is clunkier than package managers allow (essentially either you have to download the full version of each program update or programs are bundled with their own package management mechanism, duplicating effort).
> Led by ex-Mac people, including the former CEO of Apple. Targeted at the BeBox (PPC) and PPC Macs. Shopped to Apple for purchase. It was intended to be the successor to MacOS that Copland wasn't.
Jean-Louis Gassée was a senior member at Apple, but never the CEO. BeOS was targetted at BeBox (their own machine) at first, then when that platform didn't take off it was targetted at PPC Macs, then x86 PCs. The purchase talks happened because the OS was struggling to gain market share.
> Then maybe the new Haiku leadership should stop blindly copying what they're familiar with from Linux.
As I said before, the design is quite different from Linux package managers, so Haiku are doing things their way.
All your criticism can be summed up by "it doesn't look like a Mac, therefore it's the wrong approach".
Haiku is not a Mac. It's not Linux either, but, from a computer management perspective, tools like ports and yum solve many problems Macs also have. It's no coincidence each and every developer in my office who use a Mac also has either ports or brew installed. Dragging .app folders into icons does not solve every software management issue.
If you need to keep your machine in a known and repeatable state, dragging icons will not take you far.
What you're really saying is "I disagree with you, but I'm going to take a rhetorical roundabout in which I attempt to disqualify your argument by calling it 'not helpful'"
> All your criticism can be summed up by "it doesn't look like a Mac, therefore it's the wrong approach".
No, my criticism can be summed up like so: If you create unnecessary, reducible complexity, then add even more complexity on top of that to manage it, you're doing it wrong.
> It's no coincidence each and every developer in my office who use a Mac also has either ports or brew installed.
You're right. It's not.
First of all, note what you said: every developer.
Second of all, note what they're installing: UNIX software. UNIX software is a distribution mess, and it requires a UNIX package manager. If you don't create the mess in the first place, you don't need a package manager to manage it.
Let third-party packaging systems deal with the UNIX packaging mess, and let engineers who need that software deal with the package managers needed to manage it.
Net result: Your users (which includes engineers when they don't have their software development hat on) don't have to deal with the package management disaster unless they need to deal with UNIX software.
> If you create unnecessary, reducible complexity, then add even more complexity on top of that to manage it, you're doing it wrong.
I believe the fact nobody has been able to reduce the "reducible" complexity you point out for the past 40 years is telling. And no, the NeXT .app folder thing does not reduce it - it replaces the shared library "problem" with other problems (security and just plain malfunction) through obsolete duplicate libraries that may or may not get updated by someone other than the packager.
> First of all, note what you said: every developer.
I'm sorry, but I don't think BeOS was ever aimed at someone other than developers. It would be quite surprising if Haiku were aimed at a different public.
Again, I fail to see your problem with package management. My mother uses a Linux machine and the only contact with package managers she has is the auto-update feature - and her machine is working for 4 straight years without a full reinstall, which is more than most other OSs can say about machines that are not actively managed by someone knowledgeable. I manage dozens of Linux machines and I never experienced the package management disasters you describe.
Maybe you should get some first hand experience and, dare I say, read the manual. If you experience a significantly larger number of disasters than your peers, the problem is most likely not the tooling.
So you're saying that Mac OS, Mac OS X, Android, and iOS are all broken? And Linux's software distribution mechanism is working for end users?
> I'm sorry, but I don't think BeOS was ever aimed at someone other than developers. It would be quite surprising if Haiku were aimed at a different public.
The involvement of former Apple employees, targeting Macs, the attempted sale to Apple, the single-user OS, the UI riffing off MacOS, the focus on media, the simple UI -- those we're all flukes? It was actually meant to be a difficult to use Linux clone that focused on shipping packaged UNIX software, despite its particularly weak posix compatibility and complete non-standard directory layout?
I was hacking on BeOS since DR2. I have friends who worked there. It was contemporary with my career, and I was following Apple's and Be's parallel efforts closely. It was, as far as my knowledge and experience goes, a user-focused operating system ala MacOS.
> Maybe you should get some first hand experience and, dare I say, read the manual. If you experience a significantly larger number of disasters than your peers, the problem is most likely not the tooling.
Many years ago, I wrote one one of the package managers in wide use today. Then I spent years shipping software for multiple platforms. I think I understand the trade-offs, and implementing package management only made the underlying failure of the Linux package manager model more clear.
What kind of ridiculous system requires an army of volunteers to maintain a graph of dependencies in lockstep, making it nearly impossible for 3rd party developers to directly release simple binaries that work across their user's systems. Instead we have to add Chrome package repos to our Ubuntu installations that break across major releases.
It's stupid. There are better ways, which are evidenced by the fact that they're working, today, and have been working for some 20 odd years, and are being further defined in the AppStore model.
Maybe you should stop being so selfish by trying to force your inexperience and UNIX sysadmin use case on everyone.
> So you're saying that Mac OS, Mac OS X, Android, and iOS are all broken?
No. I said they solve some problems and don't solve others.
> And Linux's software distribution mechanism is working for end users?
I am yet to meet a non-technical Linux user who has experienced what could be described as "package management disaster". Software management is mostly automated for their use cases.
> Maybe you should stop being so selfish by trying to force your inexperience and UNIX sysadmin use case on everyone.
I solve my problems, you solve yours. Deal with it.
I can report the opposite - I've had to assist a fedora user when yum/rpm left them in a state that prevented a ton of new packages from being installed due to an interaction between the official fedora repos and rpm fusion, the repo everyone tells you to add to fedora to get video drivers and codecs etc. It was actually quite complicated to resolve as packages relying on specific libraries that were being held back had to be identified, removed, external repo removed, libs updated, packages readded, repo readded.
All it took to get him in that state was copying a pasting a few lines thats suggested on every fedora forum, and a few unwise version dependencies in some official packages, and an external repo that falls behind the official one a fair amount.
That is not a description of a well working system. And casuals frequently end up with tons of held back packages with apt because of not using dist-upgrade.
I'm a heavy linux user and happily deploy it all the time, but to suggest that current package management needs no improvement is insanity. It's a highly advanced system of bandaids for decades worth of iterative engineering on a core design that predated shared libraries, CVE's and when update cycles were well longer than a year.
A clean slate design would be an infinite improvement - it's just a crazy difficult problem without it basically being a new platform and requiring modifications to the 3rd party code that you're installing.
For every problem, how many times did package management work flawlessly?
> All it took to get him in that state was copying a pasting a few lines thats suggested on every fedora forum
So, the user tried to somehow bypass the official distro package management. If you open up your microwave oven and electrocute yourself, is that because of a basic flaw of microwave ovens?
> For every problem, how many times did package management work flawlessly?
None. It built a massive teetering edifice of fragile interdependencies that incurs staggering human cost in maintenance, and has almost singlehandedly stood in the way of progress by third-parties that would benefit from working outside that system -- from commercial software vendors to OSS vendors that would prefer to be able to release versions on their own schedule.
If it wasn't for package managers making it possible to maintain fragile dependencies in lockstep, Linux distributions would have been forced to confront simple issues like ABI and API compatibility, third-party distribution, and other basic facets of producing a user-friendly and vendor-friendly OS ... we may have even had a "year of Linux on the desktop" by now.
Instead, we keep throwing humans at the problem of keeping the teetering pile of dependencies operational, largely because of people like you that cargo cult the ideas out of some strange combination of stockholm syndrome and a lack of vision for how things could be better.
Why was anyone was surprised that Google threw away the entire Linux user-space when developing Android?
> So, the user tried to somehow bypass the official distro package management.
... because that's the only way to achieve perfectly reasonable goals as a user.
If I want to install Chrome, guess what it does? It adds an external repository that broke in strange ways when I updated Ubuntu.
> If you open up your microwave oven and electrocute yourself, is that because of a basic flaw of microwave ovens?
Your microwave doesn't refuse to operate unless you only buy food that has been prepackaged by your microwave vendor, that can only be mixed with other food also repackaged by that vendor, and only if all the food has been pre-certified to work together in that exact combination.
For every problem, how many times did package management work flawlessly?
Fedora systems often enter states where manual intervention with the package system is necessary to fix and issue preventing updates, they're usually just much simpler. And upgrading from major release to major release very commonly results in orphans or zombies. At least until the most recent release, the official instructions for resolving live upgrade issues involved 2-3 reboots and manual management of the package database in single user mode.
So, the user tried to somehow bypass the official distro package management. If you open up your microwave oven and electrocute yourself, is that because of a basic flaw of microwave ovens?
No, it's the expected behavior of many fedora users and common among developers. Fedora has a zero tolerance policy on binary blobs and anything potentially ip encumbered. This is their arms length provider of such, and the official packagers will direct you there if you look to get your software included in the main repos but they have concerns about patent coverage.
They rely on the use of that repo so much that they actually first shipped gnome 3 with the open source nvidia driver they shipped with blacklisted because of how bad it was, and instructed nvidia users to install the proprietary drivers to get a working system.
> No. I said they solve some problems and don't solve others.
Yes, they don't solve the problem of distributing messy UNIX software with complex and unstable dependency graphs, written for systems with anemic base libraries, that install a litter of files all over your system.
That's a good thing. In fact, I'd say the world would be a better place if we'd never implemented package managers and instead UNIXes were finally forced to clean up their mess. The real world doesn't work that way, so instead the best we can do is create new systems that don't inherit the mistakes of the old.
> I am yet to meet a non-technical Linux user who has experienced what could be described as "package management disaster". Software management is mostly automated for their use cases.
Use cases like, say, trying a new piece of software that hasn't been packaged?
Getting updates directly from the vendor?
Being able to have their vendor-supplied applications continue to work across major OS releases?
Or how about from the vendor perspective, where we have to deal with mistake-prone volunteers packaging up our software, inconsistent and incompatible libraries and an ever-shifting dependency graph. The only reason anything ever works at all is because there are hundreds/thousands of people whose sole contribution is to keep the entire dependency graph afloat. Just how many human hours do you think are spent on software packaging overhead?
> I solve my problems, you solve yours. Deal with it.
Thanks for elucidating exactly why Linux developed shouldn't be anywhere near the design process for consumer software like an OS.
You're projecting your view of Linux package management onto Haiku, when the situation with Haiku is going to be pretty different.
For starters, let's start with libraries. To use a concrete example, let's say the Cairo vector graphics library. What happens when a program requires Cairo 1.12.14? The library package gets downloaded. What happens when a second program requires Cairo 1.12.13 (i.e. the previous version)? The library gets stored alongside the newer version, so both are available. What happens when a program has forked Cairo, and requires that version? Hopefully the answer is clear.
So in this example we have three versions of Cairo. Seems inefficient right? In some ways it is, but efficiencies can emerge when programs do target the same version of Cairo on our system, as the library will already be ready for new programs to use.
It's also important to realise in what ways having these three libraries is inefficient. The only real issue here is storage, as we'd probably be looking at three times the storage space for the Cairo functionality. However, as inefficient as this is, it's still more efficient (from a storage point of view) than each application bundling its own libraries, as with installing the libraries separately there's at least a chance of the libraries being shared.
There is an alternative, which is to specify library versions that developers should use and bundle these with the system. This has advantages and disadvantages. The advantage is that the functionality available to you is easier to scope out. The disadvantages are that recommended libraries get updated less frequently, so if you wish to use a new version you're either forced to wait or bundle your own library, which brings you back to the inefficiencies you had before.
Taking time to reflect, I see now that your issue isn't really with package managers per se, but rather that you dislike the 'rolling release' approach of many open-source projects. It's the shifting target that annoys you, how this gets managed is secondary. Would you say that's a fair appraisal?
Completely agree. It seems people who have no problem with Linux package management are bringing over the same problems to what should be a non-programmer-friendly system.
'Non-programmer-friendly' like how MS-DOS was non-programmer-friendly with its memory models and lack of multitasking, or like how AS/400 was non-programmer-friendly with you choice of RPG or COBOL, or do you actually think that making something friendly for non-programmers automatically makes it non-friendly for programmers?
Sorry, I meant user-friendly, where the user is not a programmer. Actually, making a package system friendly for users will make it friendly for a lot of programmers too - who are also users (and don't feel like wrestling with package systems too).
Since you seem rather familiar, I've always wanted to ask what the story with the widgets/theme is. I have nothing but respect for all the work that's been done. But the UI really stands out as distinctively from a very specific era and just doesn't feel very appealing now. So I'm curious what the primary driver is there. Faithful recreation as a core value? Sort of a badge of honor type thing for the BeOS faithful? Lack of ui/ux contributors? Or just lower on the priority list?
I'm not knocking it, rationally i don't have a problem with it, but at the same time i can't imagine i'd be up for using it as a main os.
There have been some refinements made to the UI during the Haiku era (such as Stack and Tile windows and vector icons by default), but has otherwise remained stable. What's the main reason behind that? It's not a priority for R1 (the first stable release). No reason it can evolve in time.
Oh, I don't mean app positions or use patterns or anything like that. I mean toolkit widgets like sliders, buttons, chrome, window manager elements, that kind of thing.
And for the record i feel the exact same way about plain xtk, old style gtk/gnome and probably win2k and earlier if i saw em.
I had to go and look at a bunch of screenshots to come up with an answer besides just the "feel". I think a big part of it is the heavy reliance on thin embossed/3d borders and lines, no rounded or softened elements, the limited palette use in core elements, no rich gradients or transparencies.
I didn't realize it at all until i made the list, but I guess a big part of it is the look of a toolkit/window manager that was built on top of a 3d api and compositor.
I guess the gpu industry norms are a huge barrier for anyone on an alternate path.
It's really both of these. For a long time, the constraint was fidelity with BeOS R5, which kept focus on an achievable goal.
However, there has been some interest in making UX/UI improvements; the problem seems to be that there just isn't much (if any) design/UX expertise in the open source community.
I think you're absolutely right : package management is a symptom of a developper-centric OS. I've packaged several hundreds of apps for Linux and have been using it almost exclusively since 1997. And the least I can say is that it's a bloody unholy mess. The latest joke/failure in Linux is the packaging of TeX on Fedora which uses (if my memory serves me right) over 3,000 packages!
Many developpers just do what they feel like doing and often disregard standards because a lot of them think they know better ( also known as the "not invented here" syndrome ). How many times did I send patches upstream to fix an standards issue ( such as a missing pkgconfig file ) and some arrogant developper who thinks he knows better rejects it. And when someone comes in and tries to consolidate the OS a bit (what the systemd guys are trying to do) a horde of reactionary users start trolling the hell out of them.
As far as Haiku, I think the plan with the package manager is to only use it to update the base OS. Apps would still be installed by unzipping them in an appropriate place. At least I hope so. If not it will be as you say yet another exotic UNIX variant. Unfortunately, there also have been talks of replacing the BeOS API with Qt.
They don't really need the code at this point anymore. They have as much BeOS compatibility as they'd get nowadays... now they're focusing on driver compatibility, porting more recent software to it and finally moving to GCC4 rather than BeOS's GCC2.95, IIRC. Also, more architectures.
While I never used BeOS, and haven't tried Haiku either, I can't help but hope that something not Unix-based* gains some popularity sometime. At lot of the "innovation" happening in desktop OS's today seems incremental. In fact, I'd argue that there's a bit of a monoculture among the various Unix-derivatives that discourages radical changes, for compatibility reasons (which is reasonable). Though I don't think the various Linux distros and BSDs have all that much of a competitive effect on one another, anyway.
Or have we reached a point where OS's aren't that interesting any more?
The problem is that it's seriously hard to improve meaningfully on Unix.
Take a look at Plan 9, for example. Plan 9 (which is not Unix), was meant to be the 'next iteration' of Unix, taking the Unix philosophy to the next level. http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
The reason Plan 9 failed to catch on, despite being strictly better, is because it didn't provide a significant enough improvement.
With non-Unix OSes, you not only face the challenge of providing not just an improvement, but a significant improvement, but you also face the challenge of providing a complete toolset[0] that people have come to expect. Plan 9 mostly failed in this regard, despite not even deviating that much from Unix. I can't imagine how much work it would be to do the same 'from scratch'.
[0]Let's not forget that the reason GNU tools (particularly gcc) caught on was precisely because they were able to provide this complete toolchain.
> The problem is that it's seriously hard to improve meaningfully on Unix.
From a more technical perspective, there are a number of things that Unix isn't great at. I'm confining myself here to commonalities between OSX (a BSD) and Linux, as I'm not an OS expert...
* characters for everything
* file abstraction doesn't really work 100% as an abstraction.
* based around C
* huge barrier between code and data.
* abysmal permissions model (read/write/execute/sticky/etc)... SELinux and facls slightly fix this, at the cost of UX.
* monolithic kernel
* interface designed for teletype machines, not graphic displays.
* textual interface mixes control and data planes
* limited APIs for threading/fibers/etc.
There is an old and somewhat out of date book called the Unix Haters Handbook. It's worth a read.
Plan 9 needs to be thought of as a "Unix evolution", not a different OS.
For a perspective on what would be different and possibly better, you will need to look at z/OS, Windows NT, QNX, L4, Wind River, Mac OS <= 9, Genera, and a few of the other more lesser known operating systems.
I was impressed when I discovered z/OS uses a JIT based environment for all user space applications, in a way similar to what Microsoft was trying with Vista, or Google with Android, before the NDK came into the picture.
Having had contact with UNIX when Linux was just a thought for Linus, I surely think there are many more types of operating systems to explore.
UNIX is nice, but not the best of all.
Who knows how things would have turned out to be if Apple had gone BeOS instead of NextStep.
Fantastic, if for nothing other than Dennis Ritchie's "anti-foreword":
"Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy."
"The problem is that it's seriously hard to improve meaningfully on Unix."
It's certainly not seriously hard from a technical perspective, it's relatively easy to design a superior system.
What is trickier is building momentum for a new operating system. Your only real option (unless you have tons of cash like Microsoft or Apple) is to first focus on a niche and build from there. The new OS has to clearly be the best at something, even if it's just one thing, so that usage and software can build.
Yes, thank you for mentioning Plan9, it's a wonderful example of the limits on current OS research.
The arguments you give are spot on, I would only add the need for backwards compatibility, or at least the possibility of maintaining the huge and ever increasing volume of mission-critical systems running Unix (Banking systems, the financial world, the Internet, ...).
However, while it's true that Plan9 failed to catch on, a lot of its ideas have been backported to Unix (/proc anyone?). I think that there's something there. Unix can be improved. But no one is going to look at your improvements if it breaks their existing systems.
To put it another way - any potential future competitor to UNIX will have to include UNIX, via a POSIX compatibility layer.
But that won't be enough, because of all the extensions to POSIX. So you really need a Linux compatibility layer (which we see that FreeBSD, for example, already has).
So, if you want to make a better UNIX, no matter how good your idea is - you have to implement Linux as well, in addition to all your great ideas. At that point, maybe your time would be better spent working on Linux directly.
As has been mentioned in other comments, the idea that Unix was "decades ahead of any other operating system..." is debatable. For an insightful (but obviously biased) account of Unix's history, read the first chapter or two of "The UNIX-HATERS Handbook" (http://web.mit.edu/~simsong/www/ugh.pdf). It was written back in the early 90's by a group of academics who distinctly felt that Unix was too beholden to its late-60's origins, and its' widespread adoption has held back new developments.
With NT4 they moved graphics drivers into the kernel, and these were crashing often. NT3.5 was stable in this regard, although dog slow.
They also added the I/O fastpath in NT4, to combat dog slowness -- and as a result of not thinking hard enough about that, killed the ability to unload storage drivers, which actually mattered to me.
And that's just the design decisions - the implementatin was also abysmal; there were remote exploits published daily in those days, and only half of them were through IE (which had no reason to be bundled into the OS except for MS world domination plans, but as it was and was unremovable, it was a convenient attack vector.
And don't get me started on concurrency bugs that I reported to MS on NT4 and as of Server 2003 were not yet fixed.
Well, I was doing multi-platform C development across all major commercial UNIX vendors and NT on those days, what about you?
> With NT4 they moved graphics drivers into the kernel, and these were crashing often. NT3.5 was stable in this regard, although dog slow.
At least they did work, not the same could be said about Linux and BSD distributions with their open source drivers 10 years ago.
> And that's just the design decisions - the implementatin was also abysmal; there were remote exploits published daily in those days, and only half of them were through IE (which had no reason to be bundled into the OS except for MS world domination plans, but as it was and was unremovable, it was a convenient attack vector.
Windows problems with security were no different than any other desktop operating system before it.
As for being the beloved target for hacking, it happens with every system they see value into cracking, as the increase in mobile malware shows.
> And don't get me started on concurrency bugs that I reported to MS on NT4 and as of Server 2003 were not yet fixed.
Are every single bug fixes you report to open source projects fixed?
> Well, I was doing multi-platform C development across all major commercial UNIX vendors and NT on those days, what about you?
HP-UX and AIX for me, and NT (my colleagues also worked on Netware, but I wasn't involved with it). My experiences are different than yours: we had near-daily BSODs and the system was generally regarded as a bit of a joke.
We worked closely with MS back then (late '90s) and I met some of the kernel team, who told me about the farce of pushing GDI into the kernel - the worst mistake they ever made in terms of stability, though usability-wise it was great. The Windows UI was silky smooth on the limited hardware of the time.
But yeah, in my experience NT defenders were few and far between back then.
> Well, I was doing multi-platform C development across all major commercial UNIX vendors and NT on those days, what about you?
Various Unixes, NT and NetWare 4-6. NetWare was, by far, the ugliest. But NT was really, really bad.
> At least they did work, not the same could be said about Linux and BSD distributions with their open source drivers 10 years ago.
I've been running a Linux desktop on and off since 1994, (last used anything else in 2005) and never had a problem getting X to work. And it wasn't until my latest Lenovo on Ubuntu 10.10 that I had a single crash because of a display driver.
> Windows problems with security were no different than any other desktop operating system before it.
Except NT4 was supposedly a server OS. It was bearable as a desktop OS thanks to moving GDI into the kernel, but just barely.
> As for being the beloved target for hacking, it happens with every system they see value into cracking, as the increase in mobile malware shows.
This is so wrong I won't even try to correct you.
> Are every single bug fixes you report to open source projects fixed?
About 10 for each one I report to a closed source project, and that's been the experience of everyone I know.
Certainly 10 years ago and debatably 15 years ago Linux already had graphical installers and more comprehensive out of the box drivers (in certain distros) than Windows. Mandrake, RedHat, SuSe were all very user friendly around the turn of the century.
BSDs took a little more work, but were relatively friendly to install and worked on a wide variety of hardware around that time as well.
BeOS had some extremely interesting concepts, and I'd love to see Haiku gain some traction.
I'm not sure whether or not to call it Unix-based, though. It certainly isn't based on any known Unix code-wise: it's not even written in C. But it does retain a Unix-like command line, and you can even get much of the GNU toolset for it.
Why was my previous comment modded down? Haiku is no more Unix-based than Windows, i.e. they both have support for POSIX, but that's about it. BeOS was designed to leave behind the cruft from older systems, not build upon it.
I remember being completely blown away back in the 90s when I installed BeOS on a Pentium - on Windows 9X the machine struggled to play a single RealPlayer video, whereas under BeOS I could run 30 or 40 videos simultaneously with each window bouncing around automatically - and the sound had zero glitches(must have been some kind of demo?) Also you could put up to 6 live videos on the faces of a rotating cube, which was even more amazing at the time.
My wow moment with BeOS came when ripping a cd under the os. The process took forever on any program I tried on windows. On beos the entire cd was burned in the time it would take to process a single track on windows.
It was an impressive little OS. It's shame it did not manage to go mainstream.
I've been monitoring this for years, what's changed recently? I'd be looking for some web development options, ruby, python, console, vim, before i use it a on a daily basis.
Recently: x64 support, Bluetooth support, WiFi improvements, and a package manager and porting tools.
In answer to your questions: Python definitely works just fine on it, as do Vim and the terminal emulator. I have no idea about Ruby, but I'd be surprised if it didn't work.
That said, what'll bite you is the lack of browser support. There are actually good browsers, mind, but you don't have your usual Firefox/Chrome duopoly fully available. There's also no virtualization support. While I don't know what your web dev workflow looks like, mine needs at least something along the lines of LXC/FreeBSD jails for me to actually get stuff done.
I just want to say, this is such an amazing HN thread. No snark, no one trying to feel superior. Just pure excitement over something that (at this point) is no where near having a serious impact. Just the joy of pre-smartphone nerdery.
Best of all, an incredible amount of information. I know nothing of this low-level system stuff, yet i cant stop reading.
I like Haiku OS very much :)... Last year, I tried using it as my primary OS for a couple of weeks but it didn't work very well. It's not productive enough (for me) yet.
But I will certainly try it again in the near future because I like very much switching my OS every now and then. And I definitely recommend it for any advanced user to try it out. =)
I was initially skeptical and thought this would be another pet open source project without direction, a viable target market, or good design sense, but after checking this out I was proved very wrong on all counts.
This is amazing. The people behind this seem to really know what they're doing. The operating system's interface design and that of its default applications are better than anything offered on Linux [0]. I'm also really impressed with the fact that there is One True environment and toolkit which is integrated into the OS, which, compared to the Linux desktop, should decrease development time while increasing the consistency and overall quality of the user experience. And it has bash!
I thought Linux Mint with Cinnamon was great, but I'm strongly considering dropping it and using this as my primary OS.
I've enjoyed the discussion above, so I think it was a worthy submission. I guess I don't really understand why people are bothered by someone getting those priceless karma points even if it is a repost.
I think most people don't care about karma farmers, but I think you'll agree that karma farmers' submissions often increase the noise rather than the signal.
Do we draw a line? Is there a knowledge baseline expected on HN, or would a submission of the Wikipedia article on bubble sort be fair game? I mean, I've seen links to two generals' problem on Wikipedia getting voted up.
Sort of tangential, but I'd be interested in seeing an OS based on Go, where Go::Go-OS as C::Unix. (And you could call it "Goose".) Given Go's awesome features, I would imagine it could be pretty interesting.
What could you get from an OS written in Go that an OS written in C doesn't already provide? If you were writing a new OS then it might be easier to write it mostly in Go, but I don't think there is any kind of fundamental difference like there is between Linux and Squeak or a Lisp Machine.
If /usr/include were dropped and /usr/lib only contained Go packages, then you'd have an ecosystem where library namespaces are handled in a scalable way--that's a pretty big deal. You'd be working in a statically linked environment rather than a dynamically linked environment--another major change. Garbage collection for everything in user space. Potentially, the removal of select/poll? Drastic increase in memory safety (buffer overruns, etc).
Based on the package naming, dependency management, and concurrency, it might even be argued that a Go user space is a bigger fundamental change than a Smalltalk or Lisp user space.
Btw, one probably wouldn't write a kernel in Go so I take the parent to be speculating about a system where new OS features were provided by integrating them first into a Go standard library rather than by integrating them into the C standard libraries.
Most of these things don't sound like they need OS support. Just writing Go libraries and using Go alongside the existing system can provide a statically linked environment, no need for the application write to use select/poll or worry about memory safety, and garbage collection. It doesn't have to be "Go all the way down" since you won't be modifying your environment at runtime.
Haiku is built on object-oriented principles, so the question is really whether you consider C++ as used in the project to be modular and simple. The API is pretty clever, mostly built on implicit threading and message passing. I consider it a pretty decent API, so I would say yes. The existence of replicants is a pretty compelling demonstration of the flexibility it affords: any view can be marked as "replicable" and then copied onto the desktop or any other replicant target.
Now, because data is exchanged almost exclusively using BMessages and everything is C++, if you're using C++ it's highly modular. If your definition of modularity and simplicity implies Unix processes passing plain text between them using pipes, you probably won't find it all that inspiring. My knowledge is all vintage BeOS R4 so I don't know whether Haiku is more multilingual today; I'd guess probably so, but if not, that would be a detriment since I'm not overly fond of C++ and wouldn't consider it "simple."
I would say that it was a key concept in BeOS and still is in Haiku. Haiku development actually started by replacing one module at a time in BeOS so several userland modules were actually working before there even was a bootable kernel.
I wonder who owns the intellectual property rights these days, or if there is something unsolvable about the licensed components. I know Jean-Louis Gassée is a notorious asshole at times, but it really seems like somebody should just give the code to these guys. It's not like they're ever going to market it again.