jclulow

I was diagnosed in my 30s. In retrospect, it explains a lot of difficulties I have had for my entire life. I wasn't hyperactive, so they mostly went unnoticed by other people -- it's really hard to know whether your struggles are unusual or not from the vantage point of your own head.

I would say that if you feel good and life is working for you, then you don't need to do anything. If your life circumstances change (e.g., for me, our having a child definitely exhausted my ability to grit my teeth and push through my focus issues with all nighters, followed by sleeping all day to recover) then help is generally not far away!

As a person with ADHD whose executive function is markedly improved by stimulant medication, and who knows a lot of people in the same boat, the whole thrust of the introduction to this article is pretty amazingly tone-deaf and specious.

It's still early days for us obviously, but we have some of our equipment in a cage in a regular colocation facility, on the Internet. We're generally able to provide access to systems there so that folks can kick the tyres as part of a pre-sales engagement. If you or your customers are interested, you're always welcome to reach out to our sales folks and have a chat!

> So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.

Yes, delivering device control software in a browser with webusb from a cloud platform will usher in a whole new chapter of keeping people from truly owning the scientific research equipment they have procured!

Yes, frankly. It results in terrible outcomes for basically everyone, which ultimately hurts patients the most.

It's actually possible to produce a stack trace of sorts, if you use a lot of bash functions. One possible implementation is: https://github.com/TritonDataCenter/sdc-headnode/blob/master...

There's a common thread in the comment you're replying to and another comment made by the same author, in which they appear to quietly suggest that perhaps it's just TBIs and sleep deprivation. I get the sense it's a theme.

> One common feature of Western culture, or at least US culture, is to play down PTSD

Yes indeed!

It's really hard to read this comment as anything but a quiet suggestion that perhaps PTSD is a result of mental health workers and not the result of trauma. What seems far more likely is that people trapped in cultures that have not really developed a strong mental health response (e.g., 20th century America) have few if any resources available to help people with their literally invisible condition, and they have been trained through stigma and other "culture-bound" behaviours to keep their problems to themselves and show that stiff upper lip.

I've thought about this a lot, and I feel that it's not really as big a detriment to safety as you might expect. It's not exactly the same as an air gapped token generator, obviously, but:

- It's still something you have, and don't know: the TOTP secret. What you transmit is a short term generated code, but unlike your password, you don't send the secret key at any point.

- The downside of air gapped tokens is that when they break or are lost or stolen, you have to somehow re-enroll with a new device. The security properties of this process are deeply variable between authorities, and there's always the risk of just total loss of access. If you have the TOTP secrets backed up in Bitwarden, you can avoid this.

- Vault software can keep all of these secrets encrypted using keys protected by biometrics on a phone, or an external device like a Yubikey, that are only unwrapped by a particular physical interaction. Usually the vault software does a better job than the average person of determining whether you're looking at a legitimate authentication prompt or a phishing site, and I suspect it's less likely to automatically enter your TOTP code into the wrong than a person is when transcribing it by hand or copy pasting.

Much of this article is bullshit, to be honest. There's a lot of wailing and gnashing of teeth about how you can only have one version of python installed at a time, but obviously that's patent nonsense: lots of OSes shipped a python2 and a python3 binary for many years, and some are only just giving up the former now as it it's all totally EOL.

Also the idea that everything has to go into a flat /bin directory is nonsense too. My experience is chiefly with illumos, but we have inherited a number of separate trees for compatibility with different standards; e.g., /usr/xpg4/bin had some POSIX binaries where they were incompatible with the default /usr/bin binaries. There were also SunOS (BSD) compatibility binaries in /usr/ucb for a long time. Commonly different JDK versions could be installed alongside one another under /usr/jdk/$version. Unbundled software from many other places would find its way into trees in /opt. Even shared libraries can be installed alongside one another without conflicts, provided you do the right thing with ABI stability and sonames etc.

I have no doubt that other OSes have made a set of similar decisions to provide various levels of binary compatibility and evolution over time, depending on how important it has been to their respective user communities and customer bases.

