HN user

foresterre

391 karma
Posts13
Comments64
View on HN

I don't think the article tries to argue against the good sides.

In my opinion it asks us to not just look at individual gain of using LLM's (which can be powerful), but also place it in context how we as humans built long-term sustainable societies. Most societies are currently ignoring that part for the most part, because they fear missing out.

Probably the hardest problem of LLM's is their ethics. As the author put it:

Modern multi-billion parameter AI models are scaffolded on and made possible by the largest heist in human history: theft of everything that could be scraped from every corner of the digital spaces we share. Without prevention of and justice for this damage caused by current models, their use is highly fraught, ethically. We, as human beings, have developed complex social forms of intelligence when it comes to dealing with things like credit and provenance, two things that modern models are incapable of.

No one currently seems to have serious solution for this. Solving it the right way would be choosing the hard path. While some artists or writers are fighting for their rights, us programmers are collectively ignoring the issue. It is funny how most companies (and some individuals) only want to use LLM's of they don't train on their code. But is just fine to use some 40 years of collective open-source without any compensation or even acknowledgement.

This side of the story doesn't make LLM's less technically impressive, nor does it make the tools themselves less powerful. But unlike the industrial revolution, which some like to compare the AI boom to, during the industrial revolution humans built stronger productivity solely on innovation without strip mining all intellectual property in human existence.

I can see the benefits of LLM's, enjoy the technical capabilities and be impressed by the technology, and at the same time find these tools wholly unethical in their current form.

In addition, there's about 2x year a 25% sale and you have a year to activate the passes.

The in southern Europe (e.g. France, Spain, Italy), required seat reservation is most common and most expensive.

I don't mind requiring seat reservations, but that it is separate from the ticket price and significant (eg 15€/seat reservation in Italy), feels like price gouging. It also feels different from say the optional (and way lower priced seat reservations in German ICE's (high speed rail)). I rather pay for a "high speed rail supplement" instead of seat reservation haha :).

I interrailed last year through Germany, Austria, Slovenia, Italy and Switzerland.

In Germany I was lucky, I only had a small delay on the way back.

Austria was exceptional in everything. On time, modern trains and facilities. I guess the food on the train was expensive and bland, but I've never seen a train where that's different.

Slovenia was the weirdest and had the most delays. Train cars for which I had seat reservations consistently didn't exist or arrive. They use old stock, but that also made it kind of fun and there were great views. I couldn't rely on the time table though.

Italy has lots of high speed rail, but required (paid) seat reservations. The problem is that for almost any medium-long distance there's no slower speed alternative. The normal speed stock is fine (can be taken to go to smaller cities) and was generally on time.

Trains in Switzerland are exceptional too. Funnily enough, I did have fairly significant delays 2/5 times.

As a general rule, you always include the currency code (EUR, SEK, USD etc.) and if possible also the amount of decimals, when using minor units.

Currency codes can be found in ISO 4217.

What's a problem though is that while it includes a reference, its distillation from the source, or worse, from the combination of sources, is often plain wrong. I check them regularly, and it made me very distrustful of Claude's capacity to faithfully summarise or explain from a source.

When asked to give specific links, it's usually even worse.

stdx is a monorepo of, as of today, 64 crates

It's quite an, ahem, interesting mix of libraries, including three csv libraries, hyper_utils (but not hyper itself), and a ton of copied crates from other maintainers.

I hope the author has a good way of updating these with upstream fixes (some look out-of-date already), otherwise you may replace one security issue with another.

And the name stdx has been taken on crates.io, more than 11 years ago which can also be equally confusing.

This and PEP-783 do remind me a bit of the story of watt (1) and serde_derive, where the latter was published containing a to WebAssembly compiled proc macro with the former as WebAssembly runtime (2).

It tried amonst others to improve isolation and long compile times in a fairly foundational Rust library which can be found in many dependency trees. I found it a cool proof of concept at the time.

Having a WebAssembly binary embedded in a library was relatively unpopular in the Rust community (3). serde_derive 1.0.184 restored the uncompiled source version, but the release notes mention they hope that crates.io (Rust equivalent of PyPi) will add WebAssembly support in the future.

One of the reasons why this wasn't very popular was that WebAssembly is much harder to inspect than Rust source code (4).

I'm not a PyPi expert. The PEP itself seems to permit adding WebAssembly to a wheel (a python package). The PEP literally mentions "There are no security implications in this PEP" (security for whom?). In 2022 the supply chain attack surface was notably smaller since powerful enough LLM's didn't exist yet, yet it was for many a concern to include WebAssembly to package s in another ecosystem back then.

I do think other forms of binaries were already permitted, such as precompiled C/C++ libraries, so if that's true, then this is indeed relatively not that big of a security concern, but _no_ security implications seems to be a bit much.

I do see the added advantage to reduce friction of loading pre-compiled webassembly from PyPi directly instead of going through alternative packaging registries though.

