Much of the book is very dated, complaining about things that have been rectified many years ago.
However I think it still has a valuable lesson that many, particularly young CS students, would benefit from: Unix is not the perfect fundamental model for computing. C is not the gospel. Their prevalence today is as much a historic and economic accident as a rational consequence of their objective merits. Both are social artifacts, not manifestations of fundamental truths.
Worshipers of Bell Labs (such as the cat-v or suckless folks) don't get this, and I've seen them pull a lot of people down that rabbit hole with them, particularly young and inexperienced students.
As a systems software researcher, I concur. I like Unix and I’m very greatful for its impact on computing, but Unix and its derivatives are not the final answers of systems software design. I feel that much of the software engineering and computer science world (even among OS researchers) is unfamiliar with non-Unix designs other than Windows. We can learn a lot from historical non-Unix operating systems such as the Genera OS for Symbolics LISP machines and the Oberon operating system.
Ever try to port a POSIX utility to BeOS? I did. No mmap and no BSD sockets killed any chance of easily porting any network utility to BeOS. It had a directory called /dev, yes, but it was absolutely nothing like /dev on any Unix system; it's all home grown. No permissions; it's a single-user system. It stores file owners and modes, yes, but they don't actually mean anything; you don't need the +x bit to execute a file, you don't need the +x bit to list a directory, everything is owned by "baron", etc. It supported fork but it's incompatible with threads, and everything on BeOS is threaded. Some signals are implemented, but the C API is home grown instead of the standard POSIX calls. Etc. They built a Unix facade but the system is very un-Unix like.
mmap could be emulated very easily via create_area(), and I think most people did this indeed.
> and no BSD sockets
BONE (an official R5 patch) had BSD sockets. There were also libraries for this also.
> it was absolutely nothing like /dev on any Unix system
What does this mean? Devices were in "/dev" could be opened, stat'ed, "dd"'ed to, etc. It had a different naming convention, but so does macOS and the like.
> No permissions; it's a single-user system. It stores file owners and modes, yes, but they don't actually mean anything; you don't need the +x bit to execute a file, you don't need the +x bit to list a directory, everything is owned by "baron", etc.
"baron" was just UID 0. I haven't looked in a while, but I'm pretty sure you needed +x to actually execute files? At least we mandate this on Haiku and it hasn't broken BeOS compatibility at all, as far as I'm aware of.
> It supported fork but it's incompatible with threads, and everything on BeOS is threaded
What does this mean? Its fork behaved the same way fork does on any other UNIX-like OS, i.e. only one thread carries over. The same is true in Linux...
> Some signals are implemented, but the C API is home grown instead of the standard POSIX calls.
Again, I don't know what you mean here. "glibc" was there, and so of course was malloc(), string.h, etc. etc.
Further, "UNIXy" does not mean "POSIX compatible." IMO the fork-based process model and "/dev" are the large hallmarks of the "UNIX philosophy". POSIX was a larger set of API calls that plenty of 90s-era UNIXy OSes did not ever implement.
Re: sockets. We both know BONE was never officially released because Be went out of business before Dano came out, that it was written to solve exactly the problem I described, and that Haiku picked it up because the networking situation without BONE is dire. Come on. I don't get the feeling that you're arguing in good faith here. If you know about BONE, you know that I'm not whistling dixie about the lack of sockets on BeOS being a problem.
Re: /dev. If the only thing similar to Unix is that it contains file-like objects (i.e. "can be opened, stat'd, dd'd to"), and everything else is different, is that really similar?
Re: +x to execute. I'm pretty certain BeOS didn't obey the +x bit, because I remember being surprised by it later when I migrated to a Linux system, but I'm too lazy to fire up real BeOS and not Haiku to check. I only have Haiku set up. Let's assume you're right.
Re: baron. He wasn't "just" UID 0. He was the only user -- you couldn't create others. I tried to create a multiuser addon for BeOS and gave up; you can't do much more than swapping home directories. I feel like you're seeing a facade they built and assuming an entire multiuser infrastructure is present, when they're just supplying whatever hardcoded information they need in order to make their POSIX facade work.
Re: fork. BeOS is so deeply multithreaded their marketing called it "pervasive". Linux is not at all; fork is the standard model for multiprocessing and most processes can happily be forked without issue. Almost nothing on BeOS forks because almost everything needs to use a thread at some point. You know this too; I really think you're playing dumb here in order to make your point seem more convincing. We both know that BeOS does not primarily use forking as its process model, and that fork's use is very rare.
Re: signals. BeOS doesn't have the same internal signal infrastructure as a POSIX system. The "Porting UNIX Applications" book has a whole chapter on how signals in BeOS are different from POSIX systems. The chapter treats signals as sort of a Venn diagram between BeOS and POSIX, where there is some common functionality in the middle, and then some BeOS-only stuff (SIGKILLTHR), some POSIX-only stuff (lots of signals not implemented in BeOS). BeOS's glibc is forked and heavily modified.
Indeed, I am very aware that POSIX and Unix are different. BeOS aimed for some level of POSIX compatibility via a facade, and it's not really very similar to Unix systems.
> and that Haiku picked it up because the networking situation without BONE is dire
Haiku is vastly more POSIX compatible than BeOS ever was (we have mmap, pthreads, posix_spawn, madvise, etc. etc. etc.) It is indeed compatible with both BONE and Net-API BeOS applications, but properly speaking our network stack is neither; under the hood it looks nothing like the BeOS network stack did (only NIC drivers are source-compatible for the most part.)
> I don't get the feeling that you're arguing in good faith here. If you know about BONE, you know that I'm not whistling dixie about the lack of sockets on BeOS being a problem.
Nowhere did I say it was not a problem. What I did say that a lack of them does not make BeOS "not a UNIX".
> and everything else is different, is that really similar?
What does this mean? Do you think that if there is no "/dev/sda", it's "not UNIX"? There was "/dev/zero", "/dev/null", "/dev/random", etc. What exactly are you asking for here?
> when they're just supplying whatever hardcoded information they need in order to make their POSIX facade work.
The point is that the facade is at least there; I think they were planning to add multiuser in a later release. (Haiku is still single-user on the facade, but under the hood you can useradd, chown, SSH in to other users, etc.)
> BeOS is so deeply multithreaded their marketing called it "pervasive". Linux is not at all; fork is the standard model for multiprocessing and most processes can happily be forked without issue.
Yes, obviously using fork() in an application that used the GUI would not make sense on BeOS. It doesn't make sense on Linux either; it's just that most "BeOS native" applications had GUIs. So what is the difference here?
> Almost nothing on BeOS forks because almost everything needs to use a thread at some point. You know this too; I really think you're playing dumb here in order to make your point seem more convincing.
My point is, again, not that "nothing used it", but rather that "this is how the process model works." I am not playing dumb here...
I didn't look at the details, but my understanding is that the Be-native API calls (e.g. BRoster::Launch) invoked fork/exec under the hood. So, again, simply "it's not that useful when you are using threads" is not the case here.
> The chapter treats signals as sort of a Venn diagram between BeOS and POSIX, where there is some common functionality in the middle
I haven't read the book; what's in the diagram? Is it just signal names e.g. SIGKILL, SIGTERM, etc.?
Only having some signals and not others does not mean it's "not a UNIX". If it talks like a duck, quacks like a duck, looks like a duck, but it's missing a leg and half its feathers ... it's still a duck.
> BeOS's glibc is forked and heavily modified.
Not really? They released the modified source due to GPL of course, and they mostly just removed stuff like mmap() or the like.
I think you're one or two generations late, you'd have to be a hipster to be a CS student worshiping C and Bell Labs these days. I suspect most CS students these days start around web technologies using VS Code in stock Ubuntu, not hacking C programs using Emacs running in dwm on a heavily customized Slackware.
I do agree that cat-v and the suckless folks should be taken with a massive grain of salt though.
I used to be a suckless person, not official, but I had branded them _my tribe_. I still appreciate them for their simplicity target, but the means and methods for me have changed.
When I first came across the UHH, my systems exposure was AmigaDOS, DOS, Windows 95, Windows NT 4, Ultrix, FreeBSD and Linux. I had never used VMS in any meaningful way (David Cutler is a well known Unix Hater) and the idea of "Hating Unix" was off putting because it seemed so useful, and the pain inflicted I internalized as my failing for not properly understanding it. I had no idea how much of a patched together mess it was. Hell, I think if we had continued using DOS that it would have eventually gotten a scheduler, memory protection, pipes and signals and then ended up in largely the same place.
At the part of the stack that most programmers are operating now, the operating system doesn't matter much. We can take the pain points from UHH and apply them to our own lack of system design.
Anecdotally, very few people buy Chromebooks as their primary college computer. Most people, irrespective of their major, need to work with Microsoft Office, sometimes some custom publisher software, etc. and nobody seems to thing that Chrome OS is up for this task. Plus, I feel like a "college computer" is a weighty purchase for many students, and buying a $200 Chromebook doesn't really seem right for this.
For computer science, the only people who buy Chromebooks are the people who install Linux on them or have another machine to SSH into.
> However I think it still has a valuable lesson that many, particularly young CS students, would benefit from: Unix is not the perfect fundamental model for computing. C is not the gospel.
The problem is, this book doesn't actually motivate that lesson. Instead, it spends a lot of its time sniping rather than arguing for why the entire philosophy is perhaps misguided or outright wrong. And sometimes, even the snipe targets are pretty idiotic: when complaining about C++ syntax, for example, the target isn't the incomprehensible nature of template rules [1], but one C++ compiler doesn't lex //* correctly.
[1] I'm not sure anyone actually understands how name lookups work when templates are in play. Instead there's a lot of guesswork and don't-shadow-names-if-it-might-matter going on.
> "The problem is, this book doesn't actually motivate that lesson. Instead, it spends a lot of its time sniping"
Yes but that sniping does a good job of deconstructing the historical revisionism that Unix was some beautifully architected thing, rather than something that's become less shit over time.
However I think it still has a valuable lesson that many, particularly young CS students, would benefit from: Unix is not the perfect fundamental model for computing. C is not the gospel. Their prevalence today is as much a historic and economic accident as a rational consequence of their objective merits. Both are social artifacts, not manifestations of fundamental truths.
Worshipers of Bell Labs (such as the cat-v or suckless folks) don't get this, and I've seen them pull a lot of people down that rabbit hole with them, particularly young and inexperienced students.