MurphyA/hacker-news huggingface dataset:
by alexgieg | 2025-12-28 21:41:29+00:00
You're uninformed. France has that, and it doesn't result in excessive unemployment; in fact, the unemployment rates in France and in the US are practically the same, respectively 7.5% vs. 7.8%.

What changes between the countries is the hiring procedure.

US and UK companies mostly use a "hire anyone, keep the slightly useful ones for as long as they seem slightly useful, fire everyone else, fire them too, wash, rinse, repeat" narcissistic-sociopathic trial-and-error pseudo-method that's just guesswork dressed up as "choice".

French companies, and those in countries with similar preferences, take their time to very seriously vet the people they're hiring with a focus on the long term, and do it right from the start, following scientific hiring methodologies that leave little to no space for guesswork and gut feelings.

The result for the company is the same: the proper employee, at the proper position, doing the proper job the company needs.

The result for the employee is that the first "method", being as it is narcissistic-sociopathic, promotes unnecessary human suffering with zero actual benefit to anyone, whereas the second promotes well-being, satisfaction, and good work-life balance.

And, again, unemployment rates don't vary between them.

Now, if you believe your company would do badly under this system, maybe it would indeed. Which only goes to show you don't know how to hire properly. Start hiring better, and it'd make zero difference for you whether you're in a system or the other. In fact, start hiring better, and you may even move ahead compared to your narcissistic-sociopathic competitors, since then they will be the ones going with simple trial-and-error, while you will get the right employees from the start, and without regrets.
by maxglute | 2025-12-28 21:42:27+00:00
I was invited to lunch near factory 541, tank city, a pseudo closed area sprawled in some Shanxi valley. Turned out it was lunch and a show, they were going executing some drug traffickers from strike hard. Impromptu don't do drug lesson from uncle. We had to turn around because I had naturalized western citizenship and weird dialect by then and they figure security would not let us through. It was pretty surreal experience vs how nice and insular danwei life was otherwise.
by goldsteinq | 2025-12-28 21:42:36+00:00
Okay, sorry, not oss-security mailing list, oss-security _distros_ mailing list.

https://oss-security.openwall.org/wiki/mailing-lists/distros

> Only use these lists to report security issues that are not yet public

> To report a non-public medium or high severity 2) security issue to one of these lists, send e-mail to distros [at] vs [dot] openwall [dot] org or linux [dash] distros [at] vs [dot] openwall [dot] org (choose one of these lists depending on who you want to inform), preferably PGP-encrypted to the key below.
by concinds | 2025-12-28 21:43:36+00:00
> The rest of the executives were fully content with this effort, and in the end he wasn't even forced out

Tim Cook, by all accounts, can be very micromanaging and demanding when it comes to logistics underlings, but has been extremely hands-off with all his other underlings, doesn't insert himself into their loops or require his approval, doesn't decide by decree like Jobs which forces underlings to fight the bureaucracy on their own, leaves them to resolve conflicts among themselves on their own. He treats Apple like a machine or system where his role is to keep things running smoothly.

It's not "the rest of the executives", that's how Cook's Apple is run. Reportedly.
by anonym29 | 2025-12-28 21:44:03+00:00
Great, then it sounds like we agree: your original equivalence of Signal and WhatsApp was misguided, since one offers a verifiable chain of trust that starts with source availability and the other doesn't, to say nothing of the lengthy history of untrustworthiness and extensive, deliberate privacy violations of the company that owns and maintains WhatsApp, right?
by zed_labs_dev | 2025-12-28 21:44:05+00:00
I built this product and optimized it for formatting with Jake's Resume template. You can give it a very badly formatted resume, and it will clean and restructure it.

I created it mostly because the resumes I see now are so badly formatted and don't work with the parsers that are used.

I am using a combination of LLM + semantic analysis to achieve this here
by zahlman | 2025-12-28 21:44:57+00:00
> And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so. Let's see - at 20000 clients, that's 50KHz, 100Kbytes, and 50Kbits/sec per client. It shouldn't take any more horsepower than that to take four kilobytes from the disk and send them to the network once a second for each of twenty thousand clients. (That works out to $0.08 per client, by the way. Those $100/client licensing fees some operating systems charge are starting to look a little heavy!) So hardware is no longer the bottleneck.

