I have noticed that since the release of Haiku R1 Alpha 3, there has been little or no noticeable change in the number of closed and active tickets! With all the change that has gone on in the last seven months, I assumed the number of active tickets would have diminished. As of the date of this posting, there are 14 closed, 42 active, and 56 total tickets.
Unless I am mistaken, all active tickets must be closed before the Beta milestone can be reached. If there has been relatively no noticeable change in the number of active tickets in seven months, how long will it reasonably take to reach that milestone? The time between Alpha one to Alpha two was eight months. From Alpha two to Alpha three took thirteen months. If the current pattern holds, we will not see a beta until December 2012!
If I am mistaken or confused then please let me know. The longer it takes for R1 to arrive, the less relevant it becomes! Haiku R1 is to become source and binary compatible with BeOS R5. This means that by the time Haiku R1 ships It will be 10-15 years behind the times. That is not to say that BeOS was not ahead of it’s time back in the day, it was. My argument is the longer it takes to release Haiku R1, the less “ahead of it’s time” it will be!
Operating systems are created in a burst of creativity and potential! In the beginning it is revolutionary not evolutionary! Systems evolve and adapt to new environments it finds itself in. Haiku is still reinventing the wheel so to speak, and has not evolved in significant way. It has been more than ten years since the Haiku project sought to revive BeOS! It is still not finished and I have to ask myself one simple question. When Haiku R1 is released, will it be so far behind that it is no longer relevant? Will it be so far behind the times that it would be another 10 years to get R2 up to today’s standards?
I love Haiku and I think she is a superb OS! The problem is time. A handful of volunteer programmers and one or two paid programmers isn’t enough to keep Haiku in the same evolutionary time frame as the rest. Especially since Haiku is based on 90’s OS designs and technology.
I know I am going to get much negative responses. I look forward to be proven wrong!
I agree. I love the Haiku-style, but I have to admit that there’s the need of new technology development… you reached 30000$ from donations, this starts getting serious
consider releasing soon the R1, than break BeOS compliance as soon as you can, or it will forever be a hobby os…
When we break compliance with Beos, does that mean Beos programs will no longer work on Haiku or Haiku programs will no longer work on Beos? Is there a reason that we must make so that Beos programs no longer work on Haiku? Can’t we keep backwards compatibility with Beos and add new functionality to Haiku at the same time?
“When we break compliance with Beos, does that mean Beos programs will no longer work on Haiku or Haiku programs will no longer work on Beos?” I would guess both would be true! Since Haiku is a reimplementation of BeOS R5 both BeOS R5 apps will fail to run on Haiku R1 and Haiku R1 apps will fail to run on BeOS R5!
“Can’t we keep backwards compatibility with Beos and add new functionality to Haiku at the same time?” Yes, it is possible to do that. I do not have any inside knowledge of any plans to do so, but I think that would be their goal.
If you remember, backwards compatibility was a major reason why Be Inc. did not use any of the OS’s at the time! They believed that backwards compatibility adds cruft and bloat to the OS and makes it harder to debug!
My opinion is that Haiku R1 should be backwards compatible with BeOS R5. Haiku R2 should be a clean break from compatibility with BeOs while adding new technologies! Haiku R3 should be backwards compatible with Haiku R2, while R4 is Backwards compatible with R3, but not R2 etc. This way future versions of Haiku are not burdened by backwards compatibility all the way to R1, but just one version back!
I see your reasoning, but what about apps that get abandoned without the source code. Windows has backwards compatibility all the way back so that people can still use the software from the companies that long died out. What if an installoptionalpackage was made to remap the calls from previous versions. This way all the old calls will be deprecated but still be available until a newer version of software is out.
“I see your reasoning, but what about apps that get abandoned without the source code.” A compatibility layer can be added as an optional package to give backwards compatibility for those who need it. It would be a project unsupported by the Haiku team that would bridge the gulf between backward compatibility and forward innovation.
Windows has backwards compatibility all the way back so that people can still use the software from the companies that long died out." Yes, and that is one major reason for proliferation of Windows viruses! Windows is forced to keep ancient ABI’s and shared libraries so that apps written many years ago may run on today’s Windows OS.
What if an installoptionalpackage was made to remap the calls from previous versions. This way all the old calls will be deprecated but still be available until a newer version of software is out." That was my first point. I have no problem with keeping backwards compatibility as long is it is outside the OS and installable as an optional package.
[quote=ddavid123]
My opinion is that Haiku R1 should be backwards compatible with BeOS R5. Haiku R2 should be a clean break from compatibility with BeOs while adding new technologies! Haiku R3 should be backwards compatible with Haiku R2, while R4 is Backwards compatible with R3, but not R2 etc. This way future versions of Haiku are not burdened by backwards compatibility all the way to R1, but just one version back!
So what do you think?[/quote]
We should be so lucky as to have sufficient buy-in for backward compatibility to be a problem. Realistically, if we do get such buy-in, we will want more than one rev’s backward compatibility. Think of the effort wasted having to continually update whatever application have been developed with a one revision compatibility window.
Firstly, backward compatibility is good way for developers: lesser software to update. So backward compatibility is preferred as for developers as for end users.
Secondary, windows viruses works due to shining holes in windows internal safety. Firefloor must fix that. It is like a firewall, but internal.
Thirdly, old software support is necessary for large business. Business is money, money is method to happy life.
If Haiku will not have backward support - it will be hopeless as Windows alternative.
PS: Do not forget about Fallout 1, HoMM 3, Raptor and other things like this. Also, try to start some 16 bit apps (cardifile or schedule+) in win 4.x+ and see, what happens.
Backwards compatibility is criticle. The utility of the operating system is the vast amount of applications available for the end-user. Older apps are often times proven apps. New apps are often subject to errors made in the past. It would be a mistake to dump the past for the possibility of a future. New developers are not as focused on productivity as those from the past. Take it from someone who’s been writing software for a very long time.
Although backwards compatibility is indeed critical to the survival of Haiku as a viable alternative OS, the backwards compatibility is also what is currently crippling it for app developers. The dependency on the old and very outdated GCC2 makes porting software to Haiku a difficult task. The GCC2/4 hybrids do indeed appear to solve this problem, but it’s by no means a cure-all, as GCC4 software compiled for GCC2/4 hybrids may not run on GCC4 or GCC4/2 hybrids, and vice-versa. The difficulty with Haiku, is that to continually support BeOS software, it needs to be a GCC2 based system. This creates a vicious loop, where developers can’t compile their software on GCC2, or cannot be bothered with the vast amount of effort required to get it to compile, therefore newer software doesn’t get ported. Without newer software, Haiku doesn’t get a significant userbase and attract new developers, meaning it fades into obscurity.
The only way out of this loop is (IMHO) using a GCC4/2 hybrid, in which modern software gets developer and API/ABI priority, relegating BeOS “legacy” software to an imperfect and possibly crippled GCC2 compatibility layer.
Of course, this is merely a point of view from someone outside of the project, and i’m sure developers can give valid and logical reasons for the official GCC2/4 hybrid support. But IMHO it just seems to cause headaches for app developers
It has been discussed that the Haiku package manager could solve the issue of backwards compatibility. Here’s how it would work.
When an executable is started by the app server the ELF file format is checked to see if it
is a GCC2 or GCC4 binary. If it is a GCC2 then a GCC2 library path is used to resolve
the shared library calls and system calls. If it is a GCC4 then the GCC4 lib path is used.
The GCC2 libs would be frozen and little development would occur. This would preserve some level of backward compatibility. Right now Haiku A3 has some backward compatibility but it’s not great. If you look through Haikuware you can see the results of testing against A3. A lot of classic BeOS apps do not run. Unless they are recompiled, that situation won’t change much.
But anyway, the package manager is one possible solution. It is not currently implemented this way but it was discussed as a possibility.
Thirdly, old software support is necessary for large business. Business is money, money is method to happy life.
Currently there is only one business that uses BeOS software on Haiku. It is for music scheduling and it runs OK. So old software is not a business issue for Haiku.
I just love the argument about needing to be backwards compatible for all the old BeOS software that is being used by the millions upon millions of users of those apps. Really, this whole idea should be used by a comedian in a stand up routine. If there were that many people using BeOS and that BeOS software, BeOS would not have gone out of business.
I don’t know that that is “The Issue”. The issue is functionality. The older apps have a track record(i.e. “They WORK”). While it’s true that KOffice will not load on Alpha 3, It does run if you juggle the library paths and gcc4. I don’t think that is an answer for a novice. Choices must be made in any operation. Newer isn’t always better. The bells and whistles will come later.
What ever is fielded has to work. The downloads from Haikuware have to work. They need to work every time, even for novice users.
I can make most anything work after doing it for the past 33 years. I am not the public at large. It is important that the point and clickers are mollified. So I say again, if it doesn’t work out of the box it can’t be part of the distribution.
I have BeOS all the way back to Version 3 Professional. Haiku on a P4 or better is my goal for each recipient. I fear the Computers people throw my way don’t always meet that standard, so I work with what I get.
Let’s get back on point.
The Older apps are a jumping off point. They give Haiku a proven base to build on. Selling the need for another OS on the market has to come from the facts - it works, its professional, it has utility (ie from music mgt/creation to Text Processing).
The Interface is dated but not so much. Vista and Windows 7 are little changed from Windows 95 or NT 4. MS Metro ® is junk as far as most of my clients are concerned. Apple isn’t much better. Being on the cutting edge isn’t as important as reliability. Stanford University’s HiStar kernel is cutting edge but has no interface or real distribution.
The difference is clear, Haiku has apps that work!
It’s time to move past the Alpha Stage with the Kit Browser’s HTML 5 coming soon, I hope. Start with Support for Cloud Apps if you must have the new and their support. Poorman makes Haiku easy to set up as a dedicated web server.