I promise that we have shipped several of them around. We have one parked in a cage in the south bay, and I believe aside from getting the crate on and off the truck, it was almost certainly rolled into the DC on its castors. I have personally helped push one or two of them into the crates we use, which is something of a production but doable. I also occasionally have to shunt a few of them around the office, which I have been able to do on the castors there as well; the floor is relatively flat concrete.

FWIW, I believe we've now fixed the clone-related crash issue, as of https://www.illumos.org/issues/14003

> occasionally, updates can break things

But other than that, Mrs. Lincoln, how was the theatre?

That is in fact how crash dump works on illumos systems. Once you enter a kernel panic, interrupts are disabled, all other CPUs are brought to rest, etc. Then the panic code takes the pages to write to the dump and passes them to a special routine in the driver for the dump device: usually either a slice on a disk or a zvol). That driver is responsible for getting the device into a state where polled I/O can be performed, and to write the pages out. At the end the system reboots, and on the next boot a program called savecore inspects the dump device to see if there is a new dump, and if there is it transfers it into a new file.

Yeah, we definitely only intend Helios to run on either the Oxide rack or in service of software engineering work surrounding the rack (that's what we use the ISO installers and virtual machine images for).

If you're interested in a distribution targeting end user use of illumos on servers, I would absolutely recommend looking at OmniOS! Helios is very closely based on OmniOS r151046 LTS, and we use that LTS of OmniOS release directly for non-Oxide-rack infrastructure systems inside Oxide as well.

FWIW, though for historical reasons we use dmake to build the core operating system, I tend to recommend people use GNU make (gmake) for new Makefiles in other consolidations. It's broadly available (including on other platforms) and has more modern features.

> sprinkling LD_LIBRARY_PATHs here and there and then removing undocumented dot files here and there

I obviously don't have any context about the issues you were facing at the time, and I can't really figure it out based on the advice you ostensibly received. I'm definitely sorry if we have lead you astray in the past, but those are not workarounds I would encourage people to use today. If there's some aspect of the build process that requires workarounds like you're describing, it's definitely a bug and we'll fix it when we're made aware as best we can.

As for the rest of it, I think you're putting the cart before the horse on some level. An operating system is a large and complex thing to work on, regardless of whether it's built with make or ninja or bazel or whatever other build tool.

The Rust toolchain is another similarly complex body of software, which also has a large and at times inscrutable build process. I know because I have personally contributed to it, and had to figure out how to get it to work. Rust obviously has more active contributors than illumos, but it also has vastly more active _users_ -- it is a body of software that has broad applicability to many people and the work they do.

For illumos to continue to succeed as an actively maintained project, what we need to do is continue to inspire _users_ to want to use it. Nobody wants to work on an operating system they don't personally need to use at all. We draw contributions today from a mixture of community driven distributions making fixes or adding features, and by people employed by companies like Oxide who have a vested economic interest in the deployment of the software.

None of this is to say that we're perfect, or that we're not trying to improve things. Just that we're trying to put build system improvements in the proper context amongst all the other work there is to do with our limited resources. It's probably more important that we have support for new Intel client NICs like you would find in a modern desktop system, for example, than it is that we replace make. It's important that we continue to add system calls and libc facilities that other platforms have adopted in order to ease software porting. It's important that we continue to maintain modern JDKs and Python and Go and Rust and C/C++ compilers. It's important that we keep up with security issues and the endless stream of mitigations imposed by the sieve-like nature of speculative CPUs.

There's actually quite a lot of stuff going on for us all the time, and we do still find time to improve the build system. If you have more specifics in mind, that's fantastic and we'd love to here about them concretely! I would encourage you to channel your enthusiasm into writing an illumos project discussion (IPD) describing the issues you see and the work you'd propose to sort them out! You can see some examples of existing IPDs at https://github.com/illumos/ipd

And as ever, if you hit issues in the build as it stands, please file bugs! We can't fix things we haven't heard about.

Cheers.

I've noticed you make this comment repeatedly when illumos is mentioned on HN. I think you're underestimating the irreducible complexity of the build process for what is essentially a whole UNIX operating system, save for a few external dependencies. It's not just a kernel, but an extensive set of user mode libraries and executables. The build is complex in part because it's a complex body of software.

I also think you're overestimating the extent to which make(1S) is the reason we're not more popular than Linux. There are any number of more relevant factors that make someone choose one operating system or another. Also, certainly for me personally my goal is not world domination, merely the sustainable maintenance of a body of software that helps me solve the problems that I work on, and which I enjoy using and developing as a result.

I agree we need (as do all projects!) new developers, both now, and over the long term. We work as we can to make improvements to the build process, and the documentation. We are a relatively niche project, but we do attract new developers from time to time, and we're making changes at least as rapidly as we ever have in the past. There are a number of actively maintained illumos distributions (OmniOS, SmartOS, Tribblix, OpenIndiana, and now Helios) and there are a variety of commercial interests that ship more proprietary appliances on top of an illumos base. For our part at Oxide we continue to encourage our staff to get involved with illumos development as it makes sense for them, and we try to offer resources and assistance to the broader community as well.

If you would like to contribute, we have a guide to getting started: https://illumos.org/docs/contributing/

Please, though, it's "illumos", not "IllumOS"!

I tried some of the examples on my phone but it ends up being basically microscopic because it's targetting a classic Mac resolution. I think it would help if it either did something intelligent with pixel doubling or some other scaling technique, or at least didn't disable the user's ability to zoom in when it's too small.

I remember using ACDSee in my Windows desktop era, and for what it's worth I enjoy "feh" on Linux today in a similar vein.

If you're going to drop secret masking, it at least needs to be optionally still available. Modern cameras can capture quite a lot od what's on today's bright, high contrast, high resolution, wide viewing angle screens from surprisingly far away.

Unless we're going to use a dark cloth on our phones as if they were an old view camera, I think secret masking still serves a purpose on phones.

I suppose, in that model, unplugging them?

Good news! Climate change is already making malaria worse, decreasing food security, and will presumably begin destabilising governments in some regions as a result of disasters and migration if it has not already begun to do so. Prioritising efforts to stem the tide of climate change is prioritising those things!

On at least some other operating systems, getenv(3C) and setenv(3C) are indeed thread-safe; e.g., on illumos: https://illumos.org/man/3C/getenv

We inherited our implementation from OpenSolaris, as did Oracle when they created their Solaris 11 fork. I expect at least some of the BSDs have probably fixed this as well.

Also, an apparently nostalgia-rich rose coloured recollection of the artistic expression present in earlier hand-animated cartoons that I suspect would not stand up to serious scrutiny.

> Any UI is worse than a good AI assistant that I can chat/talk to

Speak for yourself. I have zero interest in having a conversation with the computer, whether typing or (especially) speaking out loud.

Product and UI and UX work will continue to be valuable; if anything, good quality work will stand out even more amongst the oncoming tidal wave of low quality AI/LLM stuff.

I think it was more likely an emergent effect of rubbish file system and disk cache behaviour, little or no prefetching, etc, than any coordinated activity in SMB?

Note that unlike the GPL, the CDDL is file-based. It doesn't require your entire body of software to be CDDL, it just requires that you make modifications to CDDL-licenced files available under the CDDL.

Why don't they just whack it straight in the licence text then?

I'm amazed at the extent to which Google Meet's user interface remains at a preliminary technology demonstration or undergraduate project level of user interface design. The grid/gallery view is barely functional:

- you have to pick a number of tiles to fit on the screen, it cannot deduce the right number automatically

- the selection for this is buried in an options dialogue

- there is no facility to hide participants that don't have video from the tile grid, wasting screen space with useless squares containing an enlarged initial

- there is no way to flip to a second page of tiles if there are too many people to fit on the screen together, you just get a random sampling of call members

- there is apparently no way to drag to resize the space dedicated to the screen sharing display versus the video tiles

There are also other ridiculous limitations and rough edges, like the chat box silently truncating messages at about 500 characters.

It is as if nobody who works on the product is forced to use the thing.