| |||||||||||||
OpenIndiana lead Alasdair Lumsden resignsOpenIndiana lead Alasdair Lumsden resignsPosted Aug 30, 2012 22:58 UTC (Thu) by peterj (guest, #86487)Parent article: OpenIndiana lead Alasdair Lumsden resigns
I am sorry to hear this. Anything that reduces diversity reduces the resilience of an ecosystem. Unfortunately, it seems that the niche OI was aimed at failed to attract a critical mass and the commercial variants of Illumos didn't see any benefit in supporting OI.
Alasdair is right that GNU/Linux is a monoculture - just because it's OSS doesn't prevent this.
Some of this is active antagonism to anything other than Linux. Witness the attitude of MongoDB in the link Alasdair posted: "you're not using Linux, we don't want to hear from you". And cases where Linux developers have deleted all the code not needed for Linux on previously portable code.
This is fostered by GNU's "extend-and-embrace" approach - lots of seemingly nice but non-standard extensions that lock you into GNU. Whether intentionally or not, lots of OSS developers write "C" code that can only be compiled by gcc and scripts beginning "#!/bin/sh" that fail on POSIX shells. Libtool and autotools are classic double- speak - they claim to promote portability but actually do the opposite - the code might be portable but autotools and libtool still endeavour to make building the code as painful as possible unless you have a GNU toolchain (preferably on Linux).
(Log in to post comments)
OpenIndiana lead Alasdair Lumsden resigns Posted Aug 30, 2012 23:27 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> Anything that reduces diversity reduces the resilience of an ecosystem
I disagree with this. The ecosystem requires lots of experimentation, some of those experiments result in things that are _worse_ than what was there to start with.
failure of experiments is the flip side of being able to experiment.
some failures are small (how many people write perfect code the first time? how many people have never written a patch that broke something?)
some failures (distros, the OI project) are much larger. It's too bad that it took so much time and resources, but even in failure there are good things that happened
There were a lot of people who got involved in FOSS software who had not done so before. Yes, we will probably loose some of those people as the one project they were working on goes away, but I'll bet we don't loose them all. And even those who we loose as developers are probably now far more willing to use or recommend FOSS software than they were before getting involved.
> Alasdair is right that GNU/Linux is a monoculture
It's funny to read this at the same time I'm reading that the reason that we haven't had the "year of the Linux desktop" is because Linux is so fragmented :-)
OpenIndiana lead Alasdair Lumsden resigns Posted Aug 31, 2012 2:48 UTC (Fri) by marcH (subscriber, #57642) [Link]
Breaking compatibility does not require a different culture.
OpenIndiana lead Alasdair Lumsden resigns Posted Aug 31, 2012 11:04 UTC (Fri) by drag (subscriber, #31333) [Link]
Yeah. Everybody in 'linux land' is using the just about the same version of the same software as everybody else, but can't get along with each other enough to actually work out the niggling technical details of how they use the software in order to not make it hell for application developers.
The solution that has come up so far is to put a HUGE amount of effort in repackaging the same software a dozen different times to make up for those relatively tiny differences.
Meanwhile people that actually are trying to move things forward are always met with derision and are lambasted for not following a imaginary and continuously shifting unix methodology/ideology that is used to justify all sorts of weirdness in the system. The flip side of the coin is full of people whose main approach to deciding system design is simply to not decide anything at all and make users and developers deal with a thousand different possible combinations of this-or-that.
It is not so much a monoculture as a monodisfunction.
But in the end I still prefer it to the alternatives.
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 2, 2012 21:04 UTC (Sun) by nix (subscriber, #2304) [Link] Libtool and autotools are classic double- speak - they claim to promote portability but actually do the opposite - the code might be portable but autotools and libtool still endeavour to make building the code as painful as possible unless you have a GNU toolchain (preferably on Linux).This is obviously an entirely different autotools and libtool than I have used, perhaps from a parallel dimension or something. The autotools (and gnulib) maintainers are some of the most portability-crazed people I have ever heard of.
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 3, 2012 11:13 UTC (Mon) by schily (guest, #60311) [Link]
Try to have a look beyond your own nose:
libtool handles "portability" on Linux but does not even handle basic ld features like -L and -R options correctly.
All a bit more complex projects have problems compiling on Solaris because usually -R is not used and the linked binaries thus will not find their libraries and this is definitely not a Solaris caused problem.
BTW: even "autotools" is a step from autoconf into the wrong direction. Autoconf (as documented by the FSF is based on self modifying makefiles - a technique from the 1970s). What the FSF calls "automake" is definitely not an automake program but something that makes people believe that it will create portable makefiles but does not. What it really does is to propagate code that depends on bugs and extensions of gmake.
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 5, 2012 23:57 UTC (Wed) by nix (subscriber, #2304) [Link] Well, this is the kind of attention to detail that gives you (and Solaris, alas, if people should think you have anything to do with Solaris, which thankfully you do not) a bad name. (If people want to see what Solaris hackers are actually like, I recommend talking to Alan Coopersmith. A more charming and helpful man was never born.)The -R (DT_RPATH) handling in Libtool was very carefully thought out specifically so as to work properly on both systems with an /etc/ld.so.conf-equivalent (like Linux) and systems which prefer DT_RPATH (like Solaris). If you have a problem with it, I might recommend you report it: but configure / make / make install with a variety of prefixes and DESTDIRs works perfectly in my testing. (There have been bugs in this area, but not for a long time). It is definitely unacceptable to just use DT_RPATH, since that would torpedo Linux systems. Instead, we provide an implementation which permits you to use -R to get the effect of DT_RPATH, while instead providing whatever implementation is preferred on the system being used (including 'none' for systems like Linux, if the user so requests). That's kind of what Libtool is all about, after all. As for 'self modifying makefiles', you really do have no clue what you're talking about here. Autoconf is based on M4-driven generation of shell scripts. Automake is based on Perl-driven generation of makefiles (which do in fact warn about non-POSIX-make features, but most people sensibly don't care because GNU make is portable and most non-GNU makes are a horror show: here I explicitly include the coredumping halfwitted feature-free pile that is Solaris make: I have fairly frequent nightmares about the ten years I spent forced to keep things working with it). Nothing whatsoever in GNU autotools is based on 'self-modifying Makefiles'. Perhaps you are talking about the dependency generation in Automake-driven makefiles, which does rely on generation of makefile fragments which are then included, but does not require self-modifying a makefile, unlike the 'make depend' system it generally replaced. The makefile-fragment scheme may be 'a technique from the 1970s' but I'll note that this is both a non sequitur and untrue, since makes didn't have the ability to automatically reload their makefiles if their include dependencies had been modified until long long after that. Furthermore, it doesn't matter how old the scheme is: it works, and it is completely transparent to the user, unlike the horrible old 'make depend' system, which worked fine until you deleted or moved a file with generated dependencies, whereupon everything fell down in a screaming heap until you hand-hacked the dependencies or did a complete 'make clean' and rebuilt. Clearly you haven't read Paul D. Smith's excellent paper on this algorithm (due to Tom Tromey), which clearly describes the reasons why the scheme was implemented as it was. (Actually, sorry, perhaps I was wrong: quite possibly you have read that paper. I'd forgotten how immune to reasoned argument you are. My apologies. For a moment I thought I was talking to a rational being.) (corbet: sorry about the tone here, but I consider it important to refute schily's untruths, and further that, to be blunt, driving off schily before he converts the entire site into a single giant flamewar is more important than civility in this instance, not least since schily has long since proved himself incapable of civilized discourse. We are talking about someone who got himself banned from the Debian bugtracker(!) for repeated kibozing and trolling, after all.)
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 6, 2012 10:45 UTC (Thu) by schily (guest, #60311) [Link]
People like you are responsible for the bad taste Linux has in the public.
Attacking people for a bug description is more than a fauxpas....
BTW: this was different before aprox. 2004. Before that time Linux people generally have been very polite and helpful. Since then there are so many unfriendly people that these people unfortunately dominate the rest in the public.
Looking at your reply shows that you don't know what you are talking of.
- If you like to associate -R with an environment, it is LD_RUN_PATH.
- Linux uses the old runtime linker that was written for a.out
- It may be that recent libtool versions are better, but there is too much
- It seems that you just know too few things about GNU autoconf.
- Using "configure" to create something like config.h (as done in the
- It seems that Paul Smith copied the ideas for a more modern
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 6, 2012 13:04 UTC (Thu) by mpr22 (subscriber, #60784) [Link] It may be that recent libtool versions are better, but there is too much software out that uses non-working versions That's not an argument for claiming that libtool is bad. That's an argument for claiming that the software that uses bad versions of libtool is bad (and I will cheerfully admit that there's a lot of badly maintained software out there that, if it runs on anything except Linux, does so only by serendipity). ELF has a RUNPATH property that is better than the method in the old a.out system. And the GNU dynamic linker, used on Linux, supports it.
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 8, 2012 16:08 UTC (Sat) by nix (subscriber, #2304) [Link]
Oh gods, this is hilarious. Unintentionally, of course, but still.
Let's go down your fun little list one by one, as far as it is worth it to go.
- DT_RPATH does exist. It is the name of the ELF dynamic tag that is used to implement various linkers' RPATH flags. (It sucks because it wires paths into binaries in a way that is impossible to override without binary editing: DT_RUNPATH sucks slightly less, but still wires paths into binaries, which is less than good).
- The glibc runtime linker was rewritten from scratch for ELF support. It doesn't support a.out, and never has. Linker caching exists because it provides a huge speedup over searching at runtime; its search path exists to allow that to be customized; and RUNPATH is a mild abomination, as you would immediately realize if you had ever had a binary with a runpath that had a path baked into it (often a build path) which was pointing to an NFS server that had become unavailable. I've used Solaris for many, many years, and believe me the number of bugs we had reported that were attributable to mis-set LD_LIBRARY_PATHs (which were *all supposed to have the same value* and which on Linux would just have been set in /etc/ld.so.conf) was simply astonishing.
The rest of your comment is as far as I can tell pure ad hominems, arguments from authority, and straw man attacks, not worthy of a response. ("based on outdated technologies from the 1970s", I'll bet if I ask the actual authors, the only people who might know, they would disagree.)
|
|||||||||||||