karl wrote:



The mess is not the Haiku projects doing directly, The mess is that developers of 3rd party software don't always follow guidelines. In this particular case however no guidelines were given so the end result was linux like anrachy.No system equalls a bad system.

I will be repacking apps and creating a page with links and I will be hosting all tested software and link it back to haikuware. My intention however was to offer alacarte' and to offer a rather large unzipp collection of software in a iso or raw format. download, unzip and go.


The idea here is to stop this problem before it gets worse, and I have tested many Beos apps that don't work properly on BeOs either and the same goes for windows.

The core issue is getting a handle on the situation and getting the issues resolved. Many can be fixed with repacking and directory adjustments.

I personally think the compatability logo's are needed, a basic measure of quality is a good reassurance to anyone considering using Haiku.

Really, you should first ask permission if you're going to do something like this. First from Haikuware, and then from the individuals that submitted the apps.



In part it is. The original goal of Haiku was to achieve binary compatibility with BeOS R5; this was dropped. Even an optional R5 compatibility package was removed. All BeOS software here should have been compatible with Haiku R1, at least that was the intent of Haiku when I started this website.

Secondly, Haiku releases two different versions. GCC2 & GCC4 (well actually four), yet the 'official' flavour is the GCC2 Hybrid. Confused? So, whose fault is it that developers develop GCC4 apps that don't work on the official hybrid but work on the GCC4 builds? Well, that's interesting. On one hand you could say the developer, on the other hand you could say Haiku because if Haiku only had one official version of their operating system, there wouldn't be this mess in the first place... If they release different versions of their operating system (and I'm not talking architectures), they themselves should ensure that GCC2 software will work on GCC4 builds, and visa versa. To me it's a mess. You don't see this problem with Windows or OS X software. You download it, and it works. There may be a problem with x software only running on WinXP, or OS X 10.5.3, but you don't have to have knowledge of which package/zip file you have to download and which Haiku OS the software will run on.



Will you be repacking the software when A4, Beta 1, 2, RC1 RC2, and R1 (e,g) are released?? I can guarantee you a lot the software you repack for A3 a) won't work b) will be broken on future releases due to core OS changes between now and then.



I can understand a compatibility logo for legacy BeOS apps here, because they were two different operating systems. People submit Haiku software here, and it should just work on Haiku. Again, having a software site dedicated to Haiku software, and then having a compatibility logo against its own brand is rather silly - sorry. A 'verified working' logo on the software may be more suitable, but even then the information won't/may not be accurate until R1 is released - at that time, yes it's a good idea.

+1 - I agree

Not sure because I go to app page to download the program and would not like checking out a list first to see what works or does not but I see your point.

If possible, fixing the popular, top 100 (or 200) downloaded apps with repackage and haiku compatible logo would be enough since they may account for 70% or higher of the downloads.

+1 - by R1 it could be that many applications no longer work and would require some dev or porter to update it. Fat bundles should let programs work much longer but they can still end up broken by time of R1 if not updated every 6 to 12 months.

Easy fix. Some other user(s) can test and leave a comment to say who is right or wrong. =)
In response the application would be fixed if possible (fat bundle) and the page would then get updated to be accurate.

I also think Sean removed the lib folder maybe seeing it redundant having SDL libs included with app and because he is "quickly" testing lots of apps might have not realized it. Mistakes happen when rushing.

+1 - that of course is another way to do things but leaves the onus on the porter to fix the issue

Another option is to have tester-packagers who would go through checking applications and repackaging them with libraries and proper folder layout. That way the burden would be shifted from you or the porter and put onto other volunteers. Of course that means giving higher access to these "helpers" to replace files and maybe add in Haiku compatible logo to the pages.

Another option is to offer another version on the page made by a different submitter. ie, additional downloads from others. Say I see a problem with a game so I port a newer version or repackage the old to fat bundle then would be nice to somehow add the download to the original page rather than make new entry. My download and the other downloads on the page could then be rated by users.

