Live data from Hacker News

Disney Open Source

disney.github.io

81–90 of 126 posts

Re: Disney Open Source

#81
post #58
post #51

Earlier quoted context omitted.

Pixar: USD, OpenSubdiv, jss-api-gem WDAS: Reposado, SeExpr, Ptex, Partio, Dynamica, BRDF Explorer ILM: OpenEXR, Alembic (with Sony)

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.

Re: Disney Open Source

#83

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. [1] https://github.com/munki/munki [2] https://github.com/wdas/reposado

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.

Re: Disney Open Source

#84

Just an FYI: Always be careful! 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 th…

> why this is an issue The fact that this comes from Disney does not help, too.

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.

Re: Disney Open Source

#85
post #57

Earlier quoted context omitted.

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) [1] https://www.constituteproject.org/constitution/United_States...

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.

Yeah, I don't know what was more offensive: extending copyright YET AGAIN or doing so retroactively to save Steamboat Willie.

I vowed to boycott Disney, but Pixar got subsumed into the evil empire and I gave up.

Re: Disney Open Source

#86

Earlier quoted context omitted.

I don't think it changes yazaddaruvala's point. What happens when ptex website goes away and disney lawyers decide there was no proof?

Copy the license into your fork of the codebase.

That's not how licenses work. You can't just apply what you assume is true. You'll get called out when you don't expect it.

Re: Disney Open Source

#87
post #44

Earlier quoted context omitted.

Like the entire game has changed, rules, board, pieces and everything? Or like the game has been somewhat improved?

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.

"fundamental" seems to imply a magnitude shift. 100x seems the minimum bar IMHO. Otherwise its just decimate..

Re: Disney Open Source

#88
post #44

Earlier quoted context omitted.

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.

"fundamental" seems to imply a magnitude shift. 100x seems the minimum bar IMHO. Otherwise its just decimate..

In this case the frame rate went from 0.25 fps to 40 fps, a 160x improvement, so "fundamental" it is.

Re: Disney Open Source

#89
post #81
post #58

Earlier quoted context omitted.

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.

Version 1.0.

I was at The Foundry while this was happening.

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.

Re: Disney Open Source

#90
post #69

Earlier quoted context omitted.

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…

Death should be the limit, and 70 years for corporate owned assets. You shouldn't get to make money just because your mom or dad was creative. I know that sucks if you die early and your kids are young.

[deleted]
Post reply on HN