Actually, I am using BeOS on a laptop today. I take minutes for various organizations with GoBe, do some light gaming, and read some articles online. Not missing much online, that’s for sure.
Many old devices may not work today, but some would easily work just as they had 20 years ago. Depends on what you do with them. Teapot rusting through is a bad analogy. More accurate would be tea kettle you have to put over a stove vs an electric one.
My nearly 50 year old car never used leaded gas. It handles better on the road than any modern car, and even the cars that did use lead, they make substitute additives. Also, I can’t think of a car that isn’t legal to be on the road. Even horse and buggy are legal on the road. Maybe it’s different in certain… collectivist countries.
Neither the car, or BeOS, make me suffer. If a modern car company made a car that was a recreation of an old car, with modern conveniences, that would be cool too. (Except for stupid laws about flip up headlight covers or boot ornaments) I think that’s the idea, or an idea, of Haiku. Why try to change the goal of it?
And BeOS R5 had webcam support? Online storage options? More printer/scanner support? I was making a direct comparison between BeOS R5 and Haiku today. Not between Haiku and any other OS.
Haiku (today) is chasing after a moving target. BeOS R5 had its own, specific agenda. And, as far as I’m aware, was doing pretty good at doing so. It had a limited set of hardware it was going after and trying to be good at working on it. They even hired Intel employees to help them make it work better on Intel Pentium III’s, as I recall! That was an exciting move!
Haiku would do well to focus on what it’s going after right now and get the bugs worked out. Stop chasing the moving target. Stop finding new shinies to get dazzled by. If R1 = R5, then we need to get R1 out the door at any cost! THEN, we can chase all the new shinies for R1.5 and beyond… or whatever. Haiku needs to focus on incremental improvements, not trying to get on top of the latest thing. R1 has this set of features/driver support. R1.5 has this set of features/driver support, etc.
And I think system stability is of primary concern. A ton of features inside a house of cards on a windy day is not going to go over well.
If I had $1M right now and the authority to direct things, I’d say, “STOP!” Focus on what’s right in front of you. Make Haiku a reliable, stable OS, FIRST! What is the point of an OS that has a bazillion features and functions, if the OS is crashing or locking up or freezing or being completely unreliable at any given moment? Who wants to USE it, if you can’t TRUST it?
As it is, I still can’t use Mail! At one time, I could GET mail, but I’ve NEVER been able to SEND mail (or maybe it was the other way around, I forget). Like I said… isn’t 20 years long enough? We have GOT to start thinking like a team and stop going after our own itches to scratch, unless it’s NECESSARY to keep going in the same direction with everyone else, to get R1 released. I, frankly, couldn’t care how limited Haiku R1 was, if it was able to install/boot and run reliably. If I could trust it with my data. If I could browse the web and get/send my mail and a few other basic functionalities. The stuff we generally do EVERY DAY. Having a stable, reliable OS is the priority. Why are we not to that point yet? Honestly. That’s what’s so frustrating.
If we lack someone (or someones) who can work on specific functions of the OS that are related to making a stable, reliable Haiku R1, then we need to pool financial resources to find/get that person. Not in funding the next platform (and all it’s issues). Do we focus on x86 (BeOS R5 compatible version) or x86_64? That should be the limited range. One or the other. Not both… unless they can be developed simultaneously (they each get the same function/stability improvements, etc.), because they’re based on the same “foundation”. I believe we are spread too thin and too distracted to ever reach R1, if we do not start looking at R1 on one or the other of those two platforms as THE goal to reach, at ANY cost. If we are entirely selfish and ONLY want to do what WE want to do, then R1 will remain elusive. How many more betas? How many more years? Haiku is not “let’s make BeOS R5 for just ME”… Haiku is “let’s make BeOS R5 for EVERYONE!” We must ALL benefit or NONE of us will benefit.
Now, realistically, Haiku is significantly better than BeOS R5 in many ways. Be we need to know where to stop the feature-creep and focus on making an OS that we can boot and use on a daily basis without having to complain about it crashing or corrupting data or whatever.
If all we want to do is just keep doing what we’re doing and to H with how long it takes to get to R1, then let’s not fool ourselves (or anyone else) with false hope of getting to R1 in anyone’s lifetime. 20 years of waiting has taught me plenty. And that’s “plenty” I did not need to learn.
If people are realistic, we know that Haiku R1 is not about “shinies” (endless new features and capabilties). It’s about having BeOS R5 in modern form. But, we have to be realistic and realize you CANNOT have EVERYTHING you want, if you want ANYTHING… in a timely fashion. And 20 years to get a “clone” of BeOS R5… seriously? TWO FREAKING DECADES?!?
Maybe a lack of finances was partly to blame. Maybe a lack of manpower or the right people to work on the necessary components. I mean, if an open-source project with a low level of finances takes 20 years to reach beta… then I guess it couldn’t be helped, but I sure didn’t think we were THAT unmotivated over the years.
You can expect whatever you want. If there’s not enough people doing the actual work to fulfill the roadmap it’s not going to happen. This is exactly why we don’t have a time based roadmap. Only tickets that are defined as blockers for R1. This has been explained by the developers in several threads on this forum and I wonder how many times it needs to be repeated.
EDIT: It’s even explained by several devs in this very thread
Whatever you say would be valid if the project solely went on with volunteers. Now there is a person on the payroll, paid to do exactly this kind of stuff.
Edit: There was a deleted sentence here, which I am not sure if qualified as an insult, but still removed it as per the mod team’s suggestion just to be on the same page and not give birth to misunderstandings. Didn’t expect this to blow up this much though. Sorry everyone!
One paid developer is most likely not enough to guarantee an exact timeframe for an R1 release. And I think it’s good that the project is quite upfront with this, instead of making promises that can’t be kept. Everybody that’s thinking about donating can decide if they are OK with this or not.
Besides, I don’t think we would benefit from an exact schedule that much. Think about several releases of commercial software (OS and applications) that were not really ready and were rushed out on the market because of release schedules.
BeOS had its time as a commercial OS and it failed. I think we should be happy that Haiku exists as an open source non-commercial project that moves forward maybe a bit slowly, but also can’t die instantly like commercial endeavours.
What do you find unrealistic about the current list of bugs? The fact that it keeps gettting bigger over time instead of reducing?
One part-time developer, even paid, is not going to make that much of a difference here. Or, well, it does make a large difference, but the TODO list is even larger.
I think, on the contrary, that the current plan is realistic, in the sense that it matches with who is working on the project and what we can commit to it. It is disappointing that this means R1 is several years in the future, but it is realistic. We could instead make a more ambitious plan and then fail at it because we don’t have the workforce to do it.
Indeed. Anyone can look at the activity & contract reports I’ve written over the last two years, and my commit logs to match them to see that this is the case.
Not really the same track; Zircon is based on LittleKernel, Travis Geiselbrecht’s refinement of the ideas he championed in the NewOS kernel… while the Haiku kernel is essentially a fork of the last version of the NewOS kernel, co-written by Geiselbrecht et al.
In essence, LK/Zircon had much more time under Geiselbrecht’s control and my basic thinking here is that because he hit a winning formula with NewOS, it makes sense to take the ultimate expression of this winning formula, rather than some earlier stage.
Though what I’m very carefully not saying, now that all this work has been done to leave the Haiku contributors’ stamp on the NewOS kernel, is that this must now be ripped out wholesale. What I am saying is that if Haiku must change its kernel, it must be necessarily Zircon or no change at all. Now, I still think there are advantages to going over to a more recent kernel built by the same man on the same ideas, but this is not something I proclaim with conviction.
The word you’re looking for is Catch-22. “There was only one catch and that was Catch-22, which specified that a concern for one’s own safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions.”
I’m not paid to work on Haiku, but Waddlesplash is (and he’s not in France).
Also I think your tone is very inappropriate, there is no need to be so aggressive here. Especially for a discussion that was already closed almost a year ago, what’s the point?
Not really. These kernels were developped with different goals in mind. LK is a microkernel, NewOS isn’t. The reason Haiku picked NewOS is because it was the closest thing to the BeOS kernel available at the time. LK is improved for other uses, but by doing so, it drifts away from BeOS, and is less useful to Haiku.
