lambdaone

Why limit your changes to syntax? Intercal's COME FROM would be a good addition, but you definitely also need SOLVE and PROVE statements to increase the power of the language.

Having IF TERMINATES and IF NOT TERMINATES predicates would be useful, too. Why limit yourself to everyday computable functions? And if you really wanted to, you could implement both SOLVE and PROVE in terms of them...

You're right that this is generally a golden rule. But rules can have exceptions, and this seems to be one of them; the Linux kernel is now so large and complex, and C so obviously outdated now, that it's worth the pain to start writing drivers in Rust. And because of the modularity of the kernel, and the care taken to make Rust binary-compatible with C, this looks to be actually practical, as individual subsystems will be either entirely Rust or entirely C, particularly when new drivers are involved.

Rust is a systems programming language by design; bit-banging is totally within its remit, and I can't think of anything in the kernel that Rust can't do but that C could. If you want really, really tight control of exactly which machine instructions get generated, you would still have to go to assembler anyway, in either Rust or C.

While it's almost never a compiler error, it happens, and I have personal experience; I once found an error in the VAX/VMS Pascal compiler - and could demonstrate it as such by disassembling the compiler output - and had to work around it until DEC fixed it.

See my comments about L4S.

It is until you congest it. Then, like all other network technologies, performance collapses. You can still force traffic through with EDC, buffering, and re-tries, but at massive cost to overall network performance.

Wireless networks' latency problems are almost entirely caused by contention, buffering, and vast over-booking of bandwidth, where raw bandwidth number competition has been over-valued relative to actual network application performance.

L4S is on its way, and may finally be the beginning of the end for bufferbloat and congestion, and vendors of mobile devices are in an almost unique position of being able to roll out network stack changes en masse. And just for once, consumer incentives, vendor incentives and network operator incentives all align - and it's incremental, and lacking in incentives for bad actors.

See this blog entry: https://www.ietf.org/blog/banishing-bufferbloat/ for more on L4S and bufferbloat. And this: https://datatracker.ietf.org/meeting/105/materials/slides-10... for a proper technical deep dive.

The development of L4S has been a pincer operation across all levels of the network stack, integrating everything previously understood about latency and congestion in real networks, and one of the most impressive bits of network engineering I've seen in the history of the Internet.

One in five seems to be an under-estimate. Based on my experience of Upwork, at least 50% would be a better estimate.

I think there's big potential in using DNS blacklists for this: they have the advantage of being massively scalable and simple to maintain, and clients configuration to use them is also easy.

The scalability comes from the caching inherent in DNS; instead of having to have millions of people downloading text files from a website over HTTP on a regular basis, the data is in effect lazy-uploaded into the cloud of caching DNS resolvers, with no administration cost on behalf of the DNSBL operator.

Reputation whitelists (or other scoring services) would also be just as easy to implement.

What's the reasoning behind the 10^12 instances claim? It is based on something like 20^9 mobile devices, each with 50 apps, each with an SQLite database?

Or some other calculation?

The next logical step after AI-slop music from Spotify would be for device manufacturers to cut out one more middleman, and provide their own locally-generated on-device AI-slop music as a feature of their devices.

It's quite concerning that they had at least two things go wrong at once, each without a backup plan. What happens now? Is something like an FAA investigation going to happen, or is SpaceX not under any kind of regulatory control in this regard?

While it's true that mathematics cannot ever be completely formalized, per Gödel's incompleteness theorems, a huge amount of it obviously can, as is demonstrated by the fact that we can write it down in a reasonably rigorous way in a combination of conventional mathematical notation and plain English.

Nor is this in any way "a fundamental problem with using AI to do math".

Yes. The lack of diffuse reflection from the pink train is the clearest giveaway, and AI videos in general have problems with getting shadows and radiosity right. There's also the existence of the real-world Hello Kitty Shinkansen and the APM Cat Bus in Japan that makes this image more plausible.

