lambdaone

This sounds risky: is the goal truly 100% uptime? Real 24/7 is difficult, even in safety-critical fields. When would you ever push out fixes or do live testing?

This is magnificent reverse engineering. I wonder why retrocomputing is so fascinating? Is it an attempt (by older people) to rediscover their youth, or is it a search for a golden age of computing where people still had some autonomy over their hardware? Or something else?

There are a vast number of problems that all can be summarized as "this is a really stupid thing to do, unless you really know what you are doing". This is one of them.

Yes. Micromouse was exactly what I was thinking of.

That is quite spectacular, but perhaps not for the reasons the organizers intended. This is pretty much the minimal toy problem for self-driving, with a well-defined course with clear markings, with the only real difference being that the car in question is a full-size racing car instead of a toy car with an Arduino on top.

Of course, the physics of dealing with a real high-speed vehicle is substantially more complex (and more high consequence) compared with that of a toy car moving at a few centimeters a second, but it's not, to coin a phrase, rocket science; the physical principles are well-known, and automotive engineering is a whole industry in itself.

I'd be interested in knowing what actual physical testing was carried out before the race, and how much time the teams had to prepare.

I was about to be outraged about this until I RTFA and saw that this is a 20 year old CPU feature. Just for once I think it's worth cutting Microsoft some slack on this.

This article is two years old. I don't think things as as dire as they seem, just a bit more boring than people might like.

I can't see any sign that long-term IPv6 growth has stopped, it's just ceased to accelerate. Looking at Google's IPv6 traffic graph (https://www.google.com/intl/en/ipv6/statistics.html), this is entirely consistent with being the first half of a classic logistic curve, with growth now linear as it approaches the 50% point after 15 years. If this is actually a logistic growth curve, we will presumably see the end of IPv4 sometime around 2040. Even if we take a more optimistic view and assume linear growth continues, it will still take until about 2035.

And that's fine. Old technlogies tend to wither away, not go out with a bang.

Worse than that, having a gun doesn't make you safer; it increases the risk to everyone in your household. But I can absolutely understand why fear drives people to own guns -- it's a vicious circle as increased gun ownership drives fear, which in turn drives even more gun purchases...

London's homicide rate is (roughly, depending on which source you use and year you take) about one-fifth of the average US homicide rate; you are safer in London than in almost anywhere in the US.

The homicide rate in Australia is particularly low. But in terms of overall homicide rate the United States is higher than the vast majority of other developed countries, and indeed most developing countries.

Most of the world sees the United States as a dangerous country.

For example, using the source you've just given, the US homicide rate is over 5 times the homicide rate of the United Kingdom, France and Germany, and over 10 times that of Norway.

Granted, you're more likely to die in a car accident than to be murdered in the US, but that's no reassurance; this is partly because the vehicle accident mortality rate is so high in the US, at over four times the rate in the UK. And your comment about dying in a plane crash is completely wrong: the air travel mortality rate is very close to zero, with under 200 deaths for over 800 annual million air travellers; a rate of less than 0.025 per 100,000 per annum.

I presume the value is in the associated open source software. You could obviously build your own for less in hardware costs, but once you've put in the effort of doing so, you will have spent far more of your time on the project than the cost of the ready-made product. You're paying for the bundling and the convenience.

Ross Anderson was indeed a giant, not just in computer science, but also in his work on the politics and ethics of the influence of computing in our lives. The world is lessened by his passing, but his work lives on in those he has inspired.

Kudos to the ACM for doing this. The way to open access is slow; one journal, one publisher at a time. But the world is moving in the right direction.

As a sidelight on this, I thought I'd also mention the book "Seeing Red: A Study in Consciousness" by Nicholas Humphrey, which advances a similar argument, but with brain output instead of body state as the driver of sensation.

A fascinating article. My first thought was "I wish they'd gone into more detail about current research", but then I actually read the whole article and they have gone into detail about exactly that. It seems to my layman's eyes that they've been pretty thorough.

I'd be interested to hear what those actually expert in the field make of the article.

That's the one.

A version of this was set to me in a university interview.

