Hacker News Reader

Comment by thibran | Hacker News Reader

I wish Microsoft would update Windows to use a Chrome OS like update system with delta updates and read-only system partitions. When partition A is in use (mounted read-only), an update would create a copy of A on partition B. Then download a binary delta and apply it to B to update B to the newest OS version. On the next system start partition B would be booted, if there is an error restart to partition A (a known working state), otherwise B is marked as 'good'.

It's 2018 and updates are still slow to apply and/or break computers... what a strange world.

View on HN

My Windows directory is currently sitting at 49GB. I don't think this is a realistic idea for Windows-based PCs unless cheap SSDs start getting bigger with a quickness.

SSD are getting surprisingly cheap, you can now get 250 GB for 50 euros, 500 for less than 100 euros (and we're talking samsung 860 evo, not cheap knock off)

I just recently discovered the same. I hadn't shopped SSD prices in a quite a while, so I was pleasantly surprised when I did last week. I picked up the Samsung 860 evo for $87 (USD).

Split that 49GB into separate piles of OS binaries, configuration data, and third-party crap that gets dumped into the Windows directory, and the problem won't look so bad. And SSD prices have been dropping fast for several months now, and the drops will continue well into next year.

But the ideal solution would be a copy-on-write filesystem supporting snapshots, rather than A/B partitions.

> But the ideal solution would be a copy-on-write filesystem supporting snapshots, rather than A/B partitions.

NTFS is already that via Volume Shadow Copy. They just don't use it in the way we're discussing, but the tech is there.

Why is it so big though? On my system the Windows directory is only 5GB.

I did a clean install of Windows 10 on my workstation less than a month ago and my Windows directory is sitting at 23GB, methinks something funky is going on here.

Do you have a bunch of applications installed? IIUC, Windows keeps different versions of each of its DLLs around for whatever apps requires them. I would expect that installing applications might embiggen your Windows directly a lot.

I wouldn't say I have "a lot" of applications installed, although I'm not too sure how to quantify that.

I assumed it WinSxS related as the other reply mentions, and upon investigation found that it is 9GB alone! I don't run Windows outside of work so I've just never really bothered looking into it, but if it continues to balloon I guess I'll have to.

It's probably due to WoW64 and WinSxS inflating due to dll caching and backup resources after Windows Update.

I just checked mine and it is at 33 GB. Are you running a fresh installation? Do you have very many MS development tools installed?

I know in the past, any Windows updates would be cached in your windows directory forever and there was no safe way to remove them. That would gradually grow the windows directory size forever. Also, it seems there are a lot of files that get thrown in there when you start installing multiple versions of SQL Server or Visual Studio.

Right-click on the drive -> Properties -> General.

Disk Clean-up.

Clean-up System Files.

Windows Update Clean-up (and Temporary Windows installation files).

Ok. Ok.

Enjoy.

> My Windows directory is currently sitting at 49GB.

That doesn't sound like how much Windows is actually using for itself. How much of it is \Windows\Installer\?

Actually, I was surprised to find that MacOS does a form of this, apparently - I recently attempted an update that failed and simply had to hold down ‘option’ on boot to select my regular drive instead of the update. The second time I tried the update it worked just fine.

I'm not 100% sure what you were experiencing, but this is not how macOS works under normal circumstances. Maybe while the update is in progress, but you can't just downgrade to High Sierra from Mojave so easily, once the installation is complete.

I suspect the GP saw this during a point release update on Mojave.

Baseless speculation: I suspect that they were referring to Apple making use of the ability to spin up a new temporary APFS volume to store the Update packages + Staging environment and blessing it for boot.

It makes a certain amount of sense to push out a static staging environment to then run the requisite OS updates and firmware updates from that controlled environment. That way you can reboot as many times as is required for the updates in the point release and still come back to the staging environment ready to go to the next stage - only needing to touch the User Data Volume when absolutely necessary.

While not nearly as 'clean' as an atomic update on a read only root filesystem, this method could be significantly more controllable and more 'clean' than doing it live on the User's Data Volume.

I suspect with iOS Software updates - it's a transactional atomic update as those machines all use read only root filesystems regardless.

It is in the works :)

The reason this update was paused was that it deleted user files (subdirectories of your user folder that it thought were empty and useless but actually weren't). The model you suggest might be a good idea but it wouldn't have helped with this update at all.

Fedora is also trying to do this for linux with their "Silverblue" tech preview

I wish Microsoft would modernize Windows to be a fully (or mostly) POSIX-compliant architecture like (almost?) every other OS in existence. It's a unicorn in that regard, and unicorns should stay extinct. ;-)

The people who truly care about it not being POSIX compliant are also the people who would still denigrate it even if it became fully compliant so ... From their point of view, why bother ? You are your own worst enemy on that one.

On the flip side, with WSL windows 10 can now pretty much run any POSIX compliant code anyway.

POSIX was made to unite the UNIXes. The reason why POSIX compatibility would be important is for efficient porting of software from one platform to another, especially when the platforms aren't UNIX-compliant.

Microsoft never needed to buy into that; Microsoft set its own standards with MS-DOS long before that, and Windows further cemented Microsoft's position. Where all the UNIXes and UNIX clones were in dire need of standardisation, MS-DOS and Windows were and still are the Microsoft standard.

Even in modern times, POSIX compliance doesn't necessarily mean much when a lot of recent software is being designed Linux-first, with support for other POSIX systems sometimes relegated to third-party or distribution-specific patches. Not to mention all the various implementations of POSIX compliance come with their own little quirks that make things different enough to still require manual checking for this or that.

Additionally, there are plenty of libraries that are compatible with both POSIX-compliant and non-POSIX platforms. Targeting these libraries produces perfectly usable software.

Therefore, POSIX compliance isn't the be-all and end-all of computing. Somehow or other we've managed to muddle through the years without it in Windows, and Nazis aren't riding dinosaurs on blood-soaked streets just yet.

You're making fun of unicorns, but treating 'POSIX' like a magic word.

As someone who generally prefers Windows, it would still be nice to have a greater degree of POSIX in it, just for the sake of more portability. There are some choices, like the path syntax, that are never going to make Win32 fully POSIX compliant. But why can't we e.g. have POSIX threads and synchronization primitives, or most of the filesystem API?

The old Unix personality had that - and now the new Linux Personality (they no longer call it that) implements this for you. This complaint no longer makes sense since WSL was released.

WSL serves different scenarios - it is for running Linux software on Windows. It's all or nothing - if you want Linux, you get Linux. If you want Windows, you get Windows. You can't mix and match.

So it doesn't help you if you want to, say, write a cross-platform library in C that needs threads, and that can be used from both Unix console apps and Win32 desktop apps. For that, you actually need a cross-platform threading API. In C++, that actually exists, in form of std::thread and friends. In C, you have to rely on third-party libraries, and those libraries have to wrap the various platform-specific APIs - so your program is only as portable as those third-party libraries. If you could just #include <pthread.h> everywhere, it would have been so much easier.

The IPC communication between WSL and native windows applications is getting better all the time. Along with the filesystem they both share you can use sockets, and named pipes.

Because of fork() you will never be able to arbitrarily use NT objects unconstrained in WSL apps, but there are lots of options. You can launch both windows and Linux programs arbitrarily from the shell now so the decision to choose one or the other is slowly coming down to preference.

Reply on news.ycombinator.com