I'm glad I waited and didn't return a sarcastic comment about how useful your first comment was as a bug report...;-) Thanks for this comment; it makes it pretty clear what happened.
I'm guessing that the first time, you ended up installing modules in the same directory (/lib/modules/2.2.12-20/) as the existing modules, but that you left some old modules in place because you did not rebuild them with your new configuration. Your changed configuration changed some signature information, so you ended up with a mix of inconsistent modules. When you downloaded a kernel tarball, you moved to a unique directory (/lib/modules/2.2.12/, I presume) which did not have old modules in it and so you did not have the same problem.
Now that you have provided a good report, I'd like to reiterate that this is not new to Red Hat Linux 6.1 -- it's just the first time that this particular gotcha, well, gotcha.
So this is clearly not a bug. I'd like to take a moment, however, to point you and everyone else reading this thread to our Bugzilla bug tracking database. If you use it to report bugs, we can do a much better job of keeping track of things and letting you know if/when we are able to fix the bug. Even when it turns out to be a feature rather than a bug, it's there for the next person who searches the bug database for the problem they are having. Which, of course, brings me to another point: before entering your bug, use bugzilla's search facilities to see if someone else has already reported a similar problem.
PPPoE allows the ISP to require a password to grant access, unlike a plain DHCP-negotiated network connection.
I don't expect metered bandwith to be much of an issue in the US in the near future (even for phone links they try to get as close to flat rate as they can and still stay in business as consumers here prefer it) and the scuttlebutt I've heard does not indicate that metered usage is the reason that north american ISPs are considering PPPoE.
That's not reliable by any means, just vague rumor. Make of it what you will.:-)
Actually, we do use DDC to query the monitor, and we do use extended refresh rate ranges when the monitor supports them. However, many monitors do not. sigh...
We have not changed the procedure for booting custom kernels. Unresolved kernel symbol errors are typical of forgetting to build/install kernel modules when you build a kernel.
We experimented with higher refresh rates, and thus reduced the number of working monitors in our test lab by one. While 60Hz hurts (no pun intended) your eyes, it should not kill even older fixed-pitch monitors.
Fortunately, you do have the option of text-mode installation. When you boot the install disk, read the text that shows up -- it tells you to type "text" if you want a text-mode install. While graphical mode is naturally the default, text mode is faster for those of us who know the procedure and prefer typing to mousing. Take your pick!
Most cable modems today are just ethernet, just like most xDSL connections. That's likely to change over time; ISPs like the authentication capabilities of PPPoE (PPP over Ethernet, RFC 2516 and are likely to switch over time.
This is on-topic inasmuch as it relates to the future ability of Linux users to use cable modem and similar (xDSL) services...
Re:Christian Hackers? Let your light shine!
on
Jesux is a Bad Pun
·
· Score: 2
Yeah, I think there are quite a few of us. I've been nearly -- but not quite -- surprised by the numbers of Christian hackers I've met. And some of the venerated members of the CS community are Christians as well, including one of the true originals in the free software movement, Donald Knuth. How about Fred Brooks -- anyone who reads The Mythical Man Month can tell what his beliefs are. Larry Wall. The list goes on and on of Christians whose faith, as a natural part of their lives, mixes artlessly with their good and worthwhile work in the CS world...
I agree that being a follower of Christ and a developer and proponent of free software are more than compatible. I think that my overwhelming desire to work with free software is a vocation that God gave me as a gift the same way he gives other vocations, whether they look secular or religious.
I think there's a strong moral (Christian or not) element to free software. I see that it creates software that frees people from certain external manipulation. Proprietary, closed-source software locks people in. That is not a value judgement against anyone who makes proprietary software, only those who use their position to manipulate the people who use their software. I think that manipulative ones are a small minority, honestly. But I like the fact that it's harder to manipulate software users with free software; it's one of the things that makes me love my job. And if I help people taste freedom, I hope to give them a glimpse of Christ, the ultimate author of freedom.
...and you shall know the truth, and the truth shall set you free.
Yes, it has been OK to import strong encryption. I suppose that if it is a munition, then it falls under our right to keep and bear arms...:-)
Seriously, this has always been confusing to people. You have been able to import an encryption product into the US from country B, and then not export the exact same encryption product back to country B.
Taking down non-essential machines leaves more backup power juice (generic technical term for batteries and gasoline;-) for the essential machines. And there's no guarantee that we'll have an internet connection, let alone sufficient juice, for the duration of the storm. That's why we have distributed important services like ftp and web service.
Electricity in these parts is not highly reliable; our UPSs seem to scream in protest about once a week, and every few months someone drives into a power pole and, whoops, there goes the power for an hour or three... There are few buried power lines except for the last distribution stage, so the whole infrastructure is extremely fragile. This situtation took me by surprise when I moved to NC from the midwest (MN and WI), where nearly all the power is buried and a power loss is something to write home about.
Time to go kick myself again for not buying a generator for home when they were relatively cheap. Maybe they'll be cheap again after Y2K fizzles.:-)
Fiscally centrist (If people wish to eat, they should work -- but if they are willing to work, they should be able to eat...)
Socially centrist (society has never amounted to much, and can't be fixed, but if we don't try to improve it, we'll get worse; like Alice, we must run as hard as we can to stand still).
I think that the other poster who pointed out that geeks are sensitive to and abhor hypocrisy, combined with the near moral irrelevance of many of the modern churches, is right on the money. Very few geeks have been personally offensive to me about my belief in Jesus; the few that have were only trying to be offensive to Christians in general and probably didn't yet know that I am a Christian...
I lay a good bit of the burden for the stereotype on geeks themselves. Geeks are no different from other people in needing attention, and folks tend to exagerate their differences from others in order to garner attention. I've met many geeks who are nearly completely unwilling to admit to being relatively normal, despite the fact that they are right in the middle of most bell curves describing their peer groups, the nation, and probably the world.
Also, are geeks really different from the rest of the world in that their stereotypes often do not fit? Aren't stereotypes prototypically, well, stereotypical?:-)
In fact, once Red Hat Linux 6.0 is released, RawHide will be even more useful that it has been in the past. Folks running Red Hat Linux 5.2 have had to recompile source rpms from RawHide in order to run them on their 5.2 systems because RawHide is glibc-2.1-based and 5.2 is glibc-2.0-based. With Red Hat Linux 6.0 based on glibc-2.1 and RawHide based on the same, folks running Red Hat Linux 6.0 will be able to download and use RawHide binary rpms without recompiling unless they want to.
This is not official word, since I'm not an officer of Red Hat Software. That said, almost everything I say here, Red Hat Software has said officially in several contexts, and regular/. readers will see little new here. I'm not sure that this statement is needed, frankly; the majority of the comments I have seen so far are right on the money.
Red Hat Software is supporting the LSB project both practically, by participation, and philosophically, by agreeing that the LSB is a good idea and expressing our expectation that it will produce a useful and workable standard).
By now, most/. readers will have heard Red Hat Software's general policy, rarely broken, of not preannouncing software releases. We stick to this policy for many reasons, but two really good reasons are our absolute disgust for vaporware and murphy's law. Things will go wrong and change our delivery dates from time to time. That does not keep us from working on software, obviously -- it just keeps us from preannouncing.
The same is true for our support of the LSB. We will not preannounce that we will make Red Hat Linux LSB-compliant when the LSB does not exist. That does not keep us from expressing our expectation (it's stronger than simple hope) that the LSB will be a good standard that we will want to implement because it will make our users' lives (and our own work) simpler and easier. We contribute publically to the effort to build the LSB standard, reserving our judgment for the completed standard.
To the folks who think that Red Hat Software is trying to corner the market in black helicopters, I'll only say that a good enough LSB standard would be very good for all of Linux, abolutely and most definitely including Red Hat Software. But if you think that Red Hat has bought the black helicopters, you aren't going to believe a word I say anyway.;-)
I'm guessing that the first time, you ended up installing modules in the same directory (/lib/modules/2.2.12-20/) as the existing modules, but that you left some old modules in place because you did not rebuild them with your new configuration. Your changed configuration changed some signature information, so you ended up with a mix of inconsistent modules. When you downloaded a kernel tarball, you moved to a unique directory (/lib/modules/2.2.12/, I presume) which did not have old modules in it and so you did not have the same problem.
Now that you have provided a good report, I'd like to reiterate that this is not new to Red Hat Linux 6.1 -- it's just the first time that this particular gotcha, well, gotcha.
So this is clearly not a bug. I'd like to take a moment, however, to point you and everyone else reading this thread to our Bugzilla bug tracking database. If you use it to report bugs, we can do a much better job of keeping track of things and letting you know if/when we are able to fix the bug. Even when it turns out to be a feature rather than a bug, it's there for the next person who searches the bug database for the problem they are having. Which, of course, brings me to another point: before entering your bug, use bugzilla's search facilities to see if someone else has already reported a similar problem.
I don't expect metered bandwith to be much of an issue in the US in the near future (even for phone links they try to get as close to flat rate as they can and still stay in business as consumers here prefer it) and the scuttlebutt I've heard does not indicate that metered usage is the reason that north american ISPs are considering PPPoE.
That's not reliable by any means, just vague rumor. Make of it what you will. :-)
Actually, we do use DDC to query the monitor, and we do use extended refresh rate ranges when the monitor supports them. However, many monitors do not. sigh...
We have not changed the procedure for booting custom kernels. Unresolved kernel symbol errors are typical of forgetting to build/install kernel modules when you build a kernel.
We experimented with higher refresh rates, and thus reduced the number of working monitors in our test lab by one. While 60Hz hurts (no pun intended) your eyes, it should not kill even older fixed-pitch monitors.
Fortunately, you do have the option of text-mode installation. When you boot the install disk, read the text that shows up -- it tells you to type "text" if you want a text-mode install. While graphical mode is naturally the default, text mode is faster for those of us who know the procedure and prefer typing to mousing. Take your pick!
Fortunately, Linux support for PPPoE is coming along -- there is a beta-test version of a user-space "redirector" that provides PPPoE support for Linux 2.2.x, and in-kernel support is being written for 2.{3,4}.x; while it may well not be added to Linus's standard kernel, it should not be hard to add.
This is on-topic inasmuch as it relates to the future ability of Linux users to use cable modem and similar (xDSL) services...
I agree that being a follower of Christ and a developer and proponent of free software are more than compatible. I think that my overwhelming desire to work with free software is a vocation that God gave me as a gift the same way he gives other vocations, whether they look secular or religious.
I think there's a strong moral (Christian or not) element to free software. I see that it creates software that frees people from certain external manipulation. Proprietary, closed-source software locks people in. That is not a value judgement against anyone who makes proprietary software, only those who use their position to manipulate the people who use their software. I think that manipulative ones are a small minority, honestly. But I like the fact that it's harder to manipulate software users with free software; it's one of the things that makes me love my job. And if I help people taste freedom, I hope to give them a glimpse of Christ, the ultimate author of freedom.
Seriously, this has always been confusing to people. You have been able to import an encryption product into the US from country B, and then not export the exact same encryption product back to country B.
Electricity in these parts is not highly reliable; our UPSs seem to scream in protest about once a week, and every few months someone drives into a power pole and, whoops, there goes the power for an hour or three... There are few buried power lines except for the last distribution stage, so the whole infrastructure is extremely fragile. This situtation took me by surprise when I moved to NC from the midwest (MN and WI), where nearly all the power is buried and a power loss is something to write home about.
Time to go kick myself again for not buying a generator for home when they were relatively cheap. Maybe they'll be cheap again after Y2K fizzles. :-)
I think that the other poster who pointed out that geeks are sensitive to and abhor hypocrisy, combined with the near moral irrelevance of many of the modern churches, is right on the money. Very few geeks have been personally offensive to me about my belief in Jesus; the few that have were only trying to be offensive to Christians in general and probably didn't yet know that I am a Christian...
I lay a good bit of the burden for the stereotype on geeks themselves. Geeks are no different from other people in needing attention, and folks tend to exagerate their differences from others in order to garner attention. I've met many geeks who are nearly completely unwilling to admit to being relatively normal, despite the fact that they are right in the middle of most bell curves describing their peer groups, the nation, and probably the world.
Also, are geeks really different from the rest of the world in that their stereotypes often do not fit? Aren't stereotypes prototypically, well, stereotypical? :-)
In fact, once Red Hat Linux 6.0 is released, RawHide will be even more useful that it has been in the past. Folks running Red Hat Linux 5.2 have had to recompile source rpms from RawHide in order to run them on their 5.2 systems because RawHide is glibc-2.1-based and 5.2 is glibc-2.0-based. With Red Hat Linux 6.0 based on glibc-2.1 and RawHide based on the same, folks running Red Hat Linux 6.0 will be able to download and use RawHide binary rpms without recompiling unless they want to.
Red Hat Software is supporting the LSB project both practically, by participation, and philosophically, by agreeing that the LSB is a good idea and expressing our expectation that it will produce a useful and workable standard).
By now, most /. readers will have heard Red Hat Software's general policy, rarely broken, of not preannouncing software releases. We stick to this policy for many reasons, but two really good reasons are our absolute disgust for vaporware and murphy's law. Things will go wrong and change our delivery dates from time to time. That does not keep us from working on software, obviously -- it just keeps us from preannouncing.
The same is true for our support of the LSB. We will not preannounce that we will make Red Hat Linux LSB-compliant when the LSB does not exist. That does not keep us from expressing our expectation (it's stronger than simple hope) that the LSB will be a good standard that we will want to implement because it will make our users' lives (and our own work) simpler and easier. We contribute publically to the effort to build the LSB standard, reserving our judgment for the completed standard.
To the folks who think that Red Hat Software is trying to corner the market in black helicopters, I'll only say that a good enough LSB standard would be very good for all of Linux, abolutely and most definitely including Red Hat Software. But if you think that Red Hat has bought the black helicopters, you aren't going to believe a word I say anyway. ;-)