jclulow

Kids being forced to start school in basically the middle of the night is another especially American phenomenon that requires a separate solution, I feel.

I'm glad that works for you! The challenge with executive function issues is that it can be literally impossible to reliably do things like that in advance! Especially months and months in advance. It's also a challenge to delay gratification; when I find something that really speaks to me about someone, I really just want to give it to them straight away.

As a result I think I place a pretty low value on events centred around gift giving -- and yet I live in a society, etc.

Speaking from personal experience: people with ADHD, who don't have their shit together but desperately want to avoid disappointing the people they care about. People who then get hoodwinked by the bald faced lies everybody from Amazon right through to the courier staff will tell you about projected delivery dates and "oh, gosh, sorry, you know we just attempted delivery but couldn't get in!" (while you're sitting in front of the building)

Note that the rack doesn't accept DC input, like lots of (e.g., NEBS certified) telco equipment. There's a bus bar, but it's enclosed within the rack itself. The rack takes single- or three-phase AC inputs to power the rectifiers, which are then attached to the internal bus bar.

Yes we're definitely building the next generation of equipment to fit into the existing racks!

Wild that one would pick the only platform with a rubbish VMs and CI story as the OS to use for building software!

Is that true? All of my Internet and mobile telephone service is post-paid with automatic billing. I know one can get prepaid plans from some providers, but how are you arriving at "usually"?

No honour among thieves, I guess!

> I very much resent the people who abuse the meds I need to function ... I resent the meth addicts ... it means I have to pee into a jar every three months to prove I'm not a meth addict who is abusing methylphenidate.

It's important to remember that no addict did this to you. An addict doesn't force Kaiser to charge me $20 when they demand I piss in a cup in order to receive my legally prescribed medication. It's fucking Kaiser, and the DEA, and the mad cap conservative politicians and their shitty fucking values. Drug addicts are suffering from a health problem, just like you and I are with our ADHD. None of us have the power to influence the massive engine of carceral drug policy and the promotion of mass moral panic about people taking medication that helps them.

It's important to point the anger at the right people.

> Let's ignore for now that this will surprise every C developer out there that have been doing if (NULL != ptr) free(ptr) for 50 years now.

If you've been doing C for five decades, it's a shame not to have noticed that it's totally fine to pass a NULL pointer to free().

FWIW, I don't otherwise agreed with the thesis. I've written probably ten FFI wrappers around C libraries now, and in every case I was able to store C pointers in some Rust struct or other, where I could free them in a Drop implementation.

I also think it's not actually that unusual for C allocators (other than the truly ancient malloc(3C) family) to require you to pass the allocation size back to the free routine. Often this size is static, so you just use sizeof on the thing you're freeing, but when it's not, you keep track of it yourself. This avoids the need for the allocator to do something like intersperse capacity hints before the pointers it returns.

Cisco have sat on the steering committees for a lot of things where they had a proprietary initial version of something. It's not that unusual, and also, it's often frankly not actually that open; e.g., see the rent seeking racket for access to PCI documentation, or USB-IF actively seeking to prevent open source hardware from existing, etc.

Alas, it's pretty clear that we won't!

That's generally what the Cache Directory Specification attempts to cover: https://bford.info/cachedir/

Lots of things like the Rust tool chain now create the CACHEDIR.TAG files so that backup tools can ignore that part of the hierarchy. Alas, I believe the rsync folks refuse to implement it.

Setting the SPARC bits aside, I feel like the Ultra 20/24/27 machines were well-constructed 64-bit x86 machines with regular AMD and Intel processors and ECC memory and reasonable fans and so on. I don't remember how they were on price, but I feel like they were not outrageous when compared to similar lines from Dell or HP at the time.

I believe these days SSH is willing to forward a UNIX domain socket to a remote TCP port, or a local TCP port to a remote UNIX domain socket, or any combination of the two families really. You could use names locally, if your client tools are willing to do AF_UNIX!

> notify the kernel you write something in the last page which is actually write-protected, so it triggers the kernel trap

Right, that's a page fault; i.e., a context and privilege level switch. I can't imagine that's going to be any cheaper than a system call.

> None? You don't need really need a user-space thread to execute code in the kernel

I didn't mention user space. There are threads in the kernel. From a scheduling perspective, somebody needs to be billed for the work they're doing. If it's not the process that invoked the system call, that seems like a pretty easy way to induce a bunch of noisy work on the system in excess of what the regular scheduling algorithm and resource capping would allow.

> With multi-core systems we have today, arguably having a whole core dedicated exclusively for some core OS functionality could be more performant than having this core "constantly" switch contexts?

Perhaps! Without a design and some measurement it seems impossible to know. Logically, though, you'll still have (kernel) threads of some kind executing in that special partition. They'll compete for execution time, just like user mode threads compete for execution time, at which point for fairness you'll have to figure out how to bill the work back to the user process somehow.

This article, and indeed much of the discourse about the facility out in the wild, could really use some expansion on at least these two points:

> The application submits several syscalls by writing their codes & arguments to a lock-free shared-memory ring buffer.

That's not all, though, right? Unless you're using the dubious kernel-driven polling thread, which I gather is uncommon, you _also_ have to make a submit system call of some kind after you've finished appending stuff to your submit queue. Otherwise, how would the kernel know you'd done it?

> The kernel reads the syscalls from this shared memory and executes them at its own pace.

