One of the things that has been missing on the BeOS platform, either for BeOS, ZETA or Haiku, is pthread, and this was also something that yellowTAB experienced when they were working on a port of OpenOffice. Hence, the development team has released support for phthread. This improvement will be contributed to Haiku as soon as it reaches a more mature state.
I love that Zeta is still moving forward even with the recent problems.
This improvement will be contributed to Haiku as soon as it reaches a more mature state
so when does it count as mature? would it not be better to release it now and get the oss communities help? (even if that is only testing)
so when does it count as mature? would it not be better to release it now and get the oss communities help? (even if that is only testing)
You can get it now, just email Bernd. If you have been following the Haiku m-l (like me) you’ll see a LOT of cooperation between Bernd and the Haiku guys.
I suppose the question would be – then – why not just release it to the public? If all it takes is an email, and he’s giving it away like candy on Halloween, it just seems like one more “motion” you have to go through. IE – let’s see how many hoops you have to jump through to walk a meter. It doesn’t seem a very “open” process, at all. Nor does it make sense. That can be said about a lot of things yT.
That being said, I’m glad support was added. Will be quite handy in making ports. Good job, and good luck!
Assuming the port is still in testing, I can see a decent rationale for not widely releasing it yet. It limits potential users to those who are serious enough to EMail Bernd and ask for it. If it was widely released, then it would probably get mentioned here, and then Bernd and co. would have to deal with EMails along the lines of “i instaled ur ptreads and i still cant install this rpm of mysql in zeta. halp plz. thx.”
You can get it now, just email Bernd.
But is that the source? I suspect the OP was referring to the source – since that is what would be donated to Haiku ultimately.
Pthreads are posixthreads, right? I assume these are a different kind of threads from the standards BeOS-kernel threads..then how do they coexist? Does the kernel support both? Or are they entirely different beasts?
Someone a lot more knowledgeable than me please elucidate
I’ll try to make this quick.
#1 – Yes, pthreads == posix threads. They are referring to the API in this case, the “way” in which the developers can deal with threading. Most applications out there were developed for posix threading libraries, so having an implementation makes porting *much* easier, because BeOS’s (Haiku’s) model is radically different. This brings us to…
#2 – “Threads” are “threads”, logically. The exact implementation can be totally different. The BeOS/now Haiku threading API is nothing like the pthread API. They are treated in-kernel the same. They co-exist fine, because at a low level, they are doing the same thing. Bernd & company just made a pthread-implementation so when porting programs from other unices/linux/etc, you don’t have to change the threading code (royal PITA.) Native programs will continue to use the BeOS/Haiku thread API, but ported stuff will likely just utilize pthreads.
Hope that helps.
David
PS – This is a very non-technical explanation, please don’t nitpick on technicalities, it was simply meant to explain the basics to this fellow.
Could you also tell us how the implementation of BeOS threads differs from POSIX threads as implemented in say Linux?
That’s far beyond the scope of this website (and my available free time!)
However, look here for more information on BeOS/Multithreaded programming:
http://www.oreilly.com/catalog/beosprog/book/ch09.pdf
Also, as a FYI:
http://www.oreilly.com/catalog/beosprog/book <– good (free) resource about beos programming.
Tons of books around concerning pthreads, as well as websites. Google should be able to cover you.
Thanks!
Unfortunately that chapter said nothing about the implementation of BeOS threads, only about their use in applications but mostly it was about message passing…..
[I know how POSIX threads implemented on Linux that’s why I brought that up as a possible comparison, though I would much prefer sleeplocks to spinlocks….. So Linux pthreads are far from optimal as well]
Ahh, you want how threads are handled in-kernel? You’re probably best off talking to some Haiku devs (or even looking at the Haiku code), and get information on at least how they implemented it. I don’t know the OS that low-level to explain it properly. My apologies for the misunderstanding! There used to be a book covering all kinds of stuff like that, but I haven’t found a copy online to show you, perhaps somebody else can chime in. Good luck!
I believe you mean the BeBook!
Check http://www.beunited.org/bebook/ and go into ‘The Kernel Kit’ for threads.
So it’s just an extra API? Thank you so much
This improvement will be contributed to Haiku as soon as it reaches a more mature state.
The check is in the mail.
There.. I fixed it for you.
–bornagainpenguin
PS: I’ll believe it when I can see some evidence to support their other claims. Like maybe their claims to have a legal right to modify and distribute BeOS code…
Edited 2006-11-14 02:51
What’s with all that “do they have the rights”-crap? How much longer must I hear this whining?
I don’t know about the legal system in your country, but most western countries I know, the principle “innocent until proven guilty” applies. If you think Magnussoft is doing something illegal, they have to prove nothing. It’s up to you to prove that they did something wrong.
Besides, if they were violating someone’s copyright – don’t you think that the copyright holder would have sued them by now? I’m pretty sure that Palm Source and their successors have received hundreds of email from selfless people informing them about this evil German company who’s ripping them off.
What’s with it? You must be kidding. It’s been questioned a billion times, and nobody has ever gotten a straight response from them. This would make me question (it does) exactly what they do have/don’t have.
yT was poorly run, Magnussoft seems to be run by the same people (or at least run in the same way.) I am not impressed.
So, to answer your question, why people keep questioning them – because they are so secretive and won’t say one way or another. What legitimate company would hide this kind of information from the public? There would be NO reason to hide their licensing deal, if it exists. It all seems mighty shadey.
Are *you* kidding ?
There is absolutely no reason for contracts to be discussed on the public place. Would you ask microsoft to give you a copy of their contract with SCO and others ? They do their best already to hide the bad OEM contracts… Only when they want advertising do they talk about how they owned Novell.
Likewise there is no reason for yT/MS to advertise this. Be sure Palm do know about this (wish I could tell how much they tried to stale it despite being bound). All this is just FUD by clueless ppl.
“There is absolutely no reason for contracts to be discussed on the public place.”
Of course, but we’re not talking about a contract but licensing. If a company is questioned wether they have a license for a certain product it’s customary to provide proof of that. I wouldnt want to do business with a company that couldnt prove that they have a valid license to resell/sell their product. It’s sane business-sense.
Edited 2006-11-14 11:50
There is absolutely a reason for them to simply say “yes, we have legal rights to the source”. It’s a burning question that has been biting Zeta in the proverbial ass for quite some time now, nobody trusted yT (well, very few did) and it’s showing again with Magnussoft. You saw how well yT did. Nobody is asking them to give all the terms.
I like your insults at the end there, but let me humor you. Me being the “clueless” person I am – I’m going to make a prediction. In two years or less, Magnussoft will be gone. Just like yT, except this time the cohorts won’t be reforming under a new name. Zeta will cease to exist. It’s already just about irrelevant. Some cool things come out of it from time to time (pthreads for instance) but with all the secrecy, and all the distrust, it’s not going anywhere as a company. You blame it on whatever you’d like, strange licensing agreements which prohibit them from simply saying they have source (what in the heck did yT/MS sign??? Sounds like a deal with the devil…) I’ve dealt with restrictive licensing before, but nothing like what you claim to be the case. It sounds like there are terms restricting a lot, if they can’t even confirm source rights. It’s just one more reason for people to worry (and it’s quite obvious they do.)
Again, I wish MS the best of luck, but unless they change something radically with how the company is run, and help get rid of the public perception they currently have (including all the unknowns) they are going nowhere. Haiku is well on it’s way as it is – and people don’t have to “wonder” about it. I don’t know how many companies you’ve run, but when anybody has uncertainties about your product/services, and you don’t get rid of them, you fail. If the licensing is that insane, then they dug their own grave before they started. Would have been better to not even aquire the license in the first place, and just be a commercial support company for Haiku (which, btw, is what it looks like they intend on doing once Haiku matures, and ditching Zeta.)
You may want to consult the FAQ on yellowTab.com:
I heard that ZETA is using some illegal code. Is this true?
No. yellowTAB does not use illegal or leaked software.
source: http://www.yellowtab.com/support/faqs/search_result.php?cat_id=-1&f…
To me the situation seems fairly clear.
Magnussoft has a license to develop Zeta, which is derived from BeOS. The details of that license are private, and do not have to be shared with the public. It was almost certainly a condition of the license that the details of the license are not made public.
Clearly there is a license – Magnussoft have the source code, they have put out a commercial product, and they have not been prosecuted for doing so either under civil or criminal law.
BeOS contained IP that was covered by patents, and thus so does Zeta. Public knowledge of the license details for Zeta would affect negotiations for license fees for those patents.
Chances are the license fee for Zeta is minimal, and that is why no details of it are public.
The question is though, with Haiku coming on strong, how relevant is Zeta going to be in the near future?
Haiku, being an MIT licensed project can later be used by Zeta, by being modified with their own api, and sold as a Haiku distro or as a commercial OS.
Rather than discuss the archane details of contracts, how about some discussion of the benefits of threads to YT & Haiku?
What can we do now with pthreads that we could not do before? Do pthreads with SMP on multi-core CPU?
Can we build some cooler demos?
Nothing. As I said a few times now, it just makes porting software easier. The existing API is better than pthreads for threading, that’s one of the reasons BeOS was so cool, the clean programming APIs available.
It just means porting of unix/linux/etc software will be much easier, because you won’t have to re-write all the threading code, which is quite a PITA (as mentioned before.)
Not to imply that I know something that I don’t, but it wouldn’t surprise me at all if the license that YT signed did not allow using the BeOS name. Notice that they don’t, at least anywhere that I could find. License to use the code doesn’t necessarily imply trademark license. Look at the BSD’s clauses that forbid use of the university’s name in ads. If YT had signed something like that, it would make sense that they can’t put up a big banner and a copy of the legal agreement.
Besides… If Bernd did come out and say “Yes, we have an agreement”, would those who are inclined to doubt now believe him? What proof would you accept? A signed document scanned on the web? JLG’s blood and a DNA analyzer?
Okay… I obviously have to kick in here…
Prior to Be’s death, yellowTAB had an agreement with Be, INC for rights to distribute a customized BeOS Personal Edition.
When yellowTAB was moving to the Dano base, it was ( at least originally ) a binary tree with source on top for building the system. This was needed as there was NO source code for the system itself.
What now is not known, is only what I was unable to figure out prior to my exit from yellowTAB… does yellowTAB have source? Do they have a legal right to that source?
The only thing, however, I do know is that yellowTAB was, in fact, given permission, in a manner, by the response from the owner of Be’s IP: We don’t give a rats arse about this crap, not our line of business. It was purchased to add value to the company, no other reason but to make our stockholders happy.
BTW, upon releasing each of my seven Dano-based distributions, I worked primarily with that knowledge. The product is not technically legal, but I have confirmation of moratorium.
I had to get a lawyer to find out if I was safe with what I could prove. I was assured as such after acquiring more information in quest of making a legal Zeta only.
The thing is, however, that there are many things that had to be taken into consideration within the system itself: third-party licenses acquired by Be, INC. In order to make the Dano base system legal, certain components needed one of two things: removal or a license.
Of course, with removal… comes replacement. This is why PhOS Beta 4, 5, & 6 are so radically departed from each other in accompanying applications. I had to ENSURE that the system was technically only released to Beta testers ( just public Beta testing ), and that any sells were obviously not meant to make money, just to essentially cover costs incurred for the Beta process.
The law applies to OFFICIAL releases of software. The purpose is to allow protection for research projects at large corporations. It means the business has to go as far as to actually publish, en mass, to the public for sale / distribution. The Beta process, within the software world, is a essentially a part of R&D as seen by the law in regards to this matter.
Please note, though, I am NOT a lawyer, and it has been a while since I have exited the beta phase within the development life cycle for my product. Which, of course, means I can no longer skirt the legal boundary as I was. I would now prosecutable under law if I were to release a non-Beta version. BUT, I went from alpha to beta in six months, and it took 3 years from beta to internal only ( no public advertisements for derived or potentially infringing products allowed during this time (unless your asking for trouble) ).
Of course, yellowTAB fell out of this model rather a while back. Then suddenly got itself a, most likely, legal-guard (blinder): Magnussoft.
Naturally, I can only throw conjecture forth towards the legal status of Zeta based on what I know from a few years ago. Times change quickly, and yellowTAB has clearly demonstrated that they at least have the ability to modify the kernel code. So the only question to be answered?
Do they have a right to re-sell their products?
That is important, because if they do not, any of the third-party license holders could also sue yellowTAB / magnussoft and perhaps even their partners for back-royalties on their product inclusions, at the rate Be, INC charged + a min of $750 per unit fine.
BTW, that $750 would be required ( amount will depend on the nation of complaint’s legal proceedings as hedged with various international laws regarding copyright and intellectual property rights as pertaining to international and “virtual” businesses ).
If yellowTAB had any legal rights, I think they would WANT to make those public in this case, though just to the effect of saying: “Yes, we have the legal right to produce our product and distribute it.”
If a company says that, you have no fear from working with them. Even if it turns out not to be true, you may refer to that statement and not be harmed. Without such a statement, it is possible that lawsuits could, technically, be waged. However, if you recall the aforementioned response from the owners in regards to the intellectual property in question… they don’t care.. that is all yT is going on until I hear otherwise.
For the average consumer, it will only mean yT could eventually not be around, but that is most likely anyway. Buying Zeta will not endanger you in any way. But partnering or entering into certain contracts with yellowTAB would be very, very, iffy.
SO, Magnussoft exists to provide a company that is licensing from yellowTAB, so that, in the event of yellowTAB being sued, Magnussoft could still continue, meaning yT exists on paper now, Magnussoft is what happened to the physical aspects of it.
See? Now, of course, Magnussoft would have no reason to exist if yellowTAB had legal rights.
–The loon
PS: I had the legal right to draw into question the legality of the project I was working on at yellowTAB, and did so regularly. The only answer I ever got was, “we are trying, it would be cool.”
_____________________
EDIT: Clarification, inadvertently made it seem like I was releasing Zeta Beta 4, 5 & 6. And fixed a fully reversed sentence ( dyslexic ).
Edited 2006-11-14 17:08
Going by the information you’re providing, yT/MS are safe as long as JLGs heading Palm, but if Zeta becomes very succesful and when Palm goes down the crapper and gets bought up by Microsoft, they’re in big trouble.
PalmSOURCE (note, not Palm, the hardware company) got bought out nearly a year ago and is going to cease to exist as a brand, etc, shortly. ACCESS now own BeOS, not Palm.
Now, of course, Magnussoft would have no reason to exist if yellowTAB had legal rights.
Magnussoft existed long before the yT/Zeta deal. They have been distributing games in Germany for years.
To be more precise, archive.org’s wayback machine lists magnussoft.de since 2001, whereas yellowtab.de starts in 2002.
So… how’s it going with that Flash player you were writing?
Flash Player…
I had originally intended of making a GPL flash player work on BeOS. Which I did. Only problem is that the claims of functionality from the code were somewhat misrepresented.
That is not a show stopper, but it has put the work onto the back boiler as I struggle to keep my head above waters in the real world.
However, I have a fully planned development cycle involving other projects, mine AND those of others’, that will comprise components of a complete new flash-similar live content system. At first the generation will occur through a form of XML, with behavioral methods via in-line scripting.
This will be the raw language for handling many different types of interactive streaming data within the Serenity framework. I am hoping, soon, to come up with some time away from developing, to get the project better organized in the public world. The major hold-up in this arena was my dependence on BeOS Dano R5.1d0, and my investigations into best-possible integration with Haiku above ALL-ELSE.
This likely means I will be donating to Haiku soon, because FINALLY our interests have overlapped in several highly critical areas that my involvement would in no possible way cause any questions, because my long-gone PhOS and SuprDANO distributions.
The technologies in question are, naturally, XML parsing, SVG handling ( and related code ), SVG Rendering, and such other technologies that were, at no time, heavily ( or ever ) utilized by Be, INC for BeOS ( even unreleased builds ).
This is the order of events for the Haiku-compatible Flash Player, which will likely run on R5 with some libhaikuOS-compat.so for R5 Also, much is already in some state of operation:
-> Build synchronized, Haiku-only build environment
….60% or so, still trying to iron out some paths.
-> Core Facilities
1. Thread=*, *Manager, *Group, Smart*Group
…a Service=*, *Manager
…… Core facilities are components from my LoonTracker project, and are mostly complete.
2. XML Parser
… where Haiku or other code will likely be used
… to speed up development.
3. SVG abstraction ( C++ ideally )
… This WILL be utilized from libicon.a from Haiku
… as well as #
4. SVG Render ( ^^^ )
From there there is still the in-line scripting and the scripting language.
I have decided that I will need to do a lot of experimenting on the best way to create a set stream of actions to be performed entirely within the contexts necessary to provide compatibility with multiple paradigms for this type of functionality.
Meaning, the interaction framework, so the player can support FULL scripting. From then it is nothing but polishing and testing of our raw format directly, then some more simplistic file format translators before finally assembling everything needed to translate the raw stream data ( which would have been created by an up-front read-formatter ( so the data comes in as a set of streams among various threads and by multiple concurrent services, piggy-backing on a near real-time ( just constant time with async move instead of copy ) messaging system ( 99% complete ))).
All that means, is that the pieces of the system are there, they really just need individual polish, then assembly, then testing, further polishing, then expansion to handle formats other than an internal format. The idea is to achieve 100% CAPABILITY to support flash and whatever other similar formats their are.
I may get around to writing a flash module set, but may not. If so, you can rest assured that I will be looking for a MUCH better source of flash handling than what I found originally. Problem is, I am picky.. sometimes maybe too picky
–The loon
…but, even if Zeta disappears before releasing their API implementation of pthreads, someone else will do it for the Haiku project. Long live open source.
It’s strange that people think contributing is about kindness or lack of it. Even if Magnussoft act in their own interest, it would be disastrous for Zeta and Haiku to diverge too far.
Partly because they share the same developer base, but also if Haiku starts taking their user-base, they have a new option. Port their software suite, contribute the missing features to Haiku and become the best commercial distro. It might not be imminent, but if I were in their position I’d be keeping Plan B.