I never took any notes in any of my classes, except for a few cases where I was in charge of class notes for a few lectures. Whenever I tried writing things down during class, I'd get less of an understanding of the material.
There is a certain value in writing things down for the purpose of remembering them better, but I think there's a unnecessary penalty if you do this in class, because you may miss something that won't be repeated. It's probably more useful to summarize the lecture notes or the readings when you're not in lecture, and not write much if anything while you're in lecture.
Of course, there's no reason you should expect that a site will render the same in every browser. In fact, no site renders the same in Firefox 1.5 when other people run it and Firefox 1.5 when I run it, because I insist on a relatively narrow window that's taller than it is wide. A well-designed site will render differently in my browser, but still look good and have the intended characteristics. Further out, a site has to generate a vastly different effect on a system with large print for the vision-impaired or a screen-reader for the blind.
Almost everybody is a creator at some level and an end-user at all the other levels. The authors of academic papers generally don't want to write their own document formatting systems. The authors of document formatting systems don't want to write their own compilers. The authors of compilers don't want to write their own text editors. The authors of text editors don't want to write their own version control systems. The authors of version control systems don't want to write their own diff utilities. The authors of diff utilities don't want to comes up with their own comparison algorithms. The inventors of comparison algorithms write academic papers about them.
The point is that people who are trying to create something depend on not having to use their creativity on making tools suitable for their needs. It may be okay to do a bit of work on the tools to make them a lot more effective by making some small changes (to configure them for some particular usage), but they need to basically work without any attention, and the minor changes need to be easy.
Actually using a Wiki would be terrible for scientific papers (or almost anything, really). It is only really good if there is some clear organizing principle for the information, which is why it's great for an encyclopedia (which are generally organized strictly by article title anyway), but lousy for things where the ontology is more complicated.
On the other hand, traditional scientific papers are hard to deal with, because a newer paper will often revise the understanding of some aspect of an earlier paper, but not entirely obsolete the earlier paper, due to not reanalyzing its whole content. That means that people will often have to struggle through reading the old paper with the out-of-date terminology and assumptions, figuring out what the new analysis of the unique cases in that paper should be, and this effort is not then made available to others.
With the way fields evolve over time, most of our understanding of most topics is nowhere in the public record in the current terminology. There is, essentially, a vast amount of bit rot in our scientific knowledge, and no standard mechanism for fixing it. I think that, in addition to papers reporting current work ("I did this experiment, this happened, this is what I think it means"), there some be Wiki-like expositions of current theory. To address your issue about disputes, I say that every author gets one, with the ability to accept theories from other authors, or ignore them, or modify them. Of course, there would be just as much bit rot, but readers could propose updates ("I think that the explanation of example 3 of S&C, in light of the refinements to the theory in T&MO should be as follows..." would be sent to the author, who would then accept the modification, figure out what it should actually be, or ignore the message). As it stands, there is no forum for an author to be asked for a modern clarification of an old paper, nor for the author to publish such a thing (since it's pretty boring as a new paper).
What do you have against selling mp3s? Would you be okay selling wavs? Or wavs plus PDFs (of the liner notes and album art)? It's a little odd to refuse to accept money unless you get to ship some metal, glass, plastic, and paper somewhere.
I'll agree with your assessment about requiring payment to provide an mp3, but that doesn't mean you can't also sell people the same thing you've already given them for free. It seems dumb, but it's a mechanism for letting people show appreciation for what you already gave them that credit card companies like better than accepting donations.
Of course, the physical CDs as artwork are another matter; but the site doesn't really give much of an impression of what the manufactured item is like (as opposed to the sound which may be produced by playing it in a CD player, among other ways). If that is your particular artistic expression, you should have images of the item for sale; the mp3s don't really speak to that, since the buyer would have to rip the CD (or download all the mp3s) to simultaneously listen to the audio and look at the CD. And, of course, you're not offering anything for people who like the music but not the visual art, so it's not too surprising that a segment of people listen to the music and then don't buy anything.
Encrypting everything doesn't help security at all. It only helps if you have some idea of who the intended recipient is. For most traffic, that's an application-specific concern, and so a general encryption mechanism is useless. For example, if I want to send email to a gmail user, and I care about it being private, I have to find a private key for the user. It doesn't help to just encrypt (great, nobody at all can read it), or encrypt it for secure transit to Google (why should I trust Google more than other random intermediaries?). I need the actual user's PGP key, and that requires an application specific identity specification (i.e., the email address), with a user-specific way of determining that I've got the right address for the communication.
I haven't noticed any particular speed advantage to things compiled locally; I suspect that anything where it actually makes a big difference (e.g., codecs) does runtime detection of the correct version anyway.
The big advantage to compiling things locally is that the rules for which packages work together are based on source compatibility, not binary compatibility. This, in turn, means that you have a lot more flexibility in updating things, and this flexibility eliminates a lot of the "flag day, new stable version" problems. The recent release of Gentoo 2006.0 didn't contain anything that my Gentoo 2005.0 system hadn't already taken as a regular package update; the point of the release was that the packages on the 2005.1 ISO were out of date, meaning that you'd have to immediately update everything if you installed 2005.1. As far as I know, there aren't any plans for having a distribution upgrade in the foreseeable future, because it's unnecessary. (There is a similar stable/testing/unstable distinction to what Debian uses, except that it is on a per-package level, rather than all changing together).
USE flags generally apply to optional support for things (which can be hugely important, because lots of apps now have optional Gnome and KDE support, and you generally want to not have these require at least one desktop environment you're not going to use) and also to compile-time options, including things like whether you want debugging symbols in your system libraries.
My experience is that running exactly the same binaries as thousands of other machines doesn't help stability any if you might be running a combination of installed versions of packages that nobody else has ever tried, Or if you have different hardware, or if you've modified configuration files. Compiling from source reduces the subtle version skew problems without requiring a lot of lock-step updates.
I've never gotten encrypted email, but I've dealt in both directions with encrypted documents, often attached to unencrypted emails. Email in my experience is rarely all that important to keep private (I think 90% of the email I get also goes into public mailing list archives), and when it contains anything important, it tends to be an attachment anyway. Of the exceptions, they're almost all cases where the sender is an automated system that hasn't heard of you before (e.g., online hotel reservations), and the fact that you've published a key isn't useful, because the site doesn't know whether to trust it (it probably should let you specify a key you want it to use).
It's actually a perfectly reasonable idea. They're not using Vista now, and they're fine. Why should they get a lot of new software they clearly don't need? There are three potential reasons to get Vista: it comes with the computer (not applicable in this case), you want some feature it has (they don't), or you expect that you'll want a future version of Windows and want to maintain an upgrade contract. They've got their Linux system to the point where they are confident that it'll handle anything new they could want by 2010 (for that matter, we recently saw that lots of businesses now think the Linux business desktop is not ready yet but is the right thing long-term), so they don't expect to want future Windows upgrades.
That's probably better, really. It's at least easier to debug than having your program misbehave in subtle ways. Or not so subtle ways; I've had gcc generate code that tried to use an instruction incorrectly, causing it to jump to somewhere totally random (GCC 3.3.2 for the AVR trying a tablejump).
The weird thing is that homeland security is concerned about people paying off their credit card bills suddenly. I understand them worrying about transactions which cause somebody to have an unusually large amount of money, but I somehow doubt that the credit card company is planning any terrorist activities, and nobody else ends up with a sudden increase in ready cash or valuable items. I could see putting on a temporary low credit limit, if the Feds thought this might be a trick for getting their available credit to a high enough level to do something.
Of course, I don't think letting your credit card debt creep up over $6K when you have the money to pay it off is really particularly financially responsible.
The Firefox community says plenty of stuff beyond reporting the number of downloads. The Times ad had distinct names of individuals. The Firefox page reports a bunch of important features. However, the media keeps picking up the download count. You can't really blame Mozilla for the press's focus on meaningless statistics.
Since Linux development is all in the open, even more than most OSS projects, due to using git so extensively, they should be able to check stuff that hasn't yet been merged into the mainline, and therefore report new bugs before they actually affect anyone. For that matter, they'd be able to identify the commit with contains the bug. If they wanted to be really slick, they could search for the patch being posted to the mailing list and reply inline to the posting with a report, just like human patch-readers do.
Interestingly, the discussion on the mailing list so far has been primarily complaining that the announcement failed to take into account the fact that Coverity has been doing this already for a while. In fact, the only thing that's new is that they've put together internal infrastructure that lets them also handle other projects conveniently, and have therefore moved their kernel result info. It looks a bit like they sent a newly-scanned-project-directed form letter to the project they were already scanning, which is clearly a bit of a faux pas.
Since it's all static checks, it should be able to check different architectures than the program runs on without any problem. Remember that this isn't even supposed to find cases where the program behaves consistantly, but does something that's wrong (like, the PCI spec doesn't actually let you do what you're doing).
They actually do a lot with violation of invariants: it's looking for cases where it can't prove that the invariant is maintained. Of course, there's always the chance of false positives, where the code is sure to work, but only for some tricky reason that the checker can't figure out, but these are often cases where the code should be made more obvious anyway, because somebody's likely to accidentally change it in ways that don't work if it's subtle. There's also a lot of extra-detailed type checking along particular code paths, so it can identify, for example, what it's safe to turn a particular void * into in a particular function, and then verify (e.g.) that ext3_release_file is only called on struct files where private_data is a struct dir_private_info. (Which is true, because nothing could create a struct file with something else there and with the ext3 fops, or create another set of fops with ext3_release_file)
Checking external drivers shouldn't be a problem. The reason they need a lot of code is because they're determining invariants from actual usage, and it needs the actual usage to cover the possibilities well (e.g., it tries to find a lock that almost always protects a particular bit of data, and then gives errors on violations; if you only have a couple of places that access something, and they don't match, it can't tell which is the real lock and which spots are wrong). External drivers are small, but their behavior can be compared against the rest of the kernel, because they do a lot of calling functions that the base kernel defines and uses. The hard case is really something like libpng, where it has a wide API, and there's no way for the program to determine what rules users of the library are told by the documentation to follow. (In this case, it may make sense to check the library combined with a number of common programs and use that to generate the checker's expectations of library usage.)
It's also not particularly useful to check things like gcc, because the checker doesn't have any way to determine if the compiler is compiling correctly or not; it can only tell if it might do crazy things in odd situations. Compilers are generally written sufficiently conservatively that problems tend to be safe-but-does-the-wrong-thing code, and the bugs you'd find with the checker would generally be "internal compiler error" bugs, not ones that lead to incorrect output (or any output at all...)
According to their announcement, Apple thinks their iPod Hi-Fi will sounds as good as a "home theatre in a box" system. It's true that it'll be somewhat more limited, but that's only an issue for A/V and live stuff; lots of people have serious stereo equipment that they only use for listening to music, and iTunes or the iPod handle all the selection issues, and people put all their music in anyway.
The sort of mystifying thing is that they simultaneously released the media center machine and the stereo system that don't work together particularly well.
It is true that projects to cover education-specific needs haven't gotten particularly far, most likely because it's a relatively specialized field that doesn't have too many developers actually in it, and open source developers working on software they aren't planning to use themselves are easily distracted.
For general stuff, projects are generally in the stage of being about as good as closed-source products, but not compellingly better. There's a lot of interest and pilot programs, but relatively little wholesale adoption. The article seems quite positive towards open source to me; it looks like people are starting to expect that open source will be the way to go before long, and this perception makes a big different in short-term direction. People will be asking vendors about Linux versions, and trying to avoid lock-in. If they're making their present plans with the idea that they won't use MS Office 2008, but instead use some version of OpenOffice at that point, they'll be making their current decisions with the migration issues in mind.
Actually, all it takes is big web companies acting together to stop it. Such, you can save 20 a month and get tiered service, but that means that you can only connect to your ISP, because nobody else is willing to pay.
If Google just detected Deutsche Telekom AG connections, and put on a note that says that the reason pages are so slow for you is that your ISP makes them slow, DT would probably lose a lot of customers. Google could probably actually extort a bunch of money from DT now, if they wanted to, by threatening to delay responses for DT customers and blame DT (except that DT could prove that it wasn't true, and it wouldn't work if people didn't believe Google).
As far as I can tell, a 2005.0 or 2005.1 system that's up to date isn't going to see any significant changes with 2006.0. They've been good about not having changes be incompatible, so old profiles have only minimal effects. (In fact, it's been ages since they had any major upheavals in profiles, aside from needing a new version of portage to handle the new profile files themselves, which isn't even all that recent.)
As somebody else pointed out, they have to contact the actual copyright holder to find out what license to read, particularly if they didn't actually confiscate anything that would have the license on it (and they'd still have to find out if the copyright holder had actually licensed it to the people selling it, since the license isn't a signed and notarized document from Mozilla). (The slashdot blurb is wrong: the article doesn't say that the govt confiscated anything, and implies by omission that they didn't.) Of course, there are plenty of press releases they could have looked at; I doubt that they call up Microsoft every time they see something new sold as a Microsoft product to make sure that Microsoft really did release this.
As for the guidelines to give businesses, the Mozilla rep really ought to have said, "Tell them to look for the license on http://www.opensource.org/licenses/. If it's there (and the actual owner seems to really have released it under that license), then follow the guidelines in http://www.opensource.org/docs/definition.php. Otherwise, it's too risky to use unless you look over the license with a lawyer or can understand it yourself."
The weird thing is really that Google is doing, so far as I can see, the least evil thing they can. They couldn't offer uncensored web search to the Chinese people; the government would prevent it, and Google can't do anything about that. It wouldn't hurt the government or help the people if Google stayed out of China entirely; the people would just continue to do their web searches on Yahoo, and Yahoo would continue turning over records to the government. The best they can do is offer censored web search and not turn over logs to the government. The critical issue shouldn't be censorship, since their only alternative is to offer less information; it should be privacy, and they've simultaneously been demonstrating that they're willing to stand up to a government with more power over them in a case that's less important for the personal safety of the users.
For that matter, I wouldn't be at all surprised if Google intentionally set up features which would allow covert information distribution. E.g., if some site has a page with an unusual combination of innocent terms, it'll be the only hit once Google has indexed it. A group can arrange in advance a series of such combinations, and tell people the next combination, which will give a page with a Google Local location, which is where the next protest will be. By the time the government tells Google to censor that particular combination and Google complies, tons of people will have already gotten the details of the protest, along with convenient satellite photos and maps. Then Google says that they didn't know what the combination was, and they don't have records of who searched for it. They provide a generic information service, and their structure doesn't give them any way to prevent people from using it in unexpected ways.
You can't direct light blue light with light blue optics; it obviously goes straight through. But light blue optics can bend green light perfectly well.
I think a lot of the exposition would be fine as scene-introducing voice-over by Hiro (or other characters as appropriate). And a lot of it could be visual instead of text without losing anything. The opening sequence would be perfectly good with no words at all, with just the high-speed driving, cuts to the countdown, and cuts to Hiro being tense and wired. Credits overlaid, ending with the movie title, then the punch line. Of course, you'd need a huge budget to pull it off, but at least the metaverse scenes would be cheap these days.
(HHGTTG could also be done well as a movie, but only by someone who really knew what they were doing. The way the books work is that they violate expectations about writing, and so the movie should violate expectations about film. E.g., the camera work and soundtrack leads the audience to expect something to happen, and nothing does; the Heart of Gold is exquisitely CGI-rendered in minute detail to look exactly like a running shoe that they could clearly have stuck in front of a blue screen instead of modelling; and so forth.)
He was really going about it the wrong way the first time, and he was still going about it the wrong way the second time. What he should have done was start by hiring a retired school administrator who is willing to play with computers (but doesn't necessarily know anything about them). Then somebody who to keep the computer working. Then a couple of developers, chosen mostly by the school administrator based on whether they find the manager's excitement infectious.
You always get shiny geek toys. Knowing this, what you have to do is make the result you're after the most shiny thing around. It's probably too hard to find a group of developers who are mostly interested in school administration, but you can get the programming skill and interest from different people, so long as the people mix well. Of course, ideally, you want to enlist users as soon as possible, too, because even someone who used to need the software but doesn't now is going to have less of a focus on getting it. Pick some school system that's really in bad shape organizationally (so what you can do quickly is an improvement), get the people who would use the system to spend the summer working with the project, and actually use it in the fall.
This gives the team pressure to have something working and useable and real soon, so they don't get sidetracked into all the millions of things they could work on, which would advance the state of the art but not actually lead to the actual goal.
Browsers are designed to make people assume that CA-signed SSL certificates actually mean something they care about. The only thing this stops is somebody who manages to take control of a site's DNS or TCP traffic but somehow fails to use this control to get a certificate issued. But browsers treat self-signed certificates as really suspicious and CA-signed certificates as perfectly secure. The user isn't given any useful information, and has to make the decision based on information which, as you say, is not actually relevant. (Actually, CA-signed certificates are less trustworthy in many cases than self-signed ones, because the browser doesn't report that a CA-signed certificate is unfamiliar, while a self-signed one is saved, so it's obvious when it's not the same.)
What would prevent this sort of scam is if people were told that any certificate your browser doesn't already have saved is suspicious, and shown what can be demonstrated about the certificate. If you have a prior relationship with this site, check that this string: (fingerprint of certificate) appears in the information you received. If not, decide whether you believe one of these organizations (signers of certificate, using PKI, based on certificates which come with the system) to make the operation you are doing today safe. In either case, choose a description of the site, which will be displayed when you return to this site in the future. Ideally, the user would be asked to choose whether they recognize the site before they are told more about the certificate, so they don't just look for a reasonable-looking signer.
That way, people click the link, get the real certificate for something that isn't their bank, and they notice that the window doesn't say "Secure connection to: My Bank" (if they've done this before), or notice that the fingerprint doesn't match the fingerprint on their bank statement, and then they know that, whoever this is, it's nobody they've got an existing business relationship with, and the claim about an existing account is clearly bogus.
(Last detail: the certificate with the fingerprint in question should be a self-generated CA certificate, not the actual SSL certificate in use, so the bank can change domain name while keeping the same saved info. The CA cert should be signed by the FDIC and other banking-related organizations, who wouldn't be tempted to possibly sign a sporting-goods store certificate, but that's only at all relevant to people trying to choose a bank online, because the instructions will clearly state that this is not the user's current bank.)
Slashdot Mirror
I never took any notes in any of my classes, except for a few cases where I was in charge of class notes for a few lectures. Whenever I tried writing things down during class, I'd get less of an understanding of the material.
There is a certain value in writing things down for the purpose of remembering them better, but I think there's a unnecessary penalty if you do this in class, because you may miss something that won't be repeated. It's probably more useful to summarize the lecture notes or the readings when you're not in lecture, and not write much if anything while you're in lecture.
Of course, there's no reason you should expect that a site will render the same in every browser. In fact, no site renders the same in Firefox 1.5 when other people run it and Firefox 1.5 when I run it, because I insist on a relatively narrow window that's taller than it is wide. A well-designed site will render differently in my browser, but still look good and have the intended characteristics. Further out, a site has to generate a vastly different effect on a system with large print for the vision-impaired or a screen-reader for the blind.
Almost everybody is a creator at some level and an end-user at all the other levels. The authors of academic papers generally don't want to write their own document formatting systems. The authors of document formatting systems don't want to write their own compilers. The authors of compilers don't want to write their own text editors. The authors of text editors don't want to write their own version control systems. The authors of version control systems don't want to write their own diff utilities. The authors of diff utilities don't want to comes up with their own comparison algorithms. The inventors of comparison algorithms write academic papers about them.
The point is that people who are trying to create something depend on not having to use their creativity on making tools suitable for their needs. It may be okay to do a bit of work on the tools to make them a lot more effective by making some small changes (to configure them for some particular usage), but they need to basically work without any attention, and the minor changes need to be easy.
Actually using a Wiki would be terrible for scientific papers (or almost anything, really). It is only really good if there is some clear organizing principle for the information, which is why it's great for an encyclopedia (which are generally organized strictly by article title anyway), but lousy for things where the ontology is more complicated.
On the other hand, traditional scientific papers are hard to deal with, because a newer paper will often revise the understanding of some aspect of an earlier paper, but not entirely obsolete the earlier paper, due to not reanalyzing its whole content. That means that people will often have to struggle through reading the old paper with the out-of-date terminology and assumptions, figuring out what the new analysis of the unique cases in that paper should be, and this effort is not then made available to others.
With the way fields evolve over time, most of our understanding of most topics is nowhere in the public record in the current terminology. There is, essentially, a vast amount of bit rot in our scientific knowledge, and no standard mechanism for fixing it. I think that, in addition to papers reporting current work ("I did this experiment, this happened, this is what I think it means"), there some be Wiki-like expositions of current theory. To address your issue about disputes, I say that every author gets one, with the ability to accept theories from other authors, or ignore them, or modify them. Of course, there would be just as much bit rot, but readers could propose updates ("I think that the explanation of example 3 of S&C, in light of the refinements to the theory in T&MO should be as follows..." would be sent to the author, who would then accept the modification, figure out what it should actually be, or ignore the message). As it stands, there is no forum for an author to be asked for a modern clarification of an old paper, nor for the author to publish such a thing (since it's pretty boring as a new paper).
What do you have against selling mp3s? Would you be okay selling wavs? Or wavs plus PDFs (of the liner notes and album art)? It's a little odd to refuse to accept money unless you get to ship some metal, glass, plastic, and paper somewhere.
I'll agree with your assessment about requiring payment to provide an mp3, but that doesn't mean you can't also sell people the same thing you've already given them for free. It seems dumb, but it's a mechanism for letting people show appreciation for what you already gave them that credit card companies like better than accepting donations.
Of course, the physical CDs as artwork are another matter; but the site doesn't really give much of an impression of what the manufactured item is like (as opposed to the sound which may be produced by playing it in a CD player, among other ways). If that is your particular artistic expression, you should have images of the item for sale; the mp3s don't really speak to that, since the buyer would have to rip the CD (or download all the mp3s) to simultaneously listen to the audio and look at the CD. And, of course, you're not offering anything for people who like the music but not the visual art, so it's not too surprising that a segment of people listen to the music and then don't buy anything.
Encrypting everything doesn't help security at all. It only helps if you have some idea of who the intended recipient is. For most traffic, that's an application-specific concern, and so a general encryption mechanism is useless. For example, if I want to send email to a gmail user, and I care about it being private, I have to find a private key for the user. It doesn't help to just encrypt (great, nobody at all can read it), or encrypt it for secure transit to Google (why should I trust Google more than other random intermediaries?). I need the actual user's PGP key, and that requires an application specific identity specification (i.e., the email address), with a user-specific way of determining that I've got the right address for the communication.
I haven't noticed any particular speed advantage to things compiled locally; I suspect that anything where it actually makes a big difference (e.g., codecs) does runtime detection of the correct version anyway.
The big advantage to compiling things locally is that the rules for which packages work together are based on source compatibility, not binary compatibility. This, in turn, means that you have a lot more flexibility in updating things, and this flexibility eliminates a lot of the "flag day, new stable version" problems. The recent release of Gentoo 2006.0 didn't contain anything that my Gentoo 2005.0 system hadn't already taken as a regular package update; the point of the release was that the packages on the 2005.1 ISO were out of date, meaning that you'd have to immediately update everything if you installed 2005.1. As far as I know, there aren't any plans for having a distribution upgrade in the foreseeable future, because it's unnecessary. (There is a similar stable/testing/unstable distinction to what Debian uses, except that it is on a per-package level, rather than all changing together).
USE flags generally apply to optional support for things (which can be hugely important, because lots of apps now have optional Gnome and KDE support, and you generally want to not have these require at least one desktop environment you're not going to use) and also to compile-time options, including things like whether you want debugging symbols in your system libraries.
My experience is that running exactly the same binaries as thousands of other machines doesn't help stability any if you might be running a combination of installed versions of packages that nobody else has ever tried, Or if you have different hardware, or if you've modified configuration files. Compiling from source reduces the subtle version skew problems without requiring a lot of lock-step updates.
I've never gotten encrypted email, but I've dealt in both directions with encrypted documents, often attached to unencrypted emails. Email in my experience is rarely all that important to keep private (I think 90% of the email I get also goes into public mailing list archives), and when it contains anything important, it tends to be an attachment anyway. Of the exceptions, they're almost all cases where the sender is an automated system that hasn't heard of you before (e.g., online hotel reservations), and the fact that you've published a key isn't useful, because the site doesn't know whether to trust it (it probably should let you specify a key you want it to use).
It's actually a perfectly reasonable idea. They're not using Vista now, and they're fine. Why should they get a lot of new software they clearly don't need? There are three potential reasons to get Vista: it comes with the computer (not applicable in this case), you want some feature it has (they don't), or you expect that you'll want a future version of Windows and want to maintain an upgrade contract. They've got their Linux system to the point where they are confident that it'll handle anything new they could want by 2010 (for that matter, we recently saw that lots of businesses now think the Linux business desktop is not ready yet but is the right thing long-term), so they don't expect to want future Windows upgrades.
That's probably better, really. It's at least easier to debug than having your program misbehave in subtle ways. Or not so subtle ways; I've had gcc generate code that tried to use an instruction incorrectly, causing it to jump to somewhere totally random (GCC 3.3.2 for the AVR trying a tablejump).
The weird thing is that homeland security is concerned about people paying off their credit card bills suddenly. I understand them worrying about transactions which cause somebody to have an unusually large amount of money, but I somehow doubt that the credit card company is planning any terrorist activities, and nobody else ends up with a sudden increase in ready cash or valuable items. I could see putting on a temporary low credit limit, if the Feds thought this might be a trick for getting their available credit to a high enough level to do something.
Of course, I don't think letting your credit card debt creep up over $6K when you have the money to pay it off is really particularly financially responsible.
The Firefox community says plenty of stuff beyond reporting the number of downloads. The Times ad had distinct names of individuals. The Firefox page reports a bunch of important features. However, the media keeps picking up the download count. You can't really blame Mozilla for the press's focus on meaningless statistics.
Since Linux development is all in the open, even more than most OSS projects, due to using git so extensively, they should be able to check stuff that hasn't yet been merged into the mainline, and therefore report new bugs before they actually affect anyone. For that matter, they'd be able to identify the commit with contains the bug. If they wanted to be really slick, they could search for the patch being posted to the mailing list and reply inline to the posting with a report, just like human patch-readers do.
Interestingly, the discussion on the mailing list so far has been primarily complaining that the announcement failed to take into account the fact that Coverity has been doing this already for a while. In fact, the only thing that's new is that they've put together internal infrastructure that lets them also handle other projects conveniently, and have therefore moved their kernel result info. It looks a bit like they sent a newly-scanned-project-directed form letter to the project they were already scanning, which is clearly a bit of a faux pas.
Since it's all static checks, it should be able to check different architectures than the program runs on without any problem. Remember that this isn't even supposed to find cases where the program behaves consistantly, but does something that's wrong (like, the PCI spec doesn't actually let you do what you're doing).
They actually do a lot with violation of invariants: it's looking for cases where it can't prove that the invariant is maintained. Of course, there's always the chance of false positives, where the code is sure to work, but only for some tricky reason that the checker can't figure out, but these are often cases where the code should be made more obvious anyway, because somebody's likely to accidentally change it in ways that don't work if it's subtle. There's also a lot of extra-detailed type checking along particular code paths, so it can identify, for example, what it's safe to turn a particular void * into in a particular function, and then verify (e.g.) that ext3_release_file is only called on struct files where private_data is a struct dir_private_info. (Which is true, because nothing could create a struct file with something else there and with the ext3 fops, or create another set of fops with ext3_release_file)
Checking external drivers shouldn't be a problem. The reason they need a lot of code is because they're determining invariants from actual usage, and it needs the actual usage to cover the possibilities well (e.g., it tries to find a lock that almost always protects a particular bit of data, and then gives errors on violations; if you only have a couple of places that access something, and they don't match, it can't tell which is the real lock and which spots are wrong). External drivers are small, but their behavior can be compared against the rest of the kernel, because they do a lot of calling functions that the base kernel defines and uses. The hard case is really something like libpng, where it has a wide API, and there's no way for the program to determine what rules users of the library are told by the documentation to follow. (In this case, it may make sense to check the library combined with a number of common programs and use that to generate the checker's expectations of library usage.)
It's also not particularly useful to check things like gcc, because the checker doesn't have any way to determine if the compiler is compiling correctly or not; it can only tell if it might do crazy things in odd situations. Compilers are generally written sufficiently conservatively that problems tend to be safe-but-does-the-wrong-thing code, and the bugs you'd find with the checker would generally be "internal compiler error" bugs, not ones that lead to incorrect output (or any output at all...)
According to their announcement, Apple thinks their iPod Hi-Fi will sounds as good as a "home theatre in a box" system. It's true that it'll be somewhat more limited, but that's only an issue for A/V and live stuff; lots of people have serious stereo equipment that they only use for listening to music, and iTunes or the iPod handle all the selection issues, and people put all their music in anyway.
The sort of mystifying thing is that they simultaneously released the media center machine and the stereo system that don't work together particularly well.
It is true that projects to cover education-specific needs haven't gotten particularly far, most likely because it's a relatively specialized field that doesn't have too many developers actually in it, and open source developers working on software they aren't planning to use themselves are easily distracted.
For general stuff, projects are generally in the stage of being about as good as closed-source products, but not compellingly better. There's a lot of interest and pilot programs, but relatively little wholesale adoption. The article seems quite positive towards open source to me; it looks like people are starting to expect that open source will be the way to go before long, and this perception makes a big different in short-term direction. People will be asking vendors about Linux versions, and trying to avoid lock-in. If they're making their present plans with the idea that they won't use MS Office 2008, but instead use some version of OpenOffice at that point, they'll be making their current decisions with the migration issues in mind.
Actually, all it takes is big web companies acting together to stop it. Such, you can save 20 a month and get tiered service, but that means that you can only connect to your ISP, because nobody else is willing to pay.
If Google just detected Deutsche Telekom AG connections, and put on a note that says that the reason pages are so slow for you is that your ISP makes them slow, DT would probably lose a lot of customers. Google could probably actually extort a bunch of money from DT now, if they wanted to, by threatening to delay responses for DT customers and blame DT (except that DT could prove that it wasn't true, and it wouldn't work if people didn't believe Google).
As far as I can tell, a 2005.0 or 2005.1 system that's up to date isn't going to see any significant changes with 2006.0. They've been good about not having changes be incompatible, so old profiles have only minimal effects. (In fact, it's been ages since they had any major upheavals in profiles, aside from needing a new version of portage to handle the new profile files themselves, which isn't even all that recent.)
As somebody else pointed out, they have to contact the actual copyright holder to find out what license to read, particularly if they didn't actually confiscate anything that would have the license on it (and they'd still have to find out if the copyright holder had actually licensed it to the people selling it, since the license isn't a signed and notarized document from Mozilla). (The slashdot blurb is wrong: the article doesn't say that the govt confiscated anything, and implies by omission that they didn't.) Of course, there are plenty of press releases they could have looked at; I doubt that they call up Microsoft every time they see something new sold as a Microsoft product to make sure that Microsoft really did release this.
As for the guidelines to give businesses, the Mozilla rep really ought to have said, "Tell them to look for the license on http://www.opensource.org/licenses/. If it's there (and the actual owner seems to really have released it under that license), then follow the guidelines in http://www.opensource.org/docs/definition.php. Otherwise, it's too risky to use unless you look over the license with a lawyer or can understand it yourself."
The weird thing is really that Google is doing, so far as I can see, the least evil thing they can. They couldn't offer uncensored web search to the Chinese people; the government would prevent it, and Google can't do anything about that. It wouldn't hurt the government or help the people if Google stayed out of China entirely; the people would just continue to do their web searches on Yahoo, and Yahoo would continue turning over records to the government. The best they can do is offer censored web search and not turn over logs to the government. The critical issue shouldn't be censorship, since their only alternative is to offer less information; it should be privacy, and they've simultaneously been demonstrating that they're willing to stand up to a government with more power over them in a case that's less important for the personal safety of the users.
For that matter, I wouldn't be at all surprised if Google intentionally set up features which would allow covert information distribution. E.g., if some site has a page with an unusual combination of innocent terms, it'll be the only hit once Google has indexed it. A group can arrange in advance a series of such combinations, and tell people the next combination, which will give a page with a Google Local location, which is where the next protest will be. By the time the government tells Google to censor that particular combination and Google complies, tons of people will have already gotten the details of the protest, along with convenient satellite photos and maps. Then Google says that they didn't know what the combination was, and they don't have records of who searched for it. They provide a generic information service, and their structure doesn't give them any way to prevent people from using it in unexpected ways.
You can't direct light blue light with light blue optics; it obviously goes straight through. But light blue optics can bend green light perfectly well.
I think a lot of the exposition would be fine as scene-introducing voice-over by Hiro (or other characters as appropriate). And a lot of it could be visual instead of text without losing anything. The opening sequence would be perfectly good with no words at all, with just the high-speed driving, cuts to the countdown, and cuts to Hiro being tense and wired. Credits overlaid, ending with the movie title, then the punch line. Of course, you'd need a huge budget to pull it off, but at least the metaverse scenes would be cheap these days.
(HHGTTG could also be done well as a movie, but only by someone who really knew what they were doing. The way the books work is that they violate expectations about writing, and so the movie should violate expectations about film. E.g., the camera work and soundtrack leads the audience to expect something to happen, and nothing does; the Heart of Gold is exquisitely CGI-rendered in minute detail to look exactly like a running shoe that they could clearly have stuck in front of a blue screen instead of modelling; and so forth.)
He was really going about it the wrong way the first time, and he was still going about it the wrong way the second time. What he should have done was start by hiring a retired school administrator who is willing to play with computers (but doesn't necessarily know anything about them). Then somebody who to keep the computer working. Then a couple of developers, chosen mostly by the school administrator based on whether they find the manager's excitement infectious.
You always get shiny geek toys. Knowing this, what you have to do is make the result you're after the most shiny thing around. It's probably too hard to find a group of developers who are mostly interested in school administration, but you can get the programming skill and interest from different people, so long as the people mix well. Of course, ideally, you want to enlist users as soon as possible, too, because even someone who used to need the software but doesn't now is going to have less of a focus on getting it. Pick some school system that's really in bad shape organizationally (so what you can do quickly is an improvement), get the people who would use the system to spend the summer working with the project, and actually use it in the fall.
This gives the team pressure to have something working and useable and real soon, so they don't get sidetracked into all the millions of things they could work on, which would advance the state of the art but not actually lead to the actual goal.
If the average player plays about 4 hours and 20 minutes a day, it would be in 4 million hands and 11 million pockets at any given time.
Browsers are designed to make people assume that CA-signed SSL certificates actually mean something they care about. The only thing this stops is somebody who manages to take control of a site's DNS or TCP traffic but somehow fails to use this control to get a certificate issued. But browsers treat self-signed certificates as really suspicious and CA-signed certificates as perfectly secure. The user isn't given any useful information, and has to make the decision based on information which, as you say, is not actually relevant. (Actually, CA-signed certificates are less trustworthy in many cases than self-signed ones, because the browser doesn't report that a CA-signed certificate is unfamiliar, while a self-signed one is saved, so it's obvious when it's not the same.)
What would prevent this sort of scam is if people were told that any certificate your browser doesn't already have saved is suspicious, and shown what can be demonstrated about the certificate. If you have a prior relationship with this site, check that this string: (fingerprint of certificate) appears in the information you received. If not, decide whether you believe one of these organizations (signers of certificate, using PKI, based on certificates which come with the system) to make the operation you are doing today safe. In either case, choose a description of the site, which will be displayed when you return to this site in the future. Ideally, the user would be asked to choose whether they recognize the site before they are told more about the certificate, so they don't just look for a reasonable-looking signer.
That way, people click the link, get the real certificate for something that isn't their bank, and they notice that the window doesn't say "Secure connection to: My Bank" (if they've done this before), or notice that the fingerprint doesn't match the fingerprint on their bank statement, and then they know that, whoever this is, it's nobody they've got an existing business relationship with, and the claim about an existing account is clearly bogus.
(Last detail: the certificate with the fingerprint in question should be a self-generated CA certificate, not the actual SSL certificate in use, so the bank can change domain name while keeping the same saved info. The CA cert should be signed by the FDIC and other banking-related organizations, who wouldn't be tempted to possibly sign a sporting-goods store certificate, but that's only at all relevant to people trying to choose a bank online, because the instructions will clearly state that this is not the user's current bank.)