frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Quality of drinking water varies significantly by airline

https://foodmedcenter.org/2026-center-for-food-as-medicine-longevity-airline-water-study/
102•azinman2•4h ago•62 comments

Animated AI

https://animatedai.github.io/
35•frozenseven•4d ago•4 comments

A faster heart for F-Droid

https://f-droid.org/2025/12/30/a-faster-heart-for-f-droid.html
312•kasabali•9h ago•134 comments

FediMeteo: A €4 FreeBSD VPS Became a Global Weather Service

https://it-notes.dragas.net/2025/02/26/fedimeteo-how-a-tiny-freebsd-vps-became-a-global-weather-s...
242•birdculture•9h ago•57 comments

Readings in Database Systems (5th Edition)

http://www.redbook.io/
22•teleforce•2h ago•1 comments

Show HN: 22 GB of Hacker News in SQLite

https://hackerbook.dosaygo.com
388•keepamovin•11h ago•134 comments

A Vulnerability in Libsodium

https://00f.net/2025/12/30/libsodium-vulnerability/
231•raggi•11h ago•31 comments

Honey's Dieselgate: Detecting and tricking testers

https://vptdigital.com/blog/honey-detecting-testers/
148•AkshatJ27•6h ago•33 comments

OpenAI's cash burn will be one of the big bubble questions of 2026

https://www.economist.com/leaders/2025/12/30/openais-cash-burn-will-be-one-of-the-big-bubble-ques...
248•1vuio0pswjnm7•6h ago•329 comments

Zpdf: PDF text extraction in Zig – 5x faster than MuPDF

https://github.com/Lulzx/zpdf
142•lulzx•8h ago•52 comments

We don't need more contributors who aren't programmers to contribute code

https://discourse.llvm.org/t/rfc-llvm-ai-tool-policy-human-in-the-loop/89159
12•pertymcpert•1h ago•3 comments

Electrolysis can solve one of our biggest contamination problems

https://ethz.ch/en/news-and-events/eth-news/news/2025/11/electrolysis-can-solve-one-of-our-bigges...
131•PaulHoule•10h ago•37 comments

Loss32: Let's Build a Win32/Linux

https://loss32.org/
225•akka47•1d ago•324 comments

Toro: Deploy Applications as Unikernels

https://github.com/torokernel/torokernel
121•ignoramous•11h ago•105 comments

Mitsubishi Diatone D-160 (1985)

https://audio-database.com/MITSUBISHI-DIATONE/diatonesp/d-160-e.html
25•anigbrowl•2d ago•13 comments

Reverse Engineering a Mysterious UDP Stream in My Hotel (2016)

https://www.gkbrk.com/hotel-music
185•bayesnet•1w ago•25 comments

Non-Zero-Sum Games

https://nonzerosum.games/
346•8organicbits•16h ago•178 comments

What If Heavy Files Felt Heavy?

https://www.shiveesh.com/thoughts-and-ideas/what-if-heavy-files-actually-felt-heavy
6•shiveeshfotedar•5d ago•5 comments

Escaping containment: A security analysis of FreeBSD jails [video]

https://media.ccc.de/v/39c3-escaping-containment-a-security-analysis-of-freebsd-jails
68•todsacerdoti•9h ago•1 comments

Professional software developers don't vibe, they control

https://arxiv.org/abs/2512.14012
135•dpflan•8h ago•163 comments

The British empire's resilient subsea telegraph network

https://subseacables.blogspot.com/2025/12/the-british-empires-resilient-subsea.html
174•giuliomagnifico•15h ago•44 comments

Times New American: A Tale of Two Fonts

https://hsu.cy/2025/12/times-new-american/
231•firexcy•15h ago•139 comments

L1TF Reloaded

https://github.com/ThijsRay/l1tf_reloaded
9•Fnoord•2h ago•0 comments

Approachable Swift Concurrency

https://fuckingapproachableswiftconcurrency.com/en/
162•wrxd•15h ago•81 comments

Show HN: RAMBnB.xyz P2P marketplace for RAM rentals

https://www.rambnb.xyz
13•olivierroy•5h ago•2 comments

Go away Python

https://lorentz.app/blog-item.html?id=go-shebang
368•baalimago•19h ago•337 comments

Five Years of Tinygrad

https://geohot.github.io//blog/jekyll/update/2025/12/29/five-years-of-tinygrad.html
198•iyaja•1d ago•91 comments

Igniting the GPU: From Kernel Plumbing to 3D Rendering on RISC-V

https://mwilczynski.dev/posts/riscv-gpu-zink/
75•michalwilczynsk•14h ago•8 comments

What Happened to Abit Motherboards

https://dfarq.homeip.net/what-happened-to-abit-motherboards/
99•zdw•13h ago•68 comments

Netflix Open Content

https://opencontent.netflix.com/
616•tosh•18h ago•119 comments
Open in hackernews

Path is a utility for working with paths

