I believe one of the Sony models has a built-in LED reading light - actually I'm sure one does. They also make a lot of covers with reading lights built in. Or, you could always get a book lamp, they work even better on e-book readers than on books (no floppiness or having to move it around at all to get the whole page), and the eye-strain is far, far less than a back-lit LCD (it's about the same as paper, oddly enough).
I wouldn't buy a Kindle either, just because of lock-in. While convenient, those books are not portable to any other device. Sony does ePub now, which is a ubiquitous format - most e-book readers (except kindle of course) support it.
Seriously, if lack of light is the only reason you're not getting an e-book reader then you can't be much of a reader anyway. Buy a table lamp, or a clip-on book lamp. Either option is far cheaper than a laptop. Only a netbook could compete with the e-book reader + lamp combo in price, and that would be a bitch to read on. Though, it is certainly more usefull for doing other things.
I have a crappy old Sony PRS-500 and I love it, I think I'm going to trade up soon. And I'm definitely getting the Plastic Logic reader when it comes out, so I can comfortably read my tech books and other PDFs that end up being a pain on smaller screens.
Check out the Sony store (so far I'm sold on Sony, sorry it sounds like an advertisement) or any other reader that supports more portable formats. The newest Sony reader even does wireless 3g book-buying like the Kindle, plus it has a huge display and touchscreen. There are others out there, but Sony seems to me to have the best price-value. My reader was even a refurb and it has been rock solid for a couple years now. Plus you get direct access to Google's millions of public-domain books.
Sorry for rambling, but I can't say enough about the e-readers.
As usual, the summary writer didn't actually read the article. The OLED screen was not for the e-book reader, it was for other devices.
The e-book screen was something called Ch-LCD, which apparently is sorta similar to e-ink I guess, but with color. Also note that it is far slower than even e-ink, taking 40 seconds to produce an image on the screen. I imagine text will be better, but still, e-ink can do grey-scale images in a few seconds at the most, so while the color is nice it is definitely not practical if it takes that long to load up an image.
Why hasn't anybody tried using the yellow-green-magenta-black of printers for a color e-ink display? It should work exactly the same as producing color on an ink-jet printer.
I imagine they are working on three little balls of pigment per pixel instead of two to make color - then you could arrange them in tri-color pixels like LCDs. The color would be far lower resolution than the black/white, but I don't see that as a bad thing. That I could see as taking a long time to work out.
Actually the main advantage of e-ink in e-readers is they look like ink on paper - hence the name e-ink. Reading on even an old reader with one of the earlier e-ink displays is nearly as good as reading on paper.
That it sips power is a BONUS of the technology, not the main purpose. Most people get eye strain from looking that the harsh, polarized reflected flourescent light of an LCD display. Plus, they are lit by reflected light off the pixels themselves instead of light passed through a pixel filter, which makes them easier to read in almost every case. The only time LCDs win the readability contest is in complete darkness, and then only if you don't have a little book light for your e-ink reader. But if you have a place to plug in a laptop or desktop for a long session of reading you almost certainly have access to a lamp to read by, so it's not much of an advantage for back-lit LCDs.
Anybody who knows how flourescent bulbs actually work will tell you that the gas inside becomes a plasma. As a plasma, the gas conducts electricity, which pretty much precludes it from being an arc of electricity (though it does start as an arc, it's complicated).
To create an arc, the electric current must make a jump from a conductive electrode across a non-conductive space to another conductive electrode. The electricity super-heats the gas as it makes the jump, causing it to glow. This process actually does produce small amounts of plasma, but an arc lamp maintains the arc, while a flourescent lamp maintains the plasma. Arc lamps, I believe, tend to be a lot more power hungry than flourescents, because once in the plasma state much less electricity is needed to maintain the flourescent lamp. The gas in an arc lamp is always non-conductive, while the gas in a flourescent lamp becomes conductive. See?
A failing ballast may well produce a relatively constant arc of electricity by creating irregular spikes in current, which don't allow the plasma to fully form, but this is not the same as what happens in a functioning flourescent lamp.
I think the reason reflected light (from an external source, LCDs are actually reflected light from an internal lamp) tends to be superior is because of the lack of washout from ambient light. Since you are generally getting the light as a direct reflection from a lamp or the sun, it tends to be far brighter than what an LCD can produce. LCDs are often far dimmer than a good lamp, and the only reason we get by with them is most places we live and work are very poorly lit. They are also generally lit by reflected-flourescent light, which is much harder on the eyes (though less bright) than a nice, warm, yellow lamp.
OLEDs, however, are completely different from LCDs, and should not be confused with them in any way. I've never actually seen one in person, but from what I gather they have none of the deficiencies of LCDs. Their light isn't polarized, it isn't reflected at all and therefore has none of the washout problems LCDs have. They will almost always be brighter than an external man-made lamp, and from what I've heard even the bright sun does not wash them out. Think of how bright an LED can be, and shrink it way down to the size of a pixel, and you have OLED. They have a few of their own issues, though - they are prohibitively expensive for starters. 4.1 inches is actually relatively impressive for an OLED in any kind of consumer product. I remember a couple years ago Sony (I think) managed a prototype 15 inch OLED monitor. Trouble is, it would cost thousands of dollars even mass-produced in a time when you could get a 20 inch LCD for a couple hundred dollars. The only consumer products I know of are a few cell phones, as the screen size can be small while still being economical.
If it proves to be as easy to read as paper (from what I've heard this seems to be the case), OLED will be the way to go for a small, portable, multi-function device, while e-ink will be for the purists (reflected light or bust!) and large-format display e-readers.
So... people... um... didn't do... like, 99% of what they needed to do in the day, when it's light, back then? Funny, I thought they did, because the light of the moon is far less useful than the light of the Sun.
He's saying if all life in the solar system came from the same source, it will all look essentially the same (with overall minor variations). I'll be more specific, so you can understand the analogy.
Suppose you toss a bucket of yellow paint in five directions, making five splashes on the ground. One may land on concrete, and look completely different from the one that landed on grass, which looks totally different than the one that landed on the bush, etc. But when you take a sample of what they are all made of, you'll find they are made of exactly the same stuff: yellow paint.
For a car analogy, suppose there are five models of vehicle in existance. They are very different, some are bigger and tougher, others are smaller and faster, etc. If they were all made at a GM factory, though, then they are similar at the fundamental level - they are all made with the same type of steel, rubber, and plastic, and they have similarities in design across the board.
That's what he's talking about when he talks about all life coming from the same source. It makes it seem less likely that the rest of the universe will be teaming with life if we find that it only happened once to our solar system. In truth, the chances don't change at all, it just seems different. There could just as well be cans of red, or blue, or white paint, as well as fords and toyotas and hondas out there. We already know it can happen once, the chances that it can happen again don't really change whether it happened once and migrated across our solar system or if it happened several times in our solar system, or if it only ever happened once in our solar system. It doesn't do anything for the likelihood of life in a completely separate system.
Oh boo-hoo, I live in Alaska, in the middle of the most urban (such as it is up here) city in the state, and the best I can do is 12mb if I give an arm, two legs, and my first born child each and every month (that gets difficult after the first month).
Seriously, I'm paying $70 per month for 3mbps with a 20gb cap. The cable company sucks. DSL is more expensive for the same speed (and they can't do 12mbit), but at least there is no cap.
I actually have to buy two internet plans - one with slow, unreliable, cheap ClearWire for general browsing and the other with not quite as slow, reliable, but expensive cable for my Netflix addiction. Netflix eats 20gb fast though...
You cannot patent light, dumbass. Else the Sun is prior art. Light is not the product (i.e. the thing you produce and sell), the lightbulb is, and Tesla's bulb was vastly different than (and in many ways superior to) Edison's.
I don't think you know very much about lightbulbs (I don't either, but obviously a lot more than you do), see Edison's bulb was what they call an incandescent bulb. Big word I know, but it operates by passing electrical current through a tungsten fillament. The fillament is high-resistance, so when that resistance is overcome it gets very hot and glows brightly, giving off light. Note that the reason most incandescent bulbs are round is because in order to extend the life of the fillament it needs to be set inside a vacuum to prevent oxidization (they burn out super quick without it).
Flourescents are more complicated. A glass tube is filled with an inert gas of some type, lots of current is pumped in, some magic happens (sorry, I don't know nearly as much about flourescents off the top of my head), the inert gas becomes charged, conducts electricity, and becomes a plasma. Plasma glows quite brightly, thus, we have light.
Just so we are crystal clear, you CAN NOT PATENT LIGHT. But you CAN and DO patent LIGHTBULBS. Mmmkay?
No, it isn't. Exercising a patent, and warning companies that they may be infringing on a patent is definitely not patent trolling.
Patent trolling is very simply buying up someone else's patent, waiting for the idea to become popular and widespread, and then suing the pants off anyone and everyone who even might be infringing on the patent. It's a dangerous game, because the longer you wait the more you'll get for the lawsuits, but if you wait too long your patent claim can become nullified due to lack of action.
THAT is patent trolling, and that is not what MS does. Patent trolls don't even attempt to license their patents, or if they do it is at extortionary rates. Microsoft does try to use patents to gain competitive advantage, and you can see that as dirty tactics if you want to, but that's not patent trolling. They only actually seem to sue when their patent is threatened - as in the Tom Tom case. In case you missed it, Tom Tom refused to license the patent MS had which they infringed upon. It was not only their right to sue, if they had NOT sued they would have lost the right to sue in the future.
Chances are the reason MS only threatens to sue Linux companies and never actually sues them is because they have waited far to long for most of the patents they use to be upheld. All they would be doing is destroying business partners. By not suing, and allowing the threat to hang there, they get to cajole and coerce their partners instead. It's much more advantageous to them than becoming a patent troll - patent trolls are bottom feeders, and legitimate companies only resort to it when they are dieing.
I know you wish patents somehow meant you could never sue, but there are legitimate reasons for suing for patent infringment, namely when someone infringes on your patent! Duh!
Permissions elevation in Windows Vista and 7 performs a function very similar to sudo. If MS does not at least try to patent their version of it, it leaves them open to one of the smaller but often nastier Linux patent trolls coming back later and suing the snot out of them.
So it's a big deal.
Is it right? That depends, I honestly don't know how the Windows version differs from Sudo in any detail, but at least at the user's end it seems to be a lot more transparent and automatic.
I'm assuming you're a programmer when you say this, and as such, have you never been working on a problem, implimented a solution that works, then discussed it with a collegue who said "Why'd you do that? Just do X, Y, and Z first, then you can A, B, C it and be done" in very generic terms and had a giant light light-bulb go off in your head? You think "Oh my God, why didn't I think of that?" Well because it was a better way of doing it.
That is the kind of thing software patents should cover, though obviously on the truly unique and innovative level, not just the "something I never thought of before" level. It should also give a description of the idea that gives a competant software engineer working in the same area a light-bulb moment of their own.
MOST software patents aren't even close to that, IMO, and should never have been granted in the first place.
Lets face it, the USPTO is out of their league when it comes to software patents, and they are over-worked (from what I hear anyway) to boot. Something has to give.
Wrong, patents protect the final product. If the widget warrants a patent, person B must improve the widget in some useful, non-trivial way in order to reproduce it.
The only way person B can reproduce the widget is by licensing the patent to do so from person A. You'll note that in most patent disputes, unless the patent is for the process itself and not the product, that the two parties don't give a rat's ass about the process used to produce either item, and again, unless it's a patent of a process, most patents describe what the product does, not how it is manufactured.
Unfortunately, although software certainly uses mathematics, software is -not- mathematics. Saying software is mathematics and therefore should not be patentable or copyrightable is akin to saying mechanical engineering is mathematics and therefore not patentable. Well of course it's mathematics, but it produces a product and that product is what is patentable.
No mathematical algorithm produces anything on its own, no matter how complex it is or how difficult it was create. That is what makes math non-patentable - it produces nothing. Math needs an application to be useful, and it's that application that is potentially patentable.
In other words, if you took an algorithm and used it to produce a new cryptographic system which was faster and more secure than any previous system, you could patent it. If you took that same algorithm and built a device that would tell the best places to install sensors for survey purposes, and there was no similar way to do that already or the new device makes it better/easier/cheaper, then you could patent that as well. Two patents, two applications, one algorithm.
Get over yourselves programmers, your code is not special, logic is logic, patenting a logical procedure is about as wrong as it gets in my books.
I've found programming to be more like engineering that math, and it's certainly about a lot more than logical procedures. If this than that, sure, it also involves applying various algorithms in a way that is useful to the end user. Pure math doesn't bother with this, the math must always be applied somewhere else. That is at the heart of what makes software patentable vs mathematics, math simply doesn't produce a final product, software does. This should be easy to see, since you don't patent the source code (which contains the logic), you patent what the source code compiles into, which is the finished product.
I believe there is a place for software patents, but I also think software patents are vastly over-issued. For some reason patent officials seem to think "on a computer" is not obvious and deserves a patent.
I also think that if Patents apply to compiled software, copyright should only apply to the source code. If we consider software a "work of art", then it should not be patentable at all.
It doesn't allow for duplication if the result is the same. It allows for innovations to be added onto an existing patent, so if your different implimentation improved the original in some meaningful and non-obvious way, it should be legit.
For example, the first person who invents the wheel gets totally screwed out of his innovation if someone else is allowed to make the exact same thing (a wheel) via a different process. Now, if the new process improved the design of the wheel - say by making it lighter and stronger, then the original inventor is just too slow to profit from his idea, as something better has come along.
This is exactly the reason why a lot of software patents are complete bull, because they usually perform some mundane function, but on a computer. That alone should not be enough to make it innovative, yet we see patents awarded for such things all the time.
But are we talking failure of cookies, MITM attacks, replay attacks, authentication is too vague!
I'm not sure why you think it's too vague, they are counting the number of authentication failures, which would include all of those.
But how does that compromise a web app? XSS?
It wouldn't compromise the app itself, it would compromise the client running the app - the end user attempting to use the application. If it were an ordinary software application, you would say the compromise happens at the keyboard interface, before it even hits the application. A rough analogy, but not too far off.
How do you get from webserver running as it should to...code injection, that is the tricky part.
The first form of code injection was the buffer-overrun. A poorly written piece of software would occasionally get into a situation where it did not allocate enough address space in RAM to process the data it was working with. Often it could be forced into this situation by another program. This would cause a hard failure, but leave the address space available. At that point, a separate application could take ownership of that address space, and inject its own code with the credentials of the failed program. If it's a piece of software that has lower-level access than a normal application would, then the system has been compromised.
Buffer-overruns were fixed pretty quickly, and pretty much don't exist any more, but all code injection techniques try to exploit a situation that allows them to do the exact same thing - inject their own code into the memory space of another application, thereby bypassing whatever security measures would ordinarily prevent it from running that code in the first place. Modern operating systems have various ways to protect against this, but a vulnerability in the application itself could still present problems - and of course a vulnerability in the OS could as well.
Code injection is the oldest class of security vulnerability there is (aside from physical theft), it is ever evolving and it is probably never going to go away. Any time you hear of a vulnerability that allows "arbitrary code execution", you're dealing with code injection of some sort.
I'm not sure I agree, Firefox should be vetting the plugins it allows to attach to it. Also, the plugins are tied to the browser, so any vulnerability that pops up is at least indirectly related to the way the browser handles the plugin.
In any case, if we are making a distinction between plugins and extensions (I assume we are), then IE has just as many plugins as Firefox, and that should not be the cause of the disparity unless there is a fundamental flaw in the way Firefox handles plugins. If we are including extensions, then I think it's very much Firefox's fault for allowing what should be low priority, sandboxed code to do damage to the system.
Telnet is also pretty much universally disabled on outward facing (web) servers, and nearly universally disabled on inward facing servers. Microsoft desktop and server products have disabled telnet by default since at least Windows XP, so catching someone who doesn't know better is even a long shot.
I wouldn't suggest you hinge your massive scheme to conquer the world on the ability to do anything at all with telnet.
You realize they actually do that when building houses, right?
Tar paper and Visqueen go all over the house before the outer shingles (or whatever roofing/siding material you use) go on. It creates a moisture barrier that keeps any leakage that may get through the shingles from actually entering the house. It takes a hole in BOTH layers to cause a leak. They like to call these "vapor barriors", as they go beyond preventing large droplets of water through and actually seal the house from vapor if properly applied. It's simple, cheap, and critical to preventing mildew problems later on.
In other words, geeks should really stay away from making construction analogies unless they are construction geeks, because you pretty much made the opposite point you were going for.
14% authentication (what sort of authentication flaws?)
Server X accepts client Y as authentic, but client Y is not authentic. It does not matter how you arrived at the mis-authentication if all you are doing is tallying the number of authentication failures.
8% browser ? (What does that mean?)
The browser itself has an exploitable vulnerability.
7% code injection (injection into where?)
Running memory on the OS, that's where all code injection goes.
To relate it to the SQL stat, SQL injection would be injecting SQL into a running database query.
Ummm... ActiveX is a separate technology from web browsers, I'm not sure of the objection here.
ActiveX is how pre-.Net Win32 applications primarily accessed.dll's. They were a response to the dll problem programmers had in the Win95/98 era (essentially version control, but other things as well), and while they made things better we still had DLL hell..Net nearly solves this, and makes ActiveX.dlls unnecessary, though now specific versions of.Net are necessary. Overall it's better though, as you can have more than one version of.Net on your system at a time.
There is a HUGE difference between generic Win32 ActiveX, and web-based ActiveX. The latter is a small sub-set of the former, and has been considered for many years to be a very insecure way of handling the web. Thus, IE since IE6 has generally wanted you to jump through several steps before allowing ActiveX content in your browser.
If it's a flaw in how the OS handles a legitimate request from the browser, then it's a flaw in the OS.
OF COURSE you wouldn't count that. There have been similar flaws that were exploitable via ANY browser, and those would not be counted against the browsers either.
Another way to look at it, is did they have to fix IE to fix the problem? If no, it's obviously not a problem with IE. It's like saying code injection via a browser vulnerability is an exploit in your router - of course it isn't, it's an exploit in the browser. Same thing with this issue, it was a problem in the OS, not the browser.
Slashdot Mirror
I believe one of the Sony models has a built-in LED reading light - actually I'm sure one does. They also make a lot of covers with reading lights built in. Or, you could always get a book lamp, they work even better on e-book readers than on books (no floppiness or having to move it around at all to get the whole page), and the eye-strain is far, far less than a back-lit LCD (it's about the same as paper, oddly enough).
I wouldn't buy a Kindle either, just because of lock-in. While convenient, those books are not portable to any other device. Sony does ePub now, which is a ubiquitous format - most e-book readers (except kindle of course) support it.
Seriously, if lack of light is the only reason you're not getting an e-book reader then you can't be much of a reader anyway. Buy a table lamp, or a clip-on book lamp. Either option is far cheaper than a laptop. Only a netbook could compete with the e-book reader + lamp combo in price, and that would be a bitch to read on. Though, it is certainly more usefull for doing other things.
I have a crappy old Sony PRS-500 and I love it, I think I'm going to trade up soon. And I'm definitely getting the Plastic Logic reader when it comes out, so I can comfortably read my tech books and other PDFs that end up being a pain on smaller screens.
Check out the Sony store (so far I'm sold on Sony, sorry it sounds like an advertisement) or any other reader that supports more portable formats. The newest Sony reader even does wireless 3g book-buying like the Kindle, plus it has a huge display and touchscreen. There are others out there, but Sony seems to me to have the best price-value. My reader was even a refurb and it has been rock solid for a couple years now. Plus you get direct access to Google's millions of public-domain books.
Sorry for rambling, but I can't say enough about the e-readers.
As usual, the summary writer didn't actually read the article. The OLED screen was not for the e-book reader, it was for other devices.
The e-book screen was something called Ch-LCD, which apparently is sorta similar to e-ink I guess, but with color. Also note that it is far slower than even e-ink, taking 40 seconds to produce an image on the screen. I imagine text will be better, but still, e-ink can do grey-scale images in a few seconds at the most, so while the color is nice it is definitely not practical if it takes that long to load up an image.
Why hasn't anybody tried using the yellow-green-magenta-black of printers for a color e-ink display? It should work exactly the same as producing color on an ink-jet printer.
I imagine they are working on three little balls of pigment per pixel instead of two to make color - then you could arrange them in tri-color pixels like LCDs. The color would be far lower resolution than the black/white, but I don't see that as a bad thing. That I could see as taking a long time to work out.
Actually the main advantage of e-ink in e-readers is they look like ink on paper - hence the name e-ink. Reading on even an old reader with one of the earlier e-ink displays is nearly as good as reading on paper.
That it sips power is a BONUS of the technology, not the main purpose. Most people get eye strain from looking that the harsh, polarized reflected flourescent light of an LCD display. Plus, they are lit by reflected light off the pixels themselves instead of light passed through a pixel filter, which makes them easier to read in almost every case. The only time LCDs win the readability contest is in complete darkness, and then only if you don't have a little book light for your e-ink reader. But if you have a place to plug in a laptop or desktop for a long session of reading you almost certainly have access to a lamp to read by, so it's not much of an advantage for back-lit LCDs.
Anybody who knows how flourescent bulbs actually work will tell you that the gas inside becomes a plasma. As a plasma, the gas conducts electricity, which pretty much precludes it from being an arc of electricity (though it does start as an arc, it's complicated).
To create an arc, the electric current must make a jump from a conductive electrode across a non-conductive space to another conductive electrode. The electricity super-heats the gas as it makes the jump, causing it to glow. This process actually does produce small amounts of plasma, but an arc lamp maintains the arc, while a flourescent lamp maintains the plasma. Arc lamps, I believe, tend to be a lot more power hungry than flourescents, because once in the plasma state much less electricity is needed to maintain the flourescent lamp. The gas in an arc lamp is always non-conductive, while the gas in a flourescent lamp becomes conductive. See?
A failing ballast may well produce a relatively constant arc of electricity by creating irregular spikes in current, which don't allow the plasma to fully form, but this is not the same as what happens in a functioning flourescent lamp.
I think the reason reflected light (from an external source, LCDs are actually reflected light from an internal lamp) tends to be superior is because of the lack of washout from ambient light. Since you are generally getting the light as a direct reflection from a lamp or the sun, it tends to be far brighter than what an LCD can produce. LCDs are often far dimmer than a good lamp, and the only reason we get by with them is most places we live and work are very poorly lit. They are also generally lit by reflected-flourescent light, which is much harder on the eyes (though less bright) than a nice, warm, yellow lamp.
OLEDs, however, are completely different from LCDs, and should not be confused with them in any way. I've never actually seen one in person, but from what I gather they have none of the deficiencies of LCDs. Their light isn't polarized, it isn't reflected at all and therefore has none of the washout problems LCDs have. They will almost always be brighter than an external man-made lamp, and from what I've heard even the bright sun does not wash them out. Think of how bright an LED can be, and shrink it way down to the size of a pixel, and you have OLED. They have a few of their own issues, though - they are prohibitively expensive for starters. 4.1 inches is actually relatively impressive for an OLED in any kind of consumer product. I remember a couple years ago Sony (I think) managed a prototype 15 inch OLED monitor. Trouble is, it would cost thousands of dollars even mass-produced in a time when you could get a 20 inch LCD for a couple hundred dollars. The only consumer products I know of are a few cell phones, as the screen size can be small while still being economical.
If it proves to be as easy to read as paper (from what I've heard this seems to be the case), OLED will be the way to go for a small, portable, multi-function device, while e-ink will be for the purists (reflected light or bust!) and large-format display e-readers.
So... people... um... didn't do... like, 99% of what they needed to do in the day, when it's light, back then? Funny, I thought they did, because the light of the moon is far less useful than the light of the Sun.
I'm guessing none.
What do I win?
He's saying if all life in the solar system came from the same source, it will all look essentially the same (with overall minor variations). I'll be more specific, so you can understand the analogy.
Suppose you toss a bucket of yellow paint in five directions, making five splashes on the ground. One may land on concrete, and look completely different from the one that landed on grass, which looks totally different than the one that landed on the bush, etc. But when you take a sample of what they are all made of, you'll find they are made of exactly the same stuff: yellow paint.
For a car analogy, suppose there are five models of vehicle in existance. They are very different, some are bigger and tougher, others are smaller and faster, etc. If they were all made at a GM factory, though, then they are similar at the fundamental level - they are all made with the same type of steel, rubber, and plastic, and they have similarities in design across the board.
That's what he's talking about when he talks about all life coming from the same source. It makes it seem less likely that the rest of the universe will be teaming with life if we find that it only happened once to our solar system. In truth, the chances don't change at all, it just seems different. There could just as well be cans of red, or blue, or white paint, as well as fords and toyotas and hondas out there. We already know it can happen once, the chances that it can happen again don't really change whether it happened once and migrated across our solar system or if it happened several times in our solar system, or if it only ever happened once in our solar system. It doesn't do anything for the likelihood of life in a completely separate system.
Oh boo-hoo, I live in Alaska, in the middle of the most urban (such as it is up here) city in the state, and the best I can do is 12mb if I give an arm, two legs, and my first born child each and every month (that gets difficult after the first month).
Seriously, I'm paying $70 per month for 3mbps with a 20gb cap. The cable company sucks. DSL is more expensive for the same speed (and they can't do 12mbit), but at least there is no cap.
I actually have to buy two internet plans - one with slow, unreliable, cheap ClearWire for general browsing and the other with not quite as slow, reliable, but expensive cable for my Netflix addiction. Netflix eats 20gb fast though...
End result is the same (produce light)
You cannot patent light, dumbass. Else the Sun is prior art. Light is not the product (i.e. the thing you produce and sell), the lightbulb is, and Tesla's bulb was vastly different than (and in many ways superior to) Edison's.
I don't think you know very much about lightbulbs (I don't either, but obviously a lot more than you do), see Edison's bulb was what they call an incandescent bulb. Big word I know, but it operates by passing electrical current through a tungsten fillament. The fillament is high-resistance, so when that resistance is overcome it gets very hot and glows brightly, giving off light. Note that the reason most incandescent bulbs are round is because in order to extend the life of the fillament it needs to be set inside a vacuum to prevent oxidization (they burn out super quick without it).
Flourescents are more complicated. A glass tube is filled with an inert gas of some type, lots of current is pumped in, some magic happens (sorry, I don't know nearly as much about flourescents off the top of my head), the inert gas becomes charged, conducts electricity, and becomes a plasma. Plasma glows quite brightly, thus, we have light.
Just so we are crystal clear, you CAN NOT PATENT LIGHT. But you CAN and DO patent LIGHTBULBS. Mmmkay?
(sorry, I'm apparently grumpy this morning)
This is the very definition of patent trolling.
No, it isn't. Exercising a patent, and warning companies that they may be infringing on a patent is definitely not patent trolling.
Patent trolling is very simply buying up someone else's patent, waiting for the idea to become popular and widespread, and then suing the pants off anyone and everyone who even might be infringing on the patent. It's a dangerous game, because the longer you wait the more you'll get for the lawsuits, but if you wait too long your patent claim can become nullified due to lack of action.
THAT is patent trolling, and that is not what MS does. Patent trolls don't even attempt to license their patents, or if they do it is at extortionary rates. Microsoft does try to use patents to gain competitive advantage, and you can see that as dirty tactics if you want to, but that's not patent trolling. They only actually seem to sue when their patent is threatened - as in the Tom Tom case. In case you missed it, Tom Tom refused to license the patent MS had which they infringed upon. It was not only their right to sue, if they had NOT sued they would have lost the right to sue in the future.
Chances are the reason MS only threatens to sue Linux companies and never actually sues them is because they have waited far to long for most of the patents they use to be upheld. All they would be doing is destroying business partners. By not suing, and allowing the threat to hang there, they get to cajole and coerce their partners instead. It's much more advantageous to them than becoming a patent troll - patent trolls are bottom feeders, and legitimate companies only resort to it when they are dieing.
I know you wish patents somehow meant you could never sue, but there are legitimate reasons for suing for patent infringment, namely when someone infringes on your patent! Duh!
Permissions elevation in Windows Vista and 7 performs a function very similar to sudo. If MS does not at least try to patent their version of it, it leaves them open to one of the smaller but often nastier Linux patent trolls coming back later and suing the snot out of them.
So it's a big deal.
Is it right? That depends, I honestly don't know how the Windows version differs from Sudo in any detail, but at least at the user's end it seems to be a lot more transparent and automatic.
I'm assuming you're a programmer when you say this, and as such, have you never been working on a problem, implimented a solution that works, then discussed it with a collegue who said "Why'd you do that? Just do X, Y, and Z first, then you can A, B, C it and be done" in very generic terms and had a giant light light-bulb go off in your head? You think "Oh my God, why didn't I think of that?" Well because it was a better way of doing it.
That is the kind of thing software patents should cover, though obviously on the truly unique and innovative level, not just the "something I never thought of before" level. It should also give a description of the idea that gives a competant software engineer working in the same area a light-bulb moment of their own.
MOST software patents aren't even close to that, IMO, and should never have been granted in the first place.
Lets face it, the USPTO is out of their league when it comes to software patents, and they are over-worked (from what I hear anyway) to boot. Something has to give.
Sorry, I apparently completely misread the post. So long as the widgets weren't part of the patent there would be nothing stopping person B.
Wrong, patents protect the final product. If the widget warrants a patent, person B must improve the widget in some useful, non-trivial way in order to reproduce it.
The only way person B can reproduce the widget is by licensing the patent to do so from person A. You'll note that in most patent disputes, unless the patent is for the process itself and not the product, that the two parties don't give a rat's ass about the process used to produce either item, and again, unless it's a patent of a process, most patents describe what the product does, not how it is manufactured.
Unfortunately, although software certainly uses mathematics, software is -not- mathematics. Saying software is mathematics and therefore should not be patentable or copyrightable is akin to saying mechanical engineering is mathematics and therefore not patentable. Well of course it's mathematics, but it produces a product and that product is what is patentable.
No mathematical algorithm produces anything on its own, no matter how complex it is or how difficult it was create. That is what makes math non-patentable - it produces nothing. Math needs an application to be useful, and it's that application that is potentially patentable.
In other words, if you took an algorithm and used it to produce a new cryptographic system which was faster and more secure than any previous system, you could patent it. If you took that same algorithm and built a device that would tell the best places to install sensors for survey purposes, and there was no similar way to do that already or the new device makes it better/easier/cheaper, then you could patent that as well. Two patents, two applications, one algorithm.
Get over yourselves programmers, your code is not special, logic is logic, patenting a logical procedure is about as wrong as it gets in my books.
I've found programming to be more like engineering that math, and it's certainly about a lot more than logical procedures. If this than that, sure, it also involves applying various algorithms in a way that is useful to the end user. Pure math doesn't bother with this, the math must always be applied somewhere else. That is at the heart of what makes software patentable vs mathematics, math simply doesn't produce a final product, software does. This should be easy to see, since you don't patent the source code (which contains the logic), you patent what the source code compiles into, which is the finished product.
I believe there is a place for software patents, but I also think software patents are vastly over-issued. For some reason patent officials seem to think "on a computer" is not obvious and deserves a patent.
I also think that if Patents apply to compiled software, copyright should only apply to the source code. If we consider software a "work of art", then it should not be patentable at all.
It doesn't allow for duplication if the result is the same. It allows for innovations to be added onto an existing patent, so if your different implimentation improved the original in some meaningful and non-obvious way, it should be legit.
For example, the first person who invents the wheel gets totally screwed out of his innovation if someone else is allowed to make the exact same thing (a wheel) via a different process. Now, if the new process improved the design of the wheel - say by making it lighter and stronger, then the original inventor is just too slow to profit from his idea, as something better has come along.
This is exactly the reason why a lot of software patents are complete bull, because they usually perform some mundane function, but on a computer. That alone should not be enough to make it innovative, yet we see patents awarded for such things all the time.
I think, therefore I am.
Now gimme gimme gimme!
But are we talking failure of cookies, MITM attacks, replay attacks, authentication is too vague!
I'm not sure why you think it's too vague, they are counting the number of authentication failures, which would include all of those.
But how does that compromise a web app? XSS?
It wouldn't compromise the app itself, it would compromise the client running the app - the end user attempting to use the application. If it were an ordinary software application, you would say the compromise happens at the keyboard interface, before it even hits the application. A rough analogy, but not too far off.
How do you get from webserver running as it should to ...code injection, that is the tricky part.
The first form of code injection was the buffer-overrun. A poorly written piece of software would occasionally get into a situation where it did not allocate enough address space in RAM to process the data it was working with. Often it could be forced into this situation by another program. This would cause a hard failure, but leave the address space available. At that point, a separate application could take ownership of that address space, and inject its own code with the credentials of the failed program. If it's a piece of software that has lower-level access than a normal application would, then the system has been compromised.
Buffer-overruns were fixed pretty quickly, and pretty much don't exist any more, but all code injection techniques try to exploit a situation that allows them to do the exact same thing - inject their own code into the memory space of another application, thereby bypassing whatever security measures would ordinarily prevent it from running that code in the first place. Modern operating systems have various ways to protect against this, but a vulnerability in the application itself could still present problems - and of course a vulnerability in the OS could as well.
Code injection is the oldest class of security vulnerability there is (aside from physical theft), it is ever evolving and it is probably never going to go away. Any time you hear of a vulnerability that allows "arbitrary code execution", you're dealing with code injection of some sort.
I'm not sure I agree, Firefox should be vetting the plugins it allows to attach to it. Also, the plugins are tied to the browser, so any vulnerability that pops up is at least indirectly related to the way the browser handles the plugin.
In any case, if we are making a distinction between plugins and extensions (I assume we are), then IE has just as many plugins as Firefox, and that should not be the cause of the disparity unless there is a fundamental flaw in the way Firefox handles plugins. If we are including extensions, then I think it's very much Firefox's fault for allowing what should be low priority, sandboxed code to do damage to the system.
Telnet is also pretty much universally disabled on outward facing (web) servers, and nearly universally disabled on inward facing servers. Microsoft desktop and server products have disabled telnet by default since at least Windows XP, so catching someone who doesn't know better is even a long shot.
I wouldn't suggest you hinge your massive scheme to conquer the world on the ability to do anything at all with telnet.
You realize they actually do that when building houses, right?
Tar paper and Visqueen go all over the house before the outer shingles (or whatever roofing/siding material you use) go on. It creates a moisture barrier that keeps any leakage that may get through the shingles from actually entering the house. It takes a hole in BOTH layers to cause a leak. They like to call these "vapor barriors", as they go beyond preventing large droplets of water through and actually seal the house from vapor if properly applied. It's simple, cheap, and critical to preventing mildew problems later on.
In other words, geeks should really stay away from making construction analogies unless they are construction geeks, because you pretty much made the opposite point you were going for.
14% authentication (what sort of authentication flaws?)
Server X accepts client Y as authentic, but client Y is not authentic. It does not matter how you arrived at the mis-authentication if all you are doing is tallying the number of authentication failures.
8% browser ? (What does that mean?)
The browser itself has an exploitable vulnerability.
7% code injection (injection into where?)
Running memory on the OS, that's where all code injection goes.
To relate it to the SQL stat, SQL injection would be injecting SQL into a running database query.
Does that help?
Ummm... ActiveX is a separate technology from web browsers, I'm not sure of the objection here.
ActiveX is how pre-.Net Win32 applications primarily accessed .dll's. They were a response to the dll problem programmers had in the Win95/98 era (essentially version control, but other things as well), and while they made things better we still had DLL hell. .Net nearly solves this, and makes ActiveX .dlls unnecessary, though now specific versions of .Net are necessary. Overall it's better though, as you can have more than one version of .Net on your system at a time.
There is a HUGE difference between generic Win32 ActiveX, and web-based ActiveX. The latter is a small sub-set of the former, and has been considered for many years to be a very insecure way of handling the web. Thus, IE since IE6 has generally wanted you to jump through several steps before allowing ActiveX content in your browser.
If it's a flaw in how the OS handles a legitimate request from the browser, then it's a flaw in the OS.
OF COURSE you wouldn't count that. There have been similar flaws that were exploitable via ANY browser, and those would not be counted against the browsers either.
Another way to look at it, is did they have to fix IE to fix the problem? If no, it's obviously not a problem with IE. It's like saying code injection via a browser vulnerability is an exploit in your router - of course it isn't, it's an exploit in the browser. Same thing with this issue, it was a problem in the OS, not the browser.