The initial argument was that MacOS is nice because it has the core Unix tool. I find this baffling because MacOS has very little to do with a traditional Unix apart from the certification and the core utils are literally usable on approximately anything.
Speed bumps regarding what?
I’m mostly using Linux nowadays but when I have to use Windows, the experience is fairly ok. The tooling when you want to manage it is imho superior to what Apple provides. I’m not used to develop on it but I have seen people do and it didn’t seem particularly worse than Linux-like environment.
Not that I really have anything against MacOS. I think it’s neglected by Apple and not as enjoyable as it used to be. I dislike Apple and the policies it’s pushing for. Nevertheless, it’s ok to use. Everything pretty much is nowadays.
When producing cross-platform software I find creating it on Linux first to be the most cost effective. Porting it to macOS has the least resistance. Windows is where it cost more time and code to release.
macOS, Linux, and BSD treat CMD and GUI applications the same while Windows separates applications. Window's two type of application approach brakes the ability to use STDIN and STDOUT for logging and other useful means. Simple debugging of `./app > app.log` does not work on Windows with `app.exe > app.log` with GUI applications. The Windows variant needs a specialized logging system and more boilerplate code.
Windows also has one of the worst automation system when it comes to solution deployment. One needs to create custom mouse and keyboard emulation scripts to automate the installation of 3rd party applications when their installer does not support silent mode. AutoIT helps me with this greatly.
Windows does have quirks: MSI installers, Inno Setup, NSIS, and custom EXEs may or may not support silent mode. When they don’t, automation is ugly (AutoIt, AutoHotKey).
But Windows also has strong automation tooling: PowerShell, WinRM, Chocolatey, Winget, MSIX packaging. These provide far more than “mouse and keyboard emulation.”
So your statement ignores the modern ecosystem and overstates the weakness.
If you mean UNIX System V via green phosphor text terminals, thankfully not.
Speed bumps regarding compilation of tooling written with UNIX semantics in mind, without taking into consideration Windows development culture and OS semantics.
Linking to Glibc? Sharing a roughly similar file system structure? Expecting bash to be there?
Because from where I stand the people that care about BSD have spent the past decade complaining it’s getting more and more complicated to port Linux software so I’m very curious to know what the common DNA is supposed to be.
The initial argument was that MacOS is nice because it has the core Unix tool. I find this baffling because MacOS has very little to do with a traditional Unix apart from the certification and the core utils are literally usable on approximately anything.
Speed bumps regarding what?
I’m mostly using Linux nowadays but when I have to use Windows, the experience is fairly ok. The tooling when you want to manage it is imho superior to what Apple provides. I’m not used to develop on it but I have seen people do and it didn’t seem particularly worse than Linux-like environment.
Not that I really have anything against MacOS. I think it’s neglected by Apple and not as enjoyable as it used to be. I dislike Apple and the policies it’s pushing for. Nevertheless, it’s ok to use. Everything pretty much is nowadays.
When producing cross-platform software I find creating it on Linux first to be the most cost effective. Porting it to macOS has the least resistance. Windows is where it cost more time and code to release.
macOS, Linux, and BSD treat CMD and GUI applications the same while Windows separates applications. Window's two type of application approach brakes the ability to use STDIN and STDOUT for logging and other useful means. Simple debugging of `./app > app.log` does not work on Windows with `app.exe > app.log` with GUI applications. The Windows variant needs a specialized logging system and more boilerplate code.
Windows also has one of the worst automation system when it comes to solution deployment. One needs to create custom mouse and keyboard emulation scripts to automate the installation of 3rd party applications when their installer does not support silent mode. AutoIT helps me with this greatly.
Windows does have quirks: MSI installers, Inno Setup, NSIS, and custom EXEs may or may not support silent mode. When they don’t, automation is ugly (AutoIt, AutoHotKey).
But Windows also has strong automation tooling: PowerShell, WinRM, Chocolatey, Winget, MSIX packaging. These provide far more than “mouse and keyboard emulation.”
So your statement ignores the modern ecosystem and overstates the weakness.
3 replies →
If you mean UNIX System V via green phosphor text terminals, thankfully not.
Speed bumps regarding compilation of tooling written with UNIX semantics in mind, without taking into consideration Windows development culture and OS semantics.
What are these mythical Unix semantics?
Linking to Glibc? Sharing a roughly similar file system structure? Expecting bash to be there?
Because from where I stand the people that care about BSD have spent the past decade complaining it’s getting more and more complicated to port Linux software so I’m very curious to know what the common DNA is supposed to be.
7 replies →