I worked at DreamWorks Animation on the pipeline, lighting and animation tools for almost ten years. All of this information is captured in our pipeline process tools, although I am sure there are edits and modifications that are done that escape documentation. We were able to pull complete shows out of deep storage, render scenes using the toolchain the produced them and produce the same output. If the renders weren't reproducable, madness would ensue.
Even with complete attention to detail, the final renders would be color graded using Flame, or Inferno, or some other tool and all of those edits would also be stored and reproducible in the pipeline.
Pixar must have a very similar system and maybe a Pixar engineer can comment. My somewhat educated assumption is that these DVD releases were created outside of the Pixar toolchain by grabbing some version of a render that was never intended as a direct to digital release. This may have happened as a result of ignorance, indifference, a lack of a proper budget or some other extenuating circumstance. It isn't likely John Lasseter or some other Pixar creative really wanted the final output to look like this.
Steve lived on for quite some time in an undocumented key command you could use in the Finder. I forget the exact sequence; ctl-alt-cmd-shift space or something. It has become more broken over releases and may be gone now. We added it to make all animations go very slow. We would invoke it at Steve’s request in demo to him and he would open and close windows, show and hide sidebars, enter and exit TimeMachine and more. This shipped in numerous version of OSX.
There was a lot of "arguing" at Amazon, or you could call is strenuous discussions. Another principle was Disagree and Commit. I found this principle lacking at other companies. People would disgres and then sabatoge. The Amazon way was to agree to disagree and commit to sincerely work in the direction of the decision. Winning the initial argument did not make you the leader. You became the leader once your solution shipped, gained signifcant market share and some other succcess metric. This was not always the case!
I wonder if overall team size has something to do with how the principles are dealt with? Mobile Shopping is huge. Some teams are tiny, experiencing massive growth or winding down. If a team has a super mature code base or market, and the team feels like they are caretakes as opposed to innovators, how does that impact them? How can it really always be Day One?
> the team feels like they are caretakes as opposed to innovators, how does that impact them?
During my time at least (late COVID and layoffs), this was not perceived amongst the people I interacted with as a great position to be in unless you were raking in sizeable revenue for the company. Even then, I think folks always had eyes on the back of their heads.
> How can it really always be Day One?
I think for many there, it'd feel that way when you're a part of a re-org every year or the other and have to fulfill new projects and deadlines.
I worked at Amazon before the two newest principles were added, so I can't comment on Strive to be Earth's Best Employer and Success and Scale Bring Broad Responsibility. I was asked about the principles during my interview(s) and they were discussed extensively during my onboarding process. I found there were groups of peeple who were very sincere about them and groups that were quite cynical. Some co-workers had no opinion and just wanted to survive their current pager duty. I frequently used some combination of principles as support for an argument for or against some technical or business decision. It was nice to have them written down and the entire company accepting them as the basis of how the business should operate. This was quite different from my time at Apple, where the principles were somewhat fuzzy other than Do the Right Thing, Do What Steve Wants or Put the User First.
The Amazon of the 2020s is different from my Amazon of the 2010s or others earlier Amazons. I can't remember any instance of someone saying a certain principle needs to be violated because it would lead to decrease in profits or market share. There certainly could be cases I don't know about. I found many of the principles helped create a good environment to make technical decisions and maintain some technical autonomy across groups. Yes, working at Amazon is a grind and there many ways working there can suck the joy out of your life. I never found the principles used as a weapon against me, my team or customers. I know Amazon has a lot of faults, but I am not sure they are are directly correlated to the principles. A thought experiment would be to wonder what Amazon would be like if it didn't have any principles at all?
All organisations have principles. Beyond a certain size - and sometimes long before then - they're never the stated ones.
And while you may have used the stated principles to create a good environment, there's nothing in Amazon's principles that prevents someone else using them to create a bad environment.
For example - conspicuously absent from them is any concept of worker welfare.
The problem with the LPs is they are all contradictory. You can make an argument for anything you want using LPs. Want to refactor something? Insist on the highest standards. Don't want to refactor something? Deliver results. It's all BS.
Apple employee pre, during and post Steve. I was in a lot of meetings with VPs whose tasteless suggestions were shut down immediately with the usual Steve critiques attached.
My recollection is that Eddy Cue got the most critiques, Phil Schiller the least and the rest were in between. Eddy would push back and still get shut down.
When Steve left the last time, it was knives out between these guys with Scott Forstall taking a fall as Tim Cook got ultimatums from everyone including Jony. I imagine loud voices with bad taste are pushing Tim hard. Apple can be an investor darling but Tim has needed to consider an exit and find a strong successor that knows what made Apple great in other ways.
Apple was fairly flat under Steve and meetings could have a fair number of interested parties involved. I can recall numerous weekly UI meetings with several of the people listed above there. Also note that Jony, Eddy and others weren’t always high level. Steve handed out his harsh comments regardless of concern for your level. Steve was a micromanager and was involved in anything that the user came in contact with and more.
To directly address your question, the answer was yes in that if you developed a feature, a demo, or anything Steve wanted to see, you would end up in a forum with a bunch a various levels of employees.
Thinking of C suite meetings happening when Steve was around cracks me up. Steve was always on the move, making edicts, rejecting things, walking into offices, having lunch with people, etc. There was no Jira, Confluence, Agile or any of that. It was a fight to ship by an imposed date or die trying.
>Tim Cook asserted his control over the company, putting his own personnel in place, and now his authority is absolute. Even those few others who remain from the Jobs era, such as “Apple Fellow” Phil Schiller, are overridden by Cook
Extracting the licensed 3rd party code and doing the other cleanup needed to do a release would be a chore. I have done this for other code bases and it always ends up being a lot of work that involves lawyers.
The BeOS code wasn’t huge (I remember the tarball being 98mb) but there was licensed code in the codecs, drivers, compilers, dev tools, possibly in NetPositive and more.
It is cool to look at from a historical perspective, which would be the main reason to release it. I wouldn’t advise using the code as a foundation for any future project.
I think it would be interesting to involve the Computer History Museum. I suspect a lot of people would be passionate about helping to archive the project properly. There's a lot of educational value in it, I think.
Former Be employee here who ended up at Apple eventually. BeOS was way, way behind NeXTStep in so many ways. We also had fragile base class problems and had a lot of kernel issues. BeFS was cool but Dominic ended up at Apple (and is still there) so I feel Apple got generations of BeFS evolution. Jean Louis wanted an unrealistic price and Apple spent the smartest 400 million dollars that I can think of by buying NeXT. Apple got Steve, Avie, Bertrand and so many others. Many Be people ended up on board after journeys with Eazel and others. Some never made it to Apple due to their Danger/Android/Google paths. This saddens me even to this day.
Yeah, BeOS was nice in some ways but seriously overrated in these discussions.
The "database file system" was just a regular file system with a somewhat crude indexing system for xattrs. By crude I mean it was up to apps to manage indexes, i.e. it wasn't really useful as a cooperative scheme to help apps work together. Files that had an xattr before an index was created wouldn't be incorporated into a newly created index, so in practice it was only useful to help an app find its own data quicker assuming it stored each data item only in individual files. If you connected a storage device and labelled a file with an xattr, it just wouldn't show up in indexes at all unless an app had created an index on that device first. People hear "database file system" and assume it had similar features to an RDBMS but it didn't. And of course it suffered the conceptual problems that kill off most attempts to extend the FS into a DB; users don't want to interact with their data via a one-size-fits-all file explorer filled with confusing things like tree widgets, and devs don't want to end up exposing a pseudo-API to other apps for technical or business reasons.
The BeOS API had wider design issues too. C++ was one, as you note. Microsoft invented COM and NeXT invented Objective-C to dodge that. But the heavy use of multi-threading was another. People can't handle that even today, and they were doing this in 1995! It led to slick demoware but, as an HN commenter said last time, you could "deadlock the entire system". That was a Win3.1/MacOS Classic level design issue, but BeOS was targeting NT level hardware. When Be engineers went to Android and built a Be-inspired API, the first thing they did was tone down the multithreading and dump C++. The OS was less responsive but more stable and easier to program.
To add a little detail, Objective C was created by Brad Cox and Tom Love who formed PPI/Stepstone, with NeXT becoming a customer when Steve Naroff left Stepstone for NeXT to add support in GCC
> When Be engineers went to Android and built a Be-inspired API, the first thing they did was tone down the multithreading and dump C++. The OS was less responsive but more stable and easier to program.
Yeah, Android sucked in responsiveness (gap still there but closer) compared to iOS. I guess it didn't matter given the ecosystem dynamics but it was frustrating to see the jankiness of the OS compared to the buttery smooth behavior on iOS.
Marking Menus [1], Pie Menus, Radial Menus and friends have been around for a while. There is good body of research on them, with some recent research done on their use in multi-touch environments. [2]
While working at DreamWorks, I would often watch artists navigate complex marking menu hierarchies and invoke a command before the menu items themselves could actually be read by a non-trained user. In our custom lighting tool, you could execute the marking menu command by invoking the menu command and making them mouse movement before the menu actually drew.
It was used in some games to great effect as well, e.g. Neverwinter Nights. Same story there - once you memorize where the commands are, each invocation effectively becomes a mouse gesture performed without even looking at the bubbles.
John is cool, but I don't think he was around when the Macintosh II software and hardware was being designed for color support. I did work with Eric Ringewald at Be and he was one of the Color Quickdraw engineers. He would be fun to talk to. Michael Dhuey worked on the hardware of the Mac II platform. I guess we can give some credit to Jean-Louis Gassée as well. Try to talk to those people! I got to work with a lot of these Apple legends at General Magic, Be, Eazel and then back at Apple again. I never got to work on a project with JKCalhoun directly, but I did walk by his office quite frequently.
True. I showed up at Apple in '95 after Color Quickdraw was already a thing.
Hilariously though, I did get handed the color pickers to "port" to PowerPC. In fact one of the first times I thought I was in over my head being at Apple was when I was staring at 68030 assembly and thinking, "Fuck, I have to rewrite this in C perhaps."
From your username, I feel like we've chatted before (but I don't know your real name).
Even with complete attention to detail, the final renders would be color graded using Flame, or Inferno, or some other tool and all of those edits would also be stored and reproducible in the pipeline.
Pixar must have a very similar system and maybe a Pixar engineer can comment. My somewhat educated assumption is that these DVD releases were created outside of the Pixar toolchain by grabbing some version of a render that was never intended as a direct to digital release. This may have happened as a result of ignorance, indifference, a lack of a proper budget or some other extenuating circumstance. It isn't likely John Lasseter or some other Pixar creative really wanted the final output to look like this.