Hacker News Reader

Comment by gigatexal | Hacker News Reader

Oh what would have been what could have been had Apple bought Be instead of Next. We'd likely not have any iPhones or a 2.5T Apple but we could have had some really cool software. BeOS and now Haiku will always have a special place in my nerd-head.

consider sponsoring the team here: https://github.com/sponsors/haiku

View on HN

Many Be employees, including myself, ended up at Apple; some after a brief time at Eazel and others later on. They had, and continue to, make great contributions. As a former Be employee and lover of BeOS, I can say that Apple acquiring Be would have been a disaster for Apple. I have no ill will to Gil Amelio, Ellen Hancock, Steve Glass and the other leadership, but they didn't have what it took (other than the NeXT purchase) to pull Apple out of crisis.

I find this take somewhat baffling. At the moment that Apple bought NeXT, NeXTSTEP had a mature software toolchain, a working IPv4 networking stack, and enterprise customers, three things that BeOS lacked. BeOS had a primitive software toolchain ecosystem based on pre-standard C++. BeOS IP networking barely worked and despite everything claimed in their advertising it was fully serialized, single-threaded networking. BeOS had zero customers.

The only thing that Be did have was one nifty demo, and a somewhat innovative file system. Apple must have correctly deduced that it would be easy to improve the filesystem, because they later did so, with the same author.

Comparing BeOS and NextSTEP in 1997 is like comparing a ham sandwich to a piglet and a bag of flour. One of these things was a finished product.

(Just because I love this argument): Have you used Mid-90s OpenStep and BeOS on period hardware? People rose-tinted-glasses the hell out of OpenStep (...and the first few OS X releases), it's ridiculously sluggish and brittle (in that same kind of "I did something to config and rendered it unbootable" way as early 2000s Linux). BeOS is shockingly performant and flexible on the same hardware.

