He waffles back and forth, first cooperating, then not, then cooperating, then not. The Microsoft guy has the patience of the Buddha..! By the end of it, the dev is actually threatening to re-enable the Express support if Microsoft doesn't keep corresponding with him.
Whew.
Yes, I've read the entire exchange. And honestly it looks a lot like the dev is being a dick about it.
Re:Well.. he right about Subversion, anyway.
on
Linus on GIT and SCM
·
· Score: 1
.. and now that I've watched the entire thing, start to finish, and wrote a near-complete transcript of it, Linus gets tonnes of things wrong. Oh Linus.. why did you have to begin spewing such diatribes about stuff you visibly know nothing about? Talking about Git is one thing, but then to claim that other products don't do the stuff git does? Sigh. I mean really.. narrowing down changesets to a single directory? Pulling a report of what's changed between two dates or two revisions, narrowed to a single directory or set of directories? Everyone can do that! And you went on for like.. two minutes about how tremendously powerful that ability was, claiming that you "guarantee" that no other system can do that.
Sooo disappointed at how little research you've done.
Uh.. it's a direct response to the original, which itself deviated from the Lina vs. Java VM of the post it was replying to.
I suppose a non-answer is enough for me. There's no point to Lina, and its limitations and restrictions on commercial use (insofar as they're willing to release actual details about it) make it a non-starter. They haven't even actually released it yet! It's slated for release in June 2007.
What they're doing right now is gauging interest by doing a press release with limited details. They claim it's been in development for four years, but honestly: a single video too small to make any informed opinion? Smells not only like vapourware, but free market research by Slashdot. I wonder who paid whom how much to get a (so far) vapourware product on the front page?
And what makes you think that yet another emulation layer in the form of a Lina host isn't more of a nightmare to retool your application to use? If you want a cross-platform GUI, QT works very nicely and you get natively-compiled applications that actually run at native speeds.
There's no mention of execution speed at the Lina website, and I'll take a wild stab at why: It slows things down to a crawl. Looks like it did in the video!
A: LINA is dual licensed. For non-commercial users, LINA is available under the GNU General Public License, Version 2. If you wish to use it commercially, please contact us to find out more about the LINA commercial license.
How can they expect to bar commercial *use* of Lina when it's a GPL'd software product--unless their software must be embedded in the end executables?
Meanwhile, the video describing Lina is terrible. It shows (in a ridiculously puny window) two people installing an Apache-backed *WEB APPLICATION* onto two apparently different systems: a Linux machine and a Mac machine. What's the point of that when a PHP-backed application will do just as well and is nearly as simple use? (And what needed Lina? Apache? The web app itself? Both? Beats the hell out of me.)
There's no word on actual performance of Lina binary applications either, and while they claim additional "security," the reality is that complexity does NOT breed security, and Lina is yet another layer which must be maintained, secured, configured, and reconfigured.
Java already provides all or nearly all of this, and targetting development at Lina would be a massive re-tooling. It would also appear that the LINA PDF is internally inconsistent on the matter of whether legacy *binaries* or just legacy *apps* would run under a Lina host. I'll guess that everything must be recompiled specifically for Lina for it to work properly.
Quite frankly, once Java's GPL'd code is ported to the missing OSes it needs to be ported to, there will be no barrier to Java adoption anymore. Plus, commercial devs can still create independently-licensed Java applications without worrying about Lina demanding their cut for commercial development under Lina.
.. that the article is glaringly absent *actual check-in times.* Or, where *actual check-in times* are available, the details of whether it's the same file as in previous tests is glaringly absent. This leaves open the question as to whether the data set they were working on was identical or whether it was different between the various tests.
Questions that remain:
1. Does the algorithm simply "plainly store" previously-compressed files, and is this the reason why that is the most time-efficient? 2. What exactly was the data for the *actual check-in* times? (What took 28m? What took 13m?) 3. Given that speedier/efficient check-in requires a large tarball format, how are artists supposed to incorporate this into their standard workflow? (Sure, there's a script for check-in, but the article is absent any details about actually using or checking-out the files thus stored except to say it's an unresolved problem regarding browsing files so stored.)
The amount of CPU required for binary diff calculation is pretty significant. For an artistic team that generates large volumes of binary data (much of it in the form of mpeg streams, large lossy-compressed jpeg files, and so forth) it would be interesting to find out what kind of gains a binary diff would provide, if any.
Document storage would also be an interesting and fairer test. Isn't.ODF typically stored in compressed form? If not, then small changes wouldn't necessarily affect the entirety of the file (as it would in a gzip file if the change were at the beginning) and SVN might be able to store the data very efficiently. Uncompressed PDF would certainly benefit.
Something better to do? You mean like actually reading the measly 29-page NIH overview about the available toxicology literature on the health effects of the stuff that millions of us drink every day before I post a link to it? Why yes. Yes I do.
Meanwhile, you still haven't identified which study you're talking about, so nobody knows what you're talking about. There are dozens of studies that show similar things, but it's not clear whether you mean one of those or the NIG *overview*. Which one specifically are you talking about?
A subscription-based publication which the poster didn't say was necessary, and didn't even describe how to find. I.e. he didn't cite *which* study was involved. Therefore, the link is useless. Who amongst the readers of Slashdot even has these subscriptions?
If you consider 40 pages to be "lengthy" you've been on the Internet too long letting your attention span shrink. Also, it's not 40 pages, it's only 29 pages. It's 44 pages after you add in the bibliography, appendix, and table of contents. Why would the table of contents figure in your estimate of how abysmally long you think the review of toxicology is? You can just skip that stuff.
Honestly people, a few pages of PDF that you can simply run a find on, and people run screaming..?
Why even post at all if you're not going to at least read it and offer a few useful comments?
You said, "Here's the study." There's isn't just *one* study, which you'd known if you'd stopped reflexively clicking the "Reply" button and kharma whoring before making even a modicum of effort. There are a whole pile of them spanning multiple decades.
Incorrect. They do *NOT* have to de-gas for three days. Depending on the bean and the drinker (that's you and me) the stuff ground and brewed even just a few hours post-roast can taste absolutely fantastic and has its own unique flavours to contribute. I'm not sure what your idea of horrid is, but perhaps the beans you're buying aren't so great or you're roasting them toolight or dark?
1. Buy high-quality, vetted green coffee beans either from a reputable local specialty roaster *who roasts their own beans either daily or every other day,* or from www.sweetmarias.com.
2. Roast your own beans. You can get away with a popcorn popper. I do. A small convection drum-roaster costs a few hundred but is worth it if you can control the temperature during the roast. A 6-12 hour resting period *exposed to the air* works well, but experimentation will give you best results since *EVERY* green coffee bean lot no matter what it's labelled is different. Even the same coffee growers from year to year can be drastically different. The length of time it stays in port affects it. What it's sitting next to at port will affect it. Let someone else worry about that stuff. STAY AWAY FROM SUPERMARKET COFFEE. Gross!
3. Grind your beans *only just the instant* prior to brewing. I use a burr hand-grinder. It's a Peuguot "Nostalgie". Lifetime guarantees rule. Zasserhaus also makes good hand-grinders. DO NOT USE whirly blade grinders. Those pulverise and powder.
4. Brew in as simple, and therefore cleanable, device as possible. French Press is popular in part because it's easy to keep the mechanism clean and it produces wild and tasty flavours. A vacuum brewer works, and I've heard great things about the AeroPress if you're impatient, want a filter, or have bad cholesterol.
5. Drink. Most of the coffee you brew this way actually tastes better with no cream nor sugar.
If you roast, grind, and brew as above, you will never be able to drink another Starbucks again. Every other cup of coffee you taste will be flat and boring at best, or vile on average, or revolting enough to make you gag at worst.
People who say they don't drink coffee--will drink your coffee. You will obsessively pursue the best green beans, and will begin opening up that gourmet side of yourself you never knew existed. The richness, the amazing quality, will absolutely blow you away.
Above all, EXPERIMENT. Apply a little scientific method, and keep logbooks. It's a great hobby too!
Did you just completely ignore my post? I suppose that's typical. Set up your straw man and knock em right back down again.
I said very specifically: "Michael Geist has already conclusively disproved the notion that even a significant fraction of piracy originates in Canada."
But I note that you didn't quote that part, because that's not what you were addressing. Instead, you went off on a completely different tangent. I didn't say Michael's numbers were perfect. I said he's disproved the notion that a significant fraction of *PIRACY* originates in Canada. I didn't mention Mr. Geist's specific "3%" number at all, actually. So, then, what precisely are you trying to disprove of my statement that doesn't still hold? After all, it addresses an issue you completely ignored! Let me spell it out more clearly: the MPAA is spreading lies about Canada. Michael Geist disproved them.
Additionally, your silly logic about the popularity of movies being somehow a factor in that 3% (by implication apparently suggesting that the 3% is *from* the most popular movies to begin with,) is preposterous. Evidence? Quotes?
The BBC article isn't very clear either (unfortunately:) "As of August 2006, the MPAA documented 179 camcorded movies as the source for infringing DVDs since 2004." We both know that many of those 179 are going to be overlapping: more than one camcording individual is going to be recording "300" from theatres in multiple locations, for example. All those people selling counterfeit copies aren't going to be cooperating as perfectly as you are suggesting!
Finally, you are quoting out of context (Ben Jonson would be frowning at you for that) by ignoring the fact that Michael states plainly later on in the same article: "I acknowledge that counterfeiting may be an issue, but argue that Henderson and the CACN have exaggerated the impact[.]"
P.S. Why would you expect me to read through the entirety of your comment history for the one reference to a 30% figure you derived in a completely different conversation thread? Now pay attention: click "Parent" and then click "Parent" again and once more. Where's the 30%? I don't see any mention of 30%.
If someone who by your description is not technically inclined can sit there and become a better web designer than you after reading a book or two, and by your review's splash it would appear that you are a formally trained techie, then you are not programming, nor are you a formally-trained techie.
Slashdot Mirror
He waffles back and forth, first cooperating, then not, then cooperating, then not. The Microsoft guy has the patience of the Buddha..! By the end of it, the dev is actually threatening to re-enable the Express support if Microsoft doesn't keep corresponding with him.
Whew.
Yes, I've read the entire exchange. And honestly it looks a lot like the dev is being a dick about it.
.. and now that I've watched the entire thing, start to finish, and wrote a near-complete transcript of it, Linus gets tonnes of things wrong. Oh Linus.. why did you have to begin spewing such diatribes about stuff you visibly know nothing about? Talking about Git is one thing, but then to claim that other products don't do the stuff git does? Sigh. I mean really.. narrowing down changesets to a single directory? Pulling a report of what's changed between two dates or two revisions, narrowed to a single directory or set of directories? Everyone can do that! And you went on for like.. two minutes about how tremendously powerful that ability was, claiming that you "guarantee" that no other system can do that.
Sooo disappointed at how little research you've done.
Oh well.
Uh.. it's a direct response to the original, which itself deviated from the Lina vs. Java VM of the post it was replying to.
I suppose a non-answer is enough for me. There's no point to Lina, and its limitations and restrictions on commercial use (insofar as they're willing to release actual details about it) make it a non-starter. They haven't even actually released it yet! It's slated for release in June 2007.
What they're doing right now is gauging interest by doing a press release with limited details. They claim it's been in development for four years, but honestly: a single video too small to make any informed opinion? Smells not only like vapourware, but free market research by Slashdot. I wonder who paid whom how much to get a (so far) vapourware product on the front page?
And what makes you think that yet another emulation layer in the form of a Lina host isn't more of a nightmare to retool your application to use? If you want a cross-platform GUI, QT works very nicely and you get natively-compiled applications that actually run at native speeds.
There's no mention of execution speed at the Lina website, and I'll take a wild stab at why: It slows things down to a crawl. Looks like it did in the video!
Erm.. it needs to be re-tooled to run under Lina anyway, and you have to pay them for commercial use?
And if I'm going to pay for anything cross-platform, why wouldn't I take advantage of native machine speeds and write a QT app?
How can they expect to bar commercial *use* of Lina when it's a GPL'd software product--unless their software must be embedded in the end executables?
Meanwhile, the video describing Lina is terrible. It shows (in a ridiculously puny window) two people installing an Apache-backed *WEB APPLICATION* onto two apparently different systems: a Linux machine and a Mac machine. What's the point of that when a PHP-backed application will do just as well and is nearly as simple use? (And what needed Lina? Apache? The web app itself? Both? Beats the hell out of me.)
There's no word on actual performance of Lina binary applications either, and while they claim additional "security," the reality is that complexity does NOT breed security, and Lina is yet another layer which must be maintained, secured, configured, and reconfigured.
Java already provides all or nearly all of this, and targetting development at Lina would be a massive re-tooling. It would also appear that the LINA PDF is internally inconsistent on the matter of whether legacy *binaries* or just legacy *apps* would run under a Lina host. I'll guess that everything must be recompiled specifically for Lina for it to work properly.
Quite frankly, once Java's GPL'd code is ported to the missing OSes it needs to be ported to, there will be no barrier to Java adoption anymore. Plus, commercial devs can still create independently-licensed Java applications without worrying about Lina demanding their cut for commercial development under Lina.
If Java's GPL then why do we need another Java?
Plus, I've been successfully spam-free for over 4 years.
.. that the article is glaringly absent *actual check-in times.* Or, where *actual check-in times* are available, the details of whether it's the same file as in previous tests is glaringly absent. This leaves open the question as to whether the data set they were working on was identical or whether it was different between the various tests.
.ODF typically stored in compressed form? If not, then small changes wouldn't necessarily affect the entirety of the file (as it would in a gzip file if the change were at the beginning) and SVN might be able to store the data very efficiently. Uncompressed PDF would certainly benefit.
Questions that remain:
1. Does the algorithm simply "plainly store" previously-compressed files, and is this the reason why that is the most time-efficient?
2. What exactly was the data for the *actual check-in* times? (What took 28m? What took 13m?)
3. Given that speedier/efficient check-in requires a large tarball format, how are artists supposed to incorporate this into their standard workflow? (Sure, there's a script for check-in, but the article is absent any details about actually using or checking-out the files thus stored except to say it's an unresolved problem regarding browsing files so stored.)
The amount of CPU required for binary diff calculation is pretty significant. For an artistic team that generates large volumes of binary data (much of it in the form of mpeg streams, large lossy-compressed jpeg files, and so forth) it would be interesting to find out what kind of gains a binary diff would provide, if any.
Document storage would also be an interesting and fairer test. Isn't
Okay that was funny. :-)
I'm just saying it's not a hard read. If you drink coffee you owe it to yourself to at least skim through it.
I post because I care.
About you. And all the other Slashdot readers.
Something better to do? You mean like actually reading the measly 29-page NIH overview about the available toxicology literature on the health effects of the stuff that millions of us drink every day before I post a link to it? Why yes. Yes I do.
Meanwhile, you still haven't identified which study you're talking about, so nobody knows what you're talking about. There are dozens of studies that show similar things, but it's not clear whether you mean one of those or the NIG *overview*. Which one specifically are you talking about?
They worked in the original transforming noise from the cartoons. :-)
Good enough for me! I'll be standing in line for this one.
Ssshhhh.. Don't tell anyone.
A subscription-based publication which the poster didn't say was necessary, and didn't even describe how to find. I.e. he didn't cite *which* study was involved. Therefore, the link is useless. Who amongst the readers of Slashdot even has these subscriptions?
If you consider 40 pages to be "lengthy" you've been on the Internet too long letting your attention span shrink. Also, it's not 40 pages, it's only 29 pages. It's 44 pages after you add in the bibliography, appendix, and table of contents. Why would the table of contents figure in your estimate of how abysmally long you think the review of toxicology is? You can just skip that stuff.
Honestly people, a few pages of PDF that you can simply run a find on, and people run screaming..?
Why even post at all if you're not going to at least read it and offer a few useful comments?
You said, "Here's the study." There's isn't just *one* study, which you'd known if you'd stopped reflexively clicking the "Reply" button and kharma whoring before making even a modicum of effort. There are a whole pile of them spanning multiple decades.
Sheesh.
Yargh! Boiled coffee has more cafestol and kahweol even than French pressed!! Something like twice as much. Time to get your cholesterol checked!! :-)
NIH's review of current toxicology reports on cafestol and kahweol describes, on pages 2, 9, 10, and 23:
NIH Toxicology Literature Review
Incorrect. They do *NOT* have to de-gas for three days. Depending on the bean and the drinker (that's you and me) the stuff ground and brewed even just a few hours post-roast can taste absolutely fantastic and has its own unique flavours to contribute. I'm not sure what your idea of horrid is, but perhaps the beans you're buying aren't so great or you're roasting them toolight or dark?
1. Buy high-quality, vetted green coffee beans either from a reputable local specialty roaster *who roasts their own beans either daily or every other day,* or from www.sweetmarias.com.
2. Roast your own beans. You can get away with a popcorn popper. I do. A small convection drum-roaster costs a few hundred but is worth it if you can control the temperature during the roast. A 6-12 hour resting period *exposed to the air* works well, but experimentation will give you best results since *EVERY* green coffee bean lot no matter what it's labelled is different. Even the same coffee growers from year to year can be drastically different. The length of time it stays in port affects it. What it's sitting next to at port will affect it. Let someone else worry about that stuff. STAY AWAY FROM SUPERMARKET COFFEE. Gross!
3. Grind your beans *only just the instant* prior to brewing. I use a burr hand-grinder. It's a Peuguot "Nostalgie". Lifetime guarantees rule. Zasserhaus also makes good hand-grinders. DO NOT USE whirly blade grinders. Those pulverise and powder.
4. Brew in as simple, and therefore cleanable, device as possible. French Press is popular in part because it's easy to keep the mechanism clean and it produces wild and tasty flavours. A vacuum brewer works, and I've heard great things about the AeroPress if you're impatient, want a filter, or have bad cholesterol.
5. Drink. Most of the coffee you brew this way actually tastes better with no cream nor sugar.
If you roast, grind, and brew as above, you will never be able to drink another Starbucks again. Every other cup of coffee you taste will be flat and boring at best, or vile on average, or revolting enough to make you gag at worst.
People who say they don't drink coffee--will drink your coffee. You will obsessively pursue the best green beans, and will begin opening up that gourmet side of yourself you never knew existed. The richness, the amazing quality, will absolutely blow you away.
Above all, EXPERIMENT. Apply a little scientific method, and keep logbooks. It's a great hobby too!
Why the heck is parent modded informative? The link doesn't take you to the study, it takes you to PubMed.
The "Lengthy Review" isn't anywhere near lengthy and is in fact merely a review of *available* toxicological studies about cafestol.
It's like he didn't even read what he's linking to! What the hell?
Did you just completely ignore my post? I suppose that's typical. Set up your straw man and knock em right back down again.
I said very specifically: "Michael Geist has already conclusively disproved the notion that even a significant fraction of piracy originates in Canada."
But I note that you didn't quote that part, because that's not what you were addressing. Instead, you went off on a completely different tangent. I didn't say Michael's numbers were perfect. I said he's disproved the notion that a significant fraction of *PIRACY* originates in Canada. I didn't mention Mr. Geist's specific "3%" number at all, actually. So, then, what precisely are you trying to disprove of my statement that doesn't still hold? After all, it addresses an issue you completely ignored! Let me spell it out more clearly: the MPAA is spreading lies about Canada. Michael Geist disproved them.
Additionally, your silly logic about the popularity of movies being somehow a factor in that 3% (by implication apparently suggesting that the 3% is *from* the most popular movies to begin with,) is preposterous. Evidence? Quotes?
The BBC article isn't very clear either (unfortunately:) "As of August 2006, the MPAA documented 179 camcorded movies as the source for infringing DVDs since 2004." We both know that many of those 179 are going to be overlapping: more than one camcording individual is going to be recording "300" from theatres in multiple locations, for example. All those people selling counterfeit copies aren't going to be cooperating as perfectly as you are suggesting!
Finally, you are quoting out of context (Ben Jonson would be frowning at you for that) by ignoring the fact that Michael states plainly later on in the same article: "I acknowledge that counterfeiting may be an issue, but argue that Henderson and the CACN have exaggerated the impact[.]"
P.S. Why would you expect me to read through the entirety of your comment history for the one reference to a 30% figure you derived in a completely different conversation thread? Now pay attention: click "Parent" and then click "Parent" again and once more. Where's the 30%? I don't see any mention of 30%.
You == still clueless. I win.
End of Line.
You == clueless. Michael Geist has already conclusively disproved the notion that even a significant fraction of piracy originates in Canada.
If someone who by your description is not technically inclined can sit there and become a better web designer than you after reading a book or two, and by your review's splash it would appear that you are a formally trained techie, then you are not programming, nor are you a formally-trained techie.
After all, Sykes does mean "shit-head" in Tenctonese.
.. and a bowl of cereal topped with fruit, berries, or nuts.
Finally found the answer:
s p#h1
http://www.sun.com/software/opensource/java/faq.j