The 144k is symbolic.

Jesus is symbolic.

Where do you draw the line?

Are they just going to let someone fry their GPU and turn it in for warranty repairs now?

Perhaps just more aggressive thermal throttling in newer driver versions? "Sure, overclock all you like, but at 80C core or 40C ambient, you may a well have an IGP".

Though as I understood their original announcement, they hadn't so much seem a wave of outright DOA returns, as much as expressing concerns that prolonged pushing of the envelope would lead to reduced lifetimes. In that case, as long as the parts can outlast their warranty, NVidia may simply have come to the conclusion that earlier death means earlier replacement.

There. FTFY. The government has already meddled.

Not really - FINRA has issued guidance for those trying to stay legal; the government has made some high-profile arrests; the FBI has confiscated individual wallets through physical seizure of the machines they lived on. But overall, the government hasn't done (and realistically, can't do) a damned thing to substantially interfere with the core functionality of BitCoin.

Sure, they could impose some draconian "death penalty for using or posessing BTC or any of its associated software", but even that would only apply to those under US jurisdiction, and the system itself would keep chugging away merrily.

The way it's done with my bank is that you set a phrase that only you know, which is displayed when the page is spawned.

Bruce Schneier (IIRC) described the obvious hack for that the day Visa came out with it...

The attacker (whether a fake merchant, or a MitM) waits for a request for you to verify your identity. It then presents your information to the real site (keep in mind the attacker builds this connection, so encryption doesn't mean a damned thing). The real site responds with your known prompt-phrase, so you "know it's legit". Attacker then prompts you with that phrase, and waits (and records) your response. Attacker passes your response on to the bank, and the transaction goes through successfully.

Except, that the attacker now has everything he needs to produce as many fraudulent charges as he wants.

Great question! I had wondered about this myself - How does C&P really make the card more secure if you still basically just need a photocopy of it to use it? Or do they have an entirely different mode of operation when used online (like easy generation of disposable one-use card numbers)?

Not that it matters - US vendors will fight this to the bitter end. I already have cards with a chip in them (not sure about the "pin" part, since I certainly don't know any pin to use with them), one of which I've had for over five years. And I have *never* found a merchant that it works in any mode other than "swipe and sign". My local supermarket actually has readers compatible with them - And have intentionally disabled that feature because it "confuses" people - Damned straight, it confuses people! It confuses the hell out of me that you've intentionally made your readers insecure, and that after a major breach a few years ago!

Fuck the PCI, and fuck merchants. Give me security or pay me real penalty-money when your latest data breach results in my identity getting stolen. None of this "$50 maximum liability" bullshit - You lose my identity, BAM, $100k in my pocket. Anything less, and we'll keep hearing about the latest record-breaking breach-of-the-week.

That xkcd is just more of the recent bullshit Randall has started putting out lately

July 17, 2009 counts as "lately"?

I'll agree with you that every now and then, Randal seems to toss a turd directly at his core fanbase; but that hasn't really changed or gotten noticeably worse over time.

Most of the time, I just excuse it as a failed attempt at self-debasing humor and move on to the next comic - In many of his "preachy" ones like #610, he explicitly makes a point of including himself among the set of people guilty of whatever trait he has bashed.

It would all depend on your definition of 'significant rewrite/technology/architectural changes'. There is a lot of room in there for interpretation - particularly if a project was changing constantly.

At the same token, if a project has stablilized to the point of little or no changes, then have a long-lived 'W' wouldn't necessarily be a bad thing either.

Human beings create these numbering schemes for human consumption - and therefore can reasonably adjust them to avoid confusion as necessary.

Yes, really.

I stopped using GOTO when I moved beyond GW-Basic some 25 years ago. And I've used plain ol' C for the majority of the code I've written in my life. And yes, FWIW, I've written firmware - Low-level coding, unless done in assembly, doesn't give you a pass on flagrantly breaking the built-in flow control devices of a language.

If you need to resort to a GOTO, you did something wrong before you ever typed your first "#include ...". Simple as that. Yes, you can defend various uses of it, and no, most of them probably don't merit invoking Dijkstra's Wrath. Most of them don't count as outright harmful, just unneccessary. But for every use case you can come up with, I can give you a non-GOTO way of handling every... single... one. As I mentioned, I've re-written plenty of code to remove the GOTOs from it. You just don't need them, period.

There are no stupid date formats - just stupid people.

Symbols, and words, phrases, and sentences created with those symbols are neither right or wrong in and of themselves. In a given context (e.g. spoken words, computer file name, database representation, printed document etc) each and every method has its place.

That being said, I do agree, and use myself ISO date/time formats when dealing with data, file names, and other things that I want to conveniently order by date/time. (yyyymmddhhmmss). That does not preclude me from using other methods in different contexts.

The fix for the human factors problem is to automate the generation of the bug report on the user's system such that it captures the version information for things critical to your app (e.g. kernel version, libraries versions, your application's version etc...). Have the application itself do this upon failure, and/or provide a tool to capture the requisite information after the fact.

Then, make it a policy not to accept bug reports without the appropriate error log data accompanying it (with clear instructions about how to generate the information, and where to get the output file for sending etc). You can then easily filter out any non-compliant reports to make your life a lot easier.

That's how I would do it anyway. I've been burned/wasted my limited time too often by people raising 'bugs' without any backup evidence that then turned out to be user error - or some other component of the system unrelated to the application upon closer inspection. I no longer accept unsubstantiated bug reports.

I would argue for adding an extra decimal point: W.X.Y.Z

'W' - Major Release - reserved for significant rewrite/technology/architectural changes

'X' - New Feature Release - significant changes to existing architecture/technology

'Y' - Minor Release - minor changes to existing architecture/technology - could be for major bug patches, or other miscellaneous performance enhancements that we want to differentiate from previous releases.

'Z' - Patches - things that do not rise to the level of a full release - could be for minor bug fixes, or to track iterative evolution and re-factoring of a small component of the overall system. Having the extra number here would allow you to keep each individual decimal number smaller by selectively rolling the number above it without necessarily impacting your major release numbers - basically it splits up the last number - which seems to get a lot of use - into two numbers to spread the load.

The more copies you make of a block of code, the higher the probability that you'll miss one of them when you later have to modify that block of code.

Not sure what you mean by "copies" - In that example, you have only a single cleanup section, in the calling function rather than in the called function - You've basically split the problematic code into two pieces to let the stack itself unwind most of the problem naturally, rather than needing to jump around to various no-context error handling blocks.

Assuming we don't write this in a language with some variant of either "using" or "finally" syntax... You still have two alternatives in cases where you have cleanup that needs to occur unconditionally.

The first (which I often opt for, myself) - Put it in the caller:
foo = BuildUpFragileStatefulStuff();
result = myEasilyBrokenHugeBlockOfConditions(foo);
if(result==OhShit) {foo.unwind(); foo.cleanup(); foo.bar(); foo.close(); foo.dispose(); foo=null;}

And the second, for when you have lot of cleanup - Put it in its own function:
foo = BuildUpFragileStatefulStuff();
...
if(ThisCondition==BadMojo) return(UnFuckify(foo));


I really cannot think of a scenario where one of those leads to less clarity or more redundancy than replacing them with "Goto OhShit"

How many levels of nested if blocks are you willing to tolerate solely in the name of avoiding a single use of the keyword goto?

If GOTO would actually alleviate that problem for you - You've already done something very, very wrong.

I have written a lot of code in my life - Thousands of projects, millions of lines of code (for whatever that means), across a dozen languages and twice as many platforms. And outside Assembly (and DOS batch, if you want to count that as a "language"), I have not ever encountered a situation where I thought to myself "gee, I could really improve this with a GOTO, if only everyone wouldn't laugh at me for it".

I have, however, removed some pretty heinous uses of GOTO from other people's code. The most common one I see, people can't quite bring themselves to "return" from an error handler in the middle of a function, so they instead GOTO the end of it. Really??? Talk about missing the forest for the trees!

I don't think I would so much call GOTO "harmful", so much as "completely unnecessary in any modern language".

Excellent points. I think all of the angst that is coming out of the systemd debacle is really the result of a long time defacto state where most distros - because of their common POSIX-ish modular implementations could work with just about any software out there - so even if your distro didn't support something (like a very small X11 compliant text based window manager - which I managed to shoehorn onto an old AST 486 laptop with 20 MB harddrive and 1 Mb ram running a stripped down version of Slackware 10) it could be made to work on the distro you were most happy with. People had their cake and because of interoperability could generally eat it too relatively easily - with some exceptions (e.g. device drivers).

Systemd, Dbus, et al created a situation where the choices that were once 'AND' choices, now became 'OR' choices - at first for the developers of key system components - but with enough momentum this trickled down to the end user. Developers who were once maintainers of alternative versions of various key applications are finding that the code they once depended on for porting no longer supports the old interfaces, and so they are faced with a hard choice - either spend their time working on the most widely distributed version of their software (for systemd based distros - abandoning general support across BSD and non-systemd Linuxes), or focus their energy on back-porting the code in external interfaces to work across non-systemd distros. A Hobson's choice for both developers and users who value interoperability/portability of their systems.

Frankly, I am surprised that Linux, BSD, and the shared GNU POSIX tool set was able to maintain this benign portability for as long as it has across such an eclectic assortment of distributions. I would argue that this gave Linux time to incubate, and grow up in a stable environment. With the systemd gauntlet thrown down it is now time for other alternatives to be put out there - the more the merrier! Maybe one new distro would be enough to address the complaints. Maybe 10 or a hundred. Who knows? The more of these there are, the more likely someone complaining about lack of options today will find something they like tomorrow without having to try to move a boulder up hill with a straw.