c00lio

The original idea for netlink sockets (where the name comes from) is to be able to do some network packet processing in userspace. E.g. to do stuff like virus-scanning on TCP connections.

The situation there is exactly the opposite of a syscall, it is rather that the kernel calls into userspace to perform a helper function.

Communication with the socket is still read()/write()/..., so there are still syscalls. The userspace program will do a read() to get the next struct+packet out of the socket.

The modern, syscall-less interface for stuff would be io_uring. There, you do not need to read(), you can just get your data written into a userspace buffer that you can mwait or poll on.

Yes, but there are a lot of "in-betweens":

https://www.ch.ch/en/vehicles-and-traffic/how-to-behave-in-r...

You won't immediately loose your license for speeding, even in Switzerland. Afaik it'll be expensive until 20km/h over, only after that will the really nasty things like criminal prosecution and car impound start (for first-time offenders, repeat offenders are punished more harshly).

A driving exam also happens on the road. I'd suggest a similar, supervised test series with mandatory emergency drivers.

The Snowden revelations had profound consequences on the standardisation process, because mass surveilance was thereby proven as a real and present attack that has to be considered. Undue influence on standardisation processes by the NSA was also a relevant point. Later protocols and standards started to take both into account. All those are in scope for RFCs, there are quite a few about standardisation procedures, circumstances, etc.

OK, then the US is a very strange place. I'm European, so forgive my ignorance in those matters, I thought things worked similarly over there.

It should be per software. Maybe per software version, if the company can conclusively prove that the prior problems that led to points cannot happen again.

If this were a human driver, at least half of those would loose you your driver's license. Why are there no such consequences for the companies?

Right, registers are even faster.

> Coercing random access memory into a serial file just to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

The file doesn't need to have an on-disk representation. I don't see why an mmap-ed file should behave any different from a SHM segment. They are basically the same thing, the SHM segment even has a file descriptor. It just doesn't have a name somewhere in the filesystem hierarchy. https://man7.org/linux/man-pages/man7/shm_overview.7.html

Netlink sockets in Linux input and output packed C structures. Doesn't get more efficient than that. Such an interface definitely doesn't have to be strings-only. But of course, you cannot use it with just 'echo' in that case.

As always, Fabrice Bellard is ahead of his time: https://bellard.org/jslinux/ :)

That is already done. Similarly, anyone who requests priority landing because of low fuel will be investigated as a matter of cause.

On the other hand, layering tons of stuff on unsuitable interfaces has been all the rage in the last 25 years. Just think of everything-over-http, stuff-it-in-xml/json, program-it-in-yaml and similar industry trends. ;)

There are still tons of stringly-typed interfaces in powershell.

Why would (pseudocode, nonexisting but possible example) write(SIGKILL, "/proc/12345/signals") not be possible? For the other direction, there is signalfd in Linux. And of course you can get a peer address from /dev/tcp (https://andreafortuna.org/2021/03/06/some-useful-tips-about-... ). Yes, /dev/tcp is not an OS primitive but a bash builtin, but there isn't really a reason you cannot do this in the OS. Shared memory can be a file, you just have to mmap() it. mmap is always left out of the open/close/read/write-enumeration of the traditional file API, but I think it is actually extremely useful and should be the fifth alongside those.

Debugging is hard to imagine, yes. One could look at /proc/12345/mem, write breakpoints in there, but I'm not sure about how to do the more exotic things.

Under water, sonar could pick them up, but sonar is mostly "look down". If a current dragged them somewhere outside the immediate vicinity, they'll be hard to find, because the search vessel needs to be within at most 4km to find them in the water if they are drifting. Far less on the ground, because eliminating and processing ground echos is extremely hard.

If they are on the surface, getting them by sonar is not possible, but aerial surveillance might find them. However, things are very hard to see in the ocean if there are waves. They might have an AIS locator which would transmit their position and an emergency signal, but maybe they skimped on that too, because the submarine-rated ones are expensive.

Maybe. Sound travels longer distances in water than in air, but there still is a limit. And hydrophone chains and buoys are probably not dense enough to hear everything.

Volume is also an issue, the Titan is far smaller than a military sub, so the sonar spike corresponding to the implosion will be shorter and of a smaller amplitude.

The sonar on their surface vessel should have picked up the noise, if they have one that does recordings and passive mode. But I guess they were too cheap for that as well, since no regular sonar surveilance of the sub is mentioned in the press.

My educated (a little bit of engineering at uni) perspective is: Completely idiotic to build a submarine out of carbon and not have the means for a complete inspection for manufacturing defects as the original article suggests.

Carbon, as you correctly note, needs to be very homogeneous. Bubbles, lamination defects or -god beware- fissures lead to failure, of the sudden, unannounced and total kind. And not only is it necessary to check after production, but also after regular short intervals of use, because a mere scratch in the carbon can be fatal.

Oxygen is just about running out in the next few hours, they don't seem to have had any sonar contact, no cable or underwater phone. Getting something like a DSRV (which wouldn't really help if they are at ground level there, because it cannot dive that deep) there will take at least a day. Even if they are still alive, their chances of rescue are nonexistent.