(1) https://crates.io/crates/watt

(2) https://github.com/serde-rs/serde/commit/1afae183b06ffe47d05...

(3) https://github.com/serde-rs/serde/issues/2538

(4) https://old.reddit.com/r/rust/comments/15wx2xe/precompiled_b...

(5) https://peps.python.org/pep-0783/

Their strategy always was "buy company" and "instantly lay off about everyone" to save costs and rapidly increase subscription pricing (1).

So far they've been relatively soft (for their doing) on Komoot, which I too am most anxious off.

Bikepacking.com has a good read about Komoot; it was probably unsustainable in the long run before bending spoons took over anyways (2), yet I much rather had they stayed a sort of indie company driven by their passion. I will cancel my long standing Komoot subscription the day enshittification news breaks.

(1) https://www.dcrainmaker.com/2025/03/komoot-acquired-history-... (2) https://bikepacking.com/plog/when-we-get-komooted/

MAI-Thinking-1 2 months ago

Almost all licenses have requirements to redistribute copies of the work, or derivatives thereof. Even permissive licenses do. It's very little to ask when open source dev's provided thousands of hours of free work.

For example, the Apache 2.0 license requires in just 4.c:

  You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works;
Just because they're tokenized and transformed into a probabilistic mapping, doesn't suddenly mean that they weren't copied.

I find it morally unethical that they (likely) just ingest IP of all open source repo's without asking, but also importantly without any attribution.

Let me also note that I'm not against LLM's in general. But I do think training on open source must be opt-in, and I look forward to a world with actually ethical, and traceable (i.e. on what they were trained on, like a bill of materials (BOM)), models.

I've used Fastmail for years but a year ago switched to Proton. For me the only reason to switch to Proton was that its hosted within the European continent, while Fastmail is hosted in

I would say that Fastmail is the "Ferrari of e-mail" services. It does everything well, or extremely well, especially if you have more advanced setups like wildcard domains.

In particularly, I miss being able to send from wildcard domains. While proton has a thing called simplelogin, it only works kind of seamlessly if you get an e-mail on a wildcard address and want to reply to that same address. Sending from any * domain requires you to make the address via the simplelogin page and isn't nearly as seamless. While you can make some sending addresses (i.e. regular aliases) in the protonmail interface, that's a trap, because once you've made an alias, you can't delete it unless there's no mail related to it in your mailbox anymore (even if you have a catch-all setup; I wonder if it has anything to do with how the encryption keys are setup, but it still sucks).

I also miss both snoozing and pinning mail. Officially, the proton mail apps (1) do support snoozing, but that requires "conversation view" to be enabled. I think the conversation view over groups e-mails too aggressively, and don't really understand why snoozing without conversation view isn't possible. It's utterly annoying. As far as I know, pinning e-mails isn't a thing in the proton apps. There are "stars" but these could have been labels (which also exist). They don't pin the e-mail to the top.

The proton mobile apps also lack various settings which are in the web interface, like access to sieves. The apps are sometimes a bit laggy, especially if you have a lot of e-mails, although there seem to have been some improvement on this end. I also still get double "fingerprint to unlock" requests sometimes.

Then there's theming, which I can imagine is (even) more of an opinion, but I liked the Fastmail interface more than the proton interface. I think its cleaner. Not a particular fan of any of the themes of protonmail.

I left Fastmail just as it added offline access. This was originally my biggest gripe. I might have stayed longer if they added it just before I left.

For Proton, they have been releasing a lot of new services lately. I hope they will spend a year or more, just polishing what they currently have. They did say they will spend some time on polish in a blogpost recently, but haven't really seen the fruits from this yet (or I care about different things than they do?). And I hope I will one day be able to add more domains to my account. Even with Visionary, you only get 6 domains for 6 users, and no way to add more.

I sincerely hope Proton will never add any of the AI nagging , the OP was talking about. If they do, I'll leave the instant.

(1) https://proton.me/support/snooze-emails

MAI-Thinking-1 2 months ago

I would really like to see what "appropriately licensed data" means. Cannot imagine they didn't copy all open repo's on GitHub, and can't imagine they asked for permission, or are reproducing license texts from these repo's now. It sounds hand wavy.

P.S. A fairly basic website otherwise, but it unfortunately seems to be hacking scroll for no good reason.

I've played both Factorio and Bitburner extensively (both >1000h, but that's unfair wrt bitburner, because you let it run in the background sometimes), but I don't find they compare that well. Factorio can be played without any optimization and completely mechanically if you wanted (i.e. no "programming" of circuits). It's visual style also makes interfacing with the game more like most games you encounter.

In bitburner, you literally have sort of editor (or terminal), which is also the world (you can use an external editor though). The whole game is about programming your way to destroy a BitNode.

I guess they're comparable because they are both about optimization of bottlenecks. In my experience though, having played Factorio for hundreds of hours with software engineer friends, BitBurner with its text only interface is far more niche, and only the thought of playing it reminds some of them of work (so they don't try) ;).

