Back in 2006, Yahoo bought JumpCut. I met some of the JumpCut founders shortly after the acquisition, and they were hopeful at the time, because they we being rebranded as "Yahoo Video".
Other than the implementation of ads, that doesn't different significantly from what they had 8 years ago. Why did it take this long?
You missed something critical posted by the AC. He said you have to assign a unique prime number to each user. Not simply a number. The 30 millionith prime is 573259391. The 50 millionith prime is 982451653. I couldn't find the 60 millionith prime anywhere, and another 20M should be enough room for the corporations. In either case ceil(log2(573259391)) == ceil(log2(982451653)) == 30. The beauty of this is you can multiply two large primes, take the modulo and somebody with the primes can still verify/extract them later: This isn't very different from doing RSA crypto with very short primes...
Look for a used LTO3/LTO4 tape drive, then bulk-buy tapes. Write each set of content to two tapes, ideally of different brands, and store in different places if you're really concerned.
I've been backing up to LTO3 tapes for ~3 years now, i've got 50+ tapes, mostly in my safety deposit box at the bank (cost $75/year)
LTO4 based on eBay prices right now would be an initial expenditure of ~$1k for the drive, and $25-30 per 800GB of storage.
The cloud options aren't really feasible for me, as the upload time & bandwidth cost is horrendous.
I have the original WiSpy model, from when they first hit the market, and I still use it extensively.
It's been insanely useful in tracing the problems, just put it on a laptop, with a long USB extension cable, and wander around. I will admit that I've only used it on Linux, as I don't have any Windows around, but it's been perfectly suited to my needs.
A friend of mine was having a similar interference problem, during a subset of hours, and I traced it to one of the neighbours that would prepared dinner while using a set of wireless headphones.
Yeah, we had a Summer of Code project that did a full-scale review of it before. It's just gaining the traction needed now, and convincing folks that they don't need partial subtree checkouts really.
For anybody interested on this in Gentoo, I have updated my GLEPs about signing the portage tree to include a Gentoo-specific solution for this, by distributing a copy of the top-level signatures by a trusted system: http://robbat2.livejournal.com/226512.html
Formatting of data It's ~24600 rows (746 pages) of what must be pilot data.
The first 746 pages are Flight Hours (A1), Flight Legs (A2), and would be how many of each the pilot has undertaken, in the last N years.
The next 746 pages are Career Hours (A8), this is also sorted, so I think it was the key they used.
The last 746 pages are percentage and plane-type breakdown per pilot. It mainly seems to be the larger jets, but there are a few interesting smaller, older aircraft, couple of fighters, and business jets.
However, what is lacking from this data is actual accident report and statistics. We've only got pilot information here.
That 6-port on PCI-e x4 is a good card, I had only seen a 4-port previously, thanks for pointing it out.
However to reach the OP's goal of 40 ports, he needs 7 x4 slots available using those 6-port cards. I'm not aware of any system that provides that many lanes in such a configuration (Not that you couldn't build one, there are definetly 32-lane and 48-lane chips out there). It might be possible to get a pair of x16 -> (4)x4 convertors in an external box (still in the engineering sample state, but definetly in the pipeline from at least one company).
If you aren't deterred by this: 1. Get a motherboard. 2. Get a decent PCI backplane. A quick Google search brings this company: http://www.commell.com.tw/Product/Peripheral/Backp lane/backplane.HTM and they have a backplane with 17 PCI slots. 3. Buy 4-port PCI 100mbit network cards (http://www.americanpredator.com they don't list it on their site, but I'm certain they do custom quad port cards, or can point you to somebody that can, $500/card for industrial grade hardware). 4. 17*4 = 68x 100Mbit ethernet ports.
that's actually a very interesting, esp that you could make the LEDs flash (actually a dim-bright transfer, possibly using reed encoding, but never turning off totally) with an encoded number, and thus allowing them to be identified quickly by software after an occlusion event.
The primary reason for lots of cameras is still the occlusion problem. I agree that if you are only capturing one person at a time that the problem is reasonably reduced, but it still exists (consider the pose of bending over to touch your toes, which greatly occludes your front surface).
The figure pose stuff I have dealt with as well - using early and recent versions of Credo Interactive's "LifeForms" and the mocap input form they take. It's good for helping to solve occlusion by predicting which location a ball belongs to, but still has issues.
The kinetics/kinematics is the intrinsic source data of the figure poses, again mistaken identity is still bad (consider rotating your figure faster than the refresh on your cameras).
silhouette fails with multiple subjects and shadows.
cameras are cheap now - the ones I was pointing at are under $100 each. you could probably arrange $50 each if you were to buy a bulk set. Assuming my coding time is $25/hour (below my current wage), buying 4 more cameras is a better use of my money than coding.
Couple of things in here, from researching the field with a university research lab to see about buying commercial gear, I have a lot of suggestions.
- For your camera, look for cheap used DV cameras on ebay. Not super high res, but lots of them 3 ain't going to cut it, consider at least 9 (high/low from each of the cardinal directions, and on top [might want a few for different sectors]) - occlusion is an absolute bitch of a problem. - This will provide reliable time-synced data, and NOT max out your USB bus. - USB cannot provide you with images from 3 cameras with the same timesync, it's just not capable of such behavior. - Firewire has a longer length limit on the cables, which is a big help for your work.
- Cheap PCI firewire cards - two should be enough, this will give you 6 seperate firewire busses, and put you at the limit of your PCI bus. - Find filters that fit said cameras, and are opaque to visible light, but transparent to infrared. - Rig up really bright infra-red lighting, ideally with a low quantity of visible light output. - Go to an burgler alarm supply place, and buy infra-red reflective tape - I leart this tip from the EA guys a couple of years back, the 'official' reflective tape from 3M costs too much, and is a pain to order, but alarm places stock stuff that works even better, and is cheaper to boot. - Buy really small polystrene balls, and cover with infra-red tape. On one small part of the ball, put the hook side of a velcro dot. These are reusable now, avoiding problem with tape waste. You can also clean them easily to keep them very reflective. - For your subjects, get them to wear any clothing that velcro will hook reliably onto (pretty easy choice) - Place the reflective balls on either side of every joint, spaced not more than 90 degrees apart - eg your elbow should have 8 balls.
Using infra-red helps reduce the data-set size way down, and also lets you use the cameras in monochrome for capturing, greatly reducing the data-set size.
From working with several commercial mocap rigs, I'll say that the calibration routines are extremely important. You need to accurately map the entire volume that you wish to capture in. Depending on space available to you, consider building a simple frame or using a lighting rig to attach the cameras to.
I will repeat again, occlusion is an absolute killer problem. From visting the EA facilities in Burnaby BC to specifically research their systems (I was working with a university research lab at the time), they estimated that they lost 2 hours of production a day to occlusion problems during mocap shoots. Your system must be capable of tracking all the balls, all of the time. If it loses one, it's almost impossible to pick it up again properly during a runtime - you'd need to recode the relative location of that ball before it gave you useful data again.
Zipties are an interesting idea, except for the fact that you need to have some way of cutting them - which tends to get packed inside the suitcase you are marking with zipties, because you can't take it in carry-on.
I personally will not be flying again until electronic devices, books and food/water are allowed. 90% of my flights tend to be international, and there is NO way I'm sitting on a plane for 8-14 hours with nothing to do (I struggle to sleep on planes, and they wouldn't let you take over-the-counter sleeping pills anyway with the medication restrictions).
There's a few routes that all fit under your description.
The first and most obvious one, is an well-standardized API for using the card. This isn't new, in fact for 2D stuff, it's ancient news. The standard is VESA VBE (video bios extensions), with it's lesser known cousin VESA VBE-AF (video bios extensions - acceleration functions). The VBE standard itself was legally free. The VBE-AF interface was only available as a commercial specification, with distribution restrictions - but copies of the information do exist.
While 2D is reasonable simple, doing a similar thing for 3D isn't trivially, because of how different cards are internally. The major downside for manufacters is that they need to include silicon that can convert from the standardized form (say OpenGL) to what their hardware actually uses, and this raises production and development costs. If they leave out the standardized API from the silicon, and instead provide software drivers that convert from the standardized form to the internal format. When they find glitches, they can update the software much easier, and the other major advantage is that production costs are reduced (less silicon), providing better profits.
Next you might suggest a firmware based approach, similar to some of the current generations of wireless hardware. Without their firmware, they are not capable of doing anything. Internally they are generally a CPU (such as ARM or MIPS with some hardware acceleration for wireless stuff). This direct approach would prevent you from being able to see your BIOS or system firmware, as you need a system to load the firmware, and you can't install a machine without seeing what's going on. (Circular loop).
A hybrid approach might work instead: - Existing ATI/Nvidia chips, wired to an embedded processor, with both a default boot ROM which provides a firmware containing basic 2D and character mode only, and you can upload a newer firmware with 3D support to the embedded processor. You'd upload the 3D firmware every time you boot the system, just like present wireless gear.
In cost of parts, doing this would raise production costs $30-$50 per graphics card. Initial development would be a nasty hump as well for the large players Nvidia/ATI - because they presently just add new chips to the existing drivers, but after the initial development, things would be reasonable.
The hybrid approach has been done by one company before... SGI! Their systems booted with basic 2D, and later pushed firmware into the graphics controllers, that allowed you to send a variant of raw OpenGL to the controller (It was a variant in that some of the complex operations had to be broken down into simpler ones). If SGI consider selling their OpenGL IP as suggested previously on slashdot, such an approach MAY be feasible for the company that buys it.
And one comment that applys to both the Airaya and Redline gear. Due to the frequencies and power in use, do NOT stand in front of the units for longer than 20 seconds when they are powered on. You will get the most severe pounding migraine-level headache you have ever experienced.
I previously worked for a Metro-level ISP, that had their network between approx 20 buildings using wireless gear. Our preferred short distance solution was from Airaya - http://www.airaya.com/products/p2p.asp We used the AI108-4958-O model mainly. It comes with (50,150 or 300ft) of external grade CAT5e attached to the sealed unit. Mount that sealed unit on the building or a tripod mount ($100USD in Home Depot and RadioShack parts for a decent DIY tripod). Run the CAT5e into one of your roof access areas (look at the top of elevator shafts, there should be airways that are usable). Put the POE injector there. From there, run normal CAT5e to your switch gear.
The Airaya units are rated to 108Mbps (realistically we did 30-80Mbps usable IP depending on distance and interferance), no additional license is needed for the spectrum, and they are well designed and NEMA outdoor rated. Not sure what the current price is, they were dropping a lot during the time that I used them, but probablly $1200USD/pair.
Since you say you have multiple buildings, you should look at some of their other gear - the most we ever did was three units in a set (two slave sites pointing to one master, and sending their traffic via the master if they needed to talk).
One of your other high-end solutions is Redline http://www.redlinecommunications.com./ We used a single AN-100 unit for a long-distance haul (~10km), got a reasonable 60Mbps out of it. Cost wise it's not a nice number, and they refuse to sell it to you unless you get a certified installer to handle it.
"So, if coal (being 70-80% carbon) has little effect, then I fail to see how a bit of dust can." Coal is already mostly carbon by your own admission, and has a reasonably high ignitation point, but it also explosive when the atmospheric dust concentration Dust on the other hand catches fire a lot easier - I've had a case fire from not cleaning out before, and it's not a pretty sight to see your home fileserver have (but my uptime was 700+ days at the time) - now I clean my boxes a lot more reguarlly, incl. cleaning the fileserver while it's still online (just watch out for the fan blades, 7000rpm fans cut fingers really well!).
Slashdot Mirror
Back in 2006, Yahoo bought JumpCut. I met some of the JumpCut founders shortly after the acquisition, and they were hopeful at the time, because they we being rebranded as "Yahoo Video".
Other than the implementation of ads, that doesn't different significantly from what they had 8 years ago. Why did it take this long?
You missed something critical posted by the AC. He said you have to assign a unique prime number to each user. Not simply a number.
The 30 millionith prime is 573259391. The 50 millionith prime is 982451653. I couldn't find the 60 millionith prime anywhere, and another 20M should be enough room for the corporations. In either case ceil(log2(573259391)) == ceil(log2(982451653)) == 30. The beauty of this is you can multiply two large primes, take the modulo and somebody with the primes can still verify/extract them later: This isn't very different from doing RSA crypto with very short primes...
Look for a used LTO3/LTO4 tape drive, then bulk-buy tapes.
Write each set of content to two tapes, ideally of different brands, and store in different places if you're really concerned.
I've been backing up to LTO3 tapes for ~3 years now, i've got 50+ tapes, mostly in my safety deposit box at the bank (cost $75/year)
LTO4 based on eBay prices right now would be an initial expenditure of ~$1k for the drive, and $25-30 per 800GB of storage.
The cloud options aren't really feasible for me, as the upload time & bandwidth cost is horrendous.
http://dev.gentoo.org/~tove/stats/gentoo-x86/cvs-log-sum.txt
I'm number 20 on that list, having recently surpassed 10k commits to Gentoo myself (in 7 years). The top of our list is somebody with 70k commits.
- robbat2@gentoo
I use the Watt's Up Pro, but it's for monitoring a single outlet.
Do you intend to monitor your entire house, or just some devices?
I have the original WiSpy model, from when they first hit the market, and I still use it extensively.
It's been insanely useful in tracing the problems, just put it on a laptop, with a long USB extension cable, and wander around. I will admit that I've only used it on Linux, as I don't have any Windows around, but it's been perfectly suited to my needs.
A friend of mine was having a similar interference problem, during a subset of hours, and I traced it to one of the neighbours that would prepared dinner while using a set of wireless headphones.
Very worthwhile, for both the strategy and melee modes.
And if they are marginally movie-geek, here's another reason why:
http://www.titaniumrings.com/AbyssDVD.html
My wife's engagement ring, plus our wedding bands are Titanium:
http://titaniumrings.com/
Yeah, we had a Summer of Code project that did a full-scale review of it before. It's just gaining the traction needed now, and convincing folks that they don't need partial subtree checkouts really.
For anybody interested on this in Gentoo, I have updated my GLEPs about signing the portage tree to include a Gentoo-specific solution for this, by distributing a copy of the top-level signatures by a trusted system:
http://robbat2.livejournal.com/226512.html
There are new MIPS stages however under /experimental/. Go and bug the MIPS team if you want a CD as well.
Postgres v8.3 yes:
http://packages.gentoo.org/package/postgresql
KDE v4 no (not outside the KDE overlay)
http://packages.gentoo.org/package/kde-meta
OpenOffice 2.4 yes
http://packages.gentoo.org/package/openoffice
Formatting of data
It's ~24600 rows (746 pages) of what must be pilot data.
The first 746 pages are Flight Hours (A1), Flight Legs (A2), and would be how many of each the pilot has undertaken, in the last N years.
The next 746 pages are Career Hours (A8), this is also sorted, so I think it was the key they used.
The last 746 pages are percentage and plane-type breakdown per pilot.
It mainly seems to be the larger jets, but there are a few interesting smaller, older aircraft, couple of fighters, and business jets.
However, what is lacking from this data is actual accident report and statistics. We've only got pilot information here.
That 6-port on PCI-e x4 is a good card, I had only seen a 4-port previously, thanks for pointing it out.
However to reach the OP's goal of 40 ports, he needs 7 x4 slots available using those 6-port cards. I'm not aware of any system that provides that many lanes in such a configuration (Not that you couldn't build one, there are definetly 32-lane and 48-lane chips out there). It might be possible to get a pair of x16 -> (4)x4 convertors in an external box (still in the engineering sample state, but definetly in the pipeline from at least one company).
Limitations:
p lane/backplane.HTM
- PCI bus bandwidth is going to hurt you hard. 32-bit PCI @ 33Mhz = 127Mbyte/sec. 64-bit PCI-X @ 66Mhz = 508Mbyte/sec.
- 100Mbit ethernet = ~10Mbyte/sec (assume 10b8 encoding, easier numbers).
- 127Mbyte/sec / ~10Mbyte/sec = 12 100Mbit ports only.
If you aren't deterred by this:
1. Get a motherboard.
2. Get a decent PCI backplane. A quick Google search brings this company:
http://www.commell.com.tw/Product/Peripheral/Back
and they have a backplane with 17 PCI slots.
3. Buy 4-port PCI 100mbit network cards (http://www.americanpredator.com they don't list it on their site, but I'm certain they do custom quad port cards, or can point you to somebody that can, $500/card for industrial grade hardware).
4. 17*4 = 68x 100Mbit ethernet ports.
that's actually a very interesting, esp that you could make the LEDs flash (actually a dim-bright transfer, possibly using reed encoding, but never turning off totally) with an encoded number, and thus allowing them to be identified quickly by software after an occlusion event.
The primary reason for lots of cameras is still the occlusion problem. I agree that if you are only capturing one person at a time that the problem is reasonably reduced, but it still exists (consider the pose of bending over to touch your toes, which greatly occludes your front surface).
The figure pose stuff I have dealt with as well - using early and recent versions of Credo Interactive's "LifeForms" and the mocap input form they take. It's good for helping to solve occlusion by predicting which location a ball belongs to, but still has issues.
The kinetics/kinematics is the intrinsic source data of the figure poses, again mistaken identity is still bad (consider rotating your figure faster than the refresh on your cameras).
silhouette fails with multiple subjects and shadows.
cameras are cheap now - the ones I was pointing at are under $100 each. you could probably arrange $50 each if you were to buy a bulk set.
Assuming my coding time is $25/hour (below my current wage), buying 4 more cameras is a better use of my money than coding.
Couple of things in here, from researching the field with a university research lab to see about buying commercial gear, I have a lot of suggestions.
- For your camera, look for cheap used DV cameras on ebay. Not super high res, but lots of them 3 ain't going to cut it, consider at least 9 (high/low from each of the cardinal directions, and on top [might want a few for different sectors]) - occlusion is an absolute bitch of a problem.
- This will provide reliable time-synced data, and NOT max out your USB bus.
- USB cannot provide you with images from 3 cameras with the same timesync, it's just not capable of such behavior.
- Firewire has a longer length limit on the cables, which is a big help for your work.
- Cheap PCI firewire cards - two should be enough, this will give you 6 seperate firewire busses, and put you at the limit of your PCI bus.
- Find filters that fit said cameras, and are opaque to visible light, but transparent to infrared.
- Rig up really bright infra-red lighting, ideally with a low quantity of visible light output.
- Go to an burgler alarm supply place, and buy infra-red reflective tape - I leart this tip from the EA guys a couple of years back, the 'official' reflective tape from 3M costs too much, and is a pain to order, but alarm places stock stuff that works even better, and is cheaper to boot.
- Buy really small polystrene balls, and cover with infra-red tape. On one small part of the ball, put the hook side of a velcro dot. These are reusable now, avoiding problem with tape waste. You can also clean them easily to keep them very reflective.
- For your subjects, get them to wear any clothing that velcro will hook reliably onto (pretty easy choice)
- Place the reflective balls on either side of every joint, spaced not more than 90 degrees apart - eg your elbow should have 8 balls.
Using infra-red helps reduce the data-set size way down, and also lets you use the cameras in monochrome for capturing, greatly reducing the data-set size.
From working with several commercial mocap rigs, I'll say that the calibration routines are extremely important. You need to accurately map the entire volume that you wish to capture in. Depending on space available to you, consider building a simple frame or using a lighting rig to attach the cameras to.
I will repeat again, occlusion is an absolute killer problem. From visting the EA facilities in Burnaby BC to specifically research their systems (I was working with a university research lab at the time), they estimated that they lost 2 hours of production a day to occlusion problems during mocap shoots.
Your system must be capable of tracking all the balls, all of the time. If it loses one, it's almost impossible to pick it up again properly during a runtime - you'd need to recode the relative location of that ball before it gave you useful data again.
Zipties are an interesting idea, except for the fact that you need to have some way of cutting them - which tends to get packed inside the suitcase you are marking with zipties, because you can't take it in carry-on.
I personally will not be flying again until electronic devices, books and food/water are allowed. 90% of my flights tend to be international, and there is NO way I'm sitting on a plane for 8-14 hours with nothing to do (I struggle to sleep on planes, and they wouldn't let you take over-the-counter sleeping pills anyway with the medication restrictions).
There's a few routes that all fit under your description.
The first and most obvious one, is an well-standardized API for using the card.
This isn't new, in fact for 2D stuff, it's ancient news. The standard is VESA VBE (video bios extensions), with it's lesser known cousin VESA VBE-AF (video bios extensions - acceleration functions). The VBE standard itself was legally free. The VBE-AF interface was only available as a commercial specification, with distribution restrictions - but copies of the information do exist.
While 2D is reasonable simple, doing a similar thing for 3D isn't trivially, because of how different cards are internally.
The major downside for manufacters is that they need to include silicon that can convert from the standardized form (say OpenGL) to what their hardware actually uses, and this raises production and development costs. If they leave out the standardized API from the silicon, and instead provide software drivers that convert from the standardized form to the internal format. When they find glitches, they can update the software much easier, and the other major advantage is that production costs are reduced (less silicon), providing better profits.
Next you might suggest a firmware based approach, similar to some of the current generations of wireless hardware. Without their firmware, they are not capable of doing anything. Internally they are generally a CPU (such as ARM or MIPS with some hardware acceleration for wireless stuff). This direct approach would prevent you from being able to see your BIOS or system firmware, as you need a system to load the firmware, and you can't install a machine without seeing what's going on. (Circular loop).
A hybrid approach might work instead:
- Existing ATI/Nvidia chips, wired to an embedded processor, with both a default boot ROM which provides a firmware containing basic 2D and character mode only, and you can upload a newer firmware with 3D support to the embedded processor.
You'd upload the 3D firmware every time you boot the system, just like present wireless gear.
In cost of parts, doing this would raise production costs $30-$50 per graphics card. Initial development would be a nasty hump as well for the large players Nvidia/ATI - because they presently just add new chips to the existing drivers, but after the initial development, things would be reasonable.
The hybrid approach has been done by one company before...
SGI! Their systems booted with basic 2D, and later pushed firmware into the graphics controllers, that allowed you to send a variant of raw OpenGL to the controller (It was a variant in that some of the complex operations had to be broken down into simpler ones).
If SGI consider selling their OpenGL IP as suggested previously on slashdot, such an approach MAY be feasible for the company that buys it.
And one comment that applys to both the Airaya and Redline gear.
Due to the frequencies and power in use, do NOT stand in front of the units for longer than 20 seconds when they are powered on. You will get the most severe pounding migraine-level headache you have ever experienced.
I previously worked for a Metro-level ISP, that had their network between approx 20 buildings using wireless gear.
Our preferred short distance solution was from Airaya - http://www.airaya.com/products/p2p.asp
We used the AI108-4958-O model mainly. It comes with (50,150 or 300ft) of external grade CAT5e attached to the sealed unit.
Mount that sealed unit on the building or a tripod mount ($100USD in Home Depot and RadioShack parts for a decent DIY tripod). Run the CAT5e into one of your roof access areas (look at the top of elevator shafts, there should be airways that are usable). Put the POE injector there. From there, run normal CAT5e to your switch gear.
The Airaya units are rated to 108Mbps (realistically we did 30-80Mbps usable IP depending on distance and interferance), no additional license is needed for the spectrum, and they are well designed and NEMA outdoor rated. Not sure what the current price is, they were dropping a lot during the time that I used them, but probablly $1200USD/pair.
Since you say you have multiple buildings, you should look at some of their other gear - the most we ever did was three units in a set (two slave sites pointing to one master, and sending their traffic via the master if they needed to talk).
One of your other high-end solutions is Redline http://www.redlinecommunications.com./ We used a single AN-100 unit for a long-distance haul (~10km), got a reasonable 60Mbps out of it. Cost wise it's not a nice number, and they refuse to sell it to you unless you get a certified installer to handle it.
"So, if coal (being 70-80% carbon) has little effect, then I fail to see how a bit of dust can."
Coal is already mostly carbon by your own admission, and has a reasonably high ignitation point, but it also explosive when the atmospheric dust concentration
Dust on the other hand catches fire a lot easier - I've had a case fire from not cleaning out before, and it's not a pretty sight to see your home fileserver have (but my uptime was 700+ days at the time) - now I clean my boxes a lot more reguarlly, incl. cleaning the fileserver while it's still online (just watch out for the fan blades, 7000rpm fans cut fingers really well!).
He's got pointy hair, and he's my boss. What more of PHB do you need?
His method is just to mess around with things until they work (and break a few other things along the way sometimes).