And the firmware inside that rp2040 is stored on plain old flash memory. So while the data may still be on the memory chip, the controller chip dies at just the same pace than every other usb drive - and then you can’t access it.

Well, doing none of the many chores to transform his pedo club into something socially acceptable, and instead killing his boredom by holding talks about a topic that has neither anything to do with church nor is he remotely qualified to say anything about, is on a whole other level of disrespect, isn’t it?

This is the correct answer, every device you use a bitwarden-client regularly on automatically becomes a backup

As far as I understand, in this case opaque binary test data was gradually added to the repository. Also the built binaries did not correspond 1:1 with the code in the repo due to some buildchain reasons. Stuff like this makes it difficult to spot deliberately placed bugs or backdors.

I think some measures can be:

• establish reproducible builds in CI/CD pipelines
• ban opaque data from the repository. I read some people expressing justification for this test-data being opaque, but that is nonsense. There’s no reason why you couldn’t compress+decompress a lengthy creative commons text, or for binary data encrypt that text with a public password, or use a sequence from a pseudo random number generator with a known seed, or a past compiled binary of this very software, or … or … or …
• establish technologies that make it hard to place integer overflows or deliberately miss array ends. That would make it a lot harder to plant a misbehavement in the code without it being so obvious that others note easily. Rust, Linters, Valgrind etc. would be useful things for that.

So I think from a technical perspective there are ways to at least give attackers a hard time when trying to place covert backdoors. The larger problem is likely who does the work, because scalability is just such a hard problem with open source. Ultimately I think we need to come together globally and bear this work with many shoulders. For example the “prossimo” project by the Internet Security Research Group (the organisation behind Let’s Encrypt) is working on bringing memory safety to critical projects: https://www.memorysafety.org/ I also sincerely hope the german Sovereign Tech Fund ( https://www.sovereigntechfund.de/ ) takes this incident as a new angle to the outstanding work they’re doing. And ultimately, we need many more such organisations and initiatives from both private companies as well as the public sector to protect the technology that runs our societies together.

Ah thank you, that wasn’t obvious to me from its website

Why do you prefer it over syncthing?

I don’t have one, I can only tell you that you can change the keyboard layout. The Readme of the firmware sourcecode says:

To change the keyboard layout, adjust the matrix arrays in keyboard.c.

https://source.mnt.re/reform/reform/-/tree/master/reform2-keyboard-fw

You might find more information in the mnt forum, it is here: https://community.mnt.re/

I ordered some parts from them a couple weeks ago to build my own custom laptop, and they’re finally on their way and I’m super excited! The article is missing this, but you can order hinges, keyboard (with or without case), trackball/-pad and all these things individually from them, and use them for your own purposes.

It is just mind boggeling how much MNT encourages hacking with their stuff. They even went and made a dedicated logo you can put on things that are made to work with the reform ecosystem / derivatives: https://source.mnt.re/reform/reform/-/blob/master/symbol-for-derived-works/mnt-based-reform.svg

You can also search for the founder Lukas F. Hartmann and find a couple interviews out there.

I don’t get your second paragraph. There are many markdown editors, and you can use their inbuilt methods or pandoc to convert that to epub/pdf/whatever. What features are missing from those editors?

It takes time, as it all is under heavy development. Just since very recently there are risc v sbc available that can run linux - before it was pretty much microcontrollers only. Be patient :)

Ohhh yesss, I’ve been scratching a nostalgia itch recently too with turbo, tilde and mc. I’ll absolutely try these, looks awesome! Maybe some fitting hardware would be cool too, like finally getting something with risc-v, a nice clickety-clacky keyboard and an epaper screen…

First thing to try would be cleaning your bed with alcolhol / soapy water. Grime and fat from your fingers prevents good sticking of prints.

Then, what happend to your first layer? Is it supposed to be cylindrical at the bottom too? It also looks like the first layer height is way to high: the filament is just laying around like spaghetti, not adhered to the bed

One additional counter measure that is not mentioned in the article is doing a slight z-hop (like half the layer heigt) for travels. That can help prevent depositing the ooze-drop along the travel move, given that all other mitigations are in place and the ooze-drop is small enough. Do not hop very high, because the vertical lift will pull strings out of the nozzle otherwise.

Uhhh typst looks hot, that one I need to give a spin, thanks!

Use a systemd-service + systemd-timer. You can then run “systemctl start myjob.service” to check that it runs as you expect. If it works “systemctl enable --now myjob.timer” to kick it off as scheduled

I think problems that turn up with time are also things like dependencies moving on, people with a slightly different setup which unfortunately breaks the thing or at least surfaces bugs, or that the author doesn’t even use the software anymore because it was hardware specific and they have other hardware now etc… Yes they are not obliged to anything, that’s what I think too. I was more thinking in the direction of taking some precautionary measure that makes the project stay more useful (and maybe more maintained) when the original author has long abandoned it.

Ahhh that looks very interesting! It seems to commit on actuall maintaining the projects that make it in there, hence of course trying to keep the number small and only letting relevant high quality projects in. That’s of course more than gifting ownership of a project to the public for somebody to grab, but a rather nice concept nontheless!

I like your second point, and already started polishing the thing more than I would have for just my own purposes. It’s a good way to make it easier for somebody to take it on in the future. And it’s also a measure that the original creator more likely has the will to implement while focusing on building the thing, i.e. before they moved on to other things. Also for my current project I try to keep it simple. It may not be the prettiest, most configurable or universal tool. But it has a short code and minimal dependencies. Thank you for your comment, that made me think about how traits like this can become very valuable for others.

Your first point I do anyways, and the third I’m not sure about yet. Maybe documenting such things as issues preserves them decently.

The learning curve of NixOS is also what keeps me from trying it out, hence I prefer the “take it or leave it” mantra of the immutable fedoras, and try to keep the amount of packages I have rpm-ostree layer on top minimal.

As for Distrobox, yes there’s ways it can fail, altough that happened rarely to me. What happens mostly is that the distro inside distrobox goes kaput because that’s just what mutable distros beared with a plethora of questionable tooling installed with “curl something | bash” does. But for me that’s the point of distrobox: separate all that shady cruft one may need for work/developing/etc from the host os. It’s a place for messing about without messing up the computer and with it the bits that need to keep working

I don’t know to what extent you got molested by the prophets of immutable distros yet, but I can only recommend to join the cult. Install Fedora IoT (or CoreOS) and simply know that you’ll get a working container host (powered by podman) with every update. The whole discussion about which distro might survive whatever massacre the respective package manager commits next becomes superflous: You simply get the next image that was built upstream solely to serve containers. The whole package-udpating-shengiangs is done by other people for you, you only collect the sweet result. The only “downside” is that one has to become familiar with containers, but since you run docker already that should work out. Also for stuff like tinkering with the latest tools, just put those in a distrobox. That way they are indipendent from your solid container host, and you can mess them up in whatevery way you fancy and dispose them without any traces left behind.

Edit: To give one more example why this is awesome: It wouldn’t even matter which one you install, you can just rebase to the other (IoT lives in the fedora-iot remote. silverblue, coreos and the others in the fedora remote. Just for anybody who might be confused by only looking at ostree remote refs fedora)