Worse, it's New!Yahoo. Forced rollout of an Awkward New!Ponies look, theme-above-thought, CSS-uber-alles which I KNOW wasn't retro-tested because the topic bullet-list insists on masking the upper-left even of this TEXTAREA (Yeah, this is FF2, which is what this distro supports -- can't imagine how broken earlier browsers look here)... I know I'm pissing-and-moaning here, but seriously, this stuff's broken. I can't wait til http://www.alterslash.org/ has caught up with the changes so I can go back to reading Slashdot, because I sure can't here.
"Glass cubicle walls will cut down on noise like a cubicle would, but does not give as much of the feeling of being in a box as standard cubicles. They allow unobstructed view of the video-wall and you can write on them with grease pens."
They also allow an unobstructed view of things you really don't want to stare at such as bright lights.
My experience is from the dev cubicle floor, not a NOC, but it applies at least as much to monitoring a screen or screens as to staring through the screen into the code-realm. Bad placement plus a low ceiling meant that I had a bright fluorescent fixture showing just above the cubicle corner. I tried sunglasses, moving the monitor, etc. and ended up roofing that corner of the cube with cardboard, just so I didn't have that light stabbing my eye while I was trying to dive into my code. Glass cubes will exacerbate this into a no-escape situation. Nobody's going to want to keep staring at a view which is actually painful.
Even if you don't go with glass, before you sign off on that build, have a short person and a tall person test out every station for glare within scope of view. Be prepared to hood some of those lights to keep them out of people's eyes.
Someone with a schematic of the car should have a look to see how those signals are generated and routed. If they go through the same microcontroller...
In my Chrysler-made minivan, I've learned that headlights have to be turned off BEFORE the engine is stopped. If I switch the lights off first (two steps on a rotary knob), things work fine no matter how fast I twist that knob; both switch-events are caught.
If I turn the key first, though, turning off the engine before shutting off the headlights, both headlight-switch events will be missed by whatever MCU drives the headlight relays. The lights are on, the door is open, the engine is off, but I get no chimed 'lights left on' alert unless I put that switch through another full-on-full-off cycle to resync the micro with the physical state of things. My guess is that the same MCU is responsible for a number of tightly timed engine-shutdown sequence events during which it has to mask off switch interrupts, which is lousy embedded design on Chrysler's part.
Nothing says that the same crappiness of design isn't evident in Toyota's machines, in which case the timing of those brake lights coming on means exactly nothing: that pedal might have been pressed for some seconds before the MCU got around to noticing.
All the time I spent vacuuming out dead roaches from my computer cases... wasted. If I'd mashed them flat instead, obviously I'd have had a lot fewer live bugs to eliminate from my code as a result.
There's nothing like a screen that even remotely appears to respond to viewer interaction to get children involved. They won't tell you this, of course, but you'll know immediately by the trails of peanut butter, jelly, ketchup and various bodily emissions left as bookmarks in their favorite places on your console. Trust me on this.
Your ability to read and measure low-level signals will depend on a low noise floor in your 'scope. How low-level will your lab be interested in displaying? Make sure the devices you're considering aren't displaying significant switching noise and sampling artifacts in those ranges. My unpleasant surprise (admittedly, a decade old -- things will have hopefully improved by now) was a digital Tektronix where the lowest ranges, right where I was trying to look at input stages, were too grassy for my purposes, and that unit was a self-contained instrument. I keep a lowly refurbished Tektronix 465 on hand for analog work for just that reason.
Not quite; sorry. Part 97, the part of the FCC rulebook governing amateur radio, forbids the following:
- broadcasting (the tolerated exception being QST's from W1AW and the like, because they're intended only for licensed amateurs)
- music-playing
- commercial programming, including commercials
Ham radio is intended primarily for point-to-point or point-to-net communications where there's a live operator at each transmitter, and the only audience is other hams (you as a shortwave listener or scanner user can listen in, but they're not supposed to be talking to you). The exceptions are tolerance for automata like FM repeaters and packet BBSes, and even then there's supposed to be a control operator on frequency or around the station who can take the transmitter off the air if someone starts misusing it for things like broadcasting.
I've seen this one, and the cause for it, in equipment I've acquired.
That "fat kind of connector, like a ps/2 plug but much bigger" is a 5-pin DIN plug. The mechanical forces one of those connectors can couple into the mating jack without crumpling can sometimes tear the mating jack loose from its soldering, especially if the motherboard manufacturer doesn't spec a jack with mounting tabs, or doesn't provide solderable plated feedthrus for them, and especially if the solder in the waveflow soldering machine was getting a bit tired when that board went through.
With one (or more) contacts loose in its feedthru, and mating surfaces oxiding on exposure to air, you sometimes do have to treat it like a knife-switch, moving it back and forth to make it self-wipe and make electrical contact.
The real fix, of course, is touch-up soldering of the loosened contacts, but that's a skill to develop elsewhere, not on a computer you care about. The next best fix, once you get the connection working, is to tie down the cable so it can't move from that position.
These schools (and, eventually, all others) are going to have to ban all RIAA recordings, in ANY format including CD and tape, from their campuses, with violations subject to immediate seizure and disposal. That includes blocking any radio feeds and frequencies that carry their tunes. That's the only way to end the legal exposure to RIAA racketeering.
There's plenty of good music out there that isn't RIAA-tainted. Blanket-banning the tainted stuff will be a GOOD thing.
Syndrome: You have a Compact Fluorescent lamp powered through an X10 Appliance Module (Am486 or equivalent). You command the X10 module to turn off power to the CF lamp, and it does, but, after a second or two, it turns right back on.
This is repeatable, consistent behavior when the CF lamp is the only load on the X10 module, but things behave properly (off means OFF) when you plug an incandescent lamp into the module in parallel (low-wattage, 7W and up, will fix this behavior, but that's 7W of power wasted on heating up a resistor until it glows). Oh, and, to limit this to something about which I have direct knowledge, your local power mains are 110VAC, not 220VAC, although all of this except for the module model number may directly apply to the 220VAC version as well for all I know.
Cause: The X10 module has a "local sense" feature intended to allow you to command the module to turn on by physically switching the controlled device off-and-on; the CF lamp is triggering this feature.
The Compact Fluorescent lamp, as a load, does not behave like a simple resistor, instead its loading fluctuates at its own flash rate. It contains an electronic circuit in its base which rectifies and filters mains power to feed an oscillator, which then flashes the fluorescent lamp at a rate much higher than 60Hz. When the power is switched off, there is enough power stored in the filter's capacitor for the oscillator to trigger the local-sense circuit in the module.
Cure: Disable the X10 module's "local sense" feature.
There are several writeups on this around the Net; a quick search ("Am486 local sense") turned up this pageand this one, both of which discuss several forms of X10/CF misbehavior and point to how-tos specific to the Am486 module. If your module is different, search using its nearest-equivalent X10-brand model number (Radio Shack, for one, sells house-branded X10 modules with different numbers but obvious similarities). Remember, you are dealing with mains power, which can kill people and set fire to things if abused; use caution, patience, and the right tools here.
It's like any other field of hackery: if you want its benefits, even those you dream up, you'll tweak it until it delivers.
I'm somewhat hard to wake up at the best of times. Not good when there are kids to be gotten up, fed and clothed and off to catch the schoolbus on time. I use a combination of cron and X10 stuff to turn on lights before the alarm clock (so I'm almost awake), then play WAV sounds as timing chimes (even a Morse countdown to when each schoolbus is due to go by). In the evening, the same system turns on lights, reminds me to get up and fix dinner, drops the kids' Net access with firewall rules and time-chimes bath- and bed-times. After bedtime, a light-killer script runs for awhile to make those bedroom lights stay off.
To get my relatively simple system working right, I've gone so far as to open up X10 relay modules and clip out the local-sense resistor, so the Compact Fluorescent lamps I drive with them will stay off, and throw together a CGI buttons page on my LAN specifically to drive X10 units.
You can take it a lot further than I have (look up MisterHouse to see a comprehensive system that even yields fuel savings), but, like anything else that's worthwhile to implement, it'll take some money, some time and some learning; it's up to you where that fits into your scale of values.
If you're new to Windows, you're used to an honest filesystem that isn't actively trying to hide things from you and take control away from you. Ztree for Windows gives you back some of that control and transparency.(Ob.Disclaimer: no connection other than having bought and used it.)
Back in the DOS days, there was Xtree, XtreePro and then XtreeGold from Executive Systems. This was a character-mode file-manager/navigator-plus-toolbox. Symantec bought it and promptly took it off the market. Today, XtreeGold is memorialized at the Xtree Fan Page; go there to get a feel for the program. The original Xtree programs are now quite dated -- they can't handle FAT32, much less NTFS.
ZtreeWin is a clean reimplementation of XtreePro (actually by now it's most of the way from XtreePro to XtreeGold in that development effort) for Win32. It's shareware (but, hey, it's for Windows, where, FLOSS aside, it's rare that you're not expected to pay for every little thing). In my time using it on Windows (I'm pretty much solely on Linux now), I got quite pleased with how much Windows didn't get in my way because I used it; I considered it indispensable.
If you need to find a specifc pic, fire up Picassa (Windows only sadly) and scan through for the picture.
gqview on Linux/UNIX will do just fine for this. Flip through the pix (it'll do the flipping for you in slide-show mode), then right-click the chosen cluster to "edit in the GIMP" to crop down to just the one you want.
Copy Protection failed back when it was just a laser burn on a floppy. It inconvenienced the best customers; the rest of those who were interested in the product just bypassed it. (Ob.Disclaimer: a decade or two later, and I'm *still* pissed at the defective-floppy-lockout on my copy of ThinkTank. Generalization: expect pissed-off customers to have *long* memories.)
DRM will fail for the same reasons, taking with it those who rely on it to prop up their business. It's damage, and us pissed-off ex-customers are, with practice, getting real good at routing around that.
The one thing I *don't* have is a graphical net explorer that wlil also show me the net in real time in a format that shows the network structure with traffic, etc. 3M has a tool, but it is only so-so (last time I tried it) and rather slow on the older Windows laptop I have available. I'd love to have a good FOSS app for this, preferably for use under Linux, but Windows is aceptable.
I use etherape in combination with iptraf for this. Both are open-source Linux apps. Etherape uses Gtk/Gnome widgets; iptraf is a console app that runs nicely in an ssh'd xterm from the firewall. I'm not sure what level of depiction you're looking for, but these two are worth a try regardless IMO.
You should know that you can buy or build an extension cable for the headphone cord. The extra length means that you can route the cable to fit your workspace, rather than having to deal with a cord which is stretched across the most annoying part of your keyboard. The extra length is also insurance against tugging the headphone cord leads loose within the plug, or (worse) within the headphone set itself. The thinner and more limply flexible the headphone cord is, the thinner and more fragile the individual copper strands within it are likely to be; minimizing wear and tear on them is common sense.
Form a loose knot with the two cables around the junction of the plug and the inline jack, and they won't pull apart. Keep the headphone cord up off the floor, and it'll be the extension cable that takes the punishment from having the desk chair's rollers pass over it. When it breaks down, either shorten it to remove the damaged part (if you're handy with a soldering iron and your time is cheap), or buy a new one. If the longer run of the combined cables picks up buzz, look into getting a shielded extension cable (the cheap ones aren't).
In my experience, cord problems start much earlier than ear-cushion problems, though I've had those too. YMMV; I might just be a more abusive user.
trust n. 9. A combination of firms or corporations for the purpose of reducing competition and controlling prices throughout a business or industry. --See Synonyms at monopoly.
As long as you keep that definition in mind when about anything having to do with Microsoft or Windows, their meaning is quite clear.
Plus, a new keyboard shortcut permits the user to return to a saved cursor position.
Not that I'm not very glad that OOo is here and getting better, but...
this catches them up to WordStar 2.6 on CP/M, circa, what, 1978? (^K1..9 to set one of the markers, ^Q1..9 to go there, ^Qv to get back to where you were before a file operation). Yay team!
The 'telephone' part is the problem, in my experience.
I've driven while conversing on CB and ham radio, both in a car and on a motorcycle, without any real problem or disruptive diversion of attention. I've also tried to have a brief conversation on a normal handheld cell phone, and scared myself badly at just how disrupted my normal driving skills were when I was doing it, even at low speeds.
IMO, the problem is a dangerous separation of 'psychological spaces', something you can't afford when you're driving. Talking on the phone means conversing within an isolated 'space' and focusing on the voice you're hearing in one ear. The fact that your voice is replicated within that space so you'll control your voice amplitude makes the isolation more complete. That's normal for talking on a telephone, and focusing on that isolated sound source is something we've all learned to do well, but when you're driving you can't afford to do that.
The solution, at least in my case, is to put the conversation in the driving space, using a hands-free cradle for the cell phone. The speaker within the cradle is loud enough to put the other party's voice in the car's cabin at a conversational volume, just as if it was a voice coming in on the radio, and a ceiling-mounted microphone picks up my normally-spoken responses, less obtrusively than if I was using a push-to-talk mike. This brings the conversation into the driving space where it belongs, to compete for attention along with all the sounds of the road and the other people in the vehicle. When something important shows up, you can ignore the phone conversation long enough to deal with it, no problem. More important, your attention is not refocused away from the driving environment to that conversation in one ear, so you're not having to context-switch between that and driving, and that saves you seconds of focused response time, and maybe lives.
Slashdot Mirror
Worse, it's New!Yahoo. Forced rollout of an Awkward New!Ponies look, theme-above-thought, CSS-uber-alles which I KNOW wasn't retro-tested because the topic bullet-list insists on masking the upper-left even of this TEXTAREA (Yeah, this is FF2, which is what this distro supports -- can't imagine how broken earlier browsers look here)... I know I'm pissing-and-moaning here, but seriously, this stuff's broken. I can't wait til http://www.alterslash.org/ has caught up with the changes so I can go back to reading Slashdot, because I sure can't here.
I'm surprised I didn't hear about this via email direct marketing!
"Glass cubicle walls will cut down on noise like a cubicle would, but does not give as much of the feeling of being in a box as standard cubicles. They allow unobstructed view of the video-wall and you can write on them with grease pens."
They also allow an unobstructed view of things you really don't want to stare at such as bright lights.
My experience is from the dev cubicle floor, not a NOC, but it applies at least as much to monitoring a screen or screens as to staring through the screen into the code-realm. Bad placement plus a low ceiling meant that I had a bright fluorescent fixture showing just above the cubicle corner. I tried sunglasses, moving the monitor, etc. and ended up roofing that corner of the cube with cardboard, just so I didn't have that light stabbing my eye while I was trying to dive into my code. Glass cubes will exacerbate this into a no-escape situation. Nobody's going to want to keep staring at a view which is actually painful.
Even if you don't go with glass, before you sign off on that build, have a short person and a tall person test out every station for glare within scope of view. Be prepared to hood some of those lights to keep them out of people's eyes.
Someone with a schematic of the car should have a look to see how those signals are generated and routed. If they go through the same microcontroller...
In my Chrysler-made minivan, I've learned that headlights have to be turned off BEFORE the engine is stopped. If I switch the lights off first (two steps on a rotary knob), things work fine no matter how fast I twist that knob; both switch-events are caught.
If I turn the key first, though, turning off the engine before shutting off the headlights, both headlight-switch events will be missed by whatever MCU drives the headlight relays. The lights are on, the door is open, the engine is off, but I get no chimed 'lights left on' alert unless I put that switch through another full-on-full-off cycle to resync the micro with the physical state of things.
My guess is that the same MCU is responsible for a number of tightly timed engine-shutdown sequence events during which it has to mask off switch interrupts, which is lousy embedded design on Chrysler's part.
Nothing says that the same crappiness of design isn't evident in Toyota's machines, in which case the timing of those brake lights coming on means exactly nothing: that pedal might have been pressed for some seconds before the MCU got around to noticing.
*poof*
You're a sandwich.
All the time I spent vacuuming out dead roaches from my computer cases... wasted. If I'd mashed them flat instead, obviously I'd have had a lot fewer live bugs to eliminate from my code as a result.
There's nothing like a screen that even remotely appears to respond to viewer interaction to get children involved. They won't tell you this, of course, but you'll know immediately by the trails of peanut butter, jelly, ketchup and various bodily emissions left as bookmarks in their favorite places on your console. Trust me on this.
Not exactly my preferred mind-picture of "open source", thank you.
Who should we expire next?
Your ability to read and measure low-level signals will depend on a low noise floor in your 'scope. How low-level will your lab be interested in displaying? Make sure the devices you're considering aren't displaying significant switching noise and sampling artifacts in those ranges. My unpleasant surprise (admittedly, a decade old -- things will have hopefully improved by now) was a digital Tektronix where the lowest ranges, right where I was trying to look at input stages, were too grassy for my purposes, and that unit was a self-contained instrument. I keep a lowly refurbished Tektronix 465 on hand for analog work for just that reason.
Judging by the intellectual caliber of their most vocal constituents, it seems to be working.
...HAM Radio. The problem has been solved.
Not quite; sorry. Part 97, the part of the FCC rulebook governing amateur radio, forbids the following:
- broadcasting (the tolerated exception being QST's from W1AW and the like, because they're intended only for licensed amateurs)
- music-playing
- commercial programming, including commercials
Ham radio is intended primarily for point-to-point or point-to-net communications where there's a live operator at each transmitter, and the only audience is other hams (you as a shortwave listener or scanner user can listen in, but they're not supposed to be talking to you). The exceptions are tolerance for automata like FM repeaters and packet BBSes, and even then there's supposed to be a control operator on frequency or around the station who can take the transmitter off the air if someone starts misusing it for things like broadcasting.
I've seen this one, and the cause for it, in equipment I've acquired.
That "fat kind of connector, like a ps/2 plug but much bigger" is a 5-pin DIN plug. The mechanical forces one of those connectors can couple into the mating jack without crumpling can sometimes tear the mating jack loose from its soldering, especially if the motherboard manufacturer doesn't spec a jack with mounting tabs, or doesn't provide solderable plated feedthrus for them, and especially if the solder in the waveflow soldering machine was getting a bit tired when that board went through.
With one (or more) contacts loose in its feedthru, and mating surfaces oxiding on exposure to air, you sometimes do have to treat it like a knife-switch, moving it back and forth to make it self-wipe and make electrical contact.
The real fix, of course, is touch-up soldering of the loosened contacts, but that's a skill to develop elsewhere, not on a computer you care about. The next best fix, once you get the connection working, is to tie down the cable so it can't move from that position.
...and I, for one, can't wait to see it happen.
These schools (and, eventually, all others) are going to have to ban all RIAA recordings, in ANY format including CD and tape, from their campuses, with violations subject to immediate seizure and disposal. That includes blocking any radio feeds and frequencies that carry their tunes. That's the only way to end the legal exposure to RIAA racketeering.
There's plenty of good music out there that isn't RIAA-tainted. Blanket-banning the tainted stuff will be a GOOD thing.
Syndrome: You have a Compact Fluorescent lamp powered through an X10 Appliance Module (Am486 or equivalent). You command the X10 module to turn off power to the CF lamp, and it does, but, after a second or two, it turns right back on.
This is repeatable, consistent behavior when the CF lamp is the only load on the X10 module, but things behave properly (off means OFF) when you plug an incandescent lamp into the module in parallel (low-wattage, 7W and up, will fix this behavior, but that's 7W of power wasted on heating up a resistor until it glows). Oh, and, to limit this to something about which I have direct knowledge, your local power mains are 110VAC, not 220VAC, although all of this except for the module model number may directly apply to the 220VAC version as well for all I know.
Cause: The X10 module has a "local sense" feature intended to allow you to command the module to turn on by physically switching the controlled device off-and-on; the CF lamp is triggering this feature.
The Compact Fluorescent lamp, as a load, does not behave like a simple resistor, instead its loading fluctuates at its own flash rate. It contains an electronic circuit in its base which rectifies and filters mains power to feed an oscillator, which then flashes the fluorescent lamp at a rate much higher than 60Hz. When the power is switched off, there is enough power stored in the filter's capacitor for the oscillator to trigger the local-sense circuit in the module.
Cure: Disable the X10 module's "local sense" feature.
There are several writeups on this around the Net; a quick search ("Am486 local sense") turned up this pageand this one, both of which discuss several forms of X10/CF misbehavior and point to how-tos specific to the Am486 module. If your module is different, search using its nearest-equivalent X10-brand model number (Radio Shack, for one, sells house-branded X10 modules with different numbers but obvious similarities).
Remember, you are dealing with mains power, which can kill people and set fire to things if abused; use caution, patience, and the right tools here.
It's like any other field of hackery: if you want its benefits, even those you dream up, you'll tweak it until it delivers.
I'm somewhat hard to wake up at the best of times. Not good when there are kids to be gotten up, fed and clothed and off to catch the schoolbus on time. I use a combination of cron and X10 stuff to turn on lights before the alarm clock (so I'm almost awake), then play WAV sounds as timing chimes (even a Morse countdown to when each schoolbus is due to go by). In the evening, the same system turns on lights, reminds me to get up and fix dinner, drops the kids' Net access with firewall rules and time-chimes bath- and bed-times. After bedtime, a light-killer script runs for awhile to make those bedroom lights stay off.
To get my relatively simple system working right, I've gone so far as to open up X10 relay modules and clip out the local-sense resistor, so the Compact Fluorescent lamps I drive with them will stay off, and throw together a CGI buttons page on my LAN specifically to drive X10 units.
You can take it a lot further than I have (look up MisterHouse to see a comprehensive system that even yields fuel savings), but, like anything else that's worthwhile to implement, it'll take some money, some time and some learning; it's up to you where that fits into your scale of values.
If you're new to Windows, you're used to an honest filesystem that isn't actively trying to hide things from you and take control away from you. Ztree for Windows gives you back some of that control and transparency.(Ob.Disclaimer: no connection other than having bought and used it.)
Back in the DOS days, there was Xtree, XtreePro and then XtreeGold from Executive Systems. This was a character-mode file-manager/navigator-plus-toolbox. Symantec bought it and promptly took it off the market. Today, XtreeGold is memorialized at the Xtree Fan Page; go there to get a feel for the program. The original Xtree programs are now quite dated -- they can't handle FAT32, much less NTFS.
ZtreeWin is a clean reimplementation of XtreePro (actually by now it's most of the way from XtreePro to XtreeGold in that development effort) for Win32. It's shareware (but, hey, it's for Windows, where, FLOSS aside, it's rare that you're not expected to pay for every little thing). In my time using it on Windows (I'm pretty much solely on Linux now), I got quite pleased with how much Windows didn't get in my way because I used it; I considered it indispensable.
gqview on Linux/UNIX will do just fine for this. Flip through the pix (it'll do the flipping for you in slide-show mode), then right-click the chosen cluster to "edit in the GIMP" to crop down to just the one you want.
DRM is Copy Protection.
Copy Protection failed back when it was just a laser burn on a floppy. It inconvenienced the best customers; the rest of those who were interested in the product just bypassed it. (Ob.Disclaimer: a decade or two later, and I'm *still* pissed at the defective-floppy-lockout on my copy of ThinkTank. Generalization: expect pissed-off customers to have *long* memories.)
DRM will fail for the same reasons, taking with it those who rely on it to prop up their business. It's damage, and us pissed-off ex-customers are, with practice, getting real good at routing around that.
For Real.
The one thing I *don't* have is a graphical net explorer that wlil also show me the net in real time in a format that shows the network structure with traffic, etc. 3M has a tool, but it is only so-so (last time I tried it) and rather slow on the older Windows laptop I have available. I'd love to have a good FOSS app for this, preferably for use under Linux, but Windows is aceptable.
I use etherape in combination with iptraf for this. Both are open-source Linux apps. Etherape uses Gtk/Gnome widgets; iptraf is a console app that runs nicely in an ssh'd xterm from the firewall. I'm not sure what level of depiction you're looking for, but these two are worth a try regardless IMO.
You should know that you can buy or build an extension cable for the headphone cord. The extra length means that you can route the cable to fit your workspace, rather than having to deal with a cord which is stretched across the most annoying part of your keyboard. The extra length is also insurance against tugging the headphone cord leads loose within the plug, or (worse) within the headphone set itself. The thinner and more limply flexible the headphone cord is, the thinner and more fragile the individual copper strands within it are likely to be; minimizing wear and tear on them is common sense.
Form a loose knot with the two cables around the junction of the plug and the inline jack, and they won't pull apart. Keep the headphone cord up off the floor, and it'll be the extension cable that takes the punishment from having the desk chair's rollers pass over it. When it breaks down, either shorten it to remove the damaged part (if you're handy with a soldering iron and your time is cheap), or buy a new one.
If the longer run of the combined cables picks up buzz, look into getting a shielded extension cable (the cheap ones aren't).
In my experience, cord problems start much earlier than ear-cushion problems, though I've had those too. YMMV; I might just be a more abusive user.
From AHD:
trust n.
9. A combination of firms or corporations for the purpose of reducing competition and controlling prices throughout a business or industry. --See Synonyms at monopoly.
As long as you keep that definition in mind when about anything having to do with Microsoft or Windows, their meaning is quite clear.
Plus, a new keyboard shortcut permits the user to return to a saved cursor position.
Not that I'm not very glad that OOo is here and getting better, but...
this catches them up to WordStar 2.6 on CP/M, circa, what, 1978? (^K1..9 to set one of the markers, ^Q1..9 to go there, ^Qv to get back to where you were before a file operation). Yay team!
Probably. I wonder if that Psalm Pilot uses a KJV desktop...
The 'telephone' part is the problem, in my experience.
I've driven while conversing on CB and ham radio, both in a car and on a motorcycle, without any real problem or disruptive diversion of attention. I've also tried to have a brief conversation on a normal handheld cell phone, and scared myself badly at just how disrupted my normal driving skills were when I was doing it, even at low speeds.
IMO, the problem is a dangerous separation of 'psychological spaces', something you can't afford when you're driving. Talking on the phone means conversing within an isolated 'space' and focusing on the voice you're hearing in one ear. The fact that your voice is replicated within that space so you'll control your voice amplitude makes the isolation more complete. That's normal for talking on a telephone, and focusing on that isolated sound source is something we've all learned to do well, but when you're driving you can't afford to do that.
The solution, at least in my case, is to put the conversation in the driving space, using a hands-free cradle for the cell phone. The speaker within the cradle is loud enough to put the other party's voice in the car's cabin at a conversational volume, just as if it was a voice coming in on the radio, and a ceiling-mounted microphone picks up my normally-spoken responses, less obtrusively than if I was using a push-to-talk mike. This brings the conversation into the driving space where it belongs, to compete for attention along with all the sounds of the road and the other people in the vehicle. When something important shows up, you can ignore the phone conversation long enough to deal with it, no problem. More important, your attention is not refocused away from the driving environment to that conversation in one ear, so you're not having to context-switch between that and driving, and that saves you seconds of focused response time, and maybe lives.