codethief

That makes sense! I wasn't aware of min_version for some reason, thanks so much!

> Bonus points for it running fine on Linux, too.

I haven't really been able to use outlook.office.com in anything but Edge, which on my Windows machine automatically authenticates with M365. In other browsers I regularly get stuck in an auth redirect loop between different Microsoft domains when I open the site. Sometimes it helps to clear all cookies and re-login (which is a real pain with 2FA and all) but it only ever helps once: If I close and re-open the site, I'll have to do it again.

How people voluntarily pay for this crap is beyond me. (In my case it's forced upon me by my client. On my own machines I switched to Linux in 2010 and never looked back.)

For anyone not familiar with the reference: https://m.youtube.com/watch?v=BzAdXyPYKQo

> I wanna hang out with coders who care, I wanna read articles about caring and how you can achieve more with less code

This very much reminds me of an expression coined by Loris Cro (VP of Community at Zig Foundation): "Create software you can love".

Looks like it's even got a website these days: https://softwareyoucan.love/

Ha, I came here to share this! :)

Thanks so much for your work on mise! I used to be a heavy asdf user but nowadays I'm an even heavier mise user!

Random question while you're here: mise is undergoing pretty heavy development these days and I recently noticed that 1) my coworkers and I are not always on the same version, so some features/bug fixes are not available to everyone, and 2) package registries often don't have the latest mise version.

So I think we need a meta tool manager here to manage the tool manager version. :) Seriously, though, have you considered having mise manage its own version? I think that'd be pretty neat!

Thinking aloud, I guess one way to do this might be to distribute through package registries only a lightweight bootstrap application, which 1) reads the pinned mise version from mise.toml and downloads it as necessary, and 2) sets up a basic shell hook that the active mise version can then hook into(?) I know, this probably sounds a lot easier than it actually is.

Does anyone know who the authors of the study are and what the data basis was (how many people were interviewed, age brackets, etc.)?

Good point. Maybe there'll be companies that maintain your on-premise GPU cluster just like there are companies that service the coffee machine in your office?

> AI is different.

I agree. The other thing here is that, once you can run LLMs on a single piece of commodity hardware (whether that includes one GPU or several), the difference between cloud vs. on-premise LLMs will largely be about where your hardware is located. There will be very little software configuration involved (just an HTTP endpoint that talks to the GPU). This is decidedly different from cloud products where the moat of hyperscalers is largely in the software and services on top of the hardware, not the hardware itself. (Sure, GPUs will eventually break & need replacement, too, but there's no state to lose, so that's already orders of magnitude easier than replacing hard drives.)

What toothbrush do you have? I've been looking for a USB-C charger for mine (standard Oral-B toothbrush) but the only ones I've found were from no-name Chinese brands and didn't work at all.

> Meanwhile, some projects are doing the opposite, like going from Rust to Zig, here's an example from a podcast I recently listened to: https://www.youtube.com/watch?v=XSXGf3oN2yU

Thanks for the link! Unfortunately, contrary to what the title suggests, that video seems to be more about AI than about the migration? (Sigh…) I did, however, find the following document where they explain why they migrated to Zig. It makes for a nice read: https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...

That's all good and well but the UX sucks. I usually have dozens of commands like

  git commit -m "PROJECT-XXXX Foo the bar to baz the qux"

in my shell history, which means 1) I can easily create follow-up commits under the same ticket number (no having to type the ticket number again), 2) I don't have to keep remembering the ticket number once I created the first commit on the given ticket. I'm sure I could set up an elaborate set of shell scripts and git aliases to auto-insert a ticket number as structured data at the bottom of each of my commits. But good luck convincing the rest of your team to do that.

Also, having the ticket number in the subject line means every git-related tool I use will always display it (even if the rest of the message gets cut off).

> Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.

I agree that this is a problem but at the same time associating commits with a ticket number is useful, especially if I have dozens of commits on a single ticket and am doing trunk-based development (so not all commits are on the same short-lived branch). Maybe the lesson here is that, once completed, tickets should be exported and stored in the Git repository.

Do we know what the situation looks like with other popular indices such as MSCI World, MSCI ACWI, MSCI ACWI IMI, FTSE All-World, …? Do they have any requirement of 12 months of trading or of profitability or similar?

> to settle bar bets

As I learned just yesterday, this is exactly how the Guinness World Records books came about. :)

https://en.wikipedia.org/wiki/Guinness_World_Records

> Why would documents have menus? Menus are for applications.

s/menu/navigation

> And there was nothing wrong with tables for layout, especially back then when the alternatives were very brittle.

I never said there was anything wrong with tables. OP said there was nothing preventing the design from being responsive, to which I responded yes, there was, at least in a lot of cases.

(Responsiveness was also mostly irrelevant back then because smartphones were not a thing yet.)

Right but how would you even display a vertical menu back then? `float: left` was rather bad, so you went back to using tables[0]. Good luck making these responsive.

[0]: and to using dozens of images sliced to fit your table cells, for that cool hover effect as well as round corners. :-)

I had the pleasure to talk to Loris about this topic just last week and I've liked his take very much.

