I'm using Ubuntu's default AC Power Management configuration on an IBM A21M Thinkpad. By default, power management (system < preferences < power management), put's the laptop in sleep mode after a period of 30 min. It won't wake up if I press the keyboard or move the mouse. I've found reference to this issue on the Ubuntu forums.
The XPC's primary competitor is existing desktop PCs. Zipzoomfly.com sells them.
TVHarmony AutoPilot is the perfect companion to Tivo® and TivoToGo™. The software is a powerful scriptable scheduling tool that will automatically transfer, convert, and store your programming while you are asleep. Using a simple user interface, you can:
From Tivo to MPEG
From MPEG to Palm
TCPMP (The Core Pocket Media Player) Installed on the Palm [16 bit color, 320 x 480 Transflective TFT display]
Supported file containers
- AVI (*.avi)
- Matroska (*.mkv, *.mka)
- MP4 (*.mp4, *.m4a)
- Ogg Media (*.ogg, *.ogm)
- ASF (*.asf)Supported audio codecs
- Mpeg 1 Layer III
- Ogg Vorbis
- Musepack
- Windows Media Audio (on Windows Mobile devices)
- AC-3
- AMR
- Adpcm, uLawSupported video codecs
- DivX
- XviD
- MPEG4-SP (plus B-frame support)
- MPEG1
- M-JPEG
- Windows Media Video (on Windows Mobile devices)
Various to Tivo
As long as it's an MPEG 2 format that Tivo can understand it, ,but…
The TiVo is VERY specific on video format (pixel resolution) and if not the correct format will not load the file. It basically looks for
720×480
704×480
544×480
480×480
352×480
The Ubuntu server release supports a LAMP "stack," so that an admin can set up a LAMP server with a single command rather than installing and configuring the Apache, MySQL, and PHP software separately. In effect, this allows Ubuntu to be used almost as a software appliance.
Darik's Boot and Nuke ("DBAN") is a self-contained boot floppy that securely wipes the hard disks of most computers. DBAN will automatically and completely delete the contents of any hard disk that it can detect, which makes it an appropriate utility for bulk or emergency data destruction.
Excerpt from Slashdot…
Two solutions to prevent this compromise of the rest of the network:
1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.
2) Use a different public/private key pair for each box. That way, if you didn't firewall the DMZ off it would still fail on the key authentication. The drawback of this is a) the attacker can still ssh to your admin box which contains all of the private keys and b) you lose most of the advantage of agent forwarding; the ability to ssh through a chain of boxes without any but the first needing to store the private key.