> ... we'd need a system 12.5 times bigger, i.e., roughly 531 square metres, or about 2.6 times the size of the relevant solar array. This is now going to be a very large satellite, dwarfing the ISS in area, all for the equivalent of three standard server racks on Earth.

https://taranis.ie/datacenters-in-space-are-a-terrible-horri...

The gist of it is that about 99% of cooling on earth works by cold air molecules (or water) bumping into hot ones, and transferring heat. There's no air in space, so you need a radiator 99x larger than you would down here. That adds up real fast.

Any halfway-competent developer can write some code that does a SHA256 hash of all your files and uses the Apple filesystem API's to replace duplicates with shared-clones. I know swift, I could probably do it in an hour or two. Should you trust my bodgy quick script? Heck no.

The author - John Siracusa - has been a professional programmer for decades and is an exceedingly meticulous kind of person. I've been listening to the ATP podcast where they've talked about it, and the app has undergone an absolute ton of testing. Look at the guardrails on the FAQ page https://hypercritical.co/hyperspace/ for an example of some of the extra steps the app takes to keep things safe. Plus you can review all the proposed file changes before you touch anything.

You're not paying for the functionality, but rather the care and safety that goes around it. Personally, I would trust this app over just about any other on the mac.

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

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.

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 :-)

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.

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.

Epic opened a developer account under their european subsidiary company, which applied for this, and Apple just banned that account, so Epic can't create a store. Perhaps if someone else (Google, Microsoft, Meta) made a store, Epic might be able to upload apps to that store, but because in the Apple world everything traces back to the developer accounts, I'm pretty sure that would be blocked by Apple as well.

As much as it might seem like Tim Sweeney was exaggerating about Apple's DMA "compliance" changes being hot garbage, a horror show, and malicious compliance -- he really wasn't. Apple are in full on villain mode here.

The part that doesn't make sense, is why Apple are choosing to be such dicks about everything, when the EU is already breathing down their necks. They're inviting more and harsher regulation upon themselves and making the rest of the world hate them in the process.

That's a lot of very high hurdles to clear. Even if this magically solved all my scaling and distributed system problems forever, I'm not sure it'd be worth it. Good luck to them though for being ambitious.

It's easy to improve over a fake strawman

I've owned personally, and used macs for work since around 2009. I've never installed any third party window-snapping or management systems, and I don't consider it a big deal.

I do use window snapping on Win10/11 periodically, but TBH I find that the beefed up snapping in Win11 is more annoying than it is useful, often snapping things to quarters of the screen when I just wanted to move a window.

Likewise, I've seen non-programmer users on win10 hit the window snapping by accident and be confused and put off by it.

Would I like it if Apple were to build a power-user window snapping feature into macOS? Yes, I would. Am I upset at them for not including it? Certainly not. Were I a product manager for macOS I would find it hard to justify the investment, given all the other things they can and do work on.

It holds value even if you wrote all your UI in SwiftUI. Whether it's a dead-end technology or not, only apple knows (and they won't tell us), but SwiftUI alone doesn't remove the need for it.

I used to work at a company which makes security and access control systems (swipe cards, electronic locks, etc).

They created a consumer-level system (as opposed to the big Enterprise ones they were known for) and tried to create a distribution model which appears to be how you're thinking about it. The idea was they'd build a network of contractors ("Installers"). Customers would buy direct from the company, who would then forward a request to your local installer (lead gen). The company would cut the installers in for some percentage of the ongoing subscription revenue cost, plus whatever margin they added at install time.

This failed miserably. The company learned within the space of a couple of years, that all the good installers want to build a relationship with (and critically, to bill) the customer, they don't want to be a behind-the-scenes referral on someone else's website. Few signed up, and the ones that did, weren't incentivized to prioritize it highly. They put it lower down on their job lists, which led to customers having to wait a long time and experiencing poor service in some cases. Not great. The company also struggled tremendously to drum up interest. Because security systems (like HVAC) come with maintenance/repairs/etc, the market had evolved into one centered around companies/individuals looking around at their local providers first, picking the "best" one, and then choosing a product based on what the provider was offering or what they recommended, much like you would with a Plumber or Electrician.

Maybe the HVAC industry is sufficiently different from Security and this model might work for you? From what I saw though, there's a lot of overlap there and I'm not optimistic.

After a year or two, the company pivoted to a model where they formed partnerships with contractors/installers and moved away from the direct-to-consumer model. At the time I left, this was proving much more successful of a model. The partnership model involved more revenue share, training, and a bunch of other stuff I wasn't involved in, but critically, it meant that when an end-customer went to their local security system provider and asked them what was good, they'd be highly likely to recommend my ex-company's product. That was the clincher.

I hope that's of some use @cmui