mioelnir

I've talked to a mail admin from one of the companies involved in "Email made in Germany" once about it, and his reply was basically that of course it was marketing, and of course the techs had the idea to enable TLS in the drawer for years.

But at their scaling, enabling TLS means a lot of additional compute power, and due to that marketing campaign they now finally got the budget to install the additional hardware and enable it. Before, there was no business value that justified to spend that much more to get an - to the outside observer - unchanged product.

BioNTech developed the vaccine now mass-produced by Pfizer. For that, they received $445m from the German government. So, as a tax-paying German citizen I can say, not only will I do that, but even better, I already did.

It also feels deeply wrong to pull the "but all the research efforts that did not lead anywhere" argument, when Pfizer did not do the research in the first place. They should get compensation for organizing the huge trial, of course; that expertise was why they were on-boarded in the first place. And nobody expects them to manufacture that stuff at loss or cost. But we should not accept public money buying them goose laying golden eggs either.

They are not immutable in the 'chflags uchg,schg ' sense.

Updating these files is not in any way shape or form a hassle anymore if you do not update them. etcupdate has that solved. Even mergemaster has specific options to handle unchanged /etc that only diffs in svn-id tags and similar.

But in my opinion the basic premise of the article is false. mergemaster and etcupdate with their diff and 3-way merge capabilities are there because these files are assumed to have local edits.

The startup procedure, scripts, options are expected to be customized; thus the update procedure has handling to preserve local edits.

FreeBSD has had fully integrated, working ZFS for over 10 years. You were so excited to deploy the BSD killer app, you forgot to do so for ten years.

I can only tell you, whatever scary differences you expect between Linux and FreeBSD are probably no more than between any two Linux distros with different packaging systems.

Ten years ago, fresh out of a failed stint at university, I applied for a junior position at a Linux shop. Would nowadays probably be called junior system engineer or so. The night before the interview, I read around a bit in Stevens' TCP/IP Illustrated as well as Design and Implementation of BSD (to calm my nerves). I told them honestly, I had maybe 15 lifetime minutes on a Linux shell. But I started with FreeBSD4.4 and had by then already 8'ish years of experience on general *nix administration.

I'm still there. Pivoted around and upward a couple of times internally. But I still run FreeBSD on my workstation to get things done. And we're still fundamentally a Linux shop.

But the root cause of my career is a friend at university handing me a FreeBSD 4.4 CD. It is a tremendous system if you want to learn about the services a kernel offers to its userland. If you care to make the dive, it not only tells you the what and how, but the why and all the compromises that had to be made along the way. And that understanding is universal.

FreeBSD may be well known as a solid production platform. It's true strength is as the foundation for not only a lifetime of learning, but a lifetime of understanding.

Or not. Landesregierung BaWü for example distributes the daily COVID-19 news via Threema.

There is also another german word in the realm of centralization - Gleichschaltung. It is nowadays exclusively used to describe the centralization of government functions and bodies during the beginning of the 3rd Reich. Big central government offices, their tracking capabilities and emerging network effects were one of the required precursors for what came later.

It is why many parts of the modern/post-war German bureaucracy were intentionally set up inefficient and why we still dislike any "central databases" for anything, from law enforcement to tax collection. Slow, decoupled government systems slow down unwanted usage patterns much more than valid ones, are generally harder to game (try explaining your urgent need for some data to a rural bavarian city hall employee) and easier to monitor/verify for citizens.

By dropping transmutative alchemy from the sprint, allowing the implementation of a capability system on top of a now unforgeable subset of existing resources...

Simulated DC failure is more often then not just traffic flow engineering. It is more about testing the DC that takes over the traffic than it is about testing service restart in the inactive DC.

There is little to test about the introduction of a hard fault, but the service resumption in the other DC is full of data to analyze. Also, in such a setup, getting the fault location running again is not on a hard clock, since it is about restoring redundancy instead of the service.

> But something about is very compatible with the way my mind works.

Yes. For me it is channels. After nearly 20 years of UNIX'ish systems, pipes are a mental abstraction that I do not have to think about any more. And channels fit right in, they feel much closer to a how a pipe is used on the cli than a pipe or socketpair ever did in code.

For example a range loop over a closed channel is, for me, piping things to xargs. It's easy to understand, reason and conceptualize because it feels familiar.

This article lost me after just the first couple of paragraphs. If Leibniz is, as quoted in the text, `recognized for first formally proposing` the binary system - then what relevance does it have that someone had the idea earlier (and thought it was useless)? He is not recognized for having had the idea first, he is recognized for seeing an application of it and formally proposing and specifying it.

Roentgen wasn't the first to observe x-rays either, he was the first to perform extensive studies and publications on them.

Another option would be to make it an easily abortable multi-step process with a long delay timer, ie. you disable 2FA and an abortable 3-4 day timer starts ticking with frequent reminder mails inbetween. Once the timer is done, you can confirm the deactivation.

Video games have been doing similar things for character deletion for years, yet it is rarely if ever found for account credentials in general.

As someone that has both Kafka and Redis in use without issue, for years, (and is about to replace a lot of misused Redis instances with Kafka) I really fail to follow your points.

So, a Zookeeper cluster can't survive accidentally injecting just the right malicious data that will make it keel over. I'm sorry, how do you accidentally achieve that? Do you also accidentally configure your Redis Sentinel to replicate from /dev/null?

As a matter of fact, this announcement comes at a very inopportune time for me. antirez had the epiphany of reading on IRC about replicated logs instead of looking at the opening paragraphs of the Kafka documentation, and all the Redis evangelists at my job will now try to shoe-horn the wrong usecase back into Redis because Redis!1cos(0)!. Sigh.

Regarding point 3, unless your system is under massive memory pressure, no caught-up Kafka consumer should be serviced from disk. Old offsets that are flushed out of memory because you do not have it obviously are served from disk, with essentially linear reads of disk blocks (of consecutive logical addresses if flush sizes are large enough that then can end up on disk in any number of ways, depending on how much the firmware lies, I know) of the requested file.

I really can not see how Redis is going to perform "much better" reading from disk once the entries are no longer in RAM. At that point both Kafka and Redis have to read from disk, and you either have the IOPS to serve all the lagging consumers or you don't. Maybe you have enough of them to service 1 or 2 concurrent reads, maybe 10-12. But for the same messages counts, sizes and concurrent consumers, your workload will become IOPS bound rather fast.

Note: "much better" to me implies 10x+ better, not "my C library read() is 2.3% better than your Java".

I don't think a careful, sane user who's concerned about their data would be on btrfs in the first place.

Then now is his moment to learn about open source licensing. Doesn't mean the infraction does not count or we should let it slide. As any license, even MIT with its few requirements must be enforced to be worth its bytes.