It occurs to me it may be possible to speed the actual processing part up by splitting the Gigapixel images up into ever smaller quadrants, treating them as textures, and using shaders to do the actual heavy lifting.
HAMR could increase the limit of magnetic recording by more than a factor of 100. This could result in storage capacities as great as 50 terabits per square inch.
* Seagate believes it can produce 300 terabit (37.5 terabyte) Hard disk drives using HAMR technology.[1] Some news sites reported that Seagate would launch a 300Tb HDD by 2010 but this is wrong. Seagate responded to this news stating that 50 terabit per-square-inch density is well past the 2010 timeframe and that this may also involve a combination of Bit Patterned Media.
It's not all about storage, though. This also requires a collosal amount of CPU-time, which makes Google a good fit: They know how to store and access massive amounts of data, and they know how to parallelise.
I saw a documentary not long ago about doing just this photographing of the same piece of sky, only with longer intervals than 30 seconds. Anything moving would automagically be flagged by the software, it's vector computed. Correct me if I'm wrong, but from what I can tell of this project, it's going to do exactly that (and more), but on a larger scope, and with better accuracy?
Will they be successful with helping scientists tag and catalog events in our universe? Will they defeat the monster and get the girl? And will they be home in time for tea? Find out next on GoogleTrek.
Seriously though, processing something the equivalent of 3/4th's of the LoC every night is nothing to be sneezed at. Over the course of those 10 years that's about 110 Petabyte (40TB * 365.25 * 10) of unprocessed data.
Just a thought... but if you were to write a VME bus driver and submit it for inclusion into the mainline kernel, wouldn't that solve your problem by virtue of being able to communicate with the stable API that driver exposes? That is if the VME bus is at all comparable to USB.
This just is not true at all. We have a whole sub-architecture that only has 2 users in the world out there. We have drivers that I know have only one user, as there was only one piece of hardware ever made for it. It just isn't true, we will take drivers for anything into our tree, as we really want it.
We want more drivers, no matter how "obscure", because it allows us to see patterns in the code, and realize how we could do things better. If we see a few drivers doing the same thing, we usually take that common code and move it into a shared piece of code, making the individual drivers smaller, and usually fixing things up nicer.
Possibly your situation is more of a legal problem than it is a technical one. If such a VME acquisition driver is technically feasible, as well as preferable to hacking against a moving target, that is.
Cue depends.exe to do just that, indeed. Some relatively well-known examples of using undocumented APIs are by Sysinternals, who were recently acquired by Microsoft:
Fundelete accomplishes this through the use of an undocumented API, ObOpenObjectByPointer ... The final step Fundelete performs is to convert the binary representation of the SID into a textual representation. Another undocumented API, RtlConvertSidToUnicodeString, performs this. ... Tokenmon relies on several undocumented SRM functions to obtain a logon ID from a thread's primary and impersonation tokens, and GetSecurityUserInfo, an undocumented function exported by the KSecDD (Kernel Security-support driver) that retrieves a logon session user's name, domain name, and logon server given a logon ID. Another interesting implementation detail is that several of the native API functions that Tokenmon hooks are not exported by ntoskrnl.exe for use by drivers. Thus, the Tokenmon GUI must reach into NTDLL.DLL, extract their system call numbers, and pass them to the driver.
This courtesy of the people who unearthed the Sony Rootkit, which goes to show it takes someone with knowledge of deeply intertwingled cruft to find it?
But more importantly: if ISVs behave in this way with limited knowledge of undocumented functions, how do you think Microsoft uses them?
Ultimately this will/has hurt Windows, as those programs targetting the undocumented APIs -where some MS apps get their features from- will require that hidden API to remain relatively static. And when problems are found in this undocumented API, either you leave the problem in place and work around it (and thereby leave the existing software using it potentially vulnerable), or you have to push an update for all those programs.
Maybe this is part of the reason why Linux's kernel has no fixed ABI?
And he already had a support structure in place as well, to make money off. Assuming users migrated away from Pegasus to other clients because of features that he couldn't provide as a single programmer, he may even make more money opening the source. Provided it's picked up by a community, of course.
Maybe the same people arguing for the.xxx TLD will grab porn.xxx to host a site about how 'porn corrupts your soul'*, and what not? Just on the odd chance people don't filter out all.xxx domains.
If you can figure what makes people buy anything to start with, you could make even more money running a marketing agency, with the added benefit of not having to remove BonziBuddy umpteen times a week.
The developer could use a bit of javascript to hide the submit button, show the wanted image. Then an OnClick event on the image submits the form as per usual. This way it'll also degrade properly when javascript is disabled, seeing as the non-image submit is defaulted to.
It occurs to me it may be possible to speed the actual processing part up by splitting the Gigapixel images up into ever smaller quadrants, treating them as textures, and using shaders to do the actual heavy lifting.
It's not all about storage, though. This also requires a collosal amount of CPU-time, which makes Google a good fit: They know how to store and access massive amounts of data, and they know how to parallelise.
I saw a documentary not long ago about doing just this photographing of the same piece of sky, only with longer intervals than 30 seconds. Anything moving would automagically be flagged by the software, it's vector computed. Correct me if I'm wrong, but from what I can tell of this project, it's going to do exactly that (and more), but on a larger scope, and with better accuracy?
Will they be successful with helping scientists tag and catalog events in our universe? Will they defeat the monster and get the girl? And will they be home in time for tea? Find out next on GoogleTrek.
Seriously though, processing something the equivalent of 3/4th's of the LoC every night is nothing to be sneezed at. Over the course of those 10 years that's about 110 Petabyte (40TB * 365.25 * 10) of unprocessed data.
Only because you didn't tilt your head and squint... doh!
I for one welcome our new (morally) bankrupt overlords, imagine a Beowulf cluster of those.
Kroah on obscure drivers not being accepted:Possibly your situation is more of a legal problem than it is a technical one. If such a VME acquisition driver is technically feasible, as well as preferable to hacking against a moving target, that is.
If you can violate laws of physics, you can make a whole lot more money than the entire MAFIAA combined.
This courtesy of the people who unearthed the Sony Rootkit, which goes to show it takes someone with knowledge of deeply intertwingled cruft to find it?
But more importantly: if ISVs behave in this way with limited knowledge of undocumented functions, how do you think Microsoft uses them?
Ultimately this will/has hurt Windows, as those programs targetting the undocumented APIs -where some MS apps get their features from- will require that hidden API to remain relatively static. And when problems are found in this undocumented API, either you leave the problem in place and work around it (and thereby leave the existing software using it potentially vulnerable), or you have to push an update for all those programs.
Maybe this is part of the reason why Linux's kernel has no fixed ABI?
Witness for yourself the l33t powers of Microsoft's wooing. Not exactly worrying, is it?
37signals seems to be just such a company.
Because whoever'd publish such a list would get hit with a defamation suit within the hour?
And he already had a support structure in place as well, to make money off. Assuming users migrated away from Pegasus to other clients because of features that he couldn't provide as a single programmer, he may even make more money opening the source. Provided it's picked up by a community, of course.
Does it run Linux?
Maybe the same people arguing for the .xxx TLD will grab porn.xxx to host a site about how 'porn corrupts your soul'*, and what not? Just on the odd chance people don't filter out all .xxx domains.
* Insert variant rhetoric where applicable.
If you can figure what makes people buy anything to start with, you could make even more money running a marketing agency, with the added benefit of not having to remove BonziBuddy umpteen times a week.
Ah, but on a quantum computer it's running and not running at the same time.
You may be on to something here. Once your box is a pile of smoking rubble from all that trashing, *nobody* will be able to pwn it.
Indeed, Embryo = Fertilised Egg, last I was taught biology.
I'm glad to see someone understood the underlying mechanism of my suggestion. ;)
Myself, I filter javascript, cookies, ads, flash, activex and so on at the firewall level for sites unknown.
Ever since Netcraft confirmed it.
The developer could use a bit of javascript to hide the submit button, show the wanted image. Then an OnClick event on the image submits the form as per usual. This way it'll also degrade properly when javascript is disabled, seeing as the non-image submit is defaulted to.
Daniel Cohen-Or manages something I consider far more interesting. Take for instance this PDF about image reconstruction.
There's quite a few more impressive papers on his page, for those interested in graphics.
Either that, or you end up seeing a 3D schooner.