Well, for those who really can't afford to make a financial contribution, there are other ways that they can help out. Here are a few I can think of right off the top of my head:
They can contribute back more free software, which is probably the best way.
They can help debug or otherwise improve free software.
They can help write documentation for free software.
They can help provide technical support for other users (especially newbies).
So while your point about money making the world go round is good up to a point, it isn't the only thing.
So why aren't all Americans using Debian, it rocks when you don't have to worry about phonebills.
We still have the problem of being impatient or having to share a phone line with spouses, roomates, parents, etc.
Buying a CD is often just plain more palatable than downloading even when it doesn't necessarily make complete sense from a strictly monetary point of view.
Besides that, American techies are supposedly fairly afluent financially compared to the european average, so we should theoretically be able to afford to buy more CDs.
I believe that LinuxMall does have cheap (less than $5) SuSE 6.1 CD's. The $27.50 list InfoMagic 6-CD "Linux Developer's Resource" CD set includes SuSE 6.1 (of course it also includes RedHat 6.0, Caldera OpenLinux 2.2, Slackware 4.0 and some other stuff). So there may not be as much of a cost issue with SuSE as an awareness issue.
RedHat might have reported losses, but they charge less for their distribution and thus enjoy a lot more installations.
Actually, RedHat (as of 6.0) charges more than SuSE. RedHat's list price for their Official 6.0 box is now $80, compared to SuSE's list price for their Official 6.1 box which is still $50.
The price differential is one of the primary reasons I bought the boxed version of SuSE 6.1 instead of the boxed version of RedHat 6.0.
I will probably want to put RedHat 6.0 on a couple of my boxes which currently have RedHat 5.2 on them, but I think I will just buy the CheapBytes CD (for $2 plus shipping, or about $10 total).
Incidentally, CheapBytes and/or LinuxMall also sell cheap CD-only versions of SuSE 6.1, Mandrake 6.0, Debian 1.3 and 2.1, and Slackware 4.0, Stampede and even FreeBSD, NetBSD and OpenBSD for those so inclined.
Yet more evidence that the U.S. Gov't's policy on export control of crypto products is obsolete. Sorry spooks, its already overseas, and its well known enough that students can even put it in hardware. Give up already.
Depends how you use it. Projects I work on are always cross-platform, usually some variant of Unix and NT.
The projects I used to work on when I was subjected to NT were usually cross-platform, although few started out that way. Some started out on *nix, and some on Windows. I did most of the work to make the code portable. I was often working with code that I hadn't written at all.
What we do is create an include file that lists the source files, a makefile for the Unix side, and a makefile.mak for the NT side.
I ended up scrapping M$'s make and using a port of GNU Make for Win32. M$'s make not only seemed to be a cruel joke, it also seemed to be a moving target (changed between versions of MSVC and the automated conversion usually failed). Later on I switched to using Watcom (Powersoft) C/C++ for Windows compiles, as it has significantly better cross-platform compliance (working strcpy(), strcat(), opendir(), readdir(), etc).
The top-level makefile has targets that invoke each of the subdirectory makes. The most likely thing to burn you is that it's natural to use the directory names of the sub-projects as the names of the top-level make targets, and that doesn't work (changing the source files always updates the timestamp of the directory, so M$ nmake doesn't chase down the sub-project build.)
I've seen wacky things like that happen. I am glad I don't have to deal with it anymore.
On NT, create a top-level project using the existing makefile.mak, and sub-projects for the subdirectories. You can select your top-level project to build everything, or individual sub-projects as necessary.
Personally I just use MSVC for debugging -- I do the actual builds using command line windows and the MKS utilities.
That sounds kinda similar to what I ended up doing. You almost have to have something like MKS, albiet even with a lot of add-on utilities, I could never really get an environment under NT I was happy with.
Setting up the whole project under MSVC and then trying to port to cross platform makefiles takes much more time than starting with your own makefiles and wrapping M$ project files around them -- the makefiles generated by MSVC have platform-specific directives and really don't look much like makefiles if you let MSVC manage them directly.
If you use their generated files, they don't seem to be intended to be human readable at all.
I gotta admit -- M$ IDE is far, far ahead of most Linux/Unix tools for debugging.
M$'s IDE is far flashier than most of the free tools, but I am not sold on its overall functionality. More often than not, my experience with the MSVC debugger was that errant code either froze the whole machine, blue screened the machine, or crashed the debugger. In other words, it was worse than useless.
Kind of irritates me that *nix platforms still haven't got such functionality unless you look at the multi-K$ price range,
For work, multi-K$ prices aren't that big an issue. M$'s 'Enterprise' versions of their tools aren't all that cheap either. For my outside work I do at home, M$'s tools are just too expensive. I can't justify spending $3,000+ for NT+MSVC+MKS+ other 3rd party tools versus what I get when I buy a $50 box from SuSE.
and even then only if you've got a truly obscene amount of memory so that the multiple debug and executable processes don't thrash themselves to death.
I use SparcWorks at work, it has a debugger I like a lot better than that in MSVC, and it runs fine on an Ultra 5 with 128M of RAM.
Yeah, yeah -- xdb, dbx, gdb, yada yada -- I've got several years experience with them, and only 2-3 years with MSVC, but it only took 6 months to convince me the M$ debug environment was a much cleaner solution.
I spent a year with MSVC, and it convinced me that I never want to do development on Windows again.
It gets really addictive to be able to step-trace through code as quick as you can hit the function keys, rather than waiting for the 0.5-2.0 second lag with the *nix debuggers,
I've never noticed that kind of lag.
and I have found nothing under *nix that lets me set watch points over memory regions the way I can with MSVC
SparcWorks debugger has a feature like that, I've seen a similar utility on IRIX, but that was quite some time ago.
(nothing else is anywhere near so handy for tracking down that rogue piece of code that's overwriting memory it shouldn't be touching!)
You might look at Purify and Electric Fence.
Big projects? Currently working on one that's well over 500K lines, expected to exceed 1M during the next year. No debug problems on NT or *nix so far, other than the ever increasing memory requirements during debugs -- and the ever decreasing screen space.
Most of the projects I work on these days are smaller (less than 200,000 lines), and I no longer have to do any Windows development, so all is happy for me.
Ever heard of a white-noise generator? You know what white noise does to *any* type of signal. It would be quite easy to jam your computer's interference (and legal too, just keep the amplitude close to your computer's).
Now you are talking about specialized jamming equipment, something that I've said is a possibility, at least it sounds more feasable than relying on masking from generic appliances.
Besides, getting back to the main topic, the police always have other evidence of crimes, beside the encrypted information.
This assumes that the police would be the only people using electronic eavesdropping for surveilance. It can also be an effective tool for such things as industrial espionage, or even just spying on your neighbors, relatives, spouse, etc. The issue is, why make it any easier for someone who might be spying. That is why shielding is a good idea, and in general doesn't have much of a downside except cost. Cost wouldn't be so high if it was a standard practice thing.
Why? Other people trying to save their own skins will 'rat you out'.
That assumes that there is someone else that knows.
How well can, say, VisualC++ do the above? (I'm really asking, as I haven't used it.)
Very poorly. I was entirely unhappy with Visual C++ for large projects (>100,000 lines of code). It doesn't even do well when, for example a 500,000+ line project is divided into smaller executables which are each in the 3,000 to 50,000 line range (not counting of course common library code).
It is no fun trying to set up Visual C++ to rebuild things, for example when you make changes to a common library function and now have to open up several dozen projects, edit them and rebuild. You really need a good scripting tool to do that, and Visual C++ wasn't designed to play nicely with scripting tools.
For me I'd much rather use a UN*X-like environment for large scale development. Thankfully, I can pretty much pick and choose what I work on, so I am lucky enough not to have to deal with Visual C++ anymore.
And don't even get me started about things that are agregiously broken with Visual C++ like lstrcpy(), lstrcat(), etc...
I downloaded it yesterday and installed it on my laptop today. Looks pretty good, although my laptop is too small and slow to do it justice (486SX-33, 36M RAM). I will be installing it on another box (K6-166, 128M RAM) that should be more suitable.
Visual Age for Java is the preferred Java tool where I work, so this is a pretty nice thing to have. I am going to be attending a week long training class on Visual Age pretty soon and I am going to be starting work on a project that is being developed with Visual Age, so I should get some chance to work on it. If it works well for me I will probably buy the professional edition when it ships.
IBM, if you are listening... I'd also like a Solaris (Sparc) version of Visual Age so I could run it on the SparcStation on my desk at work. If it runs on AIX and Linux, it couldn't be much work to make a Solaris version.
Maybe we've worked with different style cases, but the ones I've used don't have power supply issues.
Probably, there are so many different cases out there. Many of the 'slim' cases I have seen only have 120-175 watt power supplies, which may be adequate for most uses, but may not be the best for sustained heavy duty use. Typical mid tower cases usually have 200-250 watt supplies.
As for floppy drives - simple - don't put one in the box.
The problem there is that it may increase the time necessary to service a machine if it dies.
For bulk serving you don't need it.
Very true under normal circumstances, but my concern is when the proverbial excrement hits the rotary oscillator. I want to be able to fix any problem ASAP. Having to find and install a floppy drive in a machine to bring it back up is time I may not want to take.
Nor a CD ROM drive.
That is normally something that you can usually do without, provided one is available on a network reachable machine.
If the box is at a colocation, you're going to get to it via ssh, not standing in front of it.
Provided you aren't dealing with a crashed hard drive or some other issue that can't be solved remotely.
Another complaint I have about a lot of 'slim' cases I've seen is many of them have limited quantities of front-panel accessable drive bays. While that isn't a big deal for most things, one useful thing when you are dealing with a large number of servers is the inexpensive IDE 'lock and load' trays, which make swapping in and out hard drives much faster and easier. It can make large scale upgrades or dealing with crashed drives a lot faster since you can do the work on another machine and then only take down the server box to do the actual swap.
Would seem they could cut down on rack space by 50% or more by going with a slim chassis
Personally I hate most 'slim' style cases for a few reasons:
There isn't enough space to work in them, so SIMM/DIMM slots are often obscured by power supplies, etc. I want something that is easy to work in when I need to get things back up and running quickly.
Most of them use riser cards for the slots, which are a pain in the butt.
Most of them use non-standard motherboard layouts, and part of the idea of building clusters is to have cheap commodity priced, easily upgradeable hardware. Some of them even require goofy special floppy drives (due to custom faceplate bezels).
Slim cases often include wimpy power supplies which may not be as durable and reliable as higher output supplies used in larger cases.
Personally, I like the 'mid tower' type of case. In today's world with huge capacity hard drives, the big full tower cases are often overkill, but the mini-towers are too cramped to work in.
generate too much EM crap (very strong, very random)
operate near soft drink vending machines
The kind of signals emitted from that type of equipment doesn't really fit your criteria, as it is very organized and predictable. It also likely doesn't fall into the same frequency ranges as most of those generated by a laptop (at least not the interesting ones).
While background noise may help some as a jamming source, I'd be suspicious of relying on it as the 'best' way to avoid being eavesdropped on. I have considered the possibilities of active jamming with specialized hardware, however, and that has more potential in my opinion. I don't think I'd consider it a substitute for also doing as much shielding as possible though.
Radio emmisions are on a particular frequency and you are only looking for an "interesting" signal
A very good point, albiet I'd argue that there is often a lot of bleed of signals across from one frequency to another (which in general makes it easier when it comes to eavesdropping, not harder). I've seen a lot of equipment where signals were repeated at various harmonic intervals so that any one signal source was basically polluting a large part of the radio spectrum. The advent of cheap and powerful digital signal processing really worries me when it comes to Van Eck style eavesdropping, because it could be used to very easily isolate those "interesting" signals.
Now I hate to defend Microsoft, but they did have one (1) original idea: BASIC.
Not hardly. BASIC existed way before Microsoft (it was developed as a learning tool for Fortran). Microsoft wasn't even the first implementation, it was available on other systems before Microsoft did Altair BASIC in 1975, for example the DEC and HP minicomputers. In fact, Altair BASIC wasn't even the first BASIC dialect for microcomputers, just the first reasonably full featured one that became commercially successful. When Bill Gates was a student at Harvard, he worked as an intern at one of DEC's research labs, working on, surprise-surprise, DEC's BASIC interpreter for the PDP-11. Not surprisingly, Altair BASIC looked very similar to DEC's BASIC.
I'll just list the things that will interfere with the RF leakage:
While all of that is true to a certain extent, as someone who has seen 'Van Eck' type equipment in operation, I can tell you that you shouldn't be so quick to dismiss the interception of RF leakage as an eavesdropping risk. The basic 'Van Eck' type equipment can be further refined with highly directional antennas, amplification and filtering hardware to increase its ability to discriminately intercept data. It would be probably be safe to assume that the feds have already done this.
Maybe we ought to ban these too or require a TEMPEST compatible transmitter in all non-picture-tube monitors
That might be true if the CRT was the only RF leaker in the typical computer system. The previous poster mentioned eavesdropping on the keystrokes containing the password. Since no reasonable encryption system echoes such keystrokes to the display, I would tend to assume they were talking about eavesdropping on the keyboard itself or something inside the computer directly attached to it. While there are probably less emissions from a device such as a keyboard than from a CRT, there are likely to still be measurable enough amounts that sophisticated and sensitive enough equipment could intercept it. The feds have plenty of money to buy/build such equipment.
Actually I believe that it is around 14%, with Doug Michels and his father each owning somewhere between 10-14%, and all of the rest of the outstanding shares held by people with much smaller percentage interests.
While none of the shares would give a level of absolute control, given an agreement amongst those three shareholders, it would only take a small percentage of the rest to vote with them for them to have their way.
What would your linux system look like if you deleted all beta SW?
Beta means something different in the Linux world than it does for Microsoft. Microsoft releases a lot of things as finished versions that would be considered in the Linux world to be beta (or you could reverse that and say that a lot of things that are released in the Linux world as Beta would be released by Microsoft as a final version). Stuff that Microsoft labels as betas are often of a quality similar to stuff released on Linux as Alpha or pre-Alpha.
I can see why Compaq went with RH for their Alpha CPUs.
Someone else has mentioned that Compaq has a small investment in Red Hat, so that might have something to do with it. Compaq might also have a side agreement with Red Hat exchanging Red Hat's continued support for Alpha for Compaq promoting Red Hat's distribution on their x86 boxes as well.
But why does Dell and the others?
That is probably a better question, since they may not have quite as many obvious reasons.
Not to start a flame war, but it sure would be nice to have the option of Caldera or RedHat.
It would be nice I suppose, but you still have the choice to install Caldera over the top of Red Hat if you want. The fact that Compaq will be doing the homework to make sure the components they put in their machines are Linux friendly will still be a big advantage even for those who choose a different distribution.
Yes RedHat has the name recognition, but no wonder with all these announcements. If these announcements included Caldera or another distribution I would bet they would have just as much 'name' as RedHat.
Maybe, maybe not. Red Hat seems to actively court more media attention, and advertise more widely than Caldera. Red Hat may be more actively seeking out this sort of relationship with companies like Compaq and Dell than Caldera, we really don't know what is going on behind the doors here. A lot of name recognition has to do with how good a company is at promoting themselves, and Red Hat has done a pretty good (albiet not perfect) job there.
I like choice, do you?
Sure, which is why I run Red Hat on some of my machines, SuSE on others, and even have a machine running Caldera (albiet an old version) and one running Slackware. However, I am not a typical Compaq customer. Unfortunately, a lot of the PHB types are actually afraid of choice. For them picking Linux is already a big decision, and having to pick between distributions might just tax their wee brains too much.:-)
Frankly, just having a choice other than Windows is enough of a step in the right direction I have trouble complaining too much about Compaq.
Slashdot Mirror
Or you could get a cable modem or dsl and "apt-get install" or "apt-get dist-upgrade" all day. Less effort that way. :)
If cable modems or DSL are available where you live. In a lot of the U.S., neither are available.
So while your point about money making the world go round is good up to a point, it isn't the only thing.
So why aren't all Americans using Debian, it rocks when you don't have to worry about phonebills.
We still have the problem of being impatient or having to share a phone line with spouses, roomates, parents, etc.
Buying a CD is often just plain more palatable than downloading even when it doesn't necessarily make complete sense from a strictly monetary point of view.
Besides that, American techies are supposedly fairly afluent financially compared to the european average, so we should theoretically be able to afford to buy more CDs.
Dohh. I got burned by being too lazy to preview!
I always forget those pesky greater and less thans in the text.
lack of cheap CD's is a real cost issue
I believe that LinuxMall does have cheap (less than $5) SuSE 6.1 CD's. The $27.50 list InfoMagic 6-CD "Linux Developer's Resource" CD set includes SuSE 6.1 (of course it also includes RedHat 6.0, Caldera OpenLinux 2.2, Slackware 4.0 and some other stuff). So there may not be as much of a cost issue with SuSE as an awareness issue.
lack of cheap CD's is a real cost issue
I believe that LinuxMall does have cheap (
RedHat might have reported losses, but they charge less for their distribution and thus enjoy a lot more installations.
Actually, RedHat (as of 6.0) charges more than SuSE. RedHat's list price for their Official 6.0 box is now $80, compared to SuSE's list price for their Official 6.1 box which is still $50.
The price differential is one of the primary reasons I bought the boxed version of SuSE 6.1 instead of the boxed version of RedHat 6.0.
I will probably want to put RedHat 6.0 on a couple of my boxes which currently have RedHat 5.2 on them, but I think I will just buy the CheapBytes CD (for $2 plus shipping, or about $10 total).
Incidentally, CheapBytes and/or LinuxMall also sell cheap CD-only versions of SuSE 6.1, Mandrake 6.0, Debian 1.3 and 2.1, and Slackware 4.0, Stampede and even FreeBSD, NetBSD and OpenBSD for those so inclined.
hack this device into the world's fastest RC5 block cruncher
:-)
That would be quite a hack, since the chip is designed to do DES...
Yet more evidence that the U.S. Gov't's policy on export control of crypto products is obsolete. Sorry spooks, its already overseas, and its well known enough that students can even put it in hardware. Give up already.
so why is my hard drive littered with CORE files?
Because you don't have your environment set to limit coredumpsize=0 perhaps?
Depends how you use it. Projects I work on are always cross-platform, usually some variant of Unix and NT.
The projects I used to work on when I was subjected to NT were usually cross-platform, although few started out that way. Some started out on *nix, and some on Windows. I did most of the work to make the code portable. I was often working with code that I hadn't written at all.
What we do is create an include file that lists the source files, a makefile for the Unix side, and a makefile.mak for the NT side.
I ended up scrapping M$'s make and using a port of GNU Make for Win32. M$'s make not only seemed to be a cruel joke, it also seemed to be a moving target (changed between versions of MSVC and the automated conversion usually failed). Later on I switched to using Watcom (Powersoft) C/C++ for Windows compiles, as it has significantly better cross-platform compliance (working strcpy(), strcat(), opendir(), readdir(), etc).
The top-level makefile has targets that invoke each of the subdirectory makes. The most likely thing to burn you is that it's natural to use the directory names of the sub-projects as the names of the top-level make targets, and that doesn't work (changing the source files always updates the timestamp of the directory, so M$ nmake doesn't chase down the sub-project build.)
I've seen wacky things like that happen. I am glad I don't have to deal with it anymore.
On NT, create a top-level project using the existing makefile.mak, and sub-projects for the subdirectories. You can select your top-level project to build everything, or individual sub-projects as necessary.
Personally I just use MSVC for debugging -- I do the actual builds using command line windows and the MKS utilities.
That sounds kinda similar to what I ended up doing. You almost have to have something like MKS, albiet even with a lot of add-on utilities, I could never really get an environment under NT I was happy with.
Setting up the whole project under MSVC and then trying to port to cross platform makefiles takes much more time than starting with your own makefiles and wrapping M$ project files around them -- the makefiles generated by MSVC have platform-specific directives and really don't look much like makefiles if you let MSVC manage them directly.
If you use their generated files, they don't seem to be intended to be human readable at all.
I gotta admit -- M$ IDE is far, far ahead of most Linux/Unix tools for debugging.
M$'s IDE is far flashier than most of the free tools, but I am not sold on its overall functionality. More often than not, my experience with the MSVC debugger was that errant code either froze the whole machine, blue screened the machine, or crashed the debugger. In other words, it was worse than useless.
Kind of irritates me that *nix platforms still haven't got such functionality unless you look at the multi-K$ price range,
For work, multi-K$ prices aren't that big an issue. M$'s 'Enterprise' versions of their tools aren't all that cheap either. For my outside work I do at home, M$'s tools are just too expensive. I can't justify spending $3,000+ for NT+MSVC+MKS+ other 3rd party tools versus what I get when I buy a $50 box from SuSE.
and even then only if you've got a truly obscene amount of memory so that the multiple debug and executable processes don't thrash themselves to death.
I use SparcWorks at work, it has a debugger I like a lot better than that in MSVC, and it runs fine on an Ultra 5 with 128M of RAM.
Yeah, yeah -- xdb, dbx, gdb, yada yada -- I've got several years experience with them, and only 2-3 years with MSVC, but it only took 6 months to convince me the M$ debug environment was a much cleaner solution.
I spent a year with MSVC, and it convinced me that I never want to do development on Windows again.
It gets really addictive to be able to step-trace through code as quick as you can hit the function keys, rather than waiting for the 0.5-2.0 second lag with the *nix debuggers,
I've never noticed that kind of lag.
and I have found nothing under *nix that lets me set watch points over memory regions the way I can with MSVC
SparcWorks debugger has a feature like that, I've seen a similar utility on IRIX, but that was quite some time ago.
(nothing else is anywhere near so handy for tracking down that rogue piece of code that's overwriting memory it shouldn't be touching!)
You might look at Purify and Electric Fence.
Big projects? Currently working on one that's well over 500K lines, expected to exceed 1M during the next year. No debug problems on NT or *nix so far, other than the ever increasing memory requirements during debugs -- and the ever decreasing screen space.
Most of the projects I work on these days are smaller (less than 200,000 lines), and I no longer have to do any Windows development, so all is happy for me.
Ever heard of a white-noise generator? You know what white noise does to *any* type of signal. It would be quite easy to jam your computer's interference (and legal too, just keep the amplitude close to your computer's).
Now you are talking about specialized jamming equipment, something that I've said is a possibility, at least it sounds more feasable than relying on masking from generic appliances.
Besides, getting back to the main topic, the police always have other evidence of crimes, beside the encrypted information.
This assumes that the police would be the only people using electronic eavesdropping for surveilance. It can also be an effective tool for such things as industrial espionage, or even just spying on your neighbors, relatives, spouse, etc.
The issue is, why make it any easier for someone who might be spying. That is why shielding is a good idea, and in general doesn't have much of a downside except cost. Cost wouldn't be so high if it was a standard practice thing.
Why? Other people trying to save their own skins will 'rat you out'.
That assumes that there is someone else that knows.
How well can, say, VisualC++ do the above? (I'm really asking, as I haven't used it.)
Very poorly. I was entirely unhappy with Visual C++ for large projects (>100,000 lines of code). It doesn't even do well when, for example a 500,000+ line project is divided into smaller executables which are each in the 3,000 to 50,000 line range (not counting of course common library code).
It is no fun trying to set up Visual C++ to rebuild things, for example when you make changes to a common library function and now have to open up several dozen projects, edit them and rebuild. You really need a good scripting tool to do that, and Visual C++ wasn't designed to play nicely with scripting tools.
For me I'd much rather use a UN*X-like environment for large scale development. Thankfully, I can pretty much pick and choose what I work on, so I am lucky enough not to have to deal with Visual C++ anymore.
And don't even get me started about things that are agregiously broken with Visual C++ like lstrcpy(), lstrcat(), etc...
I downloaded it yesterday and installed it on my laptop today. Looks pretty good, although my laptop is too small and slow to do it justice (486SX-33, 36M RAM). I will be installing it on another box (K6-166, 128M RAM) that should be more suitable.
Visual Age for Java is the preferred Java tool where I work, so this is a pretty nice thing to have. I am going to be attending a week long training class on Visual Age pretty soon and I am going to be starting work on a project that is being developed with Visual Age, so I should get some chance to work on it. If it works well for me I will probably buy the professional edition when it ships.
IBM, if you are listening... I'd also like a Solaris (Sparc) version of Visual Age so I could run it on the SparcStation on my desk at work. If it runs on AIX and Linux, it couldn't be much work to make a Solaris version.
Maybe we've worked with different style cases, but the ones I've used don't have power supply issues.
Probably, there are so many different cases out there. Many of the 'slim' cases I have seen only have 120-175 watt power supplies, which may be adequate for most uses, but may not be the best for sustained heavy duty use. Typical mid tower cases usually have 200-250 watt supplies.
As for floppy drives - simple - don't put one in the box.
The problem there is that it may increase the time necessary to service a machine if it dies.
For bulk serving you don't need it.
Very true under normal circumstances, but my concern is when the proverbial excrement hits the rotary oscillator. I want to be able to fix any problem ASAP. Having to find and install a floppy drive in a machine to bring it back up is time I may not want to take.
Nor a CD ROM drive.
That is normally something that you can usually do without, provided one is available on a network reachable machine.
If the box is at a colocation, you're going to get to it via ssh, not standing in front of it.
Provided you aren't dealing with a crashed hard drive or some other issue that can't be solved remotely.
Another complaint I have about a lot of 'slim' cases I've seen is many of them have limited quantities of front-panel accessable drive bays. While that isn't a big deal for most things, one useful thing when you are dealing with a large number of servers is the inexpensive IDE 'lock and load' trays, which make swapping in and out hard drives much faster and easier. It can make large scale upgrades or dealing with crashed drives a lot faster since you can do the work on another machine and then only take down the server box to do the actual swap.
Personally I hate most 'slim' style cases for a few reasons:
Personally, I like the 'mid tower' type of case. In today's world with huge capacity hard drives, the big full tower cases are often overkill, but the mini-towers are too cramped to work in.
generate too much EM crap (very strong, very random)
operate near soft drink vending machines
The kind of signals emitted from that type of equipment doesn't really fit your criteria, as it is very organized and predictable. It also likely doesn't fall into the same frequency ranges as most of those generated by a laptop (at least not the interesting ones).
While background noise may help some as a jamming source, I'd be suspicious of relying on it as the 'best' way to avoid being eavesdropped on. I have considered the possibilities of active jamming with specialized hardware, however, and that has more potential in my opinion. I don't think I'd consider it a substitute for also doing as much shielding as possible though.
You mention Van Eck eavesdropping: can you point to any online or print sources of information about this?
Check out:
"Electromagnetic Radiation from Video Display Units: An Eavesdropping Risk?" by Wim van Eck, Computers & Security, 1985 Vol. 4.
If you can find it. The NSA made efforts to try to eradicate every copy of this publication, but thankfully were unsuccessful.
Take a look here:
http://jya.com/bits.htm
The little that I do know about it is, frankly, unnerving.
As well it should.
Radio emmisions are on a particular frequency and you are only looking for an "interesting" signal
A very good point, albiet I'd argue that there is often a lot of bleed of signals across from one frequency to another (which in general makes it easier when it comes to eavesdropping, not harder). I've seen a lot of equipment where signals were repeated at various harmonic intervals so that any one signal source was basically polluting a large part of the radio spectrum. The advent of cheap and powerful digital signal processing really worries me when it comes to Van Eck style eavesdropping, because it could be used to very easily isolate those "interesting" signals.
Now I hate to defend Microsoft, but they did have one (1) original idea: BASIC.
Not hardly. BASIC existed way before Microsoft (it was developed as a learning tool for Fortran). Microsoft wasn't even the first implementation, it was available on other systems before Microsoft did Altair BASIC in 1975, for example the DEC and HP minicomputers. In fact, Altair BASIC wasn't even the first BASIC dialect for microcomputers, just the first reasonably full featured one that became commercially successful. When Bill Gates was a student at Harvard, he worked as an intern at one of DEC's research labs, working on, surprise-surprise, DEC's BASIC interpreter for the PDP-11. Not surprisingly, Altair BASIC looked very similar to DEC's BASIC.
I'll just list the things that will interfere with the RF leakage:
While all of that is true to a certain extent, as someone who has seen 'Van Eck' type equipment in operation, I can tell you that you shouldn't be so quick to dismiss the interception of RF leakage as an eavesdropping risk. The basic 'Van Eck' type equipment can be further refined with highly directional antennas, amplification and filtering hardware to increase its ability to discriminately intercept data. It would be probably be safe to assume that the feds have already done this.
Maybe we ought to ban these too or require a TEMPEST compatible transmitter in all non-picture-tube monitors
That might be true if the CRT was the only RF leaker in the typical computer system. The previous poster mentioned eavesdropping on the keystrokes containing the password. Since no reasonable encryption system echoes such keystrokes to the display, I would tend to assume they were talking about eavesdropping on the keyboard itself or something inside the computer directly attached to it. While there are probably less emissions from a device such as a keyboard than from a CRT, there are likely to still be measurable enough amounts that sophisticated and sensitive enough equipment could intercept it. The feds have plenty of money to buy/build such equipment.
something like 25% of them is owned by Microsoft.
Actually I believe that it is around 14%, with Doug Michels and his father each owning somewhere between 10-14%, and all of the rest of the outstanding shares held by people with much smaller percentage interests.
While none of the shares would give a level of absolute control, given an agreement amongst those three shareholders, it would only take a small percentage of the rest to vote with them for them to have their way.
What would your linux system look like if you deleted all beta SW?
Beta means something different in the Linux world than it does for Microsoft. Microsoft releases a lot of things as finished versions that would be considered in the Linux world to be beta (or you could reverse that and say that a lot of things that are released in the Linux world as Beta would be released by Microsoft as a final version). Stuff that Microsoft labels as betas are often of a quality similar to stuff released on Linux as Alpha or pre-Alpha.
I can see why Compaq went with RH for their Alpha CPUs.
:-)
Someone else has mentioned that Compaq has a small investment in Red Hat, so that might have something to do with it. Compaq might also have a side agreement with Red Hat exchanging Red Hat's continued support for Alpha for Compaq promoting Red Hat's distribution on their x86 boxes as well.
But why does Dell and the others?
That is probably a better question, since they may not have quite as many obvious reasons.
Not to start a flame war, but it sure would be nice to have the option of Caldera or RedHat.
It would be nice I suppose, but you still have the choice to install Caldera over the top of Red Hat if you want. The fact that Compaq will be doing the homework to make sure the components they put in their machines are Linux friendly will still be a big advantage even for those who choose a different distribution.
Yes RedHat has the name recognition, but no wonder with all these announcements. If these announcements included Caldera or another distribution I would bet they would have just as much 'name' as RedHat.
Maybe, maybe not. Red Hat seems to actively court more media attention, and advertise more widely than Caldera. Red Hat may be more actively seeking out this sort of relationship with companies like Compaq and Dell than Caldera, we really don't know what is going on behind the doors here. A lot of name recognition has to do with how good a company is at promoting themselves, and Red Hat has done a pretty good (albiet not perfect) job there.
I like choice, do you?
Sure, which is why I run Red Hat on some of my machines, SuSE on others, and even have a machine running Caldera (albiet an old version) and one running Slackware. However, I am not a typical Compaq customer. Unfortunately, a lot of the PHB types are actually afraid of choice. For them picking Linux is already a big decision, and having to pick between distributions might just tax their wee brains too much.
Frankly, just having a choice other than Windows is enough of a step in the right direction I have trouble complaining too much about Compaq.