Readers of Hebrew have similar sensitivity patterns around their foci, except that it's to the left rather than to the right; the brain learns where to pay attention to in the process of learning to read. Interestingly, a common cause of dyslexia during the 80s and early 90s in the US was that these children's sensitivity was greatest to the right of their foci, not at it, so they would be distracted by the next word and unable to read the one they were looking at. One plausible explanation is that these children had learned to read from side-scrolling video games, and were trained to pay attention to the wrong thing. They could be taught to read correctly with a window which only showed the important area.
I don't know of any research on languages with primarily single-character words or vertical text; I suspect that the single-character studies just wouldn't be all that interesting, because there's less that can be skimmed.
Actually, a lack of ease of use is the most common source of security vulnerabilities. Requiring long passwords (or frequently changed passwords) mostly causes people to reuse them or write them down. If a security-related program is complicated or difficult to use, there is a higher chance that the users will screw it up and not actually be secure.
People's web spaces could have support for making a list of email addresses that could get a document. This would work by looking up the domain's public certificate (ideally out of a local cache of public certificates from previous interactions with the particular users; don't trust VeriSign), and requiring the client to use a client certificate with the right distinguished name signed by the domain. Other users would, when they logged in, go to their domain's CA web site and get a client certificate by supplying their password. Easy to use, real security. None of this "send a reuseable authentication token to somebody else's system" junk.
The problem is not so much that the clueless don't understand security as that there isn't really a secure system available which is sufficiently comprehensible to explain to them such that they can use it successfully.
Actually, it takes kernel developers about a week to work through the implications of an extension to the behavior of filesystems, and they seem to be converging to a solution that will continue to behave in the expected way for programs that don't know about the new possibilities. (The flamefests were pretty brief, and then people got down to hashing out the new semantics)
Chances are that the reason WinFS is delayed is that, while it works great, it breaks half of MS's applications and all of everybody else's, because MS doesn't have a set of specifications which they are following, so they don't know what behavior people are depending on. Sure, they don't have to fight with people who don't want to change anything internally, but they do have to contend with legacy applications which depend on undocumented behavior (because important things weren't documented) and are all that are tying many users to Windows.
It seems to me like they included practically nothing useful in the "Options..." thing, and that about:config is nice enough anyway. The main thing it's lacking is documentation; smaller things are that it doesn't seem to support a "one of these strings" type and it doesn't seem to have cut-and-paste support (which would be nice for telling people about options in slashdot posts). The "search all the options for one like this" feature is easier to use than the hard-to-remember organizations that all of the "user-friendly" configuration systems have had.
Go to about:config, find image.animation_mode, and set it to "no". I actually set mine to "once", which means that I see animated images if I'm actually watching; I generally iconify the browser and do something else while pages load, so I miss all the ads, but I can actually watch a weather image if I want. As far as I can tell, there's no documentation for this anywhere.
That's a very informative site, but it's arranged to refute the idea that the Holocaust didn't happen, and therefore is arguing against the idea that killing large numbers of people isn't possible (with the documented methods), not the idea that killing large numbers of people is possible without those methods. For that matter, if the rate at which they could kill people was limited by disposing of the bodies and by transporting the poeple beforehand, surely they didn't need fast techniques for killing them in between. I didn't see anything claiming that 1-2 million people couldn't have died at Auschwitz by arriving dehydrated and not getting food or water upon arrival.
It is clear that the Nazis did try a lot of things, including gassing people with HCN, but I'm not convinced that it was necessarily a common cause of death. For that matter, the descriptions of people being gassed sound like a fate reserved for those deemed necessary to kill at once, not the bulk of the deaths. The site also mentions that the initial application of Zyklon B to people didn't kill all of them the first day. Also, the amount necessary for killing insects in clothing, which was clearly also going on, is known to be higher, so looking at the quantity used isn't very helpful; it would take more to delouse the clothes of those killed than it would to gas them.
I'd guess that he'd claim that they died of illness, malnutrition, and exposure. Survivors reported people dying that way, and reported conditions in which that would be expected.
I wouldn't be too surprised if the stories of Nazis slaughtering Jews are all made up by people who couldn't believe that 12 million people could die from poor conditions, and who wanted to believe that the Nazi camps were qualitatively (as opposed to only quantitatively) worse than the American ones. Showers that gas people really sounds like something you'd come up with when you're expecting something specifically deadly, and don't find anything.
But why would any Jews have survived after reaching the camps, let alone survived long enough to be rescued, if the camps were actually designed specifically to kill groups of people together and suddenly? Why would they build sneaky devices to kill people with when they could kill them simply by failing to provide adaquately for them? Occam's Razor suggests that the way that eyewitnesses report people dying, if sufficient, was the only way people died.
Not, of course, that this excuses anything; if anything, being starved and worked to death is a worse fate than poison gas. But it does mean that we can't think of the Nazis as being crazy and inexplicable people doing things we know we wouldn't do. Sure, the Nazis were evil, but don't think they were overtly evil. There is only so much most people are capable of as far as things that are obviously wrong. But people are capable of much worse things that aren't obviously wrong. If we don't recognize this, we risk justifying another Holocaust simply by telling outselves we aren't gassing people in showers.
Actually, there's also piezoelectrics. You could have a speaker which connected the membrane to a stack of 16 piezos which get zero or power-of-two voltages across them depending on input bits. Sure, it would be nuts, but it would be all digital (except for the air, of course) and not magnetic...
MIT is actually pretty careful to arrange their gender-equality-seeking efforts in terms of marketting toward women, rather than actually giving women an advantage. MIT admissions specifically tries to get women to apply, and tries to get women who are accepted to enroll. The idea is that there probably aren't fewer smart women than smart men, but more of the smart women don't apply. MIT has had sufficient qualified applicants to make a 50% female class for years, if they wanted to arrange things that way. Instead, they try to ignore gender in admissions and try to make the application pool gender balanced.
The WTP program mentioned in the article is part of this. There are similar programs open to everybody, but fewer girls show up to them than boys. So they have a program for girls that does more outreach.
It's easy to see statistically that white males apply without any particular encourgement (the same seems to be true of asian women, actually). If the chance that a good candidate doesn't apply is higher for a particular minority, that means that the chance that a random member of that minority who wouldn't otherwise apply would be a good candidate is higher (assuming that demographics really don't matter). So you get better results by seeking applications from underrepresented minorities and ignoring demographics in your decision than you do by seeking applications equally from everyone.
So hasn't required anything of anyone. Sure, they've tried to get people to pay them for a worthless license, and it's probably fraudulent, but IBM doesn't have standing to complain about that. It's not like SCO has actually bought a copyright infringement claim against anyone over Linux (despite what their press releases have said). Furthermore, they could reveal the license to only apply to parts of their Linux distribution which they have uncontested copyright to, and say that there was confusion over exactly what was meant by "Linux".
As for repudiating the GPL, it doesn't really matter what they say. The GPL grants permission to distribute a program if you license it to recipients under the GPL. You can say you never agreed to the license, and you can insult the document, so long as you actually send the source, send the license, and don't sue anyone for that particular thing. I suspect that SCO has been careful to actually abide by the GPL so that they will be able to use this defense; otherwise, why would they have failed to actually sue Linux users for copyright infringement on code they own in Linux?
IBM doesn't need Linux developers' loyalty. IBM is generally happy with the stuff that Linux developers do anyway, and they put in their own effort when they need something that others haven't done. They argue for inclusion of their changes on technical merit.
As for this case, IBM isn't going to the mat to defend open source; they're defending themselves in a contract dispute. They're also attacking SCO with copyright claims, but they aren't offering to lead a class action on behalf of Linux copyright holders; they're only using their own copyrights, and intend to keep any damages they are awarded. For that matter, the community, simply out of outrage at SCO, has contributed substantial research to IBM with nothing asked in return.
Now, it would be nice to have actual, specific, legal precedent saying that the GPL is a valid license and that it does not permit its restrictions to be ignored, and having IBM's legal team argue the case is nice. On the other hand, I'm not personally convinced that SCO has actually violated the GPL; they've claimed to have violated it, they're committing international mail fraud, and they're encouraging others to violate it, but the GPL doesn't actually prohibit you from doing these things, and they are, evidentally, continuing to abide by the actual terms. So I suspect that the actual case will come down to whether SCO actually violated the GPL with a set of actions that nobody else is likely to do in the future, once it actually gets to the point of setting precedent.
There are a lot of devices which aren't supported but don't need specific support. For example, most digital cameras aren't supported, but they act as USB storage devices, so you don't need anything special for them. I'm happily using an nVidia card at home with free drivers, and it works fine for 2D stuff, which is all I've tried doing. Devices often have extra features which aren't supported under Linux but which aren't necessarily good ideas anyway.
Keyboard keys are fully-customizable. It's not like your keyboard actually runs programs. It just sends scancodes to the driver, which then sends them to programs (on Linux, generally X, which passes them on to applications). The thing that's really needed is a standard X program that shows the scancode for each key you press in the window.
On the hardware side, it would be nice to have a keyboard that came with no caps on the function keys and a couple dozen extra function-key-sized key caps with pictures on them.
I have to agree that terseness is good; I've found that the changes in Java 5 make it much faster to write. If you don't count lines with nothing but single braces, however, Java is getting pretty good. The main thing that sucks is small callbacks, where you have to have a couple lines of junk around the code.
Hopefully, Java will get parameterized types with a variable number of parameters, and then can have methods as first-class objects.
The thing that makes most Java verbose these days is that the standard libraries, while extensive, are often awkward. It's actually pretty easy to make a library of wrappers that reduces an unreadable 10 lines of code to "ReflectUtils.getStaticFieldValue(cl, name)" and such.
I bet most OSS authors wouldn't be willing to take the effort of collecting money from end users for a mere $99.95 per copy. I don't know about you, but I don't want to work in shipping and billing, let alone marketing or management.
I think most OSS programmers do care about the UI; after all, they're going to be using it most, and, if it's difficult to use, it will probably drive them crazy more than anyone else. On the other hand, they don't care about learnability (because they already know it), and don't necessarily have any skill at making it good.
My contention is that you shouldn't have to rely on coders to implement the UIs you design. The tools you use should produce UIs directly, and the code should be elegant in that it allows you to have the calls you need to make the program function behind the UI.
I think you've misunderstood the unix philosophy. The unix philosophy is to have a set of tools, each of which has a single function, which it performs in an entirely predictable fashion. The GUIs currently available for Linux do not follow the unix philosophy at all, and the tools for a lot of recent applications are not very compliant, either.
What I propose as the right way to involve UI designers in OSS is really the application of the unix philosophy to modern UI ideas: there are a set of operations which may be performed with various details specified, and these operations are documented in extensive detail. The UI designer builds the UI and uses these operations to make it active.
As a side note, I think that you're undervaluing the command line. Certainly it is a bad UI to require the user to type in a complete command while remembering the names of everything and without getting any feedback. But a line of text is about the most complete and expressive description of an action, and I think that a command line with a whole lot of assistance and feedback is probably much clearer than the common WIMP design. But this is really a matter for usability testing to determine; I'll just mention that my mother seems to find Pine on my Linux box easier to use than Windows, and she can write down and follow a set of instructions much easier with a keyboard interface and a WIMP one.
UI designers aren't any more likely than programmers to hate their work and never want to do anything similar in their spare time. The reason that OSS projects don't usually have UI designers as regular contributors is the amount of knowledge necessary to change a program's UI that isn't in the standard graphic design curriculum. In the commercial world, UI designers generally work by having the authority to tell programmers what to do; in the OSS world, they have no way to get this authority, because they don't have the skills for the entry-level gathering of respect.
In order to have good UIs, we need to involve people who can design them. In order to involve them, we have to empower them to make patches on their own. And that means arranging for UI coding to be completely obvious, and separate from the inner workings of the program.
Considering that a substantial portion of the economy now depends on secure communications, this is pretty unlikely. Between online credit card purchases, online banking, DVDs, and VPNs, there's not all that much in the business world that would be able to continue as it is at this point without encryption.
It's not a coincidence that all actual police states have had centralized economies, and nationalizing businesses is one thing that would have a hard time getting through Congress, considering that it would be opposed by practically everyone with lobbyists.
Slashdot Mirror
V svaq gung guvf fbeg bs grkg whfg whzcf bhg ng zr. Pyrneyl V'ir ernq gbb znal fcbvyref ba erp.tnzrf.ebthryvxr.argunpx bire gur lrnef. Zl oenva fubhgf "Ybbx! Nqivpr!"
Ba gur bgure unaq, zl fcryypurpxre trgf bqqyl haunccl...
Readers of Hebrew have similar sensitivity patterns around their foci, except that it's to the left rather than to the right; the brain learns where to pay attention to in the process of learning to read. Interestingly, a common cause of dyslexia during the 80s and early 90s in the US was that these children's sensitivity was greatest to the right of their foci, not at it, so they would be distracted by the next word and unable to read the one they were looking at. One plausible explanation is that these children had learned to read from side-scrolling video games, and were trained to pay attention to the wrong thing. They could be taught to read correctly with a window which only showed the important area.
I don't know of any research on languages with primarily single-character words or vertical text; I suspect that the single-character studies just wouldn't be all that interesting, because there's less that can be skimmed.
The moderators couldn't find "Shaal"?
Fbzrubj V pna'g unir zhpu pbasvqnapr va n grpuavdhr juvpu crbcyr nccyl va gurve urnqf. Be vf gung whfg zr?
You mean "Merged SoundTrack: 3 Kommentators"? Apple should be safe, because they didn't catch the weird naming thing from the KDE folks.
Actually, a lack of ease of use is the most common source of security vulnerabilities. Requiring long passwords (or frequently changed passwords) mostly causes people to reuse them or write them down. If a security-related program is complicated or difficult to use, there is a higher chance that the users will screw it up and not actually be secure.
People's web spaces could have support for making a list of email addresses that could get a document. This would work by looking up the domain's public certificate (ideally out of a local cache of public certificates from previous interactions with the particular users; don't trust VeriSign), and requiring the client to use a client certificate with the right distinguished name signed by the domain. Other users would, when they logged in, go to their domain's CA web site and get a client certificate by supplying their password. Easy to use, real security. None of this "send a reuseable authentication token to somebody else's system" junk.
The problem is not so much that the clueless don't understand security as that there isn't really a secure system available which is sufficiently comprehensible to explain to them such that they can use it successfully.
Actually, it takes kernel developers about a week to work through the implications of an extension to the behavior of filesystems, and they seem to be converging to a solution that will continue to behave in the expected way for programs that don't know about the new possibilities. (The flamefests were pretty brief, and then people got down to hashing out the new semantics)
Chances are that the reason WinFS is delayed is that, while it works great, it breaks half of MS's applications and all of everybody else's, because MS doesn't have a set of specifications which they are following, so they don't know what behavior people are depending on. Sure, they don't have to fight with people who don't want to change anything internally, but they do have to contend with legacy applications which depend on undocumented behavior (because important things weren't documented) and are all that are tying many users to Windows.
It seems to me like they included practically nothing useful in the "Options..." thing, and that about:config is nice enough anyway. The main thing it's lacking is documentation; smaller things are that it doesn't seem to support a "one of these strings" type and it doesn't seem to have cut-and-paste support (which would be nice for telling people about options in slashdot posts). The "search all the options for one like this" feature is easier to use than the hard-to-remember organizations that all of the "user-friendly" configuration systems have had.
Go to about:config, find image.animation_mode, and set it to "no". I actually set mine to "once", which means that I see animated images if I'm actually watching; I generally iconify the browser and do something else while pages load, so I miss all the ads, but I can actually watch a weather image if I want. As far as I can tell, there's no documentation for this anywhere.
That's a very informative site, but it's arranged to refute the idea that the Holocaust didn't happen, and therefore is arguing against the idea that killing large numbers of people isn't possible (with the documented methods), not the idea that killing large numbers of people is possible without those methods. For that matter, if the rate at which they could kill people was limited by disposing of the bodies and by transporting the poeple beforehand, surely they didn't need fast techniques for killing them in between. I didn't see anything claiming that 1-2 million people couldn't have died at Auschwitz by arriving dehydrated and not getting food or water upon arrival.
It is clear that the Nazis did try a lot of things, including gassing people with HCN, but I'm not convinced that it was necessarily a common cause of death. For that matter, the descriptions of people being gassed sound like a fate reserved for those deemed necessary to kill at once, not the bulk of the deaths. The site also mentions that the initial application of Zyklon B to people didn't kill all of them the first day. Also, the amount necessary for killing insects in clothing, which was clearly also going on, is known to be higher, so looking at the quantity used isn't very helpful; it would take more to delouse the clothes of those killed than it would to gas them.
I'd guess that he'd claim that they died of illness, malnutrition, and exposure. Survivors reported people dying that way, and reported conditions in which that would be expected.
I wouldn't be too surprised if the stories of Nazis slaughtering Jews are all made up by people who couldn't believe that 12 million people could die from poor conditions, and who wanted to believe that the Nazi camps were qualitatively (as opposed to only quantitatively) worse than the American ones. Showers that gas people really sounds like something you'd come up with when you're expecting something specifically deadly, and don't find anything.
But why would any Jews have survived after reaching the camps, let alone survived long enough to be rescued, if the camps were actually designed specifically to kill groups of people together and suddenly? Why would they build sneaky devices to kill people with when they could kill them simply by failing to provide adaquately for them? Occam's Razor suggests that the way that eyewitnesses report people dying, if sufficient, was the only way people died.
Not, of course, that this excuses anything; if anything, being starved and worked to death is a worse fate than poison gas. But it does mean that we can't think of the Nazis as being crazy and inexplicable people doing things we know we wouldn't do. Sure, the Nazis were evil, but don't think they were overtly evil. There is only so much most people are capable of as far as things that are obviously wrong. But people are capable of much worse things that aren't obviously wrong. If we don't recognize this, we risk justifying another Holocaust simply by telling outselves we aren't gassing people in showers.
Actually, there's also piezoelectrics. You could have a speaker which connected the membrane to a stack of 16 piezos which get zero or power-of-two voltages across them depending on input bits. Sure, it would be nuts, but it would be all digital (except for the air, of course) and not magnetic...
MIT is actually pretty careful to arrange their gender-equality-seeking efforts in terms of marketting toward women, rather than actually giving women an advantage. MIT admissions specifically tries to get women to apply, and tries to get women who are accepted to enroll. The idea is that there probably aren't fewer smart women than smart men, but more of the smart women don't apply. MIT has had sufficient qualified applicants to make a 50% female class for years, if they wanted to arrange things that way. Instead, they try to ignore gender in admissions and try to make the application pool gender balanced.
The WTP program mentioned in the article is part of this. There are similar programs open to everybody, but fewer girls show up to them than boys. So they have a program for girls that does more outreach.
It's easy to see statistically that white males apply without any particular encourgement (the same seems to be true of asian women, actually). If the chance that a good candidate doesn't apply is higher for a particular minority, that means that the chance that a random member of that minority who wouldn't otherwise apply would be a good candidate is higher (assuming that demographics really don't matter). So you get better results by seeking applications from underrepresented minorities and ignoring demographics in your decision than you do by seeking applications equally from everyone.
So hasn't required anything of anyone. Sure, they've tried to get people to pay them for a worthless license, and it's probably fraudulent, but IBM doesn't have standing to complain about that. It's not like SCO has actually bought a copyright infringement claim against anyone over Linux (despite what their press releases have said). Furthermore, they could reveal the license to only apply to parts of their Linux distribution which they have uncontested copyright to, and say that there was confusion over exactly what was meant by "Linux".
As for repudiating the GPL, it doesn't really matter what they say. The GPL grants permission to distribute a program if you license it to recipients under the GPL. You can say you never agreed to the license, and you can insult the document, so long as you actually send the source, send the license, and don't sue anyone for that particular thing. I suspect that SCO has been careful to actually abide by the GPL so that they will be able to use this defense; otherwise, why would they have failed to actually sue Linux users for copyright infringement on code they own in Linux?
I was actually thinking of just the KeyPress events, and displaying in the window, and less intimidating, but that does serve the purpose, yes.
IBM doesn't need Linux developers' loyalty. IBM is generally happy with the stuff that Linux developers do anyway, and they put in their own effort when they need something that others haven't done. They argue for inclusion of their changes on technical merit.
As for this case, IBM isn't going to the mat to defend open source; they're defending themselves in a contract dispute. They're also attacking SCO with copyright claims, but they aren't offering to lead a class action on behalf of Linux copyright holders; they're only using their own copyrights, and intend to keep any damages they are awarded. For that matter, the community, simply out of outrage at SCO, has contributed substantial research to IBM with nothing asked in return.
Now, it would be nice to have actual, specific, legal precedent saying that the GPL is a valid license and that it does not permit its restrictions to be ignored, and having IBM's legal team argue the case is nice. On the other hand, I'm not personally convinced that SCO has actually violated the GPL; they've claimed to have violated it, they're committing international mail fraud, and they're encouraging others to violate it, but the GPL doesn't actually prohibit you from doing these things, and they are, evidentally, continuing to abide by the actual terms. So I suspect that the actual case will come down to whether SCO actually violated the GPL with a set of actions that nobody else is likely to do in the future, once it actually gets to the point of setting precedent.
There are a lot of devices which aren't supported but don't need specific support. For example, most digital cameras aren't supported, but they act as USB storage devices, so you don't need anything special for them. I'm happily using an nVidia card at home with free drivers, and it works fine for 2D stuff, which is all I've tried doing. Devices often have extra features which aren't supported under Linux but which aren't necessarily good ideas anyway.
Between the Sun and Mars, probably.
Keyboard keys are fully-customizable. It's not like your keyboard actually runs programs. It just sends scancodes to the driver, which then sends them to programs (on Linux, generally X, which passes them on to applications). The thing that's really needed is a standard X program that shows the scancode for each key you press in the window.
On the hardware side, it would be nice to have a keyboard that came with no caps on the function keys and a couple dozen extra function-key-sized key caps with pictures on them.
I have to agree that terseness is good; I've found that the changes in Java 5 make it much faster to write. If you don't count lines with nothing but single braces, however, Java is getting pretty good. The main thing that sucks is small callbacks, where you have to have a couple lines of junk around the code.
Hopefully, Java will get parameterized types with a variable number of parameters, and then can have methods as first-class objects.
The thing that makes most Java verbose these days is that the standard libraries, while extensive, are often awkward. It's actually pretty easy to make a library of wrappers that reduces an unreadable 10 lines of code to "ReflectUtils.getStaticFieldValue(cl, name)" and such.
I bet most OSS authors wouldn't be willing to take the effort of collecting money from end users for a mere $99.95 per copy. I don't know about you, but I don't want to work in shipping and billing, let alone marketing or management.
I think most OSS programmers do care about the UI; after all, they're going to be using it most, and, if it's difficult to use, it will probably drive them crazy more than anyone else. On the other hand, they don't care about learnability (because they already know it), and don't necessarily have any skill at making it good.
My contention is that you shouldn't have to rely on coders to implement the UIs you design. The tools you use should produce UIs directly, and the code should be elegant in that it allows you to have the calls you need to make the program function behind the UI.
I think you've misunderstood the unix philosophy. The unix philosophy is to have a set of tools, each of which has a single function, which it performs in an entirely predictable fashion. The GUIs currently available for Linux do not follow the unix philosophy at all, and the tools for a lot of recent applications are not very compliant, either.
What I propose as the right way to involve UI designers in OSS is really the application of the unix philosophy to modern UI ideas: there are a set of operations which may be performed with various details specified, and these operations are documented in extensive detail. The UI designer builds the UI and uses these operations to make it active.
As a side note, I think that you're undervaluing the command line. Certainly it is a bad UI to require the user to type in a complete command while remembering the names of everything and without getting any feedback. But a line of text is about the most complete and expressive description of an action, and I think that a command line with a whole lot of assistance and feedback is probably much clearer than the common WIMP design. But this is really a matter for usability testing to determine; I'll just mention that my mother seems to find Pine on my Linux box easier to use than Windows, and she can write down and follow a set of instructions much easier with a keyboard interface and a WIMP one.
UI designers aren't any more likely than programmers to hate their work and never want to do anything similar in their spare time. The reason that OSS projects don't usually have UI designers as regular contributors is the amount of knowledge necessary to change a program's UI that isn't in the standard graphic design curriculum. In the commercial world, UI designers generally work by having the authority to tell programmers what to do; in the OSS world, they have no way to get this authority, because they don't have the skills for the entry-level gathering of respect.
In order to have good UIs, we need to involve people who can design them. In order to involve them, we have to empower them to make patches on their own. And that means arranging for UI coding to be completely obvious, and separate from the inner workings of the program.
Considering that a substantial portion of the economy now depends on secure communications, this is pretty unlikely. Between online credit card purchases, online banking, DVDs, and VPNs, there's not all that much in the business world that would be able to continue as it is at this point without encryption.
It's not a coincidence that all actual police states have had centralized economies, and nationalizing businesses is one thing that would have a hard time getting through Congress, considering that it would be opposed by practically everyone with lobbyists.
Unfortunately, the transparent stuff isn't very good for blocking EM radiation in the critical petahertz range...