Become informed of the dangers of Dihydrogen Monoxide before it's too late! And please work to save the American Clay Pigeon. Tens of thousands of these delicate creatures (they are fragile as eggs) are blasted by evil hunters every year -- and then left on the ground because they're not even edible. Yet the slaughter continues!
I donut think this is a trivial matter and I donut think that there is a clear resolution of the issue.
Perhaps the officer can release claims to the code in exchange for an employment contract to continue development of useful software for law enforcement focusing on interoperability and information sharing. The office sounds like a smart and resourceful fellow.
That way everybody wins.
I experience a similar bug with Linux kernel 2.6.17, 1.5 GB RAM, nVidia driver 9746. Haven't seen anything useful from the usual sources. Using 800 MB of Ram lessens the problem. Error messages generated just before the freeze always list memory addresses. I'm hoping a driver update will "fix" this and not introduce new bugs.
They will heavily liposuction Shatner and use the fat as the old Kirk, the thin and wrinkled Shatner as Christopher Pike and James Spader as young Kirk. "Yoeman Rand, have you had you bottom soundly spanked today? Come bend over my command chair you naughty, naughty girl and we'll boldly go . .."
Metric is already the official standard of measurement in the USA. While the Government lacks the influence to convert the general population, perhaps Wal-Mart can do it. After all, their products aren't made in any countries that _use_ Imperial measures. I'm sure they have solved the conversion problem and should share that information with Homeland Security.
But then again, Wal-Mart did fail with pushing the gold dollar coin. But for that to have succeeded, the Government needed to stop printing dollar bills. Once Wal-Mart completes their takeover of the Government (they can start with NASA and DHS, um, no need to involve Immigration or the FTC), perhaps coercion of the general population can be the success proponents of metric adoption hope it o be.
I, for one, welcome our new Retail Overloards . . .
Perhaps the recent Microsoft/Novell Linux agreement had an influence?
Re:With much better distro options out there..
on
Fedora Linux
·
· Score: 1
I gave up on Fedora as well. Besides being a pain to "flesh out", it became a pain to write a book on a just-don't-get-it publisher's schedule and I stopped. For me, Mandriva has been a much easier distro to work with. This book sounds like the one I wanted to morph the Fedora Unleashed title to, but that's just me.
This Would Be the End of TiVo Hacking
on
Apple to Buy TiVo?
·
· Score: 1, Insightful
Does anyone really think that Apple would allow the TiVo hacking community to continue to flourish? And I doubt that they would permit "lifetime" service to continue to be available on hacked TiVos; you'ld have to download the inevitable Apple-ed-over TiVo software that would undoubtedly be hacker-unfriendly.
YUM is written in Python as are Fedora's Fedora-centric tools and installer, so that makes sense. Urpmi is written in Perl as are Madrakre's installer and tools, so that makes sense as well. Apt for RPM is still a hack of the code written for.deb's, Synaptic is just a GUI interface for APT like rpmdrake is a GUI interface for urpmi. There are valid reasons for all of them existing. They all have pretty much the same features and do pretty much the same thing.
The important thing is to standardise the server index files so that apt, urpmi, and yum can all access the same software repositories, a boon to non-distro-specific software developers. Then, if the distros can standardise their file directory structures . . . Well, too much to hope for, I suppose with SuSE's unique approach.
These are the package formats. The first three are attempts to improve things over a source code installation by adding advanced scripting, dependency resolution and post-installation management. (There are other obscure packaging formats.) Each one has strengths and weaknesses and features the others lack. Since it's all open source, why can't the best feature be incorporated into all of them? The answer is that initial design considerations preclude easily adding ceratin features (similar the old GTK find file dialog problem).
apt vs. yum vs. urpmi vs. yast
All accomplish about the same thing which is to easily install software packages using dependency resolution. Each was written to scratch a particular itch. apt used for rpms (originall written for.deb packages) is considered kind of a hack, especially the way it eventually installs the packages. yum was written to provide apt-like features, but written in pyhton, like all of Red Hat's tools, so it could more easily integrate into those tools. urpmi is written in perl since Mandrake's tools are written in perl (as is Mandrake's disk partitioning tool, which might be why Red Hat hasn't integrated it into Anaconda). I'm not sure what apt and the package management portion of yast are written in, but the same difficulties might apply to them.
Debian vs. Mandrake vs. RedHat/Fedora & clones vs. SuSe vs. Slackware vs. etc.
While all the distros are Linux, each uses a modified version of the kernel (and glibc?) to tweak it's performace/feature set and show that it's version is superior. That, along with slightly different file locations, variations on a few configuration file names, and differnt vesions of core libraries and utilities just make it more difficult to create "universal" software packages. Getting these distros to eliminate this kind of incompatability is likely impossible because it removes their perceived "competitive advantage" and fails to massage their respective engineers' often siezable egos.
Solving the Problem
There is some work afoot to cooperatively meet on a common hdlist format so that all the versions of the package managers can use a single index file (repositories only need generate a single file to be apt-yum-urpmi-yast-etc compatible. That's a good thing and allows customization of the management tools for particluar needs (like different editors using the same text file formats).
The package incompatability problem could be ameliorated if packagers would statically compile binaries. I know, that uses more "space" and introduces potental security threats, but there are ways to deal with that: cheap and huge hard drives solve one problem and key signing, md5 and similar technologies address the other.
Put Religious Wars and Ego Aside: Work Cooperatively
There's not a need for a single, unified packaging tool or packaging format just like there is no need for a single, unified desktop environment. There are some areas where everyone needs to cooperate more effectively, though.
What sets them apart? 1. The installer application: some are cryptic and text-based; some are graphical and helpful; some require almost no user interaction; all can be daunting to the uninitiated. 2. Kernel patches: Few distros provide a "vanilla" kernel; patches are used to support additional hardware devices; provide functionality not yet present in the vanilla kernel; address quirks of the software engineers; make each distro stand apart. 3. They use different versions of the gcc compiler and C libraries: the version-of the month-club; newer always equals better! 4. Differnet compilation optimizations: low optimizations to make it run on everything; high optimizations to gain bragging rights and performance. 5. Different packaging management:.rpm,.deb,.tgz, or source packages; the end result is an installed application in any case. 6. Different eye candy, modified application defaults, varied application choices; to each his own and nothing you can't eventually do yourself. 7. Different design philosophies, build policies, quality assurance policies, target markets, language and cultural foci, political adgendas, an infinitum. No matter how many ways you cook an egg, it's still an egg. 8. Choice of init process: System V, BSD, or script-based will all get you to the same place in the end.
In the end, they all pretty much accomplish the same tasks. How they go about it (especially administrative tasks) differs, but the basics apply to all distros. Most differences are only as important as the current zealots want to make them, meaning that you can ignore them.
My advice is to try a few of the more poular distros and use the one that installs best (recognizes all you hardware and provides applications you want). Plenty of time - and choices - for later reflection. Above all, have fun.
I became aware of the book when Greene was interviewed on "All Things Considered" a while back. I'm about 1/3 through the book (sadly, I do not have _enough_ time to read for pleasure) and it's enjoyable because the author provides just enough disequilibrium to keep me thinking as I read. So far, the sequence of the presentation has helped me work out my own [limited] understanding of the theories.
Unlike others, I don't however find his humor appealing nor do I find his use of the Simpson's characters anything more than a distraction. Greene uses too many "Let's ignore that for now" escapes in his explanations for my tastes (I know the subject is complex, but he does such a good job explaining things, I expect more from him as I read). As far as using footnotes to move the more obtuse stuff out of the main body of the text, he could look to Alfie Kohn ("Punished By Rewards", an excellent book about how we learn best) as a model for technical footnotes done well for this kind of popular presentation.
Still, it's an excellent and compelling read I would not hesitate to recommend it to anyone with an interest in the subject.
Here I am, Bill, finally getting wireless connectivity on the ship working with Linux.8)
I also appreciate _all_ the comments and I consider all of them when I go to re-edit the book. There are a number of content changes I have planned for Red Hat Linux 10 Unleashed, and all except the inclusion of a section on YUM are driven by reader feedback, like DVD burning and better mutimedia coverage.
Thanks to all those who commented on the book and thanks to the reviewer.
Now, back to the cruise . . .
Hoyt
As the co-author of Red Hat Linux 8.0 Unleashed, I can say that the new edition (due in bookstores soon) has been extensively re-written to make the information more accessible to newer Linux users while trying to adequately address the needs of more seasoned veterans.
I'd be delighted to hear from the Slashdot community as to how well we succeeded, what we did well, and what we can do better next time.
Slashdot Mirror
I donut think this is a trivial matter and I donut think that there is a clear resolution of the issue. Perhaps the officer can release claims to the code in exchange for an employment contract to continue development of useful software for law enforcement focusing on interoperability and information sharing. The office sounds like a smart and resourceful fellow. That way everybody wins.
I experience a similar bug with Linux kernel 2.6.17, 1.5 GB RAM, nVidia driver 9746. Haven't seen anything useful from the usual sources. Using 800 MB of Ram lessens the problem. Error messages generated just before the freeze always list memory addresses. I'm hoping a driver update will "fix" this and not introduce new bugs.
And if you make hackable hardware and _don't_ embrace the hacker community, you can share all the success of the ahref=http://fastolfe.net/2006/iopener/faqrel=url2 html-21081http://fastolfe.net/2006/iopener/faq> I-Opener
They will heavily liposuction Shatner and use the fat as the old Kirk, the thin and wrinkled Shatner as Christopher Pike and James Spader as young Kirk. "Yoeman Rand, have you had you bottom soundly spanked today? Come bend over my command chair you naughty, naughty girl and we'll boldly go . . ."
Metric is already the official standard of measurement in the USA. While the Government lacks the influence to convert the general population, perhaps Wal-Mart can do it. After all, their products aren't made in any countries that _use_ Imperial measures. I'm sure they have solved the conversion problem and should share that information with Homeland Security.
But then again, Wal-Mart did fail with pushing the gold dollar coin. But for that to have succeeded, the Government needed to stop printing dollar bills. Once Wal-Mart completes their takeover of the Government (they can start with NASA and DHS, um, no need to involve Immigration or the FTC), perhaps coercion of the general population can be the success proponents of metric adoption hope it o be.
I, for one, welcome our new Retail Overloards . . .
Before they go, perhaps they could release all their code? That could be fun.
Perhaps the recent Microsoft/Novell Linux agreement had an influence?
I gave up on Fedora as well. Besides being a pain to "flesh out", it became a pain to write a book on a just-don't-get-it publisher's schedule and I stopped. For me, Mandriva has been a much easier distro to work with. This book sounds like the one I wanted to morph the Fedora Unleashed title to, but that's just me.
Does anyone really think that Apple would allow the TiVo hacking community to continue to flourish? And I doubt that they would permit "lifetime" service to continue to be available on hacked TiVos; you'ld have to download the inevitable Apple-ed-over TiVo software that would undoubtedly be hacker-unfriendly.
YUM is written in Python as are Fedora's Fedora-centric tools and installer, so that makes sense. Urpmi is written in Perl as are Madrakre's installer and tools, so that makes sense as well. Apt for RPM is still a hack of the code written for .deb's, Synaptic is just a GUI interface for APT like rpmdrake is a GUI interface for urpmi. There are valid reasons for all of them existing. They all have pretty much the same features and do pretty much the same thing.
The important thing is to standardise the server index files so that apt, urpmi, and yum can all access the same software repositories, a boon to non-distro-specific software developers. Then, if the distros can standardise their file directory structures . . . Well, too much to hope for, I suppose with SuSE's unique approach.
So for the ADD brain, does lying provide the stimulation it seeks?
And how does lying affect levels of seratonin, dopamine, and norepinephrine? Could lying be addictive or reinforcing in this way?
Hmmm . . .
The Cobind Software Manager works well here. It's a little feature-poor at the moment, but that's to be expected.
.rpm vs. .deb vs. .tgz vs. source code
.deb packages) is considered kind of a hack, especially the way it eventually installs the packages. yum was written to provide apt-like features, but written in pyhton, like all of Red Hat's tools, so it could more easily integrate into those tools. urpmi is written in perl since Mandrake's tools are written in perl (as is Mandrake's disk partitioning tool, which might be why Red Hat hasn't integrated it into Anaconda). I'm not sure what apt and the package management portion of yast are written in, but the same difficulties might apply to them.
These are the package formats. The first three are attempts to improve things over a source code installation by adding advanced scripting, dependency resolution and post-installation management. (There are other obscure packaging formats.) Each one has strengths and weaknesses and features the others lack. Since it's all open source, why can't the best feature be incorporated into all of them? The answer is that initial design considerations preclude easily adding ceratin features (similar the old GTK find file dialog problem).
apt vs. yum vs. urpmi vs. yast
All accomplish about the same thing which is to easily install software packages using dependency resolution. Each was written to scratch a particular itch. apt used for rpms (originall written for
Debian vs. Mandrake vs. RedHat/Fedora & clones vs. SuSe vs. Slackware vs. etc.
While all the distros are Linux, each uses a modified version of the kernel (and glibc?) to tweak it's performace/feature set and show that it's version is superior. That, along with slightly different file locations, variations on a few configuration file names, and differnt vesions of core libraries and utilities just make it more difficult to create "universal" software packages. Getting these distros to eliminate this kind of incompatability is likely impossible because it removes their perceived "competitive advantage" and fails to massage their respective engineers' often siezable egos.
Solving the Problem
There is some work afoot to cooperatively meet on a common hdlist format so that all the versions of the package managers can use a single index file (repositories only need generate a single file to be apt-yum-urpmi-yast-etc compatible. That's a good thing and allows customization of the management tools for particluar needs (like different editors using the same text file formats).
The package incompatability problem could be ameliorated if packagers would statically compile binaries. I know, that uses more "space" and introduces potental security threats, but there are ways to deal with that: cheap and huge hard drives solve one problem and key signing, md5 and similar technologies address the other.
Put Religious Wars and Ego Aside: Work Cooperatively
There's not a need for a single, unified packaging tool or packaging format just like there is no need for a single, unified desktop environment. There are some areas where everyone needs to cooperate more effectively, though.
What sets them apart? .rpm, .deb, .tgz, or source packages; the end result is an installed application in any case.
1. The installer application: some are cryptic and text-based; some are graphical and helpful; some require almost no user interaction; all can be daunting to the uninitiated.
2. Kernel patches: Few distros provide a "vanilla" kernel; patches are used to support additional hardware devices; provide functionality not yet present in the vanilla kernel; address quirks of the software engineers; make each distro stand apart.
3. They use different versions of the gcc compiler and C libraries: the version-of the month-club; newer always equals better!
4. Differnet compilation optimizations: low optimizations to make it run on everything; high optimizations to gain bragging rights and performance.
5. Different packaging management:
6. Different eye candy, modified application defaults, varied application choices; to each his own and nothing you can't eventually do yourself.
7. Different design philosophies, build policies, quality assurance policies, target markets, language and cultural foci, political adgendas, an infinitum. No matter how many ways you cook an egg, it's still an egg.
8. Choice of init process: System V, BSD, or script-based will all get you to the same place in the end.
In the end, they all pretty much accomplish the same tasks. How they go about it (especially administrative tasks) differs, but the basics apply to all distros. Most differences are only as important as the current zealots want to make them, meaning that you can ignore them.
My advice is to try a few of the more poular distros and use the one that installs best (recognizes all you hardware and provides applications you want). Plenty of time - and choices - for later reflection. Above all, have fun.
I became aware of the book when Greene was interviewed on "All Things Considered" a while back. I'm about 1/3 through the book (sadly, I do not have _enough_ time to read for pleasure) and it's enjoyable because the author provides just enough disequilibrium to keep me thinking as I read. So far, the sequence of the presentation has helped me work out my own [limited] understanding of the theories. Unlike others, I don't however find his humor appealing nor do I find his use of the Simpson's characters anything more than a distraction. Greene uses too many "Let's ignore that for now" escapes in his explanations for my tastes (I know the subject is complex, but he does such a good job explaining things, I expect more from him as I read). As far as using footnotes to move the more obtuse stuff out of the main body of the text, he could look to Alfie Kohn ("Punished By Rewards", an excellent book about how we learn best) as a model for technical footnotes done well for this kind of popular presentation. Still, it's an excellent and compelling read I would not hesitate to recommend it to anyone with an interest in the subject.
Here I am, Bill, finally getting wireless connectivity on the ship working with Linux.8) I also appreciate _all_ the comments and I consider all of them when I go to re-edit the book. There are a number of content changes I have planned for Red Hat Linux 10 Unleashed, and all except the inclusion of a section on YUM are driven by reader feedback, like DVD burning and better mutimedia coverage. Thanks to all those who commented on the book and thanks to the reviewer. Now, back to the cruise . . . Hoyt
As the co-author of Red Hat Linux 8.0 Unleashed, I can say that the new edition (due in bookstores soon) has been extensively re-written to make the information more accessible to newer Linux users while trying to adequately address the needs of more seasoned veterans.
I'd be delighted to hear from the Slashdot community as to how well we succeeded, what we did well, and what we can do better next time.
Hoyt Duff
.