As much as the original BeOS network stack was mediocre (and it was, it wasn't fixed until the BONE design in that final Dano leak in 2001) the much-touted NeXT networking stack was literally the open source 4.3BSD networking code running hosted, with their awful NetInfo system on top, which Apple spent the next several years excising. Excising like the Adobe license fees cost more than a PC, few major vendors (not even Adobe!) willing to port their software to, Display PostScript GUI they had to throw out and replace.

I'll grant that they got a really good set of development tools they're still essentially using, and Be's were rough (and kind of alien, that kind of pervasive threading is _still_ hard with decades of work on the tooling).

Apple bought NeXT because the stack looked architecturally like a less-bungled version of their own failed Pink/Taligent effort, and Steve Jobs had a better relationship with people still at Apple than Jean-Louis Gassée.

I ran NEXTSTEP 3.2 and I think, 3.3, on both 486 DX2/66 and original NeXT hardware. At one job I ran on a 25Mhz Mono slab as my daily and only machine. I did Web surfing, email, used VarioData for the home-built sales/contact system, etc.

There were some pieces that were slow, but overall it was a fantastic experience. The "Shelf" was great; I would store commonly-used docs there, reference materials etc.

Look I'm not going to bat for NeXTSTEP as a user nirvana, but at the time Apple bought it it was hugely advanced compared to BeOS, which still had not reached R3. A few things that NeXT could do that Be could not do at the time: run on an Intel PC, burn CD-Rs, and print.

BeOS R4–the first revision that did useful things users actually wanted–came out two years after Apple agreed to acquire NeXT. The current BeOS at the moment was "DR8" as in "developer release".

The fundamental thing Apple got out of the NeXT acquisition was an adult OS management team. The software acquired was totally irrelevant (at the time). What was important was new people in charge, who unlike the previous Apple management, could actually make decisions. The decisions were often bad, but they were decisions!

If Amelio and Hancock had been competent, they would have actually set up a management structure internally and started focusing on shipping Copland-based software instead of shopping externally. Strip it down and get it out the door and build on that. It could absolutely have been done.

Of course, you wouldn’t have the iMac or iPod or iPhone. And Apple might not have survived. The world would be very different.

(That all said, OpenStep was truly dire in 1997. Yes, it could print, although they ended up having to write an entirely new graphics stack from scratch anyway. It actually took six years from 1997 to turn moribund OpenStep into a viable consumer OS (I could not recommend anything before Jaguar to end users — the Finder, among other things, was unusable up to that point).

The tale of major incumbents' completely bungled OS/Platform projects of the 80s and 90s really is one of the great epics of the field.

A short - and playing it a little fast and loose for narrative like a Malcolm Gladwell piece - telling of the circumstances:

Apple failed utterly with Taligent, and Copland, and mismanaged A/UX into the ground, so it's the mid 90s and they're shipping a hyper-extended version of a one-off from 1984 that had to be hacked for even cooperative multitasking, looking around for a platform to jump on to. With IBM's help in two of those cases. They even, reportedly, batted around giving up and becoming a shell on top of NT or Solaris by porting Quickdraw during their flail in the early 90s. Then they bought NeXT, took one more (and it was at least the third after A/UX and the MAE product which was really more of an emulator, but so was Classic) pass at "Let's slap a Mac-like shell and compat layer on top of a UNIX and call it a day" and got successful selling mostly handheld appliances running basically that stack.

IBM failed utterly with their share of Taligent and the A/UX/AIX merger planning, and mismanaged OS/2 into the ground, until IBM, once of "IBM and the Seven Dwarves" dominance, became a midsize player in the PC market they created (more through incumbent effects than technical prowess), until they gave up and sold the businesses to a Chinese clone maker and retreated to high-end niche markets. (Their spun out printer division, the legacy of their once dominant typewriter business, would also later also be bought out by a Chinese cartridge cloner, so it's almost a theme for them.)

DEC dithered on ...literally everything because they didn't understand the world after minicomputers, so all their talent left as they crumbled (which is also a large part of how AMD64 happened, there is an awful lot of Alpha lineage in the K8 design). Eventually their corpse was consumed by a PC cloner, who were themselves consumed by HP.

The UNIX vendors were too busy infighting to get much done, and all the UNIX-brand-UNIX vendors license cost overhead was too high to put up credible consumer offerings anyway, until eventually a hobby project from some kid in Finland ate their entire software business while Intel (possibly accidentally, Itanium is the culmination of a series of failures - 432,860,960 - for them too) ratfucked their long term hardware projects to death.

...And so Microsoft, then famous for 8-bit BAISCs, slowly abandoning their own successful but mutant UNIX offering (Xenix), managing to sell Seattle Computer Products' DOS to IBM after Digital Research/Gary Kidall (CP/M) didn't want to deal with IBM, and the surprising success of their awful DOS shell, ran away with nearly the entire mainstream OS market for decades by gathering everyone competent from the VMS and OS/2 lineages (they put Dave Cutler and Moshe Dunie in charge) and having them write NT. Running mostly on Intel's inescapable accidental success extension-of-an-extension-of-an-extension legacy architecture.

It's a weird field we're in.

Spot on man. I think we've all learned that the best tech stack will not win without also having a good sales, marketing, and management team to support it. And if you are completely incompetent at those things it doesn't matter how good your tech is, you will turn into a hilarious failure we'll all be laughing at later. (Though we'll have a lot of fun making YouTube videos where we run all your shit through emulation.) I know people always shat on Microsoft's engineering, though the truth is I think they tried to do the best they could with what they had and they also understood how important backwards compatibility was, and they had to work within that limitation. But I think that maybe they were just a bit jealous that their management was so far ahead of everyone else (really only Apple after Jobs came back could rival them)!

I'm not sure that attributing the successes to "sales or marketing" had as much to do with it as timing and position. Management _failures_ certainly dominated the era, there were vast numbers of unforced errors due largely to managerial empire building, feature creep/novelty seeking, and ambition exceeding the scale of tractable development practices. The note up-thread about "What was important was new people in charge, who unlike the previous Apple management, could actually make decisions. The decisions were often bad, but they were decisions!" is, IMO, a great read on the situation. I've posted in earlier HN threads about my belief in the "Next bought Apple with Apple's money" idea, and the replacement (or reversion since a lot of them were Apple folks to start with) of Apple's management with Next folks in short order. They were making largely the same kinds of decisions that almost bankrupted Next, but under more favorable circumstances.

Even as someone who has run Linux most of the time for like 15 years, the underlying tech in NT is in many ways by far the best design of the OSes that survived to modern maturity. I just hate almost everything they've done with the upper layers of the stack since 7.

R3 could actually run on Intel PCs; it was the first release to have that option available. The other two you are probably right about, I'm not actually an expert in BeOS history pre-R5 :)

NetInfo did have some good ideas, and I suppose it could have been improved, but the market wanted a standards-based solution. I think macOS was the first commercial operating system to ship with a RFC2307 LDAP client. Jaguar (10.2) had a NetInfo to LDAP bridge and subsequent versions removed NetInfo entirely, although I think NOOP stubs may still remain in libSystem.

Also, NeXtSTEP could reliably print stuff. Which, given that publishing was the niche that arguably kept the Mac alive during those years: kinda important!

NeXT even had stuff like WebObjects, which was really ahead of its time back then. And AFAIK it still powers some services at Apple.

iTunes and App Store seem to both still be backed by webobjects services. Stuff like [1] still respond at WO-like URLs and still include headers like `x-webobjects-whatever` so I surmise these are still production WO apps.

1: https://itunes.apple.com/WebObjects/MZStoreServices.woa/ws/w...

It would be interesting to see what would have happened had Apple bought Be instead of Apple, but I think it's pretty clear Apple made the "right" move. NeXT had really good software, and of course, Steve Jobs (and let's not forget about the rest of the NeXT team with people like Avie). Hard to imagine Jean-Louis Gassée (or anyone else really) being able to turn the company around like Steve did.

Exactly. In acquiring NeXT, Apple bought leadership and culture. And we can argue forever if Apple’s engineers could have shipped the first OSX release earlier or in a better state, had they instead acquired Be. But I doubt it. Because - again - they bought themselves a high-performance culture, which they might not have gotten from Be. Porting BeOS to Apple hardware / existing software would have likely required an equally Herculean effort.

Oh and they got Steve Jobs of course who made quick work of pushing out the old Apple leadership. And good that he did.

BeOS already ran on existing Apple PowerPC hardware of the time:

http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/su...

In school, I quad-booted Debian, Win2k, QNX, and BeOS on my desktop.

BeOS was very light weight. Its ethernet driver for 3c509 was buggy and crashed often, but being a userspace driver, I just got a popup asking permission to restart the driver. Conversely, a couple years later I had an OSX laptop, and a corrupted backup CD that would kernel panic OSX, Win2k, and Linux. (Honestly, ISO 9660 and FAT32 drivers should be migrated out of mainstream OS kernels, since kernel latency is very far from being the bottleneck when using thunmb drives or CDs.)

On the other hand, BeOS had some questionable uses of metadata. After improperly using tar to backup my home directory before a reinstall, I lost all of my NetPositive browser bookmarks. I didn't realize each bookmark was a zero-sized file with the URL actually stored in metadata. My improper backup procedure dropped the metadata fork.

Also, there was a kernel bug related to semaphores. I had some semaphore code that worked fine under Linux but would kernel panic BeOS.

Had Apple purchased Be, we'd likely have a much lighter weight OSX, though perhaps with poorer support for multiple users.

I'm still hoping that someday QNX RTP gets open-sourced. A hard real-time light weight microkernel OS was fun to play around with. In particular, a cache benchmark I ran for a systems class showed quite a bit smaller cache footprint for QNX vs. Debian. (Though, Debian almost certainly had more daemons running, so it's not an apples-to-apples comparison of kernel cache footprints.)

