Exactly, you can have the train station downtown so you don’t have to get to the airport, wait for checkin, wait for the plane, etc. If you factor all the time around the trip, 6 hour train ride will win every time.

Wasps stop projecting challenge impossible. https://peoplesdispatch.org/2025/06/23/niger-to-nationalize-uranium-to-wrest-control-over-its-resource-from-france/

Yup, very similar stuff.

Oh man, wait till you find out how much fascist crap gets published in the west. Yet, somehow you chuds don’t claim it’s official state policy here, even though it’s much easier to make that case.

ha!

The funniest thing for me has always been that the empire just openly writes policy papers detailing exactly what they’re doing, and then we have a bunch of people running around pretending it’s not happening.

I’m sure that’s what was going through the mind of that one downvoter 🤣

Sure, different people like different things. My original point was that just being able to use natural language would be a benefit for non technical users. Most people struggle with complex UIs or achieving tasks where they have to engage multiple apps. Being able to just explain what you want the way you would to another person would lower the barrier significantly. For technical users, we already have tools that we can leverage, but if MCP services started becoming a common way to build apps, then we’d get benefits from that as well.

I haven’t seen this to be a problem when you’re using it to pull data from existing sources with tools like MCPs. Specifically, the content stays stable even if there are minor presentation variations. That’s sufficient to be useful in most scenarios. Like if you get it to pull some JSON from a service and render a table or graph it, the content of the presentation will not change.

People who keep parroting this clearly never bothered actually seeing how these tools work in practice. Go play with DeepSeek canvas and look at how it can render the data you give it. Meanwhile, what you as a technical user prefer is vastly different from what an average person wants.

You wouldn’t be the target audience for this. Vast majority of people using computers aren’t technical, and they very much would prefer just being able to use natural language. The whole hallucination thing is also much less of a problem when the model is simply used as an interface to access services, pull data from them, and present it. In fact, you can already try this sort of functionality with DeepSeek right now, where it has a canvas, and you can ask it to pull some data from the internet and render it. I’m always amazed how technical people are utterly unable to step out of their shoes and imagine what a non technical person might prefer to use.

I don’t think the underlying command line will go away, but if things moved in this direction that would be a benefit for people who use command line directly as well. The big disadvantage of GUI apps the way they work currently is that the UI is tightly coupled to the business logic. This makes it impossible to make scripts that combine functionality from different apps the way you can do with shell utils. In my opinion, this was the wrong direction all along. It would be much better if GUI apps were developed using client/server architecture. The service could then be used headless, and you could use it for MCPs for LLMs or to drive these services directly by hand.

Amusingly, I can see a future where LLMs become the default interface most people use making GUIs as we know them obsolete. Each app could provide MCP services, and then you UI would just be a text prompt and a canvas where whatever information you’re looking for is visualized in whatever way you need. The model would take care of coordinating the functionality from different available services and rendering the output on the fly.

I think the way we should view this is that “developed nations” means nations that have peaked in their development and are no longer capable of developing further. Meanwhile, “developing nations” are the ones where progress is happening. Everything makes a lot more sense framing it that way.

I’m guessing you didn’t bother actually reading the paper, here are some relevant quotes from it:

This paper compares an example implementation from the RISC and CISC architectural schools (a MIPS M/2000 and a Digital VAX 8700) on nine of the ten SPEC benchmarks.

Performance comparisons across different computer architectures cannot usually separate the architectural contribution from various implementation and technology contributions to performance.

We will do this by studying two machines, one from each architectural school, that are strikingly similar in hardware organization, albeit quite different in technology and cost.

There are strong organizational similarities between the VAX 8700 and the MIPS M/2000… Figure 1 shows that the pipelines match up quite closely, with the obvious exception of the VAX instruction decode stage.

…these two machines are very different in technology, size, and cost: the VAX processor is nine boards full of ECL gate arrays; the MIPS processor is one board with two custom CMOS chips.

…this paper shows that the resulting advantage in cycles per program ranges from slightly under a factor of 2 to almost a factor of 4, with a geometric mean of 2.7.

This factor [the RISC factor] ranges from just under 2 to just under 4, with a geometric mean of 2.66.

The RISC approach offers, compared with VAX, many fewer cycles per instruction but somewhat more instructions per program.

The correlation has a simple and natural explanation: given reasonable compilers, higher VAX CPI should correspond to a higher relative instruction count on MIPS.

The MIPS architecture has 32 (32-bit wide) general registers and 16 (64-bit wide) floating-point registers; VAX has 15 (32-bit wide) general registers… This can obviously lead to more memory references on the VAX…

The time for the simplest taken branch (or unconditional jump) on the VAX 8700 is five cycles. On MIPS, which has a delayed branch, it is one cycle if the delay slot is filled, and two otherwise.

The MIPS architecture allows instructions to be inserted in code positions that might otherwise be lost to pipeline delays… This ability is not present in the VAX architecture…

First, we cannot easily disentangle the influence of the compiler from the influence of the architecture. Thus, strictly speaking, our results do not compare the VAX and MIPS architectures per se, but rather the combination of architecture with compiler.

Second, we measured a rather small number of programs. Measurements that attempt to characterize machines broadly should be based on much more data.

…we believe that the fundamental finding will stand up: from the architectural point of view (that is, neglecting cycle time), RISC as exemplified by MIPS offers a significant processor performance advantage over a VAX of comparable hardware organization.

Likely the ones you’re hallucinating.

bingo

You should only use models that are safely and reliably tuned to spew capitalist talking points.

It’s hilarious how they can’t complain that the model is controlled by evil see see pee since it’s open, so they’re now complaining that users being able to tune it the way they like is somehow nefarious. What happened to all the freeze peach we were promised.

exactly