cxr

I suspect the fidelity of your comment to your actual level of confusion is low. In any case, if you're really this confused by the information provided earlier, then the chances aren't good that there's anything that anyone could say to get you unconfused.

You've made the same exaggerated claim in two comments. Not only are you not banned from Codeberg if you have used LLMs to help you write code "in any of your projects", but you're not even prohibited from using LLMs to help you develop projects that you host on Codeberg.

What you can't do is "share projects that mostly consist of code written by 'generative AI'-tools". <https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36...>

This reads like someone who either never had one of these jobs and is left to try to use their imagination, or someone who is knowingly misrepresenting what consequences are awaiting low-level employees purely by choice.

Either way, the conversation would be better without your involvement.

> it's not an "invalid argument" to share your experience

<https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>

> I didn't mean to say the critique isn't valid, nor did I say that, you're putting words in my mouth there.

Is this performance art?

But GitHub has _bad_ Markdown support. GFM is the reason why so many projects on GitHub are besot with Markdown that's unreadable in a text editor.

You moved the goalposts from "The simplest way to build a high-quality website" to "there are benefits to using Astro".

> The thing you linked doesn't meet the bar I'm aiming for, either for the resulting site or for the experience of building it.

And now you're applying a standard that was never claimed to have been met.

There's a way this back-and-forth could have gone, which is right after I emphasize that "The simplest way to build a high-quality site" doesn't belong at the top of the page because it doesn't reflect what you're actually doing, then you say, "Oh yeah, I see what you mean. I went ahead and changed it to something that's more accurate and (a little less hyperbolic). I'm not trying to fundamentally throw out the experience that people who are already familiar with building sites with conventional NodeJS-based frameworks like Astro are used to. Just trying to make it a little easier."

Instead we got this.

I'm responding to a specific claim that you put at the top of the page the linked to.

> the [dependencies] used here were carefully selected because they do provide a benefit.

You're moving the goalposts.

Even for people who don't practice this, if you're publishing a static site, you can make sure you're generating output with rel=canonical links and at any given point, you should be able to run a tool (entirely separate from your chosen static site generator) over the output to extract those URLs and verify at time t2 that the set of links that existed at t1 (where t1 < t2) is a subset of those at t2.

Readers encountering this project for the first time should be aware that the earlier Oberon-on-RISC-V project <https://github.com/solbjorg/oberon-riscv> (HN discussion: <https://news.ycombinator.com/item?id=25497002>) exists and was already discussed on the mailing list:

<https://lists.inf.ethz.ch/pipermail/oberon/2026/017161.html>

Plenty of discussion about this on HN over the last six months

<https://github.com/mdp/linkedin-extension-fingerprinting>

<https://browsergate.eu/>

> The simplest way to build a high-quality website.

The build (generation) step should be able to execute on/inside the browser runtime (using standardized APIs, not hardcoded against proprietary APIs that the NodeJS people invented).

See also <https://crussell.ichi.city/pager.app.htm>

"The amount[...] that industries pollute" is just "personal changes" with more steps.

In this case, do the things that it says are no use focusing on. Change your individual behavior to align with the position you profess to have taken about whether or not climate change is a serious and urgent problem.

Somehow I get the sense that you don't shoot for a balance of $0 in your bank account.

It's because inhabitants of metric land neglect the decimeter, probably because it's too awkward of a word.

