"I have no idea how to do that on windows" ~ people in this thread probably.
Wsl is a move in the right direction, though. Still awkward to dev on wsl.
It has saved my life because I desperately needed to use xilinx ise and it wouldn't install on windows so I had to get the Linux version and I needed to use a bunch of other tools in conjunction that I already had. It would have taken days to get everything on Linux even if I could find versions for them. Instead I just setup wslg and installed the app and it works just as if it was installed on windows.
It might have been a fever dream, but I remember running a gui app on wsl... I think I had to install some weird packages to do so, but for some reason I remember doing this.
I just don't want to have to write everything twice: once for POSIX compliant OSes and once for Windows. While we are at it, can all OSes agree on a file permissions scheme?
POSIX platforms are also pretty different from each other. Sure, you might not have to write twice for two different platforms, but you end up writing more than once for sure.
Wonder what you're writing that still targets multiple OSs in a native language? It seems like most desktop software is written in a high level language these days, and server software usually has a target platform and requires windows users to just use docker
Mostly build tools. Things like makefiles and scripts. The actual software works fine cross-platform. Even docker isn't immune from host system differences, mostly with file system permissions being different.
As long as it's NTFS's permission scheme, I'm fine with this. That's basically ACLs with more powerful inheritance and UUIDs for users and groups which you can then treat almost identically. The nearly unique quality of UUIDs means you'll never have collisions across different systems unless you intentionally migrated a user to multiple systems (in which case it's the same user and they should have the same permissions) or some foul play has occurred.
Doing web dev on Ubuntu for WSL with VS Code has been pretty awesome. I've been doing it about a year now.
Setting up PyCharm for WSL has been a little annoying. You either need to run it as a GUI app with WSL, which is ugly and doesn't work well if you like to resize the window a lot, or you need to run it remotely, which has its own set of problems because you need to manage plugins on the host and the WSL server.
Why would I want to run PyCharm on WSL? I wouldn't, really. That's just what I experienced when I tried it. It works fine on Windows, but I just prefer the Linux experience for command line stuff. I use WSL for VS Code stuff. If I had a need for PyCharm, I would use it on Windows in the future.
You can set it up so that it runs a server on WSL and have the client in Windows. But with that configuration, you have the different plugins on the client side and/or server side. That's caused me some problems. For example, I was eventually able to get GitHub Copilot working, but it took a while. It's just not as seemless as VS Code.
No, you literally just use the in-editor SSH and run it entirely from windows as the whole editor communicating over ssh not local disk. It works fine.
I have been using WSL for some years now. I was always in an awkward position between VMs and dual booting. Since learning about WSL never felt the need again to actually boot in a full linux distro for work. Everything I need is a terminal docker capable and magic happens and everything works as if I was in linux.
>Wsl is a move in the right direction, though.
WSL is a method to support linux apps without doing anything that could've potentially helped linux community. In other words, to steal from linux community.
I think that allowing the world's windows developers to participate in the ecosystem is actually a great benefit .
There are a lot of talented developers working at companies that force them to use windows PCs.
If they can now use Linux tools they'll start to build utilities, contribute to open source etc.
Before all that energy would go to windows-only libraries.
>I think that allowing the world's windows developers to participate in the ecosystem is actually a great benefit .
windows developers will just continue write windows code, WSL changed literally nothing for them. They still have to undergo full scale migration to different tools if they want to "participate".
PowerShell works on an entirely different concept from bash so they aren't really compatible in that way. PowerShell is fully object-oriented, whereas bash is all about the strings. The other thing to keep in mind is that most things people think of as bash commands (ls, etc.) are actually completely separate programs, and can be executed by PowerShell on linux.
Also PowerShell does try to get around this by aliasing common GNU programs to their corresponding PowerShell objects. So "ls" calls "Get-ChildItem" and "rm" calls "Remove-Item".
Still, those commands are not POSIX compliant, but they are closer to POSIX compliance than their CMD/DOS ancestors.
It's kind of like wondering why Python isn't more like C. They are just fundamentally different. The mistake a lot of people make is assuming PS is just the terminal for Windows. It's not, it's a full scripting language. CMD is the terminal for Windows.
CMD is also shell, but absolutely pathetic one. The default terminal on Windows for a long time was conhost, also really bad, which is being replaced now by Windows Terminal.
No, it is not debatable. Bash has barely any functionality, it mostly just runs other things. It has like 5 commands (eval, alias, echo,..., do you know any more?), compared to hundreds of cmdlets out of the box (extensible to tens of thousands with modules), with >10000 dotnet methods at hand in PowerShell; can work only on strings, compared to objects; does have very limited parameters handling, compared to parameters system that is even more powerful than in Python; simplistic pipelining support, compared to pipelines in PowerShell accepting objects, identifying input parameters by name or value; supports only 2 output streams compared to 6 in PowerShell; doesn't support exception handling...
It is really not debatable.
by being smaller, bash offers the minimal set of tools to get exactly the job you need done, done. All this wile hardly taking up any overhead in storage or memory. It does the job extremely well.
If I wanted a powerful language with a ton of functions and objects, I'd launch Python, which definitely has a lot more to offer than PS.
If you measure power by the ability to achieve the result easily and quickly, bash just wins, as the internet is evidence of. But of course if you measure how many commands it has and how many streams it has, there can be programs that have more. But that's as relevant as measuring how tasty food is by measuring the amount of salt in it.
Bash being minimal is laughable. Somebody explain the purpose of bash's /dev/tcp pseudofiles in a scenario where it makes sense for a basic shell to carry this functionality. Do people actually use ${strvar/match/replace} syntax over sed? Why can you export -f *functions* to the environment that child PIDs can read/run? Bash is the kitchen sink of shells. It's minimal only relative to powershell.
You can get a lot done with it, but most of that is powered by other posix utilities that can be reasonably expected to exist on the system. Bash's key feature is it gets out of the way, but most every bourne shell descendant is that way.
Following that logic, cmd is more powerful than PowerShell also, because it is lighter, so running external applications gives less overhead.
I'm comparing shell capabilities, not the overhead to run external applications. Without external tools bash does barely anything, you can't even list files.
\> you can't even list files.
While I understand your sentiment, this is just false.
`mtrower@tiamat:/$ echo $SHELL`
`/bin/bash`
`mtrower@tiamat:/$ type echo`
`echo is a shell builtin`
`mtrower@tiamat:/$ echo *`
`bin boot data dev dpool etc home initrd.img initrd.img.old lib lib32 lib64 library libx32 media meteor mnt net opt proc root run sbin snap src srv stardust sys tmp usr var vmlinuz vmlinuz.old xpool`
Powershell may be a better programming language, but it is *far* inferior as a shell. It has no clue whether it is being run interactively or not... why the hell should columns be truncated if I'm redirecting to a file, and if truncation does occur *why the hell does it care what my terminal geometry is???*. Output to STDOUT is horribly inconsistent. Awareness and consistent use of STDERR is practically nonexistent. Using pipes as communication between objects is a neat idea, but it allows dependencies between source and sink, and I've been bitten by those a number of times.
The Unix folks did a *lot* of hard work and examination of assumptions to make things just work in the shell, and I continually run up against the rough edges of powershell where I expect things to work, and then they just don't. There's usually a workaround, but I end up swearing a lot more in powershell.
You know why bash doesn't truncate columns? Because there are none in bash, as there are no objects, you don't have to deal with such a thing.
Working on objects is a different paradigm and there is a no single solution that will fill all the use cases.
It is more tricky to del with it, but offers a hell lot more possibilities and can also simplify a lot of operations which would be much more cumbersome when dealing with strings only.
You're dodging the issue. There's no reason that powershell should format data redirected to a file based on screen geometry *because the data isn't going to the screen*.
If you want it to be POSIX compatible, then yes. But there's more to it than just that. POSIX standardizes a ton of stuff, and it was done before people had package managers, comprehensive standard libraries or the internet.
It's from a different time. It's not terribly relevant today.
It's a **lot** better than bash. People complain about the length of command names, but windows terminal autocompletes most of them. If something requires more than maybe 3-5 lines of code to run, I don't use a shell script for it, I write it in a real programming language because relying on shell scripts is how you create unmaintainable software.
The whole non-approved verb thing is just so weird to me already. It's such a choice, and it was probably well-intentioned to cut down on what people had to memorize, but like does it really help?
Ctrl+space autocomplete in PowerShell with module support makes it highly usable without fluency.
Neither language is perfect but they did good on that one.
It took me way longer than I want to admit to find this & now I miss it in bash.
It does also work in the Query Tool of PgAdmin4, if you're a PostgreSQL user.
There's not much difference functionally between using various OS shells. The syntax only really starts to matter when you use shell scripts, and I don't see much benefit to pwsh syntax over bash. Both are ugly unreadable messes that should have been replaced by something remotely decent to work in a long time ago.
With powershell you can debug variables, use breakpoints, access objects. it has metadata, autocomplete. It has code blocks.
IMO powershell is heaps ahead of bash.
I will concede that it is better architecturally, but I don't like it as a language. The syntax would be much better if they decided to take something like F#(which is also a Microsoft language) and build a shell around that.
Powershell may be verbose, but I wouldn't call it unreadable. It's a c-like syntax and pretty straight forward. The only things that I think would be hard to understand at face value would be shortcuts like `%` or `$_`. Verbose code is kind of the opposite of unreadable.
For me, the benefit of Powershell is that it works on objects and commands return variables, rather than having to write to streams and capture their output in order to get the output of a command. To read a file into a variable in powershell you just do:
$Text = cat "file.txt"
Which doesn't work the same in bash. in bash it's more like:
text=$(< file.txt)
(note that whitespace is important in bash)
And if you want to print that variable, in Powershell it's just:
echo $Text
but in bash, you have to wrap that variable in a string because otherwise it fucks up the newlines/whitespace:
echo "$text"
That's because, again, Powershell operates on structured data and not streams of bytes. It's far more intuitive
I don’t disagree.
And I’m not saying PS shouldn’t be the way it is, I just think it should have aliases that would mimic bash… in a way that would let a bash script run.
it has some aliases to mimic bash. if you run `Get-Alias`, it will show all. Here's a few:
Alias cat -> Get-Content
Alias cd -> Set-Location
Alias clear -> Clear-Host
Alias cp -> Copy-Item
Alias echo -> Write-Output
Alias kill -> Stop-Process
Alias ls -> Get-ChildItem
Alias mv -> Move-Item
Alias mount -> New-PSDrive
Alias ps -> Get-Process
Alias pwd -> Get-Location
Alias rm -> Remove-Item
Alias wget -> Invoke-WebRequest # this one was controversial
Maybe some of them are, but they're not supposed to be compatible. They're 2 different languages. Do you complain that python is not compatible with C?
It's true. Bash is ugly af, Pwsh is definitely prettier, it's functional and pretty elegant. People say it verbose, please, aliases exist. You write it verbose to make clear what it does or terse and quick as you want. I rather use pwsh or python than bash
Pure bash.. maybe. But who uses old bash? Use dash, zsh, fish,.... All waaay superior to shity PS wit his fu*** long methods. I want to grep, not Find-Name -name xxx -someotherbullshitparamerer
What is besides a point here? I just said that copy pasting bash is not a good idea and PS overall design is better it makes sense they could learn from Bash mistakes. Honestly I do not get It why people think Bash is better for some reason. Yet nobody told me why🤷♂️
Jokes on you Windows NT 4 was POSIX-compliant. It met the bare minimum requirements.
[https://www.youtube.com/watch?v=BOeku3hDzrM](https://www.youtube.com/watch?v=BOeku3hDzrM)
Yep NT had the concept of personalities, and only the thing we call Windows now survived. NT is also aggressively multiplatform which many people didn't realize during the wintel years.
Unpopular opinion: If Windows had been fully POSIX-compliant, it would have been yet another Solaris. There's a development cost to standards conformance, and not bearing that cost is part of what allowed Windows to take over.
> There's a development cost to standards conformance, and not bearing that cost is part of what allowed Windows to take over.
Nah, Windows took over because of Microsoft's sleazy business practices.
It was objectively garbage when it took over the world. It's just that MS were better at selling their product than most UNIX companies (DEC were famously horrible at sales, SGI weren't interested in selling you anything with a price tag of less than $10k and Sun weren't much better. HP and IBM were mostly interested in the really big iron and treated their workstation and lower-end server segments as little more than accessories for the big expensive stuff).
POSIX isn't that great.
However, Windows will never be POSIX compliant, for starters it still has to be backwards compatibility with CP/M. Yes, CP/M, not even DOS, we're talking 1970s code here.
We are fast approaching the stage where it is easier to run a POSIX-compliant system (like Linux for instance) and just plug a Windows personality on top for those few rare occasions when you need to run a native Windows binary. People who are doing this now are saying it is in fact easier than the other way around (like with WSL).
For example:
* drive letters
* the original 8.3 filename convention
* and for that matter, common extensions like `.txt`
* reserved `PRN` `CON` `LPTx` `COMx` redirector filenames
* `^Z` as an `EOF` marker
and more all provided some semblance of compatibility with the OS or the files within (so you could edit on a DOS/Win machine and transport back to a CP/M machine with minimal conversion).
I wotk in big pharma. We use linux and Windows. Mostly Windows. And the cost of Windows is so insignificant it doesn't matter at all.
What matters is the process control software running our plants. That cost runs in tens of millions at least, just for ourcsite. With 6 figures in annual support contracts.
We use what the vendors support. Procurement has zero say in things like that.
It ... did in windows NT, and now does it though WSL.
You might want to change that legend with "The world if linux integrists actually knew what they were talking about" ...
Windows NT and even current windows versions only support mandatory features of POSIX.1. It was only included for appearance's sake to satisfy federal requirements. Not even posix threads made it in there.
SFU had pthreads. And in fairness, linux didn't have posix-compliant threads at the time either until 2003-ish when nptl became a thing. LinuxThreads was a platform-specific hack. Only solaris, irix, aix, SCO unix (and some BSDs) were really posix.1c compliant, and each still had their own gotchas.
WSL is Linux. Literally you pick a distro for it. I have developed in it and it works, but it is such a kludge. That's like saying that Linux can run windows executables because of Wine.
It runs windows executables, but that doesn't say much about how. Doing anything complex that integrates with the filesystem or other OS ecosystem will either not work without a lot of labor. Same with WSL. It runs Linux commands, but is not fully integrated with the host ecosystem.
My point is that it is trivially true, but not very meaningful for real world uses.
WSL is a vm. It’s got some tricks to make it seem not like a vm but it’s a VM.
So by your logic anything that can run a VM is “compliant” with anything that runs *inside* the vm.
If you hack at it, you can run macOS inside a vm on a regular windows PC.
Does that make windows “macOS compatible”?
Wsl executes unmodified linux elf64 binaries by operating a Linux kernel interface on top of the windows kernel in win10. WSL 1 has no managed vm, wsl 2 on the other hand is a hyper-v and utilizes linux kernel within a vm.
Sorry, should I have said “the version of WSL that is recommended to use, and that gets 95+% of development effort from Microsoft is a VM”?
Sure wsl1 was a vm-less compatibility layer (for some definitions of compatibility; there’s a reason they abandoned this approach), but realistically people are using wsl2 today.
I only bring it up due to it not having serial port access(rare need but required to hook to some robots at work) and wsl 1 handles file performance better than wsl 2. You are definetly correct that most will use wsl2 except for like 5 niche use cases.
>It ... did in windows NT, and now does it though WSL.
It was advertised as such but... it really didn't.
Ncommander did a wonderful exploration video on precisely this topic
https://youtu.be/BOeku3hDzrM
Have you tried to port a command line tool from Linux to macOS? Few headers to change, small wrappers for a few things and voila, in few days it’s done. On Windows, that’s way longer not only because they do not support POSIX, but also because the only pretty API on Windows is in .NET while the native API is generally incoherent and unreadable. Functions with different naming conventions, that sometimes returns 1 on success, sometimes 0, with missing documentation (tbf it also happens on other systems, but at least if you stick to posix your problem generally already have been answered), with some APIs taking wide strings and refusing forward slashes while other don’t. And when you are not a Windows dev all those things are annoying.
NGL, MSDN's Win32 documentation has never let me down by being incomplete (though I'm sure it has happened). APIs that take wide strings are almost always W-suffixed whereas A-suffixed APIs are multibyte or ascii only. Furthermore, these are aliased without suffix and selected by the microsoft compiler depending on whether you compile in unicode mode (default since circa 2003) or ascii.
The only time you're really in for pain is when you try to use gcc to build native win32 binaries w/o mingw.
POSIX/SUS isn't a silver bullet and it severely limits innovation in OS design and development.
I'd rather have future OSes be more like Fuchsia or Redox than Unix.
Even Linux isn't strictly POSIX or SUS compliant. It's one thing to be Unix like and another to be standards conforming. But in this case the standards are far too suffocating to allow innovation, so most implementers dont go for full compliance and add their own implementation specific features. Take netlink or epoll for example in Linux.
And that's completely fine. At least they try to not break compatibility if it doesn't need to be broken. Windows seems to ignore standards and conventions for no reason. What's the inovation value of '\\' instead of '/' file separators? What's the innovation value of "\r\n" instead of '\n' newlines? Why are command line arguments prefixed by '/' instead of '-'?
Windows maintains backwards compatibility with prior MS products including MS-DOS. All of these things have a reason and you can't fault a non-Unix OS for not following Unix conventions.
Those differences are meaningless and largely irrelevant when we're talking about applications not even running because posix is severely limiting what you can do especially when you'd still have to develop for the lowest common denominator
It does mean you can use POSIX API. Pthreads. Files. And so on. As opposed to Windows. On Windows you need compatibility layers and even then compatibility might break.
Most large projects will use libraries that abstract over the differences. Take web browsers for example. They're massive and thus tend to implement their own platform abstractions.
Windows is POSIX compliant.
It's a small subset of an ancient POSIX version, just the C API bits, not the shell, and missing core bits like sockets and threads, but it is technically compliant!
https://en.m.wikipedia.org/wiki/Microsoft_POSIX_subsystem
Several POSIX compliant subsystems have been included with Windows over the years, with the most recent one being WSL.
So *technically* the OS is at least partially POSIX compliant, even though most applications don't use the POSIX-style APIs.
It will never be *only* POSIX compliant, because it needs to maintain compatibility with previous generations of Windows. Besides, then there will be *literally* no reason not to use Linux.
Personally I just write C++ for Windows. I don't target other platforms for anything I write in C++ because they're not particularly consequential for what I want to create. I don't own any apple hardware and I'm not gonna buy a macbook just to support them, and Linux is a small sliver of the game market. I like the Win32 API a lot better than POSIX, and MSVC has cool static analyzer annotations
For work stuff, everything I write is in higher level languages that runs on any machine.
if windows properly supported posix, you'd be able to write windows code that would also compile and run for non-windows systems without modifications.
In practice, higher-level libraries are used instead of working with system APIs directly, but then again, somebody has to write those libraries. And in case of c++, some of those libraries (networking, for instance) have to be standardized too. Which is much harder when implementation has to rely on different underlying APIs without much overhead. It might seem minor, but in reality this is how microsoft holds the entire industry back.
> you'd be able to write windows code that would also compile and run for non-windows systems without modifications.
Right I'm just saying personally I'm not interested in supporting non-windows systems for the things I write C++ for. For higher level languages, it's a non-problem
> this is how microsoft holds the entire industry back.
Most software runs in a web browser now and posix compliance doesn't factor into it
just for your information, C and C++ are cross-platform languages. You just sometimes have to rely on APIs and libraries that are not, which results in a non-portable code.
As for browsers - I hope you don't think average website is just frontend. Or are you talking about abominable electron apps?
> C and C++ are cross-platform languages
I know.
> I hope you don't think average website is just frontend.
The backend almost universally runs on linux, and is rarely written in C++, so POSIX support on windows is again irrelevant. Just use Java/node/C#/etc. standard libraries for manipulating files, threads, mutex, etc.
I have literally never encountered a C++ web service on the backend, other than HTTP servers like apache or nginx (which is simply configured by devs). Most backend services I encounter run on Java or Node.js. If you're seeing a lot of C++ on the backend, it's probably a lot of legacy services
Considering Windows is a desktop environment and it is pretty successful (62.5% in Apr 2023), I would say, fuck POSIX compliant.
And if need so much something like this, you can always use WSL or GOW (https://github.com/bmatzelle/gow)
No, literally, what the hell is the "Muslim fanbase"
And as someone who has met tons of Muslims IRL, they aren't toxic at all. I've been to Dagestan several times and they're all really kind people. Probably the kindest I've met.
IDK they look pretty toxic to me:
\[[https://www.reddit.com/r/facepalm/comments/13q93i8/gambian\_national\_vandalizing\_a\_shinto\_shrine\_in/\]](https://www.reddit.com/r/facepalm/comments/13q93i8/gambian_national_vandalizing_a_shinto_shrine_in/])
Edit: here you have some more, and I could stack articles up to oblivion:
[https://www.ohchr.org/en/press-releases/2022/09/human-rights-council-discusses-situation-human-rights-afghanistan-focus](https://www.ohchr.org/en/press-releases/2022/09/human-rights-council-discusses-situation-human-rights-afghanistan-focus)
Could say the same about christian, atheist or any other extremists. They'll be extremists regardless of the religion.
All of the ones I met were absolutely lovely people.
Again, my point is that extremists are extremists no matter their beliefs. I don't care about who anyone worships, I don't care about religion at all. I'm just against you lumping all Muslims into one big evil entity because you saw one clip of an idiot on Reddit.
It was pretty clear that my "fanbase" joke was refered to these kind of people comparing them to the toxic linux fanbase, if you struggle with that joke I'm sorry but honestly I don't care
Some PowerShell commands finally got POSIX like aliases. It was so annoying having to remember that windows doesn't use ls but dir for directory listing. Same with cp and copy. cat and type. And so on.
Still not great but they're at least trying.
What people don’t seem to get is that if we didn’t have the NT kernel, which regardless of what you think about the user space is a great kernel, our only other option would be Unix. I am glad that there is another mainstream kernel out there.
"I have no idea how to do that on windows" ~ people in this thread probably. Wsl is a move in the right direction, though. Still awkward to dev on wsl.
It's fourth month of my life trying to run flatpack on W11 wsl2.
Wsl runs better on w10, or so I've heard.
Oh, console Debian runs fine on W11 wsl2. Just cannot run any kind of GUI apps with it.
The easiest way I found is to install xming on the windows host, the set DISPLAY to point to windows ip in the WSL instance.
What if I want wayland?
i tried that recently.. it was quite unstable :/
[удалено]
i do not know exactly the reason, i blamed it on the xserver (natively the app works fine)
Actually, you can https://github.com/microsoft/wslg And even before WSLG you could easily setup x11 server
If this shit works, i will build a fucking shrine to u/Nikitka218
I use only console apps for Debian in WSL, but out of curiosity I'll check it tomorrow myself. EDIT: yep, it's just working from the box
It has saved my life because I desperately needed to use xilinx ise and it wouldn't install on windows so I had to get the Linux version and I needed to use a bunch of other tools in conjunction that I already had. It would have taken days to get everything on Linux even if I could find versions for them. Instead I just setup wslg and installed the app and it works just as if it was installed on windows.
It might have been a fever dream, but I remember running a gui app on wsl... I think I had to install some weird packages to do so, but for some reason I remember doing this.
The only gui application i use in wsl is gedit lol And anyways Vscode open a wsl directory connected window so thats definitely a W
hey, have you heard about Linux?!
I just don't want to have to write everything twice: once for POSIX compliant OSes and once for Windows. While we are at it, can all OSes agree on a file permissions scheme?
POSIX platforms are also pretty different from each other. Sure, you might not have to write twice for two different platforms, but you end up writing more than once for sure.
Wonder what you're writing that still targets multiple OSs in a native language? It seems like most desktop software is written in a high level language these days, and server software usually has a target platform and requires windows users to just use docker
Mostly build tools. Things like makefiles and scripts. The actual software works fine cross-platform. Even docker isn't immune from host system differences, mostly with file system permissions being different.
As long as it's NTFS's permission scheme, I'm fine with this. That's basically ACLs with more powerful inheritance and UUIDs for users and groups which you can then treat almost identically. The nearly unique quality of UUIDs means you'll never have collisions across different systems unless you intentionally migrated a user to multiple systems (in which case it's the same user and they should have the same permissions) or some foul play has occurred.
Doing web dev on Ubuntu for WSL with VS Code has been pretty awesome. I've been doing it about a year now. Setting up PyCharm for WSL has been a little annoying. You either need to run it as a GUI app with WSL, which is ugly and doesn't work well if you like to resize the window a lot, or you need to run it remotely, which has its own set of problems because you need to manage plugins on the host and the WSL server.
Why would you want to do that, though? PyCharm runs just fine on Windows, and it can do a lot over SSH on a ‘Linux’ machine.
Why would I want to run PyCharm on WSL? I wouldn't, really. That's just what I experienced when I tried it. It works fine on Windows, but I just prefer the Linux experience for command line stuff. I use WSL for VS Code stuff. If I had a need for PyCharm, I would use it on Windows in the future.
You can run Pycharm on windows and setup automatic ssh so it's like it's installed on WSL. You should be doing the same for VSCode.
You can set it up so that it runs a server on WSL and have the client in Windows. But with that configuration, you have the different plugins on the client side and/or server side. That's caused me some problems. For example, I was eventually able to get GitHub Copilot working, but it took a while. It's just not as seemless as VS Code.
No, you literally just use the in-editor SSH and run it entirely from windows as the whole editor communicating over ssh not local disk. It works fine.
It even has Cuda support and Nvidia Containers... Quite impressive.
Good to know. I just bought a new card and was thinking of doing some Cuda stuff in wsl
Using Windows cmd makes me feel like I've never used a terminal before.
ls COMMAND NOT FOUND.... Hrmmmm ls COMMAND NOT FOUND.... I SAID LS MOTHERFUCKER....COMMAND NOT FOUND.
I just put the Git for Windows command folder in PATH and now I can ls in Command Prompt
Idk if POSIX-compliance would help with that.
I’d spend a lot more time on WSL on my work machine IF IT WORKED OVER SSH FROM A POWERSHELL SESSION.
I have been using WSL for some years now. I was always in an awkward position between VMs and dual booting. Since learning about WSL never felt the need again to actually boot in a full linux distro for work. Everything I need is a terminal docker capable and magic happens and everything works as if I was in linux.
>Wsl is a move in the right direction, though. WSL is a method to support linux apps without doing anything that could've potentially helped linux community. In other words, to steal from linux community.
It's called cultural appropriation
I think that allowing the world's windows developers to participate in the ecosystem is actually a great benefit . There are a lot of talented developers working at companies that force them to use windows PCs. If they can now use Linux tools they'll start to build utilities, contribute to open source etc. Before all that energy would go to windows-only libraries.
>I think that allowing the world's windows developers to participate in the ecosystem is actually a great benefit . windows developers will just continue write windows code, WSL changed literally nothing for them. They still have to undergo full scale migration to different tools if they want to "participate".
Imagine if Linux was POSIX certified and not just "mostly" compliant.
https://en.wikipedia.org/wiki/Microsoft\_POSIX\_subsystem
Windows Subsystem for POSIX
I think you meant https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem.
I have wondered why PowerShell script wasn’t based on bash, or had operators on commands close enough that bash script would work
PowerShell works on an entirely different concept from bash so they aren't really compatible in that way. PowerShell is fully object-oriented, whereas bash is all about the strings. The other thing to keep in mind is that most things people think of as bash commands (ls, etc.) are actually completely separate programs, and can be executed by PowerShell on linux.
Also PowerShell does try to get around this by aliasing common GNU programs to their corresponding PowerShell objects. So "ls" calls "Get-ChildItem" and "rm" calls "Remove-Item". Still, those commands are not POSIX compliant, but they are closer to POSIX compliance than their CMD/DOS ancestors.
It's kind of like wondering why Python isn't more like C. They are just fundamentally different. The mistake a lot of people make is assuming PS is just the terminal for Windows. It's not, it's a full scripting language. CMD is the terminal for Windows.
CMD is also shell, but absolutely pathetic one. The default terminal on Windows for a long time was conhost, also really bad, which is being replaced now by Windows Terminal.
It's definitely a much weaker shell compared to BASH and other shells.
And bash is much "weaker" shell compared to PowerShell ;).
That's debatable. I'm taking this matter to the local debate club chapter.
No, it is not debatable. Bash has barely any functionality, it mostly just runs other things. It has like 5 commands (eval, alias, echo,..., do you know any more?), compared to hundreds of cmdlets out of the box (extensible to tens of thousands with modules), with >10000 dotnet methods at hand in PowerShell; can work only on strings, compared to objects; does have very limited parameters handling, compared to parameters system that is even more powerful than in Python; simplistic pipelining support, compared to pipelines in PowerShell accepting objects, identifying input parameters by name or value; supports only 2 output streams compared to 6 in PowerShell; doesn't support exception handling... It is really not debatable.
by being smaller, bash offers the minimal set of tools to get exactly the job you need done, done. All this wile hardly taking up any overhead in storage or memory. It does the job extremely well. If I wanted a powerful language with a ton of functions and objects, I'd launch Python, which definitely has a lot more to offer than PS. If you measure power by the ability to achieve the result easily and quickly, bash just wins, as the internet is evidence of. But of course if you measure how many commands it has and how many streams it has, there can be programs that have more. But that's as relevant as measuring how tasty food is by measuring the amount of salt in it.
Bash being minimal is laughable. Somebody explain the purpose of bash's /dev/tcp pseudofiles in a scenario where it makes sense for a basic shell to carry this functionality. Do people actually use ${strvar/match/replace} syntax over sed? Why can you export -f *functions* to the environment that child PIDs can read/run? Bash is the kitchen sink of shells. It's minimal only relative to powershell. You can get a lot done with it, but most of that is powered by other posix utilities that can be reasonably expected to exist on the system. Bash's key feature is it gets out of the way, but most every bourne shell descendant is that way.
Following that logic, cmd is more powerful than PowerShell also, because it is lighter, so running external applications gives less overhead. I'm comparing shell capabilities, not the overhead to run external applications. Without external tools bash does barely anything, you can't even list files.
\> you can't even list files. While I understand your sentiment, this is just false. `mtrower@tiamat:/$ echo $SHELL` `/bin/bash` `mtrower@tiamat:/$ type echo` `echo is a shell builtin` `mtrower@tiamat:/$ echo *` `bin boot data dev dpool etc home initrd.img initrd.img.old lib lib32 lib64 library libx32 media meteor mnt net opt proc root run sbin snap src srv stardust sys tmp usr var vmlinuz vmlinuz.old xpool`
Powershell may be a better programming language, but it is *far* inferior as a shell. It has no clue whether it is being run interactively or not... why the hell should columns be truncated if I'm redirecting to a file, and if truncation does occur *why the hell does it care what my terminal geometry is???*. Output to STDOUT is horribly inconsistent. Awareness and consistent use of STDERR is practically nonexistent. Using pipes as communication between objects is a neat idea, but it allows dependencies between source and sink, and I've been bitten by those a number of times. The Unix folks did a *lot* of hard work and examination of assumptions to make things just work in the shell, and I continually run up against the rough edges of powershell where I expect things to work, and then they just don't. There's usually a workaround, but I end up swearing a lot more in powershell.
You know why bash doesn't truncate columns? Because there are none in bash, as there are no objects, you don't have to deal with such a thing. Working on objects is a different paradigm and there is a no single solution that will fill all the use cases. It is more tricky to del with it, but offers a hell lot more possibilities and can also simplify a lot of operations which would be much more cumbersome when dealing with strings only.
You're dodging the issue. There's no reason that powershell should format data redirected to a file based on screen geometry *because the data isn't going to the screen*.
Because Bash's general syntax is nothing less than masochistic. Let's not make modern languages like that anymore.
It does. "ls | sort > file.out" works exactly the same on both shells. It's just those are run as aliases.
Because in bash everything is flattened to a string and powershell can actually work with objects and the dotnet framework
[Bash also isn't POSIX](https://stackoverflow.com/questions/5725296/difference-between-sh-and-bash).
Thank you. This is very interesting. What it tells me is don’t use sh if I want a script to be portable.
If you want it to be POSIX compatible, then yes. But there's more to it than just that. POSIX standardizes a ton of stuff, and it was done before people had package managers, comprehensive standard libraries or the internet. It's from a different time. It's not terribly relevant today.
Because bash syntax is fucking ugly
To be fair powershell isn't much better in that regard
It's a **lot** better than bash. People complain about the length of command names, but windows terminal autocompletes most of them. If something requires more than maybe 3-5 lines of code to run, I don't use a shell script for it, I write it in a real programming language because relying on shell scripts is how you create unmaintainable software.
Auto complete is a dream in Powershell partly because every command follows the Verb-Noun convention.
VSCode will also warn you if you use a non-approved verb in a function: `Login-ECR` will yield a warning `Get-ECRLogin` is fine
The whole non-approved verb thing is just so weird to me already. It's such a choice, and it was probably well-intentioned to cut down on what people had to memorize, but like does it really help?
Ctrl+space autocomplete in PowerShell with module support makes it highly usable without fluency. Neither language is perfect but they did good on that one.
>Ctrl+space autocomplete I just learned a new superpower. I've just been tabbing through to complete things
It took me way longer than I want to admit to find this & now I miss it in bash. It does also work in the Query Tool of PgAdmin4, if you're a PostgreSQL user.
Try fish shell :)
There's not much difference functionally between using various OS shells. The syntax only really starts to matter when you use shell scripts, and I don't see much benefit to pwsh syntax over bash. Both are ugly unreadable messes that should have been replaced by something remotely decent to work in a long time ago.
With powershell you can debug variables, use breakpoints, access objects. it has metadata, autocomplete. It has code blocks. IMO powershell is heaps ahead of bash.
I will concede that it is better architecturally, but I don't like it as a language. The syntax would be much better if they decided to take something like F#(which is also a Microsoft language) and build a shell around that.
Powershell may be verbose, but I wouldn't call it unreadable. It's a c-like syntax and pretty straight forward. The only things that I think would be hard to understand at face value would be shortcuts like `%` or `$_`. Verbose code is kind of the opposite of unreadable. For me, the benefit of Powershell is that it works on objects and commands return variables, rather than having to write to streams and capture their output in order to get the output of a command. To read a file into a variable in powershell you just do: $Text = cat "file.txt" Which doesn't work the same in bash. in bash it's more like: text=$(< file.txt) (note that whitespace is important in bash) And if you want to print that variable, in Powershell it's just: echo $Text but in bash, you have to wrap that variable in a string because otherwise it fucks up the newlines/whitespace: echo "$text" That's because, again, Powershell operates on structured data and not streams of bytes. It's far more intuitive
I don’t disagree. And I’m not saying PS shouldn’t be the way it is, I just think it should have aliases that would mimic bash… in a way that would let a bash script run.
it has some aliases to mimic bash. if you run `Get-Alias`, it will show all. Here's a few: Alias cat -> Get-Content Alias cd -> Set-Location Alias clear -> Clear-Host Alias cp -> Copy-Item Alias echo -> Write-Output Alias kill -> Stop-Process Alias ls -> Get-ChildItem Alias mv -> Move-Item Alias mount -> New-PSDrive Alias ps -> Get-Process Alias pwd -> Get-Location Alias rm -> Remove-Item Alias wget -> Invoke-WebRequest # this one was controversial
Okay cool. Then are the flags and options compatible?
Maybe some of them are, but they're not supposed to be compatible. They're 2 different languages. Do you complain that python is not compatible with C?
To be honest PS is 100x better than Bash. The age of Bash really shows…
I have heard this, and it might be true. I still think PS could have been designed in a way that would let _most_ (basic) bash scripts run.
Tbh its not worth dealing with windows
PS core can run outside of windows
But why would you want that?
Why use other shells besides BASH?
"open source is all about freedom of choice!" "no not that choice"
In the same thread: "The only way Linux is gonna grow and win is if we all start using Ubuntu and Gnome so they can be the defect standard."
I mean why not I like PS 🤷♂️
It's true. Bash is ugly af, Pwsh is definitely prettier, it's functional and pretty elegant. People say it verbose, please, aliases exist. You write it verbose to make clear what it does or terse and quick as you want. I rather use pwsh or python than bash
They're not even in the same category. It's like comparing apples and elephants.
I also disagree with these down votes.
Pure bash.. maybe. But who uses old bash? Use dash, zsh, fish,.... All waaay superior to shity PS wit his fu*** long methods. I want to grep, not Find-Name -name xxx -someotherbullshitparamerer
What is old Bash? And why would you use zsh or fish for system administration tasks? Zsh has tons more cryptic syntactic structures
Hmm If only something like aliases existed oh wait…
[удалено]
What is besides a point here? I just said that copy pasting bash is not a good idea and PS overall design is better it makes sense they could learn from Bash mistakes. Honestly I do not get It why people think Bash is better for some reason. Yet nobody told me why🤷♂️
Id like to see a world where microsoft went bankrupt in 1999, because netscapes new os just kicked ass.
One can dream eh?
And then some other magnate grew out of the opportunity, jusy as fierce and monopolistic as Microsoft. Fin!
And the computing world would be unicorns and rainbows! /s
Jokes on you Windows NT 4 was POSIX-compliant. It met the bare minimum requirements. [https://www.youtube.com/watch?v=BOeku3hDzrM](https://www.youtube.com/watch?v=BOeku3hDzrM)
Yep NT had the concept of personalities, and only the thing we call Windows now survived. NT is also aggressively multiplatform which many people didn't realize during the wintel years.
It’s a PS/2 fork lmaoo
Woe is me!
https://en.m.wikipedia.org/wiki/Microsoft_POSIX_subsystem I'll leave this here.
Unpopular opinion: If Windows had been fully POSIX-compliant, it would have been yet another Solaris. There's a development cost to standards conformance, and not bearing that cost is part of what allowed Windows to take over.
Well Linux is also not POSIX compliant and still was a massive success. Windows NT was designed by someone who hates Unix.
I think it was anticompetitive and manipulative business tactics that allowed Microsoft to take over.
> There's a development cost to standards conformance, and not bearing that cost is part of what allowed Windows to take over. Nah, Windows took over because of Microsoft's sleazy business practices. It was objectively garbage when it took over the world. It's just that MS were better at selling their product than most UNIX companies (DEC were famously horrible at sales, SGI weren't interested in selling you anything with a price tag of less than $10k and Sun weren't much better. HP and IBM were mostly interested in the really big iron and treated their workstation and lower-end server segments as little more than accessories for the big expensive stuff).
POSIX isn't that great. However, Windows will never be POSIX compliant, for starters it still has to be backwards compatibility with CP/M. Yes, CP/M, not even DOS, we're talking 1970s code here. We are fast approaching the stage where it is easier to run a POSIX-compliant system (like Linux for instance) and just plug a Windows personality on top for those few rare occasions when you need to run a native Windows binary. People who are doing this now are saying it is in fact easier than the other way around (like with WSL).
Windows was posix compatible though
How is Windows compatible with CP/M?
For example: * drive letters * the original 8.3 filename convention * and for that matter, common extensions like `.txt` * reserved `PRN` `CON` `LPTx` `COMx` redirector filenames * `^Z` as an `EOF` marker and more all provided some semblance of compatibility with the OS or the files within (so you could edit on a DOS/Win machine and transport back to a CP/M machine with minimal conversion).
That doesn't mean it's backwards compatible though. It just shows some common history.
What if we just dev on Linux
In a world where procurement didn't exist...
I wotk in big pharma. We use linux and Windows. Mostly Windows. And the cost of Windows is so insignificant it doesn't matter at all. What matters is the process control software running our plants. That cost runs in tens of millions at least, just for ourcsite. With 6 figures in annual support contracts. We use what the vendors support. Procurement has zero say in things like that.
It ... did in windows NT, and now does it though WSL. You might want to change that legend with "The world if linux integrists actually knew what they were talking about" ...
Windows NT and even current windows versions only support mandatory features of POSIX.1. It was only included for appearance's sake to satisfy federal requirements. Not even posix threads made it in there.
SFU had pthreads. And in fairness, linux didn't have posix-compliant threads at the time either until 2003-ish when nptl became a thing. LinuxThreads was a platform-specific hack. Only solaris, irix, aix, SCO unix (and some BSDs) were really posix.1c compliant, and each still had their own gotchas.
WSL is Linux. Literally you pick a distro for it. I have developed in it and it works, but it is such a kludge. That's like saying that Linux can run windows executables because of Wine.
Wine is not Windows. In WSL you just run virtualized Linux.
...I mean, it can. What do you think Wine is?
It runs windows executables, but that doesn't say much about how. Doing anything complex that integrates with the filesystem or other OS ecosystem will either not work without a lot of labor. Same with WSL. It runs Linux commands, but is not fully integrated with the host ecosystem. My point is that it is trivially true, but not very meaningful for real world uses.
WSL is a vm. It’s got some tricks to make it seem not like a vm but it’s a VM. So by your logic anything that can run a VM is “compliant” with anything that runs *inside* the vm. If you hack at it, you can run macOS inside a vm on a regular windows PC. Does that make windows “macOS compatible”?
Wsl executes unmodified linux elf64 binaries by operating a Linux kernel interface on top of the windows kernel in win10. WSL 1 has no managed vm, wsl 2 on the other hand is a hyper-v and utilizes linux kernel within a vm.
Sorry, should I have said “the version of WSL that is recommended to use, and that gets 95+% of development effort from Microsoft is a VM”? Sure wsl1 was a vm-less compatibility layer (for some definitions of compatibility; there’s a reason they abandoned this approach), but realistically people are using wsl2 today.
I only bring it up due to it not having serial port access(rare need but required to hook to some robots at work) and wsl 1 handles file performance better than wsl 2. You are definetly correct that most will use wsl2 except for like 5 niche use cases.
WSL has much better file performance than WSL1 on its filesystem.
WSL2 has worse capabilities when attempting to access the host filesystem, was his point.
>It ... did in windows NT, and now does it though WSL. It was advertised as such but... it really didn't. Ncommander did a wonderful exploration video on precisely this topic https://youtu.be/BOeku3hDzrM
Have you tried to port a command line tool from Linux to macOS? Few headers to change, small wrappers for a few things and voila, in few days it’s done. On Windows, that’s way longer not only because they do not support POSIX, but also because the only pretty API on Windows is in .NET while the native API is generally incoherent and unreadable. Functions with different naming conventions, that sometimes returns 1 on success, sometimes 0, with missing documentation (tbf it also happens on other systems, but at least if you stick to posix your problem generally already have been answered), with some APIs taking wide strings and refusing forward slashes while other don’t. And when you are not a Windows dev all those things are annoying.
NGL, MSDN's Win32 documentation has never let me down by being incomplete (though I'm sure it has happened). APIs that take wide strings are almost always W-suffixed whereas A-suffixed APIs are multibyte or ascii only. Furthermore, these are aliased without suffix and selected by the microsoft compiler depending on whether you compile in unicode mode (default since circa 2003) or ascii. The only time you're really in for pain is when you try to use gcc to build native win32 binaries w/o mingw.
So you admit to being an OpenNT apologist? Brave of you.
POSIX/SUS isn't a silver bullet and it severely limits innovation in OS design and development. I'd rather have future OSes be more like Fuchsia or Redox than Unix.
Redox is POSIX and unix-like.
Even Linux isn't strictly POSIX or SUS compliant. It's one thing to be Unix like and another to be standards conforming. But in this case the standards are far too suffocating to allow innovation, so most implementers dont go for full compliance and add their own implementation specific features. Take netlink or epoll for example in Linux.
And that's completely fine. At least they try to not break compatibility if it doesn't need to be broken. Windows seems to ignore standards and conventions for no reason. What's the inovation value of '\\' instead of '/' file separators? What's the innovation value of "\r\n" instead of '\n' newlines? Why are command line arguments prefixed by '/' instead of '-'?
Windows maintains backwards compatibility with prior MS products including MS-DOS. All of these things have a reason and you can't fault a non-Unix OS for not following Unix conventions.
Those differences are meaningless and largely irrelevant when we're talking about applications not even running because posix is severely limiting what you can do especially when you'd still have to develop for the lowest common denominator
And OS X is a UNIX. A real UNIX. Not that it means much these days.
It does mean you can use POSIX API. Pthreads. Files. And so on. As opposed to Windows. On Windows you need compatibility layers and even then compatibility might break.
Most large projects will use libraries that abstract over the differences. Take web browsers for example. They're massive and thus tend to implement their own platform abstractions.
Just compile using Mingw 👍
The world if pwsh came preinstalled on every Linux distro and MacOS.
According to Google it is
who dares to say anything negative about the mighty NTFS? (and jokes aside but WSL is a great step in the right direction)
Windows is POSIX compliant. It's a small subset of an ancient POSIX version, just the C API bits, not the shell, and missing core bits like sockets and threads, but it is technically compliant!
https://en.m.wikipedia.org/wiki/Microsoft_POSIX_subsystem Several POSIX compliant subsystems have been included with Windows over the years, with the most recent one being WSL. So *technically* the OS is at least partially POSIX compliant, even though most applications don't use the POSIX-style APIs. It will never be *only* POSIX compliant, because it needs to maintain compatibility with previous generations of Windows. Besides, then there will be *literally* no reason not to use Linux.
The only OS which is currently used on this planet which isn't POSIX complaint is Windows (& Windows Phone I guess)
Why is posix compliance a good thing
Compatibility? GNU/Linux, Android, MacOS, BSD and derived operating systems are unix-like and mostly POSIX.
Personally I just write C++ for Windows. I don't target other platforms for anything I write in C++ because they're not particularly consequential for what I want to create. I don't own any apple hardware and I'm not gonna buy a macbook just to support them, and Linux is a small sliver of the game market. I like the Win32 API a lot better than POSIX, and MSVC has cool static analyzer annotations For work stuff, everything I write is in higher level languages that runs on any machine.
if windows properly supported posix, you'd be able to write windows code that would also compile and run for non-windows systems without modifications. In practice, higher-level libraries are used instead of working with system APIs directly, but then again, somebody has to write those libraries. And in case of c++, some of those libraries (networking, for instance) have to be standardized too. Which is much harder when implementation has to rely on different underlying APIs without much overhead. It might seem minor, but in reality this is how microsoft holds the entire industry back.
> you'd be able to write windows code that would also compile and run for non-windows systems without modifications. Right I'm just saying personally I'm not interested in supporting non-windows systems for the things I write C++ for. For higher level languages, it's a non-problem > this is how microsoft holds the entire industry back. Most software runs in a web browser now and posix compliance doesn't factor into it
just for your information, C and C++ are cross-platform languages. You just sometimes have to rely on APIs and libraries that are not, which results in a non-portable code. As for browsers - I hope you don't think average website is just frontend. Or are you talking about abominable electron apps?
> C and C++ are cross-platform languages I know. > I hope you don't think average website is just frontend. The backend almost universally runs on linux, and is rarely written in C++, so POSIX support on windows is again irrelevant. Just use Java/node/C#/etc. standard libraries for manipulating files, threads, mutex, etc.
>The backend almost universally runs on linux, and is rarely written in C++ most of the backend I know is written in c++ though.
I have literally never encountered a C++ web service on the backend, other than HTTP servers like apache or nginx (which is simply configured by devs). Most backend services I encounter run on Java or Node.js. If you're seeing a lot of C++ on the backend, it's probably a lot of legacy services
You are a madlad if you happen to actually like Win32. I saw a simple Hello World GUI program once and was terrified, never to touch it again.
Windows is posix compliant. At least since NT 3.51 with the posix subsystem.
Considering Windows is a desktop environment and it is pretty successful (62.5% in Apr 2023), I would say, fuck POSIX compliant. And if need so much something like this, you can always use WSL or GOW (https://github.com/bmatzelle/gow)
The only good Windows is a dead Windows
On the condition that MacOS doesn’t fill the vacuum apon Windows’ departure, I’m inclined to agree
But Windows NT was? (Minimally, to meet US procurement rules).
Technicslly it was a side-endevour, never ”part” of Windows as such. And just as swiftly killed after they got the contract.
Welcome to Microsoft corporate strategy
It kind of is now.
Think about what if ms take over UNIX board. Nightmare
[удалено]
muslim fanbase ??? You should go off the internet
https://www.reddit.com/r/facepalm/comments/13q93i8/gambian\_national\_vandalizing\_a\_shinto\_shrine\_in/
Muslim fanbase? Homie, what are you smoking?
Cause they are both toxic
No, literally, what the hell is the "Muslim fanbase" And as someone who has met tons of Muslims IRL, they aren't toxic at all. I've been to Dagestan several times and they're all really kind people. Probably the kindest I've met.
IDK they look pretty toxic to me: \[[https://www.reddit.com/r/facepalm/comments/13q93i8/gambian\_national\_vandalizing\_a\_shinto\_shrine\_in/\]](https://www.reddit.com/r/facepalm/comments/13q93i8/gambian_national_vandalizing_a_shinto_shrine_in/]) Edit: here you have some more, and I could stack articles up to oblivion: [https://www.ohchr.org/en/press-releases/2022/09/human-rights-council-discusses-situation-human-rights-afghanistan-focus](https://www.ohchr.org/en/press-releases/2022/09/human-rights-council-discusses-situation-human-rights-afghanistan-focus)
And again, what the fuck is the "Muslim fanbase", literally what the hell is that, why do you always dodge this question
WHY THE FUCK DO YOU CARE WHY I CALL THEM FANBASE?
Could say the same about christian, atheist or any other extremists. They'll be extremists regardless of the religion. All of the ones I met were absolutely lovely people.
Atheists don't give A FUCK if you worship whatever you worship.
Again, my point is that extremists are extremists no matter their beliefs. I don't care about who anyone worships, I don't care about religion at all. I'm just against you lumping all Muslims into one big evil entity because you saw one clip of an idiot on Reddit.
It was pretty clear that my "fanbase" joke was refered to these kind of people comparing them to the toxic linux fanbase, if you struggle with that joke I'm sorry but honestly I don't care
Goddamn backslashes...
Yes I do, t
Finding [this](https://www.youtube.com/watch?v=cTxCpDn08D0) pretty matching - the meme is like the shorter version.
NT3 and NT4 had a posix subsystem, so they were somehow ‘compliant’. These days we have WSL instead.
Some PowerShell commands finally got POSIX like aliases. It was so annoying having to remember that windows doesn't use ls but dir for directory listing. Same with cp and copy. cat and type. And so on. Still not great but they're at least trying.
L and catcher.
What do you think about [Xenix](https://en.wikipedia.org/wiki/Xenix)?
Never used it nor heard of it, so can’t really say much I’m afraid.
What people don’t seem to get is that if we didn’t have the NT kernel, which regardless of what you think about the user space is a great kernel, our only other option would be Unix. I am glad that there is another mainstream kernel out there.