MurphyA/hacker-news huggingface dataset:
by sebk | 2025-09-25 13:45:45+00:00
I agree with this. One way to keep changes small but still compose them into a coherent PR is to make each commit in the final PR independently meaningful, rather than what actually transpired during local development. TFA touches on this somewhat, contradicting the bit you quoted.

A trivial example would be adding the core logic and associated tests in the first commit, and all the remaining scaffolding and ceremony in subsequent commits. I find this technique especially useful when an otherwise additive change requires refactoring of existing code, since the things I expect will be reviewed in each and the expertise it takes are often very different.

I don't mind squashing the branch before merging after the PR has been approved. The individual commits are only meaningful in the context of the review, but the PR is the unit that I care about preserving in git history.
by snapplebobapple | 2025-09-25 13:45:46+00:00
As has been said already those can fail nuclear disaster style so I have no interest in having those back. Give me an ethernet port and a wifi interface (ideally supporting at least wifi 6 but ideally wifi 7 so it's not polluting the airwaves causing interference. It should also be able to be disabled if I want to use ethernet only) that has a locked down web interface exposed on one port with some standardized interface (is rest still what all the cool kids are using?) that exposes all the machine functions and lets me configure access credentials. The apps are spyware garbage that I'm sure are fine for some people but with local polling I can integrate this stuff into my home assistant setup and do all I would ever want with it and block the machine's external access. All these commodity manufacturers of household goods are trying to lock us into their software walled gardens to rip us off more/sell our information to advertisers and governments and that needs to be aggressively stopped imo.
by shiandow | 2025-09-25 13:46:57+00:00
If you want to avoid the double root you could also solve for sin(2t). The derivative of the arcsin is simpler if anything.

You may need some special handeling for sin(2t)=1 still. You could pretend the funtion continues there (just join it together with asin(z - 1) + z - 1 + pi/2). Or maybe some other transformation.
by AfterHIA | 2025-09-25 13:47:10+00:00
The feeling of, "being able to breathe again" that this creates is a boon to my failing health. I'm seeing movements in this direction alongside, "HTML-only" as a better realization/utilization of the internet. We might not ever get the Vannevar Bush-Ted Nelson lost super internet some speculate about but I'm glad we can at least get to, "something workable." Cheers speckx!
by FuriouslyAdrift | 2025-09-25 13:47:19+00:00
I was the 'owner' of record. The others held rights to the house by agreement with me but all the responsibilities were mine.

The others could have just stopped paying 'rent' and I would be stuck with the full mortgage...or I could have just sold the place and walked away with everything.

Definitely an exercise in trust and mutual self interest.
by mft_ | 2025-09-25 13:47:31+00:00
For example, the last big company I worked for had invested in building out its campus with multiple new flagship bespoke buildings, including during (and not reconsidered due to) the pandemic. It would be quite difficult and/or a loss of corporate face to sell/lease them out.

I'm not saying it's rational, but that doesn't mean it's not sometimes an influential factor.
by snowwrestler | 2025-09-25 13:47:31+00:00
Overall national wealth and power shrink under monopoly super corporations, that is the reason it is a matter of public policy in the first place. If you go back and review the major antitrust actions of the 20th century, each one was followed by an explosion of market-creating innovation: Standard Oil, Bell Telephone, even Microsoft. Look even further back, and many national economies were organized around a few state-sponsored monopolies e.g. the East India Company. They all lost ground to economies with more numerous and competitive companies, most notably the U.S.
by hmokiguess | 2025-09-25 13:47:36+00:00
The roadmap on the other hand seems to have 4 things tagged AI on it. https://zed.dev/roadmap

The blog used to be really personal and nice but now it's all AI https://zed.dev/blog

I get it, pausing some work to ship AI integration plumbing is a good strategy to keep momentum up with competition.

I think after their Series B, looking at the roadmap, and now with this pricing featured it's pretty clear what their priorities have become.

I'm not against AI, I just feel like they can do better and their original mission is still a better long-term angle.
by BenoitEssiambre | 2025-09-25 13:47:39+00:00
To add to this. There's fundamental theoretical reasons why microservices or bad. They increase the entropy of code (https://benoitessiambre.com/entropy.html) by increasing globally scoped dependencies. They are the global variables or architecture. Having lots of interconnected global variables makes for an unpredictable chaotic system.
by philipallstar | 2025-09-25 13:47:47+00:00
> it's really sad that scientists need to justify their funding to the public

The (mostly American) public pays their salaries; it's not that odd. The public elect the government (mostly the US government) that distributes the funds. The US voter in general has just got tired of living in the "worst place in the world" while also funding the majority of the world's science and health breakthroughs, I think.
by rkomorn | 2025-09-25 13:49:21+00:00
At the risk of sounding like a cave dweller even though I'm out and about my capital city every day... I think a lot of people are staying home. Understandably so.

They're exhausted from work, commutes, everything costing more money, being advertised/pitched/upsold to at every chance, crypto bros, noise, constant calls to their attention, being the target or witness of unsavory interactions, etc.

There are a bunch of reasons to hate it "outside", in increasing numbers, with at best no increase in reasons to enjoy it.
by nathan_compton | 2025-09-25 13:49:28+00:00
Ok, people say this, but is it really true?

My personal experience, the boring sexual harassment training, and talking to the AI, suggests that asking out a coworker at the same level of the org chart with whom you don't closely work is not considered really problematic, especially among young people.

You can't ask out someone you supervise and its considered a little socially risky to get involved with someone who you work with really closely, but nothing seems to prevent coworkers from asking each-other out, as far as I can tell.
by 2THFairy | 2025-09-25 13:49:59+00:00
So, obviously, ads were the norm back in the day. The author had to be wearing several rose tinted glasses when writing that.

But the author isn't entirely wrong. There were/are a lot of websites that simply did not run ads. Hosted not for money, but "for love of the game".

This is something that was lost with the shift to exclusively platform-based hosting. A facebook page or subreddit simply is never going to be ad-free in the way that a lot of former or legacy forums were and are.
by lordkrandel | 2025-09-25 13:50:08+00:00
Hello, in Odoo, we use stdnum, but a valid CLI tool is nice. Looks like you have descriptions in German in your code, which are kinda unintellegible to me ^^''

https://github.com/odoo/odoo/blob/f6548acabd93dcb5c2dcd9ec54...
by vault_ | 2025-09-25 13:50:18+00:00
> - A big queue of PR's for reviewers to review

This is a feature. I would infinitely prefer 12 PRs that each take 5 minutes to review than 1 PR that takes an hour. Finding a few 5-15 minute chunks of time to make progress on the queue is much easier than finding an uninterrupted hour where it can be my primary focus.

> - The of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)

