Helldiver's engine does have that capability, where bundle patches only include modified files and markers for deleted files. However, the problem with that, and likely the reason Arrowhead doesn't use it, is the lack of a process on the target device to stitch them together. Instead, patch files just sit next to the original file. So the trade-off for smaller downloads is a continuously increasing size on disk.

from my understanding of the technique youre wrong despite being 80% sure ;)

any changes to the code or textures will need the same preprocessing done. large patch size is basically 1% of changes + 99% all the preprocessed data for this optimization

Generally "small patches" and "well-compressed assets" are on either end of a trade-off spectrum.

More compression means large change amplification and less delta-friendly changes.

More delta-friendly asset storage means storing assets in smaller units with less compression potential.

In theory, you could have the devs ship unpacked assets, then make the Steam client be responsible for packing after install, unpacking pre-patch, and then repacking game assets post-patch, but this basically gets you the worst of all worlds in terms of actual wall clock time to patch, and it'd be heavily constraining for developers.

It goes all the way back to tapes, was still important for CDs, and still thought relevant for HDDs.

Basically you can get much better read performance if you can read everything sequentially and you want to avoid random access at all costs. So you can basically "hydrate" the loading patterns for each state, storing the bytes in order as they're loaded from the game. The only point it makes things slower is once, on download/install.

Of course the whole excercise is pointless if the game is installed to an HDD only because of its bigger size and would otherwise be on an nvme ssd... And with still affordable 2TB nvme drives it doesn't make as much sense anymore.

The user VMs are mostly Linux but Azure itself runs on a stripped down version of Windows Server and all the VMs are hosted inside Hyper-V. See https://techcommunity.microsoft.com/blog/windowsosplatform/a...

Passion over paycheques

Is this a trick question, because you run it as administrator in a sandboxed account.

Procmon.exe. Give me 2 minutes. You make it sound like it's such a difficult thing to do. It literally will not take me more than 2 minutes to tell you exactly where the permission issue is and how to fix it.

and why is it not on the vendor of the critical application?

ACLs in Linux were tacked on later; not everything supports them properly. They were built into Windows NT from the start and are used consistently across kernel and userspace, making them far more useful in practice.

Also, as far as I know Linux doesn't support DENY ACLs, which Windows does.

Haha, sure. Sorry, it's not you, it's the ACLs (and me nerves). Have you tried configuring NFSv4 ACLs on Linux? Because kernel devs are against supporting them, you either use some other OS or have all sorts of "fun". Also, not to be confused with all sorts of LSM based ACLs... Linux has ACLs in the most ridiculous way imaginable...

Not by default. Not as extensive as in Windows. What's your point?

Debian (and thus Ubuntu) has full support for automated installs since the 90's. It's built into `dpkg` since forever. That include saving or generating answer to install time questions, PXE deployment, ghosting, CloudInit and everything. Then stuff like Ansible/Puppet have been automating deployment for a long time too. They might have added yet another way of doing it, but full stack deployment automation has been there for as long as Ubuntu existed.

> Ubuntu just recently got a way to automate its installer (recently being during covid).

Preseed is not new at all:

https://wiki.debian.org/DebianInstaller/Preseed

RH has also had kickstart since basically forever now.

I've been using both preseeds and kickstart professionally for over a decade. Maybe you're thinking of the graphical installer?

> Ubuntu just recently got a way to automate its installer (recently being during covid). I think you can do the same on RHEL too. But that's largely it on Linux right now. If you need to admin 10,000+ computers, Windows is still the king.

What?! I was doing kickstart on Red Hat (want called Enterprise Linux back then) at my job 25 years ago, I believe we were using floppies for that.

Still the king but developing/testing/debugging group policy issues is a miserable experience.

> Ubuntu just recently got a way to automate its installer (recently being during covid). I think you can do the same on RHEL too. But that's largely it on Linux right now. If you need to admin 10,000+ computers, Windows is still the king.

1. cloud-init support was in RHEL 7.2 which released November 19, 2015. A decade ago.

2. Checking on Ubuntu, it looks like it was supported in Ubuntu 18.04 LTS in April 2018.

