Simply lock up the CPU doing something busy all the time.... ie
nice -n +20 gzip </dev/zero >/dev/null &
On any modern unix variant, you'll not notice any loss in performance, however, just about every available cpu cycle will be chewed. Your system load (cpu and interrupt) will be relatively constant, regardless of what else you might have the box doing.
Check and see, but I think all of us unix junkies have those commands installed by default.:) No recompile or rewrite of some RFC required.
By "low power", I'm assuming PBS or less, perhaps a PEG (public, educational, goverment) channel. I would guess that a homegrown linux solution using VLM would be of higher quality than much of the programming itself. VLC supports a telnet command-able mode which is called VLM (google for it). Under this mode, it's possible to control streaming via telnet, which means under program control (think Net::Telnet and perl as one option).
I have actually implimented a streaming system for my employer which accomplishes "repeating playouts" rather effortlessly (like "Channel 1" type services that loop over some time period, or placeholders like "having tech difficulty"). VLM supports some real-time-priority and disk caching options which makes it a very respectable playout system. My design uses three servers, two that stream (redundancy for each other) and one admin box. The admin box "registers" content, and uses a bandwidth limited rsync to move assets to the streaming boxes. In this way there is no single point of failure, the streamers are prefectly capable of carrying out their last playout sequence indefinately, and any box could be promoted to admin status trivially.
To actually accomplish TV station grade programming (ie queuing, commercials, intersticials, and so forth) would be somewhat more complex that I've done so far, however I expect it to be possible. The thing VLM is missing would be some "event trigger" mechanism, presently you have to poll for information about what or how it's doing.
The largest obsticles to clear would be the speed of the playout startup, and massaging the end and start of the MPEG assets to assure that the resulting MPEG stream itself didn't have MPEG sequencing errors. Always deciding that the start and end of an MPEG asset will be black, and that start is MPEG sequence 1 and end is sequence 0 should help that. A program to set this up ahead of time shouldn't be too hard. Building the queuing system would be a fun project. A design that feeds an hours worth of programming to VLM on one server and then switches to another server for the next hour would give you an easy framework to take servers offline for service.
Streaming MPEG has many options for injection and translation back to baseband. A simple STB like an Amino A110 can do this very cheaply. Harmonic, Terayon, etc, have numerous devices for this space.
A bit on timing... in the IP space, packet burstiness isn't too big of a deal (as long as it is linear and packets get there on time, 1 packet bursts or 20 packet bursts are okay, devices that listen to streaming MPEG have buffers to eat up burstiness). But clock drift in STBs can be off by seconds over the course of several days. You'd need to make certain that the PC source clock(s), and whatever is doing your network stream to baseband conversion didn't have any appreciable clock drift. If this timing is off, you can see undesireable affects later on. If your "low power" station goes off-air daily, this probably needn't be a big concern.
Just like we saw a market correction to the over inflated tech stocks this year, we will also see a correction with these Oppressive and Limiting law suits.
Society will eventually decide it values the availability of music (for instance) rather than a few rich companies, and take away that legal bludeon we've given them.
I axiously await a thinking and informed Society who'll start making much needed Societal Corrections.
I bought Q3A for linux only... and then got shafted by idSoftware and all of the third party stuff.
I didn't get a copy of the Windows game, so I can't use 99% of the mods that are out there.
And very nearly simultaneously Nvidia backed of from their statements about releasing Xwindow servers. I only bought a TNT2 Ultra because Nvidia made statements positive to releasing drivers. Nvidia has cheesed me off.
Id should stick a Windows version along with the Linux version until 80% or more of the mod makers are releasing for linux also.
To this day, the only dollars idSoftware has seen from me were for the Linux version whenever it has been available, and will continue to be so.
id, Nvidia and others need to realise they need to sweeten the deal a little bit and be a little more realistic in there efforts.
Has errors in forking/threading use... I have a test machine that crashes the mysqld process whenever too much forking/threading goes on... works great in light use (less than 4 threads).
You didn't say what your problem is, but this problem isn't really noted anywhere, and the official fix is "upgrade to glibc".
3.21.x works great w/ libc5, and the static 3.22.x rpms are supposed to work fine too. (and obviously 3.22.x runs just fine on glibc).
Slashdot Mirror
Simply lock up the CPU doing something busy all the time.... ie
/dev/zero > /dev/null &
:) No recompile or rewrite of some RFC required.
nice -n +20 gzip <
On any modern unix variant, you'll not notice any loss in performance, however, just about every available cpu cycle will be chewed. Your system load (cpu and interrupt) will be relatively constant, regardless of what else you might have the box doing.
Check and see, but I think all of us unix junkies have those commands installed by default.
I think it's a cool fix.
By "low power", I'm assuming PBS or less, perhaps a PEG (public, educational, goverment) channel. I would guess that a homegrown linux solution using VLM would be of higher quality than much of the programming itself. VLC supports a telnet command-able mode which is called VLM (google for it). Under this mode, it's possible to control streaming via telnet, which means under program control (think Net::Telnet and perl as one option).
I have actually implimented a streaming system for my employer which accomplishes "repeating playouts" rather effortlessly (like "Channel 1" type services that loop over some time period, or placeholders like "having tech difficulty"). VLM supports some real-time-priority and disk caching options which makes it a very respectable playout system. My design uses three servers, two that stream (redundancy for each other) and one admin box. The admin box "registers" content, and uses a bandwidth limited rsync to move assets to the streaming boxes. In this way there is no single point of failure, the streamers are prefectly capable of carrying out their last playout sequence indefinately, and any box could be promoted to admin status trivially.
To actually accomplish TV station grade programming (ie queuing, commercials, intersticials, and so forth) would be somewhat more complex that I've done so far, however I expect it to be possible. The thing VLM is missing would be some "event trigger" mechanism, presently you have to poll for information about what or how it's doing.
The largest obsticles to clear would be the speed of the playout startup, and massaging the end and start of the MPEG assets to assure that the resulting MPEG stream itself didn't have MPEG sequencing errors. Always deciding that the start and end of an MPEG asset will be black, and that start is MPEG sequence 1 and end is sequence 0 should help that. A program to set this up ahead of time shouldn't be too hard. Building the queuing system would be a fun project. A design that feeds an hours worth of programming to VLM on one server and then switches to another server for the next hour would give you an easy framework to take servers offline for service.
Streaming MPEG has many options for injection and translation back to baseband. A simple STB like an Amino A110 can do this very cheaply. Harmonic, Terayon, etc, have numerous devices for this space.
A bit on timing... in the IP space, packet burstiness isn't too big of a deal (as long as it is linear and packets get there on time, 1 packet bursts or 20 packet bursts are okay, devices that listen to streaming MPEG have buffers to eat up burstiness). But clock drift in STBs can be off by seconds over the course of several days. You'd need to make certain that the PC source clock(s), and whatever is doing your network stream to baseband conversion didn't have any appreciable clock drift. If this timing is off, you can see undesireable affects later on. If your "low power" station goes off-air daily, this probably needn't be a big concern.
... up the voltage.
I really didn't expect to see such a graphic proof of Paul Graham's article so quickly.
1 4
http://www.paulgraham.com/submarine.html
http://slashdot.org/article.pl?sid=05/04/21/19532
Knew this sounded familiar.
. html
AT&T announced this 12 years ago... http://www.wired.com/wired/archive/1.01/electrons
Just like we saw a market correction to the over inflated tech stocks this year, we will also see a correction with these Oppressive and Limiting law suits.
Society will eventually decide it values the availability of music (for instance) rather than a few rich companies, and take away that legal bludeon we've given them.
I axiously await a thinking and informed Society who'll start making much needed Societal Corrections.
I bought Q3A for linux only... and then got shafted by idSoftware and all of the third party stuff.
I didn't get a copy of the Windows game, so I can't use 99% of the mods that are out there.
And very nearly simultaneously Nvidia backed of from their statements about releasing Xwindow servers. I only bought a TNT2 Ultra because Nvidia made statements positive to releasing drivers. Nvidia has cheesed me off.
Id should stick a Windows version along with the Linux version until 80% or more of the mod makers are releasing for linux also.
To this day, the only dollars idSoftware has seen from me were for the Linux version whenever it has been available, and will continue to be so.
id, Nvidia and others need to realise they need to sweeten the deal a little bit and be a little more realistic in there efforts.
Has errors in forking/threading use... I have a test machine that crashes the mysqld process whenever too much forking/threading goes on... works great in light use (less than 4 threads).
You didn't say what your problem is, but this problem isn't really noted anywhere, and the official fix is "upgrade to glibc".
3.21.x works great w/ libc5, and the static 3.22.x rpms are supposed to work fine too. (and obviously 3.22.x runs just fine on glibc).