| |||||||||||||
Small problem for Linux ? Sure. Big problem for Linux user? Of course.Small problem for Linux ? Sure. Big problem for Linux user? Of course.Posted Jul 9, 2009 10:27 UTC (Thu) by nye (guest, #51576)In reply to: Small problem for Linux ? Sure. Big problem for Linux user? Of course. by khim Parent article: Google Chrome OS and the community
Well, I was pleasantly surprised the other week when I tried running an old copy of Mosaic. The Linux binary from something like 1995 ran without my having to do anything more than extract and execute. Of course, this is because it wasn't built to rely on shared libraries.
(Sadly it turns out that NCSA's own website was the only one I could find which still uses HTTP/1.0, so it was all for naught.)
(Log in to post comments)
You were surprised? Why? Posted Jul 9, 2009 16:24 UTC (Thu) by khim (subscriber, #9252) [Link] Well, I was pleasantly surprised the other week when I tried running an old copy of Mosaic. I run old DOS/Windows programs quite often - and I expect that they'll work on new version of Windows (the fact that Windows Vista x64 dropped support for DOS/Win16 was unpleasant surprise but AFICS it's problem with AMD64 mode, not the result of Microsoft's negligence). For you the fact that old copy of Mosaic can run is pleasant surprise. Nuff said. The really strange this here is that GNU/Linux core is 99% bullet-proof: linux kernel and glibc go the huge pains to guarantee backward compatibility. But the further you go up in the software stack the flakier ABI stability becomes - by the time you've reached layers where you can do something usefull it's gone almost completely...
You were surprised? Why? Posted Jul 9, 2009 16:30 UTC (Thu) by martinfick (subscriber, #4455) [Link]
There are plenty of old dos programs that do not run on windows. Anything that polled a mouse will chew up CPU. Anything that did out of the ordinary graphics will not work, games...
Yeah, but then Linux's task is simpler from the start... Posted Jul 9, 2009 19:07 UTC (Thu) by khim (subscriber, #9252) [Link] There are plenty of old dos programs that do not run on windows. Anything that polled a mouse will chew up CPU. Anything that did out of the ordinary graphics will not work, games... Sure. DOS programs were written as if they own the computer. Which they did. So it's not easy to containerize them without huge overhead. The comparable thing in Linux world are OSS programs - they also like to hog the part of computer (/dev/dsp device). And like MS DOS games these old programs worked poorly with new distributions. And like with Windows the idea that you can just rewrite all programs (Windows old took of with version 3.0 which was the first version with decent support for MS DOS programs) didn't fly. Why the hell linux developers must repeat all Microsoft's mistakes?
Yeah, but then Linux's task is simpler from the start... Posted Jul 11, 2009 9:55 UTC (Sat) by nix (subscriber, #2304) [Link]
Because they're not "Microsoft"'s mistakes, per se: they're mistakes made
by software developers in general. MS just tripped over them, and now so are we.
Actually, this one isn't even a mistake: it's an inevitable consequence of
You were surprised? Why? Posted Jul 11, 2009 9:46 UTC (Sat) by nix (subscriber, #2304) [Link] But the further you go up in the software stack the flakier ABI stability becomes - by the time you've reached layers where you can do something usefull it's gone almost completely...Is it? I see only one or two small ABI breakages a year (much less if you ignore libdb, OpenSSL, ffmpeg, libperl and libpython, which all break ABI at the drop of a hat), and the only specific complaints I've seen on this thread have been people trying to run things that expect new ABIs of old libraries, which isn't going to work until we all have our time machines. The major high-in-the-stack desktop libraries and the things they use go to great lengths to maintain back-compatibility, and it seems to work. What they do instead is introduce new libraries with better APIs every so often (e.g. gvfs replacing gnome-vfs), and, sure, if you don't have those and you install something that needs them, you'll have to install them. But, again, this has nothing to do with ABI breakages, which pretty much aren't happening.
Binary compatibility Posted Jul 10, 2009 18:31 UTC (Fri) by anton (guest, #25547) [Link] Yes, my binary of Mosaic 2.7b5 still works on my Debian Lenny AMD64 system, and it also understands current HTTP (but often likes to download instead of display HTML pages due to charset issues (IIRC)). The binary is from 1998 and is statically linked.A Mosaic binary from 1994 just segfaults, as well as all the other ZMAGIC binaries (1994-1995) I have lying around. The QMAGIC binaries (1995-1997) all report "can't load dynamic linker '/lib/ld.so nor /usr/i486-linux/lib/ld.so'" and could probably be made to work by copying the appropriate file to the right place (plus any libraries needed). Then we get into the ELF era (since 1998), and the binaries (e.g., ssh 1.2.25) work if (compatible versions of) the libraries they use are present; for that ssh binary the libraries are libnsl.so.1 libcrypt.so.1 libutil.so.1 libc.so.6 /lib/ld-linux.so.2, which came with the libc6-i386 package on Lenny. Not bad. I usually preserve old distributions I used to use, so I can easily copy the old libraries to my new distribution if I need them (or maybe just include the old library directories in ld.so.conf). I have not needed to do that for quite some time, though.
Binary compatibility Posted Jul 11, 2009 10:04 UTC (Sat) by nix (subscriber, #2304) [Link]
I think you have to turn off address space randomization to get old ZMAGIC
binaries to work (but I'd not be surprised if they'd rotted completely: does anyone other than Alan Cox run them anymore? :) )
Binary compatibility Posted Jul 13, 2009 13:26 UTC (Mon) by anton (guest, #25547) [Link] Address-space randomization was turned off in my experiments, so that alone is not enough. Apart from such experiments I don't run them anymore.
|
|||||||||||||