Define 1 metric hand = 1 decimeter, and you can cleanly convert between hands and meters (it's just a factor of 10 instead of the weird jump from centimeters to meters) and at the same time be able to approximate three metric hands to a foot.

Somehow I get the sense that you don't shoot for a balance of $0 in your bank account.

For a time, it was popular for movie trailers to end with a domain, often of the form "${ $TITLE }film.com", which would take you to the marketing site for that release. Nowadays there's a whole TLD specifically for movies.

It's a shame that isn't a norm for you to be able to plug a URL into a reader that consumes application-specific RSS (à la podcast clients) for the express purpose of giving notifications when that film is available (either for rent or by subscription) on a new platform.

(Ideally, of course, the media itself would be self-hosted, so you could paste the URL into e.g. VLC and encounter a platform-neutral way to negotiate payment directly with the distributor (or not and just get embedded ads—à la podcasts) and then you're off to the races.)

And the Web is not HTTP!

> There's always some nincompoop who brings that up. Al Gore deserves credit for what he did as a senator and vice president. He helped to pass legislation that enabled the NSFNET backbone to grow and to permit commercial traffic to flow on the government-sponsored backbones in the US. Had he not done that, it's pretty likely that the commercial sector would not have seen an opportunity to create a commercial internet that all of us can enjoy, so he does deserve some credit for what he's done.

— Vint Cerf, Tracking the Internet into the 21st Century <https://www.youtube.com/watch?v=Hf0rjtnwC9A>

> Would moving the untrusted content to be served from a separate domain entirely close the hole?

Yes.

> That's why I'm careful not to include allow-same-origin in the sandbox attribute

It doesn't matter. I just said there is no combination of CSP or the iframe sandbox attribute that can be relied upon here.

> <iframe sandbox=""> - which really is designed to be used as a sandbox

Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written.

(There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)

CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.

A lot of people don't get podcasts. They think it's a genre (and that it applies to the show(s) they watch on YouTube).

For a large segment, telling them that a feed reader is for podcasts but for reading will just elicit a "what?"

It's no use being pedantic if you're not going to be correct.

> This is a pedantic point, but that's not really what the definition of compiler is as much as a common understanding of it. By definition, it just translates one language into another

The history and etymology doesn't support that definition, either; that's just another "common [mis]understanding" of the term. It's in the name. A compiler produces a compilation—an aggregate of multiple subroutines, including user-supplied ones and some by the system/programming environment, transformed into a single program for a given target.

(You're describing the process of "autocoding", a job that every compiler does, and a term that predates "transpiler" but that no one uses because they favor stretching the more frequently encountered term "compiler" for their use case.)

The creator of lcc also published a paper "lcc.NET: targeting the .NET Common Intermediate Language from Standard C" (2004).

<https://drh.github.io/documents/msil-spe.pdf>

One problem with lcc has always been that it's distributed as source available with restrictions and has never been available under a FOSS license.

> You seem very angry and I clearly don't understand what you are talking about.

Luckily you managed to frame it so that the failure comes across like something that I got wrong and messed up and am responsible for, and that's the most important thing.

> Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.

Right, it's so much less onerous to have people download and set up an entirely separate fickle toolchain—and needing to trust that the install triggers in the package.json of some transitive dependency won't exfiltrate your personal data or install some nefarious ineradicable background service onto your system, versus the two extra clicks you'd have to subject yourself to if you wanted to re-run the build.*

Wait, no.

> people [are] forced to ship "Chrome-based only" features

No they're not. By your own admission they could make their build scripts work with the standardized HTML5 APIs that are well-supported in all major browsers. They choose not to.

And you're not really responding to the substance, anyway—which is that JS programmers (frequently writing for browser runtimes, even) require that you install NodeJS, Bun, or Deno (because they hardcode the build scripts internals against one of those runtime's APIs). If programmers really were writing build scripts that you could run in Chrome but unfortunately not Firefox, then even that would be an improvement over the status quo. But that's not what we're talking about, because that's not happening.

* most of which are destined to be one-shot executions, anyway

That's a start at improving something. But it won't rid itself of the Playskool/Fisher-Price gimmick factor or have any lasting effect until we can convince JS developers to write their own tools in a standards-compliant dialect and use standardized APIs so that contributors can use the runtime they already have installed instead of being cajoled and browbeaten into installing NodeJS or Bun or Deno or whatever to do what the browser runtime is perfectly capable of: opening a project directory, executing the code comprising the build script, and outputting the build artifacts when it's done.