For the MS folk reading this: native zsh on Windows, please?
WSL2 is great, but native POSIX is even better. Of course it’s a big undertaking, but it makes Windows a first-class dev platform for those who need POSIX in production.
NT kernel can and did implement POSIX. Multiple times even. That's how WSL1 works. NTFS can also support Unix-like permissions. There are ACLs for Owner and Group.
However, I'm not keen on using yet another Unix clone as well. At least Windows NT brought the world into 90s in the OS state-of-the-art where Unix clones are stuck in 80s and each of them patch around the deficiencies of POSIX. Native asynchronous APIs and truly object-oriented system call infrastructure is nowhere to be found in POSIX.
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().
Just because YOU don't have access to the functionality used for fork, it doesn't mean that there are no internal API calls that can do a fork or do something very similar that it is indistinguishable. A ring-0 driver (like lxcore.sys) that can access a non-standard special process model (pico processes) and is allowed to register its own syscall entry/exit points can also access lower level functionality like accessing the page table of a pico process, modifying it and responding to non-Win32 syscalls.
When you run fork in a WSL1 program now, its effects are the same as doing a fork natively on a Linux kernel: the memory space view is cloned as CoW, a new stack is allocated and the execution is resumed in both processes. If it forks like a duck, it is a duck.
Yes standard Win32 cannot do forks. However, Win32 isn't the only identity NT can expose and NT provides functionality to do forks. Just not to the normal programmers.
Those are just bots sending reset attempts to obtain your email or phone hint. I receive hundreds per year. All you need to send a password reset link is the account's username, which is, of course, publicly accessible.
One of the things I like about Steam is that your email address, username, display name and id slug (/id/*) aren't required to be the same. All public identifiers should be changeable (regardless of whether or not making the change is a publicly available option).
Yes, I was wondering about this. Old iPads running iPad OS 15 received updates last month. So even an iPad Air 2 from 2014 could receive updates in 2026.
The big issue with old iPads though is that apps drop support for older iPad OS versions. Usually their older versions do keep working, though.
I was using poetry pretty happily before uv came along. I’d probably go back.
Note that uv is fast because — yes, Rust, but also because it doesn’t have to handle a lot of legacy that pip does[1], and some smart language independent design choices.
If uv became unavailable, it’d suck but the world would move on.
Like, the whole point of open source is that this thread is not a thing. The whole point is "if this software is taken on by a malevolent dictator for life, we'll just fork it and keep going with our own thing." Or like if I'm evaluating whether to open-source stuff at a startup, the question is "if this startup fails to get funding and we have to close up shop, do I want the team to still have access to these tools at my next gig?" -- there are other reasons it might be in the company's interests, like getting free feature development or hiring better devs, but that's the main reason it'd be in the employees' best interests to want to contribute to an open-source legacy rather than keep everything proprietary.
The leadership and product direction work are at least as hard as the code work. Astral/uv has absolutely proven this, otherwise Python wouldn't be a boneyard for build tools.
Projects - including forks - fail all the time because the leadership/product direction on a project goes missing despite the tech still being viable, which is why people are concerned about these people being locked up inside OpenAI. Successfully forking is much easier said than done.
I had a lot of trouble convincing people that a correct Python package manager was even possible. uv proved it was possible and won people over with speed.
I had a sketched out design for a correct package manager in 2018 but when I talked to people about it I couldn't get any interest in it. I think the brilliant idea that uv had that I missed was that it can't be written in Python because if is written in Python developers are going to corrupt its environment sooner or later and you lose your correctness.
I think that now that people are used to uv it won't be that hard to develop a competitor and get people to switch.
Liquid Glass is Apple’s Windows Vista. They had a ton of fun with Vista in their “switch” ads, if the Windows team were in better shape they could have a field day just screenshotting Tahoe on Social Media. Lucky they’re distracted with their own challenges.
Liquid Glass does have some good points, but it feels like someone turned in C- level work.
I see the Vista comparison a lot but I'm not sure I agree with it. I never thought Vista was that ugly, I thought it was more most of the computer hardware people were buying at the time just wasn't capable of running those visual effects (and I recall it was pretty buggy too)
It had a glassy aesthetic but the similarity doesn't go much further than that description. They didn't make all the buttons into glass blobs floating on top of the content with distracting warping effects; the window chrome was still generally separated from the content.
The EU’s tech regulation has always been a bit “off”, like they don’t really understand tech or how to encourage improved behaviour. Eg cookie popups, those are a blight and it’s the EU’s fault — to the point they’re working to roll them back[1] after all these years, because informed consent is impossible at the scale at which cookie popups hit users.
Then there was the whole “pay or okay” controversy around paywalls or tracking ads.
My observation is: saying no to tech rarely works. Building a more compelling alternative does. But the EU would rather regulate than build.
I do get that there are use cases for actual hardware bound keys for enterprise settings. But having non-exportable credentials (effectively non-ownable) is not acceptable in a consumer setting. This is a thinly veiled attempt at strengthening platform lock-in.
Look, the spec says you can't export the keys to a file! Too bad, go re-register your 120 websites if you want to stop using iCloud/Google!
Last I checked, they were working on interop so you can move your keys from one provider to another without creating CSV files or equivalent[1].
However from my PoV — if the user or an open source project wants to create CSV files, they should be free to do so. That’s part of putting the user in control.
For me, KeePass XC is the canary in the coal mine that helps me figure out what FIDO’s priorities are. I don’t have a problem with crypto around passkeys. They’re great. The non-functionals though (including shipping passkeys without good import/export) are a bit of a mess.
WSL2 is great, but native POSIX is even better. Of course it’s a big undertaking, but it makes Windows a first-class dev platform for those who need POSIX in production.
reply