The test suite is very thorough and pokes around in obscure areas of the various specs, some of which are ambiguous.
This is obviously a good reason to ignore Sun's certification: the test suite relies on unspecified behaviour, and is therefore not 100% compliant itself. Of course, the J2EE specification itself is badly managed; it is impossible to write code for container-managed relations which is legal with both the second proposed final version of the latest release and the final release. Most of the incompatibilities between JBoss and other implementations that I have noticed has been that JBoss only follows the version of the specification that it says it does, while Weblogic (e.g.) lets you use features together which were never both permitted in a single version.
Of course, the certification is essentially bogus anyway; I've seen obvious non-compliant behaviour from a version of Weblogic that was certified.
It's based on sales, not on net income. It's a bit harder to arrange to never show any sales, and still survive as a company.
The idea is for major customers to demand this, not for companies to be interesting in doing it on their own. There are no benefits at all for the producer in this system, except that you may be excluded from consideration by major customers if you don't play along.
It would be trivial to prevent the attack: add a nanosleep(10) to the end of each operation, and any amount of time under the size of a timeslice disappears, because the SSL server will spend the rest of the timeslice sleeping, making the timing perfectly uniform.
If you want to be sure (and deal with multi-timeslice operations and kernels that give the process control in a more timely fashion), use setitimer. It's not a hard problem to correct, but people didn't previously think that it was actually a problem (i.e., that you learned significantly more about the private key from timing than you did from seeing something encrypted with it).
Half of the point of wearables is the ability to make the device less intrusive, so that you can have it not get in your way without having to leave it behind. Your cell phone should know when you're in the car and not take calls. Ideally, it would know when you were likely to get where you're going, so the voice mail could tell the caller when you're likely to be able tot take the call. Furthermore, it would know when you got out of the car, at which point you're not in the middle of anything, and it makes sense to tell you that you have voicemail. Same for concerts, dinners, movies, etc. Non-wearable technology generally lacks the ability to keep track of what you're doing when you're not using it, so it intrudes randomly when it wants to get your attention.
Having some devices like a HUD can be useful, because it means that you can use the system without using your hands and without taking it out of your pocket. This means that you can use it in shorter periods of time and stop using it more suddenly. The resolution on a HUD is actually the same as a current PDA (or better).
A current PDA actually makes a good computing core for a wearable system; it's got a reasonable amount of processing power, and just needs a bunch of devices to determine whether it should try to interrupt you.
$2.4 million / 7000 is $342/student. If you're going to outfit the whole school (for the first year, at least) on this money, you're going to need to stick with existing hardware to a significant extent. It's a nice idea, but the money is insufficient for a complete switch.
It's not clear that the hippocampus actually gets all of the data; it may well be that the hippocampus only produces "tags" for memories, which get sent to the parts of the brain having the experiences, and those parts encode their current state and store it with the tag. In this case, the output of the hippocampus would serve to produce the associations you would have with every moment of your life, but not the moments themselves (or the content of the associations).
In computer terms, the hippocampus would be the CPU issuing DMA requests; the data actually goes from RAM (short-term memory) to disk (long-term memory), without appearing in the output of the CPU. Recording the output of the CPU gives you all of the disk and RAM addresses, but not the actual data or the meanings of the addresses.
This project doesn't attempt to understand how the hippocampus works, or even what its exact role in memory is (beyond the fact that, whatever is does, it is necessary to memory work); it attempts to duplicate the signals the normal hippocampus produces. For all we know, the hippocampus might be an incredibly complex clock, needed for memory but having no useful relationship to the experiences you're having.
I didn't use any MicroSoft products or services after my freshman year (except that I saw somebody use Excel once, and I fought with and learned nothing about Word one term). Didn't cause any problems for me trying to get a job, and I didn't use anything from MicroSoft there in a year and three quarters.
The "real world" where everybody uses MicroSoft products seems to me to be business administration, not programming. You therefore mean "PowerPoint", not "Visual Basic".
We'll probably start switching to electrics when it becomes as easy to get suitable fuel for them as it is to get gas. The real benefit of hybrids is that you can get good efficiency out of them running on a fuel that's easy to find. The next benefit is that you can store sufficient energy to go a really long way. Once there's an energy source for electric cars that's as standardized as the unleaded gas pump and gas stations can provide it as with at least as good a profit margin as gas, people will start running their hybrids off of that, and then people can start switching to entirely electric engines.
The price of gas doesn't really matter that much; there's enough gas in the world that gas will be the cheapest original source of fuel for electric vehicles even once everybody's switched. Of course, the energy will be extracted from the oil in a far cleaner and more efficient way than it is now. The price of oil is now, and will be for the forseeable future, determined by the politics of getting it from the people who have it, not the remaining supply.
I'd be glad if the software I write makes life better for Palestinians, Jews, Muslims, Hindus, etc. Even people whose actions I don't approve of deserve better than to have to deal with a MicroSoft interface or have their computers crash on them. Sure, I don't think much of the Bush administration, but my life isn't any better if they're annoyed by their computers. And if they're going to be watching me, I certainly don't want there to be backdoors in the tools they're using; it's bad enough for the government to have that information.
Most of all, I hope that my work makes life more pleasant for terrorists. Perhaps it will serve in some small way to make up for the government activity which supposedly represents me, and serve to distinguish the behavior of US citizens from that of the US government.
War is a lot of wasted effort (since there's effort on both sides intended to counteract the other side's effort). Providing general tools to everyone simply reduces the duplicated and wasted effort.
If it didn't, Sun wouldn't have a positive reputation to lose. Neither, for that matter, would IBM. The open source community doesn't trust anybody to do the right thing in the future, and pays no attention to bad things anybody's done in the past. If you're producing good code under a suitable license now, you're liked. If you did so in the past, you're remembered. Otherwise, it's just talk, and doesn't matter.
Kinetic energy is a form of energy. Momentum is not a form of energy. It doesn't even have the right units for energy. It also has a direction, which means that it doesn't sum up in the right way for a "heat" version to make sense.
That's why, when the tides slow the Earth down, they also speed the moon up, such that the pair will converge to being tidally locked with a period somewhere in the middle, the whole thing going around together with the same total angular momentum that the whole thing has now, just distributed differently.
If you don't want the menubar, whyever would you use a menu to turn it off? You should only be able to turn off the menubar with a keyboard shortcut, thereby demonstrating that you use keyboard shortcuts.
It's plausible that there will be PS3 units available to developers 2 years in advance of its release to the public, considering that it took developers two years to figure out how to heck to program the PS2, and the PS3 is supposed to be far more complicated to program. Sony doesn't want to repeat the release of the PS2, where it was released to much fanfare and then no really good games were available for years, after which people actually started switching to the system.
You're thinking of leap seconds, which are used to synchronize the time of day with the number of seconds elapsed. These get applied to the readouts of atomic clocks, and the time gets distributed from there.
Momentum isn't energy, and is conserved by itself. In fact, the numeric value of momentum depends entirely on the reference frame, and therefore can't tend towards zero due to non-conservative forces, because there's no zero, since there's no absolute reference frame.
There are two ways the earth's rotation can change: keep the same angular momentum by moving mass away from the axis, and throwing mass out into space with a more easterly velocity than it would have sitting where it started.
The study mentioned in the article isn't talking about a non-conservative change in the Earth's rotation, in any case, but rather a conservative change due to permanent (or, at least, long-term) climate change. If the winds blow harder, the Earth slows down; if the winds blow less hard, the Earth speeds up. If the winds continue to blow hard for the next millenium, it'll be a long millenium.
Some people are theorizing that SCO's goal is to get IBM to buy them. Say this happens. Now it's IBM going after Sun, which would be much more troubling for them.
On the other hand, IBM would be throwing away several billion dollars worth of good will they've developed in the open source community if they tried this, but Sun can't really depend on IBM not to be stupid.
The open source community has a short memory for insults; if someone's presently being helpful, it doesn't matter all that much what they did in the past. So they can afford to offend if it's safer for their business, and plan to produce some more useful code in the future to make up for it.
It was only a temporary logo, and seems only to be a temporary name. You can't expect the same people who come up with a working RSS search engine to simultaneously come up with a good name for it. For that matter, somebody entirely different already owns roogle.com.
Linus did mention a "CPU hug detector" patch at one point. And there's work in progress to let you remove parts of your computer.
"He's unplugging the serial cable! He's removing the network card! He's pulling out a CPU! Will he remove the motherboard, too? To find out, order... (picture of Linus hugging one of his still-warm P4s)"
It's easier to be perfectionistic in making anime than it is in making a live-action film; you can tweak the visuals arbitrarily until they're just right, and it's much easier to do a lot of takes of the audio and splice the best ones together, because you're not trying to fit video and the actors don't have to do difficult things while speaking. This means you can get a better result with somewhat less effort, and that you can get a good result with less skilled people taking more time.
American cartoons tend to be taken less seriously than anime, which means that you don't get as impressive results most of the time.
So anime isn't automatically great, but it's a lot more practical for a lot of good stories.
There seems to be a lot of effort in automated testing which goes into trying to determine what the program is supposed to do. An automated tool can never find all of the bugs, since some of them will be that the program doesn't crash or anything, but fails to follow the specification, which isn't given to the automated tool.
How would you extend C/C++ to include information about the intended behavior of programs, so that programmers can tell the tool directly what is supposed to happen?
It's only generally considered extortion or coercion if you're say "We will do X if you don't pay use." If the thing you're going to do is legal and paying will provide a legitimate service which is useful in the situation, that's generally fine.
In any case, being slashdotted isn't such a bad thing; probably more people will read your site before the server gets overloaded than would have otherwise read the site in the time it will take to get it back to normal. And getting people to read the site is kinda the point, anyway.
Assuming you're willing to join in the big common table for each child, sure. And it's worth it if you actually want a relational database containing this data (actually, the operations you want to do on the data should dictate the table structure you choose out of the several options). But that just makes a mess of things if all you want out of the database is persistence.
In order for this to be exploitable, the compiler has to arrange the data segment such that there is a structure containing pointers shortly after the buffer that can be overrun. As it turns out, most builds of sendmail, including all of the Red Hat precompiled binaries tested and all of the commercial UNIX ones tested, are not directly exploitable (that is, it might be possible to get them to misbehave somehow, but not to crash in any predictable way). The exploits also depend on knowing what structure you've hit, which is only possible if you have access to the particular binary, and the exploits will only work for a particular binary.
So this is not a good candidate for a worm or automated exploit, and only useful for a direct attack if you happen to be relatively unlucky and the attacker knows it.
In this case, it's companies (sendmail, inc, and companies with derived code) that needed to know; debian just has to apply the patch, recompile, and release, which they can do in a small bounded amount of time. Telling the people who need to come up with the patch first is all that's necessary.
What's wrong with building a kernel for your home machine? You don't want to configure it by hand, but having your kernel rebuild in response to some actions makes a lot of sense.
I'd like to get a program to let my PDA talk to the internet through the cradle. Of course, this "program" mostly consists of turning on some kernel options, building some modules, and a little script to enable it when I plug in the PDA. Most kernel configuration should be possible through autodetecting; have the config thing determine what hardware you have and turn on the options to use it.
When I started using Linux, you would tune your XF86Config to get the image nicely centered on your screen and stretched to the edges. Since then, XFree86 has gotten more clever, and just figures out the right tunings. Sure, you *can* still do your own mode, but the system has gotten better at it so it's not worthwhile. Likewise, I bet it won't be too long before you choose the best scheduler (and scheduler settings) by running your machine for a while and then hitting the button to optimize your kernel for the hardware you have and the workload it's under. And you'll do it with a little button on your desktop and from the command line on the server, but it will be the same program. And if you'd like, you can see the config it's chosen, but it's not necessary.
But for now, you can just give desktop users a kernel with everything as a module, and they don't have to rebuild anything, and they don't load the modules they don't need.
Slashdot Mirror
The test suite is very thorough and pokes around in obscure areas of the various specs, some of which are ambiguous.
This is obviously a good reason to ignore Sun's certification: the test suite relies on unspecified behaviour, and is therefore not 100% compliant itself. Of course, the J2EE specification itself is badly managed; it is impossible to write code for container-managed relations which is legal with both the second proposed final version of the latest release and the final release. Most of the incompatibilities between JBoss and other implementations that I have noticed has been that JBoss only follows the version of the specification that it says it does, while Weblogic (e.g.) lets you use features together which were never both permitted in a single version.
Of course, the certification is essentially bogus anyway; I've seen obvious non-compliant behaviour from a version of Weblogic that was certified.
It's based on sales, not on net income. It's a bit harder to arrange to never show any sales, and still survive as a company.
The idea is for major customers to demand this, not for companies to be interesting in doing it on their own. There are no benefits at all for the producer in this system, except that you may be excluded from consideration by major customers if you don't play along.
It would be trivial to prevent the attack: add a nanosleep(10) to the end of each operation, and any amount of time under the size of a timeslice disappears, because the SSL server will spend the rest of the timeslice sleeping, making the timing perfectly uniform.
If you want to be sure (and deal with multi-timeslice operations and kernels that give the process control in a more timely fashion), use setitimer. It's not a hard problem to correct, but people didn't previously think that it was actually a problem (i.e., that you learned significantly more about the private key from timing than you did from seeing something encrypted with it).
Half of the point of wearables is the ability to make the device less intrusive, so that you can have it not get in your way without having to leave it behind. Your cell phone should know when you're in the car and not take calls. Ideally, it would know when you were likely to get where you're going, so the voice mail could tell the caller when you're likely to be able tot take the call. Furthermore, it would know when you got out of the car, at which point you're not in the middle of anything, and it makes sense to tell you that you have voicemail. Same for concerts, dinners, movies, etc. Non-wearable technology generally lacks the ability to keep track of what you're doing when you're not using it, so it intrudes randomly when it wants to get your attention.
Having some devices like a HUD can be useful, because it means that you can use the system without using your hands and without taking it out of your pocket. This means that you can use it in shorter periods of time and stop using it more suddenly. The resolution on a HUD is actually the same as a current PDA (or better).
A current PDA actually makes a good computing core for a wearable system; it's got a reasonable amount of processing power, and just needs a bunch of devices to determine whether it should try to interrupt you.
$2.4 million / 7000 is $342/student. If you're going to outfit the whole school (for the first year, at least) on this money, you're going to need to stick with existing hardware to a significant extent. It's a nice idea, but the money is insufficient for a complete switch.
It's not clear that the hippocampus actually gets all of the data; it may well be that the hippocampus only produces "tags" for memories, which get sent to the parts of the brain having the experiences, and those parts encode their current state and store it with the tag. In this case, the output of the hippocampus would serve to produce the associations you would have with every moment of your life, but not the moments themselves (or the content of the associations).
In computer terms, the hippocampus would be the CPU issuing DMA requests; the data actually goes from RAM (short-term memory) to disk (long-term memory), without appearing in the output of the CPU. Recording the output of the CPU gives you all of the disk and RAM addresses, but not the actual data or the meanings of the addresses.
This project doesn't attempt to understand how the hippocampus works, or even what its exact role in memory is (beyond the fact that, whatever is does, it is necessary to memory work); it attempts to duplicate the signals the normal hippocampus produces. For all we know, the hippocampus might be an incredibly complex clock, needed for memory but having no useful relationship to the experiences you're having.
I didn't use any MicroSoft products or services after my freshman year (except that I saw somebody use Excel once, and I fought with and learned nothing about Word one term). Didn't cause any problems for me trying to get a job, and I didn't use anything from MicroSoft there in a year and three quarters.
The "real world" where everybody uses MicroSoft products seems to me to be business administration, not programming. You therefore mean "PowerPoint", not "Visual Basic".
We'll probably start switching to electrics when it becomes as easy to get suitable fuel for them as it is to get gas. The real benefit of hybrids is that you can get good efficiency out of them running on a fuel that's easy to find. The next benefit is that you can store sufficient energy to go a really long way. Once there's an energy source for electric cars that's as standardized as the unleaded gas pump and gas stations can provide it as with at least as good a profit margin as gas, people will start running their hybrids off of that, and then people can start switching to entirely electric engines.
The price of gas doesn't really matter that much; there's enough gas in the world that gas will be the cheapest original source of fuel for electric vehicles even once everybody's switched. Of course, the energy will be extracted from the oil in a far cleaner and more efficient way than it is now. The price of oil is now, and will be for the forseeable future, determined by the politics of getting it from the people who have it, not the remaining supply.
I'd be glad if the software I write makes life better for Palestinians, Jews, Muslims, Hindus, etc. Even people whose actions I don't approve of deserve better than to have to deal with a MicroSoft interface or have their computers crash on them. Sure, I don't think much of the Bush administration, but my life isn't any better if they're annoyed by their computers. And if they're going to be watching me, I certainly don't want there to be backdoors in the tools they're using; it's bad enough for the government to have that information.
Most of all, I hope that my work makes life more pleasant for terrorists. Perhaps it will serve in some small way to make up for the government activity which supposedly represents me, and serve to distinguish the behavior of US citizens from that of the US government.
War is a lot of wasted effort (since there's effort on both sides intended to counteract the other side's effort). Providing general tools to everyone simply reduces the duplicated and wasted effort.
If it didn't, Sun wouldn't have a positive reputation to lose. Neither, for that matter, would IBM. The open source community doesn't trust anybody to do the right thing in the future, and pays no attention to bad things anybody's done in the past. If you're producing good code under a suitable license now, you're liked. If you did so in the past, you're remembered. Otherwise, it's just talk, and doesn't matter.
Kinetic energy is a form of energy. Momentum is not a form of energy. It doesn't even have the right units for energy. It also has a direction, which means that it doesn't sum up in the right way for a "heat" version to make sense.
That's why, when the tides slow the Earth down, they also speed the moon up, such that the pair will converge to being tidally locked with a period somewhere in the middle, the whole thing going around together with the same total angular momentum that the whole thing has now, just distributed differently.
If you don't want the menubar, whyever would you use a menu to turn it off? You should only be able to turn off the menubar with a keyboard shortcut, thereby demonstrating that you use keyboard shortcuts.
It's plausible that there will be PS3 units available to developers 2 years in advance of its release to the public, considering that it took developers two years to figure out how to heck to program the PS2, and the PS3 is supposed to be far more complicated to program. Sony doesn't want to repeat the release of the PS2, where it was released to much fanfare and then no really good games were available for years, after which people actually started switching to the system.
You're thinking of leap seconds, which are used to synchronize the time of day with the number of seconds elapsed. These get applied to the readouts of atomic clocks, and the time gets distributed from there.
Momentum isn't energy, and is conserved by itself. In fact, the numeric value of momentum depends entirely on the reference frame, and therefore can't tend towards zero due to non-conservative forces, because there's no zero, since there's no absolute reference frame.
There are two ways the earth's rotation can change: keep the same angular momentum by moving mass away from the axis, and throwing mass out into space with a more easterly velocity than it would have sitting where it started.
The study mentioned in the article isn't talking about a non-conservative change in the Earth's rotation, in any case, but rather a conservative change due to permanent (or, at least, long-term) climate change. If the winds blow harder, the Earth slows down; if the winds blow less hard, the Earth speeds up. If the winds continue to blow hard for the next millenium, it'll be a long millenium.
Some people are theorizing that SCO's goal is to get IBM to buy them. Say this happens. Now it's IBM going after Sun, which would be much more troubling for them.
On the other hand, IBM would be throwing away several billion dollars worth of good will they've developed in the open source community if they tried this, but Sun can't really depend on IBM not to be stupid.
The open source community has a short memory for insults; if someone's presently being helpful, it doesn't matter all that much what they did in the past. So they can afford to offend if it's safer for their business, and plan to produce some more useful code in the future to make up for it.
It was only a temporary logo, and seems only to be a temporary name. You can't expect the same people who come up with a working RSS search engine to simultaneously come up with a good name for it. For that matter, somebody entirely different already owns roogle.com.
Linus did mention a "CPU hug detector" patch at one point. And there's work in progress to let you remove parts of your computer.
"He's unplugging the serial cable! He's removing the network card! He's pulling out a CPU! Will he remove the motherboard, too? To find out, order... (picture of Linus hugging one of his still-warm P4s)"
It's easier to be perfectionistic in making anime than it is in making a live-action film; you can tweak the visuals arbitrarily until they're just right, and it's much easier to do a lot of takes of the audio and splice the best ones together, because you're not trying to fit video and the actors don't have to do difficult things while speaking. This means you can get a better result with somewhat less effort, and that you can get a good result with less skilled people taking more time.
American cartoons tend to be taken less seriously than anime, which means that you don't get as impressive results most of the time.
So anime isn't automatically great, but it's a lot more practical for a lot of good stories.
There seems to be a lot of effort in automated testing which goes into trying to determine what the program is supposed to do. An automated tool can never find all of the bugs, since some of them will be that the program doesn't crash or anything, but fails to follow the specification, which isn't given to the automated tool.
How would you extend C/C++ to include information about the intended behavior of programs, so that programmers can tell the tool directly what is supposed to happen?
It's only generally considered extortion or coercion if you're say "We will do X if you don't pay use." If the thing you're going to do is legal and paying will provide a legitimate service which is useful in the situation, that's generally fine.
In any case, being slashdotted isn't such a bad thing; probably more people will read your site before the server gets overloaded than would have otherwise read the site in the time it will take to get it back to normal. And getting people to read the site is kinda the point, anyway.
Assuming you're willing to join in the big common table for each child, sure. And it's worth it if you actually want a relational database containing this data (actually, the operations you want to do on the data should dictate the table structure you choose out of the several options). But that just makes a mess of things if all you want out of the database is persistence.
In order for this to be exploitable, the compiler has to arrange the data segment such that there is a structure containing pointers shortly after the buffer that can be overrun. As it turns out, most builds of sendmail, including all of the Red Hat precompiled binaries tested and all of the commercial UNIX ones tested, are not directly exploitable (that is, it might be possible to get them to misbehave somehow, but not to crash in any predictable way). The exploits also depend on knowing what structure you've hit, which is only possible if you have access to the particular binary, and the exploits will only work for a particular binary.
So this is not a good candidate for a worm or automated exploit, and only useful for a direct attack if you happen to be relatively unlucky and the attacker knows it.
In this case, it's companies (sendmail, inc, and companies with derived code) that needed to know; debian just has to apply the patch, recompile, and release, which they can do in a small bounded amount of time. Telling the people who need to come up with the patch first is all that's necessary.
What's wrong with building a kernel for your home machine? You don't want to configure it by hand, but having your kernel rebuild in response to some actions makes a lot of sense.
I'd like to get a program to let my PDA talk to the internet through the cradle. Of course, this "program" mostly consists of turning on some kernel options, building some modules, and a little script to enable it when I plug in the PDA. Most kernel configuration should be possible through autodetecting; have the config thing determine what hardware you have and turn on the options to use it.
When I started using Linux, you would tune your XF86Config to get the image nicely centered on your screen and stretched to the edges. Since then, XFree86 has gotten more clever, and just figures out the right tunings. Sure, you *can* still do your own mode, but the system has gotten better at it so it's not worthwhile. Likewise, I bet it won't be too long before you choose the best scheduler (and scheduler settings) by running your machine for a while and then hitting the button to optimize your kernel for the hardware you have and the workload it's under. And you'll do it with a little button on your desktop and from the command line on the server, but it will be the same program. And if you'd like, you can see the config it's chosen, but it's not necessary.
But for now, you can just give desktop users a kernel with everything as a module, and they don't have to rebuild anything, and they don't load the modules they don't need.