4. You can't plug AMD CPUs into Intel-chipset motherboards.
That's my reason. I don't believe that AMD-supporting chipsets are any worse than Intel's, but they do seem to be less well documented, which in turn means more quirks and bugs in drivers.
those damn right-handed-facist at logitic refuse to make a mouse that has 2+ buttons, and a scroll, for lefties.
Eh? Unlike Microsoft's devices, most (if not all) of Logitech's mouse devices are symmetrical about the y-axis. Certainly, my Mini Optical and Pilot are. Both have 3 buttons (one by clicking the wheel).
I agree, but whilst a signicant number of applications aren't ready for a.UTF-8 locale, IMHO, distros should stick to non-.UTF-8 equivalents. I'll concede that this is a religious issue.;-)
As for ALSA and freshrpms, I wholeheartedly recommend freshrpms. Matthias Saou has put together a phenomenal resource (far better than Red Hat's old 'contrib' collection of RPMs). My point was that ALSA is increasingly required and to not even include it on the current standard distro discs is somewhat short-sighted.
Yeah, don't get me wrong - as I said in my original post, I still prefer RH to the other distros (much as that baffles my Debian, Gentoo and Slackware-using buddies), but it feels like it's not going to be as comfortable using their free distros as it was, circa 4.x-7.x. I used to be able to stay on a single version quite comfortably for 12-18 months, but that will now be a maximum of 12 months, unless I feel like backporting and packaging all the security fixes myself.
RHEL is too expensive (and arguably too static) for myself, my business and many of the businesses that I've worked with. It seems like it's priced for the Fortune 100 types to me.
OTOH, that also presents an opportunity for my business (backporting errata for EOLed RH distros). So far, very few customers have expressed an interest in paying for such a service though.
I'll have to remember --oldpackage and --replacepkgs. I think those must be relatively recent additions. I've been using RH since 2.1 days, and I've got a subset of RPM switches readily accessible in my brain. Actually, reading the manpage, those two options are individual sub-features of --force. If you know exactly why you're --force'ing, there's no practical difference. The syntactic sugar is nice though.
The package version issue I mentioned isn't always caused by renaming the package file; IIRC, Ximian's package names used to throw RPM off. I'm pretty sure is it uses a naÃve alpha-numeric comparison, so it's fairly easy to fool
Finally, I'm not averse to building my own RPMs, but I try and stick to pristine Red Hat RPMs on production machines (particuarly if I'm not the only sysadmin). I did a minimal install of RH8 recently (i.e. for headless server use), and I found a single binary that required the X libraries. It seemed a bit daft to drag in a whole raft of X stuff just for that one binary, so I broke the dependency.
Firstly, I wasn't the original poster - I just rudely butted into the discussion.;-)
Secondly, some of these updates are recommended for reliability and/or security reasons. In some cases (e.g. ghostscript), security fixes have been backported. I'm not sure that's happened with everything though (and I'm pretty darned sure it hasn't with Mozilla). Red Hat used to be fairly on-the-ball with this, but I'm not sure they've got the motivation to carry on doing so with their Free distros.
Thirdly, w.r.t. my "proving ground" claim, can you offer any other explanation for the Native POSIX Thread Library (NPTL) stuff being backported from the 2.5 kernel to the 2.4 kernel shipped with RH9, despite it breaking widely-used packages like WINE? Looks like the beginning of "proving ground" stuff to me...
It's easy to think that way, but IMNSHO, that's pretty unprofessional, and a pile of crap to leave for someone to clear up after you decide to quit (or get downsized anyway).
Besides, "if you make yourself irreplaceable, you'll never get promoted" as they say.
Care to point one out? Anything in Red Hat 7.3, 8.0 or 9 will do but it must be "glaringly obvious" and "major".
IMHO, relative to RH8:
Setting the locale to en_GB.UTF-8 or whatever (instead of en_GTB), thus breaking Adobe Acrobat Reader.
Shipping versions of RPM older than 4.1.1
Shipping Mozilla 1.0.1 and galeon 1.2.6 as the latest errata
Not providing an update to XFree 4.3, which seems critical for hardware-assisted GL to work well with ATI Radeon cards
Not including ALSA, despite being required for lots of current sound cards
Not including ACPI support in the kernel and updating the battstat-applet in the gnome-applets package accordingly (required for laptops bought in the last year or so).
Shipping a very old version of ImageMagick
Leaving the netprofile functionality broken because of a simple typo in/etc/rc.d/rc.sysinit
Shipping an old version of xpdf
That's just a quick list culled from the set of custom packages I built to make RH8 "usable". I still prefer RH to the other distros, but I can see that their Free distros are going to become increasingly a proving ground for features before they're incorporated into RHEL.
The RPM DB does not usually simply corrupt itself, in 90% of the cases, in my experience, it's because someone did a --force at some point, the rest is because of HW problems (sig 11's, flaky memory).
Actually, there are known issues with rpmdb corruption with the versions of RPM shipped with RH8 and RH9. The good news is that they seem to have been ironed out in 4.1.1 and 4.2, but RH haven't deemed those versions suitable for shipping to the masses as an official errata update. Which is funny, because I find 4.1.1 much more stable.
I agree with most of your other points, though there are sometimes legitimate reasons to use --force (downgrading a package to an older version, and upgrading a package with a version that confuses RPM into thinking it's older than an already-installed package). --nodeps also has valid uses; if you don't want to pull in a dependency (e.g. a shared library, or application that provides the shared library) to satisfy a small non-critical sub-component of a critical package (and you're prepared to accept that sub-component being broken as a result).
8&9 make fine desktops, but introduce some annoying stability problems, not the lest of which is the old "corrupt RPM DB trick" that they have yet to fix
It's a bit scary, but I've found the rpm 4.1.1 backport of 4.2 to be much more stable than the current version shipped with RH8 (and presumably RH9). It's now one of my standard upgrades.
According to this site, a P5 has 3.1 million transistors. Assuming an average size of a discrete transistor package at 4mm x 3mm, that would require an area of at least 37.2(m^2) - or a square board measuring ~6.1m on each edge.
And that's discounting passive components and assuming that you can squeeze the wiring between the gaps.
For comparison, using the same assumptions, a P4 would require a square board measuring ~22.5m on each edge [504(m^2) area].
I'll leave it to someone else to work out the power requirements, and how reliable it would be with all those heat-generating components packed so closely together.
It sometimes takes a while to learn that little life's lesson... but I figured it out. I'll look for a bargain, but I don't go as cheap as possible for everything, and I'll bet you don't either.
I tried doing that, but I stopped when I realised I was getting the same substandard crap, but in a prettier case and with a more recognisable brand. Now I buy the cheapest that does the job, and save the extra so that I can afford to buy another one when it breaks.
(OK, that's a bit of an exaggeration, as I refuse to buy stuff like PC Chips motherboards, Tesco "Value" chicken and hard discs with less than 3 years warranty. OTOH, those are all examples of things that don't "do the job" IMHO.)
If the company's new workers make cheap, substandard crap, people won't buy it, and the company loses... so you can't go too cheap.
In my experience, that's a fiction. What really happens is that the company offering a quality service loses so much business in the first round of the competition that they go under. Then, despite the customers being disappointed with the substandard crap they bought last time, that's now all they can now find for sale, plus they've gotten used to the LOW! LOW! PRICES! and resent paying what was a reasonable price for a quality version, so they carry on buying the substandard crap. Rinse and repeat.
(Seriously. A modified PC is more flexible, but it isn't going to beat custom hardware of the same generation. In a few years, though...)
I didn't take a close look at the specifics, but a low-end Cisco box I glanced the innards of appeared powered by a mere M68030, and a SecureIDS box I looked at was definitely a Dell PowerEdge with a sticker covering the Dell logo. Given Cisco's markup, you could buy a kickass PeeCee for the same price. I call this the "US automobile" approach to performance; why bother solving the problem elegantly by building a light, but stiff chassis with a 2.0L engine, when you can put a 5.0L V8 in a heavy chassis?
Of course, this doesn't necessarily apply to Cisco's high-end gear, and certainly doesn't help with some users' support requirements...
It obviously costs something in time and money to create ideas and technologies. Has anyone done a scientific study comparing the creativity levels of countries with differing copyright systems? I'd love to see one done, as its results could shed light on the (non-)benefits given by extending copyright terms.
Purely empirically, based on my observations of the world around me, countries with strong IP laws - like the US, UK, Switzerland, Japan and others - have the highest standards of living, the lowest infant mortality rates, the highest literacy rates, the most Nobel prize winning scientists, and in fact lead the world in pretty much any metric you want. Countries without strong IP laws, or at least the enforcement of those laws, come right near the bottom.
Now look at rate of change of living standards. I think you'll find that the association is reversed.
States only start caring about IP once they have something they think is worth protecting. Just as IP rights are largely ignored in the developing world now, so the US copyright law once tolerated infringement of IP created by non-Americans.
In other words, some security is still better than none.
Unless it gives you a false sense of security (making you believe you don't need to lock the door to your home when you leave), which products like this can sometimes do.
I haven't looked at Exult, but my guesses as to the reasons for the large size of the binary:
It's statically linking all its libraries.
There's really a lot of code or data there
Choosing to modularise your application using libraries (be they statically, or dynamically linked) shouldn't in itself impact the size of the application noticeably. In fact, it's likely to encourage you to factorise better (leading to less repetition of code in slightly varied forms throughout the application) and lead to better overall memory usage if a.n.other application also uses one or more libraries.
Anyway, I was asking about applications that go to the trouble of building shared libraries (i.e. lib*.so) that are not used by any other applications.;-)
The solution is to use dynamic linking, but to provide the libraries with the rpm. At install time, if the library is there, you leave it alone (or give the user the choice to upgrade).
That's fine, but if you just upgrade the lib*.so, then the RPM database entry for the package that originally "owned" it is going to be inaccurate. This is where Windows-style DLL-hell begins; installers not using the specified API to update shared files.
Also, what about any header files the user may have installed? If you update the library object file, you should update the header files too. Oh, look, you've just re-created libfoo-1.2-3.i386.rpm and libfoo-devel-1.2-3.i386.rpm, but without seperate RPM database entries for them.
One approach that is interesting, is that of (at least some versions of) Star/OpenOffice. A script probes to see what libraries you have installed, and if you don't have libraries matching those the package was compiled with, it monkeys with LD_LIBRARY_PATH so that the appropriate versions get loaded from the Star/OpenOffice install. Good for compatibility, but it bloats the package, both on disc and in memory, and leaves you open to the possibility that you might want to update that library in the future to handle a critical security update.
It's almost certainly one of the.21 release candidates, possibly with one of Alan Cox's -ac patch sets amongst other things. It would appear that XFree 4.3.0 needs updated kernel DRM drivers, which would make the use of a 2.4.21-rc vaguely sensible.
Can you name any examples of applications that use shared libraries, but which the libraries aren't shared?
I can only think of drip at the moment.
The underlying problem is poorly specified packages (and I know some of my own fall into this category).
When building a binary rpm, RPM (the tool) will automatically detect shared libraries used by binaries and add dependencies accordingly (e.g. libasound.so.2). There's nothing to stop the package creator manually adding more informative package dependencies (e.g. Requires: alsa-lib >= 0.9.2) for the benefit of users installing their package. Red Hat are fairly good at this, and Matthias Saou of freshrpms.net fame is even better, IMHO. But a lot of third-party packagers aren't so dilligent. Adding manual dependencies also makes it easier for automatic dependency resolution tools (and this is why Debian's package management works well, rather than the technology!)
There's also nothing stopping a packager from creating an install.sh that rpm -Uvh's all the packages it needs. I seem to recall that CheckPoint do this with FireWall-1 for RH Linux.
DG's technological guru had one very precient saying "commodity economics always wins".
That saying mirrors how I've been thinking for a while now. With hindsight, the success of the x86 PeeCee was inevitable, based on how open it was compared with contemporary hardware designs.
Now, the question is, which is more of a commodity; Free software (inc. Linux) or Windows?
On one hand, Free software is a commodity because it's cheap, good enough, and open (like the PC, in fact). On the other, Windows is a commodity because the people who admin it are a commodity, and there's plenty of software and hardware designed for it.
I find it almost scary how much more I know about computer science than the computer scientists do. I'll mention a simple datastructure (hashtable, b-tree, anything!) and watch the eyes of degree holders gloss over.
Then, with due respect, you're interviewing some pretty crappy graduates. I got a lower-second on a three year bachelor's degree from a UK university that's second or third tier, and even I know what those datastructures are. I could even easily implement a hashtable, though I'd need to consult my textbooks to work out how to implement B-trees (as distinct from binary trees).
Though admittedly, I'd been playing around with computers for nine years prior to starting my degree.;-)
Slashdot Mirror
4. You can't plug AMD CPUs into Intel-chipset motherboards.
That's my reason. I don't believe that AMD-supporting chipsets are any worse than Intel's, but they do seem to be less well documented, which in turn means more quirks and bugs in drivers.
--
Eh? Unlike Microsoft's devices, most (if not all) of Logitech's mouse devices are symmetrical about the y-axis. Certainly, my Mini Optical and Pilot are. Both have 3 buttons (one by clicking the wheel).
--
As for ALSA and freshrpms, I wholeheartedly recommend freshrpms. Matthias Saou has put together a phenomenal resource (far better than Red Hat's old 'contrib' collection of RPMs). My point was that ALSA is increasingly required and to not even include it on the current standard distro discs is somewhat short-sighted.
--
RHEL is too expensive (and arguably too static) for myself, my business and many of the businesses that I've worked with. It seems like it's priced for the Fortune 100 types to me.
OTOH, that also presents an opportunity for my business (backporting errata for EOLed RH distros). So far, very few customers have expressed an interest in paying for such a service though.
--
The package version issue I mentioned isn't always caused by renaming the package file; IIRC, Ximian's package names used to throw RPM off. I'm pretty sure is it uses a naÃve alpha-numeric comparison, so it's fairly easy to fool
Finally, I'm not averse to building my own RPMs, but I try and stick to pristine Red Hat RPMs on production machines (particuarly if I'm not the only sysadmin). I did a minimal install of RH8 recently (i.e. for headless server use), and I found a single binary that required the X libraries. It seemed a bit daft to drag in a whole raft of X stuff just for that one binary, so I broke the dependency.
--
Secondly, some of these updates are recommended for reliability and/or security reasons. In some cases (e.g. ghostscript), security fixes have been backported. I'm not sure that's happened with everything though (and I'm pretty darned sure it hasn't with Mozilla). Red Hat used to be fairly on-the-ball with this, but I'm not sure they've got the motivation to carry on doing so with their Free distros.
Thirdly, w.r.t. my "proving ground" claim, can you offer any other explanation for the Native POSIX Thread Library (NPTL) stuff being backported from the 2.5 kernel to the 2.4 kernel shipped with RH9, despite it breaking widely-used packages like WINE? Looks like the beginning of "proving ground" stuff to me...
--
Besides, "if you make yourself irreplaceable, you'll never get promoted" as they say.
--
IMHO, relative to RH8:
Setting the locale to en_GB.UTF-8 or whatever (instead of en_GTB), thus breaking Adobe Acrobat Reader.
Shipping versions of RPM older than 4.1.1
Shipping Mozilla 1.0.1 and galeon 1.2.6 as the latest errata
Not providing an update to XFree 4.3, which seems critical for hardware-assisted GL to work well with ATI Radeon cards
Not including ALSA, despite being required for lots of current sound cards
Not including ACPI support in the kernel and updating the battstat-applet in the gnome-applets package accordingly (required for laptops bought in the last year or so).
Shipping a very old version of ImageMagick
Leaving the netprofile functionality broken because of a simple typo in /etc/rc.d/rc.sysinit
Shipping an old version of xpdf
That's just a quick list culled from the set of custom packages I built to make RH8 "usable". I still prefer RH to the other distros, but I can see that their Free distros are going to become increasingly a proving ground for features before they're incorporated into RHEL.
--
Actually, there are known issues with rpmdb corruption with the versions of RPM shipped with RH8 and RH9. The good news is that they seem to have been ironed out in 4.1.1 and 4.2, but RH haven't deemed those versions suitable for shipping to the masses as an official errata update. Which is funny, because I find 4.1.1 much more stable.
I agree with most of your other points, though there are sometimes legitimate reasons to use --force (downgrading a package to an older version, and upgrading a package with a version that confuses RPM into thinking it's older than an already-installed package). --nodeps also has valid uses; if you don't want to pull in a dependency (e.g. a shared library, or application that provides the shared library) to satisfy a small non-critical sub-component of a critical package (and you're prepared to accept that sub-component being broken as a result).
--
It's a bit scary, but I've found the rpm 4.1.1 backport of 4.2 to be much more stable than the current version shipped with RH8 (and presumably RH9). It's now one of my standard upgrades.
--
And that's discounting passive components and assuming that you can squeeze the wiring between the gaps.
For comparison, using the same assumptions, a P4 would require a square board measuring ~22.5m on each edge [504(m^2) area].
I'll leave it to someone else to work out the power requirements, and how reliable it would be with all those heat-generating components packed so closely together.
--
I tried doing that, but I stopped when I realised I was getting the same substandard crap, but in a prettier case and with a more recognisable brand. Now I buy the cheapest that does the job, and save the extra so that I can afford to buy another one when it breaks.
(OK, that's a bit of an exaggeration, as I refuse to buy stuff like PC Chips motherboards, Tesco "Value" chicken and hard discs with less than 3 years warranty. OTOH, those are all examples of things that don't "do the job" IMHO.)
--
In my experience, that's a fiction. What really happens is that the company offering a quality service loses so much business in the first round of the competition that they go under. Then, despite the customers being disappointed with the substandard crap they bought last time, that's now all they can now find for sale, plus they've gotten used to the LOW! LOW! PRICES! and resent paying what was a reasonable price for a quality version, so they carry on buying the substandard crap. Rinse and repeat.
--
--
I didn't take a close look at the specifics, but a low-end Cisco box I glanced the innards of appeared powered by a mere M68030, and a SecureIDS box I looked at was definitely a Dell PowerEdge with a sticker covering the Dell logo. Given Cisco's markup, you could buy a kickass PeeCee for the same price. I call this the "US automobile" approach to performance; why bother solving the problem elegantly by building a light, but stiff chassis with a 2.0L engine, when you can put a 5.0L V8 in a heavy chassis?
Of course, this doesn't necessarily apply to Cisco's high-end gear, and certainly doesn't help with some users' support requirements...
--
Purely empirically, based on my observations of the world around me, countries with strong IP laws - like the US, UK, Switzerland, Japan and others - have the highest standards of living, the lowest infant mortality rates, the highest literacy rates, the most Nobel prize winning scientists, and in fact lead the world in pretty much any metric you want. Countries without strong IP laws, or at least the enforcement of those laws, come right near the bottom.
Now look at rate of change of living standards. I think you'll find that the association is reversed.
States only start caring about IP once they have something they think is worth protecting. Just as IP rights are largely ignored in the developing world now, so the US copyright law once tolerated infringement of IP created by non-Americans.
--
Unless it gives you a false sense of security (making you believe you don't need to lock the door to your home when you leave), which products like this can sometimes do.
--
It's statically linking all its libraries.
There's really a lot of code or data there
Choosing to modularise your application using libraries (be they statically, or dynamically linked) shouldn't in itself impact the size of the application noticeably. In fact, it's likely to encourage you to factorise better (leading to less repetition of code in slightly varied forms throughout the application) and lead to better overall memory usage if a.n.other application also uses one or more libraries.
Anyway, I was asking about applications that go to the trouble of building shared libraries (i.e. lib*.so) that are not used by any other applications. ;-)
--
That's fine, but if you just upgrade the lib*.so, then the RPM database entry for the package that originally "owned" it is going to be inaccurate. This is where Windows-style DLL-hell begins; installers not using the specified API to update shared files.
Also, what about any header files the user may have installed? If you update the library object file, you should update the header files too. Oh, look, you've just re-created libfoo-1.2-3.i386.rpm and libfoo-devel-1.2-3.i386.rpm, but without seperate RPM database entries for them.
One approach that is interesting, is that of (at least some versions of) Star/OpenOffice. A script probes to see what libraries you have installed, and if you don't have libraries matching those the package was compiled with, it monkeys with LD_LIBRARY_PATH so that the appropriate versions get loaded from the Star/OpenOffice install. Good for compatibility, but it bloats the package, both on disc and in memory, and leaves you open to the possibility that you might want to update that library in the future to handle a critical security update.
--
--
I can only think of drip at the moment.
The underlying problem is poorly specified packages (and I know some of my own fall into this category).
When building a binary rpm, RPM (the tool) will automatically detect shared libraries used by binaries and add dependencies accordingly (e.g. libasound.so.2). There's nothing to stop the package creator manually adding more informative package dependencies (e.g. Requires: alsa-lib >= 0.9.2) for the benefit of users installing their package. Red Hat are fairly good at this, and Matthias Saou of freshrpms.net fame is even better, IMHO. But a lot of third-party packagers aren't so dilligent. Adding manual dependencies also makes it easier for automatic dependency resolution tools (and this is why Debian's package management works well, rather than the technology!)
There's also nothing stopping a packager from creating an install.sh that rpm -Uvh's all the packages it needs. I seem to recall that CheckPoint do this with FireWall-1 for RH Linux.
--
cd
Then scribble nnn on the CD's hub, and maybe a few of the more salient contents if I'm feeling enthusiastic.
I then zgrep /usr/local/doc/cdcontents/* for when I'm looking for files. I use descriptive paths and filenames.
--
That saying mirrors how I've been thinking for a while now. With hindsight, the success of the x86 PeeCee was inevitable, based on how open it was compared with contemporary hardware designs.
Now, the question is, which is more of a commodity; Free software (inc. Linux) or Windows?
On one hand, Free software is a commodity because it's cheap, good enough, and open (like the PC, in fact). On the other, Windows is a commodity because the people who admin it are a commodity, and there's plenty of software and hardware designed for it.
Hmmmm...
--
Then, with due respect, you're interviewing some pretty crappy graduates. I got a lower-second on a three year bachelor's degree from a UK university that's second or third tier, and even I know what those datastructures are. I could even easily implement a hashtable, though I'd need to consult my textbooks to work out how to implement B-trees (as distinct from binary trees).
Though admittedly, I'd been playing around with computers for nine years prior to starting my degree. ;-)
--
--