I followed a previous comment's link to the MIT library services' page about owning the entire 18.*.*.* A block, then went poking around the American Registry of Internet Numbers website and, on their transfers page, found the following text:
"There is also a Transfers to Specified Recipients Policy to allow entities to monetize transfers of extra address space to specified recipients who qualify for the space."
"Monitization" of transfers? Sounds like the sale of IPV4 addresses is okay, at least those administered by the ARIN.
I don't argue that the cost-per-base of sequence is dropping dramatically - but comparing the output of an Illumina sequencer (the tens-of-thousands of dollars pricepoint) to the Human Genome Project is misleading. The reason the HGP cost so much is the quality of the reference sequence they produced - the so-called Bermuda standard, of one error in 10,000 bases. The HGP researchers assembled all those individual sequence reads into an almost unbroken reference of astounding quality and utility.
In comparison, the sequence data people are producing today is crap. The individual reads are 30-80 base pairs and get put together into contiguous runs of only several thousand bases of length, on average. This is good for some kinds of work, but it doesn't give nearly the same picture of the genome that made the original human genome sequence such a masterpiece.
It's a constant old-media gripe of mine. They linked back to the Nano Letters front page - how much harder would it have been to link straight to the article?
Yeah, the article just talks about the fabrication and characterization of the nanopores, and demonstrates that they can detect the translocation of single nucleotide pairs. If they had actually been able to identify the nucleotides, it would published somewhere bigger than Nano Letters.
It drives me nuts when the popular media article doesn't include a citation back to the original research. Here's a link to the article on the Nano Letters website:
http://pubs.acs.org/doi/full/10.1021/nl103873a
If there was a "standard" eBook format, then I would agree with you. As much as there is one, though, it seems to be the.mobi / mobipocket format - which the DX reads as well. Actually, the Amazon.azw format is just the the mobipocket format with a different extension and a single bit flipped in the header.
And then there's PDF support for full-page formatted documents, which works well (if subject to a few limitations as noted further up in the thread.) Frankly, I love my DX - it was expensive but I fully intend to get $500 of use out of it.
I use OpenDX regularly. I like how easy it is to implement arbitrary data manipulations without "programming", per se, and the graphics are pretty. I'm a big fan of R for serious statistics, but I think complex visualizations are easier to implement with OpenDX.
On the downside, you're stuck importing flat files (no DB access), and the interface is rather dated (Motif? Ugh.)
Well, it seems to me that this is an obvious pressure for residential routers to allow traffic prioritization using standard QoS protocols. I don't know about you, but my P2P traffic should always be low priority. What I'm saying is that I'd love to be able to specify that preference.
Whoa. There's a little ire in the above posts - obviously this isn't a popular thing.
I personally think this could be implemented in a manner that is "fair" to everyone involved. What I'd like to see is a tiered setup similar to that of the IgLou ISP: their DSL customers pay for a fixed amount (say 10 GB) of "high-priority" traffic, and the rest is de-prioritized to "bulk." Thus, a DSL subscription is truly "all-you-can-eat", but users with greater needs are encouraged to pay for what they're using.
I think this kind of scheme could work great if paired with a QoS setup on the end-user's part. What if I could prioritize my own traffic? (Not something I think IgLou lets its residential DSL customers do.) Then, you could de-prioritize P2P traffic and super-prioritize VoIP or shell traffic (maybe "pay" double?) -- everything runs more smoothly. The casual users' web-browsing speeds stay high, and the power users have an incentive to mark bulk traffic for what it is.
The book you want is titled "At the Bench" by Kathy Barker, (c) 1998 Cold Spring Harbor Press, ISBN 0-87969-523-4. (Here's an Amazon link.)
I'm a fourth-year graduate student, and this book has been invaluable - I wish I had it doing undergraduate research! It starts with chapters on general orientation, "what to expect" kind of things, notebook-keeping and organization (and it's nothing like what you did for highschool labs), experimental design, presentations and communication, etc. Then, it dives into practical instructions for making buffers, sterile technique, cell culture (eukaryotic and bacterial), manipulation of DNA/RNA/protein, radiation, microscopy, etc. In all likelihood, the actual lab's expectations will be a little different, but if you've looked over this book you won't be caught flat-footed.
Beyond this particular book, I'll reiterate something that has been said above: your best resource (to start with) is the other people in the lab. You will spend an entire month badgering others with "where is" and "how do I" questions. Don't worry about it, that's just the way it works. One caveat, though: when someone takes the time to demonstrate a technique or the operation of a piece of equipment to you, do them the courtesy of taking copious notes so that you won't have to ask them again. This serves to back up your memory of the procedure, and it impresses upon the senior lab members that you are interested and appreciative of what they have to tell you.
1) What is the usual failure rate for replication?
2) Do the letters routinely get published?
3) You just do that for work you're following up with experiments, not for everything you cite, right?
Unfortunately, I'm not in a hypothesis-driven lab, so I can't speak to any of these from direct experience. I know that I routinely see such letters published (frequently as "technical comments"), and I know that I go to seminars and routinely see people get raked over the coals for not having verified someone else's results. The only time you would do so, though, is for results on which your work depends directly.
Of course, there are perfectly valid reasons why that validation might fail, reasons that have nothing to do with someone being sloppy or deceitful. For example, many oft-used cell lines mutate as they are cultured, so your flask of MCF-7 breast cancer cells might not behave the same as the MCF-7 cells used across campus.
It's not just medical research. The scientific community works like any other community: the greater the implications, the greater the scrutiny, attempts to replicate, etc. The Huang embryonic stem cell study is a great case-in-point: the image-manipulation fraud was uncovered because of the vast number of researchers looking at the micrographs he published. (That sounds familiar, doesn't it: "Many eyes make all bugs shallow.") Global warming has many, many people working on models, taking ice cores, doing other analysis.
Of course, the vast majority of published research isn't reported in Science or Nature, and so it doesn't get as much exposure. That's why around here (the University of Wisconsin), it's standard practice that if your work depends on someone else's result, you first replicate her experiment and make sure you get the same result. (If you can't, you write a letter to the appropriate publication making note of your inability to replicate the result.) This means that eventually the mistake gets uncovered, and your research doesn't get burned because someone else has been sloppy.
Meh... I'm not so sure I agree. I don't think the best way to learn CVS is to read a book about CVS, but rather to puzzle through downloading a source tree, making a few changes, creating a diff, etc. There's no better incentive to learn how to use a tool than having a job you need to get done with it.
I remember the first time I had to extract a.tar.gz archive... the man page had me completely lost, and the GNU info pages weren't any better. But darn it, I had to get the archive open!
Certainly, there are a few exceptions (sendmail? autoconf?) where a good reference text makes a huge difference. But for "getting involved in Open Source development", I don't think B&N is the place to start.
Slashdot Mirror
"There is also a Transfers to Specified Recipients Policy to allow entities to monetize transfers of extra address space to specified recipients who qualify for the space."
"Monitization" of transfers? Sounds like the sale of IPV4 addresses is okay, at least those administered by the ARIN.
In comparison, the sequence data people are producing today is crap. The individual reads are 30-80 base pairs and get put together into contiguous runs of only several thousand bases of length, on average. This is good for some kinds of work, but it doesn't give nearly the same picture of the genome that made the original human genome sequence such a masterpiece.
(I'm a genomics grad student. Can you tell?)
It's a constant old-media gripe of mine. They linked back to the Nano Letters front page - how much harder would it have been to link straight to the article?
Yeah, the article just talks about the fabrication and characterization of the nanopores, and demonstrates that they can detect the translocation of single nucleotide pairs. If they had actually been able to identify the nucleotides, it would published somewhere bigger than Nano Letters.
It drives me nuts when the popular media article doesn't include a citation back to the original research. Here's a link to the article on the Nano Letters website: http://pubs.acs.org/doi/full/10.1021/nl103873a
If there was a "standard" eBook format, then I would agree with you. As much as there is one, though, it seems to be the .mobi / mobipocket format - which the DX reads as well. Actually, the Amazon .azw format is just the the mobipocket format with a different extension and a single bit flipped in the header.
And then there's PDF support for full-page formatted documents, which works well (if subject to a few limitations as noted further up in the thread.) Frankly, I love my DX - it was expensive but I fully intend to get $500 of use out of it.
I use OpenDX regularly. I like how easy it is to implement arbitrary data manipulations without "programming", per se, and the graphics are pretty. I'm a big fan of R for serious statistics, but I think complex visualizations are easier to implement with OpenDX. On the downside, you're stuck importing flat files (no DB access), and the interface is rather dated (Motif? Ugh.)
Well, it seems to me that this is an obvious pressure for residential routers to allow traffic prioritization using standard QoS protocols. I don't know about you, but my P2P traffic should always be low priority. What I'm saying is that I'd love to be able to specify that preference.
Whoa. There's a little ire in the above posts - obviously this isn't a popular thing.
I personally think this could be implemented in a manner that is "fair" to everyone involved. What I'd like to see is a tiered setup similar to that of the IgLou ISP: their DSL customers pay for a fixed amount (say 10 GB) of "high-priority" traffic, and the rest is de-prioritized to "bulk." Thus, a DSL subscription is truly "all-you-can-eat", but users with greater needs are encouraged to pay for what they're using.
I think this kind of scheme could work great if paired with a QoS setup on the end-user's part. What if I could prioritize my own traffic? (Not something I think IgLou lets its residential DSL customers do.) Then, you could de-prioritize P2P traffic and super-prioritize VoIP or shell traffic (maybe "pay" double?) -- everything runs more smoothly. The casual users' web-browsing speeds stay high, and the power users have an incentive to mark bulk traffic for what it is.
I'm a fourth-year graduate student, and this book has been invaluable - I wish I had it doing undergraduate research! It starts with chapters on general orientation, "what to expect" kind of things, notebook-keeping and organization (and it's nothing like what you did for highschool labs), experimental design, presentations and communication, etc. Then, it dives into practical instructions for making buffers, sterile technique, cell culture (eukaryotic and bacterial), manipulation of DNA/RNA/protein, radiation, microscopy, etc. In all likelihood, the actual lab's expectations will be a little different, but if you've looked over this book you won't be caught flat-footed.
Beyond this particular book, I'll reiterate something that has been said above: your best resource (to start with) is the other people in the lab. You will spend an entire month badgering others with "where is" and "how do I" questions. Don't worry about it, that's just the way it works. One caveat, though: when someone takes the time to demonstrate a technique or the operation of a piece of equipment to you, do them the courtesy of taking copious notes so that you won't have to ask them again. This serves to back up your memory of the procedure, and it impresses upon the senior lab members that you are interested and appreciative of what they have to tell you.
1) What is the usual failure rate for replication?
2) Do the letters routinely get published?
3) You just do that for work you're following up with experiments, not for everything you cite, right?
Unfortunately, I'm not in a hypothesis-driven lab, so I can't speak to any of these from direct experience. I know that I routinely see such letters published (frequently as "technical comments"), and I know that I go to seminars and routinely see people get raked over the coals for not having verified someone else's results. The only time you would do so, though, is for results on which your work depends directly.
Of course, there are perfectly valid reasons why that validation might fail, reasons that have nothing to do with someone being sloppy or deceitful. For example, many oft-used cell lines mutate as they are cultured, so your flask of MCF-7 breast cancer cells might not behave the same as the MCF-7 cells used across campus.
It's not just medical research. The scientific community works like any other community: the greater the implications, the greater the scrutiny, attempts to replicate, etc. The Huang embryonic stem cell study is a great case-in-point: the image-manipulation fraud was uncovered because of the vast number of researchers looking at the micrographs he published. (That sounds familiar, doesn't it: "Many eyes make all bugs shallow.") Global warming has many, many people working on models, taking ice cores, doing other analysis. Of course, the vast majority of published research isn't reported in Science or Nature, and so it doesn't get as much exposure. That's why around here (the University of Wisconsin), it's standard practice that if your work depends on someone else's result, you first replicate her experiment and make sure you get the same result. (If you can't, you write a letter to the appropriate publication making note of your inability to replicate the result.) This means that eventually the mistake gets uncovered, and your research doesn't get burned because someone else has been sloppy.
> If I remember right, one version of Excel also had a flight simulator.
Yep, Excel '97 had a flight sim.
- Hit 'F5'
- Jump to cell X97:L97
- Press 'TAB'
- Hold down and
- Press the "Chart Wizard" button on the toolbar.
I bet the graphics in this one are a little better, though.
Meh ... I'm not so sure I agree. I don't think the best way to learn CVS is to read a book about CVS, but rather to puzzle through downloading a source tree, making a few changes, creating a diff, etc. There's no better incentive to learn how to use a tool than having a job you need to get done with it.
.tar.gz archive ... the man page had me completely lost, and the GNU info pages weren't any better. But darn it, I had to get the archive open!
I remember the first time I had to extract a
Certainly, there are a few exceptions (sendmail? autoconf?) where a good reference text makes a huge difference. But for "getting involved in Open Source development", I don't think B&N is the place to start.