You have to be a big customer to get any clout!
on
Bob Metcalfe On NPR
·
· Score: 2
I hope you know you have to be a big customer to get any clout. Otherwise, your complaints don't mean squat.
And it is getting to the point that some Microsoft licensees are finding out that they have to screw with the source themselves, Microsoft doesn't care about anything that doesn't affect at least 1 million people anymore -- seriously! And getting access to the source code of Windows is a tricky game. It's costly, and Microsoft could still withhold it from you at any time (e.g., Bristol Technology).
So, unless you are a Fortune 500 company, I really don't see the "somebody to sue" factor even being remotely applicable. The result is what we see in Internet servers... big business chooses Microsoft, smaller businesses choose Open Source.
And it even goes deeper than that! 90% of those big businesses don't run their business on the Internet (and the ones that do choose UNIX/OSS), nor do they entrust Microsoft for most of their back-ends. It's still tried and true big iron and/or UNIX -- which is more of a testament to UNIX, and not so much Open Source (but wasn't UNIX developed akin?).
Because of my bringing it to the attention of a few people, it was even mentioned in several print publications.
Fuck you very much./. You've rejected all kinds of goodies from me including:
2000-06-13 15:46:44 Dell Linux PC systems are locked at 128MB of RAM??? (articles,linux) (rejected)
2000-08-13 06:25:59 Microsoft addresses Gartner's concerns over OEM licensing (articles,microsoft) (rejected)
2000-08-24 18:17:29 "Windows 2000: A Threat to Internet Diversity" says IEEE (articles,news) (rejected)
2000-08-29 15:19:18 Latest Electronic Design intros new embedded Linux toolkits (articles,news) (rejected)
And my submissions to other posts have usually been moderated up between 3-5 on almost every post I make. Karma in just the last 2 months has me at an automatic +2 now and I cannot even get one fucking article posted!
Aw man, you had to mention the Central Point shell. Boy did I hate the world when Windows 3.1 died and I couldn't run that anymore.
Luckily for us, Gnome/E became stable about 12 months ago and I've been hooked since. Sure there are "similiar" offers for Windows, but not one that works so intelligently like Central Point's did.
Now if Eazel could get a good file manager out for Gnome... I'd be in heaven!
Guys, I'm trying to explain why nothing in the Microsoft world will ever be like UNIX. Minimal reboots, multiuser aware, network aware, more secure, etc... In a nutshell, the answer to your question is in fantasy land.
Geez! I understand the underlying Windows 9x and NT/2000 design than probably most who posted here. Stuff like what you want for Windows will never, ever happen! Microsoft makes GUIs, not OSes. Windows 9x is not an modern OS implementation, it's a modern application. Don't expect it to act like an OS.
To Microsoft, reboots are something that the consumer can do easily. They would rather you reboot than try to explain how to dynamically load drivers! It's that simple. Microsoft wants dumb users.
I can tell you little of what Microsoft does has any technical reasoning. In fact, if irresponsible marketing that really doesn't make a difference (e.g., no 'emergency' CLI mode like OS/2) conflicts with technical reasoning of the utmost concern, that marketing, no matter how flawed, still wins. Everything from drive letters, to symbolic links to many other ideas were dropped for 'marketing' considerations. [ And we all know how "customizable" NT is -- e.g., ever try using the POSIX subsystem in NT to implement symlinks like someone did in the NT Resource Kit? Pow! Corrupted filesystem! ]
Coming from OS/2, NT was a _real_ disappointment. I got involved in NT because the first native app for NT was Integraph/Bentley Microstation (a traditionally UNIX CAD program, with them trying to cut into AutoDesk AutoCAD PC share via NT). Boy did they make a mistake by going with NT. From lack of dual-monitor support (after request after request) to various, almost anti-CAD decisions, it makes you wonder if Microsoft really cares about the people that use their system (I mean, the only people that did NT for awhile were Integraph users!).
And it got worse. Not even Microsoft's own application group was supporting NT -- heck, that still exists today. Every freak'n ignorant ISV (independent software vendor) to Microsoft themselves totally ignores NT when it comes to designing their applications. As such, we have a wealth of NT ignorant applications resulting in users having to run with full administrator privaledges which, of course, defeat security, yada yada yada.
The only vendor I have ever seen support NT 100% in their installer as well as their apps operation is Digital. Makes you wonder just who wrote Windows NT??? NT = "Not our Technology". And now Digital is all but gone, Compaq does not seem to be holding much of a candle to their old software development attitude.
In 1993, I discovered Linux. In 1994, Gates chose to support "Chicago" (aka MS-DOS 7.x with the GUI atop we now know as Windows 9x), that killed any chance of NT becoming a good product. It had the potential to be one, but hey, it's Microsoft we're talking about here! And they were able to dupe companies like Integraph, Bentley, Micrografx and a host of other companies we can talk about sometime.;-> Yes, by 1995, I saw Linux was the future!
System administrators have had it with multiuser and network ignorant OSes from Microsoft. I'm one of them. TOC (total cost of ownership) of Microsoft products is a freak'n nightmare. I'm seeing this first hand as I roll out a new batch of dual-booting NT/Linux systems. Thank God my servers are 100% Linux/Solaris at my current job (so it's just the desktop TCO nightmare for now, until Linux takes over;-).
-- Bryan "TheBS" Smith
Re:3Ware's ATA-RAID controllers do just that!
on
IDE Co-Processors?
·
· Score: 2
Er, that should read "dedicated CPU drives your disks" not "dedicated CPU drives your CPU." [ DOOH! ]
Also wanted to point out that with any striping, mirroring, parity, you are "bothering" your CPU with BIOS or software RAID solutions (and the Promise solution *IS* a "BIOS" RAID solution). The 3Ware controller will off-load these routines onto it's own co-processor.
-- Bryan "TheBS" Smith
3Ware's ATA-RAID controllers do just that!
on
IDE Co-Processors?
·
· Score: 3
Forget Promise, SIIG and others. 3Ware's Escalade series of products are just what you are looking for. Keys to performance with Escalade:
On-board co-processor that acts like a SCSI target from the standpoint of the OS/driver. The same you'll find on most SCSI RAID controllers (i960 or similiar). This dedicated CPU drives your CPU, not your mainboard chipset's southbridge (which normally requires some CPU overhead even with bus mastering).
One IDE drive per-channel. No "slave" issues. 100% Hot-Swap capability (although you'll need a IDE hot-swap bay/chassis for full hot-swap capability). Maximum performance.
2-8 channel boards, roughly $50-60/channel -- not much more than those crappy Promise FastTrak cards, only much, much faster.
100% Linux support. 3Ware controller support is built-in to most newer 2.2.x kernels.
If you want to minimize cost and performance, 3Ware's Escalade is what you want. Their new 6000-series offers 2-8 channels of RAID-0/1/1+0 with Ultra66 support for $139/279/479 (2/4/8 channel).
3Ware is also working on a 64-bit PCI board with RAID-5 support (as well as Ultra100). Be looking out for it (I know I will).
A better comparison is QNX to Cygnus eCos, the Linux-preemptive RT/Linux kernel/system, WindRiver's VxWorks, etc... It is really unfair (for both sides) to compare a "lightweight" OS for small, embedded systems against a be-all/do-all behemoth like Linux (which does have a minimum size limitation).
I'm sure you'll be able to find some overlap, but it's really a question of "which is better for this application" and not "which is better period".
First off, I was trying to make a point that we should not be looking into 100% electric vehicles until both the technology and infrastructure exist! I am NOT saying we should not be looking into them period, just that people should get off the ignorance game.
Secondly, I stand by my "5 times" statement on electric power that is generated by fossil fuel power plants for 100% electric vehicles. Until the majority of America's power either comes from non-fossil fuel sources, or the vehicles themselves are not just stored electric vehicles (i.e. fuel cells instead of batteries), it holds true! It's one of those "trees make smog" type of deals that people like to play "politically correct" on where the base problem is humanity and you can't do anything to stop (besides getting rid of humanity;-).
100% electric is a pipe dream until we can come up with an infructure that at least:
Produces enough for the masses
Is so cost-effective and efficient, it can replace all localized (i.e. non-power plant) fossil fuel use.
Some of it will come from the "'PC' Renewable Energies", but figure less than 25% total, period. I guess it is my bias, but I believe fusion power plants are the best chance and could be a reality in 25-50 years *IF* proper funding is re-implanted into the various research programs. It is too bad the world has been turned off of nuclear fusion, largely from the irresponsibility of various members of our science community (on both sides of the cold fusion argument -- never seen so many closed minds on both sides). While cold fusion may or may not be a reality -- in fact, I think it will not be, at least in my lifetime -- but I think traditional, high-temperature nuclear fusion *IS*!
For now, hybrid (petroleum and electrical return) and, soon, alternate fossil (CNG) and electric (hydrogen) fuels and fuel cells are our best chance. I sick of people blindly stating electric cars and zero emissions without knowing jack!
As far as solar, it's a mixed bag. Solar is expensive, period, and does not produce much. Some new solar technology is on the horizon, but it is rediculously expensive and the actual results are not concrete yet. It holds promise, but don't invent a reality that does not exist yet, let alone we don't know if it will be cost-effective (time will tell).
Wind is looking better and better. I have no problem with eyesores and someone brought up that point (I cannot believe people would argue against them because they are eyesores!). But that's an infrastructure that is a whole new bag.
Water is not an option to power the entire nation. There just aren't enough rivers and damns that can be built to power even 1/10th of the US. It is also questionable how long it takes to get a return on the initial investment which is extremely large in the case of hydropower.
Again, I'm just an engineer. That means I'm a scientist and a businessman. I'm not going to say things that are PC, just reality today. I hope for the best in the future but clinging to alternate realities or lying to yourself as you see fit are NOT 2 ways to get there!
I am personally getting sick of people who say "we should all move to electrical vehicles." The main problem is the the answer to, 'where does the electricity they use come from?' And the answer surely does not come out of thin air like many "wantabe" environmentalists think it does!
Electric cars use upto 5 times as much fossil fuels than ICE (internal combustion engine) vehicles.
How and why? First off, the electricity is produced at a power plant, of which, the nation still relies on 70-80% of fossil fuels to generate. Secondly, the efficiency of first generating the electricity from fossil fuels to drive a motor by electricity, rather than via an ICE is much, much lower. And, finally, there is a lot of transmission loss between the power plant, relay stations to your home (the most likely location where you will charge your vehicle). And there is the fact that the current power generation infrastructure could not meet the power generation needs to support home charging of electrical cars if 1/4th of America was driven them. In addition, I think most Americans would take exception to a $400-500 "electrical bill" even if they did not have to fuel their vehicles elsewhere.
In addition, because the elctricity is still generated from fossil fuels 70-80% of the time, the belief that it is "zero emissions" is just untrue. Now on the flip-side I will admit that power generation from fossil fuels at a power plant is less of a polutant than generation from fossil fuels in an ICE -- probably by an order of magnitude. So even if it takes 5 times as much gas to power the electric vehicle and, therefore 5 times as much fossil fuels are used, the total number of pollutants are probably cut in half. I.e. 5 (times as much fuel) x 1/10 (the pollution per unit fuel) = 1/2 (the total pollution).
So, at best, the "zero emissions electric vehicle" is a flight of fantasy, at least until we either develop direct heat to electricity generation (by passing the traditional steam turbine/generator system of today), possibly in combination with commodity fusion power generation (until which, we will be dependent on fossil fuels).
And if you are even thinking of solar power, don't bother. Solar cells would have to be 25 times as efficient as they exist now. Putting solar panels atop of your hood, top and trunk would not even yield enough power to go a few miles after several hours of charge. Wind power is in the same boat, although it it is more efficent than solar.
The reality of reduced fossil fuel dependence comes not from its total elimination. No. The best solutions come in "hybrid" electric vehicles where an ICE is used in combination with electric systems. Everything from alternators to flywheels are used to generate and charge the batteries while the ICE is running. Hybrid vehicles can almost double the MPG (miles per gallon) rating of vehicles over their ICE-only components.
Looking beyond just they ICE-electric hybrid, we can look at one petroleum replacement, and another one electrical source (other than direct battery storage and recharge). CNG (compressed natural gas) is one since it burns much cleaner than petroleum, and is in limited used in largely application-specific commercial vehicles (like various commercial utility trucks, etc...). Hydrogen fuel cells are a promising technology that will make electric cars much more efficient than charged and discharged batteries. But, both CNG and fuel cells have serious safety issues in their on-board storage in that massive explosions can result in rupture of their tanks (much larger than possible with petroleum-based ones because of the pressure and density of CNG, and the volitity of hydrogen in fuel cells).
Lastly, some may remember "gasohol", an ICE fuel replacement for petroleum. Gasohol is a reality, and can be used to power ICE. In fact, the US' total agriculture capability could meet the world's total demand for gasahol at least two times over if petroleum did not exist tomorrow. The reason it does not today is because of the cost of its refining into an end-user product. Not so much in the refining process itself, but in the massive and quite useless by-products and waste as a result of the refining process. As such, until petroleum resources start to dry up and drive costs of a crude barrel at least 5 times more than the cost today, gasohol will remain a relatively untapped technology.
I seriously hope I educated some individuals here. I don't work the petroleum industry nor do I defend them -- I'm actually quite critical, especially in light of the little effort by everyone in the US to push for the development and maturity of economical fusion power generation (which I believe is possible). I'm just an engineer who is sick of reading various comments on "electrical cars" or "renewable energies/fuels." Let's talk reality people or not talk at all!
Windows 2000 is designed to market a Windows server-dependency. The IEEE Computer Society's latest August 2000 (Vol. 33, No. 8) Computer magazine featured an article called Windows 2000: A Threat to Internet Diversity and Open Standards? (PDF available to members here).
A such, you need to adopt a Windows server-free network. This includes holding off on Windows 2000 until either Samba supports its interfaces (will take some reverse engineering) or someone finds a way to have it use NIS/NIS+ for authentication -- e.g., NISGINA does for NT 4.0. At my company, Theseus Logic, we use NISGINA instead of Samba TNG (just use regular Samba 2.0.7) to deal with authentication of NT 4.0 systems.
Just run rpm -Fhv *.rpm in your newer distro's RPM directory (e.g.,/mnt/cdrom/RedHat/RPMS) and it will only upgrade those componenets that are install.
Heck, sometimes you don't even need to reboot! (although expect a few library issues until you do)
It's just a little box like the Linksys one, but so much more protective and flexible! If you're gonna spend $150-200 for a POS, why not spend $350-400 for a real firewalling solution?
Dude! Linksys should be SMACKED for calling that POS a "firewall". Linux IPChains is MUCH, MUCH better! At least it has some REAL logging!
For $350, you can get the SonicWall SOHO/10. It is the only ICSA approved firewall you can find for under $500. It has excellent features, including one-to-one NAT (so you can let in certain ports), and logging is fairly good (nothing to complain about at that price). I've used these little babies on corporate networks.
Microprocessor Design was quoted as saying that MHz for MHz, the Pentium IV will lose badly to the Athlon, especially when AMD matches Intel's 0.13um feature sizes. Why?
The Pentium IV is still the aged-old Pentium Pro core. Intel keeps pushing back the release of a new core design, simply slapping on instructions or widening the path internal datapaths, but doing nothing about the inefficiencies nor the stalling 10-12 stage pipelines in their design.
"Williamette" was supposed to change that and bring 17-20 stage pipelines that are much more scalable, like the Athlon's 18 stage design. Unforunately Intel is having design issues with the Williamette and holding off on Williamette's completion means Intel can get to market faster. Hence, this is what they have been doing to keep up with AMD.
Without "Willamette", AMD will still continue to beat Intel MHz for MHz on even Pentium optimized code with a reverse engineered AGP spec. Kinda makes you wonder if the odds were even if AMD wouldn't dominate Intel?
Now image that "Pentium optimized" FPU code still runs slower on a Pentium IV 1.4GHz than a 1.1GHz Thunderbird. Would I continue to make my code and compilers "Pentium optimized"? Imagine a world where code and compilers came "Athlon optimized"? I think you'd see the Athlon really slam Pentium.
95% of applications can be served by the monolithic design
Linux is built on a KISS principle -- microkernel conflicts with that
As Linus has shown, microkernels can have their own weaknesses and performance issues (and this argument dates back to 1992!)
Re-inventing the wheel -- other things are more important
Issues, issues, issues -- new design, new drivers, etc...
If it ain't broke, don't fix it, and...
Very imporant, you can run a microkernel OS underneath a monolithic one!
This is where RT/Linux, and other Linux pre-emptive microkernels come in. Advantages:
It addresses hard real-time
No re-inventing the wheel, you only implement what you need in real-time in the microkernel (e.g., drivers, etc...)
You still have full-blown Linux, which runs as a non-RT task in the microkernel
You can address, change and do all the little things you need, without having to address the whole kernel and compatibility with modules you could care less about.
You get the best of both worlds. Minimal redesign, maximum reuse. The whole microkernel argument is old, very old. Linus has gotten Linux to the best it can be as far as soft real-time can be in 2.4. RT/Linux is the microkernel that addresses hard real-time and other size and response time issues. And it is a microkernel, running the main Linux kernel as a regular process. A perfect solution.
In a nutshell, it's impossible to get Linux to do everything without major modifications. There will have to be non-direct kernel implementations to do those unique applications. I really don't see any other way to do it. And besides, I don't see QNX, VxWorks, nor any other RTOS being as flexible as Linux is at doing many other things.
Mainboard BIOS RAID (same thing as the crappy Promise cards)
Or more than 2 ATA drives in Software RAID if you need your CPU at all (too much CPU utilization).
Additionally, what you need to consider:
PCI Throughput -- try putting your controller on its own PCI channel and go for 66MHz (or PCI64, but you'll need Linux 2.4 for 64-bit PCI) -- you'll need a more costly mainboard to do this, ones based on the ServerWorks (fka RCC) ServerSet chipsets come highly recommended. Otherwise, you'll easily saturate a traditional mainboard with a single PCI bus with a I/O rate that high.
SCSI since you're going to need more than 2 stripped drives -- try ~8 Ultra160 drives stripped over 2-4 channels on a 66MHz PCI64 card. The new Mylex eXtremeRAID 2000 is such a 4-channel Ultra160 board with a powerful StrongARM 233MHz at the core (compared to whimpy i960 66-100MHz co-processors on other SCSI RAID controllers).
If cost is a factor, look into a "Real" co-processing ATA RAID controller that acts like a SCSI disk/target like those from 3Ware (which has full Linux support). 3Ware's new 6000-series has Ultra66 support and claims >100MBps read speeds and upto 84MBps write speeds (I'm sure that's the 8-channel board with 8 disks stripped;-).
My company refuses to drop the "Microsoft Virus Distribution System" (aka Outlook). After applying the security patch (that disables a crapload of its insecure features), we ran into various issues. Basically, I think the whole security patches for Outlook were specifically designed to force you to buy Exchange. Instead, we opted for HP OpenMail. It's free for upto 50 users and has a 6 month trial (unlimited users).
It solved our shared Calendar and Contacts issues with its MAPI interface. Of course, none of these features of Outlook, even though they are stored on the server, are compatible with its included, native clients. We're still waiting for something better, but for free, it was a perfect fit (as my "cry baby" ignorant Office users complained after I installed the much needed Outlook fix when it came out). Hopefully the iCalendar and vCard standards in clients like Evolution will push Microsoft (among others) to support them (hopefully).
I mean, E-mail shouldn't be this hard and Sendmail (once setup) has been running for us solid for 12 months non-stop. OpenMail is great because it uses Sendmail (or any other MTA) underneath so you're not at it's mercy. Although you can have all our company's mail get redirected to OpenMail (e.g., as a Sendmail rule), setting up a subdomain or other MX record keeps its crap separate (I don't like Outlook crap going around on my network any more than I have to).
Anything to keep ignorant users (only about 20% of my company are these admin users, the rest are UNIX-using engineers) from screaming for Exchange is helpful. OpenMail is your ticket to keeping your servers Microsoft-free -- like ours where 90% of our work is UNIX-based and Samba handles the rest nicely. It is incredibly stable (even though the MAPI client for Outlook is only version 0.5 "preview release") and our server has been running for months now. Everytime I've dealt with an Exchange server, I expect no more than 60 days before a major corruption that keeps me busy for 48 hours straight. Not with OpenMail, it's rock-solid and has even survived someone twice accidently (and quite incorrectly) powering-off the Linux box where it is hosted.
It also doesn't take a lot of resources to run. Figure about 1-2MB max per client. For ~50 clients, a Pentium with 128MB of RAM will do nicely. We use a Pentium II 400MHz with 384MB and this system also seconds as a secondary NFS/SMB server (to Solaris clients and NT workstations) and Intranet (informational) server. Gotta love Linux baby!
I believe a set of kernel 2.2.16-1 RPMs appeared on RedHat Rawhide within days. It wasn't until 2 weeks later when the 2.2.16-3 kernel set was tested before RedHat officially announced the RPMs with the press release.
Note to reviewer: At least we have the option of running untested stuff at our own risk from various distro test labs and sites. You don't have that option with "Muppet Labs".;->
Again, I think people are making this out to be too much of an OS issue. It's not. The fact of the matter is that many space vehicles don't have an OS and the use of a RTOS for multitasking has only been around for 3 years (forget even using a general purpose SO). So, again, it's a development tool issue and GNU is here and Windows is no where.
Space vehicles have a two fold requirement:
Ultra-low power
Ultra-low response times
These are the extremes of the extremes. Although Linux can get sub-ms response times, you need a fast processor to get there (as with any general OS). Since low power is an even greater consideration, you're not going to get that speed. As such, you'll need to use a small, RTOS to get those response times on slower processors. [ I hope everyone here knows Microsoft is quite out of their mind when they say Windows CE is a RTOS -- it is NOT! ]
Where Linux comes into the space program (other than the engineering workstation/development systems themselves) is in the support systems. Several examples:
Telemetry support systems -- a heavily SGI-driven market of "soft" real-time UNIX systems. As we all know, SGI is going Linux so this is a development focus for them.
CIL/HWIL systems -- Computer-in-the-loop, hardware-in-the-loop is a very important set of pre-flight verification simulations. Again, SGI has quite a market here.
CFD computing clusters -- Linux clusters are 10x the bang for the buck versus shared memory systems for Computational Fluid Dynamics (CFD). CFD is a design-time simulation tool and it scales extremely very linerly over a cluster of systems (i.e. it is idea of clusters) because it is 98% computation, 2% data traffic (before/after simulation).
This JPL mission really set the "standard" on what COTS hardware and software could do. It is the main reason why VxWorks was so widely adopted by the rest of the Aerospace industry.
[ Note: I was a Software Engineer at Coleman Aerospace for 3 years ]
Many of the early computers in ballistic missiles and space probes borrowed heavily from the military. Much of the gyros and computing systems were produced by Bendix for the Department of Energy (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant). In case you aren't familiar with how the government works, the DoE was and still is the non-military, government agency tasked with the creation of numerous components of our nuclear arms technology (as well as their normal energy details, a natural tandem role). Looking at their "most advanced computer" in the early 1980s (the Bendix 930 in the Pershing II MRBM), you essentially had a 16-bit CPU and database with 64KB of memory on various cards in a wire-wrapped backplane. And, yes, all the target code for these machines are done in assembler.
Today, both the military and NASA contractors "better, faster, cheaper" attitude of using off-the-shelf hardware, tools and software revolves mainly around the VME architecture (usually for 68300 and, increasingly, PowerPC boards -- military spec/hardening) with WindRiver's VxWorks RTOS. VxWorks is heavily BSD 4.3-based OS with response times in the tens of microseconds (on a 40-50MHz processor). Development is done using GNU development tools using a customized Cygnus GNUPro (now under RedHat's services group) product called Tornado (customized for WindRiver by Cygnus) so it can target various VxWorks architectures with Linux, Solaris and Windows being the most popular host development platforms. [ I personally found Windows to be a real pain if you also install Visual Studio on the same system because which tries to take over your system -- have to be careful you run the right make, etc... binary ].
A well-known 68K/VxWorks-based mission was the Mars Pathfinder. Today, the combo is used in a wide variety of launch and space vehicles. At my former employer, we used it for our ballistic target and booster vehicles for the military and LEO (low earth orbit) launch vehicles for NASA (and they continue to do so). A future mission to the outer planets will be PPC/VxWorks-based, all written with the GNU development system. [ Since Linux nor most other general-purpose OSes cannot guarantee such "hard" real-time response times (let alone no Windows platform can seem to deliver even deliver any "soft" real-times either), it is my hope that Cygnus' (now RedHat's) eCos takes off and cuts into VxWorks' market in the next 5 years). ]
Which brings me to my final point: I think people get caught up with the whole this OS versus that OS issue when the argument should be GNU development versus Microsoft Visual development for "mission critical" purposes. The GNU cross-compilers and tools allow you to target dozens of platforms and massive code reuse whereas Microsoft changes its Visual Studio products on a whim. I mean, it's really harder to port Windows code just for a version change than it is to port to another, completely different architecture with GNU. I personally don't see why Windows developers put up with it because Cygnus makes some damn good IDE and tools for development.
Personally, I think the best remedy for the whole DOJ v. Microsoft trial would be to force Microsoft to support GNU-based development tools for the Windows platform (both target and host) -- and set a time-frame in which they would have to drop their current, non-GNU-based Visual product (e.g., 5 years). This would do several things: actually force the documentation of the API, thus increase overall stability of the Windows platform, finally address multi-user ignorance as the main problem with Windows security (98% of even Microsoft's own applications are multi-user ignorant!), and many, many other benefits to the developers as well as the consumer. Of course no one in the trial has the forsight to see this as the best remedy, and I seriously doubt we will see any discussion of it either.
First off, only 5-10 miles big is too small to always be spherical. I believe it is somewhere between 100-200 miles (160-320 km) in diameter before gravitational forces are strong enough to force a spherical shape -- assuming the mean density of most asteroids/planets which can, of course, vary greatly. Please correct me if I am wrong.
So what is the criteria for an orbiting object to be termed a "natural satellite" then? I assume it is:
A stable, perpetual orbit (which eliminates 99.999% of the rocks out there)
A certain set of characteristics other than size about the object itself -- e.g., magnetic field? attitude and orientation? ???
I'm a big proponet of putting peltzer or other thermal control logic on high power ICs (such as general-purpose CPUs) to control these cooling devices. The main problem is condensation and if you put the CPU in control of its own cooling, that would eliminate 98% of it's issues.
Otherwise, I found the units for enclosures to be a little too expensive for consideration ($500+!). While it would be neat to run my box with a consistent 60-65 degrees F (you should always run about 55 degrees F for condensation purposes), I don't think it is worth it for $500.
Slashdot Mirror
I hope you know you have to be a big customer to get any clout. Otherwise, your complaints don't mean squat.
And it is getting to the point that some Microsoft licensees are finding out that they have to screw with the source themselves, Microsoft doesn't care about anything that doesn't affect at least 1 million people anymore -- seriously! And getting access to the source code of Windows is a tricky game. It's costly, and Microsoft could still withhold it from you at any time (e.g., Bristol Technology).
So, unless you are a Fortune 500 company, I really don't see the "somebody to sue" factor even being remotely applicable. The result is what we see in Internet servers ... big business chooses Microsoft, smaller businesses choose Open Source.
And it even goes deeper than that! 90% of those big businesses don't run their business on the Internet (and the ones that do choose UNIX/OSS), nor do they entrust Microsoft for most of their back-ends. It's still tried and true big iron and/or UNIX -- which is more of a testament to UNIX, and not so much Open Source (but wasn't UNIX developed akin?).
-- Bryan "TheBS" Smith
Because of my bringing it to the attention of a few people, it was even mentioned in several print publications.
Fuck you very much ./. You've rejected all kinds of goodies from me including:
And my submissions to other posts have usually been moderated up between 3-5 on almost every post I make. Karma in just the last 2 months has me at an automatic +2 now and I cannot even get one fucking article posted!
-- Bryan "TheBS" Smith
Aw man, you had to mention the Central Point shell. Boy did I hate the world when Windows 3.1 died and I couldn't run that anymore.
Luckily for us, Gnome/E became stable about 12 months ago and I've been hooked since. Sure there are "similiar" offers for Windows, but not one that works so intelligently like Central Point's did.
Now if Eazel could get a good file manager out for Gnome ... I'd be in heaven!
-- Bryan "TheBS" Smith
What the hell? Off-topic?
Guys, I'm trying to explain why nothing in the Microsoft world will ever be like UNIX. Minimal reboots, multiuser aware, network aware, more secure, etc... In a nutshell, the answer to your question is in fantasy land.
Geez! I understand the underlying Windows 9x and NT/2000 design than probably most who posted here. Stuff like what you want for Windows will never, ever happen! Microsoft makes GUIs, not OSes. Windows 9x is not an modern OS implementation, it's a modern application. Don't expect it to act like an OS.
To Microsoft, reboots are something that the consumer can do easily. They would rather you reboot than try to explain how to dynamically load drivers! It's that simple. Microsoft wants dumb users.
-- Bryan "TheBS" Smith
I can tell you little of what Microsoft does has any technical reasoning. In fact, if irresponsible marketing that really doesn't make a difference (e.g., no 'emergency' CLI mode like OS/2) conflicts with technical reasoning of the utmost concern, that marketing, no matter how flawed, still wins. Everything from drive letters, to symbolic links to many other ideas were dropped for 'marketing' considerations.
[ And we all know how "customizable" NT is -- e.g., ever try using the POSIX subsystem in NT to implement symlinks like someone did in the NT Resource Kit? Pow! Corrupted filesystem! ]
Coming from OS/2, NT was a _real_ disappointment. I got involved in NT because the first native app for NT was Integraph/Bentley Microstation (a traditionally UNIX CAD program, with them trying to cut into AutoDesk AutoCAD PC share via NT). Boy did they make a mistake by going with NT. From lack of dual-monitor support (after request after request) to various, almost anti-CAD decisions, it makes you wonder if Microsoft really cares about the people that use their system (I mean, the only people that did NT for awhile were Integraph users!).
And it got worse. Not even Microsoft's own application group was supporting NT -- heck, that still exists today. Every freak'n ignorant ISV (independent software vendor) to Microsoft themselves totally ignores NT when it comes to designing their applications. As such, we have a wealth of NT ignorant applications resulting in users having to run with full administrator privaledges which, of course, defeat security, yada yada yada.
The only vendor I have ever seen support NT 100% in their installer as well as their apps operation is Digital. Makes you wonder just who wrote Windows NT??? NT = "Not our Technology". And now Digital is all but gone, Compaq does not seem to be holding much of a candle to their old software development attitude.
In 1993, I discovered Linux. In 1994, Gates chose to support "Chicago" (aka MS-DOS 7.x with the GUI atop we now know as Windows 9x), that killed any chance of NT becoming a good product. It had the potential to be one, but hey, it's Microsoft we're talking about here! And they were able to dupe companies like Integraph, Bentley, Micrografx and a host of other companies we can talk about sometime. ;-> Yes, by 1995, I saw Linux was the future!
System administrators have had it with multiuser and network ignorant OSes from Microsoft. I'm one of them. TOC (total cost of ownership) of Microsoft products is a freak'n nightmare. I'm seeing this first hand as I roll out a new batch of dual-booting NT/Linux systems. Thank God my servers are 100% Linux/Solaris at my current job (so it's just the desktop TCO nightmare for now, until Linux takes over ;-).
-- Bryan "TheBS" Smith
Er, that should read "dedicated CPU drives your disks" not "dedicated CPU drives your CPU." [ DOOH! ]
Also wanted to point out that with any striping, mirroring, parity, you are "bothering" your CPU with BIOS or software RAID solutions (and the Promise solution *IS* a "BIOS" RAID solution). The 3Ware controller will off-load these routines onto it's own co-processor.
-- Bryan "TheBS" Smith
Forget Promise, SIIG and others. 3Ware's Escalade series of products are just what you are looking for. Keys to performance with Escalade:
If you want to minimize cost and performance, 3Ware's Escalade is what you want. Their new 6000-series offers 2-8 channels of RAID-0/1/1+0 with Ultra66 support for $139/279/479 (2/4/8 channel).
3Ware is also working on a 64-bit PCI board with RAID-5 support (as well as Ultra100). Be looking out for it (I know I will).
-- Bryan "TheBS" Smith
A better comparison is QNX to Cygnus eCos, the Linux-preemptive RT/Linux kernel/system, WindRiver's VxWorks, etc... It is really unfair (for both sides) to compare a "lightweight" OS for small, embedded systems against a be-all/do-all behemoth like Linux (which does have a minimum size limitation).
I'm sure you'll be able to find some overlap, but it's really a question of "which is better for this application" and not "which is better period".
-- Bryan "TheBS" Smith
First off, I was trying to make a point that we should not be looking into 100% electric vehicles until both the technology and infrastructure exist! I am NOT saying we should not be looking into them period, just that people should get off the ignorance game.
Secondly, I stand by my "5 times" statement on electric power that is generated by fossil fuel power plants for 100% electric vehicles. Until the majority of America's power either comes from non-fossil fuel sources, or the vehicles themselves are not just stored electric vehicles (i.e. fuel cells instead of batteries), it holds true! It's one of those "trees make smog" type of deals that people like to play "politically correct" on where the base problem is humanity and you can't do anything to stop (besides getting rid of humanity ;-).
100% electric is a pipe dream until we can come up with an infructure that at least:
Some of it will come from the "'PC' Renewable Energies", but figure less than 25% total, period. I guess it is my bias, but I believe fusion power plants are the best chance and could be a reality in 25-50 years *IF* proper funding is re-implanted into the various research programs. It is too bad the world has been turned off of nuclear fusion, largely from the irresponsibility of various members of our science community (on both sides of the cold fusion argument -- never seen so many closed minds on both sides). While cold fusion may or may not be a reality -- in fact, I think it will not be, at least in my lifetime -- but I think traditional, high-temperature nuclear fusion *IS*!
For now, hybrid (petroleum and electrical return) and, soon, alternate fossil (CNG) and electric (hydrogen) fuels and fuel cells are our best chance. I sick of people blindly stating electric cars and zero emissions without knowing jack!
As far as solar, it's a mixed bag. Solar is expensive, period, and does not produce much. Some new solar technology is on the horizon, but it is rediculously expensive and the actual results are not concrete yet. It holds promise, but don't invent a reality that does not exist yet, let alone we don't know if it will be cost-effective (time will tell).
Wind is looking better and better. I have no problem with eyesores and someone brought up that point (I cannot believe people would argue against them because they are eyesores!). But that's an infrastructure that is a whole new bag.
Water is not an option to power the entire nation. There just aren't enough rivers and damns that can be built to power even 1/10th of the US. It is also questionable how long it takes to get a return on the initial investment which is extremely large in the case of hydropower.
Again, I'm just an engineer. That means I'm a scientist and a businessman. I'm not going to say things that are PC, just reality today. I hope for the best in the future but clinging to alternate realities or lying to yourself as you see fit are NOT 2 ways to get there!
-- Bryan "TheBS" Smith
I am personally getting sick of people who say "we should all move to electrical vehicles." The main problem is the the answer to, 'where does the electricity they use come from?' And the answer surely does not come out of thin air like many "wantabe" environmentalists think it does!
Electric cars use upto 5 times as much fossil fuels than ICE (internal combustion engine) vehicles.
How and why? First off, the electricity is produced at a power plant, of which, the nation still relies on 70-80% of fossil fuels to generate. Secondly, the efficiency of first generating the electricity from fossil fuels to drive a motor by electricity, rather than via an ICE is much, much lower. And, finally, there is a lot of transmission loss between the power plant, relay stations to your home (the most likely location where you will charge your vehicle). And there is the fact that the current power generation infrastructure could not meet the power generation needs to support home charging of electrical cars if 1/4th of America was driven them. In addition, I think most Americans would take exception to a $400-500 "electrical bill" even if they did not have to fuel their vehicles elsewhere.
In addition, because the elctricity is still generated from fossil fuels 70-80% of the time, the belief that it is "zero emissions" is just untrue. Now on the flip-side I will admit that power generation from fossil fuels at a power plant is less of a polutant than generation from fossil fuels in an ICE -- probably by an order of magnitude. So even if it takes 5 times as much gas to power the electric vehicle and, therefore 5 times as much fossil fuels are used, the total number of pollutants are probably cut in half. I.e. 5 (times as much fuel) x 1/10 (the pollution per unit fuel) = 1/2 (the total pollution).
So, at best, the "zero emissions electric vehicle" is a flight of fantasy, at least until we either develop direct heat to electricity generation (by passing the traditional steam turbine/generator system of today), possibly in combination with commodity fusion power generation (until which, we will be dependent on fossil fuels).
And if you are even thinking of solar power, don't bother. Solar cells would have to be 25 times as efficient as they exist now. Putting solar panels atop of your hood, top and trunk would not even yield enough power to go a few miles after several hours of charge. Wind power is in the same boat, although it it is more efficent than solar.
The reality of reduced fossil fuel dependence comes not from its total elimination. No. The best solutions come in "hybrid" electric vehicles where an ICE is used in combination with electric systems. Everything from alternators to flywheels are used to generate and charge the batteries while the ICE is running. Hybrid vehicles can almost double the MPG (miles per gallon) rating of vehicles over their ICE-only components.
Looking beyond just they ICE-electric hybrid, we can look at one petroleum replacement, and another one electrical source (other than direct battery storage and recharge). CNG (compressed natural gas) is one since it burns much cleaner than petroleum, and is in limited used in largely application-specific commercial vehicles (like various commercial utility trucks, etc...). Hydrogen fuel cells are a promising technology that will make electric cars much more efficient than charged and discharged batteries. But, both CNG and fuel cells have serious safety issues in their on-board storage in that massive explosions can result in rupture of their tanks (much larger than possible with petroleum-based ones because of the pressure and density of CNG, and the volitity of hydrogen in fuel cells).
Lastly, some may remember "gasohol", an ICE fuel replacement for petroleum. Gasohol is a reality, and can be used to power ICE. In fact, the US' total agriculture capability could meet the world's total demand for gasahol at least two times over if petroleum did not exist tomorrow. The reason it does not today is because of the cost of its refining into an end-user product. Not so much in the refining process itself, but in the massive and quite useless by-products and waste as a result of the refining process. As such, until petroleum resources start to dry up and drive costs of a crude barrel at least 5 times more than the cost today, gasohol will remain a relatively untapped technology.
I seriously hope I educated some individuals here. I don't work the petroleum industry nor do I defend them -- I'm actually quite critical, especially in light of the little effort by everyone in the US to push for the development and maturity of economical fusion power generation (which I believe is possible). I'm just an engineer who is sick of reading various comments on "electrical cars" or "renewable energies/fuels." Let's talk reality people or not talk at all!
-- Bryan "TheBS" Smith
Windows 2000 is designed to market a Windows server-dependency. The IEEE Computer Society's latest August 2000 (Vol. 33, No. 8) Computer magazine featured an article called Windows 2000: A Threat to Internet Diversity and Open Standards? (PDF available to members here).
A such, you need to adopt a Windows server-free network. This includes holding off on Windows 2000 until either Samba supports its interfaces (will take some reverse engineering) or someone finds a way to have it use NIS/NIS+ for authentication -- e.g., NISGINA does for NT 4.0. At my company, Theseus Logic, we use NISGINA instead of Samba TNG (just use regular Samba 2.0.7) to deal with authentication of NT 4.0 systems.
-- Bryan "TheBS" Smith
Have done this several times myself.
Just run rpm -Fhv *.rpm in your newer distro's RPM directory (e.g., /mnt/cdrom/RedHat/RPMS) and it will only upgrade those componenets that are install.
Heck, sometimes you don't even need to reboot! (although expect a few library issues until you do)
-- Bryan "TheBS" Smith
It's just a little box like the Linksys one, but so much more protective and flexible! If you're gonna spend $150-200 for a POS, why not spend $350-400 for a real firewalling solution?
-- Bryan "TheBS" Smith
Dude! Linksys should be SMACKED for calling that POS a "firewall". Linux IPChains is MUCH, MUCH better! At least it has some REAL logging!
For $350, you can get the SonicWall SOHO/10. It is the only ICSA approved firewall you can find for under $500. It has excellent features, including one-to-one NAT (so you can let in certain ports), and logging is fairly good (nothing to complain about at that price). I've used these little babies on corporate networks.
-- Bryan "TheBS" Smith
Microprocessor Design was quoted as saying that MHz for MHz, the Pentium IV will lose badly to the Athlon, especially when AMD matches Intel's 0.13um feature sizes. Why?
The Pentium IV is still the aged-old Pentium Pro core. Intel keeps pushing back the release of a new core design, simply slapping on instructions or widening the path internal datapaths, but doing nothing about the inefficiencies nor the stalling 10-12 stage pipelines in their design.
"Williamette" was supposed to change that and bring 17-20 stage pipelines that are much more scalable, like the Athlon's 18 stage design. Unforunately Intel is having design issues with the Williamette and holding off on Williamette's completion means Intel can get to market faster. Hence, this is what they have been doing to keep up with AMD.
Without "Willamette", AMD will still continue to beat Intel MHz for MHz on even Pentium optimized code with a reverse engineered AGP spec. Kinda makes you wonder if the odds were even if AMD wouldn't dominate Intel?
Now image that "Pentium optimized" FPU code still runs slower on a Pentium IV 1.4GHz than a 1.1GHz Thunderbird. Would I continue to make my code and compilers "Pentium optimized"? Imagine a world where code and compilers came "Athlon optimized"? I think you'd see the Athlon really slam Pentium.
-- Bryan "TheBS" Smith
First off, let's face it guys:
This is where RT/Linux, and other Linux pre-emptive microkernels come in. Advantages:
You get the best of both worlds. Minimal redesign, maximum reuse. The whole microkernel argument is old, very old. Linus has gotten Linux to the best it can be as far as soft real-time can be in 2.4. RT/Linux is the microkernel that addresses hard real-time and other size and response time issues. And it is a microkernel, running the main Linux kernel as a regular process. A perfect solution.
In a nutshell, it's impossible to get Linux to do everything without major modifications. There will have to be non-direct kernel implementations to do those unique applications. I really don't see any other way to do it. And besides, I don't see QNX, VxWorks, nor any other RTOS being as flexible as Linux is at doing many other things.
-- Bryan "TheBS" Smith
First off, AVOID:
Additionally, what you need to consider:
-- Bryan "TheBS" Smith
My company refuses to drop the "Microsoft Virus Distribution System" (aka Outlook). After applying the security patch (that disables a crapload of its insecure features), we ran into various issues. Basically, I think the whole security patches for Outlook were specifically designed to force you to buy Exchange. Instead, we opted for HP OpenMail. It's free for upto 50 users and has a 6 month trial (unlimited users).
It solved our shared Calendar and Contacts issues with its MAPI interface. Of course, none of these features of Outlook, even though they are stored on the server, are compatible with its included, native clients. We're still waiting for something better, but for free, it was a perfect fit (as my "cry baby" ignorant Office users complained after I installed the much needed Outlook fix when it came out). Hopefully the iCalendar and vCard standards in clients like Evolution will push Microsoft (among others) to support them (hopefully).
I mean, E-mail shouldn't be this hard and Sendmail (once setup) has been running for us solid for 12 months non-stop. OpenMail is great because it uses Sendmail (or any other MTA) underneath so you're not at it's mercy. Although you can have all our company's mail get redirected to OpenMail (e.g., as a Sendmail rule), setting up a subdomain or other MX record keeps its crap separate (I don't like Outlook crap going around on my network any more than I have to).
Anything to keep ignorant users (only about 20% of my company are these admin users, the rest are UNIX-using engineers) from screaming for Exchange is helpful. OpenMail is your ticket to keeping your servers Microsoft-free -- like ours where 90% of our work is UNIX-based and Samba handles the rest nicely. It is incredibly stable (even though the MAPI client for Outlook is only version 0.5 "preview release") and our server has been running for months now. Everytime I've dealt with an Exchange server, I expect no more than 60 days before a major corruption that keeps me busy for 48 hours straight. Not with OpenMail, it's rock-solid and has even survived someone twice accidently (and quite incorrectly) powering-off the Linux box where it is hosted.
It also doesn't take a lot of resources to run. Figure about 1-2MB max per client. For ~50 clients, a Pentium with 128MB of RAM will do nicely. We use a Pentium II 400MHz with 384MB and this system also seconds as a secondary NFS/SMB server (to Solaris clients and NT workstations) and Intranet (informational) server. Gotta love Linux baby!
-- Bryan "TheBS" Smith
I believe a set of kernel 2.2.16-1 RPMs appeared on RedHat Rawhide within days. It wasn't until 2 weeks later when the 2.2.16-3 kernel set was tested before RedHat officially announced the RPMs with the press release.
Note to reviewer: At least we have the option of running untested stuff at our own risk from various distro test labs and sites. You don't have that option with "Muppet Labs". ;->
-- Bryan "TheBS" Smith
Again, I think people are making this out to be too much of an OS issue. It's not. The fact of the matter is that many space vehicles don't have an OS and the use of a RTOS for multitasking has only been around for 3 years (forget even using a general purpose SO). So, again, it's a development tool issue and GNU is here and Windows is no where.
Space vehicles have a two fold requirement:
These are the extremes of the extremes. Although Linux can get sub-ms response times, you need a fast processor to get there (as with any general OS). Since low power is an even greater consideration, you're not going to get that speed. As such, you'll need to use a small, RTOS to get those response times on slower processors. [ I hope everyone here knows Microsoft is quite out of their mind when they say Windows CE is a RTOS -- it is NOT! ]
Where Linux comes into the space program (other than the engineering workstation/development systems themselves) is in the support systems. Several examples:
-- Bryan "TheBS" Smith
Here's the direct URL:
http://www.wrs.com/products/html/jpl.html
This JPL mission really set the "standard" on what COTS hardware and software could do. It is the main reason why VxWorks was so widely adopted by the rest of the Aerospace industry.
-- Bryan "TheBS" Smith
In case you're interested in eCos, here's the homepage URL (forget to include it above):
http://sources.redhat.com/ecos/
-- Bryan "TheBS" Smith
[ Note: I was a Software Engineer at Coleman Aerospace for 3 years ]
Many of the early computers in ballistic missiles and space probes borrowed heavily from the military. Much of the gyros and computing systems were produced by Bendix for the Department of Energy (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant). In case you aren't familiar with how the government works, the DoE was and still is the non-military, government agency tasked with the creation of numerous components of our nuclear arms technology (as well as their normal energy details, a natural tandem role). Looking at their "most advanced computer" in the early 1980s (the Bendix 930 in the Pershing II MRBM), you essentially had a 16-bit CPU and database with 64KB of memory on various cards in a wire-wrapped backplane. And, yes, all the target code for these machines are done in assembler.
Today, both the military and NASA contractors "better, faster, cheaper" attitude of using off-the-shelf hardware, tools and software revolves mainly around the VME architecture (usually for 68300 and, increasingly, PowerPC boards -- military spec/hardening) with WindRiver's VxWorks RTOS. VxWorks is heavily BSD 4.3-based OS with response times in the tens of microseconds (on a 40-50MHz processor). Development is done using GNU development tools using a customized Cygnus GNUPro (now under RedHat's services group) product called Tornado (customized for WindRiver by Cygnus) so it can target various VxWorks architectures with Linux, Solaris and Windows being the most popular host development platforms. [ I personally found Windows to be a real pain if you also install Visual Studio on the same system because which tries to take over your system -- have to be careful you run the right make, etc... binary ].
A well-known 68K/VxWorks-based mission was the Mars Pathfinder. Today, the combo is used in a wide variety of launch and space vehicles. At my former employer, we used it for our ballistic target and booster vehicles for the military and LEO (low earth orbit) launch vehicles for NASA (and they continue to do so). A future mission to the outer planets will be PPC/VxWorks-based, all written with the GNU development system. [ Since Linux nor most other general-purpose OSes cannot guarantee such "hard" real-time response times (let alone no Windows platform can seem to deliver even deliver any "soft" real-times either), it is my hope that Cygnus' (now RedHat's) eCos takes off and cuts into VxWorks' market in the next 5 years). ]
Which brings me to my final point: I think people get caught up with the whole this OS versus that OS issue when the argument should be GNU development versus Microsoft Visual development for "mission critical" purposes. The GNU cross-compilers and tools allow you to target dozens of platforms and massive code reuse whereas Microsoft changes its Visual Studio products on a whim. I mean, it's really harder to port Windows code just for a version change than it is to port to another, completely different architecture with GNU. I personally don't see why Windows developers put up with it because Cygnus makes some damn good IDE and tools for development.
Personally, I think the best remedy for the whole DOJ v. Microsoft trial would be to force Microsoft to support GNU-based development tools for the Windows platform (both target and host) -- and set a time-frame in which they would have to drop their current, non-GNU-based Visual product (e.g., 5 years). This would do several things: actually force the documentation of the API, thus increase overall stability of the Windows platform, finally address multi-user ignorance as the main problem with Windows security (98% of even Microsoft's own applications are multi-user ignorant!), and many, many other benefits to the developers as well as the consumer. Of course no one in the trial has the forsight to see this as the best remedy, and I seriously doubt we will see any discussion of it either.
-- Bryan "TheBS" Smith
Good question.
First off, only 5-10 miles big is too small to always be spherical. I believe it is somewhere between 100-200 miles (160-320 km) in diameter before gravitational forces are strong enough to force a spherical shape -- assuming the mean density of most asteroids/planets which can, of course, vary greatly. Please correct me if I am wrong.
So what is the criteria for an orbiting object to be termed a "natural satellite" then? I assume it is:
-- Bryan "TheBS" Smith
I'm a big proponet of putting peltzer or other thermal control logic on high power ICs (such as general-purpose CPUs) to control these cooling devices. The main problem is condensation and if you put the CPU in control of its own cooling, that would eliminate 98% of it's issues.
Otherwise, I found the units for enclosures to be a little too expensive for consideration ($500+!). While it would be neat to run my box with a consistent 60-65 degrees F (you should always run about 55 degrees F for condensation purposes), I don't think it is worth it for $500.
-- Bryan "TheBS" Smith