| |||||||||||||
ISVs providing Linux downloadsISVs providing Linux downloadsPosted Sep 11, 2012 23:07 UTC (Tue) by khim (subscriber, #9252)In reply to: ISVs providing Linux downloads by drag Parent article: Meeks: Linux on the (consumer) Desktop
The big problem here is the fact that existing software in Linux is not designed to be base for a stable system. Kernel and some basic libraries (GLibC, Xlib and some other libraries) are designed to offer such an interface, but everything above it... it's a mess. Developers hate the fact that distributors make it hard to distribute software, but when they act as upstream… they break ABI left and right. And you can not have your cake and eat it too: either ABI breakage is tolerated, expected and distributions constantly paper it or developers of the software must keep it stable and upgradeable. And it's even worse than just libraries! Most languages in Linux world are developed with complete disregard to compatibility! C works fine (using versioned symbols), C++ has namespaces (but note that this is quite new invention: 2006 year, to be exact), but other languages... ugh. Python breaks everything in each release and Perl does the same. You literally can not offer any sort of compatibility if you use them - and yet they are considered to be part of the core (and distribution maintainers are start spewing bad words if package brings it's own version of python). To have a sane system you need core system developers at least as disciplined as GNU C++ developers—who accidentally broke compatibility between C++98 and C++11 in GCC 4.7 and fixed the problem in GCC 4.7.2 even if that made GCC less compatible with a C++ standard! Looks like they will break the ABI with GCC 4.8 - but hey, previous ABI was with us for a six years! And the plan is to still make it possible to use libraries with old ABI and a new ABI in the same process. So yes, we have sane foundation, but everything on top of it… I'm not sure what to do with that. As I've said just a few days ago It is hard. It's also necessary.
(Log in to post comments)
ISVs providing Linux downloads Posted Sep 14, 2012 16:37 UTC (Fri) by sciurus (subscriber, #58832) [Link]
Hey, give Perl some credit!
http://www.modernperlbooks.com/mt/2012/05/why-i-use-perl-...
ISVs providing Linux downloads Posted Sep 14, 2012 16:55 UTC (Fri) by khim (subscriber, #9252) [Link] Perl is in the same ballpark as PHP, Python, Ruby, TCL, PHP and other popular Linux scripting languages: totally incompatible between versions at the C ABI level. You can not even link two modules together in a single program if they use different versions of Perl! The only sane way to use it is to never use it as a glue code and bundle one specific version of the interpreter with your application (this is how OpenOffice uses python on Windows, BTW). Now, what distribution developers think about this idea? Yeah, I've hear the howls, they are loud and clear. No, Perl is very much part of the problem, not part of the solution. It (like bazillion other things in Linux) is created with the assumption that you can “recompile the world”.
ISVs providing Linux downloads Posted Sep 14, 2012 19:21 UTC (Fri) by jackb (subscriber, #41909) [Link] It (like bazillion other things in Linux) is created with the assumption that you can “recompile the world”.What's so hard about "emerge -e world"?
ISVs providing Linux downloads Posted Sep 15, 2012 16:40 UTC (Sat) by anselm (subscriber, #2796) [Link] Perl is in the same ballpark as PHP, Python, Ruby, TCL, PHP and other popular Linux scripting languages: totally incompatible between versions at the C ABI level. For Tcl that hasn't been true since version 8.1, which was released in 1999.
ISVs providing Linux downloads Posted Sep 15, 2012 17:31 UTC (Sat) by khim (subscriber, #9252) [Link] I think you have missed one small yet vital letter. I'll highlight: totally incompatible between versions at the C A⇒B⇐I level. ABI, not API. Here we go: You can not easily use TCL in any library or plugin because of that. If one plugin will use TCL 8.4 and another plugin will use TCL 8.5 you'll have Russian Roulette: it may work for sime time, but nobody can predict when (and if!) it'll kill you. Note that even Microsoft is guilty: .NET framework 1.x is totally incompatible with .NET framework 2.x. Thankfully they quickly dropped this insane idea and .NET frameworks 3.x were built on top of the CLR 2. .NET frameworks 4.x use different (and incompatible!) runtimes, but you can use in-process side-by-side hosting to run multiple versions of the CLR in a single process. Sure, you can do with TCL using some tricks with dlopen and some recompileable shims (nVidia does this even with Linux kernel ABI which is infamous for it's instability!), but… this is not something TCL authors propose and support. They push for the same tried and found wanting "recompile the world" approach.
ISVs providing Linux downloads Posted Sep 15, 2012 17:52 UTC (Sat) by anselm (subscriber, #2796) [Link] I suggest you read up on »Tcl stubs«, which is a feature that was introduced in Tcl 8.1 especially to make Tcl extensions in C usable with different (notably future) versions of Tcl. I used to do a lot of C-level programming with Tcl and this proved to be a very valuable feature because you didn't have to recompile your extensions whenever a new Tcl version came out. So no, you don't need to »recompile the world«, and indeed that is not something the Tcl authors recommend – they recommend using stubs instead so your extensions will be compatible with future Tcl versions without recompilation. In other words, you're wrong.
ISVs providing Linux downloads Posted Sep 15, 2012 18:39 UTC (Sat) by khim (subscriber, #9252) [Link] Thanks you for the pointer. I take my words back. Yes, Tcl stubs is about what's needed for the stable ABI. So we have at least one scripting language whose authors are serious about compatibility. Now we need to convince developers of extensions to use this mechanism, but this is indeed a good start. Too bad the Tcl itself is not all that popular. And there is also the unfortunate fact that distributions often don't use Tcl stubs but link with one single version of Tcl directly - but yes, in this particular case authors of the language did their part.
ISVs providing Linux downloads Posted Sep 16, 2012 13:31 UTC (Sun) by anselm (subscriber, #2796) [Link] Tcl/Tk – once you get used to it – is much better than its reputation would suggest (Sun would have been able to make a difference when John Ousterhout was at Sunlabs but by that time they had another language to hype). As it is, Tcl/Tk remains one of the better-kept secrets of the industry; lots of people use it as a work horse but it isn't as »hip« as some of the other languages in the same space – even though it is very well engineered and documented and has been quite innovative in lots of areas. For example, Tcl offered full Unicode support with the release of Tcl 8.1 in 1997, way before any of the other popular languages followed suit, and of course Tk revolutionised X11 GUIs in the early 1990s when everyone else's idea of GUI programming involved C and OSF/Motif. Tcl/Tk can do things like cross-platform single-file deployment that are very helpful and simply not available with most other similar languages. Too bad it doesn't get the attention it deserves.
|
|||||||||||||