frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Open in hackernews

Modern Linux tools

https://ikrima.dev/dev-notes/linux/linux-modern-tools/
84•randomint64•3h ago

Comments

_ZeD_•2h ago
the second item is

exa modern replacement for ls/tree, not maintained

"not maintained" doesn't smell "modern" to me...

arccy•1h ago
like good open source, it's now forked by a community instead of having only a single maintainer

eza: https://github.com/eza-community/eza

abenga•1h ago
The README has an ad at the top.

Yeeeah, nope.

CaptainOfCoit•50m ago
For a cloud-based terminal emulator that heavily focuses on AI none the less. And they have the stomach to call it "for developers".
selectnull•33m ago
The tool itself has no ads. What's wrong with a README having an ad?
Hendrikto•1h ago
Literally the next line lists its replacement eza.
throw_a_grenade•1h ago
On the contrary, that's exactly what “modern” sounds like. I wonder when all those tools will go unmaintained. Coreutils, with all their problems, are maintained since before authors of many listed tools were born.
JohnKemeny•1h ago
That's the Lindy effect: old tools like ls last because they've already lasted, while modern ones often don’t stick around long enough to.

    the future life expectancy is proportional to its current age
https://en.wikipedia.org/wiki/Lindy_effect
bieganski•2h ago
i wish there was an additional column in the table, that says "what problem does it solve". oh, and 'it's written in rust' does not count.
oneeyedpigeon•1h ago
Many of the entries do include this detail — e.g. "with syntax highlighting", "ncurses interface", and "more intuitive". I agree that "written in rust", "modern", and "better" aren't very useful!
account42•39m ago
Some of this just makes me think that they are compared against the wrong tool though. E.g.

> cat clone with syntax highlighting and git integration

doesn't make any sense because cat is not really meant for viewing files. You should be comparing your tool with the more/less/most family of tools, some of which can already do syntax highlighting or even more complex transforms.

oneeyedpigeon•27m ago
Yup, I made that same point in another comment. Out of interest, though, how do you get syntax highlighting from any of those pagers? None of them give it to me out of the box.
drob518•1h ago
“It’s written in Rust”

Actual LOL. Indeed. I was working for a large corporation at one point and a development team was explaining their product. I asked what its differentiators were versus our competitors. The team replied that ours was written in Go. #faceplam

IshKebab•55m ago
That is a differentiator if your competitors are written in Python or Ruby or Bash or whatever. But yeah obviously for marketing to normal people you'd have to say "it's fast and reliable and easy to distribute" because they wouldn't know that these are properties of Go.
account42•42m ago
You can write slow unmaintainable brittle garbage in any language though. So even if your competition is literally written in Bash or whatever you should still say what your implementation actually does better - and if it's performance, back it up with something that lets me know you have actually measured the impact on real world use cases and are not just assuming "we wrote it in $language therefore it must be fast".
drob518•38m ago
No. The differentiator is whatever benefits such an implementation might deliver (e.g., performance, reliability, etc.). Customers don’t start whipping out checkbooks when you say, “Ours is written in Go.”
maeln•31m ago
That is what the post you responding to is saying
demetris•24m ago
The Rust rewrites can become tiresome, they have become a meme at this point, but there are really good tools there too.

An example from my personal experience: I used to think that oxipng was just a faster optipng. I took a closer look recently and saw that it is more than that.

See: https://op111.net/posts/2025/09/png-compression-oxipng-optip...

pasc1878•56m ago
Also using a non GPL license does not count.
Otek•1h ago
This is 2023 article. As with most “modern tools” half of them probably already have some newer, shinier and more trendy replacements
oneeyedpigeon•1h ago
There's a lot of tools here. Half still leaves plenty of value.
Scotrix•1h ago
would be good to have an indicator if it’s available with your distro by default or what package you’ll need to install it since all tools are only as useful as available they are…
0x37•1h ago
These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere.

Learn the classic tools, learn them well, and your life will be much easier.

