251–260 of 260 posts
Earlier quoted context omitted.
Yup! echo is a CMD builtin and doesn't exist as a dedicated executable.
Sorry, I'm not following the logic. Isn't the same true for dir?
Earlier quoted context omitted.
I didn't say it was the one and only True Way. My intended meaning - which I admit I may have poorly conveyed - is that tools from the unix ecosystem are intended to work on unix conventions, and do, and that works. Windows has different standards, which is also fine, but it follows that you shouldn't expect unix tools to follow Windows standards even if you make them run on Windows. This is like getting Windows soft…
Your entire framing is wrong imho. Multi-platform is very easy and a solved problem if you try juuuust a tiny amount. For example the Rust stdlib iterator for lines() handles both conventions. It just works. Very easy. I live in a cross-platform world. Line endings in text files should not be a breaking problem because some CLI tool refuses to support both. That’s just plain bad software engineering. I expect Unix to…
You're right, this is a complete nonissue.
Earlier quoted context omitted.
MIT is a good license to maximize proliferation of use. It seems to be working as intended for uutils.
As if being popular by itself is actually a good thing. Popular with corporate shitheads that want free stuff and not contribute anything sure. Is it good for Open Source, absolutey not.
Earlier quoted context omitted.
As if being popular by itself is actually a good thing. Popular with corporate shitheads that want free stuff and not contribute anything sure. Is it good for Open Source, absolutey not.
The authors have agency to use whatever license they want. They chose MIT.
Earlier quoted context omitted.
The authors have agency to use whatever license they want. They chose MIT.
Just because they chose it doesn’t make it a good choice.
At best, we can make the guess: They chose the license that best fits their interests.
Earlier quoted context omitted.
WSL1 DOES implement fork() for WSL1 lightweight processes in the lxcore.sys driver: https://learn.microsoft.com/en-gb/archive/blogs/wsl/windows-...
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 i…
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.
Actually a further research reveals that it is very much possible to trigger forking behavior even from the user space. Here is the proof: https://github.com/mobdk/CloneProcess https://stackoverflow.com/questions/985281/what-is-the-close... . You just need to use ZwCreateProcess.
Earlier quoted context omitted.
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 i…
In the next post they literally tell that NT kernel "supports" it https://learn.microsoft.com/en-gb/archive/blogs/wsl/pico-pro... . In the same post if you scroll down into the comments they also say that their fork implementation 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 indist…
Earlier quoted context omitted.
> But line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating. The Linux ecosystem handles it fine (by using a single standard). Windows doesn't. That's its problem.
Complete and utter nonsense. Every Windows tool I remember using has handled LF-only endings perfectly fine, meanwhile Linux tools regularly fail to handle CRLF endings.
cough notepad cough