There are already a lot of suggestions for which particular package to use, so I'll contribute my thoughts.

I've used RT. It worked.

The main feature that helped me move my (financial services) office from word-of-mouth to proper tracking is that RT supported submitting issues by email. We already used internal email extensively for other workflows, so it was easy for me to convince people to send an email to <project>@tracking.<domain>, and they'd get an emailed response showing the ticket number and a link where they could follow the progress.

RT let me run different projects (which in my case usually meant only 1-3 people) separately, and each project had nice charts showing how many open issues they had to work on. Managers loved that, because they could see who was overloaded and by how much. Each user was also able to create their own dashboard to display when they logged in, so they could get a to-do list first thing in the morning.

For each project, I could modify what information was needed when a ticket was created. Almost the entire ticket form was customizable, so that was adapted to the project needs. For our financial advisors, they had simple forms with a customer name and a description field. Traders had buy and sell forms with security symbols, amounts, account numbers, et cetera.

I haven't been in a position to manage very many trackers, so maybe these features are standard-issue. Maybe something else will work for you, but like it said, RT worked for my needs.

Now, if it were tattooed to their backsides, how would they be able to read it? Most literary critics aren't quite that flexible.

I suppose if it were tattooed to all of their backsides, perhaps a few pages per critic, an organized effort could have them read each others' backside-books out loud, so they all can get the whole story. However, that's a significant undertaking, especially considering works like Lord Of The Rings, which would involve several hundred backsides.

Honestly asking out of ignorance, not malice, Sad that I have to note that, but I digress...

Are there any notable kernels written in modern C++ (or even C++98)? I've never bothered to keep track of what kernel was written in which language, so I'm sure my knowledge is sorely lacking in this area. Hurd? Mach? Any of the many RTOS kernels?

The real story is that Slashdot is actually admitting it was wrong.

I've gotten all of my jobs as #3, but one company in particular I worked for did primarily #1, and when they had to lay off a few hundred folks, most were supplying #2 pretty quickly.

The key detail is that interview. It seems everybody has that one interview horror story or six, because that's usually the first time a candidate has to actually show that what the employer read on their resume is actually what they provide. Note that I refer to what was read, rather than what was written. You might think your resume says you're a Linux kernel guru with a decent bit of shell scripting knowledge, but to someone looking to hire a Perl programmer, you look like a scripting guy who spent time as a sysadmin. It's then very likely that your interview will show that you're not as quick with the Perl as they were expecting, and you'll wonder why the interviewer spent so much time on those ridiculous scripting questions.

An internship is a several-month interview, where the employee knows they're getting the shitty jobs at shitty pay. Expectations are low, but it's easy to exceed them and be one of the regular team before the internship's end. Of course, by that time you already know the project and the company, so the company's cost to hire you is significantly reduced, as well.

Similarly, hiring from other companies reduces the risk of hiring someone. They were good enough for the competition, and it's not their fault they're looking for a new job, so they'll likely be good for us, too. Half of the interview is already done, just because they already have a job.

Of course, your technical skill is only half of that interview. The other major factor is whether you're a good fit for the company. I've been at companies that wanted aggressive personalities, hoping the drive to be the best would carry their product for the ride. I've also worked at places where you could get away with pretty much anything, as long as you were always smiling in front of the customers. My current job takes all kinds (and keeps them - I've seen one person actually fired in the last two years), but the ones who stay late and help push for deadlines are the ones who get the most respect.

I can easily picture a half-million IT jobs in the US. I'd expect that very, very few of them are actually a good fit for any particular candidate.

Let's do the math, then. The specifications of Solar Impulse-2 are available as a starting point.

