Actually, probably more than half of Microsoft users don't want to have anything to do with them. Lots of people care (about all these things), they just don't do anything.
I think IT departments concerned about security should make it a stated policy that they will try to find out your password, and, if they succeed, they'll reset it and prevent you from ever using that one again, and you have to figure out yourself that it's been changed, and ask them to let you set it to something you know. That would quickly make people a lot more resistant to social engineering and less likely to write passwords down or choose obvious ones. It would also show that the IT department is doing something about password security, since they'd occasionally catch people revealing their passwords and enforce the policy.
(Obviously, they wouldn't use their special IT abilities, like being able to install keyloggers on people's computers, but anything that an arbitrary employee would be able to do without being too obvious or causing damage is fair game.)
Since the correction is that "ID by rows" isn't supposed to be anything (it's random padding at the end to make the block in the sculpture line up and to conceal the true length of the message), and it only looks like words by chance, after the sculptor removed the final punctuation of the actual message for aestetic reasons without checking that the random padding wasn't now shifted into decoding to something, that site, which doesn't use the "ID by rows" line at all is just as accurate as ever.
With Google, you don't find out anything particularly interesting with you search for certain topics, at least if you're not clever about it. And, of course, you can't use Google as a proxy to get to web sites that the government blocks, but Google isn't a proxy service anyway (Google doesn't give you in the US unrestricted access to, for example, the New York Times article, nor should it).
Anyway, the main information factor in formenting revolution is generally not particular details, pieces of history, etc. It's more abstract concepts, like, for example, the engineering method: that you can find the best way to do things not by being told by somebody authoritative, but by trying things. And that isn't a matter of a web site that says "You might be able to have a better life if you change your government", which could be censored, but a matter of watching engineering being done. The Linux kernel mailing list archives are really more subversive than your average "subversive" website (if you start actually following it enough to get an idea of the characters involved), because they contain numerous examples of authority figures being forced to accept changes that they oppose, simply based on those changes actually being right.
What I actually see as the main issue is that the proprietary code links with the kernel (sort of; there's generally an open-source glue layer so that you can use the same proprietary object file with a variety of kernels) and runs in its address space. I'd like to see a driver in the kernel which handles the bus behavior of the card, presenting it as a generic device to userspace, and proprietary code in userspace that does graphics with this device. It wouldn't be particularly slow, since it could be given special scheduling status and there's nice things for zero-copy data transfer these days, and Linux's system call overhead is really low.
It would still be nice to be able to debug display problems and be able to tweak your driversto do new and interesting things, but at least you'd have the userspace protections as a barrier to any intentional or accidental driver misbehavior.
(One of the reasons that USB is going open-source-only is that there is libusb for controlling USB devices from userspace, so proprietary software for a USB device can be entirely in userspace and clearly not a license problem.)
Re:Simplicity, price, and size please
on
The Future of the PDA
·
· Score: 3, Insightful
I'd also really like to see something that's UI-equivalent with my trusty Handspring Visor Deluxe. The differences I want:
Sync with a standard mini-USB cable, instead of a cradle.
Support charging rechargable AAA batteries when plugged in.
Use sane file formats for memos, notes, calendar entries, and addresses.
It'd be nice to support a mini-SD card for storage, so that you can replace it if it breaks by removing the card and putting it in a new one.
I think it would be cute to support Bluetooth keyboard and mouse, just so you could look weird in cafes, with a full-size keyboard for a computer the size of the numeric keypad. But that's just silly.
Now you are veering away from realistic scenarios and conjuring up an AI system requiring a much deeper grasp of language, which requires cognitive abilities that are too far off into the future technologically to begin speculating about.
I don't think it needs a very deep grasp of language; it needs a deep grasp of chess, and some grasp of language. I think the current generation of chess programs (Fritz, Shredder, etc., not Deep Blue) has the necessary abstract and explicit knowledge about chess to support conversation about the subject. It would need advances in language to be a plausible conversational partner, but nothing insurmountable.
There's no real inherent intelligence in linguistical analysis without accompanying semantical analysis, which programmers have yet to figure out how to code.
I don't think there's really such a thing as semantic analysis as a general thing. My claim is that it's all part of a working knowledge of some field or other, and the only magic missing part is having all the parts put together in such a way that the mismatches don't prevent information from getting through. Our introspection tells us that there's a sentient center somewhere in there, but I think that's just an illusion our minds create to keep us from second-guessing ourselves too much. We seem to have general intelligence apart from any particular subject, but I think that's just the ability of the specific mechanisms to not notice that the information they're dealing with isn't really applicable.
I don't think the parlor-trick version of language processing is useful for this, but I think linguistics isn't too far off from being able to handle the demands of explaining a chess program's analysis and discussing it at a rudimentary level. A chess master is very intelligent, but this isn't a particularly language-oriented intelligence. We don't need the program to elucidate the analysis with metaphors, or write a sonnet about it, or argue convincingly about the correctness of the analysis; nor do we need to figure out the human's motivations, or understand rhetoric, or odd, archaic, or slang requests. The chess master isn't going to sit down at the computer and say, "So, how about those black bishops?" and expect the computer to have any clue how to respond.
So this is actually a humble step (once you've got a chess program that plays in a way comprehensible to humans, of course): the human is going to be reasonably formal, stay on a known topic, and not be too demanding about style, while the computer has a large body of information which may be conveyed through language with the shared understanding of the terminology for the computer's chess-playing methods ("sacrifice", "trap", "tempting", etc) as well as chess terminology ("knight", "rank", "move", etc).
From there, we could move into much harder things, like trying to convince a person that the program's analysis of a chess match is correct.
The issue, in my opinion, is that doing a chatbot other than as a parlor trick doesn't give interesting results unless you undertake quite an advanced project. The environment of a conversation is pretty harsh; people will quickly get fed up with a system that acknowledges that it doesn't understand much language and doesn't have anything to talk about.
I think the best change for chatbox advances is actually chess programs. Recent programs are actually doing clever things that aren't just a lot of calculation, and they often come up with plans that their programmers don't expect, and that are based on recognizing complicated patterns (rather than just a huge list of favorable outcomes). So it could be useful in debugging such systems if the program could carry on a simple conversation with the programmer: "Why did you make that move halfway through the previous game?" "I saw a chance to set up an attack of this sort, and guessed that I could get my opponent to fall for a trap to make it happen, but it either didn't fall for it or didn't see it, so I abandoned that plan without going any further on it." "I think the bait for the trap wasn't tempting enough. You were overestimating your opponent's interest in taking your knights." "I was expecting them to be worth about this much, because..." Then the programmer adds support for whatever was off about the program's evaluation of the sacrifice. The programs are getting to the point where a conversation is justified, and development teams are starting to include chess experts who don't necessarily have computer experience and would help more given a human-language analysis of what happened. And it's starting to be plausible as a possibility, because these programs have a significant amount of understanding of what's going on.
I've used Oracle on both Linux and Solaris. We were running it on Linux workstations, along with a bunch of other things, for development, and on Solaris to test it in the conditions we expected it to use in production, with nothing else running on the database server. Even so, we found that it was faster in the Linux setup. Of course, this is a while ago, and on relatively small data sets, and not an especially high-end Solaris machine, but it was still striking. At the time, at least, if you could get a big enough Linux box to handle your data, it would cost probably 1/20 of the cost of a Solaris system capable of the same performance. You'd probably have issues if you had to move to a database cluster, because the software for getting a cluster to work wasn't so good (when we tried it a few years later), but for a range of useful sizes, Linux was a much better value than Solaris.
The issue with clusters seemed to be that it was only available in a special custom Red Hat configuration, and it wasn't well tested, because it was just Red Hat and Oracle doing it, not everybody looking over the patches for whether they would screw up the rest of the system. There's been a bunch of merging work on cluster stuff since then, so the code quality is probably now up to the usual standards.
(Of course, I've been just as happy with other database programs on Linux, but I don't have any experience trying to use them for insanely large or busy databases; our program was supposed to work with huge data, but we never used it on huge data ourselves.)
Very little serious work has gone into chatbots since the 80s. The reason is that it's easy to make a chatbot that does practically nothing more than the textual equivalent of nodding whenever someone stops talking. It's hard to get any further with this approach. Actually chatting requires the bot to know something about some topic and be able to evaluate the other party's statements about it. Until both of these are done, you don't get a meaningful improvement. Furthermore, the system needs to be able to introspect its understanding of the topic. (There have been very old chatbots which actually did pretty well, by having a limited understanding of language and of some restricted topic. But these are relatively unintersting to chat with, compared to bots that let the user talk about anything and nod). Most of the recent AI research has involved making systems which behave appropriately in complex situations, and introspection isn't helpful for this (in people, this sort of stuff is preconscious, too; you can't explain how you recognize faces or voices or exactly how you identify spoken words). The things people have been working on turn out to have more direct practical uses, but they don't give the system anything to talk about. And, of course, there's been relatively little work on understanding arbitrary language since it became clear that it isn't that effective a way of communicating with computers anyway, because the human output side is slow and ambiguous, compared to other user interfaces.
Most likely, introspection in AI systems will be driven at some point by the need to combine different types of input to make a complete analysis (once there is sufficient success at handling those sorts of input), and language use will be driven by the need to handle language written for people as input (e.g., reading news reports for background information). At that point, it'll become reasonable to write an effective chatbot which talks about stuff that people care about.
I didn't mean to imply that they were missionaries, let alone fundamentalists. I was a bit carelessly suggesting that they did translations of the bible; but I'd assume that all translations of the bible are relevant to their work, so they'd have some familiarity with the issues involved in documents in modern written languages with odd features, in addition to odd ancient languages that relate to their work.
And it is a bit unusual for a group of humanities academics to get involved in technology, unfortunately. I know somehow who recently had a lot of trouble with quoting Armenian in her Byzantine Studies master's thesis and didn't get any help from her department. (This was a bit before ODF was actually specified and implemented.) So the SBL is a bit unusual in both knowing about exciting formatting needs and actually telling an OASIS committee what those needs are.
Being CEO is incompatible with doing any of the productive work of the business. It's a full-time bureaucracy job. Assuming you were basing your business model on your ability to do something, you need to be free to actually make the shots, not spend all of your time calling them.
The MN bill is not specific to ODF. It would require use of some open format (i.e., one which is clearly specified and may be implemented without license restrictions) if such a format is available. Under this bill, ODF would only be required if it is, in fact, ready.
The MA situation doesn't involve legislation, but is an executive order from the IT department. The IT department is responsible for implementing the switch, and there's no reason it couldn't abandon the project if it turned out to be unworkable. They're also perfectly able to make exceptions for cases where they can't get it to work or simply don't feel like dealing (if someone had an extremely complex Word macro that they use a lot, and the ITD couldn't figure out how to do it in ODF, they could just shrug and let it go), because it's just a policy, not a law.
With respect to the maturity of ODF, it was developed by a group of organizations which, between them, are likely to have all of the needs that anyone has. For example, the Society for Biblical Literature was an active member of the technical committee. This may be a bit surprising, until you realize that they've got at least one document (a translation of the bible) in every known living language, documents in many dead languages, and things like illuminated hand-written manuscripts. Additionally, ODF was designed to include the concepts in Microsoft Office formats (based on existing converters and on inspection of the interface presented to the user).
NPR is trying to get everything into their podcast directory to have this sort of uniformity. It's already to the point of having a couple hundred shows there.
I don't think the model of paying for the archives is going to work for most NPR shows; most of them are in some way discussing current events, so they become pointless or incomprehensible after a few weeks.
On the other hand, NPR's business model has always been to make people care that it continues and therefore fund it. They've never had to model of exchanging something for money. Unlike in a lot of industries, NPR's issue with online distribution is mainly the distribution of money. It used to be that listeners would donate to their local stations, even though small local stations don't produce much content; the big local stations produce content, and don't mind that small stations freeload on the content, because the big stations have more listeners and therefore more money to fund shows. Producing shows is in part a matter of pride, and in part an effect of ability. But with online distribution, the entities that the listeners hear about are the central organization (which isn't set up to run on donations directly from listeners) and the large stations that produce shows (which are fine with donations from their local areas). It's all a matter of getting the money redistributed in a way that isn't actually fair but is how it needs to be. (Closing all the small local stations would be bad, because they do local reporting, which matters a lot to locals, but which wouldn't generate the funding to support a station by itself.)
If those are your Windows applications, you could probably run Windows without any network access. Of course, the users need network access at the same time, but using VMWare or equivalent with the only Windows network being a local non-gateway link to another guest that serves a shared drive (so you can get data into and out of the applications) would probably solve your security issues.
As described, this would be the first time that Google would be getting money directly from the masses. I don't think selling music themselves is enough of a feature to justify the hassle for them. I think it's much more likely that they'll stick with the search step, and pass customers to vendors who are willing to give them commissions. So you search for a song (by lyrics, title, performer, composer, etc.), and you get a list of results, each with links to places you can buy the song.
It's possible that Google will do a store eventually, but I bet they'd start by getting a lot of customers going through their site to other stores, like they did for maps originally (with Yahoo and Mapquest as options for the actual map), and stocks (with a number of options for the quotes).
The slowness of the XML parser doesn't matter much if you don't save and reload the document with every modification.
Actually, OOo is so slow because they don't use a widget set. The display is hand-drawn by a bunch of monks in Germany, because the project started before Qt or Gtk.
My wife, on the other hand, giggled a bunch. And then said, "I'd read them more if they had more about ponies." So where are the stories with ponies? There must be someone who's made a full-scale working pony out of legos, or genetically-engineered green phosphorescent ponies, or pony clones (clonies?), and so forth. And in Tsarist Russia...
Actually, what could be done is to tell people to view the certificate for the site, and verify that the SHA1 fingerprint matches what's printed on the back of their card. Of course, there's no way to get Chase's certificate without using your password, so it's presently hopeless.
With browser support, you would identify the certificate when you originally set up your account, and you'd mark the certificate in your browser as belonging to your bank, and no other site could make the greeting look like your bank, because your browser wouldn't recognize the certificate (and it would therefore pop up message saying "This is an ecommerce site that you don't have an existing relationship with", instead of "This is your bank").
It would depend on how the device is used. If someone uses it instead of trying to read expressions, they'll just become dependant on it. But if they try to anticipate what it's going to tell them, they can use it to learn. Autistic people in some living conditions are like people trying to learn a foreign language with flash cards who don't ever get to look at the answer side of the card, because people in their surroundings never explain their emotions, so they never find out any correct answers to learn.
None of these people was actually sufficiently paranoid for my taste, including the study designers. The study designers claim that 7 web sites in their list were legitimate, but they ask "Imagine that you receive an email message that asks you to click on one of the following links. Imagine that you decide to click on the link to see if it is a legitmate website or a "spoof" (a fraudulent copy of that website)." I don't have accounts at any of the sites they list, and practially nobody would have accounts at all of them (there are three different banks, for example). Even if the site is "real", there must be something illegitimate going on in this situation.
For all of the organizations in this survey, the user should have a pre-existing relationship with the organization in order for an interaction to be legitimate, and none of the evaluation methods used (or available in this study) evaluate this.
My favorite piece of data (from figure 2) was that, of users who checked for SSL use, those who checked certificates did worse than those who didn't.
This just lets you set the maximum volume setting. But if there's some maximum volume setting you don't want to exceed, just don't set the volume higher. The real issue, in my opinion, is that you're likely to have tracks that have different average volumes, and if you play a quiet track, you'll turn it up, and then the next loud track damages your hearing. Using this feature to limit it, you play a quiet track, and you can't hear it. Or you adjust the maximum while playing a medium-volume track, and the loud tracks damage your hearing anyway. What they need is something to calculate RMS volume levels and automatically adjust the volume to even out tracks and limit the loudness of the output independant of the input.
You mean you don't think the post was a prayer for divine intervention? It's a bit of an odd idea, but terrestrial agents seem ineffective, so maybe it's worth a try.
Slashdot Mirror
Actually, probably more than half of Microsoft users don't want to have anything to do with them. Lots of people care (about all these things), they just don't do anything.
I think IT departments concerned about security should make it a stated policy that they will try to find out your password, and, if they succeed, they'll reset it and prevent you from ever using that one again, and you have to figure out yourself that it's been changed, and ask them to let you set it to something you know. That would quickly make people a lot more resistant to social engineering and less likely to write passwords down or choose obvious ones. It would also show that the IT department is doing something about password security, since they'd occasionally catch people revealing their passwords and enforce the policy.
(Obviously, they wouldn't use their special IT abilities, like being able to install keyloggers on people's computers, but anything that an arbitrary employee would be able to do without being too obvious or causing damage is fair game.)
Since the correction is that "ID by rows" isn't supposed to be anything (it's random padding at the end to make the block in the sculpture line up and to conceal the true length of the message), and it only looks like words by chance, after the sculptor removed the final punctuation of the actual message for aestetic reasons without checking that the random padding wasn't now shifted into decoding to something, that site, which doesn't use the "ID by rows" line at all is just as accurate as ever.
With Google, you don't find out anything particularly interesting with you search for certain topics, at least if you're not clever about it. And, of course, you can't use Google as a proxy to get to web sites that the government blocks, but Google isn't a proxy service anyway (Google doesn't give you in the US unrestricted access to, for example, the New York Times article, nor should it).
Anyway, the main information factor in formenting revolution is generally not particular details, pieces of history, etc. It's more abstract concepts, like, for example, the engineering method: that you can find the best way to do things not by being told by somebody authoritative, but by trying things. And that isn't a matter of a web site that says "You might be able to have a better life if you change your government", which could be censored, but a matter of watching engineering being done. The Linux kernel mailing list archives are really more subversive than your average "subversive" website (if you start actually following it enough to get an idea of the characters involved), because they contain numerous examples of authority figures being forced to accept changes that they oppose, simply based on those changes actually being right.
What I actually see as the main issue is that the proprietary code links with the kernel (sort of; there's generally an open-source glue layer so that you can use the same proprietary object file with a variety of kernels) and runs in its address space. I'd like to see a driver in the kernel which handles the bus behavior of the card, presenting it as a generic device to userspace, and proprietary code in userspace that does graphics with this device. It wouldn't be particularly slow, since it could be given special scheduling status and there's nice things for zero-copy data transfer these days, and Linux's system call overhead is really low.
It would still be nice to be able to debug display problems and be able to tweak your driversto do new and interesting things, but at least you'd have the userspace protections as a barrier to any intentional or accidental driver misbehavior.
(One of the reasons that USB is going open-source-only is that there is libusb for controlling USB devices from userspace, so proprietary software for a USB device can be entirely in userspace and clearly not a license problem.)
I'd also really like to see something that's UI-equivalent with my trusty Handspring Visor Deluxe. The differences I want:
Sync with a standard mini-USB cable, instead of a cradle.
Support charging rechargable AAA batteries when plugged in.
Use sane file formats for memos, notes, calendar entries, and addresses.
It'd be nice to support a mini-SD card for storage, so that you can replace it if it breaks by removing the card and putting it in a new one.
I think it would be cute to support Bluetooth keyboard and mouse, just so you could look weird in cafes, with a full-size keyboard for a computer the size of the numeric keypad. But that's just silly.
Yes, but you can change that with a USE flag.
I don't think it needs a very deep grasp of language; it needs a deep grasp of chess, and some grasp of language. I think the current generation of chess programs (Fritz, Shredder, etc., not Deep Blue) has the necessary abstract and explicit knowledge about chess to support conversation about the subject. It would need advances in language to be a plausible conversational partner, but nothing insurmountable.
I don't think there's really such a thing as semantic analysis as a general thing. My claim is that it's all part of a working knowledge of some field or other, and the only magic missing part is having all the parts put together in such a way that the mismatches don't prevent information from getting through. Our introspection tells us that there's a sentient center somewhere in there, but I think that's just an illusion our minds create to keep us from second-guessing ourselves too much. We seem to have general intelligence apart from any particular subject, but I think that's just the ability of the specific mechanisms to not notice that the information they're dealing with isn't really applicable.
I don't think the parlor-trick version of language processing is useful for this, but I think linguistics isn't too far off from being able to handle the demands of explaining a chess program's analysis and discussing it at a rudimentary level. A chess master is very intelligent, but this isn't a particularly language-oriented intelligence. We don't need the program to elucidate the analysis with metaphors, or write a sonnet about it, or argue convincingly about the correctness of the analysis; nor do we need to figure out the human's motivations, or understand rhetoric, or odd, archaic, or slang requests. The chess master isn't going to sit down at the computer and say, "So, how about those black bishops?" and expect the computer to have any clue how to respond.
So this is actually a humble step (once you've got a chess program that plays in a way comprehensible to humans, of course): the human is going to be reasonably formal, stay on a known topic, and not be too demanding about style, while the computer has a large body of information which may be conveyed through language with the shared understanding of the terminology for the computer's chess-playing methods ("sacrifice", "trap", "tempting", etc) as well as chess terminology ("knight", "rank", "move", etc).
From there, we could move into much harder things, like trying to convince a person that the program's analysis of a chess match is correct.
The issue, in my opinion, is that doing a chatbot other than as a parlor trick doesn't give interesting results unless you undertake quite an advanced project. The environment of a conversation is pretty harsh; people will quickly get fed up with a system that acknowledges that it doesn't understand much language and doesn't have anything to talk about.
I think the best change for chatbox advances is actually chess programs. Recent programs are actually doing clever things that aren't just a lot of calculation, and they often come up with plans that their programmers don't expect, and that are based on recognizing complicated patterns (rather than just a huge list of favorable outcomes). So it could be useful in debugging such systems if the program could carry on a simple conversation with the programmer: "Why did you make that move halfway through the previous game?" "I saw a chance to set up an attack of this sort, and guessed that I could get my opponent to fall for a trap to make it happen, but it either didn't fall for it or didn't see it, so I abandoned that plan without going any further on it." "I think the bait for the trap wasn't tempting enough. You were overestimating your opponent's interest in taking your knights." "I was expecting them to be worth about this much, because..." Then the programmer adds support for whatever was off about the program's evaluation of the sacrifice. The programs are getting to the point where a conversation is justified, and development teams are starting to include chess experts who don't necessarily have computer experience and would help more given a human-language analysis of what happened. And it's starting to be plausible as a possibility, because these programs have a significant amount of understanding of what's going on.
I've used Oracle on both Linux and Solaris. We were running it on Linux workstations, along with a bunch of other things, for development, and on Solaris to test it in the conditions we expected it to use in production, with nothing else running on the database server. Even so, we found that it was faster in the Linux setup. Of course, this is a while ago, and on relatively small data sets, and not an especially high-end Solaris machine, but it was still striking. At the time, at least, if you could get a big enough Linux box to handle your data, it would cost probably 1/20 of the cost of a Solaris system capable of the same performance. You'd probably have issues if you had to move to a database cluster, because the software for getting a cluster to work wasn't so good (when we tried it a few years later), but for a range of useful sizes, Linux was a much better value than Solaris.
The issue with clusters seemed to be that it was only available in a special custom Red Hat configuration, and it wasn't well tested, because it was just Red Hat and Oracle doing it, not everybody looking over the patches for whether they would screw up the rest of the system. There's been a bunch of merging work on cluster stuff since then, so the code quality is probably now up to the usual standards.
(Of course, I've been just as happy with other database programs on Linux, but I don't have any experience trying to use them for insanely large or busy databases; our program was supposed to work with huge data, but we never used it on huge data ourselves.)
Very little serious work has gone into chatbots since the 80s. The reason is that it's easy to make a chatbot that does practically nothing more than the textual equivalent of nodding whenever someone stops talking. It's hard to get any further with this approach. Actually chatting requires the bot to know something about some topic and be able to evaluate the other party's statements about it. Until both of these are done, you don't get a meaningful improvement. Furthermore, the system needs to be able to introspect its understanding of the topic. (There have been very old chatbots which actually did pretty well, by having a limited understanding of language and of some restricted topic. But these are relatively unintersting to chat with, compared to bots that let the user talk about anything and nod). Most of the recent AI research has involved making systems which behave appropriately in complex situations, and introspection isn't helpful for this (in people, this sort of stuff is preconscious, too; you can't explain how you recognize faces or voices or exactly how you identify spoken words). The things people have been working on turn out to have more direct practical uses, but they don't give the system anything to talk about. And, of course, there's been relatively little work on understanding arbitrary language since it became clear that it isn't that effective a way of communicating with computers anyway, because the human output side is slow and ambiguous, compared to other user interfaces.
Most likely, introspection in AI systems will be driven at some point by the need to combine different types of input to make a complete analysis (once there is sufficient success at handling those sorts of input), and language use will be driven by the need to handle language written for people as input (e.g., reading news reports for background information). At that point, it'll become reasonable to write an effective chatbot which talks about stuff that people care about.
I didn't mean to imply that they were missionaries, let alone fundamentalists. I was a bit carelessly suggesting that they did translations of the bible; but I'd assume that all translations of the bible are relevant to their work, so they'd have some familiarity with the issues involved in documents in modern written languages with odd features, in addition to odd ancient languages that relate to their work.
And it is a bit unusual for a group of humanities academics to get involved in technology, unfortunately. I know somehow who recently had a lot of trouble with quoting Armenian in her Byzantine Studies master's thesis and didn't get any help from her department. (This was a bit before ODF was actually specified and implemented.) So the SBL is a bit unusual in both knowing about exciting formatting needs and actually telling an OASIS committee what those needs are.
Being CEO is incompatible with doing any of the productive work of the business. It's a full-time bureaucracy job. Assuming you were basing your business model on your ability to do something, you need to be free to actually make the shots, not spend all of your time calling them.
The MN bill is not specific to ODF. It would require use of some open format (i.e., one which is clearly specified and may be implemented without license restrictions) if such a format is available. Under this bill, ODF would only be required if it is, in fact, ready.
The MA situation doesn't involve legislation, but is an executive order from the IT department. The IT department is responsible for implementing the switch, and there's no reason it couldn't abandon the project if it turned out to be unworkable. They're also perfectly able to make exceptions for cases where they can't get it to work or simply don't feel like dealing (if someone had an extremely complex Word macro that they use a lot, and the ITD couldn't figure out how to do it in ODF, they could just shrug and let it go), because it's just a policy, not a law.
With respect to the maturity of ODF, it was developed by a group of organizations which, between them, are likely to have all of the needs that anyone has. For example, the Society for Biblical Literature was an active member of the technical committee. This may be a bit surprising, until you realize that they've got at least one document (a translation of the bible) in every known living language, documents in many dead languages, and things like illuminated hand-written manuscripts. Additionally, ODF was designed to include the concepts in Microsoft Office formats (based on existing converters and on inspection of the interface presented to the user).
NPR is trying to get everything into their podcast directory to have this sort of uniformity. It's already to the point of having a couple hundred shows there.
I don't think the model of paying for the archives is going to work for most NPR shows; most of them are in some way discussing current events, so they become pointless or incomprehensible after a few weeks.
On the other hand, NPR's business model has always been to make people care that it continues and therefore fund it. They've never had to model of exchanging something for money. Unlike in a lot of industries, NPR's issue with online distribution is mainly the distribution of money. It used to be that listeners would donate to their local stations, even though small local stations don't produce much content; the big local stations produce content, and don't mind that small stations freeload on the content, because the big stations have more listeners and therefore more money to fund shows. Producing shows is in part a matter of pride, and in part an effect of ability. But with online distribution, the entities that the listeners hear about are the central organization (which isn't set up to run on donations directly from listeners) and the large stations that produce shows (which are fine with donations from their local areas). It's all a matter of getting the money redistributed in a way that isn't actually fair but is how it needs to be. (Closing all the small local stations would be bad, because they do local reporting, which matters a lot to locals, but which wouldn't generate the funding to support a station by itself.)
If those are your Windows applications, you could probably run Windows without any network access. Of course, the users need network access at the same time, but using VMWare or equivalent with the only Windows network being a local non-gateway link to another guest that serves a shared drive (so you can get data into and out of the applications) would probably solve your security issues.
As described, this would be the first time that Google would be getting money directly from the masses. I don't think selling music themselves is enough of a feature to justify the hassle for them. I think it's much more likely that they'll stick with the search step, and pass customers to vendors who are willing to give them commissions. So you search for a song (by lyrics, title, performer, composer, etc.), and you get a list of results, each with links to places you can buy the song.
It's possible that Google will do a store eventually, but I bet they'd start by getting a lot of customers going through their site to other stores, like they did for maps originally (with Yahoo and Mapquest as options for the actual map), and stocks (with a number of options for the quotes).
The slowness of the XML parser doesn't matter much if you don't save and reload the document with every modification.
Actually, OOo is so slow because they don't use a widget set. The display is hand-drawn by a bunch of monks in Germany, because the project started before Qt or Gtk.
My wife, on the other hand, giggled a bunch. And then said, "I'd read them more if they had more about ponies." So where are the stories with ponies? There must be someone who's made a full-scale working pony out of legos, or genetically-engineered green phosphorescent ponies, or pony clones (clonies?), and so forth. And in Tsarist Russia...
Actually, what could be done is to tell people to view the certificate for the site, and verify that the SHA1 fingerprint matches what's printed on the back of their card. Of course, there's no way to get Chase's certificate without using your password, so it's presently hopeless.
With browser support, you would identify the certificate when you originally set up your account, and you'd mark the certificate in your browser as belonging to your bank, and no other site could make the greeting look like your bank, because your browser wouldn't recognize the certificate (and it would therefore pop up message saying "This is an ecommerce site that you don't have an existing relationship with", instead of "This is your bank").
It would depend on how the device is used. If someone uses it instead of trying to read expressions, they'll just become dependant on it. But if they try to anticipate what it's going to tell them, they can use it to learn. Autistic people in some living conditions are like people trying to learn a foreign language with flash cards who don't ever get to look at the answer side of the card, because people in their surroundings never explain their emotions, so they never find out any correct answers to learn.
None of these people was actually sufficiently paranoid for my taste, including the study designers. The study designers claim that 7 web sites in their list were legitimate, but they ask "Imagine that you receive an email message that asks you to click on one of the following links. Imagine that you decide to click on the link to see if it is a legitmate website or a "spoof" (a fraudulent copy of that website)." I don't have accounts at any of the sites they list, and practially nobody would have accounts at all of them (there are three different banks, for example). Even if the site is "real", there must be something illegitimate going on in this situation.
For all of the organizations in this survey, the user should have a pre-existing relationship with the organization in order for an interaction to be legitimate, and none of the evaluation methods used (or available in this study) evaluate this.
My favorite piece of data (from figure 2) was that, of users who checked for SSL use, those who checked certificates did worse than those who didn't.
This just lets you set the maximum volume setting. But if there's some maximum volume setting you don't want to exceed, just don't set the volume higher. The real issue, in my opinion, is that you're likely to have tracks that have different average volumes, and if you play a quiet track, you'll turn it up, and then the next loud track damages your hearing. Using this feature to limit it, you play a quiet track, and you can't hear it. Or you adjust the maximum while playing a medium-volume track, and the loud tracks damage your hearing anyway. What they need is something to calculate RMS volume levels and automatically adjust the volume to even out tracks and limit the loudness of the output independant of the input.
You mean you don't think the post was a prayer for divine intervention? It's a bit of an odd idea, but terrestrial agents seem ineffective, so maybe it's worth a try.