You mean: He put his ass where his mouth was...?

Problem with all kinds of asynchronous I/O is that your processes then need internal multiplexing, akin to what certain lightweight userspace thread models are doing. In the end, it might be harder to introduce than just using OS threads.

Why should TLB flush performance ever be a problem on big machines? You can have one process per core with 128 or more cores, never flush any TLB if you pin those processes. And as it is a database, shoveling data from/to disk/SSD is your main concern anyways.

Yes, lane count is the number of parallel links.

Switches are far more complex. The protocol specifies addressing, bandwidth reservations, flow control, priorities and message ordering requirements, which the switches have to handle.

Not a switch thing per se, but also relevant for "single transistors won't do": On the physical layer, each port/link is also relatively complicated to initialize and operate. The transmission encoding, due to the relatively high speeds involved, requires a learning phase where both ends measure the link characteristics and adjust their (relatively complex) signal processing accordingly. The physical layer also handles different link speeds for down-/upward compatibility.

> Private insurance can be used as well, giving preferred access and treatment.

Well, actually, the contracts doctors have with the public insurance carriers forbid giving preferred access. So handing out earlier appointments to privately insured people is verboten. But no doctor obeys this, and punishment is practically nonexistent.

Differences in offered treatments are allowed, the catalogue that private insurance pays for is usually larger.

On some level yes, on some level no. The physical interface for each point-to-point link is serial, but one device can have several of those links and use them (send/receive packets on them) in parallel.

The defining characteristic of PCIe isn't faster bus timings. It is that PCIe isn't even a "bus" in the traditional sense. With a bus, you have a number of shared physical wires for addresses and data, and an arbitration system that assigns those shared wires to one device at a time. The available bandwidth is just the bandwidth of the bus, divided into the time you can reserve it for yourself.

PCIe is a tree-shaped network (root is the root hub in the CPU, inner nodes are switches, leafs are devices) with point-to-point links (called lanes) that transmit packets. Bandwidth is determined by the number of lanes that a device's path up to the root hub has at the narrowest node.

Higher IPC is relevant for workloads that are compute- but not data-intensive. There are practically no common server applications with that characteristic. In high performance computing, you might find some such applications, e.g. some Monte-Carlo-Type simulations, some linear-algebra-heavy workloads. Of course especially the latter are reported in popular benchmarks like the Top500, so marketing puts a special emphasis on those. But even there, raw IPC is mostly useless, since common problem sizes make a lot of network communication necessary to e.g. solve computational fluid dynamics problems. For those you'd need both IPC and (low latency and high bandwith) I/O, because one machine won't be enough and you have to do clustered computations with lots and lots of I/O-intensive communication to transmit your boundary results to your neighboring machines.

But run-of-the-mill server workloads are more like database applications (get query, load data from mass storage, do some processing on it, send results to network), HTTP and similar servers (get request, load data from mass storage, do some processing on it, send results to network), file servers (load/store data from network, only a little processing), terminal servers (wait for user interaction on network, process/load/store a bit, shovel out screen updates). Lots and lots of I/O, not so much computation that would care about IPC.

I'd be sceptical about "can be rack mounted" in the context of Apple hardware. Remember those?

https://www.sonnettech.com/product/legacyproducts/rackmacpro... https://www.myelectronics.nl/us/mac-studio-empower-station-r...

At least the new case is available with rails, but cooling and management are still crap.

Actually, no. It only limits the available I/O bandwidth to those GPU(s), that is, data transfers from and to the CPU will be far slower. You'll notice in games when the "loading next level" screen takes longer, that's usually a large geometry and texture copy to the GPU.

As an extreme example, when and where it was/is still viable, cryptocurrency mining operations use external PCIe cases with lots of slots, attached to only a few or even just one lane per case. For their purpose this was still viable, since mining uses very little I/O from/to the GPU, essentially only a small block of setup data into the GPU ("try hashing this block, vary those bytes within that range, report when result matches this pattern", a few kB) and a few bytes of results out ("found a match, varied bytes were as follows").