You use distrobox (https://distrobox.it/) and move on with your life. At work I use multiple versions of Ubuntu seamlessly without messing with VMs on a host fedora box without issue. That includes building things like .deb packages.

I feel like there have been rumblings of an honor Harrington by David Weber movie for decades at this point. It it may just not happen.

Yep, simplified by removing all those silly extraneous ‘u’s

Other way around. The British wanted to differentiate themselves from colonial hillbillies so they tried to assume the appearance of culture by making the words look more French.

The threat model is getting the decrypted data.

If someone steals the device and removes the drive the data is encrypted.

If someone steals the device and powers it on, the os that wrote the encrypted data (and is presumably secured) can enforce login authorization which the thieves presumably cannot bypass.

Both of these are big ifs, but the installed os won’t just divulge the contents of the disk so the trick is locking down the disk so that it’s easy for the installed os to access but becomes useless if the disk is removed from the computer.

All of this depends on the TPM implementation not being trash, which integrated instances help with. Ultimately this is a trade off for convenience. I don’t worry about random thieves probing the buses in my computer to get my tax info, so I don’t use luks’ other stuff.

The inner platform effect intensifies.

Then this would be manufacturing liability because they are not fit for purpose.

There’s no macro system in TS that could analyze the type to build the parser. So, you work the other way and build the parser and then produce the type from that.

Async communications can be exhausting. It’s infuriating to need some bit of information and be stuck with chat because 1. People are terrible at organizing things like slack as far as I can tell. 2. Walking over to someone and having a 15 minute conversation is less disrupting to the day than tossing a mention into the void and then having responses dribble in over the next hour and a half.

A work from home full time and don’t want to go back to the office, but the periodic need for unscheduled ad-hoc communication is absolutely the most exhausting part of it.

> Walking over to someone and having a 15 minute conversation is less disrupting to the day than tossing a mention into the void and then having responses dribble in over the next hour and a half.

There’s a balance here, as the 15 minute conversation is often a 45 minute disruption for the target and often the people around them. The other challenge is in my experience the trade off wasn’t “this information cannot be obtained any other way” but more along the lines of “it’s easier to walk over than read the documentation/make any attempt to answer the question on my own”.

Asynchronous shifts the downsides to the person asking, so people tend to have strong opinions if they tend to be on one of those sides a lot more than the other.

Of course, you can also ask about the blockers ahead of time or just do something else. This does require your org to trust you with more than one strictly defined ticket at a time though.

> Of course, you can also ask about the blockers ahead of time or just do something else

Sure, but that’s going to impact the claimed time differential if you have to schedule it and wait.

I think both approaches have their merits but unless you’re in a group focused on the same goals I prefer the approach of trying to solve it yourself and trying an asynchronous message first, possibly turning into synchronous if needed, because the first two steps don’t have dependencies and will make the last more productive.

> if you have to schedule it and wait

I mean you ask away... asynchronously... then do some other task or part of task that doesn't require the blocker. By the time you're done with that you may have your answer or whoever's attention that you need.

Less disrupting the day for who?

> 2. Walking over to someone and having a 15 minute conversation is less disrupting to the day than tossing a mention into the void and then having responses dribble in over the next hour and a half.

I fucking hate this, it's less disrupting for you but the person you asked might be like me and need another 15-30 min to get back into the same focus state they were before your question came through.

If you think it's hard to go do something else while you are waiting for a response to not lose context the same applies to the other side, it can be hard to get back into the context they were pulled from.

At least with async communication I can reply when I get unfocused or finish what I was working on, even just saying "sorry, can't answer you right now" when in a state of deep focus takes me out of that state...

It's extremely exhausting being the person who gets asked multiple times a day about things outside of the current context, switching them to answer your inquiries is not effortless, it just looks that way to you.

You just set up a quick video call. I do it all the time.

Zoom calls are 10,000% more mentally draining than desk interruptions, for me.

Same here. The commute and being at the office are 100000% more mentally and physically draining than working from my own desk at home though.

My read is that whatever subset of the ecosystem bcachefs-tools just hasn’t stabilized. Presumably it will, but once everything is functionally at 1.x even if they don’t reach it officially this will be become a non-issue.

That said, having dabled in rust there’s a temptation to name breaking changes to improve ergonomics because the type system is so expressive. I almost wonder if this is an argument for simpler type systems to reduce churn.

An anecdote:

I don’t care if things look native, however I am actively repulsed by modern web design trends.