- These are all things I'd rather have seen the article set out to talk about as well, instead it opens up to disprove a statement saying AI can write the coding portion of the engineering problem by means of showing it being used that way with Bun to mean Anthropic must not actually think that.
- Something about the way the article sets up the conversation nags at me a bit - even though it concludes with statements and reasoning I generally agree quite well with. It sets out what it wants to argue clearly at the start:
> Everyone’s heard the line: “AI will write all the code; engineering as you know it is finished... The Bun acquisition blows a hole in that story.”
But what the article actually discusses and demonstrates by the end of the article is how the aspects of engineering beyond writing the code is where the value in human engineers is at this point. To me that doesn't seem like an example of a revealed preference in this case. If you take it back to the first part of the original quote above it's just a different wording for AI being the code writer and engineering being different.
I think what the article really means to drive against is the claim/conclusion "because AI can generate lots of code we don't need any type of engineer" but that's just not what the quote they chose to set out against is saying. Without changing that claim the acquisition of Bun is not really a counterexample, Bun had just already changed the way they do engineering so the AI wrote the code and the engineers did the other things.
- I think it got added by Samsung / someone employed by Samsung at the time https://www.phoronix.com/news/KSMBD-Lands-In-Linux-5.15
- Most of these are unfair in some way and many are wrong. What makes this funny is precisely that it has more snark than is reasonable (and often pushes bad assumptions as snark usually does!)
- For most any 5G network you should be safe to 1420 - 80 = 1340 bytes if using IPv6 transport or 1420 - 60 = 1360 bytes if using IPv4 transport.
For testing I recommend starting from 1280 as a "does this even work" baseline and then tweaking from there. I.e. 1280 either as the "outside" MTU if you only care about IPv4 or as the "inside" MTU if you want IPv6 to work through the tunnel. This leverages that IPv6 demands a 1280 byte MTU to work.
- With IPv6 there is even an extension to go to 4 GB packets (extremely rare to actually be implemented though), which you can send in less than 100 ms with an 800G NIC!
- Looking through the readme, it seems this is a "matching decomp" type project which does not bundle assets (i.e. those get pulled from your local copy during the build).
I'm no lawyer, and this is no claim that it is/isn't one way or the other, but Super Mario 64 had a CC0 1.0 licensed decomp in 2019 with PC port in 2020 and Nintendo vehemently chased compiled copies of the game being shared and videos of the ports on YouTube but never went after the actual source code repo for either the decomp or port (which do not contain any of the assets). Of course there is nothing saying Nintendo can't wait 6 years and then issue action (just look how long they put up with Yuzu/Ryujinx before going after the decryption and other arguments just before the Switch 2 launched), but they were certainly aware of it when they took action against the resulting binaries/videos and didn't try to touch the code repo yet for one reason or another.
I expect some big court case to happen about this style of project within the next decade. Maybe not as big as Google LLC v. Oracle America, Inc., but still one that makes the news a fews times and gives direct precedent rather than comparisons to similarish cases.
- I admit it took me until the 4th gen Epyc to realize this. I laughed out loud at myself/the numbering scheme.
- The SMB Direct support mentioned here is in the kernel for client & server from 5.15+. After that it's just a mount point any application can access. No Microsoft stuff needed on either side.
- "Can" is too overloaded a word even with context provided, ranging from places like "could conceivably be achieved" to "usually possible".
The only hint you can dig out is where they might have limits feasibility around it. E.g. "I can fly first class all the time (if I limit the number of flights and spend an unreasonable portion of my weath on tickets)" is typically less useful an interpretation than "I can fly first class all the time (frequently without concern, because I'm very well off)", but you have to figure out which they are trying to say (which isn't always easy).
- 100%! I dearly missed how simple it was to correlate security & issue event tracing (even for guest users!) without NAT/PAT at the following job, what a treat that was.
Right as I was on the way out they finally started using 10/8 after merging with another large org that had a lot of branches (and a "normal" amount of public IPs for their size :)).
- "Unused" isn't quite the right term here. "Misassigned if they were to design their network today" or something would be more apt.
I had a networking job where we had a /16 legacy assignment nearly completely used but only one /24 "in use" according to what you could see from the internet. We looked at how the space was worth about a million dollars at the time but found it was not really worth it to try to move off anyways. Unfortunately, a lot of the devices smattered across that space were embedded devices where we had to pay bespoke vendors to come change the IP assignments or devices with IPs statically coded into home grown applications and every other sort of nightmare you could imagine. It'd have taken many bodies for a year + the associated costs + any of the operational fallout. At the following job we had roughly the same number of employees as Ford and our 10/8 was very tight as a unified network.
I'm not saying it would be as hard for Ford to try to find sub-blocks worth selling off or anything, just highlighting that waaaaay more of that IP space is being used than it seems from that picture and they likely do have a lot similar piece of shit equipment/sensors/building control and whatnot as well.
- Some things need to be opt in but most things don't. What makes sense to have which way is not as simple as saying "if people wanted it, they'd configure it that way". Imagine how many problems having to opt in to keeping recent files or whatever on each program you use on all of your devices would be. Apart from the annoyance of setting it up, the annoyance of forgetting to set that (among a dozen other opt-ins) on one of your dozens of programs and finding out only when you can't remember the name of the document you had open yesterday. Most people would "opt in" to use a provider which has what most consider "sane" defaults instead.
But there are obviously MANY things we prefer to keep opt-in. E.g. sharing my recents data with 3rd party advertises. No need to throw the baby out with the bath water and make every service awful by default just to have a universal rule to quote though.
- I think the point extends well beyond the specific app/OS example though, even though the article talks to macOS exclusively. For macOS and Windows there are built in tools which offer direct recording functionality. To trigger on macOS Command+Shift+5 (or launch it via QuickTime as jasonlotito noted), on Windows Win+Shift+S. Both of these utilize the same OS APIs OBS Studio uses to get the screen content, but they skip the step of needing a renderer at all.
- Are you referring to user namespaces and, if so, how does that kind of break out to host root work? I thought the whole point of user namespaces was your UID 0 inside the container is UID 100000 or whatever from the perspective of outside the container. Escaping the container shouldn't inherently grant you ability to change your actual UID in the host's main namespace in that kind of setup, but I'm not sure Docker actually leverages user namespaces or not.
E.g. on my systemd-nspawn setup with --private-users=pick (enables user namespacing) I created a container and gave it a bind mount. From the container it appears like files in the bind mount created by the container namespace's UID 0 are owned by UID 0 but from outside the container the same file looks owned by UID 100000. Inverted, files owned by the "real" UID 0 on the host look owned by 0 to the host but as owned by 65534 (i.e. "nobody") from the container's perspective. Breaking out of the container shouldn't inherently change the "actual" user of the process from 100000 to 0 any more than breaking out of the container as a non-0 UID in the first place - same as breaking out of any of the other namespaces doesn't make the "UID 0" user in the container turn into "UID 0" on the host.
- I don't use Docker for my containers at home, but I take it by the concern that user namespacing is not the employed by them or something?
- Naturally - losing a few hundred million users is likely why they are trying to find a different strategy than focusing on privacy or what power users comment on in the following decade and expecting better results for some reason.
Mozilla's funding comes almost entirely from the Google search deal. They can't afford to let the user count continue to dwindle on a principled stance alone. They either need to find workable alternative income of the same scale (which they've tried at least a dozen things that didn't pan out) or try to focus on what the average user wants in a browser rather than what the GNU fan power user comments in tech forums. They don't need a few principled people to stick with it, they need to be popular with the average person again.
When you go to the desktop it becomes harder to justify including beefed up memory controllers just for the CPU vs putting that towards beefing some other part of the CPU up that has more of an impact in cost or performance.