32-bit Linux has similar limitations, too. OS needs to reserve *some* addresses to access other hardware such as CPU registers, PCI cards, etc. Since 32-bit CPUs can only count up to 2^32, it cannot address all the locations in RAM. This is definitely not just Microsoft....:-)
If that number is sufficiently high, I move out of cash and into stocks, even onto margin if I think the economy is doing well. This way, I can take a 50% hit in the stock market and still not have to panic and get out.
Hmmm.... This sounds like an algorithm for making one "buy high and sell low." Didn't they teach you in school that in order to make a profit, you need to do exactly the opposite?
This cracked me up, man. IIRC a couple of years ago people used to write a whole kernel in 415. Of course I never took that since I took 414 over the summer and 415 wasn't offered.
I took CS 415 in 94 (Maybe 95. I am not sure any more....) We wrote a preemptive threading library on SunOS. (How many CS Cornellians still remember the good old Sunlab?) I remember in order to allocate stack space for each task without mucking around with the stack pointer, we were told to setjmp, call a function containing a large local variable, and then longjmp. The task would then use the space for the local variable as stack space. I thought that was kind of interesting.
Obviously the course seems to have gone downhill from the previous posts....:-(
You might also ask how long it takes to get to the position of "senior programmer" or equivalent. If it takes only six to eight years or less to reach that level, you might ask what the career path looks like beyond "senior programmer," and how many people get beyond that level.
Whoa. Personally I like companies with a more result-oriented approach. Instead of having a set time schedule on what position an employee can reach, one's position should be based on the person's skill and experience. A senior staff should have the technical knowledge required for completing the project and evaluate the recommendations submitted by members of the team, and enough experience to be a team leader. On top of that, the senior staff should also know his or her own personal limitations and know when to ask for help (but is still experienced and knowledgeable enough to distinguish a good idea from bad ones).
I'm 26, four years out of college. Yes, my official title is "Senior Software Engineer." I've been in the leadership position for many projects, working with people much older than myself, and am totally comfortable with it.
On the other hand, I believe talking to senior staff during interviews is crucial in evaluating the success of the company. If you don't think you would trust the person in senior staff to run a successful project if you were the company's CEO, I'd put a big question mark on the state of the company.
As to life after being a senior staff, there are always more challenging projects out there, or more challenging jobs in other fields....
Their reply was something to the effect of, "well, that's exactly what we do. We develop strictly for NT, because that's how it's done in business today. NT is simply the standard, and it's the best." I laughed at them and left, but I could have laughed at them all I wanted because in the end, they may be wrong about NT being the best, but they're RIGHT about NT being what people want.
My solution for avoiding coding in Win32 (that API drives me nuts!) is getting into embedded development. Here Microsoft's presence can hardly be felt. Not that Bill didn't try to get his hands into the embedded world, fortunately most embedded people are hard-core engineers. They know a piece of junk software when they see one (read: Windows CE). Most RTOS bear more resemblance to UNIX than Windows. People are just becoming aware of embedded Linux now. Heck, sometimes when you get lucky, you might even get to write a Linux device driver or two like I did last year. The only down side is that the best development and debugging tools seem to come out first for the Windows platform. But at least I don't have to code Windows, just use it.
If you like solving complex problems and writing tight, efficient code instead of spending most of your time drawing GUI on screen, I highly recommend giving embedded development a try. You won't regret it.
The problem is sadly, that neither Microsoft or you it seems are familiar with a concept much of the world is quite comfortable with. We call them seasons. And if there were no unix vendors at your summer job fair it is because they know summer was 2 months ago.
In case you don't know, on college campuses companies are actively recruiting interns for the COMING summer (i.e. summer 2001) along with permanent employees TODAY.
It's nuts. I know. But this is just the nature of business in this field.
One of my stock questions is this: "Write a function to accept an array of items, and sort them according to some ordering appropriate to the type of the items. You may use any language, and types of items (integers, floating point numbers, strings, etc.), but you will have to explain the complexity of the function in 'big-O(n)' notation. It doesn't have to be the most efficient algorithm."
Guess what? 95% of the candidates can't do this!
Many similar experiences here. You'd be surprised how many people applying to be embedded developers are clueless about my first question: write a piece of code that wait until the most significant bit of the 8-bit register at address 0x2000 to be set. Very few get past my second: Discuss the impact of a busy-wait loop such as
while( !( *(volatile char *)0x2000 & 0x80 ) );
on a real time system.
Some companies are very willing to train people, but one can't expect to be taught trignometry if he or she has never bothered to memorize the multiplication table!
32-bit Linux has similar limitations, too. OS needs to reserve *some* addresses to access other hardware such as CPU registers, PCI cards, etc. Since 32-bit CPUs can only count up to 2^32, it cannot address all the locations in RAM. This is definitely not just Microsoft.... :-)
Thanks for sharing this cool tip. Wish MacOS X existed when I was learning English 20 years ago :-)
Cell phones also have been around for a lot longer htan 25 years.
8 99 .htm
http://inventors.about.com/library/weekly/aa070
If that number is sufficiently high, I move out of cash and into stocks, even onto margin if I think the economy is doing well. This way, I can take a 50% hit in the stock market and still not have to panic and get out.
:-b
Hmmm.... This sounds like an algorithm for making one "buy high and sell low." Didn't they teach you in school that in order to make a profit, you need to do exactly the opposite?
This cracked me up, man. IIRC a couple of years ago people used to write a whole kernel in 415. Of course I never took that since I took 414 over the summer and 415 wasn't offered.
:-(
I took CS 415 in 94 (Maybe 95. I am not sure any more....) We wrote a preemptive threading library on SunOS. (How many CS Cornellians still remember the good old Sunlab?) I remember in order to allocate stack space for each task without mucking around with the stack pointer, we were told to setjmp, call a function containing a large local variable, and then longjmp. The task would then use the space for the local variable as stack space. I thought that was kind of interesting.
Obviously the course seems to have gone downhill from the previous posts....
You might also ask how long it takes to get to the position of "senior programmer" or equivalent. If it takes only six to eight years or less to reach that level, you might ask what the career path looks like beyond "senior programmer," and how many people get beyond that level.
Whoa. Personally I like companies with a more result-oriented approach. Instead of having a set time schedule on what position an employee can reach, one's position should be based on the person's skill and experience. A senior staff should have the technical knowledge required for completing the project and evaluate the recommendations submitted by members of the team, and enough experience to be a team leader. On top of that, the senior staff should also know his or her own personal limitations and know when to ask for help (but is still experienced and knowledgeable enough to distinguish a good idea from bad ones).
I'm 26, four years out of college. Yes, my official title is "Senior Software Engineer." I've been in the leadership position for many projects, working with people much older than myself, and am totally comfortable with it.
On the other hand, I believe talking to senior staff during interviews is crucial in evaluating the success of the company. If you don't think you would trust the person in senior staff to run a successful project if you were the company's CEO, I'd put a big question mark on the state of the company.
As to life after being a senior staff, there are always more challenging projects out there, or more challenging jobs in other fields....
Their reply was something to the effect of, "well, that's exactly what we do. We develop strictly for NT, because that's how it's done in business today. NT is simply the standard, and it's the best." I laughed at them and left, but I could have laughed at them all I wanted because in the end, they may be wrong about NT being the best, but they're RIGHT about NT being what people want.
My solution for avoiding coding in Win32 (that API drives me nuts!) is getting into embedded development. Here Microsoft's presence can hardly be felt. Not that Bill didn't try to get his hands into the embedded world, fortunately most embedded people are hard-core engineers. They know a piece of junk software when they see one (read: Windows CE). Most RTOS bear more resemblance to UNIX than Windows. People are just becoming aware of embedded Linux now. Heck, sometimes when you get lucky, you might even get to write a Linux device driver or two like I did last year. The only down side is that the best development and debugging tools seem to come out first for the Windows platform. But at least I don't have to code Windows, just use it.
If you like solving complex problems and writing tight, efficient code instead of spending most of your time drawing GUI on screen, I highly recommend giving embedded development a try. You won't regret it.
The problem is sadly, that neither Microsoft or you it seems are familiar with a concept much of the world is quite comfortable with. We call them seasons. And if there were no unix vendors at your summer job fair it is because they know summer was 2 months ago.
In case you don't know, on college campuses companies are actively recruiting interns for the COMING summer (i.e. summer 2001) along with permanent employees TODAY.
It's nuts. I know. But this is just the nature of business in this field.
One of my stock questions is this: "Write a function to accept an array of items, and sort them according to some ordering appropriate to the type of the items. You may use any language, and types of items (integers, floating point numbers, strings, etc.), but you will have to explain the complexity of the function in 'big-O(n)' notation. It doesn't have to be the most efficient algorithm."
Guess what? 95% of the candidates can't do this!
Many similar experiences here. You'd be surprised how many people applying to be embedded developers are clueless about my first question: write a piece of code that wait until the most significant bit of the 8-bit register at address 0x2000 to be set. Very few get past my second: Discuss the impact of a busy-wait loop such as
while( !( *(volatile char *)0x2000 & 0x80 ) );
on a real time system.
Some companies are very willing to train people, but one can't expect to be taught trignometry if he or she has never bothered to memorize the multiplication table!