Try all kinds of new things; take the harder classes if they are topics you don't yet know about but are interested in. Find the people who will be good, reliable, long term friends, and stay in touch after college.
Go to parties, get laid, but be responsible! Know if you are the kind of person who is prone to abuse, and if so, address the issue. Otherwise, do some drinking, or whatever (stay AWAY from E), and have some fun. But find out about emergency contraception, and don't do anything to excess.
Manage your own bills, try to find roomates or housemates who will elevate you, not bring you down. DON'T watch lots of TV (unless it is in a social way), but go to movies with friends.
Go to the library, walk around, check out the journals, books, etc. All the ones you haven't seen before. Don't blow off the required classes that aren't in your major; try to find rewarding or interesting ones, and pay attention. Don't expect to end up where you think you will, expect to find NEW things. Talk with the professors in their office hours, and get to know a few (but don't be too pushy, just drop by, even if you don't have to)
If you like doing things on your own, try to find partners to do projects with. Expect LOTS of people to be working together, on homework, projects, even tests. Students cheat, don't let it surprise you. Learn to collaborate (and give credit when it is required), while turning in work that reflects what you have done.
Get outside, go to events. Hang out in the field; go to the gym. Try not to eat crappy cafeteria food all the time. Take some extracurriculars (aikido, fencing, swimming, whatever).
Don't shy away from theory stuff, even if it isn't your thing. If you are all about theory, get some practical stuff as well (and get to know people who are good in what you aren't, and talk with them). Geek out and enjoy, if you wish. But not always. Look into exchange student programs, and consider some studying abroad, in exotic locales.
Enjoy. I went in as a skeptic, and am very glad I went.
I use assertions (in a crude "precondition/postcondition/invariant check" manner), and I haven't used a debugger in years (the occasional printf solves the rest).
So that isn't an answer, but it may be that developing a test suite (unit tests, plus assertions), may obviate the need for a debugger even on existing projects.
At the Great Pyramids, in Egypt, during the night show, countless numbers of people were taking photos with their flashes on (I mean HUNDREDS of flashes in the course of a few minutes). This was in a viewing area that was probably a mile away, and every time a flash went off, all you could see was the dust right in front of your face. It was glaringly obvious that the pictures wouldn't come out, but everyone still did it.
And in St. Peter's Cathedral, people would stand at the entrance and try to get a flash picture of the whole interior. I turned off my flash and got a gorgeous photo (holding my camera rock still). Then I turned the flash on the see what everyone else was gonna get (out of curiosity). Pure gray washed out haze.
What amazes me is that most of these people will probably never learn on their own, even when they get their ruined pictures back.
As an American, I must remind you that we would no doubt be just another member of the British commonwealth, if the French had not seen to it that we won the War of Independence. We repayed our debt in WWII (IMO), but we musn't forget that they helped us first.
Oh, one more thing. I use an external USB mouse with my iBook, which has three buttons and a wheel. It works fine under both MacOS X (where the extra buttons give context specific menus, etc.) and Debian. I find this much nicer than the trackpad/single button that comes built in; but I've never really liked any other pointing device than a mouse with at least two buttons.:)
Okay, I'll clear that up. The version I have has a 15 gig drive (small, but enough for now). I have it split in half; one half being a Debian partition, the other a MacOS X partition. Basically, when I got it, I wasn't sure which I'd use more, so I can boot into either. I do NOT have OS 9 installed (and thus I opted for the UFS file system for Mac OS X, which I've learned is slower than the HFS+ filesystem, at least as implemented)
I personally use Debian about 100% of the time; I just have it all set up the way I like things, and haven't had time to get into OS X. The original poster was asking about OS X, so that is why I talked about it more. But I'd suggest that people just use what they like; OS X seems to have a lot of potential.
I use my iBook2 a lot, running Linux. I carry it around lots of places. It is lite, durable, QUIET! (no fan, and a quiet drive); in short a very good geek computer for a low budget.
You could pick the older model up (say 500 Mhz, ATI Rage Pro; not Radeon) for a decent price, I bet. I bought a carry sleeve from Waterfield Designs (www.sfbags.com) that keeps it very safe in my backpack. I find it feels a bit more rugged than the HP or Compaqs in a similar price range (but less than the heavier Thinkpads, which I used to have)
OSX, formatted with HFS+, I hear is pretty fast if you get the latest versions (online update). I use Debian Linux on it, and am not lacking any features (plus I get ext3, which is fast and I can just poweroff in a pinch)
Battery is okay, but only if you turn down the screen brightness, and make some tunings to the drive spin down (under Linux, probably is better under OS X on batteries). I can get four hours out of it fairly easy.
This is probably a result of C99 deciding that these keywords ("xor", "and", "or", etc.) were now acceptable (There were introduced by C++). However, they are only supposed to be enabled by a certain include. Anyway, possibly not a bug, and almost certainly an overridable option.
Yeah, but it depends if the nature of the exploit is one that yields execution privileges (such as corrupting the user stack and running your own code before sshd drops down from root), or is a protocol weakness which then allows you to (for example) bypass authentication and log in, which would give you user privileges (assuming root logins are disabled).
My favorite bit of inaccuracy in "The Mummy Returns", is when the heroes fly past the temple of Abu Simpel (at the southern border of modern day egypt). The temple in the movie looks like it does today, carved out of a mound of earth, on a flat plain. However, when the movie took place, that famous temple was carved into a cliff just a few dozen yards away from the Nile river. It was moved (in a VERY famous project) to higher ground in the 1960s, to avoid being drowned by a man-made lake.
Many issues old of National Geographic are available to show the painters and animators how it looked at the time of the movie, which shows how lazy the historical consultants for the movie must have been. Also, it would have been a nice opportunity to show the temple in it's original (and MUCH grander) location.
This was featured in a Scientific America article in the mid to late 80's (A. K. Dewdney's column, I believe). One could look up the specific article, if no one here can provide it.
A "salt" is a little bit of randomness to increase entropy (information content). Say you have a simple password ("apple"), without a 'salt' added. Then someone just needs to encrypt the entire dictionary, which has the word "apple" in it, and compare the encrypted result to your encrypted password. They will easily be able to see that "apple" is your password (because the encryptions match). Note that they only had to encrypt the dictionary ONCE, to detect any simple dictionary password.
Now, suppose that your password "apple" had 12 random bits added to it BEFORE it was encrypted. Those 12 random bits are not-secret (they are published along with the encrypted password+salt). The person who wants to use a dictionary attack on your password has to first look at your salt, and add it to all the words in their dictionary before encrypting and comparing them. Thus, they either have to generate (and store) encrypted dictionaries with all possible salts, or wait until they know your salt to start encrypting. Either way, you given them more work (possibly a LOT more work).
Finally, if they get a thousand encrypted passwords, each with a different salt, they have to do 1000 dictionary searches (one per each unique salt), rather than just one.
So, 'salts' are just small bit of randomness that are added to a lot of cryptographic protocols (and are crucial to certain more advanced protocols), do basically eliminate certain simple cracking methods, without adding much complexity or work for the legitimate users of the protocol.
Let's say we could use any of approximately 96 printable ASCII characters (in actuality, the password may allow non-printable, or international characters)
Also, let's assume passwords must be at LEAST 4 characters (I don't know what restrictions, if any, are applicable to MacOS X).
Then we have 96^8 + 96^7 + 96^6 + 96^5 + 96^4 = 7289831534100480 passwords.
So, assuming about 10% of those are "guessable" by standard dictionary cracking methods (a ridiculously high amount), you have 728983153410048 non-guessable passwords (about 2^52).
That is A LOT to brute force. That doesn't even take into account the use of 'salts' to help discourage dictionary attacks.
So, true, allowing longer passwords would be nice. But it isn't even close to a troubling limitation. If you need more protection for your data, use mcrypt.
A bigger concern would be if Mac OS X didn't use a shadow password file (anyone?), and if it doesn't at least to a rudimentary check to disallow easily guessable passwords. I assume Mac OS X can be configured to be insecure (boot up into desktop without a password), or more secure (passords required, easy passwords disallowed, etc.)
I found it non-intuitive as well, but that is the answer: You need an additional 2*pi feet (approx. six feet) of cord to raise it a foot above the equator, all the way around...
They don't. If they want to store your VISA info on their server (to allow for faster processing by repeat customers), they store it hashed, and check it against the infor that you re-enter each time (say just your card number and expiration date).
They could use an offline system to do the actual billing, which is keyed on hashed info sent by the server that interacts with customers. But no net reachable computer should be storing the raw credit card info, and hashing can help make this separation easy and still secure.
(This is one I heard; I didn't think it up myself)
If you wrapped a cord around the Earth's equator (assuming a perfectly round, solid Earth), and then wished to lengthen that cord so that it could be suspended one foot above the equator at every point, while still making a full loop around, by how much would you have to lengthen the cord?
It has been shown that encryption keys can easily be found in dumps of memory, because their entropy patterns do not match surrounding memory. It helps to produce hashed chunks of memory as decoys, and then embed the key in one of these chunks (obviously, the chunks should have a similar entropy profile as the surrounding decoy memory).
If these are session keys, this obfuscation can help delay the time it would take to discover the key (by following pointers, etc.). But just storing keys in memory, without obfuscation of some sort, is a no-no.
Credit cards should, ideally, NEVER be stored online. They should be combined with other necessary information (name, address, etc.), then stored as a hash (just like UNIX does with the secret password file). Any intruder who gets the hashed data won't directly be able to use a credit card.
BTW, it is also the way Slashdot should have been storing user passwords (except that they want to be able to mail your password to you). For that, they need an offline database, and the encrypted passwords could be loaded into memory with a session key, as above.
Slashdot Mirror
Try all kinds of new things; take the harder classes if they are topics you don't yet know about but are interested in. Find the people who will be good, reliable, long term friends, and stay in touch after college.
Go to parties, get laid, but be responsible! Know if you are the kind of person who is prone to abuse, and if so, address the issue. Otherwise, do some drinking, or whatever (stay AWAY from E), and have some fun. But find out about emergency contraception, and don't do anything to excess.
Manage your own bills, try to find roomates or housemates who will elevate you, not bring you down. DON'T watch lots of TV (unless it is in a social way), but go to movies with friends.
Go to the library, walk around, check out the journals, books, etc. All the ones you haven't seen before. Don't blow off the required classes that aren't in your major; try to find rewarding or interesting ones, and pay attention. Don't expect to end up where you think you will, expect to find NEW things. Talk with the professors in their office hours, and get to know a few (but don't be too pushy, just drop by, even if you don't have to)
If you like doing things on your own, try to find partners to do projects with. Expect LOTS of people to be working together, on homework, projects, even tests. Students cheat, don't let it surprise you. Learn to collaborate (and give credit when it is required), while turning in work that reflects what you have done.
Get outside, go to events. Hang out in the field; go to the gym. Try not to eat crappy cafeteria food all the time. Take some extracurriculars (aikido, fencing, swimming, whatever).
Don't shy away from theory stuff, even if it isn't your thing. If you are all about theory, get some practical stuff as well (and get to know people who are good in what you aren't, and talk with them). Geek out and enjoy, if you wish. But not always. Look into exchange student programs, and consider some studying abroad, in exotic locales.
Enjoy. I went in as a skeptic, and am very glad I went.
Yes, they are related. Fred Fish even helped develop it, IIRC.
Use LVM, filesystem snapshots, and tar (or cpio).
You say in your post:
Don't post.
and yet your signature says:
The act of censorship is always worse than whatever is being censored.
Seems a bit strange, is all...
I use assertions (in a crude "precondition/postcondition/invariant check" manner), and I haven't used a debugger in years (the occasional printf solves the rest).
So that isn't an answer, but it may be that developing a test suite (unit tests, plus assertions), may obviate the need for a debugger even on existing projects.
At the Great Pyramids, in Egypt, during the night show, countless numbers of people were taking photos with their flashes on (I mean HUNDREDS of flashes in the course of a few minutes). This was in a viewing area that was probably a mile away, and every time a flash went off, all you could see was the dust right in front of your face. It was glaringly obvious that the pictures wouldn't come out, but everyone still did it.
And in St. Peter's Cathedral, people would stand at the entrance and try to get a flash picture of the whole interior. I turned off my flash and got a gorgeous photo (holding my camera rock still). Then I turned the flash on the see what everyone else was gonna get (out of curiosity). Pure gray washed out haze.
What amazes me is that most of these people will probably never learn on their own, even when they get their ruined pictures back.
No wonder the rock rolled aside...
As an American, I must remind you that we would no doubt be just another member of the British commonwealth, if the French had not seen to it that we won the War of Independence. We repayed our debt in WWII (IMO), but we musn't forget that they helped us first.
Ummmmm... George Harrison, too.
Oh, one more thing. I use an external USB mouse with my iBook, which has three buttons and a wheel. It works fine under both MacOS X (where the extra buttons give context specific menus, etc.) and Debian. I find this much nicer than the trackpad/single button that comes built in; but I've never really liked any other pointing device than a mouse with at least two buttons. :)
Okay, I'll clear that up. The version I have has a 15 gig drive (small, but enough for now). I have it split in half; one half being a Debian partition, the other a MacOS X partition. Basically, when I got it, I wasn't sure which I'd use more, so I can boot into either. I do NOT have OS 9 installed (and thus I opted for the UFS file system for Mac OS X, which I've learned is slower than the HFS+ filesystem, at least as implemented)
I personally use Debian about 100% of the time; I just have it all set up the way I like things, and haven't had time to get into OS X. The original poster was asking about OS X, so that is why I talked about it more. But I'd suggest that people just use what they like; OS X seems to have a lot of potential.
I use my iBook2 a lot, running Linux. I carry it around lots of places. It is lite, durable, QUIET! (no fan, and a quiet drive); in short a very good geek computer for a low budget.
You could pick the older model up (say 500 Mhz, ATI Rage Pro; not Radeon) for a decent price, I bet. I bought a carry sleeve from Waterfield Designs (www.sfbags.com) that keeps it very safe in my backpack. I find it feels a bit more rugged than the HP or Compaqs in a similar price range (but less than the heavier Thinkpads, which I used to have)
OSX, formatted with HFS+, I hear is pretty fast if you get the latest versions (online update). I use Debian Linux on it, and am not lacking any features (plus I get ext3, which is fast and I can just poweroff in a pinch)
Battery is okay, but only if you turn down the screen brightness, and make some tunings to the drive spin down (under Linux, probably is better under OS X on batteries). I can get four hours out of it fairly easy.
This is probably a result of C99 deciding that these keywords ("xor", "and", "or", etc.) were now acceptable (There were introduced by C++). However, they are only supposed to be enabled by a certain include. Anyway, possibly not a bug, and almost certainly an overridable option.
True; but I didn't want to jump to any conclusions before the details are released.
Yeah, but it depends if the nature of the exploit is one that yields execution privileges (such as corrupting the user stack and running your own code before sshd drops down from root), or is a protocol weakness which then allows you to (for example) bypass authentication and log in, which would give you user privileges (assuming root logins are disabled).
But this time it was posted just after a story about growing new Thymus organs. Probably not a coincidence...
My favorite bit of inaccuracy in "The Mummy Returns", is when the heroes fly past the temple of Abu Simpel (at the southern border of modern day egypt). The temple in the movie looks like it does today, carved out of a mound of earth, on a flat plain. However, when the movie took place, that famous temple was carved into a cliff just a few dozen yards away from the Nile river. It was moved (in a VERY famous project) to higher ground in the 1960s, to avoid being drowned by a man-made lake.
Many issues old of National Geographic are available to show the painters and animators how it looked at the time of the movie, which shows how lazy the historical consultants for the movie must have been. Also, it would have been a nice opportunity to show the temple in it's original (and MUCH grander) location.
Solving a maze is a good example of recursion.
So is solving a maze.
This was featured in a Scientific America article in the mid to late 80's (A. K. Dewdney's column, I believe). One could look up the specific article, if no one here can provide it.
A "salt" is a little bit of randomness to increase entropy (information content). Say you have a simple password ("apple"), without a 'salt' added. Then someone just needs to encrypt the entire dictionary, which has the word "apple" in it, and compare the encrypted result to your encrypted password. They will easily be able to see that "apple" is your password (because the encryptions match). Note that they only had to encrypt the dictionary ONCE, to detect any simple dictionary password.
Now, suppose that your password "apple" had 12 random bits added to it BEFORE it was encrypted. Those 12 random bits are not-secret (they are published along with the encrypted password+salt). The person who wants to use a dictionary attack on your password has to first look at your salt, and add it to all the words in their dictionary before encrypting and comparing them. Thus, they either have to generate (and store) encrypted dictionaries with all possible salts, or wait until they know your salt to start encrypting. Either way, you given them more work (possibly a LOT more work).
Finally, if they get a thousand encrypted passwords, each with a different salt, they have to do 1000 dictionary searches (one per each unique salt), rather than just one.
So, 'salts' are just small bit of randomness that are added to a lot of cryptographic protocols (and are crucial to certain more advanced protocols), do basically eliminate certain simple cracking methods, without adding much complexity or work for the legitimate users of the protocol.
Let's say we could use any of approximately 96 printable ASCII characters (in actuality, the password may allow non-printable, or international characters)
Also, let's assume passwords must be at LEAST 4 characters (I don't know what restrictions, if any, are applicable to MacOS X).
Then we have 96^8 + 96^7 + 96^6 + 96^5 + 96^4 = 7289831534100480 passwords.
So, assuming about 10% of those are "guessable" by standard dictionary cracking methods (a ridiculously high amount), you have 728983153410048 non-guessable passwords (about 2^52).
That is A LOT to brute force. That doesn't even take into account the use of 'salts' to help discourage dictionary attacks.
So, true, allowing longer passwords would be nice. But it isn't even close to a troubling limitation.
If you need more protection for your data, use mcrypt.
A bigger concern would be if Mac OS X didn't use a shadow password file (anyone?), and if it doesn't at least to a rudimentary check to disallow easily guessable passwords. I assume Mac OS X can be configured to be insecure (boot up into desktop without a password), or more secure (passords required, easy passwords disallowed, etc.)
I found it non-intuitive as well, but that is the answer: You need an additional 2*pi feet (approx. six feet) of cord to raise it a foot above the equator, all the way around...
They don't. If they want to store your VISA info on their server (to allow for faster processing by repeat customers), they store it hashed, and check it against the infor that you re-enter each time (say just your card number and expiration date).
They could use an offline system to do the actual billing, which is keyed on hashed info sent by the server that interacts with customers. But no net reachable computer should be storing the raw credit card info, and hashing can help make this separation easy and still secure.
(This is one I heard; I didn't think it up myself)
If you wrapped a cord around the Earth's equator (assuming a perfectly round, solid Earth), and then wished to lengthen that cord so that it could be suspended one foot above the equator at every point, while still making a full loop around, by how much would you have to lengthen the cord?
It has been shown that encryption keys can easily be found in dumps of memory, because their entropy patterns do not match surrounding memory. It helps to produce hashed chunks of memory as decoys, and then embed the key in one of these chunks (obviously, the chunks should have a similar entropy profile as the surrounding decoy memory).
If these are session keys, this obfuscation can help delay the time it would take to discover the key (by following pointers, etc.). But just storing keys in memory, without obfuscation of some sort, is a no-no.
Credit cards should, ideally, NEVER be stored online. They should be combined with other necessary information (name, address, etc.), then stored as a hash (just like UNIX does with the secret password file). Any intruder who gets the hashed data won't directly be able to use a credit card.
BTW, it is also the way Slashdot should have been storing user passwords (except that they want to be able to mail your password to you). For that, they need an offline database, and the encrypted passwords could be loaded into memory with a session key, as above.