I was trying to agree with your statement that leaving out core packages is unwise. I have different reasons than you do to say this. It's not that disk space is cheap on desktop systems, as you pointed out, but rather that tools like a good compiler is core to poking around with the system. Leaving it out of a new user's operating system to avoid "bloat" is like not keeping plates in your kitchen to avoid cluttering your shelves. It kind of defeats the purpose of having a kitchen, or in this case an operating system.
The uses of Linux are not merely for hard-core developers: shiftiing the price of using a fully featured OS from a cash price to buy licensed tools to a developmentn cost of building your own first set from scratch is simply going to keep out some bright people and waste their time re-inventing the wheel. Humans have specialiists for making better tools for their community: this is one way to share them: we don't make even professional chefs in school milk their own cows and harvest their own wheat and feed their own chickens to learn to make pie crust, except perhaps once for appreciation of the source of their food.
Not that farm-made produce isn't wonderful and tasty, but the rest of us have to get to work to do everything else we do: we trade them the machine tools and goods the rest of us make for their goods. It's good to learn a bit about them to appreciate them, but we don't give new parents a pile of wood, a pile of seeds, and an empty field to make their first home. We help them get a home and throw them a baby shower to help htem raise their first child. After they get settled, they can look at buying their dream house and how they want to raise their kids and whether to use cloth or disposable diapers.
Oh, the kernel on RedHat/CentOS is pretty old, and it's not state-of-the-art by any means: the RHEL 5 beta release is a vast improvement in hardware support. RHEL is for if you need server-grade kernel and system support and don't have it in-house.
And by this point, your hardware was six months older, right? Meaning there was time to integrate the latest monitor, graphics drivers, and other hardware related details into the OS? Have you retried that hardware with the latest "live" CD's of the other distributions, to see if they've worked out the relevant kinks?
How well does Ubunto handle Xen or another lightweight Windows virtualization system? I'd absolutely recommend that new Linux hardware have the CPU virtualization features to run another Windows OS directly locally: most new hardware comes with enough speed and RAM to do this, and a Windows license anyway, so let the user have Windows available in a local installation for games and Windows Media and other tools they may require, and use Linux for the basic OS stability and tools as they learn to play with them.
A recent enough OS to support Evolution for access to MS Exchange email and calendar functionality in a shared or corporate environment is vital. Fedora Core 6, the RHEL 5 demo, and the latest OpenSuSE seem to support it, although Novell has just made a huge licensing mistake involving Microsoft patents and just lost one of the core Samba developers in the resulting mess and will doubtless lose other core people. Expect SuSE support of critical Windows compatibility to be actually hurt by their deal with Microsoft, as they cripple themselves by using Microsoft technologies directly and not being able to use GPL tools from that patent agreement.
For ease of use, find what the local Linux experts use at home, and stay away from bleeding edge hardware that may involve a lot of manual work to integrate into your OS. 64-bit dual-core Opterons have good reports and better Linux support than Intel's 64-bit oddnesses: high-end ATI video cards are better supported than NVidia because ATI publishes their specifications, NVidia tries to shoe-horn their proprietary and extensively modified libraries on top of existing Linux tools and does a very strange job of it. 250 Gig drives are cheap and plentiful: use known-vendor, actual hardware RAID instead of software RAID, if you need RAID, since a lot of software RAID drivers are poorly documented and a nightmare to integrate. Check what the network chipsets are: if they're something unheard of, prepare to spring for a $10 NE2000 card or borrow a cheap USB network port, just to get booted far enough to grab patches.
Describe what you need or want to accomplish for more ideas: are you a gamer? A Perl programmer? Doing simple web browsing with flash and animation making you excited? Doing Q/A work?
There's a big difference between tracking people in a voluntary fashion with a wrist bracelet, or giving ordinary people access to the RFID information of the contents of stores, than using it against their will via a national ID card or even a passport where they didn't ask for it and they have no access whatsoever to the data: only the federal government has access to the data, with all the risks and demonstrated incompetence the passport RFID project has demonstrated, and where the risks of forgery are much more demonstrable.
Not at all. With RFID tags for pets, children's toys, and passports, the tracking possibilities of having the readers ubiquitously placed are quite intriguing. As the technology becomes more widespread it can be used for tracking stolen goods as well as for surveillance tracking by law enforcement and by the stores, customers looking for sales items and whether there are any in stock in the back room or sitting in the "returned" departments without troubling the staff to go and look or even being able to check the website and verify how many are on the shelves so they can pre-order one or put one on reserve before visitint the store, etc.
There are numerous uses for the technology. Evne putting a tag on the reader itself can let a grown child or spouse wander off for a bit of private shopping for holiday gifts and be tracked for safety or to meet at a specified time with ease. It's potentially useful technology, although I hope security concerns have been addressed properly.
Not necessarily. With a water flight and reasonably large wings, he can attempt to stall just before hitting the water. Still quite dangerous, but it's at a much lower velocity and lower altitude: airplane pilots are taught similar tricks for aircraft with ruined landing gear.
The issue came up in a discussion of a similar technology 30 years ago: these ideas are hardly new.
There was a magazine article on a similar technology over 30 years ago. I believe it was in Popular Mechanics: using small jet engines purchased from the US Air Force, with 30 miles per gallon fuel economy and a cruising velocity of roughly 100 mph, and a lift capacity of roughly 300 pounds. It was VTOL, and under the aircraft licensing of the time would have been considered an "ultra-light" and not required a pilot's license.
The builder wanted to switch to duced fans for commercial use: I never knew what became of the project, but I've wanted my own for more than 30 years.
The visually impaired, especially htose using text->speech synthesizers, have real problems with most Javascript. Given how much Javascript is also done incredibly badly, there's really no excuse for most of it.
Even the world's best developers don't have time to waste: failing to properly bundle the software is begging for conflicts with existing software. They'renot Oracle: they don't have a big enough customer base to write a software installer that bad.
It's not extortion. If you need core support, or even more important new features for RedHat software, or QA testing with new hardware before you buy dozens of expensive systems only to find out the kernel doesn't support their new hardware, you pay RedHat to get that support. And the CentOS packagers aren't the authors of some core modern features, like the clustering software or new file system. If you need that sort of thing, you can pay and train people in house, or you can buy it from RedHat.
If you've got the expertise or desire to do it in house, you hire your own people.
Amen. Debian benefited from.deb nazis who insisted on good and consistently written packages, making it much easier to read. RPM has suffered extensively from a lot of Perl-novice like code and feature promulgation, and the result has been extremely painful to work with.
I agree with your assessment, but remember that RPM originally had to work in a very, very tiny boot medium (floppies!) cpio is ocnsiderably smaller and less feature-filled than GNU tar: it fits in a lot less binary space. So historically, it makes sense. Similarly, putting a header on the front with the package informaton is faster than putting it on the back, even if you have to strip it off with 'dd' to get the actually package bundle. And rpm2cpio works pretty well to make that painless.
But I agree with you about careless/naive developers. RPM package management has a very poor history of even its main corporate package reviewers performing and propagating absolute insanities, such as inconsistent naming schemes, and extremely poorly written pre and post-install operations. After all, is it libgimp, or gimp-lib? kernel-source, or kernel-devel? Who can tell? Should we save a copy of httpd.conf as httpd.conf.rpmsave, or just overwrite it? What's the right default behavior?
"Unfortunately the time I am willing to wait for this agreement to be changed to remedy the GPL violation has passed, and so I must say goodbye."
He starts work for Google in early 2007, and is answering a lot of questions with silence. But his letter is painfully clear. I think we can also expect Samba development to get a real boost from this.
That's really odd: the quote posted here on Slashdot of your original article shows you ranting like a raving blogger with not a hint of the actual failure or problems, making it impossible to actually assess the problem. And now you say you didn't want a flamewar or to get slashdotted? It does seem rather like a typical Mac vs. Windows review, where the actual content gets yanked and you now protest innocence of your intent.
And the references to Ron Newman testing the site and finding it working well with Opera that are mentioned here are interesting. Is "Ron Newman" this guy (http://www.xs4all.nl/~kspaink/cos/rnewman/home.ht ml)? He is an ancient spam and Internet abuse hunter, going all the way back to the original Canter&Siegel Usenet spam. An ISP I worked for took some serious grief when he and his peers started complaining, before they could update their NNTP servers to block the forgeries they were complaining about.
Next time, test with Lynx, links, or with the Emacs web browsers. Seriously, a lot of graphical absurdities get done in a lot of web sites, which a flat-text browser is wonderful for identifying and testing and encouraging designers to move away from whatever graphical absurdities their particular design tools tend to encourage.
Please do send in your complaints. If a site doesn't work with Lynx, it's very unlikely to work with poor bandwidth clients, or with text->speech synthesizers for the visually impaired, or with a broad variety of web clients that don't violate the HTML or XTML specifications exactly the way the favored browser does. Letting web authors, and most especially their bosses, know that they're making life hard for their customers is a basic step to getting it fixed and getting them to design it the right way next time.
Explaining to a web designer that Javascript should not be mandatory in a client is a big step to keeping web pages legible and reliable, even 2 years from now when you have to pull some information off of a backup or a Google cache. And your low end computer users, like Nick Negroponte's "One Laptop Per Child" clients, will appreciate keeping web pages full of actual content, rather than filled with dancing bears and unwanted pop-ups.
I remember that case too: her nylons were actually melted to her legs. We're talking about major burns, surgery, and permanent scarring. It's a great example of how a case can be mistold to give the wrong lesson.
And to the trolls who talk about "natural selection" with children's toys, behavior is part of natural selection. We babysitters, godparents, and relatives of the next generation improve our chance of the next generation carrying our genes by protecting them from fools and teaching them elementary caution. If you want to have completely awesome raw lives and evolutionary forces at play, strip naked right now and go find your own food for 3 days without getting it from others or borrowing any tools from them.
This is particularly important for libraries: no one cares if libc.so.42 is from glibc-4.x or if glibc gets updated to glibc-7.x, and the library comes from a compatibility package. But for core libraries like glibc, openssl, and X11, it's much safer to make the dependency on a library than on a package.
This is exacerbated by tools like XFree86, xorg, modprobe, and modutils where the package names themselves have changed. And the problem is also worsened by programs that include different files depending on build-time options, such as SuSE's MPEG players and various kernel configurations. It makes it impossible to predict which package will satisfy the dependency, but has to be resolved based on the file name.
That's why SQLite replaces it so well for such lightweight applications. By leaving out so many excessive and unstable features of db4, it's made RPM databases stable and far faster. And db4, or rather the Sleepycat company that developed it, has been purchased by Oracle. Expect db4's better ideas and development to be migrated over to Oracle development, and for long-standing bugs and feature demands to fall on deaf ears.
Better yet, go try to find, much less download, the latest db4.5. Yes, it has new features, but it's no more stable under real world loads, its behavior is still not sufficiently atomic, and recovering from a corrupted database is just as awful. And don't expect a db4.6 now that Oracle owns it.
Sure, I'm a special case. But having to strip out packages after the fact, I'm begging for pain and difficulty. And the -devel packages can get quite bulky. If I'm installing a kernel RPM, and have to include kernel-devel as well as the binaries by default, that means I may no longer have space to do the installation in a microsystem. That's especially painful when you have to install or upgrade a lot of packages at a time.
Also, on systems deliberately restricted for security reasons, they should certainly be considered separate. I'd just like to see such packages used consistently: too many newly written packages fail to separate the development components, or name them something weird and unpredictable so they're tough to manage. And there's much less technical reason for that.
Yes, that's completely reasonable. But that's when you build it in a sandbox, and then RPM bundle it to get it under a management system so that the setup for your test box is the same as on other people's live setups.
A lot of the problems of RPM and other packaging systems benefit when the author has to actually bundle it, and when the bundlers contact the author and point out where they've violated standards. And refusals to bundle cleanly, or to work with software bundlers, are why Pine is no longer in RedHat, and why no RPM-based distribution includes Dan Bernsteiin's tools: they won't even permit others to modify the system to package it more cleanly.
Slashdot Mirror
I was trying to agree with your statement that leaving out core packages is unwise. I have different reasons than you do to say this. It's not that disk space is cheap on desktop systems, as you pointed out, but rather that tools like a good compiler is core to poking around with the system. Leaving it out of a new user's operating system to avoid "bloat" is like not keeping plates in your kitchen to avoid cluttering your shelves. It kind of defeats the purpose of having a kitchen, or in this case an operating system.
The uses of Linux are not merely for hard-core developers: shiftiing the price of using a fully featured OS from a cash price to buy licensed tools to a developmentn cost of building your own first set from scratch is simply going to keep out some bright people and waste their time re-inventing the wheel. Humans have specialiists for making better tools for their community: this is one way to share them: we don't make even professional chefs in school milk their own cows and harvest their own wheat and feed their own chickens to learn to make pie crust, except perhaps once for appreciation of the source of their food.
Not that farm-made produce isn't wonderful and tasty, but the rest of us have to get to work to do everything else we do: we trade them the machine tools and goods the rest of us make for their goods. It's good to learn a bit about them to appreciate them, but we don't give new parents a pile of wood, a pile of seeds, and an empty field to make their first home. We help them get a home and throw them a baby shower to help htem raise their first child. After they get settled, they can look at buying their dream house and how they want to raise their kids and whether to use cloth or disposable diapers.
Oh, the kernel on RedHat/CentOS is pretty old, and it's not state-of-the-art by any means: the RHEL 5 beta release is a vast improvement in hardware support. RHEL is for if you need server-grade kernel and system support and don't have it in-house.
And by this point, your hardware was six months older, right? Meaning there was time to integrate the latest monitor, graphics drivers, and other hardware related details into the OS? Have you retried that hardware with the latest "live" CD's of the other distributions, to see if they've worked out the relevant kinks?
How well does Ubunto handle Xen or another lightweight Windows virtualization system? I'd absolutely recommend that new Linux hardware have the CPU virtualization features to run another Windows OS directly locally: most new hardware comes with enough speed and RAM to do this, and a Windows license anyway, so let the user have Windows available in a local installation for games and Windows Media and other tools they may require, and use Linux for the basic OS stability and tools as they learn to play with them.
A recent enough OS to support Evolution for access to MS Exchange email and calendar functionality in a shared or corporate environment is vital. Fedora Core 6, the RHEL 5 demo, and the latest OpenSuSE seem to support it, although Novell has just made a huge licensing mistake involving Microsoft patents and just lost one of the core Samba developers in the resulting mess and will doubtless lose other core people. Expect SuSE support of critical Windows compatibility to be actually hurt by their deal with Microsoft, as they cripple themselves by using Microsoft technologies directly and not being able to use GPL tools from that patent agreement.
For ease of use, find what the local Linux experts use at home, and stay away from bleeding edge hardware that may involve a lot of manual work to integrate into your OS. 64-bit dual-core Opterons have good reports and better Linux support than Intel's 64-bit oddnesses: high-end ATI video cards are better supported than NVidia because ATI publishes their specifications, NVidia tries to shoe-horn their proprietary and extensively modified libraries on top of existing Linux tools and does a very strange job of it. 250 Gig drives are cheap and plentiful: use known-vendor, actual hardware RAID instead of software RAID, if you need RAID, since a lot of software RAID drivers are poorly documented and a nightmare to integrate. Check what the network chipsets are: if they're something unheard of, prepare to spring for a $10 NE2000 card or borrow a cheap USB network port, just to get booted far enough to grab patches.
Describe what you need or want to accomplish for more ideas: are you a gamer? A Perl programmer? Doing simple web browsing with flash and animation making you excited? Doing Q/A work?
There's a big difference between tracking people in a voluntary fashion with a wrist bracelet, or giving ordinary people access to the RFID information of the contents of stores, than using it against their will via a national ID card or even a passport where they didn't ask for it and they have no access whatsoever to the data: only the federal government has access to the data, with all the risks and demonstrated incompetence the passport RFID project has demonstrated, and where the risks of forgery are much more demonstrable.
Not at all. With RFID tags for pets, children's toys, and passports, the tracking possibilities of having the readers ubiquitously placed are quite intriguing. As the technology becomes more widespread it can be used for tracking stolen goods as well as for surveillance tracking by law enforcement and by the stores, customers looking for sales items and whether there are any in stock in the back room or sitting in the "returned" departments without troubling the staff to go and look or even being able to check the website and verify how many are on the shelves so they can pre-order one or put one on reserve before visitint the store, etc.
There are numerous uses for the technology. Evne putting a tag on the reader itself can let a grown child or spouse wander off for a bit of private shopping for holiday gifts and be tracked for safety or to meet at a specified time with ease. It's potentially useful technology, although I hope security concerns have been addressed properly.
Not necessarily. With a water flight and reasonably large wings, he can attempt to stall just before hitting the water. Still quite dangerous, but it's at a much lower velocity and lower altitude: airplane pilots are taught similar tricks for aircraft with ruined landing gear.
The issue came up in a discussion of a similar technology 30 years ago: these ideas are hardly new.
There was a magazine article on a similar technology over 30 years ago. I believe it was in Popular Mechanics: using small jet engines purchased from the US Air Force, with 30 miles per gallon fuel economy and a cruising velocity of roughly 100 mph, and a lift capacity of roughly 300 pounds. It was VTOL, and under the aircraft licensing of the time would have been considered an "ultra-light" and not required a pilot's license.
The builder wanted to switch to duced fans for commercial use: I never knew what became of the project, but I've wanted my own for more than 30 years.
The visually impaired, especially htose using text->speech synthesizers, have real problems with most Javascript. Given how much Javascript is also done incredibly badly, there's really no excuse for most of it.
Even the world's best developers don't have time to waste: failing to properly bundle the software is begging for conflicts with existing software. They'renot Oracle: they don't have a big enough customer base to write a software installer that bad.
It's not extortion. If you need core support, or even more important new features for RedHat software, or QA testing with new hardware before you buy dozens of expensive systems only to find out the kernel doesn't support their new hardware, you pay RedHat to get that support. And the CentOS packagers aren't the authors of some core modern features, like the clustering software or new file system. If you need that sort of thing, you can pay and train people in house, or you can buy it from RedHat.
If you've got the expertise or desire to do it in house, you hire your own people.
Amen. Debian benefited from .deb nazis who insisted on good and consistently written packages, making it much easier to read. RPM has suffered extensively from a lot of Perl-novice like code and feature promulgation, and the result has been extremely painful to work with.
I agree with your assessment, but remember that RPM originally had to work in a very, very tiny boot medium (floppies!) cpio is ocnsiderably smaller and less feature-filled than GNU tar: it fits in a lot less binary space. So historically, it makes sense. Similarly, putting a header on the front with the package informaton is faster than putting it on the back, even if you have to strip it off with 'dd' to get the actually package bundle. And rpm2cpio works pretty well to make that painless.
But I agree with you about careless/naive developers. RPM package management has a very poor history of even its main corporate package reviewers performing and propagating absolute insanities, such as inconsistent naming schemes, and extremely poorly written pre and post-install operations. After all, is it libgimp, or gimp-lib? kernel-source, or kernel-devel? Who can tell? Should we save a copy of httpd.conf as httpd.conf.rpmsave, or just overwrite it? What's the right default behavior?
If it threatens to, the main author of Samba just gave Google a shovel. From the article at http://www.groklaw.net/article.php?story=200612210 81000710:
"Unfortunately the time I am willing to wait for this agreement to be changed to remedy the GPL violation has passed, and so I must say goodbye."
He starts work for Google in early 2007, and is answering a lot of questions with silence. But his letter is painfully clear. I think we can also expect Samba development to get a real boost from this.
Oh, you're like me. "Keep It Simple, Stupid" web design is a lot easier with a text editor.
That's really odd: the quote posted here on Slashdot of your original article shows you ranting like a raving blogger with not a hint of the actual failure or problems, making it impossible to actually assess the problem. And now you say you didn't want a flamewar or to get slashdotted? It does seem rather like a typical Mac vs. Windows review, where the actual content gets yanked and you now protest innocence of your intent.
t ml)? He is an ancient spam and Internet abuse hunter, going all the way back to the original Canter&Siegel Usenet spam. An ISP I worked for took some serious grief when he and his peers started complaining, before they could update their NNTP servers to block the forgeries they were complaining about.
And the references to Ron Newman testing the site and finding it working well with Opera that are mentioned here are interesting. Is "Ron Newman" this guy (http://www.xs4all.nl/~kspaink/cos/rnewman/home.h
Next time, test with Lynx, links, or with the Emacs web browsers. Seriously, a lot of graphical absurdities get done in a lot of web sites, which a flat-text browser is wonderful for identifying and testing and encouraging designers to move away from whatever graphical absurdities their particular design tools tend to encourage.
Please do send in your complaints. If a site doesn't work with Lynx, it's very unlikely to work with poor bandwidth clients, or with text->speech synthesizers for the visually impaired, or with a broad variety of web clients that don't violate the HTML or XTML specifications exactly the way the favored browser does. Letting web authors, and most especially their bosses, know that they're making life hard for their customers is a basic step to getting it fixed and getting them to design it the right way next time.
Explaining to a web designer that Javascript should not be mandatory in a client is a big step to keeping web pages legible and reliable, even 2 years from now when you have to pull some information off of a backup or a Google cache. And your low end computer users, like Nick Negroponte's "One Laptop Per Child" clients, will appreciate keeping web pages full of actual content, rather than filled with dancing bears and unwanted pop-ups.
I remember that case too: her nylons were actually melted to her legs. We're talking about major burns, surgery, and permanent scarring. It's a great example of how a case can be mistold to give the wrong lesson.
And to the trolls who talk about "natural selection" with children's toys, behavior is part of natural selection. We babysitters, godparents, and relatives of the next generation improve our chance of the next generation carrying our genes by protecting them from fools and teaching them elementary caution. If you want to have completely awesome raw lives and evolutionary forces at play, strip naked right now and go find your own food for 3 days without getting it from others or borrowing any tools from them.
This is particularly important for libraries: no one cares if libc.so.42 is from glibc-4.x or if glibc gets updated to glibc-7.x, and the library comes from a compatibility package. But for core libraries like glibc, openssl, and X11, it's much safer to make the dependency on a library than on a package.
This is exacerbated by tools like XFree86, xorg, modprobe, and modutils where the package names themselves have changed. And the problem is also worsened by programs that include different files depending on build-time options, such as SuSE's MPEG players and various kernel configurations. It makes it impossible to predict which package will satisfy the dependency, but has to be resolved based on the file name.
Yum caches much of it, too. Check out the "metadata".
It's amazing how much of this conversation has switched to yum vs. apt, instead of yum vs. pkg or deb, by the way.
That's why SQLite replaces it so well for such lightweight applications. By leaving out so many excessive and unstable features of db4, it's made RPM databases stable and far faster. And db4, or rather the Sleepycat company that developed it, has been purchased by Oracle. Expect db4's better ideas and development to be migrated over to Oracle development, and for long-standing bugs and feature demands to fall on deaf ears.
Better yet, go try to find, much less download, the latest db4.5. Yes, it has new features, but it's no more stable under real world loads, its behavior is still not sufficiently atomic, and recovering from a corrupted database is just as awful. And don't expect a db4.6 now that Oracle owns it.
Sure, I'm a special case. But having to strip out packages after the fact, I'm begging for pain and difficulty. And the -devel packages can get quite bulky. If I'm installing a kernel RPM, and have to include kernel-devel as well as the binaries by default, that means I may no longer have space to do the installation in a microsystem. That's especially painful when you have to install or upgrade a lot of packages at a time.
Also, on systems deliberately restricted for security reasons, they should certainly be considered separate. I'd just like to see such packages used consistently: too many newly written packages fail to separate the development components, or name them something weird and unpredictable so they're tough to manage. And there's much less technical reason for that.
Yes, that's completely reasonable. But that's when you build it in a sandbox, and then RPM bundle it to get it under a management system so that the setup for your test box is the same as on other people's live setups.
A lot of the problems of RPM and other packaging systems benefit when the author has to actually bundle it, and when the bundlers contact the author and point out where they've violated standards. And refusals to bundle cleanly, or to work with software bundlers, are why Pine is no longer in RedHat, and why no RPM-based distribution includes Dan Bernsteiin's tools: they won't even permit others to modify the system to package it more cleanly.