[PLUG-TALK] What Windows Is _Really_ Like

Michael M. nixlists at writemoore.net
Tue Jun 27 13:27:20 UTC 2006


plug_0 at robinson-west.com wrote:
> Just because Linux is open source, that doesn't mean you can't release binary
> only form software that works with it.  Why should Opera, which was given
> as an example, be statically linked?  If you know a binary release program
> will break the system if the libraries are upgraded, or you can detect this
> before upgrading, it only seems logical to use a package management 
> system that addresses this issue.  Yes, writers of binary only programs for 
> Linux should do compatibility testing.  If they want to maintain a good 
> reputation with their user community, they can consider releasing patches 
> for those who will upgrade their libraries, kernel, etc.  What's wrong 
> with the kernel devs developing standardized hooks for proprietary libraries 
> and code?  As long as this code doesn't go inside the kernel itself, why 
> should the purists be concerned?  There is no excuse for any Linux
> application coder failing to maintain updated Linux systems matching 
> what they are targeting.  If you are targeting the latest Debian, you
> should continue to verify that your software application(s) still work 
> on the most patched version of it, at least for as long as you are 
> producing it.
>   

I don't know why Opera should be statically linked, or whether it should 
be or shouldn't be.  So are you saying that the problem is that Opera is 
not written properly?  Who is the "you" who is supposed to suspect or 
detect the potential breakage:  the developer, the distro maintainers, 
the end-user?  That's what I don't get.  If it's the developer, the 
developer can't control the rest of the system.  How does the developer 
know when system libraries might come along that will break his app, or 
what system changes the distro will make that will cause his app to 
break the system?  If it's the distro maintainers, how are they to know 
what binary blobs some users have installed?  Most distros are clear 
about what software they support vs. what software they don't, and where 
it comes from.  Use software that doesn't come from these sources, they 
say, and you're on your own.  If it's the end-user, you're asking an 
awful lot.  That's another hurdle to overcome for more widespread Linux 
adoption.  A Windows or an OS X user goes to a website, finds an *.exe 
or *.dmg, installs it, and it works.  A Linux user gets his software 
from his distro's official repositories, and it works.  What happens 
when the latter tries to do what the former is used to?  My question is, 
can distros really handle this elegantly?  Package management systems 
depend upon recompiling the source code when necessary to accommodate 
system changes, to create packages that will work together as a whole.  
Google says of Picasa, "Newer distributions may include changes that 
break Picasa."  They don't say, "Installing Picasa might prevent you 
from upgrading your system to newer versions of software Picasa depends 
upon."  But isn't that a distinct possibility, if not with Picasa 
specifically, then with other closed-source apps?  You can say the 
developers should maintain current versions that will work with the 
latest updates, but how do you coordinate that?  What happens, for 
example, when Xorg 7.0 enters Debian Etch, and all the paths get moved 
around?  If all goes well, all the software that comes from the official 
repositories gets updated on the user's system to reflect these changes, 
all at once, with a seamless "aptitude dist-upgrade."  But the binary 
blob doesn't get updated, because it's not in the repositories.  It was 
downloaded from a website.  Well, maybe the patched version is now 
available on that website, but that doesn't do the end user much good 
when his system is broken because he didn't first remove the binary blob 
before he tried to upgrade his system.

> If you are writing proprietary software to run on OSS systems, you don't
> have to pay a company like Microsoft developer licensing fees.  There's
> nothing stopping you from spearheading your own Linux distribution 
> customized to support your proprietary software.  When it comes to 
> writing games, why not?
>
>   

So now we've gone from "Hey, people, release for Linux," to "Hey, 
people, release your own Linux distros"?  Every time I want to play a 
different game, I have to install a different operating system?  Yikes!

-- 
Michael M. ++ Portland, OR ++ USA
"No live organism can continue for long to exist sanely under conditions of absolute reality; even larks and katydids are supposed, by some, to dream." --S. Jackson




More information about the PLUG-talk mailing list