Yeah, the mass media will start using that mouthful any day now, pot.
At least "cracking" has a connotation with breaking things open, you know, making a "crack". People even say things like "cracking the firewall", so it's not much of a stretch to call the person doing the cracking a cracker. *shrug*
I think those who see the romance in the term "hacker" would prefer everyone used the term "cracker" for criminal-hackers. Unfortunately the mass media has never gotten this memo, using "hacker" for everyone from script-kiddies to social engineers, yet ironically almost never for the programmers who first coined the phrase for themselves to describe simply great coding... bah.
Assume for the moment that poor people tend to live in less desirable areas, and that power lines reduce land value, and also that being poor is bad for your health, then you will find that people living under power lines tend to be sick. But this is due to the common cause of being poor: given these assumptions the power lines are filtering the population sample, as opposed to making them sick in the first place.
This is why correlation is not causation: there may be other correlations as well, and one of them may be a common cause.
The task requires more than picking a single random number, the task is to generate a random ordering of elements. Doing this correctly is not simply a matter of choosing a seed for the PRNG, if that is what you are referring to. Where Microsoft has screwed up is applying a randomized comparison function to a sort operation. This does not yield anything close to a uniform distribution depending on the sorting algorithm being used. (Thus the test results showing 50% probability of IE in slot 5!)
Instead, FTFA one of the good solutions is to iterate backwards through the list, swapping the current element with a randomly chosen element earlier in the list.
It's not an academic issue of minor bias: the measurements show that IE winds up in slot 5 with 50% probability. That's hugely biased.
And although some might shrug as the rightmost slot being somehow "bad", there are well known tendencies for people to remember the first and last thing in a list. The point of this whole ballot screen is to even the playing field to avoid this psychology stuff, and they missed the mark. Not to mention how bad it looks that they supposedly hire the best and brightest, but can't code a shuffle properly for a key component of a major lawsuit. WTF.
In my experience, the AX12 is precise, but only under zero load. Once there is resistance, the proportional control method used by the servo means there will be error proportional to the resistance.
However, on the up side this easy to model and calibrate, so if you can predict the load, you can add a feed-forward term to the position command so the servo moves to the intended position. (i.e. add the amount of expected error to the command so the final position is correct)
Alternatively, or in addition, since you can query the servo for its position, you can add a layer of integrative control in your own software to account for unmodeled errors and drive the servo to the correct position over time.
You might have noticed on the Dynamixel page, they have the RX series which are considerably stronger and have metal gears. They have frames for them as well, but these frames are not compatible with the AX series found in the Bioloid kits.
Robots running haywire and trying to supplant the human race is exactly what Asimov was known for not doing.
Actually, isn't there a story where a set of robots decide humans are bad at managing themselves, and thus for the greater good the robots must take control as an extension of the first law?
Of course, in that story it's a long term plan to subvert humanity, not a sudden hostile takeover, so your point stands on that regard and the whole "killer robots" coming after Spooner definitely did bother me in the movie.
This is because they have digital communication with feedback, so the robot can actually sense its "muscles". The common hobby servos, even the ones advertised as "digital", only have one-way analog communication, so all the appendages are blind... no idea if it has run into something, and no idea how hard it's working. [*] Also, there's no way to adjust controller parameters in the servo, for example to make it soft for interaction.
But these servos are also a new technology, and the student in question (Matt Bunting) has done some extra (and nicely executed) work of his own in order to interface with them. (I've been corresponding with him about this interface board)
[*] Actually, I believe some Hi-tec servos are starting to include some funky methods for requesting an analog position check or switching into a digital communication mode, but these are poorly advertised and documented, and require support on the servo controllers which drive them, and even so aren't as well designed as the Dynamixel interface, so it's still kind of moot.
The old version doesn't have vision processing... vision processing is a whole 'nother ball game of power and complexity. Adding the extra CPU opens new doors for doing interesting research, he's aiming higher than a remote controlled puppet. For instance, I'm doing research in manipulation and motion planning with a similar robot, and quite appreciate his design.
But yeah, if all *you* want is a coffee pot, then don't bother giving it a brain.
No, for one the hexapod in question is made with Dynamixel servos from Robotis, not the "hobby" servos on the MSR... it's also running a dual-core Atom CPU (Z530 if I remember) vs. a PIC microcontroller, and he is actually using that CPU to do some nice vision processing (optic flow). The MSR is a nice hexapod design, but this newer hexapod is quite a bit more powerful.
Krakaotas come and go, but human burning of fossil fuels is non-stop and world wide. Maybe we're not 100% of CO2 production, doesn't mean we don't add up to a significant chunk. And CO2 is only one part of the pollution problem, we also put a lot more exotic stuff in the atmosphere.
Regardless of the size of our contribution, a separate question is whether we are heading toward global warming and what we can to mitigate this... maybe cutting production, maybe also boosting absorption like protecting rain forests or seeding algae in the oceans. Or we can just run around yelling "LALALALA not my fault LALALA" as Florida goes underwater. (hey, maybe global warming isn't such a bad thing!)
It is possible, but not proven, that adding CO2 to the atmosphere is increasing the energy stored in the ocean system.
Sounds like you already contradicted your "debate is over" statement. This is why we need research, not people running around spouting policy advice like they already know the extent of our impact.
And yes, if we then decide to change our impact, this would require a corresponding change in our technologies and usage. I'm not sure why sibling post considers this insightful.
Just because climate changes occurred before humanity existed doesn't mean we can't cause changes as well, or that we shouldn't be concerned and mitigate future changes regardless of whether we are the original trigger.
Our industrial processes are massive. Pretending that this has no effect on the environment or that we shouldn't care about the environment is willfully short sighted.
Do you have any idea what you are talking about? Cardiovascular failure and cancer would beg to differ about the flu thing, which ranks a little above leprosy.
Infographic: http://www.flickr.com/photos/michaelpaukner/4052849920/sizes/o/in/pool-16135094@N00/
Sure, maybe flu will get worse, but it's got a long, long, ways to go. Don't watch so much sensationalist network news.
And not just copied it (it's easy to breed flies:), but translated it into mathematics! This will open it to a much broader audience for analysis and adaptation into working systems. I'm really excited to see how this research pans out... vision processing is a major hurdle for robotics today, and this could have significant impact.
I don't believe there is really any major problems with networked applications from being ran on Linux at this time.
Except if you want to let 64-bit machines run natively but still support 32-bit machines... then you have to maintain two separate file shares. FatELF would have let you keep it all synchronized on one share.
Further, this only works if you're globally using a standard distribution and release revision. It's not clear if FatELF would have supported distribution tags, but that seems like something that could be added fairly easily. Then when you want to start upgrading some machines to a newer distribution, you could just do 'apt-get --add dist-upgrade' or such on the server drive and have it merge the binaries into those that are already installed... life would be beautiful for sys admins.
(Also, FYI we actually use AFS, which is a somewhat more advanced network file system in that it is distributed as well, has its own permissions system, etc. Not actually sure how it winds up comparing to NFS on performance, but probably on par.)
What the hell, it's a setup shared by anyone who wants to run software from a networked file system. Even so, I suppose 99% of users don't use GDB either, so I guess we can just drop things like that from package management, right?
Seriously, just because *you* don't need a feature on your dinky home installation, doesn't mean it's not a very useful feature for others. 'raw' binaries on Linux are only ugly because people like you don't want to contemplate fixing it. That's fine if you want to ignore it, but if you're just going to complain about a partial solution, either demonstrate why it negatively effects you or shut up and get out of the way.
You're back to assuming yum/dpkg package installation is the end-all and be-all of linux installation.
At our university for example, we have the AFS network file system. I can put stuff in my network home directory and run it from a variety of lab and cluster workstations where I don't have time or permission to install a bunch of dependancies. But it's a huge pain in the butt when I sit down at a 32 bit machine and I had previously compiled some tool or library as 64 bit or whatever.
So yes, FatELF doesn't really help dpkg or yum do their thing. That doesn't mean it isn't useful elsewhere.
For instance, for me to install blender right now would take downloading 7 other packages.
And on OS X I just download Blender directly from the website... very easy because it contains everything I need.
As much as I appreciate the linux package system handling dependencies and installation of shared resources, whenever you're doing something *outside* of the packaging system it's a pain in the butt. *This* is where FatELF is handy.
You need to make your code portable, which involves endianess and alignment issues for a start. That's what will take the real work, the shell script is a tiny thing in comparison.
That's a side issue, completely unrelated. Once you've taken the time to make your app portable, coding minutia have nothing to do with making it harder than it needs to be to make use of that portability.
you can just ship i386 and not bother with this at all
that assumes the i386 libraries are in place, which as my original parent was just saying, isn't necessarily the case because often you can get everything purely 64-bit. (and as a side-effect of the earlier strawman, that CDs don't have room for both architectures, so only one is installed)
Then no one wants to be that one 32-bit app which requires the user to install the whole set of 32-bit system libraries... especially as the whole point of a USB or net install is to avoid installing crap on every single machine you use.
And besides, who wants to have to maintain a shell script and two+ executables for every application? It doesn't scale well. FatELF would be a straightforward solution to some real issues, I'm disappointed people couldn't give constructive criticism instead of getting hung up on a single use case (native installation) where's it's not *really* needed. I'm sure FatELF won't make you coffee either, doesn't mean it isn't helpful in other areas. (non-"installed" software)
FWIW, the driver situation seems almost by choice to be designed such that it works more smoothly when you have the source code for the drivers.
Which as far as I'm concerned device manufacturers are crazy not to do... the best a driver can hope for is to simply not get in the way, yet hardware manufacturers seem to have a really hard time writing decent drivers that work correctly. It's not a competitive advantage, all it does is screw themselves over when I can't use their device. Why they want to turn down help from users who can fix their drivers for them is beyond me.
So fat binaries would be of limited help for drivers... it's less of an issue for an installer to pick the right architecture to copy into place, as it is an issue that the Linux design philosophy is simply better suited for open source drivers. (which could be transparently compiled by the installer during installation for the target system)
There are places this would be very useful to have. Anytime we're distributing binaries to users, hosting binaries on a network file share, or carrying portable media, it's a big pain in the butt to maintain completely separate architecture trees. In some cases it wastes a lot of space too if there's significant data files along with the executables, because we generally wind up replicating that in each arch install tree.
I've definitely appreciated OS X's universal binaries in the past, it's a shame to lose an opportunity for having that on Linux. Guess I'm not going to see bundled, versioned libraries like OS X Frameworks anytime either, sigh.
You give "we all" too much credit:-/ As grandparent demonstrates, there's still a lot of console-based luddites that want to restrict us all to the lowest common denominator. Which is especially sad in this case because web fonts will allow text to degrade much more gracefully than the current solutions of using images (and then usually forgetting the alt tags) or worse, flash.
The problems start, however, at the very point where the website stops working correctly because the user had the "arrogance" of replacing the font with his own, or the "nerve" to press Ctrl++ to try and make the text bigger.
The current alternatives to font downloads degrade much worse! Currently, images are often used for things such as button labels or headings or logos or such fancy UI elements. There is no way to replace these elements with a more readable font for visually-impared users, alt tags are often forgotten, and it's invisible to spidering and context parsing. Scaling with Ctrl-+, if the browser even scales images, becomes blurry and unreadable.
I have trouble imaging how font downloads will do anything but improve the current situation. I'm sure there's some demented edge cases, but by and large this is a Good Thing.
Slashdot Mirror
Black Hat is a much better term.
Yeah, the mass media will start using that mouthful any day now, pot.
;)
At least "cracking" has a connotation with breaking things open, you know, making a "crack". People even say things like "cracking the firewall", so it's not much of a stretch to call the person doing the cracking a cracker. *shrug*
--kettle
I think those who see the romance in the term "hacker" would prefer everyone used the term "cracker" for criminal-hackers. Unfortunately the mass media has never gotten this memo, using "hacker" for everyone from script-kiddies to social engineers, yet ironically almost never for the programmers who first coined the phrase for themselves to describe simply great coding... bah.
Assume for the moment that poor people tend to live in less desirable areas, and that power lines reduce land value, and also that being poor is bad for your health, then you will find that people living under power lines tend to be sick. But this is due to the common cause of being poor: given these assumptions the power lines are filtering the population sample, as opposed to making them sick in the first place.
This is why correlation is not causation: there may be other correlations as well, and one of them may be a common cause.
The task requires more than picking a single random number, the task is to generate a random ordering of elements. Doing this correctly is not simply a matter of choosing a seed for the PRNG, if that is what you are referring to. Where Microsoft has screwed up is applying a randomized comparison function to a sort operation. This does not yield anything close to a uniform distribution depending on the sorting algorithm being used. (Thus the test results showing 50% probability of IE in slot 5!)
Instead, FTFA one of the good solutions is to iterate backwards through the list, swapping the current element with a randomly chosen element earlier in the list.
It's not an academic issue of minor bias: the measurements show that IE winds up in slot 5 with 50% probability. That's hugely biased.
And although some might shrug as the rightmost slot being somehow "bad", there are well known tendencies for people to remember the first and last thing in a list. The point of this whole ballot screen is to even the playing field to avoid this psychology stuff, and they missed the mark. Not to mention how bad it looks that they supposedly hire the best and brightest, but can't code a shuffle properly for a key component of a major lawsuit. WTF.
In my experience, the AX12 is precise, but only under zero load. Once there is resistance, the proportional control method used by the servo means there will be error proportional to the resistance.
However, on the up side this easy to model and calibrate, so if you can predict the load, you can add a feed-forward term to the position command so the servo moves to the intended position. (i.e. add the amount of expected error to the command so the final position is correct)
Alternatively, or in addition, since you can query the servo for its position, you can add a layer of integrative control in your own software to account for unmodeled errors and drive the servo to the correct position over time.
You might have noticed on the Dynamixel page, they have the RX series which are considerably stronger and have metal gears. They have frames for them as well, but these frames are not compatible with the AX series found in the Bioloid kits.
Robots running haywire and trying to supplant the human race is exactly what Asimov was known for not doing.
Actually, isn't there a story where a set of robots decide humans are bad at managing themselves, and thus for the greater good the robots must take control as an extension of the first law?
Of course, in that story it's a long term plan to subvert humanity, not a sudden hostile takeover, so your point stands on that regard and the whole "killer robots" coming after Spooner definitely did bother me in the movie.
Also the Dynamixel servos are an important upgrade IMHO
This is because they have digital communication with feedback, so the robot can actually sense its "muscles". The common hobby servos, even the ones advertised as "digital", only have one-way analog communication, so all the appendages are blind... no idea if it has run into something, and no idea how hard it's working. [*] Also, there's no way to adjust controller parameters in the servo, for example to make it soft for interaction.
But these servos are also a new technology, and the student in question (Matt Bunting) has done some extra (and nicely executed) work of his own in order to interface with them. (I've been corresponding with him about this interface board)
[*] Actually, I believe some Hi-tec servos are starting to include some funky methods for requesting an analog position check or switching into a digital communication mode, but these are poorly advertised and documented, and require support on the servo controllers which drive them, and even so aren't as well designed as the Dynamixel interface, so it's still kind of moot.
The old version doesn't have vision processing... vision processing is a whole 'nother ball game of power and complexity. Adding the extra CPU opens new doors for doing interesting research, he's aiming higher than a remote controlled puppet. For instance, I'm doing research in manipulation and motion planning with a similar robot, and quite appreciate his design.
But yeah, if all *you* want is a coffee pot, then don't bother giving it a brain.
No, for one the hexapod in question is made with Dynamixel servos from Robotis, not the "hobby" servos on the MSR... it's also running a dual-core Atom CPU (Z530 if I remember) vs. a PIC microcontroller, and he is actually using that CPU to do some nice vision processing (optic flow). The MSR is a nice hexapod design, but this newer hexapod is quite a bit more powerful.
Krakaotas come and go, but human burning of fossil fuels is non-stop and world wide. Maybe we're not 100% of CO2 production, doesn't mean we don't add up to a significant chunk. And CO2 is only one part of the pollution problem, we also put a lot more exotic stuff in the atmosphere.
Regardless of the size of our contribution, a separate question is whether we are heading toward global warming and what we can to mitigate this... maybe cutting production, maybe also boosting absorption like protecting rain forests or seeding algae in the oceans. Or we can just run around yelling "LALALALA not my fault LALALA" as Florida goes underwater. (hey, maybe global warming isn't such a bad thing!)
It is possible, but not proven, that adding CO2 to the atmosphere is increasing the energy stored in the ocean system.
Sounds like you already contradicted your "debate is over" statement. This is why we need research, not people running around spouting policy advice like they already know the extent of our impact.
And yes, if we then decide to change our impact, this would require a corresponding change in our technologies and usage. I'm not sure why sibling post considers this insightful.
Just because climate changes occurred before humanity existed doesn't mean we can't cause changes as well, or that we shouldn't be concerned and mitigate future changes regardless of whether we are the original trigger.
Our industrial processes are massive. Pretending that this has no effect on the environment or that we shouldn't care about the environment is willfully short sighted.
Do you have any idea what you are talking about? Cardiovascular failure and cancer would beg to differ about the flu thing, which ranks a little above leprosy.
Infographic: http://www.flickr.com/photos/michaelpaukner/4052849920/sizes/o/in/pool-16135094@N00/
Sure, maybe flu will get worse, but it's got a long, long, ways to go. Don't watch so much sensationalist network news.
they took a proven system and copied it.
And not just copied it (it's easy to breed flies :), but translated it into mathematics! This will open it to a much broader audience for analysis and adaptation into working systems. I'm really excited to see how this research pans out... vision processing is a major hurdle for robotics today, and this could have significant impact.
I'm sorry, are we on your grass?
I don't believe there is really any major problems with networked applications from being ran on Linux at this time.
Except if you want to let 64-bit machines run natively but still support 32-bit machines... then you have to maintain two separate file shares. FatELF would have let you keep it all synchronized on one share.
Further, this only works if you're globally using a standard distribution and release revision. It's not clear if FatELF would have supported distribution tags, but that seems like something that could be added fairly easily. Then when you want to start upgrading some machines to a newer distribution, you could just do 'apt-get --add dist-upgrade' or such on the server drive and have it merge the binaries into those that are already installed... life would be beautiful for sys admins.
(Also, FYI we actually use AFS, which is a somewhat more advanced network file system in that it is distributed as well, has its own permissions system, etc. Not actually sure how it winds up comparing to NFS on performance, but probably on par.)
What the hell, it's a setup shared by anyone who wants to run software from a networked file system. Even so, I suppose 99% of users don't use GDB either, so I guess we can just drop things like that from package management, right?
Seriously, just because *you* don't need a feature on your dinky home installation, doesn't mean it's not a very useful feature for others. 'raw' binaries on Linux are only ugly because people like you don't want to contemplate fixing it. That's fine if you want to ignore it, but if you're just going to complain about a partial solution, either demonstrate why it negatively effects you or shut up and get out of the way.
At our university for example, we have the AFS network file system. I can put stuff in my network home directory and run it from a variety of lab and cluster workstations where I don't have time or permission to install a bunch of dependancies. But it's a huge pain in the butt when I sit down at a 32 bit machine and I had previously compiled some tool or library as 64 bit or whatever.
So yes, FatELF doesn't really help dpkg or yum do their thing. That doesn't mean it isn't useful elsewhere.
For instance, for me to install blender right now would take downloading 7 other packages.
And on OS X I just download Blender directly from the website... very easy because it contains everything I need.
As much as I appreciate the linux package system handling dependencies and installation of shared resources, whenever you're doing something *outside* of the packaging system it's a pain in the butt. *This* is where FatELF is handy.
You need to make your code portable, which involves endianess and alignment issues for a start. That's what will take the real work, the shell script is a tiny thing in comparison.
That's a side issue, completely unrelated. Once you've taken the time to make your app portable, coding minutia have nothing to do with making it harder than it needs to be to make use of that portability.
you can just ship i386 and not bother with this at all
that assumes the i386 libraries are in place, which as my original parent was just saying, isn't necessarily the case because often you can get everything purely 64-bit. (and as a side-effect of the earlier strawman, that CDs don't have room for both architectures, so only one is installed)
Then no one wants to be that one 32-bit app which requires the user to install the whole set of 32-bit system libraries... especially as the whole point of a USB or net install is to avoid installing crap on every single machine you use.
And besides, who wants to have to maintain a shell script and two+ executables for every application? It doesn't scale well. FatELF would be a straightforward solution to some real issues, I'm disappointed people couldn't give constructive criticism instead of getting hung up on a single use case (native installation) where's it's not *really* needed. I'm sure FatELF won't make you coffee either, doesn't mean it isn't helpful in other areas. (non-"installed" software)
FWIW, the driver situation seems almost by choice to be designed such that it works more smoothly when you have the source code for the drivers.
Which as far as I'm concerned device manufacturers are crazy not to do... the best a driver can hope for is to simply not get in the way, yet hardware manufacturers seem to have a really hard time writing decent drivers that work correctly. It's not a competitive advantage, all it does is screw themselves over when I can't use their device. Why they want to turn down help from users who can fix their drivers for them is beyond me.
So fat binaries would be of limited help for drivers... it's less of an issue for an installer to pick the right architecture to copy into place, as it is an issue that the Linux design philosophy is simply better suited for open source drivers. (which could be transparently compiled by the installer during installation for the target system)
There are places this would be very useful to have. Anytime we're distributing binaries to users, hosting binaries on a network file share, or carrying portable media, it's a big pain in the butt to maintain completely separate architecture trees. In some cases it wastes a lot of space too if there's significant data files along with the executables, because we generally wind up replicating that in each arch install tree.
I've definitely appreciated OS X's universal binaries in the past, it's a shame to lose an opportunity for having that on Linux. Guess I'm not going to see bundled, versioned libraries like OS X Frameworks anytime either, sigh.
You give "we all" too much credit :-/ As grandparent demonstrates, there's still a lot of console-based luddites that want to restrict us all to the lowest common denominator. Which is especially sad in this case because web fonts will allow text to degrade much more gracefully than the current solutions of using images (and then usually forgetting the alt tags) or worse, flash.
The problems start, however, at the very point where the website stops working correctly because the user had the "arrogance" of replacing the font with his own, or the "nerve" to press Ctrl++ to try and make the text bigger.
The current alternatives to font downloads degrade much worse! Currently, images are often used for things such as button labels or headings or logos or such fancy UI elements. There is no way to replace these elements with a more readable font for visually-impared users, alt tags are often forgotten, and it's invisible to spidering and context parsing. Scaling with Ctrl-+, if the browser even scales images, becomes blurry and unreadable.
I have trouble imaging how font downloads will do anything but improve the current situation. I'm sure there's some demented edge cases, but by and large this is a Good Thing.