jclulow

The name of the file is just part of the committed interface that the binary consumes. You could just as well suggest it's silly that every Linux system needs to agree on the behaviour of each system call number, or no program for another system will possibly be able to run on it.

We don't call it Solaris anymore! :P

Rumours of our death are, as ever, greatly exaggerated. We continue to maintain the core OS facilities provided by illumos and the organisations behind distributions like SmartOS and OmniOS continue to ship maintained, supported software to a mixture of community and commercial users.

One of our core product goals is to actually allow relatively hot swapping of individual compute sleds. It's true that each sled is an x86 server, but there's control software managing the whole rack as a unit, with live migration of workloads and replicated storage. The architecture of the whole thing leans towards treating sleds as essentially like CPU and memory (and storage) boards in previous generations of large scale computers like mainframes.

What _does_ count as a utility, then? I expect anything that is considered (or even legally classified) as a utility is going to have rules and "someone" to decide who to kick out; e.g., the electrical grid, or the water supply, or the telephone system, or council rubbish collection, etc.

There is filesystem(7) on illumos, although it needs a few updates at this point to retire things we've removed like SPARC support: https://illumos.org/man/7/filesystem

I'm Australian and though I don't live there now, I did for 27 years. Most of the things you're describing are just a function of the people you were hanging out with. I knew people like that, and I chose different friends.

People definitely used gay as a slur when I was in high school, and then people grew out of it because it was childish and awful. Perhaps it was at about the time that some of us came out as gay.

Diversity is certainly not uniform in the country, obviously, and exposure is a critical part of being well rounded. We had a lot of people from PNG and Sri Lanka where I grew up, and when I went to Uni there were a lot of foreign students from Kenya and other places. Being weird or racist about it would have been pretty fucking unacceptable to me and my friends. But I have met people who are indeed weirdly racist or sexist.

Also, I have noticed a pretty broad shift in this from people in my parents generation to people in my generation, and I'm sure again to people younger than myself. I think this actually happening in lots of places though, not just Australia.

As far as swearing goes... Yes? We swear a lot. It works for us!

We have lots of problems, and a truly horrendous history of colonial violence -- which we have at least begun to address in history class in schools in the last thirty years. Lots more work to do. I'm sorry you had a bad go of it, but please don't assume that you have a picture of every Australian.

The purest idealistic version of means testing may well be fine in theory, but in practice means testing is universally co-opted by conservative governments to make it difficult or impossible for the people with the least resources (and thus most in need of the benefits) to actually get them.

