MurphyA/hacker-news huggingface dataset:
by sshine | 2026-01-04 18:33:02+00:00
> and a DevOps guy who was already stretched thin

Another favourite antipattern: making devops a bottleneck. Don’t over-engineer production, don’t buy abstraction you can’t afford, and educate your colleagues to lower the bus factor.

Dedicated devops that aren’t co-founders are notorious for cv optimizing: working with cool, but time-consuming stuff they don’t yet master, at the cost of delivery-time risk.
by Volundr | 2026-01-04 18:33:02+00:00
Lots of folks are pointing this out, but it's not like there isn't evidence to suggest this will also apply to humans.

> Human knee tissue collected during joint replacement surgeries also responded positively to the treatment. These samples, which include both the joint’s supporting extracellular scaffolding, or matrix, and cartilage-producing chondrocyte cells, began forming new cartilage that functioned normally.
by mananaysiempre | 2026-01-04 18:33:09+00:00
I went and checked, and it was an SPE article from 1990[1]: “Why X is not our ideal window system” by Gajewska, Manasse, and McCormack. Section 3 has extensive diagrams of various races, including ones between clients and the window manager. Was even discussed here at one point[2], it turns out. Where I came across it I’m not sure (on X.org[3] possibly?).

[1] https://dx.doi.org/10.1002/spe.4380201409, https://people.freedesktop.org/~ajax/WhyX.pdf or http://os.4uj.org/WhyX.pdf

[2] https://news.ycombinator.com/item?id=15120308

