In the interest of good open source-dness, I'd like to know how it's "wrong" to object to the presence of a compiler that's not a public release, not a stable beta, and not even considered a "stable development version" by the team that designed it. No offense intended, sir, but that's a lot to swallow, and even more to defend in front of a client or executive.
I understand innovation. I appreciate some dominant distro taking a bit of a technological leap to push the progress of the whole Linux market. That's actually a good thing, and RH has done it before in *.0 versions. I would prefer, however, that 7.1 greet my machine with a rock-solid gcc 3.0 and recompile my kernel in the process. I'd prefer that my inet superdaemon be the industry standard, Berkley's inetd, with a single config file that I can scan at a glance, instead of "xinetd" with its whole directory full of config files. I don't consider that an improvement. I'd rather the exciting new Red Hat Network daemon be, at least, a debugged product before finding out on the internet that it crashes the system after three weeks uptime. I understand improving RPM to 4.0, but making it completely backwards-incompatible is a real leap. It makes experimentation with 7 more of a wholesale leap into the deep, red fog. (BTW, thanks to RH for the cd full of apps already packaged with RPM 4, which eases the transition a LOT!)
Bugs in a *.0 are not unknown, and IT pros know better than to go mission-critical with a first releast of *any* OS. The whole business of unsupported, unfinished, unknown, unstable ingredients that forces a soup-to-nuts upgrade cycle is made even worse when the non-compatible nature of that upgrade is not (at the very least) advertised clearly beforehand. It brings to mind the two-year life cycle of MS Office 95 and all its file formats. Educated users should be equipped to make qualified decisions about upgrading from a top-notch 6.2 to a pre-release quality 7.0. How difficult does this make the job of Linux professionals who have to explain why their bosses should *not* respond immediately to the hot new release from Red Hat? Red Hat's not Microsoft, never intended to be, but the unidirectional nature of the development of key components is a big pill to swallow, especially when they're not Unix industry standard.
No offense intended, but we're not just "wrong", sir. We're concerned.
I went to college, and graduate school, to pursue a dream I'd had since grade school. I was thiiis close to being a professional molecular biologist. Got two years into a PhD, published 4 papers off my work, had a good time. Some family business pulled me out of grad school, and I ended up teaching...math. The next job let me teach math and chemistry; I fit in a senior Bio II class once, just for kicks. Being a teacher got me using computers professionally, then for fun, then AS a profession. Now I'm a Unix/network engineer.
College isn't about career training anymore. A degree shows you have long-term goal priorities and a breadth of knowledge. Frankly, I sit up nights and watch the History Channel because I've grown to "like" it. Has nothing to do with my career. It has to do with breadth of interest, something that was fostered in college, and something that ended up providing me long-term marketability. I could go back into teaching tomorrow if I needed to, and a 30-yr-old with a degree gets taken seriously when he has two years' experience in his current field.
The idea of storing bits of info without names and classifying them according to retrieval is already implemented in a crude form in the "find" utility. We can search for a document containing a text string, created on a date, of a size. It's limited, for certain, but the idea of data without names is not as foreign as some of you have suggested. It's just clumsy and slow, as we become with age and poor mental conditioning.
The idea of storing 100 papers with numeric titles in a directory together and retrieving them by a find search is not entirely unfeasible. The retrieval of a picture out of 100 basically untitled images, however, is different. A picture may be worth a thousand words, but not to this particular Compaq.
Slashdot Mirror
In the interest of good open source-dness, I'd like to know how it's "wrong" to object to the presence of a compiler that's not a public release, not a stable beta, and not even considered a "stable development version" by the team that designed it. No offense intended, sir, but that's a lot to swallow, and even more to defend in front of a client or executive.
I understand innovation. I appreciate some dominant distro taking a bit of a technological leap to push the progress of the whole Linux market. That's actually a good thing, and RH has done it before in *.0 versions. I would prefer, however, that 7.1 greet my machine with a rock-solid gcc 3.0 and recompile my kernel in the process. I'd prefer that my inet superdaemon be the industry standard, Berkley's inetd, with a single config file that I can scan at a glance, instead of "xinetd" with its whole directory full of config files. I don't consider that an improvement. I'd rather the exciting new Red Hat Network daemon be, at least, a debugged product before finding out on the internet that it crashes the system after three weeks uptime. I understand improving RPM to 4.0, but making it completely backwards-incompatible is a real leap. It makes experimentation with 7 more of a wholesale leap into the deep, red fog. (BTW, thanks to RH for the cd full of apps already packaged with RPM 4, which eases the transition a LOT!)
Bugs in a *.0 are not unknown, and IT pros know better than to go mission-critical with a first releast of *any* OS. The whole business of unsupported, unfinished, unknown, unstable ingredients that forces a soup-to-nuts upgrade cycle is made even worse when the non-compatible nature of that upgrade is not (at the very least) advertised clearly beforehand. It brings to mind the two-year life cycle of MS Office 95 and all its file formats. Educated users should be equipped to make qualified decisions about upgrading from a top-notch 6.2 to a pre-release quality 7.0. How difficult does this make the job of Linux professionals who have to explain why their bosses should *not* respond immediately to the hot new release from Red Hat? Red Hat's not Microsoft, never intended to be, but the unidirectional nature of the development of key components is a big pill to swallow, especially when they're not Unix industry standard.
No offense intended, but we're not just "wrong", sir. We're concerned.
John Beamon, RHCE
I went to college, and graduate school, to pursue a dream I'd had since grade school. I was thiiis close to being a professional molecular biologist. Got two years into a PhD, published 4 papers off my work, had a good time. Some family business pulled me out of grad school, and I ended up teaching...math. The next job let me teach math and chemistry; I fit in a senior Bio II class once, just for kicks. Being a teacher got me using computers professionally, then for fun, then AS a profession. Now I'm a Unix/network engineer.
College isn't about career training anymore. A degree shows you have long-term goal priorities and a breadth of knowledge. Frankly, I sit up nights and watch the History Channel because I've grown to "like" it. Has nothing to do with my career. It has to do with breadth of interest, something that was fostered in college, and something that ended up providing me long-term marketability. I could go back into teaching tomorrow if I needed to, and a 30-yr-old with a degree gets taken seriously when he has two years' experience in his current field.
The idea of storing bits of info without names and classifying them according to retrieval is already implemented in a crude form in the "find" utility. We can search for a document containing a text string, created on a date, of a size. It's limited, for certain, but the idea of data without names is not as foreign as some of you have suggested. It's just clumsy and slow, as we become with age and poor mental conditioning.
The idea of storing 100 papers with numeric titles in a directory together and retrieving them by a find search is not entirely unfeasible. The retrieval of a picture out of 100 basically untitled images, however, is different. A picture may be worth a thousand words, but not to this particular Compaq.