Did you read the linked page? It explains how that CSS menu degrades gracefully to be perfectly useful -- just not as flashy -- in browsers without the proper CSS support. Graceful degradation is a key design principle of HTML which many sites choose to ignore (ex. by requiring Flash or JavaScript). A good example is the commenting on Slashdot with the new discussions system: if you do not have JavaScript enabled, the reply button is just a normal link, allowing, for example, opening a reply box in a new tab, while supporting the AJAX inline reply box as well.
Hint: Forms with password boxes contain secret information.
Of course, plenty of sites send passwords over HTTP (hopefully no banks...), so a blanket warning on passwords being sent unencrypted would just train users to ignore the warning. Furthermore, the use of passwords sent via HTTPS forms is still training users to type their passwords into phishing sites (if they manage to get to one via a typo or convincing e-mail (my credit card company includes links to their site in their e-mails, faking those e-mails with a slightly different link would be trivial)), but better auth methods are not easy to switch to.
I am not sure exactly how you would incentivize schools in poor areas -- probably by funneling the money through larger regions (states/federal government) so the wealthier areas end up subsidizing them.
On the other hand, a system where private schools are fighting over students sounds great. Properly managed competition generally makes industries more efficient and provide better products.
Sorta. Wikipedia has the full details, but here is the relevant part:
The age of consent in Pennsylvania is 16 years of age. Teenagers aged 13, 14 and 15 may legally engage in sexual activity with partners who are less than 4 years older.
... (3) there will be no one to buy solar panels from because everyone else had the same reasoning and the solar panel manufacturers all went bankrupt.
Someone has to be the early adopters and actually fund the research and have real world data on how well solar panel installations actually work and what various details need more attention.
Problems we experience: Privacy. It's difficult to ascertain just what records which type of doctor should be seeing, so right now we basically have a system where any variety of doctor or technician can see any variety of a particular patient's records (except Mental Health and STD visits, which are accessible only by password by default). This situation makes some patients rather uncomfortable.
It seems like with a rather simple security system, this could be handled in a way very similar to how paper records are handled: to give them to another doctor, one of the doctors/offices with access to the files has to somehow give it to the doctor that needs access (probably handing it over physically or faxing it). With a computer database, there could be a "give doctor access" button (maybe to a section of that person's information, if that makes sense). To keep the security simple, allow any doctor that can see a file access to give the file to another doctor (as that is the old security). This still keeps the privacy advantages over paper in that the paper cannot fall into the wrong hands and 99% of doctors do not have access to any specific person's medical records. Also, it would likely match the system used with paper rather closely which would aid the transition. If it made sense, more advanced security could possibly be added later.
How? If the user is willing to give their password to http://twitter.access-logins.com/login/, why wouldn't they give their password to https://twitter.access-logins.com/login/?
SSL logins are a good idea, but I do not see how they address phishing. I guess an EV might have some effect because users might be trained to expect to see "Twitter, Inc." in the URL bar... but if they are not even looking to see if they are on twitter.com when entering their password, I doubt it.
The real problem is sending passwords in plaintext (or encrypted plaintext like SSL, which doesn't help if you have an encrypted connection straight to the phishers) as opposed to some form of challenge response, but that is a hard one to fix since they are so prevalent and the framework to replace them does not really exist.
The CA cannot spy on any arbitrary SSL traffic, but they can MITM any SSL connection (that they can intercept) because they are able to create a trusted certificate that says anything they want so they can make their own key pair and sign that. Then they can spy on any connection they MITM. More work than just looking and theoretically detectable, but CAs certainly have the ability to spy on SSL connections if they want to.
That is pretty common in RPGs. I remember thinking it was a bit less blatant in Metroid Prime, but I very recently played two RPGs which usually only had save points in dungeons if the boss was in the next room, so it was a pretty obvious hint that the boss was next.
This is not exactly a new proposal, and it has been shot down on Slashdot before. One major problem is that a lot of spam is through botnets and the spammers would not get charged the e-mail fees, people with zombied computers would. I suppose this would make people with zombied computers notice, but why would they agree to sign up for such a service in the first place? Also, tying e-mail to payment means that the payment is probably traceable to a real person, which a lot of people do not want.
Which is why students use text messages. It is nearly impossible to miss a student talking on their phone during class, but students have no problem holding their phone under their desk and texting during class without getting caught.
The DRM is not an issue. Virtual console games are encrypted and tied to the Wii they were bought on. You can copy them to an SD card, you just have to copy them back onto the Wii to actually play them, which seems quite silly.
Okay, give each thread a buffer. Not a big deal, although something you do have to remember to do.
It sounds like the problem is not with OOP, but with garbage collected languages with insufficiently intelligent allocators/garbage collectors. The solution seems to be to either use an unsafe language which allows direct control of memory (like C++) or make the allocator smarter, perhaps by including profiling in the optimization process (otherwise the optimizer might not get clued in that it should prepare space for lots of message objects) or possibly just some sort of hinting from the programmer.
Perhaps I am misunderstanding, but in the frameworks I have used, I do not touch the event loop. I just register events and have methods get called when they occur. In Java, the order is based on the order of registration with the event, but if the event handler does a lot of work, it should probably be in a separate thread anyway (as the next event handler cannot be called until the current one returns). I think I am just not envisioning a system with the massive number of events you seem to be describing as causing a problem because I just have not worked with a project that large. I am not sure why a GUI would have so many event handlers around that it would be hard to keep track of all of them; I would expect at most one (a few?) of each type on each widget, and even then you probably do not care about most of the events.
GUI engines are outgrowing objects in my opinion. Objects are fine when you have hundreds, but not bajillions.
May I ask what you mean by that? I only have GUI programming experience in AWT, Swing, and a little GTK, and from those objects seem very natural for GUI programming. Your description of events sounds pretty much like those frameworks handle events, except you do have to think about how the event loop works due to threading issues, which seems like it could be fixed in the context of OOP.
The Metascore project (part of the Metagovernment project) is working on a moderation system that would work for a discussion of that scale, which may be interesting. I do not know if they will come up with a working solution, but it is worth looking at.
May I ask what is wrong with other methods like BitTorrent? Too much work to set up? I suspect the files are too large for e-mail, which would explain not using that. I am not trying to troll; it just seems ridiculous (although probably true) that the best way to send a video to your friends is to upload it to a third-party ad supported website which imposes strict quality and time limits. Does anyone else have suggestions for an easy to use way to do such transfers?
Voice recognition certainly has uses, of course. If you lack fingers, or the space for a keyboard, or your hands are busy doing other things -- like flying a fighter jet -- certainly. But if you're composing an essay, or a report, or doing anything where accuracy matters. ..why not type up your resume by throwing a frisbee -- one foot for the letter A, two feet for the letter B., and so on.
You seem to be sorta getting to the point here: use the right tool for the job. For normal text entry and most graphical interfaces, keyboard and mouse are the right tools. For applications like "sounds like" dictionary/spell check lookup or text entry on a device too small for a keyboard or when your hands are otherwise occupied (say, driving or, as you suggest, flying a jet), voice recognition (or subvocalization) is more likely to be the right tool. Other posters have suggested that when you want to manipulate a physical object on screen, multitouch works well, probably much better than a mouse combined with keyboard commands. I am sure there are other instances where it would be the optimal control method.
Currently most (computer) interfaces are keyboard-only or keyboard and mouse. The Slashdot audience is probably familiar with various tasks that are normally done with a mouse that they find easier/more efficient to do with a keyboard (see: vim/emacs vs. a common word processor or text editor). Adding more control mechanisms allow for more variety of interfaces, which will likely be better for at least some subset of users. If you do not like hand gestures then you can not get a device that uses them / use software that supports the control methods you prefer.
You are talking about static code analysis and formal verification. Basically, you can write proofs that a program works and halts, but programming languages and compilers that work with such proofs are very rare outside of research settings, mostly because proving a program is valid is a very long and tedious process. I suspect mainstream compilers will be getting better about checking if programs definitely halt and other easy proofs (like you seem to be discussing) in the future.
Also, there is the field of programming languages with very detailed type systems which, among other things, may be able to prove that an integer can never overflow. How much the programmer has to write about those types varies from language to language, but such languages are generally consider research only and too complicated for normal use.
Slashdot Mirror
Here is an article on the study by the BBC. Google finds a lot of similar articles.
This article explores this fourth possible explanation for the dearth of women in science: They found better jobs.
Basically, it argues that men are too stubborn and competitive to get out of math/science when they should.
Did you read the linked page? It explains how that CSS menu degrades gracefully to be perfectly useful -- just not as flashy -- in browsers without the proper CSS support. Graceful degradation is a key design principle of HTML which many sites choose to ignore (ex. by requiring Flash or JavaScript). A good example is the commenting on Slashdot with the new discussions system: if you do not have JavaScript enabled, the reply button is just a normal link, allowing, for example, opening a reply box in a new tab, while supporting the AJAX inline reply box as well.
Of course, plenty of sites send passwords over HTTP (hopefully no banks...), so a blanket warning on passwords being sent unencrypted would just train users to ignore the warning. Furthermore, the use of passwords sent via HTTPS forms is still training users to type their passwords into phishing sites (if they manage to get to one via a typo or convincing e-mail (my credit card company includes links to their site in their e-mails, faking those e-mails with a slightly different link would be trivial)), but better auth methods are not easy to switch to.
In fact, as Arrow's Impossibility Theorem proves, no voting system is fair if there are more than two candidates, for quite modest meanings of "fair".
Yes, no (rankings based) voting system can be fair, but first-past-the-post is not even trying.
So, you were hoping for ads more like the rejected PETA ad (non-PETA link)? ;-)
I am not sure exactly how you would incentivize schools in poor areas -- probably by funneling the money through larger regions (states/federal government) so the wealthier areas end up subsidizing them.
On the other hand, a system where private schools are fighting over students sounds great. Properly managed competition generally makes industries more efficient and provide better products.
You mean like nLite/vLite?
The age of consent in Pennsylvania is 16 years of age. Teenagers aged 13, 14 and 15 may legally engage in sexual activity with partners who are less than 4 years older.
If he puts the system in in, say, 5 years time
... (3) there will be no one to buy solar panels from because everyone else had the same reasoning and the solar panel manufacturers all went bankrupt.
Someone has to be the early adopters and actually fund the research and have real world data on how well solar panel installations actually work and what various details need more attention.
Problems we experience: Privacy. It's difficult to ascertain just what records which type of doctor should be seeing, so right now we basically have a system where any variety of doctor or technician can see any variety of a particular patient's records (except Mental Health and STD visits, which are accessible only by password by default). This situation makes some patients rather uncomfortable.
It seems like with a rather simple security system, this could be handled in a way very similar to how paper records are handled: to give them to another doctor, one of the doctors/offices with access to the files has to somehow give it to the doctor that needs access (probably handing it over physically or faxing it). With a computer database, there could be a "give doctor access" button (maybe to a section of that person's information, if that makes sense). To keep the security simple, allow any doctor that can see a file access to give the file to another doctor (as that is the old security). This still keeps the privacy advantages over paper in that the paper cannot fall into the wrong hands and 99% of doctors do not have access to any specific person's medical records. Also, it would likely match the system used with paper rather closely which would aid the transition. If it made sense, more advanced security could possibly be added later.
How? If the user is willing to give their password to http://twitter.access-logins.com/login/, why wouldn't they give their password to https://twitter.access-logins.com/login/?
SSL logins are a good idea, but I do not see how they address phishing. I guess an EV might have some effect because users might be trained to expect to see "Twitter, Inc." in the URL bar... but if they are not even looking to see if they are on twitter.com when entering their password, I doubt it.
The real problem is sending passwords in plaintext (or encrypted plaintext like SSL, which doesn't help if you have an encrypted connection straight to the phishers) as opposed to some form of challenge response, but that is a hard one to fix since they are so prevalent and the framework to replace them does not really exist.
The CA cannot spy on any arbitrary SSL traffic, but they can MITM any SSL connection (that they can intercept) because they are able to create a trusted certificate that says anything they want so they can make their own key pair and sign that. Then they can spy on any connection they MITM. More work than just looking and theoretically detectable, but CAs certainly have the ability to spy on SSL connections if they want to.
That is pretty common in RPGs. I remember thinking it was a bit less blatant in Metroid Prime, but I very recently played two RPGs which usually only had save points in dungeons if the boss was in the next room, so it was a pretty obvious hint that the boss was next.
This is not exactly a new proposal, and it has been shot down on Slashdot before. One major problem is that a lot of spam is through botnets and the spammers would not get charged the e-mail fees, people with zombied computers would. I suppose this would make people with zombied computers notice, but why would they agree to sign up for such a service in the first place? Also, tying e-mail to payment means that the payment is probably traceable to a real person, which a lot of people do not want.
Which is why students use text messages. It is nearly impossible to miss a student talking on their phone during class, but students have no problem holding their phone under their desk and texting during class without getting caught.
The DRM is not an issue. Virtual console games are encrypted and tied to the Wii they were bought on. You can copy them to an SD card, you just have to copy them back onto the Wii to actually play them, which seems quite silly.
Okay, give each thread a buffer. Not a big deal, although something you do have to remember to do.
It sounds like the problem is not with OOP, but with garbage collected languages with insufficiently intelligent allocators/garbage collectors. The solution seems to be to either use an unsafe language which allows direct control of memory (like C++) or make the allocator smarter, perhaps by including profiling in the optimization process (otherwise the optimizer might not get clued in that it should prepare space for lots of message objects) or possibly just some sort of hinting from the programmer.
Perhaps I am misunderstanding, but in the frameworks I have used, I do not touch the event loop. I just register events and have methods get called when they occur. In Java, the order is based on the order of registration with the event, but if the event handler does a lot of work, it should probably be in a separate thread anyway (as the next event handler cannot be called until the current one returns). I think I am just not envisioning a system with the massive number of events you seem to be describing as causing a problem because I just have not worked with a project that large. I am not sure why a GUI would have so many event handlers around that it would be hard to keep track of all of them; I would expect at most one (a few?) of each type on each widget, and even then you probably do not care about most of the events.
GUI engines are outgrowing objects in my opinion. Objects are fine when you have hundreds, but not bajillions.
May I ask what you mean by that? I only have GUI programming experience in AWT, Swing, and a little GTK, and from those objects seem very natural for GUI programming. Your description of events sounds pretty much like those frameworks handle events, except you do have to think about how the event loop works due to threading issues, which seems like it could be fixed in the context of OOP.
How would you rather they be handled?
The Metascore project (part of the Metagovernment project) is working on a moderation system that would work for a discussion of that scale, which may be interesting. I do not know if they will come up with a working solution, but it is worth looking at.
May I ask what is wrong with other methods like BitTorrent? Too much work to set up? I suspect the files are too large for e-mail, which would explain not using that. I am not trying to troll; it just seems ridiculous (although probably true) that the best way to send a video to your friends is to upload it to a third-party ad supported website which imposes strict quality and time limits. Does anyone else have suggestions for an easy to use way to do such transfers?
If someone can prove how they voted then they can be coerced to vote a certain way.
Voice recognition certainly has uses, of course. If you lack fingers, or the space for a keyboard, or your hands are busy doing other things -- like flying a fighter jet -- certainly. But if you're composing an essay, or a report, or doing anything where accuracy matters. . .why not type up your resume by throwing a frisbee -- one foot for the letter A, two feet for the letter B., and so on.
You seem to be sorta getting to the point here: use the right tool for the job. For normal text entry and most graphical interfaces, keyboard and mouse are the right tools. For applications like "sounds like" dictionary/spell check lookup or text entry on a device too small for a keyboard or when your hands are otherwise occupied (say, driving or, as you suggest, flying a jet), voice recognition (or subvocalization) is more likely to be the right tool. Other posters have suggested that when you want to manipulate a physical object on screen, multitouch works well, probably much better than a mouse combined with keyboard commands. I am sure there are other instances where it would be the optimal control method.
Currently most (computer) interfaces are keyboard-only or keyboard and mouse. The Slashdot audience is probably familiar with various tasks that are normally done with a mouse that they find easier/more efficient to do with a keyboard (see: vim/emacs vs. a common word processor or text editor). Adding more control mechanisms allow for more variety of interfaces, which will likely be better for at least some subset of users. If you do not like hand gestures then you can not get a device that uses them / use software that supports the control methods you prefer.
You are talking about static code analysis and formal verification. Basically, you can write proofs that a program works and halts, but programming languages and compilers that work with such proofs are very rare outside of research settings, mostly because proving a program is valid is a very long and tedious process. I suspect mainstream compilers will be getting better about checking if programs definitely halt and other easy proofs (like you seem to be discussing) in the future.
Also, there is the field of programming languages with very detailed type systems which, among other things, may be able to prove that an integer can never overflow. How much the programmer has to write about those types varies from language to language, but such languages are generally consider research only and too complicated for normal use.