Live data from Hacker News

Windows 9x Subsystem for Linux

social.hails.org

101–110 of 265 posts

Re: Windows 9x Subsystem for Linux

#101
post #67

Earlier quoted context omitted.

The core of the software is a subsystem, specifically a Windows subsystem; you're not running this subsystem on macOS or FreeBSD. The "for Linux" is added because it's a subsystem for Linux applications (originally not leveraging a VM). Microsoft also had the "Microsoft POSIX subsystem" (1993) and "Windows Services for UNIX" (1999) which were built on the "Subsystem for Unix-based Applications" (rather than "Unix-bas…

To me, it sounds like a subsystem that provides Windows Compability for the Linux host . I do agree it's an issue of English being an imprecise language.

Still a better language than other myriad of languages with uselessly complicated grammars and rules. And I'm not a native English speaker.

And this is a poor example, because Microsoft wants to be Microsoft.

Re: Windows 9x Subsystem for Linux

#102
post #47

Hmm I wonder how stable it is.. It cannot render correctly Window control buttons (Minimize, Maximize, Close). If it fails on such basic task, I wonder where it crashes...

That's a graphics driver problem. Fairly common to see when running Windows 9x/Me under QEMU.

Re: Windows 9x Subsystem for Linux

#103
post #40
post #5

Okay what is it with WSL naming, this always confuses me. Shouldn't it be Linux subsystem for Windows?

I always have the same problem myself. Same as I had with version naming of old programs like "Microsoft Word for Windows 2.0" instead of the easier "Microsoft Word 2.0 for Windows".

The problem is Word 2.0 for Dos was released in 1985, and Word for Windows 2.0 was released in 1991. Calling it Word 2.0 for Windows wouldn't make sense, because it wasn't the 1985 release with a new coat of paint, Word for Windows was its own thing, and this was the second version. Word for Mac was also separate, but eventually Word 6 was a common code base and it made sense to have Word 6.0 for [whatever]

Re: Windows 9x Subsystem for Linux

#105
post #26
post #20

Earlier quoted context omitted.

Cygwin is way older than CoLinux. CoLinux is from 2004. Cygwin was first released in 1995. The problem with Cygwin as I remember it was DLL hell. You'd have applications (such as a OpenSSH port for Windows) which would include their own cygwin1.dll and then you'd have issues with different versions of said DLL. Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limi…

Just use ssh from Cygwin. DLL hell was rarely a problem, just always install everything via setup.exe. The single biggest problem it has is slow forking. I learned to write my scripts in pure bash as much as possible, or as a composition of streaming executables, and avoid executing an executable per line of input or similar.

Try using the Windows busybox port of "Bash":

https://frippery.org/busybox/index.html

It has a subset of bash implemented on Ash/Dash. Arrays are not supported, but it is quite fast.

The forking problem is still present, though.

Re: Windows 9x Subsystem for Linux

#106
post #99
post #6

Earlier quoted context omitted.

Well it did take me 6 years to follow that up!

Can we get an official statement on which OS your project runs inside which OS? It's left slightly unclear, for the uninitiated!

doslinux is some tricky sleight of hand where it looks like Linux is running inside DOS, but it's actually the other way around (even though DOS boots first).

WSL9x takes quite a different approach. Windows boots first, but once Linux starts both kernels are running side-by-side in ring 0 with full privileges. They are supposed to cooperate, but if either crashes then both go down.

Re: Windows 9x Subsystem for Linux

#108
post #105
post #26

Earlier quoted context omitted.

Just use ssh from Cygwin. DLL hell was rarely a problem, just always install everything via setup.exe. The single biggest problem it has is slow forking. I learned to write my scripts in pure bash as much as possible, or as a composition of streaming executables, and avoid executing an executable per line of input or similar.

Try using the Windows busybox port of "Bash": https://frippery.org/busybox/index.html It has a subset of bash implemented on Ash/Dash. Arrays are not supported, but it is quite fast. The forking problem is still present, though.

Cygwin bash isn't slow either. The problem is a typical bash script isn't a series of bash operations, it's a series of command line program executions.

For example, someone might do something like this (completely ignoring the need to quote in the interests of illustrating the actual issue, forking):

    for x in *; do
      new_name=$(echo $x | sed 's/old/new/')
      mv $x $new_name
    done
Instead of something like this:

    for x in *; do
      echo $x
    done | sed -r 's|(.*)old(.*)|mv \1old\2 \1new\2|' | grep '^mv ' | bash
This avoids a sed invocation per loop and eliminates self-renames, but it's harder to work with.

Of course the code as written is completely unusuable in the presence of spaces or other weird characters in filenames, do not use this.

Re: Windows 9x Subsystem for Linux

#109
post #60

> Proudly written with zero AI. Unfortunately this is ambiguous, as there's an AI product called Zero AI.

> Proudly written without AI. Looks like it's been updated now to be more clear. Amazing though.

Looks like opportunity for new AI product called "without AI".
Post reply on HN