4 ms·

Fundamental problem with the classic: >benefits of standardization trumps openness Is that openness provides the same benefits of a standard. A ground floor t

Fundamental problem with the classic: >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).

cwyers 12y ago
Well, that's not really the whole story, though. Look at Linux. Linux is "open." Linux is also a much harder target to write software for than OS X or Windows, because a lot of people do a lot of different things with that openness, and so you can't count on a specific version of certain APIs or ABIs being there. If modern CPUs looked like modern Linux distributions, a lot more effort would be required to make software portable and to run widely. (The irony here is that ARM resembles this Tower of Babel situation a lot more than x86 does.)
- niklasni1 12y ago
  re: linux I find that's less true than it used to be, at least on x86; I run a few pieces of non-free software, binary software (Xilinx tools, Renoise) and it's problem free. Huge statically linked blobs though.
- Zardoz84 12y ago
  I found that programming for Windows is a pain in the ass compared to GNU/Linux. If I need a library, I only need to do a apt-get install XXX or download the source ode and it will compile with usually zero problems. I can't say anything about OS X
  - cwyers 12y ago
    I'm not talking about writing software, so much as I am talking about distributing software. Yes, you can use apt-get to install whatever libraries you need, but you can't guarantee that users are going to have access to the same version as you through their distro's repo, so you have to either statically link the version of each library you wrote the code with, or wait for your software to be picked up by a maintainer for all the common distros out there.
    - zanny 12y ago
      Packages do fix this problem though. You specify dependencies in your target distros package you make, and either you duplicate that dependency graph across distros (bad idea) or you let that distros packagers handle it (good idea). 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.
      - cwyers 12y ago
        This only works if you let the distros handle all the work for you. But say you need an Apache version RHEL 6 doesn't have, so now you have to build from source. And now you have to build PHP from source, because now RHEL's PHP package won't run with your new Apache. On Windows, this requires that you run two MSI files and hit okay a few times. On Linux, this means you're compiling everything from source. Linux apps are less portable between distributions than Windows apps are among Windows versions (hell, thanks to WINE a randomly picked Windows app is more likely to run on both Fedora and Ubuntu without modification than an actual Linux app is, the distribution just hides that work from you most of the time).
  - Igglyboo 12y ago
    OS X has good package managers but they aren't as intwined with the os as aptitude or yum, for better or worse. Homebrew and Macports are the most popular package managers.
  - GFK_of_xmaspast 12y ago
    "will compile with usually zero problems" 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.
- valarauca1 12y ago
  In Linux if I want to create a file I call 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.
  - pjmlp 12y ago
    The fallacy is that the world enjoys a lot more diversity in OS systems than just Windows or POSIX compatible.
  - angersock 12y ago
    Both of your examples explode pretty badly once you start adding the additional Linux/POSIX code to fully match the functionality that the Windows stuff has. 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.
    - orbifold 12y ago
      Linux/Unix has a significantly lower barrier to entry compared to Windows and a much nicer command line interface that just works by default. Want to install a C compiler? Just run apt-get install gcc and you are golden. Same for python, ruby, haskell and any other language under the sun. I've barely used Windows since I've outgrown the my fascination for computer games, it has nothing compelling to offer for someone working in a scientific environment, who is not forced to use Microsoft Office.
- kps 12y ago
  > 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.

cwyers 12y ago

Well, that's not really the whole story, though. Look at Linux. Linux is "open." Linux is also a much harder target to write software for than OS X or Windows, because a lot of people do a lot of different things with that openness, and so you can't count on a specific version of certain APIs or ABIs being there. If modern CPUs looked like modern Linux distributions, a lot more effort would be required to make software portable and to run widely. (The irony here is that ARM resembles this Tower of Babel situation a lot more than x86 does.)

niklasni1 12y ago
re: linux I find that's less true than it used to be, at least on x86; I run a few pieces of non-free software, binary software (Xilinx tools, Renoise) and it's problem free. Huge statically linked blobs though.
Zardoz84 12y ago
I found that programming for Windows is a pain in the ass compared to GNU/Linux. If I need a library, I only need to do a apt-get install XXX or download the source ode and it will compile with usually zero problems. I can't say anything about OS X
- cwyers 12y ago
  I'm not talking about writing software, so much as I am talking about distributing software. Yes, you can use apt-get to install whatever libraries you need, but you can't guarantee that users are going to have access to the same version as you through their distro's repo, so you have to either statically link the version of each library you wrote the code with, or wait for your software to be picked up by a maintainer for all the common distros out there.
  - zanny 12y ago
    Packages do fix this problem though. You specify dependencies in your target distros package you make, and either you duplicate that dependency graph across distros (bad idea) or you let that distros packagers handle it (good idea). 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.
    - cwyers 12y ago
      This only works if you let the distros handle all the work for you. But say you need an Apache version RHEL 6 doesn't have, so now you have to build from source. And now you have to build PHP from source, because now RHEL's PHP package won't run with your new Apache. On Windows, this requires that you run two MSI files and hit okay a few times. On Linux, this means you're compiling everything from source. Linux apps are less portable between distributions than Windows apps are among Windows versions (hell, thanks to WINE a randomly picked Windows app is more likely to run on both Fedora and Ubuntu without modification than an actual Linux app is, the distribution just hides that work from you most of the time).
- Igglyboo 12y ago
  OS X has good package managers but they aren't as intwined with the os as aptitude or yum, for better or worse. Homebrew and Macports are the most popular package managers.
- GFK_of_xmaspast 12y ago
  "will compile with usually zero problems" 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.
valarauca1 12y ago
In Linux if I want to create a file I call 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.
- pjmlp 12y ago
  The fallacy is that the world enjoys a lot more diversity in OS systems than just Windows or POSIX compatible.
- angersock 12y ago
  Both of your examples explode pretty badly once you start adding the additional Linux/POSIX code to fully match the functionality that the Windows stuff has. 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.
  - orbifold 12y ago
    Linux/Unix has a significantly lower barrier to entry compared to Windows and a much nicer command line interface that just works by default. Want to install a C compiler? Just run apt-get install gcc and you are golden. Same for python, ruby, haskell and any other language under the sun. I've barely used Windows since I've outgrown the my fascination for computer games, it has nothing compelling to offer for someone working in a scientific environment, who is not forced to use Microsoft Office.
kps 12y ago
> 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.