Code is newly released, and rough around the edges.
We're working to get the docs up to par and some Docker containers ready for ease of use.
Feedback is welcome.
Disney probably doesn't need a blockchain, but they do a fair bit of research. Considering Disney already has a relationship with its customers, a centralized system works best. In fact, this is what they're doing now with their wristband payment/identity system. Considering they just invested $1bn into this, I suspect they're going to be using it for quite some time.
While Disney Dollars are no longer produced, I can see them used in other ways. If you haven't been to Walt Disney World (not Disneyland) in the last 2-3 years then you might not know about their MagicBands. They are a RFID wrist band that you basically use it for everything. To get on the Magical Express from MCO, check in at resort, open your room door, park admission, fastpasses, dining reservations, dining plan information, gift shop purchases, etc.
Seems to be mostly a rebranding of the Pixar opn source page? Consolidation with other Disney software is great. Hope to see more, and especially usecases or how Disney use it... And allow for outside contribs to do the same.
Alembic has been a game changer (efficient geometry cache, thread safe hierarchy access, etc.), OpenEXR has been a major improvement to the industry, OpenSubdiv is very cool but definitely not a game changer.
Check out the video. In the example, rendering of an animated model goes from 0.25fps without it, to 4fps with it using CPU rendering, or up to 40fps using CUDA for the example model....
I'd say that is large enough to have the potential to fundamentally alter how people work.
Also, diminishing returns apply: going from 0.25 fps to 40 fps is a game changer when doing interactive modelling, in the sense that only one of the two can be considered interactive. Going 40 fps to 4000 fps wouldn't really be make things much better (I'm sure artists would simply push the tools to bring that frame rate down again, and any improvement to render speed obviously would matter for final exports, but you get what I mean).
Kind of - it depends on the artist you talk to. OpenSubdiv utilities have been part of the major 3D packages for about a year or two now, and it's true that they can offer some significant speedup, well-needed in both the games and per-rendered CGI industries where high-poly subd models can easily go up to several million triangles.
Besides the speedup, there is a very interesting feature of OpenSubdiv - local edge creasing. To influence the general creasing or smoothing of a subd mesh, an artist usually has to add more or subtract geometry in an area, respectively - whereas OpenSubdiv gives you the alternative option to assign a crease value to an area of the source mesh which influences the apparent creasing of the resultant mesh in that area without the artist having to add more geo. It works some of the time: not every artist likes using local edge creases but for those that do, it can be a very big help, considering the the occasional difficulty in adding new geometry to a mesh that flows correctly and doesn't accidentally ruin the rest of the mesh.
I opened up a couple of these repos and some seem to have modifications on their licenses.
Some like OpenEXR say "BSD" but don't actually have a license file.
Others like, Ptex and Partio, have no mention of a license at all.
Edit: For anyone wondering why this is an issue. From a legal standpoint, there is a huge difference between being able to read the code, and being able to use the code.
IANAL (but I work often with them) and, about (2)... It'd depend mostly on how it's presented. You could either argue along your reasoning (only sub-directories are licensed) or say "it's right there in the 'documents' subdirectory that comes with the project, it's in another directory only to have things better organized, so all the project is licensed".
Probably you'd be able to find legal precedents for both arguments. Still, I agree with you that it's good to pay attention and understand the licenses (or get legal councel if you don't) if you're planning on doing anythnig with these projects (and others too).
Luckily there are tools like the Wayback Machine from archive.org where you can retrieve the previous versions. There's also some existing cases where it's been ruled to be a legitimate source of evidence too so you're not arguing that from scratch.
If by "well-defined rules" you mean normal "Copyright Law", then yes. But it extends no protections or permissions beyond what copyright law already gives you.
Huge chunks of modern computer graphics production rendering infrastructure is based on open codebases.
I don't get the snark. The visualization studios (Disney, Sony, etc) work on open source is a fantastic example how open sourcing codebases can be a win-win-win situation.
The DIY style management software for OS X/macOS[1][2] is interesting. I knew commercial packages existed for this sort of thing (and more), but I'm fascinated that Disney admins & engineers chose to implement their own Software Update Servers.
FYI, a large number of enterprise orgs and Edus use Munki and Reposado to manage Macs.
Among these: Google(their fork is called Simian: https://github.com/google/simian) and Facebook.
Not only is Munki used across a large number of organizations, it also happens to arguable be the best current software management tool for Macs.
How tied to Disney is munki and reposado? I use the Server app, but the functionality is continually hamstrung and honestly these open-source apps probably have more functionality than was ever in Server.
It's really interesting to hear that they could be tied so closely to Disney though.
As far as how tied to Disney they are: the project lead and initial sole developer (others chip in quite a bit now) is an employee of Disney. My impression is that he's open to changing things but not if those changes interfere or complicate their deployment at Disney. So I'd say definitely Disney-prioritized rather than a straight up community project. Affiliated projects like AutoPkg are community driven and somewhat tool agnostic.
I think what you should use depends on your available time, inclination and mindset. I meant for this to be short but it ended up being ridiculously long. Sorry about that. Hopefully it helps save you and anyone else the time required to get a broad understanding of this space. tl;dr at the bottom.
I wouldn't bother with Server App. It's complete crap. Maybe useful for >10 macs but I'm honestly not sure if that's even true given all the ways it can totally shit the bed on you. Not well maintained. Probably best to think of it more as a reference implementation for 3rd parties developing an MDM solution.
If you have time for the learning curve, want to apply the configuration as code/automated testing mindset and want/need to save money go with the open source tools. Don't expect to be able to commit the commercial versions to source control.
Munki+Reposado+Margarita+AutoPkg for sure:
Munki: Nothing touches it terms of the core/engine's package installation abilities. Repo is configured by the admin/tools like autopkg so it's just a static repo that can be hosted by any web server. Customizable self-service app that's very similar to the app store app.
Reposado: Let's you do pipeline/canary testing/one-some-many deployments of your official Apple updates since they can rarely mess things up on their own but more frequently break some software.
Margarita: Web UI for managing Reposado, only needed if you want/need that or just don't want to deal with figuring out how to manage/automate it.
AutoPkg: This is so amazing you'll want this even if you use something like Casper but it was designed with Munki in mind. Using recipes it downloads updates for software from the vendor's websites/repositories, repackages as necessary and can be configured to automatically add those as updates for your existing packages. So you can get security updates and force their installation long before your average laptop user bothers to update. You can do pipeline/canary testing/one-some-many deployments using your preferred CICD tool (Jenkins seems to be popular for this). Recipes are maintained in a community repo so even if a vendor changes their site and breaks things someone has probably noticed before you and provided a fix.
Key differentiators for these: Open Source, configuration management as code, automation, testing, CICD, etc.
Puppet, Chef, Ansible, Salt or GitHub's Boxen (Uses Puppet but has an opinionated layer on top): If you want more configuration management and distributing it via packages through Munki isn't your cup of tea use one of these in addition to Munki.
Key differentiators: Open Source, configuration management as code, automation, testing, CICD, etc.
If you want easy as pie and very SMB oriented take a look at JAMF's Bushel. It's clean looking and subscription based and probably the least amount of effort overall. It's cloud-only I believe, so if on-prem is a requirement look at the next one. Not sure if you can do custom packages or much in the way of config but you can definitely distribute Apple App store applications.
Key differentiators: modern, easy to use and quick to get started with. Auto-magic enrollment of devices you buy (as long as they are through the same account). Distributed App Store apps.
If you want more control and a decent GUI (particularly if you have a decent number of Macs) take a look at JAMF's Casper. Warning: The trial is limited to 14 days but you can purchase a 45 or 60 day trial+2 or 3 days of training for a mere ~$4K or $6K. Training I think is provided by a VAR/Partner. No you can't use it after that unless you buy it. Expect a hard and high touch sales experience since this is more or less enterprise software. There's a cloud version and on-prem version. On-prem will require some upkeep (MySQL instance to manage, java app that runs on tomcat, etc.). You should use AutoPkg with Casper too even if it's a bit annoying to get setup.
Key differentiators: Big community with a lot of answers and advice that are often universal enough to be useful no matter what you're using. Very enterprise-y so good if you need that (contract, support, feel good sales pitch to management). Easy to use for junior admins or support people. Easy self-service that customizable per-person/group. Auto-magic enrollment of devices you buy (as long as they are through the same account).
Note: The JAMF sales people might bring in a rep from Apple's Enterprise Support team during the sales process to talk about the benefits of Casper (they use it at Apple) as well as (surprise) pitch their enterprise support services and a package called enterprise connect. Enterprise connect is essentially a workaround for bad UX/bugs in Apple's directory services support that they want you to pay for. When the Apple rep told us that you'd be silly to use open source tools we asked about Google and Facebook and he replied, "Yeah... well they probably think they're pretty smart! Haha." Backpedaling ensued and he said, "Well of course they're smart, they just have different problems." When pressed about the problems Casper couldn't resolve for them he said "scale" after conferring with another person at Apple.
There are others but either I don't know enough about them to offer any insight or they aren't worth mentioning for various reasons.
tl;dr:
Munki/Reposado/AutoPkg: If you can afford the learning curve and need/want the DevOps tools/automation/philosophy.
Bushel: If you want easy, no hassle and automatic device enrollment, SMB.
Casper: If you want a GUI, enterprise features and automatic device enrollment, easy self-service, have a decent number of Macs.
There's definitely much easier to use tools out there in terms of the UX, learning curve and some features that just aren't in scope for munki/reposado/autopkg but in many respects the commercial competition has been (and still is) playing catch up. Back when it was first introduced the divide was even greater.
Good. I have downloaded and viewed a lot of WD movies with torrents (I'm a near homeless man in Italy, no money to buy/rent DVD). Now I can give back something contributing to the open source project.
I as really hoping all the projects would be named after Disney characters, because it would be fun to say, "I think we should run Mickey, but we may need to fork Donald to make it work in our environment".
No thanks, Disney has already done enough to fuck over the public domain via copyright. We don't need them using trademarks to fuck over developers too. Besides, I doubt their lawyers would want them to dilute their trademarks like that.
That didn't stop Whatsapp from using DMCA to get a GitHub repo removed: http://boingboing.net/2014/02/21/whatsapp-abused-the-dmca-to.... The point I'm trying to make is that Disney's lawyers have already proven themselves to be snakes (or whatever is the vilest creature you can imagine) regarding their intellectual property. Giving them character names to work with would not be in developer's best interests, even if the original comment was meant to tongue-in-cheek.
jedberg, we deserve the down votes (-4 for me. a personal record!). These are the kind of comments that have come to dominate slashdot - a formerly awesome site. Sorry HN, I couldn't help it this time. Now back to the higher quality discourse.
Why? Disney has invested countless dollars into Mickey Mouse over the past 89 years. It's not like the Happy Birthday song, being hoarded without innovation purely for profit; they're actively expanding/investing/improving and making billions of people happy.
Why should random companies get to legally print knockoff Mickey t-shirts just because enough time has passed?
Because that's what the US Constitution requires [1]:
"To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries"
(Emphasis added)
Copyright is limited. It's just that the Mickey Mouse collective is constantly getting laws passed that push back how far away "limited" is. It's more like a pay-as-you-go scheme for unlimited copyright while skirting around the US constitution. And of course, because Disney has enough money they can also convince Congress to apply the law changes retroactively.
The content Mickey Mouse has been in is copyrighted. Mickey Mouse himself is trademarked. So you /may/ be able to reuse Steamboat Willie for whatever purposes you wish (assuming Disney Legal doesn't get Copyright extended), but you'll probably never get Mickey Mouse as a symbol to work with.
"Mickey Mouse collective" is a term I use for the pro-copyright-extension lobby. But yes, you're right that Mickey Mouse will probably never be a usable character.
I take a boycott from buying Disney products (including movie tickets / movies). I will gladly watch their movies if a friend has a copy (copyright law still hasn't taken that freedom away from me), but if no-one has a copy the movie couldn't have been that good anyway. :P
Your talking about a company that owns at least 50% of it's success to the i.p. of characters it didn't create. Cinderella, Sleeping Beauty, Pinocchio, Aladdin, Beauty and the Beast...i could go on. I don't think anyone would argue that the films they made, based on the work of others whom they did not pay, contained substantial original creative effort and that they deserve the success they gained from those films due to the significant changes they made. The great hypocrisy though is that Disney would not have nearly the success they have today if Disney had achieved then what they are striving to achieve today.
No, the better question is; Should someone else be able to build a knock-off of your home?
IP is not the same as physical property. Disney isn't forced to give away they artwork they've made internally. Mickey Mouse as IP, i.e. as a concept, is currently not allowed to be reproduced.
If we're going to debate property rights, it's important to have the context and the property properly defined. Many people can rightfully ask if land should be allowed to be held by any single entity for infinite time, but again, that's not the question here.
The moment Mickey's copyright expires I'm creating a series called Mickey Mouse. There won't be any women though because it's about IT consultants and their daily goings-on.
If someone could take an exact copy of my family home and live in it somewhere else, leaving me happy to live in my own home, then ABSOLUTELY!
I realize that's not what you meant, but acting as though Mickey Mouse becoming public domain will "take away" from us, in the same way giving away the house you live in will "take away" your home is at best a total fallacy.
i don't think that's strictly true - while you're correct that i [as a homeowner, specifically a freeholder] don't own the land, but i own (i think) a title to this plot of land, it's not a 100 year lease - I "own" this land for an unlimited period and i don't need to renew anything ever. not to be confused with leasehold properties (eg flats) where you have a lease, typically ~100 yrs, to the freeholder (who owns the block of flats), that you have to renew.
"Why should random companies get to legally print knockoff Mickey t-shirts just because enough time has passed?"
Because that was the deal on copyright. Protection in exchange for release into the public domain. Extending copyright is a really shitty way for them not to stick to their end of the deal.
The purpose of copyright law is only to "promote the arts and sciences". Note that it doesn't say anything about the individual creator.
There are two factors determining how much value a society can derive from the body of art created within: the amount and the distribution. (ignoring "quality" because it's unaffected by the following).
The quantity created and the distribution it gets are somewhat conflicting goals: If you maximize for distribution (all works are public domain), the amount that is created may be low because artists aren't rewarded financially / can't concentrate fully on their art etc.
Currently, the compromise is to protect a work of art for 70 years after the creator's death, assuming there are very few people who'd say "oh, I'd love to write the great american novel, but I fear my great-grandchildren won't be able to collect royalties on it, so I'll go be an investment banker instead".
Arguably, 70 years is too long to be optimal. Personally I'd say something from 10 to 20 years is probably enough, or maybe different terms for different categories like newspapers being protected for a week and movies for 30 years.
I think that the 70 years thing is also to dis-incentivize killing the creator to cash in on his work a mere 10 years later. Though 70 years is overkill even in this regard, I doubt anyone would wait say, 20-30 years, for such a plan.
That may have been an argument in setting the date, but Disney was the real driver of it. The reason it's 70 years after the death of the creator is because Mickey Mouse was in danger of becoming public domain again, so they added years to the law.
I think you'd be hard pressed to find any instances of people committing murder for IP reasons.
Because it does not benefit society in any way to grant them a monopoly on Mickey t-shirts. Society as a whole is better off when there is market competition. Monopoly is only granted to encourage the initial creativity. There is also significant public cost in protecting the Mickey monopoly, such as courts and police.
I hope Disney does more of this! They're a tech company in a lot of ways. I believe they're using Rails for their site (which would make it amongst the biggest Rails sites in the world) and I hope they release some Rails stuff too!
I hope so too. As an employee and an open source enthusiast. There are many people inside the (very large) company pushing for more of this. Many of them have replied in this thread. :)
Oh, so that's what the replacements that Disney outsourced and canned those US professionals will be using? Maybe not the most polite type of joke, but hey, I just saw that a judge recently smacked down the class action the terminated employees had submitted (using sound logic).
Be wary of anything with Disney's fingerprints on it. They are - rightly or wrongly - seen as Public Enemy #1 to Copyright reform. Throwing some spare change into the pond of Open Source should be measured.
Alembic was actually mostly Sony originally - ILM were mostly just a name on the ticket, and ILM started using the format because it was much more Katana-friendly (random access and lazy-loading) than their current format, and they were starting to use Katana at the time.
The first version of Alembic was pretty much just Sony's internal geometry format renamed.
I'm not sure what you're referring to as "first version". Did you work on Katana at Sony, and are you referring to the choice to use HDF5?
The idea (a hierarchical organization of geom prims and transforms) was very similar between ILM and Sony. The library API organization (for better and worse) and hashing more more ILM but it was a pretty close collaboration all along the way.
ILM struggled to use Katana with their existing file format.
I'd be worried if the idea wasn't similar - it was the implementation that mattered, and ILM's older format wasn't very good at random access and lazy loading (which were things needed for efficient use in Katana).
Alembic 1.0 was very close to Sony's Taco format rebranded.
We don't need Disney to open-source their software. We need Volkswagen and various bogus companies to open-source the software of safety-sensitive material. Dangerous hardware, measurement tools (e.g. petrol stations, security cams), voting machines, droids... Disney's open-source is merely dry bread for the plebs: We'll take it but it's not advancing our situation.
I was expecting to see some Squeak links (OSS Smalltalk) but I guess no one at Disney is using it now? I think it was the Go.com group ala Alan Kay that was doing something with it internally (I'll need to do some googling but it appears the group moved to ycombinator according to wikipedia... my memory sucks).
If you must Squeak to a company, attribute it to Apple. That's where the project started. The team behind it then moved to Walt Disney Imagineering (Disney's R&D Arm). From then, the team's corporate sponsorship becomes a tangled mess, but according to Wikipedia, they've been with HP Labs, SAP Labs, and... Y-Combinator.
It's calculated of some predefined averages that are way lower than actual market rates. Most H1B's I know are making pretty much market rate or within 5-10% of market rate though. How do they find people to work for about half I have no clue.
What happened was HCL and Cognizant were going to provide IT consultant work for Disney, but the consultants were based somewhere else other than Disney that had a lower prevailing wage.
Sponsoring employers are supposed to report the working areas on the LCA applications, and the USCIS is cracking down hard on the tech consultant firms trying to exploit that loophole this year.
FTA
"H-1B immigrants work for less than American tech workers, Professor Hira said at a hearing in March of the Senate Judiciary Committee, because of weaknesses in wage regulations. The savings have been 25 percent to 49 percent in recent cases, he told lawmakers."
It's for their job title; Disney is happy to pay 150% of an Associate Junior Technician's $30k average salary compared to 100% of a Senior Systems Administrator's $150k.
The trick is the H1Bs are not displacing American workers at the company they work at (the outsourcing company), the company is just expanding. Nor is Disney replacing it's workers with H1Bs, they're just outsourcing to another company.
And apparently, this loophole works, because a judge just dismissed the case.
"The outsourcing companies successfully argued that the law did not apply to them because the plaintiffs who were displaced were not originally their employees."
Pretty sure the labor certification and prevailing wage requirement is on a county / city basis (i.e. somewhat related to the actual local wages), see also https://www.dol.gov/whd/immigration/h1b.htm
Hope it isn't based on what the government pays developers. I've seen some java devs making upper 30s to low 40s within the past few years. That's just crazy.
This is a showcase of larger open source projects used in the visual effects and animation industry. Several of them are contributed to by Disney engineers, but most people would not consider these Disney projects. Disney has open sourced and released some impressive open source projects over the years, and it's exciting to see their endorsement on these others.
I run Disney's open source program. This page is a showcase of all projects from Disney business units. It's currently slanted towards animation because these organizations have been the most prolific to date. We (Disney) expect to broaden the range of projects, to other types of open source projects, for example Dragonchain https://github.com/dragonchain/dragonchain
Alembic was originally Sony's thing, which ILM started using in their early Katana days because their own file format wasn't good enough for use with Katana (random access and lazy loading).
Sony gave it to ILM to start using, and then open-sourced it.
I'd quibble that while ILM and Pixar employees are technically now Disney employees, it's not as if they work for Walt Disney Animation Studios directly, so it's not as clear cut as you make out.
ILM and Pixar are very much Disney employees though, as in employees of the wider Walt Disney Company (which this page is for; the specific page for WDAS is here [1]). If you get a Silver Pass and your pay comes from TWDC's bank account, I'm pretty sure you are a Disney employee. WDAS, Pixar, and ILM are all just individual subsidiaries under the wider TWDC umbrella.
We also just open sourced a hybrid public/private blockchain platform "Dragonchain" with some interesting features.
https://github.com/dragonchain/dragonchain
Architecture document: https://dragonchain.github.io/doc/DragonchainArchitecture.pd...
Code is newly released, and rough around the edges. We're working to get the docs up to par and some Docker containers ready for ease of use. Feedback is welcome.