Re:What's wrong with national IDs?
on
Beyond Fear
·
· Score: 1
IMO, simple legislation that provides baseline standards for government-issued ID cards (eg, driver licenses) to have anti-fraud features are all that's needed.
You obviously don't track this stuff closely. There've been a couple of states that have done something along these lines, complete with "unforgeable" drivers licenses.
The result was DMV offices being broken into and blank cards and the machines to make them being stolen.
Re:there is a national ID system
on
Beyond Fear
·
· Score: 3, Interesting
And California is about to massively devalue that ID by issuing drivers licenses to undocumented (aka illegal) aliens.
Logically, every other state in the union should refuse to recognize a CA drivers license as a valid ID, except maybe as proof of the ability to drive a car (about the same utility as the "international drivers license" you can get). I'm sure Californians will be real happy when TSA stops accepting their DLs as valid ID next time they try to board a plane.
You want a national ID? Get a passport.
Re:Here is a way for security
on
Beyond Fear
·
· Score: 1
This is so dumb it's probably a troll, but on the offchance it's not:
You're confusing "security" with "privacy". A few points which are clearly anti-security:
3. Use cash to pay your share of rent/utilities 4. Use throw-away cell phones paid with cash 5. Use calling cards vended for cash via
vending machines 7. Work for cash
Carrying all that cash around makes you a target.
7. Work for cash (under the counter
That makes you a target known to less than honest types (if they're willing to pay under the counter) and a target known to not want involvement with the authorites, i.e, a prime target.
9. Travel via thumbing.
Sure, so you can be picked up by who knows who and taken to nobody knows where...
10. Get around as much as possible via bike/skate/walking.
Yes, that makes you a much easier target for muggers, or just plain being hit by a car.
Security? I think not.
(And while the odds of any of the above may be low, they're higher than the odds of something terrible happening to you just because you own a car or use a credit card -- unless you're already a fugitive.)
However, the width of the individual color pixels is the same as the that of the luma information.
No it's not. We're talking about the visual output here, not whatever signals are input (which are quite different for NTSC vs digital LCD).
High luma spacial frequencies do not mean that the luminance signal is a melange of chroma and luma.
They do if the signal is pretending to be a composite signal rather than pure luminance (as with the Apple II).
However, when you push the frequency of the luma signal into the chroma band, you get color. That's nothing but a decoder artifact.
Exactly, and that's what Woz's circuit took advantage of. Feeding that same signal into a high rez monochrome monitor reveals the higher frequency (ie subpixel) luma pattern. NB, a B&W TV is not a high rez monochrome monitor.
Microsoft's subpixel antialiasing has nothing to do with NTSC signals
Quite right, I didn't say that it did. It does, however, work by feeding a pixel color value to the driver to result in selected portions of the pixel being illuminated (ie, subpixel addressing).
you can't affect the luma signal by doing *anything* to the chroma.
No, but you can affect the luma signal by your choice of color values to send to the video driver.
True free market capitalism, yes. Government tends to dicka around with that by throwing in subsidies here and special taxes there. Then there's the cost of whatever damage is done to the commons (air, water, etc) that doesn't figure into the power or dollar equation. (Well, it might figure into the dollar part as part of taxes or set-asides for cleanup, but often not.)
(Don't get me wrong, I think cheap solar power would be a great thing. So would cheap nuke power -- far cleaner than coal.)
No one ever mentioned anything about where THAT code may have come from before it was introduced into SYSV.
You did, when you wrote "they put SYSV code in the Linux codebase."
The phrase "SYSV code" implies a certain provenance, that it originated in SYSV. Microsoft uses Berkeley code in its FTP program. If you independently write an FTP program based on the BSD code, is it correct to say that "you put Microsoft code in your FTP program"?
This would appear to someone with color vision as an alternating sequence of magenta and green stripes (ack!) three of each. To a colorblind person, it appears as nine each alternating light and dark stripes. Same thing applies to displaying an Apple II composite video signal on a monochrome monitor -- instead of magenta and green stripes, you get a tighter pattern of white (or amber or green, depending on the monitor) and black stripes.
Under NTSC, luminance is constant and independent of chroma.
Not in a composite signal, it's not. Hence the name -- it's a composite of the chroma and luma signals, and with high luma spatial frequencies you get chroma artifacts -- that was the whole point of Woz's video circuitry. As far as the rest of the computer was concerned, you sent a color pixel value to the video circuitry and got a color pixel on the screen (assuming composite color TV). But because of the implementation detail, if you were using a monochrome screen you could send a color pixel to the video circuitry and get a specific set of subpixels illuminated.
You can't pick a color and get it to affect the luma at all.
Sure, as I illustrated above. You pick the color to affect the luma at a specific location. If you couldn't, then Microsoft's subpixel antialiasing wouldn't work.
The claim, or the method of implementing the claim?
Given the claim alone as a requirement ("we need a method to do X and Y"), for many patents yes, the method is obvious to one skilled. Not always, and sure, those nonobvious methods deserve patents.
As for the subpixel thing -- you're getting hung up on the hardware, which is irrelevant because in both cases, the hardware existed before the method. The hardware is not designed to allow sub-pixel addressing (and the Apple II video is certainly based on pixels, it's the force-fit of pixelated video into an NTSC waveform that makes the trick work), the method (same in both cases) just takes advantage of the fact that in both an NTSC signal and an LCD screen, the luma resolution is higher than the chroma resolution, and there is a fixed relationship between the two. The method of picking a particular chroma value to address the luminence component of the display "pixel" will work for any display technology where that is true.
Note carefully, we're not talking about the use of Woz's careful timing of luminance pulses to confuse NTSC TV circuits into displaying color, we're talking about programmers taking advantage of that implementation detail to do subpixel addressing on a monochrome display -- just as the LCD trick is only really useful for high-contrast (black on white or vice versa) text display.
I am just saying that their case is strengthening.
And if you pee in the Sahara, you could say that the desert is getting wetter. Either way it doesn't amount to much.
Who is to say that this is all of the code lines in question?
SGI. In the letter. They said that they'd searched the rest of the SysV code (they have a license, remember?) and only found a few possible instances, which they're fixing. You did read the letter, didn't you?
Making fun of SCO won't make them go away.
Really? Dang!
How about if we make fun of you, will you go away?
Now SGI is ADMITTING that they put SYSV code in the Linux codebase.
No they're not. They're saying that they found code that happens to match some Sys V code in what they submitted -- less than 0.02% worth. The exact provenance of that code isn't clear, SysV may have got it from the same place SGI did. Your statement implies several levels of culpability that is just plain not in the SGI letter.
Whether or not it has been removed is IMMATERIAL for purposes of this case.
What case? So far the only "case" (lawsuit) is between IBM and SCO, and between RedHat and SCO. IF SCO decides to launch yet another lawsuit and sue SGI for copyright infringment (and remember, SCO has NOT made any copyright complaints against IBM (but IBM has against SCO)), then there may be a case. But SGI's action in removing the questionable code is VERY MATERIAL -- it limits SCO's claims. (Furthermore, since SCO has so far refused to reveal what code it thinks infringes, it may have no claim because it hasn't taken the necessary steps to mitigate damage.)
200 lines of code out of one million is about the same as four or five lines of text out of a 500 page book. (And note these 200 lines were scattered over several modules, not one contiguous block.)
Or about the same as less than one syllable out of a song.
And no, they're not "admitting" anything, just describing what they found and how they're fixing it.
Microsoft's patent covers non-fatal program failures as well.
So, what's a "non-fatal program failure"? Does that mean it's just wounded, but will get better? Does that mean the program is going to phone home every time the user tries to open the wrong kind of file or the app runs out of memory or the user makes an error? I hope Microsoft is planning on increasing their bandwidth...
Most patents are actually about some marginally improved twist on a mature technology.
Yeah, which is why most patents are obvious to someone skilled in the art. That latter phrase is a key part of the "obviousness" test, and what may well be unobvious to the lay person or the person only casually familiar with an art really is obvious to someone who has practised it for years.
Oh, and your comparison of subpixel addressing is misguided. Yes, Woz's color generation circuit per se didn't have anything to do with subpixel addressing -- except that it took advantage of the well known (to video engineers, anyway) aliasing effect of a high spatial frequency monochrome signal on the NTSC chroma signal (which is why you shouldn't wear pin-stripes on camera). Inverting that makes a direct relationship between color and specific subpixel areas that get illuminated, just as with the LCD-based subpixel addressing method. They are both a simple mapping of subpixel-area-desired -> pixel-color. The fact that the reasons it works is different for LCDs and synthesized NTSC video is irrelevant to the fact that the same method is used.
Blue is too peaceful. RED scares the crap out of end users.
Which is exactly why MS's SODs are blue. Do you think Redmond wants to put up with the calls they'd get and the general aversion to the product with red screens? (As if blue weren't bad enough.)
Come to think of it, I'd be surprised if there wasn't a Linux printer driver to do the same thing....
And if there isn't, it's easy enough to set up a custom print queue to do so. (Just pass the dvi, ps, etc output through the appropriate *2pdf filter). Easy enough with printcap, anyway. I assume the same can be done with CUPS.
Yep, and the guy responsible for SGI betting on NT, Rick Belluzzo, went on to head up Microsoft's internet operations. A reward for a job well done, even as SGI was tanking?
Often times a scene will have some sort of issue that you otherwise wouldn't see,
Remember the "Genesis planet" sequence from Star Trek - The Wrath of Kahn? Dates back about 20 years. Obvious CG -- it was supposed to be -- animation of a planet coalescing, mountains rising, etc as the POV swept in and across the surface. Just one problem, the damn mountain range kept rising right into the flight path. They ended up hacking the software so that a canyon opens up just as the POV gets to the mountain range and can fly through it.
That much I can confirm from watching the video. What I can't confirm, that the ILM programmer who told this story to me said, is that carved onto the canyon walls is (are?) the name(s) of the programmer(s) who did that hack. (Too blurred in the video).
I should take my own advice and read the followups to the followups.
Eric Andersen's reply to Rob Landley points out that Cisco has had quite a few months (and several lawyer letters) to get into compliance, and are foot-dragging. (Although Linksys' letter seems to confirm that they outsourced the code development and they may not have the source themselves. Stupid.)
In particular, Rob Landley's well thought out response.
If Cisco/Linksys is deliberately violating the GPL, then yes, they should be raked over the coals as appropriate. However, given that they've already tried to cooperate with the GPL, it may be that there was just a disconnect between the guys putting stuff up on the website and the actual developers of the Linksys kernel (which, as Landley points out, might even have been outsourced -- and Cisco is probably pretty upset with them about now.)
it's a limit because the maximum velocity for a space craft is the velocity with which it ejects its fuel.
No, it isn't. You just have to carry more fuel if you want to exceed your exhaust velocity. This is basic physics. Review the rocket equation. Current rockets routinely exceed their exhaust velocity by several times. (NB - this applies to rockets carrying -- and hence accelerating -- their fuel. A scramjet has a problem with this -- which is why scramjets are really a silly idea for Earth-to-orbit propulsion.)
(Of course, this falls down at relativistic speeds, you aren't going to exceed an exhaust velocity of c no matter how much fuel you're carrying.)
Higher exhaust velocity means more momentum exchange per gram of propellant, which is the same as saying a higher specific impulse, which means a given mass of high speed propellant will result in greater delta-v than a low speed propellant.
Slashdot Mirror
IMO, simple legislation that provides baseline standards for government-issued ID cards (eg, driver licenses) to have anti-fraud features are all that's needed.
You obviously don't track this stuff closely. There've been a couple of states that have done something along these lines, complete with "unforgeable" drivers licenses.
The result was DMV offices being broken into and blank cards and the machines to make them being stolen.
And California is about to massively devalue that ID by issuing drivers licenses to undocumented (aka illegal) aliens.
Logically, every other state in the union should refuse to recognize a CA drivers license as a valid ID, except maybe as proof of the ability to drive a car (about the same utility as the "international drivers license" you can get). I'm sure Californians will be real happy when TSA stops accepting their DLs as valid ID next time they try to board a plane.
You want a national ID? Get a passport.
This is so dumb it's probably a troll, but on the offchance it's not:
You're confusing "security" with "privacy". A few points which are clearly anti-security:
3. Use cash to pay your share of rent/utilities
4. Use throw-away cell phones paid with cash
5. Use calling cards vended for cash via
vending machines
7. Work for cash
Carrying all that cash around makes you a target.
7. Work for cash (under the counter
That makes you a target known to less than honest types (if they're willing to pay under the counter) and a target known to not want involvement with the authorites, i.e, a prime target.
9. Travel via thumbing.
Sure, so you can be picked up by who knows who and taken to nobody knows where...
10. Get around as much as possible via bike/skate/walking.
Yes, that makes you a much easier target for muggers, or just plain being hit by a car.
Security? I think not.
(And while the odds of any of the above may be low, they're higher than the odds of something terrible happening to you just because you own a car or use a credit card -- unless you're already a fugitive.)
However, the width of the individual color pixels is the same as the that of the luma information.
No it's not. We're talking about the visual output here, not whatever signals are input (which are quite different for NTSC vs digital LCD).
High luma spacial frequencies do not mean that the luminance signal is a melange of chroma and luma.
They do if the signal is pretending to be a composite signal rather than pure luminance (as with the Apple II).
However, when you push the frequency of the luma signal into the chroma band, you get color. That's nothing but a decoder artifact.
Exactly, and that's what Woz's circuit took advantage of. Feeding that same signal into a high rez monochrome monitor reveals the higher frequency (ie subpixel) luma pattern. NB, a B&W TV is not a high rez monochrome monitor.
Microsoft's subpixel antialiasing has nothing to do with NTSC signals
Quite right, I didn't say that it did. It does, however, work by feeding a pixel color value to the driver to result in selected portions of the pixel being illuminated (ie, subpixel addressing).
you can't affect the luma signal by doing *anything* to the chroma.
No, but you can affect the luma signal by your choice of color values to send to the video driver.
True free market capitalism, yes. Government tends to dicka around with that by throwing in subsidies here and special taxes there. Then there's the cost of whatever damage is done to the commons (air, water, etc) that doesn't figure into the power or dollar equation. (Well, it might figure into the dollar part as part of taxes or set-asides for cleanup, but often not.)
(Don't get me wrong, I think cheap solar power would be a great thing. So would cheap nuke power -- far cleaner than coal.)
Hm. And just how much power did it take to manufacture those solar panels?
No one ever mentioned anything about where THAT code may have come from before it was introduced into SYSV.
You did, when you wrote "they put SYSV code in the Linux codebase."
The phrase "SYSV code" implies a certain provenance, that it originated in SYSV. Microsoft uses Berkeley code in its FTP program. If you independently write an FTP program based on the BSD code, is it correct to say that "you put Microsoft code in your FTP program"?
Nope. The luma resolution is three times the chroma resolution. Imagine if you were color blind. Given the sequence of fully illuminated segments:This would appear to someone with color vision as an alternating sequence of magenta and green stripes (ack!) three of each. To a colorblind person, it appears as nine each alternating light and dark stripes. Same thing applies to displaying an Apple II composite video signal on a monochrome monitor -- instead of magenta and green stripes, you get a tighter pattern of white (or amber or green, depending on the monitor) and black stripes.
Under NTSC, luminance is constant and independent of chroma.
Not in a composite signal, it's not. Hence the name -- it's a composite of the chroma and luma signals, and with high luma spatial frequencies you get chroma artifacts -- that was the whole point of Woz's video circuitry. As far as the rest of the computer was concerned, you sent a color pixel value to the video circuitry and got a color pixel on the screen (assuming composite color TV). But because of the implementation detail, if you were using a monochrome screen you could send a color pixel to the video circuitry and get a specific set of subpixels illuminated.
You can't pick a color and get it to affect the luma at all.
Sure, as I illustrated above. You pick the color to affect the luma at a specific location. If you couldn't, then Microsoft's subpixel antialiasing wouldn't work.
The claim, or the method of implementing the claim?
Given the claim alone as a requirement ("we need a method to do X and Y"), for many patents yes, the method is obvious to one skilled. Not always, and sure, those nonobvious methods deserve patents.
As for the subpixel thing -- you're getting hung up on the hardware, which is irrelevant because in both cases, the hardware existed before the method. The hardware is not designed to allow sub-pixel addressing (and the Apple II video is certainly based on pixels, it's the force-fit of pixelated video into an NTSC waveform that makes the trick work), the method (same in both cases) just takes advantage of the fact that in both an NTSC signal and an LCD screen, the luma resolution is higher than the chroma resolution, and there is a fixed relationship between the two. The method of picking a particular chroma value to address the luminence component of the display "pixel" will work for any display technology where that is true.
Note carefully, we're not talking about the use of Woz's careful timing of luminance pulses to confuse NTSC TV circuits into displaying color, we're talking about programmers taking advantage of that implementation detail to do subpixel addressing on a monochrome display -- just as the LCD trick is only really useful for high-contrast (black on white or vice versa) text display.
You mean that McBride's rants may actually have a bit of substance behind them?
Saying that McBride's rants have substance because of this is like saying the Sahara Desert is wet because a camel peed on it.
McBride has been raving on about "millions of lines" of stolen SysV code, and other such idiocy. Even a stopped clock is right twice a day.
I am just saying that their case is strengthening.
And if you pee in the Sahara, you could say that the desert is getting wetter. Either way it doesn't amount to much.
Who is to say that this is all of the code lines in question?
SGI. In the letter. They said that they'd searched the rest of the SysV code (they have a license, remember?) and only found a few possible instances, which they're fixing. You did read the letter, didn't you?
Making fun of SCO won't make them go away.
Really? Dang!
How about if we make fun of you, will you go away?
and also
Bullshit. Are you trolling for SCO?
As I have stated previously,
You were wrong then, too.
Now SGI is ADMITTING that they put SYSV code in the Linux codebase.
No they're not. They're saying that they found code that happens to match some Sys V code in what they submitted -- less than 0.02% worth. The exact provenance of that code isn't clear, SysV may have got it from the same place SGI did. Your statement implies several levels of culpability that is just plain not in the SGI letter.
Whether or not it has been removed is IMMATERIAL for purposes of this case.
What case? So far the only "case" (lawsuit) is between IBM and SCO, and between RedHat and SCO. IF SCO decides to launch yet another lawsuit and sue SGI for copyright infringment (and remember, SCO has NOT made any copyright complaints against IBM (but IBM has against SCO)), then there may be a case. But SGI's action in removing the questionable code is VERY MATERIAL -- it limits SCO's claims. (Furthermore, since SCO has so far refused to reveal what code it thinks infringes, it may have no claim because it hasn't taken the necessary steps to mitigate damage.)
200 lines of code out of one million is about the same as four or five lines of text out of a 500 page book. (And note these 200 lines were scattered over several modules, not one contiguous block.)
Or about the same as less than one syllable out of a song.
And no, they're not "admitting" anything, just describing what they found and how they're fixing it.
Microsoft's patent covers non-fatal program failures as well.
So, what's a "non-fatal program failure"? Does that mean it's just wounded, but will get better? Does that mean the program is going to phone home every time the user tries to open the wrong kind of file or the app runs out of memory or the user makes an error? I hope Microsoft is planning on increasing their bandwidth...
Most patents are actually about some marginally improved twist on a mature technology.
Yeah, which is why most patents are obvious to someone skilled in the art. That latter phrase is a key part of the "obviousness" test, and what may well be unobvious to the lay person or the person only casually familiar with an art really is obvious to someone who has practised it for years.
Oh, and your comparison of subpixel addressing is misguided. Yes, Woz's color generation circuit per se didn't have anything to do with subpixel addressing -- except that it took advantage of the well known (to video engineers, anyway) aliasing effect of a high spatial frequency monochrome signal on the NTSC chroma signal (which is why you shouldn't wear pin-stripes on camera). Inverting that makes a direct relationship between color and specific subpixel areas that get illuminated, just as with the LCD-based subpixel addressing method. They are both a simple mapping of subpixel-area-desired -> pixel-color. The fact that the reasons it works is different for LCDs and synthesized NTSC video is irrelevant to the fact that the same method is used.
Blue is too peaceful. RED scares the crap out of end users.
Which is exactly why MS's SODs are blue. Do you think Redmond wants to put up with the calls they'd get and the general aversion to the product with red screens? (As if blue weren't bad enough.)
Come to think of it, I'd be surprised if there wasn't a Linux printer driver to do the same thing....
And if there isn't, it's easy enough to set up a custom print queue to do so. (Just pass the dvi, ps, etc output through the appropriate *2pdf filter). Easy enough with printcap, anyway. I assume the same can be done with CUPS.
it may actually be a useful feature for the device to be able to answer http requests with an XML document that provides a system status report.
Got something against SNMP? Especially "if you have 100 toasters or whatever".
SGI bet on NT and lost.
Yep, and the guy responsible for SGI betting on NT, Rick Belluzzo, went on to head up Microsoft's internet operations. A reward for a job well done, even as SGI was tanking?
Often times a scene will have some sort of issue that you otherwise wouldn't see,
Remember the "Genesis planet" sequence from Star Trek - The Wrath of Kahn? Dates back about 20 years. Obvious CG -- it was supposed to be -- animation of a planet coalescing, mountains rising, etc as the POV swept in and across the surface. Just one problem, the damn mountain range kept rising right into the flight path. They ended up hacking the software so that a canyon opens up just as the POV gets to the mountain range and can fly through it.
That much I can confirm from watching the video. What I can't confirm, that the ILM programmer who told this story to me said, is that carved onto the canyon walls is (are?) the name(s) of the programmer(s) who did that hack. (Too blurred in the video).
I should take my own advice and read the followups to the followups.
Eric Andersen's reply to Rob Landley points out that Cisco has had quite a few months (and several lawyer letters) to get into compliance, and are foot-dragging. (Although Linksys' letter seems to confirm that they outsourced the code development and they may not have the source themselves. Stupid.)
In particular, Rob Landley's well thought out response.
If Cisco/Linksys is deliberately violating the GPL, then yes, they should be raked over the coals as appropriate. However, given that they've already tried to cooperate with the GPL, it may be that there was just a disconnect between the guys putting stuff up on the website and the actual developers of the Linksys kernel (which, as Landley points out, might even have been outsourced -- and Cisco is probably pretty upset with them about now.)
it's a limit because the maximum velocity for a space craft is the velocity with which it ejects its fuel.
No, it isn't. You just have to carry more fuel if you want to exceed your exhaust velocity. This is basic physics. Review the rocket equation. Current rockets routinely exceed their exhaust velocity by several times. (NB - this applies to rockets carrying -- and hence accelerating -- their fuel. A scramjet has a problem with this -- which is why scramjets are really a silly idea for Earth-to-orbit propulsion.)
(Of course, this falls down at relativistic speeds, you aren't going to exceed an exhaust velocity of c no matter how much fuel you're carrying.)
Higher exhaust velocity means more momentum exchange per gram of propellant, which is the same as saying a higher specific impulse, which means a given mass of high speed propellant will result in greater delta-v than a low speed propellant.
The name of the east Indian village translates as "Smallville".