That's not the point.

Terrorism isn't about making the statement "We can hurt easy targets". It's about the statement "we can hurt any target."

The World Trade Center was a giant building. With control of a plane, it would have been easy to hit. The terrorist aspect is that the hijackers interrupted a regular normal daily routine to commit their chosen atrocity. Now, it's doxing. ISIS is claiming that they have supporters in the US who are willing to kill anyone with a name and an address.

Sure, they've picked a few soldiers now, but the subtext is that their targets could be anyone. A few articles later on the front page, there's discussion of video gamers calling in SWAT raids. 4Chan makes a point of identifying anyone for any reason for the fun of it. Anyone paying enough attention to understand what ISIS is threatening today knows that they could end up a target next week, and it's probably too late to scrub their records from public systems. There is no defense against the doxing, and if ISIS really does have a hidden network of bogeymen in the United States, there's nowhere to hide.

That's the real message ISIS is saying here: You could be next if you piss us off. Bow in fear, praise our particular flavor of deity, surrender all of your free will to our self-interested leader, and so on and so forth.

Your "gut feeling" is also often wrong, but you don't notice because of your confirmation bias.

The paranoia's adorable, but here in the real world, everything I do is a balance between risk and reward.

Sure, our data could be sold off, but that's what contract lawyers are for, just like any other business deal. Sure, I risk a malevolent company holding my data hostage, but even at increased prices, it's still cheaper than handling the data myself. Sure, I could be using the same rack a terrorist uses, but he could also be renting office space in the same building we use.

My company could, of course, buy its own building, own its own servers, manage all of its own data, and run all of its own processing... and then promptly go bankrupt, because the cost to do that is too high for the extremely limited benefit.

Well, yes...

The problem is that we don't know what the problems will be. Today, Network neutrality is the hot-button issue the FCC is finally forced to deal with, but tomorrow, who knows? Maybe we'll have to have regulations on compliance (or not) with encryption-busting wiretaps, DNS hijacking, advertisement injection, or something completely different.It's taken long enough for the FCC to move on this that we've already had a few cases of effective extortion by an ISP, and maybe those issues will be even more problematic.

The solution, then, is to bring the FCC in as an advocate for the American citizen, since that's pretty much the government's primary job. This establishes a process where the FCC can say "You're not breaking rules now, but you're getting really close" and give the ISPs a chance to avoid sinking investment capital into systems that will be outlawed as soon as people notice. Cooperating with regulators, especially by asking permission rather than forgiveness, is also a great way to reduce future penalties if the FCC's policies do turn against them.

If the ISPs' new business models don't piss off the FCC, then they don't have to worry about new regulation in the short term. Only ISPs with predatory business models to hide should be worried.

Not quite the same ring to it...

The upside is that my problems are now someone else's problems.

I no longer need to manage my long-term backups for my team's projects. They go off to a cloud provider, and if we really need something, we can get it back, and I don't have to worry about keeping tapes or disks around, and I don't have to be the one going through the library to find some old media. Data is encrypted prior to archival, so privacy isn't really a big deal.

I no longer have to worry about constant availability. If my local servers go down for a few minutes, maybe a user will notice. If they're down for an hour, I'll probably get an annoyed email, but I will get that email because our constant-availability services are hosted elsewhere.

Now, I do still have local servers to manage. I do still keep a decent number of nines, and I do still make my nightly backups, but I don't need to be managing every aspect of every problem. I can push that responsibility elsewhere, and make my workload more manageable without bringing on significantly more risk.

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.