[haiku-development] Re: AW: Re: What's the status of Haiku?
- From: Edward Robbins <edd.robbins@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 30 Aug 2014 12:58:28 +0100
On Fri, Aug 29, 2014 at 9:21 AM, James Leone <linuxcpa@xxxxxxxxx> wrote:
>
> Well the package manager delivered two surprises.
>
> First one is how well it works if a package is available. It will be a
> dream package manager once we have a full suite of packages.
>
> The second surprise is that package development has appeared to have
> declined since it was put in place.
>
> The truth is that the new package manager locked up the system to a point
> that package development is too tedious to work on.
>
> The number one issue Haiku faces is manpower. But problem is that the
> number of people that can help out is limited. I'm not speaking in the
> classical general sense however, there are some people with intermediate
> skills that under less restrictive circumstances, could probably pitch in
> by compiling applications for people to use.
>
> I'm one of those people. I've got libX11 (1.62) and Python 3.4 compiled.
> But going further is proving difficult because there are just too many
> Python modules that are dependencies that require a writeable /usr
> directory to push forward.
>
I think you expect the bar to be too low. This is what caused the plethora
of ports that were unstable and didn't work after small changes to haiku,
often distributed in zip files etc pre package management, and why we ended
up with most software on haikuware being unusable. There actually was a way
to do things properly back then, using the old haiku ports system, but lots
of people ignored it, or went the easy (but broken) way.
I'm somebody who actually, when I get the time, does have the skills to
port software to haiku, and I found the previous situation extremely
annoying (though the old ports system was pretty good, but not many used
it). If you look at ports systems in other OSs - FreeBSD, OpenBSD etc,
gentoo linux, arch you will find that the haiku ports system retains all
the features and is just as easy for developers to use, but is better
documented, neater and handles most of the edge cases elegantly (where the
others can be a mess) and you end up with _very_ neat packages afterwards.
There is a little extra complexity in getting directories etc correct, but
just dumping stuff in /usr or whatever was never the correct way before, it
was just permitted.
> But even before that...its a struggle the whole way, even with patches
> ready. So...the more difficult it is to help...the less help we will get
> from the community.
>
This is mad. I've found that people for the most part are unbelievably
helpful and patient. Just go on IRC and ask, or start doing pull requests
on bitbucket.
> It seems that Python wants a /usr directory and the inability to create
> one has cost numerous hours.
>
> > > Haiku needs a project manager but that isn't a fun job and tends to
> cost quite
> > > a bit if we wanted to hire someone.
>
> > As you already noticed, this is an open source project, and it just
> doesn't and cannot work this way. Either the developers are focused, or
> they aren't. Other than pleading them to focus (or pay them to work on
> something in particular), there is nothing one can do. We do have a pretty
> good plan of what there is left to do, anyway.
>
> I hate to say this but the lack of manpower here has been created by us.
> The catch 22 of the package manager is that it works beautifully but the
> requirements presume tge community has a higher skill level or much more
> time then it has. End result is that we haven't kept pace with software
> that is available. Tge overall effect is a decline in user moral.
> Developers get the misimpression that Haiku is working against them.
>
As a developer, I have to say this is not true, the bar is not that high
for package management. Most linux, *bsd, windows etc developers are not
porting software all the time, and you shouldn't expect that the average
haiku user can do so either.
The difficulty for me as a developer is that while I use a lot of command
line only software and those are mostly relatively painless to port to
haiku, porting or developing GUI applications is much harder, because
ultimately I'd like my software to be available in multiple places. I have
ideas of writing, e.g. a calendar app for haiku, as a native app, which is
fine as it doesn't need to be cross platform. But if I want to write a
general piece of software for desktop computers, especially a commercial
application (i.e. in my work life) I want it to work on Linux/*nix/*BSD,
Mac OS and maybe even windows as well, and while I as a developer am really
keen to see haiku support (especially if it is for free) there's no real
way for me to do that and justify it, so haiku gets ignored.
QT5 support is great because it allows me to get haiku support for free,
without spending any meaningful amount of extra time on it, and I can just
say "hey look, it even works on haiku as well". But then I feel bad because
it isn't native. I know that I am really talking about the chicken and
egg/developers and users problem here though.
What haiku needs is to gradually get all the applications that are needed
for day to day work. Once it has a stable, modern web browser (almost
there), office, some media etc apps it will start getting used a lot more.
The web browser has been the biggest issue for a lot of people for a long
time. Contrary to the discussion that has been going on for the last week
or two, I don't believe it matters if the OS doesn't work on some hardware,
because people will simply use it if it works with their hardware or get
hardware that works, and as time goes on people will want to use it and
you'll find that some people will just fix drivers because they want their
own hardware to work. I actually chose my last two laptops largely because
I wanted them to work well with haiku, and then invested a fairly large
amount of time porting software so that I could do most of my day-to-day
work in haiku, and I don't think I'm alone.
Ed
Other related posts:
