This can work out cheaper. Take Cingular phones for example, you can use a data or bluetooth cable and use the data services built into the phone.
For example, adding unlimited data to a cell phone plan on cingular is an extra $20 or so on top of the existing stuff, while an unlimited data card plan is $80 or so. The information is "out there" if you know what to search for.
And secondly, you can usually do a trial link with the phone and see if the data rates are suitable before getting a data card. If you can manage that, you'll find out pretty quickly if you're wasting your time or not.
I myself use bluetooth or a data cable to talk to my Cingular/Motorola V551 when in need of an on-the-spot connection. Throughput isn't bad, but latency can be a bit brutal. The data cable option seems faster/more reliable to me.
Umm. SSE2 is included on the athlon64 and opteron series, and it is even actually called SSE2. The Athlon-XP and earlier (K7) do not have it. Not even by another name. 3dnow is something very different.
SSE2 *is* used for number crunching. One of the things that SSE brings to the processor feature set is single precision (32 bit) floating point support without the awkward 387 floating point model. SSE2 adds double precision (64 bit) floating point modes.
SSE2's floating point model is more efficient and is the default ABI model for unixes on the amd64 platform. (fp args are passed in SSE2 registers instead of on the x87 fp stack).
In other words, even though SSE / SSE2 were created for other purposes, they are very very useful for floating point / number crunching purposes in real world programs.
I couldn't help but chuckle.. the likely amount anybody would actually get in return for what would likely be quite a lot of effort would pale in comparison to the reward/effort ratio from simply sending in rebate forms. And we all know how well those are acted apon.
I'm sure a few dedicated people would probably have the time/energy/persistence to see it through to the bitter end, but I suspect that actually sending in rebate forms would have a much greater payoff.
For some reason the FAA and TSA wouldn't let my wife take a lead-acid battery on the plane to power her CPAP machine for a 16 hour overnight flight. The NCharge-II battery pack was more than enough to run the device.
All those damn tips came in handy after all because sooner or later you can find one with the right shape and a close enough voltage.
The TSA wont let you take wet cell batteries on at all. FAA will let you take "non spillable" batteries, but you're not allowed to actually use them during the flight.
Something like the NCharge battery packs with their dry cell batteries can be quite a godsend.
The way the cable/dsl modem cap is implemented? One word: Poorly.
TCP was designed with the assumption that each hop had a buffer and that congestion would increase packet delays long before causing outright packet loss.
So, TCP reacts to 'delay' as a sign to slow down a bit.
The problem is that cable/dsl modems generally do not introduce delays at all. They go direct from normal speed to dropped packets, with little or no warning. TCP goes into a panic and jams on the brakes instead of gracefully backing off like it does when it hits delays.
One of the best things you can do to make your cable/dsl modem work better is to use a traffic shaper on it. I do this with my unix boxes. They provide way more buffering than the modems do, and are set just shy of the packet loss threshold on the modem.
As a result, you introduce delay yourself (so tcp responds sanely) and avoid going off the cliff.
BTW; I felt that DSL modems were a little more extreme in how they did this. They fragment the 1500 byte ethernet frames into 48-byte ATM frames. I suspected that the rate limiting was done at the ATM level and it would drop ATM frames to keep the rates down. The result of that is that a single lost ATM frame means that you're still chewing up bandwidth to carry the other 98% of each ethernet frame which cannot be reassembled at the other end. Maybe I'm wrong about that, but it sure felt like it with my old DSL connection. As much as I hate my cable provider, it doesn't seem to die off quite as suddenly as it did with DSL.
That's the real problem.. Just like Real programmers can write Fortran in any language, Windows users can f*ck up in any OS. No matter how much you think you've got it covered.
Switching OS's gives new and exciting potential for creative new ways to f*ck something up!
The same boxy feel is because the map (yes, singular) isn't all that changed. They've put some new objects in there for fun, but the beta is mostly about testing the game engine. Do the corpse ragdoll physics work? Does the engine render properly? Is it fast enough? Do the new objects behave right? (shoot the barrel -> it rolls, the glass bottles shatter etc). And so on. Its not supposed to look that different yet since its still mostly got the same textures and building models.
I read the article and thought "what a bunch of whiners!" and then read the legislation. Wow. One of the side effects is to make it illegal to have a targeted ad trigger based on a federally registered trademark. So, it becomes illegal to have an ad system (even if the computer owner explicitly wants it!) to detect "1800contacts" or "windows" or the like as triggers for suggesting cheaper contact lenses or linux/open source etc.
I hate ads as much as most people, but I know of people who do actually use this stuff on purpose - they're also the type of people who collect coupons etc. Should it be illegal for them to install software to look up cheaper/better alternatives?
It seems to me that this is more about a company trying to protect is business models than about consumer interest or spyware/adware/etc.
FreeBSD/amd64 is a pure 64 bit OS. There is no 32 bit code at all. The kernel, userland, ports/packages etc are all 64 bit. None of this hybrid 64/32 stuff.:-)
Actually, this is probably our greatest liability. While we can run 32 bit binary applications (can you say perforce?), it isn't perfect. Much more work is still going to be done in this regard.
If anybody is interested in giving FreeBSD/amd64 a whirl on one of these machines, we'd appreciate folks trying out the 5.2-RC1 ISO images. See the ftp link on the story above. Since RC1, lots of bugs have been found and fixed. Most notably for support of KDE and gnome environments. If you do try it out, do be aware that its still a little green in this area.
I personally, have been running a FreeBSD/amd64 desktop for about 2 months. I do subscribe to the 'eat my own dogfood' mantra. I do not have any x86 unix machines left except for my 486 firewall and a laptop. That goes for both home and work. My work desktop is FreeBSD/amd64 too.
Anyway, it's nice to see a FreeBSD reference here for a change.
While thats true, NetBSD's initial amd64 port was done years ago, the hardware hasn't been available in interesting quantities until relatively recently.
On the other hand, if you want to talk about bragging rights, FreeBSD's ia64 code hit the tree in September 2000. NetBSD still doesn't have support for that platform. Mind you, FreeBSD's 2000 version of ia64 support wasn't any more useful than NetBSD's 2001 amd64 code landing.
NetBSD's x86_64 support initially targeted the simulator, just like FreeBSD's initial ia64 support. Both were essentially academic curiosities at the time.
I've only had real x86_64^H^H^H^H^Hamd64 hardware since august 2002-ish.
You could make video phones work with 1280x1024 with 100 frames per second, but it still won't change the fact that people don't really like to be on camera. Tell me that you dont't feel slightly unsettled when walking into a bank and being faced with a camera pointing right at you. There is a reason why cameras are hidden under domes etc. People just do not like it.
Right now, people take it for granted that they have some privacy when answering the phone. You don't need to check what you look like, whether you need to brush hair, etc etc. Answering the phone in the middle of the night adds new hazards if you get out of bed insufficiently dressed etc.
If people wanted to do video phones, we'd be doing it already. And the people who do want to do it are using webcams, online chat, etc. The technology is already there.
Argh, for goodness' sake, dont click on embedded links unless you've read the raw email source. A good deal of the links have embedded addresses that encoded your email address identity. By clicking on a link, you've probably disclosed to a spammer that you're a responsive email address interested in penis enlargement. Expect more spam.:(
For example, if the link looks like this in the html source: http://spammer.com/response.cgi?id=123456678 then you can bet that they have a web server that logs the id and they match "12345678" back to your email address.
Likewise, many spams have 'bugs' in them where the recipient id is encoded in a http url somewhere so that they can see who is reading the emails. If you have an email client that shows you a preview, it is quite likely identifying you to the spammers as a valid email address. You do not even need to read these if your client (eg: outlook and its ilk) has got preview mode on.
eg: <img src="http://spammer.com/image.gif?id=12345678"> and so on. These are often 1x1 pixel transparent images so you cant see it, but your mail client will happily fetch it for you and put your id into their web server logs for identifying your email address as 'working'.
If you can, tell it to turn off images in emails. And investigate something like the mimedefang type scrubbers that remove web bugs and and javascript etc from email.
Mind you, if you use outlook you're already in the line of fire.
Having NetBSD/FreeBSD seperate was good in many ways because it kept mutually incompatable folks away from each others throats. Once things cooled down, technology began to flow in both directions between NetBSD and FreeBSD. Later on, OpenBSD came along. All sorts of good things came from that. Can you say OpenSSH?
It would be nice if DragonFlyBSD (gah, ENAMETOOLONG) was a similar deal. As a FreeBSD developer, I hope that there will be plenty of opportunities to take good stuff in both directions. If we can keep people away from each others throats and work on making the code better, then everybody wins.
Diversity is good. Developers fighting each other is bad. Forks can be a good way to relieve the stress. There is no need to make a Big Deal(TM) about it.
Yes. FreeBSD's driver configuration and stacking model goes beyond what NetBSD's does. While FreeBSD picked up bus_space and busdma from NetBSD, it has its own configuration and driver interface (dubbed 'newbus'). It is tree structured, and the bus layer at each node controls device identification and runs the 'auction' of an identified device to all the possible drivers. The pci bus stack happily runs under acpi enumeration or via direct configuration registers - the drivers themselves have no knowledge of where they are. For all they know, they could be on an emulated pci bus on the wrong side of a very creative usb bridge.:) All the driver cares about is 'give me my resources'.
A light overview is here (The article has some inaccuracies though, new-bus was designed by Doug Rabson, not obtained from NetBSD).
If you dont have a FreeBSD system, you can follow the cross references
here
and
here.
Actually, not true. It was USL that initiated the lawsuit, and after Novell bought out AT&T's stake in USL it was Novell who pushed for the settlement.
Sure, things were not looking too good for USL's case and BSDI/UCB might have won in the end, but by initiating the push for a settlement, they saved us from another year or so of legal limbo.
But by then it was too late. *BSD had lost momentum and that gave Linux enough of a free run and got its momentum going.
UFS == FFS. Its a slightly different name/acronym for the same thing. NetBSD/OpenBSD completed a tree-wide sweep and changed all UFS references to FFS for consistency. FreeBSD still (mostly) calls it UFS. "Fast File System" is not much better than "Unix File System". "Berkeley Fast File System" (BFFS) would be most correct.
How do they compare? They all pretty much use the same on-disk format. There were some relatively recent changes (dirpref) that started using some previously unused space. I think this has been ported to Net/OpenBSD now. You already mentioned soft-updates, but this doesn't change the fs format except add a new flag bit. And then there are snapshots (which depend on soft-updates) and again, they just use some extra flag and file type bits. UFS2 is a significant on-disk format change. All the 32-bit block addresses and sizes are now 64 bits so the 1TB/2TB file system and file size limits are gone. It is the 64 bit stuff that is the primary reason for the larger inode sizes.
It was a joke, I changed the clock speed strings to 'pi'. This is a 10 month old pre-pre-pre-production A0-step silicon machine. I'm not allowed to talk about the speed of this particular machine. But I can say that I'm rather impressed given this particular machine's early production state. It does run very nicely in 32 bit mode. It is faster than my home desktop machine, and is faster than my work desktop (in single processor mode).
Also, note this is a Clawhammer cpu, not the Sledgehammer/Opteron that is coming up for release on April 23.
The last time I had a cable install done (june this year), they needed to log into something on their internal network to activate the modem (AT&T broadband, SF Bay Area).
I had already set up a blank install on a machine for him, just in case I couldn't talk him out of installing the stuff. I told him so. I also told him that the computer that I normally use is still plugged in at the old house and that I probably wasn't going to use the one here, and that I'd be quite happy for him not to touch the this machine (as I wasn't going to use it) and I'd sign his checklist for him anyway.
He looked at me as though I might have been from some internal AT&T "sting" operation to check on the installers for a few seconds, then asked me if I was sure, and then he was happy. I signed the checklist, and he was out of there in 5 minutes flat.
Personally, I think the best policy is to tell them up front what you want and that you're willing to sign off on the install anyway. Once they realize that the work they'd be doing would be a waste anyway, most will see the light. Most. Some will be bloody-minded about it and are not worth fighting with. But even then it is ok because you only let them near the blank install.
I wonder if Steve and Bill have nightmares and wake up in the middle of the night in a cold sweat and wonder if the day may come where they may have to actually *earn* the money they extract from folks?
The day will come, sooner or later, when enough people will realize that they no longer have to accept what M$ deems that the market has to buy next.
But the really good part is that I didn't have DSL for over a year. Suddenly this popped up on my December bill, and they started charging me over $300 per month after that. It took quite some undoing. Everybody admitted that $1300 for DSL service from Dec 12 2001 through Dec 12 2001 was kinda strange, but nobody had any idea what to do about it.
Slashdot Mirror
This can work out cheaper. Take Cingular phones for example, you can use a data or bluetooth cable and use the data services built into the phone.
For example, adding unlimited data to a cell phone plan on cingular is an extra $20 or so on top of the existing stuff, while an unlimited data card plan is $80 or so. The information is "out there" if you know what to search for.
And secondly, you can usually do a trial link with the phone and see if the data rates are suitable before getting a data card. If you can manage that, you'll find out pretty quickly if you're wasting your time or not.
I myself use bluetooth or a data cable to talk to my Cingular/Motorola V551 when in need of an on-the-spot connection. Throughput isn't bad, but latency can be a bit brutal. The data cable option seems faster/more reliable to me.
The FreeBSD/amd64 kernel runs on Intel's EM64T cpus which implement hyperthreading.
Umm. SSE2 is included on the athlon64 and opteron series, and it is even actually called SSE2. The Athlon-XP and earlier (K7) do not have it. Not even by another name. 3dnow is something very different.
SSE2 *is* used for number crunching. One of the things that SSE brings to the processor feature set is single precision (32 bit) floating point support without the awkward 387 floating point model. SSE2 adds double precision (64 bit) floating point modes.
SSE2's floating point model is more efficient and is the default ABI model for unixes on the amd64 platform. (fp args are passed in SSE2 registers instead of on the x87 fp stack).
In other words, even though SSE / SSE2 were created for other purposes, they are very very useful for floating point / number crunching purposes in real world programs.
I couldn't help but chuckle.. the likely amount anybody would actually get in return for what would likely be quite a lot of effort would pale in comparison to the reward/effort ratio from simply sending in rebate forms. And we all know how well those are acted apon.
I'm sure a few dedicated people would probably have the time/energy/persistence to see it through to the bitter end, but I suspect that actually sending in rebate forms would have a much greater payoff.
For some reason the FAA and TSA wouldn't let my wife take a lead-acid battery on the plane to power her CPAP machine for a 16 hour overnight flight. The NCharge-II battery pack was more than enough to run the device.
All those damn tips came in handy after all because sooner or later you can find one with the right shape and a close enough voltage.
The TSA wont let you take wet cell batteries on at all. FAA will let you take "non spillable" batteries, but you're not allowed to actually use them during the flight.
Something like the NCharge battery packs with their dry cell batteries can be quite a godsend.
The way the cable/dsl modem cap is implemented? One word: Poorly.
TCP was designed with the assumption that each hop had a buffer and that congestion would increase packet delays long before causing outright packet loss.
So, TCP reacts to 'delay' as a sign to slow down a bit.
The problem is that cable/dsl modems generally do not introduce delays at all. They go direct from normal speed to dropped packets, with little or no warning. TCP goes into a panic and jams on the brakes instead of gracefully backing off like it does when it hits delays.
One of the best things you can do to make your cable/dsl modem work better is to use a traffic shaper on it. I do this with my unix boxes. They provide way more buffering than the modems do, and are set just shy of the packet loss threshold on the modem.
As a result, you introduce delay yourself (so tcp responds sanely) and avoid going off the cliff.
BTW; I felt that DSL modems were a little more extreme in how they did this. They fragment the 1500 byte ethernet frames into 48-byte ATM frames. I suspected that the rate limiting was done at the ATM level and it would drop ATM frames to keep the rates down. The result of that is that a single lost ATM frame means that you're still chewing up bandwidth to carry the other 98% of each ethernet frame which cannot be reassembled at the other end. Maybe I'm wrong about that, but it sure felt like it with my old DSL connection. As much as I hate my cable provider, it doesn't seem to die off quite as suddenly as it did with DSL.
That's the real problem.. Just like Real programmers can write Fortran in any language, Windows users can f*ck up in any OS. No matter how much you think you've got it covered.
Switching OS's gives new and exciting potential for creative new ways to f*ck something up!
Now you're talking. Or use some of the supposedly abundant and cheap electricity for a giant electromag launch accelerator.. who needs rockets? :)
The same boxy feel is because the map (yes, singular) isn't all that changed. They've put some new objects in there for fun, but the beta is mostly about testing the game engine. Do the corpse ragdoll physics work? Does the engine render properly? Is it fast enough? Do the new objects behave right? (shoot the barrel -> it rolls, the glass bottles shatter etc). And so on. Its not supposed to look that different yet since its still mostly got the same textures and building models.
Yeah, and I dont carry or use a swiss army knife either. :)
I dont give a damn what fruit that they put in it, as long as they dont forget that at the end of the day, the phone still needs to be a good phone!
But if somebody comes up with a half-baked phone with a half-baked pda, a half baked computer and a half-baked game system built in, no thanks!
Integrating pagers into phones made lots of sense. But that doesn't mean that integrating everything else does.
I read the article and thought "what a bunch of whiners!" and then read the legislation. Wow. One of the side effects is to make it illegal to have a targeted ad trigger based on a federally registered trademark. So, it becomes illegal to have an ad system (even if the computer owner explicitly wants it!) to detect "1800contacts" or "windows" or the like as triggers for suggesting cheaper contact lenses or linux/open source etc.
I hate ads as much as most people, but I know of people who do actually use this stuff on purpose - they're also the type of people who collect coupons etc. Should it be illegal for them to install software to look up cheaper/better alternatives?
It seems to me that this is more about a company trying to protect is business models than about consumer interest or spyware/adware/etc.
FreeBSD/amd64 is a pure 64 bit OS. There is no 32 bit code at all. The kernel, userland, ports/packages etc are all 64 bit. None of this hybrid 64/32 stuff. :-)
Actually, this is probably our greatest liability. While we can run 32 bit binary applications (can you say perforce?), it isn't perfect. Much more work is still going to be done in this regard.
If anybody is interested in giving FreeBSD/amd64 a whirl on one of these machines, we'd appreciate folks trying out the 5.2-RC1 ISO images. See the ftp link on the story above. Since RC1, lots of bugs have been found and fixed. Most notably for support of KDE and gnome environments. If you do try it out, do be aware that its still a little green in this area.
I personally, have been running a FreeBSD/amd64 desktop for about 2 months. I do subscribe to the 'eat my own dogfood' mantra. I do not have any x86 unix machines left except for my 486 firewall and a laptop. That goes for both home and work. My work desktop is FreeBSD/amd64 too.
Anyway, it's nice to see a FreeBSD reference here for a change.
While thats true, NetBSD's initial amd64 port was done years ago, the hardware hasn't been available in interesting quantities until relatively recently.
On the other hand, if you want to talk about bragging rights, FreeBSD's ia64 code hit the tree in September 2000. NetBSD still doesn't have support for that platform. Mind you, FreeBSD's 2000 version of ia64 support wasn't any more useful than NetBSD's 2001 amd64 code landing.
NetBSD's x86_64 support initially targeted the simulator, just like FreeBSD's initial ia64 support. Both were essentially academic curiosities at the time.
I've only had real x86_64^H^H^H^H^Hamd64 hardware since august 2002-ish.
You could make video phones work with 1280x1024 with 100 frames per second, but it still won't change the fact that people don't really like to be on camera. Tell me that you dont't feel slightly unsettled when walking into a bank and being faced with a camera pointing right at you. There is a reason why cameras are hidden under domes etc. People just do not like it.
Right now, people take it for granted that they have some privacy when answering the phone. You don't need to check what you look like, whether you need to brush hair, etc etc. Answering the phone in the middle of the night adds new hazards if you get out of bed insufficiently dressed etc.
If people wanted to do video phones, we'd be doing it already. And the people who do want to do it are using webcams, online chat, etc. The technology is already there.
Argh, for goodness' sake, dont click on embedded links unless you've read the raw email source. A good deal of the links have embedded addresses that encoded your email address identity. By clicking on a link, you've probably disclosed to a spammer that you're a responsive email address interested in penis enlargement. Expect more spam. :(
For example, if the link looks like this in the html source: http://spammer.com/response.cgi?id=123456678 then you can bet that they have a web server that logs the id and they match "12345678" back to your email address.
Likewise, many spams have 'bugs' in them where the recipient id is encoded in a http url somewhere so that they can see who is reading the emails. If you have an email client that shows you a preview, it is quite likely identifying you to the spammers as a valid email address. You do not even need to read these if your client (eg: outlook and its ilk) has got preview mode on.
eg: <img src="http://spammer.com/image.gif?id=12345678"> and so on. These are often 1x1 pixel transparent images so you cant see it, but your mail client will happily fetch it for you and put your id into their web server logs for identifying your email address as 'working'.
If you can, tell it to turn off images in emails. And investigate something like the mimedefang type scrubbers that remove web bugs and and javascript etc from email.
Mind you, if you use outlook you're already in the line of fire.
Having NetBSD/FreeBSD seperate was good in many ways because it kept mutually incompatable folks away from each others throats. Once things cooled down, technology began to flow in both directions between NetBSD and FreeBSD. Later on, OpenBSD came along. All sorts of good things came from that. Can you say OpenSSH?
It would be nice if DragonFlyBSD (gah, ENAMETOOLONG) was a similar deal. As a FreeBSD developer, I hope that there will be plenty of opportunities to take good stuff in both directions. If we can keep people away from each others throats and work on making the code better, then everybody wins.
Diversity is good. Developers fighting each other is bad. Forks can be a good way to relieve the stress. There is no need to make a Big Deal(TM) about it.
Yes. FreeBSD's driver configuration and stacking model goes beyond what NetBSD's does. While FreeBSD picked up bus_space and busdma from NetBSD, it has its own configuration and driver interface (dubbed 'newbus'). It is tree structured, and the bus layer at each node controls device identification and runs the 'auction' of an identified device to all the possible drivers. The pci bus stack happily runs under acpi enumeration or via direct configuration registers - the drivers themselves have no knowledge of where they are. For all they know, they could be on an emulated pci bus on the wrong side of a very creative usb bridge. :) All the driver cares about is 'give me my resources'.
A light overview is here (The article has some inaccuracies though, new-bus was designed by Doug Rabson, not obtained from NetBSD).
If you dont have a FreeBSD system, you can follow the cross references here and here.
Actually, not true. It was USL that initiated the lawsuit, and after Novell bought out AT&T's stake in USL it was Novell who pushed for the settlement.
Sure, things were not looking too good for USL's case and BSDI/UCB might have won in the end, but by initiating the push for a settlement, they saved us from another year or so of legal limbo.
But by then it was too late. *BSD had lost momentum and that gave Linux enough of a free run and got its momentum going.
UFS == FFS. Its a slightly different name/acronym for the same thing. NetBSD/OpenBSD completed a tree-wide sweep and changed all UFS references to FFS for consistency. FreeBSD still (mostly) calls it UFS. "Fast File System" is not much better than "Unix File System". "Berkeley Fast File System" (BFFS) would be most correct.
How do they compare? They all pretty much use the same on-disk format. There were some relatively recent changes (dirpref) that started using some previously unused space. I think this has been ported to Net/OpenBSD now. You already mentioned soft-updates, but this doesn't change the fs format except add a new flag bit. And then there are snapshots (which depend on soft-updates) and again, they just use some extra flag and file type bits. UFS2 is a significant on-disk format change. All the 32-bit block addresses and sizes are now 64 bits so the 1TB/2TB file system and file size limits are gone. It is the 64 bit stuff that is the primary reason for the larger inode sizes.
It was a joke, I changed the clock speed strings to 'pi'. This is a 10 month old pre-pre-pre-production A0-step silicon machine. I'm not allowed to talk about the speed of this particular machine. But I can say that I'm rather impressed given this particular machine's early production state. It does run very nicely in 32 bit mode. It is faster than my home desktop machine, and is faster than my work desktop (in single processor mode).
Also, note this is a Clawhammer cpu, not the Sledgehammer/Opteron that is coming up for release on April 23.
The last time I had a cable install done (june this year), they needed to log into something on their internal network to activate the modem (AT&T broadband, SF Bay Area).
I had already set up a blank install on a machine for him, just in case I couldn't talk him out of installing the stuff. I told him so. I also told him that the computer that I normally use is still plugged in at the old house and that I probably wasn't going to use the one here, and that I'd be quite happy for him not to touch the this machine (as I wasn't going to use it) and I'd sign his checklist for him anyway.
He looked at me as though I might have been from some internal AT&T "sting" operation to check on the installers for a few seconds, then asked me if I was sure, and then he was happy. I signed the checklist, and he was out of there in 5 minutes flat.
Personally, I think the best policy is to tell them up front what you want and that you're willing to sign off on the install anyway. Once they realize that the work they'd be doing would be a waste anyway, most will see the light. Most. Some will be bloody-minded about it and are not worth fighting with. But even then it is ok because you only let them near the blank install.
I wonder if Steve and Bill have nightmares and wake up in the middle of the night in a cold sweat and wonder if the day may come where they may have to actually *earn* the money they extract from folks?
The day will come, sooner or later, when enough people will realize that they no longer have to accept what M$ deems that the market has to buy next.
But POKE 65497,0 was more interesting! :)
But the really good part is that I didn't have DSL for over a year. Suddenly this popped up on my December bill, and they started charging me over $300 per month after that. It took quite some undoing. Everybody admitted that $1300 for DSL service from Dec 12 2001 through Dec 12 2001 was kinda strange, but nobody had any idea what to do about it.