Not that I particularily like Steam from Valve Software yet, but it may be a decent beginning for something useful.
Anyway, when they rolled Steam out, their servers were immediately DOSed by CounterStrike players who were trying to upgrade. After having read the description on the Steam homepage I had assumed that Steam would be using a P2P scheme for content delivery. I geuss they didn't think of that.:(
In my opinion, their "content servers" should have provided an original copy and checksums, and the Steam client should have used the same mechanism it uses to find other players (essentially finds other Steam clients) to find Steam clients who have the required file already, and have not maxed out their outgoing bandwidth. The client should then add different sources until the download bandwidth maxes out or until there are no more sources. The original content servers should be the last resort to ensure minimal load.
Maybe Valve could look at eDonkey/eMule for an example implementation.
Just an instance where I believe P2P should have been used. (Hey, maybe if they are smart they will add this in a furure update...)
I think the whole point is that encrypting the entire datastream is too processor intensive in this case, so SFTP (or even SCP) would be out of the question. PPP could potentially be run over a TCP/IP socket (like VPN/PPTP). Not that PPP itself is really the point, I just thought that there might be a way to use existing authentication methods. The script I wrote does not use PPP, but implements a challenge handshake based on some of the same concepts as CHAP.
Not sure exactly how you would set it up, but PPP supports unencrypted data streams with hashed passwords when using authentication like CHAP.
or...
Maybe you could write a Perl (or Python, or shell) script that issies a challenge and spits out whatever files you want if the challenge succeeds. Hell, maybe I'll write one right now - here I go!
(check this thread in a few minutes to see the finished product...)
Here in the U.S., ISP and phone charges work a little differently. Phone companies usually charge a fixed monthly rate (usually about $20) for local service (unlimited calls within the local switching network), and large ISPs like AOL set up an access number in each (well, almost) switching network. Thus internet acces is a local call which is covered under the fixed monthly phone bill. Because of this, ISPs here do not receive income from the phone call itself, but rather charge a monthly fee. The difference between your "free" basic internet and our $9.95 is that you pay your phone company for your internet by the minute, we pay the ISP directly by the month. Personally, I think the pricing may even be a bit cheaper here. If you can get a month of continuous use for $9.95 (well, you also gotta pay $20 for the phone), how does that compare to your european phone bill for using the phone constantly for a month?
Then again, I have DSL, so what would I know?;)
Actually they ran under the Pink party, with the Sweating Man as their publicity advisor. Unfortunately, even though Pinky made a great president, Brain's questionable past forces the duo to resign.
It would be good to have the ability in the kernel to (optionally of course) run through a full memory scan and map any bad memory. This way the kernel can avoid allocating the bad memory and allow the system to run reliably at least until the memory can be replaced.
This could be very useful in a remote environment where physical access to the hardware is not immediately available.
Personally I get my DSL from Surf City Networks (surfcity.com). They have really great support, and had no problem with me running Linux on my system. I can call them anytime during business hours and talk to a competent technician. The only drawback is that the local loop for my apartment is provided by Verizon, and they are the most retarded morons in the telecom business. (Although I'm sure some of you would disagree;) Fortunately, as long as their wiring and switch stay intact, I don't have to deal with them at all.
Quite true. The Promise FastTrack is just a glorified IDE controller. But there is one very important perk: It has an onboard BIOS that understands RAID arrays and can build an array before an OS is even installed. Kinda like a built in recue disk. Unfortunately for Promise, they are almost as stuck-up as TI when it comes to driver support on Linux. They have a few "binary drivers" that are compiled from proprietary source and only work with very specific kernel builds (namely those that shipped with a few major commercial distros). A year or two ago I sent numerous emails to Promise's tech support asking when they would release their driver source. The answer I eventually got was basically, "whenever the hell we feel like it." So, the Promise cards at my work were resticted to use in Windoze machines or storage in scrap boxes until recently. Recently things have improved drastically for FastTrack under Linux. Open souce drivers have finally been reverse-engineered for the controller, and it is now possible to run the controller in RAID mode reliably under the latest Linux kernels. (although it still takes a little voodoo to get the driver working.) Because Promise RAID controllers are built into many new motherboards, I see no real reason not to use the RAID function under Linux. On the other hand, if you don't already have a controller handy, I would recommend just using the Linux built-in software RAID. One other nice thing about the Promise RAID controllers is that if run in a mirrored RAID configuration, either of the drives can be removed from the controller and placed in a computer without a RAID controller, and all of the data remains accessable.
Just a side note: Don't confuse the Promise FastTrack line of RAID controllers with their line of UltraATA controllers.
The one interesting thing I noted in the article is that cellophane apperently has the uniqe property of _ALTERING_ the direction of polarization in light (instead of simply rejecting all non-aligned light like standard polarazers) thus allowing the alteration of the direction of polarization of already polarized light instead of completely blocking it.
Aside from that interesting fact, the rest of the article reads like Magic Eye (TM) instuctions. The whole polarization scheme presented serves only to aid in focusing the eyes at the right portions of the screen, not to actually decode an image like an interlaced polarizer would.
Slashdot Mirror
Not that I particularily like Steam from Valve Software yet, but it may be a decent beginning for something useful. :(
Anyway, when they rolled Steam out, their servers were immediately DOSed by CounterStrike players who were trying to upgrade. After having read the description on the Steam homepage I had assumed that Steam would be using a P2P scheme for content delivery. I geuss they didn't think of that.
In my opinion, their "content servers" should have provided an original copy and checksums, and the Steam client should have used the same mechanism it uses to find other players (essentially finds other Steam clients) to find Steam clients who have the required file already, and have not maxed out their outgoing bandwidth. The client should then add different sources until the download bandwidth maxes out or until there are no more sources. The original content servers should be the last resort to ensure minimal load.
Maybe Valve could look at eDonkey/eMule for an example implementation.
Just an instance where I believe P2P should have been used. (Hey, maybe if they are smart they will add this in a furure update...)
That sounds like exactly what I meant when I mentioned PPP.
I think the whole point is that encrypting the entire datastream is too processor intensive in this case, so SFTP (or even SCP) would be out of the question. PPP could potentially be run over a TCP/IP socket (like VPN/PPTP). Not that PPP itself is really the point, I just thought that there might be a way to use existing authentication methods. The script I wrote does not use PPP, but implements a challenge handshake based on some of the same concepts as CHAP.
Here You go! /. doesn't seem to like code. Well here's a link to the code then!)
:)
(Darn,
server.pl
client.pl
Let me know what you guys think!
This code should provide all of the mentioned features: an MD5-based challenge authentication, and unencrypted transfer of files.
Here's a link to the manpage. http://www.die.net/doc/linux/man/man1/scp.1.html
Not sure exactly how you would set it up, but PPP supports unencrypted data streams with hashed passwords when using authentication like CHAP. or... Maybe you could write a Perl (or Python, or shell) script that issies a challenge and spits out whatever files you want if the challenge succeeds. Hell, maybe I'll write one right now - here I go! (check this thread in a few minutes to see the finished product...)
Try scp. It is included with ssh.
Here in the U.S., ISP and phone charges work a little differently. Phone companies usually charge a fixed monthly rate (usually about $20) for local service (unlimited calls within the local switching network), and large ISPs like AOL set up an access number in each (well, almost) switching network. Thus internet acces is a local call which is covered under the fixed monthly phone bill. Because of this, ISPs here do not receive income from the phone call itself, but rather charge a monthly fee. The difference between your "free" basic internet and our $9.95 is that you pay your phone company for your internet by the minute, we pay the ISP directly by the month. Personally, I think the pricing may even be a bit cheaper here. If you can get a month of continuous use for $9.95 (well, you also gotta pay $20 for the phone), how does that compare to your european phone bill for using the phone constantly for a month? Then again, I have DSL, so what would I know? ;)
Actually they ran under the Pink party, with the Sweating Man as their publicity advisor. Unfortunately, even though Pinky made a great president, Brain's questionable past forces the duo to resign.
Unfortunately your computer wakes up as soon as I send a packet because you forgot to turn off the Wake-on-LAN feature of your integrated NIC.
It would be good to have the ability in the kernel to (optionally of course) run through a full memory scan and map any bad memory. This way the kernel can avoid allocating the bad memory and allow the system to run reliably at least until the memory can be replaced. This could be very useful in a remote environment where physical access to the hardware is not immediately available.
Personally I get my DSL from Surf City Networks (surfcity.com). They have really great support, and had no problem with me running Linux on my system. I can call them anytime during business hours and talk to a competent technician. The only drawback is that the local loop for my apartment is provided by Verizon, and they are the most retarded morons in the telecom business. (Although I'm sure some of you would disagree ;) Fortunately, as long as their wiring and switch stay intact, I don't have to deal with them at all.
Quite true. The Promise FastTrack is just a glorified IDE controller. But there is one very important perk: It has an onboard BIOS that understands RAID arrays and can build an array before an OS is even installed. Kinda like a built in recue disk.
Unfortunately for Promise, they are almost as stuck-up as TI when it comes to driver support on Linux. They have a few "binary drivers" that are compiled from proprietary source and only work with very specific kernel builds (namely those that shipped with a few major commercial distros).
A year or two ago I sent numerous emails to Promise's tech support asking when they would release their driver source. The answer I eventually got was basically, "whenever the hell we feel like it." So, the Promise cards at my work were resticted to use in Windoze machines or storage in scrap boxes until recently.
Recently things have improved drastically for FastTrack under Linux. Open souce drivers have finally been reverse-engineered for the controller, and it is now possible to run the controller in RAID mode reliably under the latest Linux kernels. (although it still takes a little voodoo to get the driver working.)
Because Promise RAID controllers are built into many new motherboards, I see no real reason not to use the RAID function under Linux. On the other hand, if you don't already have a controller handy, I would recommend just using the Linux built-in software RAID.
One other nice thing about the Promise RAID controllers is that if run in a mirrored RAID configuration, either of the drives can be removed from the controller and placed in a computer without a RAID controller, and all of the data remains accessable.
Just a side note:
Don't confuse the Promise FastTrack line of RAID controllers with their line of UltraATA controllers.
The one interesting thing I noted in the article is that cellophane apperently has the uniqe property of _ALTERING_ the direction of polarization in light (instead of simply rejecting all non-aligned light like standard polarazers) thus allowing the alteration of the direction of polarization of already polarized light instead of completely blocking it.
Aside from that interesting fact, the rest of the article reads like Magic Eye (TM) instuctions. The whole polarization scheme presented serves only to aid in focusing the eyes at the right portions of the screen, not to actually decode an image like an interlaced polarizer would.