4 ms·
I only hear people lionizing it. What were the rough parts?
by appleflaxen 3y ago
I only hear people lionizing it. What were the rough parts?
- sillywalk 3y agoA long time ago, I actually bought a copy of BeOS 5 Professional to run on a pair of Pentium 3's. I really did quite enjoy using it, it was snappy, however, rough parts, ... there was a leaked 'Dano' release that fixed some of these problems, but it was too late. Rough Bits: - Limited Software. Gobe Productive as an office suite was quite nice, but not anything like Word Perfect or MS Office, and importing stuff was limited. The web browser Netpositive was behind Netscape / Internet Explorer - no Flash, or Java - it had limited Posix support, so command line utilities could be ported from Linux/BSDs, but no X or GTK/QT - no 'killer app'. - No Colour sync, little/no accessibility, localization. - network stack was slow - even Linux was getting way more commercial software Limited hardware support - no 3d acceleration (at least released publicly) - limited drivers for other hardware - e.g. printing support was .. limited - USB support was limited So, for day to day use, it was fine by me, especially for ripping CDs, BeOS had a feature where CD Audio tracks would appear as AIFF files in the Tracker, and could lookup the names with CDDB (before gracenote killed that), There was a bash script by BeOS evangelist and author Scott Hacker(?) that would rip tracks, edit the MP3 metadata and the Be Filesystem meta data, so you could do mp3 tracklists by query. It was/is used as a Radio Station automation software, called Tune Tracker[0] though they may have switched to Haiku [0] http://www.tunetrackersystems.com http://www.tunetrackersystems.com
- retrocryptid 3y agoIt would be nice if you could print something with it. And "Fragile Base Class as a Service" isn't really the road to riches they thought it was in the 90s. Though I guess we replaced the fragile base class problem with the initialization fiasco and trying to figure out how to compile two different versions of boost into the same executable because you have two dependencies which depend on different versions of boost. In other words... C++ is great for closely coupled systems and services. But in many ways, application environments running on top of operating systems are more loosely coupled. Earlier versions of BeOS did not make it easy to run an app compiled for an earlier OS API to run on a machine with a later OS API without being re-compiled. That's not too big of a deal with Linux since many things are trivial to recompile. But BeOS was supposed to be a commercial platform and they were releasing a new version of the OS every 6 months. So if you wanted your software to run for people with an installed base and new customers, you had to maintain multiple versions of the same code for different minor revs of the OS. I'm not the biggest fan of the GNU Objective-C compiler (I cut my teeth on the full-function stepstone version), nor am I a fan of Mach (a heavyweight microkernel) or the son-of-NeXTStep monstrosity that is Rhapsody/macOS (with it's spinning beachball of death), but they did sort of figure out how to make late binding between applications and OS services work.