3. For admining tens of thousands of servers, if you're in the RHEL ecosystem you use Satellite and it's ansible integration. That's also been going on for... about a decade. You don't need much integration though other than a host list of names and IPs.

There are a lot of people on this list handling tens of thousands or hundreds of thousands of linux servers a day (probably a few in the millions).

I'm surprised no one has said NixOS yet.

That's not a SAK, you can disable it with setxkbmap. A SAK is on purpose impossible to disable, and it exists on Linux: Alt+SysRq+K.

Unfortunately it doesn't take any display server into consideration, both X11 and Wayland will just get killed.

The "threat model" (if anyone even called it that) of applications back then was bugs resulting in unintended spin-locks, and the user not realizing they're critically short on RAM or disk space.

This setup came from the era of Windows running basically everything as administrator or something close to it.

The whole windows ecosystem had us trained to right click on any Windows 9X/XP program that wasn’t working right and “run as administrator” to get it to work in Vista/7.

That's not the same thing at all.

The more powerful form is the UAC full privilege escalation dance that Win 7+(?) does, which is a surprisingly elegant UX solution.

   1. Snapshot the desktop
   2. Switch to a separate secure UI session
   3. Display the snapshot in the background, greyed out, with the UAC prompt running in the current session and topmost

Clever way of dealing with the train wreck of legacy Windows user/program permissioning.

It made a lot more sense in the bygone years of users casually downloading and running exe's to get more AIM "smilies", or putting in a floppy disk or CD and having the system autoexec whatever malware the last user of that disk had. It was the expected norm for everybody's computer to be an absolute mess.

These days, things have gotten far more reasonable, and I think we can generally expect a linux desktop user to only run software from trusted sources. In this context, such a feature makes much less sense.

It's useful for shared spaces like schools, universities and internet cafes. The point is that without it you can display a fake login screen and gather people's passwords.

I actually wrote a fake version of RMNet login when I was in school (before Windows added ctrl-alt-del to login).

https://www.rmusergroup.net/rm-networks/

I got the teacher's password and then got scared and deleted all trace of it.

I think they are a bit different - in the Windows kernel, all IO is asynchronous on the driver level, on Linux, it's not.

io_uring didn't change that, it only got rid of the syscall overhead (which is still present on Windows), so in actuality they are two different technical solutions that affect different levels of the stack.

In practice, Linux I/O is much faster, owing in part to the fact that Windows file I/O requires locking the file, while Linux does not.

That argument holds no water. IOUring is essential for the performance of some modern POSIX programs.

You can see shims for fork() to stop tanking performance so hard too. IOUring doesnt map at all onto IOCP, at least the windows subtitute for fork has “ZwCreateProcess“ to work from. IOUring had nothing.

IOCP is much nicer from a dev point of view because your program can be signalled when a buffer has data on it but also with the information of how much data, everything else seems to fail at doing this properly.

If you have anything less than perfect vision and need any accessibility features, yes. If you have a High DPI screen, yes. In many important areas (window management, keyboard shortcuts, etc.), yes.

Here's one top search result that goes into far more detail: https://www.reddit.com/r/linux/comments/1ed0j10/the_state_of...

For the general user, yes absolutely.

Linux DEs still can't match the accessibility features alone.

yeah, there's layers and layers of progressively older UIs layered around the OS, but most of it makes sense, is laid out sanely, and is relatively consistent with other dialogs.

macOS beats it, but its still better in a lot of ways over the big Linux DEs.

I prefer it. Linux desktop feels a lot more laggy to me on the same hardware.

Of course that is minus all the recent AI/ad stuff on Windows…

With the massive adoption of web apps in Enterprise I have seen I would expect Windows to become irelevant or even a liability in business use as well.

Sleep brokenness is ecosystem-wide. My Thinkpad crashes/freezes during sleep 3 times a week. Lenovo serviced/replaced it 3 times to no avail.

> its development model cannot consistently provide this product feature.

The real problem is that the hardware vendors aren't using its development model. To make this work you either need a) the hardware vendor to write good drivers/firmware, or b) the hardware vendor to publish the source code or sufficient documentation so that someone else can reasonably fix their bugs.

