Actually, yes. These loans can't even be dismissed via bankruptcy and many government benefits are tied to the repayment of them.

Because no lender in their right mind would loan students money to begin with.

Student loans are unsecured - the student doesn't put up anything and can borrow easily $100K. And if the student can't find a job, it's not repaid. No lender would take that kind of risk, especially at a measly 7% interest rate - typical unsecured loans are closer to 20-30% (you know them as credit cards).

So the government has to put in some incentives otherwise financial institutions will not provide the loans as they're too risky. By making it non-dischargeable, the banks know that declaring bankruptcy will not make it go away for pennies on the dollar with no recourse (assuming they can get anything - secured creditors are paid first and often the money isn't sufficient to cover those so those take pennies on the dollar. Unsecured creditors typically get zilch).

It's just like if your company goes bankrupt - as an employee, your unpaid wages and benefits are unsecured, so you line up with the rest of the unsecured creditors to hope to get some money.

Back to Tesla, those DOE loans went to a lot of people. Few companies every paid even a portion back. Tesla managed to pay it back, early, with interest.

and fuck the attendant, who is probably complicit in the scheme.

Actually, the attendant pointed out the camera several times - and the fact that she was being recorded.

Even more than that, she identified herself as a celebrity and that she would post some crap about it all over TV.

So no sympathies at all. Even less so when you're trying to exert influence over others by using your authority.

And definitely no sympathy for her situation, because it was pointed out that everything she was doing and say was being recorded.

Perhaps her car was towed illegally. That doesn't excuse you for harassing the attendant and trying to use your position of power to influence them. Especially as the attendant repeatedly notifies her that she's under surveillance.

Anyhow, the response is not to be "nice" or "polite", it's to be "diplomatic". There's a time and a place for everything, and a time and a place where something is inappropriate. I don't know if it's social media or what, but it seems to have created a pile of self-entitled people who can muster up twitter to "shame" people and companies. Oh no, my package hasn't arrived yet? Tweet the company is awful and doesn't keep promises. Voila, package is now at door! Company didn't give me another free sample? Tweet, and there it is!

Unfortunately, the power company is still expected to make sure that the power comes in at the right voltage and frequency. And with control on only part of the inputs, that's a lot harder. The fewer inputs they control, the harder...

Theoretically, you can design a control system that'll handle the problem. But, so far, noone has bothered to, because noone's had a need to. As solar becomes more common that'll change, and the problems will go away.

Already exists, and Germany and California require all solar installations use smart inverters if they're going to hook to the grid. A smart inverter is a regular inverter except it's controllable as necessary.

They're able to do frequency detection (if the frequency drops, more power is needed on the grid, and if it rises, less power is needed and it should cut back. Even more advanced ones can invert with reactance.

Of course, it all means you can't dump all the power you generate into the grid - and if you're residential, it can also mean there's not enough transmission capacity to go from your house to the business and industrial district where it's needed most.

There's also something called "net metering" where the power company sells you electricity at retail price, and buys it at wholesale price.

Either way, if you're blessed with it, the general best idea is to just use it all - if you're in a sunny and hot location, well, use it to run the A/C when your system is producing maximum power (and maybe even use cold storage), because selling it back to the grid doesn't generally pay off,,,

Is it really common practice now to have laid off workers escorted out by security?

Depends on location. In the US, it's extremely common, potentially due to their more violent nature and the second amendment.

In a lot other countries, layoffs can take different schemes - they may provide notice of layoff - as in you're going to get a severance and all that, but it's a 2-week notice, and no, they're not going to buy you out, you're going to work those two weeks. Seems incredible, but a lot of companies do it because they want an orderly transition, and they do trust their employees enough to not be burning bridges. Some even go out of their way to help them find a new job (instead of just giving them the number of the employment agency) - and that includes counseling services. Heck, even benefits often continue for a few months after the layoffs (health insurance).

I don't know what it is about the US - perhaps their proclivity towards violence leads to basically shoving them out the door after the meeting is over - if you need any personal belongings, they'll fetch it for you and pack up the rest of your stuff.

Yes, but it took two whole years before the fix came out. And the fix was made within a day of the exploit being released.

Yes, I can understand 90 days being a bit tight if you're talking fundamental software like operating systems (which require a lot of testing, staging, and you lose some to Patch Tuesday), especially since root causing and fixing can require a bit of time. But two years is a bit on the long side.

More like the guy got ignored and once he released the code, the "OH SH*T" came out.

This is one of those struggles between what's right and what's reasonable... 90 days is a bit quick for something big like an operating system where a change can break everything, but it's also on the long side for something that only breaks something really minor, like Minecraft.

I seriously doubt it. I don't see how location reporting for a payment transaction in which location data is irrelevant could possibly pass Google's privacy policy review process. Collection of data not relevant to the transaction is not generally allowed[*], and if the data in question is personally identifiable (mappable to some specific individual), then a really compelling reason for collection is required, as well as tight internal controls on how the data is managed and who has access. I don't see what could possibly justify it in this case, and I can see a lot of risk in collecting it.

