Sure, you're posting anonymously, but *I'm* cancer.

I get the sentiment, but there's absolutely no basis for what you're saying. There's no anti-trust issue because Apple isn't colluding with a bunch of other manufacturers to make sure they also do this.

There's no FCC issue because this isn't about denial of service or the phone going outside the bounds of what a cell phone is allowed to do in terms of broadcast strength and frequency.

There's no FTC issue because no one is forced to buy an Apple phone and there's no end-user expectation of being able to replace the battery on an Apple phone (which customers know when they buy it). If the FTC were going to get involved in this in any way, they already would have come down on printer manufacturers like a ton of bricks long ago, since they've been running similar toner and inject cartridge scams for years and years. Unless the batteries are exploding or have an unreasonably short lifetime compared to similar products, the FTC doesn't give a shit about whether you can replace them.

I get that it feels super-unfair, but the fact is this is a case where you just have to rely on market forces. Apple will just get shittier and shittier in this kind of behavior as long as people keep buying the phones. I don't and won't buy any Apple products. The only one I have in my home is a work-provided MacBook because I have to do software development and testing on it.

So sure, "fuck Apple", but don't expect the government to step in and fix something because you can't get Joe's Computer Shop to do something that Apple explicitly said only it could do. And before you make an argument that right to repair laws should let you do this, bear in mind that the consequences of installing dodgy high-capacity lithium batteries in phones has been widely demonstrated. All Apple has to do is say that they can't trust random repair shops to have sourced safe, reliable batteries and therefore not disabling the phone would present a danger to their users.

He's either a) using really bad terminology to ask why we're using rasteriszation over ray tracing techniques or b) using somewhat bad terminology to ask why we're using polygons over implicit surfaces. In both cases the answer is really the same.... modern GPU hardware is designed and optimized for doing lots of rasterization work using polygons, and it's a far more efficient use of the GPU hardware than either the use of implicit surfaces or ray tracing. Both ray tracing and the use of implicit surfaces to render a scene share the same problem at a low level. To process a given output pixel on the screen you have to have local knowledge of the *entire* scene that's being rendered, since a given ray or reflection could in theory bounce off any surface at all. Existing rasterization techniques don't have this problem, so while they produce less realistic scenes, they're far more efficient, meaning you can put more content in the scene and have a better overall end use experience.

Yes, thank god we've all converged on the clean, easy to understand x86 / x86_64 architecture.

CMake + Github is about as close as we have in C++ to Maven. Its still pretty ugly though, because C++ doesn't have a consistent build system and the number of options for building and linking is at least two orders of magnitude more than you have to deal with in Java.

Most software is obscure, full-stop. Just because you don't use most (or even any) of the packages on that page doesn't mean that Qt isn't a viable mainstream library, or that there's anything wrong with it.

Qt, like any other large framework, has a learning curve. If you're writing an application that works just fine using whatever libraries you're already using and you're only targeting one OS, then you probably aren't motivated to go climb that mountain. On the other hand if you're writing software (possibly with a complex UI) that is intended to target multiple operating systems, then Qt is probably the single best framework out there for doing so. Otherwise you're in for a long haul of writing your own less functional version of some subset of Qt features in order to abstract platform specific code away from the rest of your application functionality.

No one said that. They said that the price of NAND based storage will drop to be competitive with HDDs, but I suspect that there's an unspoken assumption there of HDDs staying static... in other words, NAND storage in a few years will be equivalent to the price per GB of HDDs now.

Even if NAND storage reaches price parity with HDDs, there will probably remain markets for both, since they have different performance behavior for the lifetime of the device, sine NAND cells will die over time. On the other hand, if the price drop is significant enough to make NAND approach optical media in terms of price per GB, we might see the return of cartridge based game consoles, and the death of long load times and waiting while the game is copied to the console internal HDD.

No matter how great your local storage is, you can't carry *all the media*, meaning that at some point you have to pick the subset of media you want and transfer it over the network. There's nothing wrong with that, but I suspect that for the vast majority of consumers being able to browse and choose content at the time of watching will always be more convenient than trying to anticipate everything you're going to want to watch.

*No form of money* has intrinsic value. The US doesn't create value if it prints more dollar bills, nor does the EU if they make more euros. The value that these units represent is mantained via artificial scarcity.

Because enough people haven't been bitten by this exact scenario yet for people to realize it's a basic requirement of any mediated market. Black and grey markets will likely be the last place such protections will pop up because the people populating the market are not bitcoin sophisticates, but rather fall largely into the criminals and drug aficionados categories.

Very much this.

The problem I have with this article is that it's basically pointing out a tautology. The kind of fusion created by slamming atoms together at high speed (in other words, high temperature fusion) can't be done at low temperatures. OK, but we have empirical evidence of other mechanisms for causing fusion.

Other forms of catalyzed fusion, if they exist, probably also require some pretty exotic physics, or we'd see lots of evidence of unusually high energy output in nature.

I understand this point of view, but on the other hand, I think that the VR killer app hasn't been found yet. The 'mainstream' equation works both ways. Sure there's a bigger potential customer base for VR apps running on Windows and OSX, but I think there's a bigger 'idea base' for new VR apps with hackers running Linux.

The Oculus SDK license specifically forbids using it to connect to non-Oculus hardware. On the other hand, they've recently released the full specs of the DK1 as open source, so it's now possible to legally build a piece of hardware that the SDK itself can't distinguish from the real thing. Hypothetically speaking, since the most recent version of the SDK relies on a runtime to communicate with the hardware, if you could spoof the runtime communication (which happens over a socket) then you could use any IMU you want to at all, as long as you replicated the mechanism that the runtime uses to send tracking data to a Rift enabled application. This is probably a violation of SDK / Runtime the license, but if you do a clean-room reverse engineering of the runtime you might be ok? IANAL.

Thank Captain Hindsight. Sure, technically anybody could have done it. But no one else actually did it, despite the numerous Linux developers complaining about the total lack of positional support for them. It's pretty easy to look at someone else's work and say "Oh, yeah, that's obvious" once they've actually done it. I don't really see why you've bothered commenting since you seem to be of the opinion that the entire exercise was pointless. If you don't buy into the entire premise of the article how can you be bothered to have an opinion of whether one of the participants in the work received proper credit?

Never mind. They've corrected the article.