4 ms·

> there's a reason we're not still using BeOS today for example (Haiku aside). You're blaming BeOS's failure on the BeBox? Every release of BeOS that was marke

> there's a reason we're not still using BeOS today for example (Haiku aside). You're blaming BeOS's failure on the BeBox? Every release of BeOS that was marked as a "full release" (as opposed to a developer preview or a "preview release") could run on Intel hardware, and the BeBox itself was discontinued long before then. This is a tangent, but I don't understand people who think BeOS was the heir-apparent to consumer/home/personal OSes. It had super half baked networking support and absolutely no concept of multi-user or privilege separation. Similar home OSes didn't enforce privilege separation or multiple users, but at least had the framework -- BeOS essentially just runs everything as root. It had some neat tricks, but was a pretty underdeveloped OS in some key areas. The fact it never took off isn't that surprising to me, and it's not just because Be was a small company or that it's hard for an underdog to get market share in a crowded space (both of which are also true). It just wasn't really well suited for "general purpose computing" in the same way that e.g. Linux, WinNT, or Darwin are.

AnIdiotOnTheNet 6y ago
> This is a tangent, but I don't understand people who think BeOS was the heir-apparent to consumer/home/personal OSes. It had super half baked networking support and absolutely no concept of multi-user or privilege separation. What need does a personal computer OS have for multi-user support? The median number of users on a personal computer at any given time is 1. Even in the rare case that two or more people want to use the same computer at separate times and desire to protect eachother's files from eachother, they can use encryption rather than fake OS enforced security. Privilege separation, in order to keep malicious applications from compromising the user's files, has become significantly more important but it wasn't that important back then.
- spijdar 6y ago
  Malicious applications and internet malware weren't raging problems in the late 90s, but they were known and predicted dangers. You really don't need "user accounts" per se, but a way to restrict process privileges, of which user accounts is just a decent abstraction. On WinNT, user accounts and groups are just abstractions for providing SIDs for your access token -- there are SIDs like NT SYSTEM which don't have a correlated user account. The important bit is you can create a process that can't accidentally fandango on core and overwrite all the system files. You have to elevate privileges -- even if there's no prompt for the user, the application dev still has to intentionally request admin rights to touch sensitive files. All that aside, though, it's a lot easier to fake "no user accounts" like Windows did and just have no password, than to genuinely have no privilege separation and try to retrofit it on later. If you're trying to market a brand new OS with new APIs that has no compatibility with anything, even in the 90s, I'd expect some kind of plan for at least optional security. Anything at all!
  - AnIdiotOnTheNet 6y ago
    > You really don't need "user accounts" per se, but a way to restrict process privileges, of which user accounts is just a decent abstraction I contend that they really aren't. > The important bit is you can create a process that can't accidentally fandango on core and overwrite all the system files. And here's why: the system files are easily replicable, there's a copy on every OS installation media. My personal files exist in far fewer places and the OS does absolutely nothing to stop a malicious application from damaging them. See also: https://xkcd.com/1200/ https://xkcd.com/1200/ We call them user accounts because they are designed around isolating users from each other and the system, but that isn't what we care about in a personal computing context. It is possible to jerry-rig the kind of permission system we actually want using the user account system, but it has a lot of problems in practice because it isn't designed for that. It is not a good abstraction.
    - spijdar 6y ago
      Yeah, I'll concede that "decent" is too much credit. Even on "true multi user systems" the simplistic models *nix don't really work, and you end up seeing people using combinations of virtual machines and containers as ham-fisted sandboxes. I was thinking of it more along the lines that it's at least kind of understandable for the average person. More so than some alternatives, at least. Still, I think it was a big oversight to provide nothing at all in BeOS. Maybe they could have come up with a better solution than the backwards-compatible status quo. Or maybe personal computers would have just been better off in an alternate timeline where networking wasn't as pervasive and we still got software on disks, and mailed off for a hard copy of GNU...
