jclulow

You can read a bit about our decision making process on the host OS and hypervisor in Oxide RFD 26: https://rfd.shared.oxide.computer/rfd/0026

The answer is definitely not "no", but as far as I'm aware we haven't found any particular cases where that level of formalism and that specific style of arrangement would help.

In an open source world where multiple shipping operating systems are based on (different snapshots of) the same core code and interfaces, it seems much more valuable to try and push straight to Committed interfaces (public, stable, documented) where we can.

There are plenty of cases where people use Uncommitted interfaces today in things that they layer on top in appliances and so on, but mostly it's expected that those people are paying attention to what's being worked on and integrated. When folks pull new changes from illumos-gate into their release engineering branches or soft forks, they're generally doing that explicitly and testing that things still work for them.

Also, unlike the distributions (who ship artefacts to users) it doesn't really make much sense for us to version illumos itself. This makes it a bit harder to reason about when it would be acceptable to renege on an interface contract, etc. In general we try to move things to Committed over time, and then generally try very hard never to break or remove those things after that point.

I'm not hugely excited about Bazel, or really any of the more complex build tools made either directly for, or in the image of, the large corporate monorepo tooling.

Right now we have decades of accumulated make stuff, with some orchestrating shell. It's good in parts, and not in others. What I would ideally like is some bespoke software that produces a big Ninja file to build literally everything. A colleague at Oxide spent at least a few hours poking at a generator that might eventually suit us, and while it's not anywhere near finished I thought it was a promising beginning I'd like us to pursue eventually!

https://github.com/oxidecomputer/eos

The remainder of the staff working on SmartOS, and the remaining IP like trademarks, and customers and so on, were all bought from Samsung by MNX so they could take it over. They're doing a great job over there with it, and unlike Samsung they actually want it!

I'm part of the illumos core team and I'm quite keen to use Rust in the base of illumos, FWIW. There several contexts in which we could make good use of it, and the primary challenges in most cases is either one of release engineering or the resultant binary sizes. I'm confident we'll be able to work them out, it'll just take more exploration and effort!

The rough areas where I think things would be useful, and probably also roughly the order in which I would seek to do them:

* Rust in the tools we use to build the software. We have a fair amount of Perl and Python and shell script that goes into doing things like making sure the build products are correctly formed, preparing things for packaging, diffing the binary artefacts from two different builds, etc. It would be pretty easy to use regular Cargo-driven Rust development for these tools, to the extent that they don't represent shipped artefacts.

* Rust to make C-compatible shared libraries. We ship a lot of libraries in the base system, and I could totally see redoing some of the parts that are harder to get right (e.g., things that poke at cryptographic keys, or do a lot of string parsing, or complex maths!) in Rust. I suspect we would _not_ want to use Cargo for these bits, and probably try to minimise the dependencies and keep tight control on the size of the output binaries etc.

* Rust to make kernel modules. Kernel modules are pretty similar to C shared libraries, in that we expect them to have few dependencies and probably not be built through Cargo using crates.io and so on.

* Rust to make executable programs like daemons and command-line commands. I think here the temptation to use more dependencies will increase, and so this will be the hardest thing to figure out.

The other thing beyond those challenges is that we want the build to work completely offline, _and_ we don't want to needlessly unpack and "vendor" (to use the vernacular) a lot of external files. So we'd probably be looking at using some of the facilities Cargo is growing to use an offline local clone of parts of a repository, and some way to reliably populate that while not inhibiting the ease of development, etc.

Nothing insurmountable, just a lot of effort, like most things that are worth doing!

Go offers channels in the standard library, which you can use to do message passing, certainly (so does Rust). But I/O through the stdlib is absolutely asynchronous. I/O routines that would block, like sending and receiving from the network, are all magic async switch points where your goroutine can be replaced on the current OS thread with another. When epoll (or whatever) signals readiness on the blocked descriptor you get switched back on. As described in the previous post, the asynchronous I/O is hidden from you as an implementation detail of the language but it's absolutely there.

What is it that you think engineering entails, exactly? In a software business your job is to produce artefacts the business can sell, without spending so much in the process as to destroy any hope of profit. Part of this involves talking to (not manipulating!) your colleagues, including product management.

Can you give some examples of the sort of harmful and dangerous untruths you're referring to? Sounds positively deleterious to me!

"Redelivery versus duplicate" is doing quite a lot of work in there. This is an "at least once" delivery system providing building blocks that you can use to cope with the fact that it's physically impossible to prevent redelivery under some circumstances, which are not actually that rare because some of those circumstances are your fault, not Google's, etc.

Is this... a service for spamming patent applications as fast as you can without paying lawyers as much as we used to? Can't see how that could exacerbate all of the deep problems with the patent system!

Can you perhaps expand on the incentives and the mechanism of increased danger?

