For example, I steadfastly avoid any movie starring Travolta. He's easily one of the most overrated "stars" in existence.
And I avoid any movie with a rap artist
Yeah, Blow Out, Monster's Ball, the Woodsman, Garden State, and Three Kings all really sucked. Don't even get me started on Boogie Nights or Pulp Fiction.
Dude, go back and read what I said. In both of the posts above this, I said that shared libs will use COW--the example I gave is not in a shared lib, and there is no way for a VM system to know that the pages are the same.
And it is a direct result of using a CreateProcess-style process creation instead of a fork/exec-style process creation.
Also not that the malloc isn't important here per se; the point is that with a spawn/CreateProcess style of process creation, all of the pages that your program initialize onces at startup (dynamically, not statically) will be copied unnecessarily.
There are times that this is the Right Thing, but by combining fork and exec in one call you lose the flexibility to keep COW data.
Uhh, I said "COW for shared lib/executable pages (and zero pages), yes". All of the things that you mention fall into that category. But that still misses the majority of the COW-shareable pages in most reasonably large apps--which was the (apparently missed) point of my post.
Imagine the case of a program that at the beginning does something like:
If the program calls fork() without exec() (e.g. to create another copy of itself that loads another file, or serves another socket, or whatever), it'll share the lookup table between copies; those pages are COW, and will never be copied unless the lookup table gets changed. If the program calls CreateProcess, it begins executing anew and will have multiple copies of lookup_table (with the same data in them)
In a typical nontrivial application, the amount of memory that is allocated and initialized but not written vastly outweighs the amount coming from shared libraries (e.g. anything set out of config files or otherwise programatically built).
As an aside, NT (and hence modern Windowsen) apparently _does_ offer an NTCreateProcess call that can be used to do a true COW process creation (ie, fork without exec), but that is an undocumented internal call not available from the Win32 API.
COC = copy-on-create, the entire memory is copied (except maybe shared lib mappings). I'd call COC "normal", given that it came first. Though COW is certainly prevalent today, so you could coherently argue that it is "normal". So I guess I'd avoid that tag entirely.
COC is how Cygwin did fork() last time I checked, but I haven't looked at it recently......Okay, after some googling it looks like NTCreateProcess is (or was) an undocumented NT internal call. The cygwin guys discovered it in 2002, but want to have a single binary for all systems (Win9x included) so they don't use it. They don't even offer a configure option for it, which is extremely weak. Apparently there have been a number of arguments about this on the Cygwin mailing lists.
Well, correct me if I am wrong, but what I was thinking is that there would be more overhead when creating a process compared to creating a thread. For instance, it would be quicker (less overhead) to create a few hundred threads rather than processes.
This actually varies based on which threading library you're using (in some, pthread_create is slower than fork), but if you're talking about bare clone() it's true.
It's also kind of irrelevant since the cost of either is extremely low (you can create tens of thousands of processes per second on modern machines) and, more importantly, isn't that important--if you care at all about performance, you're going to be pooling your threads or processes, not constantly creating new ones all over the place. So the creation cost will be amortized heavily.
Have you heard of page sharing and copy-on-write? Most of these 80MB is shared between two instances of the app.
Page sharing, yes. COW for shared lib/executable pages (and zero pages), yes.
But that's a tiny fraction of what true COW could get for you, and a tiny fraction of that 40MB. COW won't help nearly as much in the Windows world as in the Unix world, since they don't simply fork and load a new image (copying only pages that differ between the two processes, mainly the image data)--the CreateProcess* calls conflate fork/exec and there's no (COW-friendly) way to seperate the two concepts that I know of in Win32.
(The MPAA gives blanket privaledge to call a movie 'NC-17' without their approval, but that and 'X' are, I assume, still trademarked.)
They do NOT give that right. You must still submit a film for ratings board review to get an NC-17. In practice, they basically always allow it, but using it without the proper review is verboten.
The X rating was never trademarked, and you ARE allowed to self-apply that without review.
I don't mind most of the interface, but the fact that you have like 3 or 4 windows open on average and they aren't connected is a HUGE frustration for me.
Thats a wm issue. I would be pretty pissed if an application could raise or lower windows which I didn't want to (indeed, there are security issues with allowing that--ever had someone IM you a password that they were typing when their AIM client grabbed focus?). Even without that concern, I routinely want only particular windows from one application on top.
That said, sawfish (at least) allows you to group windows so that when you raise (or lower) one GIMP window they all raise (or lower). But that sort of policy defintely needs to be set at the wm level.
However, the OSS DB's don't offer higher end options such as clustering, distributed transactions, etc... While there are companies that really don't need clustering and simple data redundancy, a much larger actually do for disaster recovery, failover, etc..
Postgres and mysql both support replication and failover. Neither supports distributed transactions, but if you're just interested in disaster recovery and failover then you're covered.
It'd be stupid to use a DB for live high-value applications that didn't at least support master-slave replication with failover.
I wouldn't say that threads are faster but I do think it is fair to say that they have less overhead so you can many more threads on a system than you can processes
Except that that's not really true. If your processes actually write to a lot of pages, then they will have higher overhead--but they'll also be doing more than threads would. If they don't, then the higher overhead is basically limited to PTE mappings. In practice, thousands of processes or threads isn't a problem on modern OSes, except that it probably indicates an extraordinarily inefficient design.
Win32, at least last time I checked, didn't support COW fork(), and even doing COC fork() required a lot of hacks. The spawn family of calls conflates fork and exec. Without fork-only, you wind up using threads to work around the issue.
You raise an excellent point. If the data you are serving up is highly sensitive then you are better served by the forking model which has a process wall between the data in your HTTP connections. You never know what kind of bugs a module will exhibit in a multithreaded scenario.
Absolutely. But it's not merely protecting sensitive data--OS architects worked hard for years to implement protected memory, and threads circumvent a lot of those gains (a bug in one thread can affect them all, all memory access needs to be synchronized, etc).
There are good times to use them, but the choice should be based on whether you need to share all (or most) of the memory as opposed to sharing little or none (when processes, possibly with shared memory segments, are the correct choice).
Too many people think that somehow "threads are faster" when (excepting egregious disparities a la Windows) that isn't necessarily true--and even when it is, the performance benefits are often tiny compared to the costs you pay.
Most of the benchmarks I've seen for Apache 2.0 on linux have been pretty ambivalent; the prefork MPM is generally better at ramping up to handle large numbers of connections, and serves more reqs/sec under high load, while the worker MPM serves large numbers of requests to small numbers of connections more efficiently. But those numbers seem to fluctuate based on the application and the number of processors used, and I've seen some applications where one model was nearly twice as efficient as the other--and I've seen that big a difference work in favor of both models, for different apps (which probably points to some MPM-specific design decisions in that particular application).
As always, the decision over whether to use threads or processes should be based primarily over whether you want to give up protected memory within your application or not (unless you're dealing with a platform like Windows where the process model simply isn't flexible enough to avoid throwing memory protection out the window).
I disagree, playing as a valkyrie vs. a wizard is a very different game. I can easily see ascending as 4-5 different classes without getting bored (I've done valkyrie, archaeologist, tourist, and wizard).
I definitely discovered a lot of different things playing a wizard.
Barbarian (or valkyrie) is a great choice to try to win with.
Say it with me:
"blessed greased +2 gray dragon scale mail"
That's your first wish.
Or, alternately, silver instead of gray (depending on whether you already have another source of magic resistance).
If you're 10th level (not sure how high you need to be, but 10th is plenty), find an altar (one without an attendant priest) and sacrifice things for a while--you'll get an artifact weapon that way without wasting a wish.
Just play on and off for a decade. I finally ascended for the first time this year. Remarkably, I've ascended 3 more times since. Once you learn the tricks, it's a lot easier. Also, the beginning of the game is the hardest; it's almost impossible to die if you make it past the castle (barring silly mistakes)
a) It doesn't exceed the hardware specs for the card, just the default (the API used is documented and used by other vendors who use the chip in their cards) b) I can't imagine how they would find out, and if they did I'd expect them to deny claims solely based on the fact that I was using a 3rd-party driver in the first place
When you first installed the scanner 3 years ago you had to use a driver cd to install it.
When my parents first installed it 8 years ago they needed a manufacturer driver, yes. 3 years ago I needed no such thing...
So...wouldn't that tell you that when you upgrade to the newest OS you need to find drivers as well? The fact that the *manufacturer* no longer supports the scanner doesn't mean Microsoft is at fault. But you can't see it that way can you?
I can see it that way, which is why I wrote the post I did.
You've missed the whole point--the whole premise that I should be at the mercy of every manufacturer who made a peripheral in my machine (other than those with MS support) when deciding whether to upgrade my software is what I reject.
With closed-source, it is exactly as you say; you _are_ at the mercy of the manufacturers to support new versions of the OS as they are released, and if they don't see a good market reason to do so, you either can't upgrade the OS or have to get new hardware.
With open-source, as long as one developer has (and uses) the hardware in question then it's likely to be updated as new kernels come out. Often even if it's basically orphaned by developers and only used by end-users it'll still be updated if it's in the mainline tree. Even if not, I can either do that work myself or pay someone to do it for me. With closed-source, I have to hope that the manufacturer deigns the new OS worthy of their support (and for some of my hardware, they're out of business and so will never release another driver).
I don't care if hardware manufacturers support their stuff as long as it works. That is, in fact, the beauty of the process.
Heck, the fairly recent wireless card I have has full support to work as an access point with WPA under Linux, and can triple its power from the out-of-the-box spec. That's all "unsupported" open-source drivers.
It is barely passable as a client card (no power control and periodic dropped network) and has no access point support under the "supported" Windows drivers.
Open-source drivers should exist in a competitive environment with closed-source drivers - this will improve the quality of both.
Sadly, this free-market argument fails here for the most part. The primary argument in support of closed-source drivers (keep the hardware workings proprietary) also creates a significant barrier to entry for 3rd-party drivers (closed or open).
The trouble with this fact (new hardware not supported) is that people like me (I upgrade once or twice a year) can never get a decent, stable distribution running on their desktops
And there are people like me who (because support for non-mainstream hardware is constantly dropped) would have no hope of getting Windows running with all of their hardware. Personally I find it much more irritating when something I already own stops functioning than when I have to spend 5 minutes checking for support before buying new hardware, if your personal judgement is different then you may come to a different decision as to which OS fits your needs the best.
Point being, if you only ever do mainstream stuff and keep buying new hardware every couple of years, you might be reasonably well served by Windows. It does actually handle the "email/word processor/spreadsheet/web/games" user pretty well. Closed source will tend to come up with decent, cheap solutions for the things everyone does.
The place open source shines is in the niche--and, realistically, almost everyone has an interest or two that is really a niche. Some of those are well-served on various closed-source platforms and some aren't.
I do a ton of music visualization with digital music capture from various sources, video/TV output, etc, and I depend heavily on my hardware to keep working. If I had to worry about my infrared remote control card, or my TV output, or my various digital music capture devices, or whatever quitting on me when I did an OS upgrade then it'd be an absolute nightmare.
I strongly believe Linux will never work on the desktop unless there is a stable *binary* API for both kernel drivers and X video drivers that companies can target
For me, that is pretty much unacceptable. I often switch peripherals between machines, so having decent source available (so I can recompile for PPC or StrongARM) is a requirement; I don't much care if the binary API changes (as Linus has documented that it will even within stable branches) so long as any source-level API changes are documented.
That said, I've had no problems using the same peripherals with my desktop, my mp3 player, and my handheld. And yes, being able to slap a strobe light control (or a wireless card) that you had lying around into your Linux/StrongArm-based mp3 player for a few minutes without having to run out and buy some special mp3-player-only card that may or may not exist is actually useful.
I haven't really had any problems with X drivers since the Diamond Viper issues (over a decade ago now--summer of 1994), but I don't really care about cutting edge 3D support (mine has decent but not great 3D performance). So I can't comment on your thoughts there, other than to say that my primary machine (which spends hours each day doing pretty intense full-screen music visualization via X, with TV output--and does all my usual email/web browsing/etc on the monitor as well) hasn't had any display problems and has been up for quite a while:
14:10:56 up 140 days, 18:16, 16 users, load average: 1.39, 1.90, 1.63
The thing to understand is that this is not really a Bad Micro$oft issue, it a Technology Moves On issue
Thank you for missing the point entirely.
It is not a Bad Microsoft issue, but it is a Bad Closed-Source issue...
If you do not wish to replace your scanner with a new one for whatever reason, then you are going to be dependant on Win95/98. If you have no problem with that, fine. But, if you want / need Win2k or WinXP, than you will have to upgrade your scanner
...because that IS (sadly) the state of affairs in the closed-source world (unless the vendor or MS sees a useful market in extending support to future OS releases).
Thankfully (as was the point of my message), I can both upgrade my operating system and keep my old scanner.
It's like saying "I see no reason to get rid of my 286, my big floppies are just fine for saving files
No, it's like saying "I see no reason to get rid of my HP LaserJet IIP since it still prints at better quality than the cut-rate Best Buy crap these days and there's no point in buying yet another high-end printer to do the same thing".
Luckily that was widespread enough (and HP values support enough) that my parents can keep using it with their new Windows version.
That said, Linux still supports 5.25" drives (and 386 machines--full linux never ran on an 286, mostly because of the lack of an MMU).
The point is, as long as people are still using hardware, they can continue supporting (or paying people to support) open-source drivers for it. On the other hand, if they only have closed-source drivers then they're at the mercy of the vendor (or worse, completely SOL if the vendor goes out of business).
Slashdot Mirror
For example, I steadfastly avoid any movie starring Travolta. He's easily one of the most overrated "stars" in existence.
And I avoid any movie with a rap artist
Yeah, Blow Out, Monster's Ball, the Woodsman, Garden State, and Three Kings all really sucked. Don't even get me started on Boogie Nights or Pulp Fiction.
If the spirit rover can last for a year on Mars, why do we need to send astronauts (naughts?)?
Not because it is easy, but because it is hard.
Shared DLLs are covered by COW
Dude, go back and read what I said. In both of the posts above this, I said that shared libs will use COW--the example I gave is not in a shared lib, and there is no way for a VM system to know that the pages are the same.
And it is a direct result of using a CreateProcess-style process creation instead of a fork/exec-style process creation.
Also not that the malloc isn't important here per se; the point is that with a spawn/CreateProcess style of process creation, all of the pages that your program initialize onces at startup (dynamically, not statically) will be copied unnecessarily.
There are times that this is the Right Thing, but by combining fork and exec in one call you lose the flexibility to keep COW data.
Imagine the case of a program that at the beginning does something like:If the program calls fork() without exec() (e.g. to create another copy of itself that loads another file, or serves another socket, or whatever), it'll share the lookup table between copies; those pages are COW, and will never be copied unless the lookup table gets changed. If the program calls CreateProcess, it begins executing anew and will have multiple copies of lookup_table (with the same data in them)
In a typical nontrivial application, the amount of memory that is allocated and initialized but not written vastly outweighs the amount coming from shared libraries (e.g. anything set out of config files or otherwise programatically built).
As an aside, NT (and hence modern Windowsen) apparently _does_ offer an NTCreateProcess call that can be used to do a true COW process creation (ie, fork without exec), but that is an undocumented internal call not available from the Win32 API.
COC = copy-on-create, the entire memory is copied (except maybe shared lib mappings). I'd call COC "normal", given that it came first. Though COW is certainly prevalent today, so you could coherently argue that it is "normal". So I guess I'd avoid that tag entirely.
...Okay, after some googling it looks like NTCreateProcess is (or was) an undocumented NT internal call. The cygwin guys discovered it in 2002, but want to have a single binary for all systems (Win9x included) so they don't use it. They don't even offer a configure option for it, which is extremely weak. Apparently there have been a number of arguments about this on the Cygwin mailing lists.
COC is how Cygwin did fork() last time I checked, but I haven't looked at it recently...
This actually varies based on which threading library you're using (in some, pthread_create is slower than fork), but if you're talking about bare clone() it's true.
It's also kind of irrelevant since the cost of either is extremely low (you can create tens of thousands of processes per second on modern machines) and, more importantly, isn't that important--if you care at all about performance, you're going to be pooling your threads or processes, not constantly creating new ones all over the place. So the creation cost will be amortized heavily.
Have you heard of page sharing and copy-on-write? Most of these 80MB is shared between two instances of the app.
Page sharing, yes. COW for shared lib/executable pages (and zero pages), yes.
But that's a tiny fraction of what true COW could get for you, and a tiny fraction of that 40MB. COW won't help nearly as much in the Windows world as in the Unix world, since they don't simply fork and load a new image (copying only pages that differ between the two processes, mainly the image data)--the CreateProcess* calls conflate fork/exec and there's no (COW-friendly) way to seperate the two concepts that I know of in Win32.
(The MPAA gives blanket privaledge to call a movie 'NC-17' without their approval, but that and 'X' are, I assume, still trademarked.)
They do NOT give that right. You must still submit a film for ratings board review to get an NC-17. In practice, they basically always allow it, but using it without the proper review is verboten.
The X rating was never trademarked, and you ARE allowed to self-apply that without review.
I don't mind most of the interface, but the fact that you have like 3 or 4 windows open on average and they aren't connected is a HUGE frustration for me.
Thats a wm issue. I would be pretty pissed if an application could raise or lower windows which I didn't want to (indeed, there are security issues with allowing that--ever had someone IM you a password that they were typing when their AIM client grabbed focus?). Even without that concern, I routinely want only particular windows from one application on top.
That said, sawfish (at least) allows you to group windows so that when you raise (or lower) one GIMP window they all raise (or lower). But that sort of policy defintely needs to be set at the wm level.
However, the OSS DB's don't offer higher end options such as clustering, distributed transactions, etc... While there are companies that really don't need clustering and simple data redundancy, a much larger actually do for disaster recovery, failover, etc..
Postgres and mysql both support replication and failover. Neither supports distributed transactions, but if you're just interested in disaster recovery and failover then you're covered.
It'd be stupid to use a DB for live high-value applications that didn't at least support master-slave replication with failover.
I wouldn't say that threads are faster but I do think it is fair to say that they have less overhead so you can many more threads on a system than you can processes
Except that that's not really true. If your processes actually write to a lot of pages, then they will have higher overhead--but they'll also be doing more than threads would. If they don't, then the higher overhead is basically limited to PTE mappings. In practice, thousands of processes or threads isn't a problem on modern OSes, except that it probably indicates an extraordinarily inefficient design.
Win32, at least last time I checked, didn't support COW fork(), and even doing COC fork() required a lot of hacks. The spawn family of calls conflates fork and exec. Without fork-only, you wind up using threads to work around the issue.
It's a googlewhack (at least until they archive this page).
You raise an excellent point. If the data you are serving up is highly sensitive then you are better served by the forking model which has a process wall between the data in your HTTP connections. You never know what kind of bugs a module will exhibit in a multithreaded scenario.
Absolutely. But it's not merely protecting sensitive data--OS architects worked hard for years to implement protected memory, and threads circumvent a lot of those gains (a bug in one thread can affect them all, all memory access needs to be synchronized, etc).
There are good times to use them, but the choice should be based on whether you need to share all (or most) of the memory as opposed to sharing little or none (when processes, possibly with shared memory segments, are the correct choice).
Too many people think that somehow "threads are faster" when (excepting egregious disparities a la Windows) that isn't necessarily true--and even when it is, the performance benefits are often tiny compared to the costs you pay.
Most of the benchmarks I've seen for Apache 2.0 on linux have been pretty ambivalent; the prefork MPM is generally better at ramping up to handle large numbers of connections, and serves more reqs/sec under high load, while the worker MPM serves large numbers of requests to small numbers of connections more efficiently. But those numbers seem to fluctuate based on the application and the number of processors used, and I've seen some applications where one model was nearly twice as efficient as the other--and I've seen that big a difference work in favor of both models, for different apps (which probably points to some MPM-specific design decisions in that particular application).
As always, the decision over whether to use threads or processes should be based primarily over whether you want to give up protected memory within your application or not (unless you're dealing with a platform like Windows where the process model simply isn't flexible enough to avoid throwing memory protection out the window).
I disagree, playing as a valkyrie vs. a wizard is a very different game. I can easily see ascending as 4-5 different classes without getting bored (I've done valkyrie, archaeologist, tourist, and wizard).
I definitely discovered a lot of different things playing a wizard.
Barbarian (or valkyrie) is a great choice to try to win with.
Say it with me:
"blessed greased +2 gray dragon scale mail"
That's your first wish.
Or, alternately, silver instead of gray (depending on whether you already have another source of magic resistance).
If you're 10th level (not sure how high you need to be, but 10th is plenty), find an altar (one without an attendant priest) and sacrifice things for a while--you'll get an artifact weapon that way without wasting a wish.
Just play on and off for a decade. I finally ascended for the first time this year. Remarkably, I've ascended 3 more times since. Once you learn the tricks, it's a lot easier. Also, the beginning of the game is the hardest; it's almost impossible to die if you make it past the castle (barring silly mistakes)
a) It doesn't exceed the hardware specs for the card, just the default (the API used is documented and used by other vendors who use the chip in their cards)
b) I can't imagine how they would find out, and if they did I'd expect them to deny claims solely based on the fact that I was using a 3rd-party driver in the first place
When you first installed the scanner 3 years ago you had to use a driver cd to install it.
When my parents first installed it 8 years ago they needed a manufacturer driver, yes. 3 years ago I needed no such thing...
So...wouldn't that tell you that when you upgrade to the newest OS you need to find drivers as well? The fact that the *manufacturer* no longer supports the scanner doesn't mean Microsoft is at fault. But you can't see it that way can you?
I can see it that way, which is why I wrote the post I did.
You've missed the whole point--the whole premise that I should be at the mercy of every manufacturer who made a peripheral in my machine (other than those with MS support) when deciding whether to upgrade my software is what I reject.
With closed-source, it is exactly as you say; you _are_ at the mercy of the manufacturers to support new versions of the OS as they are released, and if they don't see a good market reason to do so, you either can't upgrade the OS or have to get new hardware.
With open-source, as long as one developer has (and uses) the hardware in question then it's likely to be updated as new kernels come out. Often even if it's basically orphaned by developers and only used by end-users it'll still be updated if it's in the mainline tree. Even if not, I can either do that work myself or pay someone to do it for me. With closed-source, I have to hope that the manufacturer deigns the new OS worthy of their support (and for some of my hardware, they're out of business and so will never release another driver).
I don't care if hardware manufacturers support their stuff as long as it works. That is, in fact, the beauty of the process.
Heck, the fairly recent wireless card I have has full support to work as an access point with WPA under Linux, and can triple its power from the out-of-the-box spec. That's all "unsupported" open-source drivers.
It is barely passable as a client card (no power control and periodic dropped network) and has no access point support under the "supported" Windows drivers.
Open-source drivers should exist in a competitive environment with closed-source drivers - this will improve the quality of both.
Sadly, this free-market argument fails here for the most part. The primary argument in support of closed-source drivers (keep the hardware workings proprietary) also creates a significant barrier to entry for 3rd-party drivers (closed or open).
And there are people like me who (because support for non-mainstream hardware is constantly dropped) would have no hope of getting Windows running with all of their hardware. Personally I find it much more irritating when something I already own stops functioning than when I have to spend 5 minutes checking for support before buying new hardware, if your personal judgement is different then you may come to a different decision as to which OS fits your needs the best.
Point being, if you only ever do mainstream stuff and keep buying new hardware every couple of years, you might be reasonably well served by Windows. It does actually handle the "email/word processor/spreadsheet/web/games" user pretty well. Closed source will tend to come up with decent, cheap solutions for the things everyone does.
The place open source shines is in the niche--and, realistically, almost everyone has an interest or two that is really a niche. Some of those are well-served on various closed-source platforms and some aren't.
I do a ton of music visualization with digital music capture from various sources, video/TV output, etc, and I depend heavily on my hardware to keep working. If I had to worry about my infrared remote control card, or my TV output, or my various digital music capture devices, or whatever quitting on me when I did an OS upgrade then it'd be an absolute nightmare.
For me, that is pretty much unacceptable. I often switch peripherals between machines, so having decent source available (so I can recompile for PPC or StrongARM) is a requirement; I don't much care if the binary API changes (as Linus has documented that it will even within stable branches) so long as any source-level API changes are documented.
That said, I've had no problems using the same peripherals with my desktop, my mp3 player, and my handheld. And yes, being able to slap a strobe light control (or a wireless card) that you had lying around into your Linux/StrongArm-based mp3 player for a few minutes without having to run out and buy some special mp3-player-only card that may or may not exist is actually useful.
I haven't really had any problems with X drivers since the Diamond Viper issues (over a decade ago now--summer of 1994), but I don't really care about cutting edge 3D support (mine has decent but not great 3D performance). So I can't comment on your thoughts there, other than to say that my primary machine (which spends hours each day doing pretty intense full-screen music visualization via X, with TV output--and does all my usual email/web browsing/etc on the monitor as well) hasn't had any display problems and has been up for quite a while:
14:10:56 up 140 days, 18:16, 16 users, load average: 1.39, 1.90, 1.63
Thank you for missing the point entirely.
It is not a Bad Microsoft issue, but it is a Bad Closed-Source issue...
Thankfully (as was the point of my message), I can both upgrade my operating system and keep my old scanner.
No, it's like saying "I see no reason to get rid of my HP LaserJet IIP since it still prints at better quality than the cut-rate Best Buy crap these days and there's no point in buying yet another high-end printer to do the same thing".
Luckily that was widespread enough (and HP values support enough) that my parents can keep using it with their new Windows version.
That said, Linux still supports 5.25" drives (and 386 machines--full linux never ran on an 286, mostly because of the lack of an MMU).
The point is, as long as people are still using hardware, they can continue supporting (or paying people to support) open-source drivers for it. On the other hand, if they only have closed-source drivers then they're at the mercy of the vendor (or worse, completely SOL if the vendor goes out of business).