setpatchaddress 6y ago
I know people who were very upset that Mac OS X required login/password. The "personal" part of "personal computer" was important to some people.
- spijdar 6y ago
  AFAIK the original releases of OS X by default did not require a login and simply booted to desktop, same as Win 9x/XP. The distinction is these systems, even if they would never ask you for a password or allow you to forgo a password altogether (like WinXP) still have the notion of user accounts and privilege separation/process isolation. It's a lot easier to fake them not being there then to retrofit them.
ryukafalz 6y ago
>You're blaming BeOS's failure on the BeBox? Every release of BeOS that was marked as a "full release" (as opposed to a developer preview or a "preview release") could run on Intel hardware, and the BeBox itself was discontinued long before then. Okay, that's fair - BeOS was a bad example. Let's say AmigaOS then, which largely seems to be limited to Amiga hardware. (Though amazingly it still seems to be maintained?)
- spijdar 6y ago
  Depends on who you ask, I think. I'm not into Amiga stuff or that knowledgeable, but I understand AROS is essentially Amiga 3 implemented on x86/ARM/PPC/M68K. However, it's not seen as being "Amiga" because it doesn't primarily run on "real Amiga hardware"?
chipotle_coyote 6y ago
Well, I don't know if I'd say it was an "heir apparent" to anything in particular, but I think BeOS was promising. You're looking back at it like an engineer, which is fair; I'm looking back at it as, well, a user, someone who ran it full-time for nearly two years. Sure, I ran into things it couldn't do, but most of the time I was kept enchanted by all the things it could already do. At the time it was being worked on its main competitors were Windows 95/98 and (pre-Unixification) Mac OS; multiuser capability just wasn't that important. If development had continued, I don't think it would have been out of the question for a future version to include multiuser support. In any case, I really do wish we'd been able to see where BeOS might have been in 2009 if things had gone differently.
smallstepforman 6y ago
BeInc launched BeOS R3 in the era of Win95/98 and MacOS classic, both were commercially successful and had no multiuser support and poor TCP/IP stacks.
- spijdar 6y ago
  Win9x did actually have multiuser support -- it didn't enforce permissions between users locally, but it could at least have multiple profiles with different settings, and could restrict network share access to user accounts with NetNTLM style authentication. The important part is the API was "multiuser aware". MacOS was inferior to basically every other alternative but it got by because of backwards compatibility with a really large catalogue of Mac software. I don't think an OS like MacOS classic could have made it from scratch. I didn't mean to sound so negative about BeOS, I just think it could have had a better chance if it had a more solid technical base, especially for an OS made from scratch in the mid 90s. Especially when Linux and BSD were accelerating. I like to imagine something like NeXTSTEP but based on a FreeBSD or Linux core with a from-scratch userland/runtime and API... mmm...

AnIdiotOnTheNet 6y ago

> This is a tangent, but I don't understand people who think BeOS was the heir-apparent to consumer/home/personal OSes. It had super half baked networking support and absolutely no concept of multi-user or privilege separation. What need does a personal computer OS have for multi-user support? The median number of users on a personal computer at any given time is 1. Even in the rare case that two or more people want to use the same computer at separate times and desire to protect eachother's files from eachother, they can use encryption rather than fake OS enforced security. Privilege separation, in order to keep malicious applications from compromising the user's files, has become significantly more important but it wasn't that important back then.

