I'd be more willing to believe that people would play nice with the Apache team than that they would with MS.
Re:Is RPM Doomed?: Morons Please.....
on
Is RPM Doomed?
·
· Score: 2
Particularly since the article basically claims that RPM is so popular that it's doomed.
Okay, there's a lot of fragmentation of the Windows API (CE, Win16, Win32 on NT, Win32 on 9x, the IE/Office extensions to each...), but I'm still waiting for Linux's World Domination, you know?
HP axed calculator development a while ago
on
Is RPM Doomed?
·
· Score: 2
They plan to keep selling existing models, but I think that RPN on the consumer calculator is going to go the way of the dinosaur.
Frankly, this move (and the others done to scrape together money, then merging with Compaq...WTF?) does a great job of showing that execs shouldn't recieve bonuses for closing mergers.
If you're using any major Linux distribution, you're using a lot of software with development funded by RH.
All the major Linux vendors that I can think of fund general Linux development. Red Hat puts more money in than any other Linux distributor (at least partly due to virtue of sheer size, yes...).
This is why I get a kick out of people bashing distributors at the same time they're using software funded by them. "SuSE sucks, and they should die? Gee, I hope you don't like using X." "Red Hat sucks and should be wiped out by Debian? Gee, I hope you don't like using GNOME or gcc."
Re:Automaticness
on
Is RPM Doomed?
·
· Score: 4, Insightful
But software should install in linux the same way that it installs in windows. There should be one file, like setup.exe
No. I'm going to have to strongly disagree here.
Your complaint is valid and reasonable, and unfortunately ignored by the Linux community, but your solution is not.
Your complaint is that you want a simple *user interface* to install large pieces of software. This is reasonable. There is not front end that I know of that's widely used that chooses a reasonable subset of packages in a large software package (like GNOME) to install. You have to select all the packages in the system, one by one. That's fair, and should be addressed.
Your solution, however, is not a good idea. The Windows method of having a single installer puts you at the mercy of sitting down at the machine and actually clicking and installing stuff. It puts you at the mercy of what features are supported in the installer, how old the installer is, etc. The Linux (well, RPM/deb) approach is to separate the program from the packages. Upgrade the program, you get more features/bugfixes. You can install every piece of software remotely (ever watch Windows administrators run around installing a new piece of software on a network? What could be done securely on Linux with a bit of setup with sshd and public keys and then a single command to install software on every machine involves the IT people running around to each machine and clicking "OK" and watching progress bars). If you bundled all these packages into one large package, and someone doesn't *need* all of them, they need to download extra data. If you need to install, say, GNOME on every machine on the network, you only have to transfer the few RPMs *your* users actually require.
The solution is a fix to the front end, not to the architecture of the system. We need a single checkbox that installs a good default subset of packages for a large software package. The "GNOME" checkbox would install gnome-core, gnome-libs, etc, but probably not glade. The Linux rpm installation architecture is superior to the Windows installshield architecture -- now let's make the user experience as nice for novices.
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
Okay, my apologies. I haven't poked around too much with KDE.
GNOME's GConf does act as a Windows-like registry.
Re:Where are the programs?
on
Is RPM Doomed?
·
· Score: 2
The first time I installed an RPM which was not included on the CDs, I was wondering badly what happened
Just do this:
rpm -Uvh foo.i386.rpm
Now the RPM is installed...now we want to see the program name.
rpm -ql foo|grep bin
Voila!
Finally, dependencies are not the fault of the RPM system. If you took the raw binaries and plopped them on your system, you'd have the same dependencies...you just wouldn't be warned about them, and programs would malfunction, not launch because the linker would give a warning, etc.
RPM warns you of dependencies to *help* you, not to hurt you.
You can always install with --nodeps, but usually, unless you know what you're doing, you're better off trusting RPM.
A simple packaging system based on tarballs, a la Slackware
Try administering a network.
My experience with Slackware is seeing people managing to *just* get their system working and then leaving chunks of the software along and letting it get ancient because they don't want to break anything. They upgrade a library, they end up with zillions of broken library dependencies and programs that won't run.
You do realize that you can extract the source from srpm files easily and build however you so desire?
There are lots of tools that can do it. If you happen to have rpm on your system, rpm -Uvh on the src.rpm will dump the tarball off in/usr/src/redhat/SOURCES on a RH box, for example.
Re:Gentoo is a giant step, too long for mere morta
on
Is RPM Doomed?
·
· Score: 2
You do realize that you can do a minimal installation of RH and install as you see fit? Just like Debian? The main difference is that you actually have industrywide support for your distro.
Re:Luke, use the source...
on
Is RPM Doomed?
·
· Score: 5, Informative
Really, there is nothing too difficult about: ./configure make su make install
Yeah. But there's the ever so much more superior checkinstall: ./configure make su checkinstall
This creates and installs an RPM of all the stuff you were installing. Voila...you can uninstall, you can query rpm to find out what package a file is part of, find out if uninstalling something will break dependencies, etc, etc...all the stuff that you can't do with just make install.
Re:single point of failure
on
Is RPM Doomed?
·
· Score: 4, Informative
The syntax of UNIX config files is pretty standard (barring the occasional ugly misfit like sendmail -- use postfix instead).
And all the Windows registry does is give a standard format for storing individual values (how should I store a string, how should I store a DWORD) and provide a hierarchy. It says nothing about format or structure within a single app.
If you want to turn on, say, mail relaying in postfix on Linux, then you look for the entry called mail_relay (or whatever) that's commented out and contains a helpful set of comments right above the config entry. On Windows, the equivalent is to go into the registry to some unspecified key, create an unspecified value there and then set it to some unspecified value.
Of course, most people just use a front end on Windows -- like a preferences or options dialog -- because the registry is next to useless to actually interact with. You can do the same thing on Linux, which is done by GNOME and friends to make things more convenient for computer novices.
Also, if the Windows registry gets corrupted, you have a big problem. If a single text format config file gets corrupted, you can probably fix it yourself. If you can't...well, it's a single file down the drain. Reconfigure that single app. Your entire system doesn't become unbootable, a la Windows.
Re:Gentoo's Portage system r00lz
on
Is RPM Doomed?
·
· Score: 2
And there are plenty of front ends to rpm that can also get dependencies. If rpm is too low-level for you, that's why it was designed to be *really easy* to write front ends for, what with rpmlib and --queryformat.
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 5, Interesting
I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.
That's already done in the LSB.
The problem is that each rpm is required to contain a static list of files it installs *with pathnames*. The nice thing about this is that it lets you run rpm -qip foo.i386.rpm without executing any code (sandboxed or otherwise) to see the list of files. The stupid thing is that there then has to be a totally different rpm for every distro and every maintainer.
In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm. This is probably the most annoying design decision of RPM I've seen. There needs to be a FILES file with a list of installed files with a gen-files script (that runs sandboxed to build FILES for not-yet-installed packages and is run at package installation time to generate FILES). Have the Makefiles read this for make install. This would make life easier for maintainers (one list of files to install), would make RPMs more reliable (no accidental adding of a file to the Makefile but not to the spec file), and would let an RPM work on any distro (if we ever get the gcc-2.7, gcc-2.96, gcc-3 stuff worked out).
even though the newer libraries could do the job of the older ones
This is true for minor version number increases, but for a major version number change, newer libraries cannot simply link to the program.
Also, the registry is a fucking stupid idea. (despite the fact that GNOME and KDE are mindlessly cloning it). The registry causes more problems than anything else I've seen on a Windows system. The MacOS did things right -- let all your centralized databases just be caches for data that can be rebuilt from files around your system. If something gets borked or corrupted...that's okay. Absolutely do *not* make your single copy of data a registry -- put the masters around the system, and let the centralized db be rebuilt if necessary.
Also, registries require "installations" and "uninstallations" instead of just copying files. You can just copy appropriate files from one system to another and run code on a Linux or MacOS box. On a Windows box, you're in for running installers to poke at the registry. And finally, I've seen tons of broken Windows installers that poke at registry entries and end up completely screwing up data that some other app uses. For example, a friend once had Sonique and WinAmp installed, but couldn't associate mp3s with either. I took a look at the registry -- Microsoft's two-entry file association scheme let the extension entry point to a nonexistent application entry, IIRC. As a result, the mp3 entry didn't show up in the Folder Options dialog in Explorer, and couldn't be reassigned, and WinAmp and Sonique kept giving errors when trying to grab associations.
The day any distro starts requiring a registry is the day I never touch that distro again. Right now, I can just uninstall GNOME if I want to do so.
Oh, and another thing. The Windows registry is a *massive* shared database. As a result, tons of stuff modifies it and causes internal fragmentation and loss of physical continuity between related keys. Then all apps use the registry heavily (God, I hate apps that poll it), so you get slow app launch times, that annoying disk churning that you hear on Windows boxes...rrrgh.
Take a look at.dll registration. On Windows, the only way the OS knows about a.systemwide dll is when you've added an entry to the registry for it. On Linux...run ldconfig, and it rebuilds the systemwide cache (ld.so.cache), which is significantly faster (contiguous, not incrementally modified, not modified by all sorts of other apps storing filename associations and the like) to read.
The registry is basically a hack, because Windows *used* to have what MS considered a worse scheme (.ini files). It isn't a very well thought out system.
I hate it! You need to compile a new RPM for each platform
What we needis a smart.tar.gz2 package which detects what OS your using, and compiles and installs automagically with an easy to use gui and a powerful cli interface
Well, hell.
------
#!/bin/sh # Demonstration that RPM ain't all that bad # Copyright 2002, 0x0d0a # This code placed under the GPL # Should compute proper buildroot, etc # Be damn sure not to set buildroot to/ # or something similar -- rm -rf would # then suck severely # Set our_rpm_buildroot appropriately # Usage: mybuildrpm.sh foo.tar.bz2 our_rpm_buildroot=/usr/src/redhat ni ce -20 rpm -tb "$@" && rpm -Uvh `find $our_rpm_buildroot -type f` && rm -f `find $our_rpm_buildroot -type f`
----- Okay, I grant that there's no gui, but you get all the many CLI options of RPM. Voila!
People love to bash RPM, but it's a pretty sweet system (except the move to the newer underlying dbfile...screw transactions, I can always rebuild the database if it gets corrupted and it takes *much* longer to install and query than things did back with rpm 3.0). If it's too simple for you, it's really easy to use it as a back end and slap something on top of it.
Note: this is a one minute hack and may not even run, much less be safe for your system...it's an example, not intended to be used. And hell, running random stuff from people on Slashdot as root just isn't a great idea.:-)
This is one of the most aggressive things you can tell an emacs user to do. It's akin to going up to someone and saying "blood...blood...blood" over and over to them.
B) Design your code before you write it. Use UML, flowcharts or whatever
I recently used UML for the first time, and I have to say that UML is abstract to the point of being useless. I want to be able to change a UML diagram and regenerate code stubs. UML isn't capable of specifying stuff that's fairly important to C++ coders, like, say, typedef. The workarounds for this are really awful -- someone has you create a class called "Typedef" and toss some junk in it...yeech.
UML is a nice idea, but it needs to be a smidgen more powerful. Oh, and all the editors need to support XMI. I can understand MS not doing it with Visio, but dia not doing it is just embarrasing to the Open Source community (which constantly claims that everyone should use standard file formats).
C)Write code away from a computer
I really don't like doing this. I don't even like doing this for English text. I remember in grade school how we were taught in English to write rough drafts on paper and then use the standard markup symbols...ick. Much, *much* easier to do revision as you go through a text editor or word processor.
A senior C developer shouldn't need to write push() and pop() for a linked list.
I agree (though C is the the language where you'd most likely have to do this yourself) -- however, a senior C developer should be able to write push() and pop() for a linked list.
They want to filter out idiots quickly. I'm sure that they have more advanced questions as well.
Also, to the person who said that they'd tell them point blank that this is a bad idea -- if the first thing you do (this is at a *job interview*) is tell them that you're not going to do what they want you to do...well, you aren't making the greatest impression in the world.
Slashdot Mirror
I agree, though it could be a bit clearer -- I think someone though that it was a troll. To clarify:
What the person wants to do is fine: the GPL is compatible with any data file license you'd like to use.
If the artist is Stallmanesque, he can say that the art can only be reused with GPLed software.
Maybe the patches are beta, but I rarely see a string of patches to patches.
This could allow arbitrary code to be run on the server as the user the Apache children are set to run as
Of course, thanks to suid and chroot, this doensn't give an attacker much.
The secret is Apache+UNIX, not just Apache.
Now, as for IIS...
I'd be more willing to believe that people would play nice with the Apache team than that they would with MS.
Particularly since the article basically claims that RPM is so popular that it's doomed.
Okay, there's a lot of fragmentation of the Windows API (CE, Win16, Win32 on NT, Win32 on 9x, the IE/Office extensions to each...), but I'm still waiting for Linux's World Domination, you know?
They plan to keep selling existing models, but I think that RPN on the consumer calculator is going to go the way of the dinosaur.
Frankly, this move (and the others done to scrape together money, then merging with Compaq...WTF?) does a great job of showing that execs shouldn't recieve bonuses for closing mergers.
If you're using any major Linux distribution, you're using a lot of software with development funded by RH.
All the major Linux vendors that I can think of fund general Linux development. Red Hat puts more money in than any other Linux distributor (at least partly due to virtue of sheer size, yes...).
This is why I get a kick out of people bashing distributors at the same time they're using software funded by them. "SuSE sucks, and they should die? Gee, I hope you don't like using X." "Red Hat sucks and should be wiped out by Debian? Gee, I hope you don't like using GNOME or gcc."
But software should install in linux the same way that it installs in windows. There should be one file, like setup.exe
No. I'm going to have to strongly disagree here.
Your complaint is valid and reasonable, and unfortunately ignored by the Linux community, but your solution is not.
Your complaint is that you want a simple *user interface* to install large pieces of software. This is reasonable. There is not front end that I know of that's widely used that chooses a reasonable subset of packages in a large software package (like GNOME) to install. You have to select all the packages in the system, one by one. That's fair, and should be addressed.
Your solution, however, is not a good idea. The Windows method of having a single installer puts you at the mercy of sitting down at the machine and actually clicking and installing stuff. It puts you at the mercy of what features are supported in the installer, how old the installer is, etc. The Linux (well, RPM/deb) approach is to separate the program from the packages. Upgrade the program, you get more features/bugfixes. You can install every piece of software remotely (ever watch Windows administrators run around installing a new piece of software on a network? What could be done securely on Linux with a bit of setup with sshd and public keys and then a single command to install software on every machine involves the IT people running around to each machine and clicking "OK" and watching progress bars). If you bundled all these packages into one large package, and someone doesn't *need* all of them, they need to download extra data. If you need to install, say, GNOME on every machine on the network, you only have to transfer the few RPMs *your* users actually require.
The solution is a fix to the front end, not to the architecture of the system. We need a single checkbox that installs a good default subset of packages for a large software package. The "GNOME" checkbox would install gnome-core, gnome-libs, etc, but probably not glade. The Linux rpm installation architecture is superior to the Windows installshield architecture -- now let's make the user experience as nice for novices.
Okay, my apologies. I haven't poked around too much with KDE.
GNOME's GConf does act as a Windows-like registry.
Just do this: Now the RPM is installed...now we want to see the program name.Voila!
Finally, dependencies are not the fault of the RPM system. If you took the raw binaries and plopped them on your system, you'd have the same dependencies...you just wouldn't be warned about them, and programs would malfunction, not launch because the linker would give a warning, etc.
RPM warns you of dependencies to *help* you, not to hurt you.
You can always install with --nodeps, but usually, unless you know what you're doing, you're better off trusting RPM.
A simple packaging system based on tarballs, a la Slackware
Try administering a network.
My experience with Slackware is seeing people managing to *just* get their system working and then leaving chunks of the software along and letting it get ancient because they don't want to break anything. They upgrade a library, they end up with zillions of broken library dependencies and programs that won't run.
You do realize that you can extract the source from srpm files easily and build however you so desire?
/usr/src/redhat/SOURCES on a RH box, for example.
There are lots of tools that can do it. If you happen to have rpm on your system, rpm -Uvh on the src.rpm will dump the tarball off in
You do realize that you can do a minimal installation of RH and install as you see fit? Just like Debian? The main difference is that you actually have industrywide support for your distro.
Really, there is nothing too difficult about:
l
./configure
make
su
make install
Yeah. But there's the ever so much more superior checkinstall:
./configure
make
su
checkinstal
This creates and installs an RPM of all the stuff you were installing. Voila...you can uninstall, you can query rpm to find out what package a file is part of, find out if uninstalling something will break dependencies, etc, etc...all the stuff that you can't do with just make install.
The syntax of UNIX config files is pretty standard (barring the occasional ugly misfit like sendmail -- use postfix instead).
And all the Windows registry does is give a standard format for storing individual values (how should I store a string, how should I store a DWORD) and provide a hierarchy. It says nothing about format or structure within a single app.
If you want to turn on, say, mail relaying in postfix on Linux, then you look for the entry called mail_relay (or whatever) that's commented out and contains a helpful set of comments right above the config entry. On Windows, the equivalent is to go into the registry to some unspecified key, create an unspecified value there and then set it to some unspecified value.
Of course, most people just use a front end on Windows -- like a preferences or options dialog -- because the registry is next to useless to actually interact with. You can do the same thing on Linux, which is done by GNOME and friends to make things more convenient for computer novices.
Also, if the Windows registry gets corrupted, you have a big problem. If a single text format config file gets corrupted, you can probably fix it yourself. If you can't...well, it's a single file down the drain. Reconfigure that single app. Your entire system doesn't become unbootable, a la Windows.
And there are plenty of front ends to rpm that can also get dependencies. If rpm is too low-level for you, that's why it was designed to be *really easy* to write front ends for, what with rpmlib and --queryformat.
I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.
.dll registration. On Windows, the only way the OS knows about a .systemwide dll is when you've added an entry to the registry for it. On Linux...run ldconfig, and it rebuilds the systemwide cache (ld.so.cache), which is significantly faster (contiguous, not incrementally modified, not modified by all sorts of other apps storing filename associations and the like) to read.
That's already done in the LSB.
The problem is that each rpm is required to contain a static list of files it installs *with pathnames*. The nice thing about this is that it lets you run rpm -qip foo.i386.rpm without executing any code (sandboxed or otherwise) to see the list of files. The stupid thing is that there then has to be a totally different rpm for every distro and every maintainer.
In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm. This is probably the most annoying design decision of RPM I've seen. There needs to be a FILES file with a list of installed files with a gen-files script (that runs sandboxed to build FILES for not-yet-installed packages and is run at package installation time to generate FILES). Have the Makefiles read this for make install. This would make life easier for maintainers (one list of files to install), would make RPMs more reliable (no accidental adding of a file to the Makefile but not to the spec file), and would let an RPM work on any distro (if we ever get the gcc-2.7, gcc-2.96, gcc-3 stuff worked out).
even though the newer libraries could do the job of the older ones
This is true for minor version number increases, but for a major version number change, newer libraries cannot simply link to the program.
Also, the registry is a fucking stupid idea. (despite the fact that GNOME and KDE are mindlessly cloning it). The registry causes more problems than anything else I've seen on a Windows system. The MacOS did things right -- let all your centralized databases just be caches for data that can be rebuilt from files around your system. If something gets borked or corrupted...that's okay. Absolutely do *not* make your single copy of data a registry -- put the masters around the system, and let the centralized db be rebuilt if necessary.
Also, registries require "installations" and "uninstallations" instead of just copying files. You can just copy appropriate files from one system to another and run code on a Linux or MacOS box. On a Windows box, you're in for running installers to poke at the registry. And finally, I've seen tons of broken Windows installers that poke at registry entries and end up completely screwing up data that some other app uses. For example, a friend once had Sonique and WinAmp installed, but couldn't associate mp3s with either. I took a look at the registry -- Microsoft's two-entry file association scheme let the extension entry point to a nonexistent application entry, IIRC. As a result, the mp3 entry didn't show up in the Folder Options dialog in Explorer, and couldn't be reassigned, and WinAmp and Sonique kept giving errors when trying to grab associations.
The day any distro starts requiring a registry is the day I never touch that distro again. Right now, I can just uninstall GNOME if I want to do so.
Oh, and another thing. The Windows registry is a *massive* shared database. As a result, tons of stuff modifies it and causes internal fragmentation and loss of physical continuity between related keys. Then all apps use the registry heavily (God, I hate apps that poll it), so you get slow app launch times, that annoying disk churning that you hear on Windows boxes...rrrgh.
Take a look at
The registry is basically a hack, because Windows *used* to have what MS considered a worse scheme (.ini files). It isn't a very well thought out system.
I hate it! You need to compile a new RPM for each platform
.tar.gz2 package which detects what OS your using, and compiles and installs automagically with an easy to use gui and a powerful cli interface
/i ce -20 rpm -tb "$@" && rpm -Uvh `find $our_rpm_buildroot -type f` && rm -f `find $our_rpm_buildroot -type f`
:-)
What we needis a smart
Well, hell.
------
#!/bin/sh
# Demonstration that RPM ain't all that bad
# Copyright 2002, 0x0d0a
# This code placed under the GPL
# Should compute proper buildroot, etc
# Be damn sure not to set buildroot to
# or something similar -- rm -rf would
# then suck severely
# Set our_rpm_buildroot appropriately
# Usage: mybuildrpm.sh foo.tar.bz2
our_rpm_buildroot=/usr/src/redhat
n
-----
Okay, I grant that there's no gui, but you get all the many CLI options of RPM. Voila!
People love to bash RPM, but it's a pretty sweet system (except the move to the newer underlying dbfile...screw transactions, I can always rebuild the database if it gets corrupted and it takes *much* longer to install and query than things did back with rpm 3.0). If it's too simple for you, it's really easy to use it as a back end and slap something on top of it.
Note: this is a one minute hack and may not even run, much less be safe for your system...it's an example, not intended to be used. And hell, running random stuff from people on Slashdot as root just isn't a great idea.
I hope that's a doubly-linked list.
A) Stop using IDEs.
This is one of the most aggressive things you can tell an emacs user to do. It's akin to going up to someone and saying "blood...blood...blood" over and over to them.
B) Design your code before you write it. Use UML, flowcharts or whatever
I recently used UML for the first time, and I have to say that UML is abstract to the point of being useless. I want to be able to change a UML diagram and regenerate code stubs. UML isn't capable of specifying stuff that's fairly important to C++ coders, like, say, typedef. The workarounds for this are really awful -- someone has you create a class called "Typedef" and toss some junk in it...yeech.
UML is a nice idea, but it needs to be a smidgen more powerful. Oh, and all the editors need to support XMI. I can understand MS not doing it with Visio, but dia not doing it is just embarrasing to the Open Source community (which constantly claims that everyone should use standard file formats).
C)Write code away from a computer
I really don't like doing this. I don't even like doing this for English text. I remember in grade school how we were taught in English to write rough drafts on paper and then use the standard markup symbols...ick. Much, *much* easier to do revision as you go through a text editor or word processor.
A senior C developer shouldn't need to write push() and pop() for a linked list.
I agree (though C is the the language where you'd most likely have to do this yourself) -- however, a senior C developer should be able to write push() and pop() for a linked list.
They want to filter out idiots quickly. I'm sure that they have more advanced questions as well.
Also, to the person who said that they'd tell them point blank that this is a bad idea -- if the first thing you do (this is at a *job interview*) is tell them that you're not going to do what they want you to do...well, you aren't making the greatest impression in the world.
I have a sudden suspicion that Sun gives this school funding...
Yes
large chunks are difficult to deal with in writing
90% of the time, anything over 100 lines of code is going to have at least one mistake in it, be it a syntax error or a bug.
I just completed Java and COBOL courses
Those are some odd bedfellows.