Yeah, it wasn't clear to me either how they'd get the MoS2 into the transistor channels either. To build such a thin structure suggests some sort of vapor deposition process if they were to commercialize it.
Digging through a couple of the links, I finally found what this experiment did in the supplemental information PDF. Their current method doesn't sound like it scales to building arbitrary chips yet:
Our device fabrication begins with scotch-tape based micromechanical cleavage of
commercially available, naturally occurring crystals of molybdenite (SPI supplies) using
the method previously developed for graphene fabrication. The scotch tape with
ultrathin crystals is pressed against the surface of a substrate composed of degenerately
doped Si with 270nm of SiO2. The substrate is imaged using an optical microscope
(Olympus BX51M) equipped with a color camera. Single layers of MoS2 are located with
respect to fiduciary markers. Monolayers can be easily identified by their optical contrast.
We have previously established the correlation between the optical contrast and thickness
as measured by AFM for a number of dichalcogenide materials, including MoS2. With
this method, we can produce cca 1-3 single layers per area of 1cm2.
If I interpreted that correctly, they're laying down MoS2 on the substrate with scotch tape, and then going back with a microscope and camera to figure out where they got the desired MoS2 monolayers in order to build their transistors. That works for an experiment, but I can't see that working in a fab.:-)
Ok, so I googled around and found this interesting report. It seems that molybdenum production has more or less kept pace with demand. It appears that the price remained high because demand was leading supply slightly. When demand fell behind supply, the price tanked.
The steep swing suggests that the annual production of molybdenum is fairly fixed (rather inelastic), at least for the time being. This suggests to me that you would probably have to find new mines or new extraction techniques (say from seawater?) to make the supply of molybdenum more elastic, and thus reduce the slope of the supply curve.
Well, according to Wikipedia, pure molybdenum was going for $30,000 a tonne in August 2009 and before that had shot up to $100,000 a tonne for several years. (That works out to $30 / kilo and $100 / kilo respectively.) I based my cost statement on the higher number on the basis that MoS2 semiconductors would increase the demand.
I guess that cost puts it on a par with silicon for bulk material cost. More expensive potentially, but not orders of magnitude more like I was thinking. The rest comes, as you say, from the processing required to turn it into a working processor. Since they're putting it into etched features on a SiO2 substrate, what sort of process are they using to get it there? I guess that's where the money maker is for this process.
Yeah, I missed that. I didn't see it in the article body, but it was obvious when I finally clicked on the image at the right so all the labels were readable.
Huh? Just like all the steel we produce somehow reduces the amount of iron plants and animals can make use of? Are you suggesting that a significant fraction of mined molybdenite goes to fertilizer manufacture?
Molybdenum may not be as abundant as silicon, but it's still fairly abundant. (54th most abundant in the crust and 25th most abundant in sea water, says Wikipedia.) And given its fairly high cost, I imagine any increased demand will be offset by its cost. This would limit molybdenum to niche applications where controlling leakage is a must. I imagine MoS2 based semiconductors would only be cost effective if they can figure out how to use as little of it as possible, perhaps with MoS2 over some other substrate.
I can think of much stupider things that we could do (and in fact are doing already), such as bottling water, or hyperfocusing food production on corn and subsidizing large quantities of corn-based ethanol production.
I can definitely the benefit of names pairs such as "Upload"/"Download" or "toServer/toClient" or "toServer/fromServer". Those all work when you've got a clear client/server orientation. But, if you're talking about more distributed situations where you have more of a peer orientation, those break down.
If you can name them separately in the client and in the server, why not use names that are meaningful to the local context? For example, the client's output stream goes to the server's input stream, and vice versa? You've got good precedent for that today in UNIXland with stdin and stdout. Consider a pipe: One side writes to its stdout, and the other side reads it from stdin. Seems perfectly logical to me.
I come in last night about half past ten,
That hydrogen wouldn't let me in.
So muon on over. Rock it on over.
Move over little atom, a mean, old atom's muon in.
I run VirtuaWin with Windows XP on my work laptop. Everything else is Linux or OS X. Sorry. I haven't tried Vista or Windows 7 yet, so I don't know what, if anything, might work well on either.
As for your sig..."Open Source is great. Unless, of course, you need a decent spreadsheet." How about Gnumeric? It works pretty well for what I use it for.
I wonder what font size people are getting that so many people are complaining that Slashdot's fonts are too small. The fonts I see here on the Slashdot page are larger than any other font on the screen currently (ie. for Firefox's menus, bookmarks, tab titles, status bar, etc...). Of course, I'm running at the miserly resolution of 1680x1050, so maybe I'm behind the curve on PPI?
Why wouldn't I? I've got 4 (or 6) virtual desktops. (And before you cry "But that's Linux!", you can do that on Windows and MacOS X too. I run virtual desktops on all three platforms.) I tend to maximize every application that benefits from it on its own desktop. Web browser, PDF readers, PowerPoint, FrameMaker, Visio, whatever. The only windows that stay narrow are terminal sessions, so I can fit three across, and IM, so that it fits next to the terminal sessions. Hotkeying between desktops is way faster than mousing or Alt-Tab-ing.
With everything maximized, it gets easier and faster to navigate to often-used elements such as scroll bars (always at the right edge), menus (always a fixed delta from the top edge), tool bars (fixed delta from top edge), etc. Fitts' Law suggests I'm doing the right thing for my productivity.
I've actually leaned on both volumes 2 and 3. The discussions about floating point and number systems are very useful in Volume 2. The sorting and searching networks in Volume 3 are must-have reading if you're trying to do complex sorting functions on highly parallel machines. (Think median filters, for an example, particularly in the context of sub-word SIMD.)
I read the first couple draft fascicles for Volume 4A, and see a bunch in there I can directly apply to other work I do, such as exhaustively evaluating portions of a larger search space. Also, some of the Boolean logic properties are very interesting.
Fun fact: It turns out that during the exact same month (March 2007?), both Knuth and I attacked essentially the same problem. We both set out to find minimal instruction sequences to implement all Boolean functions of 5 variables. I didn't find this out until well after the fact, while hunting through his website looking for a new Volume 4 fascicle. We actually had fairly similar results, but his approach was far more elegant (naturally). Also, mine was constrained to tree-like sequences and a specific target instruction set, whereas his permitted any DAG and used more generic Boolean operations. (For example, I had a "not-and" operation which does "A and not B", whereas I don't think he did.) Still, it was rather amusing to see we had both tackled the same problem at about the same time, and came up with similar overall results.
In perl-speak, a Cassandra table sounds suspiciously like a nested hash if Cassandra's rows and columns are unsorted, or an array of array of key-value pairs if they are sorted.
And if I understood the brief description of the use model from the article someone else linked, it sounds like you make a new table (columnfamily?) for each of the different criteria you might query against. The index for that table would be the parameterized bits of that query, and the other columns represent all the data that would match that particular query. Their example showed indexing employees by DOB.
If i had a more complex query (say "all employees of a particular gender and date of birth"), then the index column would contain both details, so there'd be a row for "Feb 31st, 2013, Male," "Feb 31st, 2013, Female," etc. Am I understanding this correctly?
Sounds like it'd be total crap (read: next to, if not completely impossible to use for) fully ad hoc queries whose structure isn't known beforehand. But, if you were building up something that had fairly static parameterized query structures, then it'd work out pretty well. The main thing to remember is that it transforms a pull-oriented SQL-style datamining operation into a more push-oriented "sort it as it arrives" structure.
Cookies have to be sent with every web request in the domain of the cookie. Store too much in that and the cost of making requests goes way up. There could be good reasons to store a lot of information locally on one's hard drive (imagine, your email inbox, for example) that you don't wish to communicate back to the web server with every click, but perhaps do want to make available to scripts running locally (such as the mail software). Make sense?
How can you be in two places at once when you're not anywhere at all*?
Antelope Freeway, one half mile
Antelope Freeway, quarter mile
Free Armenia, get a hairlip!
Antelope Freeway, one eighth mile
Shallow Valley Condoms: If you lived here, you'd be home by now!
Antelope Freeway, one sixteenth mile
18 Holes Underground Parking
Antelope Freeway, one thirty-second mile
Slashdot Mirror
That's crazy! How can you read anything from them if your computer goes off line? Paper tape is the only way to fly.
Mod parent up! Also, rather appropriate username for the topic.
I was thinking hearing aids and pacemakers might see this long before smartphones, for example.
Yeah, it wasn't clear to me either how they'd get the MoS2 into the transistor channels either. To build such a thin structure suggests some sort of vapor deposition process if they were to commercialize it.
Digging through a couple of the links, I finally found what this experiment did in the supplemental information PDF. Their current method doesn't sound like it scales to building arbitrary chips yet:
If I interpreted that correctly, they're laying down MoS2 on the substrate with scotch tape, and then going back with a microscope and camera to figure out where they got the desired MoS2 monolayers in order to build their transistors. That works for an experiment, but I can't see that working in a fab. :-)
Ok, so I googled around and found this interesting report. It seems that molybdenum production has more or less kept pace with demand. It appears that the price remained high because demand was leading supply slightly. When demand fell behind supply, the price tanked.
The report has more detailed insights. Enjoy!
The spot price of molybdenum was over twice its current price for around 5 years (from ~2004 - 2009). Given that the drop coincided with the recent economic meltdown, it doesn't seem like a huge leap to suggest that that drop is a direct result of reduced demand
The steep swing suggests that the annual production of molybdenum is fairly fixed (rather inelastic), at least for the time being. This suggests to me that you would probably have to find new mines or new extraction techniques (say from seawater?) to make the supply of molybdenum more elastic, and thus reduce the slope of the supply curve.
Well, according to Wikipedia, pure molybdenum was going for $30,000 a tonne in August 2009 and before that had shot up to $100,000 a tonne for several years. (That works out to $30 / kilo and $100 / kilo respectively.) I based my cost statement on the higher number on the basis that MoS2 semiconductors would increase the demand.
I guess that cost puts it on a par with silicon for bulk material cost. More expensive potentially, but not orders of magnitude more like I was thinking. The rest comes, as you say, from the processing required to turn it into a working processor. Since they're putting it into etched features on a SiO2 substrate, what sort of process are they using to get it there? I guess that's where the money maker is for this process.
Yeah, I missed that. I didn't see it in the article body, but it was obvious when I finally clicked on the image at the right so all the labels were readable.
And actually, it appears that MoS2 over a silicon substrate is exactly what they're proposing. I knew I should have looked at the blowup first.
According to Wikipedia, Molybdenite is the mineral form of molybdenum disulphide.
Huh? Just like all the steel we produce somehow reduces the amount of iron plants and animals can make use of? Are you suggesting that a significant fraction of mined molybdenite goes to fertilizer manufacture?
Molybdenum may not be as abundant as silicon, but it's still fairly abundant. (54th most abundant in the crust and 25th most abundant in sea water, says Wikipedia.) And given its fairly high cost, I imagine any increased demand will be offset by its cost. This would limit molybdenum to niche applications where controlling leakage is a must. I imagine MoS2 based semiconductors would only be cost effective if they can figure out how to use as little of it as possible, perhaps with MoS2 over some other substrate.
I can think of much stupider things that we could do (and in fact are doing already), such as bottling water, or hyperfocusing food production on corn and subsidizing large quantities of corn-based ethanol production.
I can definitely the benefit of names pairs such as "Upload"/"Download" or "toServer/toClient" or "toServer/fromServer". Those all work when you've got a clear client/server orientation. But, if you're talking about more distributed situations where you have more of a peer orientation, those break down.
If you can name them separately in the client and in the server, why not use names that are meaningful to the local context? For example, the client's output stream goes to the server's input stream, and vice versa? You've got good precedent for that today in UNIXland with stdin and stdout. Consider a pipe: One side writes to its stdout, and the other side reads it from stdin. Seems perfectly logical to me.
I come in last night about half past ten,
That hydrogen wouldn't let me in.
So muon on over. Rock it on over.
Move over little atom, a mean, old atom's muon in.
I run VirtuaWin with Windows XP on my work laptop. Everything else is Linux or OS X. Sorry. I haven't tried Vista or Windows 7 yet, so I don't know what, if anything, might work well on either.
As for your sig..."Open Source is great. Unless, of course, you need a decent spreadsheet." How about Gnumeric? It works pretty well for what I use it for.
I wonder what font size people are getting that so many people are complaining that Slashdot's fonts are too small. The fonts I see here on the Slashdot page are larger than any other font on the screen currently (ie. for Firefox's menus, bookmarks, tab titles, status bar, etc...). Of course, I'm running at the miserly resolution of 1680x1050, so maybe I'm behind the curve on PPI?
Why wouldn't I? I've got 4 (or 6) virtual desktops. (And before you cry "But that's Linux!", you can do that on Windows and MacOS X too. I run virtual desktops on all three platforms.) I tend to maximize every application that benefits from it on its own desktop. Web browser, PDF readers, PowerPoint, FrameMaker, Visio, whatever. The only windows that stay narrow are terminal sessions, so I can fit three across, and IM, so that it fits next to the terminal sessions. Hotkeying between desktops is way faster than mousing or Alt-Tab-ing.
With everything maximized, it gets easier and faster to navigate to often-used elements such as scroll bars (always at the right edge), menus (always a fixed delta from the top edge), tool bars (fixed delta from top edge), etc. Fitts' Law suggests I'm doing the right thing for my productivity.
Memory breakthrough *I* was working on... Ah well... back to the drawing board.
The memory breakthrough was working on had the speed of flash and the volatility of DRAM. It was pretty dense though...
I've actually leaned on both volumes 2 and 3. The discussions about floating point and number systems are very useful in Volume 2. The sorting and searching networks in Volume 3 are must-have reading if you're trying to do complex sorting functions on highly parallel machines. (Think median filters, for an example, particularly in the context of sub-word SIMD.)
I read the first couple draft fascicles for Volume 4A, and see a bunch in there I can directly apply to other work I do, such as exhaustively evaluating portions of a larger search space. Also, some of the Boolean logic properties are very interesting.
Fun fact: It turns out that during the exact same month (March 2007?), both Knuth and I attacked essentially the same problem. We both set out to find minimal instruction sequences to implement all Boolean functions of 5 variables. I didn't find this out until well after the fact, while hunting through his website looking for a new Volume 4 fascicle. We actually had fairly similar results, but his approach was far more elegant (naturally). Also, mine was constrained to tree-like sequences and a specific target instruction set, whereas his permitted any DAG and used more generic Boolean operations. (For example, I had a "not-and" operation which does "A and not B", whereas I don't think he did.) Still, it was rather amusing to see we had both tackled the same problem at about the same time, and came up with similar overall results.
Ooooh, ouch.
In perl-speak, a Cassandra table sounds suspiciously like a nested hash if Cassandra's rows and columns are unsorted, or an array of array of key-value pairs if they are sorted.
And if I understood the brief description of the use model from the article someone else linked, it sounds like you make a new table (columnfamily?) for each of the different criteria you might query against. The index for that table would be the parameterized bits of that query, and the other columns represent all the data that would match that particular query. Their example showed indexing employees by DOB.
If i had a more complex query (say "all employees of a particular gender and date of birth"), then the index column would contain both details, so there'd be a row for "Feb 31st, 2013, Male," "Feb 31st, 2013, Female," etc. Am I understanding this correctly?
Sounds like it'd be total crap (read: next to, if not completely impossible to use for) fully ad hoc queries whose structure isn't known beforehand. But, if you were building up something that had fairly static parameterized query structures, then it'd work out pretty well. The main thing to remember is that it transforms a pull-oriented SQL-style datamining operation into a more push-oriented "sort it as it arrives" structure.
Cookies have to be sent with every web request in the domain of the cookie. Store too much in that and the cost of making requests goes way up. There could be good reasons to store a lot of information locally on one's hard drive (imagine, your email inbox, for example) that you don't wish to communicate back to the web server with every click, but perhaps do want to make available to scripts running locally (such as the mail software). Make sense?
Well, maybe you need to find a better Ford dealer then.
"Melanie Hayber. . ." "Melanie Hayber?" ." "Audrey Farber?" ." "Oh! You mean Nancy!"
"Audrey Farber. .
"Betty Jo Bieloski. .
Antelope Freeway, one half mile
Antelope Freeway, quarter mile
Free Armenia, get a hairlip!
Antelope Freeway, one eighth mile
Shallow Valley Condoms: If you lived here, you'd be home by now!
Antelope Freeway, one sixteenth mile
18 Holes Underground Parking
Antelope Freeway, one thirty-second mile
(or something like that...)