The fun bit is that whilst the output is something like 117-0-117 the input is likely to be be either a single phase to ground or 120 degree 3 phase.
Yes. Usually (at least around here) your pole pig takes a ground and a live and gives you a split-secondary with two 117VAC hots and a neutral. In most neighbourhoods here you only have one 6.3kV line running around (and the other two phases are found on the main streets where they eventually head back to the substation) so yes -- you essentially have three noisy segments and the network data on any individual segment is a jumble of two possible phasings ("left side" and "right side" 117-VAC-originating).
The biggest problem is getting the signal through the pole pigs (can-type transformers on top of the hydro poles) -- they are big iron monstrosities that don't pass much past 1kHz or so due to their design.
One method which can be used is to simply wire some high voltage capacitors across the primary and secondary of the transformer -- they'll conduct at high frequencies (you tune this) and voila -- your signal jumps the transformer.
Of course, the problem with that is you're no longer isolated from the street-line voltages -- anywhere from about 6.9kV to 44kV, depending on who else is in your neighbourhood. The "right" way to do it is to have a line-powered conveter box at each pole pig which jumps the transformer optically, but that's expensive.
I've always been a fan of power line transmission. There's one in particular I was always amused by (no link handy) -- they claimed that by using a maser they could modulate the magnetic field without altering the voltage and current. I wonder what they think of Maxwell.
With all the transients, interference, noise, et cetera that are on power lines, this is going to be a big flop, mark my words.
Ever take a look at the PHY error counts on wireless? Hell on dialup for that matter? It's bad everywhere. That's why you use FEC techniques and trade data bandwidth for reliability.
The CF has two partitions on it: A 3M boot/config partition (Minix), and the rest is reserved for the cramfs (right now the cramfs takes about 10M).
The boot/config partition holds the kernel, GRUB, an initrd image and the system configuration. At boot time/conf is booted and the initrd is loaded and executed. It loads a few modules, mounts the cramfs and then pivot_roots so that cramfs is/. The cramfs boot process mounts/dev/pts, proc and/var (as a 4MB tmpfs), untars the basic/var system and runs init. The rest is a standard boot.
The advantage to this is that I don't waste RAM by decompressing the entire root filesystem; cramfs decompresses the program to RAM at execution time./var is the only point that is always rw but it's RAM anyway. Any time I need to do a config change I remount/conf as rw, make the change, and remount ro. If power is lost there is no fsck.
At present I have a complete firewall (including ssh, ipsec, the iptables 1.2.8 connection helpers (h323, ah/esp, etc.) and a full Perl install (I use it for SNMP, XMLRPC, integrity checking, etc.)) to fit in a 16M CF card. Cramfs is *awesome*:-)
In your situation I would probably do away with having the config in/conf, instead mounting it from the network (perhaps using BOOTP).
I'd love to know where to get a hold of a copy of the IRC transport or even a version of aim-t or yahoo-t which works with jabberd-1.4.2. The sf-like site for jabber apps is as dead as a doornail as far as offering files or getting at CVS.:-(
Seriously, we should be pushing for accountability, not a world were everybody's grandma has to learn C++ just to make sure that the big bad software company hasn't installed a trojan horse.
That's exactly the point. I can create a company that does service work which does analyze and approve security patches for its customers instead of blindly trusting the patch offerer. With OSS you can create accountability and not have to just trust the 800lb gorilla. Who watches the watchers? Other watchers. It's not one entity.
We use Rav Antivirus to scan the email for about 6000 dialup customers. It's about $600 + 20%/year for maintaining updates but we chose it specifically because it wasn't free: a virus scanner is absolutely no good when the updates aren't maintained. Pricing is based on number of domains and they have distributors all over the world.
They have versions to run qmail, sendmail, postfix, exchange server, etc., etc. and also have some user programs as well if you want. We've been very happy with it so far.
Re:As 3DFX learned the hard way
on
VisionTek Folds
·
· Score: 2
Why would a change to die size affect the PCB assembly line? Couldn't a 'pick-and-place' machine pick up a.13 um chip just as easily as a.18 um chip?
PCB stuffers don't place die for these chips -- they take the BGA package and solder them to the boards. You're picking up a device about 3/4" square and placing it. The technology inside that chip is.13um or.18um or whatever, not the packaged chip itself.
Do you think that Chinese is obfuscated because you can't read it? (assuming you don't know chinese...)
You're saying the winners of the IOPCC are not difficult to read? Christ man, I am glad you don't write code for me. Properly structured, well organized Perl is exceedingly clear. IOPCC entries are not.
I have an IDE-CF bay, a PCMCIA-CF adaptor and a USB-CF adaptor. Now linux sees the CF in the USB adaptor as a scsi disk but the others are straight IDE.
I cannot for the life of me get lilo to correctly install on CF when in my laptop, and then boot in another computer. The CF reports itself as the same CHS whether it is in my PCMCIA slot or in the final computer's primary master CF-IDE bay. I've tried linear, lba32, with and without compact.
Example setup: install CF into PCMCIA adaptor, install adaptor into laptop. Laptop sees/dev/hde. mount/dev/hde1./mnt/sbin/lilo -b/dev/hde -r/mnt. Lilo says it installs fine. umount, remove from laptop and place CF into CF-IDE adaptor on final computer. Boot. Disk is detected with same CHS as it was in the PCMCIA-CF adaptor but lilo will either say "LI" or "LI 0x01 0x01..." (0x07 is another common one.)
According to the LILO documentation that's illegal command and invalid initialization. Fun. Boot from a floppy on the target machine, run lilo from there, all is well. Unfortunately that isn't an option for me in all cases.
groups.google.com suggests that this is a longstanding problem with LILO (booting CF) but has no suggestions. Other than Grub which seems to be an excercise in bloat, has anyone got a solution to this?
I know this isn't exactly related to gaming but one thing I cannot get working on any version of WINE is direct parallel port access.
I've got am MPLAB ICE 2000 (in-circuit emulator that plugs into parallel port) and even though I've enabled the port= lines in the wine config, enabled read and write to those addresses and have the ppuser module loaded, WINE won't let me get direct access to my printer port. I've made sure that my WINE executable is executing su root too but no luck.:-(
Has anyone got this to work with any version of WINE?
Try copying the shared SSL library to another location, then start a new sshd on a different port using LD_LIBRARY_PRELOAD.
That would have been the quick way to do it.:-) I ended up using an idea very much like vph's to solve it. Thanks for the idea though, I'll keep that stored away because I'm sure it'll be handy elsewhere.
A workaround would be to move the existing library aside before you do make install. (e.g. mv libssl.so.0.9.6 libssl.so.0.9.6-OLD)
I've noted that for future reference.:-) Offhand, do you know if glibc/gcc does this automatically when you install updated system libraries? I don't ever recall this happenning with those libraries.
I think you found the reason why. Interesting, and thanks for sharing the info.
The OpenSSL INSTALL file doesn't exressly forbid shared libraries, just that they're experimental. I think I've learned my lesson though; static ssl libs for me.:-)
... I wonder why I was ever building OpenSSL with shared libaries - something tells me that mod_ssl for Apache required shared libs but in reading over its README and INSTALL files I can't find it there. <shrut>
The deal is that the version of SSH may not support the API OpenSSL provides in the latest patched version. You may have to wait for SSH to be updated to work with the newest one.
Interesting theory but why would a simple recompile of ssh work then? If the API changed I would have thought to see compiler errors.
Odd, I just updated ssl remotely via an ssh connection (compiled against the previous libs). I then recompiled ssh without problem.
Like I said, 5/7 boxes failed to do this nicely. Two of them worked as I had thought they should -- yes the libs change underneath you but you're running from in-memory copies. Someone told me this variation was due to glibc but I haven't found anything conclusive.
Upgrading SSL is nothing like upgrading SSH
on
OpenSSL Security Update
·
· Score: 5, Interesting
I have 18 firewalls to update (I sell these and support them, it's a nice way to suppliment my income). I'm not having much luck updating them though.
So far (on 5/7 firewalls), updating the ssl libraries caused ssh to kick out. This is very much unlike upgrading ssh, where the currently running sessions would stay active and you just kill off the 'parent' sshd process and restart sshd to upgrade.
Does anyone know why upgrading the shared lib is kicking out running sessions of ssh linked against it? Short of compiling sshd statically, is there any way around this? So far all the boxes are local but I have a few that are quite a distance and short of enabling telnet with a throwaway root account or statically compiling a temporary sshd, I'm screwed.:-)
Raid 1 is NOT a reason to not have backups - disk loss is not the only thing to destroy data.
Are you sure you're not Captain Obvious? I know that, but I'm saying that having a system in place so that, barring a dumb mistake, the data will be safer than with a single drive.
A quarterly backup with daily "diff" backups should do fine and keep the backup size small.
Re:What I've done for my work's system admins ...
on
Sysadmin Day. Yay.
·
· Score: 2
Linux : Windows:: Manual : Automatic Transmission
Hardly.
Can you write a batch file that takes a directory, zips it up, encrypts it and attaches it to an email with the text being the changelog since the last email? The only thing it asks me for is the passphrase.
Can you write an at job that runs the win32 equivalent of xplanet to update the background of your desktop every 5 minutes?
Linux is not the manual transmission of the computing world. Having a powerful shell and goodies like DCOP and XML-RPC built-in from the ground are wonderful things. Nice try, though.:-)
However the AIM gateway commonly causes my jabber server to crash.
Run it as a separate jabber service and then wrap that so that when it crashes it restarts. I haven't had the crash problem but the biggest joy of having an aim-t for your (small) jabber server is that it is highly unlikely that AOL will block you.
Slashdot Mirror
Neon Spiral Injector has posted 288 comments. Oh, that's too gross.
two gross and it'd be a really good pun.
The fun bit is that whilst the output is something like 117-0-117 the input is likely to be be either a single phase to ground or 120 degree 3 phase.
Yes. Usually (at least around here) your pole pig takes a ground and a live and gives you a split-secondary with two 117VAC hots and a neutral. In most neighbourhoods here you only have one 6.3kV line running around (and the other two phases are found on the main streets where they eventually head back to the substation) so yes -- you essentially have three noisy segments and the network data on any individual segment is a jumble of two possible phasings ("left side" and "right side" 117-VAC-originating).
The biggest problem is getting the signal through the pole pigs (can-type transformers on top of the hydro poles) -- they are big iron monstrosities that don't pass much past 1kHz or so due to their design.
One method which can be used is to simply wire some high voltage capacitors across the primary and secondary of the transformer -- they'll conduct at high frequencies (you tune this) and voila -- your signal jumps the transformer.
Of course, the problem with that is you're no longer isolated from the street-line voltages -- anywhere from about 6.9kV to 44kV, depending on who else is in your neighbourhood. The "right" way to do it is to have a line-powered conveter box at each pole pig which jumps the transformer optically, but that's expensive.
I've always been a fan of power line transmission. There's one in particular I was always amused by (no link handy) -- they claimed that by using a maser they could modulate the magnetic field without altering the voltage and current. I wonder what they think of Maxwell.
With all the transients, interference, noise, et cetera that are on power lines, this is going to be a big flop, mark my words.
Ever take a look at the PHY error counts on wireless? Hell on dialup for that matter? It's bad everywhere. That's why you use FEC techniques and trade data bandwidth for reliability.
I do this for my CF-based firewalls.
The CF has two partitions on it: A 3M boot/config partition (Minix), and the rest is reserved for the cramfs (right now the cramfs takes about 10M).
The boot/config partition holds the kernel, GRUB, an initrd image and the system configuration. At boot time /conf is booted and the initrd is loaded and executed. It loads a few modules, mounts the cramfs and then pivot_roots so that cramfs is /. The cramfs boot process mounts /dev/pts, proc and /var (as a 4MB tmpfs), untars the basic /var system and runs init. The rest is a standard boot.
The advantage to this is that I don't waste RAM by decompressing the entire root filesystem; cramfs decompresses the program to RAM at execution time. /var is the only point that is always rw but it's RAM anyway. Any time I need to do a config change I remount /conf as rw, make the change, and remount ro. If power is lost there is no fsck.
At present I have a complete firewall (including ssh, ipsec, the iptables 1.2.8 connection helpers (h323, ah/esp, etc.) and a full Perl install (I use it for SNMP, XMLRPC, integrity checking, etc.)) to fit in a 16M CF card. Cramfs is *awesome* :-)
In your situation I would probably do away with having the config in /conf, instead mounting it from the network (perhaps using BOOTP).
I'd love to know where to get a hold of a copy of the IRC transport or even a version of aim-t or yahoo-t which works with jabberd-1.4.2. The sf-like site for jabber apps is as dead as a doornail as far as offering files or getting at CVS. :-(
Seriously, we should be pushing for accountability, not a world were everybody's grandma has to learn C++ just to make sure that the big bad software company hasn't installed a trojan horse.
That's exactly the point. I can create a company that does service work which does analyze and approve security patches for its customers instead of blindly trusting the patch offerer. With OSS you can create accountability and not have to just trust the 800lb gorilla. Who watches the watchers? Other watchers. It's not one entity.
Where do you want your data to go today?
We use Rav Antivirus to scan the email for about 6000 dialup customers. It's about $600 + 20%/year for maintaining updates but we chose it specifically because it wasn't free: a virus scanner is absolutely no good when the updates aren't maintained. Pricing is based on number of domains and they have distributors all over the world.
They have versions to run qmail, sendmail, postfix, exchange server, etc., etc. and also have some user programs as well if you want. We've been very happy with it so far.
Why would a change to die size affect the PCB assembly line? Couldn't a 'pick-and-place' machine pick up a .13 um chip just as easily as a .18 um chip?
PCB stuffers don't place die for these chips -- they take the BGA package and solder them to the boards. You're picking up a device about 3/4" square and placing it. The technology inside that chip is .13um or .18um or whatever, not the packaged chip itself.
Do you think that Chinese is obfuscated because you can't read it? (assuming you don't know chinese...)
You're saying the winners of the IOPCC are not difficult to read? Christ man, I am glad you don't write code for me. Properly structured, well organized Perl is exceedingly clear. IOPCC entries are not.
Grub, eh? It looked like a huge time sink last time I looked at it, but perhaps it's time for a new look. :-) Thanks.
BTW have you ever tried to set the media write-lock on CF?
I have an IDE-CF bay, a PCMCIA-CF adaptor and a USB-CF adaptor. Now linux sees the CF in the USB adaptor as a scsi disk but the others are straight IDE.
I cannot for the life of me get lilo to correctly install on CF when in my laptop, and then boot in another computer. The CF reports itself as the same CHS whether it is in my PCMCIA slot or in the final computer's primary master CF-IDE bay. I've tried linear, lba32, with and without compact.
Example setup: install CF into PCMCIA adaptor, install adaptor into laptop. Laptop sees /dev/hde. mount /dev/hde1. /mnt/sbin/lilo -b /dev/hde -r /mnt. Lilo says it installs fine. umount, remove from laptop and place CF into CF-IDE adaptor on final computer. Boot. Disk is detected with same CHS as it was in the PCMCIA-CF adaptor but lilo will either say "LI" or "LI 0x01 0x01..." (0x07 is another common one.)
According to the LILO documentation that's illegal command and invalid initialization. Fun. Boot from a floppy on the target machine, run lilo from there, all is well. Unfortunately that isn't an option for me in all cases.
groups.google.com suggests that this is a longstanding problem with LILO (booting CF) but has no suggestions. Other than Grub which seems to be an excercise in bloat, has anyone got a solution to this?
I know this isn't exactly related to gaming but one thing I cannot get working on any version of WINE is direct parallel port access.
I've got am MPLAB ICE 2000 (in-circuit emulator that plugs into parallel port) and even though I've enabled the port= lines in the wine config, enabled read and write to those addresses and have the ppuser module loaded, WINE won't let me get direct access to my printer port. I've made sure that my WINE executable is executing su root too but no luck. :-(
Has anyone got this to work with any version of WINE?
Try copying the shared SSL library to another location, then start a new sshd on a different port using LD_LIBRARY_PRELOAD.
That would have been the quick way to do it. :-) I ended up using an idea very much like vph's to solve it. Thanks for the idea though, I'll keep that stored away because I'm sure it'll be handy elsewhere.
make install && /sbin/ldconfig && /etc/init.d/sshd restart
That's exactly what I did for the remainder of the installs but I used nohup instead. Same effect.
Funny, but the rest of the systems didn't crash out anyway. Unreal. :-)
A workaround would be to move the existing library aside before you do make install. (e.g. mv libssl.so.0.9.6 libssl.so.0.9.6-OLD)
I've noted that for future reference. :-) Offhand, do you know if glibc/gcc does this automatically when you install updated system libraries? I don't ever recall this happenning with those libraries.
I think you found the reason why. Interesting, and thanks for sharing the info.
The OpenSSL INSTALL file doesn't exressly forbid shared libraries, just that they're experimental. I think I've learned my lesson though; static ssl libs for me. :-)
The deal is that the version of SSH may not support the API OpenSSL provides in the latest patched version. You may have to wait for SSH to be updated to work with the newest one.
Interesting theory but why would a simple recompile of ssh work then? If the API changed I would have thought to see compiler errors.
Odd, I just updated ssl remotely via an ssh connection (compiled against the previous libs). I then recompiled ssh without problem.
Like I said, 5/7 boxes failed to do this nicely. Two of them worked as I had thought they should -- yes the libs change underneath you but you're running from in-memory copies. Someone told me this variation was due to glibc but I haven't found anything conclusive.
I have 18 firewalls to update (I sell these and support them, it's a nice way to suppliment my income). I'm not having much luck updating them though.
So far (on 5/7 firewalls), updating the ssl libraries caused ssh to kick out. This is very much unlike upgrading ssh, where the currently running sessions would stay active and you just kill off the 'parent' sshd process and restart sshd to upgrade.
Does anyone know why upgrading the shared lib is kicking out running sessions of ssh linked against it? Short of compiling sshd statically, is there any way around this? So far all the boxes are local but I have a few that are quite a distance and short of enabling telnet with a throwaway root account or statically compiling a temporary sshd, I'm screwed. :-)
Raid 1 is NOT a reason to not have backups - disk loss is not the only thing to destroy data.
Are you sure you're not Captain Obvious? I know that, but I'm saying that having a system in place so that, barring a dumb mistake, the data will be safer than with a single drive.
A quarterly backup with daily "diff" backups should do fine and keep the backup size small.
- .Net support (lock-in) in Qt
Qt has .Net support?
Linux : Windows :: Manual : Automatic Transmission
Hardly.
Can you write a batch file that takes a directory, zips it up, encrypts it and attaches it to an email with the text being the changelog since the last email? The only thing it asks me for is the passphrase.
Can you write an at job that runs the win32 equivalent of xplanet to update the background of your desktop every 5 minutes?
Linux is not the manual transmission of the computing world. Having a powerful shell and goodies like DCOP and XML-RPC built-in from the ground are wonderful things. Nice try, though. :-)
However the AIM gateway commonly causes my jabber server to crash.
Run it as a separate jabber service and then wrap that so that when it crashes it restarts. I haven't had the crash problem but the biggest joy of having an aim-t for your (small) jabber server is that it is highly unlikely that AOL will block you.