Completely agree. This is really unique. Can you imagine if it were standard practice to be open to supply chain attacks like that, by blindly relying on hotlinked or unpinned dependencies?
Why imagine? Let's take a quick look at what's actually happening right now. We can check some widely used libraries and see what their instructions are teaching new developers.
Pay close attention, they are inviting the new developer to link not just to Bootstrap, but to Popper!
HTMX (code snippet from their quick start guide):
```
<script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js"></script>
<!-- have a button POST a click via AJAX -->
<button hx-post="/clicked" hx-swap="outerHTML">
Click Me
</button>
```
Fontawesome: A video quick start guide and instructions that recommends using the direct link to the kits via CDN for performance!
Look, I certainly don't think they should be used this way. But, to say that it's unique to the White House app? I definitely wouldn't say that. In fact, I think you've dangerously overestimated the status quo.
I was being sarcastic. Although hot linking is not particularly common, it's common enough; and unpinned dependencies are just as much if not more of a supply chain attack risk.
I'd bet something like 70+% of all JS apps are inadequately protected against the risk of a malicious actor gaining access to a dependency's repo.
Pearlclutching over this while ignoring the lessons of `left-pad` and `colors` is biased motivated reasoning at best.
I'm not sure I follow. How does an integrity check help when the source is compromised? The developer doesn't know that their repo is compromised. They continue posting legitimate hashes because the repo is legitimately compromised.
> This is particularly problematic given the ways that it could be abused by some of the more authoritarian governments in the EU.
> Yes, I'm thinking of Viktor Orbán of Hungary.
Lol what?
The UK leads [edit: in Europe overall, obviously not the EU] with approximately 18 per 100k prosecuted for online speech. Germany is at about 4 per 100k. Poland at about 0.8 per 100k. Hungary about 0.1 per 100K.
For any definition of authoritarian that relates to chat control, the UK is two base-10 orders of magnitude more authoritarian than Hungary (7 base-2 orders of magnitude).
This figure in the UK is unsourced and I'm fairly sure is not true (or at least not what you've labelled it), and has been quoted out of context by people trying to stir trouble not reasoned debate. I'll assume good faith here and say the start of the video lays out why the figure is not what you've labelled it to be
The issue isn't how much free speech online is being punished. It is how surveillance could be used to reinforce authoritarianism.
The UK does a lot of prosecuting people for having said nasty things online that someone else didn't like.
Hungary is far more inclined to surveil political opponents, put people in their network in jail without fair trial, surveil successful businesses whose bribes were insufficient, find excuses to punish those businesses.
Not only are there not similar reports about the UK, but its better position in international corruption rankings points to a culture that would be less likely to tolerate this.
Any further questions about why there should be concerns about how Hungary would be likely to abuse a law like this?
Germany and Poland are. Does the existence of a non-EU country in a data set about European countries detract from the fact that Hungary doesn't prosecute people for online speech to the same extent as other European (incl. EU) countries?
I'm quite sure they thought about the UK as well, given the practice of prosecuting for lawful speech, jailing or arresting for planning peaceful protests (or threatening to arrest a man with an EMPTY placard), jailing for opposing the genocide or voicing support for the unlawfully proscribed organisation.
> any high end Ryzen will blow an ARM64 chip out of the water
I'm very skeptical about this. I've read that many benchmarks show ~40% better performance per watt on ARM than the best x64 machines. Do you have any sources that say differently?
Performance per watt isn't the same as performance. On the high end (think Threadripper), amd64 still wins most performance tests by having many high-performance cores working all at once (at the cost of single-core performance).
I disagree with "any high-end Ryzen" blowing an ARM64 chip out of the water, though, it takes quite a beefy CPU to beat an M4 Max.
No. This is a common contrarian take, but it's nonsense. macOS is built on Darwin which, along with XNU, traces its lineage through NeXTSTEP to 4.3BSD.
macOS is every bit as much of a BSD derivative as FreeBSD is.
Here's a contrarian-squared take: in reality, the question "Is macOS a BSD" is malformed. It makes some sens, but is more confusing than it's worth.
Yes, NeXT was built on Mach, which was itself basically an evolution of the Accent microkernel married with BSD, when BSD was a proper noun.
In fact, NextStep 0.8, the first public "pre-release", has left support in for A.OUT executables. The included ex and vi binaries are indeed A.OUT executables taken straight from BSD! In the very next release, support for A.OUT was removed, leaving only the Mach-O loader.
XNU is not derived from the Mach that NeXT was, though, but from the OSF Mach kernel, which was continued at the University of Utah. The BSD "bits" were selectively copied from the extent continuations of BSD, or rewritten from scratch. The XNU kernel doesn't strongly resemble any particular *BSD tree, to my knowledge.
Darwin's origins are messier, since it looks like it was a direct continuation of the existing NeXT packaging (but only Apple would know for sure). NeXT, very much unlike BSD, split its userland into distinct packages, which were versioned independently. This practice has carried on to this day, where e.g. Darwin's libc is packaged and versioned separately from the kernel and other utilities.
For that matter, for a very brief period of history, Darwin used Debian's dpkg for building and installing packages. Evidence of this stayed until OS X 10.4-ish, in the Darwin releases, but they returned to NeXT style BOM files for package management.
All that to say, does NeXT/macOS have a BSD-like userland? Yes, but so does Chimera Linux. Does the kernel resemble BSD? In some ways yes, but in many ways no, it's very semantically different.
And is it descendant from BSD? Again, "yes", but it also doesn't really "come" directly from BSD anymore than, say, OSF/1 did. There's no specific BSD it forked from, and no specific point at which it ever really looked like BSD, in terms of userland, packaging, or kernel semantics.
So I think the question just doesn't make much sense to ask.
- Darwin has no direct BSD ancestor. Unlike {Net,Free,Open}BSD and the more obscure ones (Bitrig, anyone?) there was never a point in time where it directly "connects" to the BSD lineage. The other BSDs all can trace their repositories back to CSRG's BSD.
- Darwin isn't stored or built like a BSD. The BSDs have massive monorepos containing all of the source, traditionally checked out to /usr/src, while Darwin is split into many independently versioned packages, (usually) compiled with Project Builder/Xcode.
Yes, the C API is derived from and supposed to resemble BSD, and much of the userspace was copied from a BSD-derivative (this has grown over time, as Apple (and the BSDs) replaced GNU utilities).
But that's why I would call macOS/Darwin "BSD-like" or "BSD-derived" rather than "a BSD".
Also, this isn't meant to be taken too seriously. I just like "OS taxonomy", and I think macOS/Darwin is distinct enough to qualify as a separate species ;-)
Yeah, I probably went too far in saying it's just the userland, but I'll insist it's more complicated than saying it was based on 4.4BSD-Lite2. I haven't done a proper deep dive yet, but I can tell that it wasn't strictly based on the Lite2 release. Take a look at XNU 123.5's (OS X 10.0) kern/tty.c:
You'll also see the source has been reorganized, with e.g. the VFS source being regrouped into bsd/vfs, instead of being left in bsd/kern. This coincidentally mirrors how OSF/1 was organized (no other source relation though, just an interesting observation):
This file had to be reimplemented by all of the BSDs. In this case, this version appears distinct from the FreeBSD and NetBSD versions I can find.
If you grep around for the `NeXT` ifndef/ifdefs in XNU, too, you'll see some code of which some appears to have been copied/adapted from the NeXT source tree, itself derived from Mach/CMU sources. (and 4.3BSD ;-)
I say all this to draw attention to the ways XNU differs from BSD, which is pretty interesting, at least to me.
> Jails solve the isolation problem beautifully, but they don't have a native answer to shipping. That gap is real, and it's one of the main reasons the ecosystem around jails feels underdeveloped compared to Docker's world.
The link literally uses the term ecosystem. Several times actually.
The lunatic obsession with making scroll bars invisible is not just an aesthetic choice, it's a moral one; and as a moral choice it is emphatically condemnable.
The "killer" feature is actually that it was rendering traditional websites NOT fine, but in a bunch of hacks that would force a specific viewport width where most websites would render with reasonable font sizes and double tap to zoom to paragraph would fix the remainder.
Specifically this "killer" feature would already break traditional HTML pages with just text (that were 100% responsive even before "responsive" was a thing).
The entire mobile HTML stacks is hack on top of hacks. Like everything else in computing, TBH...
reply