[3] https://x.org/wiki/XorgDeveloperDocumentation/
by 101008 | 2026-01-04 18:33:31+00:00
I was very anti AI (mainly because I am scared that I'll take my job). I did a side project that would have took me weeks in just two days. I deployed it. It's there, waiting for customers now.

I felt in love with the process to be honest. I complained my wife yesterday: "my only problem now is that I don't have enough time and money to pay all the servers", because it opened to me the opportunities to develop and deploy a lot of new ideas.
by oofbey | 2026-01-04 18:33:36+00:00
Interesting. Thanks for the reference!

It's hard to know which way this will go. Discrete/text reasoning has many advantages. Safety as you note. Interpretability, which is closely related. Interoperability - e.g. the fact that you can switch models mid-discussion in Cursor and the new model understands the previous model's CoT just fine, or the ability to use reasoning traces from a larger model to train a smaller model to reason.

Continuous latent reasoning is a big hassle, but wins on efficiency, and in some situations I'm sure people will decide that benefit is worth the hassle. Because efficiency is fighting physics, which is hard to argue with on small devices with batteries. So my guess is that we'll see some of each approach in the future - with most cloud stuff being discrete, and a few highly-tuned edge applications being continuous.

Safety is a multi-faceted problem. I think it's easy to over-index on it because the impacts can be so huge. But there are so many different ways to approach the problem, and we must not rely on any one of them. It's like cyber-security - you need to use defense in depth. And sometimes it makes sense to sacrifice one kind of protection in order to get some convenience. e.g. if you decide to use continuous reasoning, that probably means you need to write a custom classifier to detect mal-intent rather than relying on an off-the-shelf LLM to analyze the reasoning trace. So I wouldn't ever take a position like "nobody should ever use continuous reasoning because it's too dangerous" - it just means that kind of safety protection needs to be applied differently.
by bigcloud1299 | 2026-01-04 18:33:48+00:00
15 years in leadership worked at 3 jobs lead major transformations at retail where nearly 100B of revenue goes through what i built. Ran $55-$100M in a yearly budget… over 300 FTEs and 3x contractors under my or my budget,…largest retailer in google at that time…my work influenced GCP roadmap, Datastax roadmap, … much more all behind the scenes…. besides your capabilities and ability that had to be there to get you in those positions - but once you are in those positions - only that mattered is politics and asskissing. I know so many people smarter than me, always stayed lower b/c they didn’t know how to play politics. Only reason i never got higher was I didn’t know how to play politics and kiss ass any more or any better.

The top people are all who kissed each others ass and looked out only for their cohort (e.g. people who were in same positions as them in early 2013). So teach your kids to kiss ass and play poltiics.
by kentonv | 2026-01-04 18:35:00+00:00
To add some color to "workerd is not a hardened sandbox":

workerd does not include any sandboxing layers other than V8 itself. If someone has a V8 zero-day exploit, they can break out of the sandbox.

But putting aside zero-day exploits for a moment, workerd is designed to be a sandbox. That is, applications by default have access to nothing except what you give them. There is only one default-on type of access: public internet access (covering public IPs only). You can disable this by overriding `globalOutbound` in the config (with which you can either intercept internet requests, or just block them).

This is pretty different from e.g. Node, which starts from the assumption that apps should have permission to run arbitrary native code, limited only by the permissions of the user account under which Node is running.

Some other runtimes advertise various forms of permissions, but workerd is the only one I know of where this is the core intended use case, and where all permissions (other than optionally public internet access, as mentioned) must be granted via capability-based security.

Unfortunately, JavaScript engines are complicated, which means they tend to have bugs, and these bugs are often exploitable to escape the sandbox. This is not just true of V8, it's true of all of them; any that claims otherwise is naive. Cloudflare in production has a multi-layer security model to mitigate this, but our model involves a lot of, shall we say, active management which can't easily be packaged up into an open source product.

With all that said, not all threat models require you to worry about such zero-day exploits, and you need to think about risk/benefit tradeoffs. We obviously have to worry about zero-days at Cloudflare since anyone can just upload code to us and run it. But if you're not literally accepting code directly from anonymous internet users then the risk may be a lot lower, and the overall security benefit of fine-grained sandboxing may be worth the increased exposure to zero-days.
by devsda | 2026-01-04 18:35:02+00:00
> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

The main benefit of understanding the purpose and real world usage of your software is that you can ask the right questions while planning and implementing the software/feature/bug-fix and that you don't make any wrong assumptions.

In a situation where you have conflicting requirements or concerns regarding the change, you'll eventually be hit with "PM knows the product & customer better" or the explicit "your job is to deliver what is asked".
by dijit | 2026-01-04 18:35:16+00:00
I can try that version, but it's entirely possible (and even: likely) that I was already using an old version of Hugo then; whatever was installed by my package manager - assuming I updated my machine somewhat recently.

If I used MacOS then Hugo was probably very old, since I often forget to update brew packages and end up running very old software.

But, that's what I thought to do first also.

In the end, it becomes not worth the hassle, and spending time fixing it means that whatever I was going to write gets pushed out of my head, and it's very difficult to even bother.

I'll probably go back to Svbtle.
by oofbey | 2026-01-04 18:36:14+00:00
Arstechnica used to have different kinds of upvotes for "funny" vs "insightful" - I forget exactly all of them. But I found it awesome. I wanted to and could read the insightful comments, not the funny ones. A couple years back they redid the discussion system and got rid of it. Since then the quality of discussion has IMHO completely tanked.
by hansmayer | 2026-01-04 18:36:24+00:00
I do agree with you. Teams are a cancer and Azure UI sucks too. I do not use much MS products since essentially Win7 I have mainly used Linux as my work environment. But one thing MS used to be good at at least, was the documentation. If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support. With google its like...not even that.
Show HN: I built a privacy-first developer toolkit (JSON, cURL, SQL, etc.)
by dailydev | 2026-01-04 18:36:27+00:00
Hi HN,

I got tired of Googling "json formatter" or "curl converter" and landing on sites that are 80% ads, require a login, or send my clipboard data to a remote server.

So, I built Dailydev.in – a collection of developer utilities focused on speed and privacy.

The Stack:

Frontend: React + Vite (for instant loading).

Hosting: Netlify.

Philosophy: Minimalist. No tracking. No paywalls.

Key Tools:

cURL to Code: Convert cURL commands into fetch, Python, Go, etc.

JSON Tools: Formatter, Validator, and JSON-to-Typescript interface generator.

Encoders/Decoders: Base64, URL, JWT debugging.

Why I built it: I wanted a "Swiss Army Knife" that I could keep pinned in a tab without it eating up RAM or breaking my flow. Most of the logic runs entirely client-side, so your data stays in your browser.

I’m actively adding more tools (currently working on some distributed system helpers using AWS Lambda).

I’d love your feedback on the UX and suggestions for what other utilities you find yourself needing often.

Link: https://dailydev.in
by 2b3a51 | 2026-01-04 18:36:42+00:00
Can recommend the Mediterranean side salad and a bowl of roasted veg off the side menu if you are hungry.

In the centre of the city there are three spoons. One for the people with tattoos on their knuckles (near the magistrates' court oddly - I used to pick up gossip in the barbers round the corner but he has been bought out so the building can be converted in to 'luxury apartments'), one for the old geezers with leather jackets and a third very large one opposite a conference centre. This latter one very well managed and always a seat. All kinds of people but never rammed.
by zephen | 2026-01-04 18:37:42+00:00
Mentally discarding a name still takes some amount of effort, even if local.

I often write things the way you have done it, for the simple reason that, when writing the code, maybe I feel that I might have more than one use for the constant, and I'm used to thinking algebraically.

Except, that I might make them global, at the top of a module. Why? Because they encode assumptions that might be useful to know at a glance.

And I probably wouldn't go back and remove the constants once they were named.

But I also have no problem with unnamed but commented constants like the ones in the comment you responded to.
by websiteapi | 2026-01-04 18:38:00+00:00
ridiculous.

> Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop

what have you shipped? paying sees literally hundreds of thousands of dollars a year to ship out fledged out software that no one wants is exactly why Stadia lasted both way too long and got cancelled anyway.

figuring out what is useful is the hardest problem. if anything that's Google's biggest problem, not shipping fast enough, not iterating fast enough.
by embedding-shape | 2026-01-04 18:38:03+00:00
> so Spotify may break the lookup of these IDs in the future.

Luckily, Spotify seems pretty good at backwards compatibility. `spotify:user:$username` still seems to work in the search-bar, must have worked for almost 20 years now, and given that artists themselves use those track URIs and IDs, I'm sure Spotify will be even more careful with those than search query syntax.
by mike_hearn | 2026-01-04 18:38:04+00:00
> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse.

There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock"

When I worked on user facing stuff (Maps, Gmail, Accounts) I regularly read the public user support forums and ticket queues looking for complaints, sometimes I even took part in user threads to get more information. What I learned was:

• Almost nobody else in engineering did this.

• I was considered weird for doing it.

• It was viewed negatively by managers and promo committees.

• An engineer talking directly to users was considered especially weird and problematic.

• The products did always have serious bugs that had escaped QA and monitoring.

In theory there were staff paid to monitor these forums, but in practice the eng managers paid little attention to them - think "user voice" reports once a quarter, that sort of thing. Partly that's because they weren't technical and often struggled to work out whether a user complaint was just noise or due to a genuine bug in the product, something often obvious to an engineer, so stuff didn't get escalated properly.

This general disconnection from the outside world was pervasive. When I joined the abuse team in 2010 I was surprised to discover that despite it having existed for many years, only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team. He gave me his logins and we quickly discovered spammers had found bugs in the accounts web servers they were using to blow past the antispam controls, without this being visible from any monitoring on our side. We learned many other useful things by doing this kind of "abuser research". But it was, again, very unusual. The team until that point had been dominated by ML-heads who just wanted to use it as a testing ground for model training.
by croemer | 2026-01-04 18:38:19+00:00
And have a look at the bio: https://addyosmani.com/bio/

> His story isn’t just about writing code, but about inspiring a community to strive for a better web. And perhaps the most exciting chapter is still being written, as he helps shape how AI and the web will intersect in the coming decade. Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come.
by ar_turnbull | 2026-01-04 18:38:21+00:00
As someone who always dabbled in code but never was a “real” developer, I’ve found the same thing. I know the concepts, I know good from bad — so all of a sudden I can vibe code things that would have taken me months of studying and debugging and banging my head against the wall.

If you’ll forgive a bit of self promotion, I also wrote some brief thoughts on my Adventures In AI Prototyping:

https://www.andrew-turnbull.com/adventures-in-ai-prototyping...
by chuckadams | 2026-01-04 18:38:51+00:00
Yah I suppose I should have said "you just can't make any assumptions about the filesystem layout" instead. You can always assume shells have a symlink in /bin, and there's another for /usr/bin/env, and that's about it. Programs that assume the system follows the FHS tend to break on other distributions too, but certainly will on Nix. That's where we end up using containers and VMs, or whatever smoke and mirrors act NixOS does for Steam.
by aeonik | 2026-01-04 18:39:06+00:00
There's very good evidence coming out of UC Davis.

they have MRIs, decent experimental evidence, and biochemical explanations.

They have published quite a few papers over the years.

You can start here, https://pmc.ncbi.nlm.nih.gov/articles/PMC9267994/

https://pmc.ncbi.nlm.nih.gov/articles/PMC5183725/

Look up Keith Baar.
by ajross | 2026-01-04 18:39:08+00:00
No one's. Everyone sucks. Find a product and you'll find a population collating complaints about it. Whining about interface design is like the cheapest form of shared currency in our subculture.

Fundamentally it's a bikeshed effect. Complaining about hard features like performance is likely to get you in trouble if you aren't actually doing the leg work to measure it and/or expert enough to shout down the people who show up to argue. But UI paradigms are inherently squishy and subjective, so you get to grouse without consequences.
by dxdm | 2026-01-04 18:39:28+00:00
I don't understand how you can read all this and conclude that people get the information they need.

In fact, your latest response is so far out that I've started to seriously wonder if you're trying to troll. If you aren't: sorry, just trying to tell you how this comes across as absurdly disconnected. If you are: you're bad at trolling, or a master at satire. Either way, I'm outta here.
by xaerise | 2026-01-04 18:39:32+00:00
This is busybox, not the general linux distros.

busybox in Alpine Linux has for example `ps` builtin. If you install ps with `apk add ps` to get the full version, it will remove the symlink for /bin/ps and replace it with the one you installed.

You need to read up on the purpose of busybox. It is not something that the kernel people has decided upon. It is an initiative of an group of people who needed some tools onto a single floppy.

/bin/ps on a Debian distro is 154522 bytes.
The whole busybox in Alpine Linux is 804616 bytes and contains a whole lot more than just ps.

https://en.wikipedia.org/wiki/BusyBox
https://busybox.net/
by Spivak | 2026-01-04 18:39:40+00:00
And it's not even good I can't understand what they're trying to do. I press the button occasionally just to mess with it and it has zero access to my data to do anything useful. Copilot in Outlook can't read my email, it's just a worse ChatGPT window sitting next to my email. What use-cases are you even imagining?
by rewgs | 2026-01-04 18:39:50+00:00
I'm with you. I've said it before, but: LLMs have made clear who does things for the process, and who does things for the result (obviously this is a spectrum, hardly anyone is 100% on either end).

The amount of people who apparently just want the end result and don't care about the process at all has really surprised me. And it makes me unfathomably sad, because (extremely long story short) a lot of my growth in life can be summed up as "learning to love the process" -- staying present, caring about the details, enjoying the journey, etc. I'm convinced that all that is essential to truly loving one's own life, and it hurts and scares me to both know just how common the opposite mindset is and to feel pressured to let go of such a huge part of my identity and dare-I-say soul just to remain "competitive."
by joduplessis | 2026-01-04 18:40:15+00:00
> 1. The best engineers are obsessed with solving user problems.

Complete bullshit. Sorry, but the reason why people use Google is because of the ecosystem + value proposition. Google Drive & Calendar are some of the most outdated pieces of SaaS software that only gets used because of the greater ecosystem they live in - and price. They (along with the other Google products) are also some of the poorest designed user interfaces online. Let's cut the crap for once here. If I were Google I would be worried because companies like Fastmail, Notion & Proton are quickly catching up.
by tzone | 2026-01-04 18:40:45+00:00
I think it depends on what counts as doing nothing. Every time I cut my hair, I sit in a chair for ~30minutes silently without doing anything. My barber knows I don't like small talk so he just cuts my hair and that's it, there is no conversation.

I would say it is very enjoyable 30 minutes every time I do it. I don't think anyone would describe that kind of experience as hard to do?
by magicalist | 2026-01-04 18:41:31+00:00
> This appears to be the guy who just posted all over social media that they just got Claude and redid a year long project in a week

It would take less time than it did to write this comment to look it up and see that these are two different people.

Google engineer [Jaana Dogan] says Claude Code built in one hour what her team spent a year on https://news.ycombinator.com/item?id=46477966
by Xmd5a | 2026-01-04 18:42:27+00:00
Oh. just to be clear first, I’m not the OP. Sorry for the confusion.

I do understand your point, and I think it’s a fair one: when someone claims to "recreate" something, it really helps readers to know how close the result is to the original, especially for people who don’t already understand the domain.

I was mostly reacting to the idea that faithfulness always has to be the primary axis of evaluation. In practice, only a subset of users actually care about 100% fidelity. For example with DSP plugins or NES emulators, many people ultimately judge them by how they sound or feel, especially when the original artifact is aesthetic in nature.

My own case is a bit different, but related. Even though I’m working on a sensor, having a perfectly accurate physical model of the material is secondary to my actual goal. What I’m trying to produce is an end result composed of a printable geometry, a neural model to interpret it, and calibration procedures. The physics simulator is merely a tool, not a claim.

In fact, if I want the design to transfer well from simulation to reality, it probably makes more sense to intentionally train the model across multiple variations of the physics rather than betting everything on a single "accurate" simulator. That way, when confronted with the real world, adaptation becomes easier rather than harder.

So I fully agree that clarity about "how close" matters when that’s the claim. I’m just suggesting that in some projects, closeness to the original isn’t always the most informative metric.

One reason I find my case illuminating is that it makes the "what metric are we optimizing?" question very explicit.

Sure, I can report proxy metrics (e.g. prediction error between simulated vs measured deformation fields, contact localization error, force/pressure estimation error, sensitivity/resolution, robustness across hysteresis/creep and repeated cycles). Those are useful for debugging.

But the real metric is functional: can this cheap, printable sensor + model enable dexterous manipulation without vision – tasks where humans rely heavily on touch/proprioception, like closing a zipper or handling thin, finicky objects – without needing $500/sq-inch "microscope-like" tactile sensors (GelSight being the canonical example)?

If it gets anywhere close to that capability with commodity materials, then the project is a success, even if no single simulator configuration is "the" ground truth.

What could OP’s next move be? Designing and building their own circuit. Likewise, someone who built a NES emulator might eventually try designing their own console. It doesn’t feel that far-fetched.
by ghaff | 2026-01-04 18:42:43+00:00
WRT Linux. Sure, 1991 or really even mid-90s Linux was clearly immature. But Wall Street was adopting it instead of Solaris by the turn of the century. Plus "open source" so it wasn't the case of a new proprietary Unix just emerging from the sea foam which no one wanted anyway but Linux becoming the good enough Unix standard which is what people did want.
by munificent | 2026-01-04 18:42:43+00:00
> after a few trips without disaster

100%.

Exposure therapy is the cure for anxiety. I have a personal hunch that part of the massive rise in anxiety in the world is explained by many of us no longer being regularly forced outside of our comfort zones. Before the Internet and smartphones, we were obligated to go into the unknown much more often. It was a constant mandatory exposure therapy.

Today, I can't remember the last time I walked into a restaurant without already having seen the inside on Google Maps, read several reviews on Yelp, and perused the menu online.