cyphar

Breaking any kind of DRM (or writing, distributing, or using software that does so) violates section 1201 of the DMCA[1]. The maximum penalty for a violation is $500k and up to 5 years in prison. There are some token exemptions but none would apply in this case.

Ethically it's all completely bunk, but more people should be aware how insane modern copyright laws are so that we can reform them. And this is not new, folks like the FSF and EFF protested the signing of the 1996 WIPO Treaty too.

[1] https://www.law.cornell.edu/uscode/text/17/1201

I don't think the (fairly factual) description of these systems as stochastic parrots means that they will never do useful work, just that they are not intelligent in the way we believe animals to be (to "push back" on your anecdata, I've also heard fewer people claiming that LLMs are actually conscious in the past year -- maybe we're reaching the happy medium?). That was the point the stochastic parrots paper and Chinese room thought experiments were making -- nobody claimed that the man in the Chinese room would be unable to accurately translate Chinese text.

Fuzzers are another kind of stochastic generator but nobody would claim they don't do useful work in a way that is hard to replicate through deterministic methods. (I still find the code these models produce kind of awful, but advancements in harnesses do mean that they can finally produce code that works most of the time.)

They actually do use "os/user".Lookup() as a fallback if fetching via getent(1) fails, so they might be using NSS modules to dynamically define users and then not linking their binaries with glibc (musl and the opt-in pure-Go implementation of "os/user".Lookup() do not support NSS).

Still, requesting the information from systemd-userdb would be a better way of doing this if it's really necessary.

EDIT: Yeah, some older comments confirm that was their reasoning. https://github.com/tailscale/tailscale/commit/1fc1077052dfa7...

