Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyperspace

hypercritical.co

Post reply on HN
Print view View original

291–300 of 503 posts

Re: Hyperspace

#291

Post by jedbrooke »

petercooper wrote: post #6

I love the model of it being free to scan and see if you'd get any benefit, then paying for the actual results. I, too, am a packrat, ran it, and got 7GB to reclaim. Not quite worth the squeeze for me, but I appreciate it existing!

it’s very refreshing compared to those “free trials” you have to remember to cancel (pro tip: use virtual credit cards which you can lock for those so if you forget to cancel the charges are blocked)

however has anyone been able to find out from the website how much the license actually costs?

Re: Hyperspace

#292

Post by jacobp100 »

DontBreakAlex wrote: post #181

Nice, but I'm not getting a subscription for a filesystem utility. Had it been a one-time $5 license, I would have bought it. At the current price, it's literally cheaper to put files in a S3 bucket or outright buy an SSD.

The price does seem very high. It’s probably a niche product and I’d imagine developers are the ones who would see the biggest savings. Hopefully it works out for them

Re: Hyperspace

#293

Post by re »

On a related note: are there any utilities that can measure disk usage of a folder taking (APFS) cloned files into account?

Re: Hyperspace

#294

Post by criddell »

DontBreakAlex wrote: post #181

Nice, but I'm not getting a subscription for a filesystem utility. Had it been a one-time $5 license, I would have bought it. At the current price, it's literally cheaper to put files in a S3 bucket or outright buy an SSD.

I think it's priced reasonably. A one-time $5 license wouldn't be sustainable.

Since it's the kind of thing you will likely only need every couple of years, $10 each time feels fair.

If putting all your data online or into an SSD makes more sense, then this app isn't for you and that's okay too.

Re: Hyperspace

#295

Post by sterlind »

borland wrote: post #189
p_ing wrote: post #87

Earlier quoted context omitted.

Windows Server does this for NTFS and ReFS volumes. I used it quite a bit on ReFS w/ Hyper-V VMs and it worked wonders . Cut my storage usage down by ~45% with a majority of Windows Server VMs running a mix of 2016/2019 at the time.

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

hey, it's defrag all over again!

(not really, since it's not fragmentation, but conceptually similar)

Re: Hyperspace

#296

Post by criddell »

mrguyorama wrote: post #278
dewey wrote: post #209

Earlier quoted context omitted.

They had long discussions about the pricing on the podcast the author is a part of (atp.fm). It went through a few iterations of one time purchase, fee for each time you free up space and a subscription. There will always be people unhappy about either choice. Edit: Apparently both is possible in the end: https://hypercritical.co/hyperspace/#purchase

Who would be unhappy with $5 owned forever? Other than the author of course for making less money.

People who want the app to stick around and continue to be developed.

I worry about that with Procreate. It feels like it's priced too low to be sustainable.

Re: Hyperspace

#297

Post by PhilipRoman »

pmarreck wrote: post #251
borland wrote: post #158

Earlier quoted context omitted.

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

xxHash (or xxh3 which I believe is even faster) is massively faster than SHA256 at the cost of security, which is unnecessary here. Of course, engineering being what it is, it's possible that only one of these has hardware support and thus might end up actually being faster in realtime.

Blake3 is my favorite for this kind of thing. It's a cryptographic hash (maybe not the world's strongest, but considered secure), and also fast enough that in real world scenarios it performs just as well as non-crypto hashes like xx.

Re: Hyperspace

#298

Post by dylan604 »

criddell wrote: post #289
dylan604 wrote: post #130

Earlier quoted context omitted.

Even using sha-256 or greater type of hashing, I'd still have concerns about letting a system make deletion decisions without my involvement. I've even been part of de-dupe efforts, so maybe my hesitation is just because I wrote some of the code and I know I'm not perfect in my coding or even my algo decision trees. I know that any mistake I made would not be of malice but just ignorance or other stupid mistake. I've…

> I'd still have concerns about letting a system make deletion decisions without my involvement You are involved. You see the list of duplicates and can review them as carefully as you'd like before hitting the button to write the changes.

Yeah, the lack of involvement was more in response to ZFS doing this not this app. I could have crossed the streams with other threads about ZFS if it's not directly in this thread

Re: Hyperspace

#299

Post by karparov »

abrookewood wrote: post #280
taneliv wrote: post #88

Earlier quoted context omitted.

On ZFS it consumes a lot of RAM. In part I think this is because ZFS does it on the block level, and has to keep track of a lot of blocks to compare against when a new one is written out. It might be easier on resources if implemented on the file level. Not sure if the implementation would be simpler or more complex. It might also be a little unintuitive that modifying one byte of a large file would result in a lot d…

In regards to the second point, this isn't correct for ZFS: "If several files contain the same pieces (blocks) of data or any other pool data occurs more than once in the pool, ZFS stores just one copy of it. Instead of storing many copies of a book it stores one copy and an arbitrary number of pointers to that one copy." [0]. So changing one byte of a large file will not suddenly result in writing the whole file to…

Not the whole file but it would duplicate the block. GP didn't claim that the whole file is copied.

Re: Hyperspace

#300

Post by kevincox »

pca006132 wrote: post #17

Is this the dedup function provided by other FS?

Yes, Linux has a systemcall to do this for any filesystem with reflink support (and it is safe and atomic). You need a "driver" program to identify duplicates but there are a handful out there. I've used https://github.com/markfasheh/duperemove and was very pleased with how it worked.
Post reply on HN