And don’t you dare changing it unless you like random bugs

Sell me on this. Why would you want to change it? What good can actually come of allowing foo and Foo to coexist in the same directory?

Practically? Quite a few codebases from *nix systems rely on the case sensitivity. To do a successful git clone you need a file system that handles both Makefile and makefile, or whatever.

I ran into it more than once back in the day when I used Mac OS X as my primary OS.

More generally -- case sensitivity is a conceptual nightmare in the Unicode era. Should Cyrillic or Greek be case-insensitive as well? Etc. Do you really want the full complexity of Unicode string handling in your file system?

I would suggest treating file names like raw bytes. On modern Linux, anything but NUL is valid.

> anything but NUL is valid.

And slash/!

Sometimes you download stuff that relies on case sensitivity. Anyone who's dealt with this probably has a sensitive RW DMG lying around for this reason. But macOS FSes default to case-insensitive, so random issues come up if you make your root sensitive (famously in Adobe software). Damned if you do or don't.

Another weird thing in macOS:

  $ mkdir Cased
  $ cd cased
  $ pwd
  /Users/me/Downloads/cased
  $ cd ../Cased && pwd
  /Users/me/Downloads/Cased

So yeah I wish the FS defaulted to sensitive, even though I never rely on that. Not its job to normalize names.

TIL that MacOS `pwd` has `-P` and `-L` options.

     -L      Display the logical current working directory.
     -P      Display the physical current working directory (all symbolic links resolved).
     If no options are specified, the -L option is assumed.

In your example, using `-P` will show `Cased`.

In Bash and many modern POSIX shells, `pwd` is a builtin, not to mention an environment variable ${PWD}, but the POSIX system should also provide an external command, such as `/bin/pwd` that would operate on the filesystem, rather than semantically tracking your shell activity.

https://manpages.ubuntu.com/manpages/stonking/man1/pwd.1.htm...

> TIL that MacOS `pwd` has `-P` and `-L` options.

Interestingly, it wasn't designed to deal with case, but to select whether to resolve symbolic links:

    $ cd /tmp
    $ mkdir a
    $ ln -s a b
    $ cd b
    $ pwd && pwd -P
    /tmp/b
    /tmp/a

It can be nice to checkout some Git repositories that have this. It can also be nice to catch miscapitalizations of filename imports when those would fail on Linux, etc. One of my past workplaces actually had that problem, they mis-cased imports and the product failed to build on Linux. Nobody caught it because they all used macOS or Windows, I was the first to try WSL (this was before I switched back to Mac)

You would be asking for a world of hurt to put your root filesystem in a case-sensitive volume though. All sorts of software and applications have silently relied on case-insensitivity for decades. You can sometimes fix it on a case-by-case basis, but sometimes you can't, and it's also annoying for it to happen in the first place. Better to have a separate case-sensitive volume just for the stuff you want to be case-sensitive.

They are completely different words. Why should they be used to mean the same thing?

Well, so you can base84 encode your filenames for example. (Jk)

My main concern is the loose matching that comes with it where you can refer to any file or folder using any case without issue

Mostly consistency in knowing that Foo will become foo. This is a problem when it comes to (for example) supporting devs on Windows working on a codebase with prod on Linux. The database dbCustomer would be renamed dbcustomer on Windows.

There are workarounds, and containerization is a better idea, but you asked why you might want this.

No demo?

Demo here:

https://threejs.org/examples/?q=gau#webgpu_gaussian_splat

There's a bit of transparency in the lion head, is that an artifact of the splat itself or the renderer?

It is an artifact of the model I believe. I did notice that as well.

Gaussian splat models are fairly imperfect on average.

I don't know if the splat is exactly the same, but the playcanvas engine has no false transparency on this one: https://superspl.at/scene/7e4e9bcb that splat is actually of fairly high quality, so unless this is a materially different splat (with some of the gaussians dropped out maybe?) I'm inclined to blame the engine.

>https://superspl.at/scene/7e4e9bcb

If you turn off performance mode this is way higher quality than either of the other two versions of this model linked by bhouston in this thread, although with a much lower frame rate on my phone of course:

https://threejs.org/examples/?q=gau#webgpu_gaussian_splat

https://superspl.at/scene/56155c3f

I took it from here and I do see false transparency:

https://superspl.at/scene/56155c3f

There is even a link in the ThreeJS example preamble to this scene. I didn’t realize there was multiple lion splats of the same scene flying around.

Tnx!

Worktrees or sandboxes. You can tell Claude to put its stuff in a worktree. I can easily develop any amount of features in the same codebase because they all run in their own worktree

Yeah, and we don't limit how you do it — each chat gets its own tmux session, so it is up to you on how to handle it

You can have a camera doorbell using your copper wire.

With a video doorbell you can get notifications when a person enters your property. You can notify police or neighbors if it’s a stranger

Don't developers configure their LLM tools to only be able to access things the user using the LLM should have access to?

Gotta love the LP4 mode. So much music on a single disk! Remember the cool rectangular batteries? Why aren't these gumstick batteries more used in modern devices!?

The only reason I know and use DuckDB is because my (internal, private-use-only, experimental) vibe coded projects use it a ton. I didn't pick it - LLMs did. Until this article, I wasn't aware of what it actually is capable of.

Most of these projects use JSON(L) files for storage, and duckdb to process them.

If you haven’t investigated storing in parquet format - and it doesn’t break other consumers that need your jsonl formatted files - it could be worth trialling for your use case. You’ll see vastly smaller file sizes (even more so if you use zstd compression), and querying time will shoot up.

Usual caveats apply, but as a general rule it’s held up well for me. Only downside is that inspecting the results moves from vi on the output file to duckdb and a select * from.

Yup, especially data backups (although I wouldn't store critical backups like this, only nice-to-have ones). One minor note is that parquet file sizes / compressed sizes can be sensitive to ordering, so you can try different sort orders to get optimal compression.

I found with using various tricks I can get the zstd parquet to be up to 10x (or more) smaller than an equivalent Postgres table - but obviously the exact compression ratios will depend on the kind of data you have and how well your Postgres table is normalized.

I'll 100% try DuckDB in more serious projects where I would normally use Sqlite.

Try the superpowers plugin, let it write a spec (what do you want?) and a plan (how is it implemented). Then let it implement the plan.

Review each step as much as you care. These things take time so you can just do other stuff while it’s cooking.

With proper isolation of projects you can easily have multiple sessions in parallel. I frequently have 4 to 8 parallel Claude Code sessions, each with whole trees of agents reproducing, speccing, planning, implementing and reviewing things.

For common mistakes, you can make it remember things or rely on reviews.

You know what’s worse (less efficient) at parsing and writing code than LLMs?

Humans.