- The freedom to run the program as you wish, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Access to the source code and an open-source license are necessary preconditions for software freedom, but not sufficient.
And, unfortunately, we are living in an era where it is becoming ever more difficult to exercise the freedoms listed above.
Consider freedom 0. In the past, essentially all free software ran perfectly well on essentially every hardware platform and operating system. At the present time, much of what claims to be open-source software is horrendously platform-specific - sometimes by ignorance (I don't expect every developer to be able to test on all platforms), but there's a disturbing trend of deliberately excluding non-preferred platforms.
There is increasing use of new languages and runtimes, which are often very restricted in terms of platform support. If you look at some of the languages like Node.JS, Go, and Rust, you'll see that they explicitly target the common hardware architectures (x86 and ARM), deliberately and consciously excluding other platforms. Add to that the trend for self-referential bootstrapping (where you need X to build X) and you can see other platforms frozen out entirely.
So, much of freedom 0 has been emasculated. What of freedom 1?
Yes, I might be able to look at the source code. (Although, in many cases, it is opaque and undocumented.) And I might be able to crack open an editor and type in a modification. But actually being able to use that modification is a whole different ball game.
Actually building software from source often enters you into a world of pain and frustration. Fighting your way through Dependency Hell, struggling with arcane and opaque build systems, becoming frustrated with the vagaries of the autotools (remember how the configure script works - it makes a bunch of random and unsubstantiated guesses about the state of your system, the ignores half the results, and often needs explicitly overriding, making a mockery of the "auto" part), only to discover that "works on my system" is almost a religion.
Current trends like Docker make this problem worse. Rather than having to pay lip-service to portability by having to deal with the vagaries of multiple distributions, authors can now restrict the target environment even more narrowly - "works in my docker image" is the new normal. (I've had some developers come out and say this explicitly.)
The conclusion: open-source software is becoming increasingly narrow and proprietary, denying users the freedoms they deserve.
5 comments:
With regds to freedom 0, were you having SPARC in mind?
Ah, so you've hit the old "works on my machine!", have you?
The computer world we live in is an ever increasingly ignorant one. People who used to dabble on Windows at home have now switched to Linux at home, because it's trendy and "advanced" to run Linux.
./configure (and the entire autotools and friends) is a steaming pile of excrement, always was, and always will be. Have you ever tried to debug it? 60,000+ lines of machine generated shell code, good luck with that, I always tell myself, take a deep breath and hope that today, I will win the lottery and find the offending piece of dumbass logic. Where support for Solaris exist, my "favorite" thing to find in there is hardcoded linking with /usr/sfw/lib(/64)* - it's the best. Apparently the dear old developers never read Keith's "libsunw_ssl, or, How SmartOS Avoids Sadness" in order to even begin to grasp the wrongfulness of their ways.
And, things will only get worse unless we all do something about it. What can you do? Teach them UNIX. Not GNU/Linux, UNIX.
And to answer the previous poster: it's not just SPARC, although of course Google V8 is a blatant offender there, it's support for ANYHTING that is not GNU/Linux. And GNU/Linux as an operating system is now at the point where it sucks as badly as Microsoft(R) Windows(R) - one can clearly see that the Windows crowd mentality has permeated the architectural and technical decisions in GNU/Linux operating systems - these people never learned UNIX at home like the rest of us, so they are not in a position to grasp higher concepts, and it shows, very painfully, too.
And while on the subject of autotools, there are so few operating systems left in use today, that providing one generic Makefile with build rules, and one Makefile.`uname` would be practical - and very UNIXy, not to mention so much more reliable and simpler to use and maintain.
Makefile.SunOS
Makefile.Linux
Makefile.HP-UX
Makefile.Windows
Makefile
...Adding support for a new platform would be as simple as writing a thin Makefile.something, for example Makefile.AmigaOS, or Makefile.AtariST, without having to mess with the build rules.
Been there, debugged the equally gross libtool shell script, got the scars thank you! Seriously, how complicated can you make building a shared library??!
Almost certainly any file called "Makefile" is riddled with GNU make-isms, and should be named "GNUMakefile" instead.
Oh, libtool is the worst of them all, also machine generated, trying to debug it and find the dumbass logic is like winning "Swisslos" and "Euromillions" together. The source file which is used to generate the libtool shell program does not make much more sense either.
My "favorite" libtool idiocy is that in Gordon Matzikeit's village, they apparently never heard of (or discovered) the $ORIGIN linker keyword, so if one has $ORIGIN somewhere in the link line, libtool will break saying something like
"libtool: only absolute pathnames are allowed"
...the shere idiocy of it all. To somewhat lessen the pain, I have had to build and heavily modify my own version of libtool, where I simply ripped the idiotc checks (two case ... esac clauses) out of the code, and replaced the Korn-shell dependent "print" with a /bin/printf, and added better support for more than just "when all I know is a GCC, the only compiler in the world which could possibly ever exist is GCC"...
...All in all, it is an extremely frustrating and sad state of affairs. Perhaps the most galling of it all is that those same people, as well as mavericks and public figures of open source, are deeply convinced that GNU products are the best there ever was, and the quality the higher in comparison to professionally written code. While there are about 2% of the GNU and open source projects combined, that really are state of the art, the rest is far from what they claim.
Post a Comment