It increases it a little bit, sure, but it also helps keep things focused. Reviewing, for example, a refactor plus a new feature enabled by that refactor in a single PR typically results in worse reviews of either part. And good tooling also helps. This style of code review needs PRs tied together in some way to keep track of the series. If I'm reading a PR and think "why are they doing it like this" I can always peek a couple PRs ahead and get an answer.

> - You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you

This is a tooling problem. Git and Github are especially bad in this regard. Something like Graphite, Jujutsu, Sapling, git-branchless, or any VCS that supports stacks makes this essentially a non-issue.
by krapp | 2025-09-25 13:50:56+00:00
Bear in mind that the goal of Pascal's wager was to convert people to Christianity. That the wager implicitly assumes the Abrahamic God is the only one that can possibly exist is intentional.

This kind of "dishonest psychological judo" is common to Christian apologists to this day. If you've ever been in a conversation with someone trying to convert you, it becomes obvious that they're just trying to find the one crazy logic trick or rhetorical flourish that will flip you.
Ask HN: Accepted on Zenodo, but passed elsewhere — similar experiences?
by mzk_pi | 2025-09-25 13:51:38+00:00
We tried submitting our math-based contribution protocol paper to multiple preprint repositories. So far, it seems that only Zenodo is willing to host it.

Has anyone else run into something similar — where Zenodo accepts but SSRN (or other repositories) do not?

