The best editor I've ever seen doesn't, without quite a bit of extra typing. Get used to vi varient sometime, it's generally much faster. I use vim as my development IDE. ":make" will build the software and take you to the next error. ":!" will let you see the console that has all the errors (actually, it will let you see the shell that all your stuff runs it). "cn" will take you to the next error.
I could probably map a macro to something like "search whole word" if I felt like it. However, I've found using "iii" to be an idiom well worth using in conjuction with vim.
I'm sure I could find a different editor, but "ESC/iii" is how I do searching. I really don't care to figure out how to write a better expression in vim. vim is well worth it's salt, and I could probably map a macro to work for searching for a word. However, by default I'm not aware of any such option short of writting a longer regular expression that I would to search for an increment variable. Every programmer worth their salt I've known uses some vi varient or emacs. Off hand I don't know how to search in emacs, but I'll bet it's a quicker and easier for the hot key for "search", as opposed to "search for full words".
Any editor that I need to use a mouse with is defective. Mice are only good to feed cats and pick the xterm you want to use.
Ironically, the one of the best tips from one the best programmers I've ever known, is use the form "iii" for all incremented variables. Why? Because if you use English Language descriptions, "iii" should never occur when searching except for in the case of your variable. However, if you use i,j,k (the standard loop variables), when you search for them, you constantly have to search, and search again because you find those letters embedded in function names or keywords.
Wow, SCO would become the worlds most reliable source of power. Geez, if that was true, I'd start buying up the stock left and right. They are going to put them Arab's out of the Oil business. Wow, even sales people would start to be valuable. I'm fairly sure we could find some way to convert used cars salesmen lies into power using a similar princepal.
For the presidential election see the Constitution, Article II, Section 2, paragraph 4.
The Congress may determine the Time of chusing the Electors, and the Day on which they shall give their Votes; which Day shall be the same throughout the United States.
That's for Electoral College votes (only 538 of those each election). So I guess it depends on if Congress has enacted a law which would prohibit the states from using that as the "Time of chusing the Electors" (that's what we do on election day) or not. There is a similar statement covering the two houses of Congress. I'm not familiar enough with Federal Election laws to be sure what if any limits Congress has passed covering this. However, I'm guessing it's not incredibly illegal otherwise Florida couldn't have done it this year. Presumably, it's the same provision that makes Absentee ballots legal. I know several people who voted early in Nebraska (where I live). One I believe was thru a local polling place that accepted absentee ballots early when given in person.
Assuming MikroTik violates the GPL, what you are saing isn't true. Depending on the circumstances, they don't have to give you the source, they have to give the source up to people who they gave the binaries to. If they ship the binaries and the source to people at the same time, they don't have to give you the source (This is covered in Section 3 of the GPL).
Now, assuming that they are in fact violating the GPL, anyone who has copyrighted material in the work can in fact force their hand. So any kernel developer can deal with this.
Looking on their site, they have in fact given lipservice to sending you a CD (they claim it won't contain their propriatary software, but if they are following the letter of the law, they should have to give you the kernel source w/ any modifications they made). The offer is down near the bottom of this page:
This appears to be in compliance with 3b of the GPL.
If you report this on the LKML list I'm fairly sure several people would help you pursue it if you can show they are in fact violating the GPL (if they didn't modify the kernel, they aren't). If they are violating the GPL, they sure are being quiet about it. Google turns up very little about it. I've seen several threads on the LKML where people outside of Linus Torvalds pursue GPL violations. Alan Cox being on of them. Any number of people pursued Linksys.
Uhhh, how about putting both updates out on the YUM server at the same time. You don't really YUM update your kernels and not test them do you? Especially when you are using tainted kernels. If you just blindly roll out every kernel update your are being silly.
Try being a really good IT person, and testing the kernel updates first, then push them to your internal YUM server individually. It's not like you wouldn't or shouldn't be doing this with Windows or Solaris.
I support 50 desktops, this isn't a complex problem. Scaling to support 300 or 3000 wouldn't phase me as long as I still only had a handful of configurations (thousands of configurations presents a problem no matter what type of solution you use).
There needs to be a consistent driver API across each major version of the kernel.
Why? You tell a nice little story about running 4 different binary only drivers. You represent a very, very niche market.
Of anyone I've ever read or heard of, you are absolutely unique. I've run and installed Linux on hundreds if not thousands of computers. The only binary only driver I've ever had to install is the nVidia one. Even that is merely just because I wanted better performance. I could easily use the machine just fine without it.
I've installed SCSI cards, IDE cards, RAID controllers for SCSI drives. I've installed SAN drivers. I've installed up to Gigabit cards. I've installed scanners, mice and keyboards, printers, CD burners, soundcards, USB and Firewire drives. I've had desktop cameras. I've had digital cameras that used USB connectors. I've used magneto-optical drives. Heck, the Parallel port Zip drive worked better under Linux then it did under Windows. I've hooked up flash readers. I've connected a myriad of perphials. What on earth are you connecting up to a machine that you need 4 separate binary drivers? Are you sure they aren't replaceable with a component that would have worked with drivers?
I'd much rather have the developers have the ability to fix and solve bugs rather then cludge together something that might or might not work.
For the most part, 99% of the driver API is in fact stable inside of a single kernel minor release (technical speaking 2 is the major kernel release, 4 is the minor release) kernel series (the single exception I can think of is that 2.4.10 completely broke the VM subsystem from 2.4.9). Most of the other things are merely your vendor being too lazy to get off their butt and release the binary only driver. It's not particularly hard. If what your are using doesn't support both Suse and RedHat, put down the box, and back away.
Finally, just like the Apache guys have been saying for years, "We have a lot more drivers to maintain then you do, if we change the API we have a very good reason to". It's not like Linus goes and makes changes willy nilly. Generally speaking, it's been to make the API easier to use, to refactor common parts into higher layers for code reuse, or to use a more efficient/scalable model.
You can keep saying that it really needs a decent driver model. No it doesn't. It is what it is, precisely because they refuse to have choke points to when innovation can happen. You might love it if it does. Personally, I like it not having choke points. I review the hardware I plan on hooking up to a machine, and ensure that all the perphials do what I need them to do, and that they are usable under the OS I run.
Next you'll complain because your x86 machine doesn't support Nubus, or Altivec instructions. Pick things that have OS drivers and your problems go away.
Lastly, you are complaining to the wrong guy. Linus isn't your man there. Try complaining about the distributors. The distro people are the ones who make the actual final release you are using. They could just wait until tail end of the kernel life cycle and release it then with a stable API. They could maintain a stable API for you. However, you are not common in terms of users. If everyone clamoured for it, they'd get it. Heck, if that's really what you want, start using the 2.2 series kernel. It has a world class stable driver API. The problem is Linux moves fast and you want to stay with the cutting edge. It's not Window's is releasing their development stuff as early or as often as Linux is. I'm fairly sure that by the time you get the Windows kernel, it's probably similar to roughly where the 2.4 kernel is right now (maybe 6 months or a year ago). By the time you get Windows software, it's old and stale (in terms of true innovation and change, Microsoft is fairly serious about limiting architectural change, just like the 2.2 and 2.4 guys are right about now). Pick what you want.
I've got to agree with this guy. Deliver the ISO (possibly on CD ironically), with an MD5SUM of the file.
The gold master only needs to be good enough to read it once.
I burn ISO's of linux distros all the time, with the CD's I pickup using a Sony CD burner. In all that time, I think I've had a half dozen coasters. Generally your biggest problem, is the CD you are reading it on is crappy (not the burner). A lot of laptops or slimline CD's that go into 1U server or speciality small machines have a very low tolerance for error and are very sensitive to reading burned CD's. Just like CD's from pre-burner days have trouble with CDR's, and lots of trouble with CDRW's.
If you are burning them yourself, this makes sense, go get a high quality CD duplicator (stand alone machines that take spools of CD's). Use a name brand (Memorex I've had good luck with, Verbatim's I tend to stay away from if I'm paying attention, but that's an old, old bias, pickup a name brand and generally you'll be fine). If not, go pay someone with the proper tools to do it. Ten years ago, it was $1000 for the master, a buck a disk when I was looking to get CD's made when a burner was about $4K for the drive, and $20 for a blank CD. I'd guess the stamped price has stayed roughly the same, maybe gone up a little in price.
They don't even guarantee API compatibility within major releases so I can't even update machines without testing the updates first.
Really in RedHat Linux or in RedHat Enterprise Linux? They do if Fedora, but Fedora is a known broken tool (it's a shiny nifty looking tool, but broken as far as using for Enterprise quality Linux distros). I'd really like to see any anecdotes or documentation showing that RH broke the API/ABI inside the same series. As a matter of fact, they do support an ABI (which is a stronger guarantee then an API), ABI's are a binary compatibility, where as API's are a source level compatibility, except for incredibly exceptional circumstances where the security fix cannot be implemented short of changing the ABI (think somebody figured out how to factor big numbers in O(1)). You know like the RPC problems that Windows had in NT 4.0 that MS just refused to fix because there was no compatible way to fix the security flaw. RedHat backports security fixes to the version of the software they released.
If you are making a reference towards RH not supporting a single ABI inside of the kernel and breaking 3rd party modules, that's accurate. However, that's a fundamental issue with the kernel (not, it's not a problem, just an issue). I never use binary only drivers with the single exception of the nVidia drivers for home desktop machines. If that is what you are making a reference towards, even Debian can't solve that.
I've never known RH to break an ABI or API inside of the same major release series, let alone inside of the point release. That is the beauty of RH updates. They can be upgraded with a high confidence they won't break the ABI. In fact, the old rule was that if the ABI changed they incremented the major version (which is why 8.0 didn't have any point releases). It's why they always release the 7.x RPM's when they release security fixes. (glibc and the kernel being the major components of the ABI).
With only a single exception, I've never seen a RedHat RPM break anything if installed on the version of RH it was packaged for. The single exception, was the bind-chroot package. If you upgraded the bind package and you had installed bind-chroot, it moved the original configuration files and installed the default ones again. All you had to do was go move the configuration files back and it was fixed. I believe that was a total of ten minutes of downtime for me. That's in about 5 years of running RedHat as the core of our enterprise, and about 3-4 years before that (I've been running RedHat regularly since the 5.x series, but I know I ran a 4.x series that came with a RH book I picked up ages ago).
I'm highly curious to hear what your experience is with this. I've never used Debian, mainly because all the problems I've had with RedHat over the years have slowly been fixed. Debian only had one serious advantage in that apt-get was an easy way out of RPM hell. Now I just use White Box Enterprise Linux, it has yum installed. I'm happy as a clam. We run it for all of our non-Oracle machines. We save a ton on licensing, and have very few problems (all of which are problems that would have existed if we purchased RHEL).
Well you might know anyone who does it? Do you know anyone who commits murder? Do you know a hit man personally? Do you deny their existance on the basis that you don't know one?
I know people who are into this sort of thing. In fact, I ended up doing it once accidently long ago. Our floppy drive broke, I bought a new one at BB. I took it home and started trouble shooting it. I wrote a floppy on it with my only copy of some important data. I worked a day or two longer and my drive failed. I returned the drive as defective. I tried the original floppy drive in a different machine. Worked fine. I ended up calling Dell tech support to find out what to do with this machine, and if there was any way to get the data off the floppy. He said to go get the drive it was written with. It'd be the last chance I had to read the data. I walked into the BB store, about 24 hours after returning the drive and bought it for about 33% off (I offered to pay full price, but they said it was too much paper work). It still didn't work, but I kept the drive.
Interestingly enough, during that same transaction, I ended up working a different scam entirely because the girl at the counter wasn't paying attention (it was her mistake, not mine I walked back in the store and paid the difference). I bought the floppy drive and a PS/2 extension cord at the same time. They had the wrong gender. When I did the return, I walked back picked up the cable I needed and returned the drive. She ended up creditting me for the drive and for the cable I left the building with. She assumed I was returning both because both items matched the description on the receipt. The way to do this correctly, is buy two items, one cheaper then the other. Walk in, get your stuff tagged by security. Go get the more expensive item in the store. Put the cheap one back on the shelf. Return the expensive one for your money back. Buy a half dozen other items while pushing a cart.
If you are good at this, and live in a large enough city. I'd bet I could several thousand dollars a week doing this. Tax free. I'm not sure what you take home for pay, but I'd be thrilled to take that home. It's not hard to make a living being a fraudster. If you can work eBay, pawn shops, and a scams like this, I'm willing to bet I could make a lot more money then I currently do with a lot less work.
I'd never do it, but I did work retail at Babbage's for a while. I had to spot shop-lifters, and always be aware of what was going on at the cash register. Never get flustered.
I believe BB caught on to this eventually, as now I believe security walks returns to the return counter.
I've know people who steal (it's a friend of a friend, he's a pretty cool guy, except he's got fairly questionable ethics), and sell drugs for a living. He thinks the same way a lot of people who've responded to me in this thread. Screw'em, they're a corporation, they screw me, I'll screw them.
As a general rule, mail in rebates merely require you to send in the original reciept. Generally after you return something, if it's the only item, just ask the cashier for it, they'll hand it to you. If there are two items, they have to give it back to you. I've never had to send in a UPC code, and to be honest, I've never had anyone actually check anything I've returned that closely to see if the UPC code was still there.
I guy I know used to buy stuff with cash, go to where he worked, empty the contents of the computer games, put a deck of cards in it, then go to work and re-shrink wrap the box. He'd return it to Best Buy "un-opened". I worked with him at Babbage's (where he could have just taken the games home for free and played them for a week, it was store policy, that's why we had the shrink wrap gun). The sickest part was when he started doing this for a fee for people who had heard about it. Best Buy actually started calling around to places know to have shrink wrap guns (there we're 3 or 4 in the shopping center). They talked with him, and he played coy about it. He was still the manager there until the store was closed down 2-3 years later (about 8 years ago).
Well they murderd my brother, so it must be okay for me to murder their brother.... That's the sort of vigilanttism you're logically using. Repeat after me: "Two wrongs does not make a right".
Sometimes being a decent human being is tough, but try it sometime it's really not that hard. Maybe I'm just the last human being that walks back into the store when I realize they gave me too much change and gives them back the money.
Go look up the stats on it sometime. Corporations on the NYSE generate about $2000 profit per person in the US in aggregate. Corportations have to work really hard to earn a profit. If we had to live off of corporate profits, we'd be a third world nation by current standards. (Some of this is because of fat cat CEO's, but I'm betting it still wouldn't be pretty thru their salary into profits). So while you think "the man is screwing me", if you had to work half as hard as a corporation does to survive, you'd bitch about how hard life is.
As long as you don't complain when all sales are final, I don't care. I really like being able to return things if there's a problem, or if there's nothing defective about the product, but it just doesn't work with what I want it to do (I've had this happen with incompatible hardware and software back in the bad old days of manually setting IRQ/Base IO ports), the hardware just wasn't going to work for me. I returned it explaining that. Or letting me exchange cables because I forgot to get the ones with the correct gender because I was in a hurry.
If I was Best Buy, I'd establish a "Absolutely No Returns Policy". You can check to see if it's damaged in the store. Other then that, if you leave the building with it and it's broken, you get to keep all the pieces. That's the logical result of such a system.
While that's a neato concept, I'm fairly sure the truth is much closer to this:
They get to book the full purchase price today, and not have to book the rebate until the following quarter (most of the time). They get the interest of it (while it doesn't sound like a lot, for Best Buy, I'll bet it's not chump change if you aggregate the total interest). Finally Mail in Rebates are one of the few sane ways to ensure they don't sell you 10 of the loss leaders at below cost. (A super market I worked at when I was younger used to lose it's shirt on some sales like that where people would just come back in time after time. They finally established a minimum purchase to get the discount, and that was enforced only if the cashier was paying attention). You can only have one rebate per address. It's much more effective then attempting to track who has or hasn't purchased it at a deep discount on a previous trip, or a trip to a different store. This is always a problem for me, as I mirror harddrives. I can only get one drive at the discounted price.
Well, I have to say, I can't object to Best Buy saying that customers who are buying things at rebate and returning them to keep the price difference. I can't object to them saying that people who return stuff specfically so they can come back and pick it up of the rebate table.
People are abusing those benefits Best Buy provides. Now, I think the Mail in Rebates are bogus. I really wish it was required that they put the price I have to pay when I get to the counter on the price tag (I know CompUSA is notorious for this, not sure about Best Buy).
Now, forcing people to honor their advertising about price matching. That I've got no problems with the customer doing. If Best Buy doesn't want to have to lower the price, they shouldn't have advertised it as part of their pricing. I don't know if Best Buy does this, but I know that I've heard some places have branded models that are only sold by a particular chain. They sell identical systems to 3-4 chains, but each chain has it's own model number. Thus they can claim that a competitor with a lower pice isn't exactly the same model, so the guarantee doesn't apply. That's crappy, but I'm not sure if that has any bearing on this article.
I know I don't like them discussion that people "buying up all the loss leaders" are a problem. Especially when they are discussing that people are re-selling the items on e-bay. That is capitalism at it's finest. The market is being highly efficient there, they just need to realize that communication and on-line auctioning have forced retailers to be more price competitive. The world has moved on, and this is a point at which Best Buy is just being left behind (the fact that people will buy it for cost plus shipping, means either people are stupid, or Best Buy is taking a serious beating on the pricing). If Best Buy corporate had any brains, they'd setup small retailers to just sell them directly over eBay and move lots of items that way to see if they can benefit from the insanity of the purchasers.
Retail is generally a very inefficient way to sell things. There's only a single price for everyone. They'd be much better off with auction style pricing (the optimal price is found in a good market). People pay what they believe something is worth, and the store gets the maximal amount of money the market will bear. As long as there are plenty of buyers for any given item, they'd probably get a better price then they do with the shelf price. Plus it wouldn't have to be trucked around the country, and they wouldn't need as much retail space.
I don't like what they are talking about in terms of profiling. Part of my problem, is well, I don't dress my income. I had the same problem when purchasing a vehicle. Fortuantely when I went to get a house, I did the loan info over the phone. Sometimes it is nice to just be a number.
Now, Best Buy's claim that 20% of their customers are doing this sort of thing is just silly. I'm highly doubtful that it is that rampant (it might be 20% of their transactions, but not 20% of their customers).
When such firmware is built into the Linux kernel, that variant of the kernel becomes non-redistributable because one can't meet the terms of the GNU GPL
Here you claimed to understand that this wasn't a matter of being a part of the driver.
You are being silly. Go read up on the definition of "derived work" and "linking". Then read the GPL very closely. You'll notice that the firmware of a PCI card doesn't even execute on the same CPU architecture, let alone in the same address space (the rule of thumb amout if you are "linking" or not). When you get done figuring that out, realize that because the firmware was independently developed outside of the Linux kernel, and it works completely independently of the Linux kernel, it's not a derived work. Thus it's pretty much in the free and clear of all GPL issues. The actual binary bits in the kernel you are free to change to your hearts content with full GPL rights.
That's why firmware can be inside of the Linux kernel now. Some people want to move it outside of the Linux kernel (for both technical and political reasons). The technical being, that you can upgrade the firmware without re-compiling your kernel, and it shrinks the size of the kernel to not have it statically compiled in. The political is that so dolts like you don't say "That's a GPL violation". It isn't. The firmware isn't a derived work, and it isn't a linking to a GPL'ed piece of code. It's just data as far as the kernel is concerned. Just like the C code that passes thru a GCC is just data. Yes technically speaking it is source code, but it's just data. It's just like saying, well in order to initialize this card, you have to write a "0x80" to this port to get it configured correctly. In this case, instead of a single byte, it could be a 10-64k chunk of bytes. It's the same thing. They are going to make it blazingly obvious by moving it outside of the source tree so it acts just like the GCC code does in every single way. Then we can finally be finished with this argument. That's why the 2.6 kernel is building all of the infrastructure so that firmware can be loaded from user space. Then as long as the vendors say the firmware can be distributed for free, it's all good (which is what Theo is attempting to make happen).
Even if the OpenBSD and Linux people got the source to the firmware GPL'ed, there's no way in hell they'd ship source you had to compile. You'd still get a binary distributed to you. That would require you to have a development tool chain for whatever language (compiler for the language, assembler for the target architecture, and possibly a linker for the object format). Some or all of which literally might not exist outside of the company. It's not like Adaptec is using an x86 OBJ from C source for writting it's firmware. They might, but I wouldn't be shocked to find out they use a PIC with a propriatry C compiler from an embedded vendor. That would be a dependency the Linux kernel folks wouldn't allow for building a kernel.
In the past, it wasn't this way which is why I don't buy the excuse about how the economics of hardware work
Uhhh you must have some mysterious insight into the past about computers I lack. I wasn't around in the 1960's (wasn't terribly aware of computers until sometime in the 1990's). Can you describe how it used to work for me, as opposed to saying "it wasn't this way".
However, from what I've read, sure you got the source for the OS. Back then, you *rented* computer equipment a lot of the time (I believe that was IBM's original business model). I'm not sure precisely how long that lasted. However, back then, you bought computer equipment for $100K (which was a lot more money back then it is now). It took up the size of a room, and non of the software was runable on any other piece of equipment from someone besides that vendor. Heck, you could get a copy of UNIX source way back in the mid 70's. You could modify it, you could do whatever you wanted with it, except for give your copy to someone who didn't have a license. I've never known any company that allowed you to give away their software to someone who didn't have a license (some companies might have let you exchange fixes, but I'm fairly sure none of them let you give their software to anyone else, if they did that might be a clue as none of them that kept that policy are still in business).
When a piece of hardware broke, or had bad firmware, they sent a guy in a suit out to swap out the part (as opposed to shipping you the new firmware like they would today). You paid maintience on your computers that was on the order of 20% of the value of the computer. You had to pay fees and service. IBM shipped absolutely identical printers for two different models. One model printed twice as fast as the other, the only difference was a jumper setting.
When a part broke you had one vendor you could get a part from. When a disk drive went bad, you had one vendor you could get a replacement from.
Those we're the bad old days. I'm fairly sure that if you actually got what you wanted, you'd scream bloody murder to get back to the current situation. Unless you are just that much of a masochaist, or you have an ample supply of money.
You might not be aware of this, but computers used to be worth real money. I don't mean that $3,000 USD I paid in 1995 for a Gateway, I mean, in 1970, you could easily spend $250K (which is several million in todays dollars) on what was an entry level mini. When the transactions are that large, copyright violations are small deal. Hardware was expensive, and software was cheap. Programmer time was worth nothing, and computers were worth a lot (read "The Mythical Man Month", that was said by the guy who was in charge of the single largest computer development in the history of man during "the good old days").
You not believing that economics work that way based on the past is like closing your eyes and denying that I exist because you can't see me. Well, I don't believe that more then 10% of the world's population can not farm and have sustainable living. It didn't use to be that way. At one point in the point in the past, we are both highly accurate. Mine being a much longer time ago then yours. The world has passed you by while you were not paying attention.
You can try and present why it this is not the only sort of economy that would work, but you can't do it by pointing at the past and saying "see it used to be that way". The world changes, and it changes fast. Especially in the area of computing. The major change you missed was that fabricating hardware is cheap, while fabricating software is expensive. That's were the economic model changed that you apparently are in willful self-denial about.
Economics of the world is fairly vicious, if there was a better way, just describe it to people who are incredibly rich how it's better. It'll happen. They stand to make a lot of money making it happen. I'm sure
More importantly, the location of the software and how it is installed in the device is a red herring
Well, that's an interesting point. However, in this case, the firmware could effectively be in silicon. It's just easier to make it not be in silicon. Do you ask Intel for the rights to their Microcode? Intel/AMD CPU's (that's pretty much definitely hardware), have microcode patches.
Do you demand Transmeta software. Their CPU is a big software translation engine, but they burn their software into a piece of silicon because it executes faster.
Do you ask Intel for the plans to their CPU so you can use the Free Software concepts to fix up their CPU designs? They are nothing but big pieces of software that are turned into hardware by a very precise etch-a-sketch.
The problem is that hardware is software, and software is hardware. Especially at the level of firmware. If it's programming an FPGA, that's literally hardware that is changeable. You are configuring a bunch of AND and OR gates. If it's running an ARM, you might have a development environment.
However, if it's say the Adaptec SCSI firmware, you have a non-standard instruction set, with non-documented hardware. A non-existant tool chain. What do you want the source for? The only reason they do things in firmware, is so they can avoid soldering wires, flashing the PROM, or forcing you to physically pull the ROM and replace it if they find a problem. If they document it's behaviour and say "avoid that", it effectively becomes a hardware problem, the same as if they burned it to silicon.
Open Source is a fairly practical solution to an Engineering problem. It's applying the age old solution of scientific peer review to the world of software. The freedom is incidental, but most of the original great science was fairly publicly available. At the level you are talking about, you are beginning to approach, "Well, is it a wave, or is a particle", when discussing "is it software, or is it hardware". I mean the CPU is flash upgradeable, and I'd say the CPU is about as hardware like as hardware gets.
I agree that most of the time, all software should be open. However, in the case of the firmware, I think several different issues come up. Not the least of which are, you'll need the vendor to open the docs on the specifications of the hardware internals (this works at a lower layer then the driver does). You'll needs a tool chain for an assembler that might literally be a one-off designed in house by a hardware engineer. At some point, they'll be a layer of software, that until there is an open hardware maker that will be inheriently propritary (documenting the firmware properly essentially draws a blueprint for the hardware). The economics of the situation make no sense for the hardware makers to make it public knowledge. I'm not saying it's a good thing, but economics makes the computer world go around. The economics of hardware is what made writting software a possibility for so many of us. To blindly ignore them is naive. I wish that there was more open hardware that was actually made and sold as high quality equipment. I know I'd pay a premium for it to get hardware that was open all the way down to the traces on the board level.
Oddly enough, what this is doing, is precisely the way that the PWC/PWCX should be handled. He could have easily started shipping a module that was compiled out of tree, or as a patch, then no GPL violations happened (if you compile your own and don't distribute, there's literally nothing that is illegal you can do, it's only at the point that you distribute binaries that you get into trouble). He could have designed the other module to merely hook into it if it was loaded as opposed to designing it to require a function pointer. That was where it all went so badly wrong. If the binary only module was loaded inplace of the GPL'ed version it would have been fine. The problem was that the GPL'ed one was runtime linking to non-GPL'ed code. The code he was putting into the binary only version was clearly developed independently of Linux in the same fashion that the NVidia driver was (it was used in a different OS first, and it used essetially the same interface to the kernel as userspace does, thus passing Linus's criteria for not being a derived work).
The problem was that there was a hook there that had the sole purpose of explicitly violating the GPL. Here, the firmware isn't linking with the GPL'ed code. So it's all good. This is uploading firmware from userspace via the kernel. Requiring it to be GPL'ed is like requiring that the files I read and write be GPL'ed because they passed thru the kernel.
The firmware loading is there to resolve several pseudo GPL violations (I believe Adaptec has long strings of stuff that is a binary code that gets loaded into the firmware that people claim "we should have the source"). I've always held the believe that that code is not linking with the GPL'ed code, it is merely data as far as the kernel is concerned (you don't have to GPL the constants you use in drivers). While the firmware is intersting and it's plausible that OSS could improve it, it just saves the costs of burning a ROM in case there are bugs that have to be fixed.
This all came up not that long ago and was a possibly blocking problem with the next debian release, but they choose to overlook the problem. The firmware loading is clever because it solves several problems, and is more flexible, and moves the problem outside of the kernel, and turns it into a data problem, not a code problem.
Driver support? Really Driver support in a Corporate environment? For the home PC I could see that. However, for a corporate desktop, what precisely do you mean?
Who are you purchasing computer equipment from that you have a hard time with driver support. If that truely is the case you should switch vendors. I've got this brand new out of the box HP/Compaq desktop under my desk. Everything worked out of the box.
I've put Linux on several recent model Dell, Gateway, and IBM models (Dell and Gateway being 2-3 year old desktops, IBM we're several different laptops).
I've put Linux on everything under the sun. About the only thing you really have to worry about is what type of printer did you get. Get one that isn't a GDI (a window's printer). Everything else just works that I've thrown at it recently. Now, all the strange USB devices might not (USB desktop cameras being the one that comes to mind off hand). A number of scanners don't work under Linux, but that just takes a bit of review before hand to ensure compatibilty.
I've used scanners, printers, and digital cameras. I've connected up USB and Firewire external drives. I've used lots of sound cards, and more network cards then I want to think about. I've used plenty of different Video cards. I've used KVM's. I've used lots of SCSI and IDE cards. I've used DVD and CD burners. I've even got a TV tuner card. Floppies, Zip drives (parallel and SCSI, but no USB). I've used at least 15-20 different MoBo, and with the exception of one current NForce2 chipset, I could make everything on it work with Linux. Even the NForce2 it works, but I have to use binary only drivers for sounds and network (until I get a distro that has the forcedeth or whatever the open source driver is).
I never tried to put Linux on the old Win98 only PC. HP used to sell some machines that had propriatary sounds cards and video cards in the late 90's. You couldn't even run Win2K on them. They just didn't make the drivers for them. That was a marketing ploy, because they we're the el'cheapo machines that shipped with 98. If you wanted 2000, you had to pay a premium for those.
Whose equipment are you running into problems with (if only so I know to avoid them). Serial ATA, printers, and Firewire are the only areas where I know that I need to be careful about what I purchase. Even there, you can make it work if you are paying attention to compatibility. I've used Linux as my desktop for nearly 5 years now at work. It's been a joy (I'm a fairly hard core Linux guy, but after I did the IT work of setting up the computer, it's been a fairly low maintience experience). I'm about to roll it out to 20 desktops at our company for everyone who uses internal applications only.
If that's all you really want it for, there are a number of good tools to statically type check. Linus is working on one that is tailor made for the Linux kernel. g++ doesn't accumulate all of the information it should to realize that there is nothing wrong during a lot of warnings it prints out. Even gcc 3.4 goes overboard with it's type comparisons.
Lint, split, and the python scripts (one of the kernel janitors does this), smatch I believe is the name that process the output of the GCC RTL all do a good job, why not work on extending them. There's nothing compelling about doing the type checking in C++ it's trivial to do it in C, one can easily do that in C with external tools, or by modifing GCC specifically. Type checkers have been doing it since before C++ was even the name of C++.
Man getting you to state anything is like pulling teeth. Any chance you'll just list more then one "of the many places where I disagree with Linus"?
Type checking is the obvious one, virtual functions the other.
True enough, I didn't make that context clear. However, it's still mostly true (that C can be hornshoed into doing most everything C++ can, RTTI and the stack unwinding being the two most difficult to pull of, partial template specialization, and replacing some of the optimizations that templates can do). Operator overload is nothing but a hidden function call. Public vs private would be hard, but is merely a matter of discipline and careful usage of opaque types.
C++ can do things that would be very hard to do in C, using C++ without using most of the things in conjunction is just silly. C++ unravels once you say, well, you can't use exceptions, destructors and RAII become less useful (they are syntactically cleaner, but no less assured then below code). If you stop using templates, then operator overload and overloaded functions are just syntatic sugar too.
The first two things most people say you can't use in the kernel, are guess what? Templates and exceptions. Templates, because the sneakily lead to bloat (using more memory then you realize, I know that between that and inlining functions can lead to some huge binaries relative to the work they are really doing), and exceptions for reasons listed below. I've always found that using RTTI is just a design flaw. Inheritence is pretty cool, but again anyone willing to take the time can accomplish single inheritence pretty easily by just pounding out the code. Multiple inheritence isn't too much harder, you just have to resolve the collisions by hand. Virtual inheritience is probably pretty difficult unless you start doing sick twisted things with unions.
Most of the C++ functionality is there and it's all interlocking. Like if you don't want exceptions, constructors and destructors are simple:
#define WRAP( x ) { constructor() ; x ; destructor(); }
Works just fine in my C compiler. RAII can easily be implemented this way, just write a macro for each one that calls the functions you want called, make it take some more parameters if you want.
If you give up exceptions, that's all you need barring the usage of a "goto:". If you use goto you better darn well be aware of it (normally in Linux code, the goto is actually used as the error handler, you jump to the thing that releases all of the things you have allocated so far and exit).
#define LOCK_SECTION( y, x ) { lock( y ); x ; unlock( y ); }
There's a simple example of RAII, memory allocations could be the same.
I see exceptions as non-starter in the kernel for several reasons, adding a throw in any number of places can do a whole slew of nasty things if called in the wrong context, along with the fact that exceptions use up additional stack space with is at a premium in the kernel space (4k or 8k depending on the version, it's a serious overhead if you have lots and lots of threads so getting it to a single page was a goal for a long time).
Plus the kernel wasn't designed for the usage of exceptions, getting it from it's current state, to a state where using exceptions is stable probably not possible in the incremental fashion that Linus would require it to be (lots of small changes that take you slowly closer to being correct is the way to get things past Linus). Just adding exceptions to a normal program in sane fashion is hard, now think about adding it to something that is inheriently multithreaded and has multiple call stacks all of which might deal poorly with catching an exception they've not been programmed for.
Exceptions can't be added willy nilly. They would simplify things a great deal in some cases (but would require re-writting of a ton of core kernel code to conver it all over). The Linux kernel uses "goto:" as a general rule to simplify error handling inside of the function (all error handling goes at the end just before the last return statement, if you have an error, goto error_handler; then the error gets passed back up the call chain, un
Why is it everyone wants to bring up Turing machines like I have no idea what they are... Grr! Look, there is no feature of C++ which has an obvious advantage over the natural C construction in the Linux kernel. Please feel free to rebut that point (I've asked several people to do that, and nobody seems to want to answer an simple direct question, instead they want to explain "Turing Machines"). It won't be as pretty or as directly straightforward as the C construct, but it won't be like attempting to generate something like lexical closures in the C language.
Most linked lists have been abstracted. In an ugly manner versus the C++ way, but they also take up a heck of a lot less space then the C++ way using a naive implementation (with partial template specialization, you might be able to not use up any extra memory, but I believe the kernel doens't keep pointers to nodes in the lists, they keep the nodes in the list with the void *next being the first element of the structure).
Iterating over the lists is abstracted.
Virtual functions are an essential construct to the linux kernel (see the VFS).
Namespaces would be very, very nice to have in the kernel, but the kernel handles that by prefixes, and by linking everything in a subsystem into one.o and having specific entry points into that.o and then forget the rest of the symbols to avoid symbol collision between subsystems.
Classes aren't strictly necessary. As a general rule, by using opaque types, the Linux kernel gets the same types of encapsulation that the C++ class constructs do via this.
What is needed to improve the Linux kernel, is a language that can allow you to express rules that it needs. Like interrupt context, accessing a per CPU data structure, like recongnizing the locks being misued. Like realizing that you are not using the PCI accessing routines when you should be.
C++ doesn't do any of those things, and thus in my opinion is not an enhancement in any way to implementing it in C. There are several places where C++ does obscure things (read the standard sometime about resolving overloaded functions and types, even the standard writers aren't sure the rules aren't ambigious or handle all cases sanely). Default copy constructors, operator=, operator==, and the sheer number of places where an exception can be throw (read Exceptional C++ sometime), can all cause problems. Most of the really good stuff in C++ like the STL wouldn't be usable, as they don't fit the design requirements for datastructures in the Linux kernel (see all the standard libc stuff that is re-implemented in the kernel).
The tools that Linus is working on (which I've always wanted to write, both for the Linux kernel, and for projects at work), are the types of tools you need. Generate a call graph. Do static flow analysis and see if any rules are violated (did you call something which could call "schedule" where is unsafe). Did you call something that requires you hold a lock, while you don't hold the lock. Those are the types of tools and the functionality that will make the kernel better. More crappy type-checking, templates, and RTTI won't do any good. Generating tools which do the code flow analysis is much, much easier in C then it is in C/C++ code. Those will help generate better higher quality source in a much more measurable way then just allowing C++ to be used in a large body of software that it wasn't designed to be used in.
You are an odd fellow. I ask a simple direct question three times and you still duck it. You seem to have a habit of posting information like it is common knowledge and then fail to back it up with some type of reference or source material.
Never mind all that. You seem to be intelligent, and relatively active in this thread about C++ and it's good points. So I'd really like your opinion on one single question. Completely disreguard the other issues.
Name one compelling feature in C++ that you feel is unmaintainble in C, that would make a significant impact on the Linux Kernel and the quality of the source.
You can't use virtual functions or type checking. GCC and G++ already annoy Linus with the type checking, and the Linux kernel is a fine example of how to implement virtual functions in C. You can't take namespaces either, as while they are nice, I believe they are not "unmaintainable" without them in C.
Name one feature of C++ that is compelling and useful for the kernel that can't be accomplished in C in a maintainable fashion?
It's a simple question, one I posed before. Are you going to answer it or call me a troll for pointing that until the last 2 years, there wasn't a decent C++ compiler. The 2.4 kernel series still lits in it's documentation, that egcs-1.1.2 (which I believe corresponds to gcc-2.91), is still being supported. So it's not a completely irrelavent point.
Look for the entry that says "Enforce gcc 2.95 compiler as the minimum". Hey, look at that, right next to it that says, 19 months ago that was the minimum. So as off 19 months ago, it sorta follows that they had to support the what you seem to reguard as a substandard C++ compiler. I believe that 2.91 is still used as the compiler of choice for older Sparcs. That's during the 2.5 development kernel.
Hey, look at that, in the 2.6.0 Documentation/Changes, the required version is still 2.95.X (x>=3). So which version of the C++ compiler did you want to you?
So while you might think they are 4 years old, and unsupported, it is still the version that Linus says is the correct version of the compiler to use. You might think I'm a troll, but at least I know the details of the projects I use. *sigh*, I wish people paid attention to details once in a while. The kernel is very sensitive to the version of GCC it is compiled with. As a general rule that means they are very reluctant to require newer versions, or even support newer versions.
Actually, assembly is syntactical sugar, do in in machine code (or if your into Turing machine, with punched paper tape). It's nice of you to call me a troll, but you still have yet to state a compelling reason why C++ is a good idea to have in the Linux kernel. C++ and Objective C (I've programmed in both professionally), are very slick ways of accomplishing things that can be done in straight up C (especially Objective C). C++ is much nicer to program in then C if only because it means I never have to null terminate a string again. Given a choice, I'd never ever write a line of C again in my life.
The subset of C++ that is actually hard to do a good job of in C is nearly identically the subset that wouldn't be useable in the Linux kernel. Most of the best ideas for using C++ in the kernel are type checking and virtual functions. Type checking is already a problem (Linus points out that GCC emits spurious warnings about code that is obviously correct to anyone who takes a cursory look at the code w/ the 3.X series of GCC, it would only get worse with G++). He's writting his own set of tools to do type-checking that is tailor made for the Linux kernel.
Virtual functions are nothing but a table of function pointers. They do this all the time in the Linux kernel. I'm asking a simple question, name something besides those two features of C++ that are a tool that needs to be used in the Linux kernel that would be impossible to maintainably implement in C.
I wish they had namespaces, but that's not something that is impossible to do in
Well yes and no. C++ compilers have been broken for a long, long time. They are getting much better. I know I've run across things in C++ as recently as 2.96 compilers that are completely standards conformant, and won't compile with g++ 2.96. I'll used to develop on a 2.96 compiler and release with a 2.91 compiler. Let me tell you, that's a beast. I know I'm older versions there, but it was true circa 2001-2002 that 2.96 was the latest stable compiler released with most production quality Linux distributions.
Now, I'm a C++ fan. I'm a huge C++ fan. It's my language of choice. However, Linus is correct, "C++ is just C anyways". Go take a good long hard look at cfront (not sure if that's still current). C++ was literally convertable to C. Still is to this day to the best of my knowledge. There is absolutely no construct in C++ you can make that I can't do in C. It might not be a simple, it might not be as easy, but it can be done. Virtual tables, are nothing but fancy tables of function pointers. Templates are nothing but a simplification for writting the same code over and over. References are hidden pointers that can't be NULL (unless you trick the compiler). Exceptions, ahh, now that's harder, but even their it's nothing but a setjmp, longjmp type problem. I'm not saying they are nearly as easy or useful to write, but it is in fact true. Even constructors and destructors are nothing but code that must run. If you are careful, you can arrange for that in C. Yes it's harder, but it's not impossible.
Name a construct that has a useful application in the kernel that is in C++ that can't be easily duplicate in C with the use of arrays of function pointers and macros?
Remember useful. Anytime Linus wants to hide the implementation details, he does, he just uses an opaque type. He doesn't have to worry about references or non-references (especially not the NULL pointer checks that happen on every access of a reference with g++ 2.96 (not sure about later versions), that you have to disable to speed up the code). There are lots of hidden things going on in C++. They are grand and glorious most of the time.
The most useful constructs of C++ is the STL IMHO, and those are completely not allowed in a kernel. Too many memory allocations that happen transparently. Too many nasty bits where you can't access them in some specific context (interrupt context jumps to mind). You'd have to rewrite them yourself, and they already have an implementation of lists in the kernel that are C style templates.
C++ is syntactical sugar that makes it easier to enforce certain things. That's it. It's a better C. However, the number of people who can do it, and do it well are few and far between. A good tool (like the one Linus has been working on), that checks to see if you are following a specific set of rules, would be much more useful then attempting to graft C++ into the existing kernel. We'd be much better off to write tools that ensure you are using the API they way you are supposed to, rather then attempting to write the API so that C++ can check it. C++ has no concept of "interrupt context", it has no concept of "preemptible code", it has no concept of per-CPU data structures. Those are the things that need to be checked in a kernel. Not if you are accidently accessing a data memeber you shouldn't be.
A lot of the things that have been added to C++ aren't going to make it better for writting an OS then C is. You can write some wonderful interfaces useing just straight C. It's more complex the most part. If nothing else, I wish that the Linux kernel would use C++ just to get namespaces, but that's just me. C++ does have times when it can take templated code and optimize it better then C can due to it's more advance understanding of type , const'ness and inlineness. However, remember that kernel hackers would just write a custom version and use it when it's a measured speed problem.
Slashdot Mirror
I could probably map a macro to something like "search whole word" if I felt like it. However, I've found using "iii" to be an idiom well worth using in conjuction with vim.
Kirby
Any editor that I need to use a mouse with is defective. Mice are only good to feed cats and pick the xterm you want to use.
Kirby
Kirby
*grin*
Kirby
For the presidential election see the Constitution, Article II, Section 2, paragraph 4.
That's for Electoral College votes (only 538 of those each election). So I guess it depends on if Congress has enacted a law which would prohibit the states from using that as the "Time of chusing the Electors" (that's what we do on election day) or not. There is a similar statement covering the two houses of Congress. I'm not familiar enough with Federal Election laws to be sure what if any limits Congress has passed covering this. However, I'm guessing it's not incredibly illegal otherwise Florida couldn't have done it this year. Presumably, it's the same provision that makes Absentee ballots legal. I know several people who voted early in Nebraska (where I live). One I believe was thru a local polling place that accepted absentee ballots early when given in person.
Kirby
Now, assuming that they are in fact violating the GPL, anyone who has copyrighted material in the work can in fact force their hand. So any kernel developer can deal with this.
Looking on their site, they have in fact given lipservice to sending you a CD (they claim it won't contain their propriatary software, but if they are following the letter of the law, they should have to give you the kernel source w/ any modifications they made). The offer is down near the bottom of this page:
http://demo.mt.lv/help/license.html
This appears to be in compliance with 3b of the GPL.
If you report this on the LKML list I'm fairly sure several people would help you pursue it if you can show they are in fact violating the GPL (if they didn't modify the kernel, they aren't). If they are violating the GPL, they sure are being quiet about it. Google turns up very little about it. I've seen several threads on the LKML where people outside of Linus Torvalds pursue GPL violations. Alan Cox being on of them. Any number of people pursued Linksys.
http://lkml.org/lkml/2003/6/7/164
and
http://linux.derkeiler.com/Mailing-Lists/Kernel/20 03-09/7435.html
are examples
Kirby
Try being a really good IT person, and testing the kernel updates first, then push them to your internal YUM server individually. It's not like you wouldn't or shouldn't be doing this with Windows or Solaris.
I support 50 desktops, this isn't a complex problem. Scaling to support 300 or 3000 wouldn't phase me as long as I still only had a handful of configurations (thousands of configurations presents a problem no matter what type of solution you use).
Kirby
Why? You tell a nice little story about running 4 different binary only drivers. You represent a very, very niche market.
Of anyone I've ever read or heard of, you are absolutely unique. I've run and installed Linux on hundreds if not thousands of computers. The only binary only driver I've ever had to install is the nVidia one. Even that is merely just because I wanted better performance. I could easily use the machine just fine without it.
I've installed SCSI cards, IDE cards, RAID controllers for SCSI drives. I've installed SAN drivers. I've installed up to Gigabit cards. I've installed scanners, mice and keyboards, printers, CD burners, soundcards, USB and Firewire drives. I've had desktop cameras. I've had digital cameras that used USB connectors. I've used magneto-optical drives. Heck, the Parallel port Zip drive worked better under Linux then it did under Windows. I've hooked up flash readers. I've connected a myriad of perphials. What on earth are you connecting up to a machine that you need 4 separate binary drivers? Are you sure they aren't replaceable with a component that would have worked with drivers?
I'd much rather have the developers have the ability to fix and solve bugs rather then cludge together something that might or might not work.
For the most part, 99% of the driver API is in fact stable inside of a single kernel minor release (technical speaking 2 is the major kernel release, 4 is the minor release) kernel series (the single exception I can think of is that 2.4.10 completely broke the VM subsystem from 2.4.9). Most of the other things are merely your vendor being too lazy to get off their butt and release the binary only driver. It's not particularly hard. If what your are using doesn't support both Suse and RedHat, put down the box, and back away.
Finally, just like the Apache guys have been saying for years, "We have a lot more drivers to maintain then you do, if we change the API we have a very good reason to". It's not like Linus goes and makes changes willy nilly. Generally speaking, it's been to make the API easier to use, to refactor common parts into higher layers for code reuse, or to use a more efficient/scalable model.
You can keep saying that it really needs a decent driver model. No it doesn't. It is what it is, precisely because they refuse to have choke points to when innovation can happen. You might love it if it does. Personally, I like it not having choke points. I review the hardware I plan on hooking up to a machine, and ensure that all the perphials do what I need them to do, and that they are usable under the OS I run.
Next you'll complain because your x86 machine doesn't support Nubus, or Altivec instructions. Pick things that have OS drivers and your problems go away.
Lastly, you are complaining to the wrong guy. Linus isn't your man there. Try complaining about the distributors. The distro people are the ones who make the actual final release you are using. They could just wait until tail end of the kernel life cycle and release it then with a stable API. They could maintain a stable API for you. However, you are not common in terms of users. If everyone clamoured for it, they'd get it. Heck, if that's really what you want, start using the 2.2 series kernel. It has a world class stable driver API. The problem is Linux moves fast and you want to stay with the cutting edge. It's not Window's is releasing their development stuff as early or as often as Linux is. I'm fairly sure that by the time you get the Windows kernel, it's probably similar to roughly where the 2.4 kernel is right now (maybe 6 months or a year ago). By the time you get Windows software, it's old and stale (in terms of true innovation and change, Microsoft is fairly serious about limiting architectural change, just like the 2.2 and 2.4 guys are right about now). Pick what you want.
Kirby
The gold master only needs to be good enough to read it once.
I burn ISO's of linux distros all the time, with the CD's I pickup using a Sony CD burner. In all that time, I think I've had a half dozen coasters. Generally your biggest problem, is the CD you are reading it on is crappy (not the burner). A lot of laptops or slimline CD's that go into 1U server or speciality small machines have a very low tolerance for error and are very sensitive to reading burned CD's. Just like CD's from pre-burner days have trouble with CDR's, and lots of trouble with CDRW's.
If you are burning them yourself, this makes sense, go get a high quality CD duplicator (stand alone machines that take spools of CD's). Use a name brand (Memorex I've had good luck with, Verbatim's I tend to stay away from if I'm paying attention, but that's an old, old bias, pickup a name brand and generally you'll be fine). If not, go pay someone with the proper tools to do it. Ten years ago, it was $1000 for the master, a buck a disk when I was looking to get CD's made when a burner was about $4K for the drive, and $20 for a blank CD. I'd guess the stamped price has stayed roughly the same, maybe gone up a little in price.
Kirby
Really in RedHat Linux or in RedHat Enterprise Linux? They do if Fedora, but Fedora is a known broken tool (it's a shiny nifty looking tool, but broken as far as using for Enterprise quality Linux distros). I'd really like to see any anecdotes or documentation showing that RH broke the API/ABI inside the same series. As a matter of fact, they do support an ABI (which is a stronger guarantee then an API), ABI's are a binary compatibility, where as API's are a source level compatibility, except for incredibly exceptional circumstances where the security fix cannot be implemented short of changing the ABI (think somebody figured out how to factor big numbers in O(1)). You know like the RPC problems that Windows had in NT 4.0 that MS just refused to fix because there was no compatible way to fix the security flaw. RedHat backports security fixes to the version of the software they released.
If you are making a reference towards RH not supporting a single ABI inside of the kernel and breaking 3rd party modules, that's accurate. However, that's a fundamental issue with the kernel (not, it's not a problem, just an issue). I never use binary only drivers with the single exception of the nVidia drivers for home desktop machines. If that is what you are making a reference towards, even Debian can't solve that.
I've never known RH to break an ABI or API inside of the same major release series, let alone inside of the point release. That is the beauty of RH updates. They can be upgraded with a high confidence they won't break the ABI. In fact, the old rule was that if the ABI changed they incremented the major version (which is why 8.0 didn't have any point releases). It's why they always release the 7.x RPM's when they release security fixes. (glibc and the kernel being the major components of the ABI).
With only a single exception, I've never seen a RedHat RPM break anything if installed on the version of RH it was packaged for. The single exception, was the bind-chroot package. If you upgraded the bind package and you had installed bind-chroot, it moved the original configuration files and installed the default ones again. All you had to do was go move the configuration files back and it was fixed. I believe that was a total of ten minutes of downtime for me. That's in about 5 years of running RedHat as the core of our enterprise, and about 3-4 years before that (I've been running RedHat regularly since the 5.x series, but I know I ran a 4.x series that came with a RH book I picked up ages ago).
Read up on RedHat's backport policy
I'm highly curious to hear what your experience is with this. I've never used Debian, mainly because all the problems I've had with RedHat over the years have slowly been fixed. Debian only had one serious advantage in that apt-get was an easy way out of RPM hell. Now I just use White Box Enterprise Linux, it has yum installed. I'm happy as a clam. We run it for all of our non-Oracle machines. We save a ton on licensing, and have very few problems (all of which are problems that would have existed if we purchased RHEL).
Kirby
I know people who are into this sort of thing. In fact, I ended up doing it once accidently long ago. Our floppy drive broke, I bought a new one at BB. I took it home and started trouble shooting it. I wrote a floppy on it with my only copy of some important data. I worked a day or two longer and my drive failed. I returned the drive as defective. I tried the original floppy drive in a different machine. Worked fine. I ended up calling Dell tech support to find out what to do with this machine, and if there was any way to get the data off the floppy. He said to go get the drive it was written with. It'd be the last chance I had to read the data. I walked into the BB store, about 24 hours after returning the drive and bought it for about 33% off (I offered to pay full price, but they said it was too much paper work). It still didn't work, but I kept the drive.
Interestingly enough, during that same transaction, I ended up working a different scam entirely because the girl at the counter wasn't paying attention (it was her mistake, not mine I walked back in the store and paid the difference). I bought the floppy drive and a PS/2 extension cord at the same time. They had the wrong gender. When I did the return, I walked back picked up the cable I needed and returned the drive. She ended up creditting me for the drive and for the cable I left the building with. She assumed I was returning both because both items matched the description on the receipt. The way to do this correctly, is buy two items, one cheaper then the other. Walk in, get your stuff tagged by security. Go get the more expensive item in the store. Put the cheap one back on the shelf. Return the expensive one for your money back. Buy a half dozen other items while pushing a cart.
If you are good at this, and live in a large enough city. I'd bet I could several thousand dollars a week doing this. Tax free. I'm not sure what you take home for pay, but I'd be thrilled to take that home. It's not hard to make a living being a fraudster. If you can work eBay, pawn shops, and a scams like this, I'm willing to bet I could make a lot more money then I currently do with a lot less work.
I'd never do it, but I did work retail at Babbage's for a while. I had to spot shop-lifters, and always be aware of what was going on at the cash register. Never get flustered.
I believe BB caught on to this eventually, as now I believe security walks returns to the return counter.
I've know people who steal (it's a friend of a friend, he's a pretty cool guy, except he's got fairly questionable ethics), and sell drugs for a living. He thinks the same way a lot of people who've responded to me in this thread. Screw'em, they're a corporation, they screw me, I'll screw them.
As a general rule, mail in rebates merely require you to send in the original reciept. Generally after you return something, if it's the only item, just ask the cashier for it, they'll hand it to you. If there are two items, they have to give it back to you. I've never had to send in a UPC code, and to be honest, I've never had anyone actually check anything I've returned that closely to see if the UPC code was still there.
I guy I know used to buy stuff with cash, go to where he worked, empty the contents of the computer games, put a deck of cards in it, then go to work and re-shrink wrap the box. He'd return it to Best Buy "un-opened". I worked with him at Babbage's (where he could have just taken the games home for free and played them for a week, it was store policy, that's why we had the shrink wrap gun). The sickest part was when he started doing this for a fee for people who had heard about it. Best Buy actually started calling around to places know to have shrink wrap guns (there we're 3 or 4 in the shopping center). They talked with him, and he played coy about it. He was still the manager there until the store was closed down 2-3 years later (about 8 years ago).
Kirby
Well they murderd my brother, so it must be okay for me to murder their brother.... That's the sort of vigilanttism you're logically using. Repeat after me: "Two wrongs does not make a right".
Sometimes being a decent human being is tough, but try it sometime it's really not that hard. Maybe I'm just the last human being that walks back into the store when I realize they gave me too much change and gives them back the money.
Go look up the stats on it sometime. Corporations on the NYSE generate about $2000 profit per person in the US in aggregate. Corportations have to work really hard to earn a profit. If we had to live off of corporate profits, we'd be a third world nation by current standards. (Some of this is because of fat cat CEO's, but I'm betting it still wouldn't be pretty thru their salary into profits). So while you think "the man is screwing me", if you had to work half as hard as a corporation does to survive, you'd bitch about how hard life is.
As long as you don't complain when all sales are final, I don't care. I really like being able to return things if there's a problem, or if there's nothing defective about the product, but it just doesn't work with what I want it to do (I've had this happen with incompatible hardware and software back in the bad old days of manually setting IRQ/Base IO ports), the hardware just wasn't going to work for me. I returned it explaining that. Or letting me exchange cables because I forgot to get the ones with the correct gender because I was in a hurry.
If I was Best Buy, I'd establish a "Absolutely No Returns Policy". You can check to see if it's damaged in the store. Other then that, if you leave the building with it and it's broken, you get to keep all the pieces. That's the logical result of such a system.
Kirby
They get to book the full purchase price today, and not have to book the rebate until the following quarter (most of the time). They get the interest of it (while it doesn't sound like a lot, for Best Buy, I'll bet it's not chump change if you aggregate the total interest). Finally Mail in Rebates are one of the few sane ways to ensure they don't sell you 10 of the loss leaders at below cost. (A super market I worked at when I was younger used to lose it's shirt on some sales like that where people would just come back in time after time. They finally established a minimum purchase to get the discount, and that was enforced only if the cashier was paying attention). You can only have one rebate per address. It's much more effective then attempting to track who has or hasn't purchased it at a deep discount on a previous trip, or a trip to a different store. This is always a problem for me, as I mirror harddrives. I can only get one drive at the discounted price.
Kirby
People are abusing those benefits Best Buy provides. Now, I think the Mail in Rebates are bogus. I really wish it was required that they put the price I have to pay when I get to the counter on the price tag (I know CompUSA is notorious for this, not sure about Best Buy).
Now, forcing people to honor their advertising about price matching. That I've got no problems with the customer doing. If Best Buy doesn't want to have to lower the price, they shouldn't have advertised it as part of their pricing. I don't know if Best Buy does this, but I know that I've heard some places have branded models that are only sold by a particular chain. They sell identical systems to 3-4 chains, but each chain has it's own model number. Thus they can claim that a competitor with a lower pice isn't exactly the same model, so the guarantee doesn't apply. That's crappy, but I'm not sure if that has any bearing on this article.
I know I don't like them discussion that people "buying up all the loss leaders" are a problem. Especially when they are discussing that people are re-selling the items on e-bay. That is capitalism at it's finest. The market is being highly efficient there, they just need to realize that communication and on-line auctioning have forced retailers to be more price competitive. The world has moved on, and this is a point at which Best Buy is just being left behind (the fact that people will buy it for cost plus shipping, means either people are stupid, or Best Buy is taking a serious beating on the pricing). If Best Buy corporate had any brains, they'd setup small retailers to just sell them directly over eBay and move lots of items that way to see if they can benefit from the insanity of the purchasers.
Retail is generally a very inefficient way to sell things. There's only a single price for everyone. They'd be much better off with auction style pricing (the optimal price is found in a good market). People pay what they believe something is worth, and the store gets the maximal amount of money the market will bear. As long as there are plenty of buyers for any given item, they'd probably get a better price then they do with the shelf price. Plus it wouldn't have to be trucked around the country, and they wouldn't need as much retail space.
I don't like what they are talking about in terms of profiling. Part of my problem, is well, I don't dress my income. I had the same problem when purchasing a vehicle. Fortuantely when I went to get a house, I did the loan info over the phone. Sometimes it is nice to just be a number.
Now, Best Buy's claim that 20% of their customers are doing this sort of thing is just silly. I'm highly doubtful that it is that rampant (it might be 20% of their transactions, but not 20% of their customers).
Kirby
You are being silly. Go read up on the definition of "derived work" and "linking". Then read the GPL very closely. You'll notice that the firmware of a PCI card doesn't even execute on the same CPU architecture, let alone in the same address space (the rule of thumb amout if you are "linking" or not). When you get done figuring that out, realize that because the firmware was independently developed outside of the Linux kernel, and it works completely independently of the Linux kernel, it's not a derived work. Thus it's pretty much in the free and clear of all GPL issues. The actual binary bits in the kernel you are free to change to your hearts content with full GPL rights.
That's why firmware can be inside of the Linux kernel now. Some people want to move it outside of the Linux kernel (for both technical and political reasons). The technical being, that you can upgrade the firmware without re-compiling your kernel, and it shrinks the size of the kernel to not have it statically compiled in. The political is that so dolts like you don't say "That's a GPL violation". It isn't. The firmware isn't a derived work, and it isn't a linking to a GPL'ed piece of code. It's just data as far as the kernel is concerned. Just like the C code that passes thru a GCC is just data. Yes technically speaking it is source code, but it's just data. It's just like saying, well in order to initialize this card, you have to write a "0x80" to this port to get it configured correctly. In this case, instead of a single byte, it could be a 10-64k chunk of bytes. It's the same thing. They are going to make it blazingly obvious by moving it outside of the source tree so it acts just like the GCC code does in every single way. Then we can finally be finished with this argument. That's why the 2.6 kernel is building all of the infrastructure so that firmware can be loaded from user space. Then as long as the vendors say the firmware can be distributed for free, it's all good (which is what Theo is attempting to make happen).
Even if the OpenBSD and Linux people got the source to the firmware GPL'ed, there's no way in hell they'd ship source you had to compile. You'd still get a binary distributed to you. That would require you to have a development tool chain for whatever language (compiler for the language, assembler for the target architecture, and possibly a linker for the object format). Some or all of which literally might not exist outside of the company. It's not like Adaptec is using an x86 OBJ from C source for writting it's firmware. They might, but I wouldn't be shocked to find out they use a PIC with a propriatry C compiler from an embedded vendor. That would be a dependency the Linux kernel folks wouldn't allow for building a kernel.
Kirby
Uhhh you must have some mysterious insight into the past about computers I lack. I wasn't around in the 1960's (wasn't terribly aware of computers until sometime in the 1990's). Can you describe how it used to work for me, as opposed to saying "it wasn't this way".
However, from what I've read, sure you got the source for the OS. Back then, you *rented* computer equipment a lot of the time (I believe that was IBM's original business model). I'm not sure precisely how long that lasted. However, back then, you bought computer equipment for $100K (which was a lot more money back then it is now). It took up the size of a room, and non of the software was runable on any other piece of equipment from someone besides that vendor. Heck, you could get a copy of UNIX source way back in the mid 70's. You could modify it, you could do whatever you wanted with it, except for give your copy to someone who didn't have a license. I've never known any company that allowed you to give away their software to someone who didn't have a license (some companies might have let you exchange fixes, but I'm fairly sure none of them let you give their software to anyone else, if they did that might be a clue as none of them that kept that policy are still in business).
When a piece of hardware broke, or had bad firmware, they sent a guy in a suit out to swap out the part (as opposed to shipping you the new firmware like they would today). You paid maintience on your computers that was on the order of 20% of the value of the computer. You had to pay fees and service. IBM shipped absolutely identical printers for two different models. One model printed twice as fast as the other, the only difference was a jumper setting.
When a part broke you had one vendor you could get a part from. When a disk drive went bad, you had one vendor you could get a replacement from.
Those we're the bad old days. I'm fairly sure that if you actually got what you wanted, you'd scream bloody murder to get back to the current situation. Unless you are just that much of a masochaist, or you have an ample supply of money.
You might not be aware of this, but computers used to be worth real money. I don't mean that $3,000 USD I paid in 1995 for a Gateway, I mean, in 1970, you could easily spend $250K (which is several million in todays dollars) on what was an entry level mini. When the transactions are that large, copyright violations are small deal. Hardware was expensive, and software was cheap. Programmer time was worth nothing, and computers were worth a lot (read "The Mythical Man Month", that was said by the guy who was in charge of the single largest computer development in the history of man during "the good old days").
You not believing that economics work that way based on the past is like closing your eyes and denying that I exist because you can't see me. Well, I don't believe that more then 10% of the world's population can not farm and have sustainable living. It didn't use to be that way. At one point in the point in the past, we are both highly accurate. Mine being a much longer time ago then yours. The world has passed you by while you were not paying attention.
You can try and present why it this is not the only sort of economy that would work, but you can't do it by pointing at the past and saying "see it used to be that way". The world changes, and it changes fast. Especially in the area of computing. The major change you missed was that fabricating hardware is cheap, while fabricating software is expensive. That's were the economic model changed that you apparently are in willful self-denial about.
Economics of the world is fairly vicious, if there was a better way, just describe it to people who are incredibly rich how it's better. It'll happen. They stand to make a lot of money making it happen. I'm sure
Well, that's an interesting point. However, in this case, the firmware could effectively be in silicon. It's just easier to make it not be in silicon. Do you ask Intel for the rights to their Microcode? Intel/AMD CPU's (that's pretty much definitely hardware), have microcode patches.
Do you demand Transmeta software. Their CPU is a big software translation engine, but they burn their software into a piece of silicon because it executes faster.
Do you ask Intel for the plans to their CPU so you can use the Free Software concepts to fix up their CPU designs? They are nothing but big pieces of software that are turned into hardware by a very precise etch-a-sketch.
The problem is that hardware is software, and software is hardware. Especially at the level of firmware. If it's programming an FPGA, that's literally hardware that is changeable. You are configuring a bunch of AND and OR gates. If it's running an ARM, you might have a development environment.
However, if it's say the Adaptec SCSI firmware, you have a non-standard instruction set, with non-documented hardware. A non-existant tool chain. What do you want the source for? The only reason they do things in firmware, is so they can avoid soldering wires, flashing the PROM, or forcing you to physically pull the ROM and replace it if they find a problem. If they document it's behaviour and say "avoid that", it effectively becomes a hardware problem, the same as if they burned it to silicon.
Open Source is a fairly practical solution to an Engineering problem. It's applying the age old solution of scientific peer review to the world of software. The freedom is incidental, but most of the original great science was fairly publicly available. At the level you are talking about, you are beginning to approach, "Well, is it a wave, or is a particle", when discussing "is it software, or is it hardware". I mean the CPU is flash upgradeable, and I'd say the CPU is about as hardware like as hardware gets.
I agree that most of the time, all software should be open. However, in the case of the firmware, I think several different issues come up. Not the least of which are, you'll need the vendor to open the docs on the specifications of the hardware internals (this works at a lower layer then the driver does). You'll needs a tool chain for an assembler that might literally be a one-off designed in house by a hardware engineer. At some point, they'll be a layer of software, that until there is an open hardware maker that will be inheriently propritary (documenting the firmware properly essentially draws a blueprint for the hardware). The economics of the situation make no sense for the hardware makers to make it public knowledge. I'm not saying it's a good thing, but economics makes the computer world go around. The economics of hardware is what made writting software a possibility for so many of us. To blindly ignore them is naive. I wish that there was more open hardware that was actually made and sold as high quality equipment. I know I'd pay a premium for it to get hardware that was open all the way down to the traces on the board level.
Kirby
The problem was that there was a hook there that had the sole purpose of explicitly violating the GPL. Here, the firmware isn't linking with the GPL'ed code. So it's all good. This is uploading firmware from userspace via the kernel. Requiring it to be GPL'ed is like requiring that the files I read and write be GPL'ed because they passed thru the kernel.
The firmware loading is there to resolve several pseudo GPL violations (I believe Adaptec has long strings of stuff that is a binary code that gets loaded into the firmware that people claim "we should have the source"). I've always held the believe that that code is not linking with the GPL'ed code, it is merely data as far as the kernel is concerned (you don't have to GPL the constants you use in drivers). While the firmware is intersting and it's plausible that OSS could improve it, it just saves the costs of burning a ROM in case there are bugs that have to be fixed.
This all came up not that long ago and was a possibly blocking problem with the next debian release, but they choose to overlook the problem. The firmware loading is clever because it solves several problems, and is more flexible, and moves the problem outside of the kernel, and turns it into a data problem, not a code problem.
Kirby
Who are you purchasing computer equipment from that you have a hard time with driver support. If that truely is the case you should switch vendors. I've got this brand new out of the box HP/Compaq desktop under my desk. Everything worked out of the box.
I've put Linux on several recent model Dell, Gateway, and IBM models (Dell and Gateway being 2-3 year old desktops, IBM we're several different laptops).
I've put Linux on everything under the sun. About the only thing you really have to worry about is what type of printer did you get. Get one that isn't a GDI (a window's printer). Everything else just works that I've thrown at it recently. Now, all the strange USB devices might not (USB desktop cameras being the one that comes to mind off hand). A number of scanners don't work under Linux, but that just takes a bit of review before hand to ensure compatibilty.
I've used scanners, printers, and digital cameras. I've connected up USB and Firewire external drives. I've used lots of sound cards, and more network cards then I want to think about. I've used plenty of different Video cards. I've used KVM's. I've used lots of SCSI and IDE cards. I've used DVD and CD burners. I've even got a TV tuner card. Floppies, Zip drives (parallel and SCSI, but no USB). I've used at least 15-20 different MoBo, and with the exception of one current NForce2 chipset, I could make everything on it work with Linux. Even the NForce2 it works, but I have to use binary only drivers for sounds and network (until I get a distro that has the forcedeth or whatever the open source driver is).
I never tried to put Linux on the old Win98 only PC. HP used to sell some machines that had propriatary sounds cards and video cards in the late 90's. You couldn't even run Win2K on them. They just didn't make the drivers for them. That was a marketing ploy, because they we're the el'cheapo machines that shipped with 98. If you wanted 2000, you had to pay a premium for those.
Whose equipment are you running into problems with (if only so I know to avoid them). Serial ATA, printers, and Firewire are the only areas where I know that I need to be careful about what I purchase. Even there, you can make it work if you are paying attention to compatibility. I've used Linux as my desktop for nearly 5 years now at work. It's been a joy (I'm a fairly hard core Linux guy, but after I did the IT work of setting up the computer, it's been a fairly low maintience experience). I'm about to roll it out to 20 desktops at our company for everyone who uses internal applications only.
Kirby
Lint, split, and the python scripts (one of the kernel janitors does this), smatch I believe is the name that process the output of the GCC RTL all do a good job, why not work on extending them. There's nothing compelling about doing the type checking in C++ it's trivial to do it in C, one can easily do that in C with external tools, or by modifing GCC specifically. Type checkers have been doing it since before C++ was even the name of C++.
Man getting you to state anything is like pulling teeth. Any chance you'll just list more then one "of the many places where I disagree with Linus"?
Type checking is the obvious one, virtual functions the other.
Kirby
C++ can do things that would be very hard to do in C, using C++ without using most of the things in conjunction is just silly. C++ unravels once you say, well, you can't use exceptions, destructors and RAII become less useful (they are syntactically cleaner, but no less assured then below code). If you stop using templates, then operator overload and overloaded functions are just syntatic sugar too.
The first two things most people say you can't use in the kernel, are guess what? Templates and exceptions. Templates, because the sneakily lead to bloat (using more memory then you realize, I know that between that and inlining functions can lead to some huge binaries relative to the work they are really doing), and exceptions for reasons listed below. I've always found that using RTTI is just a design flaw. Inheritence is pretty cool, but again anyone willing to take the time can accomplish single inheritence pretty easily by just pounding out the code. Multiple inheritence isn't too much harder, you just have to resolve the collisions by hand. Virtual inheritience is probably pretty difficult unless you start doing sick twisted things with unions.
Most of the C++ functionality is there and it's all interlocking. Like if you don't want exceptions, constructors and destructors are simple:
Works just fine in my C compiler. RAII can easily be implemented this way, just write a macro for each one that calls the functions you want called, make it take some more parameters if you want.
If you give up exceptions, that's all you need barring the usage of a "goto:". If you use goto you better darn well be aware of it (normally in Linux code, the goto is actually used as the error handler, you jump to the thing that releases all of the things you have allocated so far and exit).
There's a simple example of RAII, memory allocations could be the same.
I see exceptions as non-starter in the kernel for several reasons, adding a throw in any number of places can do a whole slew of nasty things if called in the wrong context, along with the fact that exceptions use up additional stack space with is at a premium in the kernel space (4k or 8k depending on the version, it's a serious overhead if you have lots and lots of threads so getting it to a single page was a goal for a long time).
Plus the kernel wasn't designed for the usage of exceptions, getting it from it's current state, to a state where using exceptions is stable probably not possible in the incremental fashion that Linus would require it to be (lots of small changes that take you slowly closer to being correct is the way to get things past Linus). Just adding exceptions to a normal program in sane fashion is hard, now think about adding it to something that is inheriently multithreaded and has multiple call stacks all of which might deal poorly with catching an exception they've not been programmed for.
Exceptions can't be added willy nilly. They would simplify things a great deal in some cases (but would require re-writting of a ton of core kernel code to conver it all over). The Linux kernel uses "goto:" as a general rule to simplify error handling inside of the function (all error handling goes at the end just before the last return statement, if you have an error, goto error_handler; then the error gets passed back up the call chain, un
Most linked lists have been abstracted. In an ugly manner versus the C++ way, but they also take up a heck of a lot less space then the C++ way using a naive implementation (with partial template specialization, you might be able to not use up any extra memory, but I believe the kernel doens't keep pointers to nodes in the lists, they keep the nodes in the list with the void *next being the first element of the structure).
Iterating over the lists is abstracted.
Virtual functions are an essential construct to the linux kernel (see the VFS).
Namespaces would be very, very nice to have in the kernel, but the kernel handles that by prefixes, and by linking everything in a subsystem into one .o and having specific entry points into that .o and then forget the rest of the symbols to avoid symbol collision between subsystems.
Classes aren't strictly necessary. As a general rule, by using opaque types, the Linux kernel gets the same types of encapsulation that the C++ class constructs do via this.
What is needed to improve the Linux kernel, is a language that can allow you to express rules that it needs. Like interrupt context, accessing a per CPU data structure, like recongnizing the locks being misued. Like realizing that you are not using the PCI accessing routines when you should be.
C++ doesn't do any of those things, and thus in my opinion is not an enhancement in any way to implementing it in C. There are several places where C++ does obscure things (read the standard sometime about resolving overloaded functions and types, even the standard writers aren't sure the rules aren't ambigious or handle all cases sanely). Default copy constructors, operator=, operator==, and the sheer number of places where an exception can be throw (read Exceptional C++ sometime), can all cause problems. Most of the really good stuff in C++ like the STL wouldn't be usable, as they don't fit the design requirements for datastructures in the Linux kernel (see all the standard libc stuff that is re-implemented in the kernel).
The tools that Linus is working on (which I've always wanted to write, both for the Linux kernel, and for projects at work), are the types of tools you need. Generate a call graph. Do static flow analysis and see if any rules are violated (did you call something which could call "schedule" where is unsafe). Did you call something that requires you hold a lock, while you don't hold the lock. Those are the types of tools and the functionality that will make the kernel better. More crappy type-checking, templates, and RTTI won't do any good. Generating tools which do the code flow analysis is much, much easier in C then it is in C/C++ code. Those will help generate better higher quality source in a much more measurable way then just allowing C++ to be used in a large body of software that it wasn't designed to be used in.
Kirby
Never mind all that. You seem to be intelligent, and relatively active in this thread about C++ and it's good points. So I'd really like your opinion on one single question. Completely disreguard the other issues.
Name one compelling feature in C++ that you feel is unmaintainble in C, that would make a significant impact on the Linux Kernel and the quality of the source.
You can't use virtual functions or type checking. GCC and G++ already annoy Linus with the type checking, and the Linux kernel is a fine example of how to implement virtual functions in C. You can't take namespaces either, as while they are nice, I believe they are not "unmaintainable" without them in C.
Kirby
Name one feature of C++ that is compelling and useful for the kernel that can't be accomplished in C in a maintainable fashion?
It's a simple question, one I posed before. Are you going to answer it or call me a troll for pointing that until the last 2 years, there wasn't a decent C++ compiler. The 2.4 kernel series still lits in it's documentation, that egcs-1.1.2 (which I believe corresponds to gcc-2.91), is still being supported. So it's not a completely irrelavent point.
http://linux.bkbits.net:8080/linux-2.5/hist/Docume ntation/Changes?nav=index.html%7Csrc/%7Csrc/Docume ntation
Look for the entry that says "Enforce gcc 2.95 compiler as the minimum". Hey, look at that, right next to it that says, 19 months ago that was the minimum. So as off 19 months ago, it sorta follows that they had to support the what you seem to reguard as a substandard C++ compiler. I believe that 2.91 is still used as the compiler of choice for older Sparcs. That's during the 2.5 development kernel.
http://linux.bkbits.net:8080/linux-2.5/anno/Docume ntation/Changes@1.33?nav=index.html%7Csrc/%7Csrc/D ocumentation%7Chist/Documentation/Changes%7Cdiffs/ Documentation/Changes@1.33
Hey, look at that, in the 2.6.0 Documentation/Changes, the required version is still 2.95.X (x>=3). So which version of the C++ compiler did you want to you?
So while you might think they are 4 years old, and unsupported, it is still the version that Linus says is the correct version of the compiler to use. You might think I'm a troll, but at least I know the details of the projects I use. *sigh*, I wish people paid attention to details once in a while. The kernel is very sensitive to the version of GCC it is compiled with. As a general rule that means they are very reluctant to require newer versions, or even support newer versions.
Actually, assembly is syntactical sugar, do in in machine code (or if your into Turing machine, with punched paper tape). It's nice of you to call me a troll, but you still have yet to state a compelling reason why C++ is a good idea to have in the Linux kernel. C++ and Objective C (I've programmed in both professionally), are very slick ways of accomplishing things that can be done in straight up C (especially Objective C). C++ is much nicer to program in then C if only because it means I never have to null terminate a string again. Given a choice, I'd never ever write a line of C again in my life.
The subset of C++ that is actually hard to do a good job of in C is nearly identically the subset that wouldn't be useable in the Linux kernel. Most of the best ideas for using C++ in the kernel are type checking and virtual functions. Type checking is already a problem (Linus points out that GCC emits spurious warnings about code that is obviously correct to anyone who takes a cursory look at the code w/ the 3.X series of GCC, it would only get worse with G++). He's writting his own set of tools to do type-checking that is tailor made for the Linux kernel.
http://www.kerneltraffic.org/kernel-traffic/kt2004 1019_278.html#5
Virtual functions are nothing but a table of function pointers. They do this all the time in the Linux kernel. I'm asking a simple question, name something besides those two features of C++ that are a tool that needs to be used in the Linux kernel that would be impossible to maintainably implement in C.
I wish they had namespaces, but that's not something that is impossible to do in
Now, I'm a C++ fan. I'm a huge C++ fan. It's my language of choice. However, Linus is correct, "C++ is just C anyways". Go take a good long hard look at cfront (not sure if that's still current). C++ was literally convertable to C. Still is to this day to the best of my knowledge. There is absolutely no construct in C++ you can make that I can't do in C. It might not be a simple, it might not be as easy, but it can be done. Virtual tables, are nothing but fancy tables of function pointers. Templates are nothing but a simplification for writting the same code over and over. References are hidden pointers that can't be NULL (unless you trick the compiler). Exceptions, ahh, now that's harder, but even their it's nothing but a setjmp, longjmp type problem. I'm not saying they are nearly as easy or useful to write, but it is in fact true. Even constructors and destructors are nothing but code that must run. If you are careful, you can arrange for that in C. Yes it's harder, but it's not impossible.
Name a construct that has a useful application in the kernel that is in C++ that can't be easily duplicate in C with the use of arrays of function pointers and macros?
Remember useful. Anytime Linus wants to hide the implementation details, he does, he just uses an opaque type. He doesn't have to worry about references or non-references (especially not the NULL pointer checks that happen on every access of a reference with g++ 2.96 (not sure about later versions), that you have to disable to speed up the code). There are lots of hidden things going on in C++. They are grand and glorious most of the time.
The most useful constructs of C++ is the STL IMHO, and those are completely not allowed in a kernel. Too many memory allocations that happen transparently. Too many nasty bits where you can't access them in some specific context (interrupt context jumps to mind). You'd have to rewrite them yourself, and they already have an implementation of lists in the kernel that are C style templates.
C++ is syntactical sugar that makes it easier to enforce certain things. That's it. It's a better C. However, the number of people who can do it, and do it well are few and far between. A good tool (like the one Linus has been working on), that checks to see if you are following a specific set of rules, would be much more useful then attempting to graft C++ into the existing kernel. We'd be much better off to write tools that ensure you are using the API they way you are supposed to, rather then attempting to write the API so that C++ can check it. C++ has no concept of "interrupt context", it has no concept of "preemptible code", it has no concept of per-CPU data structures. Those are the things that need to be checked in a kernel. Not if you are accidently accessing a data memeber you shouldn't be.
A lot of the things that have been added to C++ aren't going to make it better for writting an OS then C is. You can write some wonderful interfaces useing just straight C. It's more complex the most part. If nothing else, I wish that the Linux kernel would use C++ just to get namespaces, but that's just me. C++ does have times when it can take templated code and optimize it better then C can due to it's more advance understanding of type , const'ness and inlineness. However, remember that kernel hackers would just write a custom version and use it when it's a measured speed problem.
Kirby