HN user
It wouldn't surprise me if I learned that the vast majority of programming globally is in languages like Visual Basic or PHP that are utterly unfashionable on a board like this, but still make the world go round.
It's a completely uncontroversial fact that NT does implement fork(). Turn to page 183 of Helen Custer's "Inside Windows NT" and you will read about it.
Solaris and Windows NT both have fork() and strict accounting by default.
The principle of a paging system is that main memory is just a cache for secondary memory, and the concept of "free memory" ideally rather means something like "memory that can be quickly reclaimed for another purpose". Sometimes anonymous memory will be of less us occupying main memory at some given time than would be letting cached file contents take their place.
The general principle is that what is involved in paging should not be paged itself. Wiring the memory of that whole daemon is then a trivial solution to the problem.
Plan 9 implements some sort of "everything has a directory entry" concept. Sockets are files already in Unix. "Everything is a file" in Unix means they have a uniform treatment as file descriptors. Its perfection is probably in Capsicum where when you create a new process, you get a process file descriptor referring to it instead of a PID.
It's rather a bit more BSD than merely having a "C API that resembles BSD" or a "BSD userland".
https://github.com/apple-oss-distributions/xnu/tree/main/bsd
You can find there the better part of a whole BSD kernel, including the fundamental datastructures like proc, tty, vnode, and user.
The point of departure is 4.4BSD-Lite2. The majority of the core of the BSD kernel carries the relevant notices for that.
https://github.com/apple-oss-distributions/xnu/tree
You'll find there's a great deal left. Have a look at all the fundamental datastructures (proc, vnode, tty, file to name a few) for a starting point.
The pushback is motivated by the interests of the petty-bourgeois class, and those are a larger proportion of the former.
I find it interesting that this fulfills some of Dennis Ritchie's goals for what became the STREAMS framework for byte-oriented I/O:
I decided, with regret, that each processing module could not act as an independent process with its own call record. The numbers seemed against it: on large systems it is necessary to allow for as many as 1000 queues, and I saw no good way to run this many processes without consuming inordinate amounts of storage. As a result, stream server procedures are not allowed to block awaiting data, but instead must return after saving necessary status information explicitly. The contortions required in the code are seldom serious in practice, but the beauty of the scheme would increase if servers could be written as a simple read-write loop in the true coroutine style.
The power of that framework was exactly that it didn't need independent processes. It avoided considerable overhead that way. The cost was that you had to write coroutines by hand, and at a certain point that becomes very difficult to code. With a language that facilitates stackless coroutines, you can get much of the strengths of an architecture like STREAMS while not having to write contorted code.
Linux won specifically because the GPL forced the "greedy" actors to collaborate.
How do we know that? It seems to me that a greater factor in the success of Linux was the idealism and community. It was about freedom. Linux was the "Revolution OS" and the hacker community couldn't but fall in love with Linux and its community that embodied their ideals. They contributed to it and they founded new kinds of firms that (at least when they began) committed themselves to respect those principles.
I realise the memory of Linux's roots in hacker culture is fading away fast but I really do think this might have been the key factor in Linux's growth. It reached a critical mass that way.
I'm quite certain of the fact that this was more important anyway than the fact that, for instance, Linksys had to (eventually! they didn't at first) release the source code to their modifications to the Linux kernel to run on the WRT54G. I don't think things like that played much of a role at all.
Linksys were certainly kind enough to permit people to flash their own firmware to that router, and that helped grow Linux in that area. They even released a special WRT54GL edition to facilitate custom firmware. But they could just as easily have Tivoised it (something that the Linux licence does not forbid) and that would've been the end of the story.
Just about everything of worth in operating systems (and in software in general) was already invented in those decades.
The C standard doesn't guarantee much of anything. Windows and its drivers are using bitfields anyway because they trust MSVC to do the right thing.
Some firm called CodeThink have been instigating it for RISC-V lately: https://www.codethink.co.uk/articles/risc-v-big-endian-suppo...
If it's about "prettier code" then I think a number one candidate would be making bitfields more viable for use. It could make driver code much cleaner and safer.
Windows is only targeting little-endian systems which makes life easier (and in any case they trust MSVC to do the right thing) so Windows drivers make much use of them (just look at the driver samples on Microsoft's GitHub page.)
Linux is a little afraid to rely on GCC/Clang doing the right thing and in any case bitfields are underpowered for a system which targets multiple endians. So Linux uses systems of macros instead for dealing with what Windows C uses bitfields. The usual pattern is a system of macros for shifting and masking. This is considerably uglier and easier to make a mess of. It would be a real improvement in quality-of-life if this were not so.
You can also look at Managarm (which benefits from C++ here) for another approach to making this less fraught: https://github.com/managarm/managarm/blob/a698f585e14c0183df...
There's no legal concept called "tainting". Black boxing is just a means by which you try to make yourself completely irreproachable (for if you haven't seen something, then it's outright impossible that you copied it). It obviously doesn't follow that the converse is true. If it were, musicians would not listen to other's music nor would painters look at other's paintings!
It's just a fiction to allow something freely copiable - pure information - to be pretended to be a commodity. If the AI firms have only a single redeeming feature, then it is that in them the copyright mafia finally has to face someone their own size, rather than driving little people to suicide, as they did to Aaron Swartz.
The void type has considerable heritage, dating back all the way to ALGOL 68, and is traditionally defined as having one member:
The mode VOID has a single value denoted by EMPTY.
Usually when I hear "robbery" it brings to mind someone stealing your phone or wallet at knife-point. Certainly not training some model on some code that involves neither violence nor depriving anyone of anything.
The concept of copyright is the fiction that information - something that can be freely modified, copied, or transmitted - is of the commodity-form, that information should be treated as if it were a single real object that were inherently scarce.
It is a fiction that exists to serve of some of the most hateful, mafia-like firms - your Disneys, UMGs, Getty Images, and the like.
So if the AI interests are powerful enough to deal that whole rotten system a serious blow, then I'm all for them.
you can technically look at some of the code that comes with it, but you can't modify it.
This is equally true of the GPLv2. The attempt to close this loophole - Tivoisation as Stallman called it - only won him a lot of scorn from Linux land and a refusal to adopt the GPLv3!
Windows has extreme similarities with Unix, and if you would look at a really different OS like, for instance, IBM i, it becomes clear. The Windows-Unix affinity is so great that you even interact with devices through file handles by Read, Write, and IoCtl methods.
Check "Inside Windows NT" by Helen Custer, an official account. She explicitly credits the handles to Unix. That's not surprising - not only was Unix fresh on the minds of the NT developers, with quite a few of them having Unix backgrounds, but every conceptual ancestor of Windows NT was at least significantly influenced by Unix:
- VMS: The VAX/VMS team were in regular contact with Ken Thompson, and got the idea for channel IDs (= file descriptors) for representing open files and devices from him, as well as the idea of three standard channels which child processes inherit by default: input, output, error (the error one was at the time a very recent development, I think in Unix v6 or v7)
- MICA: Would have been a combined Unix and VMS compatible system.
- OS/2: FDs with read, write, ioctl again.
Even MS-DOS is already highly Unix-influenced: they brought in file descriptors in DOS 2.0 and even called the source files implementing the API "XENIX.ASM" and "XENIX2.ASM" (see the recent open source release.)
I have deliberately chosen to not make anything of the fact that Windows NT was intended to be POSIX compatible either (and even supports fork, which WASI mercifully doesn't) because my point is the fact that all modern general-purpose operating systems are at least very much inspired and deeply indebted to Unix. I would accept that OSes that are not general purpose may not be, and old operating systems made in siloed environments like IBM are fundamentally very different. IBM i is very different to Unix and that's clear in its native APIs even though
Cocoa and Android APIs don't look much like the basic Unix APIs, it's true, even if they are implemented in terms of them. WASI wants to define APIs at that lower level of abstraction. It's tackling the problem at a different level (the inter-process level) to what object capability _languages_ are tackling (the intra-process level).
How can you implement an object capability system on WASM?
It's been well known for decades that the germ of an object capability system already exists in Unix - the file descriptor (that's why the control message for transferring them over sockets is called SCM_RIGHTS).
Capsicum was developed to make that potentiality a reality. It didn't require too much work. Since most things are represented by file descriptors, that was just a matter of tightening what you can do with the existing FDs (no going from a directory FD to its parent unless you have the right to the parent, or some parent of that parent, by another FD), and introducing process and anonymous shared memory FDs so that a global namespace is no longer needed to deal with these resources.
So WASI has derived itself from an actually existing object capability architecture - Capsicum - one which happens to be a simple refinement of the Unix API that everyone knows and every modern OS has at least been very much inspired by.
Computerised CBT is even already being delivered and by quite a bit less sophisticated systems than LLMs. Resourcing constraints have made it very popular in the UK.
Solaris achieved some kind of integration between the ARC and the VM subsystem as part of the VM2 project. I don't know any more details than that.
They're not obscure or niche, they are everywhere in operating systems. The linked list is probably the single most essential and the most used data structure in any kernel.
The idea of using a third party init system has always been quite alien to BSDs, the sames goes for almost all other Unix-like systems, which are almost all developed with a greater deal of integration within the core system. Linux is exceptional in this respect, that it has ever had a diversity of init systems.
This war of words between the BSD community and systemd, as far as I've been able to tell, dates back to when Poettering went to the GNOME mailing list to propose making GNOME depend on systemd. He made this request with the proviso that it shouldn't necessarily be a hard dependency, so that needn't have been a problem in itself, but then he made a remark in an interview with linuxfr.org:
I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.
and as you can imagine this was ill-received by the BSD community.
Could systemd, or at least a useful subset of it, have been made cross-platform from the get-go? It would've taken more work. I don't think the amount of work necessary would have been particularly onerous, which I hope InitWare shows. It would have required making certain compromises like systemd being happy optionally running as an auxiliary service manager rather than as the init system.
In the end, though, Poettering has his preference to target GNU/Linux only, and he is entitled to that.
I'm saying that it did work perfectly fine and reliably for the common case of types oneshot and simple services. To expect it to work for type Forking services would be absurd since no mechanism would exist to even try to keep track of them. It's just a point to illustrate that systemd is not as intimately and irretrievably integrated with Linux features as some imagine.
Freezers were never used by systemd as part of its process tracking mechanism. And cgroup emptiness notification was unreliable under cgroups v1. So that's not wrong. It used some horrible mechanism where a binary is launched (!) when the cgroup becomes empty. And that can fail to happen under situations of low memory availability.
Related read is Jonathan de Boyne Pollard on cgroups:https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html
Systemd uses groups for two things: for tracking processes other than direct children of the service manager, and for imposing resource limitations. Both can be done with other mechanisms, like kqueue's EVFILT_PROC and login classes respectively. But my experience in any case was that hacking up systemd to build and run under BSD it didn't need cgroups at all for basic running. Supervision of `Type=simple` and `oneshot` services worked fine. It wasn't particularly surprising to see this as cgroups really aren't ideal as a tracking mechanism - under cgroups v1, you only had a "cgroup empty" notification available as far as tracking the lifetime of processes within a cgroup, and even that was unreliable and could be left undelivered! So systemd used them to augment a more traditional process supervisor. That's why Pottering insisted on having it be PID 1, and got subreapers added to Linux for the per user systemd instances so that they could get the more traditional SIGCHLD based notification of process exits.
You can do the same with a modren C compiler - the extern and auto mean the same and int is still the default type.
As far as I can tell (this isn't gospel, just something I've inferred as the only reasonable explanation from comparing the codebases), Apple reconstructed a Mach 2.5 style kernel, like NeXTSTEP had, from fresh codebases (OSF Mach and 4.4BSD-Lite2), perhaps because 4.3BSD was still encumbered at the time.
The Darwin 0.1 and 0.3 releases contain the old kernel, derived directly from NeXTSTEP, and that's the direct derivative of Mach 2.5. The later XNU appears to be a reconstruction of that kernel with unencumbered code and that's also when IOKit replaced DriverKit.