For reference, the full text is openly available here: https://doi.org/10.5281/zenodo.16923643
Show HN: Lingo – A linguistic database in Rust with nanosecond-level performance
by peerlesscasual | 2025-09-25 13:52:00+00:00
Hi HN, I made Lingo - the SQLite of semantic search.

I'm a self-taught developer and researcher who left school at 16, and I've spent some time exploring a first-principles approach to system design for various frontier problems. In this case it's AI that challenges the 'bigger is better' transformer paradigm.

Lingo is the first piece of that research, a high-performance linguistic database designed to run on-device.

The full technical overview and manifesto is here: https://medium.com/@robm.antunes/bcd1e9752af6

The paper has been archived on Zenodo with a DOI: https://doi.org/10.5281/zenodo.17196613

The code is open-source and can be found at https://github.com/RobAntunes/lingodb, it's currently broken and feature incomplete but I'm working on it - just wanted to start getting some feedback.

All benchmarks are reproducible from the repo and can also be found in the various texts.

As an independent without academic affiliation, I'd be incredibly grateful for your feedback! I'm here to answer any questions.

Cheers!
by CodingJeebus | 2025-09-25 13:52:11+00:00
The big difference with Google monetizing in the 90’s is that they owned their platform, which gave them control to build out a search and ad network that scaled.

Perplexity uses frontier models under the hood, it doesn’t own all core aspects of its platform. They’re extremely dependent on frontier models and therefore reliant on underlying model pricing remaining sustainable.
by 101008 | 2025-09-25 13:52:19+00:00
I did something similar a few months, launched it on HN, no traction. It's really difficult. No one wants to host their blog / posts on a platform that will dissapear when the owner gets bored or can't maintain it anymore.

Added this to other comments: old web had ads (iframes, banners, popups!), and also was completely self-hosted, which gave you more freedom than any other cloud platform. If you want to resurect old web, just give a free hosting with FTP.
by NetOpWibby | 2025-09-25 13:52:24+00:00
Okay, so we need Old Web with extra steps (security).

I’ll admit that when I lament the web we used to have, I’m never thinking about viruses, malware, pop ups/unders, &c. Seems like all that stuff was just a small price to pay for connecting with likeminded people.

I have a slice of that with Mastodon but maybe being 20 years older and jaded is making me wistful, yearning for something that is never coming back.
by reaperducer | 2025-09-25 13:52:38+00:00
Not the entire planet and every greedy spyware.

I don't mind the entire planet of human beings seeing my blog, but I don't want what I write to be monetized by grifters and trillion-dollar companies.

For that reason, my personal blog is behind security so only invited people can see it.

It works very well, but no, I'm not going to explain how it works because there are plenty of people on HN who have no morals, work for crappy companies, or are part of the trillion-dollar machines that are destroying human creativity so some C-level can buy a third private island.
by fidotron | 2025-09-25 13:52:39+00:00
So you want code added in 100 line sections behind one feature flag which we then suddenly turn on?

Isn't that exactly how Google's latest big cloud outage happened?

EDIT: referring to https://news.ycombinator.com/item?id=44274563

I should add that the idea complexity relates to LoC is also nonsense. Everyone that's been doing this for a while knows that what kills people are those one line errors which make assumptions about the values they are handling due to the surrounding code.
by danielfalbo | 2025-09-25 13:53:20+00:00
Jane Street implements an awesome code review system: https://janestreet.com/tech-talks/janestreet-code-review

> [...] Telling a Story with Commits [...]

> [...] it should take the average reviewer 5-10 minutes [...]

Jane Street code review system kinda solves this problem by

- making each commit a branch,

- stacking branches on top of each other (gracefully handling rebases and everything that comes with it), and

- reviewing one iteration at a time

So one reviews single commits independently (takes probably around 5mins), and "forces" the reviewer to re-live the story that led to the bigger diff.