It seems to me that there are far fewer problems nowadays with trying to figure out how to serve a tiny bit of data to many people with those kinds of resources, and more problems with understanding how to make a tiny bit of data relevant.

It still absolutely can be. We've just lost touch.
by gattr | 2025-12-28 21:45:56+00:00
I concur; just last month I started with `wgpu` (the Rust bindings for WebGPU) after exclusively using OpenGL (since 2000, I think? via Delphi 2). Feels a bit verbose at first (with all the pipelines/bindings setup), but once you have your first working example, it's smooth sailing from there. I kind of liked (discontinued) `glium`, but this is better.
by threethirtytwo | 2025-12-28 21:46:00+00:00
>I don't think this happens most of the time, but it does mean that static typing isn't a strict upgrade in terms of reliability.

It is a strict upgrade in reliability. You're arguing for other benefits here, like readability and simplicity. The metric on topic is reliability and NOT other things like simplicity, expressiveness or readability. Additionally, like you said, it doesn't happen "most" of the time, so even IF we included those metrics in the topic of conversation your argument is not practical.

>You are paying for the extra guarantees on the code you can write by giving up lots of correct programs that you could otherwise have written.

Again the payment is orthogonal to the benefit. The benefit is reliability. The payment is simplicity, flexibility, expressiveness, and readability. For me, personally, (and you as you've seem to indicate) programs actually become more readable and more simple when you add types. Expressiveness and flexibility is actually a foot gun, but that's not an argument I'm making as these are more opinions and therefore unprovable. You're free to feel differently.

My argument is that in the totality of possible errors, statically typed programs have provably LESS errors and thus are definitionally MORE reliable than untyped programs. I am saying that there is ZERO argument here, and that it is mathematical fact. No amount of side stepping out of the bounds of the metric "reliability" will change that.
by cyberax | 2025-12-28 21:46:08+00:00
Yes, I played around with that using the isochrone API from geoapify. That's why I'm thinking that buses are not necessary.

> If the road is a bottleneck optimising for usage it may let buses have a fast lane and the difference is less.

Ha. The dirty little secret of bus lanes is that they don't work as people think they do. They don't reduce the overall aggregated travel time (the sum of commute time for all the people traveling the route) in most cases. Instead, they force people out of cars by reducing the car throughput.

The commute time for each person who is forced out of their car typically becomes longer. As is commutes for the people in cars that now have to navigate more congested roads.
by wakawaka28 | 2025-12-28 21:46:13+00:00
I explained my side already. The site's policies are selectively enforced by moderators and the liberal hive mind here downvotes most of my posts. Stop trying to deny what I have seen for the past 2 years here. If you think "a few months" of commenting is enough to get basic site features, you're wrong. I disagree with people often and talk straight, and there is very much a liberal hive mind here of established users who leave snarky fulminating comments on political stuff and downvotes on comments. There are also people shilling for particular technologies who downvote me too when I express an opinion they don't like. Anyway, it's clear you don't believe me or want to hold the line for your favorite views. So be it. Maybe if enough people like me complain something will change.
by UomoNeroNero | 2025-12-28 21:47:04+00:00
I can guarantee you, from my personal experience of being diabetic for 30 years, that every day—and in the most incredible ways—I have managed to “almost kill myself.” Whether when I used finger-prick testing, sensors, injecting insulin with pens, or managing insulin with a pump. Our life is always a delicate balancing act between too little, too much, and way too much—the kind where this time I really kick the bucket

By personal choice I use a commercial CGM (if I could “touch it,” I’d be firmly on the side of certainty about killing myself through sheer stupidity), but reading something like “associated with” really makes me angry. Before making such subtle insinuations about the open-source world (the source of the revolution of the last 10 years in this field), regulatory bodies should open their eyes to what is actually happening with the quality of current sensors and the real problems they are causing.
by davnicwil | 2025-12-28 21:47:19+00:00
the one I've noticed being the worst for lock ups is the camera / photos app, which is frankly very surprising given how central the photography usecase appears to be to iPhone sales and therefore Apple's bottom line.

I'm talking, I pull up the camera and try to take literally 4-5 shots quickly and by the 6th there's what feels like seconds of lag between the button press and the photo being taken.

It feels like I'm using an ancient camera phone, or a more modern phone but in extreme heat when the CPU is just throttling everything. But instead, this is a 2 year old iPhone at room temperature.
by osiris88 | 2025-12-28 21:47:36+00:00
There's a semantics discussion about whether progressively adding context to errors (forming an error chain) counts as "error accumulation" or if error accumulation means collecting several errors that occurred and returning that to the caller. But at this point I think you understand what I meant and I understand your meaning.

I do think that `std::error::Error` is mostly pointless. That's a value judgment, and reasonable people can disagree.

I've tried to argue that, it can create bigger problems then it solves. It's a trait that only exists on platforms with `std`. That itself is pretty nasty and if you care at all about platforms that aren't like that, you're taking on a lot of build complexity. If you really need this why not just make your own `trait HasCause` which is like a subset of `std::error::Error` functionality, and simply doesn't require `std`?

I'll list a number of things that I've experienced coworkers being confused about around the `std::error::Error` trait.

1) Why does it require `Display` and then not use it?