At 269.5 square meters of solar cell coverage, and an average power density of 1.35 kW per square meter, the maximum amount of energy the plane can harvest is about 364 kW. Now, we can use two facts to avoid the ugly world of aeronautical engineering (which I don't know): The aircraft has flown under its own power, supplied by four 17.5-horsepower motors. Those motors therefore supply about 13 kW each, for a total of 52 kW of energy required to fly.

Since 52 kW is far less than the 364 kW the solar cells produce, yes, there is in fact enough power available for collection.

As noted, the plane has already flown, carrying its lithium batteries with it.

Ah, finally some thermodynamics! Currently, the whole plane needs an efficiency of about 15% to simply fly. After some quick research, it seems most solar cell technologies today run at about 20% efficiency, with new technologies pushing 46%. Going from the 20% point, that means the motors need to be only 75% efficient. A bit more research shows that they're actually reasonably assumed to be around 85% efficient. The plane will fly in bright sunlight just fine under solar power alone.

Lithium polymer batteries have efficiencies of around 80% to 90%, so going up to a solar cell with 25% efficiency would allow the plane to either charge or fly, but not both. Double the efficiency and you double the capability, so having solar cells that are 50% efficient would allow both charging and flying under ideal conditions. We're getting pretty close to that.

Throw in some assumptions about duty cycles, allowing the plane to be on the ground for a bit (doubling its charging rate, because it doesn't need to spend energy to fly), and making long trips is feasible in several short hops. Account for an intelligent pilot, using tailwinds and other air currents to reduce the energy needs, and those hops can be made longer.

A Boeing 777 is designed for speed. If you're not in a hurry, solar power might just be a reasonable option very soon.

The project is funded by these guys, to protect those other guys, who are separated by a large number of bureaucratic layers from those different guys, who want to undermine the project so they can snoop on yet-another group of guys.

Am I the only one who thinks "the government" is actually made up of lots of independent minds, each with their own idealism and morality? A functional conspiracy to secretly undermine a project like Tor would need to involve a significant portion of the American population. Heck, Slashdot's hivemind isn't even that consistent.

The indentation is the main reason I'd avoid Python for the day-one lesson. I'd also note the empty parentheses and the colon in the function definition as being boilerplate and an easily-missed detail, respectively.

Minor points, certainly, but points nonetheless.

Those are subjects for a later lecture.

What's always amused me is that Dijkstra's hatred toward BASIC was originally hyperbole, and much of "Go To Statement Considered Harmful" Dijkstra himself later regretted, explaining that his disgust is really toward misuse of any construct, of which GOTO was the prominent example.

Of course, later retellings of the story have continually inflated the horrors of BASIC, forgetting all about the context of Dijkstra's statements.

Step 1: Show them the BASIC interpreter

Step 2: PRINT, INPUT, IF, GOTO, END

Step 3: Show them Python, C++, or even JavaScript, if you hate them

I know it's not really what a platform-builder wants to hear, but please use BASIC only for purposes for which it's the best tool. It's ideal for highlighting the often-missed initial concepts, such as the facts that statements are executed in order, variables can store information and change, and that certain statements can change the program flow. Those core ideas are so internalized by experienced programmers that they often won't understand how students could be missing them. From the student's perspective, it's perfectly reasonable that once statements are made anywhere in a program, the computer should pick which one to run based on what would make sense. It's also reasonable that a variable should be set once and never change, or should be usable before being set because "it's set right there!"

BASIC has one major advantage over every other language out there: absolutely no boilerplate, and absolutely no hidden intelligence in the interpreter. Everything that makes the program run is visible in the code, and everything in the code does something lesson-related in the most minimal programs. Contrast with C, which requires defining a main() function before the student knows what a function is. This simplicity and obviousness makes BASIC the perfect tool for demonstrating simple and obvious programs, but it's inelegant for learning any actual computer science concepts like memory management, design patterns, or data structures.

Those concepts are best covered in another language, which also highlights another important CS concept: The functional equivalence of all Turing-complete languages, but the effects of language choice on the difficulty of the project.

I once installed a new front bumper on a Honda CR-V.

I removed the front bumper cover, the grille... and found a screwdriver and a pack of cigarettes sitting in a depression on a piece of the frame. Knowing the history of the car, I'd never had anyone else do work in that area, so I'm guessing it was left there during some manual stage of manufacturing.

Being published by another source indicates nothing about the currency of the information, accuracy, or completeness. If the Marshals release the information, it implies that the Marshals are also publishing all of the metadata that is ever-so-important.

A driver's license is not really entirely about driving, which is why some jurisdictions refer to them as operator's licenses.

To operate a motor vehicle, you're showing competence in the vehicle's operation, For a normal car, that means mostly the in-motion controls and law knowledge, but there's also a section of most tests where you're required to demonstrate mastery of the machine and the ability to keep it in good condition, by demonstrating indicator lights, completing a knowledge test, passing emissions tests, and the like.

For a self-driving car, that vehicular mastery becomes more important. Do you know how to manually take control of the vehicle? Do you know in which situations you might be required to take manual control? Does your vehicle indicate that it receives reasonably-frequent data or logic updates, if needed?

In short, if you're the legal entity responsible for the vehicle, are you able to reasonably ensure its safe operation?

The government could be prevented from collection by the Fourth Amendment... but the Fourth is based on preventing the state harassing a citizen, and "inadvertently shed" DNA rather implies that there was no inconvenience to the suspect, and thus no violation.

Private citizens are prevented from harassing other citizens by various anti-harassment laws which vary by local jurisdiction. Chasing someone across the campus probably isn't allowed, but pulling a cup from the trash (once, so as not to be considered "stalking") is probably fine.