c0l0

"Play Integrity" is not there for your, the user's, security. It's there for the app makers' security and guaranteed control, so that they can force you, the user, to endure their every whim and their applications' every shit dark pattern and user-hostile behavior. It is there to make all that unmitigable. If any regulator were to put an end to all that, I'd be all for it.

Necessarily, as this is the kind of API (a file system with a well-defined structure) that the kernel exposes for querying/providing that kind of information :)

Back in 2011, I interviewed at a large-ish tech company from the US for an "SRE" role (and never had I hear that term before) that, amongst other things, created an online, browser-based alternative to MS Office. Some rounds in, after the usual phone screening, the task was some sort of supervised programming in a $thatcompany Docs document while talking to the interviewer on speaker phone. Since I had rated "shell scripting" and "Linux" fairly highly in my mandatory self-assessment sheet that I had turned in weeks prior, I was tasked with conjuring a `netstat` replacement in bash.

I quickly realized I couldn't do it (because I did not, at the time, know where and how exactly socket information was held in /proc/), but I offered to write trimmed-down replacements of `ps` and `fuser` instead. The interviewer deemed that - and my solutions eventually produced in that wretched, browser-based word processor - acceptable, and a few weeks later, I shipped out to the on-site interview series.

Now I wonder if the hypothetical scenario presented as the motivation for this exercise is more grounded in reality than Izabera (thanks for all your help in #bash over years btw!) would care to admit... ;)

We have a number of proprietary network appliances present in all connected locations that require unhampered L2 communication (for mostly dumb reasons I think, but what can you do...), unfortunately.

It's not really (my) code, it's just some clever configuration, mostly done via systemd-networkd.

At the "outside", there's two NIC with SFP+ ports that are connected via single mode optical fiber that runs through the city - let's call these NICs eth0 on each of their nodes. eth0 have RFC1918 IP addresses assigned and can talk IP with each other. Between those nodes, a wireguard instance encrypts traffic in an inner RFC1918-network of its own - that is wg0 on each node. (Initially, I had IPv6 ULA networks prepared for these two pruposes, but afaict there's some important offload support missing for IPv6 in Linux still, and performance was quite severly hampered by that.) Then, each of the nodes defines a GRETAP netdev that has, as its endpoint, the peer's wireguard interface address - that interface is grt0.

Finally, on each side, another NIC SFP+ port (let's assume eth1) using a DAC plugs into the local switch uplink port. eth1 configure in promiscuous mode, and some `tc-mirred(8)` magic makes sure every frame it receives gets replayed over grt0, and every frame that is received via grt0 gets replayed over eth1.

So it kinda looks like this in a (badly "designed") ad-hoc ASCII graph:

    [SWITCH]-<dac>-[ETH1]-<tc>-[GRT0]-[WG0]-[ETH0]-<fiber>-...

... with the whole shebang replicated once more, but in reverse, on the right-hand-side of the <fiber> cable/element.

An earlier iteration I (briefly ;)) had in operation featured a Linux bridge instead of tc, but it quickly turned out that won't work with a few L2 protocols that we unfortunately need in operation across these links (and group_fwd_mask won't cut it for them either, so patching the kernel would have been necessary), while tc-mirred can actually replay L2 traffic without any restrictions.

This would have been such a great resource for me just a few weeks ago!

We wanted to have finally encrypt the L2 links between our DCs and got quotes from a number of providers for hardware appliances, and I was like, "no WAY this ought to cost that much!', and went off to try to build something myself that hauled Ethernet frames over a wireguard overlay network at 10Gbps using COTS hardware. I did pull it off after a tenday of work or so, undercutting the cheapest offer by about 70% (and the most expensive one by about 95% or so...), but there was a lot of intricate reading and experimentation involved.

I am looking forward to validate my understanding against the content of this article - it looks very promising and comprehensive at first and second glance! Thanks for creating and posting it.

https://hn2.wilsonl.in/user/c0l0 - Apparently, I'm a (the?) leading expert on Optimizing Toilet Lid Design - AMA.

That's great, but does that particular model also know if/when/that it does not know?

The term already exists, but the "hell" is mostly silent (even in writing).

Afaik, that's a matter of the AGESA revision in the firmware and the CPU SKU. In ther real world, I think it actually matters little, since setting software power limits in the OS will be as effective as setting a low-power (35W or 45W) profile in the system firmware in my experience (which is limited to AM4 only so far, however).

Not according to the spec sheet or the PCB photos[0][1] they provide, no.

[0]: https://www.asrock.com/nettop/photo/DeskMeet%20X600%20Series... [1]: https://www.asrock.com/nettop/photo/DeskMeet%20X600%20Series...

I think you will need to go for a custom (i.e., one you buy without the mainboard pre-assembled into a complete barebone/system) case to get that. Jonsbo has a few probably interesting options for you, such as the N3[0][1]. I don't know if you could make the DeskMeet mainboards fit in that particular case - but many regular ITX boards for AM4 and AM5 come with ECC support, too.

[0]: https://geizhals.eu/jonsbo-n3-schwarz-n3-black-a3062571.html [1]: https://www.jonsbo.com/en/products/N3.html

Finally one can buy these! The sibling model, ASRock's DeskMeet X600, should exhibit a roughly equal power consumption profile, but offers support for proper ECC UDIMM in up to 4 slots, which makes it a premier choice for a cheap, powerful, reliable and flexible (SOHO) server platform.

Even the previous generation - with AM4 CPUs and DDR4 memory - of these ASRock offerings were easily enough for most users' needs (my wife still has a DeskMini X300 with a Ryzen 5 5600G as her daily driver).

Ouch, there's some bitter irony in all of this. See https://wiki.gnome.org/Attic/ProjectRidley for an explanation of the goals of this project, which now seems to be what GTK is trying to get away from again.

For those who ask themselves which device to get to give LineageOS a try, I try to automatically compile a list of recommended models from the project's structured data that underpins its wiki. The list lives at https://johannes.truschnigg.info/tmp/lineageos_device_toplis... and is updated daily.

I myself have been a happy user since when my daily driver phone had a 320x480px screen, 512MB RAM, and ran CyanogenMod with some alien skaterboi mascot ;)

