Recent submissions

Comment · 21 days ago
Comment · 3 months ago
Comment · 3 months ago
Yuck. I like both Go and C# a lot, and use them both professionally.

In my experience the strengths of Go are mostly - Deployability via single-file static binaries - Simple syntax that anyone can learn (no exceptions, no classes or inheritance) - Wicked fast compile times

And the strengths of C# are - Powerful language with null-safety and lots of syntax sugar - Runtime-level coroutines so you don't need `async/await` everywhere

G# seems like it has the _worst_ of both worlds, not the best. It's fun to write compilers, and good on them for doing it, but no thank you for real use

Comment · 8 months ago
I thought the title was clickbait, but no, he really did fix it! Nice
Comment · 9 months ago
Comment · 1 year ago
Yes, slack is intermittently down for me and the rest of my company. It's intermittently losing messages, failing to load new ones, and showing error pages :-(
Comment · 1 year ago
Comment · 1 year ago
I can't find a specific EULA or disclaimer for the Hyperspace app, but given that the EULA's for major things like Microsoft Office basically say "we offer you no warranty or recourse no matter what this software does" I would hardly expect an indie app to offer anything like that
Comment · 1 year ago
Yep. At a previous job we had a file server that we published Windows build output to.

There were about 1000 copies of the same pre-requisite .NET and VC++ runtimes (each build had one) and we only paid for the cost of storing it once. It was great.

It is worth pointing out though, that on Windows Server this deduplication is a background process; When new duplicate files are created, they genuinely are duplicates and take up extra space, but once in a while the background process comes along and "reclaims" them, much like the Hyperspace app here does.

Because of this (the background sweep process is expensive), it doesn't run all the time and you have to tell it which directories to scan.

If you want "real" de-duplication, where a duplicate file will never get written in the first place, then you need something like ZFS

Comment · 1 year ago
> This is basically only a win on macOS, and only because Apple charges through the nose for disk space

You do realize that this software is only available on macOS, and only works because of Apple's APFS filesystem? You're essentially complaining that medicine is only a win for people who are sick.

Comment · 1 year ago
He "only" saved 30%? That's amazing. I really doubt most people are going to get anywhere near that.

When I run it on my home folder (Roughly 500GB of data) I find 124 MB of duplicated files.

At this stage I'd like it to tell me what those files are - The dupes are probably dumb ones that I can simply go delete by hand, but I can understand why he'd want people to pay up first, as by simply telling me what the dupes are he's proved the app's value :-)

Comment · 1 year ago
In order to check if a file is a duplicate of another, you need to check it against _every other possible file_. You need some kind of "lookup key".

If we took the first 1024 bytes of each file as the lookup key, then our key size would be 1024 bytes. If you have 1 million files on your disk, then that's 128MB of ram just to store all the keys. That's not a big deal these days, but it's also annoying if you have a bunch of files that all start with the same 1024 bytes -- e.g. perhaps all the photoshop documents start with the same header. You'd need a 2-stage comparison, where you first match the key (1024 bytes) and then do a full comparison to see if it really matches.

Far more efficient - and less work - If you just use a SHA256 of the file's contents. That gets you a much smaller 32 byte key, and you don't need to bother with 2-stage comparisons.

Comment · 1 year ago
I don't know exactly what Siracusa is doing here, but I can take an educated guess:

For each candidate file, you need some "key" that you can use to check if another candidate file is the same. There can be millions of files so the key needs to be small and quick to generate, but at the same time we don't want any false positives.

The obvious answer today is a SHA256 hash of the file's contents; It's very fast, not too large (32 bytes) and the odds of a false positive/collision are low enough that the world will end before you ever encounter one. SHA256 is the de-facto standard for this kind of thing and I'd be very surprised if he'd done anything else.

Comment · 1 year ago
+1. He's not taking anything away because you never had it.
Comment · 2 years ago
The author is now discovering Ruby and Objective-C :-)

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton