c0l0

It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on top of these vendors' platforms - refuse to work on your machine.

I was not aware of such a directory existing in the first place :) I only advertise "my" service (it only implements DNS and DoT) through word of mouth in communities I participate in.

Well, concerning technical risks, DNS Cache Poisoning[0] is a thing - but I keep the software implementing my recursive DNS service up to date very eagerly, so I guess the risk of falling victim to such an attack is rather low.

[0]: https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_a...

I also run my own recursive DNS server on a VPS I rent, but I freely share it with other users of the Internet. This causes my "personal" signal of queries to authoritative servers to effectively disappear, and I also (marginally) benefit from caching effects of other users' lookups.

I've been doing this for years, and my shell history is usually only a few lines/commands long when I start a new session. I like it that way. My browser's roughly the same - I always start firefox in "private browsing mode" (my system's default browser application is a shell wrapper around firefox that takes care of that), and I very consciouly use a non-private instance to "soft-bookmark" stuff that gets committed to my browser history. Actual bookmarks are for all the stuff that I consider really important not to forget about. A few sites (such as HN) have the privilege of me visiting them in non-private browsing mode while authenticated via cookes.

People might find that weird, and it sure is a tad inconvenient when random, low-priority websites cosplay Internet Fort Knox with very short and annoying MFA login timeouts and methods, but for me, the benefits (I'm less susceptible to tracking and can click on stuff with less angst that I might somehow leak data from my nigh-eternal browser session to some site or another, and I get to start relatively fresh in each session) outweigh the costs.

Wow... reading this article in full really made me lose hope in OpenSSL, the project and the library.

I was well aware of the expected inconveniences any new major OpenSSL release would trigger (esp. older, less actively maintained applications having to adapt their API usage to keep working) going in, but what the linked github issue/PR comments hint at is just... mental.

As best illustrated by https://github.com/openssl/openssl/issues/20286#issuecomment... not only seem the core developers not care about runtime performance at all, they also seem to have a completely absurd perception of their own project, esp. in relation to other, genuinely small FOSS projects.

It's just wild. I hope this can still be turned around, and OpenSSL can somehow re-emerge from this clusterfuck as the stable bedrock of web transport security that we learned to rely on from 2014 onwards.

This is one of the best introductions to what programming a computer is about that I know. I highly recommend checking it out, even if Pascal-like languages are not your cup of tea.

I contributed a minor (but imho still neat :p) improvement to Redis under its original license, and personally moved to using redict when the unexpected license change to SSPL was announced - and I was feeling betrayed as a contributor to a properly-FOSS-codebase. (Had they switched to AGPL right away, I'd have been perfectly fine with that change from a moral perspective, ftr.)

I have a great deal of respect for antirez and recgnize him as a kind and benevolent member of the FOSS community, but no matter what Redis, Inc. announced or does, they have lost my trust for good, and I will continue to use Redis forks for as long as they exist.

To achieve that it is enough to hash inputs, and cache resulting outputs. Repeating a build from scratch with an emtpy cache would not necessarily have to yield the same hashes all they way down to the last artifact, but that's actually a simplification of the whole process, and not a bad thing per se.

I never really understood the hype around reproducible builds. It seems to mostly be a vehicle to enable tivoization[0] while keeping users sufficiently calm. With reproducible buiilds, a vendor can prove to users that they did build $binary from $someopensourceproject, and then digitally sign the result so that it - and only it - would load and execute on the vendor-provided and/or vendor-controlled platform. But that still kills effective software freedom as long as I, the user, cannot do the same thing with my own build (whether it is unmodified or not) of $someopensourceproject.

Therefore, I side with Tavis Ormandy on this debate: https://web.archive.org/web/20210616083816/https://blog.cmpx...

[0]: https://en.wikipedia.org/wiki/Tivoization

Yes.

I use Quad9 (the winner in this benchmark for me, personally) as a fallback resolver, in case the one I operate and use primarily (https://resolv.us.to) happens to break. I created my own (very simple - there's no global unicast with geolocation involved or anything!) service and made it publicly available a few years back because I think it's important not to have too few alternatives for DNS resolution to choose from as an "ordinary" Internet user, since meddling with DNS, down to individual ISPs' servers, is one of the cornerstones of Internet censorship, which I believe must be opposed whenever possible.

Even if WWIII is not a consequence of all this senseless and reckless militarization, each and every penny spent on it will end up missing dearly for fighting human civilization's real fight of this century: combatting climate change. It's even worse, since this kind of spending will make it even worse.

I'm afraid humanity is blowing it for good with this.

IPv6 has not "failed". I use it daily to do my networking, both at home and on the public Internet. The author's take is weird at best.

Growing up in the German-speaking part of Europe, it was impossible to not know them if you were a nerd kid in the 90s - back when you could buy retail software (not only computer games) packaged in huge, shiny cardboard boxes and delivered on physical media (3.5" floppy disks and CD-ROM) at all the fancy computer stores around town and in malls.

I remember buying a Data Becker product for cold, hard-saved-up pocket money for use with what was my first (or was it my second? Hard to tell after the decades ;)) CD writer, it was named "DER GROSSE CD-KOPIERER" ("The great CD-copier", roughly). First thing I wanted to do was use it to make a backup copy of its own installation medium, a CD-ROM containing a win32 application of only a few MBytes in size, but with the medium having had more than its nominal max. capacity of 650MB "recorded" on it regardless. It did not support that, because recording more than that amount of data mandated the use of Disc-At-Once recording mode, which "DER GROSSE CD-KOPIERER" failed to implement. So they made their amazing(ly bad) software solution to copy CDs deliberately unable to copy the very CD that program was distributed on.

Needless to say, I never considered buying any of their products again after that.

"No better place to leave for" seems an apt way to put it.

I think/fear that in the long run, there will be fewer and fewer ways to participate in activities and communities on the web on your own terms, as only a vetted, allowlisted set of client builds (that may be "open source" on the tin, but by that point it is effectively meaningless) will be able to pass CDN "anti-abuse" restrictions. It will not be a better web, but it sure will be more profitable for some.

Dammit, my clipboard manager messed up the link I was about to post, and now it's too late to edit :/

For posterity: https://bford.info/cachedir/ is what I was meant to link to above. Sorry for the inconvenience.

XDG_CACHE_HOME, as mentioned by numerous other posters, is a good remedy to deal with this kind of cached-artifacts-sprawl - but it does need a will to cooperate and care from the original software developer in the first place, which ain't a given.

So does another standard that I've come to appreciate in all software that supports it: CACHEDIR.TAG (https://github.com/LineageOS/charter/blob/main/device-suppor...) - I'm just here to spread the word! ;)

And what is it that makes the *inside* of all (read: almost all) these nice and working Docker/container images tick?

Distributions using a "model of global shared libraries".

In my spare time, I am trying to port OpenBMC[0] to the BMC of the Gigabyte MC12-LE0[1], a cheap, workstation/server-class mainboard for AMD's AM4 platform.

Unfortunately, Gigabyte denied my requests to provide me with any details (board schematics/GPIO pinouts) or source code of the (partly GPL-licensed) BMC firmware, etc.), so it's been a tedious uphill battle. However, it is also a great way to learn about (some) electronics and embedded Linux development and associated challenges.

During the past few months, I have overcome the stock firmware AST2500 bootloader and made the board play ball with standard FDIs, have reverse-engineered a workable DeviceTree specification for the hardware, and am now (well, actually, not for the next three weeks or so, due to work :)) in the process of finishing up OpenBMC userspace configuration. Once this is done, and everything works well enough to use OpenBMC as a viable alternative for the stock BMC firmware provided by AMI/Gigabyte, I will try to upstream my work, and OpenBMC will have a very cheaply available AST2500 DevKit/EVB-alternative (of sorts) in its arsenal. (And I should be able to use my mainboard where the crucial OOB management function isn't serviced by Linux 3.14 any more...)

I am looking forward to documenting the lessons learned on my blog some time in the future, too :)

[0]: https://www.openbmc.org/ [1]: https://www.gigabyte.com/Enterprise/Server-Motherboard/MC12-...

So the next cool "security"-branded thingie that will be used to enforce increasingly draconian DRM schemes upon the masses. I am not surprised any more - just wonder how long it will take for these virtuous technologies to also be used to finally effectively combat all the rampant "disinformation" on the 'Net </s>

There is, unfortunately, no directory of services like this that I am aware of. If you have a local hackerspace, asking specific questions there would probably give you answers quickly, I imagine :)

