IDK about OPs setup, but I run a pile of E5-2683v4 Xeon recycled servers for Ceph and self hosted business SaaS usage.
One node's ipmitool sensor report (and self-monitoring PSU, so grain of salt, but my UPS side monitoring tracks closely), reports 250-300w average power use. This though, mind you is for running 22 spinning disks, 2 SAS/SATA SSDs, and 4 NVME ssds, and 768GB of DDR4.
Mid-gen 2015ish Xeons were not great at power reduction, but if you are pegging the cores, they were never particularly slow, and they did have lots of PCIe lanes. This boils down to the CPU/mobo itself not being that big a cost floor, especially if you have high utilization rates.
As a comparison, my main desktop development machine, running a Threadripper 9970X, 128GB of DDR5, a RDNA4 GPU, and a small pile of NVME drives has a power floor of roughly 250W. Some CPU centric workloads you'll definitely lose out on on the older gens of machines, but they are by no means impractical.
Maybe for a desktop usecase they are absolutely suboptimal nowadays, but for a lot of realworld usecases I would say they're still relevant.
---
Like the author posts for the LLM usecase, I think optimizing the hardware choice to the application and not leaving levers unpulled is a big key, especially considering how wide a variety of bandwidth/power draw/peak frequency/corecount SKUs exist in the Xeon lines. Without knowing what you intend to run and fitting the correct processor to it, you will end up with a disappointingly poor environment fit.
Take the volume and mass of lobbying by all of data broker companies, data collection companies, and executive agencies.
Combine that with the character of practically every law written involving data privacy, use, IP, and associated regulation of activity around these since the 1990s. It becomes painfully clear that the interests of private citizens have not had a seat at the table, and the Constitution has been taken as an inconvenience to bypass, not a guiding document.
The core sticking point is, I think, is that Section 230 was envisioned as a 'common carrier' exception. Common carriers do not apply editorial control to the content they transmit.
In the modern landscape, where practically every mainstream (and most of the non mainstream even) platform has extensive policies and applies them in a manner that's equivalent to editorial control, they are no longer a common carrier, they are a publisher.
Should that exemption and safe harbor be expanded to all publishers? If no, do you really want the Government picking and choosing favorites? Either way you choose, I believe there will be many first and further order implications.
You can either get Congress to modify the definition, or you could try to get a case through the courts to clarify its interpretation. As one of those indirect implications, I am actually not sure which one would be more of a footgun.
Well tinygo takes some go bindings they implemented for llvm, https://github.com/tinygo-org/go-llvm, uses the Go standard library for parsing, and wires it up to a LLVM IR generator, with a set of flexible backend/machine definition machinery.
You could likely improve gobee to use tinygo's packages directly, instead of transpiling to C and calling into clang, and the licenses of the two projects look compatible. You'll still need to deal with defining a subset to pass the verifier, of course.
---
From the README:
> Replace clang. clang's BPF backend gives us CO-RE, BTF, and verifier-friendly codegen for free. Reimplementing that costs years and gains nothing.
The primary gotcha you may hit if you try this is how much of the BPF features are implemented by clang, and how much is instead implemented in core LLVM. Even with a LLVM sitting next door you could pull out, the harnesses may not exist independent of clang, but I have not looked THAT deep.
The title says 'standard library'. Are you saying that, in the context of C, that it is an error to take that to mean an implementation of libc?
Yes, I know the author's writeup then goes on to say that it is not a libc with a pile of questionable justfication. This is a custom runtime, in a single header no less, which is admittedly impressive, especially considering it provides runtime and thread safety primitives. This does not rise to the level of claiming the idea of a 'standard libarary' though, IMO. In that, I think the author misses the point.
I became aware of RFC4259: https://www.rfc-editor.org/rfc/rfc4259, but is there literature about its use in the wild? Searching on [rfc4259, nanog] comes up snake eyes for me.
The point isnt the apologists that pop up whereever CF gets mentioned, the point is that they more or less have a built reputation for deceptive loss leader marketing.
Maybe early/MVP product engineers should know better, but CFs own education materials do not teach you to expect that.
I think you have to look at the history of disclosure from the 90s to get a good grip here --
The CVE system arose as something of a mediating factor to enable coordinated disclosure of discovered issues and make something of a standard that vendors could point to and they they were being responsive, vs wondering if a random exposure on Bugtraq in the 90s would ruin your week.
If it no longer aids in that, then it has ceased to be a system useful for its original purpose, and it would be foolish to continue to feed it resources. It probably doesn't help that all sides viciously game the CVE system these days.
Papal visits to the United States have fairly long intervals to begin with. Wikipedia reports 10 trips between 1965 and 2015 (https://en.wikipedia.org/wiki/Papal_visits_to_the_United_Sta...). Given the relative rarity of visits, not having planned a trip during any given presidency would even be normal. It doesn't surprise me at all.
That's still a good question, though. Do any of them have anything more substantial than 'anonymous' sources, or even their own anonymous sources not linked to the breaking article's?
I am generally suspicious when anonymous sources quoted these days, but I am rather more suspicious of reports that only come from a single source and get repeated in multiple outlets more or less immediately.
I know there is some amount of synchronicity induced by syndicated news feed outlets like AP, but like many single source/anonymous stories, this reads to me like some 'suggested copy' was sent out to some reporters or outlets ahead of time.
Anonymous sources are important for the integrity of reporting, but it must also be recognized that they are essentially non-authenticatable information.
My impression is that as EFF's executive leadership has evolved over time, the driving motivations and attitudes of that leadership has changed EFFs style of execution.
It has probably helped increase their raw numbers, but it has also induced "mission drift".
What does it say? EFF has not bothered to engage with basically anyone that replies to them on X the platform at least since Dec 1, 2025. Searching for EFF replies from older posts also shows that they basically never engage with X users, apart from using it as an advertising firehose.
If they spent any appreciable amount of time replying to people and not just themselves, their X impressions would be considerably larger. X themselves has been clear that engagement weights impressions/recommendations/algorithmic display, and EFF has done none of that.
It looks to me like a people at EFF problem, not an X problem.
It seems to me at its root, that it's a question of available ad attention, and the value thereof.
The classic value prop for ads has been so badly destroyed by bad curation and content invasiveness that the basis value of that attention has dropped trough the floor. The growing prevalence of ad blocking is only a symptom of that.
This has become bad enough it even invades special interest nonprofit rags like the AAA, American Legion, and USPSA newsletters, for example.
It looks like they rolled it so you can plug in local components of your choice, though? The security model does assume you have MAC containerized environments available at your fingertips though, so having something like DHH's once is probably a soft minimal dependency if you want to do-it-yourself.
Functional April Fools, the best kind. A couple years ago Eleiko, a weightlifting equipment company did one, the 'Heavy Mug', a 19 poundish steel coffee cup with a handle in the style of a knurled bar, and actually did a limited run of them.
There is a very important consideration here that this opinion doesn't really touch on, but I think is invited down the road for future cases and legislation: Can you compel the speech of a third party to aid in exploratory evidence gathering (aka fishing expeditions) without a clear, well defined, and particular, cause of action at court to issue a subpoena?
In most classic U.S. jurisdiction, no, you cannot. Compelled activity or speech is generally frowned upon. The most important part of this case, IMO, was the Supreme Court constraining the Fourth Circuit's interpretation of contributory liability and attempting to turn the DMCA system into one for enabling those fishing expeditions.
One node's ipmitool sensor report (and self-monitoring PSU, so grain of salt, but my UPS side monitoring tracks closely), reports 250-300w average power use. This though, mind you is for running 22 spinning disks, 2 SAS/SATA SSDs, and 4 NVME ssds, and 768GB of DDR4.
Mid-gen 2015ish Xeons were not great at power reduction, but if you are pegging the cores, they were never particularly slow, and they did have lots of PCIe lanes. This boils down to the CPU/mobo itself not being that big a cost floor, especially if you have high utilization rates.
As a comparison, my main desktop development machine, running a Threadripper 9970X, 128GB of DDR5, a RDNA4 GPU, and a small pile of NVME drives has a power floor of roughly 250W. Some CPU centric workloads you'll definitely lose out on on the older gens of machines, but they are by no means impractical.
Maybe for a desktop usecase they are absolutely suboptimal nowadays, but for a lot of realworld usecases I would say they're still relevant.
---
Like the author posts for the LLM usecase, I think optimizing the hardware choice to the application and not leaving levers unpulled is a big key, especially considering how wide a variety of bandwidth/power draw/peak frequency/corecount SKUs exist in the Xeon lines. Without knowing what you intend to run and fitting the correct processor to it, you will end up with a disappointingly poor environment fit.