Indeed, but they did have code to use "os/user".Lookup() in a fallback path so I wonder if the issue is that they have some NSS module for user definitions (which wouldn't work with osusergo/static or musl-linked binaries)?

If so, this is kind of an understandably ugly problem, though there is still a better option than shelling out -- systemd-userdb.

In my experience it is really very quick and easy to get a CVE if you contact MITRE directly, and on paper you do not need to disclose too much. The GitHub CNA is (ironically) very slow by comparison but that is a GitHub issue.

Tailscale can also just apply to be their own CNA and issue CVEs for their products themselves, eliminating any such issues entirely.

As an open source maintainer of a fairly large project, we get reports from Ada Logics and similar firms every once in a while and those are absolutely not the same as a proper security audit (which we've also had commissioned in the past). Reports are just a description of a particular issue, not the deeper analysis of the general structure of the codebase that you get from a good audit.

djb proposed Internet Mail 2000 back in the early 2000s as an attempt to solve this kind of problem without micropayments[1].

As others have said, a lot of the useful emails I get are still ones where the sender probably wouldn't have paid to send them. IM2000's fairly old-school-yet-elegant approach would probably lead to a better outcome too.

[1] http://cr.yp.to/im2000.html

It really should not be surprising that we can get very high recovery percentages from batteries -- we do not mine elemental lithium, so the processes we use for extraction are already designed to extract lithium from fairly low-purity sources. In contrast, lithium batteries are an incredibly high-purity source of lithium. The main question is when it will become cost-effective to create recycling pipelines.

Lead acid batteries had a similar trajectory and modern lead acid batteries are effectively 100% recycled.

I am aware of the history behind Zones and Jails, but my point is still the same -- the (lack of) protection you get against kernel exploits should be the same because the only thing protecting you from escapes is kernel data structures.

(I've been one of the maintainers of runc -- the most widely use used container runtime on Linux -- for more than a decade, so I'm at least somewhat well-informed on the topic.)

The duct tape criticisms are fair when talking about other vulnerabilities (such as when container runtimes have misconfiguration or other inatomicity bugs) but not really here in the context of a kernel arbitrary code execution gadget. It also seems quite unlikely that the illumos kernel doesn't contain any of these kinds of bugs.

If there was a similar class of bug in the illumos kernel, it would also allow for a container escape, no?

There are many issues with the formulation of containers on Linux (though I think people overstate it whenever bugs like this happen) but ultimately this bug was a UAF that gave you arbitrary code execution in the kernel. Zone IDs are also just numbers in kernel memory... right?

Root is not just one thing on modern Linux, almost all in-kernel privilege checks are now gated via (slightly) more fine-grained capabilities and the default capability set for Docker containers disallows module loading (CAP_SYS_MODULE) and the relevant syscalls (namely (f)init_module) are also blocked with seccomp.

People still should use user namespaces (and tools like Podman and Incus do by default) but basic stuff like that is not the reason.

But the CPU is not executing the textual description of your architecture. It executes code.

Honestly, I've found that the architecture described to and by LLMs is always a more rosy picture than what is actually generated, no matter how many times you do an adversarial review. It's less visceral than in image generation, but the pattern is the same -- the broad strokes seem fine but the details are awful.

The abolition of slavery in the US is unfortunately a more complicated story than most people are aware.

The 13th amendment removed the legal concept of slavery (except for convicts) but it was still not a crime to do slavery. Slavery changed shape many times over the years since the civil war (usually involving convicting black people under sham crimes and then selling them as debt slaves or forcing them to sign contracts that rendered them slaves under threat of being convicted for said sham crimes) and can only reasonably be said to have actually ended in the US after Pearl Harbour when concerns that it would be used as enemy propaganda caused the Justice Department to properly prosecute slave owners (see Circular 3591[1]).

The last chattel slave in the US was Alfred Irving[2] and he was released in late 1942. He was kept in chains and was permanently disfigured due to constant physical abuse from his owners. He died in 1960.

[3] is a very comprehensive video essay about the topic.

[1] https://en.wikisource.org/wiki/Circular_No._3591 [2]: https://en.wikipedia.org/wiki/Alfred_Irving_(former_slave) [3]: https://www.youtube.com/watch?v=j4kI2h3iotA

I am aware of that (the articles I linked even mention it), my point was that modern fears around literacy are based on data suggesting that child literacy rates have recently declined.

If lack of phonics was solely to blame then almost all US adults alive today (not just "a generation" -- anyone born between the 1920s and 2000s, at least) would have literacy problems, but the concern is that today's children have literacy problems in contrast to previous generations -- the exact opposite of what you would expect. To be fair, people in the 1950s were also claiming that children were illiterate compared to previous generations, but I'm not sure whether those claims are really credible. Do your parents' and grandparents' generations strike you as being shockingly illiterate?

I've heard a lot of people argue that phonics are vastly superior to "whole word" techniques, and maybe that's true -- I'm definitely not an expert, though it is how I was taught English in Australia ~30 years ago.

However, I find it quite hard to believe that it is the most important cause of the modern literacy rate issues in the US. Why? Because "whole word" teaching was the conventional wisdom since at least the 1950s[1,2]! Most articles on the topic reference the book Why Johnny Can't Read (1955) which was written to argue in favour of phonics as a response to (perceived?) child illiteracy at the time and claims (page 1):

Since the 1920s, most American schoolchildren have been taught to memorize the "appearance" of words, one after another, like Chinese characters, without reference to the sounds of the individual letters that make up each word.

The reintroduction of phonics in the US first started as "balanced literacy" (phonics and "whole word", ideally tailored to students) in the 1990s and "science-based reading" (basically just phonics) properly started in the 2000s[1,2], which means that the argument that phonics would improve reading scores is on quite shaky ground (most children in the US today get taught phonics and most people >40 were probably taught with "whole word" teaching).

[1] https://wearealigned.org/brief-history-literacy-instruction-... [2]: https://www.lexialearning.com/blog/the-science-of-reading-vs...

I really wonder where all of these people who believe that tests perfectly encapsulate the behaviour of software come from. Maybe it's because LLMs happen to work better when you give them acceptance criteria and people struggle to distinguish between "better" and "good"?

1. Nobody, not even the Googles or NSAs of the world do that. No single entity has the expertise nor resources necessary to maintain a fork for every open source project they use -- forking and maintaining Linux alone takes teams of people. And no, going full psychosis mode with LLMs is not going to save you.

2. This project is AGPLv3.

"You're right to push back on that. Let me take a step back and reconsider the requirements for an application that people might entrust with their lives."

Be honest, in the counterfactual where he had said that "AI" agents are the next industrial revolution and there is no future for human skills and so on -- would you have still valued his opinion as being effectively worthless?

The man page does say that but there is no mechanism to actually make use of that at the moment.

It's not enough for it to be encrypted, it needs to be encrypted with a single-purpose key that is not known by the user. Otherwise the user could replace the hibernation image with a malicious one and chain-load a backdoored version of Windows in secure boot mode, which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.

It is my understanding that there is work on generating a non-exportable single-purpose key using the TPM to make this work, but that's still a WIP.

To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.)

Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem.

Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors.

If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.

Can I ask one question? Why not use hibernation at that point?

Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patched version of Windows under secure boot).

This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot.

[1] https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.... [2]: https://github.com/rhboot/shim-review#how-does-your-signed-k...

I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch.

Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3].

[1] https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b... [2]: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1... [3]: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/93...

Would that be pheonixmaxxing or pheonixxing these days?

I'm also taken aback with how naive folks are about companies, they really seem to have bought the whole "capitalism is efficient" maxim hook, line, and sinker.

I really struggle to imagine how anyone in a corporate environment has managed to never run into obvious examples of waste like you describe (overpaid consultants and mandatory budgets are classic examples). Office Space came out 27 years ago and has a plotline making fun of overpaid "efficiency consultants" whose only job is to tell management to fire people.

Why would a carpentry shop buy hundreds of thousands of dollars of power tools without consulting with their employees to see what they actually need to get their job done more effectively? The logic of buying the tools then forcing the employees to use them "or else" is completely backwards in any sane world.

(Of course, we've all had bosses that went to some marketing seminar and come back having been tricked^Wsold into buying some wizz-bang widget that we need to now integrate because of a sunk-cost fallacy, but I thought everyone was on the same page that this is not how normal procurement was supposed to work.)

the point is that if you wanna see if the tools are working you wanna see proof they're actually being used.

That is way too charitable, people were being fired based on these metrics and people were absolutely talking about token burn as being a metric for productivity (do I really need to link the Jensen Huang quote?). That isn't an indication of this hysteria being based on "just trying to see if the tools work".

If you want to see if the tools work, why don't you just ask your employees? Like any normal employer would?

I use Cozette[1] at the moment, which is basically a modern form of Dina (the first bitmap font I started with ~15 years ago now). It is pretty nice, though they recently started adding some kanji and I don't particularly like the style they went with (maybe I should send a PR to support more and fix up the existing styles)...

[1] https://github.com/the-moonwitch/Cozette

I'm more of a bitmap font guy (at least, as long as my eyes continue to forgive me for it) but I'm always interested to see what other fonts there are around. It does look quite nice.

I must admit when I ran across the second real paragraph from the main page, I couldn't help but only think more and more about how we will look back on marketing copy like this in a decade from now:

AI assistants produce both code and prose. MonoLisa Text renders long-form explanations with optimal readability, while MonoLisa Code keeps your code crystal clear. The perfect pairing for the AI era. (Under the title "A perfect pairing for the AI era.")

Ignoring the deep pit of sadness I felt when thinking about the incredibly long (and revolutionary) history of typefaces that led us to today for just a moment, I'm honestly curious how effective this marketing is. How many people would assume a font would be suitable for general text but not LLM-generated text and would need to be dissuaded from that notion? I wonder if someone has started selling keyboards that are "perfect for prompting" (but I'm too scared to look at this stage).

I mean, cultures are also a kind of technology, arguably one of the first we developed as Homo Sapiens.

In my view the actual issue has always been that cryptocurrency folks don't understand what purpose money serves, mostly because they're all basically gold bugs. To strain the "money is a technology" metaphor, this is a product-market-fit issue -- like trying to build a cloud orchestration framework that only works on DIY Belwulf clusters or a web framework that only looks nice on teletype.

"This particular band of gambling addicts have bet money on a particular outcome at a ratio of 68:32, so there is a 32% chance of it happening."

Wow, how informative. Maybe I should go check my horoscope for if the Iran war will end next week...