Hacker News: 0x1d7

New comment by 0x1d7 in "OneDrive data now has an expiry date"

0x1d7 — Mon, 08 Jun 2026 12:29:19 +0000

What does this have to do with the article you're responding to which is about OneDrive for Business?

More HN comments, less reddit comments, please.

New comment by 0x1d7 in "OneDrive data now has an expiry date"

0x1d7 — Mon, 08 Jun 2026 11:21:35 +0000

Odfb has always had a SharePoint backend. Used to be called MySites and carried no relation to the consumer product you’re confusing it with.

New comment by 0x1d7 in "WSL vs Wine"

0x1d7 — Sun, 07 Jun 2026 16:35:19 +0000

> What does Windows offer these devs that is missing in Linux?

A stable ABI. Then there are the specifics to the apps you're mentioning (i.e., decent color calibration support, memory management, display drivers).

We saw what happened with OS/2 supporting DOS/Win16 apps. Why bother with writing anything for OS/2 and lock yourself into a smaller market?

But this has been discussed to death on HN, if you search for it.

New comment by 0x1d7 in "WSL 2 is getting faster Windows file system access"

0x1d7 — Sat, 06 Jun 2026 20:47:36 +0000

This is correct. The flexibility of the file system filter model does have a performance penalty and you will see that across file systems.

This is why 'DevDrive' exists for ReFS, to reduce that penalty (though ReFS comes with it's own, namely in write performance due to journaling).

The model wasn't a big deal back in the day of IDE and SCSI, but it certainly shows on flash storage.

New comment by 0x1d7 in "Coreutils for Windows"

0x1d7 — Fri, 05 Jun 2026 17:11:30 +0000

NT does not have a fork-alike API. The NT internal APIs are all known.

New comment by 0x1d7 in "WSL 2 is getting faster Windows file system access"

0x1d7 — Fri, 05 Jun 2026 03:07:39 +0000

It's the file system filters that are an issue on Windows. It trades performance for extensibility.

NTFS itself is a fast file system.

New comment by 0x1d7 in "MacBook Neo Is So Popular That Apple Doubled Production"

0x1d7 — Wed, 03 Jun 2026 19:52:13 +0000

IME edu operates much differently than [US] corporations which use a 3 - 5 year deprecation schedule. Edu is more 'run it until it doesn't'.

New comment by 0x1d7 in "Coreutils for Windows"

0x1d7 — Wed, 03 Jun 2026 12:31:33 +0000

Yes, but the Executive has a hard dependence on Win32 for service control.

New comment by 0x1d7 in "Coreutils for Windows"

0x1d7 — Wed, 03 Jun 2026 00:46:09 +0000

The NT kernel does not understand fork(). You can-sorta-fake-it, which is what WSL1 did. There's no equivalent to fork() in any version of Windows. From your link:

> As an example, the Linux fork() syscall has no direct equivalent call documented for Windows. When a fork system call is made to the Windows Subsystem for Linux, lxcore.sys does some of the initial work to prepare for copying the process. It then calls internal Windows NT kernel APIs to create the process with the correct semantics, and completes copying additional data for the new process.

The MSFT driver prepped something-like-fork and then called the native NtCreateProcess, which does not implement anything like fork().

New comment by 0x1d7 in "Coreutils for Windows"

0x1d7 — Tue, 02 Jun 2026 22:42:09 +0000

POSIX was implemented as a subsystem.

And it was never _fully_ implemented, as my post said. The NT kernel doesn't support certain POSIX semantics (fork).

New comment by 0x1d7 in "Coreutils for Windows"

0x1d7 — Tue, 02 Jun 2026 19:08:53 +0000

The NT kernel could never implement full POSIX semantics. It would have to be another UN*X clone to do so.

And that would suck.

New comment by 0x1d7 in "Coreutils for Windows"

0x1d7 — Tue, 02 Jun 2026 18:56:44 +0000

NT shipped with USC-2 as UTF-8 (and -16) did not yet exist. USC-2 naturally translated to UTF-16, hence the choice. NT/Win32 is also designed for fixed-with code units, something UTF-8 doesn't support.

You can use UTF-8 on a per-application basis, within limits.

https://learn.microsoft.com/en-us/windows/apps/design/global...

Conversely, UEFI is UTF-16 only, thanks to Windows.

UTF-8 only would be an ABI breaking change, so that's not going to happen. We don't want the NT kernel to end up like Linux, after all :-)