A tragic and short-sighted act of cultural vandalism for short-term profit. In other words, business as usual.

It's mind-boggling that this is not enforced by hardware: as other commenters has said, both by powering the LED from the same power as the camera, and also by making the enabling of that power use a simple hardware pulse-stretcher that would prevent the attacker from enabling the camera at such a low duty cycle that its flickering would be invisible to the user.

Ideally, the same should also be true of the microphone pre-amp, with its own LED separate from the camera one.

Surely when the price of power turns negative, you just start to disconnect panels from the inverters at the low-voltage side? The voltage remains, but no current flows, and no power is generated. If switching huge DC currents is the issue, this disconnection can be pushed down towards the panel level; relays/contactors would do fine, and you can dial capacity up and down by connecting or disconnecting a greater or lesser area of panels.

Is there some electrical engineering reason this cannot be done?

Absolutely! Can this probability be quantified?

This is actually an extremely interesting question. 'Weak' files that are more easily compressable than others certainly exist, but with low probability.

For example, the all-zeros file is a member of the set of all random 3 megabyte files, and it would certainly be possible to compress that, if by great good fortune you were lucky enough to receive it - albeit something that is unlikely to ever happen in the possible lifetime of the universe, given current physical theories.

Is it possible to quantify this idea of a 'weak' file more accurately?

You're really going to hate it when you learn about JSON Web Tokens, which exist exactly to hack past this sort of problem.

Let's Encrypt is a massive achievement, and is now essential infrastructure.

Basing it on an open protocol, so it doesn't become a single point of failure, was a clever idea that allows the idea to survive the demise of any single organization.

May there be many more such anniversaries.

Have you considered the possibility that the ad is deliberately intended to stir up controversy, putting the brand in people's minds and priming people to pay more attention when they actually launch the new car range?

I think the idea here is that somebody else runs an underlying IP layer, and this rides on top as an overlay network.

You could, of course, run a local wireless IP layer and use this to route, but peer-to-peer wireless has well-known scaling problems.

Still, it looks like a very interesting and reasonably well thoughout out idea.

Ladybird is indeed very interesting. But it's too soon to tell whether it will be successful, and how, if it is, it will get the money to maintain its development in the long term.

The real value of Firefox is to have a serious browser vendor that is not wholly owned by a FAANG company, and it still to some extent focused on the user's needs rather than its parent company's agenda. Having a third browser engine which is neither WebKit or Blink is a win too.

Implementation diversity is absolutely essential to an open-standards based Web, and right now the Web is pretty much the only open channel for pretty much all of human discourse.

Having said which, Mozilla is in real trouble, and desparately need to sort out their business model.

It really, really struggles to move the pieces. More development is needed.

Hmm. I got ChatGPT-4o to write some code for me today. The results, while very impressive looking, simply didn't work. By the time I'd finished debugging it, I probably spent 80% of the time I would have spent writing it from scratch.

None of which is to discount the furture potential of LLMs, or the amazing ability they have right now - I've solved other simpler problems almost entirely with LLMs. But they are not a panacea.

Yet.

He's part right. There's certainly a law of diminishing returns in terms of model size, compute time, dataset size etc. if all that is to be done is to do the same as we are currently doing, only more so.

But what Marcus seems to be assuming is the impossibility of any fundamental theoretical improvements in the field. I see the reverse; the insights being gained from brute-force models have resulted in a lot of promising research.

Transformers are not the be-all and end-all of models, nor are current training methods the best that can ever be achieved. Discounting any possibility of further theoretical developments seems a bold position to take.

Evolution wasn't trying to do anything. But learning (in some sense) to walk was exactly something that evolution did, albeit very indirectly.

I'm surprised that the authors seemingly can't see that their argument hoists them by their own petard by showing, using exactly the same reasoning, that human intelligence is equally impossible to create (unless, perhaps, you are willing to use vitalist/supernatural arguments to claim is is different in kind from computational AI).

Surely the referees must have raised this at the review stage?