Show HN: Lstr – A modern, interactive tree command written in Rust

227•w108bmg•7mo ago

Hi HN,

(First time poster!)

I'm the author of `lstr`. I've always loved the classic Linux `tree` command for its simplicity, but I often found myself wanting more modern features like interactivity and Git integration. So, I decided to build my own version in Rust with a philosophy of being fast, minimalist, and interactive. It was also an excuse to help learn more about Rust\!

Here's a quick look at the interactive mode:

https://raw.githubusercontent.com/bgreenwell/lstr/main/asset...

I've just released v0.2.0 with some features I think this community might find useful:

  * **Interactive TUI Mode:** You can launch it with `lstr interactive`. It allows for keyboard-driven navigation, expanding/collapsing directories, and opening files in your default editor.
  * **Git Status Integration:** Using the `-G` flag, `lstr` will show the Git status of every file and directory right in the tree output.
  * **Shell Integration:** This is my favorite feature. In interactive mode, you can press `Ctrl+s` to quit and have `lstr` print the selected path to stdout. This lets you pipe it into other commands or use it as a visual `cd`. For example, you can add this function to your `.bashrc`/`.zshrc`:
    ```bash
    lcd() {
        local selected_path
        selected_path="$(lstr interactive -gG)"
        if [[ -n "$selected_path" && -d "$selected_path" ]]; then
            cd "$selected_path"
        fi
    }
    ```
    Then just run `lcd` to visually pick a directory and jump to it.

It also supports file-type icons (via Nerd Fonts), file sizes, permissions, and respects your `.gitignore`.

The project is open-source and I would love to get your feedback.

GitHub: https://github.com/bgreenwell/lstr

Crates.io: https://crates.io/crates/lstr

Thanks for checking it out!

Comments

aystatic•7mo ago

Neat, looks like a combination of erdtree[0] and broot[1]. I use both on a daily basis, are there any features that stand out from the two?

[0]: https://github.com/solidiquis/erdtree [1]: https://github.com/Canop/broot

drabbiticus•7mo ago

First off, the display looks great!

Second off, I didn't realize how deep the dep tree would be for this type of program -- 141 total! So much of it is the url crate, itself a dep of the git crate, but there's a bunch of others too. I'm just getting into learning Rust -- is this typical of Rust projects or perhaps typical of TUI projects in general?

(EDIT to strikeout) ~~The binary is also 53M as a result whereas /usr/sbin/tree is 80K on my machine -- not really a problem on today's storage, but very roughly 500-1000x different in size isn't nothing.~~

Maybe it's linking-related? I don't know how to check really.

(EDIT: many have pointed out that you can run `cargo build --release` with other options to get a much smaller binary. Thanks for teaching me!)

CGamesPlay•7mo ago

Likely needs features tuned. I compared Eza, similarly in Rust, and it's 1.6 MiB compiled. Looking at the Cargo.toml, it includes git2 with default-features = false. https://github.com/eza-community/eza/blob/main/Cargo.toml

fabrice_d•7mo ago

You are probably looking at a debug build. On Linux, a release build (cargo build -r) is ~4.3M, and down to ~3.5M once stripped. This could be reduced further with some tricks applied to the release build profile.

pveierland•7mo ago

Building in release:

  cargo build --release
  du -sh ./target/release/lstr -> 4.4M

Building with other release options brings it down to 2.3M:

  [profile.release]
  codegen-units = 1
  opt-level = "s"
  lto = true
  panic = "abort"
  strip = "symbols"

cyann•7mo ago

I did some benchmarks on one of our CLI and found that `opt-level = "z"` reduced the size from 2.68M to 2.28M, and shaved 10% on the build time, worth a try.

I'll try with `panic = "abort"` for our next release, thanks for the reminder.

JoshTriplett•7mo ago

> The binary is also 53M

That's a debug binary, and the vast majority of that is debug symbols. A release build of this project is 4.3M, an order of magnitude smaller.

Also, compiling out the default features of the git2 crate eliminates several dependencies and reduces it further to 3.6M.

https://github.com/bgreenwell/lstr/pull/5

https://github.com/rust-lang/git2-rs/pull/1168

