<> Find out which operating system the OS class at your university uses, waaaay back in the day it was AT&T Unix, then there was Minix, these days it's usually a flavor of Linux or BSD.
Find the web page for the class that has the build instructions for it and follow those. Get all the source code together and compile and run it. Now make some simple change like altering a boot string to say "Yay I did this." Don't use on of the pre-built VMWare images that just require you to type "make". Download the source code, download GCC and figure out all the configuration stuff needed to build the whole OS. Learn a little bit about each of the tools involved but stay focused on building and running whatever OS it is.
Once you get that far pick one of the easy early exercises like modifying the memory manager or playing with the process scheduling algorithms. Doing all that should give you a pretty good idea if you want to really specialize in OS's and you will do very well when you do take that class.
There's a quote that I can't source at the moment to the effect that "In any reasonable sized group of people there are 10% that are incorruptibly good and 10% that are irredeemably bad and the other 80% will do what the leaders do." If you've got an organization where the leaders think it's okay to pirate software then you've also got an organization where it's okay to not pay suppliers on time or be honest about how much runway is left or any number of other things. It means you can't trust those people. Now there are plenty of monetarily successful organization that run on fear and paranoia and some people can excel in that world. But if you're expecting a bonus or a promotion because someone looked you in the eye and promised it, well, get used to disappointment. The article isn't making a slippery slope argument, it's saying that you're already there, you just might not know it yet.
I think the way to disrupt that is to come up with cheaper treatments and cures that are equally effective. Come up with a way to replace dialysis, or just make it a lot cheaper and you'll save a bunch of money. Obviously prevention is by far the cheapest solution, but some financial incentives to come up with cheaper treatments might be helpful.
But what if those aren't the only two causes of poverty? I don't know if the idea has merit or not, but I think poverty is much more complicated than that.
Let's see, at the 1000 tweets per second figure from the article that's 365 * 24 * 3600 * 500 = 15,768,000,000 tweets for $360,000. Or 0.002 cents per tweet. So 500ish tweets are worth about a penny, and your $360K would be for 15 gigatweets which would weigh in at about 2.2 TB[1]. So my tweets aren't worthless, they're just very very cheap.
[1] That's a hard drive manufacturer terabyte, not a real one
Has anyone got a convenient phrase for this style of blogging? I love having these kinds of BS sessions with my friends, propounding crack-pot theories and generally playing fast and loose with the facts, but it often bugs me when I see it in a blog post. There's absolutely no reason it should bug me, blogging is whatever the blogger wants it to be, but I think if I had a name for it I could quickly go "Oh, this is just a [blank] post" and not feel the need to take it seriously. Sort of like the way Godwin's law helps you filter the worst comment threads into /dev/null. I bet it would be all kinds of fun to have dinner with Scott Adams, I just don't want to mentally peer review his after-dinner conversation.
I believe Xanadu and AMIX were canceled when Carol Bartz took over as CEO in 1992. That may well have been the right business decision to make, but it wasn't a programmer decision. And yes, it seems that Apple is a carefully crafted corporate machine that needs a design-focused highly-opinionated control-oriented person at the top. It will be interesting to someday watch Apple transition to being a post-Jobs company. (full disclosure, I worked at both NeXT and Autodesk)
I think some of this is par for the course for a geek-run successful technology company. Back in the late 80's and early 90's when programmers still controlled Autodesk it was involved in projects like Xanadu, AMIX and even created the Cyberspace Developers Kit. All of these were very cool projects but far from the core revenue generating product AutoCAD. If Google follows the trajectory of other major tech companies there will one day be a down quarter, Wall Street will scream bloody murder and management will release a memo about "refocusing the company on it core competencies." And on that day you really want to be working on AdWords where the money is and not on the cool projects.
When launching a new version of our website earlier this year we ran the numbers for the previous six months and found that 10% of our sales were not only IE, but IE 6. We're a small manufacturer that sells direct to customers and that 10% more than covered the extra time developing and testing for IE6. There was nothing sexy about the task, but none of use were willing to walk away from 10% of our sales.
A long time ago I was working on a data conversion project that involved taking what was essentially a 10 dimensional data set and reordering it. The easiest way to achieve this was to load everything into a ten dimensional array and read it out in another order, but I was sure this would take too long. So I spent some time trying to get a sparse array implementation working until I finally sat down and worked out that the entire 10 dimension data structure would require 63 megabytes of RAM (not giga, this was a long time ago.) The Sparc server in the next room had 64 megs of RAM. It was a simple algorithm with quick results and I moved on to the next problem. I think that was the last time I really really cared about performance. I'd spent the previous 15 years getting closer and closer to the hardware, caring about every register and every byte. I've spent the 15 years since then on the slow slide to letting the computer worry about everything. I currently live in Python land and love every minute of it. I hear that string concatenation is slow but honestly, it's never been an issue for me. Computers really are fast.
I like helping people and I almost always learn something interesting. I'm also personally embarrassed at how hard the we in the computer industry makes things. Grandparents want to look at pictures of their grand kids, everyone wants email and it's nice to buy things online. No one should have to know what DNS means, what an SPF record is or worry about scammers stealing their credit cards and who ever makes these things better will probably get rich as well.
Let's make a 2d matrix with 4 cells. The X axis is small company, large company, and the Y axis is successful product and failed product. Products hop about these boxes all the time. Large companies sell off divisions or spin off products, small company products vanish and even large companies have turned around failed product lines. This piece seems to assert that the transition from small company / successful product to large company mostly results in failed products. Are there any numbers to suggest a higher failure rate than any of the other transitions?
The way I heard the joke in Vermont always involved a tourist asking an old farmer for directions and getting the answer "Well, you can't get there from here."
I appreciate the call to find the exact line of code that is causing the problem. I've done a fair number of code reviews where there was a bug, and it was "fixed", but no one knew why. The developer had simply kept changing things until the problem seemed to go away. That would mark the bug as closed, but it always seemed to show up again some months later in a new guise. These days I'm a terrible nuisance as I always want to know why the bug was happening. In my experience it's not enough to "fix" the bug you really do need to understand why it was happening in the first place, which is something that not all programmers do.
I'm not sure how to paraphrase what he said about "hard-wiring" but it all rang completely true to me, as the parent of a 10 year old boy. The differences between boys and girls don't have to have value judgments attached to them, but the differences between them are far more than simply cultural.
I'd subtract two points for every startup you've already worked in, especially the failed ones. Every time you do a startup it does get easier. I've met a few people in Silicon Valley who were shoulder deep in their thirties, with kids, and working at their fourth or fifth startup.
Can't stress that one enough. Really any source code control system will do, but make sure you know one well. It was the biggest thing missing from my CS degree. And it's handy to have a solid understanding of regular expressions and SQL, but learn source code control first.
There seems to be a bit of a strawman argument going on here. When people share "their opinions on whether it was a good idea to create a Dilbert movie" there's a fair number of assumptions tied up in there. It sounds the same as the question "Can Hollywood make a successful movie out of the characters created by Scott Adams?" Could the Hollywood studio system of the 1950's have made Easy Rider? No, of course not. Adams makes some interesting and fairly uncontroversial points about execution, but seems to do so on the back of a misunderstanding. There aren't that many movies that Hollywood can make with Dilbert, and most of them aren't worth watching.