Encryption is worthless if you don't know who you're connected to. If you're on a wireless link, those guys who can so easily snoop your traffic can also hijack your connections and launch MITM attacks. Trust is more important in untrusted networks, not less as you imply.
Eric was never forthcoming about what he did to break the system, which is no surprise because it was clearly an idiot thing to do.
If he had a problem with a repository, it's because he was trying to use a repository that wasn't compatible with Fedora. libcom_err was and is part of e2fsprogs-libs.
Absent any better proof than is available, I'll maintain that rpm is not at fault, and neither is Red Hat or Fedora. Eric was doing something stupid, and he ignored the system's warning that he was going to break the system. When he broke it, it was *his* fault, and his alone.
rpm packages can do that, too, by "providing" a capability. The most common example I can think of is sendmail, which provides "server(smtp)", which any other package can require. Postfix also provides "server(smtp)", as does Courier.
And didn't some big Linux fan make a switch away from RedHat because of RPM issues?
That was ESR. He forced rpm to remove a package, even though rpm warned him that other packages needed it in order to function. Surprise of surprises, his system stopped working just like he was told that it would.
It was in no way rpm's fault that his system broke. ESR thought he knew better than rpm, and he was wrong.
I've used both, and for what little it's worth, I disagree.
For one thing, with yum I don't need to know what package name I want to install. I can "yum install certtool", and it will determine that certtool is provided by gnutls-utils and install that package. IIRC, apt-get can't do that.
I can also ask yum to install a package that's in the local filesystem, along with whatever it requires. apt-get can't do that, either.
Half of the docs that I've seen indicate that debs should be built by hand, and then the results should be packaged. I don't know what the deal is there, but rpm has always used the "spec" file to build and package software, which is a more repeatable process. Deb has "rules" now. If they were always there, I'd like to be corrected on that point. The fact that there is documentation for other processes suggests to me that the deb build process has been much worse than rpm's.
Beyond all of that, Fedora is building some really nice tools on top of rpm for automated rebuilds and packaging. Basically, all of the tools that they use to manage the distribution are open source, which makes it much easier for someone else (like Intel) to build a distribution based on Fedora's tools.
I know that Ubuntu attracts a lot of users, but I can definitely see why developers would prefer to use Fedora's tools as a base.
why does the U.S. Constitution apply to foreign nationals captured and held in places that are not the U.S.?
The Constitution describes and limits the powers of the US Government in this case, not foreign nationals. If the government chooses to imprison a person, it must charge that person with a crime and prove their guilt in court. No law gives the government the power to imprison people indefinitely without cause.
but not the right to vote in U.S. elections (yet), to bear arms, or the responsibility to pay U.S. income taxes
What the hell are you talking about? The law states specific requirements for voting, carrying a concealed weapon, and paying taxes. It does not state specific requirements to be eligible for a trial.
will Al Qaeda reciprocate?
Until the imprisoned have a trial, you have no reason to believe that they are or ever have been associated with al Qaeda. I understand if you have a difficult time being objective about this. People should be angry at terrorist attacks. At the same time, you have to be able to think rationally and realize that if these people are guilty, then we should be able to demonstrate that in court first and lock them away afterward. It's a straightforward process that protects innocent people from being detained by mistake. Why would you not want to protect the innocent?
how do you fight a war under rules that were designed for domestic law enforcement?
What makes you think that the imprisoned persons at Guantanamo were captured in war? Many of them were apparently captured by the Northern Alliance in Afghanistan. We paid them for the prisoners. Doesn't that strike you as a situation with a tremendous potential for abuse? Don't you think that we should review the evidence that those prisoners were actually combatants to avoid imprisoning the ones that weren't?
Adblock plus deprecated filterset.g. That filterset caused too many problems for users, so adblock plus introduced new subscriptions that cause fewer problems and don't require additional components.
I'd much rather have volume or block level snapshots... All that without tying you to a single file system
It is not possible to make consistent block-level snapshots without filesystem support. If your filesystem doesn't support snapshotting, it must be remounted read-only in order to take a consistent snapshot. This is true for all filesystems. When they are mounted read-write, there may be changes that are only partially written to disk, and creating a snapshot will save the filesystem in an inconsistent state. If you want to mount that filesystem, you'll need to repair it first.
He's also one of the people behind rpmforge, which tries to make a unified repo of 3rd party add-on packages. Previously there were a number of incompatible (dependencies and so forth) repositories like atrpms. Dag's work benefits all of us who use RHEL on a regular basis.
You forgot to mention that the whole reason that there is an rpmforge is that Dag and co. refuse to operate under EPEL / Fedora's rule: Don't introduce packages that are already in the main repository. As a result, Dag's archive and rpmforge will conflict with the base distribution or EPEL on some packages. Once in a while, I'll grab a spec from Dag and rebuild packages for RHEL/CentOS, but as a matter of policy I don't allow rpmforge repositories to be added to any of my systems. His work does make my life easier. Technically. From time to time. However, suggesting that there are no longer incompatible repositories gives him too much credit, I think.
The release notes for 8.3 mentioned that both Bucardo and Slony-I replication packages are included. Both of those are also usable on releases older than 8.3.
AFAIK, most crashes for motorcycles are single vehicle crashes.
Not according to the best data that we have available. Again, the first item in the Hurt Report's summary indicates that 75% of all motorcycle accidents involve collision with another vehicle, usually a passenger vehicle.
And the most represented motorcycle type in single vehicle crashes is the sport bike.
I don't know if that's intended to be anecdotal evidence, or if you have a source for that. I believe that it may be true, and it's been true in the accidents that I've seen, but I don't have a scientific source on which to found a conclusion.
As for your cycling experiences, you have all of my sympathy. Some drivers are fucking jerks.
That link isn't a scientific study, and should not be used as the foundation for broad generalizations. Furthermore, it doesn't even support your assertion. It does say that the median age of riders has risen significantly, but does not discuss the relative rates of accidents among younger and older groups.
The fact is that the best data available today still comes from the Hurt Report (rimary author, Dr. Harry Hurt), even though the study was written in 1981. Just in the last couple of months, the federal government and the AMA have jointly funded a new study intended to update those conclusions.
The summary of the Hurt Report can be found online, but I think that a couple of these conclusions are relevant here:
22. The motorcycle riders involved in accidents are essentially without training; 92% were self-taught or learned from family or friends. Motorcycle rider training experience reduces accident involvement and is related to reduced injuries in the event of accidents.
19. Motorcycle riders between the ages of 16 and 24 are significantly overrepresented in accidents; motorcycle riders between the ages of 30 and 50 are significantly underrepresented. Although the majority of the accident-involved motorcycle riders are male (96%), the female motorcycles riders are significantly overrepresented in the accident data.
23. More than half of the accident-involved motorcycle riders had less than 5 months experience on the accident motorcycle, although the total street riding experience was almost 3 years. Motorcycle riders with dirt bike experience are significantly underrepresented in the accident data.
32. Motorcycles equipped with fairings and windshields are underrepresented in accidents, most likely because of the contribution to conspicuity and the association with more experienced and trained riders.
19 and 32, especially, point to the conclusion that the "older guy on a Harley" is most definitely not more likely to suffer an accident. Younger riders are much more likely to be involved in accidents, as are less experienced riders of any age.
With that said, the thing that I think is most important is founded on these two conclusions:
1. Approximately three-fourths of these motorcycle accidents involved collision with another vehicle, which was most usually a passenger automobile.
6. In the multiple vehicle accidents, the driver of the other vehicle violated the motorcycle right-of-way and caused the accident in two-thirds of those accidents.
According to the Hurt Report, 50% of all motorcycle accidents are caused by another driver violating the motorcycle's right-of-way. More experienced and better educated riders know this. They know that their age and experience will not remove the threat that they face from other drivers on the road, which is the single biggest threat to their safety. They can only mitigate that threat by constant guard against those violations at the places that they are most likely, and development of countersteering, swerving, and braking skills.
If we take operating system for example, ther's one big glaringly obvious idea that has been much talked about but never fully implemented system-wide - the idea of a virtual file system that would replace the file/folder metaphor with something resembling the filing system of email clients, with virtual folders, tags, etc.
If people worked on that idea as much as they talk about it, it would either be available now, or those people would discover that the idea is impractical in practice and work on something else. Since that is not currently available, the logical conclusion is that it isn't practical.
Hierarchical data storage solves a lot of problems that become extremely hard when you flatten a filesystem. Consider a filesystem with named entries. Now consider that every user sharing such a filesystem will have entries with the same name. How do you prevent one user from stomping on another user's files? You could mandate labels, but then you need a security infrastructure that prevents one user from adding labels to his files which would place them in another user's view (if I can replace your ssh data with some of my own, that's a serious problem). You could create namespaces, but in the end you're just reinventing directories. No alternate name would magically provide you with benefits that hierarchical storage does not. The current implementation remains in use because it provides a better security model than the alternatives that have been explored, and it's easier to understand.
Object in a computer - single emails, files, whatever - should act the same.
There's no reason that they can't. Some email applications use Maildir storage, which places each message in an individual file. If someone thought it was useful to write an application that viewed email and images and text documents and web pages all in one view, they could. You don't have to change the operating system to support that. That is one of the strengths of operating systems as they stand: they're simple enough to layer different an innovative applications on top of them, without drastic changes to their internals.
Yes, support lifetime on Fedora is short, but I think most users see Fedora, RHEL, and CentOS as a family of distributions in much the same way that Ubuntu/Kubuntu/Xubuntu are the same family. If long term support is a requirement, RHEL and CentOS have a seven-year support cycle.
I stick with Fedora for some reasons that are pragmatic: I think its tools are great. There are political reasons, too. I like that Fedora is purely Free Software. Not just the software in the distribution, but the software used to build and release the distribution, too. Those are the Fedora Project's priorities, and they're mine too.
Slashdot Mirror
'This ignores the value of simple encryption.'
Encryption is worthless if you don't know who you're connected to. If you're on a wireless link, those guys who can so easily snoop your traffic can also hijack your connections and launch MITM attacks. Trust is more important in untrusted networks, not less as you imply.
On the internet, no one can tell that you're a VIA Nano!
Thanks, I'll try to remember that.
Still seems like it's easier with 'yum', though.
https://www.redhat.com/archives/fedora-devel-list/2007-February/msg01082.html
Eric was never forthcoming about what he did to break the system, which is no surprise because it was clearly an idiot thing to do.
If he had a problem with a repository, it's because he was trying to use a repository that wasn't compatible with Fedora. libcom_err was and is part of e2fsprogs-libs.
Absent any better proof than is available, I'll maintain that rpm is not at fault, and neither is Red Hat or Fedora. Eric was doing something stupid, and he ignored the system's warning that he was going to break the system. When he broke it, it was *his* fault, and his alone.
rpm packages can do that, too, by "providing" a capability. The most common example I can think of is sendmail, which provides "server(smtp)", which any other package can require. Postfix also provides "server(smtp)", as does Courier.
DEB in most ways is superior. (Note: Not trying to start a flame war, but merely stating facts)
If you want to state the "facts", try detailing something that the dpkg tools do, which rpm tools do not. Otherwise, you're just flaming.
And didn't some big Linux fan make a switch away from RedHat because of RPM issues?
That was ESR. He forced rpm to remove a package, even though rpm warned him that other packages needed it in order to function. Surprise of surprises, his system stopped working just like he was told that it would.
It was in no way rpm's fault that his system broke. ESR thought he knew better than rpm, and he was wrong.
I've used both, and for what little it's worth, I disagree.
For one thing, with yum I don't need to know what package name I want to install. I can "yum install certtool", and it will determine that certtool is provided by gnutls-utils and install that package. IIRC, apt-get can't do that.
I can also ask yum to install a package that's in the local filesystem, along with whatever it requires. apt-get can't do that, either.
Half of the docs that I've seen indicate that debs should be built by hand, and then the results should be packaged. I don't know what the deal is there, but rpm has always used the "spec" file to build and package software, which is a more repeatable process. Deb has "rules" now. If they were always there, I'd like to be corrected on that point. The fact that there is documentation for other processes suggests to me that the deb build process has been much worse than rpm's.
Beyond all of that, Fedora is building some really nice tools on top of rpm for automated rebuilds and packaging. Basically, all of the tools that they use to manage the distribution are open source, which makes it much easier for someone else (like Intel) to build a distribution based on Fedora's tools.
I know that Ubuntu attracts a lot of users, but I can definitely see why developers would prefer to use Fedora's tools as a base.
Maybe it's why your rulers didn't see fit to give you that right.
Rights aren't granted by government, they're taken away. Rights exist in the absence of government.
Which is to say that "his rulers" saw fit to strip their citizens of that right.
why does the U.S. Constitution apply to foreign nationals captured and held in places that are not the U.S.?
The Constitution describes and limits the powers of the US Government in this case, not foreign nationals. If the government chooses to imprison a person, it must charge that person with a crime and prove their guilt in court. No law gives the government the power to imprison people indefinitely without cause.
but not the right to vote in U.S. elections (yet), to bear arms, or the responsibility to pay U.S. income taxes
What the hell are you talking about? The law states specific requirements for voting, carrying a concealed weapon, and paying taxes. It does not state specific requirements to be eligible for a trial.
will Al Qaeda reciprocate?
Until the imprisoned have a trial, you have no reason to believe that they are or ever have been associated with al Qaeda. I understand if you have a difficult time being objective about this. People should be angry at terrorist attacks. At the same time, you have to be able to think rationally and realize that if these people are guilty, then we should be able to demonstrate that in court first and lock them away afterward. It's a straightforward process that protects innocent people from being detained by mistake. Why would you not want to protect the innocent?
how do you fight a war under rules that were designed for domestic law enforcement?
What makes you think that the imprisoned persons at Guantanamo were captured in war? Many of them were apparently captured by the Northern Alliance in Afghanistan. We paid them for the prisoners. Doesn't that strike you as a situation with a tremendous potential for abuse? Don't you think that we should review the evidence that those prisoners were actually combatants to avoid imprisoning the ones that weren't?
Jokes about murder aren't funny. What's wrong with you?
Adblock plus deprecated filterset.g. That filterset caused too many problems for users, so adblock plus introduced new subscriptions that cause fewer problems and don't require additional components.
http://adblockplus.org/en/faq_project#filterset.g
In short: don't use filterset.g. Use Adblock Plus.
I'd much rather have volume or block level snapshots ... All that without tying you to a single file system
It is not possible to make consistent block-level snapshots without filesystem support. If your filesystem doesn't support snapshotting, it must be remounted read-only in order to take a consistent snapshot. This is true for all filesystems. When they are mounted read-write, there may be changes that are only partially written to disk, and creating a snapshot will save the filesystem in an inconsistent state. If you want to mount that filesystem, you'll need to repair it first.
Link works for me. What error are you getting?
I'm sure it's just me.
It's not just you. Python exposes the locking mechanisms of the underlying platform and doesn't try to abstract any further than that.
If you want simple, portable locking, use this recipe from ASPN:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65203
He's also one of the people behind rpmforge, which tries to make a unified repo of 3rd party add-on packages. Previously there were a number of incompatible (dependencies and so forth) repositories like atrpms. Dag's work benefits all of us who use RHEL on a regular basis.
You forgot to mention that the whole reason that there is an rpmforge is that Dag and co. refuse to operate under EPEL / Fedora's rule: Don't introduce packages that are already in the main repository. As a result, Dag's archive and rpmforge will conflict with the base distribution or EPEL on some packages. Once in a while, I'll grab a spec from Dag and rebuild packages for RHEL/CentOS, but as a matter of policy I don't allow rpmforge repositories to be added to any of my systems. His work does make my life easier. Technically. From time to time. However, suggesting that there are no longer incompatible repositories gives him too much credit, I think.
While no plans have been announced, I've heard that basing EL 6 on Fedora 9 or even 10 is unlikely. Look for EL 6 to be based on Fedora 11 or 12.
It looks EL 5 will be enjoying a very long lifetime as the platform of choice for EL shops. I'm happy with that.
I think the point was that if the Debian maintainer had submitted his patch upstream, he'd have been told exactly how stupid it was.
The release notes for 8.3 mentioned that both Bucardo and Slony-I replication packages are included. Both of those are also usable on releases older than 8.3.
http://www.postgresql.org/about/press/features83.html
Or you can set up a launcher that executes:
...and skip the ridiculous shell script entirely.
"env LANG=en_US.UTF-8 pidgin"
Won't someone mod the AC up?
AFAIK, most crashes for motorcycles are single vehicle crashes.
Not according to the best data that we have available. Again, the first item in the Hurt Report's summary indicates that 75% of all motorcycle accidents involve collision with another vehicle, usually a passenger vehicle.
And the most represented motorcycle type in single vehicle crashes is the sport bike.
I don't know if that's intended to be anecdotal evidence, or if you have a source for that. I believe that it may be true, and it's been true in the accidents that I've seen, but I don't have a scientific source on which to found a conclusion.
As for your cycling experiences, you have all of my sympathy. Some drivers are fucking jerks.
That link isn't a scientific study, and should not be used as the foundation for broad generalizations. Furthermore, it doesn't even support your assertion. It does say that the median age of riders has risen significantly, but does not discuss the relative rates of accidents among younger and older groups.
;)
The fact is that the best data available today still comes from the Hurt Report (rimary author, Dr. Harry Hurt), even though the study was written in 1981. Just in the last couple of months, the federal government and the AMA have jointly funded a new study intended to update those conclusions.
The summary of the Hurt Report can be found online, but I think that a couple of these conclusions are relevant here:
22. The motorcycle riders involved in accidents are essentially without training; 92% were self-taught or learned from family or friends. Motorcycle rider training experience reduces accident involvement and is related to reduced injuries in the event of accidents.
19. Motorcycle riders between the ages of 16 and 24 are significantly overrepresented in accidents; motorcycle riders between the ages of 30 and 50 are significantly underrepresented. Although the majority of the accident-involved motorcycle riders are male (96%), the female motorcycles riders are significantly overrepresented in the accident data.
23. More than half of the accident-involved motorcycle riders had less than 5 months experience on the accident motorcycle, although the total street riding experience was almost 3 years. Motorcycle riders with dirt bike experience are significantly underrepresented in the accident data.
32. Motorcycles equipped with fairings and windshields are underrepresented in accidents, most likely because of the contribution to conspicuity and the association with more experienced and trained riders.
19 and 32, especially, point to the conclusion that the "older guy on a Harley" is most definitely not more likely to suffer an accident. Younger riders are much more likely to be involved in accidents, as are less experienced riders of any age.
With that said, the thing that I think is most important is founded on these two conclusions:
1. Approximately three-fourths of these motorcycle accidents involved collision with another vehicle, which was most usually a passenger automobile.
6. In the multiple vehicle accidents, the driver of the other vehicle violated the motorcycle right-of-way and caused the accident in two-thirds of those accidents.
According to the Hurt Report, 50% of all motorcycle accidents are caused by another driver violating the motorcycle's right-of-way. More experienced and better educated riders know this. They know that their age and experience will not remove the threat that they face from other drivers on the road, which is the single biggest threat to their safety. They can only mitigate that threat by constant guard against those violations at the places that they are most likely, and development of countersteering, swerving, and braking skills.
I am a motorcyclist.
Probably a young one.
If we take operating system for example, ther's one big glaringly obvious idea that has been much talked about but never fully implemented system-wide - the idea of a virtual file system that would replace the file/folder metaphor with something resembling the filing system of email clients, with virtual folders, tags, etc.
If people worked on that idea as much as they talk about it, it would either be available now, or those people would discover that the idea is impractical in practice and work on something else. Since that is not currently available, the logical conclusion is that it isn't practical.
Hierarchical data storage solves a lot of problems that become extremely hard when you flatten a filesystem. Consider a filesystem with named entries. Now consider that every user sharing such a filesystem will have entries with the same name. How do you prevent one user from stomping on another user's files? You could mandate labels, but then you need a security infrastructure that prevents one user from adding labels to his files which would place them in another user's view (if I can replace your ssh data with some of my own, that's a serious problem). You could create namespaces, but in the end you're just reinventing directories. No alternate name would magically provide you with benefits that hierarchical storage does not. The current implementation remains in use because it provides a better security model than the alternatives that have been explored, and it's easier to understand.
Object in a computer - single emails, files, whatever - should act the same.
There's no reason that they can't. Some email applications use Maildir storage, which places each message in an individual file. If someone thought it was useful to write an application that viewed email and images and text documents and web pages all in one view, they could. You don't have to change the operating system to support that. That is one of the strengths of operating systems as they stand: they're simple enough to layer different an innovative applications on top of them, without drastic changes to their internals.
Yes, support lifetime on Fedora is short, but I think most users see Fedora, RHEL, and CentOS as a family of distributions in much the same way that Ubuntu/Kubuntu/Xubuntu are the same family. If long term support is a requirement, RHEL and CentOS have a seven-year support cycle.
I stick with Fedora for some reasons that are pragmatic: I think its tools are great. There are political reasons, too. I like that Fedora is purely Free Software. Not just the software in the distribution, but the software used to build and release the distribution, too. Those are the Fedora Project's priorities, and they're mine too.