LegionMammal978 (u/LegionMammal978)

LegionMammal978 commented on AI tooling must be disclosed for contributions github.com/ghostty-org/gh... · Posted by u/freetonik

raggi · 4 days ago

reddit is a user hostile company, have been forever, always will be. they take rights over your content, farm things about you, sell data, do invasive things in the mobile apps, use creepware cookies, etc.

Excerpt from the user agreement:

    When Your Content is created with or submitted to the Services, you grant us a worldwide, royalty-free, perpetual, irrevocable, non-exclusive, transferable, and sublicensable license to use, copy, modify, adapt, prepare derivative works of, distribute, store, perform, and display Your Content and any name, username, voice, or likeness provided in connection with Your Content in all media formats and channels now known or later developed anywhere in the world. This license includes the right for us to make Your Content available for syndication, broadcast, distribution, or publication by other companies, organizations, or individuals who partner with Reddit. For example, this license includes the right to use Your Content to train AI and machine learning models, as further described in our Public Content Policy. You also agree that we may remove metadata associated with Your Content, and you irrevocably waive any claims and assertions of moral rights or attribution with respect to Your Content.

People put their heads in the sand over reddit for some reason, but it's worse than FAANG.

LegionMammal978 · 4 days ago

  With respect to the content or other materials you upload through the Site or share with other users or recipients (collectively, “User Content”), you represent and warrant that you own all right, title and interest in and to such User Content, including, without limitation, all copyrights and rights of publicity contained therein. With respect to the content or other materials you upload through the Site or share with other users or recipients (collectively, “User Content”), you represent and warrant that you own all right, title and interest in and to such User Content, including, without limitation, all copyrights and rights of publicity contained therein. By uploading any User Content you hereby grant and will grant Y Combinator and its affiliated companies a nonexclusive, worldwide, royalty free, fully paid up, transferable, sublicensable, perpetual, irrevocable license to copy, display, upload, perform, distribute, store, modify and otherwise use your User Content for any Y Combinator-related purpose in any form, medium or technology now known or later developed.

LegionMammal978 commented on Why Be Reactive? crank.js.org/blog/why-be-... · Posted by u/bikeshaving

LegionMammal978 · 5 days ago

That for-loop design is a really interesting way of achieving "executional transparency", which is a good name for something I've found lacking in many reactive frameworks. Trying to work with Svelte, I was annoyed by how much magic was going on behind the scenes, and how it would attempt to automagically dice up code between the client and server, only to end up in arcane errors that were painful just to understand. I've found React a fair bit better on that front, in that component code will always run exactly as written (the main question being when it is run), but it doesn't have the greatest story w.r.t. expensive derived state that you may want to compute lazily, which ends up in useEffect() and careful dependency tracking.

In contrast, this design lets you know precisely what is recomputed on each refresh, even if it comes at the cost of explicitness. Any and all timing errors will be present in the code as written.

LegionMammal978 commented on Project to formalise a proof of Fermat’s Last Theorem in the Lean theorem prover imperialcollegelondon.git... · Posted by u/ljlolel

kevinventullo · 5 days ago

I contend it is the only way to move forward on the goal of “automating” mathematics. Although we’ve seen natural language approaches do well at IMO, the human effort required to verify higher level proofs is too great with hallucinations being what they are. With something like Lean, you don’t need a human verifier.

LegionMammal978 · 5 days ago

> With something like Lean, you don't need a human verifier.

Human verification can never be ruled out entirely with these sorts of systems: you always have to check that the definitions used in the final statement mean what you think they mean, and that all of the base axioms are acceptable.

And of course, there's always the possibility of bugs in the kernel. I even recently found a bug [0] in a verifier for Metamath, which is designed to be so simple that its only built-in logic is typed string substitution. But such bugs should hopefully be unlikely in non-adversarial settings.

[0] https://github.com/metamath/metamath-exe/issues/184

LegionMammal978 commented on "Remove mentions of XSLT from the html spec" github.com/whatwg/html/pu... · Posted by u/troupo

MrJohz · 6 days ago

Wasn't this whole discussion sparked by a fairly significant bug in the libxslt implementation? There's also a comment from a Chrome developer somewhere in this thread talking about regularly trying to fix things in libxslt, and how difficult that was because of how the library is structured.

So it is currently a persistent time sync, and rewriting it so that it can sit inside the browser sandbox will probably add a significant amount of work in its own right. If that's work that nobody wants to do, then it's difficult to see what your solution actually is.

LegionMammal978 · 6 days ago

The current problem is that bugs in libxslt can have big security implications, so putting it or an equivalent XSLT 1.0 processor in a safe sandbox would make active maintenance far less urgent, since the worst-case scenario would just be presentation issues.

As for immediate work, some in this thread have proposed compiling libxslt to WASM and using that, which sounds perfectly viable to me, if inefficient. WASM toolchains have progressed far enough that very few changes are needed to a C/C++ codebase to get it to compile and run properly, so all that's left is to set up the entry points.

