MurphyA/hacker-news huggingface dataset:
by locknitpicker | 2026-01-19 07:20:49+00:00
> So I would standby for this tragedy to be used for political purposes

This is an ignorant opinion. For multiple reasons.

Derailing under these circumstances is a track issue, which means ADIF, the state's infrastructure maintainer, is under suspicion. Not operators, the state's infrastructure maintainer.

Liberalization of the railway sector is an EU-wide mandate. It's not some whimsical slip of a single country's leadership.

Years ago there was an AVE derailment in Santiago de Compostela. No one banned RENFE from the lines.
by paradite | 2026-01-19 07:21:14+00:00
If you want to pedantic:

Context is also a misnomer, where in fact it's just a part of prompt.

Prompt itself is also a misnomer, where in fact it's just part of model input.

Model input is also a misnomer, in fact it's just first input token + prefill for model output to generate more output.

Harness is also a misnomer, where it's just scaffold / tools around the model input/output.
by gregsadetsky | 2026-01-19 07:21:43+00:00
Great work, thanks for sharing and congrats on the launch!

Very very small note - many clickable things on your site (the "explore" and "new task" buttons, the directory and blog links at the top, etc.) don't change the cursor to the css "cursor:pointer" (ie the clicky hand)

You might want to add `cursor-pointer` to your tailwind <button> elements
by trimethylpurine | 2026-01-19 07:22:49+00:00
That doesn't appear to be what happened. But the marketing sure has a lot of people working quick to presume so.

I would guess it's only a matter of days before that proof, or one very similar, is found in the training data, if that hasn't happened already, just as has been the case every time.

No fundamental change in how the LLM functions has been made that would lead us to expect otherwise.

Similar "discoveries" occurred all the time with the dawn of the internet connecting the dots on a lot of existing knowledge. Many people found that someone had already solved many problems they were working on. We used to be able to search the web, if you can believe that.

The LLMs are bringing that back in a different way. It's functional internet search with an uncanny language model, that sadly obfuscates the underlying data while making guesswork to summarize it (which makes it harder to tell which of its findings are valuable, and which are not).

It's useful for some things, but that's not remotely what intelligence is. It doesn't literally understand.
by willtemperley | 2026-01-19 07:22:57+00:00
That's a good point. Hadoop may not be the most efficient way, but when a deliverable is required, Hadoop is a known quantity and really works.

I did some interesting work ten years ago, building pipelines to create global raster images of the entire Open Street Map road network [1]. I was able to process the planet in 25 minutes on a $50k cluster.

I think I had the opposite problem: Hadoop wasn't shiny enough and Java had a terrible reputation in academic tech circles. I wish I'd known about mrjob because that would have kept the Python maximalists happy.

I had lengthy arguments with people who wanted to use Spark which simply did not have the chops for this. With Spark, attempting to process OSM for a small country failed.

Another interesting side-effect of using the map-reduce paradigm was with processing vector datasets. PostGIS took multiple days to process the million-vertex Norwegian national parks, however splitting the planet into data density sensitive tiles (~ 2000 vertices) I could process the planet in less than an hour.

Then Google Earth Engine came along and I had to either use that, or change career. Somewhat ironically GEE was built in Java.

[1] https://github.com/willtemperley/osm-hadoop
by frabonacci | 2026-01-19 07:23:26+00:00
MDM platforms can skip Setup Assistant, but they require the device to be pre-enrolled in Apple Business Manager before first boot - VMs can't be enrolled in ABM, so those hooks aren't available.

defaults write only works after you have shell access, which means Setup Assistant is already done.

There are tools that modify marker files like .AppleSetupDone via Recovery Mode, but that's mainly for bypassing MDM enrollment on physical Macs - you'd still need to create a valid user account with proper Directory Services entries, keychain, etc.

The VNC + OCR approach is less elegant but works reliably without needing to reverse-engineer macOS internals or rely on undocumented behaviors that might break between versions.
by BozeWolf | 2026-01-19 07:24:02+00:00
I was about to ask the same thing. I saw mentioning of gdpr, feels like at least some europeans are involved.

However: I don’t want to have my data in the US for at least 3 years. For businesses outside the US: they simply cannot have their data in US anymore.

