MurphyA/hacker-news huggingface dataset:
by mschuster91 | 2025-08-18 12:10:37+00:00
> Still, I think it's also a case of the same thing: sell it to the right people. Find people making new distros suffering problems with DEB and RPM and tell them your tool can save them a lot of pain.

To quote one of my favorite Clone Wars episodes: Fifty tried, fifty died [1].

There have been so, so many attempts at solving the "how to ship binary builds for Linux" question... both deb and rpm have their good and their bad, and on top of that you got `alien`, flatpak, Docker images, the sledgehammer aka shipping everything as a fully static binary (e.g. UT2004 did this) or outright banning prebuilt binaries (the Gentoo and buildroot way). But that's not the actual problem that needs solving.

The actual problem is dependency hell. You might be lucky to be able to transplant a Debian deb into an Ubuntu installation and vice versa, or a SLES rpm to RHEL, but only if the host-side shared libraries that the package depends on are compatible enough on a binary level with what the package expects.

That suddenly drives up the complexity requirements for shipping software even for a single Linux distribution massively. In contrast to Windows, where Microsoft still invests significant financial resources into API-side backwards compatibility, this is not a thing in any Linux distribution. Even if you're focusing just on Debian and Ubuntu, you have to compile your software at least four different times (one each for Debian Stable, Debian Testing, Ubuntu <current rolling release> and Ubuntu <current LTS>), simply because of different versions of dependencies. Oh and in the worst case you might need different codepaths to account for API changes between these different dependency versions.

And even if you had some sort of DSL that generated the respective package manager control files to build packages for the most common combinations of package manager, distributions and actively supported releases of these, there's so, so much work involved in setting up and maintaining the repositories. Add in actually submitting your packages to upstream (which is only possible for reasonably-ish open source packages in the first place), and the process becomes even more of a nightmare.

And that's all before digging into the topics of autotools, vendoring (hello nodejs/php/python ecosystems), digital signature keyrings, desktop manager ecosystems and god knows what else. Oh, and distribution bureaucracy is even more of a nightmare... because you now have to deal with quirks in other people's software too, and in the worst case with a time span of many years of your own releases plus the distribution release cadence!

Shipping software that's not fully OSS on Linux sucks, shipping closed source software for Linux sucks even more. Windows has had that sort of developer experience figured out from day one. Even if you didn't want to pirate or pay up for InstallShield, it was and is trivial to just write an executable, compile it and it will run everywhere.

[1] https://starwars.fandom.com/wiki/Mystery_of_a_Thousand_Moons
by perrygeo | 2025-08-18 12:10:56+00:00
> tdd from the integration side and only add unit tests later

This is where I've landed as well. Unit tests are for locking down the interface, preventing regressions, and solidifying the contract - none of which are appropriate for early stages of feature development. Integration tests are almost always closer to the actual business requirements and can prove direct value - ie only once the integration works, then lock it down with unit tests.

I've also toyed with a more radical idea: don't check your tests into the git repo. Or at least keep the developer tests separate from the automated tests. Think about it: what rule says that the tests used in development should go directly into the CI test suite? One is designed to help you navigate the creative process, the other is designed to prevent regressions. I think we do a disservice by conflating the two scenarios into one "testing" umbrella. During TDD, I need far more flexibility to redefine the shape of the tests (maybe it requires manual setup or expert judgement or ...) and I don't want to be hampered by a (necessarily) rigid CI system. Dev tests vs CI serve two completely different purposes.
by tygra | 2025-08-18 12:11:26+00:00
No, I'm not talking about serious medical issues. I mean uploading your blood test results and asking an AI, "Give me specific nutrition, lifestyle, and supplementation recommendations."

For work, as an employee, sure, it's easy to say the company approved ChatGPT or Gemini, so you can go ahead and upload, for example, usage data to get a retention analysis. But what if you're the employer?
by avereveard | 2025-08-18 12:11:28+00:00
Think a LLM driving a Browser, where it fills field, click things, and in general where losing the state loses the work done so far

