Ex-colleague of mine told me he used to work for this company in UAE (he told me this story 15+ years ago, so he worked there even before that). He said it took him months of working there before he discovered that their entire business was evading US sanctions against Iran-they’d order servers/etc from the US, tell the US vendor they were for use locally in UAE, then ship them straight across the Gulf. The UAE government presumably knew this was happening but chose to turn a blind eye; the US government likely did too, but struggled to tell which orders/purchasers were legitimate and which were sanctions-evaders, plus likely was worried about enforcement action causing issues in the US-UAE diplomatic relationship.

I’m sure there are similar businesses out there who specialise in evading US sanctions on China.

(Disclaimer: Not speaking for or about my current employer, just a general industry observation.)

From the regulators’ perspective: it is a risk, but you disclosed that risk in the prospectus that buyers are assumed to have read (what percentage ever actually do?), hence it is fine

Well, when you buy into an IPO, they make you sign to say you read it. So either you did, or you made a false statement on a legal document

How much did Musk becoming a trillionaire move the US national (or global) Gini coefficient of wealth?

If wealth inequality is significantly worsening due to AI, the wealth Gini will noticeably go up. I don’t know whether that’s happening; what I do know is individual extremes are very noticeable, but have limited impact on the big picture.

The reused RS-25s aren’t the same as the ones that flew on the STS-1. STS-1 used the original RS-25, Artemis uses RS-25D, and will in future use the new RS-25E.

In the same way, if Saturn V survived to the present, we wouldn’t be using the original F-1s/J-2s any more, we’d be a using significantly enhanced versions-and the originals would be infeasible to manufacture due to component availability changes

Because it was designed to be manufactured using 1960s components. A lot of the parts it used aren’t even made anymore more, because they’ve been replaced by newer components

The Space Shuttles were progressively upgraded over time to address this, e.g. the early 90s upgrade of their computers which replaced core memory with semiconductor memory. If we’d kept the Saturn V series alive, todays Saturn Vs would have had rather different innards from the ones that flew in the 60s/70s

But this is why “just reuse the Saturn V” design never made sense. You have to redesign so much of it to substitute for unavailable original parts, you might as well just redesign from scratch

Yes, it does briefly mention a few codes it doesn’t support-but that’s in the spirit of man pages having a “limitations” section (“here’s an incomplete list of commonly requested functionality we haven’t implemented”)-it is not intended as primary documentation for control codes implemented by other software.

This is my point-Mach-O is more elegant because it applies the “there should be one way to do it” dictum made famous by Python-the answer is load commands. ELF gives you multiple ways to do the same thing and it isn’t always clear which one people should use.

> Left with having to put the signature(s) somewhere (one? multiple, if multiple chunks are getting signed? not sure.)

The way macOS handles it-the binary contains a table of hashes, with one hash per a page. The table of hashes is itself hashed, and then that hash of hashes is signed. When loading the executable, the kernel saves the table of hashes in kernel memory, checking the hash on the table of hashes and its signature as it does so. Then, all the kernel has to do, is whenever it reads into memory a page from disk, it looks up the expected hash of the page in the hash table, and compares it it to the hash of the page data being read in. (This is a somewhat simplified explanation, not 100% accurate, but conveys the gist of how it works.)

If they set up a subsidiary in Europe, they could be held liable for actions of European subsidiary.

If an independent org is stood up in Europe, with European directors, staff and funding, legally independent of US org, and the US org just provides advice/assistance to Europe org without ability to control it-legal liability for US org for Europe org’s decisions is less likely. Of course, ask a lawyer-but if you openly say “we are doing this to work around US sanctions” you could still be liable; if you say “this has nothing to do with sanctions this is about resilience of global digital infrastructure and European digital sovereignty” then under what legal theory is the US org liable?

But this isn’t true - if universe A simulates universe B, there is no requirement that they have the same laws of physics.

If we are living in a computer simulation, then the “real” laws of physics might be radically different from the apparent ones, and we might never know what the “real” laws are

If we do, well it would seem trivially possible for our simulators to provide us with an afterlife if they wished–and we honestly could have no idea what they might wish.

If you claim to know we don't live in a computer simulation, or that if we do, our simulators would be unlikely to grant us an afterlife–how do you know that?

P(we live in a computer simulation) ~= 0.5

P(there is an afterlife|we live in a computer simulation) ~= 0.5

