Live data from Hacker News

Hyperspace

hypercritical.co

231–240 of 503 posts

Re: Hyperspace

#231
post #75

> Like all my apps, Hyperspace is a bit difficult to explain. I’ve attempted to do so, at length, in the Hyperspace documentation. I hope it makes enough sense to enough people that it will be a useful addition to the Mac ecosystem. Am I missing something, or isn't it a "file de-duplicator" with a nice UI/UX? Sounds pretty simple to describe, and tells you why it's useful with just two words.

I've been using `fclones` [1] to do this, with `dedupe`, which uses reflink/clonefile.

https://github.com/pkolaczk/fclones

Re: Hyperspace

#232

Its interesting how Linux tools are all free when even trivial mac tools are being sold. Nothing against someone trying to monetize but the linux culture sure is nice!

It's not that nice to call someone's work they spent months on "trivial" without knowing anything about the internals and what they ran into.

Re: Hyperspace

#233

Earlier quoted context omitted.

At that point, why hash them instead of just using the first 1024 bytes as-is?

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 bu…

I understand the concept. My main point is that it's probably not a huge advantage to store hashes of the first 1KB, which requires CPU to calculate, over just the raw bytes, which requires storage. There's a tradeoff either way.

I don't think it would be far more efficient to do hash the entire contents though. If you have a million files storing a terabyte of data, the 2 stage comparison would read at most 1GB (1 million * 1KB) of data, and less for smaller files. If you do a comparison of the whole hashed contents, you have to read the entire 1TB. There are a hundred confounding variables, for sure. I don't think you could confidently estimate which would be more efficient without a lot of experimenting.

Re: Hyperspace

#234
post #173

Earlier quoted context omitted.

He wanted to write it in Swift 6. Does it support older OS versions?

Swift 6 is not the problem. It's backward compatible. The problem is SwiftUI. It's very new, still barely usable on the Mac, but they are adding lots of new features every macOS release. If you want to support older versions of macOS you can't use the nice stuff they just released. Eg. pointerStyle() is a brand new macOS 15 API that is very useful.

It's been a while since I last looked at SwiftUI on mac, Is it really still that bad ?

Re: Hyperspace

#235
post #163

Earlier quoted context omitted.

Probably because you need to keep a lot of those in memory.

I suspect that a computer with so many files that this would be useful probably has a lot of RAM in it, at least in the common case.

But you need to constantly process them too, not just store them.

Re: Hyperspace

#236

What algorithm does the application use to figure out if two files are identical? There's a lot of interesting algorithms out there. Hashes, bit by bit comparison etc. But these techniques have their own disadvantages. What is the best way to do this for a large amount of files?

Deleted comment based on a misunderstanding.

> This tool simply identifies files that point at literally the same data on disk because they were duplicated in a copy-on-write setting.

You misunderstood the article, as it's basically doing the opposite of what you said.

This tool finds duplicate data that is specifically not duplicated via copy-on-write, and then turns it into a copy-on-write copy.

Re: Hyperspace

#237

Earlier quoted context omitted.

Deleted comment based on a misunderstanding.

> This tool simply identifies files that point at literally the same data on disk because they were duplicated in a copy-on-write setting. You misunderstood the article, as it's basically doing the opposite of what you said. This tool finds duplicate data that is specifically not duplicated via copy-on-write, and then turns it into a copy-on-write copy.

Fair. Deleted.

Re: Hyperspace

#238
post #44

I gave it a try on my massive folder of NodeJS projects but it only found 1GB of savings on a 8.1GB folder. I then tried again including my user home folder (731K files, 127K folders, 2755 eligible files) to hopefully catch more savings and I only ended up at 1.3GB of savings (300MB more than just what was in the NodeJS folders.) I tried to scan System and Library but it refused to do so because of permission issues.…

> it only found 1GB of savings on a 8.1GB folder. You "only" found that 12% of the space you are using is wasted? Am I reading this right?

I have a 512GB drive in my MacBook Air M3 with 225GB free. Saving 1GB is 0.5% of my total free space, and it is definitely "below my line." It is a neat tool still in concept.

When I ran it on my home folder with 165GB of data it only found 1.3GB of savings. This isn't that significant to me and it isn't really worth paying for.

BTW I highly recommend the free "disk-inventory-x" utility for MacOS space management.

Re: Hyperspace

#239
post #48

> There is no way for Hyperspace to cooperate with all other applications and macOS itself to coordinate a “safe” time for those files to be replaced, nor is there a way for Hyperspace for forcibly take exclusive control of those files. This got me wondering why the filesystem itself doesn't run a similar kind of deduplication process in the background. Presumably, it is at a level of abstraction where it could safel…

NTFS supports deduplication but it is only available on Server versions which is very annoying.

Re: Hyperspace

#240
post #167

Earlier quoted context omitted.

Came here to post the same thing. Would love to try the application, but I guess not if the developer is deliberately excluding my device (which cannot run the bleeding edge OS).

The developer deliberately chose to write it in Swift 6. Apple is the one who deliberately excluded Swift 6 from your device.

Yea, too bad :( Everyone involved with macOS and iOS development seems to be (intentionally or unintentionally) keeping us on the hardware treadmill.
Post reply on HN