Hopefully they'll be able to squeeze them down to AA size. I have some lithium AA batteries for my PDA, and the battery life is a little longer, but the big plus is that the amperage keeps up even when the batteries are low. With NiMH (or NiCD I suppose) if the battery is low and you turn on the backlight, the PDA shuts off and drops to backup battery power. Maybe with a fuel-cell battery you could actually use the PC-Card slot on the road for more than 30 minutes without draining the batteries dry.
If you have any money to work with at all, consider using Compact Flash with an ATA adapter. You may be able to get the adapters and CF cards donated to you by a vendor if you can prove to their satisfaction you're trying to do something charitable. If you scale your plans to fit in an "obsolete" size of CF cards, you may have better luck. A vendor would probably be happy to donate to you a hundred 4 MB CF cards.
The advantage is that the BIOS sees the CF card as an ATA hard disk. At 1 to 16 MB, almost any BIOS will boot from one. And you can load the CF card with FreeDOS and DOS-based tools for linux (UFS), so that you can bootstrap the PC initially and THEN load additional software from CD or a harddisk or ethernet or whatever.
They might also be useful to allow an old PC to use a modern hard disk. The BIOS may be too old to like today's large disks, but CF cards should be no problem. From there, Linux ignores the BIOS like a bad relative, and can mount almost any device it would normally support. So you boot off the CF into linux, and from there have access to CD-ROMs, UltraATA size disks, or whatever you want to use. No different than booting from a DOS floppy with MSCDEX on it for PCs that don't speak El Torrito.
Also, the CF card is solid state, and a given card will either work or pretty much fail outright. Floppies and CD-ROMs are mechanical, and will give you intermittent problems if there's something wrong with them.
As far as a distro for Old PCs for non-nerds? Look for something intended for kids, like SEUL. But most linux is too incomplete to foist on people unwilling to roll up their sleeves, unless you plan to give them full KDE.
Keep it simple. Make it look like DOS with: - pretty colors - multiple simultaneous windows - 2D color graphics and printing - basic sound - documentation that looks like English - some friendly shell scripts with English names that handle the hard stuff for the user. - a paper booklet that explains how to use it.
You might look at Slackware as a basis to build you own, or dare I say it, NetBSD, which is very friendly for a free OS (good man pages, easy system administrations, a K.I.S.S approach to everything).
Keep in mind, if it wasn't much work to do, everybody would probably be doing it, and you'd find ancient relics running Linux faithfully for old ladies in every small town and ghetto of America. That doesn't mean the work's not worth doing.
Oh...and don't forget... at 13G/tape, you might be looking at 10+ tapes to back up some drives these days....It might be a cool hack, but changing tapes sucks...I'd still rather just mirror to another drive that I can remove, as the random access dramatically improves recovery time.
But if you're a home user, not backing up an IT department or your business machines, then you don't need to back the entire drive. Just the changes. And for a single PC, even with broadband, a day's worth of work isn't going to fill an entire 100GB hard disk, unless you're doing video production or audio editing with ProTools. Then your back in the "business" category of backups, and should buy a solution indexed to the cost to recreate lost data. Never backup $1000 worth of data on a $35 device unless you know your going to be able to recover it.
This isn't really a reply to your post per se, but slashdot in general. Everytime one of these "backup" related stories hits slashdot, it's always the same litany. "How do I backup my 136 GB hard disk? To another hard disk?" No. The answer is "You don't." Or "If you have to back up the WHOLE disk, you're doing it wrong."
1) Secure your computer.
If you tighten the permissions on your PC so that non-root/administrator can't write files wherever they please, this simplies backups greatly. You shouldn't be logged in as a privelidged user anyway except for maintenance. Your backup software can help you here, making a catalog of changed files to backup. If you see changes in/usr,/bin, or even Program Files or WINNT, you should figure out what those changes are and whether they need to be backed up at all. You may need to tighten permissions again or reconfigure the program to write its logs or scratch files somewhere less dangerous, like the temp directory.
2) Don't back up worthless files.
Browser cache, history, temp files, print spool files, etc etc. Just exclude them from the backup script. You're probably saving yourself from future prosecution by not backing up any way, and some of the files get corrupted and are good to purge. If you don't backup worthless junk, there's less to backup.
3) Backup in sets to multiple media.
If you've done the above, then you can use algebra to make backups. If you've already backed up the OS and apps, and your permissions and backup scripts confirm for you that there are no interesting changes in those directories to backup... then you don't need to back them up! As long as you have a duplicate of each backup tape/cd/floppy (copy 1 of 2, copy 2 of 2) and you store them in different places, you're good. I've been running on incremental backups for months.
On a home machine, with good security and a good list of junk files to exclude, a days changes are at most 1 meg, but only if I download a large file. And that includes my wife's stuff too. With an aggressive backup scheme, it really doesn't matter how big the disk is but how much change in data from day to day you have to back up. And it gives you a good opportunity to learn about your system by keeping tabs on this.
With that kind of strategy, MiniDV looks actually pretty good. Just use 2 mDVs with the same backups on each, maybe "Winter 2003 copy 1 of 2" and "copy 2 of 2". That will hold 13GB of _changes_ to your system, which is quite alot, and might actually hold a year's worth for some people. With the reduced cost, it might be worth a look.
Didn't the Apache project have an object database for storing XML object in native for and running queries? What was it called? It used to be right on the front page of apache.org, but I can't find it.
Is there anything comparable in the US? I have a cell-phone, and have thought about using it to get on-line (sort of a portable broadband connection), but the speeds available are either pathetic (like the 9600 baud from cingular) or the cost is obscene. Is there anything in America worth even looking at? I'm not talking about downloading 600 meg ISOs or albulms worth of MP3. I mostly want it so I can place my one PC wherever I want in the apartment with out having to tape phone cabling to the baseboard or shelling out money to SBC just to "activate" more than the one live RJ-11 port in my unit (in the worst possible place in the apartment of course).
Something faster that dialup but cheaper than DSL/Roadrunner and that would work on a NexTel motorola phone (one of those with the "CB-radio" chat function - I have an i30sx) would be ideal. Of course I could google for it (and have), but what do the rest of you recommend?
Spare 100 GB Hard Drives: $100 If you go with cheaper IDE drives, you probably aren't going to do hot swapping, so you'll have to bring the system down to remove them. SCSI would be more expensive, but would allow hot swapping. NAS is an option though, but slower. Drives are not meant to be carted around, bumped, etc like removable media is. One accidental drop and the entire backup is shot unlike tape or disc based backups. Really fast seek times though.
I like your post, but you forgot that modern EIDE disks support tunneling the data through another transport. So an ATA hard drive solution does _not_ mandate using an ATA adapter with 2 devices per IRQ in Master/Slave. You can mount an ATA disk using many other kinds of buses and gain hotswappability in the process. ATA bridges for USB, 1394/Firewire, SCSI, and even the parallel port exist and can be bought at Fry's. There are disadvantages, like USB's bad speed and reputation for unreliability, or Firewire's cost, or SCSI's device conflicts. But it can be done.
I _think_ SATA also supports hot-swapping drives, and there's a standard in the works for using USB for internal peripherals.
The big downside to ATA drives is storage. Even though head autopark now, they're still more vulnerable to crashes when spun-down. And if a drive mechanism is going to fail, the spin-up after the drive's been in your file cabinet for a year is when its going to happen, maybe due to a little stiction.
Sure, but with only 1 language, you lose the advantage that comes with heteorogeny (not having everything be 100% the same).
Some problems are very easy to solve in certain languages, or to say it another way, some languages make short work of what would otherwise be a long, complicated problem. If you standardize on the "one" holy language to use, then you reduce the probability that the problem you need to solve yesterday just happens to be child's play to solve in a language your people know. Especially if you only use one language, your programmer might forget this very useful fact. Why write, compile, debug, etc a program in any language when you can do it ad hoc and just as fast with one long line of sh script?
A homogenous network reduces the pool of qualified applicants for hire. Or the applicants you want to hire would be more likely to need to learn the one language you standardized on. If you standardize on 2 or 3 languages, the new hire is more likely to be immediately useful on some of your projects, and can be useful later on the rest after some studying, versus being useless for a month or two of ready O'Reily books.
Security. It is harder to have good security on a heterogenous network, because there's simply more work to do. But some security problems are mitigated by not having a homogenous LAN. Like viruses, worms, and scriptkiddies. I realize that if you use 3 languages on 3 OSes that you're more likely to be vulnerable to a given virus, worm, or rootkit that starts taking the net by storm, but if not all of your systems use all 3, then if a worm gets into your network then less than 100% of your systems could be affected. And with worms and such, that's what you want. If you can't guarantee your immunity, you should at least guarantee that you have to only fix some of the systems rather than ALL of the systems at once.
Some languages just don't run well on some platforms, and not for any good reason. Sometimes, just because. Why? Because maybe the work isn't finished. VMS, classic MacOS, and Windows CE are 3 good examples of OSes with subpar scripting language support. If a given scripting language works fine on unices, linux, NT, and even DOS/Win32, the odds are it won't work as well on VMS, WinCE, or classic MacOS simply because the bugs in the port haven't been hammered out yet (or bugs in the target OS...). Why should you, the shit-hot scripting genius give a damn about what runs or what doesn't run on VMS or whatever?
Because sometimes management buys systems without consulting the expertise they keep on retainer. Like a VAX. And then they say, port all your Ruby or whatever scripts to the new financials system and get it working so the VP can come see it working uh... when is he coming, Bob? Oh yeah, tomorrow. If you standardize on 2 or 3 languages, you're more likely to have some scripts whose interpreter installs painlessly and actually runs correctly than if everything has to run in one language. Then 30 minutes later you have something to bemuse the VP with, rather than slaving thru 8 mind-numbing hours of hell trying to figure out how to get the version of Perl you need to run on whatever monstrosity the department just bought with their end-of-fiscal-year money.
So to sum up, I agree with you: IT shops should standardize their scripting languages. But I think you create a situation where it's easy to get painted into a corner if you allow only one language to solve all your problems. It's too idealistic. Unless you work in a company where you actually have complete control over the IT setup or can do whatever you like in your own sphere, then you have to be prepared to adapt to the whims and decisions of others, no matter how stupid or dilbertesque they may be. Letting everybody use whatever they want whenever they want has obvious problems too, so 2 or 3 standard languages is a reasonable ground. Or if your LAN uses a lot of commercial software that only intergrates with native OS languages (like the command line on NT or Apple Events on old PowerMacs) then standardize on 2 "portable" languages that will run on most anything, and then whatever native language is most prevalent on the local OS (cmd.exe for NT, AppleScript for Macs, DCL for VMS, etc.) so your team will understand how to use them (rather that learning AppleEvents or CMD systax by reading the perl glue documentation.
As for programming vs. scripting -- the distinction is kind of worthless. You're supposed to be able to easily do both and use either one to facilitate the other. That was the basic point of UNIX. It was originally supposed to come with a C compiler so you could create your own compiled commands, and thanks to pipes, shell scripting in general, and the system() call it took very, very little work to write a complete UNIX command in C and just keep adding features. Then use your new command in your scripts and back and forth, ad infinitum, hypothetically getting lots of work done in the process (which, if you've ever used a public UNIX shell host, actually seems to be the case some times...)
The scripting vs. programmer schism is a hold-over from the Big Iron days when companies employed "programmers" to code or support in-house systems on their mainframe or mini. In the 80s, when most of those projects had gone on long enough to backfire, all the programmers got fired, companies started buying turnkey "solutions" from vendors to phase out their mainframes. Scripters were hired as sysadmins for buggy vendor systems or to represent the companies best interest in calling the vendor for support. Often this meant writing simple programs in scripting languages to solve a problem the vendor either should have solved in testing or refused to solve for less than a boatload of money when called on their "support" hotline. So programmers look down on scripters for what may be many reasons, but mostly they perceive us as just a bunch of dumb-ass, amatuerish scabs.
They're just jealous. To me, being on call means finding my cell phone under the bed and telling the operator "Ok, hit menu 5, then 3, then re-enter the name of the file. Yes, that's right. That did it? Ok, good night." and then going back to sleep for the night, maybe dreaming of a script to recognize the problem and solve it automatically without forcing the operator to call me unless it doesn't work. Meanwhile, programmers actually have to get out of bed and fire up the debugger, if they didn't spend all night at the office in "marathon coding" session. I guess I'm just too dumb to understand how much smarter they are than I am.
He threw _lead_ miniatures in the fire, probably painted with acryllics that may have had other fantastic ingredients. If he saw something a little crazy after that, he was probably downwind from the flames.
Or maybe he just handled the miniatures too often without washing his hands afterwards. They were made of lead (with some pewter). I remember my mom insisting when I first got some Ral Partha and Grenadier miniatures that I spray paint them first thing to put an enamel over the lead. I can't say if the propellant fumes from the chrome spray paint were any less harmfull than handling lead figures while eating junk food over a game of Stormbringer or CoC, but my other personalities all agree it was probably the right thing to do because Mother Knows Best. At least she let me play RPGs as long as I kept my grades up.
What's that Mother? Hit "Submit"? But I wanted to... Yes, Mother.
If your friend overuses the utterance "mmmkay", hit them in the eyebrows with a wrench IMMEDIATELY. A paperweight, fax machine, algebra text book, or any other solid, weighty, low-voltage object that's handy will do in a pinch.
If your friend objects to your linguistic intervention with cries of "Dude!", "Chill!!!", or "Mai Gawwd!", repeat administration of blows to the head until his outcries coalesce into complete English sentences, strings of proper Anglo-Saxon profanity, or unconciousness. Call 911, explain what happened, and the paramedics will show you the correct way to properly kick your friends ass should linguistic fault recurr.
DO NOT HESITATE TO INTERVENE. If you act now, you can save your friend from such humiliating future life experiences as the following:
DIVORCE: "Honey, I need you to properly rinse off each dish before putting them in the dishwasher, mmmkay?"
UNEMPLOYMENT: "So if you could just put the correct cover sheet on the TPS report and have it on my desk by Monday, that would be great, mmmkay??"
VIOLENT DEATH: "You young kids better turn that ganster rap music down, mmmkay???"
Remember, friends don't let friends talk down to others, mmmkay?/me ducks
Damn! They use gotos in the development of windows?!
I know understand why it keeps crashing..
Yes. It's 50 million lines of QBASIC source code.
SUB BSOD (whatExcuse, howHard)
LET hellFreezesOver = FALSE
DO
POKE (RANDOM(whatExcuse), RANDOM(howHard))
UNTIL (hellFreezesOver)
END SUB
Or something like that. Hm, that sounds like something an NT developer might say. Or a slashdot poster. I'd batter make sure I mispelld enough wurds before I give people the wrong impression...
Go to Ikea and look for the "Jerker" desk. Terrible name for a product in an English speaking country, but it's a great desk with lots of room. The have shelves, keyboard trays, cable organizers, and CPU holders (which are good for holding USB/1394 devices in a stack or your PDA/camera/cell phone stuff). They also have a rack of lights your can bolt under the top shelf for built-in lighting. You can also adjust the height of the tabletop, but you have to take the desk apart to do it.
Judging by the so-called "driving" of most BMWs I see on the road here in LA, a computer-driven surrogate brain might be of real use to them. Their own brain obviously isn't up to the job.
That reminds me of a gag I heard on car talk (Remember, kids: if you want to repeat a lame joke, just blame it on Car Talk or Slashdot and no one will question it):
Click: Say, knucklehead. Whaddaya call a sucker driving a BMW?
Clack: Hm, a sucker driving a BMW... Hey, wait a second! Isn't "sucker" and "driving a BMW" kind of redundant?!
No, it's because the term "OS" is commonly used to mean "OE" or "Operating Environment". Linux, being the kernel, is an OS. sh, and all the other shell tools are the OE. You don't have to use sh for your shell or init or any other shell tools, replacing them with other valid executables. A real world example of this is the FreeVMS project. In making a free/libre version of VMS, they don't want to duplicate the work of writing drivers and developing a kernel -- they want to focus on developing analogs of DCL, TPU, the Queue manager, etc. So they're using Linux or FreeBSD for their kernel and writing their own userland.
Same with Windows Explorer. The "My Computer" icon is part of Windows' operating environment. You can, believe it or not, use Windows without using Explorer (using the command line or a replacement shell like LiteStep). Windows just isn't designed or intended to have its core components replaced so easily. I think there was a court case about it... Anyhow, I used to run Windows NT with just cmd.exe as the shell, which was fun for a few weeks, figuring out how to set control panels from the shell. With cywin & GINA installed, you could put a nearly complete UNIX face on NT and still be able to run Win32 apps.
Sun is one the only companies I've seen distinguish between an OS and OE. They used to (still?) call it the Solaris Operating Environment, with the SunOS kernel as the underlying OS. The truth is nobody cares. _My_ eyes are glazing over just writing about this. My sincerest condolences to your disintigrating brain. But on the bright side, without the ambiguous use of technical terms, slashdot readers would have a lot less to argue about, and this site would degrade into a competitive festival of increasingly embarrassing personal confessions on sex, drug use, music, government secrets, scams, circumventing the law, satire, and other boring stuff like they have kuro5hin. If we should be so lucky.
I disagree completely. The HELP command on VMS has good docs written in fairly plain english, and it is easier to browse than man. But a lot of VMS info isn't in the help/message system.
I'd focus on the manuals first, since they actually explain the concepts. HELP is mostly just a quick reference. VMS comes with a CD of manuals in HTML and PDF, and there's a web site as well with those. If you read off a screen faster than off paper, then there you go. I think SYS$HELP: also has txt copies of some docs, if they were installed.
You can also get a VAX emulator to experiment with. CHARON used to have a free version. The project that wrote the free PDP-11 emulator has a free VAX emulator too. You'll need the install sets from the tape or CD and a valid liscence PAK for VMS. If you "borrow" the PAK from a real VAX on your LAN, you may want to avoid experimenting with networking (besides being "illegal" -- gasp!).
As far as learning an OS quickly? - 4 days isn't enough time. I say 7 to 30.
- Learn the shell and make a quick reference sheet of the sytax/commands.
- Learn the editor and do the same thing.
- Then learn how to customize the editor and do automation. EVE on VMS is underrated. You can write your own commands and maps them to keys, edit multiple files, run DCL from EVE and stick the output in a file, edit ASCII tables in block mode. And you can remap the keys. I have an EVE$INIT.EVE that leave all the standard/default keys alone, but maps all the standard commands like GET FILE to things like GOLD-O, etc. There's also EDT, but I'd learn just enough of it to be able to get out of it.
- Learn how to write scripts. On VMS you have @ and.COM files, and EVE is written in TPU which has text-oriented features. If you learned the shell syntax and the editor, then you're all set. Then you can edit startup scripts like LOGIN.COM and EVE$INIT.TPU to have all the settings you want to have all the time.
- Learn how to multitask from the shell. On VMS, the commands you want are SPAWN and ATTACH. The trick is to SPAWN the program with a process name that you pick, the use attach to switch to it. From DCL, you can use DEFINE to map the ATTACH command to a function key. From programs like EVE you again map the ATTACH command to a key to switch back to DCL. Once you get the idea, you can do one-touch task switching between DCL, EVE, pine, lynx, NOTES, and you're own programs. Then VMS doesn't seem like such a typing contest to use.
- Learn the boot process of the hardware and OS completely. FE, on VMS the boot scripts set most of the logicals and symbols. People who don't understand this tend to think they can set symbols ad hoc, then reboot the VAX if there's a problem, and the symbol will still be there. Nuh uh. Sorry.
- Also learn how to "break in" by booting up by an alternate means. If you get locked out of a machine by a coworker or assume duties of a neglected box, it nice to know which manual the procedure is in than having to wonder if you can get in at all.
- Then learn how to find, download, and install freeware from off the net. No matter how obscure a computer may be, someone has written software for it, and someone else has a collection of it on the internet for you to download. You can learn a lot by trying to install new software on an OS. You can also fuck up your production system, so use an unpriviledged account on the test systemaa (after updating your backups first) and be careful. VMS was once the MS Windows of mainframes, and it did have viruses, trojans, and other malware.
- Try installing the OS from scratch, if you can. This is where an emulator rules. It dispenses with the need for a "spare" VAX to ruin, and emulators have feature that allow you to cheat. Often you can pause the CPU and scan memory for strings, or save and restore snapshots of the disk or the entire state of the emulated machine. Then you can try all kinds of reckless and stupid things without hosing the OS (just restore a snapshot). If you wanted to learn NT from scratch, having Bochs, VMWare, or VirtualPC would give you the same advantage.
- Last, learn how to use the built-in commands to write, compile, and run your own binaries. VMS usually doesn't come with compilers unless you buy them (I think) but MACRO assembly is standard. Most wouldn't go that far, but if you really want to learn an OS, learning how to write applications for it opens all the doors. Unfortunately, you really should know all the previous stuff first or you get stuck on simple things. Assembly may sound extreme, but it's absurd how much information you can get from a binary by running it through a decompiler. If you know enough asm to be able to look up what you need to know, then that's enough to get by.
I once had a VMS problem where a W32 client would crash when the user used a "Print Preview" function. A lot of spring cleaning had been done on the VAX to remove what the vendor told us were old, useless files that were safe to delete. Ha ha ha. Fortunately I had installed infozip a while back and zip'd up these "junk" files before deleting them. But there were no log or error messages that told us what was wrong with the client (it just Dr. Watson'd). I used cygwin to run 'strings' on the client exe, and listed in there was a pathname to one of the files we'd deleted. For fun I made an empty file with CREATE on the VAX with the same name, and like that the problem was gone. The client only tested for the existance of that file, but didn't actually need its contents.
I've used the same basic steps to learn several platforms: Macs, Solaris, NT, DOS, Linux, etc. People get superstitious around computers. even experienced people. It'd be no different on other wierd architectures, like an AS/400 or a old 8-bit PC from the 80s. It's mostly just process of elimination.
Dave Roth, a Windows consultant and author of several extensions for Win32 perl, wrote a paper on managing a WAN of NT machines, most of which can apply to W98, if you do some testing:
http://www.roth.net/conference/lisant/1999/ and http://www.roth.net/conference/lisant/1999/NMMS. pp t
There's an old Mac program called RevRDist from Purdue that uses the same strategy. It might give you some good ideas, even if it's not for Windows. Another good site is on this problem in a more abstract way (centered on UNIX): http://www.infrastructures.org/
The basic trick: use login scripts. Don't think that this won't help you if your LAN can't force people to actually log in to the PCs they use. Where Roth's idea is better is that he uses 1 special login account to install batch scripts scheduled to run everyday at specific times. The batch script runs scripts off a read-only share, so saving new scripts to the share you can do automatic updates on all machines every 24 hours, including updates to the scheduled batch scripts themselves. Your staff only has to "touch" each PC once by loging in as the special account, and there after everything is automatic, depending on your ability to write robust, correct scripts and do proper testing.
As for remotely installing OS patches from a central PC? Are you totally MAD? Any feature you can easily use to remotely change a computer can be used by a hacker or worm to adversely "update" every PC on your LAN. It doesn't matter if the so-called white paper says it's secure. Internet worms are more serious problem these days than ever, so give security serious thought before you deploy, no matter what solution you decide.
Just because you switch your network to Linux doesn't mean you can't run Windows software. Even assuming all client PCs run Linux, you still have options:
Run ONE NT/2000 server just to serve up the accounting and connect to it via: - ICA/RDP clients (buy appropriate CALs!) - A browser (for web-enabled accounting apps) - VNC (just kidding)
Or run a Win32 or DOS program right on Linux for i386: - WINE or DOSemu - VMWare or Bochs
Or buy a UNIX accounting turnkey system and connect to it from linux using X, telnet, ssh, browser, or whatever. Take a look at the offerings for Solaris, AIX, Tru64 and HPUX. Accounting vendors for these commercial UNIXes may already have a Linux version for sale. Then your manager's fears will be appeased since it's a "real" accounting app you're recommending.
This is an old idea. "Poor man's clustering" is what they call it.
The essential trick that you may not think of yourself is to set the SCSI ID of the 2 SCSI host adapters to _different_ SCSI IDs. Most people forget this. Remember, the PCI SCSI you use takes 1 SCSI ID in the chain, even if it's on the motherboard. So if you connect 2 PC to the same SCSI chain, the ID of each PC's SCSI adapter needs to be different, otherwise it's no different than having two hard disks both set to ID 3.
2nd, make sure you terminate both ends and put both PCs inside the termination.
So your chain should look like this:
T-P7-6-5-4-3-2-1-P0-T
Where T is a Terminator, a number is a SCSI ID, and a P designates the SCSI adapter in a PC.
Good luck, and make sure you have enough goats!;-)
I'll second that. I've seen the AC fail in a server room, and the temperature climbs with every passing minute as hot as you let it until you improvise some ventilation or fix the AC. A colder room buys you more time to do either before the heat starts damaging equipment or causing CPUs to lockup.
I worked in a cold server room for a time and had the same problem you did. I understand where you're coming from. Being too cold to type is the least of your worries. You could catch a serious cold if you follow the contagion with a couple hours spent shivering in the server room.
- Find the drafts in the server room and reposition yourself so you aren't directly in its path and avoid the "Wind-Chill Factor". - Double-up your socks. - Wear a t-shirt under your dress-shirt, which will layer your clothing. - Wear a hat in the server room. Keep the hat in your bag or pocket at other times. Scarves work too and give you that Tom Baker idiot-savant look. - Go to a store that caters to hunters and buy some thermal underwear. The good kind looks more like medieval tights than that white pleated junk they sell at K-Mart. BE CAREFUL: when wearing thermals, you build up a lot of static electricity. Pay attention to ESD. - Shiver while you type. The motion will raise your body temperature a bit. - Eat something with a lot of calories before going in the server room. Metabolism creates body heat as a waste product. - Drinking hot liquid doesn't work. The warmth doesn't last, and it makes you have to pee. But hey, whatever gets you out of that freezing server room, right? - Gain some badly needed weight, pal. Cold doesn't bother heavier people as badly. Score some Carl's Jr. coupons and get to work.
If you're still cold after all that, then yes, maybe the room is too cold. But probably it's not, and the client is moderating your complaints as "Whiny" and "Wuss". Just quietly solve the problem on your end and protect your own health, and then you won't need to bother your clients with "I can't work under these conditions!!!"-type complaints.
ACARD makes a series of SCSI-IDE bridge cards which connect to the SCSI chain on one side and an ATA hard disk on the other. They have several models, mostly depending on what type of SCSI cabling you have, costing from $50 to $80. They support large ATA disks, the cost of which plus the $70 for the bridge is still cheaper than most SCSI drives. If you don't need the warranty and physical traits of SCSI hard disks, but you want to be able to hook up 6 drives to your PC with only 1 IRQ and IO address or add 60-80 gigs of space for under $200, this might do the trick. They also come in handy for old workstation-era machines, like PowerMacs, SparcStations, or VAXes. The bridge doesn't require any drivers or software to work, since it just tunnels ATAPI and makes the IDE drive look like just another SCSI disk in the chain.
http://www.acard.com/eng/product/scside.html
Microland sells them in the US: http://www.microlandusa.com/microland/
Some downsides: - The hard disk has to be formatted while cabled to the SCSI-IDE brige. You can't move a drive from a regular IDE controller to the SCSI-IDE bridge without getting geometry errors. - The interface is ATAPI only, so not all commands for the device may work. FE, firmware updaters and vendor utilities designed for the hard disk probably won't work the bridge. - The utility to update the bridge's firmware is only for DOS/Windows.
There will probably be LVD-SATA bridges too in the future, if SATA truly catches on.
Not quite. I can install it on any machine I want to, assuming that the machine is compatable with the OS hardware support. The main issue of course being that there are still seperate distros of Linux (PPC, x86, SPARC). When will we see a distro with all the nessesary code in one package, and a universal install?
Slashdot Mirror
Hopefully they'll be able to squeeze them down to AA size. I have some lithium AA batteries for my PDA, and the battery life is a little longer, but the big plus is that the amperage keeps up even when the batteries are low. With NiMH (or NiCD I suppose) if the battery is low and you turn on the backlight, the PDA shuts off and drops to backup battery power. Maybe with a fuel-cell battery you could actually use the PC-Card slot on the road for more than 30 minutes without draining the batteries dry.
If you have any money to work with at all, consider using Compact Flash with an ATA adapter. You may be able to get the adapters and CF cards donated to you by a vendor if you can prove to their satisfaction you're trying to do something charitable. If you scale your plans to fit in an "obsolete" size of CF cards, you may have better luck. A vendor would probably be happy to donate to you a hundred 4 MB CF cards.
The advantage is that the BIOS sees the CF card as an ATA hard disk. At 1 to 16 MB, almost any BIOS will boot from one. And you can load the CF card with FreeDOS and DOS-based tools for linux (UFS), so that you can bootstrap the PC initially and THEN load additional software from CD or a harddisk or ethernet or whatever.
They might also be useful to allow an old PC to use a modern hard disk. The BIOS may be too old to like today's large disks, but CF cards should be no problem. From there, Linux ignores the BIOS like a bad relative, and can mount almost any device it would normally support. So you boot off the CF into linux, and from there have access to CD-ROMs, UltraATA size disks, or whatever you want to use. No different than booting from a DOS floppy with MSCDEX on it for PCs that don't speak El Torrito.
Also, the CF card is solid state, and a given card will either work or pretty much fail outright. Floppies and CD-ROMs are mechanical, and will give you intermittent problems if there's something wrong with them.
As far as a distro for Old PCs for non-nerds? Look for something intended for kids, like SEUL. But most linux is too incomplete to foist on people unwilling to roll up their sleeves, unless you plan to give them full KDE.
Keep it simple. Make it look like DOS with:
- pretty colors
- multiple simultaneous windows
- 2D color graphics and printing
- basic sound
- documentation that looks like English
- some friendly shell scripts with English names that handle the hard stuff for the user.
- a paper booklet that explains how to use it.
You might look at Slackware as a basis to build you own, or dare I say it, NetBSD, which is very friendly for a free OS (good man pages, easy system administrations, a K.I.S.S approach to everything).
Keep in mind, if it wasn't much work to do, everybody would probably be doing it, and you'd find ancient relics running Linux faithfully for old ladies in every small town and ghetto of America. That doesn't mean the work's not worth doing.
Best of luck.
Oh...and don't forget... at 13G/tape, you might be looking at 10+ tapes to back up some drives these days....It might be a cool hack, but changing tapes sucks...I'd still rather just mirror to another drive that I can remove, as the random access dramatically improves recovery time.
/usr, /bin, or even Program Files or WINNT, you should figure out what those changes are and whether they need to be backed up at all. You may need to tighten permissions again or reconfigure the program to write its logs or scratch files somewhere less dangerous, like the temp directory.
But if you're a home user, not backing up an IT department or your business machines, then you don't need to back the entire drive. Just the changes. And for a single PC, even with broadband, a day's worth of work isn't going to fill an entire 100GB hard disk, unless you're doing video production or audio editing with ProTools. Then your back in the "business" category of backups, and should buy a solution indexed to the cost to recreate lost data. Never backup $1000 worth of data on a $35 device unless you know your going to be able to recover it.
This isn't really a reply to your post per se, but slashdot in general. Everytime one of these "backup" related stories hits slashdot, it's always the same litany. "How do I backup my 136 GB hard disk? To another hard disk?" No. The answer is "You don't." Or "If you have to back up the WHOLE disk, you're doing it wrong."
1) Secure your computer.
If you tighten the permissions on your PC so that non-root/administrator can't write files wherever they please, this simplies backups greatly. You shouldn't be logged in as a privelidged user anyway except for maintenance. Your backup software can help you here, making a catalog of changed files to backup. If you see changes in
2) Don't back up worthless files.
Browser cache, history, temp files, print spool files, etc etc. Just exclude them from the backup script. You're probably saving yourself from future prosecution by not backing up any way, and some of the files get corrupted and are good to purge. If you don't backup worthless junk, there's less to backup.
3) Backup in sets to multiple media.
If you've done the above, then you can use algebra to make backups. If you've already backed up the OS and apps, and your permissions and backup scripts confirm for you that there are no interesting changes in those directories to backup... then you don't need to back them up! As long as you have a duplicate of each backup tape/cd/floppy (copy 1 of 2, copy 2 of 2) and you store them in different places, you're good. I've been running on incremental backups for months.
On a home machine, with good security and a good list of junk files to exclude, a days changes are at most 1 meg, but only if I download a large file. And that includes my wife's stuff too. With an aggressive backup scheme, it really doesn't matter how big the disk is but how much change in data from day to day you have to back up. And it gives you a good opportunity to learn about your system by keeping tabs on this.
With that kind of strategy, MiniDV looks actually pretty good. Just use 2 mDVs with the same backups on each, maybe "Winter 2003 copy 1 of 2" and "copy 2 of 2". That will hold 13GB of _changes_ to your system, which is quite alot, and might actually hold a year's worth for some people. With the reduced cost, it might be worth a look.
Didn't the Apache project have an object database for storing XML object in native for and running queries? What was it called? It used to be right on the front page of apache.org, but I can't find it.
Is there anything comparable in the US? I have a cell-phone, and have thought about using it to get on-line (sort of a portable broadband connection), but the speeds available are either pathetic (like the 9600 baud from cingular) or the cost is obscene. Is there anything in America worth even looking at? I'm not talking about downloading 600 meg ISOs or albulms worth of MP3. I mostly want it so I can place my one PC wherever I want in the apartment with out having to tape phone cabling to the baseboard or shelling out money to SBC just to "activate" more than the one live RJ-11 port in my unit (in the worst possible place in the apartment of course).
Something faster that dialup but cheaper than DSL/Roadrunner and that would work on a NexTel motorola phone (one of those with the "CB-radio" chat function - I have an i30sx) would be ideal. Of course I could google for it (and have), but what do the rest of you recommend?
Spare 100 GB Hard Drives: $100 If you go with cheaper IDE drives, you probably aren't going to do hot swapping, so you'll have to bring the system down to remove them. SCSI would be more expensive, but would allow hot swapping. NAS is an option though, but slower. Drives are not meant to be carted around, bumped, etc like removable media is. One accidental drop and the entire backup is shot unlike tape or disc based backups. Really fast seek times though.
I like your post, but you forgot that modern EIDE disks support tunneling the data through another transport. So an ATA hard drive solution does _not_ mandate using an ATA adapter with 2 devices per IRQ in Master/Slave. You can mount an ATA disk using many other kinds of buses and gain hotswappability in the process. ATA bridges for USB, 1394/Firewire, SCSI, and even the parallel port exist and can be bought at Fry's. There are disadvantages, like USB's bad speed and reputation for unreliability, or Firewire's cost, or SCSI's device conflicts. But it can be done.
I _think_ SATA also supports hot-swapping drives, and there's a standard in the works for using USB for internal peripherals.
The big downside to ATA drives is storage. Even though head autopark now, they're still more vulnerable to crashes when spun-down. And if a drive mechanism is going to fail, the spin-up after the drive's been in your file cabinet for a year is when its going to happen, maybe due to a little stiction.
Sure, but with only 1 language, you lose the advantage that comes with heteorogeny (not having everything be 100% the same).
Because sometimes management buys systems without consulting the expertise they keep on retainer. Like a VAX. And then they say, port all your Ruby or whatever scripts to the new financials system and get it working so the VP can come see it working uh... when is he coming, Bob? Oh yeah, tomorrow. If you standardize on 2 or 3 languages, you're more likely to have some scripts whose interpreter installs painlessly and actually runs correctly than if everything has to run in one language. Then 30 minutes later you have something to bemuse the VP with, rather than slaving thru 8 mind-numbing hours of hell trying to figure out how to get the version of Perl you need to run on whatever monstrosity the department just bought with their end-of-fiscal-year money.
So to sum up, I agree with you: IT shops should standardize their scripting languages. But I think you create a situation where it's easy to get painted into a corner if you allow only one language to solve all your problems. It's too idealistic. Unless you work in a company where you actually have complete control over the IT setup or can do whatever you like in your own sphere, then you have to be prepared to adapt to the whims and decisions of others, no matter how stupid or dilbertesque they may be. Letting everybody use whatever they want whenever they want has obvious problems too, so 2 or 3 standard languages is a reasonable ground. Or if your LAN uses a lot of commercial software that only intergrates with native OS languages (like the command line on NT or Apple Events on old PowerMacs) then standardize on 2 "portable" languages that will run on most anything, and then whatever native language is most prevalent on the local OS (cmd.exe for NT, AppleScript for Macs, DCL for VMS, etc.) so your team will understand how to use them (rather that learning AppleEvents or CMD systax by reading the perl glue documentation.
As for programming vs. scripting -- the distinction is kind of worthless. You're supposed to be able to easily do both and use either one to facilitate the other. That was the basic point of UNIX. It was originally supposed to come with a C compiler so you could create your own compiled commands, and thanks to pipes, shell scripting in general, and the system() call it took very, very little work to write a complete UNIX command in C and just keep adding features. Then use your new command in your scripts and back and forth, ad infinitum, hypothetically getting lots of work done in the process (which, if you've ever used a public UNIX shell host, actually seems to be the case some times...)
The scripting vs. programmer schism is a hold-over from the Big Iron days when companies employed "programmers" to code or support in-house systems on their mainframe or mini. In the 80s, when most of those projects had gone on long enough to backfire, all the programmers got fired, companies started buying turnkey "solutions" from vendors to phase out their mainframes. Scripters were hired as sysadmins for buggy vendor systems or to represent the companies best interest in calling the vendor for support. Often this meant writing simple programs in scripting languages to solve a problem the vendor either should have solved in testing or refused to solve for less than a boatload of money when called on their "support" hotline. So programmers look down on scripters for what may be many reasons, but mostly they perceive us as just a bunch of dumb-ass, amatuerish scabs.
They're just jealous. To me, being on call means finding my cell phone under the bed and telling the operator "Ok, hit menu 5, then 3, then re-enter the name of the file. Yes, that's right. That did it? Ok, good night." and then going back to sleep for the night, maybe dreaming of a script to recognize the problem and solve it automatically without forcing the operator to call me unless it doesn't work. Meanwhile, programmers actually have to get out of bed and fire up the debugger, if they didn't spend all night at the office in "marathon coding" session. I guess I'm just too dumb to understand how much smarter they are than I am.
He threw _lead_ miniatures in the fire, probably painted with acryllics that may have had other fantastic ingredients. If he saw something a little crazy after that, he was probably downwind from the flames.
Or maybe he just handled the miniatures too often without washing his hands afterwards. They were made of lead (with some pewter). I remember my mom insisting when I first got some Ral Partha and Grenadier miniatures that I spray paint them first thing to put an enamel over the lead. I can't say if the propellant fumes from the chrome spray paint were any less harmfull than handling lead figures while eating junk food over a game of Stormbringer or CoC, but my other personalities all agree it was probably the right thing to do because Mother Knows Best. At least she let me play RPGs as long as I kept my grades up.
What's that Mother? Hit "Submit"? But I wanted to... Yes, Mother.
If your friend overuses the utterance "mmmkay", hit them in the eyebrows with a wrench IMMEDIATELY. A paperweight, fax machine, algebra text book, or any other solid, weighty, low-voltage object that's handy will do in a pinch.
/me ducks
If your friend objects to your linguistic intervention with cries of "Dude!", "Chill!!!", or "Mai Gawwd!", repeat administration of blows to the head until his outcries coalesce into complete English sentences, strings of proper Anglo-Saxon profanity, or unconciousness. Call 911, explain what happened, and the paramedics will show you the correct way to properly kick your friends ass should linguistic fault recurr.
DO NOT HESITATE TO INTERVENE. If you act now, you can save your friend from such humiliating future life experiences as the following:
DIVORCE: "Honey, I need you to properly rinse off each dish before putting them in the dishwasher, mmmkay?"
UNEMPLOYMENT: "So if you could just put the correct cover sheet on the TPS report and have it on my desk by Monday, that would be great, mmmkay??"
VIOLENT DEATH: "You young kids better turn that ganster rap music down, mmmkay???"
Remember, friends don't let friends talk down to others, mmmkay?
Yes. It's 50 million lines of QBASIC source code.
SUB BSOD (whatExcuse, howHard)
LET hellFreezesOver = FALSE
DO POKE (RANDOM(whatExcuse), RANDOM(howHard))
UNTIL (hellFreezesOver)
END SUB
Or something like that. Hm, that sounds like something an NT developer might say. Or a slashdot poster. I'd batter make sure I mispelld enough wurds before I give people the wrong impression...
Go to Ikea and look for the "Jerker" desk. Terrible name for a product in an English speaking country, but it's a great desk with lots of room. The have shelves, keyboard trays, cable organizers, and CPU holders (which are good for holding USB/1394 devices in a stack or your PDA/camera/cell phone stuff). They also have a rack of lights your can bolt under the top shelf for built-in lighting. You can also adjust the height of the tabletop, but you have to take the desk apart to do it.
Yes. So the "evil computer hacker" character can allude to its length in the next sequel to Jurassic Park.
Thanks. I'd hoped that given enough monkeys and enough typewriters that Slashdot wouldn't let me down...
Judging by the so-called "driving" of most BMWs I see on the road here in LA, a computer-driven surrogate brain might be of real use to them. Their own brain obviously isn't up to the job.
That reminds me of a gag I heard on car talk (Remember, kids: if you want to repeat a lame joke, just blame it on Car Talk or Slashdot and no one will question it):
Click: Say, knucklehead. Whaddaya call a sucker driving a BMW?
Clack: Hm, a sucker driving a BMW... Hey, wait a second! Isn't "sucker" and "driving a BMW" kind of redundant?!
Nobody spoil the punchline. I haven't heard this one yet.
No, it's because the term "OS" is commonly used to mean "OE" or "Operating Environment". Linux, being the kernel, is an OS. sh, and all the other shell tools are the OE. You don't have to use sh for your shell or init or any other shell tools, replacing them with other valid executables. A real world example of this is the FreeVMS project. In making a free/libre version of VMS, they don't want to duplicate the work of writing drivers and developing a kernel -- they want to focus on developing analogs of DCL, TPU, the Queue manager, etc. So they're using Linux or FreeBSD for their kernel and writing their own userland.
Same with Windows Explorer. The "My Computer" icon is part of Windows' operating environment. You can, believe it or not, use Windows without using Explorer (using the command line or a replacement shell like LiteStep). Windows just isn't designed or intended to have its core components replaced so easily. I think there was a court case about it... Anyhow, I used to run Windows NT with just cmd.exe as the shell, which was fun for a few weeks, figuring out how to set control panels from the shell. With cywin & GINA installed, you could put a nearly complete UNIX face on NT and still be able to run Win32 apps.
Sun is one the only companies I've seen distinguish between an OS and OE. They used to (still?) call it the Solaris Operating Environment, with the SunOS kernel as the underlying OS. The truth is nobody cares. _My_ eyes are glazing over just writing about this. My sincerest condolences to your disintigrating brain. But on the bright side, without the ambiguous use of technical terms, slashdot readers would have a lot less to argue about, and this site would degrade into a competitive festival of increasingly embarrassing personal confessions on sex, drug use, music, government secrets, scams, circumventing the law, satire, and other boring stuff like they have kuro5hin. If we should be so lucky.
Use the HELP command?
.COM files, and EVE is written in TPU which has text-oriented features. If you learned the shell syntax and the editor, then you're all set. Then you can edit startup scripts like LOGIN.COM and EVE$INIT.TPU to have all the settings you want to have all the time.
I disagree completely. The HELP command on VMS has good docs written in fairly plain english, and it is easier to browse than man. But a lot of VMS info isn't in the help/message system.
I'd focus on the manuals first, since they actually explain the concepts. HELP is mostly just a quick reference. VMS comes with a CD of manuals in HTML and PDF, and there's a web site as well with those. If you read off a screen faster than off paper, then there you go. I think SYS$HELP: also has txt copies of some docs, if they were installed.
You can also get a VAX emulator to experiment with. CHARON used to have a free version. The project that wrote the free PDP-11 emulator has a free VAX emulator too. You'll need the install sets from the tape or CD and a valid liscence PAK for VMS. If you "borrow" the PAK from a real VAX on your LAN, you may want to avoid experimenting with networking (besides being "illegal" -- gasp!).
As far as learning an OS quickly?
- 4 days isn't enough time. I say 7 to 30.
- Learn the shell and make a quick reference sheet of the sytax/commands.
- Learn the editor and do the same thing.
- Then learn how to customize the editor and do automation. EVE on VMS is underrated. You can write your own commands and maps them to keys, edit multiple files, run DCL from EVE and stick the output in a file, edit ASCII tables in block mode. And you can remap the keys. I have an EVE$INIT.EVE that leave all the standard/default keys alone, but maps all the standard commands like GET FILE to things like GOLD-O, etc. There's also EDT, but I'd learn just enough of it to be able to get out of it.
- Learn how to write scripts. On VMS you have @ and
- Learn how to multitask from the shell. On VMS, the commands you want are SPAWN and ATTACH. The trick is to SPAWN the program with a process name that you pick, the use attach to switch to it. From DCL, you can use DEFINE to map the ATTACH command to a function key. From programs like EVE you again map the ATTACH command to a key to switch back to DCL. Once you get the idea, you can do one-touch task switching between DCL, EVE, pine, lynx, NOTES, and you're own programs. Then VMS doesn't seem like such a typing contest to use.
- Learn the boot process of the hardware and OS completely. FE, on VMS the boot scripts set most of the logicals and symbols. People who don't understand this tend to think they can set symbols ad hoc, then reboot the VAX if there's a problem, and the symbol will still be there. Nuh uh. Sorry.
- Also learn how to "break in" by booting up by an alternate means. If you get locked out of a machine by a coworker or assume duties of a neglected box, it nice to know which manual the procedure is in than having to wonder if you can get in at all.
- Then learn how to find, download, and install freeware from off the net. No matter how obscure a computer may be, someone has written software for it, and someone else has a collection of it on the internet for you to download. You can learn a lot by trying to install new software on an OS. You can also fuck up your production system, so use an unpriviledged account on the test systemaa (after updating your backups first) and be careful. VMS was once the MS Windows of mainframes, and it did have viruses, trojans, and other malware.
- Try installing the OS from scratch, if you can. This is where an emulator rules. It dispenses with the need for a "spare" VAX to ruin, and emulators have feature that allow you to cheat. Often you can pause the CPU and scan memory for strings, or save and restore snapshots of the disk or the entire state of the emulated machine. Then you can try all kinds of reckless and stupid things without hosing the OS (just restore a snapshot). If you wanted to learn NT from scratch, having Bochs, VMWare, or VirtualPC would give you the same advantage.
- Last, learn how to use the built-in commands to write, compile, and run your own binaries. VMS usually doesn't come with compilers unless you buy them (I think) but MACRO assembly is standard. Most wouldn't go that far, but if you really want to learn an OS, learning how to write applications for it opens all the doors. Unfortunately, you really should know all the previous stuff first or you get stuck on simple things. Assembly may sound extreme, but it's absurd how much information you can get from a binary by running it through a decompiler. If you know enough asm to be able to look up what you need to know, then that's enough to get by.
I once had a VMS problem where a W32 client would crash when the user used a "Print Preview" function. A lot of spring cleaning had been done on the VAX to remove what the vendor told us were old, useless files that were safe to delete. Ha ha ha. Fortunately I had installed infozip a while back and zip'd up these "junk" files before deleting them. But there were no log or error messages that told us what was wrong with the client (it just Dr. Watson'd). I used cygwin to run 'strings' on the client exe, and listed in there was a pathname to one of the files we'd deleted. For fun I made an empty file with CREATE on the VAX with the same name, and like that the problem was gone. The client only tested for the existance of that file, but didn't actually need its contents.
I've used the same basic steps to learn several platforms: Macs, Solaris, NT, DOS, Linux, etc. People get superstitious around computers. even experienced people. It'd be no different on other wierd architectures, like an AS/400 or a old 8-bit PC from the 80s. It's mostly just process of elimination.
Dave Roth, a Windows consultant and author of several extensions for Win32 perl, wrote a paper on managing a WAN of NT machines, most of which can apply to W98, if you do some testing:
d . pp t
http://www.roth.net/conference/lisant/1999/
an
http://www.roth.net/conference/lisant/1999/NMMS
There's an old Mac program called RevRDist from Purdue that uses the same strategy. It might give you some good ideas, even if it's not for Windows. Another good site is on this problem in a more abstract way (centered on UNIX):
http://www.infrastructures.org/
The basic trick: use login scripts. Don't think that this won't help you if your LAN can't force people to actually log in to the PCs they use. Where Roth's idea is better is that he uses 1 special login account to install batch scripts scheduled to run everyday at specific times. The batch script runs scripts off a read-only share, so saving new scripts to the share you can do automatic updates on all machines every 24 hours, including updates to the scheduled batch scripts themselves. Your staff only has to "touch" each PC once by loging in as the special account, and there after everything is automatic, depending on your ability to write robust, correct scripts and do proper testing.
As for remotely installing OS patches from a central PC? Are you totally MAD? Any feature you can easily use to remotely change a computer can be used by a hacker or worm to adversely "update" every PC on your LAN. It doesn't matter if the so-called white paper says it's secure. Internet worms are more serious problem these days than ever, so give security serious thought before you deploy, no matter what solution you decide.
Just because you switch your network to Linux doesn't mean you can't run Windows software. Even assuming all client PCs run Linux, you still have options:
Run ONE NT/2000 server just to serve up the accounting and connect to it via:
- ICA/RDP clients (buy appropriate CALs!)
- A browser (for web-enabled accounting apps)
- VNC (just kidding)
Or run a Win32 or DOS program right on Linux for i386:
- WINE or DOSemu
- VMWare or Bochs
Or buy a UNIX accounting turnkey system and connect to it from linux using X, telnet, ssh, browser, or whatever. Take a look at the offerings for Solaris, AIX, Tru64 and HPUX. Accounting vendors for these commercial UNIXes may already have a Linux version for sale. Then your manager's fears will be appeased since it's a "real" accounting app you're recommending.
This is an old idea. "Poor man's clustering" is what they call it.
;-)
The essential trick that you may not think of yourself is to set the SCSI ID of the 2 SCSI host adapters to _different_ SCSI IDs. Most people forget this. Remember, the PCI SCSI you use takes 1 SCSI ID in the chain, even if it's on the motherboard. So if you connect 2 PC to the same SCSI chain, the ID of each PC's SCSI adapter needs to be different, otherwise it's no different than having two hard disks both set to ID 3.
2nd, make sure you terminate both ends and put both PCs inside the termination.
So your chain should look like this:
T-P7-6-5-4-3-2-1-P0-T
Where T is a Terminator, a number is a SCSI ID, and a P designates the SCSI adapter in a PC.
Good luck, and make sure you have enough goats!
I'll second that. I've seen the AC fail in a server room, and the temperature climbs with every passing minute as hot as you let it until you improvise some ventilation or fix the AC. A colder room buys you more time to do either before the heat starts damaging equipment or causing CPUs to lockup.
I worked in a cold server room for a time and had the same problem you did. I understand where you're coming from. Being too cold to type is the least of your worries. You could catch a serious cold if you follow the contagion with a couple hours spent shivering in the server room.
- Find the drafts in the server room and reposition yourself so you aren't directly in its path and avoid the "Wind-Chill Factor".
- Double-up your socks.
- Wear a t-shirt under your dress-shirt, which will layer your clothing.
- Wear a hat in the server room. Keep the hat in your bag or pocket at other times. Scarves work too and give you that Tom Baker idiot-savant look.
- Go to a store that caters to hunters and buy some thermal underwear. The good kind looks more like medieval tights than that white pleated junk they sell at K-Mart. BE CAREFUL: when wearing thermals, you build up a lot of static electricity. Pay attention to ESD.
- Shiver while you type. The motion will raise your body temperature a bit.
- Eat something with a lot of calories before going in the server room. Metabolism creates body heat as a waste product.
- Drinking hot liquid doesn't work. The warmth doesn't last, and it makes you have to pee. But hey, whatever gets you out of that freezing server room, right?
- Gain some badly needed weight, pal. Cold doesn't bother heavier people as badly. Score some Carl's Jr. coupons and get to work.
If you're still cold after all that, then yes, maybe the room is too cold. But probably it's not, and the client is moderating your complaints as "Whiny" and "Wuss". Just quietly solve the problem on your end and protect your own health, and then you won't need to bother your clients with "I can't work under these conditions!!!"-type complaints.
ACARD makes a series of SCSI-IDE bridge cards which connect to the SCSI chain on one side and an ATA hard disk on the other. They have several models, mostly depending on what type of SCSI cabling you have, costing from $50 to $80. They support large ATA disks, the cost of which plus the $70 for the bridge is still cheaper than most SCSI drives. If you don't need the warranty and physical traits of SCSI hard disks, but you want to be able to hook up 6 drives to your PC with only 1 IRQ and IO address or add 60-80 gigs of space for under $200, this might do the trick. They also come in handy for old workstation-era machines, like PowerMacs, SparcStations, or VAXes. The bridge doesn't require any drivers or software to work, since it just tunnels ATAPI and makes the IDE drive look like just another SCSI disk in the chain.
http://www.acard.com/eng/product/scside.html
Microland sells them in the US:
http://www.microlandusa.com/microland/
Some downsides:
- The hard disk has to be formatted while cabled to the SCSI-IDE brige. You can't move a drive from a regular IDE controller to the SCSI-IDE bridge without getting geometry errors.
- The interface is ATAPI only, so not all commands for the device may work. FE, firmware updaters and vendor utilities designed for the hard disk probably won't work the bridge.
- The utility to update the bridge's firmware is only for DOS/Windows.
There will probably be LVD-SATA bridges too in the future, if SATA truly catches on.
The answer is "Yes". Followed closely by the answers "Sorry!!!" and "Consider upgrading your system to Microsoft Windows FU."
Yes. http://www.netbsd.org/.
Why ask? All you have to do to restore his Mac is drag it out of the trashcan.