The everything-is-a-file principle – Linus Torvalds
yarchive.net
yarchive.net
MsgSend is a more useful primitive than a file. It's a subroutine call across processes, a better fit to anything that isn't stream I/O. In most OSs, you want a subroutine call, but the OS gives you an I/O operation. Linux has to stand on its head for operations such as getting all the properties of a pluggable device, because returning a variable length array of fixed-format records as an atomic operation isn't a Linux primitive.
Microkernels have a bad reputation because interprocess communication in Mach was botched. Mach was built on BSD. To do this right, you have to design CPU scheduling and message passing together, and they need to be tightly coupled. The key to interprocess communication is arranging the normal path for a message pass to throw control from one process to another without a trip through the scheduler. Get that wrong and your microkernel will be sluggish.
xnu is a hybrid of Mach and FreeBSD. To be super-concrete, it has both sets of syscalls, with Mach syscalls as negative integers, and BSD syscalls as positive integers. A given running executable has a dual existence as both a BSD pid_t and a Mach task_t. At one point it was even possible to have a Mach task without a pid.
Most executed syscalls are BSD: read, write, select, getpid, etc. However Mach still plays a role in the VM system (`vm_copy`, etc.) and crucially via the IPC workhorse `mach_msg`.
It's hard to overstate the importance of mach_msg. It underlies the great macOS IPC primitives: xpc, notify(3), etc. Linux looks anemic by comparison with its limited pipes, creaky SysV sendmsg(), and DBus (hope you never have to use it). But it also appears that Apple is preparing to drop Mach: mach_msg / MIG is buried, xpc is conspicuously designed to be separable from Mach, etc.
Why? What benefits do they have to drop it ?
It's a low level RPC mechanism, it does reschedule to the new process immediately without a trip through the scheduler when it's used, it has similar blocking semantics, etc.
It's also worth following the "bus1" work for linux which may end up being quite similar as well.
The most striking thing about running QNX on the desktop was the absolutely consistent response. It doesn't page, so everything is in memory. Going back to Linux felt so laggy.
You pay about a 10%-20% overhead cost for all that interprocess communication. It's not a big deal on modern processors, because when you send a message, the receiving process is running on the same CPU and the data is usually in L1 cache since the sender just put it there. So copying is cheap.
Incidentally, all the Boston Dynamics robots run QNX. They're coordinating all those limbs and valves from one CPU. It's not distributed; that would be too uncoordinated. Valve update is at 1KHz; balance update is at 100Hz.
Was it ever really open? I can't find copies of any version (regardless of how old)
QNX is doing well in automotive.[2] QNX is the part of Blackberry that's making money.
[1] http://www.qnx.com/news/pr_2471_1.html [2] http://canada.autonews.com/article/20180622/CANADA/180629921...
QNX does include features to control this but you have to know enough about it to realize you want them. And POSIX priorities are not enough to prevent this from happening because they are solving a different problem.
You might find it useful in servers where controllable latency is more important than responsiveness, but I wouldn't use it in a user-driven workload like a desktop OS without very carefully configuring it. Out-of-the box it can be very unstable.
- GenodeOS is reportedly used in production by some commercial clients, though mostly undisclosed IIRC; it is a higher-level layer (~OS) compatible with numerous microkernels
- Fuchsia OS - in dev; it's a recent development by Google; as much as Google is officially silent about it (I understand they're not sure how the experiment will work out for them), observers assume it's most probably hoped to be used as a successor to Android
- Redox OS - in dev; no concrete news of mainstream usage plans I know of, but has some mindshare among developers
- Minix 3 - used in production; infamously by Intel in their IME
- There is a per-thread IPC zone of 0x100 bytes. When doing IPC, the request is serialized and put into this. If bigger data than 0x100 bytes is necessary, pointers are passed around, and the Kernel maps it into the process servicing the call. - svcSendSyncRequest is used to call an IPC. It is a synchronous API that will block until the process servicing the call replies to it. - svcReplyAndReceive is used to receive an IPC request and reply to a request, and then wait until a new one is received. The syscalls are "merged" into a single one to avoid the syscall overhead: Almost all svcReply will be followed by an svcReceive, so merging them into a single call makes a lot of sense.
You can find more information about the SVCs at [1] and the IPC layout at [2].
[0] Preempting the "I thought the switch used BSD": wikipedia was wrong, the OS is completely custom, and the kernel is tailor-made. [1] http://switchbrew.org/index.php?title=SVC [2] http://switchbrew.org/index.php?title=IPC_Marshalling
A little note about this: Horizon/NX actually traces back to the Horizon OS on the Nintendo 3DS. The IPC marshalling was significantly more simple back then[1]. In all honesty, I'm not sure what made Nintendo thing the IPC marshalling on the NX was a good idea; to me it just looks like a hastily-designed mess (cf. "This one is packed even worse than A, they inserted the bit38-36 of the address on top of the counter field." on the [2] page linked by the parent comment). However, the NX incarnation was designed with "naturally" wrapping C++ methods in mind and it does a fairly decent job at that.
[1] https://www.3dbrew.org/wiki/IPC#Message_Structure
(Shoutouts to 3dbrew actually realizing that HTTPS is a thing that exists and maybe should be deployed.)
Are they symmetrical philosophies? As a layman, this appears to mirror the financial debate between everything being stocks (“the quantum of an economy is a dollar of assets!”) and everything being flows (“the quantum is a transaction!”), or physics’ particle-versus-wave formulations.
Thanks for opening me up to this issue.
https://unix.stackexchange.com/questions/11402/why-does-esc-...
>Why does `ESC` move the cursor back in vim?
>In insert mode, the cursor is between characters, or before the first or after the last character. In normal mode, the cursor is over a character (newlines are not characters for this purpose). This is somewhat unusual: most editors always put the cursor between characters, and have most commands act on the character after (not, strictly speaking, under) the cursor. This is perhaps partly due to the fact that before GUIs, text terminals always showed the cursor on a character (underline or block, perhaps blinking). This abstraction fails in insert mode because that requires one more position (posts vs fences).
>Switching between modes has to move the cursor by a half-character, so to speak. The i command moves left, to put the cursor before the character it was over. The a command moves right. Going out of insert mode (by pressing Esc) moves the cursor left if possible (if it's at the beginning of the line, it's moved right instead).
>I suppose the Esc behavior sort of makes sense. Often, you're typing at the end of the line, and there Esc can only go left. So the general behavior is the most common behavior.
>Think of the character under the cursor as the last interesting character, and of the insert command as a. You can repeat a Esc without moving the cursor, except that you'll be bumped one position right if you start at the beginning of a non-empty line.
Also:
https://superuser.com/questions/242156/make-vim-normal-mode-...
>Make VIM normal-mode cursor sit between characters instead of on them
>I would really like it if the VIM cursor in normal mode could act like it does in insert mode: a line between two characters. So for example:
>- Typing vd would have no effect because nothing was selected
>- p and P would be the same
>- i and a would be the same
>Has anything like this been done? I haven't been able to find it.
>Answers:
>The idea that the cursor is always on a line and on a character position or column is inherent in Vim's design. If you were to try to change that, many of Vim's operations would behave differently or would not work at all. It's not a good idea. My advice would be that you learn and become accustomed to Vim's basic behavior and not try to make it behave like some other editor. – garyjohn Feb 5 '11 at 23:55
>What you want is not Vim, I'm afraid. – romainl Feb 6 '11 at 7:15
And people wonder why I still use Emacs...
https://softwareengineering.stackexchange.com/questions/4659...
>"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)." -Alan Kay
NeFS -- aka NFS 3.0 -- used a PostScript interpreter as the file system API.
Plan 9 had a different view IIRC, something like everything has a protocol.
There's a common trait among many objects: you can read a sequence of bytes from it. Disk files, sockets, various input devices, random number generators, etc. There's another common trait, writing a stream of bytes. Another, even more common pair of traits, is "opening" and then "closing" something.
All of them can be described using interfaces / traits to clearly communicate which sets of operations are applicable to which objects.
This e.g. can be neatly used to describe the "many things are a file" idea:
File passwords_file = Filesystem.make("/etc/passwd");
Readable password_readable = passwords_file.openRead(); // Could be openWrite().
Process zcat_process = Processes.make("zcat /tmp/something.gz");
Readable zcat_stdout = zcat_process.stdout.openRead(); // Can only be openRead().
ClientSocket sock = Network.makeClientSocket(host, port, options); // Unlike a file.
Readable sock_readable = sock.openRead();
for (Readable r in [password_readable, zcat_stdout, sock_redable]) {
byte b = r.read(); // Read one byte from each, no matter what it is.
}
Since traits / interfaces can't have their methods overridden, you don't need the dynamic dispatch, per-instance VMT, and such; you can have fixed offsets in a method table per class, both in userland and in kernel. (Some of the indirect calls can probably be made direct if the class is exactly known at compile time.)
Rust has this built-in (lifetimes and move / borrow semantics); I suppose C++ can model this, too.
Windows does just that with their PowerShell. Here’s an example that copies a file remotely on the server:
Invoke-Command -ComputerName SERVER -credential USERNAME
-ScriptBlock { Copy-Item -Path C:\Temp\1.txt -Destination C:\Temp\2.txt }
> In Windows, you have 15 different versions of "read()" with sockets and files and pipes all having strange special cases and special system calls.
That's not correct. ReadFile can be used for all kinds of objects, including sockets: https://docs.microsoft.com/en-us/windows/desktop/api/fileapi... Yes, it behaves differently depending on the type of the object, but so does read(2) (E.g., you'll never get SIGCHLD when reading from a file, for example.)
In any case, he's very rash to call out Windows when Linux has its share of special-purpose syscalls that do the "same" thing (e.g.: send, sendv, sendmsg, sendfile, sendmmsg, …) with myriads of options to alter their behavior.
It also means that POSIX doesn't constrict you -- it gives you the tools to build rocksdb, sqlite, etc and have them be performant.
https://sqlite.org/howtocorrupt.html
It's a bad sign if you have to repair the shortcomings of a lower layer in your application.
The workarounds seem to have more to do with SQLite's use as an embedded library than with filesystem behavior.
All of section 1 is about rogue overwriting. Absent a particularly fine-grained filesystem permission model, or enforced locking. The former might only have "freedom" implications without any performance penalty, but perhaps not the latter.
Section 2 is about locking, so see above. Even if it's advisory, that just moves any slowdown from the kernel to the application. Of course, broken locking is clearly a shortcoming, and this is one of the quirkiest (maybe newest?) aspects of the filesystem. If anything qualifies under the "bad sign" characterization, this does. However, it's also not exactly fundamental to the filesystem, as even section 2.3 describes what SQLite will do if POSIX adivsory locking is not supported over NFS (i.e. it is possible for locking to be unavailable).
The remaining sections all appear to be about bugs, either hardware, thread library, elsewhere in the kernel, SQLite itself, or in configuration/usage (disabling corruption protections).
Of course, disk drive protocols also constrict you, relative to having direct control of firmware and visibility over raw flash devices, drive head position, etc. For example, it would be neat if you could send block A and block B to the disk at the same time, only to have the disk compute the checksum of block A and put it at offset k of block B before writing block B.
If it gave you that, it wouldn't be a standard anymore, just a bunch of instructions to talk to hardware.
So, of course it constricts you in some degree, but way lesser than the higher order abstractions the parent talk about.
POSIX I/O is like C. It's super powerful. It's everywhere. It's not going away. But it has sharp edges. And we can sacrifice a little efficiency on the small scale to grab huge gains in other areas like productivity and reliability.
Also relevant is Glenn Lockwood's excellent article on What's bad about POSIX I/O: https://www.nextplatform.com/2017/09/11/whats-bad-posix-io/
The resource fork was a beautiful idea; structured data built into the filesystem itself, and I wonder what the computing world would have looked like if it was used by the dominant operating system of the Internet instead of a sideshow.
Or operating on directories instead of files, like MacOSX bundles (like .app and .rtfd)?
They’ve both got their place IMHO and vive-la-difference :)
http://www.acontinuouslean.com/2013/04/05/a-better-way-to-sc...
You won't get Crysis running out of it.
Plan 9 used the file metaphor to achieve things like network transparency, which is a situation that precludes the use of mmap. (Though you could organize an OS to make it work that way.) If you just want to get access to a framebuffer as a memory-mapped resource, old style, there's no good reason for files to be involved.
That's an implementation detail.
I think, given the post we are commenting on, it is OK to distinguish these things. Historically, framebuffers are packed arrays of pixel values, and files aren't necessarily even seekable. These are well established norms.
You could argue that the real interface for writing to an image/screen should involve two-dimensional locations, instead of a linear offset. This is what Plan 9's draw facility proposed, along with alpha compositing operators. That is certainly also a question of interface, but one at a higher level.
So I don't agree that "write X at offset Y" is the ultimate, universal highest-level abstract standard for drawing on a raw raster image. It's more like an implementation detail from my point of view, actually :D
A file is a byte stream with some metadata - i.e. permissions. With such an API you can really do anything.
The command queue would be a write- and append-only pipe, containing of state setup commands and rendering, in some format that could be efficiently transformed by the driver into the actual commands that would get sent to the GPU, since this hypothetical queue would probably be GPU-agnostic. (I think this was how D3D9 worked internally, and that may still be true for more modern versions...)
(You wouldn't have commands for modifying buffers. That would be just something you do yourself by accessing the buffers. As the creator of the buffers, you know where the data is inside them, so you'd just replace the data in question with new stuff.)
Anyway, even if in practice this wouldn't be optimal, it could probably be made to work well enough. A file-based approach is at least not ridiculous to imagine.
"But what would you _do_ with them? What would be the advantage as compared to the current situation?"
Here is one answer (2008):
"This paper presents PipesFS, an I/O architecture for Linux 2.6 that increases I/O throughput and adds support for heterogeneous parallel processors by (1) collapsing many I/O interfaces onto one: the Unix pipeline, (2) increasing pipe efficiency and (3) exploiting pipeline modularity to spread computation across all available processors. PipesFS extends the pipeline model to kernel I/O and communicates with applications through a Linux virtual filesystem (VFS), where directory nodes represent operations and pipe nodes export live kernel data. Users can thus interact with kernel I/O through existing calls like mkdir, tools like grep, most languages and even shell scripts. To support performance critical tasks, PipesFS improves pipe throughput through copy, context switch and cache miss avoidance. To integrate heterogeneous processors (e.g., the Cell) it transparently moves operations to the most efficient type of core"
Sounds pretty good to me!
https://research.vu.nl/en/publications/pipesfs-fast-linux-io...
This results in systems being built ontop of narrow file-as-everything service, providing a wider interface to real data(events,sockets,pipes,messages,async IO).
Of course, people don't like it and build libraries to bypass it(and even the kernel layer itself https://blog.cloudflare.com/kernel-bypass/ ) just because the interface is inherently limited and inflexible.
Not as fun as a kernel module, though :-)
NeWS differs from the current technology stack in that it was all coherently designed at once by James Gosling and David Rosenthal, by taking several steps back and thinking deeply about all the different problems it was trying to solve together. So it's focused and expressed in one single language, instead of the incoherent fragmented Tower of Babel of many other ad-hoc languages that we're stuck with today.
I summarized the relationship of NeWS with modern technology in the wikipedia article:
https://en.wikipedia.org/wiki/NeWS
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
- used PostScript code instead of JavaScript for programming.
- used PostScript graphics instead of DHTML and CSS for rendering.
- used PostScript data instead of XML and JSON for data representation.
Here's an article I am in the process of writing about the most amazing thing ever done with NeWS, which was inspired by HyperCard:
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
>SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))
>HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!
Another thing that REALLY inspires me, which goes a hell of a lot further than NeWS ever did, and is one of the best uses of JavaScript I've ever seen, is the Snap! visual programming language!
It's the culmination of years of work by Brian Harvey and Jens Mönig and other Smalltalk and education experts. It benefits from their experience and expert understanding about constructionist education, Smalltalk, Scratch, E-Toys, Lisp, Logo, Star Logo, and many other excellent systems.
Snap! takes the best ideas, then freshly and coherently synthesizes them into a visual programming language that kids can use, but is also satisfying to professional programmers, with all the power of Scheme (lexical closures, special forms, macros, continuations, user defined functions and control structures), but deeply integrating and leveraging the web browser and the internet (JavaScript primitives, everything is a first class object, dynamically loaded extensions, etc).
Here's an excellent mind-blowing example by Ken Kahn of what's possible: teaching kids AI programming by integrating Snap! with existing JavaScript libraries and cloud services like AI, machine learning, speech synthesis and recognition, Arduino programming, etc:
AI extensions of Snap! for the eCraft2Learn project
https://ecraft2learn.github.io/ai/
>The eCraft2Learn project is developing a set of extensions to the Snap! programming language to enable children (and non-expert programmers) to build AI programs. You can use all the AI blocks after importing this file into Snap! or Snap4Arduino. Or you can see examples of using these blocks inside this Snap! project.
https://github.com/ecraft2learn/ai
http://lntrg.education.ox.ac.uk/presentation-of-ai-cloud-ser...
Imagine byte-level access to a directory. You'd have to have some library in userspace that would correctly be able to manipulate that directory's metadata. Now imagine doing that for various filesystems.
Plan 9's namespaces and file-servers were pretty awesome and flexible. It really opened my eyes to the generality of the file abstraction.
I mean, as far as I see it, the directory is still a file, of a specific format.
How is that any different than an image file, say, of a particular format? You still need specialized programs in order to manipulate them in a meaningful way. But they're just bytes. Just like the directory is just bytes.
The difference, of course, is that allowing the user to arbitrarily manipulate a directory entry at the byte-level could lead to filesystem corruption.
I'm aware I may be missing something really obvious here. Heck, even contradicting myself :)
Educate me :)
On Linux? You `open()` a directory, and `getdents()` takes that file descriptor as input.
“These are not the interfaces you are interested in. Look at readdir(3) for the POSIX-conforming C library interface.” — getdents manpage
There are a few (redundant/duplicated with minor feature differences in triplicate, 'cause it's Linux) file-ish abstractions over parts of those concepts, but those abstractions are neither the only, recommended, or most widely used means of accessing those functionalities.
I believe that Windows' HANDLE is closer to the correct abstraction.
from proc(5) :
/proc/[pid]/mem This file can be used to access the pages of a process's memory through open(2), read(2), and lseek(2)
Of course the abstraction maps varying degrees of well, but it also simplifies the hell out of the lion's share of the ways we interact with computers, and serves as a foundation for the rest.
The on-disk notion of a file sits atop layers of that abstraction. It doesn't, for example, go away when you `rm` it. An entry in a table does, but if some other process had that (disk) file open at the time, its data is still there, readable — and recoverable — through the former file's entry under that pid's /proc/$pid/fd/.
Aside from waiting, I'd say passing/referring to the objects being operated on is also a commonality. Passing a FD to a child process, for example, or giving it (the object, be that a file/pipe/socket/timer/process/etc.) a name in the FS s.t. other things can refer to them by name. (I personally wish though that fork()/exec() had forced you to specify exactly the set of objects (files/etc.) for the child to avoid the entire multithreading/close-on-exec/atomic flag setting hell that exists today.)
I don't know that read/write are actually abstract at the level of a "file descriptor" though. Eventfds and timerfds both support them, but it feels forced. Pipes are one-way, so one of read/write don't make sense, and seek on pipe doesn't either. I think some file descriptors (child classes of a generic "object"/FD/HANDLE, such as files) support read/write, but not necessarily all FDs support read/write/seek.
* Closing the handle: Release any kernel resources associated with the the handle
* Comparing to other handles
* Duplicating, e.g. duplicating a handle to be used by another process. This allow a process to create a less privileged process and only pass handles with certain privileges to the process.
* Get/set handle flags, e-g- flag which indicates whether the handle will be inherited by child processes.
For each object type a number of object type specific operations can be used in addition to the above, e.g. file read/write for files or send/receive for sockets.
Regardless of whether a handle is for a file, a socket, window, mutex or something else, the generic functions such as close will always work.
https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Rende...
Really it feels more like 'what is the hierarchical structure of my namespace' because once you nail that down, the file semantics become clearer. if its async io under the class of io its open("/io/async/my-thing", ...)
So its one of those yes.. but its so hard to nail it down moments.
> If you can read on it, it's a file.
Um, no. If you can SEEK on it, it's a file. If you can't, it's a socket or a pipe.
> In UNIX, a file descriptor is pretty much anything. You could say that sockets aren't remotely file-like, and you'd be right. What's your point?
The fact that you can't seek on a socket is irrelevant to the thread, which is about accessing files, not navigating them.
Sure, but that doesn't mean he doesn't occasionally make a mistake.
> In that message, he's talking about...
Yes, I know. But the larger context is Linus debunking (correctly) the unix philosophy that "everything is a file". Linus is correct: it is not the case, never has been the case, nor should it be the case, that everything is a file. But then he undermines his own argument with the (mistaken) claim that "if you can read it, it's a file." No. There's a salient difference between files one the one hand, and pipes and sockets on the other, and it has nothing to do with whether or not they have names. A named pipe is still a pipe, not a file. "Files" in /dev are not files, neither are "files" in /proc, despite the fact that they have names.
It's a detail, but an important one in the larger context IMHO.
Yes, the wording around "file" is a bit ambiguous, because Unix has a major design philosophy that said you can treat non files as files as get a lot of mileage, but didn't call those things "fauxles" or something instead.
No, it's quibbling pedagogy.
> Yes, the wording around "file" is a bit ambiguous
Exactly. And this can be a real problem when people are first learning about unix.
In fact, it can be a real problem even after that. Just the other day (true story) I was trying to debug some server latency issues and I asked one of our sysadmins for help. He suggested that I run lsof to help debug the problem. I told him I was pretty sure that wouldn't help because all the evidence indicated that the problem was with a rogue process, not a file, and he said, "This is unix. Everything is a file."
Kill? Possibly kill -9?
:-)
ps: jokes aside, I do believe that if the filesystem as machine representation was enforced and design with good sense and average joe in mind, you'd probably not even need man (pardon the hyperbole)
ioctl(sock_fd, SIOCSIFADDR, &ifreq_pointer);
Generally I think there's some cases where they try to push too much through limited interfaces, e.g. ptrace feels like "ok, we have an API already, lets push this unrelated functionality through it too so we don't have to design and add a new one"
If we're cheating by using file descriptors instead of files, then you could go all the way and used AF_NETLINK sockets, they allow you even to set routing or firewall. That's kind of not the point.
What was it about the mantra again?
(I did upvote you btw)
It matched Plan 9 (which is really Unix V9) really well …
Aren't netlink sockets files, and used for setting IP addresses?
The same can be said for files in '/dev/input'. Why are mouse and touchpad input exposed as files?
In the email you quote, Linus gives two reasons why futex and sockets should not be files:
> there's absolutely no point in opening /dev/futex from a shell script or similar, because you don't get anything from it.
> Perhaps because you cannot enumerate sockets and pipes?
It stands to reason that the converse of those _are_ reasons to make things a file:
I can open /dev/input/$X and get something from it. The normal thing to do is open a file under /dev/input/ and read data from it. No, we don't usually do that directly, because libinput does it for us; but that's what it's doing. As an exception, if code deals with joysticks, it seems to me that it's common to open /dev/input/js$X yourself.
I can list the entries in /dev/input/ and enumerate the input devices attached to the system.
This kind of out of context discussion that gives rise to comments like yours seems far worse than anything he has said.
How many CEOs have managed companies out in the open for 15 years plus without ever losing their cool? There is no way to know as there is no transparency.
That's because only messages in which he is yelling at someone get posted here. AFAIK, most messages he posts are neutral, but these are boring, so they don't get posted here. I just scrolled through LKML and found a random example of his normal tone (https://www.spinics.net/lists/kernel/msg2852881.html):
"So none of the patches looked scary to me, but then, neither did earlier versions.
It's the testing that worries me most. Pretty much no developers run 32-bit any more, and I'd be most worried about the odd interactions that might be hw-specific. Some crazy EFI mapping setup or the similar odd case that simply requires a particular configuration or setup.
But I guess those issues will never be found until we just spring this all on the unsuspecting public.
Linus"
You're quiet right that Mr. Torvalds is not in some permanent state of rage and does not respond inappropriately to all, maybe even most, messages on the lkml. But the fact remains that he and thus his project have a serious problem with hostility. I could understand flipping out on someone who was paid to do a job and didn't even try, someone who was deliberately introducing bugs, etc. But a simple disagreement between highly intelligent and dedicated FOSS developers never calls for this sophomoric behavior.
Almost all organizations are highly dysfunctional...and in my experience particularly the ones that are intolerant of passionate discussion.
Example https://www.phoronix.com/scan.php?page=news_item&px=mty1mza
Glass door estimates Kay is presumably paid 80-160k for this work and people have somewhat a right to be angry if code like this is pushed.
However, your attitude is kind of what Linus intends to instill in those easily deterred by such behavior. He's not interested in your contributions if you're going to be a thin-skinned child about the development process and ongoing maintenance. Your contributions won't be perfect, and he's not interested in having to waste time beating around the bush in telling you so.
"... and a black star for being stupid"
Think about it this way: A dictator has to be extremely assertive because if he said "No, I don't want that in Linux" with no basis, he'd eventually lose his dictatorship power as people would form their own "unions" to try to change things, making several directionless forks of Linux. If he instead said, "This is a completely idiotic approach and anyone that thinks it's okay is braindead," nobody would question it and most people would just take his word for it. Most heated debates have an equal number of supporters for each side, and it takes someone with a strong voice to remind them that one decision must be chosen regardless.
Lying about things and people is a bad way to force people to accept decisions. Calling someone or something stupid isn't a technical argument, it's a poorly worded conclusion.
Just a hypothesis; I've never met either one and never been a BDFL either.
I can't speak to how Linus's personality has changed over time, but for a 27 year old software project, I'd say it hasn't impacted sustainability.
Some of the other comments here have mentioned, but it bears repeating: this is not the "normal" Linus. He doesn't rant 100% of the time, but when he does, you had better pay attention because it must be something very important.
Most people are never forced to deal with enough people, to regularly be forced into extended contact with this particular kind of person. The kind of person who is forced to deal with enough people that they are likely to inevitably, eventually have to work with such people, is what we usually refer to as "a politician." But that's not quite accurate.
See, elected politicians learn to hide their distaste for such people, and that's how we get our sense of what it means to "act like a politician." But founders, kings, and other such benevolent-dictator-for-life are still politicians—they have to hold court taking the full spectrum of opinions from the brilliant to the idiotic—but they don't usually bother to hide this distaste.
We have no equivalent word for someone forced to do what a politician does, but without the same incentives to put on a face and pretend they aren't hating some parts of their job.
Hypothesis: governments and other such bodies could be a lot better-run if we just had to choose the least charismatic/diplomatic qualified person possible, because then that lack of charisma would prevent them from swaying us with anything besides facts; and then, later, nothing they could do could make anyone like them any less than they already do, so they wouldn’t have to worry about maintaining their image getting in the way of doing their job.
(What would you call that—a direct technocracy?)
God help you if you'd ever grown up working on farm equipment.
At the end of the day, most of the angry rants are about high level or influential people breaking kernel mantras. Don't break them, especially when you should know better. I'm impressed by his level of self control honestly, when I imagine the constant stream of horse shit he probably has to deal with on the daily.