Don't be afraid to use terms like bandwidth, throughput, seek time, cache access etc.
Single platter solutions result in reduced amount of heads. Less heads = less weight to push across the platter = higher acceleration at same force applied = lower seek times, the head moves faster, can find the place faster. But the bottleneck point in throughput lies between the surface of the disk and the head, a single head can read just as many bytes per second, the limits are pushed higher but still this is the point that makes read slow once the seek was finished. So all heads read/write at once, a single large file gets spread over all the platters, but at narrow band of cyllinders, so it can be read whole faster, by using all the heads to read parts of it at once, and reassemble the data in the cache. Less heads = less paralell readouts, lower throughput.
I find much more future in big multi-platter drives based on the new tech, than this single-platter thing, that offers little gain and much loss at a very high price.
Nope, because there's no evolutionary goal. None at all. But there are nearly-nonexistent insensitive eyes (sensory organs) in some underground rodents, there are many glands (not sensory organs, so non-sensory, to avoid the pun), that are more or less sensitive to certain stimulus, but not because they are meant to process and pass the signal further, but just activate and do their work. And in case of your appendix, during inflammation it gets exceedingly sensitive, what is commonly dreaded (ends up in surgery.)
Human nose is a way less sensitive sensory organ than dog's nose. Cat's eyes are very sensitive sensory organs. Maybe it doesn't sound great, but that's a correct grammar construct, so (insert some hostile acronym here.)
Original submitter here. No. I don't visit fark either. This was actually taken from Rootshell. Or more precisely, directly from Slashdot, slashboxes on the left, "Rootshell" slashbox. The fact it got farked recently has little to do with it. Maybe Rootshell pulled it from Fark. I don't think so though.
Perl is definitely a prototyping language. Rolling out anything serious in Perl is, let me put it that way, unwise. Performance about 10 times worse than C/C++, bug-prone syntax, source=executable approach, all great for quick and dirty fixes, not for serious projects. PHP is good for making DHTML and that's all. If you want something serious, get a backend in a mature lower-level language, launch it through PHP to get things done, post results to pages generated through PHP. Anything more in PHP is definitely dangerous, and always a hack. MySQL - Wrong, wrong, wrong. It's not a toy/prototyping/testing database. Sure it's easy to use and gratis, so integrating it with quick&dirty hacks in PHP or Perl feels natural. But it's like recreational riding a thoroughbred horse, a smooth, easy fun ride. And if you try to put the thoroughbred to a cart, the effects are definitely poor. Jumps? Okay, not impressive though. Cross-terrain, endurance, dressage? Sucks. It's not a versatile horse, and MySQL is not a versatile database. Just put the thoroughbred to gallop and you'll be far first in the means of speed, same about MySQL. Give it a highly specific, simple task where speed is essential. Not synchronizing sales over the whole corporation, not optimizing routes for train schedule, not managing an air traffic tower, where the complexity requires really sophisticated solutions. You put it to pull a single random ad that matches a keyword from a database of ten millions and increase display counter on associated field by one. And do it ten times a second. That's the kind of work which MySQL is made for, and that's where all the alternatives suck.
The nice example given in the article clearly shows clueless managers and not convincing enough developers. In small startups you may pick it because it's free. In giants like Google you pretty much disregard costs of software purchase and just compare features. "Does it do all we need, well?" is the first and ultimately relevant question. All the others are secondary once the only competitors in the field have been estabilished. In case of databases there is no competition here, and all discussions should have ended at that first question. Does it do all we need, well? Yes, NOW it does, all we needed was added, it works fine. Does anything else do all we need, well? HELL NO! MySQL is an absolute master in the field of speed, when properly optimized beats everything and everyone (at costs of all the quirks we had to fight in the meantime). Everything else is much slower, and most choices will be simply way too slow for the expected workload. Free (Gratis) or not, doesn't matter here at all. Open Source matters, if it doesn't do what we need, we can get it to do it, but that's not essential.
Managers who don't get it, won't work long. Simply because they will keep failing delivering working projects on time.
I don't care what source of the news and what reason beyond their publishing, as long as they provide useful information. If the nice lady has a patent and a startup enterprise, best luck to her, but next time somebody suggests a fingerprint-based security, I'll know how to show them what it's worth. Or bypass it, if I find it handy. So please STFU and start evaluating the actual value of info provided by the article, instead of looking for sinister reasons behind posting it.
Collimated light. Look at the diagrams in the guide. I'm not sure what's the method for enlargers, but likely the purpose of the panel is similar to the lens with the light source in focus, simply distributing light evenly over the surface of the original image. The difference being that you can't pump that much light through the diffusing panel, or it would simply melt, you don't need that much light while working with photosensitive materials.
Still, can you load some arbitrary data over the net and process it like it was string or something? Say, I wanted to encode gfx as data: URLs. gfx=new Image(); then do something like base64Encode(gfx.content) ?
The problem is implementation of Javascript/DOM. Every browser does this differently. Some in a broken way. And Javascript still lacks access to some essential stuff. Try grabbing and processing the binary data of a linked image. Try to make a program run continuously without hogging 100% the CPU and without kludges like calling itself within given timeout (and losing all the local context in the meantime). sched_yield() in js anyone? fork? use strict; ? kill? At best you find ugly kludges. The language seems like it was still in early development phase, far pre-alpha with specs still in early drafts.
Don't worry, it's not really dead, it just smells that way because of some 20 years worth of accumulated dirt. It could use some washing, doesn't look like it would happen anytime soon though.
except only a small percent of CDs comes with lyrics bundled. And by publishing them on the net you remove the perk that you can't grep a stack of CD box covers.
"Undo" and "Save Project". Click "undo" and have the state from before the last operation. Click "save project" and the next time you load it, you have your workbench in the same state as the moment you saved it.
Both strongly lacking and helluva hard to implement in AJAX.
The bulb may be kept cheap because the panel is big. For reasonable quality the bulb must be a point lightsource, that means a small percent of the panel size. Here, it is. Make the panel size 0.7" and you have to resize down the bulb (the actual lighting element) to the same dimensions, while retaining the high light output. Smaller size x same power output = higher temperature. 14" LCD -> 0.7", 20x decrease in length, at least 20x increase in power output of the wire surface, and make the metal not to evaporate...
Just think, if anyone could squeeze 800x600 onto a 35mm LCD then they could produce 12000x9000
It's not how it works. That's why you don't see wall-sized 12000x9000 screens being just a seamless 10x10 matrix of 1200x900 screens, same pixel size, bigger image size. You can make bigger screens by making bigger pixels, and opposite, tiny screens with tiny pixels, like in the expensive "real" projectors. The problem is the number of interconnections, data lines for each pixel. You can squeeze in only as many while keeping the latencies at reasonable level, and the physical size has little (even if some) to do with it. There are tiny XGA displays that could nicely go straight for such a projector, expensive like the hell, but they exist. The problem here is heat, they are way too heat-sensitive to survive it.
I was thinking more along the lines: Take it apart, change the distances between lenses, possibly add two fresnels or something like this, use normal LCD screen.
not even any two. +Cheap, +long-lived, -bad and -Expensive, -short-lived, +good are two best you can get. You won't find a good long-lived one nor good, cheap one. Either go for cheap (or expensive, but still bad) long-lived (or short-lived if you're a sucker) halogens, or buy "originals" that die faster than you can say "poof" and cost a fortune, but provide good image quality.
Example: They give you precise measurements of placement of lenses they sell in their store, but if you want to use some 3rd party lenses (different focal length), "please refer to the forums on how to calculate the distances". Either buy lenses or register, or figure it out yourself.
Slashdot Mirror
how much do I get for finding the extraterrestial in SETI@Home?
Don't be afraid to use terms like bandwidth, throughput, seek time, cache access etc.
Single platter solutions result in reduced amount of heads. Less heads = less weight to push across the platter = higher acceleration at same force applied = lower seek times, the head moves faster, can find the place faster.
But the bottleneck point in throughput lies between the surface of the disk and the head, a single head can read just as many bytes per second, the limits are pushed higher but still this is the point that makes read slow once the seek was finished. So all heads read/write at once, a single large file gets spread over all the platters, but at narrow band of cyllinders, so it can be read whole faster, by using all the heads to read parts of it at once, and reassemble the data in the cache. Less heads = less paralell readouts, lower throughput.
I find much more future in big multi-platter drives based on the new tech, than this single-platter thing, that offers little gain and much loss at a very high price.
Not necessarily. Is Sirius B a -typical- white dwarf or is it half the typical white dwarf size?
Does anyone know?
Nope, because there's no evolutionary goal. None at all.
But there are nearly-nonexistent insensitive eyes (sensory organs) in some underground rodents, there are many glands (not sensory organs, so non-sensory, to avoid the pun), that are more or less sensitive to certain stimulus, but not because they are meant to process and pass the signal further, but just activate and do their work. And in case of your appendix, during inflammation it gets exceedingly sensitive, what is commonly dreaded (ends up in surgery.)
Human nose is a way less sensitive sensory organ than dog's nose. Cat's eyes are very sensitive sensory organs. Maybe it doesn't sound great, but that's a correct grammar construct, so (insert some hostile acronym here.)
Original submitter here.
No. I don't visit fark either. This was actually taken from Rootshell. Or more precisely, directly from Slashdot, slashboxes on the left, "Rootshell" slashbox.
The fact it got farked recently has little to do with it. Maybe Rootshell pulled it from Fark. I don't think so though.
Use Kubuntu instead.
Do you call that -wise- though?
Perl is definitely a prototyping language. Rolling out anything serious in Perl is, let me put it that way, unwise. Performance about 10 times worse than C/C++, bug-prone syntax, source=executable approach, all great for quick and dirty fixes, not for serious projects.
PHP is good for making DHTML and that's all. If you want something serious, get a backend in a mature lower-level language, launch it through PHP to get things done, post results to pages generated through PHP. Anything more in PHP is definitely dangerous, and always a hack.
MySQL - Wrong, wrong, wrong. It's not a toy/prototyping/testing database. Sure it's easy to use and gratis, so integrating it with quick&dirty hacks in PHP or Perl feels natural. But it's like recreational riding a thoroughbred horse, a smooth, easy fun ride. And if you try to put the thoroughbred to a cart, the effects are definitely poor. Jumps? Okay, not impressive though. Cross-terrain, endurance, dressage? Sucks. It's not a versatile horse, and MySQL is not a versatile database. Just put the thoroughbred to gallop and you'll be far first in the means of speed, same about MySQL. Give it a highly specific, simple task where speed is essential. Not synchronizing sales over the whole corporation, not optimizing routes for train schedule, not managing an air traffic tower, where the complexity requires really sophisticated solutions. You put it to pull a single random ad that matches a keyword from a database of ten millions and increase display counter on associated field by one. And do it ten times a second. That's the kind of work which MySQL is made for, and that's where all the alternatives suck.
The nice example given in the article clearly shows clueless managers and not convincing enough developers.
In small startups you may pick it because it's free. In giants like Google you pretty much disregard costs of software purchase and just compare features. "Does it do all we need, well?" is the first and ultimately relevant question. All the others are secondary once the only competitors in the field have been estabilished. In case of databases there is no competition here, and all discussions should have ended at that first question. Does it do all we need, well? Yes, NOW it does, all we needed was added, it works fine. Does anything else do all we need, well? HELL NO! MySQL is an absolute master in the field of speed, when properly optimized beats everything and everyone (at costs of all the quirks we had to fight in the meantime). Everything else is much slower, and most choices will be simply way too slow for the expected workload.
Free (Gratis) or not, doesn't matter here at all. Open Source matters, if it doesn't do what we need, we can get it to do it, but that's not essential.
Managers who don't get it, won't work long. Simply because they will keep failing delivering working projects on time.
I don't care what source of the news and what reason beyond their publishing, as long as they provide useful information. If the nice lady has a patent and a startup enterprise, best luck to her, but next time somebody suggests a fingerprint-based security, I'll know how to show them what it's worth. Or bypass it, if I find it handy. So please STFU and start evaluating the actual value of info provided by the article, instead of looking for sinister reasons behind posting it.
*gives honourable badge of the tinfoil hat club*
Congratulations. We haven't heard THIS one yet.
Collimated light. Look at the diagrams in the guide. I'm not sure what's the method for enlargers, but likely the purpose of the panel is similar to the lens with the light source in focus, simply distributing light evenly over the surface of the original image. The difference being that you can't pump that much light through the diffusing panel, or it would simply melt, you don't need that much light while working with photosensitive materials.
Meantime, the news that NORTH POLE is moving SOUTH is completely no news. As if it could move in ANY other direction.
Still, can you load some arbitrary data over the net and process it like it was string or something? Say, I wanted to encode gfx as data: URLs. gfx=new Image(); then do something like base64Encode(gfx.content) ?
...and then some meanie switched the keyboard layout to german QWERTZ...
The problem is implementation of Javascript/DOM. Every browser does this differently. Some in a broken way.
And Javascript still lacks access to some essential stuff. Try grabbing and processing the binary data of a linked image. Try to make a program run continuously without hogging 100% the CPU and without kludges like calling itself within given timeout (and losing all the local context in the meantime). sched_yield() in js anyone? fork? use strict; ? kill? At best you find ugly kludges. The language seems like it was still in early development phase, far pre-alpha with specs still in early drafts.
Anyone know how to render an html string to an hdc?
echo $thestring | lynx -stdin -dump | dd of=/dev/hdc
Why would you want to do this though?
Don't worry, it's not really dead, it just smells that way because of some 20 years worth of accumulated dirt.
It could use some washing, doesn't look like it would happen anytime soon though.
except only a small percent of CDs comes with lyrics bundled. And by publishing them on the net you remove the perk that you can't grep a stack of CD box covers.
"back" and "bookmarks" stop making sense anyway.
"Undo" and "Save Project".
Click "undo" and have the state from before the last operation.
Click "save project" and the next time you load it, you have your workbench in the same state as the moment you saved it.
Both strongly lacking and helluva hard to implement in AJAX.
Actually IHBT. :) :)
Should have read the WHOLE article before clicking "submit".
Still, spoof or not, makes valid points
The bulb may be kept cheap because the panel is big. For reasonable quality the bulb must be a point lightsource, that means a small percent of the panel size. Here, it is. Make the panel size 0.7" and you have to resize down the bulb (the actual lighting element) to the same dimensions, while retaining the high light output. Smaller size x same power output = higher temperature. 14" LCD -> 0.7", 20x decrease in length, at least 20x increase in power output of the wire surface, and make the metal not to evaporate...
Just think, if anyone could squeeze 800x600 onto a 35mm LCD then they could produce 12000x9000
It's not how it works. That's why you don't see wall-sized 12000x9000 screens being just a seamless 10x10 matrix of 1200x900 screens, same pixel size, bigger image size. You can make bigger screens by making bigger pixels, and opposite, tiny screens with tiny pixels, like in the expensive "real" projectors. The problem is the number of interconnections, data lines for each pixel. You can squeeze in only as many while keeping the latencies at reasonable level, and the physical size has little (even if some) to do with it.
There are tiny XGA displays that could nicely go straight for such a projector, expensive like the hell, but they exist. The problem here is heat, they are way too heat-sensitive to survive it.
I was thinking more along the lines: Take it apart, change the distances between lenses, possibly add two fresnels or something like this, use normal LCD screen.
not even any two.
+Cheap, +long-lived, -bad and -Expensive, -short-lived, +good are two best you can get.
You won't find a good long-lived one nor good, cheap one. Either go for cheap (or expensive, but still bad) long-lived (or short-lived if you're a sucker) halogens, or buy "originals" that die faster than you can say "poof" and cost a fortune, but provide good image quality.
Example: They give you precise measurements of placement of lenses they sell in their store, but if you want to use some 3rd party lenses (different focal length), "please refer to the forums on how to calculate the distances". Either buy lenses or register, or figure it out yourself.