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).
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).
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.
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.
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.
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.
(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.
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.
>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:
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.
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.
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...
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.
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.
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.
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.
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.