I do not work at Jane Street but I frequently find myself pondering on how broken the common code review system/culture is. I've heard of tools like graphite.dev that build on top of git to provide a code review system similar to the Jane Street one, but I'm not an active user yet (I just manually stack PRs, keep them small and ask for review to one at a time to my colleagues, and handle the rebasing etc. manually myself for now).
by Esophagus4 | 2025-09-25 13:53:38+00:00
As a management, I understand that this is the perception… but it’s not remotely true. It astounds me how often this is repeated. It’s almost more of a conspiracy theory at this point. “Those evil incompetent managers are just so stupid they have to justify their existence by having people in office.”

RTO is not about watching people in their seats all day to see who is productive. It’s about getting talented people to sit next to each other, as there is significant benefit to that. It builds culture and internal networks (which helps attrition rates, especially for junior employees) and that helps junior employees learn from senior employees. They need that hands-on feedback from seniors, minute to minute. It helps people across teams work together, as in remote land, most communication is intra team only.

It’s not about input->output. It’s about building a long term company culture and employees who grow with it. It’s about building a system where communication and collaboration have less friction.

Can this be done remotely? Maybe, by a few companies who are very intentional and do it well. But remote is very difficult to do well.

If it were just about input->output, I’d offshore everything and save a ton of money.
by crabique | 2025-09-25 13:53:44+00:00
Yeah unfortunately mirrors is no go due to efficiency requirements, but luckily read performance is not that important if I manage to completely offload FS/S3 metadata and small files to flash storage (separate zpool for Garage metadata, separate special VDEV for metadata/small files).

I think I'm going to go with 8x RAIDz2 VDEVs 10x HDDs each, so that the 20 drives in the internal drive enclosure could be 2 separate VDEVs and not mix with the 60 in the external enclosure.
by gjsman-1000 | 2025-09-25 13:53:49+00:00
I think the "old web" is also heavily nostalgia-infested, it wasn't nearly as good as most people here remember.

Blatantly false information? Internet Explorer required for everything? Adobe Flash and Java all over the place? Websites that frequently actually could hack your computer? Geocities and AOL being the meeting places, reincarnated as Discord? Terribly slow, low-resolution imagery that our brains filled in the details for? The worst font and font color choices known to man? Shock content being absolutely rampant? Constant pop-ups? Every company wanting a toolbar?

That's what I remember. It's the same phenomenon where people think their Nintendo 64 or PlayStation 2 was a masterpiece never paralleled, revisit it in 2025, and realize: "wow... this... sucks actually." It's the same phenomenon where people think cars were better in the 80s, but they sit in an 80s car, and realize we've come a long, long way.
by vilunov | 2025-09-25 13:53:52+00:00
> I wonder if this will wind up being a category of problems and the solution is a separate "system" set of effects (effectively `({user}, {system})`) or if this one-off extension is all that will be needed.

It already is, kinda. In my practice very often you have global singleton values that are either defined as static variables, or passed as arguments to nearly all functions in a module. Since implicit presence of `Debug` effect is already a compilation parameter, it could be generalized to support any sets of implicit effects. Thus you might design a module that has implicit Logger and Database effects in all its functions.
by dole | 2025-09-25 13:54:01+00:00
Enter a N or n into the Editing box, you'll see the two grids that make the glyph up along with a blank third grid on the bottom, add a small tilde in the top two rows. Or copy and paste the actual Ñ or ñ characters into the Editing box to create it new, and you can use it immediately with the alphabet textbox on the left.
by FuriouslyAdrift | 2025-09-25 13:54:20+00:00
SNMP v3 at least has some security in mind, but a lot of devices are just v1 or v2c which are basically unsecured. Allowing ANY write access via SNMP is a bad idea in my opinion, unless you segment it out into it's own secured management or out-of-band network. Even then... I'd be worried.

Network infrastructure security has a lot of unsolved gotchas and not a lot of industry desire to fix. Most of what everyone interacts with is in an abstracted or virtualized layer on top of the old plumbing.
by hluska | 2025-09-25 13:55:19+00:00
People get fired doing this. If you’re in a position where you can be fired maybe that’s okay. But you have no way of knowing what your team is getting next. They can all be next out the door if you play this hand wrong.