Build european/non-us would be a great argument to use this product.
by peteforde | 2026-01-19 07:24:34+00:00
I enjoyed this post, but I do find myself disagreeing that someone sharing their source code is somehow morally or ethically obligated to post some kind of AI-involvement statement on their work.

Not only is it impossible to adjudicate or police, I feel like this will absolutely have a chilling effect on people wanting to share their projects. After all, who wants to deal with an internet mob demanding that you disprove a negative? That's not what anyone who works hard on a project imagines when they select Public on GitHub.

People are no more required to disclose their use of LLMs than they are to release their code... and if you like living in a world where people share their code, you should probably stop demanding that they submit to your arbitrary purity tests.
Show HN: Pyvoy – a modern Python application server built in Envoy
by chokoswitch | 2026-01-19 07:24:38+00:00
I have released a new Python ASGI/WSGI application server. This may be particularly interesting to

- Python developers interested in server tech, especially if already using Envoy

- Envoy users to see use cases enabled by dynamic modules

- Rust fans to see an example of it bridging two non-Rust ecosystems, Envoy and Python

Note, this is my first real project in Rust - while I tried to study idioms while working on it, I doubt it is an example of a fully idiomatic Rust project.

I was interested in a Python app server with support for HTTP/2 trailers to be able to serve gRPC as a normal application, together with non-gRPC endpoints. When looking at existing options, I noticed a lot of complexity with wiring up sockets, flow control, and similar. Coming from Go, I am used to net/http providing fully featured, production-ready HTTP servers with very little work. But for many reasons, it's not realistic to drive Python apps from Go.

Coincidentally, Envoy released support for dynamic modules which allow running arbitrary code in Envoy, along with a Rust SDK. I thought it would be a fun experiment to see if this could actually drive a full Python server - I thought it wouldn't. But after exposing some more knobs in dynamic modules - it actually worked and pyvoy was born, a dynamic module that loads the Python interpreter to run ASGI and WSGI apps, marshaling from Envoy's HTTP filter. There's also a CLI which takes care of running Envoy with the module pointed to an app - this is definitely not net/http level of convenience, but I appreciate that complexity is only on the startup side. There is nothing needed to handle HTTP, TLS, etc in pyvoy, it is all taken care of by the battle-hardened Envoy stack, and we get everything from HTTP, including trailers and HTTP/3.

