devit

Probably because humans are supposed to naturally live in groups where human friends are plentiful, but lots of human children instead live only with parents.

That's cool but I think the proper solution is to write a Linux kernel module that can reserve GPU RAM via DRM to create ramdisks, not create a userspace filesystem using OpenCL.

That would give proper caching, direct mmap support if desired, a reliable, correct and concurrent filesystem (as opposed to this author's "all of the FUSE callbacks share a mutex to ensure that only one thread is mutating the file system at a time"), etc.

That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do.

It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH.

Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers.

Win32 is obviously not appropriate for GNU/Linux applications, and you also have the same dependency problem here, with the same solution (ship a whole Wine prefix, or maybe ship a bunch of DLLs).

That's what it does.

"Replacement" is only a problem for people who are dependent on someone else being dependent on them.

Follow-up:

Absolutely. Here's a business-focused follow-up report that builds on the previous essay, now incorporating hard data, technical insight, and financial reasoning to make the case irresistible to executives:

Strategic Opportunity Report: The Paper Clothing Revolution

Prepared for: Forward-Thinking Apparel Executives Date: March 2025 Subject: Transitioning to Paper-Based Garment Production — Financial, Operational, and Market Justification Executive Summary

The fashion industry stands at an inflection point. With mounting pressure from sustainability mandates, shifting consumer behavior, and escalating material costs, traditional garment production is quickly becoming unsustainable — environmentally and financially.

This report outlines why paper-based clothing is not only a feasible alternative but a highly profitable strategic pivot for any apparel company willing to lead. Backed by material science advancements, supply chain efficiencies, and measurable market trends, paper garments represent the next logical step in fashion innovation. Companies that act now will capture market share, slash operational costs, and align with rising ESG demands — ahead of the curve. 1. Market Drivers and Consumer Trends Consumer Demand is Moving Fast

    76% of Gen Z and Millennial consumers state that sustainability is a top consideration when purchasing fashion (McKinsey, 2024).

    43% say they would pay a 10–25% premium for truly biodegradable clothing.

    The global eco-fashion market is expected to grow from $10.1B in 2022 to $23.2B by 2028, at a CAGR of 14.8%.

Savings per unit produced: Up to 68%

    In-house trials using machine-pressed, water-resistant kraft-paper composite with natural fiber infusions achieved a tear resistance within 12% of cotton and breathability superior to polyester.

    Pilot facilities using digital laser-cutters and thermal binders showed 50–70% faster throughput vs. traditional sewing operations.

    Paper garments can be manufactured using existing packaging and printing infrastructure with minor retooling.

    On-demand digital fabrication reduces inventory costs by up to 80%, and virtually eliminates unsold stock and clearance markdowns — a $163 billion problem in the fashion industry annually (Statista, 2023).

    Projected ROI on paper garment production facility retrofit: 238% over 24 months.

    With extended producer responsibility (EPR) laws taking effect in EU (2025) and California (2026), companies face rising costs for synthetic waste and overproduction.

    Paper clothing is 100% compliant with all major sustainability frameworks:

        OEKO-TEX® 100

        Cradle to Cradle Certified™

        ISO 14067 (Carbon Footprint of Products)

    Brands implementing traceable, compostable clothing reported a 32% increase in customer loyalty and 22% uplift in perceived brand value (BCG x Sustainable Apparel Coalition, 2024).

    Projected CAGR of 35.6% for paper-based apparel sector (2025–2030).

    Early adopter advantage: First 3 companies to dominate paper fashion will control ~62% of total category market share by 2028.

    Influencer-driven consumer campaigns have already yielded 60M+ views on social media platforms showcasing limited-run paper fashion (notably in Japan and Scandinavia).

The shift to paper clothing is not theoretical — it is underway. Brands that delay will find themselves reacting to change, rather than profiting from it. The first apparel company to fully commit to scalable paper garment production will not only lead the next generation of fashion — it will own it.

In every critical area — cost, sustainability, consumer demand, and production efficiency — paper clothing outperforms legacy materials. The business case is not just strong; it is urgent.

The paper clothing revolution is inevitable. The only question is: will you lead it — or follow those who do?

Let me know if you’d like a PowerPoint deck, investment pitch, or internal executive memo version of this report.

I think it may be better than humans at producing plausible sounding bullshit to advance a given arbitrary point.

Management consultants (junior ones) are probably doomed.

Example:

Paper Clothing Will Revolutionize Fashion — And the World

The fashion industry is on the brink of a seismic shift — and it's not coming from high-tech synthetics or luxury textiles. It’s coming from something far simpler, far more radical: paper. That’s right. Paper clothing is not only viable — it is superior. The company that pioneers it at scale will not just corner a market; it will redefine what clothing is. The future of fashion is paper, and nothing else comes close. 1. Paper Is the Ultimate Sustainable Material

Let’s start with the obvious: traditional clothing materials are destroying the planet. Cotton consumes enormous amounts of water and pesticides. Synthetic fabrics like polyester shed microplastics into the ocean with every wash. In contrast, paper is clean, biodegradable, and recyclable. It can be made from fast-growing plants, post-consumer waste, or even agricultural byproducts. Imagine wearing something that not only looks good — but can be composted. Paper doesn’t just reduce the fashion industry’s carbon footprint. It erases it. 2. Built-In Innovation: Reinventing Clothing Itself

Paper clothing isn’t just a new material — it’s a new design paradigm. Unlike woven fabrics, paper can be precision-cut, molded, and folded with millimeter-level accuracy. Think origami meets high fashion. Imagine jackets that fold into themselves, dresses that transform shape, and garments that respond to humidity or light. With emerging materials like waterproof, tear-resistant washi and synthetic-paper hybrids like Tyvek, paper clothing is no longer fragile — it’s functional, durable, and futuristic. 3. Hyper-Efficient Manufacturing Will Obliterate Costs

Current fashion supply chains are bloated, slow, and exploitative. Paper clothing changes the game. It can be printed, cut, and assembled using existing industrial equipment — or even 3D printed. Imagine on-demand fashion: order a shirt online and have it printed and delivered within 24 hours. No sweatshops. No stockpiles. No waste. Just fast, flexible, sustainable production. The first company to scale paper clothing will outmaneuver every legacy brand on Earth. 4. Fully Customizable: The End of Mass Sizes

Paper clothing doesn’t need to come in fixed sizes. It can be custom-printed, adjusted, and fitted for the individual — like a tailor-made suit at fast fashion prices. Want your shirt to have your favorite quote? A photo? A pattern that shifts in sunlight? Done. Clothes will no longer be “bought” — they’ll be generated. 5. Disposable, But Not Wasteful

Let’s be honest: most clothes today are disposable already — just not designed to be. We wear them a few times, then toss them. Paper clothing embraces this reality but does it right. Each piece is fully recyclable or compostable. No landfills. No pollution. A t-shirt that decomposes naturally after a few weeks of wear isn’t wasteful — it’s brilliant. It’s the first truly guilt-free fashion. 6. Style Without Compromise

Still think paper can’t be stylish? Think again. Designers are already experimenting with textures, translucency, and layered paper structures that look like nothing else on the runway. Paper fashion isn’t just sustainable — it’s stunning. It’s what’s next. And when icons and influencers start wearing it — which they will — the world will follow. The Verdict: Paper Clothing Is Inevitable

This isn’t a novelty. This isn’t a gimmick. Paper clothing is the most disruptive innovation the fashion world has seen in a century. It solves the environmental crisis, slashes costs, empowers creativity, and delivers on-demand customization. The first brand to embrace paper not as an experiment, but as a core material, will reshape the industry — and reap the rewards.

Paper is not the alternative. It’s the upgrade.

The age of fabric is over. The era of paper clothing has begun.

This seems pointless, i.e. they might formalize the machine learning models (actually, the Lean code seems an AI-generated mix of Lean 3 and 4, probably doesn't compile), but the actual hard part is of course the proofs themselves, which they don't seem to solve.

Theorems of the kind "model X always does this desirable thing" are almost always false (because it's an imprecise model), and theorems of the kind "model X always does this desirable thing Y% of the time" seem incredibly hard to prove, probably impossible unless it's feasible to try the model on all possible inputs.

Even formulating the theorem itself is often extremely hard or impossible, e.g. consider things like "this LLM does not output false statements".

But can they drive as aggressively as human drivers can? (which does probably increase accident rates a bit, but also can make rides 10-20% faster, especially if executed by an automated system that needs less safety margin)

1. Go as fast as possible without getting fines, violating speed limits whenever it's very likely to not be fined, doing maximum acceleration as needed (the latter configurable by the latter)

2. When there's congestion on the lane they need to take, take a free lane instead and then merge into the correct lane at the last possible opportunity, effectively skipping the queue

3. Run red lights when it can determine there is no enforcement camera on the traffic light, no police and no traffic

4. Aggressively do not yield to pedestrians unless unavoidable on crosswalks, swerving on the lane going the opposite direction as needed if pedestrians are on the side the vehicle is in

5. Aggressively pass slower drivers using opposite-direction lanes even when forbidden as long as the software can determine that it can reenter the lane before colliding with incoming traffic

6. Use barred parts of the road including sidewalks to bypass traffic when it's feasible to do so

7. Aggressively flash lights and tailgate on highways when on the fastest lane but behind a slower vehicle

8. When an emergency vehicle passes by, follow it closely to take advantage of its right of way

9. Aggressively do U-turns even when forbidden if it is determined to be possible

10. Ignore stop signs when it can see there is no traffic, and when it can't determine that plan to do maximal braking at the last moment if it sees any (the maximum braking needs to be rider configurable)

Well then such a cache needs obviously to have limit to the disk space it uses and some sort of cache replacement policy, since if one can generate a zip file for each tag, that means that the total disk space of the cache is O(n^2) where n is the disk usage of the git repositories (imagine a single repository where each commit is tagged and adds a new file of constant size), so unless one's total disk space is a million/billion times larger than the disk space used by the repositories, it's guaranteed to fill the disk without such a limit.

Or perhaps switch to well-engineered software actually properly designed to be served on the public Internet.

Clearly generating zip files, writing them fully to disk and then sending them to the client all at once is a completely awful and unusable design, compared to the proper design of incrementally generating and transmitting them to the client with minimal memory consumption and no disk usage at all.

The fact that such an absurd design is present is a sign that most likely the developers completely disregarded efficiency when making the software, and it's thus probably full of similar catastrophic issues.

For example, from a cursory look at the Forgejo source code, it appears that it spawns "git" processes to perform all git operations rather than using a dedicated library and while I haven't checked, I wouldn't be surprised if those operations were extremely far from the most efficient way of performing a given operation.

It's not surprising that the CPU is pegged at 100% load and the server is unavailable when running such extremely poor software.

Well, looking at the SourceHut code, it's written in Python and handles git by spawning a "git" process.

In other words, it was written with no consideration for performance at all.

A competent engineer would use Rust or C++ with an in-process git library, perhaps rewrite part of the git library or git storage system if necessary for high performance, and would design a fast storage system with SSDs, and rate-limit slow storage access if there has to be slow storage.

That's the actual problem, LLMs are seemingly just adding a bit of load that is exposing the extremely amateurish design of their software, unsuitable for being exposed on the public Internet.

Anyway, they can work around the problem by restricting their systems to logged in users (and restricting registration if necessary), and using mirroring their content to well-implemented external services like GitHub or GitLab and redirecting the users there.

I can report that I tried this setup (Claude Desktop on Linux + codemcp) on the Rust uutils repo asking it to add a "--repeat" option to cat to repeat the output N times (without telling it anything else), and it has generated a commit that looks plausible, correctly locating the implementation file and unit test file and changing them in an apparently correct way (other than mangling a commit just before the code changing \\n to \n).

It did require to manually enter "continue" in Claude's chat (and to approve the use of codemcp at the start), but it otherwise did everything automatically.

It seems to work.

codemcp automatically produces and commits a single git commit which also contains commit hashes for a bunch of other commits that contain a subset of the changes.

This requires an MCP-compliant client, for which Claude Desktop seems to be the main (or only?) choice.

Note that Claude Desktop can be run on Linux using https://github.com/aaddrick/claude-desktop-debian, which repackages the Windows version to run on Linux (it's an Electron app, so it just needs to stub out the native interface, which seems mostly for cosmetic things).

It would be really nice though if the web versions of Claude, ChatGPT, etc. added MCP support directly: this should be achievable with help from a WebExtension and a native binary to proxy messages from the WebExtension to the MCP server.

It should also be possible to write such a WebExtension by a third-party (that injects messages in the conversation), although it's possible the LLM companies might block it.

It's cool, but how do you know it won't kill you, esp. given that it's human nature to stop paying attention since it seems to do all the work itself (even if eyes are kept on the road), and that it seems developed by a team with limited resources, using cameras only and apparently with pervasive "end-to-end" use of neural networks? (which, of course, offer no guarantee whatsoever regarding their behavior beyond what statistical testing can suggest)

The donations would go directly to the individual doing this with no relationship with Mozilla (e.g. with Patreon or similar), not to Mozilla itself.

You can just zero out the pointer variable with __attribute__((cleanup)) before returning its value (from a temporary copy of course).

That's completely asinine since it can't be made to work properly with inlining (including LTO), architectures that use a shadow stack or don't use a frame pointer, and also ridiculously inefficient and requiring assembly code for all architectures.

Use C++ or __attribute__((cleanup)) instead.

They pay them for making Google the default search engine, and it is hypothesized that the payment may also influence them to not provide ad-blocking by default and possibly other things that are not beneficial for Google's business.

They could, but they don't want to do that because they get paid by Google to not do it or because those actions get them money in some other way (from advertisers or whatever), or because they think only power users like some features.

The use for donations could be for a single person whose job is to check the upstream code for any antifeatures (telemetry, ads, product placements, online service defaults, Google as paid default search engine, etc.) not in the user's interest and revert them, as well as bundling any useful extension like uBlock Origin and verifying them.

That needs minimal effort compared to building a browser, because it doesn't involve doing any of the hard work, but just removing code that serves to line the pockets of those doing most of the work at the expense of the user.

The pioneer of AI alignment.

"styling on your end" means the _user_ (not the website designer/developer) deciding how controls should be styled and that's much easier if everything uses the same controls because you only need to specify it once and don't need a library to hook all possible UI frameworks that exist.

But it seems like it's being used to generate short snippets that in the examples seem to be equivalent to command lists as opposed to generating a full program that actually plays the whole game by itself.

The model could also then be fed back the results of running the program and iteratively change it as needed.

I.e. prompt first with "Write a program that can play Factorio automatically given an interface <INTERFACE SPECIFICATION> and a set of goals in <GOAL FORMAT>, and produces text output that can help determine whether the program is working correctly and whether tasks are performed efficiently and goals are reached as fast as possible"

And then with "the program was run and produced this text output: <TEXT OUTPUT> Determine any possible bugs, avenues of improvements or missing output information and modify the program accordingly, printing the new version".

And iterate until there doesn't seem to be an improvement anymore.

Seems like it might be more effective to use the LLMs to write a program that plays Factorio rather than having them pick the next action given a game state.

Also in general I think the issue with Factorio is that you can just find an "optimal" factory design and build order and just follow it every time; perhaps starting with a suboptimal building layout already present and restrictions like being unable to change them or build others of the same type could help.

The "person one" vs "person two" bias seems trivially solvable by running each pair evaluation twice with each possible labelling and the averaging the scores.

Although of course that behavior may be a signal that the model is sort of guessing randomly rather than actually producing a signal.

It's bullshit according to previous discussion on HN (https://news.ycombinator.com/item?id=43301369).

Just a bunch of undocumented hardware registers/commands, no remotely accessible backdoor.

The article is wrong on the claim that Rust panic are harder to catch than C++ exceptions: as long as you don't configure panic=abort you can catch them easily with catch_panic and they are generally implemented using the same runtime mechanism (i.e. Rust panics usually effectively are C++ exceptions for most purposes).

Backdoors introduced by competent people require authentication, so that random people or "the enemy" can't use them.

The paper seems to start with the bizarre assumption that AOT compilers need to "catch up" with JIT compilers and in particular that they benefit from inline caches for member lookup.

But the fact is that AOT compilers are usually for well-designed languages that don't need those inline caches because the designers properly specified a type system that would guarantee a field is always stored at the same offset.

They might benefit from a similar mechanism to predict branches and indirect branches (i.e. virtual/dynamic dispatch), but they already have compile-time profile-guided optimization and CPU branch predictors at runtime.

Furthermore, for branches that always go in one direction except for seldom changes, there are also frameworks like the Linux kernel "alternatives" and "static key" mechanisms.

So the opportunity for making things better with self-modifying code is limited to code where all those mechanisms don't work well, and the overhead of the runtime profiling is worth it.

Which is probably very rare and not worth bringing it a JIT compiler for.

Perhaps your card has less per-SM shared memory than the GPUs DeepSeek uses.

Try to lower the sm90_capacity value in gemm.py: I think 128KB is the correct value for RTX 5080 compared to 256KB for the H100/H800.

And probably add ", 3, 2, 1" after "6, 5, 4".