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.

Looks like neither Backblaze nor Carbonite support E2E encrypted backups where I do not have to send the password to the cloud, or the private key is in fact generated inside the cloud.

Which means I have to really scramble to find something else that is compatible with computer-illiterate family. Geez, not what I needed.

This of course assumes you are running around an actual multiuser system without 1777 /tmp and 077 umask like it is 1989.

...and nothing happened because it does not retroactively dedup existing data?

Over time it would become horrendously slow, I agree, since you have too little RAM by a factor of at least 8.

Well, not in a test environment, but for production updates of some NoSQL stuff, sure. Snapshot the datasets, clone them over into a new rw-dataset, run the upgrade on the clone. Upgrade went wrong and corrupted your files? Destroy the clone and make a new one, then run it again (after fixing whatever caused the corruption obviously).

Want to test the upgrade in your production environment beforehand? Well, make a clone a couple days early.

And once all works out, a few days later you promote the clone and destroy the old datasets. Need a rollback? Well, just start the old application instance on the old datasets, nothing touched them.

Doesn't work for all database types, especially if you have no possibility to replay new data into the rollback. But if your system allows it, it is really comfortable.

Well, FreeBSD's mac_portacl(4) has been around since 5.1-R (June 2003) and allows per-user ACLs on privileged ports. Although the permission is for all IP addresses, not a specific one. But one could create a virtual network device per user and assign it a mac_mls policy to restrict that interface to that user... hmmmmm...

I don't think input meant configuration file syntax here, but actual

    echo $somejson-jobspec | ifconfig

    ifconfig em0 inet 192.02.1/24 alias

I very, very rarely use named return values. My usual go-to problem is when one of the return values is an `error` that I want to set inside `recover()`.

If I remember my Apache config right, the two examples are switched. The 2.4 config should be 'Require all denied' and the 'Order deny,allow' the old 2.2 syntax.

I sometimes do a an IT jeopardy during interviews and :q! is "sysadmin 100".

I can't recall where I read it, but it said that the Switch likely uses the FreeBSD networking stack running in userland. To me, this makes some sense, since if I remember correctly the 4G/5G/some-future-wireless-thing alliance uses a userland version of the FreeBSD network stack in their reference implementation.

Please also note that while FreeBSD may have the bigger individual sponsors, the FreeBSD Foundation still relies on many small contributions as the tax-free non-profit status of the Foundation relies more on the number of contributors than the amount (at least that's how I understood it).

Netflix contributes in a much more valuable currency, cold hard lines of code.

From the new ssl-enabled sendfile syscall, general scalability and performance work to the IO-scheduler they required because they shredded the SSD garbage-collection - it is all upstreamed. They actively try to run the smallest Diff they can.

While 4.0-REL was released in March 2000, and the OpenVZ history section starts with the concept phase in November 1999, the commit that upstreamed jails into FreeBSD was made in April 1999 with comment `Run for almost a year by: ...`

https://svnweb.freebsd.org/base?view=revision&revision=46155

Once any filesystem writes data that was corrupted in memory, the data is hard to recover. And any filesystem will serve this corrupted data if asked, since it is all that it has. This is not a ZFS specific failure mode.

Without ECC, ZFS loses one of the guarantees that it otherwise provides. But it only degrades down to how bad every filesystem is in the face of memory corruption - not worse.

I'm just going to shamelessly quote the FreeBSD Quarterly Status Report, Q4/2016 that came out a few days ago.

   LLD developers made significant progress over the last quarter. With
   changes committed to both LLD and FreeBSD we reached a major milestone:
   it is now possible to link the entire FreeBSD/amd64 base system (kernel
   and userland) with LLD.

   Now that the base system links with LLD, we have started investigating
   linking applications in the ports tree with LLD. Through this process
   we are identifying limitations or bugs in both LLD and a number of
   FreeBSD ports. With a few work-in-progress patches we can link
   approximately 95% of the ports collection with LLD on amd64.

[1] https://lists.freebsd.org/pipermail/freebsd-announce/2017-Fe...