There's a lot of information involved in payment systems you think are irrelevant, but are passed on in order to judge if the payment is potentially fraudulent or not.

That includes things like location data (are you making a transaction where you normally make transactions, or in a new location (this is often the reason why credit cards are blocked when on vacaation), are transactions being made in impossible schedules - e.g., you used your credit card in Seattle, then in New York an hour later?). Online sellers routinely pass your shipping information to the card processor for the same reason - and can even ask for enhanced scrutiny. This verifies that the shipping address is known to the processor (either you put it on your credit card or it's been used constantly).

You may be confident that Google isn't collecting the data, but it's made available as part of the standard fraud checks. It's also why there's slightly more pushback against Google Wallet (where Google does get all the information involved in the transaction) than Apple Pay (where after setup, Apple is out of the picture and the information is shared between you, the retailer, the processor and your bank).

Oh for fuck's sake.. it's very simple: Avionics need to be on a physically separate network from everything else, preferably encrypted. If there was 'air gap hacking' going on or even possible, wouldn't we have seen it long before now? Wouldn't an intelligent, capable, well-organized, well-thought-out terrorist (yes, Virginia, they do exist) have found a way to sneak the equipment necessary aboard a flight and implemented his hack, taken control of the plane?

Exactly.

And yes, it's possible to "break through" the airgap - cellphones are known to cause EMI issues with certain equipment on certain planes (e.g., lose GPS lock, increase INS errors, cause drift in the heading indicators, etc).

If you really wanted to cause problems, I'd go with a broadband transmitter that causes EMI in the airgapped control network more so than trying to hack it through in-flight WiFi.

The big problem with Wikipedia is that in spite of what the publicity says, it is only a small number of people who contribute, and a surprisingly large number of those people have an agenda for what they edit.

imo, with Wikipedia, truth is not the goal. A certain point of view is the goal.

No, the big problem with Wikipedia is politics. Wikipedia is the reinvention of communism, and it's proceeding just like Animal Farm and other Communist nations down the path to failure.

Heck, it's already at the "Everyone is equal, but some are more equal than others" stage.

That's the main problem - you have editors and higher ups who now patrol their part of Wikipedia who are not interested in the truth, correctness or other aspects - just in having little power struggles. Heck, for a time there were massive parts being deleted for arbitrary reasons (usually along the lines of "this content is not suitable for Wikipedia" despite having plenty of similar content around). And these days, well, edit-reversions by the same power-mad editors have basically rendered any reason to edit it moot.

I mean, there's a small amount of contributors because everyone else got driven away. Try to fix a mistake and you'll et into an edit war with an editor who thinks their interpretation is completely correct even if it's obviously wrong.

Yes, it's an encyclopedia anyone can edit. Except that if you do so, chances are someone will revert it in a few minutes because they don't agree with what you edited, even if all you did was fix an error. "Everyone has equal edit rights, but some people have more equal edit rights".

The study of Wikipedia itself is quite fascinating, no many times you get to see political ideology put into play and see the results. Usually you end up with people getting hurt or humanitarian crises if you try to experiment.

OS X does not support NVME, so no, there are no NVME drives being supplied to Apple. And finally these NVME drives are just entering production and are not available in either the OEM or Retail channels yet.

The new MacBook supports NVMe on OS 10.10.3, so support is rapidly coming...

Their reasons involve context switching and interprocess communications. Context switching has got to happen (unless they run IE in kernel space) so just get it over with. Interproces communication has always been a weakness in Microsoft systems. Since day one. Multitasking OSs are here, folks. Get over DOS.

The bug here affects the HTTP server side, not IE.

And in HTTP servers, there are LOT of context switches - in basic static file handling mode, you read a file (syscall to read file), then you write it to a socket (syscall to write to socket). in effect, a webserver is just copying from two file handles, and incurring a kernel-usermode transistion twice every round.

Add in a moderately busy webserver and you could be spending significant amounts of time just switching between modes.

Using larger buffers helps, but if your site consists of lots of little files, it's still the bottleneck.

Linux has similar functionality - see sendfile(2) and splice(2), among other commands to actually manipulate in-kernel memory buffers.

In fact, doing it in the kernel has an added bonus - if you support zero-copy, no copies are made rather than potentially having to copy to/from userspace (more overhead).

Of course, in the Linux model, all the processing happens in user made and only the tedious file copying is accelerated which ups security.

You do realize google has a history of "boiling the frog", right?

You do realize there are other browsers out there, right?

And having it done in the browser is far better than the way notifications are done now - which is usually in a little tick box that then sends updates to your email... at least browsers can make a unified window listing every site push notification allowed and offer things like "disable all" or "delete all".

Moore's law is sort of a mangled version of Koomey's law. Koomey's law states that the number of computations per joule of energy dissipated has been doubling every 1.6 years. It appears to have been operative since the late 1940s: longer than Moore's law. Moreover, Koomey's law has the appeal of being defined in terms of basic physics, rather than technological artefacts. Hence, I prefer Koomey's law, even though Moore's law is far more famous.

  There is another interesting aspect to Koomey's law: it hints at an answer to the question "for how long can this continue?" The hinted answer is "until 2050", because by 2050 computations will require so little energy that they will face a fundamental thermodynamic constraintâ"Landauer's principle. The only way to avoid that constraint is with reversible computing.

Ah, but Moore's Law has a direct correlation to a fundamental piece of computing - memory. Doubling transistors easily doubles storage capacity per unit area (and memory devices are area bound devices - there's a certain tradeoff between making huge memory devices versus defect rate - as you increase area, the defect rate increases dramatically). This isn't just RAM, but also non-volatile storage.

