Also, for some reason the wifi is really buggy (disconnecting and reconnecting after ~5 minutes, not connecting at all for some APs). Maybe its me but the intel wifi chipsets are just far more reliable.
1,316 karma · joined September 8, 2017
Also, for some reason the wifi is really buggy (disconnecting and reconnecting after ~5 minutes, not connecting at all for some APs). Maybe its me but the intel wifi chipsets are just far more reliable.
> completion from language servers
That's exactly the thing that I like about idea: It's better than that.
Not sure if "The U.S governments gold reserves" also includes the ones from other countries though.
LLMs that have to constantly fix their code and look up libraries or features are much slower, more expensive and more prone to create inefficient and slightly wrong code. Sure, an LLM can just create a new web framework from scratch, but you usually don't want to spend your tokens on that.
I also think that with LLMs, new languages will have more trouble building an ecosystem, because until now, the popular libraries had a "proof of work" that kinda also made sure that they were well-trodden and maintained. Now, anyone can just push their new generated library and we have no clue on how to compare (and tbh reading LLM-generated READMEs is also not pleasant).
( /s)
To give another (bad) analogy: The Pens aren't made to be weapons themselves, they are not intended for that. If the DoD now tries to shoot pens as projectiles and they just melt, that's no reason to classify the pen manufacturer as a supply chain risk, the product was not altered after the fact.
Of course, there _is_ a difference in "It could do that, but it shouldn't" and "It cannot do that". But it is not that large. That's why I don't see it as that clear cut.
You did read the news this summer? Like https://edition.cnn.com/2026/08/03/europe/hungary-nuclear-pl... ?
Most of the environmentalists will tell you that it's dumb to shut down nuclear, but building new plants just takes too long and is too expensive. Why then not just put the money into things that are cheap now and will get even cheaper tomorrow?
Hedging against downtime is comparatively easy, just diversify by location and improve the grid, which is way less expensive than building out power plants.
regarding the "stable energy" point: germany has one of the most (if not _the_ most) stable grids in the world and that is even with 50+ % renewables. And given it sits in the center of europe with grid connections all around, it's far cheaper to buy from whomever has the most favourable weather anyways (and sell to them if they don't). Thats why one of the biggest issues right now is not nuclear, but grids.
- Unicode-as-a-character, meaning: a whole text displayed as if it were one character, made for infinite zooming
- fully-customizable emojis (think of a RPG-like character customization screen)
- heck, why not full jpegs/gifs?
- some unicode programming script (running Doom)
- ?
That said, some very minor (HN-style) nitpick:
> Otherwise for an n byte code unit this is (5n+1) / 8n, that is 5n+1 content bits out of a total of 8n bits from n bytes. We can rewrite this as (5/8) + 1/(8n) which moderately quickly approaches 5/8 = 62.5%. It is nice that this limit is nonzero and does not depend on n.
Isn't a limit by definition no longer dependent on n?
I won't defend DB too much here but saying that 64% of trains in germany are delayed more than 15min is just plain wrong. The official statistics put it at 40% for 6min or more for long distance trains and 11% for regional trains in 2025[1]. I think if there would be 15min statistics, DB would be on a sinilar level to India for long-distance. Not something to be proud of, but not as desastrous as you paint it. Though, maybe I misunderstood? Do you have sources for the indian numbers?
[1] https://eisenbahn.de/geramond-vgb/jahresbilanz-2025-puenktli...
If an american comes and says they founded a public company (with stocks and all), and complained about the fuzz involved, you would also tell them that it's their own fault, right?
That said, maybe the US/Delaware LLC has this component as well, I'm not a lawyer :D
[1] https://www.jetbrains.com/store/?section=students&billing=ye...
How? Usually I rebase the same branch multiple times onto different, but successive commits of the master branch. But after I solved a bunch of conflicts of the first rebase, I shouldn't have the same conflicts again in a second one, since the rebased branch contains the merged conflict. Rebasing again could only turn up new conflicts (with newer, other commits on the master branch).
How can I have the same conflict again for repeated rebases?