With support for trailers, pyvoy drives the gRPC protocol support on the server for connect-python (https://github.com/connectrpc/connect-python), allowing them to be served along an existing Flask or FastAPI application as needed. Notably, it is the only server that passes all of connect's conformance tests with no flakiness. It's important to note that uvicorn also passes reliably when disabling features that require HTTP/2. It's a great server when bidirectional streaming or gRPC aren't needed - unfortunately others we tried would have unreliable behavior handling client disconnects, keepalive, and such. This doesn't surprise me as I have seen quite some time ago how hard it is to implement especially HTTP/2 reliably, and I appreciate pyvoy can rely on Envoy to just take care of it.

It seems that pyvoy is a fast (always benchmark your own workload), reliable server not just for gRPC but any workload. It also can directly use any Envoy feature, and could replace a pair of Envoy + Python app server. I currently use it in production at low scale serving Django, FastAPI, and connect-python.

Happy to hear any thoughts on this project. Thanks for reading!
by throwaway290 | 2026-01-19 07:25:07+00:00
makes it difficult to verify that it runs locally. unobfuscated source is not available. important actions, like open a PDF, save edited PDF, will be stuck or error if you cut the internet after opening the site and only unstuck after you reenable internet. I get it's probably for speed

anyway, if you save the page in Chrome and serve it on a local server, it works even with internet disabled, so there's that.
by yadavrh | 2026-01-19 07:26:01+00:00
You're exactly right. We aren't trying to replace the massive "Slack as an OS" setups that Enterprise Grid customers have built.

We are targeting teams (5-50 people) that need robust, persistent chat but are hitting that "pay-wall or lose-history" cliff with Slack. The goal is to give those teams a professional-grade experience (unlimited search, speed, reliability) without the enterprise tax or complexity
by archargelod | 2026-01-19 07:26:04+00:00
> After 5000 runs, they were all 8.4-9.7%

This sample size is really small. I ran 100 million simulations in Nim[0] (takes around a minute). And distribution converges toward 9.09% on all positions equally:

Average turns: 65.99609065001634
Final position distribution:
4: 9.095%
11: 9.093%
7: 9.091%
3: 9.091%
10: 9.090%
9: 9.090%
1: 9.090%
8: 9.090%
2: 9.090%
6: 9.090%
5: 9.089%
0: 0.000%

[0] - https://play.nim-lang.org/#pasty=hwdfbsfh (reduced amount of runs to not abuse playground server resources)
by pleurotus | 2026-01-19 07:26:14+00:00
Thanks for the explanation! It makes a lot of sense that voxels would scale as badly as they do, especially if you want to increase resolution.
Am I right in assuming that the reason this scales a lot better is because the Gaussian splats, once there's enough "resolution" of them, can provide the estimates for how light works reasonably well at most distances? What I'm getting at is, if I can see Gaussian splats vs voxels similarly to pixels vs vector graphics in images?
by renewiltord | 2026-01-19 07:26:31+00:00
lol Hacker News is ground zero for outrage porn. When that guy made that obviously pretend story about delivery companies adding a desperation score the guys here lapped it up.

Just absolutely loved it. Everyone was wondering how deepfakes are going to fool people but on HN you just have to lie somewhere on the Internet and the great minds of this site will believe it.
by vunderba | 2026-01-19 07:27:23+00:00
Seems like Clientside PDF editors are the new "hello world" app these days. From the last couple months on Show HN alone:

Show HN: PDF Quick – Free PDF tools with 100% client-side processing

https://news.ycombinator.com/item?id=46094734

Show HN: A privacy-first, client-side toolbox (PDF, Imgs, Dev) no server uploads

https://news.ycombinator.com/item?id=46018221

Show HN: FileZen – Client-side PDF and Video tools using WebAssembly

https://news.ycombinator.com/item?id=46339833

Show HN: JW Tool Box – Free, privacy-first web tools (PDF, Image, Converters)

https://news.ycombinator.com/item?id=46065448

Show HN: PDFClear – Browser-based PDF tools with local AI (WASM+Transformers.js)

https://news.ycombinator.com/item?id=46036944

Show HN: Free PDF tools that run in the browser

https://news.ycombinator.com/item?id=46315672

Show HN: Client-side file tools – PDF, images, crypto, all in-browser

https://news.ycombinator.com/item?id=46209627
by pdpi | 2026-01-19 07:28:00+00:00
I'm sorry, but that's nonsense. Soft skills are mostly definitely not about sucking up.

At a previous job, the PM for another team often asked me to join some of their meetings — her engineers were shit at talking to non-technical people, so, for critical meetings, she asked me to join to serve as an interpreter of sorts. That's soft skills at work.

Talking to stakeholders and understanding what they need? Soft skills. Understanding the different between important and urgent? Soft skills. Being able to assess a candidate during an interview? Soft skills. Navigating cultural differences when you have offices or suppliers abroad? Soft skills.

I'd go as far as to say that the single biggest difference between a junior and a senior engineer is how well developed their soft skills are.
by timschmidt | 2026-01-19 07:30:17+00:00
> The real answer should have been a new language that has memory safety without all the extra conceptual changes and orthogonal subsystems that Rust brings.

So what you're saying here is that you don't understand that Rust's rules around memory ownership, aliasing, and mutability are what allow the language to provide deterministic compile time memory safety without runtime cost. If you figure out another way to guarantee memory safety at compile time with zero runtime overhead, you should write a paper and start another language around it!

https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... exists, and is an exciting, laudable effort, I think. But requires hardware support as well as language modifications.
by yadavrh | 2026-01-19 07:32:09+00:00
Thanks! You're 100% right—the ecosystem is the hardest part to replicate.
We know we can't match 2,000+ integrations on day one. Our strategy is to nail the core "chat + search" experience first,and then offer a dead-simple, developer-friendly API (think "webhooks on steroids") so teams can easily pipe in the 3-4 critical tools they actually depend on (GitHub, Jira, Alerts), rather than waiting for us to build a massive library.
by harlanlewis | 2026-01-19 07:32:14+00:00
Clever! Sharing my lightning test of this approach.

Context - I have a 200k+ LOC Python+React hobby project with a directory full of project-specific "guidelines for doing a good job" agent rules + skills.

Of course, agent rules are often ignored in whole or in part. So in practice those rules are often triggered in a review step pre-commit as a failsafe, rather than pulled in as context when the agent initially drafts the work.

I've only played for a few minutes, but converting some of these to custom lint rules looks quite promising!

Things like using my project's wrappers instead of direct calls to libs, preferences for logging/observability/testing, indicators of failure to follow optimistic update patterns, double-checking that frontend interface to specific capabilities are correctly guarded by owner/SKU access control…

Lots of use cases that aren't hard for an agent to accurately fix if pointed at directly, and now that pointing can happen inline to the agent work loop without intervention through normal lint cleanup, occurring earlier in the process (and faster) than is caught by tests. This doesn't replace testing or other best practices. It feels like an additive layer that speeds up agent iteration and improves implementation consistency.

Thanks for the tip!
by utopiah | 2026-01-19 07:33:02+00:00
Terrible and condolences to anybody affected.

For a bit of context according to the OECD 2023 Spain had ~1800 on the road during the previous year, so that's about 5/day. There are more deaths on the road in Spain in a couple of weeks than this tragic accident. Either way it's too many deaths obviously but I want to highlight what a freak event this is compared to a more popular mode of transportation.
by bob1029 | 2026-01-19 07:33:44+00:00
Appropriate feedback is critical for good long horizon performance. The direction of feedback doesn't necessarily have to be from autonomous tools back to the LLM. It can also flow from tools to humans who then iterate the prompt / tools accordingly.

I've recently discovered that if a model gets stuck in a loop on a tool call across many different runs, it's almost certainly because of a gap in expectations regarding what the available tools do in that context, not some random model failure mode.

For example, I had a tool called "GetSceneOverview" that was being called as expected and then devolved into looping. Once I counted how many times it was looping I realized it was internally trying to pass per-item arguments in a way I couldn't see from outside the OAI API black box. I had never provided a "GetSceneObjectDetails" method (or explanation for why it doesn't exist) so it tried the next best thing foreach item returned in the overview.