There is an easier and far more elegant way to solve this than the solution given. Consider the circuit as two superimposed elements; one with a current being injected at the first point and flowing outward to a sink at infinity, and the second with current flowing in from a source at infinity and exiting at the second point. (For the sake of argument, say the current is 1 amp).

The current flow patterns in each case are easy to calculate because of the symmetry of each problem.

Now add the two superimposed elements together, and the sources and sinks at infinity cancel out, leaving only the point source and sink.

You now know the current through the overall circuit and the currents through each resistor, and because you know the values of the resistors, you also know the voltages across each resistor. Add up the voltages along any simple path between the two points to get the voltage between the points, and since you also know the overall current, you can now calculate the equivalent resistance.

This is wonderful. Kudos to the ACM for making this happen, and being on the right side of history.

Nothing jumps out at me as being fishy here. There's what appears to be a small device mounted in the middle of that empty socket. It's also possible some of the rest of the pins on the socket are being used as test points. A circuit diagram would have be good to have here.

The site even comes with its own music charts: https://www.entrances2hell.co.uk/pagechart.html

My favourite track is "Ssssuuuuft".

That's exactly the point I was making above.

More than that, a second implementation of CUDA acts as a disincentive for NVIDIA to make breaking changes to it, since it would reduce any incentive for software developers to follow those changes, as it reduces the value of their software by eliminating hardware choice for end-users (which in some case like large companies are also the developers themselves).

At the same time, open source projects can be pretty nimble in chasing things like changing APIs, potentially frustrating the effectiveness of API pivoting by NVIDIA in a second way.

It seems to me that AMD are crazy to stop funding this. CUDA-on-ROCm breaks NVIDIA's moat, and would also act as a disincentive for NVIDIA to make breaking changes to CUDA; what more could AMD want?

When you're #1, you can go all-in on your own proprietary stack, knowing that network effects will drive your market share higher and higher for you for free.

When you're #2, you need to follow de-facto standards and work on creating and following truly open ones, and try to compete on actual value, rather than rent-seeking. AMD of all companies should know this.

By making it hard just to hijack a crucial TLD and transfer it over to an potential adversary without the cooperation of multiple trusted parties? It seems to me this is DNSSEC working as designed, and being remarkably flexible in doing so. Sometimes things _should_ be difficult to do.

The globe: parameter should give you the information you need: see https://en.wikipedia.org/wiki/Template:Coord#globe:G for full documentation on this.

Their ability to superficially mimic cognition, in a way that not only raises significant philosophical questions but also seems (rightly or wrongly) to bring the prospect of "true" AI tantalizingly closer.

This is a beautiful piece of work. Connecting all the semantic levels is hard work, and this does it elegantly. It goes to show that old-fashioned technology like object files and linkers is still useful, and can still pay off in unexpected ways as part of new technology.

"Not being a protocol you tack onto your code in an afternoon" suggests that there is a big hole in the ActivityPub ecosystem; it should absolutely be possible to do that. You can, for example, write a basic HTTPS application server in an afternoon in Python, because libraries to implement all the hard bits have already been packaged by someone else. And similar functionality exists in other languages.

A similar level of cross-platform library support for ActivityPub would greatly ease its adoption across the universe of Internet applications.

I'm not sure why the ping time is ~60 seconds.

Reading the Arduino firmware suggests a data rate of 40 bits/s on the actual spaghetti strand.

Allowing for a start and stop bit, that's 4 bytes/second. Given a typical ping packet length of 56 bytes, and a negligble SLIP encapsulation overhead, I'd expect the outbound ping request would take 14 seconds to transmit, and the ping reply would take another 14 seconds after that, making 28 seconds in total (plus the processing latency, which should be negligible). The only way I can see it taking twice that time would be if the ping packets had truly unfortunate content of bytes that SLIP would need to escape into byte pairs, which seems unlikely.

I'm surprised the author didn't go for direct transmission of a 9600 baud signal; it wouldn't be too hard to use a DIY voice coil actuator to drive sound waves down the spaghetti at that frequency, and not too much DSP processing to amplify and clean up the measured movement at the optical sensor into a clean digital signal.

Thanks for all your work on Rust! If I had the option to choose just one small thing to go after next, it would be well-defined behavior and error handling for integer overflow and underflow in languages without bignums.