If your scheme to make money from Bitcoin involves giving real money to someone else who's scheme to make money from Bitcoin involves getting real money from you, then looking at past history of Bitcoin money-making schemes it's highly likely that out of all the people around the table, you are the sucker.
Not a one is actually a small, well featured phone. They are simply old and/or reduced spec phones every bit as big as the first wave of large phones.
Generally true, but I've been hearing good things about the Sony Xperia mini/compacts. At least, I'm hoping that's true because when I have to replace my current 4.3" phone, I'm not keen on going much larger...
Silk Road Kingpin or not, I'm rooting for Ross here.
I wonder what the people he attempted to have murdered think about all this?
If we follow the arguments in the article to their logical conclusion, then you're talking about an accusation coming from a bunch of criminals. Indeed, one might argue that it's a criminal conspiracy against him.
If they're going to act like criminals, then the government has no credibility in any accusation they make against Mr. Ulbricht.
Now, he likely is a criminal scumbag who did some very stupid and/or shady things, but given the choice between going after one shady guy or an entire organization of criminals, which do you think is a better use of law enforcement resources?
Changes require systematic, reliable evidence, not emotional expressions . . . In the wake of more than 3 million comments...
3 million people having a coherent opinion on the subject is as systematic, reliable evidence as any other survey of public opinion. That the bulk of those 3 million are likely saying that network neutrality is a really good idea should be considered a fairly reliable data point. I'm not sure it would be a good idea for the FCC to just brush it off.
You implied that some manufacturers don't drop support prematurely.
Hm. True. I could've phrased that better, although the definition of "premature" in this case might be debatable. I like to think that everyone will agree that "while the device is still being sold in stores" definitely counts as "premature", and I'm of the opinion that anything less than 2 years after introduction is pushing it.
Outside of the Nexus line, I'm not sure any device would get a pass.
Even Google drops support for Nexus devices after 2 years.
They suggest it'll typically be 18 months, but I'm not sure they've released enough Nexus devices to establish any kind of solid track record. At the moment, the 1st gen Nexus 7 is over the 2 year mark and appears to still be seeing updates. The Nexus 4 and 10 are still being sold, so I doubt you'll see Google stop supporting them soon even though they're comfortably at the 2 year mark.
Google is just in a snit that CyanogenMod is fantastically better than stock android, BECAUSE it gives power back to users.
So does Xposed, and far deeper than CM ever contemplated.
More likely Google is looking at CM because CM effectively helps to solve the Android "fragmentation" problem, namely getting the latest version onto devices where the manufacturers drop support prematurely. All they'd have to do is officially brand CM as their "Android legacy support" service and just kinda step back.
Even if the US changed every single speed limit sign tomorrow to from MPH to KPH, how hard is it to match a number on a guage in front of you to the sign posted on the road?
US cars have mph as the main unit and km/h as the secondary. Canadian cars, for example, have km/h as the primary and mph as the secondary.
I would never have thought this was an issue until that stretch of time where I was switching between a Canadian and US vehicle for a period of time... it's not rocket science, but it's definitely an extra cognitive load when you're driving, and if you're not used to a particular vehicle then the difference between 55mph and 55km/h isn't as obvious as you'd expect.
It's a bit like what happens when the instrument cluster is put in the center of the dash (fuck the Nissan X-Trail) or the speedometer range is substantially different from what you're used to (if you're used to 100km/h being right at the top of the dial and you move to a vehicle where 80km/h is at the top, you *do* drive slower until you compensate).
As I said, not rocket science, and individually it's not a big issue, but with the sheer quantity of marginal drivers on the roads... I don't expect the transition would be bloodless.
The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.
Hm. Okay, I'll buy that argument.
In practice, if the CGI developer follows best security practices it shouldn't be a more significant problem than any other "untrusted input" path, and whatever invokes the CGI does have the option of cleaning up the environment instead of accepting the default, but it's fair to say there's a flaw in the spec.
The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.
Well, it's not that it allows external entities to poison the environment, it's that it gives the finger to that basic secure programming practice where you should just assume that externally provided input is tainted data.
(you could say that there is a design vulnerability in CGI - and I would agree about that).
Debatable.
There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved. And, aside from security, the performance hit of invoking a shell just to launch another program makes it a bit silly to do it any other way.
And I'd point out that it's possible to explicitly control the environment of a subprocess (i.e. execle()), so anything calling a CGI program can at least sanitize things to minimize any damage. Not that the CGI should depend on the caller to sanitize things, of course.
On the other hand, the environment is a perfectly stupid way to pass code around.
Valet mode also locks storage compartments, and disables the stereo.
Missed opportunity, there. It should turn the stereo on, and shuffle play Celine Dion's Greatest Hits at loud volume. Guaranteed to discourage joyriding, or any other kind of joy.
Given the massive increase in CCTV installs in places like parking areas, can a valet make a convincing claim that they have an expectation of privacy on the job site?
The only communication mechanism for talking to the subshell is the environment.
Well, the easy communication mechanism is the environment. And, quite frankly, I don't have a particular problem with bash treating stuff that bash intends to be a chunk of code as code. It's just random other bits of the environment that aren't intended for bash that are the problem.
It's *nix, though, so there's many more ways to pass data around between processes than just the environment. Even if you've gotta use the environment, why not go with a env variable namespace, like "BASH_FUNCTION_FOO=()"?
Try to understand, this is not about executing bash scripts as cgi, and it's not about sanitizing input. Period. It is about httpd setting environment variables from unsanitized user input when calling ANY cgi.
Well... no. The root of the problem is bash treating something which really should only be considered data as code.
When I hear the words "Environment Variables", I don't think "well, some random bozo is going to look at those and just up and execute 'em". For bash to be treating the contents of the environment as anything other than dumb strings is, quite frankly, a Very, Very Bad Thing. For variables being set within a shell script, sure, they're intended for bash. But for data passed from program to program and not really even intended for interpretation by any specific script engine (which is fundamentally what environment variables are for), it's incredibly dumb.
Personally, I like the idea of that. It encourages and funds a lot of Canadian artists that might otherwise get swamped out of the market by monied American interests.
Personally, I would much, much, much rather the CRTC enforce rules for true network neutrality for Canadian internet users and find some other way to promote Canadian content.
Or, more accurately, for someone else to force the CRTC to go that way, because there's pretty much zero probability that they'll do it without coercion.
The problem with relying for support for separation from the younger generation...
Well, yes. It still takes at least a generation for them to work it out of their system. 40 years might do it, but seeing where we are now in Canada I think it's going to take another 20 or so before we can really feel comfortable that separation is truly dead.
The reality is that there's more people in the RoC (Rest of Canada) who would vote to kick Quebec out than there are Quebecers willing to pull the trigger on separation.
Oh, definitely. And to some degree, I think the growing understanding that Quebec wouldn't be able to unilaterally dictate the terms of a separation actually proceeded is one of the biggest factors in killing the movement.
Apple also sells music in its lossless format, and there it's hard to get "robust" without annoying the listener.
No argument that it's hard.
But if Apple (I highly doubt U2 is directly involved in the research itself) did manage to develop a robust audio watermark that doesn't suck, it's understandable how someone would get the impression that it might result in an "unpiratable" format, at least within the bounds of the Apple walled garden.
The separatist movement here has burned itself out, the generation who were pushing for it being seen as burned-out old farts. Go back to the UK in 40 years and tell me that everyone lost.
From what I read of the demographics, it's mainly the younger generation of Scots that supported separation. They're pretty much at the stage of Quebec in the 70's.
I wonder if this will silence or encourage the separatists that want Quebec to leave Canada?
Encourage.
The margins are way too close. If it would've been more like 75% against, the Quebec separatists might have taken a bit of a morale hit, but 55% ? That's a "Please Play Again" for a separatist. The 1980 referendum was 59% against and it certainly didn't stop them.
The real question is whether the Scots are going to be smart enough to tar and feather the next bunch of politicians that decide they want to run a country? I'm not optimistic.
Because it shows that neither know what they are talking about. If I can HEAR it, I can copy it. And the quality can get pretty damn good depending on how the sound is captured.
The only way I can see something like that working is a robust audio watermark containing the purchasers iTunes information. Won't stop copying directly, but would theoretically allow them to go after a "source" and possibly publish revocation lists that some devices could support to suppress "pirated" music.
Of course, that would only be applicable to online stores (I assume the record companies would force other stores to toe the line on the technology) and likely could only be enforced on iDevices. It obviously could be trivially defeated by ripping the music from a CD (for that short while we still have mass-pressed anonymous, physical media), pirates buying music using throwaway store accounts, or other peoples accounts being hacked.
But, let's face it, at this point the best they can hope for is deterrence rather than outright prevention.
I think you're overselling it somewhat. I've tried the swype systems, and I always devolve to just tapping. Same with my friends that have access to it. Out of 4 of us, all of us hate swype based systems. That's not data, obviously, it's just an anecdote.
I think the GP is overselling it a bit too, but I've been using the standard Android keyboard for a bit now, which includes swype-like typing, and I'd have a tough time switching back to just tapping. It's substantially faster and generally as accurate as tapping and quite a bit better than any miniature hardware keyboard I've tried. I don't know that if it wasn't built if I'd have bothered downloading Swype or Swiftkey, but it's nice to have the option.
In some ways, it reminds me of the difference between Newton HWR and Palm Graffiti; you had to learn some new patterns to use Graffiti, but when you got used to it, it was light years ahead of the performance of the natural handwriting recognition of the Newton.
Slashdot Mirror
Just think... now we're just a double entendre away from the "shlong scale".
I was going to say that "you're a coward who is poisoning our national life" is a fine example, but that's good too.
If your scheme to make money from Bitcoin involves giving real money to someone else who's scheme to make money from Bitcoin involves getting real money from you, then looking at past history of Bitcoin money-making schemes it's highly likely that out of all the people around the table, you are the sucker.
Generally true, but I've been hearing good things about the Sony Xperia mini/compacts. At least, I'm hoping that's true because when I have to replace my current 4.3" phone, I'm not keen on going much larger...
That's really just a subset of an even more general rule of thumb, "a fool and his money are soon parted".
If we follow the arguments in the article to their logical conclusion, then you're talking about an accusation coming from a bunch of criminals. Indeed, one might argue that it's a criminal conspiracy against him.
If they're going to act like criminals, then the government has no credibility in any accusation they make against Mr. Ulbricht.
Now, he likely is a criminal scumbag who did some very stupid and/or shady things, but given the choice between going after one shady guy or an entire organization of criminals, which do you think is a better use of law enforcement resources?
3 million people having a coherent opinion on the subject is as systematic, reliable evidence as any other survey of public opinion. That the bulk of those 3 million are likely saying that network neutrality is a really good idea should be considered a fairly reliable data point. I'm not sure it would be a good idea for the FCC to just brush it off.
Hm. True. I could've phrased that better, although the definition of "premature" in this case might be debatable. I like to think that everyone will agree that "while the device is still being sold in stores" definitely counts as "premature", and I'm of the opinion that anything less than 2 years after introduction is pushing it.
Outside of the Nexus line, I'm not sure any device would get a pass.
They suggest it'll typically be 18 months, but I'm not sure they've released enough Nexus devices to establish any kind of solid track record. At the moment, the 1st gen Nexus 7 is over the 2 year mark and appears to still be seeing updates. The Nexus 4 and 10 are still being sold, so I doubt you'll see Google stop supporting them soon even though they're comfortably at the 2 year mark.
So does Xposed, and far deeper than CM ever contemplated.
More likely Google is looking at CM because CM effectively helps to solve the Android "fragmentation" problem, namely getting the latest version onto devices where the manufacturers drop support prematurely. All they'd have to do is officially brand CM as their "Android legacy support" service and just kinda step back.
US cars have mph as the main unit and km/h as the secondary. Canadian cars, for example, have km/h as the primary and mph as the secondary.
I would never have thought this was an issue until that stretch of time where I was switching between a Canadian and US vehicle for a period of time... it's not rocket science, but it's definitely an extra cognitive load when you're driving, and if you're not used to a particular vehicle then the difference between 55mph and 55km/h isn't as obvious as you'd expect.
It's a bit like what happens when the instrument cluster is put in the center of the dash (fuck the Nissan X-Trail) or the speedometer range is substantially different from what you're used to (if you're used to 100km/h being right at the top of the dial and you move to a vehicle where 80km/h is at the top, you *do* drive slower until you compensate).
As I said, not rocket science, and individually it's not a big issue, but with the sheer quantity of marginal drivers on the roads... I don't expect the transition would be bloodless.
Hm. Okay, I'll buy that argument.
In practice, if the CGI developer follows best security practices it shouldn't be a more significant problem than any other "untrusted input" path, and whatever invokes the CGI does have the option of cleaning up the environment instead of accepting the default, but it's fair to say there's a flaw in the spec.
Well, it's not that it allows external entities to poison the environment, it's that it gives the finger to that basic secure programming practice where you should just assume that externally provided input is tainted data.
Debatable.
There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved. And, aside from security, the performance hit of invoking a shell just to launch another program makes it a bit silly to do it any other way.
And I'd point out that it's possible to explicitly control the environment of a subprocess (i.e. execle()), so anything calling a CGI program can at least sanitize things to minimize any damage. Not that the CGI should depend on the caller to sanitize things, of course.
On the other hand, the environment is a perfectly stupid way to pass code around.
Missed opportunity, there. It should turn the stereo on, and shuffle play Celine Dion's Greatest Hits at loud volume. Guaranteed to discourage joyriding, or any other kind of joy.
Given the massive increase in CCTV installs in places like parking areas, can a valet make a convincing claim that they have an expectation of privacy on the job site?
Well, the easy communication mechanism is the environment. And, quite frankly, I don't have a particular problem with bash treating stuff that bash intends to be a chunk of code as code. It's just random other bits of the environment that aren't intended for bash that are the problem.
It's *nix, though, so there's many more ways to pass data around between processes than just the environment. Even if you've gotta use the environment, why not go with a env variable namespace, like "BASH_FUNCTION_FOO=()"?
Well... no. The root of the problem is bash treating something which really should only be considered data as code.
When I hear the words "Environment Variables", I don't think "well, some random bozo is going to look at those and just up and execute 'em". For bash to be treating the contents of the environment as anything other than dumb strings is, quite frankly, a Very, Very Bad Thing. For variables being set within a shell script, sure, they're intended for bash. But for data passed from program to program and not really even intended for interpretation by any specific script engine (which is fundamentally what environment variables are for), it's incredibly dumb.
Personally, I would much, much, much rather the CRTC enforce rules for true network neutrality for Canadian internet users and find some other way to promote Canadian content.
Or, more accurately, for someone else to force the CRTC to go that way, because there's pretty much zero probability that they'll do it without coercion.
Well, yes. It still takes at least a generation for them to work it out of their system. 40 years might do it, but seeing where we are now in Canada I think it's going to take another 20 or so before we can really feel comfortable that separation is truly dead.
Oh, definitely. And to some degree, I think the growing understanding that Quebec wouldn't be able to unilaterally dictate the terms of a separation actually proceeded is one of the biggest factors in killing the movement.
No argument that it's hard.
But if Apple (I highly doubt U2 is directly involved in the research itself) did manage to develop a robust audio watermark that doesn't suck, it's understandable how someone would get the impression that it might result in an "unpiratable" format, at least within the bounds of the Apple walled garden.
From what I read of the demographics, it's mainly the younger generation of Scots that supported separation. They're pretty much at the stage of Quebec in the 70's.
Encourage.
The margins are way too close. If it would've been more like 75% against, the Quebec separatists might have taken a bit of a morale hit, but 55% ? That's a "Please Play Again" for a separatist. The 1980 referendum was 59% against and it certainly didn't stop them.
The real question is whether the Scots are going to be smart enough to tar and feather the next bunch of politicians that decide they want to run a country? I'm not optimistic.
The only way I can see something like that working is a robust audio watermark containing the purchasers iTunes information. Won't stop copying directly, but would theoretically allow them to go after a "source" and possibly publish revocation lists that some devices could support to suppress "pirated" music.
Of course, that would only be applicable to online stores (I assume the record companies would force other stores to toe the line on the technology) and likely could only be enforced on iDevices. It obviously could be trivially defeated by ripping the music from a CD (for that short while we still have mass-pressed anonymous, physical media), pirates buying music using throwaway store accounts, or other peoples accounts being hacked.
But, let's face it, at this point the best they can hope for is deterrence rather than outright prevention.
I think the GP is overselling it a bit too, but I've been using the standard Android keyboard for a bit now, which includes swype-like typing, and I'd have a tough time switching back to just tapping. It's substantially faster and generally as accurate as tapping and quite a bit better than any miniature hardware keyboard I've tried. I don't know that if it wasn't built if I'd have bothered downloading Swype or Swiftkey, but it's nice to have the option.
In some ways, it reminds me of the difference between Newton HWR and Palm Graffiti; you had to learn some new patterns to use Graffiti, but when you got used to it, it was light years ahead of the performance of the natural handwriting recognition of the Newton.
I couldd swear that Microsoft has been trying hard at the exact opposite...
True. But it still gets more respect than "Windows Phone".