[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