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).
There was quite a bit of discussion about this a couple of years ago. OpusModus[1] investigated supporting CCL on M1, but wasn't confident that it could be accomplished, and instead ported their product to LispWorks.
There are numerous symbols to represent pitch on a staff, numerous other symbols that can be attached to the pitch symbols that represent changes in duration, dynamics, various techniques and more. These symbols can be stacked above and below the pitch symbols, to the sides of the symbols and more. There are other symbols that can span multiple pitch symbols, groups of symbols and more. There are more symbols that control the tempo of the playback of the score, the number of times sections of the score should be repeated and other symbols that will move the current playback location of the score to some other place. The placement of all of these symbols have "rules" but these rules are really suggestions and composers will always want to adjust and bend these rules. If a system implements strict rules, that system will come under criticism as being inflexible. There seems to always an exception to every rule of music notation.
I have been working on music notation software for almost forty years and have seen programmers come and go with their attempts to "solve" the problem of music notation. It is a very difficult problem. Once upon a time SCORE [1] was considered the best of the best on music engraving software. I worked with Leland Smith to update the program to more platforms. Sadly, the SCORE source code is not available and the rights of the source code are unclear after Leland's passing. Many music publishing companies continued to maintain systems using SCORE for quite a while.
The notation engine of my iOS music notation program Komp [2] is available here: https://github.com/SemitoneGene/notation. This code is most certainly not the best or most complete, but it is easy to read and comprehend if you want to see the complexity involved. MuseScore has also been mentioned in other posts.
If I were to do a commercial engraving of a music score, I would use Dorico. It is being developed by who I would consider the most insightful and understanding group of developers who have a real desire to make the best music engraving program.
LilyPond produces very good output but offers its own series of challenges to use. MuseScore is a nice program, but it has a long way to go to meet the demands of the high professional composition and engraving market.
This is an obnoxious response that has no bearing on the content of the article. You may as well state that cancer is caused by not praying to the god of your choice or by not following some specific 12-step program that you have deemed vital.
There is no truth to your statement that is it not socially acceptable to suggest diet and lifestyle changes to improve quality of life. Those suggestions are made all the time and people who suggest them in general suffer little to no negative consequences. I am not sure how you go about making those suggestions, but perhaps your approach is less optimal. There are situations where suggestions will be made and go unheeded. Many alcoholics know that drinking is bad for them and many smokers know that smoking is not having a positive effect on their health. They choose to ignore the advice.
My wife, who passed away almost two years ago, received CAR-T therapy for triple-hit large B-cell lymphoma. I can assure you that her diet and lifestyle choices were most likely not the cause. CAR-T therapy is not made available to any and all and her case was most likely caused by exposure to specific toxic chemicals. I only wish she would have survived the extremely toxic and negative side-effects of the therapy so she could be here to reply to your comment.
I assume he would say the same things I would hear him say in meetings where the installer team would show him the lastest versions of the application. A special memory comes from the time where the installer progress bar starting going in reverse. The installer and mail teams received a lot of abuse. It took a special person to stay motivated given all of the challenges they faced and the feedback they got from SJ.
As a customer (my personal computer/display/phone/etc spend with Apple over the past 20 years or so: $25k+): I would prefer having someone in charge who can tell/understand/sense and say that something is clearly not good enough and then actually getting it solved. Tim Cook does not strike me as that kind of guy.
Stan and I worked together at DreamWorks Animation and I kept in touch with him after we both moved on. At DreamWorks, Stan was dealing with some difficult problems such as moving our code from 32 to 64 bits.
It is inevitable that Stan will be remembered for the C++ Primer. When being introduced to Stan, some percentage of people would recognize his name and ask about the book or some other aspect of C++ history. Stan would kindly respond, but I always got the sense that there were other things he would rather discuss than time spent with Bjarne in front of a whiteboard or dealings with various standards bodies.
Stan was complicated and complex. I feel that he would much rather be remembered as a father, an artist, a dancer and a lover of beauty. We usually can't determine how we will be most remembered, but Stan's work on the C++ Primer, while important, is low on my list of memories of him.
I am an adult who has built several Lego kits recently. These include the NASA Saturn rocket, the NASA LEM, a grand piano and a Fender guitar amp combo.
The plastic parts are more than just generic shapes; many of them are custom and designed for the specific kit. The plastic itself has a good feel and is durable.
The kits are unique and must have required numerous hours of research and development, prototyping and user testing.
The documentation is extensive, high-quality and complete. In addition to the instructions, there is nicely researched and presented material about the subject of the model.
If anyone is reasonably able to come up with a process to compete with the sum total of all of these elements, I wish them luck. I would also like to invest!
> The plastic parts are more than just generic shapes; many of them are custom and designed for the specific kit.
With Lego, it's surprising how often the parts are NOT designed for a specific kit.
You can look through the parts list at the end of the instruction manual. You'd be surprised how often they've re-used parts you'd think are specific to a kit. With Saturn V in particular, I was SURE the fairing must be a part specific for that kit. Turns out it's the spire from a Hogwarts castle kit. Okay, so that's the only other kit it was used, but still..
If you look at clone kits, they often have more kit-specific parts. I think this is counter-intuitively a part of a strategy based on low-cost. They spend less on extremely precise plastic molds, and designing a kit-specific part can make it easier for designers. They don't have to spend a lot of time thinking of creative ways to re-use existing parts. They don't need to have knowledge of obscure parts they could re-use either.
> The documentation is extensive, high-quality and complete.
And it's easy to find them online if you've lost them, and you can easily find missing parts of bricklink. So you can dump all your Lego in a box, save it for your kids, and be sure that they can still be used, and that you can rebuild the sets if you want.
I saved my Lego from my childhood. I recently took them out to play with my kids and they're still perfectly good. The only thing that doesn't match with modern Lego is the electric stuff.
> With Lego, it's surprising how often the parts are NOT designed for a specific kit.
OK, that is interesting.
I wonder if and or what the software used by kit designers looks like? Does Lego have a custom CAD system that references the catalog of existings parts? Are they any Lego employees here that are able to comment?
unfortunately we dont support full remote. but offer a nice relocation package. we hire for software engineers in Billund, Copenhagen and London, we have hired 1000+ last 2 years, massive digital growth
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.