(And if there really were no one-for-one replacement short of a massive labor effort, then current XSLT users would be left with no simple alternative at all, which would make this decision all the worse.)

LegionMammal978 commented on "Remove mentions of XSLT from the html spec" github.com/whatwg/html/pu... · Posted by u/troupo

troupo · 6 days ago

> their desire to minimize attack surface trumps any tendency to leave well enough alone.

It's that why Chrome unilaterally releases 1000+ web APIs a year, many of them quite complex, and spanning a huge range of things to go wrong (including access to USB, serial devices etc.)? To reduce the attack surface?

LegionMammal978 · 6 days ago

Well, their desire to stay trendy trumps their desire to minimize attack surface, I'd have to imagine. Alas, XML is roughly the polar opposite of trendy, mostly seen as belonging in the trash heap of the 90s alongside SOAP, CORBA, DCOM, Java applets, etc.

LegionMammal978 commented on "Remove mentions of XSLT from the html spec" github.com/whatwg/html/pu... · Posted by u/troupo

em-bee · 7 days ago

instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395

LegionMammal978 · 6 days ago

That's only if the original document is an XHTML document that will have scripts loaded. Other XML documents, such as RSS feeds, will not have any support for JS, short of something silly like putting it in an iframe.

LegionMammal978 commented on "Remove mentions of XSLT from the html spec" github.com/whatwg/html/pu... · Posted by u/troupo

chocmake · 7 days ago

CSS animations still lack a semantic way to sequence animations based on the beginning/end of some other animation, which SMIL offers. With SMIL you can say 'when this animation ID begins/ends only then trigger this other animation', including time offsets from that point.

Which is miles better than having to having to use calcs for CSS animation timing which requires a kludge of CSS variables/etc to keep track of when something begins/ends time-wise, if wanting to avoid requiring Javascript. And some years ago Firefox IIRC didn't even support time-based calcs.

When Chromium announced the intent to deprecate SMIL a decade back (before relenting) it was far too early to consider that given CSS at that time lacked much of what SMIL allowed for (including motion along a path and SVG attribute value animations, which saw CSS support later). It also set off a chain of articles and never-again updated notes warning about SMIL, which just added to confusion. I remember even an LLM mistakenly believing SMIL was still deprecated in Chromium.

LegionMammal978 · 7 days ago

> if wanting to avoid requiring Javascript.

And there's one of the issues: browser devs are perfectly happy if user JS can be used to replicate some piece of functionality, since then it's not their problem.

LegionMammal978 commented on "Remove mentions of XSLT from the html spec" github.com/whatwg/html/pu... · Posted by u/troupo

MrJohz · 7 days ago

Sure, but this requires someone sitting down and writing the JS polyfill, and then maintaining it indefinitely. And for something as complicated as XSLT, that will surely be indefinite maintenance, because complicated specs beget complicated implementations.

In the absence of anyone raring to do that, removal seems the more sensible option.

LegionMammal978 · 7 days ago

> Sure, but this requires [...] maintaining it indefinitely.

Does it, though? Browsers already have existing XSLT stacks, which have somehow gotten by practically unmodified for the last 20 years. The basic XSLT 1.0 functionality never changes, and the links between the XSLT code and the rest of the codebase rarely change, so I find it hard to believe that slapping it into a sandbox would suddenly turn it into a persistent time sink.

LegionMammal978 commented on "Remove mentions of XSLT from the html spec" github.com/whatwg/html/pu... · Posted by u/troupo

kstrauser · 7 days ago

> I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.

I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it.

I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it.

Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing <marquee> back in the day, but that happened to be a great idea.

LegionMammal978 · 7 days ago

True, a small number of vocal opponents does not automatically make something a bad idea. But in these cases of compatibility, especially with something as big as the Web, the vast majority of those affected who do care will be completely silent. There's no hotline to call up the entire world and tell them to update their code.

(And if you did want to tell the entire world to update their code, and have any chance of them following through with it, you'd better make sure there's an immediate replacement ready. Log4Shell would probably still be a huge issue today if it couldn't be fixed in place by swapping out jar files.)

LegionMammal978 commented on "Remove mentions of XSLT from the html spec" github.com/whatwg/html/pu... · Posted by u/troupo

intrasight · 7 days ago

It is a balance (compatibility vs attach surfaces). The issue with XSLT (which I am still a strong advocate for) is that nobody is maintaining that code. So vulnerabilities sit there undetected. Like the relatively recent discovery of the xsl:document vulnerability.

LegionMammal978 · 7 days ago

> It is a balance (compatibility vs attach surfaces).

What I'm trying to say is that it's a false dichotomy in most cases: implementations could almost eliminate the attack surface while maintaining the same functionality, and without devoting any more ongoing effort. Such as, for instance, JS polyfills, or WASM blobs, which could be subjected to the usual security boundaries no matter how bug-ridden and ill-maintained they are internally.

But removing the functionality is often seen as the more expedient option, and so that's what gets picked.