uKVZe85V

This is an example of a current trend: tools that help both humans and AI. Since both perform cognitive work, anything that makes that work easier benefits both.

The diagram showing where to smudge the disc looks so incredible, a kind of flower shape, no rotational origin. Seeing the video it makes more sense. All this is highly artisanal, the diagram is just a hint.

This give me an idea. Here's my smudge pattern that works better: (shows a diagram with blotches in the shape of Rick Astley singing).

Two reasons.

First reason, LLMs are modeled from what humans have been doing, and the have been writing software that way recently so it's easier to mimick that to get straight to results. This reason might fade away in the future.

Second reason, something related to impedance (mis)match, a signal processing notion (when the interface between two media is not well-suited, it is difficult to have a signal pass through).

Going through intermediate levels makes a structured workflow where each steps follows the previous one "cheaply". On the contrary, straight generating something many layers away requires juggling with all the levels at once, hence more costly. So "cheaply" above both means "better use of a LLM context" but also use regular tools where they are good instead of paying the high price (hardware+computation+environment) of doing it via LLM.

Interestingly, AIs are used to generate sample-level audio and some video, which may look like it contradicts the point. Still they are costly (especially video).

10 CVEs, remote code execution on platforms and individual developer's workstations. The public announcement is three days old and I couldn't find any mention here, which is kind of surprising.

Submission title here is the HTML title. Visible title in the article "The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of Anthropic’s MCP"

You're defeating your own point. CSD in practice breaks a basic feature of the desktop : knowing at first glance which of the windows will receive whatever you type on the keyboard.

For eons the standard was: the only one with the title bar showing the theme accent color. That is consistent, predictable, keeps the user in the flow.

With CSD each app does whatever inconsistent thing they can fancy. You type and oops deleted something in the wrong window.

Alas now even many default SSD setups fail at this (selected and non-selected windows look pretty much the same) and keyboard-first workflow is much hindered.

Been there, done that. Then dropped dark mode entirely. Strong filtering of blue light (use redshift or whatever your OS provides) beats dark theme IMHO, without the downsides.

I'm Not Sure.

Probably a "compatible" card that would behave like the standard of the era only after being setup by a DOS driver. Linux, like DOS programs, would find it only after such a setup. Perhaps even the card setup would not survive a reboot.

> Then I personally don’t care about needing JS to view the site (it’s 2024…)

In 2024, shouldn't hacker news visitors get that receiving a passive document to display locally is a thing, and having to run unaudited code from random strangers on your machine all the time is quite another? Then reopen the conversation about browser security?

Or, instead, get that simplicity is our ally, but unneeded complexity is the root of much evil?

Visit e.g. any stackexchange site with script disabled and be enlightened.

Not even certain this will be enough. Hawking radiation encodes the information that was thrown in. Sure at present it's a perfect mess, but who knows?

TL;DR: on that site, 77% of first-party bandwidth is Javascript. Serving HTML instead of Json would cut the bandwidth by 4.4.

> It's minimal and most code is on the server. Also it's a small footprint and proven to be fast (Preact). This site has a 100 performance score on Google Pagespeed,

Yes, it's nicely minimal in a number of aspects. Good point.

> JS doesn't mean bad UX.

For those who run their browser with scripts off by default it is.

Disabling JS and cookies by default has another nice benefit: on a number of sites, the stupid content-obcsuring cookie banner just does not exist (as well as ads, of course). And pages load time is much better.

> Blocking third party scripts and cookies is one thing, but not wanting first party script just forces the developer to use server-side templating for their static content which means you either deliver everything from the same origin (bad for latency) or chain a CDN in front that picks out static content to cache (I don't think that's compatible with the web 2.0 ideology).

That doesn't hold.

If a server can format data into a Json, it can format the same data into HTML and serve it the same. In the specific case of this site, the generated HTML has the same lifetime as the generated Json.

From the site: "It is updated every 2 hours."

Ironically, because this site is nicely minimal in a number of aspects, one can play with statistics. Not counting cloudflare beacon js, I measure

1.16k HTML, 1.56k CSS, 18.44k JS, 1.05k favicon.svg, 1.61k JSON payload.

Therefore 77% of bandwidth used is Javascript:

    p=(1.16+1.56+1.05+1.61) ; j=18.44 ; 100*j/(j+p)=77

By serving HTML instead of Json (at the same price), the bandwidth cost would be divised by 4.4:

    p=(1.16+1.56+1.05+1.61) ; j=18.44 ; (j+p)/p = 4.4

Think about it: running custom code on each browser of each visitor to perform exactly the same computation and yield the same DOM each and every time is totally useless.

All in all, serving a full HTML page instead of a HTML shell + custom JS + Json totally makes sense.

The good news is, for the past year I have started to hear seasoned web developers complain more about the sad state web development has been for years, and longing for some simplicity. Wait and see.

Kudos to the author for embracing minimalism. You can go a step further.

> The UI is almost identical to the HN frontpage

Well, for one HN works without Javascript, while that URL yields just a blank page.