Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
src
Read-only git conversion of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Given my (rough) understanding of Justine’s political leanings (active in Occupy [1]), I think (and hope) that you are mistaken. The following searchers turn up empty [2,3] as well.
[1]: https://www.thenation.com/article/archive/breaking-occupy/
[2]: https://duckduckgo.com/?q=site%3Ajustine.lol+dark
[3]: https://duckduckgo.com/?q=site%3Ajustine.lol+moldbug
It is perfectly possible that you are still right. But I would be darn careful to make statements like you made without backing them up with facts. The Internet is a chilling enough place without even more vague rumours going around.
Love your naming of the magic numbers headers. https://github.com/jart/cosmopolitan/blob/1.0/libc/sysv/cons...
> Our policy is to stick with stable supported interfaces whenever possible
Except you're not though.
FYI, on OpenBSD mincore(2) was removed 3 years, and it's UNIMPL syscall 78 was eventually reused by another system call: mquery(2), which your library passes bogus arguments to.
I would be very surprised if there aren't more serious mistakes lurking.
https://github.com/openbsd/src/commit/54e4f6b9a1dc183e1dc7c4...
https://github.com/openbsd/src/commit/1d60349d0b961891264d42...
I'm pretty sure Windows just automatically generates syscall numbers in their build process. Since the kernel and the dynamic libraries that are the only blessed way to interact with the kernel are shipped together, that's not a problem from Windows's point of view.
For example, look at [1] and search for e.g. 0x01aa, to see how the meaning of that syscall number changes in a pretty systematic way over releases.
1: https://github.com/j00ru/windows-syscalls/blob/master/x86/cs...
This is incorrect. On most platforms, the libc is part of the operating system, and the libc API is the supported system call interface; user programs aren't allowed to make system calls directly to the kernel, any more than they're allowed to jump directly into the middle of kernel routines.
As described elsewhere in this thread, that is the policy of MacOS X and Windows.
It is also a policy which OpenBSD is moving towards:
https://lwn.net/Articles/806863/
According to the Go devs, this is also the policy on Solaris-family OSs (Go uses libc there):
https://github.com/golang/go/issues/24357#issuecomment-37300...
AFAIK, it is only Linux which explicitly supports the kernel system call interface, and so where alternative libcs are possible.