6) They said: We intended it to be an open controller,
Which is a flat out lie. If the thing should be "open" they would have released a spec, a Windows driver or at least XNA integration, not leave people without any help at all like they did.
As far as I know the skeleton detection is in the Xbox360, not in the Kinect. So at this point Kinect won't give you direct motion capture capabilities, as you would still have to process the depth data manually.
I think a large part of the problem is that gaming simply hasn't yet fully grown up, it is still to much stuck in mechanics that forces the player to overcome challenges before he gets access to later content. Adjustable difficulty settings lower the harm a bit, but they don't really remove it, as the last boss on easy might still be to hard for some people and even on easy you are still forced to play stuff you don't care about.
This is one of the reasons why I like simulations on the PC, they are generally free of any kind of forced challenge or unlockables. All the vehicles are available right from the start and when the game is to hard you can switch on unlimited ammunition, invincibility and other tricks, not by some obscure cheat, but by simply going to the option menu. Those games still provide enormous amounts of depths to the player, but they don't force it on the player via a fixed structure, everybody can enjoy them how he likes. Access to in-game developer console can often do similar things in regular games.
On consoles on the other side you don't have that, you might find some obscure cheats, but in general you have to play through all the challenges yourself to unlock the content. There are a few games that tried something new, I think Alone in the Dark allows you to select all chapters of the game right from the start without unlocking and Nintendo has its Super Guide that can take over control when the game gets to difficult, so hopefully more games will follow that trend and give the player the freedom to enjoy the game like he wants, not like the developer would like it.
In theory, I completly agree. A DVCS can do everything a centralized can do and more. In practice however things look a little different. All Open Source DVCS currently still lack proper support for narrow, shallow and sparse checkouts, thus you can't download only a single directory, you have to always download the whole repository. Which makes implementing some basic workflows that you get with SVN impossible or at least highly impractical to implement with a DVCS.
That changes nothing of the underlying problem that the repositories are a single monolithic system, as all the other repositories have to work in lockstep with the main repository to make the thing work. As otherwise you run into naming conflicts, version conflicts, missing dependencies and a whole bunch of other issues. You can't just take a repository build for five year old Ubuntu release and expect it to work on a current day Ubuntu.
The only reason to make an old repository robust is going the way CDE does: build packages that depend on nothing external and include all needed libraries (preferably with unique names or directly in the main package).
AppBundles are beautiful and easy, but also not flexible enough to handle many cases, which is why quite a few of software on MacOSX comes as.pkg with an installer, instead of as AppBundle. What MacOSX however did right is making the install application a standard thing of the OS, not something that has to be reinvented by every software developer like on Windows (.msi should probably fix that one day).
So set up your own ppa (or rpm equivalent) repository.
The goal should be to have an distribution independent way to package third party software, not force each vendor to package their software for half a dozens of different distributions and different versions of the same distribution. Also repositories are extremely fragile and inflexible. For example you can't "apt-get install" two different versions of the same package and when you want to run an older game whose package depends on some library version that existed in your distribution a few version ago, but no longer in the current one you are also in trouble. If you have a relocatable binary and all required libraries bundled up you have something that is portable to all distributions and robust against most changes.
This "CDE" doesn't solve any problems, but introduces its own "dll hell"
There is no "dll hell" when each software is self contained, its completly the opposite.
The problem with static linking is that it doesn't work in many cases with modern software. For example you can't statically link against glibc or OpenGL. Also static linking makes it impossible to upgrade the libraries used by the program, which might be needed if for example Linux sound API changes again. In most cases it is much better to simply include all the required libraries as.so then to statically link them (you potentially waste a few bytes by that, but for most part its worth it).
Except that distribution specific package manager do *nothing at all* to address the problem of distribution independed binary packaging. On top of that package manage are a really lousy solution to the software packaging problem, as they don't actually solve the underlying problem of duplication and incompatibilities, instead they have a single monolithic repository that they declare as the one and only source for software out there. As long as your software is in that repository, in the version you want, you are of course fine, but if you want a newer version, an older one, two different ones at the same time or a piece of software not yet packaged, you are back at square one as the package manager doesn't deal with those at all. You have to completly bypass the package manager, compile stuff from source and install it somewhere where it doesn't conflict with existing stuff. Its pretty much one big ugly hack.
Now of course CDE isn't exactly a beautiful solution either, its a hack to solve a problem which the distribution builder have preferred to ignore for the last 15 years.
That kind of depends on how much processing of the image really happens on the Kinect, i.e. if you get a full skeleton out of it or just the depth map. If its the former, sure, but if its the later you are still pretty much at square one and have to write all the gesture detection software from scratch.
Somebody may correct me if I am wrong, but as far as I know the special Kinect port on the new Xbox360s is just a USB port that outputs more power then regular. To if you get a powersupply-less Kinect you might need to solder something together to give Kinect enough power, but it shouldn't make any difference in terms of protocols used.
To intercept USB commands you need a USB protocol analyzer, they cost something between a few hundred and a few thousands dollars. If the device you want to reverse engineer has already a Windows driver you can use a software like USBlyzer to simply monitor to communication (its a 30day free trial, but I found it much more stable and comfortable then comparable Free Software).
Random plug: There is also a bounty of now closet to $600 for a Windows driver for the Xbox360 Chatpad, any volunteers?
The fallacy in that is that bugs don't pop up because developers care less, but for most part because games got a hell of a lot more complex then back in the day. This isn't even the first time Nintendo itself fucked up, they already had a very similar issue with Zelda:TP and SmashBros had issues as well (probably not fixable by a patch, but still something that QA should have catched). And of course there have been third parties with issues to, Tomb Raider Underworld had again a very similar game breaking bug.
Nintendo's policy to not allow patches is pretty much just incompetence on their side, causing far more trouble for the player then a regular patch download system.
The tools already exist. People just have to use them.
The tools do not exist, some bare framework exists from which it is possible to replicate some effects from a proper sandbox, but thats all. I seriously doubt that you go out and build an AppArmor profile for every little app you want to run, heck, even the distris don't bother with that and only put a tiny small fraction of apps into AppArmor.
If browsers would just ship with the default of not running things unless whitelisted, most of these problems would disappear.
While whitelisting would certainly help, a proper secure OS shouldn't have an issue with running insecure code in the first place, thats the whole point of a sandbox after all.
The device is a Turing machine and the only way to stay safe is by using it in a responsible manner.
Turning completeness has nothing to do with security.
What do you mean? That ability is available today and has been for some time.
Where? Every OS has a "Run as Administrator"/"Run as Root", but I have yet to see one that has a "Run in Sandbox". Sure you can build a sandbox with chroot or do some stuff with virtualisation, but that is hardly practical for average Joe and would probably give a bunch of trouble when it comes to the GPU.
(2) We need people to start taking ownership for their machines.
No, we need OS that don't give every app access to the full system. Why is there no OS today that allows you to run an application in an isolated sandbox? Why should running an.exe be less safe then running a Flash or Javascript app? There simply isn't any good reason why things are so fucked up, its just historic ballast from the pre-Internet age, back when nobody cared about safety.
I'm not sure how to do that.
Yeah, because it *DOESN'T WORK*. And heck, even if it would work, people have absolutely no way to tell a fraudulent app from a proper one other then a good guess.
Maybe we need a cultural change.
Yeah, but one in the heads of the OS designers, so that they design their security so that it actually works for the random Joe User, not just for the professional admin that spends 10 hours a day configuring his machines.
It's because the book-scanning process is completely automated.
I doubt it, it is not exactly hard to get a book that is at a rather fixed distance into focus. Anyway, the reason why the fonts are blurry isn't the focus to begin with, the images that Google shows are simply extremely low resolution. Why they are in such a low resolution I have no idea.
Nevermind the huge difference between violence and pornography.
Where is the big difference? Both have alleged negative effects on a children's development, but neither really has clear proof behind those claims.
and then promptly ban it.
It is not a ban to begin with, it is mandatory age restrictions, which many stores enforce already anyway, so the practical effects should be rather small if any at all.
The problem with this legislation is that even your child has a right to free speech that may not be infringed upon by the government.
Except that selling porn to minors is already outlawed by the government and handling violence the same as porn doesn't sound all that far fetched to me.
Thats exactly what video game regulation would do, making it easier for parents to control what their children would consume, as children would have a harder time obtaining the games.
Re:Less resilient than a US tracker
on
USB 'Dead Drops'
·
· Score: 1
See, the key to running a cold war-style dead drop is that you DON'T tell everyone where it is.
Maybe the idea here is to spread the idea of dead drops, not the specific dead drops themselves? Also nothing stops you from uploading encrypted content if you don't want others to read it.
Bluetooth and WiFi require separate power, USB sticks on the other side don't, thus you can stick them in a wall and be done with it. Also USB sticks are really cheap. The downside of course is that they are not save against even the simplest vandalism and that they are not save for the user to use, as a modified USB plug could easily burn out the users USB port or even kill the laptop.
Building something like this with RFID could be interesting, as it would provide more security then USB and not require power like Bluetooth or WiFi, but given that RFID readers aren't exactly mainstream and the storeage on RFID chips is in the order of Bytes not Gigabytes, it wouldn't be all that practical.
The HTTP protocol has a last-modified header, and if it incorrect, that's not the fault of the protocol.
Even when it is correct it tells you absolutely nothing about the content. Getting two files with the same time stamp is not exactly hard.
And most importantly, it breaks the other way around too, just because the timestamp changed on a HTTP request doesn't mean the content changed to. Thus instead of continuing a download, you might be forced to redownload content you already have.
Slashdot Mirror
6) They said: We intended it to be an open controller,
Which is a flat out lie. If the thing should be "open" they would have released a spec, a Windows driver or at least XNA integration, not leave people without any help at all like they did.
As far as I know the skeleton detection is in the Xbox360, not in the Kinect. So at this point Kinect won't give you direct motion capture capabilities, as you would still have to process the depth data manually.
I think a large part of the problem is that gaming simply hasn't yet fully grown up, it is still to much stuck in mechanics that forces the player to overcome challenges before he gets access to later content. Adjustable difficulty settings lower the harm a bit, but they don't really remove it, as the last boss on easy might still be to hard for some people and even on easy you are still forced to play stuff you don't care about.
This is one of the reasons why I like simulations on the PC, they are generally free of any kind of forced challenge or unlockables. All the vehicles are available right from the start and when the game is to hard you can switch on unlimited ammunition, invincibility and other tricks, not by some obscure cheat, but by simply going to the option menu. Those games still provide enormous amounts of depths to the player, but they don't force it on the player via a fixed structure, everybody can enjoy them how he likes. Access to in-game developer console can often do similar things in regular games.
On consoles on the other side you don't have that, you might find some obscure cheats, but in general you have to play through all the challenges yourself to unlock the content. There are a few games that tried something new, I think Alone in the Dark allows you to select all chapters of the game right from the start without unlocking and Nintendo has its Super Guide that can take over control when the game gets to difficult, so hopefully more games will follow that trend and give the player the freedom to enjoy the game like he wants, not like the developer would like it.
In theory, I completly agree. A DVCS can do everything a centralized can do and more. In practice however things look a little different. All Open Source DVCS currently still lack proper support for narrow, shallow and sparse checkouts, thus you can't download only a single directory, you have to always download the whole repository. Which makes implementing some basic workflows that you get with SVN impossible or at least highly impractical to implement with a DVCS.
You are confusing the problem with the solution. Users should never be required to go the time consuming route to compile stuff from source.
That changes nothing of the underlying problem that the repositories are a single monolithic system, as all the other repositories have to work in lockstep with the main repository to make the thing work. As otherwise you run into naming conflicts, version conflicts, missing dependencies and a whole bunch of other issues. You can't just take a repository build for five year old Ubuntu release and expect it to work on a current day Ubuntu.
The only reason to make an old repository robust is going the way CDE does: build packages that depend on nothing external and include all needed libraries (preferably with unique names or directly in the main package).
AppBundles are beautiful and easy, but also not flexible enough to handle many cases, which is why quite a few of software on MacOSX comes as .pkg with an installer, instead of as AppBundle. What MacOSX however did right is making the install application a standard thing of the OS, not something that has to be reinvented by every software developer like on Windows (.msi should probably fix that one day).
So set up your own ppa (or rpm equivalent) repository.
The goal should be to have an distribution independent way to package third party software, not force each vendor to package their software for half a dozens of different distributions and different versions of the same distribution. Also repositories are extremely fragile and inflexible. For example you can't "apt-get install" two different versions of the same package and when you want to run an older game whose package depends on some library version that existed in your distribution a few version ago, but no longer in the current one you are also in trouble. If you have a relocatable binary and all required libraries bundled up you have something that is portable to all distributions and robust against most changes.
This "CDE" doesn't solve any problems, but introduces its own "dll hell"
There is no "dll hell" when each software is self contained, its completly the opposite.
When you connect a PS3 via a HDMI-to-DVI cable to an older monitor you will get a black screen due to lack of HDCP support in the monitor.
The problem with static linking is that it doesn't work in many cases with modern software. For example you can't statically link against glibc or OpenGL. Also static linking makes it impossible to upgrade the libraries used by the program, which might be needed if for example Linux sound API changes again. In most cases it is much better to simply include all the required libraries as .so then to statically link them (you potentially waste a few bytes by that, but for most part its worth it).
Package mangers exist for a reason, use them.
Except that distribution specific package manager do *nothing at all* to address the problem of distribution independed binary packaging. On top of that package manage are a really lousy solution to the software packaging problem, as they don't actually solve the underlying problem of duplication and incompatibilities, instead they have a single monolithic repository that they declare as the one and only source for software out there. As long as your software is in that repository, in the version you want, you are of course fine, but if you want a newer version, an older one, two different ones at the same time or a piece of software not yet packaged, you are back at square one as the package manager doesn't deal with those at all. You have to completly bypass the package manager, compile stuff from source and install it somewhere where it doesn't conflict with existing stuff. Its pretty much one big ugly hack.
Now of course CDE isn't exactly a beautiful solution either, its a hack to solve a problem which the distribution builder have preferred to ignore for the last 15 years.
That kind of depends on how much processing of the image really happens on the Kinect, i.e. if you get a full skeleton out of it or just the depth map. If its the former, sure, but if its the later you are still pretty much at square one and have to write all the gesture detection software from scratch.
Somebody may correct me if I am wrong, but as far as I know the special Kinect port on the new Xbox360s is just a USB port that outputs more power then regular. To if you get a powersupply-less Kinect you might need to solder something together to give Kinect enough power, but it shouldn't make any difference in terms of protocols used.
To intercept USB commands you need a USB protocol analyzer, they cost something between a few hundred and a few thousands dollars. If the device you want to reverse engineer has already a Windows driver you can use a software like USBlyzer to simply monitor to communication (its a 30day free trial, but I found it much more stable and comfortable then comparable Free Software).
Random plug: There is also a bounty of now closet to $600 for a Windows driver for the Xbox360 Chatpad, any volunteers?
The fallacy in that is that bugs don't pop up because developers care less, but for most part because games got a hell of a lot more complex then back in the day. This isn't even the first time Nintendo itself fucked up, they already had a very similar issue with Zelda:TP and SmashBros had issues as well (probably not fixable by a patch, but still something that QA should have catched). And of course there have been third parties with issues to, Tomb Raider Underworld had again a very similar game breaking bug.
Nintendo's policy to not allow patches is pretty much just incompetence on their side, causing far more trouble for the player then a regular patch download system.
The tools already exist. People just have to use them.
The tools do not exist, some bare framework exists from which it is possible to replicate some effects from a proper sandbox, but thats all. I seriously doubt that you go out and build an AppArmor profile for every little app you want to run, heck, even the distris don't bother with that and only put a tiny small fraction of apps into AppArmor.
If browsers would just ship with the default of not running things unless whitelisted, most of these problems would disappear.
While whitelisting would certainly help, a proper secure OS shouldn't have an issue with running insecure code in the first place, thats the whole point of a sandbox after all.
The device is a Turing machine and the only way to stay safe is by using it in a responsible manner.
Turning completeness has nothing to do with security.
What do you mean? That ability is available today and has been for some time.
Where? Every OS has a "Run as Administrator"/"Run as Root", but I have yet to see one that has a "Run in Sandbox". Sure you can build a sandbox with chroot or do some stuff with virtualisation, but that is hardly practical for average Joe and would probably give a bunch of trouble when it comes to the GPU.
(2) We need people to start taking ownership for their machines.
No, we need OS that don't give every app access to the full system. Why is there no OS today that allows you to run an application in an isolated sandbox? Why should running an .exe be less safe then running a Flash or Javascript app? There simply isn't any good reason why things are so fucked up, its just historic ballast from the pre-Internet age, back when nobody cared about safety.
I'm not sure how to do that.
Yeah, because it *DOESN'T WORK*. And heck, even if it would work, people have absolutely no way to tell a fraudulent app from a proper one other then a good guess.
Maybe we need a cultural change.
Yeah, but one in the heads of the OS designers, so that they design their security so that it actually works for the random Joe User, not just for the professional admin that spends 10 hours a day configuring his machines.
It's because the book-scanning process is completely automated.
I doubt it, it is not exactly hard to get a book that is at a rather fixed distance into focus. Anyway, the reason why the fonts are blurry isn't the focus to begin with, the images that Google shows are simply extremely low resolution. Why they are in such a low resolution I have no idea.
Nevermind the huge difference between violence and pornography.
Where is the big difference? Both have alleged negative effects on a children's development, but neither really has clear proof behind those claims.
and then promptly ban it.
It is not a ban to begin with, it is mandatory age restrictions, which many stores enforce already anyway, so the practical effects should be rather small if any at all.
The problem with this legislation is that even your child has a right to free speech that may not be infringed upon by the government.
Except that selling porn to minors is already outlawed by the government and handling violence the same as porn doesn't sound all that far fetched to me.
Leave it to the parents.
Thats exactly what video game regulation would do, making it easier for parents to control what their children would consume, as children would have a harder time obtaining the games.
See, the key to running a cold war-style dead drop is that you DON'T tell everyone where it is.
Maybe the idea here is to spread the idea of dead drops, not the specific dead drops themselves? Also nothing stops you from uploading encrypted content if you don't want others to read it.
Bluetooth and WiFi require separate power, USB sticks on the other side don't, thus you can stick them in a wall and be done with it. Also USB sticks are really cheap. The downside of course is that they are not save against even the simplest vandalism and that they are not save for the user to use, as a modified USB plug could easily burn out the users USB port or even kill the laptop.
Building something like this with RFID could be interesting, as it would provide more security then USB and not require power like Bluetooth or WiFi, but given that RFID readers aren't exactly mainstream and the storeage on RFID chips is in the order of Bytes not Gigabytes, it wouldn't be all that practical.
The HTTP protocol has a last-modified header, and if it incorrect, that's not the fault of the protocol.
Even when it is correct it tells you absolutely nothing about the content. Getting two files with the same time stamp is not exactly hard.
And most importantly, it breaks the other way around too, just because the timestamp changed on a HTTP request doesn't mean the content changed to. Thus instead of continuing a download, you might be forced to redownload content you already have.