In addition to those excellent suggestions, remember that grep is your friend. Nifty code indexers are all well and good, and might even be all you need if *everything* is c/c++/headers. I find that the larger the code base, the less likely that that's true. Write yourself some grep wrappers if the relevant files are spread around in some awkward manner.
Slashdot videos: Now with more Slashdot!
I use VirtualBox to host linux and winders VM's on a Mac laptop. It's free, and my other alternatives aren't. All I care about is whether it works, and I'm not all that interested in graphics acceleration and the like. So I hope it sticks around, even if it "stagnates".
I run Linux on a 2009 Mac Pro, and no, an equivalent PC wouldn't be much cheaper, plus I do run OS/X on it occasionally for various reasons.
The Mac Pro is dead quiet, which is extremely important to me. The hardware is completely solid and well designed, I've only had one drive failure in 5 years of continuous use. It's as fast as the (Very expensive!) shared company development machine; I'm going to upgrade the CPU and memory on the Mac Pro and easily get another 3 or 4 years out of it. Almost all of my co-workers with PC's have suffered fan failures, power supply failures, etc etc and gone through at least one replacement cycle in that time.
Sure, a PC *can* be almost as good, it's just that usually they aren't.
IMO the comparison comes about because the philosophies of the two (systemd and windows) are more related to one another than they are to Unix. Unix favors a collection of interacting tools that each do something (ideally, doing that something well). Windows is a giant monolithic shroud covering a multitude of interacting moving parts that you can't see, touch, or understand unless you spend the necessary years becoming an insider. Systemd seems to be leaning in that direction, hence the comparison. It's a big collection of "stuff" that refuses to be broken up into component functional bits.
It certainly doesn't help that the systemd authors seem to think so highly of themselves, that I feel no need to add to their aggrandizement by thinking highly of them myself.
"truly unlimited"? so we now have enough storage to compute all the states of the universe from its start, and other even more interesting problems?
This is a terrible idea, and simply stating platitudes like "it's not about legal ramifications" (hey, it IS) doesn't make it a good idea. What about bandwidth? what happens when I decide that I need that extra storage after all, and I delete your junk? Not to mention that the sites with enough storage to really make a difference to any significant number of other people are in fact the ones typically running out of space. Not to mention that space generally isn't the problem.
Not going to happen.
+1 to this. It's how I operate.
Ask your optometrist about "interview lenses". It's an extremely mild progressive that you can optimize for your eye-to-monitor distance. Done right, you don't get the side to side defocusing that makes so-called computer lenses or standard progressives completely f**king useless for computer use (IMHO).
Gee, if you can find anything worth reading in CACM once a *year*, I'm impressed. CACM was a large part of why I let my ACM membership lapse; it was chock full of hand-waving and garbage, and it wasn't optional. If I could just get TODS, TOPLAS, and maybe Surveys, without CACM, I might still be a member. Maybe.
Again, if you are a typical W-2 wage earner, those things CANNOT be deducted, unless you enjoy trying to explain them to your friendly IRS auditor (and having them denied). You can't be a business owner without a business, which most wage earners don't have. If you try to invent one, or even have a legit side business but attempt writing off non-business things to it, you are just asking for a very expensive trip to tax court and possibly prison for tax fraud. The IRS publications are pretty clear on what is and is not deductible for an employee. Your email example, just to cite one case, is explicitly excluded if we are talking about an employee checking email at home (see the example on page 4 of Pub 529).
I disagree. If you're a standard working stiff with nothing but W-2 and maybe some interest income, it's highly unlikely that your itemized deductions will be anything more than taxes, mortgage interest, and charity. You probably won't qualify for medical or miscellaneous deductions because of the AGI percentage requirements. You might have child care credits, but that's a credit, not a deduction. You don't need a professional to work that out.
Yes, some people have special circumstances, but it's just incorrect to set a general expectation of being able to "recoup thousands of dollars". For most people, it's not going to happen.
Now, if you are self-employed, that's different.
The 1065 and K-1's are filed on paper since I can't be arsed to buy the TurboTax version that has that stuff in it. I do use Turbo basic to e-file our personal fed return. I do the state return on paper, again because TT wants too much for the PA state forms.
I've done the free web-based returns (both TT and Taxact) in the past for doing the kids' returns when they were in college. They are fine for trivial returns but get annoying quickly for more complicated stuff. I recall Taxact in particular making me re-answer questions repeatedly because I needed to go back and edit something.
I've never felt the need for an accountant. The stuff can be a little tricky but for most people it's not that bad. If you have limited oil drilling depletion allowances and suchlike stuff, that might be different...
It's really simple:
If you have a job, you can get a job.
If you don't have a job, getting a job is harder.
"Promised" is an elusive word, but assuming that the $70K offer comes thru, why not take it unless he has a gaming company offer in hand? which I assume he doesn't. It's always a good thing to be able to afford housing and food while looking for the job of one's choice.
Besides, he might be surprised, and like the promised job. (Or, it might be a small step above a Siberian work camp. One never really knows about these things until one tries it; but of course the same goes for the "dream" job at a gaming company!)
Whether coding standards really matter for maintainability generally depends on how much information you expect to be carried by the formatting.
We generally assume that indentation follows block structure, so indentation standards tend to be very important. I've wasted hours over bugs that were hidden by incorrect indentation.
Naming conventions may matter if the coding standard dictates a different styles for different scopes (e.g. LeadingCapital for global names, etc), or if type info is embedded in the name (pszFoo, lBar, etc).
Beyond that, coding standards help readability but that's about it. That may or may not be an issue depending on the team involved; one benefit of a uniform look is that you get less of "You're stuck fixing that code forever because I can't read it".
Whitespace standards (outside of indentation) are generally of marginal to no use IMHO. I'd follow reasonable whitespace standards, just for that uniform look, but nobody should be spending hours on it. The fancier the coding standard, particularly as it applies to variable naming, the less useful it is in general.
You shouldn't be losing "hundreds of hours" in code reviews, though. Either you're deliberately being obtuse about things or your coding standards are insanely complex, or uselessly ambiguous. There are a number of things I don't like about the coding standard I work in now, but I stick to it anyway because it makes the code more uniform and easier to read. Have you tried doing the same?
AOA indicators aren't perfect either. What do you do when the AOA vane ices up and sends an incorrect position? It's easy to say "add sensor X" but then you have to deal with the implications of sensor X failing or sending bad data.
The biggest issue, quite frankly, is that the pilots didn't do anything they were supposed to do. They didn't perform the lost airspeed procedure. They used low altitude stall procedures when confronted with a high altitude stall onset (the two are very different). It was a thorough screw-up from beginning to end, unfortunately. The contributions of the airframe design to the accident were minor at most, and it's difficult to see how presenting different information would have helped a couple of pilots who had already ignored everything else the airplane had told them.
and airliners.net also. The ones who know what they are talking about are unanimous in that it had little to do with the non-backdriven controls; the pilots flying were so disoriented that it probably would have taken a giant flashing sign saying "you're falling out of the air, dummies!" to get them to nose down.
And anyway, FBW != back-driven controls. The thread title is wrong and misleading. Boeing uses FBW too, but they back-drive the yoke and throttles. This has been discussed plenty as well, and there's no inherent advantage to one way over the other.