That's the C in the protocol.

Sure you can add a session key to the swagger api and expose it that way so that llm can continue their conversation, but it's going to be a fragile integration at best.

A MCP tied to the conversation state abstract all that away, for better or worse.
by pjmlp | 2025-08-18 12:11:52+00:00
Not really, because they are not Automated Reference Counting, rather manual with explicit clone operations, in some scenarios.

Also contrary to systems where reference counting is part of the type system, and not library types, they aren't able to optimize counts away.

When this happens is as side effect of the compiler optimizing away inlined code, but not by pairing inc() with dec() operations that never leave scope.
by mike_hearn | 2025-08-18 12:12:03+00:00
Did capital make the big difference? Apple didn't take huge VC rounds back then and lasted much longer.

I think it was just relative lack of apps in the end. Microsoft commodified the hardware so it became competitive and prices fell dramatically. Every other company stayed attached to their integrated designs and couldn't keep up on cost. Apple held on for a while because of the bigger US ecosystem and economy but nearly got wiped out also.

Also the RiscOS wasn't really backwards compatible with BBC apps and games, iirc. More like a clean-sheet design.
Show HN: Twick SDK – an open-source React video editing toolkit
by anujkanojia29 | 2025-08-18 12:12:44+00:00
We just launched Twick SDK, an open-source toolkit to help developers build pro-grade video editing tools in React.

Features: timeline editor, animations, effects, rich elements (video, audio, text, shapes), and WYSIWYG canvas editing.

Docs: https://ncounterspecialist.github.io/twick/docs/intro

Demo: https://www.youtube.com/watch?v=EizgeoxwJsk