I faced the same problem, until I found a non-profit community-operated housing provider (a registered computer club/society that has been operating since at least the early 2000 who is also a LIR (https://en.wikipedia.org/wiki/Regional_Internet_registry#Loc...), and they give shelter, bandwidth and IP address space to anyone who participates in covering their operational costs.

I gladly do, and it's the best hosting experience I've had so far, and I used to have rented dedicated iron from Server4You, Hetzner, Webtropia and the like from 2005 on. Maybe there's a similar hidden gem in the area you live in, and you just do not know about it? :) Mine flew under my radar for nearly 20 years, and even though I knew they existed, I was not aware they'd colo other peoples' boxen at very fair rates.

> if you can share anything related to your sweetspot

For Broadwell in particular, it is enough to avoid power states lower than C1E, in my experience.

And no, MTU plays no part in the degraded IPv6 performance. I think it's rooted in a less efficient route lookup mechanism (Linux 6.7 was what I tested with), but I did not take the time to check properly.

There's a number of "special" Ethernet addresses that a proper Ethernet bridge must never forward. The Linux bridge implements a mechanism to ignore _some_ of these constraints, but not all of them. If you ned that, you can always get to manual patching in https://github.com/torvalds/linux/blob/d42f7708e27cc68d080ac... et al.

To "fix" performance (i.e., increase throughput by close to 35%) one has to mess with the "energy performance bias" on the (Broadwell) platform, e. g. using x86_energy_perf_policy[0] or cpupower[1]. Otherwise, the CPUs/platform firmware will select to operate in a very dissatisfactory compromise between high-ish power consumption (~90W per socket), but substantially less performance than with having all idle states disabled (= CPU in POLL at all times, resulting in ~135W per core) completely. One can tweak things to reach a sweet spot in the middle, where you can achieve ~99% of the peak performance at very sensible idle power draw (i.e., ~25W when the link isn't loaded).

With Zen3, this hardly mattered at all.

I also got to witness that using IPv4 for the wireguard "overlay" network yielded about 30% better performance than when using IPv6 with ULA prefixes.

[0]: https://man.archlinux.org/man/x86_energy_perf_policy.8 [1]: https://linux.die.net/man/1/cpupower

No, I actually just booted with 'mitigations=off' and called it a day. We will employ Zen4 cores on the pre-prod setup soon enough, and I'll be looking into the benefit (if any) of disabling mitigations in a more fine-grained manner there.

As I had posted a few weeks ago (https://news.ycombinator.com/item?id=41085314), I recently implemented a very similar thing myself.

My solution ended up using tc's mirred[0] action for implementing a fully L2-transparent frame relay. I wonder if their setup achieves the same degree of transparency, because afaiui, that's just not possible involving a 802.1Q-compliant (Linux) bridge.

I spent close to a week optimizing my setup looking at kernel flame graphs and perf results, reading adapter-specific tuning guides and driver source, and can say that the only really meaningful performance optimizations (in both the Broadwell- and Zen3/Vermeer-based implementations I tried) were disabling mitigations in the kernel (esp. on Zen3, that boosted performance by more than 20%), and getting CPU frequency scaling/idle states sorted out correctly (which yielded much higher wins on the older Broadwell uarch, because power state transition appears to happen much quicker on Zen3).

As for the solution presented in the (on the whole really great; I love it!) article, I have my doubts about the effectiveness of the cargo-culted "sysctl tuning" mentioned - TCP, for example, is simply not involved at all in the described setup, so "tuning" its buffer allocations cannot have any effect on the workload.

Kudos to the writers for solving their problem in a creative, cost-effective and maintainable way! :)

[0]: https://www.man7.org/linux/man-pages/man8/tc-mirred.8.html

The German military seems to have a thing for Star Wars-related themes:

https://www.youtube.com/watch?v=xzsxN4HNrNw

(... and yes, they ACTUALLY do have a "Weltraumkommando"!)

I find it kinda funny that they apparently consider themselves part of the Empire. But it seems accurate, too >:-)

Yeah, I was expecting the same kind of argument from the author, not what he actually talked about (STEM workers have to commit to life-long learning, work long hours during crunch time, feel like on a treadmill because there's always the next release ahead, etc.) in the end.

When I look at the people who finished their PhD in biotech while my wife was doing hers, the overwhelming majority of them seem to be working as project managers (not necessarily, but most likely) in the biotech industry these days - but not as scientists or even engineers, which they should be MUCH better suited for, given their decade-long training and supposed major interest in science. I hope (and so does she, ftr) she will be able to avoid that fate.