A thermostatic mixer is the usual solution. Set your desired temperature and the valve dynamically adjusts the hot and cold flows to produce that output regardless of input temperatures and presures.

Works great until it jams at the “instantly vaporize target” setting. Which reminds me, I must call a plumber…

You can have your drugs, or you can have Koffing blowing smoke. Make your choice, but choose wisely.

That’s not helping…

Like a sea turtle trying to get up on a raft.

What a mental image. Brain bleach, stat, please.

Threads like that explain a lot about the state of the world.

My god, is systemd ever a piece of crap. Coupled with ‘consistent[ha!] naming’ it’s the single most likely thing to cause a field engineer to scream into the partially-lit datacenter in abject rage and hate. Even more if they remember how fucking sysVinit actually delivered on the promise. Even more if they still remember how well inittab Just Worked.

I agree with everything you’ve said, but this paragraph in particular resonated. We used to have a clean, simple, and predictable, system. Now we have exciting race conditions, a massively over complicated monolith (“but it’s not”, I hear the Lennart’s fans scream, “you can just install the bits you want”. To them I say “Try it. You’ll soon wish for the sweet release of death. Install a good init system instead”), and once simple tasks being swamped by poorly designed tooling.

I’d say the entire design of it is badly thought out, but that implies there was much though given to it’s design at all. It seems more like it simply coagulated. As another commenter said, it’s become popular because it makes the disto builders’ lives easier, not because it’s better, and that leaves everyone actually using the thing in the lurch.

I won’t say a bad word about Gentoo, I enjoyed running it, but if you want to use sysvinit, Debian works fine with it. There’s a page on the wiki (linked form the install guide) on how to do it here. I’ve not run into any issues over the time I’ve been running like this, and having a clean init system makes my day a lot better.

That’s not the only way to do it. In quite a lot of situations you can, instead, generate artificial data that is statistically similar to the original data set and use that instead. That works well for things like system testing, performance tuning and integration testing. Done right, you can even still pull out useful corelations without risking deanonymising the data.

Well obviously. I mean, have you ever tried eating those things without sauce? They’re bland, dry, and uninteresting. Clearly that crow has a more refined palette than that.

It probably also helps lubricate it to make it easier to swallow, crows really are smart.

Sure, they blew a hole in the building, but the pizza was perfectly cooked, so mission accomplished.

Goats are actually malevolent vegetables.

It’s not the buyer saying “I owe you”, but the issuer of the currency (actually, usually just the notes, coins are considered to have value). The first person/entity to get the note gave, or promised, the issuer (usually the central bank) something of value, and the issuer gave them a token (note) saying the bank owes the holder of that note a certain amount of value. The recipient can then trade that note freely, as can future recipients, in the knowledge a vendor will accept it for its face value. So, yes, you’re trading debt when you use money, but it’s the bank’s debt to the holder, not the debt of the buyer.

Typically the bank issue money when someone takes a loan, i.e. promises that they will pay the bank the value of the loan plus interest.

I agree that them having users’ phone numbers isn’t ideal. There are other identifiers they could use that would work just as well. However, both the client and server are open source, so you can build, at least the client, yourself. If you can content yourself that it does not leak your ID when sending messages, then you don’t need to trust the server as it does not have the information to build a graph of your contacts. Sealed sender seems to have been announced in 2018, so it’s had time to be tested.

Don’t get me wrong, the fact they require a phone number at all is a huge concern, and the reason I don’t really use it much, but the concern you initially stated was addressed years ago and you can build the client yourself to validate that.

You’re correct that if you use the system the way it used to work they can trivially build that connection, but (and I know this is a big assumption) if it does now work the way they say it does, they do not have the information to do that any more as the client doesn’t actually authenticate to the server to send a message. Yes, with some network tracing they could probably still work out that you’re the same client that did login to read messages, and that’s a certainly a concern. I would prefer to see a messaging app that uses cryptographic keys as the only identifiers, and uses different keys for different contact pairs, but given their general architecture it seems they’ve tried to deal with the issue.

Assuming that you want to use a publicly accessible messaging app, do you have any ideas about how it should be architected? The biggest issue I see is that the client runs on your phone, and unless you’ve compiled it yourself, you can’t know what it’s actually doing.

Strictly you’re having to trust the build of the client rather than the people running the server. If the client doesn’t send/leak the information to the server, the people running the server can’t do anything with it. It’s definitely still a concern, and, if I’m going to use a hosted messaging app, I’d much rather see the client built and published by a different group, and ideally compile it myself. Apart from that I’m not sure there’s any way to satisfy your concerns without building and running the server and client yourself.

‘Sealed sender’ seems to avoid this by not actually requiring the client to authenticate to the server at all, and relying on the recipient to validate that it’s signed by the sender they expect from the encrypted data in the envelope. As I mentioned in another reply, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address this issue.

Whilst I absolutely agree it’s correct to be skeptical about it, the ‘sealed sender’ process means they don’t actually know which account sent the message, just which account it should be delivered to. Your client doesn’t even authenticate to send the message.

Now, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address the very issue you’ve been pointing out. Obviously it’d be better if they didn’t have your phone number at all, but this does seem to decouple it in a way that means they can’t build a connection graph.

With ‘sealed sender’ your phone number, or any other identifying information, is not included in the metadata on the envelope, only the recipient’s id is visible, and it’s up to the recipient’s client to validate the sender information that is inside the encrypted envelope. It looks like a step in the right direction, though I don’t use signal enough to have looked into auditing it myself.

It’s a non-starter for me because I sync my notes, and sometimes a subset of my notes, to multiple devices and multiple programs. For instance, I might use Obsidian, Vim and tasks.md to access the same repository, with all the documents synced between my desktop and server, and a subset synced to my phone. I also have various scripts to capture data from other sources and write it out as markdown files. Trying to sync all of this to a database that is then further synced around seems overly complicated to say the least, and would basically just be using Trillium as a file store, which I’ve already got.

I’ve also be burnt by various export/import systems either losing information or storing it in a incompatible way.

I think that the point is it’s entirely pointless building something like this into the email system. It should be a separate system that you can choose to use if you want it. Building it in just opens questions about exactly what they’re doing with your data, despite their assurances.