That has got to be the sorriest excuse I've ever heard for piracy. It doesn't matter where the costs come from. Besides, if marketing, managers, and salespeople didn't exist, you would never have seen most software products out there.
Re:this isn't the same as creating open-software
on
The Need for Open Hardware
·
· Score: 5, Informative
With a $99 FPGA development board and the free design tools from Xilinx, you too can make your own CPU without even breaking out a soldering iron.:)
There are legitimate uses for mod chips. For one to develop games without paying Sony the 30k for a development set. I know people that are doing this very thing, using modified PS2s to develop and test games without paying for a full dev kit for every employee.
And if you re-read my post you will see I am against piracy of any type. No I do not have a hacked cable box. This is different.
It sounds like he was also selling pirated games. I wonder if they would ever have cracked down on him if all he had done was sell and install mod chips. The article seems to downplay the fact that he was selling pirated games as well.
Even though I think selling mod chips shouldn't be illegal, I don't have sympathy for people who are selling pirated software!
There is a patch out there for sharing a single window (only works with the windows server right now) for TightVNC. I believe that the maintainer of tightvnc plans to integrate this functionality in the future (based on a posting to the tightvnc mailing list).
Since I was about 10, I have been very interested in AI, and typed in a BASIC version of Eliza from a book a long time ago.
I'm wondering how much ALICE is an improvement on the fundamental design of ELIZA? Is it just a more complex ELIZA, or is there a real technology improvement involved? This question isn't to imply that ALICE isn't a major functional improvment over ELIZA, it's just a question of technology.
BTW, a fun thing to say to ALICE is 'your stupid', I love it's response:
I may be stupid, but at least I know the difference between "your" and "you're."
First, get a good debugger. An old DOS version of SoftICE would do the trick.
Next, set it up to send a test message, like "test 12345". Then set a breakpoint in the code that starts transmitting to the serial port. That shouldn't be hard to figure out with some old DOS references.
Then run the program, and when the breakpoint hits search memory for your test string. Then you find the memory location of the buffer being sent by the application. Then set a memory breakpoint so the debugger will break when that buffer is read, and continue the program and have it send the message again. Now you should be able to zero in on the crc code, as it reads the buffer to compute the checksum.
Once you find the loop of asm code that's computing it, you should be able to understand the algorithm pretty easy.
1. Authentication comes before association, not the other way around as the article mentioned. Authentication was not added in 802.11b it was there in the original 802.11 spec. 2. Decryption takes no longer with 128 bit wep than it does with 64bit wep. This depends on the actual RC4 implementation, but anyone who implemented RC4 in a way that it takes twice as long to crypt a 128bit string than it does to do 64 bits doesn't know what they are doing. Most implementations use a lookup table that makes encryption take the same amount of time regardless of key length. I'm no encryption expert, but I believe that all symetric algorithms share this attribute. It certainly won't "drastically shrink useable bandwidth" unless you have a very lame access point or 802.11 card. I don't believe any implementation will reduce the bandwidth at all by using 128 bit encryption. 3. Turning off beacon frames breaks some important 802.11 features, such as power management support. What most vendors do is not disable sending beacons, but they lie about the ssid (or leave it blank) in the beacons, and only respond to probe requests if the client request the correct ssid in the probe. 4. Turning off or hiding the ssid gives you no security whatsoever. All it does is keep the casual person from seeing your network. Any form of WEP will work better than that, because the casual user won't be able to exchange data packets on your network. The professional cracker will not be slowed down at all by hiding the ssid, all it takes is a sniffer to listen for a probe request/response which contains the actual ssid. Anyone who thinks they are securing their network in this way is deluding themselves. 5. I won't repeat the comments previously made about the authors incorrect understanding of how RC4 works, and why it is exploitable in this implementation.
After I finish reading the parts on 802.1x maybe I'll add to this list.:)
UDP does have flow control, as does all IP traffic. Unfortunately the sockets API don't consistently support it. It's called an ICMP source quench message, and it tells the sending application that the receiving side couldn't keep up (or a router in the middle couldn't keep up). It's not UDP's fault that the APIs don't support flow control well, it's the fault of the OS and the sockets layers that it's not easy to use.
I've spent the past several years writing networking applications, and this is my philosophy: Anytime there is *any* chance of a packet being lost or arriving out of order, you must write code that assumes every packet has a high probability of being lost. I've seen people make assumptions that since it's running on an ethernet lan they will never lose UDP packets, then their app becomes very unstable. Even when sending UDP packets to localhost they can be lost. When designing UDP software it shouldn't be a matter of how often packets are lost, but how well your code deals with lost packets. Now if only someone would standardize a reliable datagram protocol implementation.:)
I've been working on this over the past couple of years. I bought a Minolta Dimage scan dual II film scanner(they're pretty cheap on ebay these days) which can scan whole roll of crappy APS film (I had about 50 rolls) in one shot. For 35mm it will do 6 negatives at a time. The resolution is pretty good, but you have to do some color correction still (like they do when they make prints). I've archived almost 3000 pictures this way so far.
I've got a lot of prints without negatives, for those I scan with a flatbed.
I always scan at the highest resolution, then I batch convert everything down to different resolutions, and archive everything with dates/keyword/etc. to a database using a PHP image gallery I wrote.
It's very time consuming, but nice to be able to find images so easily.
I think that list is a bunch of crap. Companies don't just pay what they think you are worth, they pay what they think will keep you working for them up until the point they think you aren't worth the money you want.
In otherwords if you accepted the job for $40k and they know you are worth $100k, most companies aren't going to walk over and say "you know, you are underpaid, here's $60k a year more." No, they will say "great job, here's a $5k a year raise!
But when it comes down to you demanding more, or telling them you are leaving they will pay you what they need to in order to keep you.
Too many people look at employment as a personal relationship, but it is much better for everyone to remember that it is a bussiness relationship for both the employee and employer.
I've got one of these, it's based on a cypress USB chip, which includes an internal 8051 cpu. Full datasheets are available for this chip. The source to the linux driver for the USB controller is also available. The device gets it's firmware from the driver on the host CPU, so it's really easy to write 8051 code and try it out on the device. I've got mine wired up to access onboard memory on my FPGA development kit, which makes for really fast IO between the FPGA and the host PC.
I didn't feel the company who makes this thing was very customer oriented, but the part itself is really cool, and highly recommended.
I think you probably are doing something wrong. I just set CVS_RSH in my wink2 user environment (CVS_RSH=ssh), and cygwin gets it just fine. As long as ssh is in your path you shouldn't need to specify the full path to your ssh executable.
Having spent 2 years as a senior programmer at a game company, I would reccomend you ask yourself if you really understand what you said about long shifts.
If you can't find the time to make at least a simple game, you are never going to be able to deal with working for a game company (I know I couldn't, which is why I left), many of which will require you to pull 14-16 hour days during crunch mode, which often lasts several months, and happens several times a year (e3 demos, releasing a game, producing demos to get project funding, etc).
Having said that, I know at least one programmer who came on right out of college and worked his way into a design position pretty fast. All he did was work hard, and contribute a lot to the game design process while he was working as a programmer. It quickly became obvious he was good at design, so he was put in a design role. Getting into a game company as a programmer would be a good start, and if you really are talented as a designer (just wanting to design games doesn't mean you *can* design fun games) and express your desire to management, you probably will get there pretty fast.
Personally, I'd rather code, and work an 8 hour day.:)
I've got an ipaq 3870 with the pcmcia sleeve and a cisco 350 802.11 card. It's awesome.
If you use a cisco access point and card you can use LEAP to get real security.
The ipaq has IE and outlook on it, and has really good handwriting recognition. It also has a windows terminal services client, and there is a vnc client ported for it. I'd say it's just what you are looking for.
I spent several weeks in a German hotel, using an IBM ISP account with a local number. To my surprise, the hotel charged me about $600 in fees for an average of 15 minutes per day over 7 weeks.
Americans are used to unlimited flat rate local calls, but in Germany I believe all calls are charged per minute. The hotels also add a hefty fee on top of that.
As someone who found a very good paying job in IT at the age of 16 (and graduated from high-school early) let me give you some advice.
Forget about the IT consulting for now unless you can do it part time, and spend the next 4-6 years in college.
I'm now 29, married with a 2 year old and working very hard to get a degree (ie. up all night doing homework). Not having the degree hasn't prevented me from getting a good paying job, but I know I could have done better with the degree. At this point in my career I don't think I can progress much more without it. I've sort of hit the "no degree ceiling".
When I was your age I thought "who needs a degree when people are willing to pay me this much without it". Don't give in to that reasoning, it's short term thinking. I don't care how smart you are, a degree is a must. You might not miss it 5 years from now, but I know you will wish you had gotten it 10 or 15 years from now if you don't. If for no other reason, because 90% of those you will be competing with for salary and jobs will have it.
I don't care if you have to get a loan and live poorly for the next few years, it will be worth it!
Sorry, but that's utter crap. Simple code is every bit as straight forward as comments in english.
You claim that code cannot be tested unless it's documented. Then how do you test the comment that is supposed to be describing the code? It's just as likely to be wrong as the code is itself. Example:
// This code prints foo to the console printf("bar");
Why should the comment be the true authority? It's no more an authority than the code. I've seen countless examples of the comments being far out of date compared to the code.
The point is that simple code *is* obvious and doesn't need any further comments.
I wasn't talking about the design document, I was talking about the inline documentation, aka comments. I think all code should be designed before it's built and that design should take the form of a document, but that is not the same discussion we were having.
It seems to me after a while you will end up with a huge amount of comments in your code. Isn't that what revision control is for? If you use CVS and you want to see why something was changed, you can do an annotate to see when it was changed and who changed it, then read their comments.
I can see where you would do what when supporting 'finished' product, but for a project under development or in a beta stage, I think you would end up with way to many bug #'s to make the code readable.
BTW, I agree with what you say about quality vs. quantity.
The article made reference to someone who coded bug-free code but didn't document it, and how that meant he probably wasn't productive. It is that statement I think is wrong. I'm much more interested in how he coded it than how he documented it.
Don't get me wrong, commenting your code is a must.
However, I would rather have a programmer who writes easily understood code but doesn't document it well than one who writes well documented but overly complex code.
I've worked on large projects where there was nearly a 1:1 ratio of comments to code, but the comment didn't help you see the big picture because the parts of the application were too far abstracted from reality. And the code was written in strange ways that made it hard for other people to understand.
In summary, the code can and show be written so that most of it documents itself. If the application is well designed and the code is written well, the need for a lot of in-code commenting goes way down. This is assuming we're not talking about assembler, which in my opinion should have a nearly 1:1 ratio of code/comments.
Slashdot Mirror
Let me know what you think again *after* you get a job in the real world.
That has got to be the sorriest excuse I've ever heard for piracy. It doesn't matter where the costs come from. Besides, if marketing, managers, and salespeople didn't exist, you would never have seen most software products out there.
With a $99 FPGA development board and the free design tools from Xilinx, you too can make your own CPU without even breaking out a soldering iron. :)
There are a lot of open hardware designs at www.opencores.org.
CPU cores, Ethernet MACs, complete SOC designs, etc. It's a great site, especially if you are into fpga development.
Right. My point though, is would the hardware charges have been pursued on their own without the piracy charges.
I'm also curious who determines what is "authorized" under Canadian law.
There are legitimate uses for mod chips. For one to develop games without paying Sony the 30k for a development set. I know people that are doing this very thing, using modified PS2s to develop and test games without paying for a full dev kit for every employee.
And if you re-read my post you will see I am against piracy of any type. No I do not have a hacked cable box. This is different.
It sounds like he was also selling pirated games. I wonder if they would ever have cracked down on him if all he had done was sell and install mod chips. The article seems to downplay the fact that he was selling pirated games as well.
Even though I think selling mod chips shouldn't be illegal, I don't have sympathy for people who are selling pirated software!
There is a patch out there for sharing a single window (only works with the windows server right now) for TightVNC. I believe that the maintainer of tightvnc plans to integrate this functionality in the future (based on a posting to the tightvnc mailing list).
Doh! I do know better than that! How embarrasing! That's one of those things I usually do wrong, but catch on proofreading.
This is slashdot, you don't seriously expect people to proofread their posts do you? It's not like the stories are proofread! :)
Since I was about 10, I have been very interested in AI, and typed in a BASIC version of Eliza from a book a long time ago.
I'm wondering how much ALICE is an improvement on the fundamental design of ELIZA? Is it just a more complex ELIZA, or is there a real technology improvement involved? This question isn't to imply that ALICE isn't a major functional improvment over ELIZA, it's just a question of technology.
BTW, a fun thing to say to ALICE is 'your stupid', I love it's response:
I may be stupid, but at least I know the difference between "your" and "you're."
First, get a good debugger. An old DOS version of SoftICE would do the trick.
Next, set it up to send a test message, like "test 12345". Then set a breakpoint in the code that starts transmitting to the serial port. That shouldn't be hard to figure out with some old DOS references.
Then run the program, and when the breakpoint hits search memory for your test string. Then you find the memory location of the buffer being sent by the application. Then set a memory breakpoint so the debugger will break when that buffer is read, and continue the program and have it send the message again. Now you should be able to zero in on the crc code, as it reads the buffer to compute the checksum.
Once you find the loop of asm code that's computing it, you should be able to understand the algorithm pretty easy.
1. Authentication comes before association, not the other way around as the article mentioned. Authentication was not added in 802.11b it was there in the original 802.11 spec.
:)
2. Decryption takes no longer with 128 bit wep than it does with 64bit wep. This depends on the actual RC4 implementation, but anyone who implemented RC4 in a way that it takes twice as long to crypt a 128bit string than it does to do 64 bits doesn't know what they are doing. Most implementations use a lookup table that makes encryption take the same amount of time regardless of key length. I'm no encryption expert, but I believe that all symetric algorithms share this attribute. It certainly won't "drastically shrink useable bandwidth" unless you have a very lame access point or 802.11 card. I don't believe any implementation will reduce the bandwidth at all by using 128 bit encryption.
3. Turning off beacon frames breaks some important 802.11 features, such as power management support. What most vendors do is not disable sending beacons, but they lie about the ssid (or leave it blank) in the beacons, and only respond to probe requests if the client request the correct ssid in the probe.
4. Turning off or hiding the ssid gives you no security whatsoever. All it does is keep the casual person from seeing your network. Any form of WEP will work better than that, because the casual user won't be able to exchange data packets on your network. The professional cracker will not be slowed down at all by hiding the ssid, all it takes is a sniffer to listen for a probe request/response which contains the actual ssid. Anyone who thinks they are securing their network in this way is deluding themselves.
5. I won't repeat the comments previously made about the authors incorrect understanding of how RC4 works, and why it is exploitable in this implementation.
After I finish reading the parts on 802.1x maybe I'll add to this list.
UDP does have flow control, as does all IP traffic. Unfortunately the sockets API don't consistently support it. It's called an ICMP source quench message, and it tells the sending application that the receiving side couldn't keep up (or a router in the middle couldn't keep up). It's not UDP's fault that the APIs don't support flow control well, it's the fault of the OS and the sockets layers that it's not easy to use.
I've spent the past several years writing networking applications, and this is my philosophy: Anytime there is *any* chance of a packet being lost or arriving out of order, you must write code that assumes every packet has a high probability of being lost. I've seen people make assumptions that since it's running on an ethernet lan they will never lose UDP packets, then their app becomes very unstable. Even when sending UDP packets to localhost they can be lost. When designing UDP software it shouldn't be a matter of how often packets are lost, but how well your code deals with lost packets. :)
Now if only someone would standardize a reliable datagram protocol implementation.
I've been working on this over the past couple of years. I bought a Minolta Dimage scan dual II film scanner(they're pretty cheap on ebay these days) which can scan whole roll of crappy APS film (I had about 50 rolls) in one shot. For 35mm it will do 6 negatives at a time. The resolution is pretty good, but you have to do some color correction still (like they do when they make prints). I've archived almost 3000 pictures this way so far.
I've got a lot of prints without negatives, for those I scan with a flatbed.
I always scan at the highest resolution, then I batch convert everything down to different resolutions, and archive everything with dates/keyword/etc. to a database using a PHP image gallery I wrote.
It's very time consuming, but nice to be able to find images so easily.
I think that list is a bunch of crap. Companies don't just pay what they think you are worth, they pay what they think will keep you working for them up until the point they think you aren't worth the money you want.
In otherwords if you accepted the job for $40k and they know you are worth $100k, most companies aren't going to walk over and say "you know, you are underpaid, here's $60k a year more." No, they will say "great job, here's a $5k a year raise!
But when it comes down to you demanding more, or telling them you are leaving they will pay you what they need to in order to keep you.
Too many people look at employment as a personal relationship, but it is much better for everyone to remember that it is a bussiness relationship for both the employee and employer.
I've got one of these, it's based on a cypress USB chip, which includes an internal 8051 cpu. Full datasheets are available for this chip. The source to the linux driver for the USB controller is also available. The device gets it's firmware from the driver on the host CPU, so it's really easy to write 8051 code and try it out on the device. I've got mine wired up to access onboard memory on my FPGA development kit, which makes for really fast IO between the FPGA and the host PC.
I didn't feel the company who makes this thing was very customer oriented, but the part itself is really cool, and highly recommended.
I think you probably are doing something wrong. I just set CVS_RSH in my wink2 user environment (CVS_RSH=ssh), and cygwin gets it just fine. As long as ssh is in your path you shouldn't need to specify the full path to your ssh executable.
Having spent 2 years as a senior programmer at a game company, I would reccomend you ask yourself if you really understand what you said about long shifts.
:)
If you can't find the time to make at least a simple game, you are never going to be able to deal with working for a game company (I know I couldn't, which is why I left), many of which will require you to pull 14-16 hour days during crunch mode, which often lasts several months, and happens several times a year (e3 demos, releasing a game, producing demos to get project funding, etc).
Having said that, I know at least one programmer who came on right out of college and worked his way into a design position pretty fast. All he did was work hard, and contribute a lot to the game design process while he was working as a programmer. It quickly became obvious he was good at design, so he was put in a design role. Getting into a game company as a programmer would be a good start, and if you really are talented as a designer (just wanting to design games doesn't mean you *can* design fun games) and express your desire to management, you probably will get there pretty fast.
Personally, I'd rather code, and work an 8 hour day.
I've got an ipaq 3870 with the pcmcia sleeve and a cisco 350 802.11 card. It's awesome.
If you use a cisco access point and card you can use LEAP to get real security.
The ipaq has IE and outlook on it, and has really good handwriting recognition. It also has a windows terminal services client, and there is a vnc client ported for it. I'd say it's just what you are looking for.
I spent several weeks in a German hotel, using an IBM ISP account with a local number. To my surprise, the hotel charged me about $600 in fees for an average of 15 minutes per day over 7 weeks.
Americans are used to unlimited flat rate local calls, but in Germany I believe all calls are charged per minute. The hotels also add a hefty fee on top of that.
As someone who found a very good paying job in IT at the age of 16 (and graduated from high-school early) let me give you some advice.
Forget about the IT consulting for now unless you can do it part time, and spend the next 4-6 years in college.
I'm now 29, married with a 2 year old and working very hard to get a degree (ie. up all night doing homework). Not having the degree hasn't prevented me from getting a good paying job, but I know I could have done better with the degree. At this point in my career I don't think I can progress much more without it. I've sort of hit the "no degree ceiling".
When I was your age I thought "who needs a degree when people are willing to pay me this much without it". Don't give in to that reasoning, it's short term thinking. I don't care how smart you are, a degree is a must. You might not miss it 5 years from now, but I know you will wish you had gotten it 10 or 15 years from now if you don't. If for no other reason, because 90% of those you will be competing with for salary and jobs will have it.
I don't care if you have to get a loan and live poorly for the next few years, it will be worth it!
Sorry, but that's utter crap. Simple code is every bit as straight forward as comments in english.
You claim that code cannot be tested unless it's documented. Then how do you test the comment that is supposed to be describing the code? It's just as likely to be wrong as the code is itself. Example:
// This code prints foo to the console
printf("bar");
Why should the comment be the true authority? It's no more an authority than the code. I've seen countless examples of the comments being far out of date compared to the code.
The point is that simple code *is* obvious and doesn't need any further comments.
I wasn't talking about the design document, I was talking about the inline documentation, aka comments. I think all code should be designed before it's built and that design should take the form of a document, but that is not the same discussion we were having.
It seems to me after a while you will end up with a huge amount of comments in your code. Isn't that what revision control is for? If you use CVS and you want to see why something was changed, you can do an annotate to see when it was changed and who changed it, then read their comments.
I can see where you would do what when supporting 'finished' product, but for a project under development or in a beta stage, I think you would end up with way to many bug #'s to make the code readable.
BTW, I agree with what you say about quality vs. quantity.
The article made reference to someone who coded bug-free code but didn't document it, and how that meant he probably wasn't productive. It is that statement I think is wrong. I'm much more interested in how he coded it than how he documented it.
Don't get me wrong, commenting your code is a must.
However, I would rather have a programmer who writes easily understood code but doesn't document it well than one who writes well documented but overly complex code.
I've worked on large projects where there was nearly a 1:1 ratio of comments to code, but the comment didn't help you see the big picture because the parts of the application were too far abstracted from reality. And the code was written in strange ways that made it hard for other people to understand.
In summary, the code can and show be written so that most of it documents itself. If the application is well designed and the code is written well, the need for a lot of in-code commenting goes way down. This is assuming we're not talking about assembler, which in my opinion should have a nearly 1:1 ratio of code/comments.