choeger

> Russia and China industrialized within one generation. No nations ever developed faster or more, an economic miracle pointedly ignored by most western economists because communism bad, STFU.

Yeah, nope. They industrialized when the west already had. There's a massive difference between developing stuff and then deploying it and outright deploying it. Compare that, e.g., to imperial Germany vs. England and you see the difference.

In the end, it all boils down to this:

1. It is trivial to have a metric about how many requests were made for a link on a site, say a/

2. It is legally very much non-trivial to have a metric about how many requests were made to a/ followed by requests to b/

One way to solve 2. would be to change links based on earlier interaction server-side. So instead of [a/, b/], the requests would be [a/, a.b/] IMO, this should be legal, but might not under strict interpretation of the law.

As it turns out, correctness very often simply doesn't matter. Or not as much as one would intuitively think.

How many shops are there optimizing "business strategies" with data that's -essentially- garbage?

That's obviously wrong. If one resource gets scarce but retains its use, it will get more expensive compared to other resources that remain plentiful.

All commodities together feed into inflation. So either some will become less expensive or some will outpace inflation.

What we're seeing here is that resource extraction can get better, so resources aren't really scarce. But there are certainly some commodities, not reflected here, that became much cheaper. E.g., corn or meat, so these metals might have become more expensive in relative terms.

Makefiles have an even more interesting issue: They lost their main purpose. In many, many projects that I've seen, they only consist of phony targets. No dependency tracking is used whatsoever.

How many Makefiles are there that just Wrap npm, pip, or some other tool like that? A Makefile is supposed to be the build system, not trigger it.

You're probably using the wrong tool and should consider a simple plain shell script (or a handful of them) for your tasks. test.sh, build.sh, etc.

Essentially, an LLM is a compressed database with a universal translator.

So what we can get out of it is everything that has been written (and publicly released) before translated to any language it knows about.

This has some consequences.

1. Programmers still need to know what algorithms or interfaces or models they want.

2. Programmers do not have to know a language very well anymore, to write code, but the have to for bug fixing. Consequently the rift between garbage software and quality software will grow.

3. New programming languages will face a big economical hurdle to take off.

Nice work. I didn't yet read it fully, but I love the idea. Looks to be a valuable thesis.

Hah! Try to separate your domain logic from your interfaces (e.g., using something like hexagonal architecture) and then say this again.

Yes, it's a lot of work coming up with good properties, but it massively helps to find gaps in the domain logic. In my experience, these gaps are what's typically expensive, not the weird problem a junior had with properly using Redis or S3.

> ensure you are only doing things they approve of

Absolutely. They might not care about individuals, though. It's their approach to shape "markets". The Apple, Google, Amazon, and Microsoft tax is not inevitable and that's their problem. They will fight toe and nail to keep you locked in, call it "innovation", and even cooperate with governments (which otherwise are their natural enemy in the fight for digital control). It's the people that a) don't care much and b) don't have any options.

In the end, a large share of our wealth is just pulled from us to these ever more ridiculous rent seeking schemes.

It's Bond. A certain resemblance is necessary. It doesn't suffice to add a few Martinis here, a PPK there, and end with a showdown against a super villain involving tech gadgets. The movie also needs sexism and humor, at least.

Seriously, reinventing Bond while modernizing it but keeping it a Bond movie is challenging. A challenge that people should accept.

> So why is the change between TOS and TNG ok but the change for Discovery isn’t?

Because of the intention. The TOS Klingons were always supposed to look like the TMP/TNG Klingons, but the producers didn't have the budget until the movie and next show.

It's an entirely different thing when the original designers correct a budget constraint vs. new designers arrogantly throwing away prior art.

When authors ignore established facts of the universe they're writing for (vulgo "the canon"), they're most likely either lazy or ignorant or arrogant. I read quotes about Star Wars lacking "strong female figures" before Disney (cough, Mon Mothma, cough Leia) and someone even mentioned that the Klingons got redesigned in STD because of their original skin color. (But why not just using some other colors is beside me.)

In all cases it's fraud. You claim to write a story inside a complex established universe but deliver something that just superficially uses some assets and then just does its own thing. Then just develop your own universe, ffs!

If you want to write Star Trek or Star Wars or whatever, adhere to the canon and stay within the established constraints. If you feel that the canon constrains your creativity too much, go find some other playground.

Bird flu pandemic.

And passkeys only work with Microsoft OS, Microsoft Browser or some other thing that Microsoft controls?

Not hat I would ever imply that Microsoft has anything than our best interests in mind...