https://gitlab.com/SpyrjaGaldr/path
60•spyrja•8mo ago
A recent post here got me thinking about my own personal gripes with OS path handling offerings. So I've basically spent the passed couple of days working on a little project in an attempt to rectify the situation somewhat (in the spirit of cross-platform development). It should also work pretty well with existing tools. Let me know what you think, and feel free to open an issue or a pull-request if you have any problems getting it running it on your system. Enjoy!

Github link: https://github.com/SpyrjaGaldr/path

https://simonsafar.com/2025/path_as_system_call/

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

Comments

vesinisa•8mo ago
What can this do that standard Unix find can not do?
autobodie•8mo ago
cross platform support, according to the description.
indemnity•8mo ago
fd exists https://github.com/sharkdp/fd
spyrja•8mo ago
Looks like it has a pretty good interface as well. It does however seem a just a bit too top-heavy (lot's of dependencies) not to mention a few more bugs than I particularly care for. But sheesh, 37K stars, it must be good for something!
blooalien•8mo ago
> ... "it must be good for something!"

It's good for finding files fast, and piping the resulting file paths into other tools for further action / handling. It does what it claims to do and does it well. :)

spyrja•8mo ago
I would say the default behaviour just isn't very ergonomic. Suppressing warnings for example requires piping to /dev/null (whereas `path` supresses permission warnings by default), if you want to limit the number of results you have to pipe the output to another command, getting xargs-like behaviour (obviously), or putting quotes around lines with embedded spaces, there are simply more hoops to jump through. It's much easier to type "path -sf .jpg .jpeg .png" than whatever would be required to get the `find` utility to do the same. (Or, say, finding all node_modules folders with "path -z n_m", it's just so much more satisfying.) But yes, these are mostly just syntactic-sugar kinds of issues. Aside from that (and perhaps the lack of cross-platform compatibility), I would say there is nothing inherently deficient about the `find` command. It's a work-horse which probably has more features than `path` does. But the latter really is growing on me. It is actually quite fun to use, if I may say so myself!
jimbokun•8mo ago
“A more ergonomic find command” is a nice elevator pitch.
pimlottc•8mo ago
From the name and description, I expected this to perform operations on file path strings, like convert relative to absolute (and vice versa), expand symlinks, convert unix paths to dos, etc. This is more like a find command.
spyrja•8mo ago
I don't see why it necessarily couldn't, my only question would be if there are really many actual use cases for such things? As far as symlinks go, I suppose being able to expand them (but not following them!) might be somewhat useful. But converting to DOS paths and vice-versa? That just doesn't seem very useful. Nevermind converting to-and-fro relative and absolute paths, I can't even imagine what the point of that would be. But perhaps I'm just not seeing the forest for the trees, as they say.
qrobit•8mo ago
As a rule of thumb I always make paths absolute when handling files in scripts. But then sometimes I need to copy a directory tree relative to $CWD somewhere else, so I convert them back to relative

Fish, being a great shell, provides this via `path` command[0]

[0]: https://fishshell.com/docs/current/cmds/path.html

jl6•8mo ago
> for the primary purpose of helping other programs know where to find stuff

Potential footgun to make a program rely on this to locate, say, a shared library (as in one of the examples), if there’s a possibility that someone has smuggled a malware’d version of it into, say, /tmp, since it defaults to searching the root directory.

spyrja•8mo ago
Kind of, but also kind of not. I mean if someone can smuggle a file into some random directory, chances are they have enough access to write directly to the "correct" folder to begin with. Personally I wouldn't execute or otherwise load any sort of executable content from a non-root directory (although certainly there are many people who wouldn't even think twice before doing such a thing). So it really just boils down to having a sane security-policy. Restrict searches with something like "path -d /usr *" and you are guaranteed not to scoop-up something that was world-writable in the first place. In fact in the example given in the README, that is precisely how that would have worked. Both /lib32 and /lib64 are owned by "root" and hence not a concern.
jl6•8mo ago
Naturally every footgun is guaranteed to be safe as long as you use it right :)

I wonder if a safer default would be to start searches at the current directory rather than the root directory?

spyrja•8mo ago
I did actually consider that at one point, but eventually decided against it because I felt would have meant a sacrifice in performance; first you'd do the local search, then start at the very top and recurse back down, checking every single entry against the local path to be sure that you don't do the local traversal all over again. Fortunately the code base is very clean and straight-forward, so it would be a fairly trivial excercise to just fork the repo and make those changes yourself to get that kind of behaviour.
spyrja•8mo ago
Well I ran a bunch of tests and it turns out that the performance wasn't actually impacted very much after all. So the changes are official. I also made some other adjustments to the default behaviour; if no pattern is specified then it just matches everything. In other words, "path -f" prints every regular file in the filesystem (starting in the current one). Anyway, thanks for the suggestion, otherwise I may not gone down that (decidedly satisfying) rabbit-hole!
account-5•8mo ago
I've been finding nushell's `ls` with a where clause is pretty good for this. There's also the `find` command too.