I graduated in 1988 (yes, an old fart in the technical world.) I am saddened, but not terribly surprised, to hear this.
I can't really say we put any effort into trying to catch people cheating. There may well have been people cheating madly when I was there, but I wasn't aware of it. The honor code was something that us arrogant engineering students were proud of. If that's no longer the case, that is truly sad.
The whole point of the Honor Code, IMHO, is that most people, when expected to act honorably, will do so. It sounds like you did. If it's now considered an anachronism that nobody believes in anymore, then nobody is really expected to follow it...just to not get caught. Also, it's worth mentioning that in my day, the honor code was a point of pride not just with the students, but faculty as well--and not just as a power-trip tool.
Don't let the bastards get you down. You're better off for doing it the right way, even though those around you didn't. The lame fucks who cheated their way through the program will have their karma cashed in when they go to work and suddenly don't know how to solve a problem on their own.
You really don't learn shit as an undergrad per se...what you get (if you do the work) is a toughened analytical mind that can later be trained on learning what you really need to know and solving real-world problems. I've run into graduates from other engineering/CS schools who, when confronted with a problem, couldn't solve it, then came back to me looking for the answer. They were then surprised to hear me say, "I don't know the answer. If I knew the answer, I would've already solved the problem. You're not in school anymore. You're an engineer now. It's your job to provide the answer."
If fixing the COE honor system is at the bottom of the to-do list, then it's already dead.
I can only speak for my umich experience. gatech's honor code may suck, or it may not.
When I was at the University of Michigan as an engineering student, our honor code was (and still is) something my fellow students and I were proud of. I didn't know of anyone who cheated, and wouldn't have associated with them if I thought they were.
It looks like it's changed slightly since I was there: when I was a student, instructors were required to leave the room during an examination (now it says "the instructor need not monitor examinations in engineering classes.") We were required to write "I have neither given nor received aid on this examination." and sign it.
We didn't have proctors. We could talk to each other if there was a reasonable need to (e.g.: "my copy is blurry...does this say 6.7 or 8.7?") We could get up and leave the room, get a drink, go to the bathroom...
...and we didn't cheat. I failed more than one exam when I could have cheated and passed, and had friends that did the same--I recall one who wrote the pledge "I have OBVIOUSLY neither given nor received aid on this examination."
We had take-home exams from time to time. Same rules. Some homework was teamwork, other required you to do it yourself. But we played by the rules, and I think I'm a better engineer and person for doing so.
Of course, all of our classes weren't in the College of Engineering. In other colleges, there was no such honor code. Proctors walked up and down the aisles. No talking. No leaving the room. And far too many of them (the lesser non-engineering mortals) cheated like it was nothing.
If the gatech student in question knew and understood the rules and broke them anyway, then I have no sympathy for him. I didn't graduate U of M with a spectacular GPA, but I earned every 0.01 point of it.
That being said, if the article is correct in stating that gatech is now forbidding students to do any learning for the class from any sources than officially sanctioned Georgia Tech course materials and instructors, then I suggest he either get together with other like-minded students and faculty to change this system, or find a better school where he might learn something. Most of what I learned was a result of group study. Anything worth learning won't be comprehended totally the first time you read it or hear it in a lecture.
It's not enough to try and cover the security issues, then throw your hands in the air and say "We're helpless!" when someone circumvents your security. You need to develop contingency plans for when your security is compromised and one of your birds is attacked.
As mentioned by another poster, unless nobody ever leaves your company and nobody ever talks, you can be vulnerable even if the protocols are never published. It is difficult, but not impossible, to reverse-engineer these protocols. It may be easier with your birds than with the commercial communications satellites I'm familiar with, as the downlinked data is probably more tightly coupled to the operational scenario (i.e.: your commands to the spacecraft will be reflected in the data stream coming down, which probably isn't encrypted.) It's pretty hard to tell the effects of most maintenance commands from the ground unless you have a telemetry receiver, which are expensive, platform-specific, and hard to come by. And you still have to know the protocol to decode the telemetry.
You may have a closed network, but it only takes one moron with a notebook and a modem who forgets to disconnect from the intranet before dialing up their ISP to change that. Or someone with a compromised computer which is then connected to your intranet. *sniff* *sniff*
A DoS attack doesn't have to be deliberate to be effective. The gremlins can get you as well; e.g.: backup command center is offline as online command's HPA fails, and nobody can talk to the bird. You need to be able to deal with these types of outages as well.
The moral of this story: the security issues are simply additional operational scenarios to address, just like a communications, gyro, or power system failure. You try to prevent these as best as you can, but you also must plan on such problems occurring in spite of your best efforts, and be ready to address them. You won't be able to think of every one, but every one you address in advance improves your chances of being able to recover from the incident.
You may want to integrate security breaches into your procedures as another failure mode; e.g.: battery heater fails. Possible causes: (1) failure of heater element, (2) power bus overload; (3) disabled by unauthorized command. Some scenarios may lead to total mission failure. C'est la vie. At least, if you've thought of the scenario in advance, you have the advantage of forethought if and/or when the problem actually occurs.
Linux Central (http://www.linuxcentral.com) sells SuSE CDs for $1.95 which include YaST.
I purchased the SuSE 6.0 GPL CD, and yes, it does have it. Boots, installs using YaST, etc.
The YaST license says you have to get permission to distribute YaST on a "data carrier" if there's a charge for it. It explictly allows distributing YaST free of charge via FTP or mail.
Apparently (hopefully!) Linux Central got permission.
Maybe CheapBytes refuses to distribute it on principle? Or just plain laziness? I don't know.
Linux is no threat to Microsoft. You have the software market wrapped up. Don't worry about it. Relax. Take a nice long vacation. Don't bother thinking about Linux again.
The machine I mentioned earlier (I'm at it now): a Packard Bell 880 with Award v4.51PG. I had it set to boot LS120, and it still didn't work. However, I didn't write LILO to the "last partition.": I either repartitioned it, or wrote the fs to the whole device (/dev/hdc.) Either way, it failed as described previously.
Can you post or email me the lilo.conf you got it to work with?
I'm 1 for 2 with a 2.0.36 kernel with LILO 20. Results seem to vary with BIOS:
AMI BIOS 1.16a on a Tyan S1836 Thunder 100 motherboard: LILO works, but in the BIOS setup, you have to change ARMD emulation from Auto to hard disk.
OTOH, using a Packard Bell with Award BIOS (I don't have the version # here), I couldn't make it work. I tried every LILO incantation I could find; got nothing but L01 01 01... I also tried writing a kernel directly to the disk. That gets "Loading.............", then hangs.
It's too bad--painfully slow, but it makes for one hell of a rescue disk. Now if it would only work on more than one computer I know of....
On both systems, I could use a 1.44M floppy to boot, then use the root filesystem on the LS-120. Swell, if you want an LS-120 and a standard floppy.
Slashdot Mirror
I graduated in 1988 (yes, an old fart in the technical world.) I am saddened, but not terribly surprised, to hear this.
I can't really say we put any effort into trying to catch people cheating. There may well have been people cheating madly when I was there, but I wasn't aware of it. The honor code was something that us arrogant engineering students were proud of. If that's no longer the case, that is truly sad.
The whole point of the Honor Code, IMHO, is that most people, when expected to act honorably, will do so. It sounds like you did. If it's now considered an anachronism that nobody believes in anymore, then nobody is really expected to follow it...just to not get caught. Also, it's worth mentioning that in my day, the honor code was a point of pride not just with the students, but faculty as well--and not just as a power-trip tool.
Don't let the bastards get you down. You're better off for doing it the right way, even though those around you didn't. The lame fucks who cheated their way through the program will have their karma cashed in when they go to work and suddenly don't know how to solve a problem on their own.
You really don't learn shit as an undergrad per se...what you get (if you do the work) is a toughened analytical mind that can later be trained on learning what you really need to know and solving real-world problems. I've run into graduates from other engineering/CS schools who, when confronted with a problem, couldn't solve it, then came back to me looking for the answer. They were then surprised to hear me say, "I don't know the answer. If I knew the answer, I would've already solved the problem. You're not in school anymore. You're an engineer now. It's your job to provide the answer."
If fixing the COE honor system is at the bottom of the to-do list, then it's already dead.
I think I'm going to drink heavily now. *sigh*
I can only speak for my umich experience. gatech's honor code may suck, or it may not.
When I was at the University of Michigan as an engineering student, our honor code was (and still is) something my fellow students and I were proud of. I didn't know of anyone who cheated, and wouldn't have associated with them if I thought they were.
For the curious, here's the umich honor code
It looks like it's changed slightly since I was there: when I was a student, instructors were required to leave the room during an examination (now it says "the instructor need not monitor examinations in engineering classes.") We were required to write "I have neither given nor received aid on this examination." and sign it.
We didn't have proctors. We could talk to each other if there was a reasonable need to (e.g.: "my copy is blurry...does this say 6.7 or 8.7?") We could get up and leave the room, get a drink, go to the bathroom...
...and we didn't cheat. I failed more than one exam when I could have cheated and passed, and had friends that did the same--I recall one who wrote the pledge "I have OBVIOUSLY neither given nor received aid on this examination."
We had take-home exams from time to time. Same rules. Some homework was teamwork, other required you to do it yourself. But we played by the rules, and I think I'm a better engineer and person for doing so.
Of course, all of our classes weren't in the College of Engineering. In other colleges, there was no such honor code. Proctors walked up and down the aisles. No talking. No leaving the room. And far too many of them (the lesser non-engineering mortals) cheated like it was nothing.
If the gatech student in question knew and understood the rules and broke them anyway, then I have no sympathy for him. I didn't graduate U of M with a spectacular GPA, but I earned every 0.01 point of it.
That being said, if the article is correct in stating that gatech is now forbidding students to do any learning for the class from any sources than officially sanctioned Georgia Tech course materials and instructors, then I suggest he either get together with other like-minded students and faculty to change this system, or find a better school where he might learn something. Most of what I learned was a result of group study. Anything worth learning won't be comprehended totally the first time you read it or hear it in a lecture.
As mentioned by another poster, unless nobody ever leaves your company and nobody ever talks, you can be vulnerable even if the protocols are never published. It is difficult, but not impossible, to reverse-engineer these protocols. It may be easier with your birds than with the commercial communications satellites I'm familiar with, as the downlinked data is probably more tightly coupled to the operational scenario (i.e.: your commands to the spacecraft will be reflected in the data stream coming down, which probably isn't encrypted.) It's pretty hard to tell the effects of most maintenance commands from the ground unless you have a telemetry receiver, which are expensive, platform-specific, and hard to come by. And you still have to know the protocol to decode the telemetry.
You may have a closed network, but it only takes one moron with a notebook and a modem who forgets to disconnect from the intranet before dialing up their ISP to change that. Or someone with a compromised computer which is then connected to your intranet. *sniff* *sniff*
A DoS attack doesn't have to be deliberate to be effective. The gremlins can get you as well; e.g.: backup command center is offline as online command's HPA fails, and nobody can talk to the bird. You need to be able to deal with these types of outages as well.
The moral of this story: the security issues are simply additional operational scenarios to address, just like a communications, gyro, or power system failure. You try to prevent these as best as you can, but you also must plan on such problems occurring in spite of your best efforts, and be ready to address them. You won't be able to think of every one, but every one you address in advance improves your chances of being able to recover from the incident.
You may want to integrate security breaches into your procedures as another failure mode; e.g.: battery heater fails. Possible causes: (1) failure of heater element, (2) power bus overload; (3) disabled by unauthorized command. Some scenarios may lead to total mission failure. C'est la vie. At least, if you've thought of the scenario in advance, you have the advantage of forethought if and/or when the problem actually occurs.
Linux Central (http://www.linuxcentral.com) sells SuSE CDs for $1.95 which include YaST.
I purchased the SuSE 6.0 GPL CD, and yes, it does have it. Boots, installs using YaST, etc.
The YaST license says you have to get permission to distribute YaST on a "data carrier" if there's a charge for it. It explictly allows distributing YaST free of charge via FTP or mail.
Apparently (hopefully!) Linux Central got permission.
Maybe CheapBytes refuses to distribute it on principle? Or just plain laziness? I don't know.
Linux is no threat to Microsoft.
You have the software market wrapped up.
Don't worry about it.
Relax.
Take a nice long vacation.
Don't bother thinking about Linux again.
I have to get back to work now....
The machine I mentioned earlier (I'm at it now): a Packard Bell 880 with Award v4.51PG. I had it set to boot LS120, and it still didn't work. However, I didn't write LILO to the "last partition.": I either repartitioned it, or wrote the fs to the whole device (/dev/hdc.) Either way, it failed as described previously.
Can you post or email me the lilo.conf you got it to work with?
!||
I'm 1 for 2 with a 2.0.36 kernel with LILO 20. Results seem to vary with BIOS:
.............", then hangs.
AMI BIOS 1.16a on a Tyan S1836 Thunder 100 motherboard: LILO works, but in the BIOS setup, you have to change ARMD emulation from Auto to hard disk.
OTOH, using a Packard Bell with Award BIOS (I don't have the version # here), I couldn't make it work. I tried every LILO incantation I could find; got nothing but L01 01 01... I also tried writing a kernel directly to the disk. That gets "Loading
It's too bad--painfully slow, but it makes for one hell of a rescue disk. Now if it would only work on more than one computer I know of....
On both systems, I could use a 1.44M floppy to boot, then use the root filesystem on the LS-120. Swell, if you want an LS-120 and a standard floppy.
C'est la PC.