spijdar 6y ago
Malicious applications and internet malware weren't raging problems in the late 90s, but they were known and predicted dangers. You really don't need "user accounts" per se, but a way to restrict process privileges, of which user accounts is just a decent abstraction. On WinNT, user accounts and groups are just abstractions for providing SIDs for your access token -- there are SIDs like NT SYSTEM which don't have a correlated user account. The important bit is you can create a process that can't accidentally fandango on core and overwrite all the system files. You have to elevate privileges -- even if there's no prompt for the user, the application dev still has to intentionally request admin rights to touch sensitive files. All that aside, though, it's a lot easier to fake "no user accounts" like Windows did and just have no password, than to genuinely have no privilege separation and try to retrofit it on later. If you're trying to market a brand new OS with new APIs that has no compatibility with anything, even in the 90s, I'd expect some kind of plan for at least optional security. Anything at all!
- AnIdiotOnTheNet 6y ago
  > You really don't need "user accounts" per se, but a way to restrict process privileges, of which user accounts is just a decent abstraction I contend that they really aren't. > The important bit is you can create a process that can't accidentally fandango on core and overwrite all the system files. And here's why: the system files are easily replicable, there's a copy on every OS installation media. My personal files exist in far fewer places and the OS does absolutely nothing to stop a malicious application from damaging them. See also: https://xkcd.com/1200/ https://xkcd.com/1200/ We call them user accounts because they are designed around isolating users from each other and the system, but that isn't what we care about in a personal computing context. It is possible to jerry-rig the kind of permission system we actually want using the user account system, but it has a lot of problems in practice because it isn't designed for that. It is not a good abstraction.
  - spijdar 6y ago
    Yeah, I'll concede that "decent" is too much credit. Even on "true multi user systems" the simplistic models *nix don't really work, and you end up seeing people using combinations of virtual machines and containers as ham-fisted sandboxes. I was thinking of it more along the lines that it's at least kind of understandable for the average person. More so than some alternatives, at least. Still, I think it was a big oversight to provide nothing at all in BeOS. Maybe they could have come up with a better solution than the backwards-compatible status quo. Or maybe personal computers would have just been better off in an alternate timeline where networking wasn't as pervasive and we still got software on disks, and mailed off for a hard copy of GNU...

setpatchaddress 6y ago

I know people who were very upset that Mac OS X required login/password. The "personal" part of "personal computer" was important to some people.

spijdar 6y ago
AFAIK the original releases of OS X by default did not require a login and simply booted to desktop, same as Win 9x/XP. The distinction is these systems, even if they would never ask you for a password or allow you to forgo a password altogether (like WinXP) still have the notion of user accounts and privilege separation/process isolation. It's a lot easier to fake them not being there then to retrofit them.

ryukafalz 6y ago

>You're blaming BeOS's failure on the BeBox? Every release of BeOS that was marked as a "full release" (as opposed to a developer preview or a "preview release") could run on Intel hardware, and the BeBox itself was discontinued long before then. Okay, that's fair - BeOS was a bad example. Let's say AmigaOS then, which largely seems to be limited to Amiga hardware. (Though amazingly it still seems to be maintained?)

spijdar 6y ago
Depends on who you ask, I think. I'm not into Amiga stuff or that knowledgeable, but I understand AROS is essentially Amiga 3 implemented on x86/ARM/PPC/M68K. However, it's not seen as being "Amiga" because it doesn't primarily run on "real Amiga hardware"?

chipotle_coyote 6y ago

Well, I don't know if I'd say it was an "heir apparent" to anything in particular, but I think BeOS was promising. You're looking back at it like an engineer, which is fair; I'm looking back at it as, well, a user, someone who ran it full-time for nearly two years. Sure, I ran into things it couldn't do, but most of the time I was kept enchanted by all the things it could already do. At the time it was being worked on its main competitors were Windows 95/98 and (pre-Unixification) Mac OS; multiuser capability just wasn't that important. If development had continued, I don't think it would have been out of the question for a future version to include multiuser support. In any case, I really do wish we'd been able to see where BeOS might have been in 2009 if things had gone differently.

smallstepforman 6y ago

BeInc launched BeOS R3 in the era of Win95/98 and MacOS classic, both were commercially successful and had no multiuser support and poor TCP/IP stacks.

spijdar 6y ago
Win9x did actually have multiuser support -- it didn't enforce permissions between users locally, but it could at least have multiple profiles with different settings, and could restrict network share access to user accounts with NetNTLM style authentication. The important part is the API was "multiuser aware". MacOS was inferior to basically every other alternative but it got by because of backwards compatibility with a really large catalogue of Mac software. I don't think an OS like MacOS classic could have made it from scratch. I didn't mean to sound so negative about BeOS, I just think it could have had a better chance if it had a more solid technical base, especially for an OS made from scratch in the mid 90s. Especially when Linux and BSD were accelerating. I like to imagine something like NeXTSTEP but based on a FreeBSD or Linux core with a from-scratch userland/runtime and API... mmm...