WSL1 was very conceptually appealing, and ended up working very poorly because of the poor matching between Linux syscalls and the Windows kernel. Git suffered terribly as a result. The inverse is also somewhat true - there have been cases where Wine is much slower than native Windows because Linux simply doesn't provide a simple way to achieve the same outcome, and interestingly the Wine developers have had reasonable (if tediously slow) success in making it possible to express the same semantics to Linux and have it handle things fast. It would be fascinating to know whether WSL1 developers didn't have enough traction to get Windows internals altered to match, or whether it's just way harder to do the same under Windows.
It did work quite well. The problem with the filesystem could have been solved by optimizing the Windows kernel, that would have benefit also programs run outside the WSL by the way (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it).
The thing that I don't like of the WSL2 is that is just a VM, but a VM that is very limited. For example working in the embedded development field I often need to use serial ports or USB devices, a thing that the WSL2 is not capable of doing (unless passing trough USB/IP that has its compatibility issues especially for stuff like debuggers needing precise timing), and that the WSL1 was at least for the serial ports able to do. This is a limitation that doesn't allow me to use the WSL. Same thing with all kind of other software that wants to access peripherals of the machine natively (e.g. a GPU for example, or another PCI card, something that to be fair is not even doable as far as I know with hypervisors on Windows but completely doable with hypervisors running on a Linux OS where trough the IO MMU you can share any PCI device of the host to the VM).
WSL1 was a great idea, bad thing that Microsoft abandoned it for something that is just good for web application development.
> (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it)
NTFS does not have performance problems. The difference between DevDrive, which uses ReFS (arguably a more 'resilient' file system than NTFS due to journaling) and a standard NTFS volume is the file system filters are either removed or in the case of Defender, put in async mode.
The file system filter architecture is the performance problem, not the file systems. It's a trade off to have a more extensible I/O stack.
I recall there was also an issue with how paths are treated in NT. I don't fully recall, but I think NT paths are parsed by the kernel early on, and the whole kernel operates on "cooked" paths. there was some major performance implications this had for WSL1 in addition to the filter driver architecture.
I also don't remember why they couldn't just bypass the filter stack for paths in a certain volume - WSL2-like I/O on WSL1 - but there must have been a reason.
> The problem with the filesystem could have been solved by optimizing the Windows kernel
Over time this would tie the Windows kernel’s requirements so that they matched the Linux kernel’s due to expectations from WSL1 users. This of course is a bad idea for any engineering organization - you will have requirements imposed on you that don’t mesh well with your other non-WSL users and you also have no real sway over Linux governance. This would lead to the Windows kernel either becoming a clone of Linux or serving at least one set of users poorly.
It's my understanding that a big part of WSL1 performance loss comes from the relatively thick layered filesystem architecture on Windows.
Since git and nodejs are both common in modern development and are expected to work efficiently with huge numbers of files, this was a real bottleneck and it couldn't easily be tackled without threatening backward compatibility.
Wine achieves better performance these days due to things like... adding a module to the Linux kernel that implements NT-like synchronization primitives. So, Linux subsystem for NT synchronization basically. (a.k.a. NTSync)
Maybe this works out better because Linux is more flexible, while Windows/NT is more "set in its ways" and therefore more difficult to implement Linux on top of... Maybe?
Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
Does any older folk here remembers when NT was the Cool New Thing (TM) and it had by design support to multiple subsystems plopped over the NT API, and Win32 was just one of them alongside POSIX (Interix) and OS/2? There was even a _very short_ time span when Interix was actually usable (it was extremely short though)
I guess that makes me square within the 'older folk' subset - I continued to use the NT core with LiteSTEP alongside the SGI/IRIX Octane2 well after Y2K.
Those days I was working on a rework of the TRO PLATO learning system which was a real beast but essential for the individual learning project of a charter school i was supporting.
PLATO had been taken from it's dedicated mainframe world and made 'runnable' on W95 workstations with an NT server - but it really didn't run well, and the kids could really get behind the interface into regular Windows environment too readily. In combination the workstations were crazy hard to keep running cleanly.
So in the end; we had to take the software out of Windows, wash it clean in the waters of Silicon Graphics System-V with BSD extensions (X11) Unix and BSD - NeXTSTEP, just so we could bring it back to Windows properly using LiteStep.
Life happened and I lost touch with the outcome of it all, moving on to my next project; but, I kept a LiteSTEP desktop until moving entirely over to Linux in 2004.
Haven't used Windows for anything but a gaming load since '05 and stopped doing even that in about 2010, nothing later than XP.
Yes, the only reason I cared for Linux in first place was that the POSIX support wasn't that good.
I am convinced that if POSIX subsystem was UNIX serious, GNU/Linux would never taken off on PC, and the whole would be divided between SGI, HP-UX, Solaris, Aix and Windows NT.
Actually Linux was very SysV like back in the day, so it was more like the stuffy OS's that people liked.
GCC was the real catalyst, With even SUN which had used bundled dev tools as a early selling point was unbundling them and charging more, many x86 UNIXes like SCO didn't even come with a tcp/ip stack without an extra fee...and you couldn't take C code from HP to another system and actually have it compile.
As Solaris is really just a sysV-ification of the bsdish sunOs...the introduction of posix as a least common denominator, and Linux being closer to the commercial-ish unixes it was just an easier sell for a lot of users.
In hindsight it may seem silly, but in may projects I was involved with, linux using sysV /etc/init.d/, vs BSD's /etc/rc.conf was the driving factor, because /etc/rc.conf was a shared dependency and harder for us to modularize projects.
IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early.
But there were still flavor wars from all sides all the time, and being an ex-op on #unix and #unixhelp from the 1990s, I dealt with them all.
But BSD and heck even ITS etc... was the free-for-all, anything-goes, platform of record.
> IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early.
IMHO what really differentiated Linux were
a. the bazaar development approach, which lowered barriers to contribution, felt more transparent and "safer" with regards to what was going on in kernel land
b. the GPL, which while annoying to certain companies due to its viral nature, it at least guaranteed that no competitor could just develop a major innovation, grab the kernel and all of your contributions and run with them, undercutting you in the process
and also a noteworthy mention was the fact the BSDs were basically sabotaged by AT&T via their nefarious set of lawsuits, which nipped in the bud any semblance of advantage they had
386BSD and its derivatives (eg FreeBSD) weren’t really attacked by SCO like other UNIXes were. In fact SCO filed more lawsuits against Linux than they did (for example) FreeBSD.
FreeBSD was also used heavily in the late 90s in ISPs and similar domains.
I think you are a possibly a decade off on the timing here.
USL v. BSDi is what impacted the BSD side, and it was during that lawsuit before Novell bought USL etc.... that the problems were that allowed Linux to make gains while the net/2 distros were in a waiting game IMHO.
The timing absolutely helped Linux and GNU being packaged as a complete system by the various distros etc..., and common OSS distribution points like Walnut Creek and PHT were very much concerned about USL v. BSDi and in an era when you had to make long distance phone calls to download with a modem, a lack of CDroms etc... absolutely caused a dip in adoption of the BSDs.
By the time the IBM v. SCO lawsuits happened (2003) the UNIX wars were long gone and Linux was already established.
SCO/Interactive/Coherent/etc... and other x86ish UNIXes were quite common in my work in the early 1990s, but the whole unix wars is way to complicated to cover in a single post.
The post .com bubble SCO lawsuits really just didn't matter much, the consolidation that happened in the early 90's that ended the UNIX wars, plus Intel killing most of the commercial unix independent CPUs with Itanium untruths and impossible promises and an inability for the major vendors to adapt to a lower margin model etc... killed those off.
The SCO lawsuits were really just the flailing of a dyeing company which was the end result of WordPerfect buying Novell with Novells money and local Utah politics.
Sorry, I don’t think my point was very clear. I wasn’t saying that SCO sued Linux in the 90s nor that the UNIX wars had zero impact.
Just that FreeBSD was still used a lot in the 90s and managed (at least from what I experienced) to dodge most of the concerns that companies had deploying other UNIXes.
I mean, it’s not like UNIX use dropped to zero overnight.
So you did see a lot of Internet companies using FreeBSD as their platform of choice. For a while, it really did look like FreeBSD was becoming the dominant server platform in that domain. Not everyone too Linux serious at that time. It wasn’t until at least 99 when Linux became a viable competitor to FreeBSD.
But once Linux did gain favour its popularity sky rocketed. Which is exactly why SCO took various Linux shops to court.
You’re sidestepping my point that FreeBSD was in widespread use in the 90s.
My point about SCO wasn’t clear though. I was just saying FreeBSD wasn’t as embroiled in the UNIX wars as the others, ie referencing SCO vs Linux to demonstrate how even Linux suffered more time in the courts than FreeBSD did.
The BSDs would be much bigger today if it wasn't for AT&T going after them hard in the early '90s, exactly when both them and Linux were starting to take up speed. I think that things could have gone way different if the BSDs were bigger and more popular, in quite unpredictable ways (it's not like they haven't been popular anyway though - see Darwin, or the Playstation OS for instance)
Cygwin was fun. I'd done zero development on Windows, but about 10 years ago I had to figure out how to deploy some nightly shell scripts across a bunch of local computers in a few dozen offices, where about 80% were MacOS and the rest were Windows. I don't remember exactly how I rigged it, but basically cygwin allowed me to keep the scripts as they were and trigger them in place, with a few small modifications.
I never want to deal with that again ;)
[edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.
The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this
You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0.
That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.
Yes, you could if you were entering them manually, but some apps that generated file names would screw it up. I think they were using some sort of stdlib function to get the path seperator. Forward slash paths working in native windows apps also wasn't quite a given, either. Keep in mind this was a loooong time ago... like windows xp era maybe, even.
Yeah, I recall directory paths being the biggest PITA with running scripts in cygwin. But I mean, that was a very minor set of things to fix compared to what would've had to be written in anything else available at the time.
Doing retail office deployments of custom code on employee computers is a weird niche, and you find whatever works and hope you can maintain it somehow. Cygwin was awesome though, saved me a ton of time and the client a lot of money for the moment. (The client later stipulated to all future franchisees that they had to buy only Macs, lol)
what do you mean? that's still the only way to work as a human in windows. wsl1 almost replaced it, but obviously they scrapped it.
if you must use windows, it's because you will compile for windows. so you install MSYS, which is a linux distro-ish compiled native for windows. and do your work.
wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.
> Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones.
Everyone in FOSS? How about Microsoft got it wrong, since they actually named it The Windows Subsystem for Linux (WSL)? It wasn't the FOSS community who chose the name for them.