Would love to hear your feedback & feature ideas! If you find it useful, a star on GitHub would mean a lot
by noirscape | 2025-08-18 12:13:37+00:00
I had issues with similar things for a couple years too. The reality is that there's remarkably little existing advice for maintaining a soft fork that doesn't intent to upstream patches. (For reference, probably the most notable patch fork that can't/doesn't upstream anything, GNU IceCat, uses a bash file from hell to apply all of it's changes to the Firefox source code - it is not a scalable solution.)

Ultimately the solution I ended up using was git rebase; it just works the nicest out of all of them:

* Your patches are always kept on top at the git log.

* It's absolutely trivial to drop an unnecessary patch, add a new one in the chain or to merge two patches that do the same thing. (Use git rebase -i for that.) Fixing typos in patches is trivial too.

* Your history isn't so important for a patch fork; the patches are what matters, so don't fret too much about commit hashes changing. I promise you, it'll be fine.

* Git will complain if you try to do a rebase that doesn't work out of the box, using similar tools as resolving merge conflicts. You can instantly do a git pull from another upstream that rebases with git pull --rebase upstream/master . This does assume you've added the upstream as a second origin to git under the name upstream and that they push the code you want to patch onto the master branch.

As for drawbacks, I only wound up with two:

* CI tools and git server UIs often aren't prepared to handle a heavily rebased master branch - it leads to lots of builds that are linked to dangling commit hashes. GitHub also for some reason insists on displaying the date of the last rebase, rather than the date of when the patch was committed. Not sure why.

* Pushing your fork means heavy use of force pushes, which feels instinctively wrong.

The drawback isn't large enough for me to mind it in practice.

Opted to use rebase for this sort of fork after reading a bit about non-merge related git flows and wondering what'd happen if I did a rebase-based workflow but just... never send any patches. Turns out it works really well.
by throwup238 | 2025-08-18 12:16:32+00:00
That’s a thought terminating cliche. Academia doesn’t care about commercialization, they care about grants and they don’t much care which organization it comes from. You can argue why they don’t make it to market as FDA regulated medicines but not why there’s no positive evidence for their efficacy.

> Telling that person apart from the sea of charlatans complicates things a bit.

Peer review (for all its faults) and clinical trials that inform evidence based medicine. That’s how you tell them apart.
by elcritch | 2025-08-18 12:18:11+00:00
Unfortunately the LSP hasn’t improved that much. There’s been some work on to kill errant processes and such. So it’s a bit more stable. It does work pretty well when it works though. But I just kill it now.

Unfortunately it may not be until Nim 3 based on the Nimony rewrite comes out. It supports incremental compiling and caching which will make the underlying LSP tooling much better.

However I find with Cursor that I don’t mind so much the missing autocomplete. I’ve actually thought about writing an alternative LSP just for quick find and error inlining…
by ehnto | 2025-08-18 12:18:27+00:00
If you're running one of the popular coding agents, they can run commands in bash which is more or less access to the infinite space of tooling I myself use to do my job.

I even use it to troubleshoot issues with my linux laptop that in the past I would totally have done myself, but can't be bothered. Which led to the most relatable AI moment I have encountered: "This is frustrating" - Claude Code thought, after 6 tries in a row to get my bluetooth headset working.
by dielll | 2025-08-18 12:18:30+00:00
Had 1 on 1's with my manager for a whole year and everytime they told me how I was doing such a great job as compared to others in the team. There was no zero bad feedback. At the end of the year we had the yearly review and they praised me. However on the review document they placed me on PIP. It was such a shock because why tell me everyday how I am doing such a great job only to put me on PIP? Raised the issue with the skip and he admitted the reason they did that was because HR forced them, claiming not everyone can do well, someone must be on Pip, so they settled on me.

These days our 1 on 1's barely last 5 minutes, it's like we do it as a formality. She is even afraid of talking to me and the worst bit is that I cannot change teams because of the PIP. Plus it's a bad job market. never been this dammned
by rhirji | 2025-08-18 12:19:39+00:00
People ask me for an AI strategy all the time, sometimes in the oddest of moment. They want a quick answer. Sorry to tell you this, but there isn’t one. To do it properly, you have to get under the skin of a business, its workflows, data, incentives, and culture. Without that, all you’ve got is doing AI things for show.
by dvfjsdhgfv | 2025-08-18 12:19:43+00:00
Frankly, I'm surprised this is the only issue you bring up (I had many, when I first tried Nim several years ago - I think they were related to cross-platform GUI libraries for Nim, or the lack of them, or their awful state back then).

But LSP as a major concern? For me these little helpers are useful to catch small typos but I could happily do without them.
by endergen | 2025-08-18 12:19:48+00:00
I for one, like the fun you had on the page. Ignore the haters. Only critique would be you should just explain how it works near the top. I think most devs myself included want to first understand what it is before the why it’s awesome.

ps. Way back there was a project called tiddlywiki that was a self modifying html file and was pretty popular. I think initially there was no way to save new version but to basically save the file to disk to either fork a file or replace itself.
by serf | 2025-08-18 12:21:00+00:00
it's placed into a flap that is cut into corneal tissue.

the flap size itself keeps the lens in place; the elasticity of the underlying tissue itself, until it heals into an encapsulation.

the surgery videos of that procedure make me squeamish unlike other surgery videos. Watching an eyeball get deflated/inflated with liquid pressure from the surgeon is just un-nerving to me; not as bad as watching a glaucoma surgery -- but up there.
by graynk | 2025-08-18 12:21:02+00:00
I am very confused.

> Everything (and I mean it) from that news report went through yours truly.

> Bob is a quality researcher

> The headlines implying this was a massive breach are misleading

But the headlines implying it are literally in the cybernews article, which is the source of it all? Why does the article talks about "the mass media" throughout the length of it, if it's the original source that was misleading?
by softwaredoug | 2025-08-18 12:21:19+00:00
Sadly structurally the system favors housing incumbents. And it doesn’t take a lot to derail efforts to create more supply.

In my town we spent 8 years of public involvement in rezoning to increase supply and density. Including several city council elections of pro-housing council members elected over more NIMBY ones.

Only to have it all screwed up by 2-3 households that sued, pausing the zoning and throwing a wrench into a lot of new housing construction.

I feel like there has to be an effort at all layers of government to solve this structural problem where a few homes can derail a democratic process.
by palata | 2025-08-18 12:21:30+00:00
Writing code was never the issue. Writing good code was. By "good", I mean that it is understandable by the human that will need to debug/maintain/extend it.

AIs on their own don't produce good code. If your AI makes you more productive on your way to write good code (just like syntax highlighting or other tools already do), then why not (ignoring the carbon footprint of course).

But if you're in the business of writing good code, AIs are not replacing you right now.
by puredanger | 2025-08-18 12:22:09+00:00
Rich Hickey actually did a talk called "Language of the System" https://www.youtube.com/watch?v=ROor6_NGIWU way back in 2013 before core.async was even created that lays out a lot of the ideas. It even has a big section explicitly about "flow" which contains the germs of core.async.flow.
by aurareturn | 2025-08-18 12:24:28+00:00
It’s very interesting. Based on this theory, stock prices should decrease as interest rates lower.

A massive number of people who are waiting for interest rates to drop will sell their equities to buy a house when it happens. IE, many couples are waiting for lower interest rates before buying a house.

This runs counter to current equities markets where hints of rate drops from the Fed will increase stock price.

It’s definitely an interesting theory.
by 999900000999 | 2025-08-18 12:24:38+00:00
Why not build your own ?

Run OBS. Use python to build a nice real time transcription app. Add the subtitles to OBS, send the OBS feed over an existing video app.

Otherwise there's just no other way for you to get what you want here, the big players like Google aren't really going to play nice with the great firewall.
by PhilippGille | 2025-08-18 12:24:55+00:00
Given the security issues that come with MCP [1], I think it's a bad idea to call MCP a "guardrail/sandbox".

Also, there are MCP servers that allow running any command in your terminal, including apt install / brew install etc.

[1] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
by kingstnap | 2025-08-18 12:25:27+00:00
ChatGPT tried tbh.

It urged her to reach out and seek help. It tried to be reassuring and convince her to live. Her daughter lied to ChatGPT that she was talking to others.

If a human was in this situation and forced to use the same interface to talk with that woman I doubt they would do better.

What we ask of these LLMS is apparrently nothing short of them being god machines. And I'm sure there are cases where they do actually save the lives of people who are in a crisis.
by MrJohz | 2025-08-18 12:25:28+00:00
For Go, they have a statistic from a few years back that suggests about 98% of a cross section of real-world Go projects are formatted according to gofmt. (https://jmoiron.net/blog/fmty-dmpty) I can believe Rustfmt and other tools not having quite the same reach, but I would guess that the proportion is still pretty high.

These tools are very standard and very widely used.

> Don't you want to see neatly formatted code while you're writing it?

Every time I pause, I press ctrl-S or an equivalent. So I really am seeing neatly formatted code while I'm writing it. I would guess that 90% of the time, if my code is syntactically valid, it's also neatly formatted. And even if it's not valid code, it's probably very close to being neatly formatted.
by yunohn | 2025-08-18 12:25:51+00:00
I mean, this whole Forex fee horse has been beaten to death by crypto evangelists for the past decade, and yet, it seems “unsolvable”?

Wise used to be almost completely free (excl spread), but they also introduced small % based fees over 1-2 yrs ago. They have had and continue to have many competitors, all of whom are experimenting with pricing models all the time.

If crypto could solve this, or if a trad-fi competitor could disrupt this, they would have. But that is not a very satisfying story, so here we are…
by TimLeland | 2025-08-18 12:26:02+00:00
Looks neat — just a heads up, be prepared for malicious users to find the service and immediately start using it for harmful redirects. I ran into this pretty early on when I launched T.LY, so it’s something worth thinking about from the start.

I ended up building an entire service to detect these URLs as soon as possible, protecting the service. Happy to give you some tips, just reach out.
by puredanger | 2025-08-18 12:26:13+00:00
Flow is intended for processes with long-running stable topologies. Rich has been thinking about options to "patch" the running topology but it is quite tricky due to the concurrency issues and I'm not sure that will ever be added.

Even though the flow topology is fixed, it's perfectly acceptable for a flow component to use other variable resources and act merely as a coordinator. So you could for example have a process that send data out to an external dynamic thread pool and gets callbacks via a channel.
by globular-toast | 2025-08-18 12:26:33+00:00
> My wife and I have been holding Treasury bills for the past few years waiting for mortgage rates or home prices to come down, but neither have.

I wonder how long people remain in such states. I feel like for something as big as house ownership you need to decide if you really want it and if you do just go for it. How much of your life are you prepared to spend on "getting ahead"? They say "life is what happens to you while you're making other plans".
by flail | 2025-08-18 12:28:21+00:00
One thing relying on coding agents does is it changes the nature of the work from typing-heavy (unless you count prompting) to code-review-heavy.

Cognitively, these are fairly distinct tasks. When creating code, we imagine architecture, tech solutions, specific ways of implementing, etc., pre-task. When reviewing code, we're given all these.

Sure, some of that thinking would go into prompting, but not to such a detail as when coding.

What follows is that it's easier to make a vulnerability pass through. More so, given that we're potentially exposed to more of them. After all, no one coding manually would consciously add vulnerability to their code base. Ultimately, all such cases are by omission.

A compromised coding agent would try that. So, we have to change the lenses from "vulnerability by omission only" to "all sorts of malicious active changes" too.

An entirely separate discussion is who reviews the code and what security knowledge they have. It's easy to dismiss the concern once a developer has been dealing with security for years. But these are not the only developers who use coding agents.
by Gazoche | 2025-08-18 12:28:51+00:00
Yeah that's also true, to a degree. Clearly, there are interesting challenges that I would have never been faced with had I stayed at a startup.

But I also found that once you reach a certain level of expertise at $BIGCORP there are few opportunities to try to push the boundaries of your domain knowledge, lest you are dead-set on taking initiatives and swim against the current of a rigid organisation. That may just be specific to my job and employer though.

And while the part about navigating internal complexity is true as well, it's harder to highlight on a CV than "I have worked with technologies X, Y and Z". At best you can say "I have worked with X at a big corp, and also Y, which you probably don't know because it's an internal tool." You just have to hope that the name of your employer alone carries enough weight on its own.
by stanleydrew | 2025-08-18 12:29:51+00:00
Technically it's not really much different from just giving the LLM an OpenAPI spec.

The actual thing that's different is that an OpenAPI spec is meant to be an exhaustive list of every endpoint and every parameter you could ever use. Whereas an MCP server, as a proxy to an API, tends to offer a curated set of tools and might even compose multiple API calls into a single tool.
by chuckmcp | 2025-08-18 12:30:00+00:00
Even with all of the CLI tools at its disposal (e.g. sed), it doesn’t consistently use them to make updates as it could (e.g. widespread text replacement). Once in a blue moon, an LLM will choose some tool and use it in a way that they almost never do in a really smart way to handle a problem. Most of the time it seems optimized for using too many individual things, probably both for safety and because it makes the AI companies more money.
by raxxorraxor | 2025-08-18 12:30:55+00:00
Public ownership can be extremely detrimental, I think it is even worse than state ownership by a few margins. Especially for setting long term goals required for infrastructure. There are investors for that as well, but they are rare and an exception.

I evade working directly for publicly traded companies like hell or let myself be paid very, very generously. Most often your time will be limited in the first place. Better to be employed as a freelancer in that case.