Linked by Thom Holwerda on Sat 19th Apr 2008 23:39 UTC, submitted by TheNerd
Thread beginning with comment 310629
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by TheNerd
by bbjimmy on Mon 21st Apr 2008 04:37
in reply to "RE[3]: Comment by TheNerd"
1) First of all, you need to acknowledge that this is pre-alpha software, and that by definition it is not feature complete, nor fully functional.
He does ... did you look at the screenshot of the about window?
2) The VMware graphics driver is left out of the official nightly builds because it does not fully work when you go into KDL. Because the nightly builds are meant to be for testing/debugging, providing functionality in the kernel debbugger is more important
Sometimes testing requires video that works.
I think you are missing the fact that there is a very specific intended audience for the nightly builds, and that this audience is expected to understand what pre-alpha software is and will therefore not jump to the kind of conclusions that your question implies. That's how we portray and position the builds, not as demos or trials.
You seem to miss the point that the superpack does indeed position the software as pre-alpha, it just lets the software be seen by a larger group than your private little developer club. This is open source software. If you don't want others to try it, even pre-alpha, than maybe you should quit developing it and forget it exists. You can't control who will see your work unless you develop private closed source software.
Good point: but you do not need to create a distro for this. An applications pack the users can download would perfectly serve this purpose, and it would save you (and me) from the burden of having to deal with branding, trademarks, guidelines, etc.
Actually, he does. This is the only way new testers can test and report on broken software.
I do see your logic, but someone who will not spend time to setup their own development environment can hardly be considered as a serious candidate for Haiku development.
I detect some HAIKU / BeOS snobbery here. Who are you to say that there might not be a very talented and willing developer that will overlook HAIKU because the current devs are insuring and insisting that it is so damned difficult to get a working development environment up and running? You seem to think that a potential developer is willing to spend hours setting up a development environment when he does not even know what HAIKU is all about. GET REAL
RE[5]: Comment by TheNerd
by koki on Mon 21st Apr 2008 05:37
in reply to "RE[4]: Comment by TheNerd"
He does ... did you look at the screenshot of the about window?
I don't think you understand the point that I am trying to make. It is not the lack of disclaimers, but the fundamental fact that there is an intent to provide an end user experience from pre-alpha software that is problematic. You are creating an expectation that Haiku
is not ready to meet yet.
Sometimes testing requires video that works.
Yes, and that's exactly why the Haiku developers decided to remove the VMWare video driver from the official builds, because it is not fully functional in KDL.
Actually, he does. This is the only way new testers can test and report on broken software.
Why? A software package that people can download would serve exactly the same purpose. As a matter of fact, that's what the Haikuware superpack started as at the beginning. Now that I think of it, it may be even be possible for Karl to work with the developers so that such an application package can be included as an option in the Haiku build process. This is what third party application maintainers are doing (ie., Vision, Wonderbush, Firefox, Pe, etc.), and it works well.
I detect some HAIKU / BeOS snobbery here...
You are probably reading too much into all this. This is open source: the code is online; the development tools are available; there is also a reasonable amount of documentation available on our website; and we have a very friendly and responsive community on mailing lists as well as IRC happy to help. Any eager developer would most likely be able to get started with development with relative ease; your mileage may vary depending on your skills, but it is not as difficult as you want to make it sound.
According to you, the superpack is intended to address people not willing to make the investment currently required to get started. From what we have seen so far during the life of our project, anyone not willing to make such an initial investment is very unlikely to become a serious candidate for Haiku development.
HTH.
RE[5]: Comment by TheNerd
by petterhj on Mon 21st Apr 2008 09:45
in reply to "RE[4]: Comment by TheNerd"
"Good point: but you do not need to create a distro for this. An applications pack the users can download would perfectly serve this purpose, and it would save you (and me) from the burden of having to deal with branding, trademarks, guidelines, etc.
Actually, he does. This is the only way new testers can test and report on broken software. "
Thats bull. He could easily have mad an application pack, or better, a BFS intialized VMWare "disk-file" with the increased size and applications. Then he just could have made a new VMX file with this in mind, so that people could download the vmware file and just place the "official" haiku.vmdk in the same folder. No need to update the pack as often, but only when new software is to be included.
But I guess it just isn't as "cool" as to be the one in charge of the "first Haiku distro" and so on.




Member since:
2005-10-17
Hi Karl,
You raise several points here, some of which are valid. Let me try to address each one individually.
Haiku is still a moving target; the nightly builds that you use to create the superpacks/senryu not only are far from being stable, but many times they break, sometimes pretty badly. This is definitely not a good base as a tool to demonstrate the capabilities of what Haiku is expected to become in the end, nor will it give any fulfilling experience to anyone who may have any kind of end user experience the expectations. The moment you say that you want to "to provide users with a more fulfilling experience," you are creating an expectation that cannot be currently met. Which is why we do not have demo/images CDs yet.
1) First of all, you need to acknowledge that this is pre-alpha software, and that by definition it is not feature complete, nor fully functional.
2) The VMware graphics driver is left out of the official nightly builds because it does not fully work when you go into KDL. Because the nightly builds are meant to be for testing/debugging, providing functionality in the kernel debbugger is more important.
3) AFAIK, audio and network do work. But if they don't and you know what needs to be done, please provide a solution through the Haiku mailing list or Trac, to see if the solution can be included in the nightly builds. This is the best way to help Haiku.
I think you are missing the fact that there is a very specific intended audience for the nightly builds, and that this audience is expected to understand what pre-alpha software is and will therefore not jump to the kind of conclusions that your question implies. That's how we portray and position the builds, not as demos or trials.
IOW, at this point in the development of Haiku, the nightly builds are not designed or meant to impress anyone, although they are definitely impressive how good they can run at times.
Now, I think this is a valid point, and I would definitely be in favor of addressing it if possible. May I suggest that you work with Sikosis (who manages our nightly builds) to see how this can be fixed?
Good point: but you do not need to create a distro for this. An applications pack the users can download would perfectly serve this purpose, and it would save you (and me) from the burden of having to deal with branding, trademarks, guidelines, etc.
I do see your logic, but someone who will not spend time to setup their own development environment can hardly be considered as a serious candidate for Haiku development.
I do acknowledge that there may be ways to make it easier for developers to become productive sooner though. But then again, may I suggest that you try to work with Sikosis and the other Haiku devs to see what viable options can be considered to address this from within the project?
The purpose has its logic and is not the problem per se. The problem is when you put this in the context of the pre-alpha software that Haiku still is, and the various goals that the project has set for itself with regards to quality, branding, etc. That's when you start seeing the discrepancies between the (good) intentions and the potentially negative ramifications.
HTH.