Totally separate the data collection from the user interface. Keep both of those totally separate from the system that selects and delivers the alerts. Make sure the system as a whole won't make the problem worse (e.g. if you lose a major piece of infrastructure, will it send you 300 alerts?)
Ireland should be in your first list. Ireland is predominantly English-speaking. Irish children learn Irish in school - at least to a basic level - but its actual use is relatively rare.
Personally, I just bought myself a bunch of (well, 6) removable SATA caddies. But I'm using them for offsite backups, so I have slightly different needs to you I guess.
And the answer is incoming links from around 86,000 pages according to google (links:domain.name)a lot of them are created internally passing links between malware site to malware site. But the majority come from sites using php forms which add user posts to the the sites pages.
A number of months ago i found my sites contact forms were sending a lot of garbage emails to me absolutely stuffed with urls and I wondered why bother doing this since i'm not going to visit the sites. anyway the cure was to only allow the forms to be processed with no more than a few urls in them. stopped the junk hitting the inbox. It's not stopped the automated posting but the forms are not processed and i don't get them any more.
When I examined the links to the malware site i found php posted user posts packed with links just like my emails had been the difference being these were posted published and being crawled. Because of these links a site with less than 4 weeks life is ranked highly because of the quantity of inbound links and thats why I got to watch a display of XP like virus and malware scanning,
The general solution to this problem is for you to modify your software so that links in blog comments are served to add rel="nofollow" to all of the links. See http://en.wikipedia.org/wiki/Nofollow for more details. Of course that will not make the spam comment posts go away immediately but if the technique is rolled out widely, then the SEOs will figure out that posting spam blog comments does not gain them anything.
It's fairly obvious that the cost of informing customers - and other related costs - should be borne by the organisation who failed in their duty to ensure the integrity and confidentiality of the data. After all, until we are at a point where it is cheaper to take the measures to keep the data safe than to be delinquent, companies are incentivised to be delinquent.
First, figure out what it means for your website to be available (do people need to be able to fetch a page, or do that also be able to log in, etc.). Select monitoring software and set it up correctly.
As for the serving architecture, at this level of load, you're better off without clustering. You don't need it for the load and it's probably a net loss for reliability; most outages I've seen in two-node cluster is either infrastructural that takes them both out (power distribution failures, for example) or problems with the HA system itself (switches going into jabber-protection mode and provoking a failover, failure detection script bugs, etc.). If you really feel that a single machine does not offer enough protection, go for an active-active configuration and simplify the problem to directing incoming requests to the working web servers, as opposed to "failing over".
This changes a bit if your reliability needs are high enough to justify separate serving facilities in separate data centres in different cities. For that sort of stuff you need to look at working with DNS to solve part of the problem too, but the right approach there depends on to what extent the website is static content.
Not a moron really, at least in terms of UK usage. Stubborn and irritating, yes, but there is not really an implication of idiocy. The phrase "stupid git" is quite common and isn't a tautology. The OED rather bloodlessly defines "git" as "a worthless person".
This is obviously not true though - it's a general argument against the adoption of any new tool. Otherwise all computer science would still be conducted in FORTRAN IV and Autocode. Any potential switch has costs and risks, as well as benefits. All of those should be weighed.
If the system you are migrating from manages trees, you should be fine. CVS migration is pretty easy and I understand that Perforce works quite well too (in both directions!). Most of the migration tools are listed in the GIT FAQ.
The places where people are likely to have trouble is migrating from tools that don't understand that there's more than one file. For example, RCS and SCCS both support branches, but in a completely different way to git (branches are per-file, they're not for the whole repository). This means that during conversion, something useful has to happen with them, but the right answer isn't clear to a program. If versions 1.1, 1.1.1.1, 1.1.1.2 and 1.2 of file "foo" exist, then versions 1.1.1.2 and 1.2 are on different branches and either may be the older revision. It's not clear if revision 1.43.1.3 of file "bar" is the same "branch" as "foo" 1.1.1.2 or not. Because RCS and SCCS deal with single files only, it's not possible to find an answer to these questions in the history files at all - if there is an answer, it's just a convention of the user. Essentially what's happening here is that the git import process requires information which isn't represented in the files you're converting from. For what it's worth, migrating from SCCS or RCS to CVS has a similar problem.
Personally, I've migrated from CVS to git for findutils (well, Jim Meyering did the actual migration; he migrated coreutils too). I haven't regretted migrating at all. It took me a long time of using git locally before I was comfortable migrating the master repo, though. As a git beginner the thing I found most worrying was that I found it hard to envisage the effect of the git command I was typing. The thing it took me a long time to figure out is that with a distributed version control system, it's safe to screw up your local copy, as long as you don't push the result.
As I recall things from those events ten years ago, Word was not capable of correctly rendering a sentence typed like this:
echo 'echo `hello`': `hello`
If you're writing a book about Unix, shell commands of that general form are not uncommon. Certainly going back to my marked copy of the published book, some backticks have been changed to single quotes, wholly changing the meaning of the text (there's an instance on page 198, for example).
Certainly there are publishers who are able to set up processes that correctly preserve information from author's finger to printed page while allowing copy-editors and layout folks to do their thing, and I concede it's possible that some of those publishers use Word, but MCP wasn't able to do that in this case.
Every publisher I know has a whole style sheet and a Word template that tells you exactly how to do all your formatting. And if you get the formatting write in there, then they aren't going to convert it to anything and all your formatting would stay intact. By "load text into word" do you mean you sending were them a.txt file?
ITYM "get the formatting right". It was not formatting that was the problem. Formatting the pages is not the author's sole responsibility anyway, there are folks at the publisher who work on page styling and who - let's face it - probably have better judgment on that than authors. It was the content that was screwed up. Backticks and quotes don't just look different, they are different characters.
Yes, I believe I sent them a text file, they had internal markup standards for indicating which sections of the text should be in a monospace font, and so forth. From the evidence left behind in my working directory, it looks like I used latex2x to automate that.
Yes, you're right. Tools are wholly secondary to the content.
After all, when was the last time you read a book and though "Wow, the page layout in this book *rocks*?". Good technical books have a well-thought-out structure, have something vital to say, and explain their material clearly. It's the content, not the tools. Every hour spent tweaking that TeX macro (or fighting with the word processor, etc.) is an hour you should have spent thinking about structure of the the book, the text, or the (often forgotten) intended reader.
Honestly, after all this time I can't remember the details, but looking at the directory containing the source, I wrote the initial draft in LaTeX. However, it looks like I pushed it through ltx2x; I don't recall whether I gave SAMS the LaTeX, the ASCII or both.
Bear in mind that there are doubtless a number of publishers who are perfectly capable of getting it right, but having been burned already, I'm probably over-cautious. In alphabetical order, the publishers I'd be interested in working with now are Addison-Wesley, O'Reilly, Prentice-Hall and Wiley.
Maybe also Morgan Kaufmann, though that's really based on the astonishing quality of some MK books I've read (e.g. "Advanced Compiler Design & Implementation" by Muchnick) more than their production methods, whatever they are. I would guess that Wrox Press's methods could have been quite workable for technical authors, but the point is moot since they went bust in 2003 and were acquired by Wiley.
One minor point about LaTeX; it's a language, so if you are a programmer, expect to get sidetracked on issues of making it do exactly what you want, for no good reason other than the fact that for a programmer, that's fun. I know that when drafting my first book (that one was never published) I spent too much time crafting a spanner to put in the margin to indicate that that paragraph needed further work. Getting the spanner to face in opposite directions depending on whether it was on an even or odd page was a lot of fun, though.
I would post the finished macros, but the Slashdot lameness filter thinks there are too many line breaks between the LaTeX commands.
I wish I'd known I had chosen the wrong publisher.
I published a book with SAMS (an imprint of Macmillan Computer Publishing, which is not related to the British publisher called Macmillan). I was working with some half a dozen other authors and only needed to complete a couple of chapters (the page production rate that Que require from authors is so huge that I'm sure I could not have achieved that as a sole author, at least not if I wanted to take the time to check the copy I was submitting).
The basic problem was that MCP's editors (I guess copy editors initially) loaded the text I gave them into Microsoft Word (I assume, I can't remember if they confirmed this). It immediately "corrected" all the punctuation. Since the book was about Unix, there was an abundance of single and double quotes, backticks, and so forth. They all got totally screwed up. On proof reading, I spotted these, fixed them and sent the corrected text back. Then of course they loaded the text into Word again and broke everything a second time.
The whole experience was frustrating and I was left with an author credit on a portion of a book that was riddled with stupid errors. I am embarrassed to have been associated with such a farce of an attempt at a technical book. I will never again work with any publisher in that group.
I should disclose that following publication, I had other difficulties with MCP in that they published the text a second time in another book under their Que imprint, without consulting me or paying me. They rectified that when I complained, though I didn't know to do so until I noticed my text in a book I browsed in a bookshop. So there is some subsequent bad feeling on my part, so take it as read that you're not getting a dispassionate report here. Mind you, the book was published ten years ago this year, so I've calmed down a bit now.
The list of publishers I'd consider collaborating with now is much, much shorter - only about four publishers (plus any others I don't know about - and I'm sure there are many - who will accept camera-ready copy).
Other people have expressed this in different ways, but:
If you want to achieve a level of excellence beyond the average programmer, learn a number of languages well. If you are developing on Unix, learn at least:
Shell programming (not just how to type Unix commands)
A proper scripting language (Python or Perl or, perhaps, Ruby) to use when that shell script would otherwise be reaching 100 or so lines
A systems programming language (C is the best choice here, though you can probably get by with C++)
An object-oriented language (e.g. Java or Python or C++)
LISP or Scheme
Any functional language (there are a number of candidates, pick something a friend uses if you need help learning one).
If you had asked about developing on any other system than Unix, I'd have dropped the requirement for shell script programming.
The benefit of learning more than one language is that it leaves you with the ability to consider a problem from more than one point of view, gives you insights into effective and powerful methods, and lets you choose the right tool for the job.
There is nothing more painful than a multi-hundred-line C program that should really be a 20 line shell script or a 300 line shell script that should really be a 500 line Python program. Especially when it comes to maintenance.
Once you have started learning the languages, take care to get to know the associated tools; the profilers, the debuggers, tools like ltrace, strace, valgrind, lint checkers, and so forth. Then research the available libraries for those languages (CPAN for Perl, Boost for C++, etc.)
Oh, and when I say learn a language, I mean use it to write a non-trivial, useful program that you intend to use regularly.
I suspect maybe you don't quite understand how MapReduce works. Take a look at the references section of the MapReduce paper; the paper's authors are well aware of research in the parallel sorting field. In particular their reference 1 is most relevant.
Slashdot Mirror
Totally separate the data collection from the user interface. Keep both of those totally separate from the system that selects and delivers the alerts. Make sure the system as a whole won't make the problem worse (e.g. if you lose a major piece of infrastructure, will it send you 300 alerts?)
Ireland should be in your first list. Ireland is predominantly English-speaking. Irish children learn Irish in school - at least to a basic level - but its actual use is relatively rare.
Personally, I just bought myself a bunch of (well, 6) removable SATA caddies. But I'm using them for offsite backups, so I have slightly different needs to you I guess.
The general solution to this problem is for you to modify your software so that links in blog comments are served to add rel="nofollow" to all of the links. See http://en.wikipedia.org/wiki/Nofollow for more details. Of course that will not make the spam comment posts go away immediately but if the technique is rolled out widely, then the SEOs will figure out that posting spam blog comments does not gain them anything.
It's fairly obvious that the cost of informing customers - and other related costs - should be borne by the organisation who failed in their duty to ensure the integrity and confidentiality of the data. After all, until we are at a point where it is cheaper to take the measures to keep the data safe than to be delinquent, companies are incentivised to be delinquent.
First, figure out what it means for your website to be available (do people need to be able to fetch a page, or do that also be able to log in, etc.). Select monitoring software and set it up correctly.
As for the serving architecture, at this level of load, you're better off without clustering. You don't need it for the load and it's probably a net loss for reliability; most outages I've seen in two-node cluster is either infrastructural that takes them both out (power distribution failures, for example) or problems with the HA system itself (switches going into jabber-protection mode and provoking a failover, failure detection script bugs, etc.). If you really feel that a single machine does not offer enough protection, go for an active-active configuration and simplify the problem to directing incoming requests to the working web servers, as opposed to "failing over".
This changes a bit if your reliability needs are high enough to justify separate serving facilities in separate data centres in different cities. For that sort of stuff you need to look at working with DNS to solve part of the problem too, but the right approach there depends on to what extent the website is static content.
Record that, and come back to read it in 20 years. Or wait 10 years and ask your information agent to find it for you.
This is somewhat ironic considering that William Herschel discovered a planet (Uranus) while Kepler did not.
The trouble is, protectionist trade policies can significantly hurt employment; consider the Smoot-Hawley Tariff Act for example.
Try talking to Tim Fletcher at Parrswood.
Not a moron really, at least in terms of UK usage. Stubborn and irritating, yes, but there is not really an implication of idiocy. The phrase "stupid git" is quite common and isn't a tautology. The OED rather bloodlessly defines "git" as "a worthless person".
This is obviously not true though - it's a general argument against the adoption of any new tool. Otherwise all computer science would still be conducted in FORTRAN IV and Autocode. Any potential switch has costs and risks, as well as benefits. All of those should be weighed.
If the system you are migrating from manages trees, you should be fine. CVS migration is pretty easy and I understand that Perforce works quite well too (in both directions!). Most of the migration tools are listed in the GIT FAQ.
The places where people are likely to have trouble is migrating from tools that don't understand that there's more than one file. For example, RCS and SCCS both support branches, but in a completely different way to git (branches are per-file, they're not for the whole repository). This means that during conversion, something useful has to happen with them, but the right answer isn't clear to a program. If versions 1.1, 1.1.1.1, 1.1.1.2 and 1.2 of file "foo" exist, then versions 1.1.1.2 and 1.2 are on different branches and either may be the older revision. It's not clear if revision 1.43.1.3 of file "bar" is the same "branch" as "foo" 1.1.1.2 or not. Because RCS and SCCS deal with single files only, it's not possible to find an answer to these questions in the history files at all - if there is an answer, it's just a convention of the user. Essentially what's happening here is that the git import process requires information which isn't represented in the files you're converting from. For what it's worth, migrating from SCCS or RCS to CVS has a similar problem.
Personally, I've migrated from CVS to git for findutils (well, Jim Meyering did the actual migration; he migrated coreutils too). I haven't regretted migrating at all. It took me a long time of using git locally before I was comfortable migrating the master repo, though. As a git beginner the thing I found most worrying was that I found it hard to envisage the effect of the git command I was typing. The thing it took me a long time to figure out is that with a distributed version control system, it's safe to screw up your local copy, as long as you don't push the result.
If you're writing a book about Unix, shell commands of that general form are not uncommon. Certainly going back to my marked copy of the published book, some backticks have been changed to single quotes, wholly changing the meaning of the text (there's an instance on page 198, for example). Certainly there are publishers who are able to set up processes that correctly preserve information from author's finger to printed page while allowing copy-editors and layout folks to do their thing, and I concede it's possible that some of those publishers use Word, but MCP wasn't able to do that in this case.
ITYM "get the formatting right". It was not formatting that was the problem. Formatting the pages is not the author's sole responsibility anyway, there are folks at the publisher who work on page styling and who - let's face it - probably have better judgment on that than authors. It was the content that was screwed up. Backticks and quotes don't just look different, they are different characters. Yes, I believe I sent them a text file, they had internal markup standards for indicating which sections of the text should be in a monospace font, and so forth. From the evidence left behind in my working directory, it looks like I used latex2x to automate that.
Yes, you're right. Tools are wholly secondary to the content.
After all, when was the last time you read a book and though "Wow, the page layout in this book *rocks*?". Good technical books have a well-thought-out structure, have something vital to say, and explain their material clearly. It's the content, not the tools. Every hour spent tweaking that TeX macro (or fighting with the word processor, etc.) is an hour you should have spent thinking about structure of the the book, the text, or the (often forgotten) intended reader.
Honestly, after all this time I can't remember the details, but looking at the directory containing the source, I wrote the initial draft in LaTeX. However, it looks like I pushed it through ltx2x; I don't recall whether I gave SAMS the LaTeX, the ASCII or both.
Bear in mind that there are doubtless a number of publishers who are perfectly capable of getting it right, but having been burned already, I'm probably over-cautious. In alphabetical order, the publishers I'd be interested in working with now are Addison-Wesley, O'Reilly, Prentice-Hall and Wiley.
Maybe also Morgan Kaufmann, though that's really based on the astonishing quality of some MK books I've read (e.g. "Advanced Compiler Design & Implementation" by Muchnick) more than their production methods, whatever they are. I would guess that Wrox Press's methods could have been quite workable for technical authors, but the point is moot since they went bust in 2003 and were acquired by Wiley.
I found the Kopka and Daly book very very useful. Maybe there are newer books for LaTeX 3e, but I found it a great resource.
One minor point about LaTeX; it's a language, so if you are a programmer, expect to get sidetracked on issues of making it do exactly what you want, for no good reason other than the fact that for a programmer, that's fun. I know that when drafting my first book (that one was never published) I spent too much time crafting a spanner to put in the margin to indicate that that paragraph needed further work. Getting the spanner to face in opposite directions depending on whether it was on an even or odd page was a lot of fun, though.
I would post the finished macros, but the Slashdot lameness filter thinks there are too many line breaks between the LaTeX commands.
[Blink.]
No, don't do that. Just use ispell -t for spell-checking, or edit your text with Emacs.
I wish I'd known I had chosen the wrong publisher.
I published a book with SAMS (an imprint of Macmillan Computer Publishing, which is not related to the British publisher called Macmillan). I was working with some half a dozen other authors and only needed to complete a couple of chapters (the page production rate that Que require from authors is so huge that I'm sure I could not have achieved that as a sole author, at least not if I wanted to take the time to check the copy I was submitting).
The basic problem was that MCP's editors (I guess copy editors initially) loaded the text I gave them into Microsoft Word (I assume, I can't remember if they confirmed this). It immediately "corrected" all the punctuation. Since the book was about Unix, there was an abundance of single and double quotes, backticks, and so forth. They all got totally screwed up. On proof reading, I spotted these, fixed them and sent the corrected text back. Then of course they loaded the text into Word again and broke everything a second time.
The whole experience was frustrating and I was left with an author credit on a portion of a book that was riddled with stupid errors. I am embarrassed to have been associated with such a farce of an attempt at a technical book. I will never again work with any publisher in that group.
I should disclose that following publication, I had other difficulties with MCP in that they published the text a second time in another book under their Que imprint, without consulting me or paying me. They rectified that when I complained, though I didn't know to do so until I noticed my text in a book I browsed in a bookshop. So there is some subsequent bad feeling on my part, so take it as read that you're not getting a dispassionate report here. Mind you, the book was published ten years ago this year, so I've calmed down a bit now.
The list of publishers I'd consider collaborating with now is much, much shorter - only about four publishers (plus any others I don't know about - and I'm sure there are many - who will accept camera-ready copy).
Other people have expressed this in different ways, but:
If you want to achieve a level of excellence beyond the average programmer, learn a number of languages well. If you are developing on Unix, learn at least:
If you had asked about developing on any other system than Unix, I'd have dropped the requirement for shell script programming.
The benefit of learning more than one language is that it leaves you with the ability to consider a problem from more than one point of view, gives you insights into effective and powerful methods, and lets you choose the right tool for the job.
There is nothing more painful than a multi-hundred-line C program that should really be a 20 line shell script or a 300 line shell script that should really be a 500 line Python program. Especially when it comes to maintenance.
Once you have started learning the languages, take care to get to know the associated tools; the profilers, the debuggers, tools like ltrace, strace, valgrind, lint checkers, and so forth. Then research the available libraries for those languages (CPAN for Perl, Boost for C++, etc.)
Oh, and when I say learn a language, I mean use it to write a non-trivial, useful program that you intend to use regularly.
Granted it's very custom stuff, but putting tech like this in a box with a SATA interface is really just evolutionary... Cool none the less though. :)
Well, it's already happened. Take a look at the RAMSAN. It kicks ass.
I suspect maybe you don't quite understand how MapReduce works. Take a look at the references section of the MapReduce paper; the paper's authors are well aware of research in the parallel sorting field. In particular their reference 1 is most relevant.