A really good summary of the new features of the 2.6 kernels is in Dave Jones' the Halloween 2.0 document. It also points out a lot of the common problems people have when migrating from 2.4 to 2.6 and how to work around them, so it's well worth a read.
The problem with ready-made solutions like TiVO is the lack of privacy and the lack of control. I don't want someone out there knowing what I watch, or being able to arbitrarily change the software running in my entertainment system.
I'm building a MythTV-based box to do PVR, watch DVDs, etc. Yes, it winds up being more expensive than running out and buying a commercial PVR. But it offers the same capabilities without giving up control.
(By "I am building" I mean that I have all of the software and supporting hardware installed on my desktop PC, and once I've gotten everything tweaked to my satisfaction I'll get a mini-ITX box and "deploy" it).
Agreed, but as Windows is generally targeted at people who don't do things like read status bar text, I'd go one further and, in addition to your solution, actually have a popup like...
"Security Warning"
"You are about to log in to site www.haxorheaven.com, with the following credentials:
username: microsoft.com password: %blahfafafofo.
Click "OK" to proceed, "Cancel" to return to the previous page.
[OK] [Cancel]"
This would make it Really Obvious when someone is trying to misdirect users.
As project officials reported at the end of today's news conference, Mission Control received a radio signal from Spirit just before 12 noon EST. This simple message from the rover confirms it had received a transmission from Earth, and encourages engineers since it proves that Spirit is still alive and functioning.
So we'll see, this does confirm that at least they can ping it.
My current car just passed 100,000 miles. It's broken down and stranded me twice so far: once, because a cell in the sealed, "maintenance-free" battery died, which due to the amazing engineering of the vehicle, took the alternator with it. No amount of jumpering can get you out of this one. The second time, the belt tensioner gave out and the serpentine belt fell to the floor of the engine compartment. The belt was checked regularly (at every oil change, which I do at about 4000 miles because I live in the Northeast) for wear and proper tensioning. Neither of these failures was due to lack of maintenance on my part, and there was no way for me to catch them before the fact, yet they happened.
The same piece of software that lets people around the world play video games on their cell phones is now letting scientists drive the ultimate remote-controlled car across the surface of Mars.
But yeah, the submission isn't very well formatted, and I really hate it when there's a sea of "informative" links like ones to java.sun.com or cnet.com.
IBM, HP, etc, are already offshoring massive numbers of jobs. This makes their outsourcing business, where they get paid to manage e.g. AT&T's networks, really profitable. But the problem for them is, the small fish are getting away. Small and medium-sized businesses don't really tend to outsource their IT processes, so there's a lost opportunity. If Carly's vision is implemented and IT becomes a generic service, they'll be able to market it at these smaller organizations and really rake in the dough. It's summed up quite well in this passage:
Some day, firms will indeed stop maintaining huge, complex and expensive computer systems that often sit idle and cannot communicate with the computers of suppliers and customers. Instead, they will outsource their computing to specialists (IBM, HP, etc) and pay for it as they use it, just as they now pay for their electricity, gas and water. As with such traditional utilities, the complexity of the supply-systems will be entirely hidden from users.
This way, the "specialists" can offshore the whole thing, pay a bunch of Indian tech slaves peanuts to run it, and charge you a rate that's just low enough to make it seem like a great deal compared to buying your own systems and paying your own people to run them. Hooray for progress.
Yeah except that paper really doesn't do anything more than rail against the current state of affairs. So what if 20 years ago people coming into Bell Labs were used to using 20 different operating systems and now they only use one? That doesn't disprove what I said in any way at all. It's basically just a longer and more eloquent way of saying the exact same thing that the original poster I responded to was saying -- quoting this back to me is really just begging the question.
Look, we already know how to make a protected memory, multitasking operating system that runs on commodity hardware and which, for the average user, provides multitasking performance indistinguishable from running individual tasks on a dedicated machine. We already know how to make a hard real-time operating system (and yes, BeOS shows us that essentially, realtime suitability multiplied by desktop suitability is a constant). We already know that microkernels don't do much more than protect you from badly coded drivers, and at a performance cost. None of these things are a mystery any more, and there just isn't a single-processor operating system model that's going to come along and revolutionize OS design on current hardware.
Multiprocessor OS'es? Yes, as I said there's plenty of room for research there. Come up with an analog processor or some other hardware revolution that we don't currently think about? Yes, that would likely turn commodity OS thinking on its ear. But there is simply no interesting innovation left in the nuts and bolts of operating system software for current commodity hardware - all of the interesting research is either at a lower (hardware) level or at a higher (way more hardware) level.
In terms of fostering new research, the one genuinely interesting statement in that paper is:
Only one GUI has ever been seriously tried, and its best ideas date from the 1970s. (In some ways, it's been getting worse; today the screen is overed with confusing little pictures.) Surely there are other possibilities. (Linux's interface isn't even as good as Windows!)
But look! He's talking about user interfaces there, not the core of the operating system. With all due respect to Robert Pike, all he's doing in this paper is expressing frustration that the good old days are over and people aren't doing fun research any more
This is just my two cents, but if you look at basic system design (device drivers, processing, filesystems, et cetera), there has been very little that is radically new.
That's basically because the problem has been solved, and there's just no need to go reinventing that wheel. The approaches to operating systems, whether for desktops, small embedded systems, etc, are well understood, they are tested and reliable, and there isn't a magical new technique which will meaningfully improve on them. The only real "interesting" research in operating systems that still takes place is in very large systems, managing large numbers of CPUs, etc. And given the nature of military applications, I seriously doubt that those areas of research lack funding.
This is not to say that areas where the user interacts with and configures the operating system don't need work -- giving users an easy way to add and remove device drivers, for example -- but those aren't core operating system concepts, those are user interface issues, and it's important not to confuse the two.
Yep. Go to this site and download the diff for your version of the driver.
You'll need to run the NVIDIA installer with the --extract-only argument to untar it, then cd usr/src/nv and patch -p1 the diff file and then cp Makefile.nvidia Makefile. Then just run make install in the top-level directory of the nvidia installer and it'll build and install a 2.6.1-compatible module.
Excuse me? You mean SCO exectutives aren't dumping SCO stock? It's not exactly an underreported story...
Groupthink and Acceptance
on
What You Can't Say
·
· Score: 2, Insightful
People like belonging to groups, and when they join one they like to tell themselves that their beliefs are closely aligned with their chosen group. And when someone comes along and challenges that group's beliefs, that makes them uncomfortable, and they'd rather suppress the challenging speech than question the group's, and by extension their own, chosen ideals.
In American society, other than threats and slander, you can say anything you want. All of the trollish ideas posters before me have come up as examples of "heresy" are regularly expounded in at least some contexts -- the idea that feminism is runining America is a recurring theme on lots of right-wing talk radio shows, the idea that 9/11 was not caused by Al Quaeda is not uncommon among liberals, etc. You're not going to get thrown in jail or executed for being a vocal follower of Noam Chomsky, either. But expressing those ideas will get you thrown out of the Young Democrats or the Young Republicans respectively.
And that's the real "heresy" any more. People pick a group, or a label, to identify themselves with, and peer pressure makes them fearful enough of opposing ideas that they'll act to suppress them rather than entertain an opposing view and possibly give themselves another choice.
A pretty good illustration of this is available any time on the Internet, just by going to, for example, a site which identifies itself as a "geek news" site and looking at the posts that get moderated down. While some of the down-moderated posts are trolls or obviously inappropriate, a lot of them are simply dissenting opinions that the moderator in question doesn't agree with, but doesn't want to form an argument against for fear of entertaining the dissenting opinion.
We always hear how bad it is to "preach to the choir," but in fact most people are members of a choir and want nothing more than to be preached to.
Businessweek is interesting and everything, but they're not an all-seeing oracle. For example, they wrote glowingly about The New Economy in the 90s and we all know where that went. The "Silent Partner" article makes some glowing statements of its own that aren't necessarily borne out by the facts:
...More important, the economic payoff of off-shoring business processes and a portion of R&D can be so enormous that even reluctant corporations will have little choice but to follow suit to stay competitive. If a major info-tech, insurance, telecom, or banking company doesn't disclose any back-office center in India, Wall Street will soon start asking, "Why not?"
There are other, just as valid points of view that see this hot new offshore oursourcing trend with a more skeptical eye. It's true that globalization is inevitable, and that means there is simply more labor to compete for (at present) fewer jobs. But everything is'nt all wine and roses with offshore outsourcing -- the start-up costs aren't trivial, there are time and cultural differences to overcome, and even when all this is done, sometimes the results are not satisfactory: Dell, for example, recently relocated some call centers back to the US after a raft of complaints about poor service.
If India is really going to be competitive, a lot of things are going to have to be upgraded there -- just an educated labor pool is not enough, you're going to need major infrastructure improvements to sustain these sorts of activities. This isn't free, and over time the cost of relocating labor there is going to go up -- either in terms of problems, or in terms of actual money invested in telecommunications, power, etc.
There's no question that India is going to become a major IT player over time. But let's not make more of this than what it really is.
That's good and well, but having an educated labor force will only get you so far. India has, for the most part, a third-world infrastructure, and if global companies are going to seriously shift a lot of sites there, the roads, power, and communications systems are going to have to be modernized. That's going to cost someone money -- either through private investments, or through taxation. And since global corporations looking for cheap labor don't tend to want to pay for things like power distribution systems, this means the government is going to have to do it, which means increased taxes, which costs are going to rise for everyone, which means the labor force is going to become more expensive over time.
So, yeah, it's a nice cheap ride for now, but eventually the costs of modernization are going to catch up and level the playing field.
LPD-17 class ships (Landing Platform, Dock) are not themselves amphibious, but transport amphibious craft such as LCACs (Landing Craft, Air Cushion) and other vehicles used in amphibious operations.
No, because that machine is not the MX server for its domain. The mail server which actually handles mail for that domain relays mail to avnavfw.pms317.navy.mil and is no doubt allowed to do so by the firewall.
Make bzImage && make modules is no longer the recommended way to do this. You should just do "make" instead, which will build bzImage and any modules you may have asked for, and do it quicker than if you specify the steps separately. See the Halloween 2.5 document for details.
Lots of people test nightly builds of Mozilla; what's so different between Mozilla and the kernel which prevents kernel binaries from being downloadable?
Because there are simply too many variables for a manageable number of binary releases to cover. You have different CPU types -- and not just x86 ones -- to optimize for. Just the x86 ones alone would require half a dozen separate builds or more, without taking into account SMP or lack of SMP.
Then you have build tools. Different versions of the compiler, of binutils, of the module tools, etc, all can expose subtle bugs. And they can introduce incompatibilities -- third-party modules built with one version of gcc won't work with a kernel built with another.
Then you have the way the system is going to be used. If you have a desktop system with lots of RAM and disk space, great, build everything and have at it. But if you're targeting an embedded platform, you may not be able to do that, so you'd want to build a much smaller subset of the kernel, possibly with some core features removed, or a different scheduler than most desktop users would want to use, etc.
Simply put, the cross product of hardware platform, intended use of the system, and development tools, is too large for binary-only releases of test kernels to be a useful test article.
What you're arguing for makes sense at the distribution level. And in fact it's there already: there's never any reason for anyone to compile their own kernel, IF they stick to production kernels. But in a testing environment, there's no way that a manageable number of binary releases is going to cover all of the possibilities.
Granted, you're mostly just trolling, but someone might seriously ask those questions. So:
Why is it necessary for anyone other than a kernel developer to compile the kernel sources?
Because this is still a development kernel. No Linux distribution ships with binaries of this kernel. So if you want to run it, you have to download the source and compile it yourself.
Why would anyone want to do that then? Because this is an open source project, and by running the test kernels, you help expose any lurking bugs so that they can be fixed. Once they're all fixed, the kernel can then be formally released. Distributions will ship with it, and people will then be able to run this kernel without the need to compile it themselves.
Should just anyone do this? No. This kernel isn't yet fit for a production environment. But people with spare machines, or who want to experiment, can do this if they want to contribute.
Why haven't all the optional pieces been broken out into modules yet?
Oh, they have been. Take a look at any of the major distributions. They ship with standard kernels, in which support for pretty much everything that can be modularized, is. That way it's as close as possible to a one-size-fits-all kernel and most users have no need to recompile it. About the only thing that can't be taken into account by this approach is CPU optimization, which is why a lot of distros ship with a set of otherwise identically configured kernels, each optimized for a particular CPU type.
This seems to be yet another in the growing collection of mostly useless 2.6 "migration guides". It doesn't mention any of the common gotchas with configuration, its recommendation for invoking the build process is wrong, etc, etc.
A much better guide is Dave Jones's Post Halloween 2.5 document, which, although very slightly dated, does a much better job explaining how and why things have changed in 2.6 and their impact when upgrading from 2.4.
Slashdot Mirror
A really good summary of the new features of the 2.6 kernels is in Dave Jones' the Halloween 2.0 document. It also points out a lot of the common problems people have when migrating from 2.4 to 2.6 and how to work around them, so it's well worth a read.
The problem with ready-made solutions like TiVO is the lack of privacy and the lack of control. I don't want someone out there knowing what I watch, or being able to arbitrarily change the software running in my entertainment system.
I'm building a MythTV-based box to do PVR, watch DVDs, etc. Yes, it winds up being more expensive than running out and buying a commercial PVR. But it offers the same capabilities without giving up control.
(By "I am building" I mean that I have all of the software and supporting hardware installed on my desktop PC, and once I've gotten everything tweaked to my satisfaction I'll get a mini-ITX box and "deploy" it).
This would make it Really Obvious when someone is trying to misdirect users.
My current car just passed 100,000 miles. It's broken down and stranded me twice so far: once, because a cell in the sealed, "maintenance-free" battery died, which due to the amazing engineering of the vehicle, took the alternator with it. No amount of jumpering can get you out of this one. The second time, the belt tensioner gave out and the serpentine belt fell to the floor of the engine compartment. The belt was checked regularly (at every oil change, which I do at about 4000 miles because I live in the Northeast) for wear and proper tensioning. Neither of these failures was due to lack of maintenance on my part, and there was no way for me to catch them before the fact, yet they happened.
Then again, I don't have a cell phone either.
There is, it's in the last sentence:
The same piece of software that lets people around the world play video games on their cell phones is now letting scientists drive the ultimate remote-controlled car across the surface of Mars.
But yeah, the submission isn't very well formatted, and I really hate it when there's a sea of "informative" links like ones to java.sun.com or cnet.com.
Look, we already know how to make a protected memory, multitasking operating system that runs on commodity hardware and which, for the average user, provides multitasking performance indistinguishable from running individual tasks on a dedicated machine. We already know how to make a hard real-time operating system (and yes, BeOS shows us that essentially, realtime suitability multiplied by desktop suitability is a constant). We already know that microkernels don't do much more than protect you from badly coded drivers, and at a performance cost. None of these things are a mystery any more, and there just isn't a single-processor operating system model that's going to come along and revolutionize OS design on current hardware.
Multiprocessor OS'es? Yes, as I said there's plenty of room for research there. Come up with an analog processor or some other hardware revolution that we don't currently think about? Yes, that would likely turn commodity OS thinking on its ear. But there is simply no interesting innovation left in the nuts and bolts of operating system software for current commodity hardware - all of the interesting research is either at a lower (hardware) level or at a higher (way more hardware) level.
In terms of fostering new research, the one genuinely interesting statement in that paper is:
But look! He's talking about user interfaces there, not the core of the operating system. With all due respect to Robert Pike, all he's doing in this paper is expressing frustration that the good old days are over and people aren't doing fun research any more
This is just my two cents, but if you look at basic system design (device drivers, processing, filesystems, et cetera), there has been very little that is radically new.
That's basically because the problem has been solved, and there's just no need to go reinventing that wheel. The approaches to operating systems, whether for desktops, small embedded systems, etc, are well understood, they are tested and reliable, and there isn't a magical new technique which will meaningfully improve on them. The only real "interesting" research in operating systems that still takes place is in very large systems, managing large numbers of CPUs, etc. And given the nature of military applications, I seriously doubt that those areas of research lack funding.
This is not to say that areas where the user interacts with and configures the operating system don't need work -- giving users an easy way to add and remove device drivers, for example -- but those aren't core operating system concepts, those are user interface issues, and it's important not to confuse the two.
Yep. Go to this site and download the diff for your version of the driver.
You'll need to run the NVIDIA installer with the --extract-only argument to untar it, then cd usr/src/nv and patch -p1 the diff file and then cp Makefile.nvidia Makefile. Then just run make install in the top-level directory of the nvidia installer and it'll build and install a 2.6.1-compatible module.
Excuse me? You mean SCO exectutives aren't dumping SCO stock? It's not exactly an underreported story...
People like belonging to groups, and when they join one they like to tell themselves that their beliefs are closely aligned with their chosen group. And when someone comes along and challenges that group's beliefs, that makes them uncomfortable, and they'd rather suppress the challenging speech than question the group's, and by extension their own, chosen ideals.
In American society, other than threats and slander, you can say anything you want. All of the trollish ideas posters before me have come up as examples of "heresy" are regularly expounded in at least some contexts -- the idea that feminism is runining America is a recurring theme on lots of right-wing talk radio shows, the idea that 9/11 was not caused by Al Quaeda is not uncommon among liberals, etc. You're not going to get thrown in jail or executed for being a vocal follower of Noam Chomsky, either. But expressing those ideas will get you thrown out of the Young Democrats or the Young Republicans respectively.
And that's the real "heresy" any more. People pick a group, or a label, to identify themselves with, and peer pressure makes them fearful enough of opposing ideas that they'll act to suppress them rather than entertain an opposing view and possibly give themselves another choice.
A pretty good illustration of this is available any time on the Internet, just by going to, for example, a site which identifies itself as a "geek news" site and looking at the posts that get moderated down. While some of the down-moderated posts are trolls or obviously inappropriate, a lot of them are simply dissenting opinions that the moderator in question doesn't agree with, but doesn't want to form an argument against for fear of entertaining the dissenting opinion.
We always hear how bad it is to "preach to the choir," but in fact most people are members of a choir and want nothing more than to be preached to.
According to An Earlier Slashdot Article, "Seems that NASA has actually lost the edge in robotic space exploration."
So how can this be?!? It must be more US Lies!
Na-yeen-anajad
Nayeenanajad
Really, it's NOT that hard!
There are other, just as valid points of view that see this hot new offshore oursourcing trend with a more skeptical eye. It's true that globalization is inevitable, and that means there is simply more labor to compete for (at present) fewer jobs. But everything is'nt all wine and roses with offshore outsourcing -- the start-up costs aren't trivial, there are time and cultural differences to overcome, and even when all this is done, sometimes the results are not satisfactory: Dell, for example, recently relocated some call centers back to the US after a raft of complaints about poor service.
If India is really going to be competitive, a lot of things are going to have to be upgraded there -- just an educated labor pool is not enough, you're going to need major infrastructure improvements to sustain these sorts of activities. This isn't free, and over time the cost of relocating labor there is going to go up -- either in terms of problems, or in terms of actual money invested in telecommunications, power, etc.
There's no question that India is going to become a major IT player over time. But let's not make more of this than what it really is.
That's good and well, but having an educated labor force will only get you so far. India has, for the most part, a third-world infrastructure, and if global companies are going to seriously shift a lot of sites there, the roads, power, and communications systems are going to have to be modernized. That's going to cost someone money -- either through private investments, or through taxation. And since global corporations looking for cheap labor don't tend to want to pay for things like power distribution systems, this means the government is going to have to do it, which means increased taxes, which costs are going to rise for everyone, which means the labor force is going to become more expensive over time.
So, yeah, it's a nice cheap ride for now, but eventually the costs of modernization are going to catch up and level the playing field.
LPD-17 class ships (Landing Platform, Dock) are not themselves amphibious, but transport amphibious craft such as LCACs (Landing Craft, Air Cushion) and other vehicles used in amphibious operations.
.
For more information on these ships, see
No, because that machine is not the MX server for its domain. The mail server which actually handles mail for that domain relays mail to avnavfw.pms317.navy.mil and is no doubt allowed to do so by the firewall.
Add a "m" to the end of the filename in the url so it reads ...bubba_ho-tep_m480.mov
The official announcement is here.
:)
I've already downloaded and installed it. Thank goodness for Slackbuild scripts
Don't forget that compiling your own OpenSSH eeds the updated OpenSSL
Nope. You only need openssl-0.9.6 or later. See the INSTALL doc in the openssh 3.7p1 source.
Make bzImage && make modules is no longer the recommended way to do this. You should just do "make" instead, which will build bzImage and any modules you may have asked for, and do it quicker than if you specify the steps separately. See the Halloween 2.5 document for details.
Lots of people test nightly builds of Mozilla; what's so different between Mozilla and the kernel which prevents kernel binaries from being downloadable?
Because there are simply too many variables for a manageable number of binary releases to cover. You have different CPU types -- and not just x86 ones -- to optimize for. Just the x86 ones alone would require half a dozen separate builds or more, without taking into account SMP or lack of SMP.
Then you have build tools. Different versions of the compiler, of binutils, of the module tools, etc, all can expose subtle bugs. And they can introduce incompatibilities -- third-party modules built with one version of gcc won't work with a kernel built with another.
Then you have the way the system is going to be used. If you have a desktop system with lots of RAM and disk space, great, build everything and have at it. But if you're targeting an embedded platform, you may not be able to do that, so you'd want to build a much smaller subset of the kernel, possibly with some core features removed, or a different scheduler than most desktop users would want to use, etc.
Simply put, the cross product of hardware platform, intended use of the system, and development tools, is too large for binary-only releases of test kernels to be a useful test article.
What you're arguing for makes sense at the distribution level. And in fact it's there already: there's never any reason for anyone to compile their own kernel, IF they stick to production kernels. But in a testing environment, there's no way that a manageable number of binary releases is going to cover all of the possibilities.
Granted, you're mostly just trolling, but someone might seriously ask those questions. So:
Why is it necessary for anyone other than a kernel developer to compile the kernel sources?
Because this is still a development kernel. No Linux distribution ships with binaries of this kernel. So if you want to run it, you have to download the source and compile it yourself.
Why would anyone want to do that then? Because this is an open source project, and by running the test kernels, you help expose any lurking bugs so that they can be fixed. Once they're all fixed, the kernel can then be formally released. Distributions will ship with it, and people will then be able to run this kernel without the need to compile it themselves.
Should just anyone do this? No. This kernel isn't yet fit for a production environment. But people with spare machines, or who want to experiment, can do this if they want to contribute.
Why haven't all the optional pieces been broken out into modules yet?
Oh, they have been. Take a look at any of the major distributions. They ship with standard kernels, in which support for pretty much everything that can be modularized, is. That way it's as close as possible to a one-size-fits-all kernel and most users have no need to recompile it. About the only thing that can't be taken into account by this approach is CPU optimization, which is why a lot of distros ship with a set of otherwise identically configured kernels, each optimized for a particular CPU type.
This seems to be yet another in the growing collection of mostly useless 2.6 "migration guides". It doesn't mention any of the common gotchas with configuration, its recommendation for invoking the build process is wrong, etc, etc.
A much better guide is Dave Jones's Post Halloween 2.5 document, which, although very slightly dated, does a much better job explaining how and why things have changed in 2.6 and their impact when upgrading from 2.4.