andai•1h ago
I wanted to say we should just stick with what Unix shipped forever. But doesn't GNU already violate that idea?
drob518•1h ago
Well, even “Unix” had some differences (BSD switches vs SysV switches). Theoretically, POSIX was supposed to smooth that out, but it never went away. Today, people are more likely to be operating in a GNU Linux environment than anything else (that just a market share fact, not a moral judgement, BSD lovers). Thus, for most people, GNU is the baseline.
imcritic•59m ago
IMO this is very stupid: don't let past dictate future. UNIX is history. History is for historians, it should not be the basis that shapes the environment for engineers living in present.
mprovost•38m ago
The point is that we always exist at a point on a continuum, not at some fixed time when the current standard is set in stone. I remember setting up Solaris machines in the early 2000s with the painful SysV tools that they came with and the first thing you would do is download a package of GNU coreutils. Now those utils are "standard", unless of course you're using a Mac. And newer tools are appearing (again, finally) and the folk saying to just stick with the GNU tools because they're everywhere ignore all of the effort that went into making that (mostly) the case. So yes, let's not let the history of the GNU tools dictate how we live in the present.
samcat116•1h ago
For some people the "uphill battle" is the fun part
pjmlp•1h ago
I know well enough my way around vi, because although XEmacs was my editor during the 1990's when working on UNIX systems, when visiting customers there was a very high probability that they only had ed and vi installed on their server systems.

Many folks nowadays don't get how lucky they are, not having to do UNIX development on a time-sharing system, although cloud systems kind of replicate the experience.

landgenoot•1h ago
This is how I feel as well. Spend some time "optimizing" my CLI with oh my zshell etc. when I was young.

Only to feel totally handicapped when logging in into a busybox environment.

I'm glad I learned how to use vi, grep, sed..

My only change to an environment is the keyboard layout. I learned Colemak when I was young. Still enjoying it every day.

UltraSane•1h ago
"I don't want to be a product of my environment. I want my environment to be a product of me."
pbduring•1h ago
so right.
oneeyedpigeon•1h ago
> Learn the classic tools, learn them well, and your life will be much easier.

Agreed, but that doesn't stop you from using/learning alternatives. Just use your preferred option, based on what's available. I realise this could be too much to apply to something like a programming language (despite this, many of us know more than one) or a graphics application, but for something like a pager, it should be trivial to switch back and forth.

acomjean•37m ago
And when those classic tools need a little help:

Awk and sed.

I like the idea of new tools though. But knowing the building blocks is useful. The “Unix power tools” book was useful to get me up to speed.. there are so many of these useful mini tools.

Miller is one I’ve made use of (it also was available for my distro)

skydhash•1h ago
I do prefer some of these tools, due to a much better UX, but the only one I do install in every unix box is ripgrep.
bonoboTP•1h ago
Some people spend the vast majority of their time on their own machine. The gains of convenience can be worth it. And they know enough of the classic tools that it's sufficient in the rare cases when working on another server.

Not everybody is a sysadmin manually logging into lots of independent, heterogeneous servers throughout the day.

CaptainOfCoit•56m ago
Yeah, this is basically what I do. One example: using neovim with bunch of plugins as a daily driver, but whenever I enter a server that doesn't have it nor my settings/plugins, it isn't a huge problem to run vim or even vi, most stuff works the same.

Same goes for a bunch of other tools that have "modern" alternatives but the "classic" ones are already installed/available on most default distribution setups.

lucasoshiro•1h ago
> that if you ever change your OS installation

apt-get/pacman/dnf/brew install <everything that you need>

You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS.

> or SSH anywhere

When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example.

> even use a mix of these on my personal computer and the traditional ones elsewhere

I can't see the problem, really. I use some of those tools and they are convenient, but it doesn't matter that I can't work without that. For example, bat: it doesn't replace cat, it only outputs data with syntax highlight, makes my life easier but if I don't have it, ok.

MarsIronPI•34m ago
> You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS.