I went one step further and asked the question "can the LLM just directly tell me what the tooling expectation gap is?" And sure enough it can. If you provide the model with a ReportToolIssue tool, you'll start to get these insights a lot more directly. Once I had cleared non-trivial reports of tool concerns, the looping issues all but vanished. It was catching things I simply couldn't see. The best insight was the fact that I hadn't provided parent ids for each scene object (I assumed not relevant for my test command), so it was banging its head on those tools trying to figure out the hierarchy. I didn't realize how big a problem this was until I saw it complaining about it every time I ran the experiment.
by yadavrh | 2026-01-19 07:34:23+00:00
Thank you! That's high praise. The "decisions" feature came from our own frustration of losing critical agreements in the endless scroll of chat.

We know it's a crowded space with a lot of history (RIP Stride/HipChat), but we're betting that for many teams, the "social" aspect has actually become too noisy. We're trying to swing the pendulum back slightly towards "calm productivity" without losing the fun of real-time chat.
by afdbcreid | 2026-01-19 07:35:59+00:00
You'd be surprised to see, after deep inspection, how little of Rust you can remove while keeping its safety story the same (that is, memory safe without GC).

Traits? Nope. We need some way for code reuse. Classes cannot be made memory safe without extra cost (at least, I don't know how can they). And they are not less complex either. Templates like C++? More complex, and doesn't allow defining safety interfaces. No tool for code reuse? That will also severely limit the safety (imagine how safe Rust was if everyone would need to roll their `Vec`).

The borrow checker of course cannot be omitted. ADTs are really required for almost anything Rust does (and also, fantastic on their own). Destructors? Required to prevent use after free.

Async can be removed (and in fact, wasn't there in the beginning) which is a large surface area, but even today it can mostly be avoided if you're not working in some areas.

I don't think anybody can deny Rust is complex, but most often it's inherent complexity (what you call "sophistication") given the constraints Rust operates in, not accidental complexity.
by pjmlp | 2026-01-19 07:36:25+00:00
While RC is a GC algorithm, chapter 5 from GC handbook, it doesn't count when it isn't part of the type system because then it becomes optional and not part of the regular use of the programming language.

Additionally Limbo's GC is a bit more complicaticated than a plain add_ref()/release() pair of library calls.

https://doc.cat-v.org/inferno/concurrent_gc/concurrent_gc.pd...
Show HN: Compare Data Between Two Stacks of Documents Using Regex
by sudostar | 2026-01-19 07:37:01+00:00
This PDF Pattern Matcher is a local web app that allows you to compare Regex matches in two stacks of documents. This is useful for e.g. document reconciliation.

I initially created a Python NiceGUI app for my parent's small business so that they can verify that all delivery notes are included in a freight credit note.

I re-implemented it as a browser-based Nuxt app.

I use PDF.js to extract text from PDFs and also experiment with Tesseract.js for OCR. Papaparse is used to generate simple CVS reports of the results.
by ycombinator_acc | 2026-01-19 07:37:08+00:00
No, that’s a common cope.

Not AI. Not bots. Not Indians or Pakistanis. Not Kremlin or Hasbara agents. All the above might comprise a small percentage of it, but the vast majority of the rage bait and rage bait support we’ve seen over the past year+ on the Internet (including here) is just westerners being (allowed and encouraged by each other to be) racist toward non-whites in various ways.
by utopiah | 2026-01-19 07:37:41+00:00
Very neat! I had a https://www.crowdsupply.com/wee-noise-makers/wee-noise-maker... but I don't always carry it with me. I do have my phone though most of the time in my pocket so having this on, Web based, is great! The author of ToneJS is very kind, if the documentation wasn't clear you might want to reach out to help clarify it.

PS: didn't check it but being a PWA to work offline would be quite neat, just in case the subway or train goes through a spot without connectivity.
by pjerem | 2026-01-19 07:38:29+00:00
I remember this day because I worked in a company that made software for train networks.

It did briefly made the news but not for long due to the terror attacks and also there wasn’t any passenger on this train, it was a train testing.

In fact the story is even more tragic when you know that the day before, they also were too fast in the same turn and in the records you hear something like « few, that was close, better take care next time ».

However, for sure this crash should have never happened but it only happened because they were testing the limits of both the train and the track.

It’s literally like a test pilot crashing an airplane while testing all the limits : it should never happen but they are still there for it not to happen in commercial flights.
by adrian17 | 2026-01-19 07:39:49+00:00
I just went to a random OpenAI blog post ("The new ChatGPT Images is here"), right-click saved one of the images (the one from "Text rendering" section), and pasted it to your [1] link - no metadata.

I know the metadata is probably easy to strip, maybe even accidentally, but their own promotional content not having it doesn't inspire confidence.
by yadavrh | 2026-01-19 07:40:14+00:00
You've hit on a core part of our mission. We are a Western European company, so GDPR and data sovereignty are at the heart of our architecture, not an afterthought.

Two big things on the data front:
1. Local-First: Since the primary storage is on your own devices, you have much more direct control over your data custody than with traditional SaaS.
2. Regional Hosting: We'll be offering a choice of data residency. If you need your data to stay within the EU for compliance or security, you can simply toggle that.
by yadavrh | 2026-01-19 07:41:33+00:00
You've hit on a core part of our mission. We are a Western European company, so GDPR and data sovereignty are at the heart of our architecture, not an afterthought.
Two big things on the data front: 1. Local-First: Since the primary storage is on your own devices, you have much more direct control over your data custody than with traditional SaaS. 2. Regional Hosting: We'll be offering a choice of data residency. If you need your data to stay within the EU for compliance or security, you can simply toggle that.
by lmm | 2026-01-19 07:42:24+00:00
IRC has many many usability problems which I'm sure you're about to give a "quite trivial curlftpfs" explaination for why they're unimportant - missing messages if you're offline, inconsistent standards for user accounts/authentication, no consensus on how even basic rich text should work much less sending images, inconsistent standards for voice calls that tend to break in the presence of NAT, same thing for file transfers...