Really minor nitpick: actually the last MS-DOS is V8.0, that's what's underneath Win Me. Yes I know I'm the only one running Win Me (precisely because it has DOS) but that doesn't mean it doesn't exist!
My main product is a DOS application (well I sell Linux and Win32 versions too but customers who care about device support get the DOS one, plus I price it to encourage DOS use since support is much easier) which for some reason doesn't work under FreeDOS (the "open file" calls fail, of all things, but I can't duplicate it in real-mode code). It does work fine under MS-DOS, PC-DOS, DR-DOS, and the usual DOS boxes (it's been so long since I tested ROM-DOS or PTS-DOS that I've forgotten what happened), so it's hard to feel like it's my fault. Really diminishes my respect for FreeDOS though. Also their COMMAND.COM doesn't accept commands like "dir.txt" which worked on every version of real DOS (and are heavily programmed into my fingers), so I wonder if some of the developers weren't even DOS users? DOS is all about the nitpicky details (since it was so crude that we all had to commit some horrible atrocities to make our programs actually get work done) so they can't skimp on stuff like this.
My understanding is that the patent only covers the LFN extension to the FAT directory structure. The rest of the FAT spec is free. So a regular DOS clone wouldn't violate it. But it sounds like yes, FreeDOS does violate it. But so does Linux and which one do you think M$ will go after first, if/when they get around to it? (Never mind why they felt like patenting such a hideous hack in the first place -- OK so it's non-obvious but the reason it's non-obvious is because it isn't as useful as a more obvious method, so it shouldn't have been patentable.)
I just read an article claiming that Pluto and its largest moon have their days synchronized with the moon's orbit so they're always facing each other with the same side. If that's true, why waste our tax money providing yet another way to get into Earth orbit -- that's been done to death. We should build a bridge between Pluto and Charon! Or at least a tether. I mean we all know the real reason Pluto got demoted as a planet was because it was discovered by an American (hasn't cleared its orbit because of Neptune? oh please, Neptune's the one that hasn't cleared its own orbit), so we might as well just claim it as ours and have some fun with it, no one else wants it anyway. Plus, I'm sure Bush would favor building a forward base to protect us against the Vogons, as an excuse to transfer half my paycheck directly to Lockheed from now on.
Someone asked, what about planes hitting the space elevator? Well screw planes, what about satellites in low orbits? It would be a long shot, but if one hit it would hit hard.
Finally, what's this thing supposed to sit on? I know a lot of it isn't supposed to weigh much (even though I'm too ignorant to understand why not, only the far endpoint is actually in orbit, the rest is going the wrong speed for its altitude), but the first few miles sure would. You can't just pour a concrete footing and then put near-infinite weight on it, it'll just drill itself into the Earth's surface. We'll be lucky if the Earth doesn't crack open like an egg! Well I guess we could spread the load out, maybe build a frame all the way around and balance it with another space elevator on the flip side of the world. I mean we didn't even get the Big Dig right and we're talking about this, might as well think big since we know we're kidding ourselves (except for the part about blowing our tax money, that's real).
I don't think you can really go wrong. It would be cool to be close enough to see the launch tower etc. but it's a pretty good show from anywhere. I was at Disneyworld with my wife in 1997 and the night of a launch we hopped in the car and headed east, hoping we'd find our way to a good vantage point. Well we got behind schedule and were still an hour away when the time came, so we pulled over (so did a lot of other cars) and turned on the radio so we'd know when to squint and look for a bright dot in the distance. Yeah right, it was like the rising sun!!! It was great. And just when the radio said they were dumping the external tanks we saw a couple of dots drop away, very very cool. So anyway after that I started to suspect that the US space program may not be a hoax after all, they sure as hell launched something and if it wasn't going to space, it wasn't for lack of trying.
Somehow I doubt that porting my stuff from IA32 to x86-64 will be worse than the port from real mode to mixed 16:16/16:32 prot mode was, or the much more involved port from there to flat 0:32 386 world was (but even those ports were mostly rote, a few editor macros made a huge difference to the 99% of code that doesn't care about word size). Anyway it's funny that vendors that used to be satisfied with a large percentage of a tiny market (early 80s PC programmers), won't bother to lift a finger for a tiny percentage of an unbelievably huge market (present day PC programmers). One programmer (plus maybe one part-time tech writer) could maintain TASM (yes I'm offering!), but no. It's like Intel leaving the embedded microcontroller market, apparently having one division make a bazillion dollars a year from a stable market isn't worth their time when they could be a in a price war with AMD.
How about Turbo Assembler? Actually they still have it on the price list, but it's been frozen at V5.0 for many years. It would be nice to see this one brought back to life, I still use it (V5.0) every day, but when the day comes that I get forced to port all my stuff to x86-64, TASM will have to go.
I assumed at the time that the speech synth was a Votrax Type-n-Talk. It was popular back then (at least among people who had $400 to blow on a gimmick, so count me out -- I built my own with a cheapy GI SP0256 chip from RadShack, but it didn't do text-to-speech itself, so I wrote some PDP-11 FORTH code to make it swear and then lost interest). There were ads in Byte, and you could get the SC01 speech chip separately to build into your own stuff. The Type-n-Talk was a stand-alone text-to-speech unit with a serial input so it would have been trivial to hook it up as shown in the movie (but it wouldn't have worked that well, I don't think the text-to-speech algorithm was very smart).
It did bug me in the movie how the incredibly crude SWTPC video terminal was suddenly able to do fancy color graphics (just like Boz's VT100 on Riptide). Also as someone said, acoustic couplers can't dial. And I like how he gets the tic-tac-toe program to play against itself by typing Z-E-R-O (not 0) at the prompt for # of players.
I love MDs (I'm even more behind the times so I don't even have Hi-MD, much less an Apple-brand MP3 player), but the reason I love them is because they're great for recording, which (at least at the time I bought my stuff) the vendors didn't seem to take seriously. The fidelity is very good so I use them for recording amateur early music stuff (woodwinds and harpsichord), but the annoying thing is that the vendors only seemed to envision people using them to make mix discs and then go snowboarding (does everyone live in a Mountain Dew ad?), so it has digital input but only analog output (same as every other model I could find at the time). So that got annoying, I use my little Sharp MD player to record gigs (because it's portable) but then I had to get a Sony MD deck which had digital-out so I could play the discs into my sound card's optical input. Yes they *used* to be multi-vendor, sounds like that's not true with the new formats.
Anyway I know I'm far from the only amateur musician that uses these things to record their own stuff. It's nowhere near as big a market as walkman type stuff, obviously, but it seems like it's a market where vendors that can be satisfied with less than 100mil units/yr in sales could make some decent money. I bought a Fostex flash recorder because it was supposed to be better yet (no moving parts and no compression) but I hated it, the sound quality was bad (with the same mike that sounded great on the MD), the fiddly user interface was annoying, and it was way too big. Plus the fact that a piece of audio equipment is frickin' RED ought to be a clue it's made for the Do The Dew crowd!
So MD is ideal for some uses even if it's not great for the mainstream ADD folks who just need to hear constantly changing background noise 24 hours a day, and it'll be a shame if MDs finish dying out. It's awesome being able to get a high-quality recording of a gig that I can suck into Cakewalk for cleanup and then burn onto a CD (the opposite of what MP3 players are for), with better fidelity (to my ear anyway) than MP3s. And compressing the decompressed ATRAC stuff into MP3s seems to work pretty well too. Not bad for something I got for $140 at Sears.
Well wait a second, not every design is trivial, plus in some cases there are standardized form factors that you have to fit, especially if you're interfacing to old hardware (which seems like a reasonable thing for penniless hobbyists to want to do, rather than making mice or whatever). The smallest DEC Unibus board has to be 8.5"x10" just to fit the box and four edge connectors properly. And those old Data General boards are really gigantic.
Anyway I agree with the other posters, expecting high-quality free CAD software is unreasonable. The thing about free software is that people only write what they feel like writing. So we have OSes out the wazoo, and tons of text editors, and a few compilers -- stuff that's interesting and of general use to lots of people. But writing an autorouter has got to be unbelievably tedious, difficult work, and it won't be appreciated by very many people (compared to a text editor I mean, which is much easier and can make you famous, apparently).
So if someone has to bash their head against a wall for several years just to get one written (not to mention all the other prettier parts of a PCB editor), it's pretty understandable if the greater glory of humankind isn't enough for them, and they want tons of cash instead. All software that's unpleasant to write is that way, it usually takes money to make it happen.
$400 is a bargain. I'm still kicking myself for not coughing up the $1500 for the full version of PADS/PCB for DOS, back when it was available, it wasn't pretty but once you got the hang of it, it was great. It was a lot more the last time I checked, and of course it isn't available for DOS any more (you're not the only one whose favorite OS gets ignored by most vendors -- don't bother telling me why DOS sucks, I don't care any more than you care why Linux sucks).
My first was a Quest Super Elf, which I believe was supposed to be a knock-off of (or follow-on to?) the Elf. I worked all summer 1981 to save up the $106.95 for the kit... which had a nice hex keypad and display so you could program it directly in machine code. I later got a bunch of the options (power supply, super expansion, S-100 memory card as a bare board, and I should still have the Super BASIC cassette in this mess somewhere although I never had tapes working with the machine so I never got to run it) and made a nice cube case for it out of redwood. Too bad the 1802 was such a lame processor. I think its claim to fame was lower power usage, since it was CMOS and also static so you could slow it down as much as you want, not very important for desktop use, so the clumsy instruction set was the main thing you noticed. But any CPU that has a SEX instruction is OK with me!
I think what you should expect depends on how you've presented yourself to the company. If you come in as a blank slate and the company has to train you how to do even your basic job functions, great, as long as you don't mind working for minimum wage with no benefits, forever. Why should they treat you like a valuable asset if everything you are (as an employee) is thanks to them anyway? But as long as you don't mind that, then sure I agree you should be able to have your job to be an all-expenses paid trip that ends at 5:00 sharp.
Meanwhile if you're a professional in your own right, i.e. you went to college (or equivalent training on your own time and at your own expense) and you keep your skills fresh by reading/etc. on your own time, now you're actually valuable and should be treated as such by the company. They hired you because you know your stuff. But it's up to you to maintain your value by updating your skills as needed on your own time. Do you pay your doctor to go to conventions, keep up with medical journals etc.? Why would you, being a doctor is their problem.
OK I can see some exceptions, like if the job needs skills that are way out of the mainstream and it's unreasonable to expect to find workers who already learned those skills on their own. My girlfriend's company is gearing up to start training fresh mainframe COBOL programmers again (turns out those layoffs weren't such a great idea), since they know that mainstream comp sci folks are heavily bigoted against COBOL (foolishly) so no one's learning it in school any more. So they have to create their own COBOL programmers.
I'm self-employed so I'm highly biased, but it really bothers me how a lot of people run their careers as if they're a consumer. They expect someone to give them their ideal job/career/life and boo hoo hoo it's so unfair when they don't get it, or they do get it but it turns out to be harder than they thought. Good geek jobs don't just happen to you, it takes a long life of being a geek to qualify for one. This is us having the last laugh, after all the Normals thought they were cooler than us but now they're working at Champs or driving cabs or whatever for crap pay, while we do really interesting (to us) work for decent money. But if you aren't really a geek... uhhhh...
Intel has tried several times to dump backward compatibility in the past, and they've been burned each time, so they're right to be a little hesitant.
The 80286 didn't have a sensible way to get back to real mode, because Intel assumed that once the 286 came out everyone would immediately switch to pure protected mode software to enjoy that luxurious 16 MB address space. Didn't happen -- at the time 1 MB was a lot (I could only afford 128 KB on my IBM PC), and after two years DOS was already entrenched. So the 386 backpedaled and added V8086 mode (further improved in the Pentium with VME).
Then the Pentium Pro got lazy about loading segment descriptors, which Intel figured was OK because everyone should have switched to 32-bit flat code by then so they wouldn't notice (since the segment registers would be loaded once and never again). Wrong again, the PPro was terrible at running 8088 or 80286 code (i.e. Win 3.1), so they went back to doing it right in the Pentium II.
Meanwhile, AMD has been diligent about making sure that new features don't come at a big cost to backwards compatibility, and it's worked out really well for them. When Intel gets ahead in the benchmarks, it's often just because their latest gimmick instruction set add-on (SSE7 or whatever we're up to now) plays directly to whatever the fad is that year, but their performance on basic integer instructions (y'know, the stuff that OSes are written in) stands still or even jumps backwards (early P4s).
So even when Intel has been ahead in the magazine benchmarks, AMD's CPUs have usually still been faster for doing real work (i.e. not video games or decompressing porn), and Intel knows it. The Itanic 1's absolutely awful x86 performance is probably what killed its market share more than any other single thing. Unusably slow is no better than totally incompatible, and if that were OK (and the market were really a fair fight on the technical merits of competing architectures) then the Alpha would have taken over the world years before and none of this would have ever happened.
Anyway, how many bits do we really need? I'm getting really sick of doubling the number of address/data bits every ten years, and breaking everything for a while each time, especially when it's obviously an ego thing as much as anything else. Let's decide how many bits we need now, then someone (CGB?) could design a nice clean instruction set, and we could just skip a few steps and start using 2048-bit CPUs now.
It'd take decades to max out on that... and I'd love to write code that I know will still run long after I'm dead, without all the new kids whining about "why are we still lugging around this stupid 512-bit compatibility mode, anyone who still writes programs that would fit in less than 4 quincentdecabytes is a wuss anyway!"
If it's true that the patents only cover the hideous SFN/LFN kludge, then that hugely reduces who's affected. A flash drive might come with a FAT file system on it, but since there are no files it can't infringe. And digital cameras etc. are OK as long as they write 8.3 filenames, and how long do you really want a randomly-generated filename to be? The Linux driver would be screwed though, as well as the LFN TSRs for real DOS.
I can absolutely give you an example of a device that's not getting community support -- the BCI-2004/BCI-2104 bus interfaces from The Logical Company. These are oddball weird strange devices for interfacing ancient DEC Q-bus/Unibus hardware to PCI-bus machines. The vendor doesn't care about Linux but provides semi-usable documentation and very friendly email support. My customers (I sell a minicomputer emulation package that runs on Linux or DOS -- don't laugh, see below) want to use the device.
So I wrote a nice driver for it, with help from the excellent Rubini book since there's no frickin' driver documentation and the Linux sources are uncommented (putting your name at the top doesn't count as commenting on any team I've been on). It worked for a few months, until the next incompatible change in the kernel. Then I poked around in the kernel until I thought I'd figured out what had changed. Got it kind-of working (DMA is unreliable and I don't know why). Then the 2nd edition of the Rubini book came out, so I rewrote the driver and got it semi-OK again. For a few months.
The kernel has had about a zillion incompatible changes in the driver interface since then, ALL UNDOCUMENTED, there's no 3rd edition of Rubini's book to sort it out for me, and I'm just lost digging through the kernel sources. It's always the same pattern: customer complains, I spend a few days fixing it, and it sort-of works for a few months until the next gratuitous interface change.
OK so I'm a for-profit vendor and therefore deserve to die (how dare I want to be paid for being a programmer, it's only people who don't create new IP who should be allowed to choose what they do for a living). But I'm not the vendor. I wrote the driver for their device (and plenty of other open source stuff) because it needed writing and no one else was doing it. The driver is distributed as fully commented source (obviously), and I've given it out to anyone who asked for it (uhh... both of them -- this hasn't made me a nickel in extra sales for the package itself, I tell users who want reliable Q-bus interfacing to use my DOS version because there's no OS to break my driver there, it's worked unchanged for YEARS). The users haven't touched a single line of code on their own that I know of, all they do is complain to me. So what's wrong with this picture? Why isn't Open Source magically making everything work, at no cost to anyone?
It's just plain arrogant to assume that Groovy Open Source will always fix itself, and therefore it's OK to make the kernel interface be a rapidly moving target with no real manual. I'm sure that when we're talking about some extremely commonplace device that hundreds of thousands of people have, it's not hard at all to raise a posse and go after new bugs when the kernel changes. But this device I'm talking about costs $2575 a pop and is of no interest to anyone who isn't keeping a 30-year-old minicomputer system alive with a brain transplant. Absolutely no one is helping me maintain the driver even though they have everything they need to do it. I'm doing a lousy job of maintaining it because it's 0.0001% of my job description, and it's just not my strength (I know how to program bare metal, keeping up with Linux internals would have to be its own full-time job).
I couldn't care less whether drivers are required by law to be open source (although I really can't believe that's enforcible on a loadable driver, licenses exist to make exceptions to the default copyright restrictions, and interoperation is not copying). If people want to see my I/O code they're welcome to it. Just please stop making it break!!! Especially if you're not going to bother helping me maintain it. I've got my hands full just keeping the user-mode code working (WTF happened to/dev/vcsa7 and up?! and/proc/meminfo?!).
Anyway my point is, if Linux would pick one driver interface, and commit to supporting it (OK, possibly among other
It may be the senility acting up but I'm reading the text differently (hmm 1984 CS AP all over again), to me it sounds like they have a particular application in mind. I.e. they promised a big customer that a certain program would work with their thingy (or Wine's thingy or whatever it really is) and they're down to the wire and are willing to pay some cash to someone clueful enough to finish the debugging for them in a hurry. So that's what they set up if you do contact them. $10K isn't such a bad deal for a one-time debugathon, as long you don't mind going to hell for helping them violate the GPL (if that's really what's up).
The hard disk boot loaders have names because they are add-ons. Originally (as of kernel 0.13 anyway, dunno before that), Linux booted only from floppy, so that loader was "the boot loader". Well at least dual-booting was easy, the floppy was either in or out.
Slashdot Mirror
My main product is a DOS application (well I sell Linux and Win32 versions too but customers who care about device support get the DOS one, plus I price it to encourage DOS use since support is much easier) which for some reason doesn't work under FreeDOS (the "open file" calls fail, of all things, but I can't duplicate it in real-mode code). It does work fine under MS-DOS, PC-DOS, DR-DOS, and the usual DOS boxes (it's been so long since I tested ROM-DOS or PTS-DOS that I've forgotten what happened), so it's hard to feel like it's my fault. Really diminishes my respect for FreeDOS though. Also their COMMAND.COM doesn't accept commands like "dir .txt" which worked on every version of real DOS (and are heavily programmed into my fingers), so I wonder if some of the developers weren't even DOS users? DOS is all about the nitpicky details (since it was so crude that we all had to commit some horrible atrocities to make our programs actually get work done) so they can't skimp on stuff like this.
My understanding is that the patent only covers the LFN extension to the FAT directory structure. The rest of the FAT spec is free. So a regular DOS clone wouldn't violate it. But it sounds like yes, FreeDOS does violate it. But so does Linux and which one do you think M$ will go after first, if/when they get around to it? (Never mind why they felt like patenting such a hideous hack in the first place -- OK so it's non-obvious but the reason it's non-obvious is because it isn't as useful as a more obvious method, so it shouldn't have been patentable.)
Dang! OK then forget the bridge or tether, how about a bungee link between Pluto and Charon?
Someone asked, what about planes hitting the space elevator? Well screw planes, what about satellites in low orbits? It would be a long shot, but if one hit it would hit hard.
Finally, what's this thing supposed to sit on? I know a lot of it isn't supposed to weigh much (even though I'm too ignorant to understand why not, only the far endpoint is actually in orbit, the rest is going the wrong speed for its altitude), but the first few miles sure would. You can't just pour a concrete footing and then put near-infinite weight on it, it'll just drill itself into the Earth's surface. We'll be lucky if the Earth doesn't crack open like an egg! Well I guess we could spread the load out, maybe build a frame all the way around and balance it with another space elevator on the flip side of the world. I mean we didn't even get the Big Dig right and we're talking about this, might as well think big since we know we're kidding ourselves (except for the part about blowing our tax money, that's real).
I don't think you can really go wrong. It would be cool to be close enough to see the launch tower etc. but it's a pretty good show from anywhere. I was at Disneyworld with my wife in 1997 and the night of a launch we hopped in the car and headed east, hoping we'd find our way to a good vantage point. Well we got behind schedule and were still an hour away when the time came, so we pulled over (so did a lot of other cars) and turned on the radio so we'd know when to squint and look for a bright dot in the distance. Yeah right, it was like the rising sun!!! It was great. And just when the radio said they were dumping the external tanks we saw a couple of dots drop away, very very cool. So anyway after that I started to suspect that the US space program may not be a hoax after all, they sure as hell launched something and if it wasn't going to space, it wasn't for lack of trying.
Somehow I doubt that porting my stuff from IA32 to x86-64 will be worse than the port from real mode to mixed 16:16/16:32 prot mode was, or the much more involved port from there to flat 0:32 386 world was (but even those ports were mostly rote, a few editor macros made a huge difference to the 99% of code that doesn't care about word size). Anyway it's funny that vendors that used to be satisfied with a large percentage of a tiny market (early 80s PC programmers), won't bother to lift a finger for a tiny percentage of an unbelievably huge market (present day PC programmers). One programmer (plus maybe one part-time tech writer) could maintain TASM (yes I'm offering!), but no. It's like Intel leaving the embedded microcontroller market, apparently having one division make a bazillion dollars a year from a stable market isn't worth their time when they could be a in a price war with AMD.
How about Turbo Assembler? Actually they still have it on the price list, but it's been frozen at V5.0 for many years. It would be nice to see this one brought back to life, I still use it (V5.0) every day, but when the day comes that I get forced to port all my stuff to x86-64, TASM will have to go.
It did bug me in the movie how the incredibly crude SWTPC video terminal was suddenly able to do fancy color graphics (just like Boz's VT100 on Riptide). Also as someone said, acoustic couplers can't dial. And I like how he gets the tic-tac-toe program to play against itself by typing Z-E-R-O (not 0) at the prompt for # of players.
Anyway I know I'm far from the only amateur musician that uses these things to record their own stuff. It's nowhere near as big a market as walkman type stuff, obviously, but it seems like it's a market where vendors that can be satisfied with less than 100mil units/yr in sales could make some decent money. I bought a Fostex flash recorder because it was supposed to be better yet (no moving parts and no compression) but I hated it, the sound quality was bad (with the same mike that sounded great on the MD), the fiddly user interface was annoying, and it was way too big. Plus the fact that a piece of audio equipment is frickin' RED ought to be a clue it's made for the Do The Dew crowd!
So MD is ideal for some uses even if it's not great for the mainstream ADD folks who just need to hear constantly changing background noise 24 hours a day, and it'll be a shame if MDs finish dying out. It's awesome being able to get a high-quality recording of a gig that I can suck into Cakewalk for cleanup and then burn onto a CD (the opposite of what MP3 players are for), with better fidelity (to my ear anyway) than MP3s. And compressing the decompressed ATRAC stuff into MP3s seems to work pretty well too. Not bad for something I got for $140 at Sears.
Anyway I agree with the other posters, expecting high-quality free CAD software is unreasonable. The thing about free software is that people only write what they feel like writing. So we have OSes out the wazoo, and tons of text editors, and a few compilers -- stuff that's interesting and of general use to lots of people. But writing an autorouter has got to be unbelievably tedious, difficult work, and it won't be appreciated by very many people (compared to a text editor I mean, which is much easier and can make you famous, apparently).
So if someone has to bash their head against a wall for several years just to get one written (not to mention all the other prettier parts of a PCB editor), it's pretty understandable if the greater glory of humankind isn't enough for them, and they want tons of cash instead. All software that's unpleasant to write is that way, it usually takes money to make it happen.
$400 is a bargain. I'm still kicking myself for not coughing up the $1500 for the full version of PADS/PCB for DOS, back when it was available, it wasn't pretty but once you got the hang of it, it was great. It was a lot more the last time I checked, and of course it isn't available for DOS any more (you're not the only one whose favorite OS gets ignored by most vendors -- don't bother telling me why DOS sucks, I don't care any more than you care why Linux sucks).
My first was a Quest Super Elf, which I believe was supposed to be a knock-off of (or follow-on to?) the Elf. I worked all summer 1981 to save up the $106.95 for the kit ... which had a nice hex keypad and display so you could program it directly in machine code. I later got a bunch of the options (power supply, super expansion, S-100 memory card as a bare board, and I should still have the Super BASIC cassette in this mess somewhere although I never had tapes working with the machine so I never got to run it) and made a nice cube case for it out of redwood. Too bad the 1802 was such a lame processor. I think its claim to fame was lower power usage, since it was CMOS and also static so you could slow it down as much as you want, not very important for desktop use, so the clumsy instruction set was the main thing you noticed. But any CPU that has a SEX instruction is OK with me!
Meanwhile if you're a professional in your own right, i.e. you went to college (or equivalent training on your own time and at your own expense) and you keep your skills fresh by reading/etc. on your own time, now you're actually valuable and should be treated as such by the company. They hired you because you know your stuff. But it's up to you to maintain your value by updating your skills as needed on your own time. Do you pay your doctor to go to conventions, keep up with medical journals etc.? Why would you, being a doctor is their problem.
OK I can see some exceptions, like if the job needs skills that are way out of the mainstream and it's unreasonable to expect to find workers who already learned those skills on their own. My girlfriend's company is gearing up to start training fresh mainframe COBOL programmers again (turns out those layoffs weren't such a great idea), since they know that mainstream comp sci folks are heavily bigoted against COBOL (foolishly) so no one's learning it in school any more. So they have to create their own COBOL programmers.
I'm self-employed so I'm highly biased, but it really bothers me how a lot of people run their careers as if they're a consumer. They expect someone to give them their ideal job/career/life and boo hoo hoo it's so unfair when they don't get it, or they do get it but it turns out to be harder than they thought. Good geek jobs don't just happen to you, it takes a long life of being a geek to qualify for one. This is us having the last laugh, after all the Normals thought they were cooler than us but now they're working at Champs or driving cabs or whatever for crap pay, while we do really interesting (to us) work for decent money. But if you aren't really a geek ... uhhhh ...
The 80286 didn't have a sensible way to get back to real mode, because Intel assumed that once the 286 came out everyone would immediately switch to pure protected mode software to enjoy that luxurious 16 MB address space. Didn't happen -- at the time 1 MB was a lot (I could only afford 128 KB on my IBM PC), and after two years DOS was already entrenched. So the 386 backpedaled and added V8086 mode (further improved in the Pentium with VME).
Then the Pentium Pro got lazy about loading segment descriptors, which Intel figured was OK because everyone should have switched to 32-bit flat code by then so they wouldn't notice (since the segment registers would be loaded once and never again). Wrong again, the PPro was terrible at running 8088 or 80286 code (i.e. Win 3.1), so they went back to doing it right in the Pentium II.
Meanwhile, AMD has been diligent about making sure that new features don't come at a big cost to backwards compatibility, and it's worked out really well for them. When Intel gets ahead in the benchmarks, it's often just because their latest gimmick instruction set add-on (SSE7 or whatever we're up to now) plays directly to whatever the fad is that year, but their performance on basic integer instructions (y'know, the stuff that OSes are written in) stands still or even jumps backwards (early P4s).
So even when Intel has been ahead in the magazine benchmarks, AMD's CPUs have usually still been faster for doing real work (i.e. not video games or decompressing porn), and Intel knows it. The Itanic 1's absolutely awful x86 performance is probably what killed its market share more than any other single thing. Unusably slow is no better than totally incompatible, and if that were OK (and the market were really a fair fight on the technical merits of competing architectures) then the Alpha would have taken over the world years before and none of this would have ever happened.
Anyway, how many bits do we really need? I'm getting really sick of doubling the number of address/data bits every ten years, and breaking everything for a while each time, especially when it's obviously an ego thing as much as anything else. Let's decide how many bits we need now, then someone (CGB?) could design a nice clean instruction set, and we could just skip a few steps and start using 2048-bit CPUs now.
It'd take decades to max out on that ... and I'd love to write code that I know will still run long after I'm dead, without all the new kids whining about "why are we still lugging around this stupid 512-bit compatibility mode, anyone who still writes programs that would fit in less than 4 quincentdecabytes is a wuss anyway!"
If it's true that the patents only cover the hideous SFN/LFN kludge, then that hugely reduces who's affected. A flash drive might come with a FAT file system on it, but since there are no files it can't infringe. And digital cameras etc. are OK as long as they write 8.3 filenames, and how long do you really want a randomly-generated filename to be? The Linux driver would be screwed though, as well as the LFN TSRs for real DOS.
So I wrote a nice driver for it, with help from the excellent Rubini book since there's no frickin' driver documentation and the Linux sources are uncommented (putting your name at the top doesn't count as commenting on any team I've been on). It worked for a few months, until the next incompatible change in the kernel. Then I poked around in the kernel until I thought I'd figured out what had changed. Got it kind-of working (DMA is unreliable and I don't know why). Then the 2nd edition of the Rubini book came out, so I rewrote the driver and got it semi-OK again. For a few months.
The kernel has had about a zillion incompatible changes in the driver interface since then, ALL UNDOCUMENTED, there's no 3rd edition of Rubini's book to sort it out for me, and I'm just lost digging through the kernel sources. It's always the same pattern: customer complains, I spend a few days fixing it, and it sort-of works for a few months until the next gratuitous interface change.
OK so I'm a for-profit vendor and therefore deserve to die (how dare I want to be paid for being a programmer, it's only people who don't create new IP who should be allowed to choose what they do for a living). But I'm not the vendor. I wrote the driver for their device (and plenty of other open source stuff) because it needed writing and no one else was doing it. The driver is distributed as fully commented source (obviously), and I've given it out to anyone who asked for it (uhh ... both of them -- this hasn't made me a nickel in extra sales for the package itself, I tell users who want reliable Q-bus interfacing to use my DOS version because there's no OS to break my driver there, it's worked unchanged for YEARS). The users haven't touched a single line of code on their own that I know of, all they do is complain to me. So what's wrong with this picture? Why isn't Open Source magically making everything work, at no cost to anyone?
It's just plain arrogant to assume that Groovy Open Source will always fix itself, and therefore it's OK to make the kernel interface be a rapidly moving target with no real manual. I'm sure that when we're talking about some extremely commonplace device that hundreds of thousands of people have, it's not hard at all to raise a posse and go after new bugs when the kernel changes. But this device I'm talking about costs $2575 a pop and is of no interest to anyone who isn't keeping a 30-year-old minicomputer system alive with a brain transplant. Absolutely no one is helping me maintain the driver even though they have everything they need to do it. I'm doing a lousy job of maintaining it because it's 0.0001% of my job description, and it's just not my strength (I know how to program bare metal, keeping up with Linux internals would have to be its own full-time job).
I couldn't care less whether drivers are required by law to be open source (although I really can't believe that's enforcible on a loadable driver, licenses exist to make exceptions to the default copyright restrictions, and interoperation is not copying). If people want to see my I/O code they're welcome to it. Just please stop making it break!!! Especially if you're not going to bother helping me maintain it. I've got my hands full just keeping the user-mode code working (WTF happened to /dev/vcsa7 and up?! and /proc/meminfo?!).
Anyway my point is, if Linux would pick one driver interface, and commit to supporting it (OK, possibly among other
It may be the senility acting up but I'm reading the text differently (hmm 1984 CS AP all over again), to me it sounds like they have a particular application in mind. I.e. they promised a big customer that a certain program would work with their thingy (or Wine's thingy or whatever it really is) and they're down to the wire and are willing to pay some cash to someone clueful enough to finish the debugging for them in a hurry. So that's what they set up if you do contact them. $10K isn't such a bad deal for a one-time debugathon, as long you don't mind going to hell for helping them violate the GPL (if that's really what's up).
The hard disk boot loaders have names because they are add-ons. Originally (as of kernel 0.13 anyway, dunno before that), Linux booted only from floppy, so that loader was "the boot loader". Well at least dual-booting was easy, the floppy was either in or out.