Circa 1999 one of the popular machines in my uni's computer club was the BeBox - it had a solid web browser, it was fast, it had the cool CPU usage indicator on the front, and it was *nix enough to compile most stuff or to work on assignments in ANSI C. And it was just so snappy, it could do more than one thing without getting janky.

A real shame that they faded out. I kind of miss those days with all the different and varied workstations – Be, SGI, DEC, HP, IBM, Sun, ...

I'd like to see the GeekPort reintroduced on non-Pi class machines. A bit of digital GPIO, some analog lines, maybe SPI...

Twenty years ago I might have liked that too, but these days I much prefer dedicated machines (MCUs like Arduino, P8X32A, R.Pico etc. or "single-board" (or rather "open-frame") computers like R.Pi, BBB etc.) for the acoustic noise alone (not to speak of power bill and electrical safety). USB or Ethernet (preferred for galvanic separation) on the PC does just fine to connect to those.

I wonder why there isn't a $20 PCI-E card (or perhaps USB dongle) that offers a 40-pin RasPi-style port.

If you had a PCI card you would need some kind of external adapter or breakout box for the GPIO pins. Seems much more practical to have the board in the "breakout box" and connect it via USB.

I don't know about the prices but mixed-signal GPIO rigs for PCIe and USB are very common. Look at the "LabJack" for example. The LabJack U3-HV has almost exact feature parity with the geekport.

A quick google puts it at $130, well beyond the price of "just buy a Raspberry Pi or similar device, which also comes with all the SoC smarts too."

Fair enough. It compares more favorably to an odd port inconveniently located on the back of a $5000 (2022 dollars) tower PC.

Assuming Apple's success by going with Be instead of NeXT, we would have yet another mainstream OS where C++ plays a major role, thus settling the whole discussiong regarding C vs C++ for OS design.

Linus Torvalds has settled that whole discussion, by rejecting C++ and subsequently adopting Rust. Even Windows is basically written in C in its lowest layers anyway, they apparently don't find C++ itself very useful.

Linus Torvalds has settled that whole discussion for the Linux kernel.

Thankfully his opinion about C++ is meaningless outside Linux world.

Windows started to adopt C++ on the kernel since Vista, you can make use of Windows Implementation Library, a C++ template library for kernel, drivers and userspace code. Just gotta to love that VC++ /kernel flag.

macOS with its NeXTSTEP heritage, changed from having Objective-C drivers on kernel space to C++ drivers in kernel space.

Then if you bother to broaden your horizons beyond FOSS UNIX clones, there are enough OSes already shipping C++ on the kernel.

Reply on news.ycombinator.com