This! I had to reload my psmouse module half way through the album. Apparently this is not so uncommon on Dell laptops.
I read the source code, and it was trivial. But the very large byte array size makes this something that's generally inadvisable, precisely because you could jump somewhere into it where the audio happens to be specific byte code. I also discovered it from tweets coming out of thegrugq, etc.
C is a perfect language for back-dooring code. Without good tools - even for the sake of code reviewers that are trying to defend the code base against good malicious programmers - we won't be able to keep up. Most C code is going to be full of accidental back doors, and possibly a few intentional ones. Something has to be done about machine assisted proof of memory safety, and about ensuring that parse code either follows a spec or stops parsing the input. High level languages with memory safe semantics are essentially constructive proof of memory safety at the cost of performance. You can also go the route of fixing the defaults of what is going to be allowed in important C files, and force programmers to #pragma their way out of violating the constraints so that potential bugs are easy to spot. Or better yet, stop using read() in the raw to ingest input; and force the code to parse input with a well defined grammar (and fail to compile otherwise).
You don't necessarily need an abstract garbage collected language that prevents you from cutting yourself. What you really need is by any means necessary to limit security critical code to constructs that the compiler can prove the consistency of. Code review should essentially amount to the reviewer making a list of proof demands, with the review process failing until there are machine checkable proofs of these facts. Every exception to these rules (Supress warnings, or accepting a hand proof, or proof by authority) need to be documented at the line where they happen. That way, when the next back door is discovered, we can easily search for the place that introduced it.
This is not theoretical at all. I worked with a guy who was publicly accused of back dooring a Unix. No amount of code review will clear anyone of suspicion; because we use the crappiest tools for proving correctness of even small things.
You have to calculate it as: (Sales + JobOpportunities - (Taxes + Hardware + Software + Books + TheJobYouCantTakeWhileYouDoDev)).... If you really are good enough to make a profitable app that covers all of your costs, then TheJobYouCantTakeWhileYouDoDev is about $100000. I put my well paid day job at risk doing part time mobile app development for a few years. My partner did in fact quit to do it full time (and eventually got tired of making $30k a year for 60hr workweeks doing work at about the $130k/year level - and found a remote development gig through the connections that app development gave him.)
I calculate that had I quit the job to do it full time, it would be roughly competitive with my day job; but with very large variables for both risk and future opportunities. I consider it roughly equivalent to getting a Masters Degree. I learned a lot about the business side of development.
There are other ways, like the military. I work at a place that is full of kernel developers. Most of our people have college degrees, but it seems that our best people went straight into tech work in the Israeli military and didn't stop to go to college when their mandatory service was up. It's different from the US because everybody does 3 years of military before they are able to go to college; but it seems to effectively provide a nationalized trade school that precedes college.
For mobile apps, this is actually not a bad idea if you can afford to fail; because you are still unattached enough that nobody depends on your income in a critical way. If nobody is going to pay your way through college, then you have nothing to lose. Get your failures and experience in before you have a house and a kid. LinkedIn will light up for you as a side-effect.
A lot of my friends are the top developers in the iOS music app space; and I was in the mosh pit trying to make it happen along with them (while working a good full-time job - contemplating full time app dev). A small number of them make a healthy living doing little more than occasional maintenance on long-shipped apps while using the rest of their time learning the craft and having a life. 90% of them fail badly, with improved job prospects. The 30% Apple tax is high, but the mobile user mindset is what makes it hard. The large volume of users that can drive your asking price down nicely can also be a major support nightmare because you have to deal with them directly. You will deal with fads, gaming the review system (ie: send you an email that implies that if they don't get something for free in a few days that you will get a 1 star review, or requesting refunds while keeping the app and still sending support questions for months on end).
The huge numbers of apps can make it hard to get a foothold on iOS/Android. On other platforms, even a well promoted and executed (even best and only for its category) app can still fail because there really are almost no users. Even given a *great* app and somebody that's good at the business, it's still far more of a gamble than showing up to a job and knowing how much you will make. But it's far better to do this while you are living with your mom than sitting around doing nothing or working an unskilled job for minimum wage.
Then remake the math curriculum around coding and probability. You should be writing lisp(?) programs to do your symbolic (not numeric) solves very early on. Put discrete math and probability far before calculus; and focus on writing programs to do the solves rather than on doing the calculations.
Whipping up an app that succeeds just well enough to get into production but not to actually survive it is a problem that purely vocational training doesn't help with. That is how you end up with situations where a contractor is brought in to clean up a mess or to move blame to the contractor.
The basics of computational complexity need to be absorbed before you can make web sites; even if they are all being hosted in AppEngine or AWS. Computer Science education is a bit floppy about teaching good software engineering (ie: small conceptual changes creating small code changes, making code organization scale, making efficient abstractions that don't leak). There comes a day where a vocational developer encounters major performance problems and things like this are found all over the code:
1) immutable string append in a loop (not understanding what O(n^2) means)
2) select * from two giant tables and group by unindexed field (not understanding what O(n^2) means)
3) deeply nested for/while loops (not understanding what O(n^2) means
4) data races (not having a coherent model of how the computer works, or what to do if you dont want to have to think about it too carefully)
Slashdot Mirror
This! I had to reload my psmouse module half way through the album. Apparently this is not so uncommon on Dell laptops. I read the source code, and it was trivial. But the very large byte array size makes this something that's generally inadvisable, precisely because you could jump somewhere into it where the audio happens to be specific byte code. I also discovered it from tweets coming out of thegrugq, etc.
C is a perfect language for back-dooring code. Without good tools - even for the sake of code reviewers that are trying to defend the code base against good malicious programmers - we won't be able to keep up. Most C code is going to be full of accidental back doors, and possibly a few intentional ones. Something has to be done about machine assisted proof of memory safety, and about ensuring that parse code either follows a spec or stops parsing the input. High level languages with memory safe semantics are essentially constructive proof of memory safety at the cost of performance. You can also go the route of fixing the defaults of what is going to be allowed in important C files, and force programmers to #pragma their way out of violating the constraints so that potential bugs are easy to spot. Or better yet, stop using read() in the raw to ingest input; and force the code to parse input with a well defined grammar (and fail to compile otherwise). You don't necessarily need an abstract garbage collected language that prevents you from cutting yourself. What you really need is by any means necessary to limit security critical code to constructs that the compiler can prove the consistency of. Code review should essentially amount to the reviewer making a list of proof demands, with the review process failing until there are machine checkable proofs of these facts. Every exception to these rules (Supress warnings, or accepting a hand proof, or proof by authority) need to be documented at the line where they happen. That way, when the next back door is discovered, we can easily search for the place that introduced it. This is not theoretical at all. I worked with a guy who was publicly accused of back dooring a Unix. No amount of code review will clear anyone of suspicion; because we use the crappiest tools for proving correctness of even small things.
You have to calculate it as: (Sales + JobOpportunities - (Taxes + Hardware + Software + Books + TheJobYouCantTakeWhileYouDoDev)) .... If you really are good enough to make a profitable app that covers all of your costs, then TheJobYouCantTakeWhileYouDoDev is about $100000. I put my well paid day job at risk doing part time mobile app development for a few years. My partner did in fact quit to do it full time (and eventually got tired of making $30k a year for 60hr workweeks doing work at about the $130k/year level - and found a remote development gig through the connections that app development gave him.)
I calculate that had I quit the job to do it full time, it would be roughly competitive with my day job; but with very large variables for both risk and future opportunities. I consider it roughly equivalent to getting a Masters Degree. I learned a lot about the business side of development.
There are other ways, like the military. I work at a place that is full of kernel developers. Most of our people have college degrees, but it seems that our best people went straight into tech work in the Israeli military and didn't stop to go to college when their mandatory service was up. It's different from the US because everybody does 3 years of military before they are able to go to college; but it seems to effectively provide a nationalized trade school that precedes college.
For mobile apps, this is actually not a bad idea if you can afford to fail; because you are still unattached enough that nobody depends on your income in a critical way. If nobody is going to pay your way through college, then you have nothing to lose. Get your failures and experience in before you have a house and a kid. LinkedIn will light up for you as a side-effect. A lot of my friends are the top developers in the iOS music app space; and I was in the mosh pit trying to make it happen along with them (while working a good full-time job - contemplating full time app dev). A small number of them make a healthy living doing little more than occasional maintenance on long-shipped apps while using the rest of their time learning the craft and having a life. 90% of them fail badly, with improved job prospects. The 30% Apple tax is high, but the mobile user mindset is what makes it hard. The large volume of users that can drive your asking price down nicely can also be a major support nightmare because you have to deal with them directly. You will deal with fads, gaming the review system (ie: send you an email that implies that if they don't get something for free in a few days that you will get a 1 star review, or requesting refunds while keeping the app and still sending support questions for months on end). The huge numbers of apps can make it hard to get a foothold on iOS/Android. On other platforms, even a well promoted and executed (even best and only for its category) app can still fail because there really are almost no users. Even given a *great* app and somebody that's good at the business, it's still far more of a gamble than showing up to a job and knowing how much you will make. But it's far better to do this while you are living with your mom than sitting around doing nothing or working an unskilled job for minimum wage.
Then remake the math curriculum around coding and probability. You should be writing lisp(?) programs to do your symbolic (not numeric) solves very early on. Put discrete math and probability far before calculus; and focus on writing programs to do the solves rather than on doing the calculations. Whipping up an app that succeeds just well enough to get into production but not to actually survive it is a problem that purely vocational training doesn't help with. That is how you end up with situations where a contractor is brought in to clean up a mess or to move blame to the contractor. The basics of computational complexity need to be absorbed before you can make web sites; even if they are all being hosted in AppEngine or AWS. Computer Science education is a bit floppy about teaching good software engineering (ie: small conceptual changes creating small code changes, making code organization scale, making efficient abstractions that don't leak). There comes a day where a vocational developer encounters major performance problems and things like this are found all over the code: 1) immutable string append in a loop (not understanding what O(n^2) means) 2) select * from two giant tables and group by unindexed field (not understanding what O(n^2) means) 3) deeply nested for/while loops (not understanding what O(n^2) means 4) data races (not having a coherent model of how the computer works, or what to do if you dont want to have to think about it too carefully)