Not every project needs an upper limit, but some certainly do. A friend of mine did the 3Doodler kickstarter and it also wound up unexpectedly successful. (Blew through the original goal in the first few hours, and wound up making a few million dollars at the end of the 30 day campaign.) When they sold out of the planned first batch, there was a bit of a scramble to estimate how quickly a second batch could be made, how big it should be, etc. But, they didn't change the design of the product, so they were basically scalable by pushing delivery deadlines for successive batches out. Of course, the risk is if you have underestimated a per unit cost that would have become obvious after the first batch, you are still locked in to deliver subsequent batches at whatever price you got for them. If you sold the first batch, and then did a re-analysis of how best to do the second batch, it's possible that things could be done better.
When you pitch in for something like a Kickstarter project, making a guess of how well the people will handle the scaling is just a part of what you have to estimate. If there isn't a history of successful delivery of similar projects, you have to deal with the likelihood that your investment won't pan out. If there is a history of it, you still have to deal with the possibility. That's what happens when you spend money on something that doesn't exist.
That said, the game devs should absolutely stick to making an initial delivery before worrying about stretch goals. I have never seen a significant game project come in ahead of schedule or under budget. Ever. I've been starting some indie game dev stuff on my own time recently, and just getting a crappy game out the door really is a shocking amount of work. Getting a good game out the door is an almost inconceivable amount of work, and getting exactly the game of your dreams out the door is simply impossible. Considering that the original planned budget of the game was such a small percentage of the ultimate take, they could have just done the original game as a "practice run" to give something to the players and then used whatever was left as the budget for the bigger fancier sequel.
The age cutoff is arbitrary. But when we do not treat it as inviolate, then we do us all a disservice. In practical terms, minors have no rights, and thus should have less responsibility. That is, they should never be tried as an adult, under any circumstances. It is always their parents' responsibility if their upbringing comes out wrong.
In the inner city, tons of young kids get adult sentences for being involved in the drug trade. So, it is already far from an inviolate already. There is a disproportionate portion of young people convicted as adults who are racial minorities, so that's another big issue with the legal system at present. But, it's silly to say that not being mature enough to automatically be trusted to sign your own contracts inherently means that you should be excused for rape.
IMO, the way it should work is that everything is recorded, and made publicly available after, say, 7 days. In that time, and officer can request that something specific be witheld from the public record. the process would basically be the same as a warrant, where the officer would go to a judge, who would review the footage and would sign off on the redaction. If the footage came up in a court case, it would be possible to petition to get it unsealed. This would cover all sorts of situations. A bust of a child pornographer might involve several minutes of child porn, for example, and you probably wouldn't want to publish that, given the point of bothering to arrest the child porn publisher. Likewise, you might want to protect a source or informant, which could be pretty broadly defined to include 'potential sources,' which would cover shopkeepers who don't want to be specifically on record as being friendly with the cops, but who the cops want to interact with and establish a relationship that may be useful to exploit in the future.
Besides, once there is a year of footage being recorded every day, it may not matter much if you get recorded talking to the cops. Your enemies will have to invest a massive labor force to find footage of you making off color jokes by watching all of it. (Unless the government successfully makes some awesome public facing database for finding this stuff, but in reality they would just hand half a billion dollars to a vendor, wait five years, and then declare failure on a project like that which a startup could have working reasonably well in a few weeks...)
ajax.googleapis.com isn't a tracking domain and your IP shouldn't be in any emails you send unless you run your own mail server.
Erm, that seems like a bit of a failure of imagination. Why wouldn't that be a "tracking domain?" Do you have some specific proof that it's somehow impossible for Google to use normal logging functionality on the web server for that domain? And that this will be true forever? Obviously, the idea that any particular domain can't be used for tracking is just silly. So, if google knows you visited the manufacturer's website, why couldn't they use that for ad tailoring when you log into gmail to send an email? Or anywhere else that you get a Google served ad, for that matter...
I'm not amazingly paranoid about this stuff, but to seriously dismiss the possibility of doing these things is just silly.
It's a good idea because magstrips are easy to erase and contacts are easy to destroy. It's unfortunate that this implementation is so crap, but that doesn't invalidate the concept.
I'm sorry, but no. The concept of contactless payment is just inherently broken. It's really obviously, blatantly, completely invalid. Making it possible for me to pay from a distance wirelessly without having to do anything specific with the payment card/source/token, means that I can be robbed without noticing it. It just takes a big antenna hidden in a backpack, or stuffed under a coat, or in a car. No matter how much you clamp down on the concept, you just require the guy robbing me to have a slightly bigger antenna.
If I absolutely had to design something like this, there would be a requirement for contact even if the data had to go over a wireless channel. Tap your conductive card on the metal plate to send a wakeup signal to the radio, or something similar. No moving parts, no requirements for the contact payment accepting device to keep the contact in pristine condition. Easy.
Well, if you had to cite a source, but all you had was your own recollection that you had heard the word, 'Meanderings of Memory' is pretty much the perfect name for it. It's even possible that within the community of people working on it, it was a well understood practice. Like giving a directing credit to Alan Smithee for a film. (For a guy who never existed, he sure was prolific!)
Related to this, ultimately what matters is the business plan. That will imply a few things...
1 - Why is this algorithm better than what's out there? 2 - Why can't anybody else do what this does? (Patents, at least.) 3 - Why you can't make money with it now, and how you will make money with it if they invest.
Frankly, without a lot more information, I'd be highly skeptical about investing in a video processing algorithm. Are you trying to productize it? Investing in product development is a very different matter from investing in an algorithm inside of a potential product. Are you going to try to license the technology? Why can't you do that without venture capital? It's fairly cheap to call Sony and try to convince them to buy the technology to stuff in their next cameras. Having a bunch more money won't make that a much easier sell.
You dont need a CNC mill. Let me guess, you think you need a supercomputer to write iphone apps? You can make a gun with rudimentary tools that are in many people's garages. How do you think gun smiths in the 1800's did things? You think they fired up their CNC mill and had their horse program the computer to start cutting?
No, but I do think they did it with a lot more skill and time than it would take me to push a button on a box I just picked up at Staples. And, with a less strict landlord than mine. If I had a workshop and the time to learn the skills, it would be awesome. But, in an urban apartment I will never learn how to make a gun by hand no matter how low-tech the process may be. And if I did, I'd never be sure if I got one wrong until I tried it and I checked to see if it blew up when I fired it. When it's a purely automated system making the parts, you can have a lot of confidence in the consistency.
I agree with your point, but would perhaps add a few extra bullet points.
#4. Where they already are. Tons of young coders started writing software for whatever type of computer was available in the living room rather than any rational assesment of which platform had the best dev tools. Tons of people will be handed blackberries by their corporate overlords, and have an itch to scratch. Those people already have full time jobs, so they won't be as prolific as full time mobile developers, but a lot of useful things have been generated by soembody who just wanted to scratch an itch.
#5. Where the competition is light. If the BB10 market turns out to be 1/10 the size of the iOS market, but has less than 1/10 of the developer focus, there may still be money to be made in that market.
#6. Where there are users. A couple of whiny users asking for their platform to be supported is sometimes enough to justify developer time. Especially for things like messaging applications, you want to be everywhere so that all the friends of your potential customer will also be able to get the app and interact with them. I buy multiplayer video games on things like Steam primarily because they support cross platform multiplayer. They don't have to be that great of games, as long as I know my couple of friends who have only OS-X will be able to play with the group.
These may all be relatively small factors for BB10, but it isn't quite dead yet. Just sort of pining for the fjords a bit...
My understanding is that there will indeed be something like RWX control. Not just for security, but also for performance. If boths ides can freely write to a chunk of memory, you can get into difficulties accounting for caches in a fast way.
That said, if the CPU and the GPU are basically sharing an MMU, then the GPU may be restricted from accessing pages that belong to process that aren't being rendered/computed. There's no reason why two different applications should be able to clobber each other's texture memory if they do something stupid. So, having the GPU share pointers with the CPU is potentially a very good thing for security. (How well AMD implements the concept in practice remains to be seen, but I'm optimistic.)
Because when you are doing stuff like OpenCL, dispatching from CPU space to GPU space has a huge overhead. The GPU may be 100x better at doing a problem than the CPU, but it takes so long to transfer data over to the GPU and set things up that it may still be faster to do it on the CPU. It's basically the same argument that led to the FPU being moved onto the same chip as the CPU a generation ago. There was a time when the FPU was a completely separate chip,a nd there were valid reasons why it ought to be. But, moving it on chip was ultimately a huge performance win. The idea behind AMD's strategy is basically to move the GPU so close to the CPU that you use it as freely as we currently use the FPU.
The way the system is set up, the government has to know something exists to be able to askfor it. It may sound slightly silly at first blush, but it's actually quite important. Imagine that a drug dealer is being prosecuted. They have sworn testimony that "yes, that hard drive has a list of drug suppliers called drugsuppliers.doc." from an employee. Failing to share the file is withholding evidence that the government knows exists. On the orher hand, if cops start going door to door to check everybody's computer for anything bad, they don't know what they are looking for. Forcing you to grant access 'just in case' would be a horrible violation. In this case, the judge is saying that the prosecution is just on a fishing trip. There might not even be anything specific to the case on that drive. There might be incredibly horrible evidence that makes this case even bigger. But in any case, the government needs some evidence ro start dismantling a person's life. They can't do it just on the possibility that they may potentially find some evidence.
You end up with unmaintainable code, late deadlines and an environment where numerous employees want to kill each other. Profit? Good luck.
It doesn't matter how talented the asshole is if he\she costs more than they're worth. I'd rather have a few mediocre developers who are nice to each other, write to spec, comment appropriately, and write code that anyone can understand and maintain.
Indeed, hiring an asshole rarely survives a really thorough cost benefit analysis. Unfortunately, the people who hire assholes never seem to take into account the potentially far reaching effects that one epic ass can have on a company. Even people who never have to interact with that person have to deal with the people who do, and the morale impact can be far reaching. I'm sure there are some rare cases where an absolute ass is unarguably the right person for a job, but these cases are few and far between. If there are any objections to be made, the long run cost is generally not worth the trouble.
(Recently had my asshole quotient expanded at the office. Have basically become completely ambivalent about the job. If they convince me to resign, they are losing one of the more qualified people in the US in a very narrow niche that I fill.)
It's kind of a nit pick, but Boston is often assumed to be larger than it is. It's kind of famous and 'important.' But, it doesn't make it on this page of "largest cities on earth:"
This is why. And this is because they don't understand copyright law and don't realize that unless they explicitly put the code into the public domain or apply a license, no one can touch it without violating copyright law.
It's probably a mixture of that and outright laziness.
Is this actually a really big deal? Given the massive number of repositories which probably contain nothing of great consequence, is anybody ever going to really need to fork more than 15% of what is on GitHub? And if they do, in most cases they can just ask the author for a license.
And, not being able to 'touch' may not matter if the author just intended for people to look. It doesn't really matter if something is GPL, proprietary or BSD if all I want is to see an example of how somebody used an obscure and poorly documented API. There are tons of libraries where a working example is worth a thousand apidoc pages that just give terse statements about functions in isolation.
Yeah, there are probably a lot of people who don't understand copyright and either think that they can use something because it is on github, or think that they don't need to pick a license for people to use their code. Most people are stupid. News at 11:00.
Dell is trying to say, "calm down, let's find a point midway that makes us all happy before this bidding war gets out of control." Who knows if that will work, but the likely endgame in all scenarios is that Dell the company will be destroyed.
Which is kind of a shame. Dell actually has some nice products. (Lots of terrible ones as well...) They are almost at the point where I would seriously consider a very large scale storage solution from Dell. (Think many hundreds of TB SAN) They have been acquiring some interesting storage companies and doing good integration work. Given that Isilon and BlueArc are currently both trying to kick their customers in the nuts, there is a good opportunity for Dell in the Datacenter.
Almost nobody does real 'Beowulf' style clusters anymore, if you use a very precise definition, but in the broader sense this would be a compute cluster. I haven't studied the details of the proposal, but I'm not sure why this would ne revolutionary. Using a cluster for rendering video is pretty common. Burn clusters are used with Autodesk Smoke. Smoke used to be quite obscure but now that it exists on Mac it is seeing pretty wide use. From what I understand, Vegas has network rendering as well. Outside of strict 'editing' and into video comp and color, tons of people use things like Nuke and After Effects on a farm and Baselight uses a cluster. So, the idea isn't really revolutionary. It all boils down to whether or not the implementation is good or not, how it gets used, and wether or not it actually makes my life better.
Distributed processing for video editing is quite tricky. Unless you are doing a lot of fancy effects (which tends to happen in something like Smoke, but as far as I know Openshot has less in the way of professional finishing effects. Some of this would include cheesy stuff like lens flares. Most o it would be stuff like tracked stabilisation and degraining which can be quite slow) actually coming up with a video frame isn't that CPU intensive. When doing ordinary cuts only editing, you just have to seek to the frame in a video file, and decide the frame. For a proper editing format like ProRes, this is about as CPU intensive as decoding a JPEG. For interactive editing, that's pretty much it. Schlepping video frames across the network for that is a huge waste. If the remote system doesn't have the right codec installed, you are sunk. As your timeline gets more CPU intensive, you get more of a payoff for having Extra CPUs to throw at the problem over a relatively high latency and low bandwidth link. Figuring out exactly what to farm out and when is a nontrivial task and it won't be possible to come up with a system that works well for all possible use cases.
Anyhow, I wish them luck. Hopefully they come up with a feature set that matches their users needs. I may have to check out a current version. Last time I played with it, OpenShot wasn't really my cup of tea, but it is always good to see somebody getting support from the community to scratch an itch.
On the subject of working with a big network, and the sort of creative influence that levels of executives can have on a project... Can you please start this interview with a fist fight?
(A probably too obscure reference to the start of the B5 spinoff show, Crusade.)
Or, to put it a bit more seriously, given that you have had frustrations with the role that networks have played on some of your previous projects, how do you see the creative process changing as time moves forward and technology changes the nature of distribution? What do you see as an end-game for these trends moving forward?
To be fair, if somebody tried to sell something as locked down as the iPad is during the period when IBM first released the PS/2, it would have also flopped. The market has changed a lot since the 1980's. People who seriously upgrade their desktop are a rather small fraction of the total market for programmable things with CPU's.
Unfortunately, you still need two separate deep images. One for each eye. Things like specular highlights and reflections shift around depending on the viewer's position, so generating a second view froom the deep data doesn't actually look right. There are some cases where it'll work fine, but it's not universally true.
Does an n-core, n-processor, or n-whatever computer running for 1 hour count as 1 compute-hour or n? Or some other number altogether?
Given the public relationsy nature of the number, assume they are going with whatever sounds biggest to the marketing guys, which would probably mean core-hours rather than machine-hours. That is to say, a two socket machine with 4 cores per socket can do 8 core-hours of calculations per hour of wall-clock time.
No idea how much this was used on this particular film, but for the record, deep images don't save disk space. They churn through it like nobody's business! The idea is driven around storing many samples per pixel instead of just one, so you have a *lot* more data than with a normal "shallow" render and compositing pipeline. It is extremely useful for some thing, but it costs so much in terms of resources that it is still not in wide use yet. On the film Battleship, ILM used a deep image pipeline, but they only did it on a handful of shots where it was deemed worth it. The vast majority of the film was done with normal issues since trying to go 100% deep images would have simply crushed ILM.
Things like 3D assets, textures, etc. don't suddenly need to be duplicated. In fact, the 3D scene itself needs very little changes, just having two cameras instead of one. It's once the movie's rendered that things double in size, but that's only a subset of the total movie's required space.
While it's true that most 3D scenes don't need major changes, and the camera data is very small, this isn't always true. In 2D, artists will occasionally use horribly nonphysical hacks to make something look the way they want,a nd some of this can break horribly in stereo. So, every once in a while a cheap flat card with a texture on it gets replaced with a real fleshed out 3D model, or a 2D dust/sparkles particle effect gets redone as a full 3D simulation. Stuff like muzzle flashes, glows, halos, flares can be quite easy in 2D but surprisingly more than 2x the work to do in stereo without giving you a headache.
You would think that for stereoscopic imagery instead of single-viewpoint imagery that the data-storage requirements would double rather than increasing by 30%. Maybe there's compression of imagery involved to save that space?
Generally speaking, nothing clever happens for stereo storage. It's just that the actual rendered frames are only a small part of the total data involved in making a film. I've never worked at Dreamworks so I can't speak in detail about their pipeline, but I wouldn't be surprised if they are rendering to.sxr or something similar. (Possibly an analagous in house format.) It's basically an OpenEXR file with metadata conventions for stereo. Basically, the two views in SXR are completely separate images stuffed into a single file. No correlation between the views so that pixels that are visible from both can be reused. You can read the SXR spec to learn all the gory details.
Slashdot Mirror
Nah, all the piracy just means *AA can't afford to hire good trolls anymore.
Not every project needs an upper limit, but some certainly do. A friend of mine did the 3Doodler kickstarter and it also wound up unexpectedly successful. (Blew through the original goal in the first few hours, and wound up making a few million dollars at the end of the 30 day campaign.) When they sold out of the planned first batch, there was a bit of a scramble to estimate how quickly a second batch could be made, how big it should be, etc. But, they didn't change the design of the product, so they were basically scalable by pushing delivery deadlines for successive batches out. Of course, the risk is if you have underestimated a per unit cost that would have become obvious after the first batch, you are still locked in to deliver subsequent batches at whatever price you got for them. If you sold the first batch, and then did a re-analysis of how best to do the second batch, it's possible that things could be done better.
When you pitch in for something like a Kickstarter project, making a guess of how well the people will handle the scaling is just a part of what you have to estimate. If there isn't a history of successful delivery of similar projects, you have to deal with the likelihood that your investment won't pan out. If there is a history of it, you still have to deal with the possibility. That's what happens when you spend money on something that doesn't exist.
That said, the game devs should absolutely stick to making an initial delivery before worrying about stretch goals. I have never seen a significant game project come in ahead of schedule or under budget. Ever. I've been starting some indie game dev stuff on my own time recently, and just getting a crappy game out the door really is a shocking amount of work. Getting a good game out the door is an almost inconceivable amount of work, and getting exactly the game of your dreams out the door is simply impossible. Considering that the original planned budget of the game was such a small percentage of the ultimate take, they could have just done the original game as a "practice run" to give something to the players and then used whatever was left as the budget for the bigger fancier sequel.
In the inner city, tons of young kids get adult sentences for being involved in the drug trade. So, it is already far from an inviolate already. There is a disproportionate portion of young people convicted as adults who are racial minorities, so that's another big issue with the legal system at present. But, it's silly to say that not being mature enough to automatically be trusted to sign your own contracts inherently means that you should be excused for rape.
IMO, the way it should work is that everything is recorded, and made publicly available after, say, 7 days. In that time, and officer can request that something specific be witheld from the public record. the process would basically be the same as a warrant, where the officer would go to a judge, who would review the footage and would sign off on the redaction. If the footage came up in a court case, it would be possible to petition to get it unsealed. This would cover all sorts of situations. A bust of a child pornographer might involve several minutes of child porn, for example, and you probably wouldn't want to publish that, given the point of bothering to arrest the child porn publisher. Likewise, you might want to protect a source or informant, which could be pretty broadly defined to include 'potential sources,' which would cover shopkeepers who don't want to be specifically on record as being friendly with the cops, but who the cops want to interact with and establish a relationship that may be useful to exploit in the future.
Besides, once there is a year of footage being recorded every day, it may not matter much if you get recorded talking to the cops. Your enemies will have to invest a massive labor force to find footage of you making off color jokes by watching all of it. (Unless the government successfully makes some awesome public facing database for finding this stuff, but in reality they would just hand half a billion dollars to a vendor, wait five years, and then declare failure on a project like that which a startup could have working reasonably well in a few weeks...)
Erm, that seems like a bit of a failure of imagination. Why wouldn't that be a "tracking domain?" Do you have some specific proof that it's somehow impossible for Google to use normal logging functionality on the web server for that domain? And that this will be true forever? Obviously, the idea that any particular domain can't be used for tracking is just silly. So, if google knows you visited the manufacturer's website, why couldn't they use that for ad tailoring when you log into gmail to send an email? Or anywhere else that you get a Google served ad, for that matter...
I'm not amazingly paranoid about this stuff, but to seriously dismiss the possibility of doing these things is just silly.
I'm sorry, but no. The concept of contactless payment is just inherently broken. It's really obviously, blatantly, completely invalid. Making it possible for me to pay from a distance wirelessly without having to do anything specific with the payment card/source/token, means that I can be robbed without noticing it. It just takes a big antenna hidden in a backpack, or stuffed under a coat, or in a car. No matter how much you clamp down on the concept, you just require the guy robbing me to have a slightly bigger antenna.
If I absolutely had to design something like this, there would be a requirement for contact even if the data had to go over a wireless channel. Tap your conductive card on the metal plate to send a wakeup signal to the radio, or something similar. No moving parts, no requirements for the contact payment accepting device to keep the contact in pristine condition. Easy.
Well, if you had to cite a source, but all you had was your own recollection that you had heard the word, 'Meanderings of Memory' is pretty much the perfect name for it. It's even possible that within the community of people working on it, it was a well understood practice. Like giving a directing credit to Alan Smithee for a film. (For a guy who never existed, he sure was prolific!)
Related to this, ultimately what matters is the business plan. That will imply a few things...
1 - Why is this algorithm better than what's out there?
2 - Why can't anybody else do what this does? (Patents, at least.)
3 - Why you can't make money with it now, and how you will make money with it if they invest.
Frankly, without a lot more information, I'd be highly skeptical about investing in a video processing algorithm. Are you trying to productize it? Investing in product development is a very different matter from investing in an algorithm inside of a potential product. Are you going to try to license the technology? Why can't you do that without venture capital? It's fairly cheap to call Sony and try to convince them to buy the technology to stuff in their next cameras. Having a bunch more money won't make that a much easier sell.
No, but I do think they did it with a lot more skill and time than it would take me to push a button on a box I just picked up at Staples. And, with a less strict landlord than mine. If I had a workshop and the time to learn the skills, it would be awesome. But, in an urban apartment I will never learn how to make a gun by hand no matter how low-tech the process may be. And if I did, I'd never be sure if I got one wrong until I tried it and I checked to see if it blew up when I fired it. When it's a purely automated system making the parts, you can have a lot of confidence in the consistency.
I agree with your point, but would perhaps add a few extra bullet points.
#4. Where they already are. Tons of young coders started writing software for whatever type of computer was available in the living room rather than any rational assesment of which platform had the best dev tools. Tons of people will be handed blackberries by their corporate overlords, and have an itch to scratch. Those people already have full time jobs, so they won't be as prolific as full time mobile developers, but a lot of useful things have been generated by soembody who just wanted to scratch an itch.
#5. Where the competition is light. If the BB10 market turns out to be 1/10 the size of the iOS market, but has less than 1/10 of the developer focus, there may still be money to be made in that market.
#6. Where there are users. A couple of whiny users asking for their platform to be supported is sometimes enough to justify developer time. Especially for things like messaging applications, you want to be everywhere so that all the friends of your potential customer will also be able to get the app and interact with them. I buy multiplayer video games on things like Steam primarily because they support cross platform multiplayer. They don't have to be that great of games, as long as I know my couple of friends who have only OS-X will be able to play with the group.
These may all be relatively small factors for BB10, but it isn't quite dead yet. Just sort of pining for the fjords a bit...
My understanding is that there will indeed be something like RWX control. Not just for security, but also for performance. If boths ides can freely write to a chunk of memory, you can get into difficulties accounting for caches in a fast way.
That said, if the CPU and the GPU are basically sharing an MMU, then the GPU may be restricted from accessing pages that belong to process that aren't being rendered/computed. There's no reason why two different applications should be able to clobber each other's texture memory if they do something stupid. So, having the GPU share pointers with the CPU is potentially a very good thing for security. (How well AMD implements the concept in practice remains to be seen, but I'm optimistic.)
Because when you are doing stuff like OpenCL, dispatching from CPU space to GPU space has a huge overhead. The GPU may be 100x better at doing a problem than the CPU, but it takes so long to transfer data over to the GPU and set things up that it may still be faster to do it on the CPU. It's basically the same argument that led to the FPU being moved onto the same chip as the CPU a generation ago. There was a time when the FPU was a completely separate chip,a nd there were valid reasons why it ought to be. But, moving it on chip was ultimately a huge performance win. The idea behind AMD's strategy is basically to move the GPU so close to the CPU that you use it as freely as we currently use the FPU.
The way the system is set up, the government has to know something exists to be able to askfor it. It may sound slightly silly at first blush, but it's actually quite important. Imagine that a drug dealer is being prosecuted. They have sworn testimony that "yes, that hard drive has a list of drug suppliers called drugsuppliers.doc." from an employee. Failing to share the file is withholding evidence that the government knows exists. On the orher hand, if cops start going door to door to check everybody's computer for anything bad, they don't know what they are looking for. Forcing you to grant access 'just in case' would be a horrible violation. In this case, the judge is saying that the prosecution is just on a fishing trip. There might not even be anything specific to the case on that drive. There might be incredibly horrible evidence that makes this case even bigger. But in any case, the government needs some evidence ro start dismantling a person's life. They can't do it just on the possibility that they may potentially find some evidence.
Indeed, hiring an asshole rarely survives a really thorough cost benefit analysis. Unfortunately, the people who hire assholes never seem to take into account the potentially far reaching effects that one epic ass can have on a company. Even people who never have to interact with that person have to deal with the people who do, and the morale impact can be far reaching. I'm sure there are some rare cases where an absolute ass is unarguably the right person for a job, but these cases are few and far between. If there are any objections to be made, the long run cost is generally not worth the trouble.
(Recently had my asshole quotient expanded at the office. Have basically become completely ambivalent about the job. If they convince me to resign, they are losing one of the more qualified people in the US in a very narrow niche that I fill.)
It's kind of a nit pick, but Boston is often assumed to be larger than it is. It's kind of famous and 'important.' But, it doesn't make it on this page of "largest cities on earth:"
http://en.wikipedia.org/wiki/List_of_cities_proper_by_population
It's only about 20% of the population of the smallest city on that page. Not exactly sure where it ranks overall.
Is this actually a really big deal? Given the massive number of repositories which probably contain nothing of great consequence, is anybody ever going to really need to fork more than 15% of what is on GitHub? And if they do, in most cases they can just ask the author for a license.
And, not being able to 'touch' may not matter if the author just intended for people to look. It doesn't really matter if something is GPL, proprietary or BSD if all I want is to see an example of how somebody used an obscure and poorly documented API. There are tons of libraries where a working example is worth a thousand apidoc pages that just give terse statements about functions in isolation.
Yeah, there are probably a lot of people who don't understand copyright and either think that they can use something because it is on github, or think that they don't need to pick a license for people to use their code. Most people are stupid. News at 11:00.
Which is kind of a shame. Dell actually has some nice products. (Lots of terrible ones as well...) They are almost at the point where I would seriously consider a very large scale storage solution from Dell. (Think many hundreds of TB SAN) They have been acquiring some interesting storage companies and doing good integration work. Given that Isilon and BlueArc are currently both trying to kick their customers in the nuts, there is a good opportunity for Dell in the Datacenter.
Almost nobody does real 'Beowulf' style clusters anymore, if you use a very precise definition, but in the broader sense this would be a compute cluster. I haven't studied the details of the proposal, but I'm not sure why this would ne revolutionary. Using a cluster for rendering video is pretty common. Burn clusters are used with Autodesk Smoke. Smoke used to be quite obscure but now that it exists on Mac it is seeing pretty wide use. From what I understand, Vegas has network rendering as well. Outside of strict 'editing' and into video comp and color, tons of people use things like Nuke and After Effects on a farm and Baselight uses a cluster. So, the idea isn't really revolutionary. It all boils down to whether or not the implementation is good or not, how it gets used, and wether or not it actually makes my life better.
Distributed processing for video editing is quite tricky. Unless you are doing a lot of fancy effects (which tends to happen in something like Smoke, but as far as I know Openshot has less in the way of professional finishing effects. Some of this would include cheesy stuff like lens flares. Most o it would be stuff like tracked stabilisation and degraining which can be quite slow) actually coming up with a video frame isn't that CPU intensive. When doing ordinary cuts only editing, you just have to seek to the frame in a video file, and decide the frame. For a proper editing format like ProRes, this is about as CPU intensive as decoding a JPEG. For interactive editing, that's pretty much it. Schlepping video frames across the network for that is a huge waste. If the remote system doesn't have the right codec installed, you are sunk. As your timeline gets more CPU intensive, you get more of a payoff for having Extra CPUs to throw at the problem over a relatively high latency and low bandwidth link. Figuring out exactly what to farm out and when is a nontrivial task and it won't be possible to come up with a system that works well for all possible use cases.
Anyhow, I wish them luck. Hopefully they come up with a feature set that matches their users needs. I may have to check out a current version. Last time I played with it, OpenShot wasn't really my cup of tea, but it is always good to see somebody getting support from the community to scratch an itch.
On the subject of working with a big network, and the sort of creative influence that levels of executives can have on a project... Can you please start this interview with a fist fight?
(A probably too obscure reference to the start of the B5 spinoff show, Crusade.)
Or, to put it a bit more seriously, given that you have had frustrations with the role that networks have played on some of your previous projects, how do you see the creative process changing as time moves forward and technology changes the nature of distribution? What do you see as an end-game for these trends moving forward?
To be fair, if somebody tried to sell something as locked down as the iPad is during the period when IBM first released the PS/2, it would have also flopped. The market has changed a lot since the 1980's. People who seriously upgrade their desktop are a rather small fraction of the total market for programmable things with CPU's.
Unfortunately, you still need two separate deep images. One for each eye. Things like specular highlights and reflections shift around depending on the viewer's position, so generating a second view froom the deep data doesn't actually look right. There are some cases where it'll work fine, but it's not universally true.
Given the public relationsy nature of the number, assume they are going with whatever sounds biggest to the marketing guys, which would probably mean core-hours rather than machine-hours. That is to say, a two socket machine with 4 cores per socket can do 8 core-hours of calculations per hour of wall-clock time.
No idea how much this was used on this particular film, but for the record, deep images don't save disk space. They churn through it like nobody's business! The idea is driven around storing many samples per pixel instead of just one, so you have a *lot* more data than with a normal "shallow" render and compositing pipeline. It is extremely useful for some thing, but it costs so much in terms of resources that it is still not in wide use yet. On the film Battleship, ILM used a deep image pipeline, but they only did it on a handful of shots where it was deemed worth it. The vast majority of the film was done with normal issues since trying to go 100% deep images would have simply crushed ILM.
While it's true that most 3D scenes don't need major changes, and the camera data is very small, this isn't always true. In 2D, artists will occasionally use horribly nonphysical hacks to make something look the way they want,a nd some of this can break horribly in stereo. So, every once in a while a cheap flat card with a texture on it gets replaced with a real fleshed out 3D model, or a 2D dust/sparkles particle effect gets redone as a full 3D simulation. Stuff like muzzle flashes, glows, halos, flares can be quite easy in 2D but surprisingly more than 2x the work to do in stereo without giving you a headache.
Generally speaking, nothing clever happens for stereo storage. It's just that the actual rendered frames are only a small part of the total data involved in making a film. I've never worked at Dreamworks so I can't speak in detail about their pipeline, but I wouldn't be surprised if they are rendering to .sxr or something similar. (Possibly an analagous in house format.) It's basically an OpenEXR file with metadata conventions for stereo. Basically, the two views in SXR are completely separate images stuffed into a single file. No correlation between the views so that pixels that are visible from both can be reused. You can read the SXR spec to learn all the gory details.