Therefore, P(there is an afterlife) >= 0.25 even if we assume P(there is an afterlife|we don't live in a computer simulation) = 0.0 (which is itself highly debatable)

Mach-O does similarly have a distinction between sections as a link-time view, and segments as an execution-time view – a Mach-O contains one or more segments (LC_SEGMENT for 32-bit, LC_SEGMENT_64 for 64-bit), each of which contains a segment header followed by zero or more section headers, so the sections are subdivisions of the segment. Mach-O has names for both segments and sections; ELF only has names for sections.

Let me put it this way – if you wanted to add embedded digital signatures to ELF, so the kernel could verify them at runtime, similar to Mach-O LC_CODE_SIGNATURE – what is the extension point you'd use? The Linux kernel supports digital signatures for ELF executables in conjunction with IMA, but instead of storing the signature in the executable like Mach-O does, it stores it in a filesystem xattr.

This isn’t my experience. In our house: I’m a software engineer, and our 13yo son writes C++ code as a hobby, so of course we both have laptops and desktops. But my wife, and our 8 year old daughter, both have laptops too, and use them regularly, despite not being remotely technical; our daughter mainly uses her laptop for games-she also has a tablet and a Nintendo Switch, but for many games (The Sims, Minecraft, Roblox) she prefers her laptop; my wife plays The Sims too, but she also prefers a laptop to a phone or tablet for sending emails and general web browsing.

Similarly my dad (a retired pharmaceutical company executive) is a lot less technical than he used to be (he hasn’t kept up to date and maybe some of these things get harder with advanced age), but he also prefers his laptop for some tasks (e.g. email, internet banking) despite also being a regular phone and tablet user

Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX

The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on their z/OS mainframe operating system, so they implemented on it a clone of Linux namespace APIs, e.g. unshare. Then we could have macOS nodes in a K8S cluster-which might actually be useful for some people, e.g. if you have a Jenkins CI farm, the Linux nodes can run on K8S, but currently macOS nodes (which you need if you are targeting iOS or macOS) can’t, they have to be bare metal or VMs.

More Linux-macOS source compatibility would also benefit macOS by making it less work to port software to it from Linux

Whereas, with ELF – if you want to add a new feature, do you add it as a new program table entry type (PT_), or a new note type (NT_), or a separate note section (SHT_NOTE)?

[0] Well, historically OSF/1 also used Mach-O, although my understanding is it was an incompatible implementation of the same basic ideas. The main vendor to ship an OSF/1-based Unix was DEC (later Compaq then HP Tru64 Unix), although HP also (briefly) shipped their own OSF/1-based Unix (prior to buying DEC/Compaq), as did IBM (the short-lived AIX/ESA for IBM mainframes, which despite its name, had very little in common with the AIX everyone knows), and also various supercomputer vendors (Intel Paragon and ASCI Red, Hitachi, Kendall Square Research). But all those systems are defunct, so Apple's Mach-O is the only member of the "Mach-O family" still in production use.

Of course, ELF still wins by being more mainstream, and not being de facto under the control of a single vendor.

This isn't true. The Linux VT console supports both X10 and X11 mouse reporting–except the Linux kernel source code calls X11 mouse reporting "VT200" instead, but it is the same thing. It relies on a user space component (traditionally the gpm daemon) to talk to the mouse driver to get the actual mouse position, and then feed that into the VT device using the TIOCLINUX ioctl (subcode TIOCL_SETSEL, mode TIOCL_SELMOUSEREPORT)

> And as I _can_ see a DECSET section, the manpage is referencing it.

Yes, it describes DECSET. But it doesn't describe many of the DECSET codes, including 1049 and 2004 which the Linux VT console supports – see https://github.com/torvalds/linux/blob/master/drivers/tty/vt... – and the many more which xterm supports – https://invisible-island.net/xterm/ctlseqs/ctlseqs.html – other terminal emulators frequently implement many (but not necessarily all) of the DECSET codes xterm does.

> And as there's whole sections about sequences _not_ implemented by the Linux console, it does not only contain what the Linux VT console support. Which is the opposite of your first statement.

It briefly mentions a few features which xterm provide that Linux VT console doesn't. It makes no attempt to provide an exhaustive summary of all the features xterm has which are lacking in the Linux VT console, since that's the job of the xterm documentation

For an example of what it omits: Alternate Screen Buffer support (DECSET 1049). This is common used by full screen apps (e.g. vi, less) to save/restore the contents of the command line screen. xterm supports it; most popular terminal emulators support it; the console_codes man page does not mention it. The Linux VT console did not support it until Linux 7.1 (see https://github.com/torvalds/linux/commit/23743ba64709a9c137c...) and the console_codes man page still hasn't been updated to mention the kernel now supports it.

> And none of them will have documented the OS-specific escapes,

These aren't really "OS-specific". The Linux console defines private sequences of the form CSI Ps ; Ps ] – those aren't specific to Linux, they are specific to the Linux console – you can't assume most Linux terminal emulators support them. They also aren't technically valid per ECMA-48 – the ] terminator was already reserved for the "START DIRECTED STRING" (SDS), which was intended for use with Bidi (e.g. Arabic, Hebrew), although I'm not sure if any terminal supported it; and also, when preceded by a space, the "SELECT ALTERNATIVE PRESENTATION VARIANTS" (SAPV) function, which also relates to Bidi, but also to Indic scripts; few vendors ever implemented either function, but IBM aixterm does partially implement SAPV.

Most terminal emulators (including xterm) instead use OSC (Operating System Command) to implement custom functionality, which would have been a more defensible choice from a standards-compliance perspective, but this feature was added in the 1990s, by developers who likely didn't have a good understanding of ECMA-48. Despite OSC's name, on almost all platforms it isn't implemented by the operating system, it is implemented by the terminal emulator, and so different terminal emulators on the same OS will implement different OSC sequences. (The only exception I am personally aware of is RMX, which uses OSC to do the moral equivalent of the termios IOCTLs under Unix-like systems, and so on RMX an OSC sent by an application is actually interpreted by the tty driver as a command to change its config.)

Do we know, how many of those deaths are due to limitations of existing treatments, versus how many are due to health care access issues?

This is somewhat outdated information. POSIX.1-2001 added "posix_openpt" to create a pseudoterminal, and most POSIX implementations now support it–at least Linux, macOS, FreeBSD, NetBSD, OpenBSD, Solaris, z/OS, AIX, HP-UX, QNX, Minix and Cygwin do. (Of course, that's only true of current versions, if you go back a decade or more you'll find many of them hadn't implemented it yet.)