Show ME the way to uninstall glibc from Linux, and I'll show you the way to remove major components of Windows. Let's see which operating system can do something after a significant portion of it has been crippled?
(btw, to uninstall media player, you go to Add/Remove Software, check "Windows Media Player", and click Remove)
...and that's because all the others that have been put into the marketplace have failed. It's obviously not impossible to succeed, Apple's still around aren't they?
IBM's PC OS division, Be, and a lot of other people have tried and failed. It's not because it's impossible for them to succeed.
It's for the same reason we almost all use X86 based systems, today. People wanted to use software that was written to run on an X86. Then they wanted to be able to take their home software to work, or their work software to home. Suddenly, the IBM PC became the defacto standard hardware system.
That Windows has become the defacto software operating system is for the same reason.
Yes, there are hardware alternatives to X86.
Motorola/IBM are still out there with PowerPC, right? But did AMD want a market share in that range, or did AMD want to take a bite out of Intel? And how did they do that?
Let's go back to the late 70's. You want an operating system? Great, every model has it's own custom OS. You want a different piece of hardware? different operating system. You want to drive a floppy drive that didn't come with the box? Write your floppy driver for your operating system. Oh, you want to print? Hi Richard! Let's write a printer driver!
Have you got a better idea than one system? If you do, I bet it runs Windows software.
Now, that sounds like a serious issue with the "Classic Media Player"'s installation. most applications to install, you just open the archive (which can usually be done by double clicking) then double click the single exe or msi, and it extracts it, and runs the setup.
Any software that does not have effectively single-click installation (minus any choices that must be made during installation) should be shot.
We moved away from this years ago, as the last of the pay-per-hour online services faded into nothingness.
You'd be here complaining about how you got raped when you fell asleep or had some general emergency take you away from your computer for several hours while you were logged in.
Last I looked at the LSB, it was just a standard that defined where files belonged. If that's still the case, then it wouldn't even be necessary with a centralized installation system.
And, a proper versioning system for dealing with libraries, would tell if your libraries are compatible.
I've been seriously thinking about doing some work in this vein, building an absolute bare base system, and then building up the utilities to create a system that would make more sense. But, I don't really have the resources.
That's why the library usage needs to be improved, as well.
--AND-- why any package that does include libraries, the installer should know where and what they are, so if any future package needs them, it can share them instead of having two identical copies of the same one in different places.
And the definition file that tells you what all is in the package, should also tell you if anything is needed for the package, allowing the installer the ability to sanely find it, if the author didn't see fit to throw one in. (in fact, the install data could even tell the installer how to find it on the internet)
Having everything have static linkage is not good. A more intelligent dynamic linking system is good.
There should be absolutely one installation method, that should encompass ALL distributions. How each distribution actually DOES it can vary as it wants.
Each application should be packaged, with a file that has a lot of information about whatever is in the archive.
What each file is, wether it's source code, a library, an extension for something else, the main executeable, or some stupid utility to go with it.
Then it's up to the installer, based on WHAT the file IS, to determine where it goes.
Then you can have distributions that use the traditional *throw every executeable in the entire world into/usr/bin, every doc into/usr/doc, every lib into/usr/lib*, or a distribution that keeps every single application's components in it's own seperate directories. All using the same install format.
Of course, each would also have version information, and also "compatible with" and "incompatible with" information, particularly for libraries, where/usr/lib/xlib1.0.so and/usr/lib/xlib1.1.so are actually totally compatible with each other, so you can erase/usr/lib/xlib1.0.so when installing 1.1.so.. but,/usr/lib/xlib2.0.so has a totally different interface, so if you have programs that depend on/usr/lib/xlib1.1.so and you install/usr/lib/xlib2.0.so, the installer will know to keep the 1.1 version around as well. (this would also eliminate the idiocy of having things like "glib-5" and "glib2-2", when glib2 replaces glib.. don't take any of these examples as examples of absolute truth, i'm just using the names as examples, rather than as case studies)
And I really love the idea of "nothing should ever be executed without the installer having previously known about it".. that would be a great thing to add to a distribution, IMO. Hell, the installer could keep track of checksums of the executeables, and make sure they haven't been modified (such as by a virus or worm or rootkit or malicious hacker) before running.
A unified installation METHOD (doesn't have to be the same program on all distros) would solve a huge amount of Linux distribution problems, and perhaps even provide an answer to more general computing problems.
The problem is, is that all of these individual, but "superior" packaging systems, all appear vastly insuperior in practice.
To quote a post I made to the main article, and also paraphrase one I made several incarnations of this same discussion back...
There should be absolutely one installation method, that should encompass ALL distributions.How each distribution actually DOES it can vary as it wants. Each application should be packaged, with a file that has a lot of information about whatever is in the archive. What each file is, wether it's source code, a library, an extension for something else, the main executeable, or some stupid utility to go with it. Then it's up to the installer, based on WHAT the file IS, to determine where it goes. Then you can have distributions that use the traditional *throw every executeable in the entire world into/usr/bin, every doc into/usr/doc, every lib into/usr/lib*, or a distribution that keeps every single application's components in it's own seperate directories. All using the same install format. Of course, each would also have version information, and also "compatible with" and "incompatible with" information, particularly for libraries, where/usr/lib/xlib1.0.so and/usr/lib/xlib1.1.so are actually totally compatible with each other, so you can erase/usr/lib/xlib1.0.so when installing 1.1.so.. but,/usr/lib/xlib2.0.so has a totally different interface, so if you have programs that depend on/usr/lib/xlib1.1.so and you install/usr/lib/xlib2.0.so, the installer will know to keep the 1.1 version around as well. (this would also eliminate the idiocy of having things like "glib-5" and "glib2-2", when glib2 replaces glib.. don't take any of these examples as examples of absolute truth, i'm just using the names as examples, rather than as case studies)
And I really love the idea of "nothing should ever be executed without the installer having previously known about it".. that would be a great thing to add to a distribution, IMO. Hell, the installer could keep track of checksums of the executeables, and make sure they haven't been modified (such as by a virus or worm or rootkit or malicious hacker) before running.
A unified installation METHOD (doesn't have to be the same program on all distros) would solve a huge amount of Linux distribution problems, and perhaps even provide an answer to more general computing problems.
So, why isn't it apparently USED by anything? Having multiple versions of/usr/lib/libwhatever.so.4 and/usr/lib/libwhatever.so.5 will drastically break the system.
Windows definitely automatically scales things upwards as your DPI gets higher.
I was unable to use Linux on my last new monitor at sizes over 1280x1024, until I figured out that there were at least -3- different configuration files where DPI settings were forced (not including the settings in GNOME) by the default Debian installation.
Once I figured that out, and removed all of those forced DPI settings, then it became quite usable all the way up to the max resolution of the monitor.
Windows just plain worked, no matter what resolution I picked.
It already stores tons of different versions of the same libraries, dig through/usr/lib and/lib sometime, and see how many outdated versions of libraries you have (at least, if you've been updating your system regularly).
My question is, why isn't there any sort of versioning system? after all, that was implemented in systems back in the 70's.
Virtually EVERYTHING uses the same installer in windows, even a bunch of Linux ports. (although my experience with Linux ports in Windows is RUN THE HELL AWAY.. except for GAIM. But using GAIM in Windows makes me realise just how much i hate GAIM's interface)
er.. when I installed ME upgrade over 98, I was given the option of retaining the previous system, so that I could go backwards. I think the same when I installed 98 over 95. I know I've got the option between XP, XP SP1, and XP SP 2.. but I haven't done a previous to XP upgrade.
You missed the ENTIRE point of his article. The "absurd requirements for Linux that the latest MS Windows can't accomplish" is the ENTIRE point. The requirements for Linux, to take a position as a better system, must be FAR higher than the requirements for Windows. It's not about playing catch up, it's about doing it better.
And about the only thing Linux does better right now, is in multiuser capability.
So, I take it that you've ignored the last 15 years of freeware Windows programs?
Just because it doesn't come packaged iwth the source doesn't mean it's not free.
Since the average windows user doesn't have the tools to work with source, why bother including it in the package, even if you are producing an open source app?
And there's a ton of open source apps being developed FOR windows and ON windows, that will probably never ever make it to Linux.
Whoever would've thought that the command to install something is called "yum"?
And, of course, that requires that your distribution already has a package by the name "application_name". You can't just go out and find a Linux Application, either on the intarwebs, or in a store, and go "yum applicationname", and expect it to install.
see, here's the deal. When you compile that program, it can tell the install functions "hey, the user here just compiled me, put my files where they go pls".. I just made a largish post elsewhere about this. It's not a bad idea to have a central installation method, no matter what you are.
There should be absolutely one installation method, that should encompass ALL distributions. How each distribution actually DOES it can vary as it wants.
Each application should be packaged, with a file that has a lot of information about whatever is in the archive.
What each file is, wether it's source code, a library, an extension for something else, the main executeable, or some stupid utility to go with it.
Then it's up to the installer, based on WHAT the file IS, to determine where it goes.
Then you can have distributions that use the traditional *throw every executeable in the entire world into/usr/bin, every doc into/usr/doc, every lib into/usr/lib*, or a distribution that keeps every single application's components in it's own seperate directories. All using the same install format.
Of course, each would also have version information, and also "compatible with" and "incompatible with" information, particularly for libraries, where/usr/lib/xlib1.0.so and/usr/lib/xlib1.1.so are actually totally compatible with each other, so you can erase/usr/lib/xlib1.0.so when installing 1.1.so.. but,/usr/lib/xlib2.0.so has a totally different interface, so if you have programs that depend on/usr/lib/xlib1.1.so and you install/usr/lib/xlib2.0.so, the installer will know to keep the 1.1 version around as well. (this would also eliminate the idiocy of having things like "glib-5" and "glib2-2", when glib2 replaces glib.. don't take any of these examples as examples of absolute truth, i'm just using the names as examples, rather than as case studies)
And I really love the idea of "nothing should ever be executed without the installer having previously known about it".. that would be a great thing to add to a distribution, IMO. Hell, the installer could keep track of checksums of the executeables, and make sure they haven't been modified (such as by a virus or worm or rootkit or malicious hacker) before running.
A unified installation METHOD (doesn't have to be the same program on all distros) would solve a huge amount of Linux distribution problems, and perhaps even provide an answer to more general computing problems.
Slashdot Mirror
Show ME the way to uninstall glibc from Linux, and I'll show you the way to remove major components of Windows. Let's see which operating system can do something after a significant portion of it has been crippled?
(btw, to uninstall media player, you go to Add/Remove Software, check "Windows Media Player", and click Remove)
...and that's because all the others that have been put into the marketplace have failed. It's obviously not impossible to succeed, Apple's still around aren't they?
IBM's PC OS division, Be, and a lot of other people have tried and failed. It's not because it's impossible for them to succeed.
It's for the same reason we almost all use X86 based systems, today. People wanted to use software that was written to run on an X86. Then they wanted to be able to take their home software to work, or their work software to home. Suddenly, the IBM PC became the defacto standard hardware system.
That Windows has become the defacto software operating system is for the same reason.
Yes, there are hardware alternatives to X86.
Motorola/IBM are still out there with PowerPC, right? But did AMD want a market share in that range, or did AMD want to take a bite out of Intel? And how did they do that?
Let's go back to the late 70's. You want an operating system? Great, every model has it's own custom OS. You want a different piece of hardware? different operating system. You want to drive a floppy drive that didn't come with the box? Write your floppy driver for your operating system. Oh, you want to print? Hi Richard! Let's write a printer driver!
Have you got a better idea than one system? If you do, I bet it runs Windows software.
Now, that sounds like a serious issue with the "Classic Media Player"'s installation. most applications to install, you just open the archive (which can usually be done by double clicking) then double click the single exe or msi, and it extracts it, and runs the setup.
Any software that does not have effectively single-click installation (minus any choices that must be made during installation) should be shot.
Yeah, I don't know what the sense in this is. So, now, Microsoft could simply choose to SELL messenger and media player to the people in these places.
It's on the same vein as forcing them to unbundle notepad from the system, or to unbundle Excel from Word when you buy Office. It's really stupid.
Force them to provide links to competitors? That's like saying Pepsi must provide coupons for Coke on their packages! wtf?
hell, VIA, Realtek, etc are still maintaining their OS/2 drivers last I went driver shopping.
nope, it's because those who design open source programs are usually skilled programmers rather than skilled designers.
We moved away from this years ago, as the last of the pay-per-hour online services faded into nothingness.
You'd be here complaining about how you got raped when you fell asleep or had some general emergency take you away from your computer for several hours while you were logged in.
As if people use Linux on supercomputers?
I had a guy arguing with me a couple days ago that Cray 1s ran Linux. flol.
Gmail is missing important features that have been part of email programs for decades. 'aemail' (anyone remember THAT?) defeats gmail.
Gmail should've been a regular email design, rather than following Opera's M2 design, with a Google search shoved into it.
Not that there's anything wrong with Opera's M2, but M2 has more useful functions than Gmail, and a lot of M2 is still so far back it's ancient.
Wow, other places say that Opera has a 6% marketshare.. so.. that's a pretty significant difference.
I'd bet that 11%+ is way exaggerated.
Last I looked at the LSB, it was just a standard that defined where files belonged. If that's still the case, then it wouldn't even be necessary with a centralized installation system.
And, a proper versioning system for dealing with libraries, would tell if your libraries are compatible.
I've been seriously thinking about doing some work in this vein, building an absolute bare base system, and then building up the utilities to create a system that would make more sense. But, I don't really have the resources.
That's why the library usage needs to be improved, as well.
--AND-- why any package that does include libraries, the installer should know where and what they are, so if any future package needs them, it can share them instead of having two identical copies of the same one in different places.
And the definition file that tells you what all is in the package, should also tell you if anything is needed for the package, allowing the installer the ability to sanely find it, if the author didn't see fit to throw one in. (in fact, the install data could even tell the installer how to find it on the internet)
Having everything have static linkage is not good. A more intelligent dynamic linking system is good.
There should be absolutely one installation method, that should encompass ALL distributions.
/usr/bin, every doc into /usr/doc, every lib into /usr/lib*, or a distribution that keeps every single application's components in it's own seperate directories. All using the same install format.
/usr/lib/xlib1.0.so and /usr/lib/xlib1.1.so are actually totally compatible with each other, so you can erase /usr/lib/xlib1.0.so when installing 1.1.so .. but, /usr/lib/xlib2.0.so has a totally different interface, so if you have programs that depend on /usr/lib/xlib1.1.so and you install /usr/lib/xlib2.0.so, the installer will know to keep the 1.1 version around as well. (this would also eliminate the idiocy of having things like "glib-5" and "glib2-2", when glib2 replaces glib .. don't take any of these examples as examples of absolute truth, i'm just using the names as examples, rather than as case studies)
How each distribution actually DOES it can vary as it wants.
Each application should be packaged, with a file that has a lot of information about whatever is in the archive.
What each file is, wether it's source code, a library, an extension for something else, the main executeable, or some stupid utility to go with it.
Then it's up to the installer, based on WHAT the file IS, to determine where it goes.
Then you can have distributions that use the traditional *throw every executeable in the entire world into
Of course, each would also have version information, and also "compatible with" and "incompatible with" information, particularly for libraries, where
And I really love the idea of "nothing should ever be executed without the installer having previously known about it".. that would be a great thing to add to a distribution, IMO. Hell, the installer could keep track of checksums of the executeables, and make sure they haven't been modified (such as by a virus or worm or rootkit or malicious hacker) before running.
A unified installation METHOD (doesn't have to be the same program on all distros) would solve a huge amount of Linux distribution problems, and perhaps even provide an answer to more general computing problems.
The problem is, is that all of these individual, but "superior" packaging systems, all appear vastly insuperior in practice.
/usr/bin, every doc into /usr/doc, every lib into /usr/lib*, or a distribution that keeps every single application's components in it's own seperate directories. All using the same install format. /usr/lib/xlib1.0.so and /usr/lib/xlib1.1.so are actually totally compatible with each other, so you can erase /usr/lib/xlib1.0.so when installing 1.1.so .. but, /usr/lib/xlib2.0.so has a totally different interface, so if you have programs that depend on /usr/lib/xlib1.1.so and you install /usr/lib/xlib2.0.so, the installer will know to keep the 1.1 version around as well. (this would also eliminate the idiocy of having things like "glib-5" and "glib2-2", when glib2 replaces glib .. don't take any of these examples as examples of absolute truth, i'm just using the names as examples, rather than as case studies)
To quote a post I made to the main article, and also paraphrase one I made several incarnations of this same discussion back...
There should be absolutely one installation method, that should encompass ALL distributions.How each distribution actually DOES it can vary as it wants.
Each application should be packaged, with a file that has a lot of information about whatever is in the archive.
What each file is, wether it's source code, a library, an extension for something else, the main executeable, or some stupid utility to go with it.
Then it's up to the installer, based on WHAT the file IS, to determine where it goes.
Then you can have distributions that use the traditional *throw every executeable in the entire world into
Of course, each would also have version information, and also "compatible with" and "incompatible with" information, particularly for libraries, where
And I really love the idea of "nothing should ever be executed without the installer having previously known about it".. that would be a great thing to add to a distribution, IMO. Hell, the installer could keep track of checksums of the executeables, and make sure they haven't been modified (such as by a virus or worm or rootkit or malicious hacker) before running.
A unified installation METHOD (doesn't have to be the same program on all distros) would solve a huge amount of Linux distribution problems, and perhaps even provide an answer to more general computing problems.
So, why isn't it apparently USED by anything? Having multiple versions of /usr/lib/libwhatever.so.4 and /usr/lib/libwhatever.so.5 will drastically break the system.
Umm.. yeah, ok.
Windows definitely automatically scales things upwards as your DPI gets higher.
I was unable to use Linux on my last new monitor at sizes over 1280x1024, until I figured out that there were at least -3- different configuration files where DPI settings were forced (not including the settings in GNOME) by the default Debian installation.
Once I figured that out, and removed all of those forced DPI settings, then it became quite usable all the way up to the max resolution of the monitor.
Windows just plain worked, no matter what resolution I picked.
set the monitor size correctly? wtf?
Why does it matter what size the monitor is?
And if it does, why can't it automagically determine it?
It already stores tons of different versions of the same libraries, dig through /usr/lib and /lib sometime, and see how many outdated versions of libraries you have (at least, if you've been updating your system regularly).
My question is, why isn't there any sort of versioning system? after all, that was implemented in systems back in the 70's.
Have you used Windows in the last... 5 years?
.. except for GAIM. But using GAIM in Windows makes me realise just how much i hate GAIM's interface)
Virtually EVERYTHING uses the same installer in windows, even a bunch of Linux ports. (although my experience with Linux ports in Windows is RUN THE HELL AWAY
Totally incorrect. I can't install a .deb on my FreeSCO box. I just plain can't do it. (FreeSCO is a particular Linux distribution)
Even if I did manage to get dpkg to operate, I would be missing hundreds of required things, or they would be vastly different versions.
This hardly ever happens in Windows.
er.. when I installed ME upgrade over 98, I was given the option of retaining the previous system, so that I could go backwards. I think the same when I installed 98 over 95. I know I've got the option between XP, XP SP1, and XP SP 2.. but I haven't done a previous to XP upgrade.
You missed the ENTIRE point of his article. The "absurd requirements for Linux that the latest MS Windows can't accomplish" is the ENTIRE point. The requirements for Linux, to take a position as a better system, must be FAR higher than the requirements for Windows. It's not about playing catch up, it's about doing it better.
And about the only thing Linux does better right now, is in multiuser capability.
So, I take it that you've ignored the last 15 years of freeware Windows programs?
Just because it doesn't come packaged iwth the source doesn't mean it's not free.
Since the average windows user doesn't have the tools to work with source, why bother including it in the package, even if you are producing an open source app?
And there's a ton of open source apps being developed FOR windows and ON windows, that will probably never ever make it to Linux.
Whoever would've thought that the command to install something is called "yum"?
And, of course, that requires that your distribution already has a package by the name "application_name". You can't just go out and find a Linux Application, either on the intarwebs, or in a store, and go "yum applicationname", and expect it to install.
see, here's the deal. When you compile that program, it can tell the install functions "hey, the user here just compiled me, put my files where they go pls".. I just made a largish post elsewhere about this. It's not a bad idea to have a central installation method, no matter what you are.
There should be absolutely one installation method, that should encompass ALL distributions.
/usr/bin, every doc into /usr/doc, every lib into /usr/lib*, or a distribution that keeps every single application's components in it's own seperate directories. All using the same install format.
/usr/lib/xlib1.0.so and /usr/lib/xlib1.1.so are actually totally compatible with each other, so you can erase /usr/lib/xlib1.0.so when installing 1.1.so .. but, /usr/lib/xlib2.0.so has a totally different interface, so if you have programs that depend on /usr/lib/xlib1.1.so and you install /usr/lib/xlib2.0.so, the installer will know to keep the 1.1 version around as well. (this would also eliminate the idiocy of having things like "glib-5" and "glib2-2", when glib2 replaces glib .. don't take any of these examples as examples of absolute truth, i'm just using the names as examples, rather than as case studies)
How each distribution actually DOES it can vary as it wants.
Each application should be packaged, with a file that has a lot of information about whatever is in the archive.
What each file is, wether it's source code, a library, an extension for something else, the main executeable, or some stupid utility to go with it.
Then it's up to the installer, based on WHAT the file IS, to determine where it goes.
Then you can have distributions that use the traditional *throw every executeable in the entire world into
Of course, each would also have version information, and also "compatible with" and "incompatible with" information, particularly for libraries, where
And I really love the idea of "nothing should ever be executed without the installer having previously known about it".. that would be a great thing to add to a distribution, IMO. Hell, the installer could keep track of checksums of the executeables, and make sure they haven't been modified (such as by a virus or worm or rootkit or malicious hacker) before running.
A unified installation METHOD (doesn't have to be the same program on all distros) would solve a huge amount of Linux distribution problems, and perhaps even provide an answer to more general computing problems.