Can someone please point me to the alleged Right to Privacy in the Constitution, because I don't see one.
There is no prohibition against government infringing upon a hypothetical right to privacy, and certainly no expectation of privacy exists for anything transmitted over the Internet, which was created and built with government money.
It's called the tenth amendment.
"The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people."
Since there's not a specific right to invade privacy granted to the Fed, there is therefore a right to privacy.
If only (Holland) some country (Holland) could come up with a way (Holland) so that areas (60% of the population of Holland) could remain viable (half of Holland's land area) in the face of (dikes in Holland) rising sea levels (Holland) so that we didn't (Holland) have to worry about this (Holland).
Doesn't the necessary (Holland) expertise (Holland) exist anywhere on Earth (Holland)?
If DRM is really impossible to implement in F/OSS software, without closed source or the threat of political force... Then what's the worry?
It seems like the worst-case scenario is media providers get a false sense of security and start providing content without silly plugins that actually ARE closed and non-accessible (under the threat of legal action).
The DRM is effectively forced.
I going to just flat out state that you've obviously never attempted to run the Netflix plugin from a ChromeOS machine (ChromeBook/ChromeBox) on another Linux platform, and discovered it won't run.
The modules in this case do navel-gazing and examine the container program to verify that the container program ins an unadulterated official build, such that you can't just compile up your own version of the browser, and expect the module to continue operating.
For Netflix on Linux desktops, this Navel-gazing took the form of utilizing the HAL, which was deprecated by its authors in 2008: http://www.freedesktop.org/wik... which was then used to generate a unique device identifier, which was used in the authorization and decryption process for the data, after having been watermarked with the same identifier at the source so that you could tell who exactly rented the content that was then stripped of DRM, and uploaded to a copy site.
This same (deprecated) module was required by Adobe FlashAccess beginning in February 2012, and was the reason for the sudden failure of rented content from both Amazon and YouTube, which both used FlashAccess as a means of DRM'ing "premium content" starting on that date.
So it's about as true to say that the DRM "isn't forced" as it's to say that the HTML "trusted proxy" mechanism would not be forced in order to allow you to make HTTPS connections, should it be standardized, thus giving a centralized ISP choke point, nominally for caching content, but practically, for introspecting HTTPS streams to make sure they are not transporting "unapproved content". If you can't access content without DRM, or you can't access HTTPS without authorizing the proxy at your ISP to listen in on the conversation, effectively instituting an automatic MITM attack for all your communications, it's kind of hard to credit participation in the scheme as "unforced" (Sure... you could choose not to have encrypted internet connectivity at all, instead of encrypted activity your ISP or anyone who got a single FISA order into your ISP could listen in on, but is that really a choice?).
An Oligarchy does not necessarily mean that the wealthy control the government; it can also apply to dynastic rulership by families on the basis of something other than wealth, e.g. as in Feudalism, or it could be a combination of factors, not always involving wealth.
The study referred to specifically called out wealth as the overriding factor in control, which makes it a Plutocracy.
You can see from the wikipedia article on Oligarchy that it's a quite inexact term for what they are talking about: http://en.wikipedia.org/wiki/O...
"Forms of government and other political structures associated with oligarchy can include aristocracy, meritocracy, military junta, plutocracy, stratocracy, technocracy, theocracy and timocracy."
For a supposedly academic study, you'd think they would be a little less loose with their definitions, particularly when they are counter to the conclusions they have reached, under some circumstances. For example, I don't think under any stretch of the imagination could we say that the government of the U.S. was a Theocracy, Technocracy, or Military Junta. Indeed, we can say that it went from a Timocracy to a Plutocracy about the time corporations gained citizenship, and dollars were ruled to be equivalent to speech by the U.S. Supreme Court.
You realize the PS3's hardware WAS exotic right? That's exactly why it's hard! Write code optimized for multiple SPE units, and see how well you can get it to run on x86.
There's actually some validity to the GP's post.
Ideally, you would write the game portably, knowing that you will need to potentially take it to market on a lot of platforms, if it ends up being a popular title, and so as a result, you'd have a minimal porting set that could just be compiled and run, with additional optimizations on top of that tuned for the platform on which it's going to run.
Although not done a lot recently, the implementation of the original libc had C versions for all the code contained therein, and then had hand optimized assembly versions that would replace the C versions on a specific platform.
The intent was to be able to get it up and running on a new platform fairly quickly by having a small *required* assembly language footprint in the context switch, bootstrap, and CRT0 code, and then optimize the C code to assembly on a platform specific basis once you wer up and running self-hosted on the platform. This also gave you the opportunity to check assembly optimizations in user space first, without breaking everything by trying something that wouldn't work because of some mistake, and ending up with a lot of work to back the changes out (this was back in the RCS/SCCS days, where source code control systems weren't as capable as they are today).
It makes sense to do the same thing for games; minimally, the complaints they had about shaders should have been totally workaroundable, given that Direct X doesn't allow indefinite termination shaders, and requires the code to be fully unrolled compared to, say OpenGL, where there's no guarantee that a shader terminates (one of the reasons a game can crash a Mac or Linux using OpenGL, but can't crash Windows, using the OpenGL compatibility layer -- if it won't unroll, then it's discarded by DirectX).
In any case, it does show that there were at least some corners cut, and just because the host library is similar, you shouldn't expect the hand tuned code to be at all similar, especially going from a Cell architecture PS/3 (essentially, a data flow processor) to Von Neumann architecture on an AMD processor on the PS/4. It's obvious that all the hand tuned pieces would need to be rewritten, just as if you were porting to Windows or XBox or some other platform that wasn't also Cell-based. You'd think if they had planned ahead for ports to other platforms other than the PS/3, that that planning would be directly applicable to geting the code running on the PS/4 as well.
The code is largely in a subset of C; there are certain language features that make it intrinsically harder to do static analysis and checking, and which you avoid in order to avoid introducing certain classes of problems into the code. Examples include unspecified array lengths for arrays declared at the ends of structures (a c99 feature first defined with a slightly different syntax by gcc), use of function pointers that don't end up with a const qualifier after initialization, serialization and deserialization of data objects containing pointers, variant length arrays, varradic functions, with or without in-band format strings for interpretation of arguments subsequent to the format strings, etc.. For a given compiler technology, it can also include dynamic scoping, locally scoped variable, and basic block replications which introduce issues when using some code constructs. Typically, there is also a requirement for single entry/single exit, and similar techniques that can use runtime assertions (statically or optionally compiled in) in order to test on larger data sets, although by definition, such things are relative Ad Hoc, and therefore not provable in terms of code coverage.
Similar dialects are defined by standards, such as "MISRA C" (Motor Industry Software Reliability Association), but of course, it costs money to get that standard, and it's not disclosed, so there's no open source compliance checkers, and there's no open source static analysis tools that can check the compliant code based on compliance related assumptions. One of the disclosed requirement is use of sized type everywhere, so fundamental C types are eschewed in favor of them; so you don't use "char", "short", "int", "long", and "long long", you use things like "uint8_t" and "int32_t", and so on. Another is that there are limits to allowed cyclomatic complexity, as determined by static analysis tools.
What it pretty much comes down to is that C by itself lets you get away with things that, if you are allowed to get away with them, makes the outcome of running the program indeterminate. It's still not possible to solve/prevent the halting problem in these dialects, but it's easier to avoid getting into a situation where you have to, if you use the constrained dialect and programming style in your code.
It's really be handy if some day MISRA or something similar became an open standard so that we could raise the level of discourse on these things, particularly as they apply to life support systems, since some people place both privacy, security of financial transactions, and so on, on an equal footing with straight life support.
Does not play, interact with others. Proprietary, exclusionary design is the baseline, the goal. Designed in malfunction.
History being a predictor, I conclude it is intentional. Proving it will be another matter.
Proving it is going to be nearly impossible. At around the time the iPhone came out, Apple gave all its employees iPhones. There were "recycle bins" all over the Apple campus where you would throw your non-Apple iPhones. Apple engineers did not see or, largely, interact with, other phones at all.
I think this was a mistake on Apple's part, and I brought it up with the exec team at the time, since it meant that none of the engineers got to see what competitors were doing wrong relative to Apple, and vice versa, so that Apple could improve its products where the competitors were better. That's mostly because there was no acknowledgement that competitors could be better in any fashion, and for a long time, that was in fact true. At the time the iPhone was introduced, it was the best damn mobile phone ever produced by anyone, and all the bitching about a lack of MS Exchange integration and a physical Blackberry-like keyboard didn't stop Microsoft employees from buying the things in droves, and didn't stop Blackberry from basically tanking in the marketplace because it was non-competitive.
For there to have been malice, or even intent, involved in the design decisions, you'd have to show that they were even considering something other than the user experience of "Hey! I don't have to pay the global average price of $0.11 per message if we both have iPhones!". To do that, they'd have to have something other than iPhones in hand, and they'd have to consider people replacing iPhones with something else in a context of something other than "What can we do to surprise and delight this unhappy customer enough to win them back as a customer?".
The bottom line is that it's a blind spot, and it was encouraged as one by the internal culture of Apple, both in terms of engineering and marketing. Why consider engineering constraints other than those right in front of you, that's how Facebook and Google work, right? If we end up in a hole, why, we'll just iterate ourselves out of it, since there have to be small evolutionary steps between a mistake and a great product, right?
Apple has a history of screwing up rather spectacularly, in was which mostly don't matter to most customers, but really cut off future avenues of products, product add-ons, functional expansion, and so on. There's a reason that the "X" in "XML" doesn't actually mean "eXtensible" when it comes to your iTunes library, and that's part of the mistake in tying in the data model behind CoreData to the implementation so strongly that iTunes loses its cookies and rebuilds your music database if you try.
Again, it's a cultural blind spot ("Why would any software other than iTunes need to access the iTunes library? Why wouldn't you just use iTunes?"). IMO, this suit will cost a lot of money, get settled to make it go away, and change nothing.
"Not really my job to give them a personally clue"
It is your job to stop lying about people doing the wrong thing when faced with evidence that they did in fact do the things that you say they were stupid not to do.
The canonically correct way to deal with this is to disable iMessage for your phone number on your iPhone *before* you switch to another phone. I've already stated that this is potentially problematic if you drop your iPhone in a toilet, and then buy a different phone than an iPhone to replace it, and never disengage in this specific way. Everything else is a workaround. That his friends with iPhones are still sending via iMessage because his # hasn't been taken out of the back end database (by him) is not "evidence" that he's correctly removed his number from the iMessage service database, it is in fact evidence that he has *not* done so.
As an IT Architect, who daily works with and for those with varying degrees of technical skills, I would disagree that the user is "an idiot". The steps you mention will certainly address the issue no doubt. What is in question is if the layperson should be aware of these steps and be capable of undertaking them "if" they forget to disable iMessage. What a class action lawsuit will do is force Apple to put in checks that look at the IMEI of the phone each time an iMessage is sent and the ack isn't received by the server from the phone in x amount of time. There is a different error message for an IMEI either offline or registered to a new user than one where the phone is simply unavailable. I can think of 5 different ways Apple can identify the device changed to a non Apple device. They haven't fixed this issue on purpose.
Messages sent via iMessage are not sent that way on the carrier back end, they are sent on the phone, via the data connection, and the IMEI or ESN/MEID is not generally sent, as it would have to be pulled out and sent in-band as part of the message in a framed header for the message on the iPhone. This would require both a software update on the iPhone, and a software update on the back end iMessage service.
Given that the iMessage service predates the current generation of iPhones, and therefore the older iPhones will not be receiving a software update, as they are incapable of running the newest version of iOS, this is not a possibility for those phones, and not a possibility to automatically deal with the issue (not to mention that the Apple ID registration on the back end would have to record both the IMEI or ESN/MEID, and for GSM, the IMSI and ICCID.
If you just switched your number over to another carrier, you are pretty much screwed without the carrier information as well, especially if the rest of the information stays the same, since the sending phone has no way in heck of knowing that that the target #'s SIM has been inserted into another phone with a different IMEI, and it's not like the Android phone is going to contact the Apple back end, and tell them about it.
There just aren't the notifications necessary from the non-iMessage enabled phone: it's a manual process at that point.
As I stated in the response to the other poster above, the carriers have basically zero incentive to cooperate by providing additional notifications in a post-switch scenario, since iMessage, like WhatsApp, undercuts their primary revenue model.
I suspect that we will be seeing the same thing with WhatsApp users who similarly undercut the carrier business model, in a way that's almost identical to the way iMessage does, but is not limited to iPhones.
Why don't you reply to this post because that person seems to have tried to unsubscribe from iMessage.
Not really my job to give them a personally clue, above and beyond the above posting, especially since they are posting AC, and I therefore can't contact them to help them directly work around whatever it is they are functionally failing to do. As an AC, there's really no way to have a conversation person to person about it.
I have an iphone. I never turned on any setting related to imessages. I still received imessages from other iphone users and would be pretty annoyed if the communication failed because of switching to a new phone.
It's turned on by default if you set up iCloud services, which people generally do to sync their address book, apps, and other content via "the cloud". That in turn is tuned on by default if you have push notifications turned on at all (which requires an Apple ID, and is how iMessage notifications happen, generally quicker than SMS notifications over the cellular providers networks (and the carrier bridge, if the sender and recipient aren't subscribed with the same carrier in the same geographic region).
Not only that, they is no indication that messages aren't being delivered.
There's a visual indicator on the sender's phone of a green vs. a blue "talk bubble" background color to indicate something sent via iMessage vs. SMS. Yeah, this isn't terrifically called out.
The notification will occur after the 45 days have elapsed (actually, it depends on when they run the batch job; it's generally 28 days +/- 14 days). But yeah, the notification is internal to the system.
I'll note for the record that SMS message delivery is also not acknowledged, so SMS messages, like iMessage messages, are pretty much like UDP datagrams, no matter how you slice things.
Poor setup on Apples part and clearly designed to hook people in.
I think it was more a cultural blind spot; in order to anticipate this being a problem, they'd have to consider the idea that someone might want to use a phone other than an iPhone, which is kind of unthinkable if you are an engineer whose livelihood is tied to building iPhone services... "Why in heck would anyone want to use software other than the software I wrote, which is the niftiest software evar?".
They have a settings mechanism on the iPhone that would take care of this, but if you dropped your iPhone in a toilet and killed it, you wouldn't be able to use that if instead of buying a replacement iPhone, ho used something else.
There's the online mechanism via appleid.apple.com, as previously noted, but I think that's a workaround. For number portability to another phone, which generally comes with a carrier contract and a new SIM (or a CDMA ID), they'd get the notification through the phone number portability act due to the carrier contract (this is half the source of the 45 days for the automatic cutover), but slamming the SIM around between phones that are iPhones and non-iPhones, there's really no network notifications that take place back to Apple that the change has occurred.
One possible workaround, and I will bet it's the one that gets put in place, should this suit be considered to have merit, rather than being a user error (it's definitely a user error, and Apple isn't really responsible for third party equipment not having the notification back to the Apple ID to dissociate it) would be to note failure to contact on the iMessage sends more promptly, and, worst case secondary settlement, probably retransmit them via SMS gateway.
This last is unlikely to happen, since it'd need to forge the source address as the original senders phone #, rather than the gateway, which would require additional agreements with all the carriers. I'm going to guess that the carriers won't be very cooperative in this, since they made about $10B last year in SMS charges worldwide, which is why Facebook was willing to pay $19B for "WhatsApp". Why cooperate with someone who is trying to disrupt your business model and reduce your profits, after all?
The people sending you messages are not sending you SMS, they are sending you iMessages. They are sending to your contact phone number, and they have iMessage turned on to save them $$$ when sending texts to other people registered with iMessage.
Because you used to have an iPhone, and had also turned iMessage on, your phone number is in their database, and so when it's deciding what data channel to use, it looks up the phone number it's about to send to, and if it's listed in the iMessage database, it sends an iMessage to the associated AppleID instead of sending an SMS via the cellular network. This way it doesn't cost them SMS $$$ to send the message.
When you pulled the SIM from your iPhone, you stupidly failed to turn off iMessage in your settings, and then sync those settings back to the iCloud. As this knowledge base article indicates, it can therefore take up to 45 days before it starts using SMS again: http://support.apple.com/kb/TS...
Alternately, you can go to http://appleid.apple.com/ and log in with your Apple ID, and manage your account, and disable iMessage that way (typically by removing your mobile phone number, and if you don't have an land line, putting the number in for your (non-mobile) contact number instead.
Note: Once the message has been sent, either via iMessage, or SMS, from the originating phone, it's sent; you don't get a second shit. It's not like those messages are "stored up" in a system that's capable of sending SMS messages, since the decision was made on the senders iPhone, not on the back end server.
Basically, it boils down to the former iPhone user being an idiot about disengaging from the additional iPhone associated services that they opt'ed into.
But never fear, up to 45 days afterward, the switch will happen automatically, as iMessage feeds back into the configuration database that the messages sent to the number have been undeliverable via iMessage. Or, you know, they could log onto http://appleid.apple.com/ now and fix it themselves, which can take up to 24 hours to take effect, because some idiot thought NoSQL was a good idea.
I can understand the idea, even if he's done an incredibly poor job of explaining his position as to why he recommends it.
Tesla is moving towards leased battery pack exchange as a quick long range refueling strategy, and as a mechanism for dealing with battery life expectancy based on number of charge cycles.
This model would be helpful to the adoption of electric vehicles from both Tesla, other vendors, as viable alternatives to hydrocarbon fuel vehicles, but that assumes that there is wide adoption of their "razor blade" design, and that in turn is dependent on them not having a monopoly, or design-favored market advantage by being in competition with their customers.
The problem is that Tesla has invented the sealed battery rechargeable flashlight already, and now that they've firmly pointed out that a market exists for flashlights, they are in the process of inventing flashlights with replaceable batteries, at the same time they are inventing "D" batteries.
The market for "D" batteries is going to be *much* larger than the market for Tesla brand flashlights.
The risk on the battery side is that someone else might come in and build a better "D" battery, while the risk on the car side is that someone might come in and build a commodity flashlight that takes "D" batteries, and vastly undercut the price of a Tesla manufactured one.
I think that the range/recharge issue is very real, particularly in dense urban areas where you have street parking for the most part (San Francisco, Seattle, etc.), where the range is less of an issue -- IFF you are able to charge when you need to, instead of trying to run an extension cord from your apartment, down sig stories, and two blocks away to the curb where you were able to find a parking spot.
Part of the value in a battery position, however, is based on establishing the "service station" company owned vertical market integration model up front, which is likely something that would need to be funded by something like bonds, given the extreme costs involved in making such things ubiquitous, even on a franchise basis.
But overall, it's like going back in time and asking Apple if they want to sell software or hardware, when Apple sold computers - the integrated aggregate of both - and I think this would be a hard case to make to Musk, who doesn't sell batteries or cars, he sells transportation.
Even if you work your ass off, it's not going to bring back your blue collar job from overseas.
Even in a technical field, working your ass off is not automatically rewarded, unless you *ask* for more rewards, and even then, with a verbal agreement in place, you can end up not getting the promised rewards.
You have exactly the same "risk" of children believing the world works, automatically, to reward hard work, as you do having them believe the world works, automatically, to reward intelligence. There is absolutely *nothing* automatic about it.
Don't praise kids for being smart, it becomes a major part of their identity and whenever some situation comes along that they fail to resolve it can mess them up and they will avoid even attempting things that can result in them feeling not smart. Praise them for working hard, etc.
Don't praise kids for working hard, it becomes a major part of their identity and whenever some situation comes along that they fail to resolve it can mess them up and they will avoid even attempting things that can result in them feeling they are not working hard enough. You know, like when they find out that "work hard, and the rewards will follow" is a lie told to get them to work hard with the promise of a future reward which never materializes.
Long-lived roads are too labor and time intensive to build.
Germany seems to manage. But then again, they put their road work out to bid, and generally award the contract to whoever offers the longest warranty. If the state itself is doing the work, they don't have to compete on price or labor efficiency, and it's in the best interests of the people doing the work to consider their future employment options by doing a crappy job, similar to Wally's "I'm going to write myself a minivan!" reaction to the announcement of a "bug bounty" in the Dilbert comic strip.
There's a reason why the joke "The shortest distance between any two points is under construction" is not really that funny in California.
are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript ?
Do you even have to ask? Do you never go out on the internet?
ALL websites are more loaded than last year in JavaScript, and this is not a new trend. GMail was just pioneering (in the webmail space that is) the webapp that has only one page and everything you do is driven by JavaScript and the DOM.
Actually, I *do* have to ask. One of Googles blind spots in doing very active UI's with JavaScript is the fundamental assumption that everyone has the same RTT you do, sitting on Google's fiber optic backbone, and that you have very high bandwidth to go with that. Not all companies developing web sites have that blind spot, and I think that it contributes significantly to Google's willingness to make certain assumptions.
I'd say that, other than companies that obviously aren't going to go anywhere, Google has probably *the* singly heaviest browser computation and bandwidth loading of an of the top 20 web sites out there.
So again: I'd really like to know what actually drove the decision to do this work, and whether it was an externality. Thanks.
Additional benchmarks for Safari with this technology vs. Chrome with its JavaScript acceleration would be appreciated; is this a closing of the speed gap, a move ahead, or a lateral move (i.e. faster in some areas than Chrome, slower in others)?
Also: the purpose Chrome has had in adopting JavaScript acceleration is that Google's web properties are JavaScript heavy, and accelerating JavaScript gives them a better overall user experience for Google Docs, GMail, and similar Google products. Was this a "compete with Chrome" move, or are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript, and so it was necessary without the Chrome pressure because of widespread increases in JavaScript overhead on average pages?
I have a really hard time caring about "up to 100 watts of power depending on the cable version", mostly because of the "depending on the cable version" part of the statement.
How is this different from DVI, which much or might not have multichannel audio, might or might not be analog, might or might not support 5 channel digital sound, etc., etc.?
One thing Thunderbolt has going for it is that a cable is a cable, and you don't have to worry about it. If you want negotiated power supplied over USB, fine, but don't make me search my cardboard box for the "most sincere USB 3.1 cable". Thanks.
- - - - - I'm afraid teachers are a large part of the problem. Their unions consistently thwart attempts to address teacher performance or rather the lack thereof. - - - - -
The first half of that (very common) statement is unproven and in most cases demonstrably false. The second half, also very common hard right wing propaganda, is an issue on which there can be reasonable disagreement but is not in any form a "given truth" and even at best ignores the history of teacher unionization from 1920. So, not very good marks to your (presumably private school?) history and political science teachers.
sPh
Vint Cerf - Vinton F'ing Cerf - was not allowed to fill in for his kids schools CS teacher for a couple of months while the teacher was unable to teach.
The reason for this was that Vinton F'ing Cerf did not have a California teacher certification to prove he knew how to teach computer science. Clearly unqualified, after having invented the F'ing Internet.
That's kind of not allowing Edison to teach a introductory science class about electricity.
I have yet to see a local cyclist perform a proper track stand and accelerate properly when a light turns green. If one watches professional cyclists one will see that one must use the rocking from side to side motion when coming out of a track stand to accelerate to high speeds. I had mastered this move when I used to ride 250 miles a week in my twenties. Cyclists should get licenses to ride on the roads just like automobile drivers.
It'd help if they at least got training. People who spend thousands of dollars on a bike, and zero dollars learning how to ride correctly are generally known as "Freds" among experienced cyclists. You can tell a "Fred" just by watching them ride or start from a stop (as yu note).
Slashdot Mirror
Can someone please point me to the alleged Right to Privacy in the Constitution, because I don't see one.
There is no prohibition against government infringing upon a hypothetical right to privacy, and certainly no expectation of privacy exists for anything transmitted over the Internet, which was created and built with government money.
It's called the tenth amendment.
"The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people."
Since there's not a specific right to invade privacy granted to the Fed, there is therefore a right to privacy.
Is there even any good encrypted email providers left?
By "good", you mean "compliant with FISA court orders for installation of monitoring equipment", right?
If only (Holland) some country (Holland) could come up with a way (Holland) so that areas (60% of the population of Holland) could remain viable (half of Holland's land area) in the face of (dikes in Holland) rising sea levels (Holland) so that we didn't (Holland) have to worry about this (Holland).
Doesn't the necessary (Holland) expertise (Holland) exist anywhere on Earth (Holland)?
If DRM is really impossible to implement in F/OSS software, without closed source or the threat of political force... Then what's the worry?
It seems like the worst-case scenario is media providers get a false sense of security and start providing content without silly plugins that actually ARE closed and non-accessible (under the threat of legal action).
The DRM is effectively forced.
I going to just flat out state that you've obviously never attempted to run the Netflix plugin from a ChromeOS machine (ChromeBook/ChromeBox) on another Linux platform, and discovered it won't run.
The modules in this case do navel-gazing and examine the container program to verify that the container program ins an unadulterated official build, such that you can't just compile up your own version of the browser, and expect the module to continue operating.
For Netflix on Linux desktops, this Navel-gazing took the form of utilizing the HAL, which was deprecated by its authors in 2008: http://www.freedesktop.org/wik... which was then used to generate a unique device identifier, which was used in the authorization and decryption process for the data, after having been watermarked with the same identifier at the source so that you could tell who exactly rented the content that was then stripped of DRM, and uploaded to a copy site.
This same (deprecated) module was required by Adobe FlashAccess beginning in February 2012, and was the reason for the sudden failure of rented content from both Amazon and YouTube, which both used FlashAccess as a means of DRM'ing "premium content" starting on that date.
So it's about as true to say that the DRM "isn't forced" as it's to say that the HTML "trusted proxy" mechanism would not be forced in order to allow you to make HTTPS connections, should it be standardized, thus giving a centralized ISP choke point, nominally for caching content, but practically, for introspecting HTTPS streams to make sure they are not transporting "unapproved content". If you can't access content without DRM, or you can't access HTTPS without authorizing the proxy at your ISP to listen in on the conversation, effectively instituting an automatic MITM attack for all your communications, it's kind of hard to credit participation in the scheme as "unforced" (Sure... you could choose not to have encrypted internet connectivity at all, instead of encrypted activity your ISP or anyone who got a single FISA order into your ISP could listen in on, but is that really a choice?).
An Oligarchy does not necessarily mean that the wealthy control the government; it can also apply to dynastic rulership by families on the basis of something other than wealth, e.g. as in Feudalism, or it could be a combination of factors, not always involving wealth.
The study referred to specifically called out wealth as the overriding factor in control, which makes it a Plutocracy.
You can see from the wikipedia article on Oligarchy that it's a quite inexact term for what they are talking about:
http://en.wikipedia.org/wiki/O...
"Forms of government and other political structures associated with oligarchy can include aristocracy, meritocracy, military junta, plutocracy, stratocracy, technocracy, theocracy and timocracy."
For a supposedly academic study, you'd think they would be a little less loose with their definitions, particularly when they are counter to the conclusions they have reached, under some circumstances. For example, I don't think under any stretch of the imagination could we say that the government of the U.S. was a Theocracy, Technocracy, or Military Junta. Indeed, we can say that it went from a Timocracy to a Plutocracy about the time corporations gained citizenship, and dollars were ruled to be equivalent to speech by the U.S. Supreme Court.
You realize the PS3's hardware WAS exotic right? That's exactly why it's hard! Write code optimized for multiple SPE units, and see how well you can get it to run on x86.
There's actually some validity to the GP's post.
Ideally, you would write the game portably, knowing that you will need to potentially take it to market on a lot of platforms, if it ends up being a popular title, and so as a result, you'd have a minimal porting set that could just be compiled and run, with additional optimizations on top of that tuned for the platform on which it's going to run.
Although not done a lot recently, the implementation of the original libc had C versions for all the code contained therein, and then had hand optimized assembly versions that would replace the C versions on a specific platform.
The intent was to be able to get it up and running on a new platform fairly quickly by having a small *required* assembly language footprint in the context switch, bootstrap, and CRT0 code, and then optimize the C code to assembly on a platform specific basis once you wer up and running self-hosted on the platform. This also gave you the opportunity to check assembly optimizations in user space first, without breaking everything by trying something that wouldn't work because of some mistake, and ending up with a lot of work to back the changes out (this was back in the RCS/SCCS days, where source code control systems weren't as capable as they are today).
It makes sense to do the same thing for games; minimally, the complaints they had about shaders should have been totally workaroundable, given that Direct X doesn't allow indefinite termination shaders, and requires the code to be fully unrolled compared to, say OpenGL, where there's no guarantee that a shader terminates (one of the reasons a game can crash a Mac or Linux using OpenGL, but can't crash Windows, using the OpenGL compatibility layer -- if it won't unroll, then it's discarded by DirectX).
In any case, it does show that there were at least some corners cut, and just because the host library is similar, you shouldn't expect the hand tuned code to be at all similar, especially going from a Cell architecture PS/3 (essentially, a data flow processor) to Von Neumann architecture on an AMD processor on the PS/4. It's obvious that all the hand tuned pieces would need to be rewritten, just as if you were porting to Windows or XBox or some other platform that wasn't also Cell-based. You'd think if they had planned ahead for ports to other platforms other than the PS/3, that that planning would be directly applicable to geting the code running on the PS/4 as well.
What is this "C dialect" of which you speak?
The code is largely in a subset of C; there are certain language features that make it intrinsically harder to do static analysis and checking, and which you avoid in order to avoid introducing certain classes of problems into the code. Examples include unspecified array lengths for arrays declared at the ends of structures (a c99 feature first defined with a slightly different syntax by gcc), use of function pointers that don't end up with a const qualifier after initialization, serialization and deserialization of data objects containing pointers, variant length arrays, varradic functions, with or without in-band format strings for interpretation of arguments subsequent to the format strings, etc.. For a given compiler technology, it can also include dynamic scoping, locally scoped variable, and basic block replications which introduce issues when using some code constructs. Typically, there is also a requirement for single entry/single exit, and similar techniques that can use runtime assertions (statically or optionally compiled in) in order to test on larger data sets, although by definition, such things are relative Ad Hoc, and therefore not provable in terms of code coverage.
Similar dialects are defined by standards, such as "MISRA C" (Motor Industry Software Reliability Association), but of course, it costs money to get that standard, and it's not disclosed, so there's no open source compliance checkers, and there's no open source static analysis tools that can check the compliant code based on compliance related assumptions. One of the disclosed requirement is use of sized type everywhere, so fundamental C types are eschewed in favor of them; so you don't use "char", "short", "int", "long", and "long long", you use things like "uint8_t" and "int32_t", and so on. Another is that there are limits to allowed cyclomatic complexity, as determined by static analysis tools.
What it pretty much comes down to is that C by itself lets you get away with things that, if you are allowed to get away with them, makes the outcome of running the program indeterminate. It's still not possible to solve/prevent the halting problem in these dialects, but it's easier to avoid getting into a situation where you have to, if you use the constrained dialect and programming style in your code.
It's really be handy if some day MISRA or something similar became an open standard so that we could raise the level of discourse on these things, particularly as they apply to life support systems, since some people place both privacy, security of financial transactions, and so on, on an equal footing with straight life support.
http://www.bbc.co.uk/news/blogs-echochambers-27074746
They're using the wrong word. It's a Plutocracy, not an Oligarchy.
A "cultural blind spot"? Innocent mistake? No.
Does not play, interact with others. Proprietary, exclusionary design is the baseline, the goal. Designed in malfunction.
History being a predictor, I conclude it is intentional. Proving it will be another matter.
Proving it is going to be nearly impossible. At around the time the iPhone came out, Apple gave all its employees iPhones. There were "recycle bins" all over the Apple campus where you would throw your non-Apple iPhones. Apple engineers did not see or, largely, interact with, other phones at all.
I think this was a mistake on Apple's part, and I brought it up with the exec team at the time, since it meant that none of the engineers got to see what competitors were doing wrong relative to Apple, and vice versa, so that Apple could improve its products where the competitors were better. That's mostly because there was no acknowledgement that competitors could be better in any fashion, and for a long time, that was in fact true. At the time the iPhone was introduced, it was the best damn mobile phone ever produced by anyone, and all the bitching about a lack of MS Exchange integration and a physical Blackberry-like keyboard didn't stop Microsoft employees from buying the things in droves, and didn't stop Blackberry from basically tanking in the marketplace because it was non-competitive.
For there to have been malice, or even intent, involved in the design decisions, you'd have to show that they were even considering something other than the user experience of "Hey! I don't have to pay the global average price of $0.11 per message if we both have iPhones!". To do that, they'd have to have something other than iPhones in hand, and they'd have to consider people replacing iPhones with something else in a context of something other than "What can we do to surprise and delight this unhappy customer enough to win them back as a customer?".
The bottom line is that it's a blind spot, and it was encouraged as one by the internal culture of Apple, both in terms of engineering and marketing. Why consider engineering constraints other than those right in front of you, that's how Facebook and Google work, right? If we end up in a hole, why, we'll just iterate ourselves out of it, since there have to be small evolutionary steps between a mistake and a great product, right?
Apple has a history of screwing up rather spectacularly, in was which mostly don't matter to most customers, but really cut off future avenues of products, product add-ons, functional expansion, and so on. There's a reason that the "X" in "XML" doesn't actually mean "eXtensible" when it comes to your iTunes library, and that's part of the mistake in tying in the data model behind CoreData to the implementation so strongly that iTunes loses its cookies and rebuilds your music database if you try.
Again, it's a cultural blind spot ("Why would any software other than iTunes need to access the iTunes library? Why wouldn't you just use iTunes?"). IMO, this suit will cost a lot of money, get settled to make it go away, and change nothing.
"Not really my job to give them a personally clue"
It is your job to stop lying about people doing the wrong thing when faced with evidence that they did in fact do the things that you say they were stupid not to do.
The canonically correct way to deal with this is to disable iMessage for your phone number on your iPhone *before* you switch to another phone. I've already stated that this is potentially problematic if you drop your iPhone in a toilet, and then buy a different phone than an iPhone to replace it, and never disengage in this specific way. Everything else is a workaround. That his friends with iPhones are still sending via iMessage because his # hasn't been taken out of the back end database (by him) is not "evidence" that he's correctly removed his number from the iMessage service database, it is in fact evidence that he has *not* done so.
As an IT Architect, who daily works with and for those with varying degrees of technical skills, I would disagree that the user is "an idiot". The steps you mention will certainly address the issue no doubt. What is in question is if the layperson should be aware of these steps and be capable of undertaking them "if" they forget to disable iMessage. What a class action lawsuit will do is force Apple to put in checks that look at the IMEI of the phone each time an iMessage is sent and the ack isn't received by the server from the phone in x amount of time. There is a different error message for an IMEI either offline or registered to a new user than one where the phone is simply unavailable. I can think of 5 different ways Apple can identify the device changed to a non Apple device. They haven't fixed this issue on purpose.
Messages sent via iMessage are not sent that way on the carrier back end, they are sent on the phone, via the data connection, and the IMEI or ESN/MEID is not generally sent, as it would have to be pulled out and sent in-band as part of the message in a framed header for the message on the iPhone. This would require both a software update on the iPhone, and a software update on the back end iMessage service.
Given that the iMessage service predates the current generation of iPhones, and therefore the older iPhones will not be receiving a software update, as they are incapable of running the newest version of iOS, this is not a possibility for those phones, and not a possibility to automatically deal with the issue (not to mention that the Apple ID registration on the back end would have to record both the IMEI or ESN/MEID, and for GSM, the IMSI and ICCID.
If you just switched your number over to another carrier, you are pretty much screwed without the carrier information as well, especially if the rest of the information stays the same, since the sending phone has no way in heck of knowing that that the target #'s SIM has been inserted into another phone with a different IMEI, and it's not like the Android phone is going to contact the Apple back end, and tell them about it.
There just aren't the notifications necessary from the non-iMessage enabled phone: it's a manual process at that point.
As I stated in the response to the other poster above, the carriers have basically zero incentive to cooperate by providing additional notifications in a post-switch scenario, since iMessage, like WhatsApp, undercuts their primary revenue model.
I suspect that we will be seeing the same thing with WhatsApp users who similarly undercut the carrier business model, in a way that's almost identical to the way iMessage does, but is not limited to iPhones.
Why don't you reply to this post because that person seems to have tried to unsubscribe from iMessage.
Not really my job to give them a personally clue, above and beyond the above posting, especially since they are posting AC, and I therefore can't contact them to help them directly work around whatever it is they are functionally failing to do. As an AC, there's really no way to have a conversation person to person about it.
I have an iphone. I never turned on any setting related to imessages. I still received imessages from other iphone users and would be pretty annoyed if the communication failed because of switching to a new phone.
It's turned on by default if you set up iCloud services, which people generally do to sync their address book, apps, and other content via "the cloud". That in turn is tuned on by default if you have push notifications turned on at all (which requires an Apple ID, and is how iMessage notifications happen, generally quicker than SMS notifications over the cellular providers networks (and the carrier bridge, if the sender and recipient aren't subscribed with the same carrier in the same geographic region).
Not only that, they is no indication that messages aren't being delivered.
There's a visual indicator on the sender's phone of a green vs. a blue "talk bubble" background color to indicate something sent via iMessage vs. SMS. Yeah, this isn't terrifically called out.
The notification will occur after the 45 days have elapsed (actually, it depends on when they run the batch job; it's generally 28 days +/- 14 days). But yeah, the notification is internal to the system.
I'll note for the record that SMS message delivery is also not acknowledged, so SMS messages, like iMessage messages, are pretty much like UDP datagrams, no matter how you slice things.
Poor setup on Apples part and clearly designed to hook people in.
I think it was more a cultural blind spot; in order to anticipate this being a problem, they'd have to consider the idea that someone might want to use a phone other than an iPhone, which is kind of unthinkable if you are an engineer whose livelihood is tied to building iPhone services... "Why in heck would anyone want to use software other than the software I wrote, which is the niftiest software evar?".
They have a settings mechanism on the iPhone that would take care of this, but if you dropped your iPhone in a toilet and killed it, you wouldn't be able to use that if instead of buying a replacement iPhone, ho used something else.
There's the online mechanism via appleid.apple.com, as previously noted, but I think that's a workaround. For number portability to another phone, which generally comes with a carrier contract and a new SIM (or a CDMA ID), they'd get the notification through the phone number portability act due to the carrier contract (this is half the source of the 45 days for the automatic cutover), but slamming the SIM around between phones that are iPhones and non-iPhones, there's really no network notifications that take place back to Apple that the change has occurred.
One possible workaround, and I will bet it's the one that gets put in place, should this suit be considered to have merit, rather than being a user error (it's definitely a user error, and Apple isn't really responsible for third party equipment not having the notification back to the Apple ID to dissociate it) would be to note failure to contact on the iMessage sends more promptly, and, worst case secondary settlement, probably retransmit them via SMS gateway.
This last is unlikely to happen, since it'd need to forge the source address as the original senders phone #, rather than the gateway, which would require additional agreements with all the carriers. I'm going to guess that the carriers won't be very cooperative in this, since they made about $10B last year in SMS charges worldwide, which is why Facebook was willing to pay $19B for "WhatsApp". Why cooperate with someone who is trying to disrupt your business model and reduce your profits, after all?
The people sending you messages are not sending you SMS, they are sending you iMessages. They are sending to your contact phone number, and they have iMessage turned on to save them $$$ when sending texts to other people registered with iMessage.
Because you used to have an iPhone, and had also turned iMessage on, your phone number is in their database, and so when it's deciding what data channel to use, it looks up the phone number it's about to send to, and if it's listed in the iMessage database, it sends an iMessage to the associated AppleID instead of sending an SMS via the cellular network. This way it doesn't cost them SMS $$$ to send the message.
When you pulled the SIM from your iPhone, you stupidly failed to turn off iMessage in your settings, and then sync those settings back to the iCloud. As this knowledge base article indicates, it can therefore take up to 45 days before it starts using SMS again: http://support.apple.com/kb/TS...
Alternately, you can go to http://appleid.apple.com/ and log in with your Apple ID, and manage your account, and disable iMessage that way (typically by removing your mobile phone number, and if you don't have an land line, putting the number in for your (non-mobile) contact number instead.
Note: Once the message has been sent, either via iMessage, or SMS, from the originating phone, it's sent; you don't get a second shit. It's not like those messages are "stored up" in a system that's capable of sending SMS messages, since the decision was made on the senders iPhone, not on the back end server.
Basically, it boils down to the former iPhone user being an idiot about disengaging from the additional iPhone associated services that they opt'ed into.
But never fear, up to 45 days afterward, the switch will happen automatically, as iMessage feeds back into the configuration database that the messages sent to the number have been undeliverable via iMessage. Or, you know, they could log onto http://appleid.apple.com/ now and fix it themselves, which can take up to 24 hours to take effect, because some idiot thought NoSQL was a good idea.
Here's my comment on the article:
I can understand the idea, even if he's done an incredibly poor job of explaining his position as to why he recommends it.
Tesla is moving towards leased battery pack exchange as a quick long range refueling strategy, and as a mechanism for dealing with battery life expectancy based on number of charge cycles.
This model would be helpful to the adoption of electric vehicles from both Tesla, other vendors, as viable alternatives to hydrocarbon fuel vehicles, but that assumes that there is wide adoption of their "razor blade" design, and that in turn is dependent on them not having a monopoly, or design-favored market advantage by being in competition with their customers.
The problem is that Tesla has invented the sealed battery rechargeable flashlight already, and now that they've firmly pointed out that a market exists for flashlights, they are in the process of inventing flashlights with replaceable batteries, at the same time they are inventing "D" batteries.
The market for "D" batteries is going to be *much* larger than the market for Tesla brand flashlights.
The risk on the battery side is that someone else might come in and build a better "D" battery, while the risk on the car side is that someone might come in and build a commodity flashlight that takes "D" batteries, and vastly undercut the price of a Tesla manufactured one.
I think that the range/recharge issue is very real, particularly in dense urban areas where you have street parking for the most part (San Francisco, Seattle, etc.), where the range is less of an issue -- IFF you are able to charge when you need to, instead of trying to run an extension cord from your apartment, down sig stories, and two blocks away to the curb where you were able to find a parking spot.
Part of the value in a battery position, however, is based on establishing the "service station" company owned vertical market integration model up front, which is likely something that would need to be funded by something like bonds, given the extreme costs involved in making such things ubiquitous, even on a franchise basis.
But overall, it's like going back in time and asking Apple if they want to sell software or hardware, when Apple sold computers - the integrated aggregate of both - and I think this would be a hard case to make to Musk, who doesn't sell batteries or cars, he sells transportation.
I seriously believe my point has been missed.
Even if you work your ass off, it's not going to bring back your blue collar job from overseas.
Even in a technical field, working your ass off is not automatically rewarded, unless you *ask* for more rewards, and even then, with a verbal agreement in place, you can end up not getting the promised rewards.
You have exactly the same "risk" of children believing the world works, automatically, to reward hard work, as you do having them believe the world works, automatically, to reward intelligence. There is absolutely *nothing* automatic about it.
"I'm worried about somebody taking my stuff while I'm gone."
"SHOOT THEM."
Good job.
Don't be intentionally dense... you shoot them *before* you leave.
Don't praise kids for being smart, it becomes a major part of their identity and whenever some situation comes along that they fail to resolve it can mess them up and they will avoid even attempting things that can result in them feeling not smart. Praise them for working hard, etc.
Don't praise kids for working hard, it becomes a major part of their identity and whenever some situation comes along that they fail to resolve it can mess them up and they will avoid even attempting things that can result in them feeling they are not working hard enough. You know, like when they find out that "work hard, and the rewards will follow" is a lie told to get them to work hard with the promise of a future reward which never materializes.
Long-lived roads are too labor and time intensive to build.
Germany seems to manage. But then again, they put their road work out to bid, and generally award the contract to whoever offers the longest warranty. If the state itself is doing the work, they don't have to compete on price or labor efficiency, and it's in the best interests of the people doing the work to consider their future employment options by doing a crappy job, similar to Wally's "I'm going to write myself a minivan!" reaction to the announcement of a "bug bounty" in the Dilbert comic strip.
There's a reason why the joke "The shortest distance between any two points is under construction" is not really that funny in California.
are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript ?
Do you even have to ask? Do you never go out on the internet?
ALL websites are more loaded than last year in JavaScript, and this is not a new trend. GMail was just pioneering (in the webmail space that is) the webapp that has only one page and everything you do is driven by JavaScript and the DOM.
Actually, I *do* have to ask. One of Googles blind spots in doing very active UI's with JavaScript is the fundamental assumption that everyone has the same RTT you do, sitting on Google's fiber optic backbone, and that you have very high bandwidth to go with that. Not all companies developing web sites have that blind spot, and I think that it contributes significantly to Google's willingness to make certain assumptions.
I'd say that, other than companies that obviously aren't going to go anywhere, Google has probably *the* singly heaviest browser computation and bandwidth loading of an of the top 20 web sites out there.
So again: I'd really like to know what actually drove the decision to do this work, and whether it was an externality. Thanks.
Additional benchmarks for Safari with this technology vs. Chrome with its JavaScript acceleration would be appreciated; is this a closing of the speed gap, a move ahead, or a lateral move (i.e. faster in some areas than Chrome, slower in others)?
Also: the purpose Chrome has had in adopting JavaScript acceleration is that Google's web properties are JavaScript heavy, and accelerating JavaScript gives them a better overall user experience for Google Docs, GMail, and similar Google products. Was this a "compete with Chrome" move, or are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript, and so it was necessary without the Chrome pressure because of widespread increases in JavaScript overhead on average pages?
I have a really hard time caring about "up to 100 watts of power depending on the cable version", mostly because of the "depending on the cable version" part of the statement.
How is this different from DVI, which much or might not have multichannel audio, might or might not be analog, might or might not support 5 channel digital sound, etc., etc.?
One thing Thunderbolt has going for it is that a cable is a cable, and you don't have to worry about it. If you want negotiated power supplied over USB, fine, but don't make me search my cardboard box for the "most sincere USB 3.1 cable". Thanks.
In the "good" old days, there was mods, maps, map editors.
“You Have Died of Dysentery”
Oh. You mean "the good old - but not quite *that* old - days"...
The first half of that (very common) statement is unproven and in most cases demonstrably false. The second half, also very common hard right wing propaganda, is an issue on which there can be reasonable disagreement but is not in any form a "given truth" and even at best ignores the history of teacher unionization from 1920. So, not very good marks to your (presumably private school?) history and political science teachers.
sPh
Vint Cerf - Vinton F'ing Cerf - was not allowed to fill in for his kids schools CS teacher for a couple of months while the teacher was unable to teach.
The reason for this was that Vinton F'ing Cerf did not have a California teacher certification to prove he knew how to teach computer science. Clearly unqualified, after having invented the F'ing Internet.
That's kind of not allowing Edison to teach a introductory science class about electricity.
I have yet to see a local cyclist perform a proper track stand and accelerate properly when a light turns green. If one watches professional cyclists one will see that one must use the rocking from side to side motion when coming out of a track stand to accelerate to high speeds. I had mastered this move when I used to ride 250 miles a week in my twenties. Cyclists should get licenses to ride on the roads just like automobile drivers.
It'd help if they at least got training. People who spend thousands of dollars on a bike, and zero dollars learning how to ride correctly are generally known as "Freds" among experienced cyclists. You can tell a "Fred" just by watching them ride or start from a stop (as yu note).