Should not rely on developers or porters to do this because may never get done. Maybe better to get some tester-packagers or allow others to provide other download versions for the application.

=)
Haiku is undergoing major changes which will break things and will not become stable until late Beta. Fat bundles should add some additional stability because the program will use the same libraries it was linked to in the first place. I too was getting very tired of having applications working one day and then later on be broken. Not fun and frustrating.

Better to have somewhat bigger downloads and installs than having to constantly deal with broken apps. Maybe post-R1 we can move away from fat bundles but that remains to be seen because much more complex and requires a very well-thought out and intelligent solution to handle thin bundles.

They do this with the nightlies but A1, A2 & A3 are only released as gcc2hybrid - one version. Still, just providing 4 different nightly versions confuses people. That's why they maybe rebadging the gcc4 nightlies to something like Walter so people realize that gcc2hybrid is Haiku and gcc4-hybrid is Walter. I always thought that if you run gcc4 programs you would want a gcc4 OS but Haiku project wants everyone to run gcc2hybrid no matter what. The gcc4 OS versions are actually for testing purposes only. Also, since lots and lots download the gcc2hybrid releases (A1, A2, etc.); we should make sure everything works right for them.

It may or may not. Depends how compatible the code stays in future releases. Fat bundles might allow the programs to continue working to a certain point. Any fat bundle broken on A4 or future versions would require recompile and maybe code changes from developer to fix.

Would be nice but not going to happen. The OS has to change to be improved upon. Libraries have to be updated to bring new features as well as security and bug fixes. These can always break an application from working on Haiku. Price to pay for making a better version of the OS.

I see what you mean here but I think testing against each release is good to know what still works and what does not. Program X worked on A1 & A2. Does it still work on A3? Good to know without having to download and test Program X out yourself. At every major release (A1, A2, A3, A4, etc.) compatibility should be checked to see if the applications are still working or not. If not, then developer would have to fix it assuming these were packaged as fat bundles.

Edit:
Removed Sean quote & response, very slightly fixed the wording on some of the post

PS
Should discuss how to make things work better, ie improvements and solutions in another post. I mention a few in this post but should rehash them elsewhere to better track the ideas.

I agree, I am taking notes on things for the development version. For instance, Axel Doerfler didn't think compatibility logos were a good idea, and suggested people leave comments. His point was, that at BeBits, the version number of the software is tagged in the title of the comment. This is something I'll have to incorporate, because it's a great idea.



Problem is, it requires people to do work. I've seen so many fly-by-nighters that promise you the world, do a bit, and then they're gone! 'I don't have time' - real life caught up' bla bla... So, it should be done, but who will do it?

karl wrote:


Just a note of contention on your last comment. I have been quietly following haiku since OpenBeos started. I have time over the next few weeks to handle this task so I will handle it. Will I handle it at r4 and B1 or B1 may be the next release? I don't know. that siad, it is time to get a crew of folks to help handle this and maybe haikuware should encourage using the haiku comapatible logo.

Windows has a certification program, Linux has the base linux program, Mac has a certification program.

Fact of the matter is, These labels are like Iso standards nothing more. Just a way of saying reasonable process has been applied to creating consistent content.

BTW I got the reply back from the Dev's. config folders go on

boot/home/config/ app name here

not

boot/home

Please if you can encourage the porters, developers to correct this its one of the big holdbacks for many applications to get a haiku comptiable logo.


Sean

SeanCollins wrote:

I am fairly sure that Haiku puts them in /boot/home/.config/application-name by default. I can tell you that we do not choose the location ourselves.

To put them in /boot/home/config would make that folder kinda messy. It already has add-ons, be, bin, boot, data, lib, settings. Imagine adding tons of applications to the root config folder. I cannot imagine this being right.

Maybe that person meant /boot/home/.config instead? Like it is now.

Hopefully you did this through mailing list post so other devs & users can check and see the answer too. Link? If not, please post it to Haiku mailing list.