2) Displaying it is very simple: `format!("{err}")`. If you want to format the error and it's chain of causes, actually using the `std::error::Error` functionality, the recommended way was to use yet another experimental `error_chain` library. When should we actually do that? When is that appropriate?

Now we have a place where there's two different ways to do the same thing (display an error). Additionally there is controversy and churn around it.

In a large project, most developers will be completely ignorant about the second more obscure possibility. And in most projects, you don't really need two ways to format an error. So I tend to do the friendliest thing for developers. There is only one way, and it is Display, which 100% of rust developers know about, and I avoid using `std::error::Error`.

I understand that there's a bright shiny future that people hope it's headed for, where everything around `std::error::Error` is easy and obvious, and we have powerful flexible expressive ergonomic error handling. I was excited about that like 7 years ago, now I just kinda want to change the channel. I respect the other point of view about that though.
I built an API to stop manual data entry from invoices and resumes
by scannyai | 2025-12-28 21:48:32+00:00
Hi HN,

I’m the founder of Scanny AI (https://scanny-ai.com/).

I built this because I noticed that despite all the advancements in AI, businesses are still hiring people to manually copy-paste data from PDFs to Excel. Standard OCR tools often just give you a "blob of text" that still requires manual cleanup.

What it does: Scanny AI takes unstructured documents (Invoices, Resumes, IDs, Receipts) and extracts specific data points into structured formats (JSON, CSV, Excel).

How it works: Unlike regex-based parsers or standard OCR, we use context-aware models to understand the document layout. This means it can identify a "Total Amount" on an invoice even if the layout changes, or extract "Implied Skills" from a CV that aren't explicitly listed as keywords.

Current Use Cases:

Invoices: Extracting line items, tax, and vendor details.

Resumes: Parsing experience and skills for HR.

IDs: extracting PII for KYC checks.

We are currently in Early Access and I’m looking for feedback on the extraction accuracy and the API usability.

I’ve enabled Free Credits for new sign-ups so you can test it on your own documents without paying.

I’d love to hear your thoughts on the edge cases (messy handwriting, weird layouts, etc.) and what features you’d like to see next.

Link: https://scanny-ai.com/

Thanks!
by duped | 2025-12-28 21:48:56+00:00
No, apple does not buy production capacity to prevent others from using it. They buy it to use it themselves.

The wafers are not DRAM. This is more likely burning oil wells so your enemy can't use them. Wafers are to chips what steel blanks are to engines. You basically need clean rooms just to accept delivery and entire fabs to do anything. Someone who doesn't own a fab buying the wafers is essentially buying them to destroy them.
by Someone | 2025-12-28 21:50:27+00:00
I can see your point, but that (https://book.pythontips.com/en/latest/context_managers.html) requires the object you’re using to implement __enter__ and __exit__ (or, in C#, implement IDisposable (https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...), in Java, implement AutoCloseable (https://docs.oracle.com/javase/tutorial/essential/exceptions...); there likely are other languages providing something similar).

Defer is more flexible/requires less boilerplate to add callsite specific handling. For an example, see https://news.ycombinator.com/item?id=46410610
by nothrabannosir | 2025-12-28 21:52:49+00:00
Individual action cannot solve a tragedy of the commons. Refraining from consuming the commons literally just leaves more for others to consume. Which they will.

A tragedy of the commons can only be resolved through collective action. Carbon tax is the obvious example.

GP technically didn't suggest otherwise, and in fact the same "selfishness" highlighted in that comment also drives people to vote against the sacrifice of collective action, so IMO they're correct. But if you forget about that (implied) step, and instead read "we should all individually just get rid of our ACs and stop flying, to solve climate change" (which GP didn't say), then that would be incorrect.
by hahahacorn | 2025-12-28 21:52:59+00:00
A highly cited reason for using mongo is that people would rather not figure out a schema. (N=3/3 for “serious” orgs I know using mongo).

That sort of inclination to push off doing the right thing now to save yourself a headache down the line probably overlaps with “let’s just make the db publicly exposed” instead of doing the work of setting up an internal network to save yourself a headache down the line.
by ludicity | 2025-12-28 21:53:35+00:00
Just wanted to pop in and say that I think Sean is absolutely right here. I've tried the ultra-cynical view at workplaces, and would have had better results with some "idealism", which he rightly notes in his form is just a more effectively action atop a base of clear-eyed cynicism.

However, I think we've got some tactical disagreements on how to actually make society a better place. Namely, I think Sean is right if you have to remain an employee, but many people just don't have to do that, so it feels a bit like a great guide on how to win soccer while hopping on one leg. Just use two legs!

My own experience, especially over the last year, has been telling me that being positioned as an employee at most companies means you're largely irrelevant, i.e, you should adopt new positioning (e.g, become a third-party consultant like me) or find a place that's already running nearly perfectly. I can't imagine going back to a full-time job unless I was given a CTO/CEO or board role, where I could again operate with some autonomy... and I suspect at many of the worst places, even these roles can't do much.

Also Sean, if you're reading this, we'll get coffee together before March or die trying.
by ghickPit | 2025-12-28 21:54:13+00:00
> Everybody knows LLMs are not alive and don't think, feel, want.

Please go ahead now and EAT YOUR WORDS:

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

https://lucumr.pocoo.org/2025/12/22/a-year-of-vibes/

> Because LLMs now not only help me program, I’m starting to rethink my relationship to those machines. I increasingly find it harder not to create parasocial bonds with some of the tools I use. [...] I have tried to train myself for two years, to think of these models as mere token tumblers, but that reductive view does not work for me any longer.
Show HN: Desktop‑2FA – offline, encrypted 2FA authenticator for your desktop
by wrogistefan | 2025-12-28 21:54:23+00:00
I’ve released desktop‑2fa v0.4.0 — an offline, encrypted TOTP authenticator designed for desktops, VMs, and air‑gapped environments.

Features:
- AES‑GCM encrypted vault with Argon2 key derivation
- No cloud, no phone, no telemetry
- RFC‑compliant TOTP (SHA1/SHA256/SHA512)
- Full CLI (add/list/generate/rename/remove/export/import/backup)
- 99% test coverage
- Zero external dependencies

GitHub: https://github.com/wrogistefan/desktop-2fa

I built this because I needed a reproducible, open-source 2FA tool for secure workstations and virtualized environments. Feedback welcome.
by subdavis | 2025-12-28 21:54:44+00:00
> We live in a late-stage-capitalist hellscape…

This is quite a straw man. I think a lot of engineers believe that other parts of the org lack perspective, sure. I’ve certainly seen managers or salespeople genuinely convinced that they’re delivering value when I know for a fact they’re selling snake oil. But I never assume it’s in bad faith, just an artifact of a shitty feedback and communication culture. People want to do good work, they just don’t often get good signal when they aren’t.
by akerl_ | 2025-12-28 21:55:43+00:00
No, we don’t agree. There are things that source code is good for, but validating the presence or absence of illicit data stealing code in apps delivered to consumers is not one of those things. For that, source code can show you obvious malfeasance, but since it’s not enough to rule out obvious malfeasance, you’re stuck going to analysis of the compiled app in both cases.

The population of users who have a verifiable path from an open source repo to an app on their device is a rounding error in the set of humans using messaging apps.
by gavinhoward | 2025-12-28 21:56:00+00:00
> For instance, you might think that big tech engineers are being deliberately demoralized as part of an anti-labor strategy to prevent them from unionizing, which is nuts. Tech companies are simply not set up to engage in these kind of conspiracies.

https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
by CodingJeebus | 2025-12-28 21:56:13+00:00
> It’s a cynical way to view the C-staff of a company. I think it’s also inaccurate: from my limited experience, the people who run large tech companies really do want to deliver good software to users.

People who run large tech companies want one thing: to increase shareholder value. Delivering "good software" (a very, very squishy term) is secondary.

I don't even think "good" is a quantifiable or effective measure here. C-level executives are deviating from reality in terms of what they say that their products are capable of versus how their products actually perform. If you're a CEO shipping a frontier model that adds some value in terms of performing basic technical tasks while simultaneously saying that AI is gonna be writing all code in 3-6 months, you're only doing good by your shareholders.
by 9dev | 2025-12-28 21:56:36+00:00
It always sounds so ridiculous to me when people working for Meta, Microsoft or Google talk about idealism, or solving good problems, or really any kind of values. The likes of you have very much sold your soul to the devil in exchange for a lot of money.
Any kind of idealism you may hold is nothing but a carefully crafted illusion to keep you from thinking too hard about what you are a part of, what are you are doing. If it hasn’t made click after big tech fell on their knees in front of Trump, there’s nothing left to say anymore.

So in a sense, Goedecke is right: Be a little cynical. Don’t bother with a veneer of the greater good or some other bullshit. Enjoy your paychecks while it lasts.
by clintjhill | 2025-12-28 21:56:41+00:00
Thanks! It's a great point to make. Early on I worked on a "migration" ability for the resources, so that every change you make automatically updates the underlying database. But the longer I worked on that, the more I realized I could create/delete as many APIs as I wanted working out what's necessary. Then scale it up for longevity. And the time it took to create/delete APIs was nearly as fast as some of the build times I've experienced for front-end applications.

That's ultimately what I think the value is: API development as hyper-iterative as front-end apps.

I'm still clearly working out how to describe this value. I'm developing more examples to help define what I think the best use-cases are.
by brabel | 2025-12-28 21:56:52+00:00
Why are people disagreeing with this? This is absolutely a problem that most other languages don't have. If you want to claim that Rust's error system is "better" than anything else (as the author did), you should have a good argument about why this exact problem the parent commenter described, which to me is a major problem, does not (maybe) cancel out all the other purported benefits of Rust's error system!
by AlexErrant | 2025-12-28 21:57:11+00:00
Hm, perhaps I was unclear.

AI absolutely is capable of doing damage, and _is_ currently doing damage. Perpetuating inequality, generating fake news, violation of privacy, questionable IP/rights, etc. These are more pressing than the idea that someday we will give AI the ability to manufacture nano-mosquitos that will poison us all, as Yudkowsky suggested on a recent podcast. He's so busy fantasizing about scifi he's lost touch with the damage it's currently doing.
by davnicwil | 2025-12-28 21:57:49+00:00
because even supposing you have an interface for your thing under test (which you don't necessarily, nor do you necessarily want to have to) it lets you skip over having to do any fake implementations, have loads of variations of said fake implementations, have that code live somewhere, etc etc.

Instead your mocks are all just inline in the test code: ephemeral, basically declarative therefore readily readable & grokable without too much diversion, and easily changed.

A really good usecase for Java's 'Reflection' feature.