The first and largest is that the Kinect is a product differentiater. It makes the XBone different from the PS4. There really isn't that much a difference between the two boxes otherwise. Fine, you can go on with the technical differences between the types of RAM and the custom silicon for the XBone's APU but those are not large concerns for Mom and Dad buying little Sally's birthday present.
Until MS comes up with something besides the software that makes their product different, the Kinect is going to hang on. But the second that happens, it'll be tossed. They know they've screwed the pooch here. They know exactly what it cost them in terms of customer relations and in terms of developers.
My friend has an Xbone. It turns out Kinect is what caused his WIFE to monopolize it. Yes, his wife took over the Xbone. Playing Just Dance 2014, Kinect Fitness and other Kinect games.
Enough so it's hard to get him on his Xbone. (And apparently, his youngest kids are all seeing mom dance and doing it themselves. And no, he's responsible - they take their kids outside to play which is why his Xbone gaming time is limited - they purposely want to keep their kids from getting addicted so they only play normal games when the kids are in bed).
Apparently they also really, really, really like Skype on it - the Kinect "zooms" in on the person speaking.
Of course, a popular peripheral for the PS4 is the camera - which if it isn't used to stream amateur porn shows on twitch...).
I have both, and find myself playing the Xbone a lot more than my PS4 - the camera's just so-so ($60 for what amounts to two $10 720p webcams...), and PS4 controller battery life is atrocious.
The only really bad thing is, on the PS4, I'm not buying games on it - I'm just waiting for them to show up on PS+. I did buy two games, though, but those were on ridiculous sale.
And no, the "p"s don't matter to me - because I end up playing PS4 using my Vita and remote play - about the best feature the PS4 has over the Xbone. But it also means the p's don't matter because ou're just squishing it down to quarter-FHD (540p) for display on the Vita screen.
Sufficient to understand, that the underlying concept of UPnP is an abomination; a sick and distorted concept that deserves nothing less than an immediate death sentence, and to be buried along with The Funniest Joke In The World; never to be resurrected again.
So how do you propose that my game on a machine on NAT arranges to receive UDP through the firewall? I'm supposed to manually configure firewall rules for each game? And then change them all if my IP changes?
Suffice it to say, most games don't need UPnP nor special firewall configuration.
Thanks to techniques like STUN, NAT traversal is made simple. For the most part, most NATs appear as "STUN Open" which mean a little trickery on the developer ensures two NATs can connect to each other. Of course, it requires an external matchmaking server, but those tend to be used anyhow for discovery.
I know I never had to do anything on my router (other than disable UPnP and all that) and I still can play via PSN and Xbox Live, and Steam, etc.
And I haven't had to touch firewall port settings in ages - usually just at the beginning to map in services like SSH and whatnot.
IPv6
Sorry, IPv6 isn't magic. In fact, you're probably going to run into even MORE connectivity issues with IPv6 than IPv4+NAT. Why? Because guess what? Practically all IPv6 endpoints are going to be firewalled by a gateway device. So you still have to create firewall rules (oh, and good luck when the IP changes either by prefix or when it's auto-generated!) to let your game/etc pass. And we'll be back to the same old troubles of spending hours debugging because someone's firewall isn't behaving.
So I'm guessing we're still going to need STUN to get through IPv6 firewalling.
And that's the problem with IPv6 - you still end up with the same headaches, multiplied because debugging is now made much harder (you can ping your IPv6 gateway? Good. That means absolutely zip because it could be using the default link-local route and address over the global prefix).
IPv4+NAT is nasty, but it works, and is easily understood compared to IPv6. NAT also has the nice side effect of isolating internal network addressing from external, so should prefixes and such change, nothing bad happens and things don't need sudden reconfiguration because of it (firewall settings ossify - if your prefix hasn't changed in a couple of years, when it does and things break, it's a huge PITA to re-find where everything is again).
Of course, those arguing for "purity" of IPv6 probably hold back development of stuff like NAT-PT and other things that could've had us on IPv6 years earlier.
However if there is a case their may be an unnatural bias. Say for video game, most of the games played professionally are targeted towards male players.
Perhaps. Though another thing is well, boorishness. I believe people were interviewed on it and someone unwisely said "Sexual harassment is part of Street Fighter culture. You can't take that away".
Well, gee, perhaps it's now obvious why e-sports are 90% males, because they creep the rest of the players out.
And then you wonder why the general public feels games are for kids - because the people they see playing on TV act like kids. They may have adult bodies (the average age of gamers is around 34), but damn, they're completely immature. Which leads to an unfortunate conclusion that "gamers" are all stereotypically kids and shouldn't be taken seriously.
Given the openness of SteamOS - I'm guessing the side effect would be to develop anti-VAC kernel modules to fool VAC into thinking everything's sane and good even if the user is cheating to heck and back (and unless VAC is using a kernel module, it's pretty hard to protect against it...).
I mean, should Valve/Steam pull this off in the future, it's trivially simple for something the user puts on SteamOS to hide the DNS resolver cache, to hide the cheat processes and fake the file hashes from any process...
Given how one of the main points of SteamOS is it's openness - does it make sense to have VAC on it?
I mean, it's a LOT easier to make a Linux kernel module that finds out what the VAC (or Steam) processes are, then having the kernel module modify responses to hide stuff from it.
I mean, lets say you have an aimbot or other cheat. You can run it on SteamOS, and have the kernel module hide that process (or even the fact network packets are redirected through it) so VAC can't even run anymore.
And I don't see VAC as a kernel module as every component in SteamOS is supposed to be replaceable so even compiling a new kernel is an option.
So I guess the question is - how is Valve protecting against SteamOS cheaters? It's a lot harder to do it on Windows since you have to do a lot of hooking and kernel signing and all that (plus trusting random binaries), whereas on Linux it's way easier to hook things.
iPhones and iPads make Apple an obscene amount of money and they are in a controlling position in the market. It should go without saying that they don't have "a deep desire to move away" from them. Add new product categories? Sure. Move away from iPhones and iPads? Nope.
No, but they realize that while the cash cow is iStuff, it won't be that way forever. Because just a little over 5 years ago, the cash cow was... iPods. Now iPods sell even less than Macs.
Oh yeah, 5 years before THAT, the hot cash cow was Macs.
The impetus is on Apple to find a new cash cow because it's obvious that iPhones and iPads aren't going to be generating the profits they used to.
The smartphone market is maturing, and the writing's on the wall - the money is still there, but it's diminishing. It's why everyone is trying everything to see what would stick. Like smart watches.
Apple knows the money from iPads and iPhones is drying up. They're looking for the next big thing because it's corporate suicide to keep relying on the old.
And one thing Apple does know - if the next big thing ends up hurting the iPad and iPhone sales, so be it - cannibalization will happen, sooner or later. better to embrace it than suffer from competitors eating you. (This happened with iPads - the low end Mac sales have deteriorated as people realized iPads suit them better than a low end Mac. Likewise, iPhones have pretty much killed the iPod).
Are you/the article saying that it is possible to have a single connection to your ISP, but for every computer, fridge, toaster, TV, etc. to have its own global IP address?
Yes, that is exactly how IPv6 is supposed to work.
And this is where fundamental assumption #1 of IPv6 falls flat. Even with IPv6, every endpoint will not be reachable.
This is the age of firewalls and all that (and even NAT provides a very basic level of firewalling). There's no guarantee that despite an endpoint having a publicly available address that it'll be reachable. Even today if a company has dozens of public IPv4 addresses for hosts, there's no guarantee that it'll be accessible.
Which means everything still breaks just as if NAT was present.
Even if IPv6 took the world over by storm, firewalls will still be around breaking connectivity. Even worse than NAT, you can't easily detect this condition. You might have a publicly visible address, but the firewall prevents you from establishing a connection. Or you may bind a port to serve something and the firewall blocks access.
In fact, the early days of NAT had those problems, but these days it's largely mitigated because of many techniques.
Possibly, but not necessarily even that. You could be set up to simply automatically generate IPv6 addresses from your MACs, and the ISP doesn't even explicitly grant you an address block.
But it may decide that you get a static IP and firewalls everything else off. E.g., even though you're advertised a/64, your ISP may filter out everything but <prefix>::1. If you ask for another "IP", because ISPs love to sell you more, they'll just hand you another prefix.
And finally, the biggest hurdle for IPv6 is NAT. Because NAT has a very nice side effect if you're maintaining a network of any size - it isolates internal network numbering for external network numbering. It doesn't matter what IP your ISP hands you for IPv4 - because NAT automatically hides it from internal clients. All they need to know is if they can see the router and magic happens.
With IPv6, you lose this handy feature - your ISP decides to change your prefix? Well, damn, they haven't done that in 5 years and now everything has been hardcoded with the old prefix in it - all your internal services used it.
flush the dns cache before you launch steam: on a mac that command is: sudo killall -HUP mDNSResponder
Except, mDNSResponder isn't a DNS cache. It's the multicast (hence "m") DNS server used by Bonjour/ZeroConfig.
It has zip to do with DNS caching other than storing what services are being made available on your machine to your network. It binds on a multicast IP.
Um, yes. In order to actually operate a Kickstarter project, you are required to give them details of an Amazon account. They only accept and transfer money via Amazon.
No, they use Amazon PAYMENTS, which while requiring an Amazon account, does not need the originating site to know it.
What happens is KickStarter forwards your pledge amount to Amazon. Amazon then asks you to log in and find out your method of payment and all that. It then gives the site back a payment token. Kickstarter uses that payment token to withdraw against the authorized amount (up to the limit which you agreed to when you agreed to the payment - Amazon knows it from the originating site and displays it to you so no shenanigans can take place).
So no, Kickstarter does not know your Amazon account information. Of course, for a lot of people, their Kickstarter login email is the same as their Amazon login...
And the Music industry isn't in a position to take on Google and Itunes and Amazon. Those three companies decide not to sell your crap-music, at your crap-prices, and you are pretty much dead in the water as a label.
Together, no. But individually, yes.
When iTunes was the only provider around and calling the shots, the music industry was afraid. Very afraid. So much so they cut Amazon a very sweetheart deal - sell music, but DRM-free, in an attempt to break up the grip iTunes had on digital distribution. It's why Apple had to cave and allow $1.29 tracks in order to get DRM-free music - Apple knows they no longer have pull with the industry with Amazon in the picture. And with two players, the industry can play each off each other.
Adding in Google Music, well, that's just a bonus topping - ensuring the music industry calls the shots, not Apple, Google nor Amazon. Because they'll be more busy competing with each other than trying o squeeze the industry.
The movie industry has seen what happened and it's why they're cutting deals with Netflix, Hulu, Vudu, Amazon, etc. But, in a twist, they're not allowing one service to "have it all" - they're ensuring content is distributed amongst all the players - if one gets too big, they cut back on its content and give it to someone else in the meantime.
I often have to encode videos to send to a few people. Most are computer-illiterate, and it needs to "just work". So I use H264 in Quicktime.mov, because most users have Macs, and those who have Windows definitely have Quicktime installed. I guess.m4v might also work as a container, except it doesn't have a timecode track.
But for the codec, is there a realistic alternative to H264 today? A format which can fit a feature-length HD movie in high quality in a file under 4GB so that it fits on any USB stick including FAT32, and that anyone can read?
m4v is the same as mp4 and a subset of the full QuickTime MOV format. (3gp is a subset of mp4). Apple promoted the use of the MOV format to the MPEG group. And MOV definitely has a timecode track (tmcd atom).
Though, you may want to investigate using Handbrake and other encoders like x264. You can choose your quality settings to find one that gets your video to the right size you want. If you have a hard 4GB limit, many frontends (like Handbrake) even offer the ability to adjust the quality to achieve the file size.
Who the hell goes to the Olympics with untested gear, just hoping it will work?
I thought the cool thing was to release stuff as "beta" into production and let the users test it live, so you can make improvements with real world usage, rather than finish the design and test and fix and finally go with a final product.
Everything, including Olympic equipment, is a beta test scenario now.
I agree the kid deserves compensation, and the company deserves to be slapped hard as an example to others, but I *seriously* doubt $100,000 is the going rate for a single image by even a top-tier professional photographer.
Well, technically it could be future licensing fees PLUS copyright infringement fees.
Remember, as photographer, he owns the copyright to the photos. The fact that the photos were pirated does entitle him to claim copyright infringement. Especially since they were used in ways to make profit.
Lets face it, sysV init is complicated. Well, the theory behind the old linear start from init script 00 and move to init script 99 isn't, but the modern implementations and the scripts themselves are complicated. I mean you're doing dependency checking and a whole bunch of other things in bash scripts. Compare that to a systemd service file, which is overall nice and readable. So, part of it is factoring out the logic from the variables. The other big thing is bash and the tools used by init scripts are like using a sledgehammer to tap in a finishing nail.
I'm not going to say that systemd is perfect. I like the "unix" way which is to use small units that do one thing well instead of anything. That's part of the reason I see bash init scripts as too much for the job. Unfortunately, the systemd authors look like they want to throw in everything but the kitchen sink. Well, everything that they can't just port to kernel space that is. But that's the thing, Linux is a Monolithic kernel. Like it or not, the "Linux" way is to have one uber optimized thing with modules to handle everything.
Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels. Enough so that switching levels is fraught with danger - you can probably start at level 1 (single user), and switch to 3, 4, or 5. Maybe you can get back to 1 because the extra demons get killed. Maybe.
In the end, it's bit of a maintenance hassle, and while completely understandable, it's a nightmare.
In fact, I'm guessing most utilities don't even bother handling the case - you just reboot and forget about it.
After all, computers are good at doing stuff automatically - so stuff like maintaining which services should run at which runlevels should be automated - the init can figure out what it needs to start, what it needs to kill and the order based on dependencies. All the user needs to do is select what needs to run at what runlevel, and the tool does the rest.
Then there are the various hacks to SysV - PID files (if so many tools need to know the daemon PID, why not have init actually do that work than requiring every script to do it manually?), the fact that state tracking isn't really in the system, and if you need services to relaunch on failure within limits, there ought to be a way to do it without requiring a trip to/etc/inittab to specify that fact.
why people are not using secure comms. No one should be using FTP for anything anymore except maybe internally. All Internet-facing servers and services should, by law, be forced to be encrypted. Enough of this cracking nonsense already. It's the same crap with MS and admin by default out of the box. As an IT guy, 95% of the malware out there could be stopped by not surfing the net with admin privileges. Are we all stupid? SSH, SSL, TLS, IKE, whatever you want to use, just use it already.
FTP is used by a lot of companies to send files. In fact, the #1 way to send files is email attachments. Followed by FTP. The first generally gets through, the second is also about the only protocol open by most corporate firewalls for outgoing connections. You can't count on ftps or sftp or ssh. Just ports 21, 80 and 443 being let out on the Internet.
FTP is a horrible protocol - it's not firewall friendly (even in passive mode), so most firewalls have an application-layer gateway module to handle it.
But it's also about the only way to get files reliabily sent and received by people in companies. Plus, people normally have to install zero software to do it. Everything else typically requires installation of software which requires going to corporate IT, etc. etc. etc.
The majority of people do not have facebook accounts. Oh, and here's another tip for you: your little circle jerk of facebook friends does not represent the real world.
Actually, Facebook gathers "shadow profiles" of people who don't have accounts but friends talk about anyways (and the information is "public" - so it's advantageous to create an account if nothing other than to mark it private).
And while the vast majority of the world doesn't have a Facebook account, the ones of interest to data miners do. If I wanted to market to people who had money, I don't care about the billions of people in third world countries who can't afford computers, nevermind get on Facebook.
More specifically, If I wanted to target the top 15% wealthiest people or so (about a billion), you can bet a good chunk of them are on Facebook. The rest? Well, they've got other problems that aren't of interest and not worth spending money marketing or getting data about.
Wrong. That's not what this agreement says. Android is still open and OEMs are free to build out AOSP with their own apps.
What this says is that if you take the Google apps, you must include the whole package under the terms specified. That's all.
Sooo many posts here written by people who didn't actually read the article.
Actually, if you sign the agreement to bundle Google apps, you're restricting in what you can release. If you want, you can release a vanilla AOSP phone. However, if you want to release a phone using AOSP that does things non-standard, you are not allowed to
That's what the anti-fragmentation part does. As long as the agreement is in place, regardless of whether or not your device is going to have Google apps, you're NOT allowed to fragment AOSP by doing things differently. Acer found out the hard way when they wanted to release that phone that had an Android compatibility layer - they weren't allowed to because they signed the agreement.
The thing is, the agreement's terms hold regardless of whether or not the device is to have Google Apps - it restricts what you can do with Android and Android-compatible products. SIgn it, and anything Android must be "official". In fact, if Microsoft were to add an Android layer to Windows 8, this could run afoul of all the Google app agreements, which means a bunch of OEMs may be prevented from releasing Windows Phone phones. Not that it really matters (Windows Phone marketshare is tiny, so OEMs may simply not bother releasing Windows Phone phones), but it is an interesting restraint.
Possible customers include anyone who doesn't follow mobile phone news very closely. Which is most people. Tech business news is not exactly gobbled up by the public. Most slashdotters won't buy, but mobile nerds aren't common. AND I might buy one if the hardware's nice enough and I can root it. What do I care about support for it if I can just install cyanogenmod?
The hardware's for emerging markets, one of Nokia's strong points.
It's not going to be "nice" hardware, it's going to be "cheap" hardware. The only reason to put Android on it is because Windows Phone has very specific hardware requirements, and they don't include low-end phones.
Of course, given that the Android low-end market is already saturated (most Android phones sold today are low-end, hence why Android outsells iOS 4-to-1 because people want free phones or ultra cheap sub-$100 phones off contract), I'm not sure how much Nokia expects to break into it - perhaps ultracheap phones that cost $30 or less? But even those have serious competition.
And yes, these phones will typically be even crappier than what carriers would be giving away in the US. Hell, maybe they'll use Android, but not expose the Android UI? Basically, use it to recapture some of the lost "featurephone" market that cheap Androids seem to be filling in for..
You mean they shouldn't have built it in China, that is. After all, the manufacturer saw that they could make a few extra bucks by using cheaper parts in it and pocketing the difference. Why bother using the expensive components they specify? Just substitute with cheaper ones - they won't know the difference and it's a few more dollars in the pocket.
Or perhaps they ripped off the design and produced a counterfeit part during the third shift?
Eggs is a good example. They where 'bad' becasue they had high cholesterol. Science move on, and it turns out there are different kind of cholesterol, some 'good' some 'bad' so now eggs aren't as unhealthy as was thought.
Fats, too. It was deemed that fats were bad for you, so instead of butter, use margarine. Better yet, skip the fats period. Bad for you.
Of course, it was also discovered that hydrogenation had a nasty habit of turning unsaturated fats into different chiral forms - "cis" and "trans". And guess what? The "trans" form of the fat is really, really, really bad for you (yes, that's the same "trans" in trans fats). Suddenly butter wasn't such an unreasonable option anymore as margarine as margarine had to undergo hydrogenation.
Not to mention the effort to go "low fat" has had nasty side effects of its own - the overuse of sugar and salt to replace the taste that fats had, resulting in even worse health problems (obesity, heart disease) than just having the fat to begin with.
(And no, banning trans fats doesn't mean they ban "yummy stuff" - there's plenty of fats you can cook with to still get the "yummy" without all the trans fats.)
What the NIF is all about is compressing D-T fuel by radiation pressure and finding out what kind of profile of the radiation pressure pulse has the highest yield. That's exactly what you do when you want to get a bigger bang out of the nuclear weapons you have, because your NATIONAL DICK isn't big enough yet to properly display your "patriotic" manlihood to the rest of the world that you feel like you have to dominate completely in order to feel like you've accomplished something.
What did you expect? The funding, building and research the NIF does is provided by the DoD. The primary interest IS to find ways to increase yield on weapons. The fact that the research can also be used towards civilian energy interests is a pleasant bonus.
Unfortunately, doing science like this has to be done under the auspices of other interests or it doesn't happen. Things like alternative fuels, climate change, etc., are happening under the DoD because of it. (Yes, climate studies are done because they're of vital interests to maintaining security. And alternative fuels as well as not having to rely on diesel trucked in has strategic interests - considering by the time it's all said and done, the fuel cost is around $400/gallon. Not counting lives lost)
Hell, any science done that isn't in a nation's interest is also cut. E.g., Canada cut funding to scientists with "inconvenient" topics (like pollution, fish habitat protection, environment, climate change) because they went against let's go sell oil around the world damn the earth mentality.
The trick with 'Android compatibility' is that it's really two different problems. One is merely engineering ('merely' in the 'may actually be quite difficult; but there are engineers that are quite smart, trying giving them money' sense) and one is strategic:
'Android' as in the ASOP is a mixture of GPL and Apache. Exactly how many man-hours it takes to get ASOP running on your platform, or Dalvik and friends running on your non-Linux kernel is an open question, and may end up being quite a few if you want it to work well; but there is nobody to stop you, and you just need suitably skilled software people.
Trouble is, much of the good stuff in 'Android' (and stuff that Google doesn't exactly discourage developers from using) isn't ASOP, it's Google Play Services, a set of proprietary applications, libraries, and Google-backed web servcies that can be bestowed or denied to your device at the power and mere pleasure of Team Mountain View. They tend to ignore indie ROM-cookers and two-bit pacific RIM clonemongers who quietly pirate GPS; but if a company large enough to target, or ambitious enough to try to cut deals with major carriers in markets Google cares about, tries to distribute GPS without Google's blessing, it's world-of-hurt time.
At a greater or lesser cost in software engineers, you could get an ASOP-compatible Android compatibility layer running on QNX, NT, OSX, whatever. However, how much that helps you is increasingly limited.
Or there's a third way.
You could try to do it Blackberry's way which is to integrate AOSP into the OS so you can run Android apps mostly unmodified, just repackaged.
Or you can put the compatibility into the dev tools itself - parse the Android makefiles to figure out how to make it a Visual Studio solution, have compatibility DLLs and java compilers (Microsoft did, at one point make a Java compiler) with native compilers and libraries to handle the JNI hooks, so a good chunk of it is just load the source into Visual Studio and click Build. Out pops a native Windows Phone binary you can use.
And if Microsoft felt generous, they could make it so Android apps can be built from the same tree and out pops an APK. So if you write within Visual Studio, you get advantages of being able to code for both, and tweak stuff so Windows Phone apps integrate properly.
Heck, Microsoft can even emulate the Google Play Services APIs using their own - Bing Maps, etc.
Free market is a thing of the past. Today you don't buy and sell goods and compete with your competitor with quality and price, you buy and sell laws and compete in who can bribe more politicians.
No, a free market tends towards monopolies - it's the ultimate end game.
What you're describing as competition and such is just an idealized situation. It's how free markets SHOULD work. You know, like how communism SHOULD work. But like communism, there are unintended consequences, and the free market producing monopolies is one of them. It's based on simplistic assumptions that do not hold out in the real world (like competition can spring up instantly - it assumes there's nothing like "startup costs" which can be insane due to infrastructure requirements (e.g., if you want to build out a new cell carrier, it costs billions in equipment, land leases, etc. Assuming no interference from competition)).
We try to fix this through regulations (commonly known as "red tape" and "bureaucracy" to those who advocate less rules and smaller government) to try to steer towards competition and away from monopoly.
iTunes/iCloud is NOT a valid solution since it resides in the 'cloud' and Bucc5062 specifically stated that "I did not want to store files in the greater 'cloud'"!
iTunes is a valid solution. You can disable iCloud. Turn on WiFi sync and the moment you plug in your iPhone, it'll connect to to WiFi to your PC running iTunes and sync/backup.
iTunes and iCloud are separate products. You can turn off iCloud completely and it won't sync at all, nor backup to the cloud, but instead to the local iTunes PC.
The only downside is well, iTunes. But WiFI sync works and is fairly transparent. Though some people I know have issues, and if your WiFI is spotty, it can also fail.
No. The network will never approve these transactions. My understanding of the problem is that exchange's use custom wallet software that can be fooled before enough confirmations come through potentially allowing an attacker to sell coins that don't exist for dollars. This has temporarily made bitcoin less liquid (as far as exchanging for country backed currencies) which has driven the price down.
The issue will likely be fixed by a combination of exchange software upgrade and, eventually, long term tweaks to the bitcoin protocol that will fix this type of attack.
No, the issue is that a bunch of fake but close-enough transactions are flooding the exchanges to de-sync them. They're trying to verify the transactions with the real blockchain, but in doing so, they fall behind, have to process a new batch of fake transactions and compare them against the real chain, etc.
Basically there's a point where the flood of fake transactions overwhelms the ability to figure out what's real and what's not. No extra money is being created unless the exchange follows the fake transactions. However, if you're trying to exchange money, it means your real transaction is now backlogged and the exchange can only get further behind as they sort out the mess.
It's like how a regular DDoS works - except the information being sent is fake and the server is bogging down under the load trying to figure out if it's real or not.
It's a classic resource starvation attack - each fake transaction consumes resources because it has to be verified against the real blockchain. But in the time to do that, more fake transactions come in so the server can do nothing but fall behind. And you intermix in real transactions which have to be processed properly as well.
I suppose a real life equivalent is a bank - where you have people trying to cash in fake cheques or exchange fake currency - it takes time to verify and fail the transaction, but even with all tellers open, there'll be a point where more people (legit and otherwise) arrive faster than they can handle so the lines get turned into crowds.
Slashdot Mirror
My friend has an Xbone. It turns out Kinect is what caused his WIFE to monopolize it. Yes, his wife took over the Xbone. Playing Just Dance 2014, Kinect Fitness and other Kinect games.
Enough so it's hard to get him on his Xbone. (And apparently, his youngest kids are all seeing mom dance and doing it themselves. And no, he's responsible - they take their kids outside to play which is why his Xbone gaming time is limited - they purposely want to keep their kids from getting addicted so they only play normal games when the kids are in bed).
Apparently they also really, really, really like Skype on it - the Kinect "zooms" in on the person speaking.
Of course, a popular peripheral for the PS4 is the camera - which if it isn't used to stream amateur porn shows on twitch...).
I have both, and find myself playing the Xbone a lot more than my PS4 - the camera's just so-so ($60 for what amounts to two $10 720p webcams...), and PS4 controller battery life is atrocious.
The only really bad thing is, on the PS4, I'm not buying games on it - I'm just waiting for them to show up on PS+. I did buy two games, though, but those were on ridiculous sale.
And no, the "p"s don't matter to me - because I end up playing PS4 using my Vita and remote play - about the best feature the PS4 has over the Xbone. But it also means the p's don't matter because ou're just squishing it down to quarter-FHD (540p) for display on the Vita screen.
Suffice it to say, most games don't need UPnP nor special firewall configuration.
Thanks to techniques like STUN, NAT traversal is made simple. For the most part, most NATs appear as "STUN Open" which mean a little trickery on the developer ensures two NATs can connect to each other. Of course, it requires an external matchmaking server, but those tend to be used anyhow for discovery.
I know I never had to do anything on my router (other than disable UPnP and all that) and I still can play via PSN and Xbox Live, and Steam, etc.
And I haven't had to touch firewall port settings in ages - usually just at the beginning to map in services like SSH and whatnot.
Sorry, IPv6 isn't magic. In fact, you're probably going to run into even MORE connectivity issues with IPv6 than IPv4+NAT. Why? Because guess what? Practically all IPv6 endpoints are going to be firewalled by a gateway device. So you still have to create firewall rules (oh, and good luck when the IP changes either by prefix or when it's auto-generated!) to let your game/etc pass. And we'll be back to the same old troubles of spending hours debugging because someone's firewall isn't behaving.
So I'm guessing we're still going to need STUN to get through IPv6 firewalling.
And that's the problem with IPv6 - you still end up with the same headaches, multiplied because debugging is now made much harder (you can ping your IPv6 gateway? Good. That means absolutely zip because it could be using the default link-local route and address over the global prefix).
IPv4+NAT is nasty, but it works, and is easily understood compared to IPv6. NAT also has the nice side effect of isolating internal network addressing from external, so should prefixes and such change, nothing bad happens and things don't need sudden reconfiguration because of it (firewall settings ossify - if your prefix hasn't changed in a couple of years, when it does and things break, it's a huge PITA to re-find where everything is again).
Of course, those arguing for "purity" of IPv6 probably hold back development of stuff like NAT-PT and other things that could've had us on IPv6 years earlier.
Perhaps. Though another thing is well, boorishness. I believe people were interviewed on it and someone unwisely said "Sexual harassment is part of Street Fighter culture. You can't take that away".
Well, gee, perhaps it's now obvious why e-sports are 90% males, because they creep the rest of the players out.
And then you wonder why the general public feels games are for kids - because the people they see playing on TV act like kids. They may have adult bodies (the average age of gamers is around 34), but damn, they're completely immature. Which leads to an unfortunate conclusion that "gamers" are all stereotypically kids and shouldn't be taken seriously.
Given the openness of SteamOS - I'm guessing the side effect would be to develop anti-VAC kernel modules to fool VAC into thinking everything's sane and good even if the user is cheating to heck and back (and unless VAC is using a kernel module, it's pretty hard to protect against it...).
I mean, should Valve/Steam pull this off in the future, it's trivially simple for something the user puts on SteamOS to hide the DNS resolver cache, to hide the cheat processes and fake the file hashes from any process...
Given how one of the main points of SteamOS is it's openness - does it make sense to have VAC on it?
I mean, it's a LOT easier to make a Linux kernel module that finds out what the VAC (or Steam) processes are, then having the kernel module modify responses to hide stuff from it.
I mean, lets say you have an aimbot or other cheat. You can run it on SteamOS, and have the kernel module hide that process (or even the fact network packets are redirected through it) so VAC can't even run anymore.
And I don't see VAC as a kernel module as every component in SteamOS is supposed to be replaceable so even compiling a new kernel is an option.
So I guess the question is - how is Valve protecting against SteamOS cheaters? It's a lot harder to do it on Windows since you have to do a lot of hooking and kernel signing and all that (plus trusting random binaries), whereas on Linux it's way easier to hook things.
No, but they realize that while the cash cow is iStuff, it won't be that way forever. Because just a little over 5 years ago, the cash cow was... iPods. Now iPods sell even less than Macs.
Oh yeah, 5 years before THAT, the hot cash cow was Macs.
The impetus is on Apple to find a new cash cow because it's obvious that iPhones and iPads aren't going to be generating the profits they used to.
The smartphone market is maturing, and the writing's on the wall - the money is still there, but it's diminishing. It's why everyone is trying everything to see what would stick. Like smart watches.
Apple knows the money from iPads and iPhones is drying up. They're looking for the next big thing because it's corporate suicide to keep relying on the old.
And one thing Apple does know - if the next big thing ends up hurting the iPad and iPhone sales, so be it - cannibalization will happen, sooner or later. better to embrace it than suffer from competitors eating you. (This happened with iPads - the low end Mac sales have deteriorated as people realized iPads suit them better than a low end Mac. Likewise, iPhones have pretty much killed the iPod).
And this is where fundamental assumption #1 of IPv6 falls flat. Even with IPv6, every endpoint will not be reachable.
This is the age of firewalls and all that (and even NAT provides a very basic level of firewalling). There's no guarantee that despite an endpoint having a publicly available address that it'll be reachable. Even today if a company has dozens of public IPv4 addresses for hosts, there's no guarantee that it'll be accessible.
Which means everything still breaks just as if NAT was present.
Even if IPv6 took the world over by storm, firewalls will still be around breaking connectivity. Even worse than NAT, you can't easily detect this condition. You might have a publicly visible address, but the firewall prevents you from establishing a connection. Or you may bind a port to serve something and the firewall blocks access.
In fact, the early days of NAT had those problems, but these days it's largely mitigated because of many techniques.
But it may decide that you get a static IP and firewalls everything else off. E.g., even though you're advertised a /64, your ISP may filter out everything but <prefix>::1. If you ask for another "IP", because ISPs love to sell you more, they'll just hand you another prefix.
And finally, the biggest hurdle for IPv6 is NAT. Because NAT has a very nice side effect if you're maintaining a network of any size - it isolates internal network numbering for external network numbering. It doesn't matter what IP your ISP hands you for IPv4 - because NAT automatically hides it from internal clients. All they need to know is if they can see the router and magic happens.
With IPv6, you lose this handy feature - your ISP decides to change your prefix? Well, damn, they haven't done that in 5 years and now everything has been hardcoded with the old prefix in it - all your internal services used it.
Except, mDNSResponder isn't a DNS cache. It's the multicast (hence "m") DNS server used by Bonjour/ZeroConfig.
It has zip to do with DNS caching other than storing what services are being made available on your machine to your network. It binds on a multicast IP.
No, they use Amazon PAYMENTS, which while requiring an Amazon account, does not need the originating site to know it.
What happens is KickStarter forwards your pledge amount to Amazon. Amazon then asks you to log in and find out your method of payment and all that. It then gives the site back a payment token. Kickstarter uses that payment token to withdraw against the authorized amount (up to the limit which you agreed to when you agreed to the payment - Amazon knows it from the originating site and displays it to you so no shenanigans can take place).
So no, Kickstarter does not know your Amazon account information. Of course, for a lot of people, their Kickstarter login email is the same as their Amazon login...
Together, no. But individually, yes.
When iTunes was the only provider around and calling the shots, the music industry was afraid. Very afraid. So much so they cut Amazon a very sweetheart deal - sell music, but DRM-free, in an attempt to break up the grip iTunes had on digital distribution. It's why Apple had to cave and allow $1.29 tracks in order to get DRM-free music - Apple knows they no longer have pull with the industry with Amazon in the picture. And with two players, the industry can play each off each other.
Adding in Google Music, well, that's just a bonus topping - ensuring the music industry calls the shots, not Apple, Google nor Amazon. Because they'll be more busy competing with each other than trying o squeeze the industry.
The movie industry has seen what happened and it's why they're cutting deals with Netflix, Hulu, Vudu, Amazon, etc. But, in a twist, they're not allowing one service to "have it all" - they're ensuring content is distributed amongst all the players - if one gets too big, they cut back on its content and give it to someone else in the meantime.
m4v is the same as mp4 and a subset of the full QuickTime MOV format. (3gp is a subset of mp4). Apple promoted the use of the MOV format to the MPEG group. And MOV definitely has a timecode track (tmcd atom).
Though, you may want to investigate using Handbrake and other encoders like x264. You can choose your quality settings to find one that gets your video to the right size you want. If you have a hard 4GB limit, many frontends (like Handbrake) even offer the ability to adjust the quality to achieve the file size.
I thought the cool thing was to release stuff as "beta" into production and let the users test it live, so you can make improvements with real world usage, rather than finish the design and test and fix and finally go with a final product.
Everything, including Olympic equipment, is a beta test scenario now.
Well, technically it could be future licensing fees PLUS copyright infringement fees.
Remember, as photographer, he owns the copyright to the photos. The fact that the photos were pirated does entitle him to claim copyright infringement. Especially since they were used in ways to make profit.
Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels. Enough so that switching levels is fraught with danger - you can probably start at level 1 (single user), and switch to 3, 4, or 5. Maybe you can get back to 1 because the extra demons get killed. Maybe.
In the end, it's bit of a maintenance hassle, and while completely understandable, it's a nightmare.
In fact, I'm guessing most utilities don't even bother handling the case - you just reboot and forget about it.
After all, computers are good at doing stuff automatically - so stuff like maintaining which services should run at which runlevels should be automated - the init can figure out what it needs to start, what it needs to kill and the order based on dependencies. All the user needs to do is select what needs to run at what runlevel, and the tool does the rest.
Then there are the various hacks to SysV - PID files (if so many tools need to know the daemon PID, why not have init actually do that work than requiring every script to do it manually?), the fact that state tracking isn't really in the system, and if you need services to relaunch on failure within limits, there ought to be a way to do it without requiring a trip to /etc/inittab to specify that fact.
FTP is used by a lot of companies to send files. In fact, the #1 way to send files is email attachments. Followed by FTP. The first generally gets through, the second is also about the only protocol open by most corporate firewalls for outgoing connections. You can't count on ftps or sftp or ssh. Just ports 21, 80 and 443 being let out on the Internet.
FTP is a horrible protocol - it's not firewall friendly (even in passive mode), so most firewalls have an application-layer gateway module to handle it.
But it's also about the only way to get files reliabily sent and received by people in companies. Plus, people normally have to install zero software to do it. Everything else typically requires installation of software which requires going to corporate IT, etc. etc. etc.
Actually, Facebook gathers "shadow profiles" of people who don't have accounts but friends talk about anyways (and the information is "public" - so it's advantageous to create an account if nothing other than to mark it private).
And while the vast majority of the world doesn't have a Facebook account, the ones of interest to data miners do. If I wanted to market to people who had money, I don't care about the billions of people in third world countries who can't afford computers, nevermind get on Facebook.
More specifically, If I wanted to target the top 15% wealthiest people or so (about a billion), you can bet a good chunk of them are on Facebook. The rest? Well, they've got other problems that aren't of interest and not worth spending money marketing or getting data about.
Actually, if you sign the agreement to bundle Google apps, you're restricting in what you can release. If you want, you can release a vanilla AOSP phone. However, if you want to release a phone using AOSP that does things non-standard, you are not allowed to
That's what the anti-fragmentation part does. As long as the agreement is in place, regardless of whether or not your device is going to have Google apps, you're NOT allowed to fragment AOSP by doing things differently. Acer found out the hard way when they wanted to release that phone that had an Android compatibility layer - they weren't allowed to because they signed the agreement.
The thing is, the agreement's terms hold regardless of whether or not the device is to have Google Apps - it restricts what you can do with Android and Android-compatible products. SIgn it, and anything Android must be "official". In fact, if Microsoft were to add an Android layer to Windows 8, this could run afoul of all the Google app agreements, which means a bunch of OEMs may be prevented from releasing Windows Phone phones. Not that it really matters (Windows Phone marketshare is tiny, so OEMs may simply not bother releasing Windows Phone phones), but it is an interesting restraint.
The hardware's for emerging markets, one of Nokia's strong points.
It's not going to be "nice" hardware, it's going to be "cheap" hardware. The only reason to put Android on it is because Windows Phone has very specific hardware requirements, and they don't include low-end phones.
Of course, given that the Android low-end market is already saturated (most Android phones sold today are low-end, hence why Android outsells iOS 4-to-1 because people want free phones or ultra cheap sub-$100 phones off contract), I'm not sure how much Nokia expects to break into it - perhaps ultracheap phones that cost $30 or less? But even those have serious competition.
And yes, these phones will typically be even crappier than what carriers would be giving away in the US. Hell, maybe they'll use Android, but not expose the Android UI? Basically, use it to recapture some of the lost "featurephone" market that cheap Androids seem to be filling in for..
You mean they shouldn't have built it in China, that is. After all, the manufacturer saw that they could make a few extra bucks by using cheaper parts in it and pocketing the difference. Why bother using the expensive components they specify? Just substitute with cheaper ones - they won't know the difference and it's a few more dollars in the pocket.
Or perhaps they ripped off the design and produced a counterfeit part during the third shift?
Fats, too. It was deemed that fats were bad for you, so instead of butter, use margarine. Better yet, skip the fats period. Bad for you.
Of course, it was also discovered that hydrogenation had a nasty habit of turning unsaturated fats into different chiral forms - "cis" and "trans". And guess what? The "trans" form of the fat is really, really, really bad for you (yes, that's the same "trans" in trans fats). Suddenly butter wasn't such an unreasonable option anymore as margarine as margarine had to undergo hydrogenation.
Not to mention the effort to go "low fat" has had nasty side effects of its own - the overuse of sugar and salt to replace the taste that fats had, resulting in even worse health problems (obesity, heart disease) than just having the fat to begin with.
(And no, banning trans fats doesn't mean they ban "yummy stuff" - there's plenty of fats you can cook with to still get the "yummy" without all the trans fats.)
What did you expect? The funding, building and research the NIF does is provided by the DoD. The primary interest IS to find ways to increase yield on weapons. The fact that the research can also be used towards civilian energy interests is a pleasant bonus.
Unfortunately, doing science like this has to be done under the auspices of other interests or it doesn't happen. Things like alternative fuels, climate change, etc., are happening under the DoD because of it. (Yes, climate studies are done because they're of vital interests to maintaining security. And alternative fuels as well as not having to rely on diesel trucked in has strategic interests - considering by the time it's all said and done, the fuel cost is around $400/gallon. Not counting lives lost)
Hell, any science done that isn't in a nation's interest is also cut. E.g., Canada cut funding to scientists with "inconvenient" topics (like pollution, fish habitat protection, environment, climate change) because they went against let's go sell oil around the world damn the earth mentality.
Or there's a third way.
You could try to do it Blackberry's way which is to integrate AOSP into the OS so you can run Android apps mostly unmodified, just repackaged.
Or you can put the compatibility into the dev tools itself - parse the Android makefiles to figure out how to make it a Visual Studio solution, have compatibility DLLs and java compilers (Microsoft did, at one point make a Java compiler) with native compilers and libraries to handle the JNI hooks, so a good chunk of it is just load the source into Visual Studio and click Build. Out pops a native Windows Phone binary you can use.
And if Microsoft felt generous, they could make it so Android apps can be built from the same tree and out pops an APK. So if you write within Visual Studio, you get advantages of being able to code for both, and tweak stuff so Windows Phone apps integrate properly.
Heck, Microsoft can even emulate the Google Play Services APIs using their own - Bing Maps, etc.
No, a free market tends towards monopolies - it's the ultimate end game.
What you're describing as competition and such is just an idealized situation. It's how free markets SHOULD work. You know, like how communism SHOULD work. But like communism, there are unintended consequences, and the free market producing monopolies is one of them. It's based on simplistic assumptions that do not hold out in the real world (like competition can spring up instantly - it assumes there's nothing like "startup costs" which can be insane due to infrastructure requirements (e.g., if you want to build out a new cell carrier, it costs billions in equipment, land leases, etc. Assuming no interference from competition)).
We try to fix this through regulations (commonly known as "red tape" and "bureaucracy" to those who advocate less rules and smaller government) to try to steer towards competition and away from monopoly.
iTunes is a valid solution. You can disable iCloud. Turn on WiFi sync and the moment you plug in your iPhone, it'll connect to to WiFi to your PC running iTunes and sync/backup.
iTunes and iCloud are separate products. You can turn off iCloud completely and it won't sync at all, nor backup to the cloud, but instead to the local iTunes PC.
The only downside is well, iTunes. But WiFI sync works and is fairly transparent. Though some people I know have issues, and if your WiFI is spotty, it can also fail.
No, the issue is that a bunch of fake but close-enough transactions are flooding the exchanges to de-sync them. They're trying to verify the transactions with the real blockchain, but in doing so, they fall behind, have to process a new batch of fake transactions and compare them against the real chain, etc.
Basically there's a point where the flood of fake transactions overwhelms the ability to figure out what's real and what's not. No extra money is being created unless the exchange follows the fake transactions. However, if you're trying to exchange money, it means your real transaction is now backlogged and the exchange can only get further behind as they sort out the mess.
It's like how a regular DDoS works - except the information being sent is fake and the server is bogging down under the load trying to figure out if it's real or not.
It's a classic resource starvation attack - each fake transaction consumes resources because it has to be verified against the real blockchain. But in the time to do that, more fake transactions come in so the server can do nothing but fall behind. And you intermix in real transactions which have to be processed properly as well.
I suppose a real life equivalent is a bank - where you have people trying to cash in fake cheques or exchange fake currency - it takes time to verify and fail the transaction, but even with all tellers open, there'll be a point where more people (legit and otherwise) arrive faster than they can handle so the lines get turned into crowds.