my wife filed a complaint with the BBB and the next day the manager of the place was ready to clean her shoes with his tongue.
Ok, which means that the manager was probably not even involved before you got the BBB involved. You probably could have gotten similar results by calling up the manager himself. Also note that the issue wasn't about money -- it was about paperwork. It probably costed the manager nothing to make your wife happy in that case, so he did.
Making good on the `lifetime warranty' memory very well may cost the Chip Merchant money, so the results are quite likely to be very different.
So, I suspect you're just being a naysayer.
Well, I said nay (sort of), so I guess that makes me a naysayer.
But, either way, it costs nothing to file a complaint, and it may have positive results.
Ok, but you should be aware of the odds. If a company is shady, the BBB is not going to make them un-shady, and the Chip Merchant is sounding very shady here. And lots of BBB members are shady.
For example, you may remember this fiasco a few years ago, where Best Buy sold a bunch of GF4 Ti4600 cards for $139, but wouldn't deliver them. The BBB was contacted repeatedly, and did nothing, even though this was exactly the sort of case where one would have thought that they should have done something. The many complaints made weren't even showing up on as complaints against Best Buy on the BBB site, when they certainly should have (even if the complaints were without merit, which they were not.) Remember, it's the business who pays the BBB, and the BBB is a business looking to make a profit like any other, and their #1 duty is to their customer (the company), not to you.
The BBB has no power. It's basically just a club that businesses can join, a club that gives you a sticker that you can put on your door that makes customers feel better about you.
If your business is not a member, then the BBB can't do anything to it.
If your business is a member, the BBB will rate it based on the number of complaints they've received on it and they'll make some token efforts to resolve complaints, but if the company doesn't want to play ball, the BBB can't do anything except rate somebody `unsatisfactory' or something similar if there's enough complaints (and there needs to be quite a few.) But before that happens, a shady business will just drop it's membership, and that's that -- they lose the sticker, and that's about it.
Bush is a simple manager that leans heavily on his "experts", and can't think on the fly to save his life
Not that I like Bush (quite the opposite, actually), but this isn't automatically a bad thing. As long as he picks the appropriate experts and actually listens to their advice, one can be a very effective leader with this sort of setup, president or manager in some company.
And Bush isn't dumb. People like to say he is, but he's really not. But seriously, nobody has enough time to learn everything and keep up to date on it, and it's good that Bush knows how to delegate and rely on his advisors. (Though he's made some awful decisions. I don't know if it's due to bad advice or bad decisions based on that advice.)
Kerry is a carreer politician who will say anything to anyone to get elected.
Of course, that statement applies to almost everybody who ever gets to the point where the have a chance at being elected president.
Not that any of this is really relevant to Congress's $3B subsidy.
Compared to the last ten year's crop of 'game' movies, Tron was new and exciting because...
... because it wasn't based on a game! The games were based on the movie, not the other way around!
In any event, I really liked the Tron 2.0 game. I wonder if they make a Tron 2.0 movie, would it be a sequel to the movie Tron (in which case it's likely to suck, but could be OK) or a movie version of the game (in which case past experience tells us that it's doomed?)
How, in practice, can the general public work to get these limitations eased?
Lobby the government, mostly. I guess it might also be possible for a non-profit organization to raise lots of money and attempt to buy some big chunks of spectrum at one of the FCC's auctions, but it would require some serious cash, and I'll bet even then it's not htat esay.
Though to be fair, the restrictions are sort of important. Yes, I'd like to see a lot more spectrum allocated to unlicensed uses -- not just the tiny slivers that are now -- but having pretty serious power limitations is probably a good thing, since people generally don't care who they're interfering with -- all they care about is that their WiFi network or their cordless phone or CB radio works. (But conversely, if somebody else interferes with them, look out!)
In theory spread spectrum generally ignores interference, but that's only in theory -- in practice, it's relatively simple to knock out the entire WiFi band in an area, for example. Accidently or intentionally.
For an individual who's looking to experiment, getting a technician class amateur radio license is relatively simple, and that gets you access to several chunks of bandwidth that you can use, often with up to 1500 watts of power. But if you go under the ham rules, there are signifigant restrictions -- you must ID yourself every 10 minutes, no encryption, no pecuniary (financial) interest, etc. It's cool for a hobbyist, but it's not really right for everybody.
This is why the ISS should have been built in Geosynchronous Orbit. True it takes more fuel/complex ships to get there
Yes, and don't discount that. It would require MUCH more fuel and MUCH more complex ships to reach it, greatly increasing the cost. Probably so much that we just wouldn't do it.
Also, having a space station down as close to the Earth as is practical allows them to do lots of things that would be harder from much further out. Rememeber, we're talking 200 miles vs. 22,000 miles. Also, the ISS travels over much of the Earth each orbit, which allows it to do things over much of the Earth's surface if needed.
A geosychronous or geostationary satellite is always in approximately the same place above the Earth all the time, so if you want to do an experiment that needs to be done over Texas... too bad. A geosynchronous or geostationary satellite is always approximately (geosynchronous satellites do move around a little bit) above the same place -- which is always on the equator. It's also a bit crowded up there already...
I wonder if the ISS gets signifigantly more benefits of shielding from radiation up there by the Earth's magnetic field than it would if it were at 22,000 miles? It may be that going up to 22,000 miles would increase the overall radiation so much that humans couldn't live up there for an extended period of time without lots of very heavy and expensive shielding? (I don't know, it's just a guess.)
And at a mere 200 miles up, I can even whip out my 5 watt ham band handi-talkie radio and can reach the amateur repeater on the ISS. Were it 22,000 miles up, I'd need more power and bigger antennas.
but the benefits of avoiding a possible catastrophe and the ease of launch cycles would far outweigh those problems IMHO.
There is no impending catastrophe here. There was a problem, yes, but the ISS is still many months from crashing into the Earth -- there's lots of time to get these problems fixed.
I think it is interesting that you assume that the first abuse is going to be by religious group
I saw no such assumption. All I saw was an example...
In any event, the FCC isn't going away any time soon. Sure, spread spectrum can make some aspects of the FCC's purpose irrelevant, but 1) not all, 2) there's a huge installed base of hardware that doesn't use spread spectrum (and much of that cannot use spread spectrum at all) and 3) the people who own and control that huge installed base of hardware have lots of money involved, and will not give up their allocated spectrum without a serious fight.
That, and I don't really see what OSS has to do with any of this, even after reading the article.
In any event, the FCC is very much in power now, and will be for quite some time, in spite of what Moglen may want. If you want to broadcast with your unlicensed spread spectrum radio, you're limited to some small bits of spectrum, where's there's already lots of other transmitters to contend with, and your output power is seriously limited. (Hams get more spectrum to work with, more power and some more flexibility, but they also have a lot more restrictions.) If you start broadcasting outside that spectrum and interfering with other spectrum users, the FCC will come down on your -- hard. They don't do much investigation on their own anymore, but the radio stations or police departments or hams or whoever you're interfering with will do their own investigation, forward the data to the FCC, and the FCC will act.
(Sorry, couldn't resist. Perhaps I should have, but I'm surprised that nobody else has alread done it. Sure, the quote was originally about Usenet, but it's close enough...)
Well, you hinted at this, but I'll be more explicit -- I suspect the reason that it sounds terrible has nothing to do with TCP/IP or ethernet, and everything to do with poor sound quality speakers and location, and there's probably some problems with the digitation of the sounds as well. Perhaps it's all based on some old cassette tapes somebody had lying around? (And really, `It's a Small World' sounds terrible no matter how perfect the sound system is:)
Done properly, music over TCP/IP could sound as good as music over anything else that's digital. The biggest problems that I'd see would be making sure that there was enough buffering so that some very minor packet loss wouldn't cause problems, and some serious time sychronization stuff going on to make sure that the left and the right speakers (and especially speakers playing the same stream) don't get out of sync with each other. The buffering would be simple enough, but getting the sychronization right could be tricky.
Doesn't seem like much of an attack to me. Certainly, I hope it's not very effective anymore.
They probably throw the book at him due to the charity nature of the site -- as if doing anything `bad' to a charity (with a worthwhile mission) is worse than doing something `bad' to an average business. (And of course lying to the police and getting caught isn't a good plan either.)
Yes, but generally you have to be sworn in or otherwise lie under oath to be convicted of perjury. (At least in the US. I don't know what the laws look like on the other side of the pond.)
Generally making a statement to the police isn't done under oath.
And really, if the crime was perjury, why wasn't he convicted for perjury and not something else?
None of the applications which were actually broken by XP SP2 are something granny would run.
Have you even looked at your linked Microsoft KB items?
Your `broken' list is just a list of programs that need to have ports opened on the firewall. I wouldn't consider that broken, though it certainly could be seen as such by grandma. (And as for things that granny might run, I agree, she might not want to run Tivoli, but why couldn't she frag you in UT 2003?)
Your `affected' list is much more relevant, however, the `loss of functionalities' given includes such gems as `Program installs, but will not start.' I wouldn't call that a minor problem. (And Photoshop *is* something my grandmother has run, and that goes for a lot of other programs in the list.) In any event, about half of the problems are so serious that the program won't run or install at all.
Of course, what's my point? Not really that any of these programs are or aren't broken, or that Windows itself is broken, but ultimately grandma is going to blame the problem either on Microsoft or AOL, because the update was made to Windows and came over AOL.
Who will she call? Last I checked, Microsoft won't even talk to you on the phone without paying for a $75 or so support call, so that's out. The program vendor would probably help, and in fact they're probably the right person to call, but since it's not just one program, and it happened right after AOL installed something on her computer, she'll probably call AOL first...
In the three cases we ran into when I was a consultant last year we placed the blame squarely on the shoulders of the vendor with the foobar product
Ok, but most Windows users don't have anything to do with consultants, and think that vendors are the guys who sell hotdogs (or the things you close to stop the wind from coming in, depending on where they live.)
Ultimately, think of Grandma. She fires up AOL, then her computer tells her that she needs SP2. She goes `ok' and many hours later, SP2 is done, and her {insert program useful to grandma here} application no longer works. She's not likely to blame this on the creator of the program -- she'll blame it on either Microsoft or AOL. (After all, grandma is no dummy. She knows that the program didn't change -- only Windows did. And perhaps AOL made it do it.)
Won't this crutch actually tempt people to write sloppy memory management because "the heap manager will catch it?"
Well, it'll catch it... and the application will immediately crash.
I don't see how that encourages writing `sloppy memory management'. Nobody wants an application that crashes. (Granted, it's correct for an application to immediately exit when it's in danger of doing damage to something, but to an end user, they don't want their application to crash.)
Perhaps if somebody is explicitly writing their application to be secure, they could worry less about their memory management and assume that the OS will keep them honest (as it should) but ultimately, an application that crashes isn't very useful. And most end users don't care much about security anyways (though if they're using OpenBSD, odds are that they care about security more than most) and would much prefer something that doesn't crash.
Is the performance hit really worth it?
Theo seems to think so. If you disagree, either disable it (it sounds like it's at least somewhat configurable, and even if not, you do have the source), or use another OS.
Sounds like those programs were broke from the start
Perhaps, but look at it from the user's perspective :
First, their system is working properly. Their OS is working, and their application is working. And then SP2 comes out, and they install it. And their application stops working.
Who are they likely to blame? Microsoft of the creator of their application? They'll look at what changed, and decide that Microsoft is to blame. And if this application is important, they'll even back out SP2 to make it work again.
The idea is that local communities can't tax the Feds or impose regulations on them. Otherwise they clearly would, and it would lead to chaos. E.g. the City of Berkeley would tax the hell out of the Feds, until they agreed to make the whole country a nuclear free zone, or cut off all business with Myanmar (Burma).
There's no fundamental reason why the local governments couldn't (if that was the law) tax federal land. Perhaps there would be some friction, but whenever one entity is charging another entity for something, there's always friction.
Ultimately, this is the case (where local communities don't get to tax the federal government) because that's the way the law has evolved. It could have evolved differently, but it didn't, and I don't see it changing now. (And it could go both ways. Perhaps the local government should be taxed by the IRS?:)
In any event, as are a we have $30 million in unfunded retirement liabilities. We need the money goes, um, too bad! You need new tax sources that the law currently explicitly denies you due to your own financial incompetence? Really, somebody needs to tell that guy never to speak to the press again.
So the "problem" is due to the law, not Google.
Obviously. Google may be taking advantage of the law, but that's what corporations do (and indiviuals, for that matter.)
you work in IT department, when is the last time you drove in at 9 AM and drove home at 5 PM? I work in IT department and I only heard of such myth by my parents back in 1960's.
Odd. I worked in an IT department, and for the most part, I worked 8 hour days, though it was more 10a-6p because I liked to sleep in (that wasn't your point, was it?). Sure, I might occasionally have to do stuff outside of those hours, but it was the exception rather than the rule.
This was even the case when I was the entire IT department...
It all depends on the job, I guess. Certainly, IT doesn't doesn't mean `lots of overtime' substantially more than other professions...
You seem to confuse a few things.
Linux is not an operating system. Linux is a kernel, and this utilizes whatever userland you choose.
I'm not confused about that. I do make some assumptions when I write things, and in that case I'm assuming that the reader understand it. I'm glad to see that you understand it.
I doubt i have any GNU software on my FreeBSD 5.4-P6 boxen.
On a FreeBSD 4.9 box --
% find/usr/share/man -type f | xargs zegrep -l 'GNU|GPL|/gnu/' | \ sed 's/.*\///' | sed 's/\.gz$//' | sed 's/\.[0-9]$//' | sort | uniq | xargs | fmt
No, they don't. None of these rely on the other. They are each seperate wholes. Maybe this could have been seen as fragmentation years ago when they forked but now they are very much seperate complete entities. No fragmentation.
Your point seems to be that the *BSDs aren't fragmented because they're so different now. Compare this to the Linux distributions, which are fragmented because they're still quite similar -- in fact, similar enough to run the same binaries in most cases.
Which I guess is valid, but it really depends on what you decide that `fragmented' means. The *BSDs (and I forgot to mention BSD/OS, MacOS, SunOS 4, Ultrix and others) are just `so fragmented' that they all look different and run different binaries, where the Linux distributions are similar enough that they can generally even run the same binaries.
So rather different is better than very similar? I can see some truth to that (as it would reduce confusion) but being different also means that commercial software is less likely to be found on the rather different systems, and in fact that is the case -- the *BSDs don't have nearly as much commecial software support as the Linuxes.
There have been a number of times when some Linux software I was trying to run, required a specific version and distro of linux to run without a recompile. If it was a comercial app, like VMware, I might have to settle for a distro I don't like and possibly an older version with a kernel that is far from up-to-date. This shows a certain type of fragmentation in Linux development.
Compare this to the *BSD version of the story, where you have an application that was built for BSD/OS, but you want to run it under FreeBSD. And it won't run, period. (Though I don't know what the binary compatibility/emulation between the BSDs looks like. Perhaps FreeBSD can run BSD/OS binaries in some cases -- I've never tried.)
So which is better? Being able to run something if you jump through some hoops, or not being able to run it at all?
However BSD systems as they stand on their own, are whole and not developed in any fragmented manner. They have their own kernels.
Actually, the various Linux distributions generally have their own kernel forks too. And the BSDs do incorporate changes made in other BSDs, though in that case the kernels are a more different so it's more difficult to do. The BSDs just don't have a `master' kernel anymore, though FreeBSD and NetBSD do have other distributions that DO share it's kernel, and there's several embedded systems built on FreeBSD that would be seen as other distributions.
Ultimately, the biggest difference between the *BSDs and the Linux distributions regarding `fragmentation' is that people tend to treat the *BSDs seperately, and to lump all of Linux under `Linux'. It's like they're expecting more of the Linuxes -- that they expect things to work under any Linux distribution, but only under one *BSD. And the Linuxes mostly deliver, but not completely -- and they gets faulted for that.
I guess the answer to the `fragmentation' issue (as it seems to be seen by you and many others) would be to make a Linux distribution that's not binary compatible with other distributions at all, and is configured and administerred differently, and to call it something other than Linux. Then it would be just like another *BSD -- not that compatible with anything else. And nobody would use it, because they'd rather have a better supported Linux distrubution, which will be compatible with a lot more things.
I prefer OpenBSD and FreeBSD where ever I can use them, because I know them best and have come to love them the most. When they both fall too short for a specific application that I need to get going, I look elsewhere.
Is that relevant at all to a discussion about `fragmentation'?
This is the only thing I take issue with. I honestly usually find that reverse engineered drivers are some of the best you can get. They're generally done by people who know what they're doing.
Yes, they're done by people who know what they're doing, because it's hard to do.
Howeve, reverse engineering doesn't always catch corner cases that happen very infrequently. So the reverse engineered driver may work fine on the developer's system, but then it gets on another system and it locks up the system on a regular basis because there's something different that the developer didn't anticipate. Had the developer had access to the (internal) documentation that goes along with the device/chipset, he'd have known that he needed to test for and handle this case, but since he didn't, he didn't.
As much as I'd like to say otherwise, expericence tells me that many Linux device drivers have bugs. Some are fatal, crashing the box or totally breaking the device in question, and some just slow things down. Mostly this is the case only with brand new hardware or things that are used very infrequently (or haven't been updated in years, being obsolete) but the bugs are still there. Windows drivers have bugs too under the same conditions, but they seem to be less common. Or maybe the occasional crashes are being blamed on Windows as a whole (because your debugging options are limited once the GUI locks up) rather than on a specific driver. Who knows?
In any event, if you want maximum system reliability, you want time-tested devices and drivers. Stay away from the bleeding edge, for both Windows and Linux, though the very first version of the Windows drivers for something are more likely to work reliably than the very first version of the Linux drivers for the same device, especially if the Linux driver had to be reverse engineered rather than being written from the proper documentation. (Though the Linux driver will probably get fixed faster if needed.)
Conversely, the absolute worst drivers you get on Linux are almost* always the binary vendor written drivers.
* Nvidia being the exception.
Generally agreed, though I've had my share of problems with the Nvidia drivers locking up the console (so I have to log in remotely and kill X, and even that doesn't always make the console usable) or my entire system. Granted, it's been a little while since I've seen this, but it certainly plagued me for a while.
which currently supported version of Windows can even reasonably run on a 386/25?
You didn't read the post in question very carefully, did you? The print server was running under FreeBSD, not Windows. Even the latest FreeBSD still supports 386 cpus, though memory might be a bit tight.
You can suspect and imagine all you want. EXPERIENCE however, would tell you otherwise.
Indeed. A few years ago, I recall putting two parallel port cards into an old 486/50 box and putting Linux on it, and putting two printers on it. Even if both printers were actively being used, the load average never went above 0.1. The box ran both lpd and samba, so printing could be done from Windows and *nix.
Eventually the printers were replaced with printers with built-in network connections and the machine retired (again -- it was pulled out of retirement to be a print server), but until then, it sat there idle for 99% of the time even when people were printing lots of stuff.
I have a laser printer that can print PostScript or PCL. If you print PostScript, it can take several minutes per page to turn it into a bitmap using its internal 50MHz MIPS processor.
I was referring to a a computer working as a print server, not the printer itself.
But yes, if the print server is doing anything more than just feeding files to the printer port (like invoking ghostscript to convert postscript files to a bitmap in some printer format) it'll require lots more cpu. But if all you're doing is feeding what's fed to the lpd port to/dev/lp0 (with the queuing and such that goes along with that) its' a very lightweight operation.
Contrast this with a FreeBSD machine running a Samba printer and 5 shared drives used by 22 other system, on a P3-800 with 768MB PC100. No lag in Firefox in X even under a heavy load, like 20 machines grabbing 2GB of files each and one machine printing out report after report.
And that's very much an apples to oranges sort of comparison. If you're going to do benchmarks, you need to pick similar tasks. The tasks you described (game servers vs. file server) are very different.
Note that running a print server for one printer is a very lightweight operation. A 386/25 could probably handle the load just fine. As for the file server part of it, that's a more difficult operation, but the load being put on the system could easily vary by a factor of 100 (merely saying `22 machines' and `2 GB files' doesn't tell us much.)
If you want a more reasonable comparison, set up the same file sharing and printer server on a Windows box, and see how that compares to the FreeBSD box. I suspect that on identical hardware that the performance will be similar -- after all, smb is a Windows protocol, and I imagine that Windows implements much of it in kernel space, where with Samba it's in userspace.
Granted, the FreeBSD box would probably be more reliable, but you weren't talking about reliability...
The BSDs don't have the fragmentation that Linux has.
They don't? Then why is there FreeBSD, OpenBSD and NetBSD? (And 386BSD, but it's dead, probably mutated into one (or all three) of the ones I just mentioned.) And then there's the sub-flavors, like Dragonfly BSD.
I say simply "FreeBSD"
Sort of like somebody might say `RedHat'. Or `Debian'. You get the idea.
By that I qualify my package management, my system boot scripts, where my conf files are, how the system works
Yes. And saying Redhat, or Debian or whatever else would qualify it as well.
"Linux", on the other hand, can mean a bunch of things:
Saying "BSD" is almost as imprecise. Really, it's hard to fault an OS just because people don't qualify it very well.
Do the same applications run on each of the *BSDs without recompliation? I tend to doubt it, but I haven't tried it...
Apache is Apache no matter in which Linux distro you run it
No, it's not. Is it Apache 1 or Apache 2? The two are very different. Which modules are configured? Default configurations vary wildly. Yes, if you know what you're doing you can easily bring them under control, but for an amateur who's just using the Apache that came with his installation, things can be VERY different from distribution to distribution. (Personally, I find myself installing my own Apache and similar daemons, even if one is provided for me, on *BSD, whatever Linux, Solaris, etc. -- it just makes things easier, starting from a known quantity. And more secure.)
okay, Stallman, GNU/Linux, as you wish
It's not up to Stallman. Call it whatever you want. Your *BSD box has a lot of GNU stuff on it too... call it GNU/BSD if you wish.
Back on topic, that Linux machine must have had some hardware flaw. Bad memory comes to mind...
That is a possiblity, but Windows hasn't really been more immune to bad memory than Linux since NT came out. Linux even has the ability to map-out known bad blocks of memory (so you can use those iffy DIMMS in the closet), though I doubt many people use it.
In any event, certain hardware devices have buggy drivers, even in the latest versions of whatever Linux kernels and distributions you prefer. The vendors generally make Windows drivers, where the Linux drivers are often reverse engineered, and it often shows in the quality.
For the *BSDs, the drivers you get are generally more reliable than those in Linux, but if you've got some new device, where Linux would support it (and the driver might have some issues), *BSD is likely to not support it at all.
But I do agree with you too -- FreeBSD does make a better server than any of the Linux distributions. However, the commercial application support is very spotty. However, I've heard that the Linux emulation is quite good, and it can run most Linux applications with little trouble. Though that just sounds so... wrong... to use it for a production server. But if it works...
Slashdot Mirror
Making good on the `lifetime warranty' memory very well may cost the Chip Merchant money, so the results are quite likely to be very different.
Well, I said nay (sort of), so I guess that makes me a naysayer. Ok, but you should be aware of the odds. If a company is shady, the BBB is not going to make them un-shady, and the Chip Merchant is sounding very shady here. And lots of BBB members are shady.For example, you may remember this fiasco a few years ago, where Best Buy sold a bunch of GF4 Ti4600 cards for $139, but wouldn't deliver them. The BBB was contacted repeatedly, and did nothing, even though this was exactly the sort of case where one would have thought that they should have done something. The many complaints made weren't even showing up on as complaints against Best Buy on the BBB site, when they certainly should have (even if the complaints were without merit, which they were not.) Remember, it's the business who pays the BBB, and the BBB is a business looking to make a profit like any other, and their #1 duty is to their customer (the company), not to you.
If your business is not a member, then the BBB can't do anything to it.
If your business is a member, the BBB will rate it based on the number of complaints they've received on it and they'll make some token efforts to resolve complaints, but if the company doesn't want to play ball, the BBB can't do anything except rate somebody `unsatisfactory' or something similar if there's enough complaints (and there needs to be quite a few.) But before that happens, a shady business will just drop it's membership, and that's that -- they lose the sticker, and that's about it.
And Bush isn't dumb. People like to say he is, but he's really not. But seriously, nobody has enough time to learn everything and keep up to date on it, and it's good that Bush knows how to delegate and rely on his advisors. (Though he's made some awful decisions. I don't know if it's due to bad advice or bad decisions based on that advice.)
Of course, that statement applies to almost everybody who ever gets to the point where the have a chance at being elected president.Not that any of this is really relevant to Congress's $3B subsidy.
In any event, I really liked the Tron 2.0 game. I wonder if they make a Tron 2.0 movie, would it be a sequel to the movie Tron (in which case it's likely to suck, but could be OK) or a movie version of the game (in which case past experience tells us that it's doomed?)
Though to be fair, the restrictions are sort of important. Yes, I'd like to see a lot more spectrum allocated to unlicensed uses -- not just the tiny slivers that are now -- but having pretty serious power limitations is probably a good thing, since people generally don't care who they're interfering with -- all they care about is that their WiFi network or their cordless phone or CB radio works. (But conversely, if somebody else interferes with them, look out!)
In theory spread spectrum generally ignores interference, but that's only in theory -- in practice, it's relatively simple to knock out the entire WiFi band in an area, for example. Accidently or intentionally.
For an individual who's looking to experiment, getting a technician class amateur radio license is relatively simple, and that gets you access to several chunks of bandwidth that you can use, often with up to 1500 watts of power. But if you go under the ham rules, there are signifigant restrictions -- you must ID yourself every 10 minutes, no encryption, no pecuniary (financial) interest, etc. It's cool for a hobbyist, but it's not really right for everybody.
Also, having a space station down as close to the Earth as is practical allows them to do lots of things that would be harder from much further out. Rememeber, we're talking 200 miles vs. 22,000 miles. Also, the ISS travels over much of the Earth each orbit, which allows it to do things over much of the Earth's surface if needed.
A geosychronous or geostationary satellite is always in approximately the same place above the Earth all the time, so if you want to do an experiment that needs to be done over Texas ... too bad. A geosynchronous or geostationary satellite is always approximately (geosynchronous satellites do move around a little bit) above the same place -- which is always on the equator. It's also a bit crowded up there already ...
I wonder if the ISS gets signifigantly more benefits of shielding from radiation up there by the Earth's magnetic field than it would if it were at 22,000 miles? It may be that going up to 22,000 miles would increase the overall radiation so much that humans couldn't live up there for an extended period of time without lots of very heavy and expensive shielding? (I don't know, it's just a guess.)
And at a mere 200 miles up, I can even whip out my 5 watt ham band handi-talkie radio and can reach the amateur repeater on the ISS. Were it 22,000 miles up, I'd need more power and bigger antennas.
There is no impending catastrophe here. There was a problem, yes, but the ISS is still many months from crashing into the Earth -- there's lots of time to get these problems fixed.In any event, the FCC isn't going away any time soon. Sure, spread spectrum can make some aspects of the FCC's purpose irrelevant, but 1) not all, 2) there's a huge installed base of hardware that doesn't use spread spectrum (and much of that cannot use spread spectrum at all) and 3) the people who own and control that huge installed base of hardware have lots of money involved, and will not give up their allocated spectrum without a serious fight.
That, and I don't really see what OSS has to do with any of this, even after reading the article.
In any event, the FCC is very much in power now, and will be for quite some time, in spite of what Moglen may want. If you want to broadcast with your unlicensed spread spectrum radio, you're limited to some small bits of spectrum, where's there's already lots of other transmitters to contend with, and your output power is seriously limited. (Hams get more spectrum to work with, more power and some more flexibility, but they also have a lot more restrictions.) If you start broadcasting outside that spectrum and interfering with other spectrum users, the FCC will come down on your -- hard. They don't do much investigation on their own anymore, but the radio stations or police departments or hams or whoever you're interfering with will do their own investigation, forward the data to the FCC, and the FCC will act.
de AD5RH
(Sorry, couldn't resist. Perhaps I should have, but I'm surprised that nobody else has alread done it. Sure, the quote was originally about Usenet, but it's close enough ...)
Done properly, music over TCP/IP could sound as good as music over anything else that's digital. The biggest problems that I'd see would be making sure that there was enough buffering so that some very minor packet loss wouldn't cause problems, and some serious time sychronization stuff going on to make sure that the left and the right speakers (and especially speakers playing the same stream) don't get out of sync with each other. The buffering would be simple enough, but getting the sychronization right could be tricky.
Doesn't seem like much of an attack to me. Certainly, I hope it's not very effective anymore.
They probably throw the book at him due to the charity nature of the site -- as if doing anything `bad' to a charity (with a worthwhile mission) is worse than doing something `bad' to an average business. (And of course lying to the police and getting caught isn't a good plan either.)
Generally making a statement to the police isn't done under oath.
And really, if the crime was perjury, why wasn't he convicted for perjury and not something else?
Your `broken' list is just a list of programs that need to have ports opened on the firewall. I wouldn't consider that broken, though it certainly could be seen as such by grandma. (And as for things that granny might run, I agree, she might not want to run Tivoli, but why couldn't she frag you in UT 2003?)
Your `affected' list is much more relevant, however, the `loss of functionalities' given includes such gems as `Program installs, but will not start.' I wouldn't call that a minor problem. (And Photoshop *is* something my grandmother has run, and that goes for a lot of other programs in the list.) In any event, about half of the problems are so serious that the program won't run or install at all.
Of course, what's my point? Not really that any of these programs are or aren't broken, or that Windows itself is broken, but ultimately grandma is going to blame the problem either on Microsoft or AOL, because the update was made to Windows and came over AOL.
Who will she call? Last I checked, Microsoft won't even talk to you on the phone without paying for a $75 or so support call, so that's out. The program vendor would probably help, and in fact they're probably the right person to call, but since it's not just one program, and it happened right after AOL installed something on her computer, she'll probably call AOL first ...
Ultimately, think of Grandma. She fires up AOL, then her computer tells her that she needs SP2. She goes `ok' and many hours later, SP2 is done, and her {insert program useful to grandma here} application no longer works. She's not likely to blame this on the creator of the program -- she'll blame it on either Microsoft or AOL. (After all, grandma is no dummy. She knows that the program didn't change -- only Windows did. And perhaps AOL made it do it.)
It must really suck doing AOL tech support :)
I don't see how that encourages writing `sloppy memory management'. Nobody wants an application that crashes. (Granted, it's correct for an application to immediately exit when it's in danger of doing damage to something, but to an end user, they don't want their application to crash.)
Perhaps if somebody is explicitly writing their application to be secure, they could worry less about their memory management and assume that the OS will keep them honest (as it should) but ultimately, an application that crashes isn't very useful. And most end users don't care much about security anyways (though if they're using OpenBSD, odds are that they care about security more than most) and would much prefer something that doesn't crash.
Theo seems to think so. If you disagree, either disable it (it sounds like it's at least somewhat configurable, and even if not, you do have the source), or use another OS.First, their system is working properly. Their OS is working, and their application is working. And then SP2 comes out, and they install it. And their application stops working.
Who are they likely to blame? Microsoft of the creator of their application? They'll look at what changed, and decide that Microsoft is to blame. And if this application is important, they'll even back out SP2 to make it work again.
Ultimately, this is the case (where local communities don't get to tax the federal government) because that's the way the law has evolved. It could have evolved differently, but it didn't, and I don't see it changing now. (And it could go both ways. Perhaps the local government should be taxed by the IRS? :)
In any event, as are a we have $30 million in unfunded retirement liabilities. We need the money goes, um, too bad! You need new tax sources that the law currently explicitly denies you due to your own financial incompetence? Really, somebody needs to tell that guy never to speak to the press again.
Obviously. Google may be taking advantage of the law, but that's what corporations do (and indiviuals, for that matter.)This was even the case when I was the entire IT department ...
It all depends on the job, I guess. Certainly, IT doesn't doesn't mean `lots of overtime' substantially more than other professions ...
I'm not confused about that. I do make some assumptions when I write things, and in that case I'm assuming that the reader understand it. I'm glad to see that you understand it.
On a FreeBSD 4.9 box --
Which I guess is valid, but it really depends on what you decide that `fragmented' means. The *BSDs (and I forgot to mention BSD/OS, MacOS, SunOS 4, Ultrix and others) are just `so fragmented' that they all look different and run different binaries, where the Linux distributions are similar enough that they can generally even run the same binaries.
So rather different is better than very similar? I can see some truth to that (as it would reduce confusion) but being different also means that commercial software is less likely to be found on the rather different systems, and in fact that is the case -- the *BSDs don't have nearly as much commecial software support as the Linuxes.
Compare this to the *BSD version of the story, where you have an application that was built for BSD/OS, but you want to run it under FreeBSD. And it won't run, period. (Though I don't know what the binary compatibility/emulation between the BSDs looks like. Perhaps FreeBSD can run BSD/OS binaries in some cases -- I've never tried.)So which is better? Being able to run something if you jump through some hoops, or not being able to run it at all?
Actually, the various Linux distributions generally have their own kernel forks too. And the BSDs do incorporate changes made in other BSDs, though in that case the kernels are a more different so it's more difficult to do. The BSDs just don't have a `master' kernel anymore, though FreeBSD and NetBSD do have other distributions that DO share it's kernel, and there's several embedded systems built on FreeBSD that would be seen as other distributions.Ultimately, the biggest difference between the *BSDs and the Linux distributions regarding `fragmentation' is that people tend to treat the *BSDs seperately, and to lump all of Linux under `Linux'. It's like they're expecting more of the Linuxes -- that they expect things to work under any Linux distribution, but only under one *BSD. And the Linuxes mostly deliver, but not completely -- and they gets faulted for that.
I guess the answer to the `fragmentation' issue (as it seems to be seen by you and many others) would be to make a Linux distribution that's not binary compatible with other distributions at all, and is configured and administerred differently, and to call it something other than Linux. Then it would be just like another *BSD -- not that compatible with anything else. And nobody would use it, because they'd rather have a better supported Linux distrubution, which will be compatible with a lot more things.
Is that relevant at all to a discussion about `fragmentation'?Howeve, reverse engineering doesn't always catch corner cases that happen very infrequently. So the reverse engineered driver may work fine on the developer's system, but then it gets on another system and it locks up the system on a regular basis because there's something different that the developer didn't anticipate. Had the developer had access to the (internal) documentation that goes along with the device/chipset, he'd have known that he needed to test for and handle this case, but since he didn't, he didn't.
As much as I'd like to say otherwise, expericence tells me that many Linux device drivers have bugs. Some are fatal, crashing the box or totally breaking the device in question, and some just slow things down. Mostly this is the case only with brand new hardware or things that are used very infrequently (or haven't been updated in years, being obsolete) but the bugs are still there. Windows drivers have bugs too under the same conditions, but they seem to be less common. Or maybe the occasional crashes are being blamed on Windows as a whole (because your debugging options are limited once the GUI locks up) rather than on a specific driver. Who knows?
In any event, if you want maximum system reliability, you want time-tested devices and drivers. Stay away from the bleeding edge, for both Windows and Linux, though the very first version of the Windows drivers for something are more likely to work reliably than the very first version of the Linux drivers for the same device, especially if the Linux driver had to be reverse engineered rather than being written from the proper documentation. (Though the Linux driver will probably get fixed faster if needed.)
Generally agreed, though I've had my share of problems with the Nvidia drivers locking up the console (so I have to log in remotely and kill X, and even that doesn't always make the console usable) or my entire system. Granted, it's been a little while since I've seen this, but it certainly plagued me for a while.Eventually the printers were replaced with printers with built-in network connections and the machine retired (again -- it was pulled out of retirement to be a print server), but until then, it sat there idle for 99% of the time even when people were printing lots of stuff.
But yes, if the print server is doing anything more than just feeding files to the printer port (like invoking ghostscript to convert postscript files to a bitmap in some printer format) it'll require lots more cpu. But if all you're doing is feeding what's fed to the lpd port to /dev/lp0 (with the queuing and such that goes along with that) its' a very lightweight operation.
Note that running a print server for one printer is a very lightweight operation. A 386/25 could probably handle the load just fine. As for the file server part of it, that's a more difficult operation, but the load being put on the system could easily vary by a factor of 100 (merely saying `22 machines' and `2 GB files' doesn't tell us much.)
If you want a more reasonable comparison, set up the same file sharing and printer server on a Windows box, and see how that compares to the FreeBSD box. I suspect that on identical hardware that the performance will be similar -- after all, smb is a Windows protocol, and I imagine that Windows implements much of it in kernel space, where with Samba it's in userspace.
Granted, the FreeBSD box would probably be more reliable, but you weren't talking about reliability ...
Do the same applications run on each of the *BSDs without recompliation? I tend to doubt it, but I haven't tried it ...
No, it's not. Is it Apache 1 or Apache 2? The two are very different. Which modules are configured? Default configurations vary wildly. Yes, if you know what you're doing you can easily bring them under control, but for an amateur who's just using the Apache that came with his installation, things can be VERY different from distribution to distribution. (Personally, I find myself installing my own Apache and similar daemons, even if one is provided for me, on *BSD, whatever Linux, Solaris, etc. -- it just makes things easier, starting from a known quantity. And more secure.) It's not up to Stallman. Call it whatever you want. Your *BSD box has a lot of GNU stuff on it tooIn any event, certain hardware devices have buggy drivers, even in the latest versions of whatever Linux kernels and distributions you prefer. The vendors generally make Windows drivers, where the Linux drivers are often reverse engineered, and it often shows in the quality.
For the *BSDs, the drivers you get are generally more reliable than those in Linux, but if you've got some new device, where Linux would support it (and the driver might have some issues), *BSD is likely to not support it at all.
But I do agree with you too -- FreeBSD does make a better server than any of the Linux distributions. However, the commercial application support is very spotty. However, I've heard that the Linux emulation is quite good, and it can run most Linux applications with little trouble. Though that just sounds so ... wrong ... to use it for a production server. But if it works ...