In college I wrote a paper that I opened with an original poem that I attributed to an 17th century poet whom I had invented. None of the four professors who saw the paper questioned this poet's existence. Was this a type of reverse plagiarism?
Yes, they do. Try reading the fine article (it's actually quite well written, especially for an economist). The guy discovered that the author of a book plagiarised from the very NY Times articles he referenced. And the plagiarising Slashdot submitters do exactly what you are saying they do not do.
The submissions I'm objecting to make it appear as if the summary is the work of the submitter, rather than a direct quotation. This is the very definition of plagiarism. In reply to the AC, I have no doubt this shameful practice has been going on for 10 years, but my unsystematic impression is that it, as well as the quality of the comments and the proportion of AC comments, has gotten a violently worse in the past year.
At the top of this page I see a cheesy advertisement for another company that offers to "check your writing for plagiarism". Since, presumably, you know whether you plagiarised, I interpret this as a service that suggests it can tell you if your plagiarism is likely to be detected.
Too bad Slashdot doesn't use something like this; plenty of submissions lately are lifted wholesale from somewhere else, without even a trivial rephrasing. It's shameful, and is certain to be a major factor in the site's all to easily predictable demise, a prospect that I find depressing and ineluctable.
I've compiled and installed plenty of "unofficial" stuff on OSX and Linux. My experience with the Ruby thing was the first time I've encountered syntax errors in libraries that were part of the official distribution. I intend to stay away.
As he says himself, "the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant."
Not just faster than CPython, but faster than C for some common tasks. Pretty amazing.
However, this project is not yet very useful to the people who might be most interested in a really fast python, as it does not work with numpy. But when they get that to work, wow.
You said "all modern e-readers". Kindle is the most prominent member of that class.
ePub might be a little better than typical Kindle output, but it still sucks. I can see it, and I'm not even particularly picky about typography. The image you link to is a good example of how bad they suck. Look how nasty and gappy the lines are. Notice how, for some reason, there is no hyphenation, and notice how a little hyphenation could have improved the readability and aesthetics of the page.
It seems tautological that you won't be able to read a pdf on a device without a properly functioning pdf reader. So, yes, if you distribute your document as pdf only you will be excluding readers who insist on exclusively using these devices, if they exist.
Pdf is obviously an option. I read pdfs on my iphone and every other screen I have. That there are problems with this option is clear, but that's not the same as "not an option".
I'm not clear what you mean by "view a PDF with large text". Do you have a pdf reader that tries to increase the font size, or make font substitutions, rather than just zooming the whole page? Of course that will mangle the page, and create something that was not intended, but pdf readers should not try to do that.
You have some pretty rigid views about the proper role of an author. Some documents are typographically complex, or convey their meaning partly through layout and typography, and these elements will be destroyed by typical e-book software and are not preserved in e-book formats. Pdf is the only way I know of to handle this. I think if a book is distributed as a pdf then a large-type version should also be prepared, since, as I think you're saying, there is no way to increase the type size of the pdf for reading on the small screen without screwing it up or having to scroll sideways to read it.
Getting a little worked up, aren't you? I wish you were correct, but you're simply wrong. If you're actually interested in this subject you might want to start educating yourself by looking here for a recent rant about the terrible typography in e-readers and why, specifically, their output does not even come close to looking "as good as the paper version". I'm curious: what hyphenation and line-breaking algorithms do you think that the "modern" e-readers use? Do they all use the same ones? Well, never mind - maybe I'm just being mean now.
Yes, you've pointed out the drawbacks with deploying as pdf, which I agree are real. And I think I've pointed out the advantages of pdf, and the drawbacks of ebook formats as they are currently implemented. If you're an author and you care or want to control what the document actually looks like, then pdf (or a bunch of images) is your only option. Neither ebook formats nor html will do this. Sometimes this is important, sometimes not.
But one of the main reasons for LaTeX is exactly to separate content from presentation, so I think you're misinformed about that; and that point doesn't apply to pdf, which is for consumption only, not for writing.
There are really only a few sizes that are used in practice. And the pages don't need to fit the screen exactly. Make one for phones, one for iPad-sized tablets, one for computer monitors, and a large-type version for each of those sizes, and you're done. Trivially scripted. But why not just use an ebook format? Because the readers attempt to do typesetting on the fly, most critically linebreaking, to flow the text to fit the device, usually without hypenation, and the result looks like crap - even worse than html displayed by a browser.
But you can make your pdf with any page size and font. You could easily make a set of pdfs for all the common devices from a single LaTeX source, and the result would look much better, typographically, than the typical ebook.
You could use some sort of XML and generate TeX from it, but typing XML is horrible. I like to work in vim, and with a couple of macros entering LaTeX is really easy.
I type both xml and LaTeX with vim, and I find both are easy if you use the right plugins. Using the xml plugin vim will type all the angle brackets for you, complete your tags, format, and generally take the drudgery out of writing xml.
Slashdot Mirror
In college I wrote a paper that I opened with an original poem that I attributed to an 17th century poet whom I had invented. None of the four professors who saw the paper questioned this poet's existence. Was this a type of reverse plagiarism?
Yes, they do. Try reading the fine article (it's actually quite well written, especially for an economist). The guy discovered that the author of a book plagiarised from the very NY Times articles he referenced. And the plagiarising Slashdot submitters do exactly what you are saying they do not do.
I see what you did there.
The submissions I'm objecting to make it appear as if the summary is the work of the submitter, rather than a direct quotation. This is the very definition of plagiarism. In reply to the AC, I have no doubt this shameful practice has been going on for 10 years, but my unsystematic impression is that it, as well as the quality of the comments and the proportion of AC comments, has gotten a violently worse in the past year.
At the top of this page I see a cheesy advertisement for another company that offers to "check your writing for plagiarism". Since, presumably, you know whether you plagiarised, I interpret this as a service that suggests it can tell you if your plagiarism is likely to be detected.
Too bad Slashdot doesn't use something like this; plenty of submissions lately are lifted wholesale from somewhere else, without even a trivial rephrasing. It's shameful, and is certain to be a major factor in the site's all to easily predictable demise, a prospect that I find depressing and ineluctable.
And I see I hit a nerve with someone who modded me "offtopic." Nothing hurts like the truth.
I've compiled and installed plenty of "unofficial" stuff on OSX and Linux. My experience with the Ruby thing was the first time I've encountered syntax errors in libraries that were part of the official distribution. I intend to stay away.
I agree (and no, Fink, etc., don't cut it). It's one of the reasons I prefer Linux and only use OSX if I have to.
I tried to install a program written in Ruby and the experience left me with a very bad impression of the Ruby ecosystem.
"Do you expect me to talk?"
"No, Mr. Bond, I expect you to die."
(If I recall correctly.)
It does with Vimium.
As he says himself, "the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant."
They're obviously a class act. Which means they don't deserve to be baldy plagiarised, which was done by the story submitter and Slashdot.
Not just faster than CPython, but faster than C for some common tasks. Pretty amazing.
However, this project is not yet very useful to the people who might be most interested in a really fast python, as it does not work with numpy. But when they get that to work, wow.
If the strangeness is you getting different results from different computers, it could be due to this.
"I specifically didn't mention the Kindle"
You said "all modern e-readers". Kindle is the most prominent member of that class.
ePub might be a little better than typical Kindle output, but it still sucks. I can see it, and I'm not even particularly picky about typography. The image you link to is a good example of how bad they suck. Look how nasty and gappy the lines are. Notice how, for some reason, there is no hyphenation, and notice how a little hyphenation could have improved the readability and aesthetics of the page.
It seems tautological that you won't be able to read a pdf on a device without a properly functioning pdf reader. So, yes, if you distribute your document as pdf only you will be excluding readers who insist on exclusively using these devices, if they exist.
Pdf is obviously an option. I read pdfs on my iphone and every other screen I have. That there are problems with this option is clear, but that's not the same as "not an option".
I'm not clear what you mean by "view a PDF with large text". Do you have a pdf reader that tries to increase the font size, or make font substitutions, rather than just zooming the whole page? Of course that will mangle the page, and create something that was not intended, but pdf readers should not try to do that.
You have some pretty rigid views about the proper role of an author. Some documents are typographically complex, or convey their meaning partly through layout and typography, and these elements will be destroyed by typical e-book software and are not preserved in e-book formats. Pdf is the only way I know of to handle this. I think if a book is distributed as a pdf then a large-type version should also be prepared, since, as I think you're saying, there is no way to increase the type size of the pdf for reading on the small screen without screwing it up or having to scroll sideways to read it.
Getting a little worked up, aren't you? I wish you were correct, but you're simply wrong. If you're actually interested in this subject you might want to start educating yourself by looking here for a recent rant about the terrible typography in e-readers and why, specifically, their output does not even come close to looking "as good as the paper version". I'm curious: what hyphenation and line-breaking algorithms do you think that the "modern" e-readers use? Do they all use the same ones? Well, never mind - maybe I'm just being mean now.
Yes, you've pointed out the drawbacks with deploying as pdf, which I agree are real. And I think I've pointed out the advantages of pdf, and the drawbacks of ebook formats as they are currently implemented. If you're an author and you care or want to control what the document actually looks like, then pdf (or a bunch of images) is your only option. Neither ebook formats nor html will do this. Sometimes this is important, sometimes not. But one of the main reasons for LaTeX is exactly to separate content from presentation, so I think you're misinformed about that; and that point doesn't apply to pdf, which is for consumption only, not for writing.
There are really only a few sizes that are used in practice. And the pages don't need to fit the screen exactly. Make one for phones, one for iPad-sized tablets, one for computer monitors, and a large-type version for each of those sizes, and you're done. Trivially scripted. But why not just use an ebook format? Because the readers attempt to do typesetting on the fly, most critically linebreaking, to flow the text to fit the device, usually without hypenation, and the result looks like crap - even worse than html displayed by a browser.
But you can make your pdf with any page size and font. You could easily make a set of pdfs for all the common devices from a single LaTeX source, and the result would look much better, typographically, than the typical ebook.
I type both xml and LaTeX with vim, and I find both are easy if you use the right plugins. Using the xml plugin vim will type all the angle brackets for you, complete your tags, format, and generally take the drudgery out of writing xml.
Range in "square miles"? That's as silly as this.
Would this do it?: http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout