I use it and Bbedit and vi.

https://www.barebones.com/products/bbedit/

This is my project and open to anyone who wants to hard fork it or whatever. It’s more like a gist than a repo because I won’t bartend PRs.

Comments URL: https://news.ycombinator.com/item?id=47580746

Points: 1

# Comments: 1

Since the released version I’ve added ~100 features.

Repo is trunk based and atypical for github. There are brew based dependencies.

I’ll formalize more later.

I am a bit, but not much, younger than 60 and have been coding since Apple II days.

These tools are pretty close to HAL 9000 so of course GIGO as always has been the case with computer tech.

Almost everything is in Go except an image fingerprinting api server written in Swift. The most USEFUL thing I’ve written is a Go based APFS monitor that will help you not overfill your SSD and get pained into corner by Time Machine.

I have worked with ~100 dev teams across industries modernizing infrastructure and most dev teams are too silo’d off from operations to effectively use K8s off the shelf.

To mask this, we write back to cache and rely on cache coherency algorithms and multiway, multilevel caches to make sure main memory is written back to and read when cache tags are invalidated.

tl;dr - Current process technologies make SRAM very much faster than DRAM and multiple levels of multiway caches create a time based interface to maximise memory throughput to the CPU regsisters while maintaining coherent memory write backs.

It’s worth noting that Apple Silicon is fast because their DRAM bandwidth is much closer to the same machine cycle latency as the APU cores’caches and registers.

I was at Microsoft as a blue badge when they intro'd the carbon neutral by 2030 initiative and the first employee to ask about how this was possible was politely swatted down by Nadella in a live company meeting.

"why are we pressuring private companies at all?"

Because what Microsoft is doing is unsustainable but Nadella and the c-suite are too busy buying back stock to care. Microsoft doesn't actually make anything anymore - they just acquire technologies and extract the value and move on.

The OpenAI acquisition will take down Microsoft because to stay on the trajectory Nadella has bet the farm on would require Moore's Law to still be increasing compute mips/watt but that ended a while ago.

By the time these companies (Google, Apple, Microsoft, Meta) realize that AI will require geometrically more compute when only a linear increase in MIPS/watt is all we are going to get out of silicon.

That none of these firms are building silicon photonics labs to be the first to make this incremental leap away from CMOS shows that they're only vaguely aware that AGI isn't anywhere close to being a reality with any silicon based technologies.

Using bullshit technology, aka AI, to look for unknown amounts of oil while telling the press the date you will be carbon neutral is just unethical garbage like so much else Microsoft does.

This is like the guy on Twitter who threw MRI scans at Claude.

Or Juicero.

It's pretty clear whomever is leading MacOS dev efforts has been given the directive to not commit any new resources to the MacOS Finder.

For organizing files, I use File Browser Pro (iOS/Apple Silicon), Leap, DevonTHINK and anything else except the finder and tags which have never really worked very well.

There are bugs in the Finder and Disk Utility that have persisted for multiple OS releases and I simply don't trust GUI file management tools in modern MacOS.

In my view, Apple has decided to kill the Mac as a tool and wants everyone to use their Apple devices as consoles except devs who have to put up with being treated as second class citizens while Apple simultaneously uses the same lot of folks to do QA during "public betas".

As an Apple follower for decades, I'm running away from the platform and have recently replaced iCloud (for all intents and purposes) with Syncthing. I use old Intel Macs as daily drivers because you can't really multitask effectively with Apple Silicon -and- work with files because, well, memory contention is still a problem with iGPUs just like it always has been. The speed-up of the much vaunted Apple Silicon has EVERYTHING to do with the physical proximity of the processor cores to the DRAM except when you have a lot of process running then the kernel panics because memory contention issues with storage since MOST storage has to be on the USB bus and you can get into situations where the Mac can't keep the files system consistent because APFS, snapshots and Time Machine are a fuxxing disaster... sorry folks. /venting.

I think Jeff should try ssfs with disk images on either end to get closer to 125 MB/s.