The writer did a very poor job of explaining how to do this. I question how much experience they have writing. But actual diplomacy is necessary in systems like this.
by computronus | 2025-09-25 13:55:55+00:00
I do agree with the common refrain, actually, and disagree with the idea that work can be so big and complex that it has to be in one pull request.

> A big queue of PR's for reviewers to review

Yes, yes please. When each one is small and understandable, reviewers better understand the changes, so quality goes up. Also, when priorities change and the team has to work on something else, they can stop in the middle, and at least some of the benefits from the changes have been merged.

The PR train doesn't need to be dumped out in one go. It can come one at a time, each one with context around why it's there and where it fits into the grander plan.

> The [totality] of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)

A primary goal of code review is to build up the mental map of the feature in the reviewers' brains. I argue it's better for that to be constructed over time, piece by piece. The immediate cognitive load for each pull request is lower, and over time, the brain makes the connections to understand the bigger picture.

They'll rarely achieve the same understanding of the feature that you have, you who created and built it. This is whether they get the whole shebang at once or piecemeal. That's OK, though. Review is about reducing risk, not eliminating it.

> You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you

I've learned not to charge too far ahead with feature work, because it does get harder to manage the farther you venture from the trunk. You will get conflicts. Saving up all the changes into one big hunk doesn't fix that.

A big benefit of trunk-based development, though, is that you're frequently merging back into the mainline, so all these problems shrink down. The way to do that is with lots of small changes.

One last thing: It is definitely more work, for you as the author, to split up a large set of changes into reviewable pieces. It is absolutely worth it, though. You get better quality reviews; you buy the ability to deprioritize at any time and come back later; most importantly for me, you grasp more about what you made during the effort. If you struggle to break up a big set of changes into pieces that others can understand, there's a good chance it has deeper problems, and you'll want to work those out before presenting them to your coworkers.
by raw_anon_1111 | 2025-09-25 13:56:38+00:00
You realize that you’re kind of making my point? Even with your rosy projections, you’re still going to be making much less than a few returning interns I know made in their first three years working at BigTech.

Heck you’re making less than a run of the mill enterprise dev is making in a second tier major city in Atlanta

And as a founder, you still need to do well to do better off than a BigTech employee and statistically you won’t come near.

And on top of that, you’re sounding like every startup that doesn’t realize that they can’t linearly project growth based on past performance. The first cohorts are almost always easier than later cohorts unless it is a platform with network effects.
by perihelions | 2025-09-25 13:56:50+00:00
The thing 'rebelgecko is alluding to is specific, and fascinating! The coolant in these space reactors is a molten metal (low-melting point sodium-potassium eutectic). When they leaked in the space vacuum, the liquid dispersed into a large number of small, metal spherules, which formed rings around Earth. Because the spherules are metallic and smooth, they're (comparatively) easy to track by radar, from Earth.

https://ntrs.nasa.gov/api/citations/20190033494/downloads/20... (pdf) ("The NaK Population: a 2019 Status")
by hedora | 2025-09-25 13:57:26+00:00
What is your definition of “viable”? Plenty of people own iPhones, which is locked down to webkit.

Similarly, firefox is fine. I switch between it chromium and safari for dev work, and (unless you go out of your way to find a counterexample) they’re completely interchangeable in terms of compatibility and real-world performance.

Firefox runs fine on android, so there’s not even a platform where chrome is the only choice (other than chromebooks).
by eszed | 2025-09-25 13:57:43+00:00
There are examples of these in the London Science Museum. I strongly recommend a visit - and not just for those: there's also a (working) full-scale replica of Babbage's difference engine; the entire early history of steam engines (the genuine articles); a duplicating lathe, from the early 19th century; models of the entire history of the (British, at least) tractor; an entire analogue telephone exchange; and way, way, way more. It's a geek's delight. One of my favorite museums ever, but be warned: it took me more than a week's worth of visits to feel like I'd seen it thoroughly.