His point is not coming from a place of LLM demonization. He very much acknowledges their usefulness, especially in a business context, e.g. for implementing yet another standard CRUD application and for shipping all the other "average" (in quality) business features quickly.

His point is a different one entirely: Say Andrew Kelley is attending the Zig Day. Why would you ask an LLM about a Zig programming problem you're struggling with instead of learning from the man himself? There's simply no LLM as knowledgeable about Zig as Andrew and the other people working on it or with it on the daily.

In other words: Zig Days are an opportunity for people to learn from each other and to spend time together (= the "Community" in "VP of Community"), and LLM are diminishing this opportunity.

Besides, Zig itself is mainly a language for people who care not just that a problem is solved but also about how it's being solved. ("Create software you can love.") While LLMs don't prevent anyone from doing so, they make it much more appealing to just vibe-code everything and not look too closely at the implementation.

> What's needed is a global "Hide AI Dreck".

As a German, I couldn't think of a more appropriate usage of the word "Dreck".

Interesting talk, thanks for sharing!

> they want to move the permission management from Flatpak into the service layer, through a new service called systemd-appd. Systemd-appd gives applications an identifier and stores their permissions, and then this data can be queried by the rest of the system. In turn, this enables a slew of other features, not least of which is subsandboxing.

This is fantastic news! As I've argued here on HN many times over the years, proper permission management is probably the single most important piece that's been keeping us from sandboxing everything by default, like on Android and iOS.

> it's important to use Better display to upscale the output to the XReals to high DPI

I got excited for a second but then read Better Display[0] is only available for MacOS? :(

[0]: https://betterdisplay.pro/

Fellow Xreal One Pro owner here. I agree 100%. The One Pros do make for a fantastic travel accessory but when it comes to coding (or reading text in general) for longer periods of time, my eyes usually start hurting after 2-3 hours because text is not 100% sharp and there's a slight blurriness / Moiré effect. (Which is a real bummer because, posture-wise, wearing the glasses puts a lot less strain on my neck than looking at a screen.)

That being said, there have been quite a few reports on Reddit lately from people that do use the glasses for coding all day every day. At the same time, my impression is that there have been fewer complaints about text blurriness than right after the One Pro got released. So I've started suspecting that Xreal might have fixed something about the hardware in recent batches. This is all very anecdotal, though. Maybe the hardware is the same and it's just my eyes.

Either way, I'm excited about future models with higher resolution. As many other people here in the thread said: This is definitely the future.

> But so is lower Manhattan, Miami, 60% of the land in the Netherlands, almost all of Bangladesh, along with numerous other places.

From page 1 of the paper: "Coastal Louisiana has been referred to as 'canary in the coal mine' with respect to climate impacts. As highlighted in the Sixth Assessment Report of the Intergovernmental Panel on Climate Change (IPCC), the central US Gulf Coast is the single most exposed LECZ (low-elevation coastal zone) in the world in terms of projected relative sea-level (RSL) rise throughout this century."

> Notably it does not predict this

Again from page 1 of the paper: "The initial impetus consists of new evidence that RSL in this region is probably committed to 3-7m of future rise, with a shoreline bound to migrate as much as 100km inland. We argue that future RSL rise to this elevation – judging from field evidence rather than climate model output – is, in fact, a best-case scenario."

> Here in Japan, some remote islands, you can travel overnight boat.

I'm sure there are many overnight ferries all over the world and I can't say I have traveled with many, but one I can recommend is the overnight ferry from Ziguinchor/Senegal to Dakar – it's reasonably priced (for a foreigner), and the cabins are very comfortable and even include a shower!

Meanwhile, the 3-day ferry from Puerto Montt (central Chile) to Puerto Natales (Patagonia) is very expensive (> 500 USD per person for the most basic cabin) and very unreliable (expect last-minute cancelations).

I agree 100%. At work I'm teaching software engineering principles to system administrators and they, too, often use AI without thinking. Then it's on me to provide feedback on the PRs they barely read themselves. Not a lot of fun but slowly but surely they're learning.

> The worst part is, even when "prompted" by bad coders, it works in the end. Even has tests (ostensibly mock-ridden, a pet peeve of mine which always falls on deaf ears). So I cannot reject the PR without being an asshole.

Yes, you absolutely can. And you should. Try to teach them lessons and what patterns to watch out for, then tell them to put those insights in their CLAUDE.md, so that their agent becomes better, too. You can also tell them to just copy your own CLAUDE.md, like I did: https://github.com/codethief/ENGINEERING_PRINCIPLES.md

Stay strong!

What does the designer say?

No, you just need to scope your styles appropriately. See also my other comment: https://news.ycombinator.com/item?id=48161902

> both in software engineering and in physis

I meant physics of course!

You're misunderstanding me. I never said you should build a framework. I said frontend frameworks already provide style locality out of the box, so there is no need to introduce an additional framework (Tailwind) for that.

> Personally, I'd rather deal with a localized class soup than trying to make sense of overlapping, often contradictory, cascades of styles across multiple files.

That seems like a false dichotomy. I'm a huge fan of locality (both in software engineering and in physis) but you can also "localize" your styles by scoping them appropriately. (Modern frontend frameworks typically do that automatically for you at the component level.) There is no need to use Tailwind for that.