Haiku booting in UEFI mode(haiku-os.org)
haiku-os.org
Haiku booting in UEFI mode
https://www.haiku-os.org/blog/jessicah/2016-12-15_uefi_progress_update
99 comments
That only means one person was able to implement hardware video decoding while others didnt, nothing to do with OS itself.
Actually, Haiku doesn't have any hardware video decoding. It's all software.
That sounds miles slower.
You're missing the point entirely, it could be done in hardware (I'm sure they would be happy with a PR) - but Haiku can do stuff in software that other OSes simply can't; media is just one of the better demos. It follows very strongly from the BeOS demos from the mid 90s[1].
[1]: https://m.youtube.com/watch?v=BsVydyC8ZGQ
[1]: https://m.youtube.com/watch?v=BsVydyC8ZGQ
Most of us get your point, I'm sure. :-) Some people just go against everything in their comments.
To me this sounds unlikely. The CPU will spend all its time in codec library code here so how much of a role will the OS get to play? More likely the difference is coming from some departure from fairness in how the software codec was compiled
I have Haiku running on an old Pentium 4 laptop. It's definitely worth a look! Just a few notes after booting it up just now:
* Connected to my site via TLSv1.2/ECDHE-ECDSA-AES256-GCM-SHA384
* Played a Youtube video just fine
* Was able to git and build libsodium, via the installed gcc 2.95.3
* wget'd an h.264 mp4 file and watched it via MediaPlayer
* OpenSSH 7.1 (newer Haiku ISOs may include a more recent release)
The default build of Haiku is dual-GCC, you can switch to GCC5 by typing "setarch x86" in any shell.
And the security model can't be helped if we want to maintain binary compatibility with BeOS - once we (mostly) drop that, we'll switch to something more sane in that department.
And the security model can't be helped if we want to maintain binary compatibility with BeOS - once we (mostly) drop that, we'll switch to something more sane in that department.
> you can switch to GCC5 by typing "setarch x86" in any shell
Awesome, that worked. Thanks!
It's also great to hear that Haiku will eventually improve the security model. That is its biggest weakness IMO, and removing it will open a lot of new doors.
Awesome, that worked. Thanks!
It's also great to hear that Haiku will eventually improve the security model. That is its biggest weakness IMO, and removing it will open a lot of new doors.
How long do you expect to maintain BeOS binary compatibility? I see in the trac roadmap that R2 is slated to be the deprecation point; is that still likely to be multiple years away? Has there been talk of an abi compatibility layer that would allow the kernel to move forward independently from the legacy platform?
Sorry if these are repetitive questions btw. I'm just curious.
Sorry if these are repetitive questions btw. I'm just curious.
Exactly how long is unclear; however, post-R1, we intend to stop prioritizing it, and if it does stay around, it'll be secondary to continued development. There's been serious talk of actually branching R1beta1 on January 31, so, hopefully soon.
The kernel already has moved pretty far forward. BeOS audio drivers, for instance, don't really work anymore in favor of our new multi-audio API (I don't think anyone had any use for BeOS audio drivers; we merged all the open-source ones, I think), the VFS layer has gotten major upgrades, we rewrote the thread scheduler and removed the 8-core limit we inherited from BeOS, and already have added ASLR and DEP support, among lots of other improvements. I think the only thing at this point which actually is still compatible kernel-wise are FS drivers (sorta) and graphics drivers (although of these, we have more in-tree than BeOS ever did, so I don't know if anyone even uses old BeOS ones anymore).
The kernel already has moved pretty far forward. BeOS audio drivers, for instance, don't really work anymore in favor of our new multi-audio API (I don't think anyone had any use for BeOS audio drivers; we merged all the open-source ones, I think), the VFS layer has gotten major upgrades, we rewrote the thread scheduler and removed the 8-core limit we inherited from BeOS, and already have added ASLR and DEP support, among lots of other improvements. I think the only thing at this point which actually is still compatible kernel-wise are FS drivers (sorta) and graphics drivers (although of these, we have more in-tree than BeOS ever did, so I don't know if anyone even uses old BeOS ones anymore).
64-bit Haiku would maybe be a good opportunity to fix the security model, but I've no idea how feasible that would be.
Not sure why you say that. It already exists, anyway: https://download.haiku-os.org/nightly-images/x86_64/
I say it as I wouldn't expect it to be compatible with 32-bit BeOS.
This is cool to see. I'm a bit sad that the ARM port hasn't made any visible progress - I remember back when the Raspberry Pi came out that there were a few discussions about other hardware being more adequate/future proof, and now that there's a quad core model it would be a great OS to run...
And the Raspberry Pi's GPIO connectors would take us full circle back to the "Geekport" of the original BeBoxen.
The minnowboard has GPIO connectors, and has already managed to boot Haiku in UEFI mode. A bit expensive though.
The ARM port presently boots all the way to the startup screen, but then it halts because it has no way of reading the boot medium, because the USB stack hasn't been ported to ARM. Patches accepted! :)
It would probably help if there was some/better/easier to find documentation on how to get a build going.
What didn't the README and README.Compiling explain adequately enough for you? (And of course, feel free to pop into Freenode#haiku and ask us questions...)
We need more OS diversity. Putting all the eggs in the same basket is too dangerous regarding security. I'm very impressed by the work of the Haiku community.
Yes, putting all our eggs in the "POSIXy, monolithic kernel implemented in C with MMU-isolated processes, ambient authority, shared mutable state concurrency" OS basket feels unwise.
Well, Haiku isn't too different from that anyways. The kernel is very much C++ and not C, and does have certain hybrid tendencies (it's a lot less monolithic and statically linked than Linux is at least), but most drivers still run in kernel space and the process model is very POSIXy, with most of the other attributes you listed, as well...
I have forever felt bitter about Haiku OS, ever since I realized they don't write all their code comments in haiku form.
Sigh, so sad.
Sigh, so sad.
We do, however, have a very nice collection of haikus about Haiku: https://github.com/haiku/haiku/blob/master/data/system/data/... :)
(Although some of those are inaccurate these days - we've had OpenJDK for a few years now, for instance.)
(Although some of those are inaccurate these days - we've had OpenJDK for a few years now, for instance.)
Can't you at least put one haiku in the comments? Somewhere? Anywhere??
And yet you yourself
Refuse to make the effort
To write in haiku.
Refuse to make the effort
To write in haiku.
Amazing! I was not around when BeOS was the thing, but I read a lot about it, and it seemed way ahead of it's time, at least to me from today's standpoint. I play with Haiku from time to time.
Is it ready yet for any real-world use cases? Like torrent station/media server or NAS or internet gateway.
[deleted]
Nice to see its development is continuing.
From the website:-
"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."
"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 BeOS wiki page:
"It has partial POSIX compatibility and access to a command-line interface through Bash, although internally it is not a Unix-derived operating system."
From that and just browsing around, it seems to be a vaguely Unix-ish environment; or at least it has more in common with Unices than the CPM/DOS/Windows or other OS families.
"It has partial POSIX compatibility and access to a command-line interface through Bash, although internally it is not a Unix-derived operating system."
From that and just browsing around, it seems to be a vaguely Unix-ish environment; or at least it has more in common with Unices than the CPM/DOS/Windows or other OS families.
The BeOS kernel is as totally un-UNIX-like as (say) Windows NT/2K/XP/7/8/10, designed from the bottom-up to be “pervasively multi-threaded” at a time when multi-core chips were at least fifteen years away and multi-processor systems were utterly exotic, lacking even the most fundamental UNIX precepts (everything-is-a-file; multi-user environment; GUI mandatory and in-built). It just ‘seems’ UNIX-ish at first glance because it has a POSIX compatibility layer added on top in hindsight (or foresight) to provide a standardised shell and GNU userland utilities, as well as providing the key compiler toolchain (GCC 2-or-3-dot-something, if memory serves).
HAIKU is basically a clean-room reimplementation of the public (and private) framework modules' APIs and as such doesn't even (really) descend from BeOS-proper at all.
(Avid late-1990s BeOS user, dual PowerPC 603e-133 BeBox owner, HAIKU supporter.)
HAIKU is basically a clean-room reimplementation of the public (and private) framework modules' APIs and as such doesn't even (really) descend from BeOS-proper at all.
(Avid late-1990s BeOS user, dual PowerPC 603e-133 BeBox owner, HAIKU supporter.)
> dual PowerPC 603e-133 BeBox owner
That's kind of amazing given how rare those were/are. I definitely can't top that, but I had a dual Pentium III machine that ran R5 (and ZETA for a while, which I had problems with) in the early 2000's. That thing seemed faster than the machines I have today. Good times.
That's kind of amazing given how rare those were/are. I definitely can't top that, but I had a dual Pentium III machine that ran R5 (and ZETA for a while, which I had problems with) in the early 2000's. That thing seemed faster than the machines I have today. Good times.
According to Wikipedia 800 or so were produced, so they're rare but not unheard-of. Mine was a much-desired Christmas present in 1997 when I was 16.
I also had a dual PIII-450 machine (alias “Mad Cow”) that dual-booted Windows NT/2K and BeOS R5 (but sadly only displayed B&W 800x600 due to lack of display-adapter driver support) and consequentially was nigh unusable.
I also had a dual PIII-450 machine (alias “Mad Cow”) that dual-booted Windows NT/2K and BeOS R5 (but sadly only displayed B&W 800x600 due to lack of display-adapter driver support) and consequentially was nigh unusable.
> I also had a dual PIII-450 machine (alias “Mad Cow”)
Did you ever use that machine for BeShare back in the day? Because that name associated with BeOS really stands out in my memory. Or maybe, were you on Usenet back then?
Sorry for the pointed questions, just trying to sort out where I remember you from. I discovered BeOS a few months before they folded, and managed to buy 5.0 Pro while it was still being sold by GoBe. I still have my disc and book to this day along with the BeOS Bible and Be Advanced Topics, and I recently acquired an old Dell P-III system which runs it flawlessly (I just need to round up a PATA hard drive as its original drive died a noisy death a few hours after I powered it up).
Did you ever use that machine for BeShare back in the day? Because that name associated with BeOS really stands out in my memory. Or maybe, were you on Usenet back then?
Sorry for the pointed questions, just trying to sort out where I remember you from. I discovered BeOS a few months before they folded, and managed to buy 5.0 Pro while it was still being sold by GoBe. I still have my disc and book to this day along with the BeOS Bible and Be Advanced Topics, and I recently acquired an old Dell P-III system which runs it flawlessly (I just need to round up a PATA hard drive as its original drive died a noisy death a few hours after I powered it up).
I had been active on BeShare, yes. I probably used the ‘qubex’ username though.
Still got my (66mhz) BeBox here .. turn it on every year just to make sure it still boots (it does) but I never know what to do with it. Sure is fun to see the blinkenlights come up, though ..
If the card was VESA compatible, there were a number of display modes to select in the "safe mode" menu, which you could get to by pressing space on the boot screen.
Same here. Stuff flew on my little Celeron with 64MB of SDRAM. I could do so much stuff in BeOS that my Windows 2000 installation couldn't, like actually play a DVD full screen. I was so sad to see it go, it breathed life into a system everyone else would make fun of.
Hell, the Linux kernel isn't very unix-ish. It's a kernel.
The Linux kernel might not be “very UNIX-ish” but the GNU/Linux integrated system clearly adheres to the basic UNIX philosophy (multi-user, everything-is-a-file, userland shell, non-mandatory non-privileged GUI).
Not all OSes have these same foundational pillars. What I meant to express is that Linux does whereas others (as disjoint as Genera, Windows NT, BeOS Amiga) don't.
Not all OSes have these same foundational pillars. What I meant to express is that Linux does whereas others (as disjoint as Genera, Windows NT, BeOS Amiga) don't.
In that sense the original UNIX kernel was not very unix-ish either. The unix philosophy to a large degree exempts the kernel, as few people will be directly interacting with it during daily usage.
You're referring to /proc and (more recently) /sys I presume. I'm sure you're aware of Plan9 that takes the everything-is-a-file idea to the logical extreme using it as a universal namespace by means of the P9000 (?) protocol (going way off-topic here).
Yes i am aware, and i suspect the Linux devs were in part inspired by that (Linux may even support 9P, iirc).
Plan 9 was pretty much about taking the "everything is a file" thinking to its logical end point. Meaning that you could even manipulate individual GUI windows via the FS.
I was simply musing that Linux may have taken the concept further than the BSDs while still being "unix". I can't say i ever got the impression that Plan 9 was intended to be posix compatible for instance.
Plan 9 was pretty much about taking the "everything is a file" thinking to its logical end point. Meaning that you could even manipulate individual GUI windows via the FS.
I was simply musing that Linux may have taken the concept further than the BSDs while still being "unix". I can't say i ever got the impression that Plan 9 was intended to be posix compatible for instance.
That still doesn't say much. Why would I be interested in this over linux?
The FAQ doesn't even say whats good about it, just that it targets personal computing, which windows and OSX would also say. Ubuntu too, probably.
The FAQ doesn't even say whats good about it, just that it targets personal computing, which windows and OSX would also say. Ubuntu too, probably.
You are probably too young to have tested in the good ol'times the original BeOS.
It was IMHO a "revolution" that - for whatever reasons - never happened.
Don't ask me the actual "technical" details, but it was small, very, very fast, even on the limited hardware of the time:
https://en.wikipedia.org/wiki/BeOS
I have no idea if Haiku is (will be) as faster as it was BeOS at the time (when compared on the same hardware to Windows 9x or NT 4.00) when compared to a "current" Windows or Linux or MacOS, but at the time it blew away any other OS, particularly when it came to browsing the web or for music, video, etc.
It was IMHO a "revolution" that - for whatever reasons - never happened.
Don't ask me the actual "technical" details, but it was small, very, very fast, even on the limited hardware of the time:
https://en.wikipedia.org/wiki/BeOS
I have no idea if Haiku is (will be) as faster as it was BeOS at the time (when compared on the same hardware to Windows 9x or NT 4.00) when compared to a "current" Windows or Linux or MacOS, but at the time it blew away any other OS, particularly when it came to browsing the web or for music, video, etc.
For an illustration of this, see [1]. Keep in mind that this was almost 20 years ago, so the hardware he's running is probably something like a dual-socket Pentium Pro or Pentium II platform with a 66 MHz bus and core clock speeds around 10% of what we see on modern processors, and nothing like a modern GPU (I'd guess that the graphics hardware has accelerated blitting and an overlay for the live video input, though; it's unlikely that software is pushing every pixel in that demo).
[1] https://youtu.be/BsVydyC8ZGQ?t=965
[1] https://youtu.be/BsVydyC8ZGQ?t=965
For reference, Win 98 (and Linux of the same vintage) used to stutter and pop on MP3 playback when you'd load a (mostly plain html back then) webpage.
Windows 7 still does this with Pandora in Chrome when loading a new tab. Oh, wait, the world moved on from 32-bit Windows 7? Let me tell my boss...
Your boss probably is doing what we are doing 7 -> 10, although why the heck you are on 32-bit is a little odd. I think we gave away all our 32-bit machines to students.
32-bit can still run Win16 code. 64-bit can't because of conflicting CPU modes. Could be they have some aging inhouse software they just can't replace...
You know, COBOL programs are easier to run on modern machines than a lot of Win16 programs. I could only imagine that utter vile feeling of seeing a Win16 program for a modern Windows programmer.
Oh man! I remember seeing this exact demo back in 2003/2004-ish .. I think. At that time, being able to capture from two video capture cards, in real time, on commodity hardware, was insane. So was being able to turn off individual processors.
When I first started University a few years earlier, I had a quard-boot Win98/2000/BeOS/Slackware box using the BeOS bootloader (it was the most colourful at the time).
/nostolgia
When I first started University a few years earlier, I had a quard-boot Win98/2000/BeOS/Slackware box using the BeOS bootloader (it was the most colourful at the time).
/nostolgia
For those of us who had the pleasure of using it, the fact that BeOS isn't the dominant desktop OS is proof that we're not living in the best of all possible worlds.
I adored BeOS but I am not sure whether the single-user “wide open” lack-of-security model it embodied was a path worth taking. Surely one can question whether it makes sense to have purportedly multi-user UNIX-derived OSes on single-user mobile devices, but...
That was the norm back then though. Windows 98, Mac OS 8 and 9. Yeah Windows NT 4 / 2000 were multi-user but they were targeting workstations rather than personal computing and even then it was another 5 or 10 years later before Microsoft took security seriously in their NT line (roughly midway through XP's like if I recall correctly)
Never mind that persistent internet connectivity was not the norm for most at that stage. This curtailed the power of drive by infections to a large degree.
My parents (and many others' parents too, I'm sure) know this all too well. Sometimes at parties I still have to hear about all those times I caused the phone bill to become huge because I couldn't leave the CompuServe Information Manager and IRC alone. Great times.
Or NT based for that matters.
Talking of PC's still today, some 20 years later, more or less the only thing that may prevent unauthorized access from an intruder with physical access to a machine is the BIOS password, anything else is just something that may slow down him/her a little bit.
Well, yeah — but NT was maimed mainly by flawed implementation and assumptions made in the threat model (crucially, assumptions about the remote and local attack surface —code execution by unauthenticated users (the world of the web) and the presumption of no offline access to local hardware (NTchngpwd)—) that required strengthening and reinforcement, whereas BeOS (and DOS/Windows9x) are totally unprepared for this kind of thinking.
Full disk encryption backed by a TPM or other hardware-based security module is secure against physical access attacks. This isn't an esoteric setup either: most windows PCs on the market support this.
Sure, but just like the mentioned BIOS password, they are hardware, they reside outside the software and/or Operating System "security model".
A (theoretical) BeOS (which as qubex noted has no authentication/login/password) install on a TPM/FDE hardware would be as safe (locally) as any Linux/NT/Whatever install.
Same applies to mobile OS, which are typically "single user", one could delegate security to the hardware and get rid of the complications of the "multi-user OS" underlying base.
I presume that what you mean by "physical access" attacks is someone being able to boot into a different OS and steal data or muck with OS components. Of course it's outside the running-OS security model: the OS isn't running! Full disk encryption with a TPM verifying boot components (usually done with the assistance of Secure Boot) is not vulnerable to such an attack. Other physical access attacks, like reading disk encryption keys from DMA ports, can also be mitigated by 1) not having those ports, or 2) disabling them and then including BIOS settings in the TPM measurements used to protect the disk encryption key.
Full disclosure: I used to work on this functionality at Microsoft.
Full disclosure: I used to work on this functionality at Microsoft.
Sure, still all these are "outside" the actual OS multi-user paradigm, as qubex stated, the whole "workstation" or "terminal" model may be debated.
At the time both Unix and NT had this generic idea that you had a "same" terminal (or workstation, call it as you like) to which multiple users with different credentials could have access.
For that use BeOS (like Windows 9x) was totally out of question.
Nowadays talking of mobile thingies, let's say a smartphone or iPad or even a MS Surface, 99.99% are "single user" so one could delegate the authentication to the hardware (TPM and SecureBootlike as much as you like) and have a simpler single user OS, without the complications, as such BeOS (or Haiku) may be not that bad.
I don't think it would simplify things that much. Having multiple users at the OS level is useful even when there's only one human user. For example, you can run a service as a user with limited privileges, to contain the effects of a vulnerability or breach.
Anyhow, sandboxing is just as necessary on a single-user OS as on a multi-user OS. And it's much more complex than multi-user support.
Anyhow, sandboxing is just as necessary on a single-user OS as on a multi-user OS. And it's much more complex than multi-user support.
[deleted]
Well most computers back then were bulky desktops, not shoulder bag friendly laptops.
Never mind that the first threat scenario contemplated is a physical attacker is way out there on the probability scale unless you already suspect you are on someone's hit list.
Never mind that the first threat scenario contemplated is a physical attacker is way out there on the probability scale unless you already suspect you are on someone's hit list.
Err. All operating systems suffer from that problem.
No. Systems that rely on encrypted and signed credentials to perform login theoretically do not suffer from that problem: case in point, the Windows SAM had hashed that seem to preclude if limited to NTLM decryption save for brute-forcing, which itself is curtailed by salting the hashes — but if those hashes are removed by offline editing to the SAM, the system allowed access. A system that did not allow removing the hashes because the file system is encrypted and/or because signing made the tampering visible (itself evaluated by TPM-style verification) would be conceptually not vulnerable to this line of attack (implementation flaws notwithstanding).
Windows has support for full-disk encryption using a passphrase or physical key. It also supports Secure Boot.
I don't see what that has to do with multi-user systems though. If your argument is that we could have the Secure Boot system ask for the passphrase and tie the entire box to a single user... then you're missing out on most of the current point of multi-user systems.
The first is that many companies actually do have multiple people using the same machines. Not at the same time, but at different times. This needs auditing - i.e. a multi-user system.
The second is, again, auditing - when a system administrator runs a command on a system remotely, they do it as their own user.
The third is security (combined with auditing) - various service processes get run in different user contexts so that they can't mess with the user's stuff unless they're allowed to, and they have their own user ID that anything they do happens under.
Operating systems aren't built for home users, they're built for companies, in almost all cases, and stripping out the multi-user framework would change the OS to be unrecognisable. Just stripping out the authentication part doesn't buy you much complexity reduction either.
I don't see what that has to do with multi-user systems though. If your argument is that we could have the Secure Boot system ask for the passphrase and tie the entire box to a single user... then you're missing out on most of the current point of multi-user systems.
The first is that many companies actually do have multiple people using the same machines. Not at the same time, but at different times. This needs auditing - i.e. a multi-user system.
The second is, again, auditing - when a system administrator runs a command on a system remotely, they do it as their own user.
The third is security (combined with auditing) - various service processes get run in different user contexts so that they can't mess with the user's stuff unless they're allowed to, and they have their own user ID that anything they do happens under.
Operating systems aren't built for home users, they're built for companies, in almost all cases, and stripping out the multi-user framework would change the OS to be unrecognisable. Just stripping out the authentication part doesn't buy you much complexity reduction either.
I must have expressed myself unclearly.
(First though: Windows now supports full disk encryption and secure boot. It certainly did not when I and it parted ways back in the days of XP SP1 circa 2002.)
I was not implying that the secure pass phrase/secure boot/etc be considered the basis for a secure mobile OS. Much the contrary. Multi-user systems with privilege hierarchies are fundamental aspects of how we now architect even our single-user devices. (Discussing whether another system is possible, desirable, and/or whether we could have or will eventually go down that route is midway between hypothetical and counter-factual.)
(First though: Windows now supports full disk encryption and secure boot. It certainly did not when I and it parted ways back in the days of XP SP1 circa 2002.)
I was not implying that the secure pass phrase/secure boot/etc be considered the basis for a secure mobile OS. Much the contrary. Multi-user systems with privilege hierarchies are fundamental aspects of how we now architect even our single-user devices. (Discussing whether another system is possible, desirable, and/or whether we could have or will eventually go down that route is midway between hypothetical and counter-factual.)
We were talking of actual single user systems in practice, tablets, smartphones and similar are usually single user devices and even in corporate many laptops are used as desktop replacement by single employees...
You mentioned PCs originally, hence the confusion.
In any case, I believe Android uses the multi-user features of Linux as a security mechanism (and building a new kernel from scratch might not have led to Android being a major player - ARM companies already knew how to write device drivers for Linux), although it could reasonably use an object-capability system under a more focused kernel.
In any case, I believe Android uses the multi-user features of Linux as a security mechanism (and building a new kernel from scratch might not have led to Android being a major player - ARM companies already knew how to write device drivers for Linux), although it could reasonably use an object-capability system under a more focused kernel.
Never mind that it even today is way down the list of probable attack scenarios for most personal computers.
I had BeOS and NeXTSTEP running and Be just didn't invest in development tools. NeXT had the best tools at the time and was a lot better UNIX.
I loved them both, but I often wish Be had gone for a lot cheaper box. It would have been good on some really cheap CPUs.
I loved them both, but I often wish Be had gone for a lot cheaper box. It would have been good on some really cheap CPUs.
Never underestimate the power of an install base. Microsoft in a rare moment did so when they introduced Windows Phone 7, and look where they mobile offering are now vs where they were with Mobile 6.5 (renamed Phone 6.5 with the intro of Phone 7).
> It was IMHO a "revolution" that - for whatever reasons - never happened.
As best i can tell, the history of computers has shown again and again that the market will tolerate at best 2 major commercial platforms.
Anyone trying to introduce a third will face a steep entry requirement.
Damn it, Jobs could not get Next off the ground when it was basically BSD with a pretty face. He needed the brand name recognition of Apple to effectively bring a revamped Next to the world (OSX).
And here came another contender that was neither one of the established platforms (Apple and Microsoft), nor was it a _nix derivative (Next ran on a BSD kernel). And it tried to pitch a vertically integrated stack in the form of BeOS running on Bebox.
As best i can tell, the history of computers has shown again and again that the market will tolerate at best 2 major commercial platforms.
Anyone trying to introduce a third will face a steep entry requirement.
Damn it, Jobs could not get Next off the ground when it was basically BSD with a pretty face. He needed the brand name recognition of Apple to effectively bring a revamped Next to the world (OSX).
And here came another contender that was neither one of the established platforms (Apple and Microsoft), nor was it a _nix derivative (Next ran on a BSD kernel). And it tried to pitch a vertically integrated stack in the form of BeOS running on Bebox.
>Damn it, Jobs could not get Next off the ground when it was basically BSD with a pretty face. He needed the brand name recognition of Apple to effectively bring a revamped Next to the world (OSX).
Alow me to partially disagree, you are jumping over an important passage, System 6/7/8 on the Mac were there in those years. In - say - 1993 System 7 ran circles around DOS and Windows 3.1/3.11, even if a part of that was due to comparatively more powerful (and very costly) hardware, it was definitely ahead:
https://en.wikipedia.org/wiki/System_7
If you bought a computer and OS in pre-Windows NT era, you could choose between DOS+Windows 3.1 and System 7, but the Mac hardware costed something like double the PC.
A LC500 was something around US$ 2000:
https://en.wikipedia.org/wiki/Macintosh_LC_500_series
A Powerbook 160 double that:
https://en.wikipedia.org/wiki/PowerBook_160
At the time a comparable PC or laptop was half of that.
BeOS came out when Windows 95 was all the rage and MacOS started to become outdated, circa 1995/1996, it ran on "normal" hardware and offered much better performance than Windows, but home users were happy with Windows 95 and businesses had NT 4.00 in the meantime, that - love it or hate it - was rock solid.
Alow me to partially disagree, you are jumping over an important passage, System 6/7/8 on the Mac were there in those years. In - say - 1993 System 7 ran circles around DOS and Windows 3.1/3.11, even if a part of that was due to comparatively more powerful (and very costly) hardware, it was definitely ahead:
https://en.wikipedia.org/wiki/System_7
If you bought a computer and OS in pre-Windows NT era, you could choose between DOS+Windows 3.1 and System 7, but the Mac hardware costed something like double the PC.
A LC500 was something around US$ 2000:
https://en.wikipedia.org/wiki/Macintosh_LC_500_series
A Powerbook 160 double that:
https://en.wikipedia.org/wiki/PowerBook_160
At the time a comparable PC or laptop was half of that.
BeOS came out when Windows 95 was all the rage and MacOS started to become outdated, circa 1995/1996, it ran on "normal" hardware and offered much better performance than Windows, but home users were happy with Windows 95 and businesses had NT 4.00 in the meantime, that - love it or hate it - was rock solid.
I'm not sure it was faster, but it was completely different in a good way.
I remember running 12 instances of a movie on beos. This was very slow, but on Windows the same trick caused my system to hang with around 6 movies.
Beos just kept going so it felt faster.
I remember running 12 instances of a movie on beos. This was very slow, but on Windows the same trick caused my system to hang with around 6 movies.
Beos just kept going so it felt faster.
Why would you be interested in it over Linux? If you are comparing it for 2016 state of PC computing Linux, nothing. There is no killer app on BeOS/Haiku that could justify it.
But if you want to compare it to 1998-style PC, BeOS was a really high-performance, POSIX-compatible OS. It could do things that neither Windows NT, Linux or MacOS (pre- OSX) could do, and it could do it even on very limited hardware.
Nowadays, I think that if Haiku could be ported to ARM, it would become a very interesting alternative for any kind of SOC-based appliance where you'd need more than a microcontroller but something like Linux/Android is overkill: smart TVs, audio/video receivers, smart home hubs, some cool guitar sound effect pedal, etc...
But if you want to compare it to 1998-style PC, BeOS was a really high-performance, POSIX-compatible OS. It could do things that neither Windows NT, Linux or MacOS (pre- OSX) could do, and it could do it even on very limited hardware.
Nowadays, I think that if Haiku could be ported to ARM, it would become a very interesting alternative for any kind of SOC-based appliance where you'd need more than a microcontroller but something like Linux/Android is overkill: smart TVs, audio/video receivers, smart home hubs, some cool guitar sound effect pedal, etc...
Huh..never thought about that. The trouble is, of course, porting anything to ARM. You'd have to maintain builds for hundreds of ARM devices with individual images and kernels, or you'd have to choose to explicitly support just a couple of devices (and then maybe people in the community will have unofficial builds for the rest).
..or you could only chose to support devices that support device tree configuration, but there's a good chance your kernel still won't boot on half of them. ARM isn't an architecture. It's just a chip, with people implementing stuff in crazy ways all over the place that will never make it back upstream to the mainline kernel. It's a fragmented mess and there's no incentive to fix it since most ARM devices are build around planned obsolescence to be replaced every two years.
..or you could only chose to support devices that support device tree configuration, but there's a good chance your kernel still won't boot on half of them. ARM isn't an architecture. It's just a chip, with people implementing stuff in crazy ways all over the place that will never make it back upstream to the mainline kernel. It's a fragmented mess and there's no incentive to fix it since most ARM devices are build around planned obsolescence to be replaced every two years.
"Why would you be interested in it over Linux? "
Personal pleasure of an alternative desktop. Experimental playground for OS developers. Minimalist box for older hardware with high performance. Obscurity benefit against hackers that I hear PPC Mac users still get.
A few things like that. It's not competitive against Linux/BSD desktops in about any other case.
Personal pleasure of an alternative desktop. Experimental playground for OS developers. Minimalist box for older hardware with high performance. Obscurity benefit against hackers that I hear PPC Mac users still get.
A few things like that. It's not competitive against Linux/BSD desktops in about any other case.
"Minimalist box for older hardware with high performance. "
That's what I like. For when even a good Linux distro is too much for the hardware. The slow, old thing can be transformed into a nice, new thing.
That's what I like. For when even a good Linux distro is too much for the hardware. The slow, old thing can be transformed into a nice, new thing.
Sadly I felt that it was the POSIX compatibility that killed it for me. Before that there were several wonderfu applications purely written for the OS. After we got ports of Linux apps which were far less interesting or as well configured for the multithreaded nature of the API.
BeOS and Haiku are fun and fast hobby toy OS'es however do not expect to do any heavy duty work under them. Back in the day BeOS would play games plus opening a bunch of videos and mp3s at the same time and have them run smooth, but it would also grind to a halt doing any networking activity outside of web browsing, printing, running Mozilla or using its native Office Suite GoBe Office or Abiword.
The shine came off BeOS around around 1999/2000 when Windows 2000 and Mac OS X came out along with Linux and FreeBSD were much better OS'es for getting real work done with better networking and better heavy load tolerance. And you could do BeOS tricks on top of that on those OS'es.
On top of that the Amiga OS was doing what BeOS was famous for years before just without memory protection slower hardware.
The shine came off BeOS around around 1999/2000 when Windows 2000 and Mac OS X came out along with Linux and FreeBSD were much better OS'es for getting real work done with better networking and better heavy load tolerance. And you could do BeOS tricks on top of that on those OS'es.
On top of that the Amiga OS was doing what BeOS was famous for years before just without memory protection slower hardware.
Haiku is a good
system for computing things
but details are slim
system for computing things
but details are slim
You would not be ’interested’ in “running [Haiku] over Linux”: the latter has evolved, the former is a re-implementation of an innovative 1990s OS that has since been left behind by about fifteen years of lack of progress.
It was fascinating and awesome at the time, however, and for many of us this project brings back those erstwhile thrills. It's a kind of futuristic retrocomputing thing that (I guess) leads others to still wax lyrical about other obsolete platforms such as (say) Amiga.
It was fascinating and awesome at the time, however, and for many of us this project brings back those erstwhile thrills. It's a kind of futuristic retrocomputing thing that (I guess) leads others to still wax lyrical about other obsolete platforms such as (say) Amiga.
Risking to go off topic, I remember a few years before, playing with these systems:
http://www.vrexperience.net/Newsroom.aspx?id=120
Amiga 3000 based, and they were like supercomputers ... ... and we liked it!
http://www.vrexperience.net/Newsroom.aspx?id=120
Amiga 3000 based, and they were like supercomputers ... ... and we liked it!
[deleted]
[deleted]
As a comparison the had builds with other operating systems and they could not compete, they ran very choppy, like 3 fps.
I suggest you try it out. It's refreshing to tinker with an OS that is so fundamentally different. When I went home I installed it on a few machines I had, which were collecting dust. Tinkering with haiku sort of reinvigorated my original wonder of computing from when I as a kid, for a couple months.
Later at the conference, I was helping at the Python booth, and I asked if haiku supported Python. The haiku guy was not sure but he got it to compile and run about 4 minutes later, and it worked!