>benefits of standardization trumps openness
Is that openness provides the same benefits of a standard. A ground floor that everyone can stand on, build on, and has no cost of entry (unlike a business ran standard).
>benefits of standardization trumps openness
Is that openness provides the same benefits of a standard. A ground floor that everyone can stand on, build on, and has no cost of entry (unlike a business ran standard).
I can't say anything about OS X
For example, you can make a deb that works on Debian, Ubuntu, and any of its derivatives with its dependency graph. You can do the same with Fedora. And the Arch ecosystem will just use PKGBUILDs of the rpm or deb to package it themselves.
Things are a lot better for this in 2014 than they were in 2004 (much less 1994) but I still regularly run into things that need quite a bit of handholding to build.
err = open("/path/to/the/file/I/want/to/make", "rw");
In Windows if I want to create a file I call err = CreateFile(TEXT("input.txt"), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
:.:.:In Linux if I want to fork a process to create a sub-process I call
err = fork();
err = exec(a.out);
//now two instances of a.out are running!
In windows bRet = CreateProcess ("myapp.exe",NULL,NULL, NULL, FALSE, 0,NULL, NULL,&sui,&pi);
//now one instance of my app is running...
In conclusion, no. Linx/Posix is far nicer then Windows/NT. There's a reason we've been using the same interfaces since 1973, they're very clean and very nice.Show me the full linux/POSIX code to open a file with different security access modes, with different sharing models, with different dispositions (when should the new file be created, if it should be created, and what should happen to an existing file with same path), with hinting to the OS how to handle the file (should it be encrypted, should it be deleted once all handles are closed to it, etc.).
Show me the full linux/POSIX code to open a process while setting the security ACLs and whatnot for it, setting its priority level, setting the environment strings, setting up the stdin/stdout/stderr file descriptors, setting the window position (if any), etc.
Linux/POSIX aren't nicer than Windows/NT--they're simpler APIs for a simpler world. That doesn't make them better or worse, they're just different tools.
Maybe now you've 'outgrown' video games you can outgrow thinking that your user experience is authoritative. Better, nicer, whatever, these are all just words people use to praise things that they like.
But saying Linux / Unix has a lower barrier to entry than Windows is the kind of thing only a long-time Linux user can say with a straight face. Unless you are talking about money, and then, well... yeah.
Python/Ruby/etc. are also available on Windows, usually with friendly installers.
Look, I'm all for Linux/POSIX from an operations standpoint, but the programming story is merely different, and to pretend otherwise makes one look foolish.
EDIT:
Also, as cobrausn pointed out, what about when the official sources for the package are hella out of date? Not so friendly then, eh?
Except that everyone and their grandmother knows how to use a windows machine and no one(relatively speaking) knows how to use linux.
Don't get me wrong I use OS X/Ubuntu daily and die when I have to use Windows with it's lack of POSIX compliance and abomination of a shell but that doesn't mean it's the right choice for the masses.
> The irony here is that ARM resembles this Tower of Babel
> situation a lot more than x86 does.
Indeed it's possible to have two ‘ARM architecture’ processors with no code that can run on both.