amoss

Ah, "code is law". Good luck with that.

So we are somewhere between 1995 and pets.com

Ah, I did not grasp that reading your comment - then we are saying the same thing.

Yes, I think that progress has become rapid enough that we can't predict six months out. I suspect that we are only 1-2 inventions away from something quite large and transformative. Obviously LLMs have already created a lot of excitement and opened up new areas of content generation already, but I think something larger is coming.

Certainty about predictions of the future has always been close to zero. If you take a person from an appropriate time and ask them what the future will look like in 1000, 100 or even 20 years then their predictions will bear little resemblence to what actually occurs.

As humans we have a tendancy to make linear future predictions based on past observations. Over the timescales that matter significant effects occur from previously unseen kinds of events that become important via interactions with other events.

The important measurement would be what the length of the event horizon - the length of time before our predictions rapidly decrease to zero certainty. In a singularity we would expect that length of time to decrease close to zero. What has it been historically? I would claim that 5-10 years is a difficult period to make meaningful predictions about. I think that 20 years has proven to be very difficult but possible in the past. I am unaware of any 100+ year predictions that have landed with better than random chance.

Interestingly I think we are entering a period where 5 years will be the upper bound, and even predictions over shorter 2-3 year timespans are going to become difficult.

Not if you are rendering the Zuck - he is quite lo-poly in real life.

Would you like some toast? Some nice hot crisp brown buttered toast. No? How about a muffin then? Nothing? You know the last time you had toast. 18 days ago, 11.36, Tuesday 3rd, two rounds. I mean, what's the point in buying a toaster with artificial intelligence if you don't like toast. I mean, this is my job. This is cruel, just cruel.

Clean implementation is an approach to guarantee a lack of pollution. It is not the minimum level necessary to avoid it.

Perhaps we are talking about overlapping but slightly different concepts? If I run the program and it goes wrong then I know there is a bug - but I don't know what or where it is.

So observing that Rowhammer causes buggy behavior may be simple. But finding the actual bug - i.e. this sequence of instructions on this data causes the memory corruption would be much harder.

Part of this comes down to how you interpret the "many eyes makes bugs shallow" but I suspect that no number of eyes would have found the Rowhammer bugs by looking at the code.

uBlock Origin removes those successfully, and a lot of other annoyances.

> They're all issues that can be understood - perhaps not exploited, certainly not fixed, but understood that a bug is there - without any deep architectural knowledge.

I don't think it is clear how you would do this other than with hindsight. When the bug was discovered, if we avoid architectural knowledge of why the bug was occurring then what information would the discoverer have access to?

- Memory corruption is occuring during execution.

- We can't find any part of code that appears to corrupt the values.

Finding the bug requires finding the Rowhammer affect, which means looking isolating the instructions that are accessing similar uncached addresses, and then finding the pattern of accesses and cache flushes which triggers the corruption.

Could you explain how this would be simple, or do you have a different view of the bug complexity that you could explain?

No. Architectural leakage via a side-channel is far from simple. It requires deep understanding of the code (i.e. what it does, why it is doing it that way and the implied effect of executing the code on the architecture) and also of the architecture (i.e. how it is executing and why that causes leakage to be observable via the side-channel).

If anything, these are canonical examples of non-simple bugs.

> Patrick Bateman's Fisher-Price

Oh wow, that one is going in the memory bank for future use.

Java, Not Even Once.

Cool, you have a very nice mic. Great sound quality on the recordings. That gives me a few days of listening material. I liked the brief glimpse of Hest in the end of the Jack Rusher talk at Strange Loop, looking forward to find out a bit more about what you're doing.

> Unlike tabs in makefiles, which is just something certain types of people like to complain about.

http://catb.org/~esr/writings/taoup/html/ch15s04.html

Which "certain type" are Stuart Feldman and Steve Johnson?

The post is interesting, and four years old... so what has changed in Hest since then?

Upgrading hardware is an ongoing process. You are proposing a single point of change without any reason for it to be handled that way.

You are arguing that all change has the same cost. I don't see your reasoning for this. A smaller change to a system has a lower cost in R&D, and a lower cost in manufacture.

Although it is probably true that the cost of updating all equipment dominates the cost of redesign, this is only an issue for a big bang update rather than a rolling upgrade.

So how many backbone routers are 20 years old?

Your claim was that any change to the ASIC was the same design cost. But really? A 40-bit routing table design, where there is a 32-bit fall-back to preserve the top 8-bits vs a 128-bit routing table design. Why would these be the same cost?

Nah, hardware people just don't negotiate hard enough.

Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged. Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone so that they can be used to handle routing in one of the new 32-bit super-A class networks.

Sure it's ugly as hell, but it is just backward compatible enough to work.

People hate kludges and backward compatibility, but IPv4.1 with 5-byte addresses would have been the dominant standard by now.

Tabs in makefiles is another classic.

The reasoning in that essay comprises pedantry and poor judgement. Language reflects usage. Accepting that a particular usage has existed for hundreds of years, but claiming it is too novel to be correct is quite bizarre.

We've reached an inflection point, the new version would be: Nvidia can sell twice as many transitors for twice the price every 18 months.

The CFO read an article in Forbes that said we would save money by migrating to the cloud, so we now have an unlimited budget for consultants to build us a cloud platform....

Latency and throughput are not inverses, although they may exhibit anti-correlation over small ranges. A low latency does not imply high throughput. In particular xterm does not buffer input / rendering, so while individual keystrokes produce a response quickly, when there is a high volume of text the throughput will be lower than other approaches.

This will still feel laggy, just a different kind of lag to the one that you perceive using a high latency terminal.

Only partly, the argument that OVPN put forward had two parts:

1. They have no information to hand over as they do not keep logs.

2. There is no law that requires them to keep logs.

They proved the first part in court, but there wasn't anything in the torrentfreak article about the second point. The second point is the relevant one here as Mullvad are making both of the same claims. While they have a legal for the first one (case law) the second is still untried as far as I could tell (only made a quick search).

For the second part to be proven, somebody would need to take them to court on the second point. Nobody has tried to do that (yet) and so the question still open, and it depends on how you interpret the wording of the law https://lagen.nu/2022:482. In particular, is the definition strict enough that it applies to the operators of the hardware that makes up the network, or does it apply to a virtual service over the top.

I'm not a lawyer, there is a lot of subtlety in how §7 is written that I do not claim to be aware of, and my swedish is quite basic.

The estimate is 100 000 casualities (20k dead and 80k wounded), and it seems to be correlated with several different intelligence sources.

The number is news because Russia is waging a large-scale invasion of another country using cannon fodder tactics. Reporting on that invasion is not simply propaganda.

> Today, thought leaders casually opine on how and where ML will be useful, and MBAs feel like this is an acceptable substitute for expert opinion.

Sounds like standard operating procedure.

I choose not to choose Java. I choose life.

This could be true if you consider survivor bias.