... post a large banner on their main page that explains everything. Can you imagine how quickly the Scientologists would back down if Google's front page contains a message along the lines of:
"Certain links have been removed from the Google search engine due to pressure from the church of Scientology. For the full story, click here."
Considering the number of people that hit Google's front page every day, this would generate a phenomenal amount of bad PR - and, more importantly, cause ordinary folks to look more closely into the DMCA.
Google actually has a fantastic opportunity here.
Laptop Server/Router
on
Low-end Laptops?
·
· Score: 3, Interesting
I have an old P100 that I got for $150 a year or so ago, from the local newspaper's classified ad section. I run Redhat 7.2 on it, and use it as a web server and NAT/firewall for my home LAN.
The downside with this is that PCMCIA ethernet cards are more expensive. The big upside, however, is that a laptop will continue to run on its own batteries should the power go out. Furthermore, you don't need to drag over a monitor and keyboard if for some reason you want to log in from the console, as you would with a non-laptop headless server.
They see their consoles as being aimed primarily at younger children and try to discourage development of 'adult' titles. Sites like http://foon.pocketheaven.com/ that carry unlicenced software weaken their position so, while being legal, their position is precarious.
As the author of FooN, I'm not sure what you're getting at here... are you implying that FooN is some kind of adult software? FooN is a Sinclair ZX-Spectrum emulator for the GBA. There is no adult content - there are not even any Spectrum game images hosted on the site (even though most Spectrum games authors have granted permission for their games to be freely distributed). I fail to see how this could 'weaken' Nintendo's position. I understand your point with regard to Nintendo's desire to control exactly what gets released for their machine, but I'm not sure why you singled me out, particularly when there are other projects of far more dubious legality!
If the issue were simply homebrew development, I doubt Nintendo would be too concerned. The number of people using Flash Linkers for development is (I suspect) significantly lower than the number who are using them to pirate GBA ROMs. Which is unfortunate.
... is the relative speed at which open-source problems are located and repaired.
Just for fun, here is a handy summary of some Windows issues, including an XMLHTTP vulnerability that allows a malicious website to read any file on your harddrive, that has been a known issue since December 15th.
The only reason British DSL costs so much, and is so late to be deployed is because of an antiquated, complacent, mismanaged, monopolistic telephone company - British Telecom. They held back DSL deployment because they didn't want ISDN sales to suffer, and even now, are doing everything possible to hinder providers' access to the local loop.
The chairman of BT once claimed that the public just weren't ready for DSL yet.
You're right of course, but I think most would understand what I meant. Incidentally, how much of the StrongARM is actually Intel-designed? Does Intel actually design a chip around the ARM instruction set, or do they actually use ARM-designed hardware?
Although the Empeg (now known as Rio Car) isn't Intel-based, it runs on a decently powered StrongARM CPU, and includes a nice screen as well. Runs Linux, and I believe is somewhat hackable.
Since they've stopped production, they're selling off the last ones really cheap - $399 for 60GB version. If you want a nice, hackable in-car computer to hack around with you might want to snap one of these up before they're all gone.
This debate seems to be over whether Smoothwall was designed to secure against attack from outside your DSL dialup or against attack from the inside. Shadow passwords are meant to provide a safeguard against dictionary attacks from logged-in users on a multiuser system. c't's complaint that there is no shadow password on a single-user system is valid; if you're worried about people in your own house trying to hack into your firewall.
From what I understand, even a user in your own house wouldn't be able to get at the password file, since only the root account (which one would assume is password protected) has access to a shell. This isn't a multiuser system that people log into.
(This is my understanding from what I've read - I've never used SmoothWall - please correct me if I'm mistaken).
Colour combiners and pixel shaders are (more often than not) exactly equivalent. Have you actually used DX8? I've written a shitload of pixel shaders, and frankly, there's very little that you can't do with a suitably powerful colour combiner.
I never suggested that vertex shaders and colour combiners were equivalent - I don't know where you got that from. I did however point out the the N64 had completely replaceable RSP microcode, enabling you to do weighted blending, env mapping, etc... etc... - in other words anything a DX8 vertex shader can do and more besides.
I don't know why you're bringing up OpenGL - basic, vanilla OpenGL can't do much more than modulate a linearly interpolated colour value with a texture map - very PS1. What's your point?
I would recommend those that want a deeper analysis of why the xbox is the graphics gaming console of the future (verses these other boxes) to have a good look at what DX8 brought us. Hint: vertex shading and pixel shading.
Hmm... Actually vertex shaders and pixel shaders are nothing new - it's just that we've finally slapped a standard name on them. Even the Nintendo64 had a "colour-combiner" which could apply two passes of linear equations to the various different colour sources - no, it wasn't a fully programmable pixel shader, but then neither is DX8's most of the time, given the various hardware limitations. I believe the GameCube has a much more sophisticated colour-combiner step - capable of doing pretty much anything the XBox can do with its pixel shader.
As for vertex shaders - gimme a break! The N64 had completely updateable microcode - you could use the RSP for whatever you wanted, and perform whatever calculations you liked at the vertex transform/shading level.
DX8 didn't bring us either of these technologies. You would do well to examine the actual meanings of these terms, and look at the capabilities of the competing hardware rather than blindly accepting the hype.
While having your servers nice and secure in a physically impenetrable fortress is all very well and good, it's sort of the physical equivalent to cryptographic security-by-obscurity. It provides a false sense of security, and doesn't address critical vulnerabilities.
Let's face it - someone who wants to take your website down isn't going to do it by physically storming the building! Unless, of course, they're the government - in which case they'll also cut off your internet feed. What good is your 7-week's worth of diesel going to do you then?
Furthermore, it doesn't make any difference how physically secure your boxen are, if you're running an OS with networking vulnerabilities, or are vulnerable to DOS attacks.
The most secure solution is complete redundancy/distribution, in both physical and network space. The most obvious example is Freenet, which sadly isn't quite mainstream-useable yet.
Store your documents in a distributed fashion across thousands of machines. Encrypt them, so even the individual user doesn't know what his cache contains. Cryptographically sign each piece of content you produce. How is anyone going to fuck with your site when it's in a thousand different places?
Trying to correctly simulate a bunch of cubes colliding with each other, and eventually coming to rest in contact with each other (and the ground) will convince you pretty damn quickly that Euler integration isn't sufficient for proper physics simulation.
The point you miss is that as time goes on, more and more developers are incorporating some form of "proper" physics simulation into their games, since pre-canned animations can only take you so far. Thus, Euler integration becomes less and less suitable.
I wouldn't make sweeping statements regarding the other guy's game dev experience - it sounds an awful lot like all you've done is springs and bouncing balls. Rigid body mechanics is a whole different world, and is likely to play a larger and larger part in videogames as CPUs become more and more capable of dealing with it.
provides an excellent, and free alternative to purchasing a weighty tome on the subject. Chris covers the details of rigid body mechanics in a thorough, but light manner.
I went to a physics lecture at GDC, the most memorable part of which was Chris saying:
"Here's how it's going to go... you're going to write your first rigid body dynamics simulator. You're going to simulate a cube dropping onto a plane. You'll run the program, the cube will drop, hit the plane... and disappear."
If any of you here are British, (or just inordinately fond of the ZX-Spectrum, or Timex-Sinclair whatever-it-was-released-as-in-the-USA), you may be interested in looking at http://foon.pocketheaven.com.
You need a GBA flash cart (available from a number of vendors), and a GameBoy advance. Hey presto - portable Speccy!
I'll concede it's a little light on the technical details, but don't forget that this article is targetted at Joe Public.
I think you missed the most revealing fact in the article: 8 out of 12 networks detected were not even using 802.11 encryption at all. Yes, we all know that 802.11 encryption is not secure, but the fact that people are broadcasting unencrypted packets does mean that the networks are incredibly insecure. I'm thinking of SMB, POP3, TELNET, FTP, or any other number of services that transmit either plaintext or weakly encrypted passwords.
Yes, people should use VPNs, but the point of the article was that they're not.
Also, "war driving" and "war pedalling" are actual, legitimate terms - I've seen them used on many occasions before, as would you, had you researched this at all before spouting off.
MP3Public is a PIC-microcontroller based MP3 player, using a MAS3507D DSP chip for decoding. It supports both CD-ROM and HD's. The HD uses a custom filesystem, with tracks/albums being downloaded through the parallel port. I built the original a few years ago (actually, I think it was one of the first working HD-based players), and others have contributed significantly to the code/design.
Firmware/schematics/PC-side source code are all open-sourced. There's a fairly clean C++ library for talking to the player and downloading tracks. I'm really hoping some kind soul will use this to write a nice GUI download application for Linux and Windows. (The current software is Windows only, and crashes fairly regularly).
Needless to say, this is a fairly complex project - don't try building one unless you've got a fair deal of soldering experience!
By browsing at +1 (or whatever), the reader is making a decision to ignore posts that (generally like-minded) reads have chosen to ignore. This is extraordinarily effective at filtering out annoying "first post" drivel.
One might accuse moderators of modding down things they don't agree with, but if you look closely, there are many pro-MS posts that get modded up to +5 because they're intelligently written and raise good points that are worth thinking about. Remember that moderators aren't necessarily evil people - they're ordinary readers, just like you and me.
Regardless of all this, however, there is still no censorship. Your post doesn't get deleted. Anyone who wants to read your post can do so by browsing at -1.
The biggest problem, presumably, is the fact that it's chewing up your network bandwidth. Adding ipchains rules will cause your machine to ignore the packets, but they're still consuming time on your DSL/cable/whatever link.
What we really need is for ISP's to take a slightly more aggressive (but directed) approach.
I explained what they were - bear in mind that your stack is now reversed, and is growing "rightwards".
return addr is the RA pointing back into the function that called BadFunction.
retaddr#2 is the RA pointing into BadFunction (BadFunction having called strcpy).
(The ebp's are just the stack frame pointers corresponding to each call).
The snapshot of the stack I illustrated was while strcpy is executing. My point was that you can still overflow the end of badBuf and scribble on retAddr#2 - thus, when strcpy returns, it will jump to an arbitrary address.
Doesn't seem any harder or easier than overflowing a buffer using a normal stack direction. Both situations require knowledge of the local stack frame layout, but that's about it.
Actually, thinking about it, the only difference is that you would need to make sure your buffer doesn't overflow *too* far, or you'll scribble on strcpy's local variables, possibly preventing it from returning.
Slashdot Mirror
... post a large banner on their main page that explains everything. Can you imagine how quickly the Scientologists would back down if Google's front page contains a message along the lines of:
"Certain links have been removed from the Google search engine due to pressure from the church of Scientology. For the full story, click here."
Considering the number of people that hit Google's front page every day, this would generate a phenomenal amount of bad PR - and, more importantly, cause ordinary folks to look more closely into the DMCA.
Google actually has a fantastic opportunity here.
I have an old P100 that I got for $150 a year or so ago, from the local newspaper's classified ad section. I run Redhat 7.2 on it, and use it as a web server and NAT/firewall for my home LAN.
The downside with this is that PCMCIA ethernet cards are more expensive. The big upside, however, is that a laptop will continue to run on its own batteries should the power go out. Furthermore, you don't need to drag over a monitor and keyboard if for some reason you want to log in from the console, as you would with a non-laptop headless server.
I'm sorry, how do two things of the same polarity bind together to form neutral polarity?
positron = positively charged electron
anti-proton = negatively charged proton
positron + anti-proton = neutral anti-hydrogen
No - this is a Flash based cart that can be loaded with a binary image, and then plugged into a GBA instead of a normal ROM-based cart.
Thus, it can be used for game piracy.
They see their consoles as being aimed primarily at younger children and try to discourage development of 'adult' titles. Sites like http://foon.pocketheaven.com/ that carry unlicenced software weaken their position so, while being legal, their position is precarious.
As the author of FooN, I'm not sure what you're getting at here... are you implying that FooN is some kind of adult software? FooN is a Sinclair ZX-Spectrum emulator for the GBA. There is no adult content - there are not even any Spectrum game images hosted on the site (even though most Spectrum games authors have granted permission for their games to be freely distributed). I fail to see how this could 'weaken' Nintendo's position. I understand your point with regard to Nintendo's desire to control exactly what gets released for their machine, but I'm not sure why you singled me out, particularly when there are other projects of far more dubious legality!
If the issue were simply homebrew development, I doubt Nintendo would be too concerned. The number of people using Flash Linkers for development is (I suspect) significantly lower than the number who are using them to pirate GBA ROMs. Which is unfortunate.
Strags
Err.... Read the article?
Wouldn't you agree that it's a good thing to improve Apache's portability?
There's also a lot more to a web server than just serving files straight off the hard drive.
... is the relative speed at which open-source problems are located and repaired.
Just for fun, here is a handy summary of some Windows issues, including an XMLHTTP vulnerability that allows a malicious website to read any file on your harddrive, that has been a known issue since December 15th.
I suspect I'm just feeding a troll here, but...
The only reason British DSL costs so much, and is so late to be deployed is because of an antiquated, complacent, mismanaged, monopolistic telephone company - British Telecom. They held back DSL deployment because they didn't want ISDN sales to suffer, and even now, are doing everything possible to hinder providers' access to the local loop.
The chairman of BT once claimed that the public just weren't ready for DSL yet.
You're right of course, but I think most would understand what I meant. Incidentally, how much of the StrongARM is actually Intel-designed? Does Intel actually design a chip around the ARM instruction set, or do they actually use ARM-designed hardware?
Whoops - my mistake - thanks! :)
Still a fair bit cheaper though
Although the Empeg (now known as Rio Car) isn't Intel-based, it runs on a decently powered StrongARM CPU, and includes a nice screen as well. Runs Linux, and I believe is somewhat hackable.
Since they've stopped production, they're selling off the last ones really cheap - $399 for 60GB version. If you want a nice, hackable in-car computer to hack around with you might want to snap one of these up before they're all gone.
This debate seems to be over whether Smoothwall was designed to secure against attack from outside your DSL dialup or against attack from the inside. Shadow passwords are meant to provide a safeguard against dictionary attacks from logged-in users on a multiuser system. c't's complaint that there is no shadow password on a single-user system is valid; if you're worried about people in your own house trying to hack into your firewall.
From what I understand, even a user in your own house wouldn't be able to get at the password file, since only the root account (which one would assume is password protected) has access to a shell. This isn't a multiuser system that people log into.
(This is my understanding from what I've read - I've never used SmoothWall - please correct me if I'm mistaken).
I'm sorry if I confused you... let me clarify...
Colour combiners and pixel shaders are (more often than not) exactly equivalent. Have you actually used DX8? I've written a shitload of pixel shaders, and frankly, there's very little that you can't do with a suitably powerful colour combiner.
I never suggested that vertex shaders and colour combiners were equivalent - I don't know where you got that from. I did however point out the the N64 had completely replaceable RSP microcode, enabling you to do weighted blending, env mapping, etc... etc... - in other words anything a DX8 vertex shader can do and more besides.
I don't know why you're bringing up OpenGL - basic, vanilla OpenGL can't do much more than modulate a linearly interpolated colour value with a texture map - very PS1. What's your point?
I would recommend those that want a deeper analysis of why the xbox is the graphics gaming console of the future (verses these other boxes) to have a good look at what DX8 brought us. Hint: vertex shading and pixel shading.
Hmm... Actually vertex shaders and pixel shaders are nothing new - it's just that we've finally slapped a standard name on them. Even the Nintendo64 had a "colour-combiner" which could apply two passes of linear equations to the various different colour sources - no, it wasn't a fully programmable pixel shader, but then neither is DX8's most of the time, given the various hardware limitations. I believe the GameCube has a much more sophisticated colour-combiner step - capable of doing pretty much anything the XBox can do with its pixel shader.
As for vertex shaders - gimme a break! The N64 had completely updateable microcode - you could use the RSP for whatever you wanted, and perform whatever calculations you liked at the vertex transform/shading level.
DX8 didn't bring us either of these technologies. You would do well to examine the actual meanings of these terms, and look at the capabilities of the competing hardware rather than blindly accepting the hype.
While having your servers nice and secure in a physically impenetrable fortress is all very well and good, it's sort of the physical equivalent to cryptographic security-by-obscurity. It provides a false sense of security, and doesn't address critical vulnerabilities.
Let's face it - someone who wants to take your website down isn't going to do it by physically storming the building! Unless, of course, they're the government - in which case they'll also cut off your internet feed. What good is your 7-week's worth of diesel going to do you then?
Furthermore, it doesn't make any difference how physically secure your boxen are, if you're running an OS with networking vulnerabilities, or are vulnerable to DOS attacks.
The most secure solution is complete redundancy/distribution, in both physical and network space. The most obvious example is Freenet, which sadly isn't quite mainstream-useable yet.
Store your documents in a distributed fashion across thousands of machines. Encrypt them, so even the individual user doesn't know what his cache contains. Cryptographically sign each piece of content you produce. How is anyone going to fuck with your site when it's in a thousand different places?
World-Renowned my ass.
Hmmm.
Trying to correctly simulate a bunch of cubes colliding with each other, and eventually coming to rest in contact with each other (and the ground) will convince you pretty damn quickly that Euler integration isn't sufficient for proper physics simulation.
The point you miss is that as time goes on, more and more developers are incorporating some form of "proper" physics simulation into their games, since pre-canned animations can only take you so far. Thus, Euler integration becomes less and less suitable.
I wouldn't make sweeping statements regarding the other guy's game dev experience - it sounds an awful lot like all you've done is springs and bouncing balls. Rigid body mechanics is a whole different world, and is likely to play a larger and larger part in videogames as CPUs become more and more capable of dealing with it.
http://www.d6.com/users/checker/dynamics.htm
provides an excellent, and free alternative to purchasing a weighty tome on the subject. Chris covers the details of rigid body mechanics in a thorough, but light manner.
I went to a physics lecture at GDC, the most memorable part of which was Chris saying:
"Here's how it's going to go... you're going to write your first rigid body dynamics simulator. You're going to simulate a cube dropping onto a plane. You'll run the program, the cube will drop, hit the plane... and disappear."
So, so true.
If any of you here are British, (or just inordinately fond of the ZX-Spectrum, or Timex-Sinclair whatever-it-was-released-as-in-the-USA), you may be interested in looking at http://foon.pocketheaven.com.
You need a GBA flash cart (available from a number of vendors), and a GameBoy advance. Hey presto - portable Speccy!
I'll concede it's a little light on the technical details, but don't forget that this article is targetted at Joe Public.
I think you missed the most revealing fact in the article: 8 out of 12 networks detected were not even using 802.11 encryption at all. Yes, we all know that 802.11 encryption is not secure, but the fact that people are broadcasting unencrypted packets does mean that the networks are incredibly insecure. I'm thinking of SMB, POP3, TELNET, FTP, or any other number of services that transmit either plaintext or weakly encrypted passwords.
Yes, people should use VPNs, but the point of the article was that they're not.
Also, "war driving" and "war pedalling" are actual, legitimate terms - I've seen them used on many occasions before, as would you, had you researched this at all before spouting off.
MP3Public is a PIC-microcontroller based MP3 player, using a MAS3507D DSP chip for decoding. It supports both CD-ROM and HD's. The HD uses a custom filesystem, with tracks/albums being downloaded through the parallel port. I built the original a few years ago (actually, I think it was one of the first working HD-based players), and others have contributed significantly to the code/design.
Firmware/schematics/PC-side source code are all open-sourced. There's a fairly clean C++ library for talking to the player and downloading tracks. I'm really hoping some kind soul will use this to write a nice GUI download application for Linux and Windows. (The current software is Windows only, and crashes fairly regularly).
Needless to say, this is a fairly complex project - don't try building one unless you've got a fair deal of soldering experience!
Slashdot doesn't censor.
By browsing at +1 (or whatever), the reader is making a decision to ignore posts that (generally like-minded) reads have chosen to ignore. This is extraordinarily effective at filtering out annoying "first post" drivel.
One might accuse moderators of modding down things they don't agree with, but if you look closely, there are many pro-MS posts that get modded up to +5 because they're intelligently written and raise good points that are worth thinking about. Remember that moderators aren't necessarily evil people - they're ordinary readers, just like you and me.
Regardless of all this, however, there is still no censorship. Your post doesn't get deleted. Anyone who wants to read your post can do so by browsing at -1.
Well, like dropping port 80 packets from offending users!
You're right about the DENY/REJECT though - I hadn't spotted that - nice one.
The biggest problem, presumably, is the fact that it's chewing up your network bandwidth. Adding ipchains rules will cause your machine to ignore the packets, but they're still consuming time on your DSL/cable/whatever link.
What we really need is for ISP's to take a slightly more aggressive (but directed) approach.
I explained what they were - bear in mind that your stack is now reversed, and is growing "rightwards".
return addr is the RA pointing back into the function that called BadFunction.
retaddr#2 is the RA pointing into BadFunction (BadFunction having called strcpy).
(The ebp's are just the stack frame pointers corresponding to each call).
The snapshot of the stack I illustrated was while strcpy is executing. My point was that you can still overflow the end of badBuf and scribble on retAddr#2 - thus, when strcpy returns, it will jump to an arbitrary address.
Doesn't seem any harder or easier than overflowing a buffer using a normal stack direction. Both situations require knowledge of the local stack frame layout, but that's about it.
Actually, thinking about it, the only difference is that you would need to make sure your buffer doesn't overflow *too* far, or you'll scribble on strcpy's local variables, possibly preventing it from returning.