If you know you're in the post office when you write down the numbers, you could just go to the USPS site. The only thing that Google adds is that it identifies the shipper by the format of the number and lets you use a control you already have to get there. Google doesn't even report the information; it just sends you to the shipper's site.
If they had used an open-source SCM from the start and not changed things around, they'd be using RCS, which is totally useless for distributed development on this scale. If they had used an open-source SCM from when they started using an SCM, they'd be using CVS, which isn't much more applicable to the actual problem. BitKeeper was something that worked through the period when the available systems weren't really appropriate, and served as something to use while the problem space become sufficiently well understood that it could be solved correctly.
Primarily due to frustration with the speed of existing solutions, and the fact that they do badly with huge numbers of tiny changes to large projects (which is what he deals with), he's started writing something that he claims isn't an SCM. What it does is store versions of trees of files and allow them to be annotated. This is different from an SCM in that it lacks support for merging changes to get a version that nobody created before out of multiple versions that people created independantly. This makes it a history archival program rather than useful for collaboration directly.
On the other hand, it's self-hosting and sparse (the previous thing he wrote when confronted by the inavailability of something he wanted) is also available stored in it. Probably, be the middle of next week (if not the end of the weekend), he'll have if set up as sufficient for his purposes, and other people will be filling in support for the way they work.
Anti-aliased stroked fonts just aren't as good as a good bitmapped font. On the other hand, they're a whole lot better than a bad bitmapped font or a non-anti-aliased stroked font. If you need to scale fonts, the current trend is a great improvement; otherwise, it's worse.
I don't think this at all indicates that Linus was wrong about using BitKeeper. BitMover is going to continue to host bkbits, there's an open source version with limited functionality (which, presumably, will be extended to more complete functionality by the community), and the existing licenses are still valid. They're just not going to do further development on the free version, and so it's time to look at alternatives, not actually switch.
Linus has just posted to the mailing list saying that he is about to stop using BitKeeper, but only so that he can evaluate other things by actually throwing his real work at them. Most likely, in a week he'll say that there's one he likes best, but it's not ready, and he's going back to using BitKeeper until it is.
Personally, I think that the free and the licensing issues surrounding it have hurt BitMover more than helped it; there have been people who have reported that BitMover refused to sell them the commercial version when they were ineligable for the free license, and I suspect that this has contributed to the idea that BitKeeper might be the best SCM out there, but BitMover is too nuts to do critical business with.
Unless you're actually interested in running a business, you should avoid having a business model. Running a successful business, regardless of the model, will take several people working full-time on overhead, and this is likely to eat up your band.
The right path is really to find someone else (such as Magnatune) who has a business model which leaves you ownership of your music, gives you a return that you feel is fair, and involves business practices you think are ethical. There's nothing inherently bad about signing with a label, just like there's nothing inherently bad about getting a loan; it's just that the well-known labels are scams.
Actually, good civil engineers do have a "build and test" mentality, and the ones who don't have their bridges fall down. The thing is that their tests are performed on models and on the materials. The reason they don't build bridges and test them is simply that the cost and danger of having a bridge fall down is too great, so they do enough testing on smaller parts that when they actually build a bridge, they can be sure that it will work.
With software, the construction costs are negligable and the costs of a full-size model failing are also trivial. The correct engineering discipline in this case is to do the testing on the actual software.
In order to use a proper engineering discipline for software, you need to document what the code is supposed to do, all of the assumptions about the state of the system, and so forth. Then you need to test whether the actual code does what it is supposed to and maintains the constraints on the data. But you only do a little of this with theory and formal methods; most of it needs to be done by actually trying the code in various circumstances. Traditional engineering is done with a lot of testing of parts, testing of models you hope are similar, some simulation, some intuition, a bit of theory, and a big final inspection.
Now, it is true that a lot of the engineering practices are missing in the software world. But the things people actually do in the software world are a part of engineering; just not a complete method. And there is an unfortunate tendancy towards producing extra work which is not actually useful in the name of adding superficial similarity to different parts of the traditional engineering process. It is a bit like asking a civil engineer to produce a drawing of a new bridge not to scale without any information about the materials or the site.
Not under Linux, at least. The VFS prohibits it; vfs_link() returns -EPERM if S_ISDIR(old_dentry->d_inode->i_mode). The FreeBSD man page for link(2) also explicitly prohibits it. Solaris evidentally lets root link and unlink directories, but that's not relevant to problems with Gentoo. (I'm not sort of curious as to whether you can fill up disks under Solaris with files in directories that have been put into cycles and unlinked)
No, people write "For whom the something somethings" and "To whom it may concern" (those being set phrases), but "Who did you vote for", "Who did you want me to tell", "Who did you trust", and so forth (from a search for "who did you"; other patterns will produce similar results).
I suspect that most people use "whom" as the object of a preposition which has moved with it, but generally use "who" if there is no preposition or if they strand it, and generally strand the preposition. So: 39 hits for "for who did you vote", 298 for "for whom did you vote", 15400 for "who did you vote for", and 369 for "whom did you vote for". In the "who did you vote for" question, I see a 96% use of "who" rather than "whom".
My guess is that, were you to actually look at all instances of "who[m]" where "whom" would be appropriate, you would get about 90% "who", but if you look at instances where "who[m]" follows a preposition or verb (e.g. pair questions like "who likes whom") you'd get 90% the other way. That is, you hear it used correctly 50% of the time, but 90% of the time it's not used and you don't notice.
Google finds 4,770,000 hits for "if I were", as opposed to 2,970,000 for "if I was" (which obviously includes indicative conditionals, which are uncommon but still account for some of the cases). That's a 61% market share for the subjunctive, in this construction at least. The subjunctive may be widely recognized as being virtually extinct, but I'm not going to give up on it until Netcraft... er, Google confirms it.
(This contrasts significantly with "whom", which seems to appear most commonly in usage examples, old writing, and references to old writing, like the common title pattern "For Whom the * *")
Even if the terrorists don't care whether we have freedom for its own sake, one of bin Laden's stated goals is to destroy the US economy. Our freedom is one of the things that makes our economy work as it is structured currently. If the US were a totalitarian dictatorship, bin Laden would have reduced the situation to a previously solved problem. So you're right that Osama doesn't hate us because we're free, but that doesn't mean that Osama doesn't have different reasons to want us not to be free (or, for that matter, for the US govt to spend a lot of money on reducing our freedom).
because they've got HARD LINKS to some directories
You can't have hard links to directories. They aren't supported, and for a good reason (they would mess up the directory structure). Whatever the problem was, it wasn't that.
Re:An observation on IPv6
on
The Next Net
·
· Score: 1
Very few major web sites have AAAA records. But a regular A record gives you an IPv6 address, because the IPv4 address space is included in the IPv6 address space. Chances are that current sites won't generally move to IPv6-only addresses for a long time, just because there's little reason to discard an IPv4 address you already have, or to get a second IPv6 address in addition to the automatic equivalent. Slashdot, for example, has the IPv6 address::66.35.250.150, aka::4223:FA96, and will probably keep using it even when all of the machines on its local network are using IPv6.
However, for a company currently in court claiming that the fruits of its labours have been misappropriated to turn around and do exactly the same thing
Actually, SCO's never claimed in court that the fruits of its labours have been misappropriated. SCO claimed that the fruits of IBM's labour belonged to them, and also claimed that they didn't misappropriate Linux. It is completely in keeping with SCO's position to use Groklaw's work; the only unusual thing is that they haven't yet sued Groklaw for not licensing it exclusively to SCO.
Google has an advantage in supporting the pet projects of employees that they're a software company. It doesn't cost a lot to make the whole codebase accessible to employees to play with (unlike, for example, giving employees access to hardware fabrication or something). As for the time, I wouldn't be surprised if Google gets just as much work on the assigned projects out of their employees as other companies do, simply because the 20% for pet projects comes primarily out of time people usually spend bored and sleepy.
If the "reuse repository" was otherwise unused, why didn't you use it for the bits you copied from one project to another? I'd guess that the rest of the organization was also reusing their code by copying it from project to project without anybody knowing.
One problem with that general plan is that you don't reuse code in the future; you reuse code from the past. When you write something, you don't know if it is going to be useful in projects which haven't started yet. You find out that something is reuseable when you need it and you've written it before. At that point, instead of copying it into the new project, you can move it into the common area and use it from there.
I don't think the perceived quality of the code that's shared matters all that much; if it did, you wouldn't be willing to work on projects with other people. I think it's more a matter of having access to code that wasn't originally written to be shared.
The "paging file" is the name that Microsoft uses for actual swap, because they had done a broken implementation of swap in pre-95 Windows and needed a different name to distinguish them.
The relevant point of using XML is that it's a standard for serializing and deserializing structured data in a way that doesn't depend on the type of data. So it's an advantage in maintainability over their old binary formats, and makes it easier for different Office versions to be compatible with each other.
The only benefit to them of XML being commonly associated with public standards is PR.
But Jello does look like it's splashing (although not enough to defeat surface tension), and it's very viscous. Putty absorbs impacts, so it's not going to do much. A low viscosity solid would be dry sand, which doesn't splash.
So the guess probably ought to be that less viscosity means that something will just spread out, medium means that it splashes, and lots means that it goes crown-shaped but no droplets fly off.
Of course, it's still necessary to do the experiment to determine which, if any, of these thresholds are attained by liquids. It could be that, at the viscosity necessary to not splash, a substance that isn't solid (i.e., composed of parts of sufficient individual mass to not float away) would vaporize.
There's also a difference between formal language and informal language, and a difference between monologue and discourse. Chances are that when you see a friend on the street, you don't launch into a speech. Rather, you exchange a series of mostly monosyllables and sentence fragments. If, however, you begin telling a story or explaining something, you'll use mostly complete sentences and organize them in a logical structure. If you are called upon to do some public speaking, you will probably additionally enunciate more and add extra information to cover for the fact that the audience cannot interrupt you with questions.
The "netspeak" discussed in the article is the written counterpart to conversational English. It is not derived from formal writing; it is derived from informal spoken discourse, adapted to typed text.
It is obviously inappropriate for formal writing, and students have to be taught to write well, but there's no reason that they can't chat online informally and write papers formally. No parents avoid chatting around the breakfast table for fear that they will somehow damage their ability to give speeches. Cicero didn't deliver a prepared speech when he wanted to know how his friends were feeling, and there's no reason people chatting online should write essays to each other.
(Incidentally, the plural of "medium" is "media", unless your offspring are chatting with the dead)
The solution is to give shiny mobile devices with browsers to PHBs (or, perhaps, management students). If the PHB doesn't bother with a laptop when first meeting web designers, but instead first looks at the site on the phone he carries around regularly, suddenly the designers have to do things very differently.
The shift to thin clients will be piece by piece. Lots of families these days have a computer per person. Before long, the effort of keeping data while upgrading these will make network-attached storage worthwhile for the family.
I wouldn't be too surprised if the home of 2015 has all of the storage on a file server appliance, and the things that act like PCs boot off of USB sticks and look a lot like flat panel iMacs.
Desktops will never offload the processing power, because processing is cheaper than communications. They will offload the storage, because it is beneficial to have that accessible. "Thin clients" will primarily not have local storage, aside from removable media; otherwise, they will be similar to current PCs, because it is necessary or cost-effective to do everything else per-client. But the "identity" of a computer, as seen by the user, is really tied to the local storage, so users will feel like they have thin clients, and say things like "I like to use my computer in the family room because the processor is faster there", like they now say, "I like to play my video games in the family room, because the TV is bigger there."
Well, with a bit of replication, your servers aren't all going to go down together due to random failures. And the same sorts of flaws that take down all of the servers would take down all of the desktops and be more of a pain anyway.
Slashdot Mirror
If you know you're in the post office when you write down the numbers, you could just go to the USPS site. The only thing that Google adds is that it identifies the shipper by the format of the number and lets you use a control you already have to get there. Google doesn't even report the information; it just sends you to the shipper's site.
If they had used an open-source SCM from the start and not changed things around, they'd be using RCS, which is totally useless for distributed development on this scale. If they had used an open-source SCM from when they started using an SCM, they'd be using CVS, which isn't much more applicable to the actual problem. BitKeeper was something that worked through the period when the available systems weren't really appropriate, and served as something to use while the problem space become sufficiently well understood that it could be solved correctly.
Primarily due to frustration with the speed of existing solutions, and the fact that they do badly with huge numbers of tiny changes to large projects (which is what he deals with), he's started writing something that he claims isn't an SCM. What it does is store versions of trees of files and allow them to be annotated. This is different from an SCM in that it lacks support for merging changes to get a version that nobody created before out of multiple versions that people created independantly. This makes it a history archival program rather than useful for collaboration directly.
On the other hand, it's self-hosting and sparse (the previous thing he wrote when confronted by the inavailability of something he wanted) is also available stored in it. Probably, be the middle of next week (if not the end of the weekend), he'll have if set up as sufficient for his purposes, and other people will be filling in support for the way they work.
Anti-aliased stroked fonts just aren't as good as a good bitmapped font. On the other hand, they're a whole lot better than a bad bitmapped font or a non-anti-aliased stroked font. If you need to scale fonts, the current trend is a great improvement; otherwise, it's worse.
I don't think this at all indicates that Linus was wrong about using BitKeeper. BitMover is going to continue to host bkbits, there's an open source version with limited functionality (which, presumably, will be extended to more complete functionality by the community), and the existing licenses are still valid. They're just not going to do further development on the free version, and so it's time to look at alternatives, not actually switch.
Linus has just posted to the mailing list saying that he is about to stop using BitKeeper, but only so that he can evaluate other things by actually throwing his real work at them. Most likely, in a week he'll say that there's one he likes best, but it's not ready, and he's going back to using BitKeeper until it is.
Personally, I think that the free and the licensing issues surrounding it have hurt BitMover more than helped it; there have been people who have reported that BitMover refused to sell them the commercial version when they were ineligable for the free license, and I suspect that this has contributed to the idea that BitKeeper might be the best SCM out there, but BitMover is too nuts to do critical business with.
Actually, they do show a moderate level of detail world-wide on the photos. It's just streets and such that are only in the US.
Unless you're actually interested in running a business, you should avoid having a business model. Running a successful business, regardless of the model, will take several people working full-time on overhead, and this is likely to eat up your band.
The right path is really to find someone else (such as Magnatune) who has a business model which leaves you ownership of your music, gives you a return that you feel is fair, and involves business practices you think are ethical. There's nothing inherently bad about signing with a label, just like there's nothing inherently bad about getting a loan; it's just that the well-known labels are scams.
Actually, good civil engineers do have a "build and test" mentality, and the ones who don't have their bridges fall down. The thing is that their tests are performed on models and on the materials. The reason they don't build bridges and test them is simply that the cost and danger of having a bridge fall down is too great, so they do enough testing on smaller parts that when they actually build a bridge, they can be sure that it will work.
With software, the construction costs are negligable and the costs of a full-size model failing are also trivial. The correct engineering discipline in this case is to do the testing on the actual software.
In order to use a proper engineering discipline for software, you need to document what the code is supposed to do, all of the assumptions about the state of the system, and so forth. Then you need to test whether the actual code does what it is supposed to and maintains the constraints on the data. But you only do a little of this with theory and formal methods; most of it needs to be done by actually trying the code in various circumstances. Traditional engineering is done with a lot of testing of parts, testing of models you hope are similar, some simulation, some intuition, a bit of theory, and a big final inspection.
Now, it is true that a lot of the engineering practices are missing in the software world. But the things people actually do in the software world are a part of engineering; just not a complete method. And there is an unfortunate tendancy towards producing extra work which is not actually useful in the name of adding superficial similarity to different parts of the traditional engineering process. It is a bit like asking a civil engineer to produce a drawing of a new bridge not to scale without any information about the materials or the site.
Not under Linux, at least. The VFS prohibits it; vfs_link() returns -EPERM if S_ISDIR(old_dentry->d_inode->i_mode). The FreeBSD man page for link(2) also explicitly prohibits it. Solaris evidentally lets root link and unlink directories, but that's not relevant to problems with Gentoo. (I'm not sort of curious as to whether you can fill up disks under Solaris with files in directories that have been put into cycles and unlinked)
No, people write "For whom the something somethings" and "To whom it may concern" (those being set phrases), but "Who did you vote for", "Who did you want me to tell", "Who did you trust", and so forth (from a search for "who did you"; other patterns will produce similar results).
I suspect that most people use "whom" as the object of a preposition which has moved with it, but generally use "who" if there is no preposition or if they strand it, and generally strand the preposition. So: 39 hits for "for who did you vote", 298 for "for whom did you vote", 15400 for "who did you vote for", and 369 for "whom did you vote for". In the "who did you vote for" question, I see a 96% use of "who" rather than "whom".
My guess is that, were you to actually look at all instances of "who[m]" where "whom" would be appropriate, you would get about 90% "who", but if you look at instances where "who[m]" follows a preposition or verb (e.g. pair questions like "who likes whom") you'd get 90% the other way. That is, you hear it used correctly 50% of the time, but 90% of the time it's not used and you don't notice.
Google finds 4,770,000 hits for "if I were", as opposed to 2,970,000 for "if I was" (which obviously includes indicative conditionals, which are uncommon but still account for some of the cases). That's a 61% market share for the subjunctive, in this construction at least. The subjunctive may be widely recognized as being virtually extinct, but I'm not going to give up on it until Netcraft... er, Google confirms it.
(This contrasts significantly with "whom", which seems to appear most commonly in usage examples, old writing, and references to old writing, like the common title pattern "For Whom the * *")
Even if the terrorists don't care whether we have freedom for its own sake, one of bin Laden's stated goals is to destroy the US economy. Our freedom is one of the things that makes our economy work as it is structured currently. If the US were a totalitarian dictatorship, bin Laden would have reduced the situation to a previously solved problem. So you're right that Osama doesn't hate us because we're free, but that doesn't mean that Osama doesn't have different reasons to want us not to be free (or, for that matter, for the US govt to spend a lot of money on reducing our freedom).
because they've got HARD LINKS to some directories
You can't have hard links to directories. They aren't supported, and for a good reason (they would mess up the directory structure). Whatever the problem was, it wasn't that.
Very few major web sites have AAAA records. But a regular A record gives you an IPv6 address, because the IPv4 address space is included in the IPv6 address space. Chances are that current sites won't generally move to IPv6-only addresses for a long time, just because there's little reason to discard an IPv4 address you already have, or to get a second IPv6 address in addition to the automatic equivalent. Slashdot, for example, has the IPv6 address ::66.35.250.150, aka ::4223:FA96, and will probably keep using it even when all of the machines on its local network are using IPv6.
However, for a company currently in court claiming that the fruits of its labours have been misappropriated to turn around and do exactly the same thing
Actually, SCO's never claimed in court that the fruits of its labours have been misappropriated. SCO claimed that the fruits of IBM's labour belonged to them, and also claimed that they didn't misappropriate Linux. It is completely in keeping with SCO's position to use Groklaw's work; the only unusual thing is that they haven't yet sued Groklaw for not licensing it exclusively to SCO.
Google has an advantage in supporting the pet projects of employees that they're a software company. It doesn't cost a lot to make the whole codebase accessible to employees to play with (unlike, for example, giving employees access to hardware fabrication or something). As for the time, I wouldn't be surprised if Google gets just as much work on the assigned projects out of their employees as other companies do, simply because the 20% for pet projects comes primarily out of time people usually spend bored and sleepy.
If the "reuse repository" was otherwise unused, why didn't you use it for the bits you copied from one project to another? I'd guess that the rest of the organization was also reusing their code by copying it from project to project without anybody knowing.
One problem with that general plan is that you don't reuse code in the future; you reuse code from the past. When you write something, you don't know if it is going to be useful in projects which haven't started yet. You find out that something is reuseable when you need it and you've written it before. At that point, instead of copying it into the new project, you can move it into the common area and use it from there.
I don't think the perceived quality of the code that's shared matters all that much; if it did, you wouldn't be willing to work on projects with other people. I think it's more a matter of having access to code that wasn't originally written to be shared.
The "paging file" is the name that Microsoft uses for actual swap, because they had done a broken implementation of swap in pre-95 Windows and needed a different name to distinguish them.
The relevant point of using XML is that it's a standard for serializing and deserializing structured data in a way that doesn't depend on the type of data. So it's an advantage in maintainability over their old binary formats, and makes it easier for different Office versions to be compatible with each other.
The only benefit to them of XML being commonly associated with public standards is PR.
But Jello does look like it's splashing (although not enough to defeat surface tension), and it's very viscous. Putty absorbs impacts, so it's not going to do much. A low viscosity solid would be dry sand, which doesn't splash.
So the guess probably ought to be that less viscosity means that something will just spread out, medium means that it splashes, and lots means that it goes crown-shaped but no droplets fly off.
Of course, it's still necessary to do the experiment to determine which, if any, of these thresholds are attained by liquids. It could be that, at the viscosity necessary to not splash, a substance that isn't solid (i.e., composed of parts of sufficient individual mass to not float away) would vaporize.
There's also a difference between formal language and informal language, and a difference between monologue and discourse. Chances are that when you see a friend on the street, you don't launch into a speech. Rather, you exchange a series of mostly monosyllables and sentence fragments. If, however, you begin telling a story or explaining something, you'll use mostly complete sentences and organize them in a logical structure. If you are called upon to do some public speaking, you will probably additionally enunciate more and add extra information to cover for the fact that the audience cannot interrupt you with questions.
The "netspeak" discussed in the article is the written counterpart to conversational English. It is not derived from formal writing; it is derived from informal spoken discourse, adapted to typed text.
It is obviously inappropriate for formal writing, and students have to be taught to write well, but there's no reason that they can't chat online informally and write papers formally. No parents avoid chatting around the breakfast table for fear that they will somehow damage their ability to give speeches. Cicero didn't deliver a prepared speech when he wanted to know how his friends were feeling, and there's no reason people chatting online should write essays to each other.
(Incidentally, the plural of "medium" is "media", unless your offspring are chatting with the dead)
The solution is to give shiny mobile devices with browsers to PHBs (or, perhaps, management students). If the PHB doesn't bother with a laptop when first meeting web designers, but instead first looks at the site on the phone he carries around regularly, suddenly the designers have to do things very differently.
The shift to thin clients will be piece by piece. Lots of families these days have a computer per person. Before long, the effort of keeping data while upgrading these will make network-attached storage worthwhile for the family.
I wouldn't be too surprised if the home of 2015 has all of the storage on a file server appliance, and the things that act like PCs boot off of USB sticks and look a lot like flat panel iMacs.
Desktops will never offload the processing power, because processing is cheaper than communications. They will offload the storage, because it is beneficial to have that accessible. "Thin clients" will primarily not have local storage, aside from removable media; otherwise, they will be similar to current PCs, because it is necessary or cost-effective to do everything else per-client. But the "identity" of a computer, as seen by the user, is really tied to the local storage, so users will feel like they have thin clients, and say things like "I like to use my computer in the family room because the processor is faster there", like they now say, "I like to play my video games in the family room, because the TV is bigger there."
Well, with a bit of replication, your servers aren't all going to go down together due to random failures. And the same sorts of flaws that take down all of the servers would take down all of the desktops and be more of a pain anyway.
So that's how the "iPod Halo Effect" works.