Indeed, the term Darwinism is mainly used by Creationists, the same way that Allopathy is a term coined by practitioners of Homeopathic medicine.
And the reason for that is because creating such a duality makes it seem that both approaches are equally valid. I'm sure there are many more examples...
If you're going downhill, on any modern car the best is to shift into a high gear (4-6th, depending o the speed you're going downhill), such that you engine is running barely above idle RPM.
Then, the ECU will shut off the fuel supply altogether, and basically go into engine braking mode instead of keeping the engine in rotation by supplying it with a trickle of fuel. The braking effect in 6th gear is however minimal and thus even a very small slope is enough to keep the car going at a constant speed.
And it isn't a general flaw in.NET - the author describes very clever ways how to use.NET applets to prepare ideal ground for a classical memory corruption attack on the browser itself. This still requires a bug in the browser or one of the plugins.
Basically what he manages to do is using a well crafted.NET DLL object putting executable code (embedded in a string constant inside the.NET DLL) to a known address, whereto he then can jump from the memory corruption exploit.
Now, to keep backwards compatibility, Microsoft did a few pretty stupid things in the implementation of the.NET applets, and because of that, putting the.NET data to a specified location in memory _AND_ marking the page executable is possible despite address space randomization and no-exec.
These implementation details can and will get fixed, though, making attacks harder again.
I suggest to read the paper, it's rather well written and very interesting.
The abstract actually tells much more than the linked article, primarily what has been researched and found.
The important bit is that this is not a new exploit, it's a way to make your memory corruption (stack or heap overflow, etc) exploit, if you find one, be able to work despite Vista's additional security measures.
Similar security enhancements are present in the Linux kernel under slightly different names: Address space randomization, non-executable stack, etc. And similar tactics could be used to circumvent them there. It's been always clear to the developers of these enhancements that they can't prevent memory corruption attacks, they just make them much harder.
So much harder that you'll need to equip your exploit code with the techniques described in the BlackHat talk, and most likely this will also limit you to only a subset of the original corruption attack vectors.
The Vista (and Linux) extra security measures aren't worthless, but they never were expected to be completely bulletproof.
After all, the only way to be perfectly safe is to not have any bugs in the software installed on your computer, which usually means no software, too.
Cell phones use a so called RSSI value for the number of the bars. RSSI is a Relative Signal Strength Indication, which is a best guess of the device how well the data transmission will go. Most use SNR directly, some use a product of signal strength and bit error rate (BER).
The reason why it doesn't always match reality is that it's really a best guess by the phone, and reality is much more complicated than just that.
2) Laptop batteries.
Laptop batteries are using charge counters. Those are resistors with very small resistance ( 0.1 Ohm) tied to a precise voltmeter in a controller chip. By integration the controller knows rather well how much charge (how many electrons) have passed through it. With Li-Ion and Li-Pol batteries in use today, however, the situation got harder because the voltage of the battery varies a lot during discharge. Nowadays, modern batteries count energy, that is the product of charge and voltage as it moves in an out, giving a very precise output of remaining energy.
The reason some batteries die very quickly once they stop showing full is because as Li-Ion batteries age, their internal resistance increases. More energy is lost within the battery during the discharge process and the amount of energy lost (and voltage decrease) is directly proportional to the current taken from the battery. At the same time, modern devices have switching regulators which take more current when voltage decreases to provide the same flow of energy to the device. Combined, this means that once the battery voltage of an aged battery starts dropping, it drops very fast.
For cell phones, this is even harder, since they don't have charge counters - the batteries have to be cheap. There the remaining energy is guessed purely based on voltage. And old Li-Ion batteries will have almost full voltage when under light load, and fail when the load is applied, causing a phone to switch off.
If the PBDEs in the whale had come from artificial (human-made) sources, they would have only contained carbon-12 and no carbon-14 due to the fact that virtually all PBDEs which are produced artificially use petroleum as the source of carbon, all carbon-14 would have long since completely decayed from that source.
Not necessarily. Carbon dating works because all newly composed organic matter is made from carbon in the atmosphere - by plants. And upper atmosphere, because it is exposed to cosmic rays, gets a fair dose of radiation, and thus our atmosphere has a percentage of the radioactive carbon-14 that has been constant over ages.
Now there is a way for a PBDE to get a carbon-14 atom in it - if it gets to upper atmosphere, or any other source of radiation, before the whale consumes it. This could just mean that PBDEs are even more widespread than thought - in atmosphere, sea water, krill, whales.
He probably used the JTAG port to take a look and play with the ARM/XScale processors, but not the Boundary Scan part of the port's capabilities. Even the article doesn't mention the Boundary Scan, which is normally used only for testing whether the processor is well and alive.
The capacitors in question are not tantalum, but solid polymer capacitors. A tantalum capacitor
design would be possible, but would be very expensive and also rather bulky.
Compared to tantalum capacitors, these capacitors reach much higher capacities at the
same physical volume, and the same or better ESL/ESR.
These aluminium electrolytic capacitors, with a solid conductive polymer electrolytic find their way even on most current mainboards, most often in the CPU DC-DC convertor circuits. They're usually easily recognizable from classic electrolytics by their small size and metal casing without a plastic sleeve.
A benefit from an all-solid-polymer capacitor mainboard is dubious, since classic alimuium electrolytic
capacitors work just fine in many roles they're needed for, particularly in low-ripple-current situations.
With the current patent system, the huge numbers of patents granted every day,
infringement cannot be considered until validated by either an agreement of two
parties (then valid for those two parties) or a court decision (then valid for everybody
in the country).
It is generally believed that most, if not all the patents Linux potentially infringes on
would fail either the obviousness or prior art tests in court.
However, again due to the sheer numbers of patents that were granted so far, it is not
possible to go and check every single one whether it passes or not in court.
At SuSE (now part of Novell), we have implemented a number of open-source drivers based on specs
we based on documentation received under some kind of contract, including
NDAs.
We always made sure that the contract contained a clause that we're free
to use any information we received this way to implement and distribute a driver
under the terms of the GPL, and that the other party knows about that and agrees
to it. This implies that there either are no patent claims on that code, or that the relevant
patents are licensed to every potential recipient of the code automatically.
We are not going to change that policy.
Btw, points 1-3 don't protect anyone from having potential patent issues, they can
only help with copyright issues. For patents, it doesn't matter how you arrived to
implementing one of those.
The patent covenant agreement alone is cash positive for Novell, sales of SLES by MS not included.
Microsoft is contractually required to sell those SLES coupons, and failing that, it would create
a reason for the termination of the agreement.
Microsoft didn't pay for any licenses, only for the right and obligation to sell SLES to its own customers.
Novell doesn't at all expect to be treated nice by Microsoft. And it isn't. Your post, attacking Novell, clearly shows that Microsoft's strategy is working. What's the best way to hurt an open-source company? Make a few remarks that turn its community against it.
Even if Linux is completely clean with regards to Microsoft patents, and I do believe it is so,
there is still a threat of a lawsuit. There always is. It would be unsuccessful, but it
still would be very inconvenient, annoying and expensive for those that get hit.
Even if Novell doesn't believe that this threat is worth any action, it's enough if its customers,
or potential customers (like those presently being Windows-only) do perceive that threat as important.
Then, paying millions to Microsoft a reasonable bussiness decision. The extra sales of Linux and
displacing Windows at those customers can offset that easily. Novell believes it should be competing
with and taking market share from Windows, not RedHat, or which is the current case, old UNIXes,
and this helps it.
Even not including any sales of SLES by Microsoft, the payment is still positive by some $108M for Novell.
It is positive, because in the deal Novell gives up the option of attacking Microsoft customers, an
option it would never execute, believing in srictly defensive usage of its patent portfolio.
Having said that, I will not argue that the deal is all roses and doesn't have any negative sides. I, working for SuSE, do certainly feel those. But I would like you to understand that there were good reasons for it, and that there is no need to search for dark ulterior motives on Novell's side.
Checking out whois isn't always the most reliable way to figure out who is behind a site.
Would you expect this on a Microsoft-owned website?
(And yes, I do work for Novell. And I don't have much of a reason to defend the site, since most of
the reasons listed don't expect Novell to survive, only to serve as a bad example.)
I, too, have been reading through the pledges at the Microsoft website, to figure out the exact wording and implications.
The "Microsoft's Patent Pledge for Non-Compensated Developers" is indeed rather useless, because it only covers creation and local use, and specifically excludes distribution.
The "Microsoft's Patent Pledge for Individual Contributors to openSUSE.org" is also not interesting,
since it covers the transfer of code from an author to SUSE, and only that and nothing else.
The "Microsoft's Patent Pledge for Hobbyist Contributors" is referenced from the above one. This should be the one that is covering the community distribution part. But is missing on the Microsoft website: Either it doesn't exist at all and the reference is a mistake, or there is a reason why it was left out from the web.
Has anyone managed to find it? Why Bradley Kuhn doesn't mention it?
The answer should be obvious: To get higher numbers.
For "Buffer to Disk", there is significant overhead caused by encoding the data with error correcting codes, sectorization, etc. This can make it use 10-15 bits per byte, with the expected performance of a 748 Mbit/sec drive being around 60-70 megabytes per second at the beginning of the drive (where rotational density of bits is highest), with 30-40 megabytes per second at the end.
For "Buffer to Host", MBytes/sec is the traditional measure. The overhead on SATA is better than traditional PATA (where for UDMA133 it's about 50%). The raw wire speed of SATA-II is 3.0 Gbit/sec, so advertising 300 Mbytes/sec is beyond realistic - even the theoretical maximum is probably less due to overhead. In benchmarks the drive achieves 180 Mbytes/sec buffered reads.
It's just pure speculation, but I guess the real reason for the antitrust lawsuit by AMD is the Turion® mobile CPU.
AMD can't sell the Turions in the white-box market, where most of its CPUs are being sold, and must rely on bigger players in the PC industry, like Dell or HP to include it in their notebooks.
After all, who builds his notebook himself at home?
Now just the fact of the existence of the lawsuit will force Intel to tone down on their rebate practices, and this may open a window for AMD to sell the chips in quantities larger than the bare
usually allowed by Intel's rebate system.
have you tried running 'jstest' and 'jscal'? 'jstest' for testing that it operates correctly and 'jscal' for changing the default calibration values if needed.
The SpaceOrb is supported as an input device and
a joystick (so it's possible to use in any game
that supports a multi-axis joystick) in Linux natively.
And most likely also the newer SpaceBall variants, because they all use USB HID.
All the drivers are GPL and included in the
standard kernel release. The CyberMan2 is
very cool for playing Descent2 on Linux.
I know it. I wrote the drivers.
It seems the project is more about developing
and marketing a new 6dof in a world where all
gaming-oriented 6dofs (the SpaceOrb, available
on e-bay for a few bucks, the CyberMan / CyberMan2) failed miserably.
Take the linear CCD array from it, add some
mechanics, and with some luck you can get
nice (in the range of megapixels) images.
These guys did it already: here
and here
Better than a webcam, and pretty good for
understanding how digital imaging works.
Btw, the problem was that 2.6.1 actually
supported the 103rd European key, and users couldn't cope with that. Now (2.6.2+) it's treated like a regular backslash key, even though they're two different keys in reality.
It's easily configurable, as everything is kept in a single, hierarchicaly structured config file.
It's very convenient to use, since you can bring up whole subtrees of services up and down with a single command.
And it's damn FAST, allowing to boot my system under three seconds from LILO to running WindowMaker desktop. It achieves that by reading just the single config time just one time and then
piping all the commands that it needs to execute
to bring the system up to a single bash instance.
I used it once, and I can't never go back and replace the init scripts on every distro I use with it.
Slashdot Mirror
Making such a beginner mistake as forgetting to connect the oxygen supply hose to the batteries ...
And the reason for that is because creating such a duality makes it seem that both approaches are equally valid. I'm sure there are many more examples ...
Not true.
If you're going downhill, on any modern car the best is to shift into a high gear (4-6th, depending o the speed you're going downhill), such that you engine is running barely above idle RPM.
Then, the ECU will shut off the fuel supply altogether, and basically go into engine braking mode instead of keeping the engine in rotation by supplying it with a trickle of fuel. The braking effect in 6th gear is however minimal and thus even a very small slope is enough to keep the car going at a constant speed.
And it isn't a general flaw in .NET - the author describes very clever ways how to use .NET applets to prepare ideal ground for a classical memory corruption attack on the browser itself. This still requires a bug in the browser or one of the plugins.
Basically what he manages to do is using a well crafted .NET DLL object putting executable code (embedded in a string constant inside the .NET DLL) to a known address, whereto he then can jump from the memory corruption exploit.
Now, to keep backwards compatibility, Microsoft did a few pretty stupid things in the implementation of the .NET applets, and because of that, putting the .NET data to a specified location in memory _AND_ marking the page executable is possible despite address space randomization and no-exec.
These implementation details can and will get fixed, though, making attacks harder again.
I suggest to read the paper, it's rather well written and very interesting.
The abstract actually tells much more than the linked article, primarily what has been researched and found.
The important bit is that this is not a new exploit, it's a way to make your memory corruption (stack or heap overflow, etc) exploit, if you find one, be able to work despite Vista's additional security measures.
Similar security enhancements are present in the Linux kernel under slightly different names: Address space randomization, non-executable stack, etc. And similar tactics could be used to circumvent them there. It's been always clear to the developers of these enhancements that they can't prevent memory corruption attacks, they just make them much harder.
So much harder that you'll need to equip your exploit code with the techniques described in the BlackHat talk, and most likely this will also limit you to only a subset of the original corruption attack vectors.
The Vista (and Linux) extra security measures aren't worthless, but they never were expected to be completely bulletproof.
After all, the only way to be perfectly safe is to not have any bugs in the software installed on your computer, which usually means no software, too.
1) Cell phones.
Cell phones use a so called RSSI value for the number of the bars. RSSI is a Relative Signal Strength Indication, which is a best guess of the device how well the data transmission will go. Most use SNR directly, some use a product of signal strength and bit error rate (BER).
The reason why it doesn't always match reality is that it's really a best guess by the phone, and reality is much more complicated than just that.
2) Laptop batteries.
Laptop batteries are using charge counters. Those are resistors with very small resistance ( 0.1 Ohm) tied to a precise voltmeter in a controller chip. By integration the controller knows rather well how much charge (how many electrons) have passed through it. With Li-Ion and Li-Pol batteries in use today, however, the situation got harder because the voltage of the battery varies a lot during discharge. Nowadays, modern batteries count energy, that is the product of charge and voltage as it moves in an out, giving a very precise output of remaining energy.
The reason some batteries die very quickly once they stop showing full is because as Li-Ion batteries age, their internal resistance increases. More energy is lost within the battery during the discharge process and the amount of energy lost (and voltage decrease) is directly proportional to the current taken from the battery. At the same time, modern devices have switching regulators which take more current when voltage decreases to provide the same flow of energy to the device. Combined, this means that once the battery voltage of an aged battery starts dropping, it drops very fast.
For cell phones, this is even harder, since they don't have charge counters - the batteries have to be cheap. There the remaining energy is guessed purely based on voltage. And old Li-Ion batteries will have almost full voltage when under light load, and fail when the load is applied, causing a phone to switch off.
Not necessarily. Carbon dating works because all newly composed organic matter is made from carbon in the atmosphere - by plants. And upper atmosphere, because it is exposed to cosmic rays, gets a fair dose of radiation, and thus our atmosphere has a percentage of the radioactive carbon-14 that has been constant over ages.
Now there is a way for a PBDE to get a carbon-14 atom in it - if it gets to upper atmosphere, or any other source of radiation, before the whale consumes it. This could just mean that PBDEs are even more widespread than thought - in atmosphere, sea water, krill, whales.
He probably used the JTAG port to take a look and play with the ARM/XScale processors, but not the Boundary Scan part of the port's capabilities. Even the article doesn't mention the Boundary Scan, which is normally used only for testing whether the processor is well and alive.
Compared to tantalum capacitors, these capacitors reach much higher capacities at the same physical volume, and the same or better ESL/ESR.
See for example here:
These aluminium electrolytic capacitors, with a solid conductive polymer electrolytic find their way even on most current mainboards, most often in the CPU DC-DC convertor circuits. They're usually easily recognizable from classic electrolytics by their small size and metal casing without a plastic sleeve.
A benefit from an all-solid-polymer capacitor mainboard is dubious, since classic alimuium electrolytic capacitors work just fine in many roles they're needed for, particularly in low-ripple-current situations.
It is generally believed that most, if not all the patents Linux potentially infringes on would fail either the obviousness or prior art tests in court.
However, again due to the sheer numbers of patents that were granted so far, it is not possible to go and check every single one whether it passes or not in court.
We always made sure that the contract contained a clause that we're free to use any information we received this way to implement and distribute a driver under the terms of the GPL, and that the other party knows about that and agrees to it. This implies that there either are no patent claims on that code, or that the relevant patents are licensed to every potential recipient of the code automatically.
We are not going to change that policy.
Btw, points 1-3 don't protect anyone from having potential patent issues, they can only help with copyright issues. For patents, it doesn't matter how you arrived to implementing one of those.
Having said that, I will not argue that the deal is all roses and doesn't have any negative sides. I, working for SuSE, do certainly feel those. But I would like you to understand that there were good reasons for it, and that there is no need to search for dark ulterior motives on Novell's side.
According to the linfo.org pages, linfo is a project of the Bellevue Linux Users Group.
Checking out whois isn't always the most reliable way to figure out who is behind a site.
Would you expect this on a Microsoft-owned website?
(And yes, I do work for Novell. And I don't have much of a reason to defend the site, since most of the reasons listed don't expect Novell to survive, only to serve as a bad example.)
The "Microsoft's Patent Pledge for Non-Compensated Developers" is indeed rather useless, because it only covers creation and local use, and specifically excludes distribution.
The "Microsoft's Patent Pledge for Individual Contributors to openSUSE.org" is also not interesting, since it covers the transfer of code from an author to SUSE, and only that and nothing else.
The "Microsoft's Patent Pledge for Hobbyist Contributors" is referenced from the above one. This should be the one that is covering the community distribution part. But is missing on the Microsoft website: Either it doesn't exist at all and the reference is a mistake, or there is a reason why it was left out from the web.
Has anyone managed to find it? Why Bradley Kuhn doesn't mention it?
The answer should be obvious: To get higher numbers.
For "Buffer to Disk", there is significant overhead caused by encoding the data with error correcting codes, sectorization, etc. This can make it use 10-15 bits per byte, with the expected performance of a 748 Mbit/sec drive being around 60-70 megabytes per second at the beginning of the drive (where rotational density of bits is highest), with 30-40 megabytes per second at the end.
For "Buffer to Host", MBytes/sec is the traditional measure. The overhead on SATA is better than traditional PATA (where for UDMA133 it's about 50%). The raw wire speed of SATA-II is 3.0 Gbit/sec, so advertising 300 Mbytes/sec is beyond realistic - even the theoretical maximum is probably less due to overhead. In benchmarks the drive achieves 180 Mbytes/sec buffered reads.
AMD can't sell the Turions in the white-box market, where most of its CPUs are being sold, and must rely on bigger players in the PC industry, like Dell or HP to include it in their notebooks.
After all, who builds his notebook himself at home?
Now just the fact of the existence of the lawsuit will force Intel to tone down on their rebate practices, and this may open a window for AMD to sell the chips in quantities larger than the bare usually allowed by Intel's rebate system.
Good luck, AMD!
have you tried running 'jstest' and 'jscal'?
'jstest' for testing that it operates correctly
and 'jscal' for changing the default calibration
values if needed.
The SpaceOrb is supported as an input device and a joystick (so it's possible to use in any game that supports a multi-axis joystick) in Linux natively.
Linux already supports the:
And most likely also the newer SpaceBall variants, because they all use USB HID.
All the drivers are GPL and included in the standard kernel release. The CyberMan2 is very cool for playing Descent2 on Linux.
I know it. I wrote the drivers.
It seems the project is more about developing and marketing a new 6dof in a world where all gaming-oriented 6dofs (the SpaceOrb, available on e-bay for a few bucks, the CyberMan / CyberMan2) failed miserably.
Take the linear CCD array from it, add some mechanics, and with some luck you can get nice (in the range of megapixels) images.
These guys did it already: here and here
Better than a webcam, and pretty good for understanding how digital imaging works.
This has already been reported earlier today.
The worm spreads through the BlueTooth interface
and requires to be run by a human after receiving.
Btw, the problem was that 2.6.1 actually supported the 103rd European key, and users couldn't cope with that. Now (2.6.2+) it's treated like a regular backslash key, even though they're two different keys in reality.
ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/ sss-0.0.1.tar.gz
It's easily configurable, as everything is kept in a single, hierarchicaly structured config file.
It's very convenient to use, since you can bring up whole subtrees of services up and down with a single command.
And it's damn FAST, allowing to boot my system under three seconds from LILO to running WindowMaker desktop. It achieves that by reading just the single config time just one time and then piping all the commands that it needs to execute to bring the system up to a single bash instance.
I used it once, and I can't never go back and replace the init scripts on every distro I use with it.
How long do your init scripts take to boot?
And don't ever send a bounce.
Send bounces only for mails not detected as either virus spam.
That would make everybody happy.