I think this leaves out most of the interesting information about how it actually works in practice. Some system calls are not especially asynchronous: they perform some amount of work that isn't asynchronously submitted to some hardware in quite the same way as, say, a disk write may be. What thread is actually performing that work? Does it occur immediately during the submit system call, and is completed by the time that call returns? Is some other thread co-opted to perform the work? Whose scheduling quantum is consumed by this?

Without concrete answers that succinctly describe this behaviour it feels impossible to see beyond the hype and get to the actual trade-offs being made.

They also just totally fucked anybody making use of the Google Photos API to access their own data: https://news.ycombinator.com/item?id=41604241

They're a trash company, and anything you get from them, even when you pay for the storage, is at best accidentally delivered to you and they could roll over in their sleep at any moment and snuff it all out.

I'm not sure why anybody would respect that licence term, given the whole field rests on the rapacious misappropriation of other people's intellectual property.

Flames... Flames from the side of my face. This is an absolute user hostile "Go Fuck Yourself" by Google. There is now no way for a user to enumerate and incrementally back up their photos (read: access their own data). Your application would only be able to see either photos that you create with the backup tool, or that you have explicitly shared with it by hand.

Fuck you, Google.

This is not strictly accurate. ZFS records checksums of the records of data that make up the file storage. If you want an end to end file-level checksum (like a SHA-256 digest of the contents of the file) you still need to layer that on top. Which is not to say it's bad, and it's certainly something I rely on a lot, but it's not quite the same!

SMF is OSS. The CDDL is an OSI approved licence. I'm not aware of any reason one couldn't readily ship user mode CDDL software in a Linux distribution; you don't even have the usual (often specious) arguments about linking and derivative works and so on in that case.

We are trying to build a business here. The goal is to sell racks and racks of computers to people, not build a menagerie of curiosities and fund personal projects. Everything we've written here is real, at least from our point of view. If we didn't think it would work, why would we throw our own business, and equity, and so on, away?

The reason I continue to invest myself, if nothing else, in illumos, is because I genuinely believe it represents a better aggregate trade off for production work than the available alternatives. This document is an attempt to distill why that is, not an attempt to cover up a personal preference. I do have a personal preference, and I'm not shy about it -- but that preference is based on tangible experiences over twenty years!

While we have a common ancestor in the original UNIX, so much of illumos is really more from our SVR4 heritage -- but then also so much of that has been substantially reworked since then anyway.

Yes, my personal goal is to ensure that basically everything we do in the Oxide "stlouis" branch of illumos eventually goes upstream to illumos-gate where it filters down to everyone else!

Folks are working on it! I believe it boots on some small systems and under QEMU, but it's still relatively early days. I'm excited for the port to eventually make it into the gate, though!

It's not a blog post, it's an RFD. We have a strong focus on writing as part of thinking and making decisions, and when we can, we like to publish our decision making documents in the spirit of open source. This is not a defence of our position so much as a record of the process through which we arrived at it. This is true of our other RFDs as well, which you can see on the site there.

> It also should not matter to their customers. They get exposed APIs and don't have to care about the implementation details.

Yes, the whole product is definitely designed that way intentionally. Customers get abstracted control of compute and storage resources through cloud style APIs. From their perspective it's a cloud appliance. It's only from our perspective as the people building it that it's a UNIX system.

Yes, to be clear this is not meant to be a criticism of software quality at OpenBSD! Though I don't necessarily always agree with the leadership style I have big respect for their engineering efforts and obviously as another relatively niche UNIX I feel a certain kinship! That part of the document was also written some years ago, much closer to 2018 when that service got started than now, so it's conceivable that we wouldn't have said the same thing today.

I will say, though, that single VCPU guests would not have met our immediate needs in the Oxide product!

FWIW, founder mode didn't exist five years ago when we were getting started! More seriously, though, this document (which I helped write) is an attempt specifically to avoid classic FUD tropes. It's not perfect, but it reflects certainly aspects of my lived experience in trying to get pieces of the Linux ecosystem to work in production settings.

While it's true that I'm a dyed in the wool illumos person, being in the core team and so on, I have Linux desktops, and the occasional Linux system in lab environments. I have been supporting customers with all sorts of environments that I don't get to choose for most of my career, including Linux and Windows systems. At Joyent most of our customers were running hardware virtualised Linux and Windows guests, so it's not like I haven't had a fair amount of exposure. I've even spent several days getting SCO OpenServer to run under our KVM, for a customer, because I apparently make bad life choices!

As for not discussing the social and political stuff in any depth, I felt at the time (and still do today) that so much ink had been split by all manner of folks talking about LKML or systemd project behaviour over the last decade that it was probably a distraction to do anything other than mention it in passing. As I believe I said in the podcast we did about this RFD recently: I'm not sure if this decision would be right for anybody else or not, but I believe it was and is right for us. I'm not trying to sell you, or anybody else, on making the same calls. This is just how we made our decision.

For what it's worth, we at _Joyent_ were seriously investing in bhyve as our next generation of hypervisor for quite a while. We had been diverging from upstream KVM, and most especially upstream QEMU, for a long time, and bhyve was a better fit for us for a variety of reasons. We adopted a port that had begun at Pluribus, another company that was doing things with OpenSolaris and eventually illumos, and Bryan lead us through that period as well.