Title: To Be: An Inside Look at the BeOS
Publisher: Morgan Kaufmann Publishers
Publication Date: August 1, 1997
Author : Henry Bortman
Language : English
ISBN-13: 978-0121186708
ISBN-10: 0121186709
Short description:
A thorough overview of the BeOS, this text is written in easy-to-understand terms for the end user.
It covers all of the instructions for installing and configuring BeOS on the Power Mac hardware, with complete
explanations for sharing files between the Mac OS and Be. The book comes with a CD-ROM with a DR9 installer
so that readers can try the BeOS for themselves.
If you are interested in participating in haiku through instructions and tutorials, you are welcome to write something for our knowledge base. We welcome your contributions.
We are always happy to accept ideas for instructions.
Lots of them are in Japanese, including translations of the BeOS Bible (in 2 volumes), âPorting Unix Applicationsâ and the OâReilly"Programming the Be Operating System".
There were also special editions of PCWAVE (from where the list above came) and DOS/V Magazine published for the release of R4, and add-ons to MacWorld Japan for AA/PR and MacPower for PR2:
I think it comes to a point where it gets too expensive to do anything with. Even giving it away would probably cost a lot in lawyers fees for some reason.
The only thing we really need is to get the âNon Derivativeâ clause from the BeBook removed, so we can complete the Haiku Book, sever the umbilical cord and move on. We could even keep the various jokes.
But dreaming is still allowed, I think.
Nowadays I almost never open the BeBook⊠I guess if you still have need for it you can see about transferring that part of knowledge over to the Haiku book, : )
Yes, in theory.
In practice, this looks like a bit challenging.
The BeBook is under a CC BY-NC-ND, the Non-Derivative clause explicitly prohibits adaptations or remixes. It is way easy to spill over parts of the Be Book in the Haiku Book even inadvertently.
Maybe Iâm too concerned by this but, ideally, the best course of action would be rewriting using a clean-room technique.
One individual outlines the topics, notes, and specifications.
A second individual would review this to make sure no parts of the original have been reutilized.
A third person would rewrite the content.
All three individuals should not be in contact with each other and potentially not be part of the same circle.
Unfortunately, there is no standard metric to measure the similarity to avoid copyright infringement.
There are studies and research about using vectorization of documents, via embeddings and vector storage, and an LLM to infer a new content. It looks interesting, but the vectorization of the Be Book, just to make an example, would be a âderivative workâ by itself. It seems a dead endâŠ
Iâm still minded that weâd better try again with Access to remove the ND clause but I donât know the last time we pursued them.
The point is that you shouldnât rewrite stuff similarily that is inside the BeBook, but instead write new documentation making the old one obsolete.
In many places where the BeBook talks about internals it simply isnât true anymore. Think for example layouts as the normal way to lay out your gui compared to manually placing views, or using ui_color and which_color instead of hardcoding colors directly.