PeaZip is great software, and doubly so because it is written using Lazarus and compiled with Free Pascal. I highly recommend giving it a try, if only to experience that high quality software can be built using tools that lead you somewhat off the beaten path.

Unfortunately, its lead developer has recently posted[0] that he has to undergo what seems to be complicated, major eye surgery, and that he will probably be unable to continue development :(

[0]: https://old.reddit.com/r/PeaZip/comments/1bn7pu0/communicati...

Especially for interactive sessions, it absolutely should! :)

4.10 was the initial release, afair :) With 6.06 (postponed by two months to "get the release right", due to the extended support cycle) as the first LTS release. I fondly receiving 5.xx-release-CDs in the mail and distributing them on our uni campus and in schools back in the day!

Oh wow, I did not know(/remember) that this existed! Will try to be going with my brothers-in-law this year, it's gonna be awesome :D Thanks for linking it!

In case you don't need an integrated GPU (that's somewhat powerful/potent), you can go with any other Ryzen AM5 CPU to receive proper ECC-enabled ECC UDIMM support, afaik :)

They also support ECC UDIMMs with ECC enabled, which has been the "PRO" series APU killer feature on AM4 for me. The non-"PRO" APUs will run fine with ECC UDIMMs, but cannot make use of the extra parity information (maybe for reasons of market segmentation - I don't know if anyone outside of AMD knows). This is probably less of a concern with DDR5 platforms and their "on-DIE ECC" (which you cannot monitor for Correctable Errors at least, afaik), but it's still gonna matter for me.

... can you really fault software that has "Grand" and "Unified" right there in its name for trying to be just that? The number of systems supported by GRUB is really impressive, the number of special-sauce features supported (filesystems, RAID levels, snapshots, etc.) downright staggering. And if you don't like it, there's plenty of alternative, simpler options with a narrowere focus. I use systemd-boot on most non-Debian (which supports A LOT of other platforms, mind you) x86 EFI boxen of mine.

GRUB might be an unnecessary complexity for a number of use cases, but it's a solution that strives towards being universal (which is also a goal of Debian). I think it comes rather close, and I am happy it exists. Learning you way around it for an hour or two will yield payoffs down the road.

OpenPGP Keys do have expiration dates/validity periods: https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....

¯\_(")_/¯

I pity the fool(s).

It's not AGPL, but LGPL-3.0-only. Neither of these licenses is "hostile".

And ftr, in my eyes, a project being created/initiated by ddevault is an asset, certainly not a liability.

Take a look at Proxmox SDN features: https://pve.proxmox.com/pve-docs/chapter-pvesdn.html (some of it is still in beta, I think).

I think it comes pretty close - close enough for probably most but the very largest of users, who, I think, should probably have tried to become hyperscalers themselves, instead of betting the farm and all the land around it on VMware (by Broadcom).

Unless your users are of the kind who re-distribute your work (or something containing/extending your work - mostly aka software developers) all the time, switching from MIT to GPL is going to be just about no hassle at all to them.

Usually (not by design, but by circumstance), if someone gains RCE on your systems, they can also find a way to bring the tools they need to do whatever they originally set out to do. It's the old "I don't want to have a compiler installed on my system, that's dangerous, unnecessary software!"-trope driven to a new extreme. Unless the executables installed are a means to somehow escalate privileges (via setuid, file-based capabilities, a too-open sudo policy, ...), having them installed might be a convenience for a successful attacker - but very rarely the singular inflection point at which their attempted attack became a successful one.

The times I've been locked in an ill-equipped container image that was stripped bare by some "security" crapware and/or guidelines and that made debugging a problem MUCH harder than it should have been vastly outnumber the times where I've had to deal with a security incident because someone had coreutils (or w/e) "unnecessarily" installed. (The latter tally is at zero, for the record.)

I contributed a few LOC to Redis in the past (before "Redis Labs" had taken over), but never signed a CLA or assigned Copyright (that's not even possible in my country of origin). I realize that under the permissive license that I published my contributions under, they can very well do what they are doing. That they are doing it, is disappointing nonetheless. I guess there are more people like me out there, with vastly more important contributions, who feel about the same. I, for one, will not contribute to the project under this new license any more.

What a shame.

I find the eventual conclusion baffling:

  > Applying this custom tuning results in an average latency of 5.2 ms, which is 0.1 ms lower than xterm, and that’s with having a much more sane terminal without legacy cruft.

This "legacy cruft" is as-close-as-it-gets compatibility to EVERYTHING the Terminal-based world has ever seen. It's an asset, not a liability, for those who need it, in case they need it - and that could very well be you one day.

I find it quite amazing that xterm manages to more or less outperform all the other implementations while (probably - I have not actually verified) being he most complete and correct one. Thomas Dickey is the man!