The Linux model is the second one. Which isn't what's happening when a hardware vendor doesn't do either of them. But some of them are better than others, and it's the sort of thing you can look up before you buy something, so this is a situation where you can vote with your wallet.

A lot of this is also the direct fault of Microsoft for pressuring hardware vendors to support "Modern Standby" instead of rather than in addition to S3 suspend, presumably because they're organizationally incapable of making Windows Update work efficiently so they need Modern Standby to paper over it by having it run when the laptop is "asleep" and then they can't have people noticing that S3 is more efficient. But Microsoft's current mission to get everyone to switch to Linux appears to be in full swing now, so we'll see if their efforts on that front manage to improve the situation over time.

I should have said ‘product development’ model versus just ‘development’ to be more clear. To state another way: Linux has no way, no function, no pathway to providing this. This is not really surprising, because it isn’t the work software developers find fun and self-rewarding, but rather more the relatively mundane business-as-usual scope of product managers and business development folks.

… And that’s all fine, because this is a super niche need: effectively nobody needs Linux laptops and even fewer depend on sleep to work. If ‘Linux’ convinced itself it really really needed to solve this problem for whatever reason, it would do something that doesn’t look like its current development model, something outside that.

Regardless, the net result in the world today is that Linux sleep doesn’t work in general.

It's not the development model at fault here. It's the simple fact that Windows makes up nearly the entire user base for PCs. Companies make sure their hardware works with Windows, but many don't bother with Linux because it's such a tiny percentage of their sales.

The feature itself works. There are just hardware that is buggy and don't support it properly.

That's a vastly different statement.

> Regardless of how it must be implemented, if this is a desirable feature then this explanation isn’t an absolution of Linux but rather an indictment: its development model cannot consistently provide this product feature.

The problem is: the specifications of ACPI are complex, Windows' behavior tends to be pretty much trash and most hardware tends to be trash too (AMD GPUs for example were infamous for not being resettable for years [1]), which means that BIOSes have to work around quirks on both the hardware and software. Usually, as soon as it is reasonably working with Windows (for a varying definition of "reasonably", that is), the ACPI code is shipped and that's it.

Unfortunately, Linux follows standards (or at least, it tries to) and cannot fully emulate the numerous Windows quirks... and on top of that, GPUs tend to be hot piles of dung requiring proprietary blobs that make life even worse.

[1] https://www.nicksherlock.com/2020/11/working-around-the-amd-...

And all this came from big game makers turning their games into casinos. The reason they want everything locked down is money is on the line.

Sounds like the sort of oddball corporate experiment that Action Retro or Michael MJD would be examining in fifteen years.

Bazzite is nice but its not very CLI centric I think because of the immutability. Its a great OS, but I found Cachy a lot better if you want to work from CLI in normal ways

Mobile is completely hamstrung, all of the effort went into creating as much vendor lock-in as possible rather than into creating a useful pocket computer. There's all this cool tech on and adjacent to mobile that you can't actually use in any meaningful way because every aspect of it is someone's money patch and they don't want to work together.

At least iOS made the deep and robust AppKit/Cocoa the foundation of its primary kit and then over the years made sensible QoL changes, resulting in something reasonably pleasant to write for. That, and it doesn’t fight you and make you jump through hoops if you’d rather use some flavor of C, C++, or something else LLVM can handle instead of a JVM-something. That goes a long way.

I'm absolutely not a normal user, but I love the experience on the Pinephone, because I can use the same stack as on desktop.

Is that true? I did just that on my newly purchsed laptop in 2023. It was a thinkpad though.

I've OOMd on my mac several times, and it has never gone completely unresponsive.

You get an OOM dialog with a list of apps that you can have it kill.

It's harmful to the ecosystem, because the reason so many Linux drivers, and Wine contributions, and a lot of other things are free software today is because of the GPL

A decade or two ago Wine was on permissive license (MIT I think). When proprietary forks started appearing, Codewavers (which employs all the major Wine contributors) relicensed it as GPL.