If you think a laptop will be money well spent towards getting a quieter computer, I think you'll be disappointed. I do a lot of service on PCs and laptops, and I've been repeatedly surprised how loud the laptop's really are -- almost a bad as a PC, if not as bad.
I suspect the noise is from MTBF of fans and hard disks. It's true that some models of hard disks and fans really are quieter or louder than others. But take two PCs of the same model with exactly the same model parts and one will be louder. A fan can get dirt in the bearings, spin unevenly, or vibrate in place, all causing irritating noise. Everyone's experienced a hard disk that works just fine but has a piercing, tinitus-inducing whine, which usually gets worse over time. Just like when you a buy a PC, there's a certain chance that when you buy a laptop that you'll get a noisy one, and you'll either have to swap the guilty parts yourself, experiment with accoustic matting, or come up with a good excuse to exchange the noisy laptop for another of the same model and hope lightning doesn't strike twice.
Now if you want your laptop to get _noisier_, just move it around a lot while it's powered on with the drives spun up and be sure to place next to a pile of dust-ridden papers. Bump, move, or shove the desk the laptop sits on as much as possible. It won't take long...
If you want permanant lasting quiet, get a handheld PC, like a Psion or a PocketPC. They're certainly not as good as a "real" PC or laptop for the money, but they are _totally_ silent. The only sound mine makes is a slight hum from the backlight, but I have to put my ear near the screen to notice.
When you say you hope we're up for another format switch in PCs, I think you're right. DoC sockets are becoming common on motherboards. CompactFlash cards are getting bigger and cheaper. USB 2 is adequate for connecting external hard disks. I suspect PCs are going to become more and more solid-state, but not for good reasons. I think Microsoft is going to push for the core of their OS to live on a DRM-enabled, read-only flash that requires digital keys to modify. Sure it will be cracked in a week, but I think the current X-box vs. Linux charade is just a rehearsal. Their using it as free research to see if it would work for PCs. Eventually PCs are going to become so powerful and so cheap that the threat "Buy a new computer!" if you want to upgrade your version of Windows will be like ordering someone to spend $50 to double the gas mileage of their car.
Let the funny Microsoft/Automotive metaphors begin.
Sun sells one. I think the name is "Sun PCi". It's a PC on a PCI card. $500 last time I checked, and no open drivers (Solaris on SPARC only), but that could change. Orange Micro used to sell PCs on PCI cards for Macs.
The reason you're getting swamped is because _you_alone_ wrote and understand the code, so _you_alone_ are the sucker stuck maintaining it. Don't fall for this. Use the "buddy system". Involve a co-worker in every project you do, whether they're willing or not. You don't have to join the extreme programming fad. But just share what your working on with a co-worker, so they have more than a passing idea what you've done. Then return the favor. Take an interest in your co-workers' projects and learn how they work. Then when something breaks on your co-worker's project when he's out sick or on vacation, see if you can solve it without bothering him at home. Eventually, they may return the favor when you're trying to get some downtime. And if they don't reciprocate, then you've learned your co-worker is a worthless fool, if you didn't know that already. Find another buddy then. It's basically the same idea as what managers mean by "cross-training". But if your manager was doing any cross-training, you wouldn't have this problem. So don't wait for your manager -- ban together with your peers, and fix it among yourselves. If some of your co-workers also don't/can't pull their fair share of the workload, teaming up on projects will throw that into high relief. Not that I've ever seen anybody get fired from an I.T. job for being too dumb or unwilling to learn to read/write simple scripts, but you could get (un)lucky.
2) Automate every stage of your work with scripts.
Get a scriptable text editor. Write macros to generate comments, common loops, subroutines. Write scripts to version/revert files, run them in a debugger, build executables, make notes about progress or bugs, insert date/time stamps, call up the manual page, etc. Use script or templates to generate new source code files, so that 99% of what you need is there. Many IDEs do most of this already, but you may not be using all the features. Or if you notice a feature that you're IDE lacks, write a script to add it in yourself. And share your scripts with a co-worker who's likely to share his scripts with you. After a while you should be able to create and maintain project with a series of single keystrokes and copying/pasting. Adding and testing new features then becomes much less of a frantic typing exersize, letting you focus on getting the solution right.
The Sam & Max adventure game was based on a comic book entitled "Sam & Max: Freelance Police". They basically roamed the world, pretending to be police officers/P.I.s and solving whatever crimes they stumbled on. Usually with violence.
I was (un)lucky enough to find a color issue of Sam & Max in the bargain bin of a comic book store while looking for back issues of Grendel, The Elementals, and Groo the Wanderer. I think I paid $4. It's the most dangerously funny posession I own. I keep it safely packed away out of sight, because I can't read the damn thing without laughing so hard it brings tears to my eyes.
The comic was drawn pictures first, and then the dialog was made up after the fact. Kind of like Mad-Libs, or the heckling on MST3K. If you like the Simpsons, you might like Sam and Max. Groo the Wanderer is good too, but it's funny the way Mad magazine or Cracked is funny (or isn't) -- mostly corny jokes.
Compare for yourselves: --- Groo: "I'm hungy. Aha! Groo smells smoke! Where there's smoke, there's fire. Or a village! Or a village on fire!!"
--- Grateful Stewardess: "Thank you for saving our plane! How can we ever repay you?"
Max: "JUST GIMME ALL THE NAKED WOMEN MY POOR EYES CAN STAND!!"
Sam: "Easy, Max. You don't even like girls." ---
Luckless Villager: "Who be you?"
Groo: "I be Groo."
LV: (aside) "We are doomed..."
--- Max: (a naked, yet fuzzy Max produces a 9mm pistol from thin air)
Sam: "Where'd you get that gun, little buddy?"
Max: (grinning) "None of your god-damned business, Sam. Tee-hee."
---
So if you liked the game, you might be able to scare up a copy of the comic book and see where it all came from. I don't there were ever many issues released, maybe less than ten. I get the impression they're fairly rare, unless they've gone into reprints since then.
It's not an OS. It's an OE, an Operating Environment, like GNOME, KDE, or CDE. That's why they named that particular string of vowels, thinking they'd made a clever pun. Ew.
I'll say it again (if only because I've said it before...) at least they saved millions of dollars by not hiring a naming consultant.
OSS is going to win the desktop war by being increasingly less pronouncable than the competition, greatly limiting the opposition's ability to spread FUD in COMDEX keynotes and by word of mouth. When criticism of your product is met with shocked replies of "What the hell did you just call me?!" or "Do you kiss your kids with that mouth?!" then you know you've correctly named your OSS/Linux/BSD/GNU-based product. It uttering your product's name aloud causes Satan to spontaneously materialize in a <BAMF>cloud of brimstone</BAMF> or motivates Chuthulu to wake up a few eons early, then you've got a killer app on your hand. The moment your competion dares utter your product's name, they'll all die screaming as hideous supernatural creatures suddenly appear in their board room meetings and devour all the executives, and you'll gain valuable mindshare with the Old Ones! The-product-whose-name-must-not-be-spoken is FUD-proof indeed, so long as you can train your staff to only converse about the product in winks, head nods, and hand gestures. Except, of course, the employees you want to "let go".
Yes, it's needed. And it's OK if the reason isn't blatantly clear. The NetBSD crowd is very much anti-hype. So a lot of its features aren't done to be cool, impress OSS mavens, make any headlines, or even to allow stingy people to avoid paying for commercial software.
NetBSD is a research OS. See: http://www.netbsd.org/gallery/research.html
NetBSD itself isn't a research project per se, but a baseline OS for conducting generic computer science research, whatever kind of research that may be. So, if you want to do your Comp Sci PhD on a revolutionary new implentation of virtual memory, use NetBSD. You don't have to waste any time writing your own OS, and NetBSD will run on almost any 16+ bit computer you can find. That old Sun, DEC, SGI, PowerMac, or wierd PC clone can become your test bed or workstation, and it just might support more hardware than the original OS. (Nowadays, you'd probably do better to buy/get a slightly obsolete PC, but for some projects old gear has advantages, like SCSI, RISC CPU(s), good SMP, a quality real-time clock, better hardware security, etc.)
For example, if you find bought/found/stole a Sun Ultra, Dec Alpha, or a PowerPPC box with PCI slots, you will have a much easier time getting almost any PCI card to work with NetBSD than with Solaris, VMS, Tru64, AIX, or MacOS X/Darwin. You will have to learn to like those two little words: No drivers. Or learn to write/port your own. Hey, it beats getting any real work done on your thesis, right?
Not to mention, you may not have those OSes laying around, or the cash to buy them, or the time to wait for the vendor to mail it to you (ahem, Sun?). Or the patience to put up with the BS required to qualify for a "hobby" version (ahem, HPaq?) that only allows you to use OS in what is essentially single user mode and has a license key that will expire annually, and will need a new key (annually) that will require you to reregister with company, even after the company ceases to exist.
<SARCASM>What a great deal!? Now I can fire up that microVAX in the garage and type my letters in EVE! At long last!!! Honey, shut down the NT box for good, cause we've found the way out!</SARCASM> And they wonder why the hobbyiest version of VMS hasn't taken the world by storm... Sheesh.
This doesn't have anything to do with whether Linux makes a good research platform. Lots of good, pure research is being done with Linux too. But Linux requires a little up-front work on your part before you can work on your original project (especially bootstrap or installation issues on non-x86 platforms). I've found installing NetBSD to be an almost trivial undertaking compared to Linux or even Windows NT. It's so distubingly straightforward, it should say so on a bumper sticker.
There's a lot of cool features in NetBSD that just came about because of basic computer science research. Binary compatability is one of them. It's just an experiment into finding ways to make the OS more useful. If it would be more useful than less for NetBSD to be able to run binaries from a platform's vendor OS, then that's exactly the sort of thing NetBSD should be able to do. That's why.
First off, let me say I'm glad they didn't blow a lot of money on a naming consultant. That ugly acronym they settled on must have saved them millions of dollars...
Soundtracks, film scoring, and even some album production is being done increasingly on DAWs, pronounced just like it's spelled. A typical configuration is a tricked-out PowerMac (Sun Ultras used to be the platform of choice) with maximum RAM and a fast RAID array (i.e RAID 0 -- don't laugh, I'm not kidding. RAID 0 is used to lower latency on the drives) and a MIDI adapter, for both driving sound modules and inputting music on a master keyboard. Add a copy of ProTools, some Mark of the Unicorn software, a DAT drive, a CD-burner, a mixer, some rack effects, and maybe a high-end audio PCI card for when you hit the limits of the Mac's decent but not that great on-board audio. This is not a sub-$1000 iMac rig were talking about here. If you want a good DAW, you go to the bank in your best suit and tie and apply for a loan.
Of course this makes no sense to an amatuer composer/musician. You might ask what's wrong with a stock PC with a good sound card, a quality microphone, UltraATA disks, a MOD Tracker with WAV/MP3 export, any old MIDI synth with velocity-sensitive keys, and CD-RW/DAT drive? Nothing really, if you want you music to sound like it was created on a computer. But that's not what a real DAW is for.
A DAW has to be _FAST_. The software used (like ProTools) is used to edit and master a gigantic audio file of CD-quality sound. Document sizes are often routinely in the gigabyte range, unless you're just editing small leadins for TV or commercials. You can use MIDI and samples to provide voices in the soundtrack, but the goal of a DAW is to have total control over the audio in the file, just like you have over a photo in Photoshop. It should be just as easy to work with a "real" audio recording (like a studio session recorded with a real orchestra) as it is to use sythentic music (samples from a microphone or synth, MIDI sequences, etc) and tweak the finished product to sound completely natural, as if real musicians had played it that way start to finish in the first place.
So any latency you have in the DAW can put skips or glitches in your recorded input. You need a workstation with enough RAM to avoid paging, fast disks that don't cause the CPU to have to wait (DMA/SCSI), and good all around performance to prevent bottlenecks: fast OS, fast graphics, fast CPU, fast audio chipset, etc.
Linux is perfect for this, because comparatively MacOS 9, MacOS X, and all versions of Windows except CE are complete pigs. Linux just lags in solid support for audio input, mixing, MIDI, and audio applications, etc. the way Macs and PCs do.
This distro isn't something you sell to end users (though they may) but to OEMs and VARs who want to sell Linux-based DAWs but want a vendor for the operating system beside Apple, Microsoft, or Sun. Other people have mentioned how poor musicians and DJs are. If you could make and market a Linux-based DAW out of PC parts with comparable performance to a ProTools rig and a substantially lower price, you could make a place for yourself in the market and do pretty well. Anything in the music equipment world that is both "really good" and "pretty cheap" and word gets out. Selling distro CDs just raises money and hopefully creates good PR for the concept of Linux as a good enough OS for a DAW.
The Azza motherboards we get from ACS come with StarOffice CDs (only Windows is pre-installed on the PC). Not that we use the CDs, but some of the beige-box assembly houses are shipping StarOffice.
This is what decompilers and the strings command are for. You'd be amazed how much you can learn about what a binary does by running the.exe through a decompiler and just leafing through the symbols. You might think most apps strip all useful symbols out, but it's not true. You can have yourself an old school literate programming session and leaf through the binary code like a book, if you have a few assembly references handy and limited understanding of addressing modes.
So even if the file is.exe, it's not like you _can't_ ever know what it will really do when you run it. You just need some time, some tools, some brains, and some nerve.
And tea is a good middle-ground between soda and water. No jitters or stomach problems like people get with soda or coffee. Ironically, it's cheaper than either, as long as you don't buy the overpriced yuppie-oriented brands like you see in coffee shops. You're talking about bottled water, right? People drink everything but tap water because most tap water is disgusting (whether or not it's any different than what you get in a bottle). If you live where the tap water is clear, clean, and free of clorine, you're pretty lucky.
If you're addicted to caffienated soda or coffee, you can wean yourself off of it without the withdrawal symptoms (bad headache, being disoriented, mood swings) by switching to tea. Two tea bags, 1/3 cups of sugar, some lemon or lime juice (very little), and a quart of boiling water in thermos makes something as powerfull as Mountain Dew. The sugar thickens the mix to get a similar consistency to uncarbonated soda. I used to make tea so strong that it scared my co-wokers who tried it. If you learn how to do it right, there's nothing weak or bitter about good tea. I've backed off on it to a more conservative recipe, but it's something that's cheap to experiment with. It's true you can make a tea that's as bad for you as soda or coffee, but there's nothing stopping you from adjusting the strength of it over time, which you can't really do with coffee or soda.
Don't leave the tea bags in more than three to five minutes (it varies with how hot the water is and the container) or it will be too bitter. Or get an iced tea recipe off the web. Or just pour the tea (after it's brewed for 5 minutes) into a metal or glass pitcher and leave it in the fridge overnight. (Rubber or plastic pitchers leave an aftertaste in the tea). For cold tea, you can make huge batches in advance on the weekend with little extra effort (making tea is a procedure that "scales up"). Adjust the ingredients until you find a mix you like, as the proportions make a big difference in the final product.
You can save a lot of money over time this way. I think I was losing an easy $2 a day on soda. I did the math on what it costs to buy tea, lemon juice, and sugar, now that I've bought the thermos, it's less than 25 cents a day. I don't know if you can get bottled water that cheaply (because I hate the plastic taste in bottled water). I don't find tea as addictive as soda either, so it's not like you're trading one craving for another.
For your vending machine, think about making a hot water tap available for people to use, and maybe an ice machine too. That way they can make hot or cold tea at work, if they don't want to or forget to make it at home. Some places go so far as to supply the tea bags and sugar, but it doesn't sound like you can do that.
You've never owned a 6400 or a 6500 then. The CPU/PS fans are so weak, the Mac tends to lock up on hotter days. If you look on google, you can find entire web sites devoted to publicising the problems with these machines. They were cheap, but IMHO not worth the trouble.
And the 6400/6500 case is anything but "easy to open". You need a special tool (a case splitter) -- otherwise you have to nearly rip the calluses off your fingertips (after your fingernails go first) straining to pull the front off. When you hear the sudden, loud CRACK sound, loud enough to suspect you broke something, then you've got the front off.
Like a lot of pre-Steve macs, the fasteners are all made of plastic or very weak metal, so unless you go carefully, you can easily break a Mac case where it will never close again properly. The PowerPC cases are great examples of the this. Everything, from the card guides for the NuBus cards to the tabs that hold the motherboard in place are made of very fragile plastic. If you're ever working inside a Mac made from about 94 to 99, be careful!
Macs have this ridiculously undeserved reputation for having great cases that are easy to work with and won't cut you. This is pure hype. The aluminum flashing inside a Mac case as RF shielding tends to get bent up as you open and close the case and is hard to straighten. I've been working inside some PowerMac and said to myself "Hey, what's that little maroon bead on the motherboard..." before I realised I was bleeding. On the upside, the shielding is sharp enough to make a clean cut.
SOME macs do have good cases, but most do not. Most require special tools (like torx wrenches) and a reasonable understanding of electronics, especially the Macs with built-in monitors (like not electrocuting yourself on the CRT). The recent macs once Jobs was back at the helm have much, much better cases than almost every mac that Apple ever made. If you have basic PC building skills, than a post-iMac era Apple machine should make you feel right at home. For all the earlier ones, read up on the specific model before you do anything. They're no worse to work on than cheap clone PCs, but they have their own unique gotchas that are sometimes so wierd, proprietary, and/or dumb, it's best just not to guess.
Apple kind of runs under this idea that the computer they are selling you is actually an _appliance_, which should run reliably as designed (not that it will). But if it doesn't, you're expected to "take it to the dealer" and have them fix it, like a car or television (which nobody does, because you'll get ripped off or have to bring it back multiple times). That's the only way they're managerie of case designs make any sense, is if a trained Apple Service tech is the only one whose ever supposed to open it.
I wouldn't buy any mac unless I already had the directions on how to open it up and work inside. That will give you an idea how many proprietary plastic parts you might have to buy from Apple for $10-$40 each if you muck around inside. If they're still available. That's what I advise people who ask me advice about what mac they should get, especially for people buying used macs.
But their Macintosh-using friends (c'mon, everyone knows at least one of them) will be constantly singing praises such as "_my_ computer doesn't tell me that those media files are protected".
No. You're right that Mac users will take DRM as an opportunity for a little evangelism. But Microsoft's plan is to lobby Congress, probably under the veil of another media group (like RIAA), to mandate that all computers sold in the US will required hardware and software compliance with DRM. It would not be impossible, in this new era under UCITA, for them to attempt a retroactive mandate, where even the computer you currently own has to get a PCI/ISA card and a OS "upgrade" to add DRM compliance, especially if you make it illegal to connect to the internet without DRM compliant gear. The Information Super Highway Patrol will pull you over and make you recite the ASCII character set backwards or get a knock on the door from your local jurisdiction officials for a little "inspection" with all kinds of probably cause. Of course it's a stupid idea for all kinds of good reasons, but that's never stopped lobbyists or ambitious politicians in the past.
You might as well say, don't use any networking on these macs, because the builtin ethernet is so slow. It is -- that's true -- but without ethernet the machines are much, much less useful. You don't wan't X on these because it will run well. It will not. He'll probably be lucky to get 640x480 at 8-bit color. But with only the console, it limits the number of apps he can realistically offer users, unless he wants do code everything with cdialog, pilot, or ksh "select" menus.
Because this is a _migration_ to linux, the users are going to know squat. He'll want X so he can offer apps that anyone who knows how to use a mouse can figure out (provided he puts in the preparation to configure the X resources and windows manager before hand so everything appears to be "just there").
Also, console apps will remind people too much of DOS. It's a PR thing -- people will see it as a step back, not forward (even though, as you and I know, Linux is much better than DOS). If a decision-maker see these macs and makes the association with DOS, he could kill the whole project. I remember what it was like supporting VMS terminal apps, like PINE, EVE, NOTES, and LYNX. These are great programs, but too many people just don't get the idea. You'll lose hours and hours hand-holding people through console apps who could otherwise use a browser all day without ever bothering you for help.
Without X, you might as well toss all these macs in the garbage and buy 100 dumb terminals from Boundless. You can buy them in bulk for $80 each, and they'll be alot less hassle to maintain then PPCs with a linux booter that depends on a working MacOS partition to boot up.
A FILE server, serves files. XServe is not a web server, or a mail server, but it can do those things. As I
said before, in a lot of very large print companies, all live jobs are on a central file server. So you log
in and open these files off the server. They might be huge 900 MB TIFF files, or a QuarkXPress file with
many EPS and TIFF files in it. This is real world, day-to-day work for people like my self.
If you worked in my production department and opened an 900 MB TIFF file from OFF THE APPLESHARE FILE SERVER I'd probably fire you.
Macs come with 60 gig ATA hard disks now. How dumb can you be not to copy the file to local storage before editing it? Real publishing houses also use OPI servers to generate lo-res placement files (FPOs) so they can edit the pages at screen dpi (72-96) and have the changes reflected on the RIP at press dpi (1016-4800 dpi) with the burden placed on the OPI server to merge in the hires (not your mac). Distiller also works well to reduce ridiculously huge graphics to a managable PDF file without much visible loss in quality (with the right Distiller settings). Most apps will let you place a PDF in a document and do operations on it, just like an EPS. 1 MB per color layer at 1200 for a newspaper page (13x22") seems to be about average at the two newspapers I worked at. Much easier to work with. You might find your work goes a little quicker.
I used to admin a college lab of these macs -- about 80 6100/6x, some 7100s, and some much, much better 7600's and 7300's. When MkLinux was first announce on the net, I snagged an abandoned 7100/66 and a spare 2 gig IBM hard disk (Thanks, Carl!) and installed MkLinux as fast as the school's T1 could get it in the building. I had this idea I could use the 7100 running netatalk to liberate my side of the lab (the mac side) from our NT file server (which wasn't a such a bad server, but SFM had some killer bugs that the service packs hadn't fixed, and I wasn't in charge of applying fixes to the NT box). But when it became obvious I was going to have to spend every waking minute of my life tweaking this new toy to make sure it didn't crash during finals week or get hacked by one of the students (I was pretty new to UNIX at the time), I shut the 7100 down and tabled the project. In retrospect, I kind of wish I'd spend more time on it. But knowing what I know now (i.e. knowing now how much I didn't know back then), I'm glad I didn't do something stupid, like make every mac in the lab rely on the MkLinux box for some network service.
So I know a little about what you're about to go through.
First, you need a Linux distro that supports Nu-Bus, because those macs are not PCI based. MkLinux will work. NetBSD, amazingly, will not run on these macs. That should set off red flags in your head. You're venturing into unsupported hardware territory. Expect that some hardware won't work AT ALL. In preparation, read through the Linux docs for whatever distro you find that supports NuBus macs and write down all the hardware that is reported as unsupported, alpha, buggy, or problematic. If a component is unneeded (like serial ports, sound in general, or audio input) then just don't use it, and maybe look for a way to remove or disable that device in the kernel. You really only need support for video in X, the mouse in X, the keyboard (especially mapping keys), and ethernet. Forget about sound, and I wouldn't be surprised if the floppy drives only work for booting, but not once linux is up and running. Maybe you can pass that off as a security "feature".
Second, you need to account for the fact that these macs are not fast. 6100's are barely quick enough to call "slow". The less software you install on these, the better. If it were me, I'd set them up as thin clients with X, a browser, telnet/ssh, maybe java, maybe a few helpers for the browser, and that's about it. Run everything else over X hosted off a better machine. If you have a few faster macs with a 604 or better yet a G3 or G4 (not a 603) consider reserving it as an X host for users to log into with XDM. Ideally, you'll want two or three machines for failover or a hot spare. If you have a more modern mac as an X host, you can run RedHat, NetBSD, SuSE, or even MacOS X (I suppose) on it, and the X clients can run software from it over the network. Just give the X host plenty of RAM, fast ethernet, and SCSI disks, and it should be fine. Also, the less software you install on the 6100 as a client, the fewer bugs you'll have to deal with where software XYZ doesn't run properly on the 601 due to some bug in the PPC targeting code of gcc.
Third, you have to prepare for the unique "features" of the Macintosh platform that are going to get in your way. You'll need a boot-loader that runs from the MacOS because these macs lack OpenFirmware. PCI macs at least can boot other operating systems by finding a boot-loader on any HFS, IS0-9660, or FAT partition. Your macs will each need a bootable HFS (MacOS) partition with just enough MacOS to run the linux boot loader (usually an extension), with maybe some ResEdit hacks to keep users from bypassing linux on bootup. Once your users get into MacOS, all security is gone and they can do whatever they like, including erase or hack the linux partition (using ext2 utilities). I would use a tool like RevRDist for the Mac side, so you can master the HFS partition from any AppleShare server (or netatalk). Then use rdist or rsync on the linux side in the start up scripts to master the linux file system from a server. Use the Apple "Network Access Disk" to jumpstart the whole process from a bootable floppy. If some genius hacks the bootup sequence and reinstalls MacOS (which they will, because MacOS unlike Linux will let them do whatever they want without ever a "permission denied") you can remaster the whole mac just by rebooting from a read-only floppy and running RevRDist from the server share. You should also should figure out what you're going to do about mouse buttons. You probably only have 1 button mice. The X Window system likes 3 buttons. The standard workaround is option+1/2/3 to fake that mouse button with the keyboard. It will take less than 60 seconds of that to either fuck up your hands or just plain drive you crazy. Use xmodmap to remap buttons 1, 2, and 3 to some single keys, like/, *, and - on the number keypad or something. Or look at the price of 3 button ADB mice and multiply that by the number of macs you have...
Basically, don't make it up as you go along and expect to get lucky. It's not going to happen. With a little thought and preparation, you should be able to automate everything and have maintenance-free LAN of semi-decent thin clients/X terminals that just happen to show a "happy mac" when they (rarely) boot up. And when you see how fast Linux runs on a 6100 compared to MacOS, you'll probably be smiling too.
You'd better not be trying this in Washington at a public school. The state has a policy of what state-purchased computers can be used for. Game playing is explicity listed as forbidden. I don't remember exactly, but I believe it could even be a felony.
We wanted to do LAN games at our university lab to raise funds, but our boss was quick to remind us that if a single administrator found out about it, we could've all been expelled.
So, you can have LAN gaming parties in Washington at a public school, but it has to be kept absolutely secret and unofficial. Just don't hurt anybody while you're breaking in to the building.
This topic was on slashdot once before, and I posted this back then as well. Miguel Freitas of Brazil got this working on his linux PC: two monitors, keyboards, and mice, served by seperate X servers. Long story short, he said performance was adequate supporting two desktops simultaneously. Using PS/2 devices for one console and USB devices for the other prevent/dev name ambiguities. The text is mirrored below with the URL at the end if you want to want to get the HTML.
This may also be possible in NetBSD if you use wscons to configure two discrete muxes and start a different X server on each one. Can anyone from core or Wasabi comment on that?
---
Multiple local XFree users under Linux Version 0.92 by Miguel Freitas
Updated April 4, 2002
You can always get the latest version of this document from: http://cambuca.ldhs.cetuc.puc-rio.br/multiuser
Keywords (for bots)
I've wasted a lot of time trying to find this kind of document in google, hotbot and so on. Let me add some keywords to help people finding it: true dual-head, multi-user support, XFree86 4.0, multiple keyboard, multiple mouse, multiple video card, dual user, XFree86 instances, dual keyboard, USB keyboard under X.
Motivation
I have one girlfriend and one computer. In normal conditions, we both couldn't use the computer at the same time, in spite of the fact that it usually has a lot of processing power available. I also have a spare monitor and a second video card for playing 3D games (voodoo) so this idea came to me as something very obvious. New XFree86 4.0 support for dualhead suggests that most of the hard work is already done. And it has to be on Linux, because no closed source OS would allow me to make the changes that I need.
As several reports confirm, Linux is been successfully used in educational institutions and projects due to it's great benefits and low cost. Using the same computer for two (or more) simultaneous students, workers, etc. is something that can reduce even more these costs.
This is also a great option for companies to simplify the management and upgrades of the shared resources (motherboard, processor, hds).
For everybody who may be asking: don't it get too slow? No. The performance difference is barely perceptible as most of the time the computer is waiting some command from the user. And if you haven't figured it out by yourself let me tell something: we live in a time of computing power in excess or do you think most of the users needs a GigaHertz Pentium 3 machine just to do their word processing and surf the web?
Problems
There are some problems that need to be addressed in order to support multiple XFree instances (and users):
VT handling - The Linux kernel Virtual Terminal scheme is a great hack these days. It used to be good in the past as a way to have multiple screens, but now it's something that needs to be completely rewritten (several Linux developers have shown interest in developing a better scheme for 2.5.x series). The main issue is that VT code doesn't understand that we may have multiple input and output devices which therefore may be completely independent. There's no way to associate a given set of VTs for each hardware so Linux kernel would know which VTs can be used simultaneously. If we dispatch multiple instances of XFree86 they would be on different VTs and the Linux kernel will inform them of all VT switching stuff. A switched out (graphic) VT must not use the hardware as it would normally mess with the other active VT, but this is no more true as we have two independent video cards. Keyboard support - Multiple mouses on X are already a reality as we may specify the "device" option for each one. Unfortunately, the keyboard driver is still deeply rooted at XFree86 core, it's not a separated module and access console I/O functions to read the scancodes. Each XFree86 instance would have their keyboard access halted by VT switching. Besides, Linux is still lacking support for multiple keyboards in a well defined way. Let's wait for 2.5.x tree to see what will be done... My solution My hack is surely not the best one, I know thousands of things that could be better implemented in XFree86 and Linux Kernel to support true dual-head (and dual-input) in a clean way. But it works for me. Don't blame me if you spend your money and time buying videocards, monitors, keyboards, mouses and it doesn't work. You've been warned.
Although I would love to see XFree86 supporting simultaneous layouts (without another instance) and a brand new keyboard driver, I don't have the necessary understanding of the project to implement it by myself. Anyway, my regards to the XFree86 developers for this great piece of software!
My idea is to have two instances of XFree86. The first will be using a normal XFree86 server, it will initialize the main video card and attach it to a VT. It will also use the standard system AT keyboard and something (PS/2, serial, USB emulated as PS/2, whatever you want) as a mouse.
The second instance of XFree will be my modified X server. It does not support VT switching at all because it's been used to control a hardware that is not normally used by any other VT. Read my lips, this is very important: The video card can't be the primary one, the mouse can't be the same used by gpm and the keyboard must be USB and must not generate scancodes to the normal Linux console!
As the keyboard doesn't look like a normal AT keyboard (no keys to standard console) the keyboard driver of my modified X server must take care of USB events translating them to normal scancodes.
Procedure (step by step)
1) You need to get XFree 4.0.x (RedHat 7.0 and a lot of recent distros comes with it) and configure it for two video cards and monitors. I suggest that you first try it with Xinerama extension following this HowTo: http://linuxdocs.org/HOWTOs/Xinerama-HOWTO.html
Then modify your XF86Config or XF86Config-4 to separate your screens in two layouts, instead of using them with Xinerama extension. Don't know what I am talking about? Then it's time to read XF86Config, do a ``man XF86Config''
With two layouts your XF86Config should look like this:
This should be trivial to do because it's almost the same as Xinerama configuration but with two layouts. Then switch your box to runlevel 3 (init 3) and try both layouts, one at a time:
Pay attention to BusID settings as described in howto. Note that a dualhead board (like Matrox G400) should NOT work through the next steps, as we will be using 2 instances talking to the same hardware. But I haven't tried myself (I'd be happy to try it if any reader wants to donate such video card...).
Not all video cards can be used with XFree86 dualhead support. Don't email me saying that you couldn't get your cards to work up to here or you will burn in hell! Read the Xinerama HowTo instead, thanks.
2) Plug your second mouse on the system and configure XF86Config to use it in the second layout. This mouse must not be used by any other program, like gpm. XF86Config will look like this (only the changed sections):
Again, test this layout to make sure it's working.
3) Get Linux Kernel 2.4.0 so we can play with USB support. Some 2.2.x kernels may work as they have backported USB support, but in doubt, stick with 2.4.0.
In the kernel configuration, enable USB support (CONFIG_USB) and keyboard (either CONFIG_USB_HID or CONFIG_USB_KBD if your don't need USB mouse support). You must enable "input core support" (CONFIG_INPUT) and MUST NOT enable "keyboard support" (CONFIG_INPUT_KEYBDEV) as we don't want the USB one to be the system keyboard. Also enable "event interface" (CONFIG_INPUT_EVDEV) as I will use it to receive scancodes.
Compile and install the kernel. Now plug your USB keyboard, once the kernel enters you should not see any pressed keys from it at the console. Now try reading the keyboard events (assuming the keyboard is the only USB device you have):
# cat/dev/input/event0
You should see some garbage on the screen as you type. That's all right, your keyboard is working. If you don't see anything or get "No such device", something is wrong with your USB system. Read Documentation/usb in your kernel sources for more information.
4) Get the sources of your XFree86 4.0.x if you haven't already done so. The sources are available from www.xfree86.org. There should be 3 or 4 big.tgz files, but you will only need the first one.
Expand the tree and apply my patch, which can be downloaded here (4.0.1) and here (4.0.2). Follow the instructions from the package to build the X server (make World). You should get a new XFree86 executable on directory xc/programs/Xserver. Copy it to your/usr/X11R6/bin with another name (like XFree86-2nd).
Or if you like the easy way, try one of my XFree86-2nd servers (compiled against glibc-2.1):
XFree86-4.0.1-2nd.gz
XFree86-4.0.2-2nd.gz
This server supports only USB keyboards and do not grab a VT. The only VT code it has is to switch to a given console through XFree86-2nd vtxx parameter.
Applying the patch is intended only for developers that can help me improving this scheme. It will also require you hundreds of MB of disk space. If my provided X servers doesn't work with your system there's little I can do about it. If you can, try to discover the problem and fix it.
5) Modify the second layout to use the USB keyboard. This will require you to use the protocol "usbev" I created and specify the/dev/input/eventx you like as the device. The XF86Config should now look like this (only the changed sections):
It should initialize your second video card, the second mouse and the usb keyboard without interfering with your console. You can even do this from a xterm window inside your running X server. Yes! It works! Now move on to the grand finale...
6) If you use gdm as display manager and to provide you a graphical login, you can edit the file/etc/X11/gdm/gdm.conf as follows:
Getting this one to work may be a major challenge. It took me a lot of trial and error until I got this stable configuration. I had to add a option "-delay" (my hack) to cause a 10 second delay at one of the servers so they would not initialize the hardware at the same time. I don't know why this is needed. Playing with the order they are initialized (by exchanging 0= and 1=) also does the trick.
Known Bugs
This thing mess up with my text console. I have to switch between the VTs a couple of times before the text looks good again. Fell free to give me a solution.
Also a main problem may be that the whole thing does not work with other hardware and you may be wasting your time reading all this. But the idea is here and I can guarantee that it worked for me. So it must be some little issue that I'm sure will be quickly resolved by another developer somewhere....
Updates
Price study
Brad Midgley pointed that support for Matrox G400 and similar dualhead cards should be possible using framebuffer interface. I still don't have the hardware to do any tests on this, but if you want to try please note that I may have removed something important for framebuffer from the init routines. Please check for any mistakes the patch might have. Any updates on this issue are greatly appreciated...
Daniel Tarbuck reported success with XFree86 4.1.0 with an additional patch: "I have implemented your patch on XF86 4.1.0 and I found that I had to comment out the following line: /*((pciArg*)arg)->func(((pciArg*)arg) ->tag, PCI_CMD_STAT_REG, ((pciArg*)arg)->ctrl); */
in xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c . (pciIoAccessDisable function)
I don't know what the problem was, and I don't know why my fix worked for me. I also don't know if there will be serious problems as a result of my fix. Here is a few details on my setup:
primary card: ATI Mach64 GT+ (PCI)
secondary card: S3 VirgeDX (AGP)
kernel 2.4.5 (Redhat 7.0)"
Jan "Yenya" Kasprzak did some tests with Daniel's patch and got two hardware configurations to work:
S3 ViRGE VX PCI (primary) SIS 6xxx AGP (secondary - USB keyb.)
I was not able to set up the AGP card as primary.
Matrox G450 AGP (primary) S3 ViRGE VX PCI (secondary - USB keyb.)
I was not able to set up the S3 card as primary.
Yenya wrote: "I still have one problem: IMHO the above patch should be applied to primary X server as well, because otherwise it locks up the secondary card when the user on the primary display logs out."
Another success report, thanks Nathan Hoult for the information:
"Geforce2pro 64meg AGP (MSI)-slave,AGP" and a "TNT 16 meg (Diamond Viper550)-master,PCI" Nathan wrote: "I used the official NVIDIA drivers too and get OpenGL to work on both quite well... well except i have permission problems all over the place but just got it working anyhow." (Mandrake8.1, XFree 4.1, linux 2.4.16)
I rebuilt the patch against XFree86-4.1.0 (from rawhide sources XFree86-4.1.0-0.9.11.src.rpm). Applying Daniel's patch to both X servers, now we have XFree86-1st and XFree86-2nd (I hope everybody knows how to use them!).
The 2nd server is using usbev keyboard as usual (thanks to Vojtech Pavlik help now we should have keyboard leds working). Please note that binary files where compiled under RedHat 7.1, so you need glibc >= 2.2.2.
Precompiled XFree86 4.1.0-1st server.
Precompiled XFree86 4.1.0-2nd server.
Patch for XFree86 4.1.0-1st
Patch for XFree86 4.1.0-2nd
Notes:
1) This binaries were tested over RedHat Linux 7.1. The gdm provided by ximian gnome desktop refused to work with my dual login, I had to downgrade to RH7.1 gdm package.
2) My usbev keyboard got wrong key mapping if I don't specify XkbModel and XkbLayout. Something seems to have changed since 4.0.2, so don't forget these settings (specially if you get a working server with no keyboard...).
3) When testing the XFree86-4.1.0-2nd inside the first instance I got errors of xauthorization. Calling the 2nd server with "-ac" may help.
4) Usb keyboard leds still don't work. I will debug it as soon as I have time to do so, there must be some mistake.
TW doesn't offer you ANY web space? Put your aquarium pictures in your area on their web servers where there's more bandwidth for others to download them. Then you'll only use your own bandwidth when you update your site. You can then turn off your PC or reboot once in a while without taking your website offline. Use your broadband to enable your home PC to upload and control your web site from home, or to fix it automatically if it gets defaced.
If you want the adventure of running your "own" server, you can get a shell account on a VMS, Linux, Solaris or BSD host, usually for a one-time fee of $10 to $50. They won't give you root access, but you can install software in your own a account and run light servers like boa as a background process. If your cable or DSL goes out, or you move, or you switch ISPs, the site will stay up.
Or almost as good, use one of those "free" web hosting companies. Both Tripod and ProHosting let you write your own CGIs in perl. That gives you most of the fun of your own server without all the crap.
Then there's the security risk. Running a server out of your house is the best way to get your machine cracked. More than likely you will never know or notice if the cracker is any good. Personal servers are different -- you can limit the allowed IPs to your work's proxy server and/or use VPN to make sure you and only you can use your machine remotely. If you configure a server wrong (it only takes 1 mistake) or the software has exploitable bugs (and ALL software has bugs), you just end up creating habitat for crackers to take up root.
Besides which the performance of broadband-hosted websites just plain sucks. Your site might become more popular if it's consistently available and fast. Good luck.
If you use an external 1394/Firewire/iLink or USB hard disk, it's just an ATA disk inside. Both 1394 and USB support hot-plugging, and linux support (at least for generic devices like ATA disks) is fairly mature. As for performance, 1394 is supposedly 400 Mb (bits) per second and USB 2.0 is 480 Mb/s. You need to buy a USB 2.0 PCI card for your PC, but they aren't too much. USB 2.0 controllers are also called "EHCI". USB 2.0 devices work with USB 1.1 controllers at the standard 12 Mb/s. Search the web for "USB ATA enclosure" or "Firewire ATA enclosure" and you should find something. For portable disks, you're more likely to find USB ports on a PC, and I suspect 1394 devices are going to seem really overpriced compared to USB 2.0. But YMMV.
http://www.linux-usb.org (you're on your own for 1394)
I know you spent money on those removable ATA caddies, but if all you want is a hot-swap ATA disk, there are other ways of getting there that are designed to do what you're after.
Slashdot Mirror
If you think a laptop will be money well spent towards getting a quieter computer, I think you'll be disappointed. I do a lot of service on PCs and laptops, and I've been repeatedly surprised how loud the laptop's really are -- almost a bad as a PC, if not as bad.
I suspect the noise is from MTBF of fans and hard disks. It's true that some models of hard disks and fans really are quieter or louder than others. But take two PCs of the same model with exactly the same model parts and one will be louder. A fan can get dirt in the bearings, spin unevenly, or vibrate in place, all causing irritating noise. Everyone's experienced a hard disk that works just fine but has a piercing, tinitus-inducing whine, which usually gets worse over time. Just like when you a buy a PC, there's a certain chance that when you buy a laptop that you'll get a noisy one, and you'll either have to swap the guilty parts yourself, experiment with accoustic matting, or come up with a good excuse to exchange the noisy laptop for another of the same model and hope lightning doesn't strike twice.
Now if you want your laptop to get _noisier_, just move it around a lot while it's powered on with the drives spun up and be sure to place next to a pile of dust-ridden papers. Bump, move, or shove the desk the laptop sits on as much as possible. It won't take long...
If you want permanant lasting quiet, get a handheld PC, like a Psion or a PocketPC. They're certainly not as good as a "real" PC or laptop for the money, but they are _totally_ silent. The only sound mine makes is a slight hum from the backlight, but I have to put my ear near the screen to notice.
When you say you hope we're up for another format switch in PCs, I think you're right. DoC sockets are becoming common on motherboards. CompactFlash cards are getting bigger and cheaper. USB 2 is adequate for connecting external hard disks. I suspect PCs are going to become more and more solid-state, but not for good reasons. I think Microsoft is going to push for the core of their OS to live on a DRM-enabled, read-only flash that requires digital keys to modify. Sure it will be cracked in a week, but I think the current X-box vs. Linux charade is just a rehearsal. Their using it as free research to see if it would work for PCs. Eventually PCs are going to become so powerful and so cheap that the threat "Buy a new computer!" if you want to upgrade your version of Windows will be like ordering someone to spend $50 to double the gas mileage of their car.
Let the funny Microsoft/Automotive metaphors begin.
That was a really funny article. I feel better already.
Sun sells one. I think the name is "Sun PCi". It's a PC on a PCI card. $500 last time I checked, and no open drivers (Solaris on SPARC only), but that could change. Orange Micro used to sell PCs on PCI cards for Macs.
Leave it to nerds to bicker over a problem that country music has already solved. The song you want is called "God is my Palm Pilot".
Can't recall who sang it though. Let me check with my personal organizer, and I'll get back to you.
1) Don't work alone.
The reason you're getting swamped is because _you_alone_ wrote and understand the code, so _you_alone_ are the sucker stuck maintaining it. Don't fall for this. Use the "buddy system". Involve a co-worker in every project you do, whether they're willing or not. You don't have to join the extreme programming fad. But just share what your working on with a co-worker, so they have more than a passing idea what you've done. Then return the favor. Take an interest in your co-workers' projects and learn how they work. Then when something breaks on your co-worker's project when he's out sick or on vacation, see if you can solve it without bothering him at home. Eventually, they may return the favor when you're trying to get some downtime. And if they don't reciprocate, then you've learned your co-worker is a worthless fool, if you didn't know that already. Find another buddy then. It's basically the same idea as what managers mean by "cross-training". But if your manager was doing any cross-training, you wouldn't have this problem. So don't wait for your manager -- ban together with your peers, and fix it among yourselves. If some of your co-workers also don't/can't pull their fair share of the workload, teaming up on projects will throw that into high relief. Not that I've ever seen anybody get fired from an I.T. job for being too dumb or unwilling to learn to read/write simple scripts, but you could get (un)lucky.
2) Automate every stage of your work with scripts.
Get a scriptable text editor. Write macros to generate comments, common loops, subroutines. Write scripts to version/revert files, run them in a debugger, build executables, make notes about progress or bugs, insert date/time stamps, call up the manual page, etc. Use script or templates to generate new source code files, so that 99% of what you need is there. Many IDEs do most of this already, but you may not be using all the features. Or if you notice a feature that you're IDE lacks, write a script to add it in yourself. And share your scripts with a co-worker who's likely to share his scripts with you. After a while you should be able to create and maintain project with a series of single keystrokes and copying/pasting. Adding and testing new features then becomes much less of a frantic typing exersize, letting you focus on getting the solution right.
LOCK
THE
DOOR!
The cracker's probably sitting right next to you, chiming in with everybody else: "How did they get through our firewall??!!"
The Sam & Max adventure game was based on a comic book entitled "Sam & Max: Freelance Police". They basically roamed the world, pretending to be police officers/P.I.s and solving whatever crimes they stumbled on. Usually with violence.
I was (un)lucky enough to find a color issue of Sam & Max in the bargain bin of a comic book store while looking for back issues of Grendel, The Elementals, and Groo the Wanderer. I think I paid $4. It's the most dangerously funny posession I own. I keep it safely packed away out of sight, because I can't read the damn thing without laughing so hard it brings tears to my eyes.
The comic was drawn pictures first, and then the dialog was made up after the fact. Kind of like Mad-Libs, or the heckling on MST3K. If you like the Simpsons, you might like Sam and Max. Groo the Wanderer is good too, but it's funny the way Mad magazine or Cracked is funny (or isn't) -- mostly corny jokes.
Compare for yourselves:
---
Groo: "I'm hungy. Aha! Groo smells smoke! Where there's smoke, there's fire. Or a village! Or a village on fire!!"
---
Grateful Stewardess: "Thank you for saving our plane! How can we ever repay you?"
Max: "JUST GIMME ALL THE NAKED WOMEN MY POOR EYES CAN STAND!!"
Sam: "Easy, Max. You don't even like girls."
---
Luckless Villager: "Who be you?"
Groo: "I be Groo."
LV: (aside) "We are doomed..."
---
Max: (a naked, yet fuzzy Max produces a 9mm pistol from thin air)
Sam: "Where'd you get that gun, little buddy?"
Max: (grinning) "None of your god-damned business, Sam. Tee-hee."
---
So if you liked the game, you might be able to scare up a copy of the comic book and see where it all came from. I don't there were ever many issues released, maybe less than ten. I get the impression they're fairly rare, unless they've gone into reprints since then.
It's not an OS. It's an OE, an Operating Environment, like GNOME, KDE, or CDE. That's why they named that particular string of vowels, thinking they'd made a clever pun. Ew.
I'll say it again (if only because I've said it before...) at least they saved millions of dollars by not hiring a naming consultant.
OSS is going to win the desktop war by being increasingly less pronouncable than the competition, greatly limiting the opposition's ability to spread FUD in COMDEX keynotes and by word of mouth. When criticism of your product is met with shocked replies of "What the hell did you just call me?!" or "Do you kiss your kids with that mouth?!" then you know you've correctly named your OSS/Linux/BSD/GNU-based product. It uttering your product's name aloud causes Satan to spontaneously materialize in a <BAMF>cloud of brimstone</BAMF> or motivates Chuthulu to wake up a few eons early, then you've got a killer app on your hand. The moment your competion dares utter your product's name, they'll all die screaming as hideous supernatural creatures suddenly appear in their board room meetings and devour all the executives, and you'll gain valuable mindshare with the Old Ones! The-product-whose-name-must-not-be-spoken is FUD-proof indeed, so long as you can train your staff to only converse about the product in winks, head nods, and hand gestures. Except, of course, the employees you want to "let go".
Best of luck to them and uh... their product.
Yes, it's needed. And it's OK if the reason isn't blatantly clear. The NetBSD crowd is very much anti-hype. So a lot of its features aren't done to be cool, impress OSS mavens, make any headlines, or even to allow stingy people to avoid paying for commercial software.
NetBSD is a research OS. See:
http://www.netbsd.org/gallery/research.html
NetBSD itself isn't a research project per se, but a baseline OS for conducting generic computer science research, whatever kind of research that may be. So, if you want to do your Comp Sci PhD on a revolutionary new implentation of virtual memory, use NetBSD. You don't have to waste any time writing your own OS, and NetBSD will run on almost any 16+ bit computer you can find. That old Sun, DEC, SGI, PowerMac, or wierd PC clone can become your test bed or workstation, and it just might support more hardware than the original OS. (Nowadays, you'd probably do better to buy/get a slightly obsolete PC, but for some projects old gear has advantages, like SCSI, RISC CPU(s), good SMP, a quality real-time clock, better hardware security, etc.)
For example, if you find bought/found/stole a Sun Ultra, Dec Alpha, or a PowerPPC box with PCI slots, you will have a much easier time getting almost any PCI card to work with NetBSD than with Solaris, VMS, Tru64, AIX, or MacOS X/Darwin. You will have to learn to like those two little words: No drivers. Or learn to write/port your own. Hey, it beats getting any real work done on your thesis, right?
Not to mention, you may not have those OSes laying around, or the cash to buy them, or the time to wait for the vendor to mail it to you (ahem, Sun?). Or the patience to put up with the BS required to qualify for a "hobby" version (ahem, HPaq?) that only allows you to use OS in what is essentially single user mode and has a license key that will expire annually, and will need a new key (annually) that will require you to reregister with company, even after the company ceases to exist.
<SARCASM>What a great deal!? Now I can fire up that microVAX in the garage and type my letters in EVE! At long last!!! Honey, shut down the NT box for good, cause we've found the way out!</SARCASM>
And they wonder why the hobbyiest version of VMS hasn't taken the world by storm... Sheesh.
This doesn't have anything to do with whether Linux makes a good research platform. Lots of good, pure research is being done with Linux too. But Linux requires a little up-front work on your part before you can work on your original project (especially bootstrap or installation issues on non-x86 platforms). I've found installing NetBSD to be an almost trivial undertaking compared to Linux or even Windows NT. It's so distubingly straightforward, it should say so on a bumper sticker.
There's a lot of cool features in NetBSD that just came about because of basic computer science research. Binary compatability is one of them. It's just an experiment into finding ways to make the OS more useful. If it would be more useful than less for NetBSD to be able to run binaries from a platform's vendor OS, then that's exactly the sort of thing NetBSD should be able to do.
That's why.
First off, let me say I'm glad they didn't blow a lot of money on a naming consultant. That ugly acronym they settled on must have saved them millions of dollars...
Soundtracks, film scoring, and even some album production is being done increasingly on DAWs, pronounced just like it's spelled. A typical configuration is a tricked-out PowerMac (Sun Ultras used to be the platform of choice) with maximum RAM and a fast RAID array (i.e RAID 0 -- don't laugh, I'm not kidding. RAID 0 is used to lower latency on the drives) and a MIDI adapter, for both driving sound modules and inputting music on a master keyboard. Add a copy of ProTools, some Mark of the Unicorn software, a DAT drive, a CD-burner, a mixer, some rack effects, and maybe a high-end audio PCI card for when you hit the limits of the Mac's decent but not that great on-board audio. This is not a sub-$1000 iMac rig were talking about here. If you want a good DAW, you go to the bank in your best suit and tie and apply for a loan.
Of course this makes no sense to an amatuer composer/musician. You might ask what's wrong with a stock PC with a good sound card, a quality microphone, UltraATA disks, a MOD Tracker with WAV/MP3 export, any old MIDI synth with velocity-sensitive keys, and CD-RW/DAT drive? Nothing really, if you want you music to sound like it was created on a computer. But that's not what a real DAW is for.
A DAW has to be _FAST_. The software used (like ProTools) is used to edit and master a gigantic audio file of CD-quality sound. Document sizes are often routinely in the gigabyte range, unless you're just editing small leadins for TV or commercials. You can use MIDI and samples to provide voices in the soundtrack, but the goal of a DAW is to have total control over the audio in the file, just like you have over a photo in Photoshop. It should be just as easy to work with a "real" audio recording (like a studio session recorded with a real orchestra) as it is to use sythentic music (samples from a microphone or synth, MIDI sequences, etc) and tweak the finished product to sound completely natural, as if real musicians had played it that way start to finish in the first place.
So any latency you have in the DAW can put skips or glitches in your recorded input. You need a workstation with enough RAM to avoid paging, fast disks that don't cause the CPU to have to wait (DMA/SCSI), and good all around performance to prevent bottlenecks: fast OS, fast graphics, fast CPU, fast audio chipset, etc.
Linux is perfect for this, because comparatively MacOS 9, MacOS X, and all versions of Windows except CE are complete pigs. Linux just lags in solid support for audio input, mixing, MIDI, and audio applications, etc. the way Macs and PCs do.
This distro isn't something you sell to end users (though they may) but to OEMs and VARs who want to sell Linux-based DAWs but want a vendor for the operating system beside Apple, Microsoft, or Sun. Other people have mentioned how poor musicians and DJs are. If you could make and market a Linux-based DAW out of PC parts with comparable performance to a ProTools rig and a substantially lower price, you could make a place for yourself in the market and do pretty well. Anything in the music equipment world that is both "really good" and "pretty cheap" and word gets out. Selling distro CDs just raises money and hopefully creates good PR for the concept of Linux as a good enough OS for a DAW.
The Azza motherboards we get from ACS come with StarOffice CDs (only Windows is pre-installed on the PC). Not that we use the CDs, but some of the beige-box assembly houses are shipping StarOffice.
This is what decompilers and the strings command are for. You'd be amazed how much you can learn about what a binary does by running the .exe through a decompiler and just leafing through the symbols. You might think most apps strip all useful symbols out, but it's not true. You can have yourself an old school literate programming session and leaf through the binary code like a book, if you have a few assembly references handy and limited understanding of addressing modes.
.exe, it's not like you _can't_ ever know what it will really do when you run it. You just need some time, some tools, some brains, and some nerve.
So even if the file is
And tea is a good middle-ground between soda and water. No jitters or stomach problems like people get with soda or coffee. Ironically, it's cheaper than either, as long as you don't buy the overpriced yuppie-oriented brands like you see in coffee shops. You're talking about bottled water, right? People drink everything but tap water because most tap water is disgusting (whether or not it's any different than what you get in a bottle). If you live where the tap water is clear, clean, and free of clorine, you're pretty lucky.
If you're addicted to caffienated soda or coffee, you can wean yourself off of it without the withdrawal symptoms (bad headache, being disoriented, mood swings) by switching to tea. Two tea bags, 1/3 cups of sugar, some lemon or lime juice (very little), and a quart of boiling water in thermos makes something as powerfull as Mountain Dew. The sugar thickens the mix to get a similar consistency to uncarbonated soda. I used to make tea so strong that it scared my co-wokers who tried it. If you learn how to do it right, there's nothing weak or bitter about good tea. I've backed off on it to a more conservative recipe, but it's something that's cheap to experiment with. It's true you can make a tea that's as bad for you as soda or coffee, but there's nothing stopping you from adjusting the strength of it over time, which you can't really do with coffee or soda.
Don't leave the tea bags in more than three to five minutes (it varies with how hot the water is and the container) or it will be too bitter. Or get an iced tea recipe off the web. Or just pour the tea (after it's brewed for 5 minutes) into a metal or glass pitcher and leave it in the fridge overnight. (Rubber or plastic pitchers leave an aftertaste in the tea). For cold tea, you can make huge batches in advance on the weekend with little extra effort (making tea is a procedure that "scales up"). Adjust the ingredients until you find a mix you like, as the proportions make a big difference in the final product.
You can save a lot of money over time this way. I think I was losing an easy $2 a day on soda. I did the math on what it costs to buy tea, lemon juice, and sugar, now that I've bought the thermos, it's less than 25 cents a day. I don't know if you can get bottled water that cheaply (because I hate the plastic taste in bottled water). I don't find tea as addictive as soda either, so it's not like you're trading one craving for another.
For your vending machine, think about making a hot water tap available for people to use, and maybe an ice machine too. That way they can make hot or cold tea at work, if they don't want to or forget to make it at home. Some places go so far as to supply the tea bags and sugar, but it doesn't sound like you can do that.
My rats are extremely excited.
At last, I can put out a cold bowl of Diet Coke for them to lap up and not worry that their 4 year life-span will be cut short by a malignant cancer.
And while they're at it, they can change the name to "Omega".
You've never owned a 6400 or a 6500 then. The CPU/PS fans are so weak, the Mac tends to lock up on hotter days. If you look on google, you can find entire web sites devoted to publicising the problems with these machines. They were cheap, but IMHO not worth the trouble.
And the 6400/6500 case is anything but "easy to open". You need a special tool (a case splitter) -- otherwise you have to nearly rip the calluses off your fingertips (after your fingernails go first) straining to pull the front off. When you hear the sudden, loud CRACK sound, loud enough to suspect you broke something, then you've got the front off.
Like a lot of pre-Steve macs, the fasteners are all made of plastic or very weak metal, so unless you go carefully, you can easily break a Mac case where it will never close again properly. The PowerPC cases are great examples of the this. Everything, from the card guides for the NuBus cards to the tabs that hold the motherboard in place are made of very fragile plastic. If you're ever working inside a Mac made from about 94 to 99, be careful!
Macs have this ridiculously undeserved reputation for having great cases that are easy to work with and won't cut you. This is pure hype. The aluminum flashing inside a Mac case as RF shielding tends to get bent up as you open and close the case and is hard to straighten. I've been working inside some PowerMac and said to myself "Hey, what's that little maroon bead on the motherboard..." before I realised I was bleeding. On the upside, the shielding is sharp enough to make a clean cut.
SOME macs do have good cases, but most do not. Most require special tools (like torx wrenches) and a reasonable understanding of electronics, especially the Macs with built-in monitors (like not electrocuting yourself on the CRT). The recent macs once Jobs was back at the helm have much, much better cases than almost every mac that Apple ever made. If you have basic PC building skills, than a post-iMac era Apple machine should make you feel right at home. For all the earlier ones, read up on the specific model before you do anything. They're no worse to work on than cheap clone PCs, but they have their own unique gotchas that are sometimes so wierd, proprietary, and/or dumb, it's best just not to guess.
Apple kind of runs under this idea that the computer they are selling you is actually an _appliance_, which should run reliably as designed (not that it will). But if it doesn't, you're expected to "take it to the dealer" and have them fix it, like a car or television (which nobody does, because you'll get ripped off or have to bring it back multiple times). That's the only way they're managerie of case designs make any sense, is if a trained Apple Service tech is the only one whose ever supposed to open it.
I wouldn't buy any mac unless I already had the directions on how to open it up and work inside. That will give you an idea how many proprietary plastic parts you might have to buy from Apple for $10-$40 each if you muck around inside. If they're still available. That's what I advise people who ask me advice about what mac they should get, especially for people buying used macs.
You don't already do this? How do you keep the the air-conditioning technicians from loitering in your server room?
No. You're right that Mac users will take DRM as an opportunity for a little evangelism. But Microsoft's plan is to lobby Congress, probably under the veil of another media group (like RIAA), to mandate that all computers sold in the US will required hardware and software compliance with DRM. It would not be impossible, in this new era under UCITA, for them to attempt a retroactive mandate, where even the computer you currently own has to get a PCI/ISA card and a OS "upgrade" to add DRM compliance, especially if you make it illegal to connect to the internet without DRM compliant gear. The Information Super Highway Patrol will pull you over and make you recite the ASCII character set backwards or get a knock on the door from your local jurisdiction officials for a little "inspection" with all kinds of probably cause. Of course it's a stupid idea for all kinds of good reasons, but that's never stopped lobbyists or ambitious politicians in the past.
You might as well say, don't use any networking on these macs, because the builtin ethernet is so slow. It is -- that's true -- but without ethernet the machines are much, much less useful. You don't wan't X on these because it will run well. It will not. He'll probably be lucky to get 640x480 at 8-bit color. But with only the console, it limits the number of apps he can realistically offer users, unless he wants do code everything with cdialog, pilot, or ksh "select" menus.
Because this is a _migration_ to linux, the users are going to know squat. He'll want X so he can offer apps that anyone who knows how to use a mouse can figure out (provided he puts in the preparation to configure the X resources and windows manager before hand so everything appears to be "just there").
Also, console apps will remind people too much of DOS. It's a PR thing -- people will see it as a step back, not forward (even though, as you and I know, Linux is much better than DOS). If a decision-maker see these macs and makes the association with DOS, he could kill the whole project. I remember what it was like supporting VMS terminal apps, like PINE, EVE, NOTES, and LYNX. These are great programs, but too many people just don't get the idea. You'll lose hours and hours hand-holding people through console apps who could otherwise use a browser all day without ever bothering you for help.
Without X, you might as well toss all these macs in the garbage and buy 100 dumb terminals from Boundless. You can buy them in bulk for $80 each, and they'll be alot less hassle to maintain then PPCs with a linux booter that depends on a working MacOS partition to boot up.
If you worked in my production department and opened an 900 MB TIFF file from OFF THE APPLESHARE FILE SERVER I'd probably fire you.
Macs come with 60 gig ATA hard disks now. How dumb can you be not to copy the file to local storage before editing it? Real publishing houses also use OPI servers to generate lo-res placement files (FPOs) so they can edit the pages at screen dpi (72-96) and have the changes reflected on the RIP at press dpi (1016-4800 dpi) with the burden placed on the OPI server to merge in the hires (not your mac). Distiller also works well to reduce ridiculously huge graphics to a managable PDF file without much visible loss in quality (with the right Distiller settings). Most apps will let you place a PDF in a document and do operations on it, just like an EPS. 1 MB per color layer at 1200 for a newspaper page (13x22") seems to be about average at the two newspapers I worked at. Much easier to work with. You might find your work goes a little quicker.
I used to admin a college lab of these macs -- about 80 6100/6x, some 7100s, and some much, much better 7600's and 7300's.
/, *, and - on the number keypad
When MkLinux was first announce on the net, I snagged an abandoned 7100/66 and a spare 2 gig IBM hard disk
(Thanks, Carl!) and installed MkLinux as fast as the school's T1 could get it in the building. I had this idea
I could use the 7100 running netatalk to liberate my side of the lab (the mac side) from our NT file server
(which wasn't a such a bad server, but SFM had some killer bugs that the service packs hadn't fixed, and I
wasn't in charge of applying fixes to the NT box). But when it became obvious I was going to have to spend
every waking minute of my life tweaking this new toy to make sure it didn't crash during finals week or get
hacked by one of the students (I was pretty new to UNIX at the time), I shut the 7100 down and tabled the
project. In retrospect, I kind of wish I'd spend more time on it. But knowing what I know now (i.e. knowing
now how much I didn't know back then), I'm glad I didn't do something stupid, like make every mac in the lab
rely on the MkLinux box for some network service.
So I know a little about what you're about to go through.
First, you need a Linux distro that supports Nu-Bus, because those macs are not PCI based. MkLinux will work.
NetBSD, amazingly, will not run on these macs. That should set off red flags in your head. You're venturing
into unsupported hardware territory. Expect that some hardware won't work AT ALL. In preparation, read
through the Linux docs for whatever distro you find that supports NuBus macs and write down all the hardware
that is reported as unsupported, alpha, buggy, or problematic. If a component is unneeded (like serial ports,
sound in general, or audio input)
then just don't use it, and maybe look for a way to remove or disable that device in the kernel. You really
only need support for video in X, the mouse in X, the keyboard (especially mapping keys), and ethernet.
Forget about sound, and I wouldn't be surprised if the floppy drives only work for booting, but not once
linux is up and running. Maybe you can pass that off as a security "feature".
Second, you need to account for the fact that these macs are not fast. 6100's are barely quick enough to call
"slow". The less software you install on these, the better. If it were me, I'd set them up as thin clients
with X, a browser, telnet/ssh, maybe java, maybe a few helpers for the browser, and that's about it. Run
everything else over X hosted off a better machine. If you have a few faster macs with a 604 or better yet
a G3 or G4 (not a 603) consider reserving it as an X host for users to log into with XDM. Ideally, you'll
want two or three machines for failover or a hot spare. If you have a
more modern mac as an X host, you can run RedHat, NetBSD, SuSE, or even MacOS X (I suppose) on it, and the X
clients can run software from it over the network. Just give the X host plenty of RAM, fast ethernet, and
SCSI disks, and it should be fine. Also, the less software you install on the 6100 as a client, the fewer
bugs you'll have to deal with where software XYZ doesn't run properly on the 601 due to some bug in the PPC
targeting code of gcc.
Third, you have to prepare for the unique "features" of the Macintosh platform that are going to get in your
way. You'll need a boot-loader that runs from the MacOS because these macs lack OpenFirmware. PCI macs at
least can boot other operating systems by finding a boot-loader on any HFS, IS0-9660, or FAT partition. Your
macs will each need a bootable HFS (MacOS) partition with just enough MacOS to run the linux boot loader
(usually an extension), with maybe some ResEdit hacks to keep users from bypassing linux on bootup. Once your
users get into MacOS, all security is gone and they can do whatever they like, including erase or hack the linux
partition (using ext2 utilities). I would use a tool like RevRDist for the Mac side, so you can master the HFS partition from any
AppleShare server (or netatalk). Then use rdist or rsync on the linux side in the start up scripts to master the linux
file system from a server. Use the Apple "Network Access Disk" to jumpstart the whole process from a bootable
floppy. If some genius hacks the bootup sequence and reinstalls MacOS (which they will, because MacOS unlike
Linux will let them do whatever they want without ever a "permission denied") you can remaster the whole mac
just by rebooting from a read-only floppy and running RevRDist from the server share. You should also
should figure out what you're going to do about mouse buttons. You probably only have 1 button mice. The X
Window system likes 3 buttons. The standard workaround is option+1/2/3 to fake that mouse button with the
keyboard. It will take less than 60 seconds of that to either fuck up your hands or just plain drive you
crazy. Use xmodmap to remap buttons 1, 2, and 3 to some single keys, like
or something. Or look at the price of 3 button ADB mice and multiply that by the number of macs you have...
Basically, don't make it up as you go along and expect to get lucky. It's not going to happen. With a
little thought and preparation, you should be able to automate everything and have maintenance-free LAN of
semi-decent thin clients/X terminals that just happen to show a "happy mac" when they (rarely) boot up. And
when you see how fast Linux runs on a 6100 compared to MacOS, you'll probably be smiling too.
You'd better not be trying this in Washington at a public school. The state has a policy of what state-purchased computers can be used for. Game playing is explicity listed as forbidden. I don't remember exactly, but I believe it could even be a felony.
We wanted to do LAN games at our university lab to raise funds, but our boss was quick to remind us that if a single administrator found out about it, we could've all been expelled.
So, you can have LAN gaming parties in Washington at a public school, but it has to be kept absolutely secret and unofficial. Just don't hurt anybody while you're breaking in to the building.
This topic was on slashdot once before, and I posted this back then as well. Miguel Freitas of Brazil got this working on his linux PC: two monitors, keyboards, and mice, served by seperate X servers. Long story short, he said performance was adequate supporting two desktops simultaneously. Using PS/2 devices for one console and USB devices for the other prevent /dev name ambiguities. The text is mirrored below with the URL at the end if you want to want to get the HTML.
/dev/input/event0
.tgz files, but you will only need the first one.
/usr/X11R6/bin with another name (like XFree86-2nd).
/dev/input/eventx you like as the device. The XF86Config should now look like this (only the changed sections):
/etc/X11/gdm/gdm.conf as follows:
/*((pciArg*)arg)->func(((pciArg*)arg) ->tag, PCI_CMD_STAT_REG, ((pciArg*)arg)->ctrl); */c . (pciIoAccessDisable function)
This may also be possible in NetBSD if you use wscons to configure two discrete muxes and start a different X server on each one. Can anyone from core or Wasabi comment on that?
---
Multiple local XFree users under Linux
Version 0.92 by Miguel Freitas
Updated April 4, 2002
You can always get the latest version of this document from: http://cambuca.ldhs.cetuc.puc-rio.br/multiuser
Keywords (for bots)
I've wasted a lot of time trying to find this kind of document in google, hotbot and so on. Let me add some keywords to help people finding it: true dual-head, multi-user support, XFree86 4.0, multiple keyboard, multiple mouse, multiple video card, dual user, XFree86 instances, dual keyboard, USB keyboard under X.
Motivation
I have one girlfriend and one computer. In normal conditions, we both couldn't use the computer at the same time, in spite of the fact that it usually has a lot of processing power available. I also have a spare monitor and a second video card for playing 3D games (voodoo) so this idea came to me as something very obvious. New XFree86 4.0 support for dualhead suggests that most of the hard work is already done. And it has to be on Linux, because no closed source OS would allow me to make the changes that I need.
As several reports confirm, Linux is been successfully used in educational institutions and projects due to it's great benefits and low cost. Using the same computer for two (or more) simultaneous students, workers, etc. is something that can reduce even more these costs.
This is also a great option for companies to simplify the management and upgrades of the shared resources (motherboard, processor, hds).
For everybody who may be asking: don't it get too slow? No. The performance difference is barely perceptible as most of the time the computer is waiting some command from the user. And if you haven't figured it out by yourself let me tell something: we live in a time of computing power in excess or do you think most of the users needs a GigaHertz Pentium 3 machine just to do their word processing and surf the web?
Problems
There are some problems that need to be addressed in order to support multiple XFree instances (and users):
VT handling - The Linux kernel Virtual Terminal scheme is a great hack these days. It used to be good in the past as a way to have multiple screens, but now it's something that needs to be completely rewritten (several Linux developers have shown interest in developing a better scheme for 2.5.x series). The main issue is that VT code doesn't understand that we may have multiple input and output devices which therefore may be completely independent. There's no way to associate a given set of VTs for each hardware so Linux kernel would know which VTs can be used simultaneously. If we dispatch multiple instances of XFree86 they would be on different VTs and the Linux kernel will inform them of all VT switching stuff. A switched out (graphic) VT must not use the hardware as it would normally mess with the other active VT, but this is no more true as we have two independent video cards.
Keyboard support - Multiple mouses on X are already a reality as we may specify the "device" option for each one. Unfortunately, the keyboard driver is still deeply rooted at XFree86 core, it's not a separated module and access console I/O functions to read the scancodes. Each XFree86 instance would have their keyboard access halted by VT switching. Besides, Linux is still lacking support for multiple keyboards in a well defined way. Let's wait for 2.5.x tree to see what will be done...
My solution
My hack is surely not the best one, I know thousands of things that could be better implemented in XFree86 and Linux Kernel to support true dual-head (and dual-input) in a clean way. But it works for me. Don't blame me if you spend your money and time buying videocards, monitors, keyboards, mouses and it doesn't work. You've been warned.
Although I would love to see XFree86 supporting simultaneous layouts (without another instance) and a brand new keyboard driver, I don't have the necessary understanding of the project to implement it by myself. Anyway, my regards to the XFree86 developers for this great piece of software!
My idea is to have two instances of XFree86. The first will be using a normal XFree86 server, it will initialize the main video card and attach it to a VT. It will also use the standard system AT keyboard and something (PS/2, serial, USB emulated as PS/2, whatever you want) as a mouse.
The second instance of XFree will be my modified X server. It does not support VT switching at all because it's been used to control a hardware that is not normally used by any other VT. Read my lips, this is very important: The video card can't be the primary one, the mouse can't be the same used by gpm and the keyboard must be USB and must not generate scancodes to the normal Linux console!
As the keyboard doesn't look like a normal AT keyboard (no keys to standard console) the keyboard driver of my modified X server must take care of USB events translating them to normal scancodes.
Procedure (step by step)
1) You need to get XFree 4.0.x (RedHat 7.0 and a lot of recent distros comes with it) and configure it for two video cards and monitors. I suggest that you first try it with Xinerama extension following this HowTo: http://linuxdocs.org/HOWTOs/Xinerama-HOWTO.html
Then modify your XF86Config or XF86Config-4 to separate your screens in two layouts, instead of using them with Xinerama extension. Don't know what I am talking about? Then it's time to read XF86Config, do a ``man XF86Config''
With two layouts your XF86Config should look like this:
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "ServerLayout"
Identifier "Layout1"
Screen 0 "Screen1"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
# this is for supporting deadkeys
Option "XkbRules" "xfree86"
Option "XkbModel" "pc101"
Option "XkbLayout" "us_intl"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/mouse"
Option "Protocol" "IMPS/2"
Option "Emulate3Buttons" "off"
Option "ZAxisMapping" "4 5"
EndSection
Section "Monitor"
Identifier "Plex17"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 31.5 - 79.0
VertRefresh 50-90
EndSection
Section "Monitor"
Identifier "Syncmaster3"
HorizSync 31.5 - 79.0
VertRefresh 50-70
EndSection
Section "Device"
Identifier "FireGL 1000 PRO"
Driver "glint"
BusID "pci:1:0:0"
BoardName "Unknown"
EndSection
Section "Device"
Identifier "Voodoo"
Driver "glide"
BusID "pci:0:12:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "FireGL 1000 PRO"
Monitor "Plex17"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1024x768"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen1"
Device "Voodoo"
Monitor "SyncMaster 3"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "800x600"
EndSubSection
EndSection
This should be trivial to do because it's almost the same as Xinerama configuration but with two layouts. Then switch your box to runlevel 3 (init 3) and try both layouts, one at a time:
# XFree86 -layout Layout0
# XFree86 -layout Layout1
Pay attention to BusID settings as described in howto. Note that a dualhead board (like Matrox G400) should NOT work through the next steps, as we will be using 2 instances talking to the same hardware. But I haven't tried myself (I'd be happy to try it if any reader wants to donate such video card...).
Not all video cards can be used with XFree86 dualhead support. Don't email me saying that you couldn't get your cards to work up to here or you will burn in hell! Read the Xinerama HowTo instead, thanks.
2) Plug your second mouse on the system and configure XF86Config to use it in the second layout. This mouse must not be used by any other program, like gpm. XF86Config will look like this (only the changed sections):
Section "ServerLayout"
Identifier "Layout1"
Screen 0 "Screen1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Device" "/dev/ttyS1"
Option "Protocol" "Microsoft"
EndSection
Again, test this layout to make sure it's working.
3) Get Linux Kernel 2.4.0 so we can play with USB support. Some 2.2.x kernels may work as they have backported USB support, but in doubt, stick with 2.4.0.
In the kernel configuration, enable USB support (CONFIG_USB) and keyboard (either CONFIG_USB_HID or CONFIG_USB_KBD if your don't need USB mouse support). You must enable "input core support" (CONFIG_INPUT) and MUST NOT enable "keyboard support" (CONFIG_INPUT_KEYBDEV) as we don't want the USB one to be the system keyboard. Also enable "event interface" (CONFIG_INPUT_EVDEV) as I will use it to receive scancodes.
Compile and install the kernel. Now plug your USB keyboard, once the kernel enters you should not see any pressed keys from it at the console. Now try reading the keyboard events (assuming the keyboard is the only USB device you have):
# cat
You should see some garbage on the screen as you type. That's all right, your keyboard is working. If you don't see anything or get "No such device", something is wrong with your USB system. Read Documentation/usb in your kernel sources for more information.
4) Get the sources of your XFree86 4.0.x if you haven't already done so. The sources are available from www.xfree86.org. There should be 3 or 4 big
Expand the tree and apply my patch, which can be downloaded here (4.0.1) and here (4.0.2). Follow the instructions from the package to build the X server (make World). You should get a new XFree86 executable on directory xc/programs/Xserver. Copy it to your
Or if you like the easy way, try one of my XFree86-2nd servers (compiled against glibc-2.1):
XFree86-4.0.1-2nd.gz
XFree86-4.0.2-2nd.gz
This server supports only USB keyboards and do not grab a VT. The only VT code it has is to switch to a given console through XFree86-2nd vtxx parameter.
Applying the patch is intended only for developers that can help me improving this scheme. It will also require you hundreds of MB of disk space. If my provided X servers doesn't work with your system there's little I can do about it. If you can, try to discover the problem and fix it.
5) Modify the second layout to use the USB keyboard. This will require you to use the protocol "usbev" I created and specify the
Section "ServerLayout"
Identifier "Layout1"
Screen 0 "Screen1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Keyboard1"
Driver "keyboard"
Option "Protocol" "usbev"
Option "Device" "/dev/input/event0"
EndSection
Now try this X server with the command:
# XFree86-2nd -layout Layout1
It should initialize your second video card, the second mouse and the usb keyboard without interfering with your console. You can even do this from a xterm window inside your running X server. Yes! It works! Now move on to the grand finale...
6) If you use gdm as display manager and to provide you a graphical login, you can edit the file
[servers]
0=/usr/bin/X11/XFree86-2nd -delay -layout layout1 vt07
1=/usr/bin/X11/X vt07
Getting this one to work may be a major challenge. It took me a lot of trial and error until I got this stable configuration. I had to add a option "-delay" (my hack) to cause a 10 second delay at one of the servers so they would not initialize the hardware at the same time. I don't know why this is needed. Playing with the order they are initialized (by exchanging 0= and 1=) also does the trick.
Known Bugs
This thing mess up with my text console. I have to switch between the VTs a couple of times before the text looks good again. Fell free to give me a solution.
Also a main problem may be that the whole thing does not work with other hardware and you may be wasting your time reading all this. But the idea is here and I can guarantee that it worked for me. So it must be some little issue that I'm sure will be quickly resolved by another developer somewhere....
Updates
Price study
Brad Midgley pointed that support for Matrox G400 and similar dualhead cards should be possible using framebuffer interface. I still don't have the hardware to do any tests on this, but if you want to try please note that I may have removed something important for framebuffer from the init routines. Please check for any mistakes the patch might have. Any updates on this issue are greatly appreciated...
Daniel Tarbuck reported success with XFree86 4.1.0 with an additional patch:
"I have implemented your patch on XF86 4.1.0 and I found that I had to comment out the following line:
in xc/programs/Xserver/hw/xfree86/common/xf86pciBus.
I don't know what the problem was, and I don't know why my fix worked for me. I also don't know if there will be serious problems as a result of my fix.
Here is a few details on my setup:
primary card: ATI Mach64 GT+ (PCI)
secondary card: S3 VirgeDX (AGP)
kernel 2.4.5 (Redhat 7.0)"
Jan "Yenya" Kasprzak did some tests with Daniel's patch and got two hardware configurations to work:
S3 ViRGE VX PCI (primary)
SIS 6xxx AGP (secondary - USB keyb.)
I was not able to set up the AGP card as primary.
Matrox G450 AGP (primary)
S3 ViRGE VX PCI (secondary - USB keyb.)
I was not able to set up the S3 card as primary.
Yenya wrote: "I still have one problem: IMHO the above patch should be applied to primary X server as well, because otherwise it locks up the secondary card when the user on the primary display logs out."
Another success report, thanks Nathan Hoult for the information:
"Geforce2pro 64meg AGP (MSI)-slave,AGP" and a "TNT 16 meg (Diamond Viper550)-master,PCI"
Nathan wrote: "I used the official NVIDIA drivers too and get OpenGL to work on both quite well... well except i have permission problems all over the place but just got it working anyhow." (Mandrake8.1, XFree 4.1, linux 2.4.16)
I rebuilt the patch against XFree86-4.1.0 (from rawhide sources XFree86-4.1.0-0.9.11.src.rpm). Applying Daniel's patch to both X servers, now we have XFree86-1st and XFree86-2nd (I hope everybody knows how to use them!).
The 2nd server is using usbev keyboard as usual (thanks to Vojtech Pavlik help now we should have keyboard leds working). Please note that binary files where compiled under RedHat 7.1, so you need glibc >= 2.2.2.
Precompiled XFree86 4.1.0-1st server.
Precompiled XFree86 4.1.0-2nd server.
Patch for XFree86 4.1.0-1st
Patch for XFree86 4.1.0-2nd
Notes:
1) This binaries were tested over RedHat Linux 7.1. The gdm provided by ximian gnome desktop refused to work with my dual login, I had to downgrade to RH7.1 gdm package.
2) My usbev keyboard got wrong key mapping if I don't specify XkbModel and XkbLayout. Something seems to have changed since 4.0.2, so don't forget these settings (specially if you get a working server with no keyboard...).
3) When testing the XFree86-4.1.0-2nd inside the first instance I got errors of xauthorization. Calling the 2nd server with "-ac" may help.
4) Usb keyboard leds still don't work. I will debug it as soon as I have time to do so, there must be some mistake.
Matrox G450 DH users should read this.
http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/
Just don't do it. Use a little sense.
TW doesn't offer you ANY web space? Put your aquarium pictures in your area on their web servers where there's more bandwidth for others to download them. Then you'll only use your own bandwidth when you update your site. You can then turn off your PC or reboot once in a while without taking your website offline. Use your broadband to enable your home PC to upload and control your web site from home, or to fix it automatically if it gets defaced.
If you want the adventure of running your "own" server, you can get a shell account on a VMS, Linux, Solaris or BSD host, usually for a one-time fee of $10 to $50. They won't give you root access, but you can install software in your own a account and run light servers like boa as a background process. If your cable or DSL goes out, or you move, or you switch ISPs, the site will stay up.
Or almost as good, use one of those "free" web hosting companies. Both Tripod and ProHosting let you write your own CGIs in perl. That gives you most of the fun of your own server without all the crap.
Then there's the security risk. Running a server out of your house is the best way to get your machine cracked. More than likely you will never know or notice if the cracker is any good. Personal servers are different -- you can limit the allowed IPs to your work's proxy server and/or use VPN to make sure you and only you can use your machine remotely. If you configure a server wrong (it only takes 1 mistake) or the software has exploitable bugs (and ALL software has bugs), you just end up creating habitat for crackers to take up root.
Besides which the performance of broadband-hosted websites just plain sucks. Your site might become more popular if it's consistently available and fast. Good luck.
If you use an external 1394/Firewire/iLink or USB hard disk, it's just an ATA disk inside. Both 1394 and USB support hot-plugging, and linux support (at least for generic devices like ATA disks) is fairly mature. As for performance, 1394 is supposedly 400 Mb (bits) per second and USB 2.0 is 480 Mb/s. You need to buy a USB 2.0 PCI card for your PC, but they aren't too much. USB 2.0 controllers are also called "EHCI". USB 2.0 devices work with USB 1.1 controllers at the standard 12 Mb/s. Search the web for "USB ATA enclosure" or "Firewire ATA enclosure" and you should find something. For portable disks, you're more likely to find USB ports on a PC, and I suspect 1394 devices are going to seem really overpriced compared to USB 2.0. But YMMV.
http://www.linux-usb.org
(you're on your own for 1394)
I know you spent money on those removable ATA caddies, but if all you want is a hot-swap ATA disk, there are other ways of getting there that are designed to do what you're after.