At a user-software level, sure, I'll buy that. The increased separation of Unix in general makes it easier to maintain and easier to keep systems operational, once you understand them. Everything is out in the open where you can see it, instead of buried in the innards of Windows.
What I'm trying to point out is the Linux kernel model, in the 2.6 series, is changing at a furious speed. Between that and the declared lack of stability in Linus' tree, developing a driver for Linux just got hellaciously more expensive. It was cheap under 2.4.X, because you did it once and it was pretty much done.
Under 2.6, that ain't the case. Now you have to do it, test it on all the distros you want to support (since Linus' tree is officially unstable, testing it alone wouldn't be enough anymore), and then with every iteration of 2.6, you have to do all that testing _again_. If you can get your drivers into the kernel tree it would be easier, but personally I don't think most large companies would want to do that.... tossing code over the fence and hoping like crazy that someone else will make your customers happy just isn't very smart.
2.6 is moving incredibly quickly, and because they refuse to declare a truly stable central tree, that makes development a LOT more expensive for companies that are responsible enough to actually test their code.
I'm pretty damn certain that Windows isn't moving that fast, and never has. If companies had to spend 30% of their budget on a system that releases new stable kernels every couple of years, think how expensive that's gonna get at a 4-month release cycle.
I don't disagree with you. All I'm trying to point out is that from the standpoint of a business, Linux is not an easy target to try to support. Windows is. Claiming that Linux is easier may be true on a technical level for exactly one kernel from exactly one vendor, but as soon as you look at the whole picture, it becomes quite different. Linux becomes very expensive. Windows is a high sunk cost with a low maintenance cost, where Linux is exactly the opposite. (which is kind of amusing, because the reverse used to be true for Linux in general... it was hard/difficult/expensive to do it on Linux, but then you never ever had to touch it again.)
Of course hardware makers should publish specs. But in the case of wireless radios, obviously some companies cut corners on the hardware, and don't feel comfortable enabling others to potentially break the law.
If Linux had a slightly saner development environment, it'd be easier to convince companies to support it directly.
Oh and btw, from that link.... getting drivers into the kernel is great, if you can do it. But as a company, I don't think 'get the driver into the kernel tree' is an acceptable solution. If that code blows up, I'm the one that's going to get the heat for it. I think it's just another form of 'throw it over the wall and hope like heck someone else makes my customer happy'. And you'd STILL have to test all the different kernel variants out there, since the core kernel isn't officially stable anymore.
Again, I'm NOT saying that the API needs to be fixed in stone forever. But changing it in much larger steps, less frequently, is going to do wonders for uptime and stability. My Debian servers have had an absolute flood of kernel patches, and that's a such a freaking hassle to deal with. And each kernel patch is putting new code in there with new features I don't know anything about. That's NOT the way to run a railroad. I can't spend half my life studying the damn kernel to make sure there are no security problems for my specific installation in the latest update.
Yes, I realize that Open Source tends to be an iterative model. Business, however, does not thrive in that environment. Stuff has to stay up. It'd be way, way better if they went off, iterated in a sandbox, and came back every couple of years with a shiny new kernel tree.
The people marking things flamebait in this thread are doing Linux a real disservice. It's not perfect. Recent changes in the development model have messed it up. And simply pointing this out IS NOT FLAMEBAIT.
Metamods: the marking of the parent as Flamebait was Unfair. Please mark appropriately.
Somehow my first reply to you got lost... perhaps I'm answering here too quickly. I'll try again:
I'm not asking for kernel APIs to be stuck in tar forever. What I AM asking for is to go back to the old development model. I want APIs and features to be stable for a couple of years at a time. I want a secure OS that never falls over, not a rickety one that's being constantly patched.
The way to get stable code, in my experience, is to stop adding new features, and fix broken ones until everything works. In other words, pretty much what we did with 2.4.X and prior. (and if you'll notice, 2.4.X is pretty stable now, late in its development cycle.)
This new crap of supporting a 'stable' kernel for only a few months (and, further, declaring that stable kernels aren't stable enough for people to use) makes it a very, very expensive target to try to develop for.
The constant exploits are just a symptom of a deeper problem... they're moving way, way too fast, and aren't giving things time to settle out.
As I said to another person, a disgruntled customer (someone I broke a promise to) is a hundred times worse than someone who isn't a customer at all. Someone who isn't a customer may still buy things from me. Someone who's mad at me won't, and will damage my business by telling other people I suck.
If I tell a customer 'works with Linux', I'd better be DAMN SURE it works with Linux. As soon as I make that claim, I'm on the hook to make sure it does.
And without that stable center, and a slow development process, it's very expensive for me to make that promise.
A customer I broke a promise to is DISGRUNTLED. A disgruntled customer is a hundred times worse than someone who didn't buy my product.
Again.... the center Linux kernel has been declared to be unsuitable for end users. It is expected that end users will run individual distro kernels.
That means that I, as a driver writer, assuming I'm an actual professional and still believe in old ideas like actually testing my code, will have to test on all the distros. Because there isn't an official, stable center point, I have to test on every kernel variant that I want to support.
If there WERE a stable center, I could just test with that... if things broke from there, then it would be the fault of the distro. But without a stable center, it's my fault.
First, realize that I have been using Linux _forever_... I think somewhere in the 0.8 kernel range. (I was absolutely in before 1.0, because I sent Linus a congratulatory message when he released it, asking if he had a favorite charity. He never answered me, which cost that entity, if it exists, $50.) So calling me an anti-Linux zealot is completely stupid. I'm upset about this new bullshit development model in 2.6, but I have been a Linux fan for more than ten years. I'm not deeply into the code, but I have been administering Linux machines for a LONG time.
When you say I run and use Linux and Windows on a daily basis... something you have obviously never done., in other words, you look like a total idiot.
You say: Windows does not move slower than Linux. The driver API changed significantly with NT, then with 2000. It's been largely stable since then, but there are still continuous changes. It's a complete misnomer to suggest otherwise.
Windows NT 3.1 shipped in 1993. In 1996, NT 4.0 moved display and print drivers into kernelspace. That didn't impact non-print and display drivers, and I don't think it was much of an change even for those. It certainly was no trouble getting my drivers updated. (I started with NT at 3.5.) As far as I know, Win2k was the first major driver shift in the NT line. It shipped in 2000.
So in other words, you have 3 years to the first change, 4 years to the second, and 6 years and counting to the third. I'd call that pretty goddamn slow... downright glacial. Win9x was in more flux, but with the advent of Win2k, SIX YEARS AGO, all that flux stopped. The flux from pre-2000 is totally unimportant to anyone developing software today, anyway.
So OF COURSE WINDOWS MOVES SLOWER. Unless, of course, you're arguing that the driver model for Linux hasn't changed in the last six years?
By the same token, the Linux API isn't as unstable as "keeping the API open" suggests. There are many drivers available in the kernel that have been there for... a LONG time. Most of them were ported to 2.6 with no trouble at all.
Sure, but someone had to do the porting. Windows drivers that were written in 2000, to my best knowledge, will still work just fine, although you'll have to click on "ok to run unsigned code". And if your driver isn't in the kernel tree, it requires constant attention. The kernel API is changing constantly, as they deprecate old interfaces and shut down calls for 'non-GPL' drivers.
If I had written a driver for Linux, in other words, I would have to be tracking kernel changes very, very carefully. With Windows, I'd just now have to be picking it back up again after six years.
[... a bucketload of absolute garbage about OS versus kernels snipped]
I'm not talking about the OS. I'm talking about the kernel. Linux no longer has a robust center. Once upon a time, there was a stable kernel tree that was really stable. (see: 2.4.X). A driver creator could write a module just once. If it worked for that center tree, that was all they had to do. Any other distro that picked it up and subsequently broke it... well, that was their fault. If a module worked in the official stable tree but didn't work in Redhat's version of the kernel, that was clearly Redhat's fault.
With the fact that Linux no longer works reliably without vendor-supplied patches, now there's no stable center to test against. Instead, a driver creator has to test it individually against each different version of the kernel. And in some cases, it's very messy, as one of the posters pointed out: Redhat 2.6.9 claims to be 2.6.9, but has the interface layout for 2.6.10. This breaks stuff.
So now, if a module breaks with RedHat, it's the module writer's fault, not RedHat's. Since Linus has announced that his tree isn't stable enough for general usage, then just writing to that tree isn't enough anymore. That increases the load for driver writers enormously.
Again (for about the third time, I realize)... that's not how businesses think. If you're going to support a given platform, you do it WELL. That means testing. That means QA engineers. The fact that open source doesn't have any kind of formalized testing process, beyond "Oh crap, my server broke!" is not going to mesh well with most development departments I've known.
From a standard business perspective, just tossing code out the door and praying for someone else to make your customers happy is suicide. If the drivers are buggy, they get blamed, even if they worked perfectly when they were first released.
And, in the case of current wireless cards, if the drivers are able to overdrive the chipsets to do illegal things, they could also be blamed as well.
That's a lot of possible blame and liability to risk for a very, very small gain.
I think, with the advent of 802.11n, Linux users will be shut out even more thoroughly.
Again, tossing some source into the wild and hoping for the best is not how businesses work. If they decide to support a product, nearly all of them want to do it well.
If the drivers are buggy, who the hell do you think gets blamed?
Even if they release the SOURCE, it's STILL going to require a lot of effort to track changes and make sure it works.
Most companies I know, if they choose to support a product, want to do it _well_. That means internal testing to make sure it works. And that means tracking multiple variants of the Linux kernel. That's really expensive. Releasing source doesn't absolve them of the testing onus.
Sure, they could just toss some code out there and hope the free community picks it up, but that's not how business thinks. You run a business on making things as certain as you can, and making sure your customers are happy. Tossing code into the wild and hoping that somebody, somewhere, might make your customers happy is a very fast way to not be in business anymore.
I bought a copy of Chessmaster a year or so ago, and thought it was a very good teaching tool. There's a great deal of chess knowledge available there, and a lot of simulated opponent skill levels. I really quite enjoyed it.
As others are suggesting, together time is most important. But if you're trying to learn, learning from an expert is the best way. So my suggestion would be... pick up Chessmaster, but study _together_. That way, you get to be social, but you can learn properly. You'll probably both get better.
You got lucky. Linux is changing internal structures all the time. You just happened not to have had any changes that blow up your particular module.
USERSPACE is extremely robust and hardly ever changes. If you have userspace code from the darkest days of prehistoric Linux, it'll run fine on a current kernel. But kernel space is changing faster than any human can keep up with, including the kernel devs. That's why you're seeing constant local kernel exploits. They're adding features too fast to consider the ramifications.
Ok, granted, but Windows moves *slower*. When you're writing drivers, slower is demonstrably a good thing. It means you spend less money and time.
Windows updates are measured in years, and have tons of notice. Linux updates are measured in just a few months, and have almost no notice at all. A company developing for Windows probably only needs to address the driver issue once in a great while... if they get a really solid driver out the door in the first place, they won't have to spend much more money on it. Trying to maintain a driver for Linux would require constant attention. Attention costs money.
Plus, Linus' kernel isn't stable. He just waves his hand in the air and announces that 'the distros' will have to make Linux actually work. That means that now we have Red Hat's kernel, Suse's kernel, Mandrake's kernel, Debian's kernel.... and they are all running different versions and patch levels, and each will have different assortments of bugs. Every new version means an additional cost in testing and validation on that new platform, and tracking of releases on that platform as that distro fixes bugs unique to their particular Linux flavor.
Because Linus refuses to do the grunt work of making sure his kernel is truly robust, it means any commercial entity has to develop separate drivers for EVERY VERSION OF LINUX.
So it's not just a moving target, it's FIVE moving targets. (or three, or however many flavors of Linux you want to support.)
If I were a hardware developer, in other words, I wouldn't be very interested in supporting Linux.
Well, considering Microsoft doesn't ship a new 'stable' kernel (that isn't even remotely stable) every four months.... no, it's really pretty easy to develop for.
The OP is talking about a 150-seat network, not a 5-seat Mom and Pop shop. If you worked for a network that big and were forced to use hubs, it'd be time to find another job.
Anyplace still using hubs at this point, unless in dire financial trouble, is just stupid. If they're that cheap, then as an IT person, you're underpaid, and can do much, much better.
Well, it depends on what you mean by 'better'. I like to measure mobile CPU's Intel's way... performance per watt. (if it's just flat performance, then it's a desktop CPU, no?)
In terms of absolute performance, I believe AMD's chips are fine. But in terms of performance per watt, they are absolutely horrible. Intel-based machines will run much cooler and quieter, and last a lot longer on batteries, simply because the CPU is enormously more efficient.
The Pentium-M is the best technology out of Intel in a long time. I have a 2Ghz Pentium M in my laptop and love it... it's fast enough for gaming, but still runs cool and quiet. The battery life is okay, but this was a desktop replacement and not aimed at that. The machines oriented toward battery life, like Thinkpads, can last 8 hours running a Pentium-M. To get that kind of life out of an AMD, you'd have to carry a 20-pound battery.
The new Core Duo should be a seriously kickass chip. It takes what's good about the Pentium-M and builds on it. I'd be very interested in these for HTPC use.
(also note: the Pentium 4 Mobile is NOT the Pentium-M, and sucks raw goat through a straw.)
I am upset with Republicans for changing the rules; that the high-interest credit card debt is supposed to be unsecured. If they'd come up with an alternate KIND of credit card that you can't default on... I could go for that. Presumably those interest rates would be much lower.
But changing the rules halfway through just means that a lot of people will be financially destroyed who otherwise wouldn't have been. They took out the cards with one understanding of the rules, and then the Republicans changed it midstream. All of a sudden, that high-interest debt is way, way more risky for the consumer.... switching the rules midway through amounts, I believe, to a bait-and-switch.
You are likely to argue that 'well if they didn't think they could pay it back, they shouldn't have taken out the debt in the first place!' To which I'd counter, there are an awful lot of people out there who took out credit card debt knowing that they couldn't be destroyed by it. Many of them used it to launch businesses and the like, knowing that if everything went south, they could at least keep their house, their car, and their furniture, and start over. They paid the high interest rates precisely BECAUSE they could keep their stuff if the business failed.
So now, suddenly, they CAN be destroyed by the debt. That is just WRONG.
'High-end'?? Who on earth uses HUBS anymore? You can get perfectly good 24-port switches for under a hundred bucks these days. Hell, my HOME network is fully switched.
If you work in a place that's still using hubs, suggest they spend a few hundred bucks and upgrade. It's worth it if you have more than one server... it'll let you use all your servers at their full capacity, rather than splitting one Ethernet cable among however many you've got. Dell has perfectly competent Fast Ethernet switches that are very cheap (I think $80 for a 24-port), and their 16-port GIGABIT Ethernet switch, which supports jumbo frames, is only $200. (their 8-port switch doesn't support jumbo frames, so if that matters to you, be careful.)
Admittedly, you might want a bigger backbone switch in the center of a 150-person organization (which I believe is the size of the OP's network), but if you presume he's on HUBS now, he could buy 240 switch ports for $800. Including installation time... under a grand to move their whole network to switched, with plenty of extra ports. And if he did go with the 'big switch in the middle' theory, it's unlikely that the total bill would exceed $2500.
Decent network infrastructure just isn't that expensive anymore.
But if, for whatever reason, that much money is out of reach... he might be able to do a DVD wallet, but didn't he say he needed 10 gigs per partition? He'd probably need at least two DVDs per machine, which is much less convenient. It means he can't just go away and let it rebuild, he has to come back halfway through. That'd be pretty annoying.
A poster over on Metafilter suggested that the profs drop some juicy liberal bits (which is what these people are REALLY after, make no mistake), and then split the proceeds 50/50.
Slashdot Mirror
At a user-software level, sure, I'll buy that. The increased separation of Unix in general makes it easier to maintain and easier to keep systems operational, once you understand them. Everything is out in the open where you can see it, instead of buried in the innards of Windows.
What I'm trying to point out is the Linux kernel model, in the 2.6 series, is changing at a furious speed. Between that and the declared lack of stability in Linus' tree, developing a driver for Linux just got hellaciously more expensive. It was cheap under 2.4.X, because you did it once and it was pretty much done.
Under 2.6, that ain't the case. Now you have to do it, test it on all the distros you want to support (since Linus' tree is officially unstable, testing it alone wouldn't be enough anymore), and then with every iteration of 2.6, you have to do all that testing _again_. If you can get your drivers into the kernel tree it would be easier, but personally I don't think most large companies would want to do that.... tossing code over the fence and hoping like crazy that someone else will make your customers happy just isn't very smart.
2.6 is moving incredibly quickly, and because they refuse to declare a truly stable central tree, that makes development a LOT more expensive for companies that are responsible enough to actually test their code.
I'm pretty damn certain that Windows isn't moving that fast, and never has. If companies had to spend 30% of their budget on a system that releases new stable kernels every couple of years, think how expensive that's gonna get at a 4-month release cycle.
I don't disagree with you. All I'm trying to point out is that from the standpoint of a business, Linux is not an easy target to try to support. Windows is. Claiming that Linux is easier may be true on a technical level for exactly one kernel from exactly one vendor, but as soon as you look at the whole picture, it becomes quite different. Linux becomes very expensive. Windows is a high sunk cost with a low maintenance cost, where Linux is exactly the opposite. (which is kind of amusing, because the reverse used to be true for Linux in general... it was hard/difficult/expensive to do it on Linux, but then you never ever had to touch it again.)
Of course hardware makers should publish specs. But in the case of wireless radios, obviously some companies cut corners on the hardware, and don't feel comfortable enabling others to potentially break the law.
If Linux had a slightly saner development environment, it'd be easier to convince companies to support it directly.
No wonder you posted anonymously.
I won't bother answering you further unless you're willing to sign your name to what you say.
Oh and btw, from that link.... getting drivers into the kernel is great, if you can do it. But as a company, I don't think 'get the driver into the kernel tree' is an acceptable solution. If that code blows up, I'm the one that's going to get the heat for it. I think it's just another form of 'throw it over the wall and hope like heck someone else makes my customer happy'. And you'd STILL have to test all the different kernel variants out there, since the core kernel isn't officially stable anymore.
Again, I'm NOT saying that the API needs to be fixed in stone forever. But changing it in much larger steps, less frequently, is going to do wonders for uptime and stability. My Debian servers have had an absolute flood of kernel patches, and that's a such a freaking hassle to deal with. And each kernel patch is putting new code in there with new features I don't know anything about. That's NOT the way to run a railroad. I can't spend half my life studying the damn kernel to make sure there are no security problems for my specific installation in the latest update.
Yes, I realize that Open Source tends to be an iterative model. Business, however, does not thrive in that environment. Stuff has to stay up. It'd be way, way better if they went off, iterated in a sandbox, and came back every couple of years with a shiny new kernel tree.
The people marking things flamebait in this thread are doing Linux a real disservice. It's not perfect. Recent changes in the development model have messed it up. And simply pointing this out IS NOT FLAMEBAIT.
Metamods: the marking of the parent as Flamebait was Unfair. Please mark appropriately.
Somehow my first reply to you got lost... perhaps I'm answering here too quickly. I'll try again:
I'm not asking for kernel APIs to be stuck in tar forever. What I AM asking for is to go back to the old development model. I want APIs and features to be stable for a couple of years at a time. I want a secure OS that never falls over, not a rickety one that's being constantly patched.
The way to get stable code, in my experience, is to stop adding new features, and fix broken ones until everything works. In other words, pretty much what we did with 2.4.X and prior. (and if you'll notice, 2.4.X is pretty stable now, late in its development cycle.)
This new crap of supporting a 'stable' kernel for only a few months (and, further, declaring that stable kernels aren't stable enough for people to use) makes it a very, very expensive target to try to develop for.
The constant exploits are just a symptom of a deeper problem... they're moving way, way too fast, and aren't giving things time to settle out.
As I said to another person, a disgruntled customer (someone I broke a promise to) is a hundred times worse than someone who isn't a customer at all. Someone who isn't a customer may still buy things from me. Someone who's mad at me won't, and will damage my business by telling other people I suck.
Much better to just not make the promise.
If I tell a customer 'works with Linux', I'd better be DAMN SURE it works with Linux. As soon as I make that claim, I'm on the hook to make sure it does.
And without that stable center, and a slow development process, it's very expensive for me to make that promise.
A customer I broke a promise to is DISGRUNTLED. A disgruntled customer is a hundred times worse than someone who didn't buy my product.
Again.... the center Linux kernel has been declared to be unsuitable for end users. It is expected that end users will run individual distro kernels.
That means that I, as a driver writer, assuming I'm an actual professional and still believe in old ideas like actually testing my code, will have to test on all the distros. Because there isn't an official, stable center point, I have to test on every kernel variant that I want to support.
If there WERE a stable center, I could just test with that... if things broke from there, then it would be the fault of the distro. But without a stable center, it's my fault.
First, realize that I have been using Linux _forever_... I think somewhere in the 0.8 kernel range. (I was absolutely in before 1.0, because I sent Linus a congratulatory message when he released it, asking if he had a favorite charity. He never answered me, which cost that entity, if it exists, $50.) So calling me an anti-Linux zealot is completely stupid. I'm upset about this new bullshit development model in 2.6, but I have been a Linux fan for more than ten years. I'm not deeply into the code, but I have been administering Linux machines for a LONG time.
When you say I run and use Linux and Windows on a daily basis... something you have obviously never done., in other words, you look like a total idiot.
You say: Windows does not move slower than Linux. The driver API changed significantly with NT, then with 2000. It's been largely stable since then, but there are still continuous changes. It's a complete misnomer to suggest otherwise.
Windows NT 3.1 shipped in 1993. In 1996, NT 4.0 moved display and print drivers into kernelspace. That didn't impact non-print and display drivers, and I don't think it was much of an change even for those. It certainly was no trouble getting my drivers updated. (I started with NT at 3.5.) As far as I know, Win2k was the first major driver shift in the NT line. It shipped in 2000.
So in other words, you have 3 years to the first change, 4 years to the second, and 6 years and counting to the third. I'd call that pretty goddamn slow... downright glacial. Win9x was in more flux, but with the advent of Win2k, SIX YEARS AGO, all that flux stopped. The flux from pre-2000 is totally unimportant to anyone developing software today, anyway.
So OF COURSE WINDOWS MOVES SLOWER. Unless, of course, you're arguing that the driver model for Linux hasn't changed in the last six years?
By the same token, the Linux API isn't as unstable as "keeping the API open" suggests. There are many drivers available in the kernel that have been there for... a LONG time. Most of them were ported to 2.6 with no trouble at all.
Sure, but someone had to do the porting. Windows drivers that were written in 2000, to my best knowledge, will still work just fine, although you'll have to click on "ok to run unsigned code". And if your driver isn't in the kernel tree, it requires constant attention. The kernel API is changing constantly, as they deprecate old interfaces and shut down calls for 'non-GPL' drivers.
If I had written a driver for Linux, in other words, I would have to be tracking kernel changes very, very carefully. With Windows, I'd just now have to be picking it back up again after six years.
[... a bucketload of absolute garbage about OS versus kernels snipped]
I'm not talking about the OS. I'm talking about the kernel. Linux no longer has a robust center. Once upon a time, there was a stable kernel tree that was really stable. (see: 2.4.X). A driver creator could write a module just once. If it worked for that center tree, that was all they had to do. Any other distro that picked it up and subsequently broke it... well, that was their fault. If a module worked in the official stable tree but didn't work in Redhat's version of the kernel, that was clearly Redhat's fault.
With the fact that Linux no longer works reliably without vendor-supplied patches, now there's no stable center to test against. Instead, a driver creator has to test it individually against each different version of the kernel. And in some cases, it's very messy, as one of the posters pointed out: Redhat 2.6.9 claims to be 2.6.9, but has the interface layout for 2.6.10. This breaks stuff.
So now, if a module breaks with RedHat, it's the module writer's fault, not RedHat's. Since Linus has announced that his tree isn't stable enough for general usage, then just writing to that tree isn't enough anymore. That increases the load for driver writers enormously.
Instead of one
Again (for about the third time, I realize)... that's not how businesses think. If you're going to support a given platform, you do it WELL. That means testing. That means QA engineers. The fact that open source doesn't have any kind of formalized testing process, beyond "Oh crap, my server broke!" is not going to mesh well with most development departments I've known.
From a standard business perspective, just tossing code out the door and praying for someone else to make your customers happy is suicide. If the drivers are buggy, they get blamed, even if they worked perfectly when they were first released.
And, in the case of current wireless cards, if the drivers are able to overdrive the chipsets to do illegal things, they could also be blamed as well.
That's a lot of possible blame and liability to risk for a very, very small gain.
I think, with the advent of 802.11n, Linux users will be shut out even more thoroughly.
Again, tossing some source into the wild and hoping for the best is not how businesses work. If they decide to support a product, nearly all of them want to do it well.
If the drivers are buggy, who the hell do you think gets blamed?
Even if they release the SOURCE, it's STILL going to require a lot of effort to track changes and make sure it works.
Most companies I know, if they choose to support a product, want to do it _well_. That means internal testing to make sure it works. And that means tracking multiple variants of the Linux kernel. That's really expensive. Releasing source doesn't absolve them of the testing onus.
Sure, they could just toss some code out there and hope the free community picks it up, but that's not how business thinks. You run a business on making things as certain as you can, and making sure your customers are happy. Tossing code into the wild and hoping that somebody, somewhere, might make your customers happy is a very fast way to not be in business anymore.
I bought a copy of Chessmaster a year or so ago, and thought it was a very good teaching tool. There's a great deal of chess knowledge available there, and a lot of simulated opponent skill levels. I really quite enjoyed it.
As others are suggesting, together time is most important. But if you're trying to learn, learning from an expert is the best way. So my suggestion would be... pick up Chessmaster, but study _together_. That way, you get to be social, but you can learn properly. You'll probably both get better.
You got lucky. Linux is changing internal structures all the time. You just happened not to have had any changes that blow up your particular module.
USERSPACE is extremely robust and hardly ever changes. If you have userspace code from the darkest days of prehistoric Linux, it'll run fine on a current kernel. But kernel space is changing faster than any human can keep up with, including the kernel devs. That's why you're seeing constant local kernel exploits. They're adding features too fast to consider the ramifications.
Ok, granted, but Windows moves *slower*. When you're writing drivers, slower is demonstrably a good thing. It means you spend less money and time.
Windows updates are measured in years, and have tons of notice. Linux updates are measured in just a few months, and have almost no notice at all. A company developing for Windows probably only needs to address the driver issue once in a great while... if they get a really solid driver out the door in the first place, they won't have to spend much more money on it. Trying to maintain a driver for Linux would require constant attention. Attention costs money.
Plus, Linus' kernel isn't stable. He just waves his hand in the air and announces that 'the distros' will have to make Linux actually work. That means that now we have Red Hat's kernel, Suse's kernel, Mandrake's kernel, Debian's kernel.... and they are all running different versions and patch levels, and each will have different assortments of bugs. Every new version means an additional cost in testing and validation on that new platform, and tracking of releases on that platform as that distro fixes bugs unique to their particular Linux flavor.
Because Linus refuses to do the grunt work of making sure his kernel is truly robust, it means any commercial entity has to develop separate drivers for EVERY VERSION OF LINUX.
So it's not just a moving target, it's FIVE moving targets. (or three, or however many flavors of Linux you want to support.)
If I were a hardware developer, in other words, I wouldn't be very interested in supporting Linux.
Well, considering Microsoft doesn't ship a new 'stable' kernel (that isn't even remotely stable) every four months.... no, it's really pretty easy to develop for.
The OP is talking about a 150-seat network, not a 5-seat Mom and Pop shop. If you worked for a network that big and were forced to use hubs, it'd be time to find another job.
Anyplace still using hubs at this point, unless in dire financial trouble, is just stupid. If they're that cheap, then as an IT person, you're underpaid, and can do much, much better.
Note: my statements re:AMD may be outdated, I'm not that familiar with the Turion line. Imbibe sodium chloride accordingly.
The Pentium M is still a _great_ chip.
Well, it depends on what you mean by 'better'. I like to measure mobile CPU's Intel's way... performance per watt. (if it's just flat performance, then it's a desktop CPU, no?)
In terms of absolute performance, I believe AMD's chips are fine. But in terms of performance per watt, they are absolutely horrible. Intel-based machines will run much cooler and quieter, and last a lot longer on batteries, simply because the CPU is enormously more efficient.
The Pentium-M is the best technology out of Intel in a long time. I have a 2Ghz Pentium M in my laptop and love it... it's fast enough for gaming, but still runs cool and quiet. The battery life is okay, but this was a desktop replacement and not aimed at that. The machines oriented toward battery life, like Thinkpads, can last 8 hours running a Pentium-M. To get that kind of life out of an AMD, you'd have to carry a 20-pound battery.
The new Core Duo should be a seriously kickass chip. It takes what's good about the Pentium-M and builds on it. I'd be very interested in these for HTPC use.
(also note: the Pentium 4 Mobile is NOT the Pentium-M, and sucks raw goat through a straw.)
I am upset with Republicans for changing the rules; that the high-interest credit card debt is supposed to be unsecured. If they'd come up with an alternate KIND of credit card that you can't default on... I could go for that. Presumably those interest rates would be much lower.
But changing the rules halfway through just means that a lot of people will be financially destroyed who otherwise wouldn't have been. They took out the cards with one understanding of the rules, and then the Republicans changed it midstream. All of a sudden, that high-interest debt is way, way more risky for the consumer.... switching the rules midway through amounts, I believe, to a bait-and-switch.
You are likely to argue that 'well if they didn't think they could pay it back, they shouldn't have taken out the debt in the first place!' To which I'd counter, there are an awful lot of people out there who took out credit card debt knowing that they couldn't be destroyed by it. Many of them used it to launch businesses and the like, knowing that if everything went south, they could at least keep their house, their car, and their furniture, and start over. They paid the high interest rates precisely BECAUSE they could keep their stuff if the business failed.
So now, suddenly, they CAN be destroyed by the debt. That is just WRONG.
'High-end'?? Who on earth uses HUBS anymore? You can get perfectly good 24-port switches for under a hundred bucks these days. Hell, my HOME network is fully switched.
If you work in a place that's still using hubs, suggest they spend a few hundred bucks and upgrade. It's worth it if you have more than one server... it'll let you use all your servers at their full capacity, rather than splitting one Ethernet cable among however many you've got. Dell has perfectly competent Fast Ethernet switches that are very cheap (I think $80 for a 24-port), and their 16-port GIGABIT Ethernet switch, which supports jumbo frames, is only $200. (their 8-port switch doesn't support jumbo frames, so if that matters to you, be careful.)
Admittedly, you might want a bigger backbone switch in the center of a 150-person organization (which I believe is the size of the OP's network), but if you presume he's on HUBS now, he could buy 240 switch ports for $800. Including installation time... under a grand to move their whole network to switched, with plenty of extra ports. And if he did go with the 'big switch in the middle' theory, it's unlikely that the total bill would exceed $2500.
Decent network infrastructure just isn't that expensive anymore.
But if, for whatever reason, that much money is out of reach... he might be able to do a DVD wallet, but didn't he say he needed 10 gigs per partition? He'd probably need at least two DVDs per machine, which is much less convenient. It means he can't just go away and let it rebuild, he has to come back halfway through. That'd be pretty annoying.
Spore, capitalized. I don't want to even imagine Will Wright's lowercase spore.
Actually, Will Wright's spore is likely to be at least partially SimDirt. :)
A poster over on Metafilter suggested that the profs drop some juicy liberal bits (which is what these people are REALLY after, make no mistake), and then split the proceeds 50/50.