Agree that 15:1 sounds crazy - but the more you look into it the more reasonable it seems. [...] On a qwerty you can type only 1 of 27 on the homerow (as). On Dvorak you can type 13 of 27.
As I wrote in another post, the ratio is only 1.7 to 1 concerning horizontal travel, or 2.5 versus 1.4 cm per keypress. The data does not show total travel distance, but it does tell us that Dvorak has 54% of the keypresses on the home row, versus Qwerty 23%. If a non-home key adds another 1.5 cm of vertical travel, we get for Qwerty: 2.5 cm + (1-0.23)*1.5 cm = 3.7 cm and for Dvorak 1.4 cm + (1-0.54)*1.5 cm = 2.1 cm, i.e. a ratio of 1.8:1. Of course, it can be debated whether you should simply add horizontal and vertical distance, but the ratio is certainly not going to be 15:1.
Comparison: on qwerty, you move your fingers 15-20 miles per day, compared to 1 mile on dvorak for (I assume) the same workload.
The ratio is more like 1.7:1 according to this keyboard analysis on prose. For 250 kB of text, you travel 6.3 km on Qwerty and 3.7 km on Dvorak (only horizontal travel counted). If you don't spend too much time thinking about what you write, you might be able to type that amount in 3 days or so, so 2 versus 1.3 km per day.
Section 3b is about physical media (e.g., cd, dvd). Do you expect to be able to order a cd with the source code for every GPL program you download from the internet?
From the GPL FAQ:
How can I make sure each user who downloads the binaries also gets the source?
You don't have to make sure of this. As long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the source.
Our requirements for redistributors are intended to make sure the users can get the source code, not to force users to download the source code even if they don't want it.
quite a few projects have pulled the source to previous releases (a violation of the GPL that these projects were released under; gaim is one of them).
It's only a violation if they continue to provide compiled binaries for download. See the bottom of section 3 of GPL v2.
Then there are those of us who think the prank is the people who refuse to use it (and who trot out the tired "hard drive manufacturers are stealing my disk space" myth/meme).
There are occasions where the distinction is important, especially when you want to know the exact number for memory allocations or in trade. But here, we were talking about "around 17 million bytes", which is probably rounded from a number between 16.51 and 17.49 M(i)B. Hence the distinction is not relevant here; the number just meant "an awfully big file".
I have a website where you can upload your screen images and have it calculate with higher accuracy what the contrast ratio is: lagom.nl/lcd-test/contrast_ratio. I tried this myself with dozens of screens (in a dark environment), and nearly all recent laptop screens have a contrast ratio of around 1:100 - 1:150 in a dark environment, a bit dependent on the viewing angle. Glossy or matte doesn't matter. I didn't check the effect of ambient light on the contrast ratio.
This value doesn't even give you the full dynamic range from an 8-bit display (255 to 1),
It doesn't work like that; the standard sRGB brightness-versus-pixel value response curve of a standard computer monitor means that officially, the brightness ratio between 1 and 255 "should" be more like 3000:1.
let alone the 1000+++ to 1 that LCD TV manufacturers claim.
I don't have much experience with LCD TVs, but if they are based on the same LCD panels as monitors (likely the case up to 24 inch), you won't get much better than about 800:1, unless the TV dims the backlight during dark scenes.
Could be true, in principle. According to This site, the chromatic abberation of the eye is about 1 diopter across the red-blue range. However, although 1 diopter is the difference between focusing at 1 meter and at infinity, it is only the difference between focusing at 20 cm or 17 cm. And you keep the problem of lack of blue receptors.
I find blue to be the worst to focus with. That may be because my sources of blue light are not sufficiently narrow band in the spectrum. Being spread out over the spectrum, it basically comes in fuzzy. Blue is also lower in contrast.
It is not the width of the spectrum, but rather the dispersion of your eye and the density of receptors in your retina. First, if you plot the refractive index of a material (e.g. optical glass) against the wavelength, you'll see that for most material this curve is steeper at the short-wavelength (blue, 400-450 nm) side of the spectrum. That means it is hard to focus at green and blue simultaneously than at green and red simultanously. Second, the density for blue receptors on the retina is much lower than for green and red. Even with monochromatic blue light, you would have this apparent focusing problem.
Fixed-sync displays (or those with a more limited sync range) have very little refresh-related flicker, because the phosphor persistence in designed to match the vertical refresh rate. For an easy to produce example, compare a static image on a multi-sync monitor running at 60 Hz vertical refresh to a similar image on a CRT TV -- the TV has much long persistence and much less flicker at low vertical refresh rates.
It is probably true for those very old monochrome monitors that had like half a second of persistence, but it is definately not the case for color TVs. Yes, there is some persistency, but over 95% of the photons are emitted within a millisecond after the electron beam hits the phosphor, and the other 5% are emitted gradually over tens of milliseconds. The net effect is that there's sharp flashing, plus about 5% (in this example) of a more-or-less constant background. That is not going to improve the flicker a lot; otherwise you could just point a lightbulb at your TV to increase the background illumination.
You can see the background light for yourself by taking a photo of a TV screen with a 1/200 exposure time.
What makes the flicker less obvious with a TV is that you normally watch a TV at 5-10 times the screen diagonal, and a computer monitor at only 2 times the screen diagonal, such that a much larger area of your field of view is covered by the screen. People are most sensitive to flicker at the edges of the field of view.
I guess that would mean my LCD is using the true 8 bits?
I'd say the 6-8 bit thing is overrated, just as CPU clock speeds were a couple of things ago. What matters in the end is whether the display is able to show subtle shades, and that can be by means of a true 8-bit DAC or a time-domain dithered 6-bit DAC, just like the 16-bit audio is reproduced with 1-bit DACs and a lot of dithering.
Every one I've seen has that same 60Hz flicker. And yes, my camera with a 1/200th shutter agrees with me. (snip) The ballasts that do operate in the kHz range are pretty expensive, you don't get them in a $7 CFL.
Well, actually they are high-frequency, because an HF ballast needs a much smaller transformer that saves on copper and iron. However, the HF signal is a bit amplitude-modulated at 100 or 120 Hz because it just switches the DC voltage coming from the rectifier, which has some 20% ripple. Suppressing the ripple may cost a few more cents per bulb.
By the way, I just checked my 3 euro IKEA bulb with my camera and at shutter times 1/400 and 1/1250 and if there's any ripple at all, it's less than 0.1 stop or 7% peak-peak.
There is a good reason white LEDs aren't just tri-color LEDs without seperate leads. See the slashdot story from this weekend about the artist exploiting the monochromatic light of LEDs to produce interesting effects when illuminating paintings. If you mix primary colors to get yellow paint, paint something with it and shine a yellow LED on it you see black.
I think you are misunderstanding a couple of things. First, I'm not sure how you would get yellow paint by mixing colors, because for paint (substractive color mixing), yellow is a primary color. (Artists consider red, yellow, blue to be primary paint colors). Of course, using an illumination spectrum consisting of a few narrow bands will make surface color appear a bit different compared to viewed in daylight, but never as dramatic as you are suggesting here.
Guess that is why white LEDs use a deep blue or UV LED with a fluorescent coating inside the package
No, that is because it is cheaper to have a single LED without distracting color variations because the three components are pointing in different directions. These LEDs are handicapped in the efficiency because of quantum mechanics blue light needs more volts than red, and in color rendition of surfaces. The latter is because they essentially emit light in TWO color bands rather than three: yellow light and blue light make white, but it doesn't cover the red and green wavelengths very well.
we use images taken from a little-known anime. You are to input the name of that anime in order to get acceptance for registration. We haven't had any spam since we implemented this a few years ago.
Well, I have a guestbook-like webpage that got spammed pretty badly, and I added the question:
What kind of being are you? [x]robot [ ]human [ ]frog.
It blocks all the spam. That's because there are plenty of bots that just look for anything that looks like a text submit form and they're not going to spend even 5 minutes on cracking it. But no way that it would work if it was in the standard distribution of phpBB.
(The silly captcha is here. I also have a much more robust captcha which I'm sure is quite hard to beat.)
enforce the provision of the registrar agreement which allows ICANN to prohibit registrars from owning or speculating in domains.
Does that provision really already exist? It would be very hard to prove, though, because one could set up a registrar that does the registrations on behalf "of their customers", and ICANN is not really in the position to trace whether those customers are the same organisation as the registrar.
Couldn't you just do a DNS request to see if a domain is taken?
Normally you use whois (which exists as a commandline tool), but you can also use DNS, for example
dig example.com (*ux) nslookup -type=ns example.com (works with Windows)
Of course, you have to trust the organisation that's at the other end of your query. It is possible that some domain owners count DNS requests. There are fewer organisations that manage the Whois database.
Every single bit of user input must be inspected and thoroughly tested, always,
The user input could be clean (i.e. not containing funny characters in itself), but instead trigger a condition in a php script that causes the script to forget a tag somewhere. For example a result set from an SQL query that in rare occasions is empty and produces a <ul></ul> without a <li> inside. Empty ULs are not allowed, so nothing at all is displayed.
For instance, if I have a single element that could be some combination of red or green, bold or italic, floated left or floated right, and 12 or 22 point text, I would have to draft 2^4 different styles that this element could be.
You can actually combine classes:
<div class="bigfont leftfloat italic">blah</div>
I agree though that html coding would get hard if an occasional style attribute is not allowed anymore. But the spec says:[ref]: We probably need to move this [style] attribute to more elements, maybe even all of them, though if we do that we really should find a way to strongly discourage its use (and the use of its DOM attribute) for non-WYSIWYG authors.
I'm not really sure how explicity declaring the end of a block in any way obfuscates the code,
When I write a webpage, I'm mainly dealing with the human-readible text. I can deal with a couple of tags here and there, but as the ratio between what's between < and > versus the actual content increases, it gets more and more cumbersome, whether it's redundant closing tags or font/color tags.
You mean apart from the very fact that [xhtml] is eXtensible without any real limitations?
Hmm, there you have a point. I was mostly thinking of XHTML 1.1 without realizing that XHTML 2 is supposed to offer these features.
It goes further than personal home pages too, HTML 5 web applications are going to be an absolute nightmare to maintain for large businesses if they end up finding they're pretty much forced to adopt it. If you have a content management system and you have a web team responsible for ensuring a corporate standard for the site is met in terms of presentation and layout then the last thing you want is for your employees to be able to randomly change font settings and so forth by including inline tags
I fail to see why they would be "forced" to adopt it. HTML 4, which is what the web apps use now, will be supported basically forever, and the disadvantages of HTML 5 you mention apply equally to HTML 4. The few websites with a CMS that really output strict XHTML right now need filtering of the user input anyway to prevent borking with "XML parse error" in the browser. An CMS for HTML 5 could implement similar filters with a subset of HTML 5.
Essentially what's happened with HTML 5 is we've got a language that caters for those incapable of working with a well structured language, on one hand this is great because more people can publish to the web, on the other it's awful as it basically fucks up the web further.
As far as I understand, HTML 5 specifies exactly how a user agent should deal with formally incorrect code. I have never understood some people's obsession with XHTML, where a compliant browser is supposed to display an error message. With Opera, I encounter "XHTML" pages every now and then that do not display at all because they were dynamically generated from a database and there is a single illegal character in there or a forgotten close tag in a string coming from a database. How is that supposed to help anyone that every scripted page needs to be tested against every possible input condition? It could have been made optional in the user-agent to display a warning for web developers, but no, the spec requires that the browser justs bails out.
And xhtml also sucks for hand-coded pages since it is full of redundant closing tags, for things like <br>, <tr>, <td>, <li, and so on. It's only more typing and more obfuscating syntactic sugar. There are millions of people who create web content, and only a handful browsers. To me it is obvious that it is a waste of manpower to require of millions of people to learn the exact strict xhtml rules rather than make the browsers more flexible with non-conformant input, in a well-defined cross-browser portable manner. HTML 5 will add new useful features. XHTML adds nothing that wasn't already possible in HTML 4.01-strict (the version without font/frameset/bgcolor/etc. stuff).
[with xhtml] small handheld devices could finally display compliant sites in a way that best fit the screen.
I think you are talking about spacer GIFs and table markup. As far as I know, you can still abuse tables for page layout in XHTML. Moreover, to make a page that is really portable between 1024 pixel monitors and devices with a 150 pixel-wide screen requires much more than just xhtml/css; both the CSS and the page structure need to be carefully designed to be portable, in a way that is not enforced by the xhtml spec.
A few years ago I was able to reduce my power bill by $100 a month (from $200 down to $100) just by turning off my computer at night.
Was that computer a Beowulf cluster or something? Over here, electricity is about EUR 0.22/kWh. EUR 70 per month for 12 hours per day would mean you have a 900 W computer, or maybe 600 W plus 300 W for the airconditioning.
Slashdot Mirror
As I wrote in another post, the ratio is only 1.7 to 1 concerning horizontal travel, or 2.5 versus 1.4 cm per keypress. The data does not show total travel distance, but it does tell us that Dvorak has 54% of the keypresses on the home row, versus Qwerty 23%. If a non-home key adds another 1.5 cm of vertical travel, we get for Qwerty: 2.5 cm + (1-0.23)*1.5 cm = 3.7 cm and for Dvorak 1.4 cm + (1-0.54)*1.5 cm = 2.1 cm, i.e. a ratio of 1.8:1. Of course, it can be debated whether you should simply add horizontal and vertical distance, but the ratio is certainly not going to be 15:1.
The ratio is more like 1.7:1 according to this keyboard analysis on prose. For 250 kB of text, you travel 6.3 km on Qwerty and 3.7 km on Dvorak (only horizontal travel counted). If you don't spend too much time thinking about what you write, you might be able to type that amount in 3 days or so, so 2 versus 1.3 km per day.
(Happily using Dvorak since 1995)
Section 3b is about physical media (e.g., cd, dvd). Do you expect to be able to order a cd with the source code for every GPL program you download from the internet?
From the GPL FAQ:
How can I make sure each user who downloads the binaries also gets the source?
You don't have to make sure of this. As long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the source.
Our requirements for redistributors are intended to make sure the users can get the source code, not to force users to download the source code even if they don't want it.
It's only a violation if they continue to provide compiled binaries for download. See the bottom of section 3 of GPL v2.
That won't reduce the amount of download when you open a page over a slow mobile GPRS connection while being charged per kB.
There are occasions where the distinction is important, especially when you want to know the exact number for memory allocations or in trade. But here, we were talking about "around 17 million bytes", which is probably rounded from a number between 16.51 and 17.49 M(i)B. Hence the distinction is not relevant here; the number just meant "an awfully big file".
I have a website where you can upload your screen images and have it calculate with higher accuracy what the contrast ratio is: lagom.nl/lcd-test/contrast_ratio. I tried this myself with dozens of screens (in a dark environment), and nearly all recent laptop screens have a contrast ratio of around 1:100 - 1:150 in a dark environment, a bit dependent on the viewing angle. Glossy or matte doesn't matter. I didn't check the effect of ambient light on the contrast ratio.
It doesn't work like that; the standard sRGB brightness-versus-pixel value response curve of a standard computer monitor means that officially, the brightness ratio between 1 and 255 "should" be more like 3000:1.
I don't have much experience with LCD TVs, but if they are based on the same LCD panels as monitors (likely the case up to 24 inch), you won't get much better than about 800:1, unless the TV dims the backlight during dark scenes.
Could be true, in principle. According to This site, the chromatic abberation of the eye is about 1 diopter across the red-blue range. However, although 1 diopter is the difference between focusing at 1 meter and at infinity, it is only the difference between focusing at 20 cm or 17 cm. And you keep the problem of lack of blue receptors.
It is not the width of the spectrum, but rather the dispersion of your eye and the density of receptors in your retina. First, if you plot the refractive index of a material (e.g. optical glass) against the wavelength, you'll see that for most material this curve is steeper at the short-wavelength (blue, 400-450 nm) side of the spectrum. That means it is hard to focus at green and blue simultaneously than at green and red simultanously. Second, the density for blue receptors on the retina is much lower than for green and red. Even with monochromatic blue light, you would have this apparent focusing problem.
It is probably true for those very old monochrome monitors that had like half a second of persistence, but it is definately not the case for color TVs. Yes, there is some persistency, but over 95% of the photons are emitted within a millisecond after the electron beam hits the phosphor, and the other 5% are emitted gradually over tens of milliseconds. The net effect is that there's sharp flashing, plus about 5% (in this example) of a more-or-less constant background. That is not going to improve the flicker a lot; otherwise you could just point a lightbulb at your TV to increase the background illumination.
You can see the background light for yourself by taking a photo of a TV screen with a 1/200 exposure time.
What makes the flicker less obvious with a TV is that you normally watch a TV at 5-10 times the screen diagonal, and a computer monitor at only 2 times the screen diagonal, such that a much larger area of your field of view is covered by the screen. People are most sensitive to flicker at the edges of the field of view.
I'd say the 6-8 bit thing is overrated, just as CPU clock speeds were a couple of things ago. What matters in the end is whether the display is able to show subtle shades, and that can be by means of a true 8-bit DAC or a time-domain dithered 6-bit DAC, just like the 16-bit audio is reproduced with 1-bit DACs and a lot of dithering.
(Shameless plug) Rather than creating the image yourself, you can also try The Lagom LCD test pages (and try lots of other monitor tests as well).
Well, actually they are high-frequency, because an HF ballast needs a much smaller transformer that saves on copper and iron. However, the HF signal is a bit amplitude-modulated at 100 or 120 Hz because it just switches the DC voltage coming from the rectifier, which has some 20% ripple. Suppressing the ripple may cost a few more cents per bulb.
By the way, I just checked my 3 euro IKEA bulb with my camera and at shutter times 1/400 and 1/1250 and if there's any ripple at all, it's less than 0.1 stop or 7% peak-peak.
I think you are misunderstanding a couple of things. First, I'm not sure how you would get yellow paint by mixing colors, because for paint (substractive color mixing), yellow is a primary color. (Artists consider red, yellow, blue to be primary paint colors). Of course, using an illumination spectrum consisting of a few narrow bands will make surface color appear a bit different compared to viewed in daylight, but never as dramatic as you are suggesting here.
No, that is because it is cheaper to have a single LED without distracting color variations because the three components are pointing in different directions. These LEDs are handicapped in the efficiency because of quantum mechanics blue light needs more volts than red, and in color rendition of surfaces. The latter is because they essentially emit light in TWO color bands rather than three: yellow light and blue light make white, but it doesn't cover the red and green wavelengths very well.
Well, I have a guestbook-like webpage that got spammed pretty badly, and I added the question:
What kind of being are you? [x]robot [ ]human [ ]frog.
It blocks all the spam. That's because there are plenty of bots that just look for anything that looks like a text submit form and they're not going to spend even 5 minutes on cracking it. But no way that it would work if it was in the standard distribution of phpBB.
(The silly captcha is here. I also have a much more robust captcha which I'm sure is quite hard to beat.)
Does that provision really already exist? It would be very hard to prove, though, because one could set up a registrar that does the registrations on behalf "of their customers", and ICANN is not really in the position to trace whether those customers are the same organisation as the registrar.
Normally, real estate is not valued on what the seller asks, but rather on the price for which comparable property actually is sold.
Normally you use whois (which exists as a commandline tool), but you can also use DNS, for example
Of course, you have to trust the organisation that's at the other end of your query. It is possible that some domain owners count DNS requests. There are fewer organisations that manage the Whois database.So can you tell me what one could gain (apart from more billable hours) by using xhtml 1 rather than html 4?
The user input could be clean (i.e. not containing funny characters in itself), but instead trigger a condition in a php script that causes the script to forget a tag somewhere. For example a result set from an SQL query that in rare occasions is empty and produces a <ul></ul> without a <li> inside. Empty ULs are not allowed, so nothing at all is displayed.
You can actually combine classes:
<div class="bigfont leftfloat italic">blah</div>
I agree though that html coding would get hard if an occasional style attribute is not allowed anymore. But the spec says:[ref]: We probably need to move this [style] attribute to more elements, maybe even all of them, though if we do that we really should find a way to strongly discourage its use (and the use of its DOM attribute) for non-WYSIWYG authors.
When I write a webpage, I'm mainly dealing with the human-readible text. I can deal with a couple of tags here and there, but as the ratio between what's between < and > versus the actual content increases, it gets more and more cumbersome, whether it's redundant closing tags or font/color tags.
Hmm, there you have a point. I was mostly thinking of XHTML 1.1 without realizing that XHTML 2 is supposed to offer these features.
I fail to see why they would be "forced" to adopt it. HTML 4, which is what the web apps use now, will be supported basically forever, and the disadvantages of HTML 5 you mention apply equally to HTML 4. The few websites with a CMS that really output strict XHTML right now need filtering of the user input anyway to prevent borking with "XML parse error" in the browser. An CMS for HTML 5 could implement similar filters with a subset of HTML 5.
As far as I understand, HTML 5 specifies exactly how a user agent should deal with formally incorrect code. I have never understood some people's obsession with XHTML, where a compliant browser is supposed to display an error message. With Opera, I encounter "XHTML" pages every now and then that do not display at all because they were dynamically generated from a database and there is a single illegal character in there or a forgotten close tag in a string coming from a database. How is that supposed to help anyone that every scripted page needs to be tested against every possible input condition? It could have been made optional in the user-agent to display a warning for web developers, but no, the spec requires that the browser justs bails out.
And xhtml also sucks for hand-coded pages since it is full of redundant closing tags, for things like <br>, <tr>, <td>, <li, and so on. It's only more typing and more obfuscating syntactic sugar. There are millions of people who create web content, and only a handful browsers. To me it is obvious that it is a waste of manpower to require of millions of people to learn the exact strict xhtml rules rather than make the browsers more flexible with non-conformant input, in a well-defined cross-browser portable manner. HTML 5 will add new useful features. XHTML adds nothing that wasn't already possible in HTML 4.01-strict (the version without font/frameset/bgcolor/etc. stuff).
I think you are talking about spacer GIFs and table markup. As far as I know, you can still abuse tables for page layout in XHTML. Moreover, to make a page that is really portable between 1024 pixel monitors and devices with a 150 pixel-wide screen requires much more than just xhtml/css; both the CSS and the page structure need to be carefully designed to be portable, in a way that is not enforced by the xhtml spec.
Was that computer a Beowulf cluster or something? Over here, electricity is about EUR 0.22/kWh. EUR 70 per month for 12 hours per day would mean you have a 900 W computer, or maybe 600 W plus 300 W for the airconditioning.