CPUs and other random logic parts have pretty much ignored Moore's law for decades now as the their limiting factor is wiring, not transistors per unit area. in fact, most random logic parts contain tons of transistors that are not hooked up to anything - they're just there. The reason for this is for revisions - fabbing extra transistors in costs nothing. But if you have a bug, if you can utilize those extra transistors, then it's less masks that have to be recreated, and at $100K a pop each, not having to redo the transistor level masks saves easily half a million or more. (It's why steppings are usually thought of as two parts - the first will be A0, while minor revisions that only change the metal layers increment the number, e.g., A1, A2, A3. Major revisions that change everything including the transistor masks change the letter, e.g, A3 to B0, etc). With proper metal layer allocations, fixing broken logic blocks may only change 1-2 metal layers rather than all metal, saving even more money when you consider that the most advanced ICs are already at 10 metal layers or more, requiring 20-30+ masks.

As clock speeds go up, random logic uses less and less minimum-size transistors and switches to larger transistors to increase drive strength. But again, transistor density isn't a problem on random logic.

They have this draconian douchebag policy that you can't ever reuse one for like 20 tries, you have to have a capital, number and punctuation.... so I just keep adding numbers to the end of it. Fark them if we get hacked.

Give me a reasonable password requirement with a reasonable expiry (NOT 30 days) and we'll talk.

Here's some...

2015January!
2015February@
2015March#
2015April$
2015May%
2015June^
2015July&
2015August*
2015September(
2015October)
2015November-
2015December=

If it's too long, shorten to 3-letter months.

And for next year, you'll have another set of "unique" passwords so it doesn't matter if they demand it doesn't match the last 100 passwords.

Numbers, capital, punctuation it's got it all.

With a few modifications, you can come up with similar passwords that will obey any other rules you need.

I've consciously avoided jobs where my code is responsible for life-and-death decisions. The problem, I guess, is that too many other good people have made the same decision, and there aren't enough good people available to do what needs to be done. I'm not sure what to do about this.

The problem is not just that, it's that those companies don't actually pay that well, either.

Writing safety-critical code is not hard - there are plenty of guidelines on what you should and shouldn't do (e.g., memory allocation is verboten). It is a specialized skill, and the job should really be done by people who have the requisite training and knowledge and often even certifications (e.g., engineering certifications).

The problem is this is very specialized, and it costs a lot of money because those people know they are taking on professional risk (not unlike many other engineers - civil, mechanical, etc., who design stuff that could fail and take lives). Of course, the IT companies behind it all? They're not willing to pay for that enhanced risk - they're going to pay market rates.

Well geez, if I'm going to be paid market, I'm not going to put my name on anything to certify because that's a specialized skill that gets paid for. (hence, things like "approved drawings" which mean some engineer actually reviewed it all and put their stamp and certification on it).

There's a reason why NASA's software for the space shuttle costs 5+ times what a normal software project of similar size and scope would cost. It's not incompetence on NASA's part, and it's not just the extensive documentation and paperwork that goes along with it, but the fact that writing safety-critical software is hard, specialized, and for every line of code, probably generates a book's worth of documentation proving it fails safe, who wrote it, who changed it, who reviewed it, etc.

Yeah. Most IT companies for health don't even come close.

The problem with total rewrites is they almost always involve a huge amount of effort, introduce new bugs and when they "work", users barely notice the difference. So the company soldiers on, applying patch upon patch to some bullshit codebase and suffering from it but in a incremental way.
Worst of all is when they embark on a rewrite and give up half way through. I was involved in a project to port a C++/ActiveX based system to .NET forms. They ported most of the major views but left a lot of the minor stuff from the old codebase lying around and wrote bridges to host it in the new framework. So they doubled the code, half of it became bitrotten and hidden by the new code and bloated out the runtime. Great project.

And what you described is technical debt.

Rewriting code costs time, effort and money, which is how you repay the debt. After all, when faced with a fix, you can do it quick and dirty and borrow from the bank, incurring debt, or fix it properly but takes longer, with no debt. The former will get it done the quickest and put the fire out, but that stuff you borrowed will haunt you later.

Your new system where you wrote bridges means you got rid of some debt, but the incurred a bunch more.