The first link states literally

"AI will take over almost all the work of software engineers (SWEs) end - to - end in just 6 - 12 months!"

What you describe is >50% of the job of SWEs, even when they write all code by hand.

Are you saying that "for many start-ups", this isn't done by SWE's but by some other career type or are you implying that it's just the code written (and first review) is replaced by AI?

And if you like Lisp and ownership, there's also Carp [1]. It doesn't mimic Rust's features and naming schemes though.

Carp is about 10 years old and has some cool demo's (like SDL for gamedev).

The key features of Carp are the following:

* Automatic and deterministic memory management (no garbage collector or VM)

* Inferred static types for great speed and reliability

* Ownership tracking enables a functional programming style while still using mutation of cache-friendly data structures under the hood

* No hidden performance penalties – allocation and copying are explicit * Straightforward integration with existing C code

* Lisp macros, compile time scripting and a helpful REPL

[1] https://github.com/carp-lang/Carp

There are other reasons why a project like Zig might not want to accept LLM generated contributions.

Zig, as programming language, has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will, as it's a fundamental building block of everything that uses Zig. Just that could be worth the extra scrutiny on every individual commit.

There's also the usual arguments: copyright ethics, environmental ethics and maintainer burden.

The Try trait (representing the ? the operation) is super cool though! I wish it was marked stable so you could implement it for types without using the nightly compiler.

Note that both Option and Result implement that same trait.

Perhaps if try blocks ever become a thing... we can finally use it for our own types ;)

https://doc.rust-lang.org/std/ops/trait.Try.html

Finally! Glad they will now offer something which doesn't have a bending frame.

... but I wish they would make something with a bit more screen estate without being heavy and bulky. Their 16" is just too big. I really like the Dell XPS 14 and MBP 14", which I think is the right trade-off between screen size and portability.

With the advent of AI, these "life" events are probably even simpler to fake than AI though, and unlike the faking of stars not against the ToS.

According to the Financial Times (1), the straight is "open" but Iran is extorting fees for passing ships.

"Iran will demand that shipping companies pay tolls in cryptocurrency for oil tankers passing through the Strait of Hormuz, as it seeks to retain control over passage through the key waterway during the two-week ceasefire."

If they really will start doing so for all shipping, that would be odd since the straight itself is in Oman's territorial waters. Even so, the UNCLOS convention (2) requires free transit:

Article 44 Duties of States bordering straits States bordering straits shall not hamper transit passage and shall give appropriate publicity to any danger to navigation or overflight within or over the strait of which they have knowledge. There shall be no suspension of transit passage.

It would be unprecedented and unlawful, but I guess previous actions of Israel, the US and Iran have shown our world is beyond adhering to laws and agreements now.

(1) https://www.ft.com/content/02aefac4-ea62-48db-9326-c0da373b1... (2) United Nations Convention on Law of the Sea: https://www.un.org/depts/los/convention_agreements/texts/unc...

Cursor 3 4 months ago

I am a developer by profession and this is the opposite of what I would want. The code is your ground truth. If all else fails, the code should reasonably be able to tell you why, and by being able to read it, it makes me independent from some closed model.

I think opt-outs are a bit backwards, ethically speaking. Instead of asking for permission, they take unless you tell them to no longer do it from now on.

I can imagine their models have been trained on a lot of websites before opt outs became a thing, and the models will probably incorporate that for forever.

But at least for websites there's an opt-out, even if only for the big AI companies. Open source code never even got that option ;).

Apple Business 4 months ago

This is annoying, but that they use user-agent solely to check irritates me even more; even (alternative) Chromium based browser like Vivaldi don't work out of the box. I usually use Vivaldi as an alternative when Firefox doesn't work.

It's 2026. I think we can expect more from Apple. It's not a small indie company after all.

Depending on your needs (i.e. how you would otherwise use your output jspn), using the reviver can have a significant impact on performance. JSON.parse itself is hyper-optimized. At the company I work we used the reviver for almost exactly this, but profiling showed that using the reviver had enormous impact on performance. We cut it out, and won in the seconds of performance for some large json's.

That's a rather unkind comment.

For the parent there's immaterial value knowing that is written by a human. From what I read in your comment, you see code more as a means to an end. I think I understand where the parent is coming from. Writing code myself, and accomplishing what I set out to build sometimes feels like a form of art, and knowing that I build it, gives me a sense of accomplishment. And gives me energy. Writing code solely as a means to an end, or letting it be generated by some model, doesn't give that same energy.

This thinking has nothing to do with not caring about being a good teammate or the business. I've no idea why you put that on the same pile.

I think that DDG's search resulrs worsened from the moment they've dropped the Yandex index, a few years back.

That, and they seem to havr focussed more on localized results, which makes searches related to software development worse. This is also a problem with Google's search engine, but it's much harder to work around on Google.