Stripping the binary further improves it to 2.9M, and some further optimizations get it to 2.2M without any compromise to performance. (You can get it smaller by optimizing for size, but I wouldn't recommend that unless you really do value size more than performance.)

esafak•7mo ago

No offense, but 4.3MB is huge for what it does. Most shells take less space than that! Where's all the bloat coming from?

have-a-break•7mo ago

I feel like that's just the result of having a native package manager making natural bloat and a compiler which hasn't had decades of work.

o11c•7mo ago

For reference, some statically-linked shells on my system:

  2288K   /bin/bash-static (per manual, "too big and too slow")
  1936K   /bin/busybox-static (including tools not just the shell)
  192K    /usr/lib/klibc/bin/mksh
  2456K   zsh-static

For comparison, some dynamically-linked binaries (some old)

  804K    ./bin/bash-3.2
  888K    ./bin/bash-4.0
  908K    ./bin/bash-4.1
  956K    ./bin/bash-4.2
  1016K   ./bin/bash-4.3
  1092K   ./bin/bash-4.4
  1176K   ./bin/bash-5.0
  1208K   ./bin/bash-5.1
  1236K   /bin/bash (5.2)
  124K    /bin/dash
  1448K   /bin/ksh93 (fattest when excluding libc!)
  292K    /bin/mksh
  144K    /bin/posh
  424K    /bin/yash
  848K    /bin/zsh

(The reason I don't have static binaries handy is because they no longer run on modern systems. As long as you aren't using shitty libraries, dynamic binaries are more portable and reliable, contrary to internet "wisdom".)

JoshTriplett•7mo ago

Among the features it has: an interactive terminal GUI, threaded parallel directory walking, and git repository support. In around a thousand lines of code, total, including tests, half of which is the GUI.

oguz-ismail•7mo ago

*TUI. Not GUI

koito17•7mo ago

> Most shells take less space than that!

Most shells dynamically link to a runtime your OS provides "for free". The 4.3 MiB binary in question is bundling the Rust runtime and its dependencies.

For reference, a statically-compiled C++ "Hello, World" is 2.2 MiB after stripping.

  % cat hello.nix
  {
    pkgs ? import <nixpkgs> { crossSystem = "aarch64-linux"; }
  }:
  
  pkgs.stdenv.mkDerivation {
    name = "hello-static";
    src = pkgs.writeText "hello.cpp" ''
      #include <iostream>
      int main() {
        std::cout << "Hello, World!" << std::endl;
        return 0;
      }
    '';
    dontUnpack = true;
    buildInputs = [ pkgs.glibc.static ];
    buildPhase = "$CXX -std=c++17 -static -o hello $src";
    installPhase = "mkdir -p $out/bin; cp hello $out/bin/";
  }
  
  % nix-build hello.nix
  ...
  
  % wc -c result/bin/hello
  2224640 result/bin/hello

esafak•7mo ago

2.2MiB for "Hello, World"? I must be getting old...

The executable takes 33KB in C, 75KB in nim.

koito17•7mo ago

By switching to e.g. musl, you can go down to a single megabyte ;)

But in all seriousness, my example is quite cherrypicked, since nobody will actually statically link glibc. And even if they did, one can make use of link-time optimization to remove lots of patches of unused code. Note that this is the same strategy one would employ to debloat their Rust binaries. (Use LTO, don't aggressively inline code, etc.)

3836293648•7mo ago

Just a `puts("Hello world!")` with -Os statically linked to musl is 22k

3836293648•7mo ago

We just have large standard libraries now

surajrmal•7mo ago

lto will remove most of it.

AdieuToLogic•7mo ago

Just for fun, I wondered how small a canonical hello world program could be in macOS running an ARM processor. Below is based on what I found here[0] with minor command-line switch alterations to account for a newer OS version.

ARM64 assembly program (hw.s):

  //
  // Assembler program to print "Hello World!"
  // to stdout.
  //
  // X0-X2 - parameters to linux function services
  // X16 - linux function number
  //
  .global _start             // Provide program starting address to linker
  .align 2

  // Setup the parameters to print hello world
  // and then call Linux to do it.

  _start: mov X0, #1     // 1 = StdOut
          adr X1, helloworld // string to print
          mov X2, #13     // length of our string
          mov X16, #4     // MacOS write system call
          svc 0     // Call linux to output the string

  // Setup the parameters to exit the program
  // and then call Linux to do it.

          mov     X0, #0      // Use 0 return code
          mov     X16, #1     // Service command code 1 terminates this program
          svc     0           // Call MacOS to terminate the program

  helloworld:      .ascii  "Hello World!\n"

Assembling and linking commands:

  as -o hw.o hw.s &&
  ld -macos_version_min 14.0.0 -o hw hw.o -lSystem -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -e _start -arch arm64

Resulting file sizes:

  -rwxr-xr-x  1 <uid>  <gid>    16K Jun 18 21:23 hw
  -rw-r--r--  1 <uid>  <gid>   440B Jun 18 21:23 hw.o
  -rw-r--r--  1 <uid>  <gid>   862B Jun 18 21:21 hw.s

0 - https://smist08.wordpress.com/2021/01/08/apple-m1-assembly-l...

creatonez•7mo ago

> The executable takes 33KB in C, 75KB in nim.

Did you statically link Glibc...? Or is this with a non-GNU libc?

Either way, it probably is true that this 2.2MiB number would be smaller on, say, Debian 5. And much smaller on PDP Unix.

wahern•7mo ago

> Most shells dynamically link to a runtime your OS provides "for free"

Rust binaries also dynamically link to and rely on this runtime.

mtndew4brkfst•7mo ago

That's not intrinsically or pervasively true, although it's not uncommon.

wahern•7mo ago

Unless the majority of Rust builds on Linux statically link musl libc or use no_std, then it's pervasively true. And it's true on most non-Linux targets, including the BSDs and macOS. It's the same situation with Go.

3836293648•7mo ago

The only way to avoid it is to be on linux with no_std, use musl statically or be on embedded. You cannot (or at least are supposed to not be able to) link to glibc statically and on every other OS you can only call syscalls via the system libraries. (Well, technically you can on most systems, it's just not stable across updates. OpenBSD will actively block it though)

creatonez•7mo ago

Yes. The main areas where Rust code uses dynamic linking by default are Glibc and OpenSSL (through the popular `native-tls` crate). Most things outside of that will be statically linked by default. There is room to improve the situation by making more C wrapper libraries support either method.

For Rust code talking to Rust libraries (such as `std`), it's a totally different challenge, similar to what you face in C++. You can compile your pure Rust app in a way to divide it up into DLLs. The problem is that the polymorphism in Rust means these DLLs must all be built together. Calling a polymorphic function means code has to be generated for it. The only way around this is for your Rust library to speak the C ABI, which bloats code as building your C-style API surface will resolve all the polymorphized functions/structs, but at least gets you swappable dynamic linking.

fuzztester•7mo ago

why did you embed the c++ code in the .nix file?

just to have everything in one file? how to show how to do it with nix?

because it seem simpler to have a separate C++ file, and a simple shell script or makefile to compile it.

e.g. although I could figure out roughly what the .nix file does, many more people would know plain unix shell than nix.

and where is $out defined in the .nix file?

AnthOlei•7mo ago

The nix file is besides the point - it gives you a totally hermetic build environment. Not OP, but it’s the only way I know how to get gcc to use a static glibc. All you should pay attention to is that it’s using a static glibc.

$out is a magic variable in nix that means the output of the derivation - the directory that nix moves to its final destination

fuzztester•7mo ago

thanks.

JoshTriplett•7mo ago

> Not OP, but it’s the only way I know how to get gcc to use a static glibc.

    /tmp$ gcc -O3 test.c -o test
    /tmp$ ldd test
     linux-vdso.so.1 (0x00007f3d9fbfe000)
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3d9f9e8000)
     /lib64/ld-linux-x86-64.so.2 (0x00007f3d9fc00000)
    /tmp$ gcc -static -O3 test.c -o test
    /tmp$ ldd test
     not a dynamic executable

fuzztester•7mo ago

>> Not OP, but it’s the only way I know how to get gcc to use a static glibc.

> /tmp$ gcc -static -O3 test.c -o test /tmp$ ldd test not a dynamic executable

yes, that last line above means it's a statically linked executable.

yes, i had a doubt about what the GP said, about their nix way being the only way to create a statically linked executable.

but I didn't remember all the details, because it's been a while since I worked with C in depth (moved to Java, Ruby, Python, etc.)(though I did a lot of that earlier, even in pre-Linux years), so I didn't say anything else. thanks, Josh Triplett for clarifying.

but one thing I do remember, is that static linking was the only option in the beginning, at least on Unix, and dynamic linking came only some time later.

when I started working on UNIX and C, there was no dynamic linking at all, IIRC.

https://en.m.wikipedia.org/wiki/Static_library

("dynamic linking" topic in above page links to the below page in Wikipedia: )

https://en.m.wikipedia.org/wiki/Dynamic_linker

3836293648•7mo ago

I thought glibc had some hacks in it to prevent it from working fully when statically linked? Is this just a myth or outdated or only affects C/C++ or what?

JoshTriplett•7mo ago

The issue is that some features of glibc want to dlopen additional libraries, most notably NSS. If you call `gethostbyname`, even a static glibc will try to dlopen NSS libraries based on /etc/nsswitch.conf, and if the dynamic NSS libraries are incompatible with your statically linked glibc, you'll have problems.

musl, by contrast, doesn't support NSS at all, only /etc/hosts and DNS servers listed in /etc/resolv.conf, so whether you statically or dynamically link musl, you just won't have any support for (for instance) mDNS, or dynamic users, or local containers, or various other bits of name resolution users may expect to Just Work.

fuzztester•7mo ago

and by the way, ignorant mindlessly downvoting dudes who don't even bother to check if a comment is right or not, can shove it up, and take a flying leap into Lake Titicaca. they'll meet a lot of their brothers there, like giant frogs.

from a Google search:

>Overview Lake Titicaca, straddling the border between Peru and Bolivia in the Andes Mountains, is one of South America's largest lakes and the world’s highest navigable body of water. Said to be the birthplace of the Incas, it’s home to numerous ruins. Its waters are famously still and brightly reflective. Around it is Titicaca National Reserve, sheltering rare aquatic wildlife such as giant frogs.

ethan_smith•7mo ago

Try `cargo build --release --no-default-features` to get a much smaller binary (~5-10MB) - Rust statically links dependencies but supports conditional compilation for optional features.

aystatic•7mo ago

Glancing at the Cargo.toml, the package doesn't define any features anyways. `cargo b --no-default-features` only applies to the packages you're building, not their dependencies -- that would lead to very unpredictable behavior

getcrunk•7mo ago

Great catch! Comments mentioned getting it down to ~2MB but that’s still humongous.

If you just think about how roughly (napkin math) 2MB can be 100k loc, that’s nuts

arlort•7mo ago

Is It though? You won't get it on an embedded device (maybe) but you could install a thousand of these tools and barely even notice the space being taken up on most machines

getcrunk•7mo ago

I think that’s a lame argument. First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space.

Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated.

I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data) Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256

dotancohen•7mo ago

So bloated software is motivating you to spend more for the larger capacity phone?

What incentive does Apple have to help iOS devs get package sizes down, then?

hnlmorg•7mo ago

I’m usually the first to complain about bloat but your counterpoints to the GPs “lame arguments” are themselves, fallacies.

> First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space.

That’s exactly how most people think about file sizes.

When your disk is full, you don’t delete the smallest files first. You delete the biggest.

> Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated.

RAM sizes have actually stagnated over the last decade.

> I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data) Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256

That’s because media sizes increase, not executable sizes.

And people do want higher resolution cameras, higher definition videos, improved audio quality, etc. These are genuinely desirable features.

Couple that with improved internet bandwidth allowing for content providers to push higher bitrate media, however the need to still locally cache media.

nicoburns•7mo ago

> That’s because media sizes increase, not executable sizes.

Part of it is app sizes on mobile. But it's apps in the 200mb - 2gb range that are the problem, not ones that single-digit megabytes.

hnlmorg•7mo ago

200MB apps wouldn’t even make a dent on a 64GB device.

The 2GB apps are usually so large because they include high quality media assets. For example, Spotify will frequently consumer multiple GBs of storage but the vast majority of that is audio cache.

nicoburns•7mo ago

I currently have 355 apps installed on my phone, so if they were all 200mb then they wouldn't fit on a 64GB device.

I agree that the largest data use tends to be media assets.

hnlmorg•7mo ago

I’m intrigued, how many of them are actual 3rd party apps though? And how many are different layers around an existing app or part of Apple / Googles base OS? The latter, in fairness, consumes several GBs of storage too.

I’m not trying to dismiss your point here. Genuinely curious how you’ve accumulated so many app installs.

nicoburns•7mo ago

It's an interesting question. Some of them are definitely from the OS (either Google or Samsung).

Looking through at categories of app where I have multiple, I'm seeing:

- Transport provider apps (Airlines, Trains, Buses, Taxis etc)

- Parking payment apps

- Food delivery apps

- Hotel apps

- Payment apps

- Messaging / Video calling apps

- Banking apps

- Mapping apps

It's especially easy to accumulate a lot of apps if you travel through multiple countries, as for a lot of these apps you need different ones in different countries.

ghosty141•7mo ago

> No one thinks of software size primarily in the context of their disk space.

This is wrong. The reason why many old tools are so small was because you had far less space. If you have a 20tb harddrive you wouldn't care about whether ls took up 1kb or 2mb, on a 1gb harddrive it matters/ed much more.

Optimization takes time, I'm sure if OP wanted he could shrink the binary size by quite a lot but doing so has its costs and nowadays its rarely worth paying that since nobody even notices wether a program is 2kb or 2mb. It doesn't matter anymore in the age of 1TB bootdrives.

pxc•7mo ago

Size may be absolute, but bigness and smallness are inherently and inescapably relative.

vlovich123•7mo ago

When you include the code for all the dependency features this uses, you probably do end up close to 100k LoC net, no?

mtndew4brkfst•7mo ago

lib.rs has a nifty (and occasionally shocking) portrayal of this on their crate pages.

https://lib.rs/crates/lstr

says for this one the deps clock in at: ~19–29MB ~487K SLoC

ipdashc•7mo ago

Seems quite cool! Though the demo gif with (what seem to be?) broken icons is a bold choice :p

w108bmg•7mo ago

lol good catch, and I totally missed it

I used vhs to record the gif which must not run the script in my native terminal! I’ll have to see about fixing it!

yonatan8070•7mo ago

I've seen a lot of people use asciinema to record and share terminal recordings, it works quite well

diggan•7mo ago

You still end up having to turn it into a GIF if you want it to autoplay on GitHub's markdown viewer, or video if you want it to run on the page but require a click-to-play.

yonatan8070•7mo ago

Huh, I though you could embed those into READMEs on GitHub, but turns out you can't

nightpool•7mo ago

How would that solve the font problem? I feel like that would only make the problem of having unsupported fonts even worse.

wonger_•7mo ago

One solution could be to use the docker version of vhs, and edit the dockerfile to pull your desired font.

sdegutis•7mo ago

I didn't notice, I was too busy seeing how impressive and useful this tool is.

And with fuzzy matching built in? Just amazing. Good job OP.

sdegutis•7mo ago

So after writing this to learn Rust, what are your thoughts on Rust? What do you especially like and dislike about it, or what were you surprised about?

w108bmg•7mo ago

I appreciate the ecosystem of packages that seem really well maintained. I don’t love the syntax and find Rust harder to read and learn so far compared to something like golang (I’m used to R which is not a compiled language but has a great dev community).

I do love the compiler and support tools built into Cargo (fmt, clippy, etc.).

sdegutis•7mo ago

That's been similar to my experience. The ecosystem is extremely polished and smooth, the build tools and package manager and IDE support, all of it. Especially compared to C++ which I cuold barely get working here.

w108bmg•7mo ago

Really appreciate all the comments and useful feedback (first Rust package). Especially ways to reduce the size of the binary!

rewgs•7mo ago

This looks awesome! Right up my alley.

Side-note: what theme are you using in the linked gif? It's right in the middle of my two favorite themes, onedark and gruvbox.

berkes•7mo ago

I really love all the "modern" takes on classic tools by the Rust community.

I'm using eza (aka exa), aliased as ls, which has "tree" built in (aliased as lt), amongst others, as replacement for "ls" and it's one of my biggest production boosts in daily commandline use. Because eza has the tree built in, and the tree is also insanely fast, I won't be needing this tool - yet. Maybe one day the interactive mode will pull me over.

Congrats on releasing. And kudo's to how well you've released it: solid README, good description, good-looking gifs with exactly the right feature highlights

fer•7mo ago

On interactive mode "ls tree" tools, an interesting one is broot.

https://github.com/Canop/broot

dboreham•7mo ago

No async which is nice. TIL that Rayon has an almost Occam like syntax: https://github.com/bgreenwell/lstr/blob/44b9bbf118ca90558138... although you subsequently went with a library that bundles parallel filesystem traversal.

gorgoiler•7mo ago

Doing this in just over 1000 lines of code is really inspiring. I was bracing myself for something quite a lot larger and, honestly, gearing up to use that as an excuse not to delve through the code. No such luck… good!

Start all of your commands with a comma (2009)

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

The Waymo World Model

Hoot: Scheme on WebAssembly

How we made geo joins 400× faster with H3 indexes

Unseen Footage of Atari Battlezone Arcade Cabinet Production

Vocal Guide – belt sing without killing yourself

Jeffrey Snover: "Welcome to the Room"

ga68, the GNU Algol 68 Compiler – FOSDEM 2026 [video]

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

Monty: A minimal, secure Python interpreter written in Rust for use by AI

Where did all the starships go?

Show HN: I spent 4 years building a UI design tool with only the features I use

Hackers (1995) Animated Experience

Sheldon Brown's Bicycle Technical Info

Show HN: If you lose your memory, how to regain access to your computer?

Microsoft open-sources LiteBox, a security-focused library OS

UK infants ill after drinking contaminated baby formula of Nestle and Danone

An Update on Heroku

PC Floppy Copy Protection: Vault Prolok

Dark Alley Mathematics

The AI boom is causing shortages everywhere else

Was Benoit Mandelbrot a hedgehog or a fox?

How to effectively write quality code with AI

Delimited Continuations vs. Lwt for Threads

Introducing the Developer Knowledge API and MCP Server

I now assume that all ads on Apple news are scams

Female Asian Elephant Calf Born at the Smithsonian National Zoo

Understanding Neural Network, Visually

I spent 5 years in DevOps – Solutions engineering gave me what I was missing

Start all of your commands with a comma (2009)

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

The Waymo World Model

Hoot: Scheme on WebAssembly

How we made geo joins 400× faster with H3 indexes

Unseen Footage of Atari Battlezone Arcade Cabinet Production

Vocal Guide – belt sing without killing yourself

Jeffrey Snover: "Welcome to the Room"

ga68, the GNU Algol 68 Compiler – FOSDEM 2026 [video]

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

Monty: A minimal, secure Python interpreter written in Rust for use by AI

Where did all the starships go?

Show HN: I spent 4 years building a UI design tool with only the features I use

Hackers (1995) Animated Experience

Sheldon Brown's Bicycle Technical Info

Show HN: If you lose your memory, how to regain access to your computer?

Microsoft open-sources LiteBox, a security-focused library OS

UK infants ill after drinking contaminated baby formula of Nestle and Danone

An Update on Heroku

PC Floppy Copy Protection: Vault Prolok

Dark Alley Mathematics

The AI boom is causing shortages everywhere else

Was Benoit Mandelbrot a hedgehog or a fox?

How to effectively write quality code with AI

Delimited Continuations vs. Lwt for Threads

Introducing the Developer Knowledge API and MCP Server

I now assume that all ads on Apple news are scams

Female Asian Elephant Calf Born at the Smithsonian National Zoo

Understanding Neural Network, Visually

I spent 5 years in DevOps – Solutions engineering gave me what I was missing

Show HN: Lstr – A modern, interactive tree command written in Rust

Comments