Speaking as someone seeing first hand the quality of today's college students, I'm not sure I can agree with you that the claim of lackluster US education is a fallacy. Being an older student (due to transferring schools and taking time off), I have the unique perspective of having seen two generations of college students while working towards my degree.
In that time, I have seen the the basic skills of the students decline dramatically. Most of the papers I've read by my classmates read like papers written by non-native speakers of English... and these are the born-and-raised American students! Simple problem-solving skills seem to be non-existent in the current generation of college students. Worst of all, academic dishonesty is rampant--when I started my college career, no one even considered cheating, but now many of the students in my classes cheat without even realizing they're cheating! Even worse, there seems to be an attitude among today's students that they are entitled to pass a class, regardless of their performance.
The only real light of hope I can see in this situation is the fact that the foriegn students, at least the ones from non-Western countries (at my school, I haven't really run into any non-Americans from Europe (perhaps because European schools are good enough that no one wants to come here instead?)), are often worse than the Americans. But I can excuse some of them--they are often not only dealing with difficult topics, but trying to learn them in a language that is not their native tongue.
So, is the US education system better than those in many other countries? I'd have to say yes. From what I can see, however, that's not really saying much. US education definitely needs improvement, because we're no longer substantially better than everyone else. And if we're going to compete, we absolutely must have the best product available, because there's no way we can compete on price.
I mean, if every device has its own atomic clock, the only time you'd have to synchronize them would be when you bring them up, unless you were doing some kind of scientific work that requires ultra-accurate timekeeping. Most other applications (I'm thinking Kerberos, remote logging, etc) would only need to be synchronized to the second (or even less) to be useful.
At least you got the award. My reward, after babying their systems through the blackout last year (not enough UPS to make it through the whole way), coming in at 5:00 in the morning so that everything would be back up and running by the open of business (which it was), and refusing to leave until _every_ system was back up and running at 100% (we had one issue with one of our third-party processors that just wouldn't go away), was to come in on Monday to be fired for not performing up to expectations. They had made the decision the day the blackout hit, but needed me to save their asses first. But I'm not bitter.
I definitely agree that it's easier to write secure Java. And yes, the problem I mentioned was independent of language. But that was the exact point I was trying to make. Just because a language protects you from the simple mistakes (that may be hard to find) doesn't mean that the programmer doesn't still have to be conscious of security.
It could even be argued that Java could, by claiming to be a "secure" language, encourage programmers to be sloppy in regards to security. However, I'm not entirely convinced of that argument myself. The vendor in my example had a long history of obliviousness to security--we only caught this problem because I disassembled the servlet to reengineer other parts of the system that I didn't have access to the source code for. I'm pretty sure that they would have given us an insecure product regardless of the language.
Java may protect you from the common mistakes like buffer overflowas and whatnot, but that doesn't mean that Java code is automatically secure code.
As an example, a company I used to work for contracted out a single-signon module for our website. Basically the user would authenticate to us, and then be passed off to a third-party site. Well, the programmer who wrote the single-signon (in Java) never checked to make sure that someone calling his servlet had a valid session on our system, so by simply caching the page with the link, anyone could get a hold of a user's login to the third party site. Granted, the flaw would be pretty difficult to exploit, since the page was transmitted over SSL, but it was by no means impossible.
So it still requires a security-conscious programmer when writing security-related code, even in Java. The security consciousness is just at a higher level than in C/C++. Java will not force an idiot to write secure code.
1) Put Ghost CD in drive 2) Reboot machine 3) Take nap 4) Take Ghost CD out of drive
Don't have Ghost? Use Knoppix and partimage. There is no reason to waste time cleaning up spyware. None. If it's a corporate machine, all data should be on the corporate file server. If it's a home machine, then all the data should be on a separate partition from the system. In either case, the data should be backed up regularly.
Man, I wish I hadn't already replied on this story and had some mod points... I was actually going to make that comparison in my post, but thought it was too low a blow. I'm glad someone else lacked my sensibilities;)
Rereading my post, it seems I came off a bit harsher than I intended. I mean, they've probably done a lot better and come a lot farther than I could have in the time they've been working on this project. And I do have to give them credit for thoroughness in their post-mortems--they seem to be learning from their mistakes. It just seems that a lot of the post-mortems have been due more to a lack of discipline at the launch pad than a failure in design. As mentioned by a sibling post, what they've got working is incredible... the launch was rock-hard stable until the engine failures occurred, and dynamic stability like that is extremely difficult.
*finally, not setting minimum fuel level for takeoff
They loaded the vehicle up with twice the expected usage; the problem seems have been that they not only burnt more on the ground than they expected, the engine wasn't burning efficiently so they burnt more on the way up too.
Sure, with 20-20 hindsight they could have put more in and/or scrubbed the launch, but they only had the estimated burning rate to go on; and they had expected that to be a lot lower.
It was sloppy not to scrub the launch when the sensors indicated that the pre-launch warmup was out of spec. It's sloppy not to have accurate telemetry on the fuel level. It's sloppy not to have accurate telemetry on the burn rate.
Especially considering they couldn't read the fuel level and monitor the fuel consumption, that launch should never have proceeded without examining the engine to determine why it was underperforming. Unless you're planning on testing failure scenarios, you don't proceed with a launch unless everything is in the green. If something unexpected is happening, it usually means there's a problem. It's always better to stop the launch and determine whether or not the problem is fatal without launching than to proceed with the launch and destroy your only prototype. I'm sorry, but I have to agree with the parent. Armadillo is consistently sloppy when it comes to fault-tolerance and response to unexpected telemetry. It's bad engineering.
That said, they've still done a damn impressive job in spite of their sloppiness.
There's nothing better to stress test the memory, disk, and processor of a new machine like Gentoo. OK, maybe a scientifically engineered burn-in test would guarantee better coverage (especially of the floating point unit) but if all you really want to do is make sure that if anything is going to fail it fails before the warranty is up, gentoo's great... install a full desktop, and if anything's going to break, it will probably break before you're done. Happened to me on my last laptop... it died a week after I bought it... after I was just finishing up my Gentoo install:)
Then you should just back up your mbr before doing the partitioning. That way, if you screw up and write a bad partition table, you can just dump it back on and start over. When you repartition, make sure you can boot into windows before you start formatting partitions, and you should be fine.
To back up your MBR do this (insert a formatted floppy into your drive first:):
Then fdisk to your heart's content. Or you can just do your partitioning using a Knoppix CD and use qtparted, which looks just like PartitionMagic, if you're still a bit queasy. Also, don't forget, until you actually write the new partition table to the disk, you're just working with an in-memory data structure, so feel free to delete and recreate partitions until you get it just right, then write out the new table.
If you try booting back into windows after that, and you screwed up, you can easily restore your MBR:
Why, it's an extra sacred cow. No, really... in India, cows with extra legs are even more sacred than normal cows. I don't know if that's true for other deformities, and I did hear it from a friend who spent most of his trip to India high on hash, but that's what I've been told.
I can't believe I just read that. Maybe this country is going down the tubes after all. I'm very frightened for the future of freedom if political activism and terrorism are now one and the same.
But my partners in several group projects do, and they have come in handy many times when brainstorming to quickly assess the feasibility of our ideas right there. Granted, it could also be done in one of the public labs, but it is far more convenient to be able to work anywhere on campus. Plus, you don't have to deal with all the dirty looks from the people in the labs who are trying to concentrate. After just two semesters, I'm convinced, for the first time, that I could put a laptop to good use _as_ a laptop. Unfortunately, that doesn't make me able to afford one:)
Now that I've checked where I read what I said (the distcc FAQ) it would appear my original post was a little more paranoid than necessary; according to the FAQ, gcc 3.x.y and 3.x.z should be mixable. Of course, it doesn't hurt to make sure that the gcc versions match exactly, just to be safe.
Some of the problems caused by mixing gcc versions, at least from my understanding, may not actually be caught at compile time, and you could end up with binaries that exhibit "strange behavior" with no apparent cause in the source.
Compiler versions should be identical. If the compilers generate different code for the same preprocessed text, weird, bad things can happen, even if compiling and linking succeed, due to one version optimizing a function call one way and the other version optimizing it in a slightly different, and incompatible way or other similar errors. You might be ok if you compile with optimizations turned off, but you're not going to do that for production code.
If you're running gentoo, and doing an emerge -u world, check to see if there's a toolchain upgrade in the mix (gcc or binutils). If there is, then run the toolchain upgrade separately with distcc disabled, then proceed with the rest of the upgrade. That should reduce, if not eliminate all of your issues with distcc.
Re:Using revision control for Web Development
on
Subversion 1.0 Released
·
· Score: 2, Interesting
What I'm going to do when I finally get things set up so that I'm not the only one using scm is set up staging areas as a virtual hosts on the same server as subversion. Every time there's a commit to a developer's branch, it's automatically exported to his staging area so he can test it. If everything works nicely, he can then merge into the global developer branch. Finally, when we're ready to do a full release, we merge the developer branch into the release branch, and it's automatically exported to the production server.
It's a little extra administrative overhead, but worth it for me to do the extra work, since I'm the only one on the team who's ever used scm, so I've got to make at easy for them as I can. Fortunately, for now, it's a small team, so I don't have _too_ much work to do to get it set up... and once I've got everything figured out completely, I can script adds, moves, and changes.
Re:astyle, indent, etc. with subversion
on
Subversion 1.0 Released
·
· Score: 5, Informative
You have 3 different places to hook into the commit cycle in version 1.0:
startcommit
Before the transaction begins, you can prequalify the user for commit privs
pre-commit
After the transaction tree has been completely built, but before it's actually committed to the repository
post-commit
After the entire commit cycle is completed
start-commit is passed the repository and the user, pre-commit is passed the repository and the name of the transaction (which can be examined with svnlook), and post-commit is passed the repository and the revision number. If either start-commit or pre-commit fail, the commit is rolled back; post-commit exit status is ignored.
This could be used to canonize it coming in... it would be up to the user to reformat it coming out if desired... but everything would then get flagged as locally modified... though the user could always recanonize the code before committing... which defeats your goal of automating it all:)
So, the grail is closer, but as always, just out of reach.
Slashdot Mirror
Speaking as someone seeing first hand the quality of today's college students, I'm not sure I can agree with you that the claim of lackluster US education is a fallacy. Being an older student (due to transferring schools and taking time off), I have the unique perspective of having seen two generations of college students while working towards my degree.
In that time, I have seen the the basic skills of the students decline dramatically. Most of the papers I've read by my classmates read like papers written by non-native speakers of English... and these are the born-and-raised American students! Simple problem-solving skills seem to be non-existent in the current generation of college students. Worst of all, academic dishonesty is rampant--when I started my college career, no one even considered cheating, but now many of the students in my classes cheat without even realizing they're cheating! Even worse, there seems to be an attitude among today's students that they are entitled to pass a class, regardless of their performance.
The only real light of hope I can see in this situation is the fact that the foriegn students, at least the ones from non-Western countries (at my school, I haven't really run into any non-Americans from Europe (perhaps because European schools are good enough that no one wants to come here instead?)), are often worse than the Americans. But I can excuse some of them--they are often not only dealing with difficult topics, but trying to learn them in a language that is not their native tongue.
So, is the US education system better than those in many other countries? I'd have to say yes. From what I can see, however, that's not really saying much. US education definitely needs improvement, because we're no longer substantially better than everyone else. And if we're going to compete, we absolutely must have the best product available, because there's no way we can compete on price.
Canada... gotta love the customer service:)
I mean, if every device has its own atomic clock, the only time you'd have to synchronize them would be when you bring them up, unless you were doing some kind of scientific work that requires ultra-accurate timekeeping. Most other applications (I'm thinking Kerberos, remote logging, etc) would only need to be synchronized to the second (or even less) to be useful.
At least you got the award. My reward, after babying their systems through the blackout last year (not enough UPS to make it through the whole way), coming in at 5:00 in the morning so that everything would be back up and running by the open of business (which it was), and refusing to leave until _every_ system was back up and running at 100% (we had one issue with one of our third-party processors that just wouldn't go away), was to come in on Monday to be fired for not performing up to expectations. They had made the decision the day the blackout hit, but needed me to save their asses first. But I'm not bitter.
So, a whole world like my office full of programmers? No thanks.
No, that would be a world of humans without (having) sex.
I definitely agree that it's easier to write secure Java. And yes, the problem I mentioned was independent of language. But that was the exact point I was trying to make. Just because a language protects you from the simple mistakes (that may be hard to find) doesn't mean that the programmer doesn't still have to be conscious of security.
It could even be argued that Java could, by claiming to be a "secure" language, encourage programmers to be sloppy in regards to security. However, I'm not entirely convinced of that argument myself. The vendor in my example had a long history of obliviousness to security--we only caught this problem because I disassembled the servlet to reengineer other parts of the system that I didn't have access to the source code for. I'm pretty sure that they would have given us an insecure product regardless of the language.
Java may protect you from the common mistakes like buffer overflowas and whatnot, but that doesn't mean that Java code is automatically secure code.
As an example, a company I used to work for contracted out a single-signon module for our website. Basically the user would authenticate to us, and then be passed off to a third-party site. Well, the programmer who wrote the single-signon (in Java) never checked to make sure that someone calling his servlet had a valid session on our system, so by simply caching the page with the link, anyone could get a hold of a user's login to the third party site. Granted, the flaw would be pretty difficult to exploit, since the page was transmitted over SSL, but it was by no means impossible.
So it still requires a security-conscious programmer when writing security-related code, even in Java. The security consciousness is just at a higher level than in C/C++. Java will not force an idiot to write secure code.
Less labor-intensive method:
1) Put Ghost CD in drive
2) Reboot machine
3) Take nap
4) Take Ghost CD out of drive
Don't have Ghost? Use Knoppix and partimage. There is no reason to waste time cleaning up spyware. None. If it's a corporate machine, all data should be on the corporate file server. If it's a home machine, then all the data should be on a separate partition from the system. In either case, the data should be backed up regularly.
Man, I wish I hadn't already replied on this story and had some mod points... I was actually going to make that comparison in my post, but thought it was too low a blow. I'm glad someone else lacked my sensibilities ;)
Rereading my post, it seems I came off a bit harsher than I intended. I mean, they've probably done a lot better and come a lot farther than I could have in the time they've been working on this project. And I do have to give them credit for thoroughness in their post-mortems--they seem to be learning from their mistakes. It just seems that a lot of the post-mortems have been due more to a lack of discipline at the launch pad than a failure in design. As mentioned by a sibling post, what they've got working is incredible... the launch was rock-hard stable until the engine failures occurred, and dynamic stability like that is extremely difficult.
*finally, not setting minimum fuel level for takeoff
They loaded the vehicle up with twice the expected usage; the problem seems have been that they not only burnt more on the ground than they expected, the engine wasn't burning efficiently so they burnt more on the way up too.
Sure, with 20-20 hindsight they could have put more in and/or scrubbed the launch, but they only had the estimated burning rate to go on; and they had expected that to be a lot lower.
It was sloppy not to scrub the launch when the sensors indicated that the pre-launch warmup was out of spec. It's sloppy not to have accurate telemetry on the fuel level. It's sloppy not to have accurate telemetry on the burn rate.
Especially considering they couldn't read the fuel level and monitor the fuel consumption, that launch should never have proceeded without examining the engine to determine why it was underperforming. Unless you're planning on testing failure scenarios, you don't proceed with a launch unless everything is in the green. If something unexpected is happening, it usually means there's a problem. It's always better to stop the launch and determine whether or not the problem is fatal without launching than to proceed with the launch and destroy your only prototype. I'm sorry, but I have to agree with the parent. Armadillo is consistently sloppy when it comes to fault-tolerance and response to unexpected telemetry. It's bad engineering.
That said, they've still done a damn impressive job in spite of their sloppiness.
There's nothing better to stress test the memory, disk, and processor of a new machine like Gentoo. OK, maybe a scientifically engineered burn-in test would guarantee better coverage (especially of the floating point unit) but if all you really want to do is make sure that if anything is going to fail it fails before the warranty is up, gentoo's great... install a full desktop, and if anything's going to break, it will probably break before you're done. Happened to me on my last laptop... it died a week after I bought it... after I was just finishing up my Gentoo install:)
Then you should just back up your mbr before doing the partitioning. That way, if you screw up and write a bad partition table, you can just dump it back on and start over. When you repartition, make sure you can boot into windows before you start formatting partitions, and you should be fine.
To back up your MBR do this (insert a formatted floppy into your drive first:):
Then fdisk to your heart's content. Or you can just do your partitioning using a Knoppix CD and use qtparted, which looks just like PartitionMagic, if you're still a bit queasy. Also, don't forget, until you actually write the new partition table to the disk, you're just working with an in-memory data structure, so feel free to delete and recreate partitions until you get it just right, then write out the new table.
If you try booting back into windows after that, and you screwed up, you can easily restore your MBR:
Reboot, and things should be back to how they were before you started.Of course you should still back up any really important stuff, just in case anything else goes wrong.
Why, it's an extra sacred cow. No, really... in India, cows with extra legs are even more sacred than normal cows. I don't know if that's true for other deformities, and I did hear it from a friend who spent most of his trip to India high on hash, but that's what I've been told.
I can't believe I just read that. Maybe this country is going down the tubes after all. I'm very frightened for the future of freedom if political activism and terrorism are now one and the same.
Geez... that's petty. You can't blame the laws of physics on Microsoft, too:)
125 years eh? So you adminned Babbage's Analytical Engine? :)
What lake was that? I could dig some free Cisco gear... and a vacation to Florida to boot:)
But my partners in several group projects do, and they have come in handy many times when brainstorming to quickly assess the feasibility of our ideas right there. Granted, it could also be done in one of the public labs, but it is far more convenient to be able to work anywhere on campus. Plus, you don't have to deal with all the dirty looks from the people in the labs who are trying to concentrate. After just two semesters, I'm convinced, for the first time, that I could put a laptop to good use _as_ a laptop. Unfortunately, that doesn't make me able to afford one:)
Now that I've checked where I read what I said (the distcc FAQ) it would appear my original post was a little more paranoid than necessary; according to the FAQ, gcc 3.x.y and 3.x.z should be mixable. Of course, it doesn't hurt to make sure that the gcc versions match exactly, just to be safe.
Some of the problems caused by mixing gcc versions, at least from my understanding, may not actually be caught at compile time, and you could end up with binaries that exhibit "strange behavior" with no apparent cause in the source.
Compiler versions should be identical. If the compilers generate different code for the same preprocessed text, weird, bad things can happen, even if compiling and linking succeed, due to one version optimizing a function call one way and the other version optimizing it in a slightly different, and incompatible way or other similar errors. You might be ok if you compile with optimizations turned off, but you're not going to do that for production code.
If you're running gentoo, and doing an emerge -u world, check to see if there's a toolchain upgrade in the mix (gcc or binutils). If there is, then run the toolchain upgrade separately with distcc disabled, then proceed with the rest of the upgrade. That should reduce, if not eliminate all of your issues with distcc.
What I'm going to do when I finally get things set up so that I'm not the only one using scm is set up staging areas as a virtual hosts on the same server as subversion. Every time there's a commit to a developer's branch, it's automatically exported to his staging area so he can test it. If everything works nicely, he can then merge into the global developer branch. Finally, when we're ready to do a full release, we merge the developer branch into the release branch, and it's automatically exported to the production server.
It's a little extra administrative overhead, but worth it for me to do the extra work, since I'm the only one on the team who's ever used scm, so I've got to make at easy for them as I can. Fortunately, for now, it's a small team, so I don't have _too_ much work to do to get it set up... and once I've got everything figured out completely, I can script adds, moves, and changes.
You have 3 different places to hook into the commit cycle in version 1.0:
- startcommit
- pre-commit
- post-commit
start-commit is passed the repository and the user, pre-commit is passed the repository and the name of the transaction (which can be examined with svnlook), and post-commit is passed the repository and the revision number. If either start-commit or pre-commit fail, the commit is rolled back; post-commit exit status is ignored.Before the transaction begins, you can prequalify the user for commit privs
After the transaction tree has been completely built, but before it's actually committed to the repository
After the entire commit cycle is completed
This could be used to canonize it coming in... it would be up to the user to reformat it coming out if desired... but everything would then get flagged as locally modified... though the user could always recanonize the code before committing... which defeats your goal of automating it all:)
So, the grail is closer, but as always, just out of reach.
Dang... got my nice, bound copy of the book too soon... they've gone through almost 200 revisions since I printed it:(
That's because they have the stargate and all that cool Goa'uld technology.