4 ms·

I remember reading about BeOS and seeing demos during 2000-2001, but I always wondered a few things. One item of curiosity was how they were able to so efficie

I remember reading about BeOS and seeing demos during 2000-2001, but I always wondered a few things. One item of curiosity was how they were able to so efficiently handle media with such a light footprint? What were the trade-offs? For devices like tablets, it seems like it would be a godsend. Also, did any of the innovations make their way into things we use today? Palm bought their tech, but did any of the media tech make it out? Or is it just an artifact from an earlier age with not much applicability to modern day needs?

allenbrunson 9y ago
I worked at Be for almost a year, and used BeOS for a couple of years before that. I am not an expert, but I can mention a couple of things. The biggest one was: freedom from backward compatibility. You can't comprehend how much cruft you are drowning in, in your typical OS, until you are free from it. Coming to BeOS from Windows, as I did, it felt like 2,000 pounds was lifted off my shoulders. BeOS was free to fully embrace some modern technologies that had been bolted on to older operating systems as an afterthought. The biggest one was multi-threading. Having spent years on earlier operating systems, I can say that all of them have a stunted idea of multi-threading, compared to BeOS. Typically, you are forced to run your user interface in your main thread, and you have to run background tasks in background threads, and invent ways to communicate between the two. Contrast BeOS: every single window runs in its own thread. Think about that for a minute: If you write a BeOS app that has two or more windows, surprise, your app is multi-threaded. Whether you like it or not! A lot of programmers, coming from older operating systems, very much did not like it. Personally, I came to embrace this as BeOS' greatest strength. Communicating between windows was pretty natural: just drop events into each other's event queues, which were of course thread-safe. Unfortunately, the early architects of the system made their own set of poor decisions that led to a new round of cruft. The worst of these was tying themselves to the ABI of a particular C++ compiler. GCC version 2.9x, I think. In the last year of Be's existence, we were really feeling the pain of this. The compiler we were shackled to was many years out of date. If we switched to a modern compiler, it would have a different ABI, and all older software that couldn't be recompiled would have been instantly broken. Nonetheless, there was a vocal minority of engineers inside Be who argued for doing just that. We weren't focused on external users at that point, just internet appliances, so we could have gotten away with it. But we were all BeOS users ourselves, so we would have lost a lot of useful apps that way.
- natecavanaugh 9y ago
  This comment is such a perfect example of the reasons I come to read the comments here on HN. Thank you for the info. Could there not have been a compromise for those devs who didn't want ABI compatibility? For instance with Apples handling of Mac OS apps and then carbon and then cocoa? Meaning, some sort of optional emulation layer? Of course, the system architecture may be so different as to make it impossible, OR the business decisions needed at the time couldn't afford a middle layer. Either way, this was one of my favorite comments on here, so thank you :)
  - allenbrunson 9y ago
    I suppose it would have been possible to build some kind of API shim that would allow for two or more ABIs. Alas, the technical details of how to make that work are above my pay grade. I can say that it never came up in the heated debates I heard inside Be. Possibly because that would have meant the base OS would have been a lot larger, and we were targeting resource-constrained internet appliances at the time. You could get a much fuller answer by exploring how Haiku handles this. I haven't paid much attention to that OS in quite awhile, but I think they did indeed succeed in keeping a set of backward compatibility libs, for older software, and also built a new set of libs for recently-compiled software.
    - memsom 9y ago
      BeIA was quite clever. The OS compressed the binaries by using a one way (?) process to pull out common code segments in to a common dictionary. The OS then read that code somehow in to memory when the apps started. You could run the OS uncrushed, but it took up a lot more space. One could fit the entire OS on a 16MB CF card in crushed format. (YES, MB not GB!!) The crushed apps have a magic symbol CEL instead of ELF in the file header. The file system was also compressed. It was called CFS, rather than BFS (BeFS) and a lot of stuff like attributes and metadata was very broken in the pre 1.0 builds I saw.
      - allenbrunson 9y ago

allenbrunson 9y ago

I worked at Be for almost a year, and used BeOS for a couple of years before that. I am not an expert, but I can mention a couple of things. The biggest one was: freedom from backward compatibility. You can't comprehend how much cruft you are drowning in, in your typical OS, until you are free from it. Coming to BeOS from Windows, as I did, it felt like 2,000 pounds was lifted off my shoulders. BeOS was free to fully embrace some modern technologies that had been bolted on to older operating systems as an afterthought. The biggest one was multi-threading. Having spent years on earlier operating systems, I can say that all of them have a stunted idea of multi-threading, compared to BeOS. Typically, you are forced to run your user interface in your main thread, and you have to run background tasks in background threads, and invent ways to communicate between the two. Contrast BeOS: every single window runs in its own thread. Think about that for a minute: If you write a BeOS app that has two or more windows, surprise, your app is multi-threaded. Whether you like it or not! A lot of programmers, coming from older operating systems, very much did not like it. Personally, I came to embrace this as BeOS' greatest strength. Communicating between windows was pretty natural: just drop events into each other's event queues, which were of course thread-safe. Unfortunately, the early architects of the system made their own set of poor decisions that led to a new round of cruft. The worst of these was tying themselves to the ABI of a particular C++ compiler. GCC version 2.9x, I think. In the last year of Be's existence, we were really feeling the pain of this. The compiler we were shackled to was many years out of date. If we switched to a modern compiler, it would have a different ABI, and all older software that couldn't be recompiled would have been instantly broken. Nonetheless, there was a vocal minority of engineers inside Be who argued for doing just that. We weren't focused on external users at that point, just internet appliances, so we could have gotten away with it. But we were all BeOS users ourselves, so we would have lost a lot of useful apps that way.

natecavanaugh 9y ago
This comment is such a perfect example of the reasons I come to read the comments here on HN. Thank you for the info. Could there not have been a compromise for those devs who didn't want ABI compatibility? For instance with Apples handling of Mac OS apps and then carbon and then cocoa? Meaning, some sort of optional emulation layer? Of course, the system architecture may be so different as to make it impossible, OR the business decisions needed at the time couldn't afford a middle layer. Either way, this was one of my favorite comments on here, so thank you :)
- allenbrunson 9y ago
  I suppose it would have been possible to build some kind of API shim that would allow for two or more ABIs. Alas, the technical details of how to make that work are above my pay grade. I can say that it never came up in the heated debates I heard inside Be. Possibly because that would have meant the base OS would have been a lot larger, and we were targeting resource-constrained internet appliances at the time. You could get a much fuller answer by exploring how Haiku handles this. I haven't paid much attention to that OS in quite awhile, but I think they did indeed succeed in keeping a set of backward compatibility libs, for older software, and also built a new set of libs for recently-compiled software.
  - memsom 9y ago
    BeIA was quite clever. The OS compressed the binaries by using a one way (?) process to pull out common code segments in to a common dictionary. The OS then read that code somehow in to memory when the apps started. You could run the OS uncrushed, but it took up a lot more space. One could fit the entire OS on a 16MB CF card in crushed format. (YES, MB not GB!!) The crushed apps have a magic symbol CEL instead of ELF in the file header. The file system was also compressed. It was called CFS, rather than BFS (BeFS) and a lot of stuff like attributes and metadata was very broken in the pre 1.0 builds I saw.
    - allenbrunson 9y ago