The Unix-Haters Handbook (1994) [pdf](web.mit.edu) |
The Unix-Haters Handbook (1994) [pdf](web.mit.edu) |
But in geoscience grad school just five or so years ago, a number of older, but technically minded professors were still using Sun machines, and most of the manuals for geoscientific software tend to provide supplementary information for other modern exotic systems/OSes, so I wonder: has windows replaced Unix as the technically inferior/evolutionary superior champion?
I know because I attended that school and worked with the fathers of Multics. The sad fact is that MIT produces extreme bloatware that nobody understands nor needs (gnu emacs cough cough). MIT has almost ruined unix with bloatware like 'configure' and gcc 'extensionettes'. The repeated rant about memory mapped files (a Multics bedrock feature) has been refuted as showboating hundreds of times by OS designers like my manager at Xerox OSD, the designer of Pilot, and an ex-MIT professor who never drank that Kool aid!
What's happening in OS's right now is that European bloatware is strangling Linux ... The reason Unix got people so thrilled is that it could 'terminate and stay resident' in one single human mind!
Say what you will about Multics, but it had essentially "no buffer overflows" [1], simply because it was written in a more memory-safe language (PL/I). (The stack also grew upward rather than downward iirc.)
It also had several nice features that I wish UNIX/Linux hadn't forgotten, even simple ones such as long names for commands (e.g. list-segments in addition to the 'ls' abbreviation.)
"Thirty Years Later: Lessons from the Multics Security Evaluation (2002)", https://news.ycombinator.com/item?id=16956386
Sure--the people who wrote systems with opposing philosophies to the "unix philosophy" are going to be the ones who write this book. And that they failed-in-the-market ("abortions") is already evident by the fact that HN is probably majority unix (mac) or unix-like (linux).
I confess I'm one of those people who has never used a lisp machine, and admires them greatly. I'd love to hear specific reasons I shouldn't admire them.
UNIX succeeded precisely because it was powerful and yet so simple a person could read any part of it and change it.
However, the kernel of UNIX is now beyond ken for most developers precisely because the developers pursued complexity and marginal features for marginal benefits, something very common in European governments and a part of that culture.
The shell commands went from maybe 50kloc to millions of lines precisely because the Linux developers were desperate for contributions and let MIT bloatware people control that part of the source code, strangling Linux with MIT culture.
The only way that makes sense is if they're referring to Lennart being German, but that's kind of a bullshit argument because SystemD was not some novel idea; launchd was around first and came from the American west coast.
Both your statement and my statement don't really mean anything.
Keep fighting the good fight, comrade.
https://github.com/ynniv/opengenera
you first have to get the opengenera sources, though. But they aren't hard to find.
As for userland.. Even OpenBSD, my personal preference of operating system and one which is known for its 'lean'ness of base userland has 10x this kloc in /bin/ and /usr/bin:
# find bin usr.bin | egrep '\.c$|\.h$' | xargs wc -l | tail -1
689562 total
coreutils$ find . | egrep '\.c$|\.h$' | xargs wc -l | tail -1
91991 total
Either way, that's not a mad amount of code imo... Which parts of this are 'MIT bloatware' ?
After years of dealing with systemd, I've finally given up on it, and I'm back on openrc.
(Yes, I know I'm not answering your question, but I'm not up to the task... ;P)
And still miss my Lisp Machine. It's not that Unix is really that bad, it's that it has a certain model of computer use which has crowded out the more ambitious visions which were still alive in the 70s and 80s.
Much as the web (the Unix of hypertext) crowded out the more ambitious visions of what computational media for intellectual work could be (see the work of Doug Engelbart and Ted Nelson). That's a bigger tragedy IMO. Unix, eh, it's good enough, but the shittiness of the web makes humanity stupider than we should be, at a time when we can ill afford it.
As the GNU coding standards say:
> Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility.
This never really clicked with me because I didn't live through a time when my primary Unix utilities weren't robust. The closest I got was using old (1990's) HP/UX and Solaris and AIX systems where the sysadmins had installed the GNU tools already. All I knew is that I shouldn't use the system tools, because they were worse.
Personally, I think what helped Unix succeed is that the implementations were bad but the architecture made it (mostly) possible to improve the implementations piecemeal. Accordingly, the parts that have had the most trouble improving (like X11, and C) are those where the design doesn't allow this.
What helped Unix succeed was that originally Bell Labs wasn't allowed to sell it, so they gave it to universities for what was a symbolic price in comparisasion what a standard OS used to cost, alongside its source code.
So naturally many stundents from those universities went out and started businesses based on UNIX, like Sun for example.
One of the reasons behing the BSD lawsuit was that AT&T got the license to charge for UNIX after Bell Labs was broken down into smaller units and they were trying to kill off those free branches.
People have a tendency to gravitate towards free stuff regarless how bad the quality happens to be.
But lately I’ve been studying systems that for whatever reason ended up losing out in the marketplace despite having really interesting design decisions and features that would be welcome today. Although I like the classic Mac OS, NeXT, and the modern macOS, I wish Steve Jobs would have “copied” all of Smalltalk and then added Mac-like touches to it. I also wish that Genera were open-sourced instead of the current situation where it’s difficult to obtain legally and inexpensively. I have a dream of writing a modern OS inspired by Genera, Smalltalk, and Apple’s OpenDoc, but writing a new OS is a major undertaking.
Maybe it’s my inner romantic speaking, or maybe I’m just drawn to beautiful things, but I’ve always been attracted to “what could have been” things. Hopefully one day we’ll have a “right thing” OS again, and maybe one day we’ll have an alternative to the Web that isn’t as much of a technology hodgepodge.
But then a rich library at university campus opened my mind to other models of computing and sundenly pure old UNIX wasn't that interesting any longer, only NeXT, which used UNIX compatibility more for winning over Sun's customers than anything else.
And there were mechanisms for an OpenDoc-like system of embedded content (maybe more like OLE). While the rough idea of OpenDoc was and is appealing, I don't think that version of the idea is actually tenable.
Alas, since it was killed, it sort of lives on and occupies that space as an ideal version of the rough idea, rather than as an artefact that can be criticised and improved upon.
25 years ago. Who the hell does that?
I heartily recommend his other writings. In fact, he considers "Worse is Better" some of the worst of his writings, and it is the most successful. ¯\_(ツ)_/¯
Just one that I've gotten a lot of mileage out of is "Habitability and Piecemeal Growth" in Patterns of Software. Lots of other gems in there: Reuse vs. Compression, The Quality Without a Name, etc.
EDIT: Forgot the link
This all happened before my time, but having read a lot about the Lisp Machine I'm as interested in the what-ifs of history if it had won out as the next guy.
I wonder though how much of the legitimate sentiment in this book is simply raging against a machine that's successful and installed in production.
Given widespread commercial use a system where you could modify the running Lisp code of any program down to the kernel would have had its own nightmare stories of sysadmins monkeypatching things in production, and e.g. the perceived shittyness of NFS being replaced by some Lisp-native system where you sent serialized Lisp objects for your program over the wire, with corresponding upgrade hassles if you needed to upgrade a client/server pair.
Plus it's too easy to "reinvent the language" in Lisp. In C-based languages, the block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent. In Lisp, one can roll their own. It's great if you are the lone reader: you can customize it to fit your head. But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop.
Here we are 25 years later and now UNIX is the "good" OS.
The horror.
-Chris
From Symbolics (Overview + Technical Summary):
http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/h...
http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/3...
Texas Instruments, Technical Summary
http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/explorer...
Xerox Interlisp-D Friendly Primer
http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/inter...
Too complex and takes too long to deliver.In the end, the winner takes it all.
your book is a pudding stuffed with apposite observations,
many well-conceived. Like excrement, it contains enough
undigested nuggets of nutrition to sustain life for some.
But it is not a tasty pie> Your sense of the possible is in no sense pure: sometimes you want the same thing you have, but wish you had done it yourselves; other times you want something different, but can't seem to get people to use it; sometimes one wonders why you just don't shut up and tell people to buy a PC with Windows or a Mac. No Gulag or lice, just a future whose intellectual tone and interaction style is set by Sonic the Hedgehog.
Ironically, Unix won yet here we are..
The authors use this convoluted bash script to show that pipes are best suited for simple hacks and might fail mysteriously under certain circumstances:
egrep '^To:|^Cc:' /var/spool/mail/$USER | \
cut -c5- | \
awk '{ for (i = 1; i <= NF; i++) print $i }' | \
sed 's/,//g' | grep -v $USER | sort | uniq
awk '/^To:|^Cc:/ { for (i = 2; i <= NF; i++) print $i }' /var/mail/$USER | \
sed 's/,//g' | grep -v myemail@exmaple.com | sort | uniq
By inverse grepping for myemail@example.com, there will not be mysterious behavior if $USER is in another person's email address.
To the contributers to this book:
I have succumbed to the temptation you offered in your preface: I do write you off as envious malcontents and romantic keepers of memo- ries. The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below. Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome.
Yet your prison without coherent design continues to imprison you. How can this be, if it has no strong places? The rational prisoner exploits the weak places, creates order from chaos: instead, collec- tives like the FSF vindicate their jailers by building cells almost com- patible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred. Your sense of the possible is in no sense pure: sometimes you want the same thing you have, but wish you had done it yourselves; other times you want something different, but can't seem to get people to use it; sometimes one wonders why you just don't shut up and tell people to buy a PC with Windows or a Mac. No Gulag or lice, just a future whose intellectual tone and interaction style is set by Sonic the Hedgehog. You claim to seek progress, but you succeed mainly in whining. Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.
Bon appetit!
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.
It's a cynical UNIX manual from the 1990's. Here:
> 14 NFS..............283
> Nightmare File System
> Not Fully Serviceable............284
> No File Security...........287
> Not File System Specific? (Not Quite)..........292
Here also:
> The Oxymoronic World of Unix Security .......243
> Holes in the Armor ........244
> The Worms Crawl In ..........257
I work in IT systems development in a University IT department. I want to read this take on UNIX from 1994, just to see how much better things haven't gotten.
OK, the state of the art has gotten better, but if I compare my work environment which is byzantine complexity and full of bespoke garbage sometimes, to the hells apparently described herein, I bet I can find more similarities than differences.
And that will hopefully make me a more effective communicator about how to make things better with modern convenience technologies that we're not using enough. (Dare I say Kubernetes is the one big thing that is actually majorly different today, compared to UNIX in the 1990's.)
Most of what's on the book has been fixed (not NFS, this one is forever), and we have an entirely new set of things to worry about.
The book is funny, but every part of it feels old.
"We wrote the contract with our publisher to have the copyright revert to us once the book went out of print. So yes, we have the right to publish it online. Feel free to mirror it where ever you want, print it out, and bind it."
I think it's a good book and worth reading still, if not especially, in the modern world where to many people Unix and its family are the hot "alternative" that is often favourably compared against Windows and its ilk.
But I also think that Ritchie's "anti-preface" was already quite on-the-nose when the book came out and has only become more true over time.
But how things change. This was before macOS became BSD-based and before I really got into web development because today, I spend so much time at a shell prompt inside of the Terminal app. I certainly appreciate the elegance of Unix a lot more today.
"We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such a database service or computation service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the application is running,” and when you see “server” think “the local machine that dis- plays output and accepts user input.”
Sigh.
Highly recommended.
I found the commentary and history both hilarious and informative. The anti-forward by Dennis Ritchie is also very funny.
If anyone has found similar CS style humor books, please let me know!
> Applicants must also have extensive knowledge of Unix, although they should have sufficiently good programming taste to not consider this an achievement.
I got my second ever hard disk drive through her employee-purchase discount. Eighty megabytes!
It came with a vomit bag.
Try unixux. Really.
And what's funny is, some of the things it criticizes are features I'd not heard of and actually learned from the book itself. E.g. bare double dash.
>C is not the gospel
>Worshipers of Bell Labs
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.
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.
More likely, Visual Studio Code on macOS.
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.
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.
All you really need to figure out for that is what a "dependent name" is. And that has a very straightforward definition.
For computer science, the only people who buy Chromebooks are the people who install Linux on them or have another machine to SSH into.
It is only a thing on US school system.
And now with latest changes at Google, eventually not even that.
Unfortunately Procyon Common Lisp was taken off the market, when it was bought by Franz, Inc. They used the Windows version of Procyon CL as kind of a starting point for their Windows offering of Allegro CL, IIRC.
There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this.
The C function definition doesn't have an operator which would help me to identify what it actually is.
float square ( float x )
{
float p ;
p = x * x ;
return ( p ) ;
}
(defun square (x)
(* x x))
Or with types/classes:
(defmethod square ((x float))
(the float (* x x)))
The names and lists may not tell you much, but to a Lisp programmer it signals the operation and the structure of the code, based on typical code patterns.
Once we learned basic Lisp syntax this is the usual pattern for definitions:
<definition operator> <name of the thing to be defined> <parameters>
<body of definition>
<define function> <name of function> <parameter list>
<declarations>
<documentation>
<body of definition>
> block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent
These are also hardwired in something like Common Lisp. But the general language is differently designed. Common Lisp has relatively few built-in basic syntactic forms (around 30) and the other syntax is implemented as macros.
> It's great if you are the lone reader: you can customize it to fit your head
Over the decades of Lisp usage a bunch of conventions and some language support for common syntactic patterns have emerged. It is considered good style to follow those patterns.
> But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop.
That's the same problem everywhere: the new control structure implemented as a Lisp macro is the new control structure in any other language implemented by a bunch of different tools (macros, preprocessor macros, embedded languages, external languages, a web of classes/methods, a C++ template, ...).
If you add a new abstraction, there is always a price to pay. In Lisp the new language abstraction often gets implemented as a new macro and may hide the the implementation behind a more convenient form.
It still stands that "}" indicates larger-scale structures than ")" in C-like languages. Lisp has nothing equivalent, and I find a visual way to identify forests versus trees without first reading text is quite helpful. Your eyes may vary; everyone's head works differently.
But as evidence people agree with me, lisp had roughly 60 years to try to catch on as mainstream. It didn't. Nothing had more opportunities. If you don't win any beauty contests after 60 years, it's time to admit you are probably ugly to the average judge.
prog, let, defun all indicate block structures.
> Your eyes may vary; everyone's head works differently
No, it's just training. You are just unfamiliar with Lisp code. After a few days training, you should have little problem reading Lisp code. It's like bicycle riding: people can't believe that it is possible to balance it, but after a few lessons it's no problem.
That's an old saying:
'Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days.' (Marvin Minsky)
> There’s only one problem with a connectionless, stateless (file) system: it doesn’t work.
> Example #1: NFS is stateless, but many programs designed for Unix systems require record locking
> Example #3: If you delete a file in Unix that is still open, the file’s name is removed from its directory, but the disk blocks associated with the file are not deleted until the file is closed.
(Example #2 is a non-issue)
The security is still lacking, and the system still can't handle failures.
Yet, yes, it's faster, easier to set-up, and more widely supported than the alternatives.
* https://en.wikipedia.org/w/index.php?diff=385927363&oldid=38...
There has been a lot of literature published on the problems with NFS, and the mismatch with POSIX file semantics, since 1988. Some of it was even in the original paper from Sun, in fact. To this day, Wikipedia has nothing on the subject. The words "stateful" and "stateless" appear once each in the entire article, with no indication of their pivotal importance, made much of in the actual literature on the subject.
If it were really Unix, they probably would not have needed to write a whole book on porting Unix applications: https://www.amazon.com/BeOS-Applications-Martin-C-Brown/dp/1...
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: /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.
AIX, non-free, was notoriously horrible, too.
And the Wirth systems that you promote here were actually free.
So what exactly is the great stable commercial alternative in the 90s?
In the mainframe world, TOPS-10/20 and VMS were both exemplary. From the user POV, the former was one of the best command-line systems ever created, with none of the insane user-hostility built into UNIX command naming. Dave "VMS -> NT" Cutler absolutely hated Unix, and it shows.
But we're really comparing cinder blocks and potatoes. UNIX was designed as a hobby/student hacker tool, not as a general user OS. Many of the design choices are bizarre and frankly stupid, as the book delights in pointing out. But hackers love UNIX because using it just it feels just like hacking code, and that's considered a good thing.
It wouldn't be impossible to design an OS with powerful command line options but a sensible command naming system, much more intelligent and reliable security, a modern filesystem, and so on - and perhaps add some of the user configurability and extendability of the Lisp/Smalltalk/Hypercard(?) world.
But UNIX is so embedded now it would be a purely academic exercise.
I guess I'm less pessimistic, because I don't think that's true. I think there are quite a few people like me who are fed up with the shit that exists today and really want a good alternative. I think we'd be willing to make quite a few sacrifices for something with a whole lot of potential.
What seems to be true is that there are very few people both capable of making that happen and bold enough to try to make it something people can actually use instead of just a toy academic project.
OS/2 was pretty solid...
Workplace Shell was so cool though.
In fact, GCC only got traction after Sun introduced the idea in the UNIX world of selling the developer tools instead of bundling them wiht the OS.
Back in 1994 the Wirth systems were mostly only available at ETHZ.
Had Linux not come up into the scene, with the ongoing BSD lawsuit, and the UNIX landscape would have looked much different nowadays.
[1] - "free" here meaning several factors cheaper than buying a VMS or OS/360 timesharing system for the university campus.
Where does the MS operating system fit in here? Arguably the worst general-computing OS, but by far the most popular. For purpose of discussion, do you consider it free due to being widely pirated?
I'll say that the developer experience on Windows was excellent around the 1995-2005 timeframe. But the user experience was horrible, yet it remained an almost monopoly on the desktop.
Obviously it’s great in a VM!
Regular consumers just handle their computers like appliances, getting a new one with whatever OS it gets bundled with.
The monopoly worked both ways, any OEM was free to ditch Microsoft agreements, they just cared to improve their profits by getting into bed with Microsoft.
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.
Of course OS/2 was later severely hampered by its inability to run Win32 apps, but that's another story.
Find a proper key for your edition here: https://docs.microsoft.com/en-us/windows-server/get-started/...
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /skms kms.digiboy.ir # just an example of many KMS servers that exist
slmgr /ato
2. Installing kmspico requires admin access to your machine. What kmspico does is that it installs a local KMS server which works the same way the remote KMS server I've suggested to use does: it activates everything you throw at it. But as I said it needs admin access to your machine, and it's up to you whether you trust kmspico or not.