Is that a prediction in the form of "There's a 30% chance of light rain that day." or "Temperature will reach 22,5°C at 14:00."?

You had punctuation? We had to to with empty spaces and silence! I once read an entire poem just using silence!

I think your model is absolutely right. But there's a catch: Zero Trust (TM) is about not giving any machine any particular kind of access. So it's an infinite amount of machines with zero access.

The point of Zero Trust (TM) is to authenticate and authorize the human being behind the machine, not the machine itself.

(Clearly, that doesn't work for all kinds of automated access and it comes with a lot of question in terms of implementation details (E.g., do we trust the 2FA device?) but that's the gist.)

Well written!

I wonder if there's a way to efficiently implement it without resorting to monomorphization?

A function that's polymorphic can be transformed into a more primitive (say C or assembly) function that gets extra arguments that carry the "shape" of the type variable (think of sizes, pointers vs. values, etc.). Is there a similar strategy for these polymorphic records?

I see two issues:

1. The offset of any particular field in the record is unknown at compile time

2. The size of the record itself is unknown at compile time (but this should be trivial as an extra argument.)

What even is the speed of causality? Is there any way to determine that causality has made it halfway from cause to effect?

Or is this just a metaphysical way of saying that no particle can move faster than the speed of light, assuming that causality is just an abstraction of moving particles around?

I would make it embeddable. The goal would be to become the Lua of web engines. As it turns out, having an embeddable web engine would be a massive market position right now.

I really don't see what the problem with the runtime metadata is? In the example, the size of T is also an argument? So why not pass a pointer to the whole set of type information there?

Daily check-ins can be necessary under certain circumstances. (Think all-hands-on-deck quickly evolving situations with a tight deadline and several unknowns. Like a big feature launch.) Sometimes you might even need them twice a day. You cannot do it much more often, though.

So the big problem with scrum is not the daily, but it's ceremonious importance. It's just fixed, it doesn't have any reason. One does it because scrum.

If you look closely, you'll see more of that pattern in scrum. Sprints, for instance, are a given. Yet, why would anybody do them when there are no new features to be developed? When a product is mature and needs maintenance or simply doesn't exist at all, there's no reason to do sprints. Whenever there's no feedback from stakeholders, there's no reason to do sprints.

> For what it's worth, I suspect those containerized builds are responsible for the overwhelming majority of Setuptools downloads, for example

I agree to that hypothesis. But other distributions (say, Debian) should be facing the very same problem, right? How often is Python downloaded from Deb mirrors nowadays?

The analysis contains an error. Binary artifacts don't cause exponential growth in storage requirements. It's still just linear. That's also quite clearly seen when after a phase of exponential growth, the binary artifacts still only account for 75%.

So this whole strategy (actually a pitch for zigbuild) would ideally reduce the storage requirements to 25% - which would buy the whole system maybe a year or two if the growth continues.

Of course, it's a good idea to build client-side. Especially considering the security implications. But it won't fundamentally change the problem.

> Possible fragmentation of bodies – in this case one of the masses breaks into 2 equally-sized pieces, which fly off into different directions.

This is the stuff I have a huge question mark about in my head. If two pieces that move very slowly relative to another collide and fragment, why should the pieces fly of in arbitrary different directions and not continue on their trajectory?

So, gravitational pull increases the velocity of bodies relative to another. That's already an exchange of energy, the piece ahead gets slowed down, the piece behind will speed up. Then they collide, exchanging the energy difference again, speeding up the piece ahead and slowing down the one behind. The relative speeds will be tiny initially, because the distances are small, so fragmentation is unlikely. Where does that process run off?

> using adapters and interfaces is costless,

Hah, no, they're not. Every production app is read many, many times by several different developers, mostly to search for bugs. Reading across adapters, services, and interfaces make that much harder. Especially, if the architectural pattern was implemented slightly differently every time by various authors.

Abstraction always comes with a price. Often, it is well worth to pay (or we would still code everything in C or assembly), but sometimes it's just a waste.

Maybe I am missing something here, but why would you run "AI" on that task when you go from formal language to formal language?

I don't get the usage of "regex/heuristics" either. Why can that task not be completely handled by a classical algorithm?

Is it about the removal of non-content parts?

I'm running Linux for decades now without problems. Gaming was Windows' last bastion, but SteamOS is looking more and more attractive. So maybe I can get rid of that crapware personally.

I think that's pretty obvious, no? Behavioral controls. You add a web cam screenshot to that desktop screenshot and sell real attention signals to advertisers.