lambdaone

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.

Enforcing memory safety is good thing, even if it's not perfect; it's the first stage in the long-needed move from throw-it-in-a-bucket-and-hope-it-works "software engineering" toward proper formal-methods-driven actual software engineering.

I feel complaining about it as insufficient is not the ideal way to push things forward. Instead, let's treat the progress on memory safety policy as a first victory in that process, and build on it.

"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.

It may not be much at the moment, but the thing that I find encouraging is that there seems to be very little pushback against it; the sanity of the Rust approach is very much accepted now.

As other commenters have said, you can do it a bit at a time, converting non-core kernel code to Rust at the edges. Another route to memory (and other) safety would be the C -> WASM -> C route that effectively rewrites/transpiles code to operate within its own sandbox, which also has the advantage that it could at some later date support modules written in languages other than C.

Indeed. People who don't do these kinds of activity wildly overestimate their physical capabilities.

Part of the reason for this, I think, is that Hollywood and TV depicts ludicrous levels of acrobatic and athletic capability as the norm; apparently normal people in movies are depicted catching falling people one-handed, outrunning explosions, and so on.

Climbing, even at an enthusiastic amateur level, is much harder than non-climbers believe, and I think your suggestion that readers try top-roping a 5.9/5.10 to get some idea of even beginning climbing difficulty is an excellent idea.

I cannot even imagine the level of dedication and expertise it takes to do this sort of feat.

What makes Rust great is that its design drew upon decades of understanding of programming language theory and practice, and the designers took bold decisions based on that understanding to avoid the mistakes of other programming languages.

The problem with async Rust is that the async idiom is new, and its interactions with the rest of the software ecosystem not particularly well understood. This makes async support glaringly different from the rest of the language.

I'm glad the designers seem to be taking a step back and reconsidering how everything fits together.

Given that an estimated 70% of security vulnerabilities are currently memory safety errors, I think that justifies the use of Rust all by itself.

But a far greater gain is that Rust is designed right from the start with tighter semantics which make it more suitable static analysis, and that it is, unlike C/C++, largely free of undefined behaviour.

This is good work, and I'm not quite sure why people are complaining about it; there clearly won't be any replacement of the traditional C sudo by this unless it's driven by distros and the community making it happen.

Multiple implementations make it much easier to do fuzzing and generate automatic test suites that may be used to improve all the versions of this critical utility.

In an ideal world, yes, they would by shut down in seconds. Yet BGP hijacks still occur in the real world; here's one from last month: https://slowmist.medium.com/analysis-of-balancer-bgp-hijacki...

And you're certainly right about government-mandated traffic hijacking.

Cool. Domain-limited CAs are a really good idea, and they don't need anything like dynamic downloading of CAA records.

No, that's not needed at all. If the malicious actor can man-in-the-middle traffic to victimsite.com (say using a BGP hijack), they can serve HTTPS traffic to the end user from their MITM server, secured with a certificate issued to "victimsite.com" that is issued by their own CA, and the MITM can then in turn communicate to the real victimsite.com using HTTPS secured by the real site's certificate, signed by its own CA.

Now, there are CAA DNS records, which serve the purpose of restricting the CAs that can sign a particular domain, which would of course be ignored by the malicious actor, but _could_ be checked by the end user's browser. But to the best of my knowledge, no browser does that.

What a terrible logo design, and semingly no real buy-in from any major organization. I'm not surprised this doesn't have any traction.

I think an IPv6-compliance logo scheme would be a good idea, but it should be driven by major commercial vendors like Apple, Microsoft, Google etc on the software side, and supported by industry forums like the WiFi Alliance and the GSM Association on the hardware side. I would love to be able to ditch IPv4 entirely for running large production networks.

I think Apple have already started to enforce IPv6 support on iOS apps. It would also be interesting to audit open source projects for IPv6 support; just the presence of the appropriate API calls would probably be sufficient for a first hack to tell the difference between IPv6-compliant and non-IPv6 compliant applications. This would allow influential distros like Debian to start the process of deprecating old software which is incapable of working properly with modern networks.

Wikipedia policies explicity forbid using Wikipedia itself as a source for Wikipedia articles. See https://en.wikipedia.org/w/index.php?title=Wikipedia:RSPRIMA...