The point is that sometimes you're SSHing to a lightweight headless server or something and you can't (or can't easily) install software.

kokada•1h ago
One of the reasons I really like Nix, my setup works basically everywhere (as long the host OS is either Linux or macOS, but those are the only 2 environments that I care). I don't even need root access to install Nix since there are multiple ways to install Nix rootless.

But yes, in the eventual case that I don't have Nix I can very much use the classic tools. It is not a binary choice, you can have both.

GuB-42•1h ago
I have some of these tools, they are not "objectively superior". A lot of them make things prettier with colors, bargraphs, etc... It is nice on a well-configured terminal, not so much in a pipeline. Some of them are full TUIs, essentially graphical tools that run in a terminal rather than traditional command line tools.

Some of them are smart but sometimes I want dumb, for example, ripgrep respects gitignore, and often, I don't want that. Though in this case, there is an option to turn it off (-uuu). That's a common theme with these tools too, they are trying to be smart by default and you need option to make them dumb.

So no, these tools are not "objectively superior", they are generally more advanced, but it is not always what you need. They complement classic tools, but in no way replace them.

kombine•59m ago
I started a new job and spent maybe a day setting up the tools and dotfiles on my development machine in the cloud. I'm going to keep it throughout my employment so it's worth the investment. And I install most of the tools via nix package manager so I don't have to compile things or figure out how to install them on a particular Linux distribution. L
trebligdivad•39m ago
Agreed, but some are nice enough that I'll make sure I get them installed where I can. 'ag' is my go to fast grep, and I get it installed on anything I use a lot.
tmountain•34m ago
Some are so vastly better that it's worth whatever small inconvenience comes with getting them installed. I know the classic tools very well, but I'll prefer fd and ripgrep every time.
dbacar•22m ago
+100
snide•1h ago
Small note that a lot of these tool makers allow sponsorship on GitHub. I use bat / fd almost every day. Happy to support https://github.com/sponsors/sharkdp#sponsors
fergie•1h ago
I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars.

I genuinely don't know what is going on here.

oneeyedpigeon•1h ago
The core Unix toolset is so good, that you can easily get by with it. Many of these tools are better, but still not necessary, and they certainly aren't widely available by default.
account42•36m ago
They tend to be popular with the "rewrite it in rust/go" crowd as far as I can tell. Or in other words, you are no longer part of the cool kids.
maeln•26m ago
> I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars.

> I genuinely don't know what is going on here.

I basically live in my music library. However, every single pop artist offers songs that I don't like, are not in my library, and mysteriously have many millions of albums sold.

I genuinely don't know what is going on here.

Joking aside, have you ever tried to use some of these tools ? I use to not understand why people where using vim until I really tried.

fergie•13m ago
> Joking aside, have you ever tried to use some of these tools

No.

> I use to not understand why people where using vim until I really tried.

There's your problem. I respectfully suggest installing Emacs.

robenkleene•21m ago
Out of curiosity, how would you recursively grep files ignoring (hidden files [e.g., `.git`]), only matching a certain file extension? (E.g., `rg -g '*.foo' bar`.)

I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools.

(And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I obviously don't want], e.g., `fd '.foo.*'`.)

fergie•16m ago
grep -ri foo ./*

Hits in hidden files is not really a pain point for me

robenkleene•10m ago
Curious if that answers the "I genuinely don't know what is going on here" then? Not searching hidden files (or third-party dependencies, which `rg` also does automatically with its ignore parsing) isn't just a nice to have, it's mandatory for a number of tasks a software engineer might be performing on a code base?
hrimfaxi•4m ago
That doesn't apply to the very specific case for which the parent asked a solution.
MontyCarloHall•8m ago
Depends on how big the directory is. If it only contains a few files, I'd just enumerate them all with `find`, filter the results with `grep`, and perform the actual `grep` for "bar" using `xargs`:

   find . -type f -name "*.foo" | grep -v '/\.' | xargs grep bar
(This one I could do from muscle memory.)

If traversing those hidden files/directories were expensive, I'd tell `find` itself to exclude them. This also lets me switch `xargs` for `find`'s own `-exec` functionality:

   find . -type f -not -path '*/\.*' -name "*.foo" -exec grep bar {} +
(I had to look that one up.)
anthk•1h ago
Modern doesn't always mean better. A better replacement for mplayer was mpv, and in some cases mplayer was faster than mpv (think about legacy machines).

   - bat it's a useless cat. Cat concatenates files. ANSI colour breaks that.

   - alias ls='ls -Fh' , problem solved. Now you have * for executables, / for directories and so on.

   - ncdu it's fine, perfect for what it does

   - iomenu it's much faster than fzf and it almost works the same

   - jq it's fine, it's a good example on a new Unix tool

   - micro it's far slower than even vim

   - instead of nnn, sff https://github.com/sylphenix/sff with soap(1) (xdg-open replacement) from https://2f30.org create a mega fast environment. Add MuPDF and sxiv, and nnn and friends will look really slow compared to these.
Yes, you need to set config.h under both sff and soap, but they will run much, much faster than any Rust tool on legacy machines.
oneeyedpigeon•1h ago
> bat it's a useless cat. Cat concatenates files. ANSI colour breaks that.

It's useless as a cat replacement, I agree. The article really shouldn't call it that, although the program's GitHub page does self-describe it as "a cat clone". It's more of a syntax highlighter combined with a git diff viewer (I do have an issue with that; it should be two separate programs, not one).

lucasoshiro•1h ago
> bat it's a useless cat

I can't see bat as a "useless cat" or a replacement for cat except for reading source code in the terminal. It's more a like a less with syntax highlight or a read-only vim.

ed_blackburn•1h ago
I agree with this. cat is great for "cating" bat is great for throwing shit on the terminal in a fashion that makes it semantically easier to reason with, two different use cases.
drob518•43m ago
Part of the problem is “naming/marketing.” Bat compares ITSELF to cat, not to more/less. IMO, this confuses the issue.
PaulKeeble•1h ago
duf is pretty good for drive space, has some nice colours and graphs. But its also not as useful for feeding into other tools.

btop has been pretty good for watching a machine to get an overview of everything going on, the latest version has cleaned up how the lazy CPU process listing works.

zoxide is good for cding around the system to the same places. It remembers directories so you avoid typing full paths.

ed_blackburn•1h ago
I’m on a Mac, and some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions. Rather than replace or fight against the system tools, I supplement them with a few extras. Honestly, most are marginal upgrades over what macOS ships with, except for fzf, which is a huge productivity boost. Fuzzy-finding through my shell history or using interactive autocompletion makes a noticeable difference day to day.
MontyCarloHall•1h ago
>some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions

That’s because they’re not GNU coreutils, they’re BSD coreutils, which are spartan by design. (FWIW, this is one of my theories for why Linux/GNU dominated BSD: the default user experience of the former is just so much richer, even though the system architecture of the latter is arguably superior.)

demetris•43m ago
Many are available on Windows too.

I know I have hyperfine, fd, and eza on my Windows 11, and maybe some more I cannot remember right now.

They are super easy to install too, using winget.

maeln•35m ago
Every time such a list is posted, it tends to generate a lot of debate, but I do think there is at least 2 tools that are really a good addition to any terminal :

`fd`: first I find that the argument semantic is way better than `find`, but that is more a bonus than a real killer feature. Now, it being much, much faster than `find` on most setup, I would consider a valuable feature. But the killer feature for me is the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one line : `fd -e jpg -x cjxl {} {.}.jxl`

`rg` a.k.a `ripgrep` : Honestly it is just about the speed. It is so much faster than `grep` when searching through a directory, it opens up a lot of possibilities. Like, searching for `isLoading` on my frontend (~3444 files) is instant with rg (less than 0.10s) but takes a few minutes with grep.

But there is one other thing that I really like with `ripgrep` and that I think should be a feature of any "modern" CLI tool : It can format its output in JSON. Not that I am a big fan of JSON, but at least it is a well-defined exchange format. "Classic" CLI tool just output in a "human-readable" format which might just happen to be "machine-readable" if you mess with `awk` and `sed` enough. But it makes piping and scripting just that much more annoying and error & bug prone. Being able to output json, `jq` it and feed it to the next tool is so much better and feel like the missing chain of the terminal.

The big advantage of the CLI is that it is composable and scriptable by default. But it is missing a common exchange format to pass data, and this is what you have to wrangle with a lot of time when scripting. Having json, never mind all the gripes I have with this format, really join everything together.

Also, honorable mention for `zellij` which I find to be a much saner UX-wise alternative to `tmux`, and the `helix` text editor, which for me is neo-vim but with, again, a better UX (especially for beginner) and a lot more battery included feature while remaining faster (IMEX) than nvim with matching plugin for feature-parity.

EDIT: I would also add difftastic ( https://github.com/Wilfred/difftastic ) which is a syntax aware diff tool. I don't use it much, but it does makes some diff so so much easier to read.

[0] https://github.com/sharkdp/fd?tab=readme-ov-file#placeholder...

rkomorn•27m ago
I briefly resisted the notion that fd and ripgrep were useful when a friend suggested them.

Then I tried them and it was such a night and day performance difference that they're now immediate installs on any new system I use.

Izkata•27m ago
> But the killer feature for me is the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one line : `fd -e jpg -x cjxl {} {.}.jxl`

That was inherited from find, it has "-exec". Even uses the same placeholder, {}, though I'm not sure about {.}

maeln•25m ago
`find` only support `{}`, it does not support `{/}`, `{//}`, `{.}` etc, which is why you often need to do some parsing magic to replicate basic thing such has "the full path without the extension`, `only the filename without the extension` etc
foofoo12•18m ago
Make sure to check out f2, the batch renaming CLI tool. It's perfectly honed and lubricated magic: https://github.com/ayoisaiah/f2

Got featured here on HN few weeks ago.

sigio•16m ago
As someone who logs into hundreds of servers in various networks, from various customers/clients, there is so little value in using custom tooling, as they will not be available on 90% of the systems.

I have a very limited set of additional tools I tend to install on systems, and they are in my default ansible-config, so will end up on systems quickly, but I try to keep this list short and sweet.

95% of the systems I manage are debian or ubuntu, so they will use mostly the same baseline, and I then add stuff like ack, etckeeper, vim, pv, dstat.

arminiusreturns•7m ago
Another reason emacs as an OS (not fully, but you know) is such a great way to get used to things you have on systems. Hence the quote: "GNU is my operating system, linux is just the current kernel".

As a greybeard linux admin, I agree with you though. This is why when someone tells me they are learning linux the first thing I tell them is to just type "info" into the terminal and read the whole thing, and that will put them ahead of 90% of admins. What I don't say is why: Because knowing what tooling is available as a built-in you can modularly script around that already has good docs is basically the linux philosophy in practice.

Of course, we remember the days where systems only had vi and not even nano was a default, but since these days we do idempotent ci/cd configs, adding a tui-editor of choice should be trivial.

oslem•16m ago
I always enjoy these lists. I think most folks out there could probably successfully adopt at least one or two of these tools. For me, that’s ripgrep and jq. The former is a great drop-in replacement for grep and the latter solves a problem I needed solving. I’ll try out a few of the others on this list, too. lsd and dust both appeal to me.

I just enjoy seeing others incrementally improve on our collective tool chest. Even if the new tool isn’t of use to me, I appreciate the work that went into it. They’re wonderful tools in their own right. Often adding a few modern touches to make a great tool just a little bit better.

Thank you to those who have put in so much effort. You’re making the community objectively better.

arminiusreturns•1m ago
[delayed]

The Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel 2025

https://www.nobelprize.org/prizes/economic-sciences/2025/summary/
25•k2enemy•1h ago•8 comments

Spotlight on pdfly, the Swiss Army knife for PDF files

https://chezsoi.org/lucas/blog/spotlight-on-pdfly.html
131•Lucas-C•4h ago•42 comments

Matrices can be your Friends

https://www.sjbaker.org/steve/omniv/matrices_can_be_your_friends.html
34•todsacerdoti•2h ago•17 comments

American solar farms

https://tech.marksblogg.com/american-solar-farms.html
93•marklit•3h ago•67 comments

More random home lab things I've recently learned

https://chollinger.com/blog/2025/10/more-homelab-things-ive-recently-learned/
30•otter-in-a-suit•1w ago•3 comments

Clockss: Digital preservation services run by academic publishers and libraries

https://clockss.org/
22•robtherobber•5d ago•6 comments

Wireguard FPGA

https://github.com/chili-chips-ba/wireguard-fpga
566•hasheddan•20h ago•137 comments

US Junk Bonds Post Worst Losses in Six Months, Spreads Widen

https://www.bloomberg.com/news/articles/2025-10-13/us-junk-bonds-post-worst-losses-in-six-months-...
32•zerosizedweasle•1h ago•13 comments

Some graphene firms have reaped its potential but others are struggling

https://www.theguardian.com/business/2025/oct/13/lab-to-fab-are-promises-of-a-graphene-revolution...
33•robaato•4h ago•10 comments

Putting a dumb weather station on the internet

https://colincogle.name/blog/byo-weather-station/
74•todsacerdoti•5d ago•15 comments

LaTeXpOsEd: A Systematic Analysis of Information Leakage in Preprint Archives

https://arxiv.org/abs/2510.03761
32•oldfuture•4h ago•11 comments

Modern Linux tools

https://ikrima.dev/dev-notes/linux/linux-modern-tools/
84•randomint64•3h ago•73 comments

Switch to Jujutsu Already: A Tutorial

https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/
18•birdculture•3h ago•14 comments

Tauri binding for Python through Pyo3

https://github.com/pytauri/pytauri
126•0x1997•5d ago•34 comments

Making regular GPS ultra-precise

https://norwegianscitechnews.com/2025/10/making-regular-gps-ultra-precise/
21•giuliomagnifico•6d ago•20 comments

Jeffrey Hudson the Court Dwarf of the English Queen Henrietta Maria of France

https://en.wikipedia.org/wiki/Jeffrey_Hudson
30•daverol•5d ago•11 comments

Ask HN: What are you working on? (October 2025)

264•david927•17h ago•725 comments

MicroPythonOS – An Android-like OS for microcontrollers

https://micropythonos.com
131•alefnula•4d ago•34 comments

Two Paths to Memory Safety: CHERI and OMA

https://ednutting.com/2025/10/05/cheri-vs-oma.html
8•yvdriess•3h ago•4 comments

Control your Canon Camera wirelessly

https://github.com/JulianSchroden/cine_remote
3•nklswbr•5d ago•0 comments

Nobel Prize in Economic Sciences 2025

https://www.nobelprize.org/prizes/economic-sciences/2025/popular-information/
7•pykello•3h ago•1 comments

Show HN: Baby's first international landline

https://wip.tf/posts/telefonefix-building-babys-first-international-landline/
164•nbr23•4d ago•46 comments

gsay: Fetch pronunciation of English vocabulary from Google

https://github.com/pvonmoradi/gsay
7•pooyamo•3h ago•0 comments

MPTCP for Linux

https://www.mptcp.dev/
12•SweetSoftPillow•3h ago•1 comments

HTTP3 Explained

https://http3-explained.haxx.se
104•weinzierl•6h ago•48 comments

Three ways formally verified code can go wrong in practice

https://buttondown.com/hillelwayne/archive/three-ways-formally-verified-code-can-go-wrong-in/
150•todsacerdoti•1d ago•89 comments

Emacs agent-shell (powered by ACP)

https://xenodium.com/introducing-agent-shell
195•Karrot_Kream•16h ago•26 comments

Bird photographer of the year gives a lesson in planning and patience

https://www.thisiscolossal.com/2025/09/2025-bird-photographer-of-the-year-contest/
154•surprisetalk•1w ago•33 comments

We need (at least) ergonomic, explicit handles

https://smallcultfollowing.com/babysteps/blog/2025/10/13/ergonomic-explicit-handles/
9•emschwartz•1h ago•0 comments

3D-Printed Automatic Weather Station

https://3dpaws.comet.ucar.edu
87•hyperbovine•3d ago•18 comments