Perhaps removing a pricing scheme so complicated that it literally can't be modelled usefully by the customer would be even better?

An apprentice is another person performing the same kind of work as the carpenter. That's fundamentally different from using an LLM, which is not a person and does not function like a person.

Whether you think LLMs are spectacularly worthwhile or odious and destructive, it's crucial not to classify them as being a person instead of a software tool.

You don't need an expensive, opaque, antisocial system to run interference against your users. What you need is literally just a checklist.

Give the user a checklist instead of just freeform text -- where they can check off the three individual things to try. When they've checked them all off, they can go back to the well for another response from support.

- Perfectionism, but defined as "Wanting to make things amazingly well, but never finishing them"

- Procrastination

- Issues from context switching and distraction

Is this ... ADHD?

Surely you could just... Use a different chat system?

I think it might actually be _the wrongdoing_ that really exposes you to legal liability.

truss(1) is not DTrace-based. It continues to be implemented in terms of the process control and instrumentation facilities provided by the proc(5) file system, as it has been for a long time.

Dear god I want off Mr Bone's Wild Ride. I can't wait for even more pull request spam, now fully automated.

> Even a cheap language tutor is 20$ an hour. With AI it'll basically be free.

Only until you drive the last tutors out of work. Then somehow it will be $40 an hour again.

Seems like a lost opportunity to introduce 0xFF as the error code that means "look in the extended error field we've since added to the message, which includes a u32 _and_ a human readable string for display" to be honest.

An incredibly long ramp up to complaining about centralised control by rent seekers (a very reasonable complaint!) which gets bogged down in some ostensibly unrelated shade about whether client-server computing makes sense (it does) or is itself somehow responsible for the rent seeking (it isn't; you can seek rent on proprietary peer to peer systems as well!) to then arrive at:

> There’s going to be a new world of haves and have-nots. Where in 1970 you had or didn’t have a mainframe, and in 1995 you had or didn’t have the Internet, and today you have or don’t have a TLS cert, tomorrow you’ll have or not have Tailscale. And if you don’t, you won’t be able to run apps that only work in a post-Tailscale world.

The king is dead, long live the king!

FWIW, I would be inclined to standardise on PIV/CAC devices (i.e., smart cards), for which there are standard USB readers and drivers and protocols. You can get started with YubiKeys because they're relatively reliable, if a little expensive, and they have good support for PIV/CAC -- but if you stick to what smart cards can generically achieve you won't get shafted by only having a single supplier in the future when Yubico inevitably becomes less attractive for some reason or other.

> The output of a machine simply does not qualify for copyright protection – it is in the public domain.

The machine, such as it is, is generally not acting on its own. A person operates the machine, and presumably is on the hook for infringement on some level.

Consider: what if one directs the machine to reproduce a specific body of code and it ostensibly does so. Was there copying?

What if I have a person read out that body of code and I type exactly what I hear? I used a machine to produce the resultant text file, but it's pretty clear that copying has occurred then.

FWIW, I'm not a copyright maximalist, but I don't think you can win a conflict by abstaining from playing the game the other team is playing. That is: the companies producing, and drawing incredible and exclusive economic value from, industrial scale plagiarism machinery are hardly going to stop ruthlessly enforcing copyright on their own proprietary software. It would seem best, if it's the goal, to get laws changed in advance of simply declaring, lopsidedly, that this is all fine.

> the situation in the wild is that most of these TUI users have a sub-optimal development experience that causes them to push more defects

What an amazing pile of unsubstantiated horsefeathers!

> Unfortunately, I don’t know how to convince others, especially those above me, that if I do less of the features they want, the product will be better, despite trying.

I think it boils down to the fact that this is nowhere near being an absolute irreducible truth. Sometimes if you don't do the features I want, the product will suck and I'm getting another product from someone who has something other than a ruthless asceticism as their only core value.

The Windows mechanisms you're mentioning were also added over the course of many, many years. Much of Windows also happened a long time after UNIX signals were invented.

If you're including all that other stuff, it's probably fair to include all of the subsequent development of notification mechanisms on the UNIX side of the fence as well; e.g., poll(2), various SVR4 IPC primitives, event ports in illumos, kqueue in FreeBSD, epoll and eventually io_uring in Linux.

Well then surely it should be "UpdAda"?

(I hardly...)

> 9p+encryption on top instead of NFS, much better

NFS with IPsec for authentication and privacy seems similar in principle, with the added benefit that it's widely available.

Yes, ZFS has the same fundamental issue that all COW file systems have here. We have a reserved pool of space that you can't use except for operations like removing stuff.

The new problem with that reserved pool mechanism is that in 2024 it's probably way too big, because it's essentially a small but fixed percentage of the storage size. Don't let people use thresholds of total size without some kind of absolute cap!