If it is just being able to make outgoing calls with your cellphone, then why not make them using the bluetooth audio channel that your phone probably supports. Have a look at the software on: http://crazygreek.co.uk/chan_bluetooth This allows you to pair your cellphone with your asterisk phone and make outgoing calls via bluetooth.
I wrote a document on authenticating enterprise systems agains LDAP. May be of some use to you: http://imaginator.com/~simon/ldap/ It's actually pretty easy!
The reciever requires that you have a windows computer running to push files to it via http. There are 2 projects I could find that allow you to stream to the Dell Reciver from your linux server: http://sourceforge.net/projects/das/ and http://www.mock.com/receiver/
I you may want to look at this as a way to access your big wad of MP3's It's an HTML interface that selects songs and allows you to stream them to yourself.
Disks are noisy especially the 7200 RPM drives. I run windows and Linux on my desktop. I became so fedup with the noise that I now netboot linux off my server next door. I still have to keep the 7200rpm disk in my desktop for when I boot into windows. Under linux I netboot (via a PXE capable eepro100), and then run the command:
scsi-spin --down/dev/sg0
for silence.
I still have fan noise but the high pitch whine is gone.
Looks like these guys have come up with a redimentary opensource tivo: http://www.stanford.edu/~jjd1/opendvr/. Looks like a fun and very promising school project! Aparently they could not solve the realtime encoding problem.
S
Re:This "feet from the office" thing seems hokey.
on
DSL Woes
·
· Score: 1
So what do you think a T1 runs off? It's 26 gauge twisted pair too.
Here's a tip sent around our company concering tweaking IDE perf. Thanks to Andrew Tridgell for the info.
This tip is useful for just about any Linux box, and is probably the simplest way to significantly speed up your IDE based Linux box without changing the hardware.
If you are impatient then just add the following near the top of your /etc/rc.d/rc.sysinit (or equivalent startup script):
By default Linux uses extremely conservative settings for IDE. In particular the default settings do two things that make IDE perform really badly:
1) DMA is not used. That means all data coming to/from the hard disk or cdrom is processed a byte at a time by the CPU. That is not very efficient. With a fast processor that isn't doing anything else at the time this can appear fast in simple minded benchmarks but it is a big drain on CPU resources when you are actively using the machine.
2) hardware interrupts are masked during IDE transfers. That means that while a lump of data is being transferred to/from a IDE device no other interrupts are processed. This includes interrupts from other IDE devices, from network devices, from serial ports and from mice. Your whole machine is effectively clagged up doing nothing but waiting for a horrendously slow device to say "I'm done". Not good.
If you want to see just how slow this is on your system then do the following:
that shows you the hard disk speed while accessing the CDROM with the default settings and with the improved settings. On my system the hard disk speed goes from 3.8 MB/sec to 12.9 MB/sec. I've seen much bigger changes on some other systems.
Even more importantly than the speedups is the fact that you will stop dropping your PPP connection while doing cdrom transfers, and you will be able to use your system while burning a cdrom without creating a coaster.
You may wonder why the default settings are so poor. The reason is that there is some rare hardware out there that corrupts data during IDE transfers when you either use DMA or receive an interrupt during a transfer. If that happens then the kernel should detect the failure (in nearly every case) and fall back to the default settings. Unfortunately after the auto-fallback you are still left with corrupt data in your cache. Luckily systems that don't handle DMA and unmasked interrupts are really quite rare these days so it is a pretty safe bet to turn the options I suggested above, especially if your system isn't from the stone age.
For more info and piles of options for fine tuning your IDE system try "man hdparm".
We are in the same position here - we are a traditional mod_perl house, however a new project has us deplying Java servlets interfacing with GSP (Gnu Server pages - a kinda embeddable in html java) all running on mod_jserv.
Have a peek at http://www.chamas.com/hello_world.html. This is a comprehensive benchmarking site for all types of backkends for webservers and includes mod_perl and jserv/servlets.
According to the site your servlets will be running about 10 times slower than perl.
Slashdot Mirror
If it is just being able to make outgoing calls with your cellphone, then why not make them using the bluetooth audio channel that your phone probably supports. Have a look at the software on: http://crazygreek.co.uk/chan_bluetooth
This allows you to pair your cellphone with your asterisk phone and make outgoing calls via bluetooth.
I wrote a document on authenticating enterprise systems agains LDAP. May be of some use to you: http://imaginator.com/~simon/ldap/ It's actually pretty easy!
The reciever requires that you have a windows computer running to push files to it via http. There are 2 projects I could find that allow you to stream to the Dell Reciver from your linux server: http://sourceforge.net/projects/das/ and http://www.mock.com/receiver/
I you may want to look at this as a way to access your big wad of MP3's It's an HTML interface that selects songs and allows you to stream them to yourself.
http://www.turnstyle.com/andromeda/
Zsh Rules: PROMPT="%{$COLOR3%}[%{$COLOR1%}%n%{$COLOR3%}@%{$CO LOR1%}%m%{$COLOR3%}[%{$COLOR1%}tty%l%{$COLOR3%}]%{ $COLOR1%}%~%{$COLOR3%}]%{$COLOR1%}%(#.#.$)%{$COLOR 4%}
Does anyone have a method to maybe change the color of the prompt or background when you su to root. This would be very useful.
scsi-spin --down /dev/sg0
for silence.I still have fan noise but the high pitch whine is gone.
I remember reading that Alan Cox had done something similar and asked him about it:
.VOB format yet)"
"Right now Im using netcat, mp1e to encode off a bttv card and mpegtv to play it (the free player wont handle the non
I haven't tried this yet but would be interested in anyone's feedback.
Looks like these guys have come up with a redimentary opensource tivo: http://www.stanford.edu/~jjd1/opendvr/. Looks like a fun and very promising school project! Aparently they could not solve the realtime encoding problem. S
So what do you think a T1 runs off? It's 26 gauge twisted pair too.
Here's a tip sent around our company concering tweaking IDE perf. Thanks to Andrew Tridgell for the info.
/dev/hda /dev/hdc
/dev/hda /dev/hdc /dev/hdc > /dev/null & /dev/hda /dev/hda /dev/hdc /dev/hda
This tip is useful for just about any Linux box, and is probably the
simplest way to significantly speed up your IDE based Linux box
without changing the hardware.
If you are impatient then just add the following near the top of your
/etc/rc.d/rc.sysinit (or equivalent startup script):
/sbin/hdparm -u 1 -d 1
/sbin/hdparm -u 1 -d 1
(and so on for any IDE devices in your system)
Now for a more complete explanation.
By default Linux uses extremely conservative settings for IDE. In
particular the default settings do two things that make IDE perform
really badly:
1) DMA is not used. That means all data coming to/from the hard disk
or cdrom is processed a byte at a time by the CPU. That is not very
efficient. With a fast processor that isn't doing anything else at
the time this can appear fast in simple minded benchmarks but it is
a big drain on CPU resources when you are actively using the
machine.
2) hardware interrupts are masked during IDE transfers. That means
that while a lump of data is being transferred to/from a IDE device
no other interrupts are processed. This includes interrupts from
other IDE devices, from network devices, from serial ports and from
mice. Your whole machine is effectively clagged up doing nothing
but waiting for a horrendously slow device to say "I'm done". Not
good.
If you want to see just how slow this is on your system then do the
following:
1) put a CDROM in the drive.
2) run the following commands:
hdparm -d 0 -u 0
hdparm -d 0 -u 0
cat
hdparm -t
hdparm -d 1 -u 1
hdparm -d 1 -u 1
hdparm -t
that shows you the hard disk speed while accessing the CDROM with the
default settings and with the improved settings. On my system the hard
disk speed goes from 3.8 MB/sec to 12.9 MB/sec. I've seen much bigger
changes on some other systems.
Even more importantly than the speedups is the fact that you will stop
dropping your PPP connection while doing cdrom transfers, and you will
be able to use your system while burning a cdrom without creating a
coaster.
You may wonder why the default settings are so poor. The reason is
that there is some rare hardware out there that corrupts data during
IDE transfers when you either use DMA or receive an interrupt during a
transfer. If that happens then the kernel should detect the failure
(in nearly every case) and fall back to the default
settings. Unfortunately after the auto-fallback you are still left
with corrupt data in your cache. Luckily systems that don't handle DMA
and unmasked interrupts are really quite rare these days so it is a
pretty safe bet to turn the options I suggested above, especially if
your system isn't from the stone age.
For more info and piles of options for fine tuning your IDE system try
"man hdparm".
Have a peek at http://www.chamas.com/hello_world.html. This is a comprehensive benchmarking site for all types of backkends for webservers and includes mod_perl and jserv/servlets.
According to the site your servlets will be running about 10 times slower than perl.
Have a look at these - I'm using one and they really help out. Much better than the M$ ones.
I had a look at this - still runs to around 400/month with pacbell costs.
I've been looking at www.sflan.com. It's a shared 10Mb/s radio network in SF. And best of all Free!
If anyone is interested I have a copy of Duncan Camphbells report to the European Parliament on my site. See http://www.imag inator.com/simon/documentation/report/ic2kreport.h tm Some very interesting reading... s