The Australian Centrelink programme is a pretty good example of what happens: one government introduces a system of unemployment benefits and then later a different conservative government (whose members and voting base don't like poor people) are able to pervert the system through means testing provisions and other bureaucratic hurdles to effectively prevent a large subset of eligible persons from actually collecting the benefits to which they are entitled, but without having to deal with the political fallout of actually ending or reducing benefits on paper.

I think there are two kinds of transitions:

- on fork, you are by definition implicitly cooperating with the parent as you are the same software image as the parent; in the case of transitive forks you can be expected, I think, to continue cooperating.

- on exec, you move from implicit cooperation to the need for explicit cooperation, through some kind of interface contract; e.g., the BASH_XTRACEFD environment variable. It is incumbent upon you to hide the good silverware before making the exec transition, as exec is a trust boundary; like when you sell your house, you don't get to control what the new owner of the process does with it, except through kernel-enforced mechanisms like privileges and resource controls and so on.

> you might duplicate file descriptors into the child that you might not have intended, and that can break things in the parent.

This is not true on all systems. For example, on ilumos we have fdwalk(3C) and in particular closefrom(3C). These allow you to dup2() your intended descriptors to a contiguous block starting at fd 3 (assuming you keep the stdio descriptors at 0-2) and then close everything from one past the last descriptor you intend the child to inherit.

https://illumos.org/man/3C/closefrom

Many of these problems are at least partially solved on other UNIX systems like illumos. To run down the top-level list:

1. It's easy for processes to leak

illumos has contracts[1][2][3], which were developed as part of the Service Management Facility[4]. They are another process grouping abstraction that allows SMF to track trees of processes, whether they daemonise or not. They allow for tracking or ignoring certain events (e.g., a fatal signal sent from outside the contract, a process within the contract that aborts and dumps core, if a particular process, or all processes, terminate in some way) and for doing certain kinds of automatic cleanup (e.g., terminate all processes in the contract when the process that owns the contract is terminated). These are managed by the kernel, so they are effectively inescapable even when not held correctly by a user process.

2. It's impossible to prevent malicious processes leaks

This is not really true for us either. Between contracts, and resource controls[5], and privileges[6], I expect one would be able to limit the malicious or accidental escape of processes from supervision or any run-away resource consumption caused by, say, a fork bomb.

3. Processes have global, reusable IDs

This is true on some level, but in practice I think that's just part of UNIX and when you have solved 1-2 and 4 in other ways, it's not actually that bad. If you want to kill everything in a contract you own, even without knowing the full list of pids, you can do that with ct_ctl_abandon(3CONTRACT)[7] which takes a contract file descriptor. The termination action (which could be to tear down all of the processes) will take effect then.

4. Process exit is communicated through signals

This is not entirely true, in the sense that they are by default for classic UNIX applications -- but they need not be. We have forkx(2)[8], which has the FORK_NOSIGCHLD and FORK_WAITPID flags. These request that SIGCHLD is not posted for process termination, and that the classic UNIX wait(2) family of calls will not receive notification or reap children. You can use these from a library, and then manage your own waitid(2) or waitpid(3C) calls on the specific process IDs you are responsible for reaping. You can also use contracts to receive notifications of events about processes within the contract coming and going.

[1]: https://illumos.org/man/5/contract

[2]: https://illumos.org/man/3LIB/libcontract

[3]: https://illumos.org/man/3CONTRACT/

[4]: https://illumos.org/man/7/smf

[5]: https://illumos.org/man/7/resource_controls

[6]: https://illumos.org/man/7/privileges

[7]: https://illumos.org/man/3CONTRACT/ct_ctl_abandon

[8]: https://illumos.org/man/2/forkx

I assume that will come well after Amazon uses the technology to remove the memory of rights holder content when you cancel your Prime subscription. Or after Disney uses it to retroactively edit the Star Wars movies for the nineteenth time, digitally gaslighting people by amending the original memories in place.

It's amazing to see you castigate the article as mere opinion and then go on to write a comment that is not merely mere opinion but also quite mean-spirited and making no room for the idea that different people work quite differently actually.

I have ADHD, which I didn't know when I was a teenager in the era before the phones you're blaming for poor sleep hygiene. I have struggled for essentially my entire life with sleep routine. I can't for the life of me get to bed at the same time every day; after three decades of trying I just don't think it is something I am readily capable of doing. It works for a few days and then gets later and later and eventually it's so late that I'm ruined by 8pm and I reset for another cycle.

This is, as it turns out, not uncommon among folks with ADHD and similar conditions -- and those conditions are more likely than you would obviously believe them to be.

So, while it absolutely is my responsibility to regulate my life, I feel you can probably keep your sanctimonious encouragement to adulthood!

I suspect people would be more sympathetic to the plight of CEOs if they didn't make hundreds or thousands of times as much money as everyone else, even and perhaps _especially_ when they commit random acts of economic violence on their staff.

Indeed the Mac OS branding didn't really kick in until after 7.5 as far as I know.

> Helios is a secret Oxide thing

It's not so much a secret as we've been rather busy, and I haven't had time to clean up the repositories to the extent that I'm comfortable making them public. Hopefully real soon now, and absolutely before we ship the hardware to anybody.

> different "distros" of illumos would have different kernel ABIs

We do have strong guarantees around various kernel API/ABIs, which one can absolutely use to produce out of tree modules that will work over the long term and across distributions. We call this the DDI, or Device Driver Interface, and it's documented as public and stable in our manual.

The vnode layer bits that FUSE uses are ostensibly sort of public but not documented. This is of questionable utility, to be honest, but it's apparently there. A mistake was likely made in adding support for inotify to a particular fork of illumos, and a struct member was added in the (again, wishy-washy) "public" preamble of the vnode struct.

> The biggest question to me is why Helios is using the FUSE kernel module from OmniOS

This is my fault. Before a distribution can be self-hosting, it needs to exist at all. I am a big fan of OmniOS so I had bootstrapped the first Helios bits by building modified OmniOS bits on OmniOS, and then massaging the packaging metadata until it looked how I wanted it for Helios. I then installed a Helios machine from those packages and everything was subsequently built on Helios from then on.

Regrettably I didn't realise the business with the vnode stuff, or even that we had a FUSE package. It has not been rebuilt since that original bootstrap build, so it was built with the wrong vnode.h. In my defence this is the first time in two years anybody has tried to use FUSE on Helios so nobody else noticed either!

Dealing with existing PC compatible servers is just a constant onslaught of tedium. Some of it is as disruptive as the DIMM stuff Bryan talked about. Some of it is just the stuff people have seemingly become desensitised to. Some of the things I've had to deal with in the last few years:

* several different servers where you can set the boot order through the Redfish API, except that it only works about 60% of the time and there is no way to tell from the response if it took or not. Just have to keep doing it and rebooting until it hopefully eventually works!

* PXE boot support that is incredibly slow, so for any reasonable payload size you need to chainload iPXE every time

* servers with oddball Broadcom NICs where chainloading iPXE doesn't work at all

* servers that sit at the BIOS screen for twenty minutes unless you pull out all the U.2 NVMe devices, then they boot OK. Maybe a firmware update will fix it!

* firmware updates that don't install properly through the BMC

* firmware updates that don't _show_ they're installed properly until the BIOS boots completely and can report the new version through apparently some kind of HTTP request on an internal USB NIC to the BMC, even though the BMC has control of the SPI flash and thus is lying to you until that reboot occurs

* BMCs that just stop working until you remove power at the wall from the whole system

* IPMI serial over LAN redirection that drops about 4% of output characters but not in a predictable way so copying and pasting, say, a serial number has be done several times to be sure you got the whole thing

* an interrupt controller in a HP system that doesn't emulate fixed interrupts correctly, and so eventually after some random number of millions of interrupts the lines are just stuck on until you power cycle the system

That's just stuff that comes to mind at the moment. There's literally no way to compose a reliable automated production system on this ridiculous tower of packing peanuts. In contrast, in the lab, I can pretty much just ask an Oxide machine to replace the contents of the SPI ROM and the M.2 storage device and power cycle it and it does what it's told. There are comparatively few moving parts and we have the source to almost all of them.

It's fine to have many smaller CPUs in the system, for all the purposes you state. The software that runs on them needs to be open, though, and something we can understand, fix, or even replace completely as needed. The operation of the components also needs to be documented so that it's possible to do that not just in principle but in practice.

We've added several small cores of our own to the systems that make up the Oxide rack, but critically we can control them with our own (open source) software stack. The large scale host CPUs where hypervisor workloads live can communicate with those smaller cores (service processor, root of trust, etc) in constrained ways across security and responsibility based boundaries.

Hewlett-Packard has never heard of a rent they didn't want to seek, so iLO definitely has bullshit extra fees for remote management after the firmware exits.

You have to ban them _and_ buy them back at the same time. You make them illegal to have, then you compensate people for the economic value of the property they now need to surrender for destruction.

That is in fact how buyback schemes work in countries that aren't totally irrational about guns.

You don't need direct Internet access to use Let's Encrypt, as long as you can arrange for the challenge response to appear in public DNS under the name you want to use.

I would generally try to avoid working somewhere so horrendous people don't even last a year. If one somehow did not already know that about Amazon, talking to future team members about the corporate culture seems like a good way to try to find out before making a mistake!

The predictive power of a single interview with a single person is just not that high.

For one thing, the company is not the only one doing the interviewing; the candidate is also interviewing the company. Before making a commitment to join a team, I think it's valuable to speak to a number of members of that team to get a sense of what they're like.

On the company side, I have also witnessed several people who might have looked alright in just one interview, but when exposed to several it became clear they were adjusting their story significantly for each interviewer to the point of dishonesty.

There is clearly some line beyond which more interviews would present seriously diminished returns, but I think six or seven interviews, each 30-60 minutes, is much more likely to result in a better outcome for a professional engineering position than just one interview with a hiring manager.

FWIW, illumos has excellent Rust support.

If through compromising those workers outside parties gain access to sensitive systems, and that situation is not promptly detected and corrected, then the system _is_ compromised.

Okta is not just a bunch of software, it's also staff and processes, and the result is a trusted service they provide to customers. If that service is compromised, it doesn't really seem to matter how?

From their perspective, is it really _broken_? If you're Microsoft, especially Ballmer's Microsoft which accounts for most of those 25 years, who cares about a handful of hostile UNIX nerds on some mailing list -- they're not going to switch to using Outlook and we want to discredit and destroy their software anyway.

From the perspective of market fit and success, there are countless less-technical business users who swear by Outlook. They are not familiar with anything other than the kind of endless thread top-posting in odd encodings that Outlook all but ensures users will do -- that's e-mail to them. Why stop selling it to them?

To be clear, I loathe all of it and I haven't used client Windows for more than a decade. When I used to support small business IT customers back then, Outlook was by far my least favourite tyre on the raging intergalactic rubbish fire. But it's not hard to see why they don't care that Outlook is the way it is.

Who says "com-poo-ter"?!

Who can say? Consider, though, that just because someone writes an open letter and resigns, doesn't necessarily make them right -- certainly, at minimum, it does nothing to cement them as somehow free from their own agenda or biases.

Neither, then, does the ostensibly irony free use of terms like "wokeness", or the placement of "lived experience" in scare quotes, do anything to bolster a putatively data-driven perspective hounded by some opposing team.

Whole fields of medical and psychological science have changed over just the course of my lifetime. I expect they will continue to change to reflect the complex needs of our society, and based on new understanding we continue to uncover. This letter is not especially moving.

It is almost cruel the extent to which the ADHD evaluation process for adults is structured. There are so many laborious steps and appointments and diagnostic procedures and so on. One is likely, by virtue of the ADHD, already struggling just to get through work and personal obligations already; adding on top an incredibly dull and complex multistep process, coloured as it is by an apparent moral panic about prescribing low grade amphetamines, is really not a fantastic standard of care.

If they don't want you to fling binaries into your home directory they should just mount it noexec. At any rate it doesn't seem like a fantastic security/ability-to-work trade-off. Limit the privileges of the account or you're one exploit away from trouble.