If VISA associated an email address with the card when the card is created and digital purchases always went to that email address, then the allure of digital fraud would be decreased since if you bought digital goods with someone else's card, you would not get the goods.
Say everything you are thinking so they can tell if you get close to the correct solution. Be experimental and try approaches you think of even you are not originally sure they will work out. Try to spend time making your code exactly right rather than just writing something down and moving past it as soon as you think it is about correct. That is because they send the code you write to the folks who actually make the hiring decision. If they give you a 2d problem with real coordinates, think about discretizing the 2d space. Know how hashes and BSTs work. Don't worry about more exotic algorithms and data structures. They probably won't test you on them. Get nine hours of sleep (or maybe even ten) before the interview.
They should start in mid May instead so students can finish their Spring semester classes and then take Udacity or Coursera courses over the summer. With the current schedule, I would have to start taking the courses near my Spring term final exams.
My education at Carnegie Mellon has made me a vastly better programmer because it has given me an extensive understanding of how the machine works. This allows me to implement code that actually does things, such as memory allocators, rather than just piecing together code that other people wrote. Also, it has taught me how to prove things about code I write so I can ensure, for example, that integer overflow will not allow an attacker to cause the system calls in my kernel to overwrite kernel memory or memory belonging to another process. Things like these validate the importance of obtaining a top CS education.
You should try going to CMU School of Computer Science. Being a student at CMU is a lot harder than working at a certain large tech company I interned at, for example.
Not shipping doesn't imply no costs. A company could produce many million units of a product but be unable to ship them for regulatory reasons, for example.
Well, one thing I worry about is the ability of hackers to continue to develop their own OS's and load them on machines. Surely big companies will need to continue to be able to do this but it's possible to imagine that that might be only able to be done with a contract with the hardware manufacturer in the future, which could destroy the ability of hackers to load their own OS's on machines. (i.e. custom os's is something that there might be insufficient demand for despite not being able to create them with future devices.)
I don't think your comment to "roll up your sleeves and compete" makes sense. It may well be that it is in the interest of the majority of people to not allow people to modify the software on their devices and therefore companies might not decide to let people do so. However, it may still be valuable to let people install their own OS's on their computers, etc. The point would be that we need to correct the market to support hacker's needs since each hacker might not individually have enough market influence to do so.
It would be cool if something like this could be done for cheap microprocessor boards so people who can't afford to start with embedded development can be helped by others.
Well, there's no way someone could get a degree in CS from Carnegie Mellon without learning quite a bit. For instance, they must take 15-213, which is an excellent systems programming course (students learn about virtual memory, UNIX programming, properties of integers that are useful for handling overflow, etc).
I fail to see how you can claim that Operating Systems Concepts is an "extremely detailed look at how operating systems work." I read every page of this book. Much of the information is outdated. For instance, much time is spent on tape drives and related devices, as well as methods of using computers that are now updated (FIFO job queues, etc). Some interesting algorithms are covered. However, many of the algorithms have little relation to the techniques used in practice. For example, most of the locking techniques presented in the book are not used on x86. The information about paging and segmentation is overly high-level and is not sufficiently deep to guide an implementor.
I'd recommend skipping this book and instead reading the Intel x86 documentation. It was vastly more useful to me while writing my own operating system than anything I read in Operating System Concepts.
Go to Carnegie Mellon School of Computer Science and you will feel very different about this. CMU SCS students must take a number of very challenging classes, including 15-251 "Great Theoretical Ideas in Computer Science," which really means "Hard Discrete Math." Additionally, many of the courses, such as 15-213 (Computer Systems) and 15-410 (Operating System Design and Implementation) have great practical utility for budding software engineers. In 15-410 you write an operating system kernel and threading library from scratch. If nothing else, the debugging skills learned are of great utility.
If you look at the classic page he references (http://news.ycombinator.com/classic), the articles are nearly identical, with slightly different ordering. That seems to suggest the problem is smaller than he indicates.
Good riddance. I am tired of GPL software. It claims freedom but restricts the right of developers to choose license terms for their own software. Further, it sucks in code licensed under permissive terms but prevents open source projects under the BSD license from doing likewise with GPL code.
It would be unfortunate if the weekend service were terminated since I rely on it to visit San Francisco on the weekend when I intern at a company in the valley.