Haiku longterm roadmap - some ideas and clarity

Feedback Ideas
41

Hi Chavoux

The glasselevator list was a mailing list, where you can suggest “new” features.
The outcome is now “archived” here:
https://www.haiku-os.org/glass_elevator

What you said about Game development… it would be really cool to have good games on haiku.

But the thing is… at the moment Linux has a much more featurecomplete Media Backend. Not only 3d hw accelaration for some cards but also thinks like gstreamer and so on. Wich is a far far advanced piece of software like media kit (mostly used for audio. …) and so one. And also they provide a such “good” eco system not much of the gamedevelopers are interested in writing games for linux.

Also if haiku offers it it will not likely mean that game dev will port it to haiku … its simply calculation … is the affort worth what i will earn?

Also i would be very very happy if we finally can use the gpu for 3d accelration but also or foremost make use of the OpenCL and so one and software which is using this
-(not shure if it would be possible that haiku os could automatically spread the calculation load to the gpu… that would be interesting… no need to rewrite your app to use OpenCL :)"

Because thats, what people, which are using computer for media (graphics editor, video production and so one) are nowadays, are used to.
They now used to the fact that really heavy operations which needs a lot of calculation power are done nearly in “real” time using the gpu speed. They will never switch if you offer them haiku which “only” gives them the processor speed (so one effekt will take 10 sec. to render e.g.)

42

[quote=Paradoxon]
-(not shure if it would be possible that haiku os could automatically spread the calculation load to the gpu… that would be interesting… no need to rewrite your app to use OpenCL :)"[/quote]

This is not really practical. A GPU is not simply a CPU that’s somehow amazingly fast, or else we wouldn’t use CPUs any more. Instead the GPU is suitable only for a particular type of parallel algorithm, and programs must be written specifically in consideration of its strengths and weaknesses if they are to experience any real benefit.

Also, most people have only a single GPU. In this configuration doing more than the lightest compute work with the GPU will “stall” your graphics, as the GPU was too busy doing calculations to update the pictures. Some users find this intolerable. Professional design workstations have separate compute GPUs and graphics cards, so that the compute workload doesn’t interfere with the GUI but this costs even more money.

43

Spinach:

I’ve never had any stability issues with Libreoffice. It does everything I need from an office suite and is widely used and well respected, despite what you say. Maybe it doesn’t have some of the power features of MS Office but it has most of the features your average desktop computer / office user requires. Having access to G docs would be better than nothing but I’d much prefer a LO port because it doesn’t require an internet connection to use, its FLOSS so I trust it more than Google who tend to change interfaces and terminate services on a whim if they’re not taking over the world - see G reader, the ever changing GMail interface etc. The only time I use web apps is for tasks that require an internet connection anyway eg email, FTP clients etc. I shouldn’t need to explain the advantages of offline, open source software here.

Like you, I’m much more interested in a good DAW and video editor but we are in the minority wanting such apps. Many more people need to view and edit spreadsheets and word/OD docs. Haiku should aim to please the bulk of desktop users if it wants to attract more users and devs and this is one of the best ways it can do that.

You made it sound like I was saying Haiku needs HW 3D accel and the support of game devs to be successful and I wasn’t saying this at all. I only brought up gfx hardware, drivers and (Linux) games because the OP brought up 3D hardware accel and I wanted to make it clear, if they were unaware, just how far off Haiku is from being a competitive gaming platform and not to hold out any hopes for it in that capacity.

44

[quote=humdinger]

The user guide describes the basics of HPKGs and how to use the non-packaged folders. The package management is working and testable in the nightly images. Apps failing under PM that worked before and suggestions for concrete improvements can be submitted as bug/enhancement to the bugtracker, as with any area of the OS.
I don’t think there are that many problems with PM to warrant a pinned news item.

Regards,
Humdinger[/quote]

Good point(s). Thought it might help perceptions with the anti-PM crowd.

45

gstreamer is pretty terrible in execution and is deployed in a pretty muddled environment — linux distros tend not to have particularly clean media backends, i know this from years spent fighting it to work as my main edit station. glad that’s over!

46

good for you! my experience is not the same, and i’ve yet to meet anyone outside of a f/loss related message board who’s even heard of LO or OOo, let alone used them. i agree that trusting a web app is not the best idea, but the option’s there and is better known than the other two. and it just about works — will work by the time the beta hits.

it’s a niche. so was the oscar-winning lightworks system. you really cannot get everybody onboard with an os when there’s so much other general purpose stuff that works and is already deployed, but if you can attack a niche well, you can do a lot more and get much more developer support and user loyalty. and then other folks will port whatever.

it’s not far from h/w acceleration though. far enough that it won’t be in r1, but not far. also not necessary, even for brand spanking new videogames.

47

But now it’s better.[/quote]
you are literally ignoring something this person is saying they need, it’s not better, they’ve said why it’s not better.[/quote]

No I have and I recognize this but related to other OS this are not that much of a problem in Haiku. It’s like complaining about why my Truck won’t fit when you’re driving a small SUV :slight_smile:

When It comes to PM I didn’t like it but come to love it. The old way and new PM co-exist. Just have your Zipped programs places in NO-Package (don’t remember the name exactly). I have Gobe and a bunch of programs there.

What’s nice are that you can with 3-4 lines in terminal update your installation and I haven’t tested it but you can when you boot choose to boot an older version…

What we really need are better sound card drivers…

48

pm is fine, this has nothing to do with pm but with the apps and documentation included in nightly releases.

assuming a steady and constant internet connection is not fine. downplaying the difficulty some might have in getting a connection in the first place is not fine.

49
  • “A rescue/diagnostic OS needs good hardware detection, is a specialized field.”

That would be one argument in favour of basing an edition of Haiku on the Linux kernel. So you could have Haiku rescue OS (with Linux kernel) as an intro to Haiku - by not requiring any further download/install of apps; then you would have the full Haiku OS (with Haiku kernel). It would no doubt require extra coding work though.

  • Have any devs looked at whether Haiku might be able to make use of the extra features available in the Z shell - as opposed to using the bash shell? http://zsh.sourceforge.net/FAQ/

Here are some things that zsh is particularly good at:

Command line editing:
    programmable completion: incorporates the ability to use the full power of zsh's globbing and shell programming features,
    multi-line commands editable as a single buffer (even files!),
    variable editing (vared),
    command buffer stack,
    print text straight into the buffer for immediate editing (print -z),
    execution of unbound commands,
    menu completion in two flavours,
    variable, editing function and option name completion,
    inline expansion of variables and history commands. 
Globbing --- extremely powerful, including:
    recursive globbing (cf. find),
    file attribute qualifiers (size, type, etc. also cf. find),
    full alternation and negation of patterns. 
Handling of multiple redirections (simpler than tee).
Large number of options for tailoring.
Path expansion (=foo -> /usr/bin/foo).
Adaptable messages for spelling, watch, time as well as prompt (including conditional expressions).
Named directories.
Comprehensive integer and floating point arithmetic.
Manipulation of arrays (including reverse subscripting).
Associative arrays (key-to-value hashes)
Spelling correction.
50

Hi Syd,

I think this has already been done (BeOS on top of Linux kernel), but not sure how effective it was: BlueEyedOS and Cosmoe. I have never tried either of these; I just used a BeOS theme for my KDE instead. :-) It would be interesting to hear from anybody who have tried them and how they compare to Haiku? In general I got the idea that BeOS and Haiku has much tighter GUI integration with the kernel than is possible in Linux resulting in a faster and smaller graphical system. I suppose one of those projects might be the better choice for this instead of starting from scratch again?

As for zsh, I have only heard good things of it. On Haiku with its GUI focus, the shell is largely meant for tinkering and not so much for daily use, so I doubt there are many/any critical Haiku apps dependent on bash. Zsh could probably interface even better with the inbuilt capabilities of Haiku, so it could be a very nice alternative if it is not too difficult to port. Haiku has the advantage of being much less CLI dependent than Linux and having much less legacy scripts that depend on bash (which is probably the major reason why bash still dominates on Linux compared to zsh).

Cheers,

Chavoux

51

zsh has been available (through HaikuDepot even) for a long time. Come on, people, at least do a bit of research and maybe even use the OS that you make suggestions for…

Regards,
Humdinger

52

I should add that with the introduction of the Launch Daemon, Haiku does not come with a single shell script on disk. We could even remove bash completely and the system would still run. So, install the shell of your choice if you wish so. We also have fish and mksh available.

Regarding BlueEyedOS and Cosmoe, a good sign that the Haiku approach is better is that both project are dead. The sources to Cosmoe are still available, however, and were even updated by an Haiku developer so you could at least build them. Cosmoe shares sources with a very old version of Haiku and it would be possible to update it to a newer one. It would also be possible to update it to a newer Linux kernel where you can get some useful features such as a devfs (no need for udev to publish your device nodes), KMS (boot screen in native resolution and no need for X11), and the hardware support everyone has been requesting (the 2.2 or 2.4 kernels supported by Cosmoe barely had USB support).

So, if your thing is a BeOS-on-Linux system, your best way to prove the Haiku developers how wrong they have been for the last 15 years is resuming development of Cosmoe. I really would like someone to do that, as it would mean more implementations of the BeAPI around and more diversity and choice. But I also think it's not something the Haiku developers should spend time on.

53

Whilst devtmpfs does publish device nodes, it honours the Linux kernel’s “no policy” principle by neither providing them with user friendly names, nor assigning them useful permissions. So in practice for a desktop computer you would probably want udev so that you could decide on actual policies for how they’re named and accessible.

54

Two things the Haiku kernel can do by itself and without external help. It used to be the same for firmware loading, however the Linux team moved that to kernel side now.

Ok, so our "BeOS on Linux" thing would have to run udev.

55

Linux could choose to do these things (and did, under devfs), but it doesn’t today because they’re a matter of policy and so userspace is better placed to decide. In Haiku of course the kernel only has one userspace to serve, developed by the same team of people, so it arguably makes sense to dictate policy from the kernel.

Be’s design makes the names a matter of driver policy, so if you find the names assigned to devices inconvenient or downright annoying, too bad you need someone to modify the device driver to fix it. With devtmpfs, since it’s a “real” filesystem you can just change stuff, or more permanently you can write a new policy for udev, such as adding symlinks with your preferred names. This is no harder than writing a simple shell script, quite a lot less daunting than writing C++ kernel code and much less likely to cause mayhem if you get it wrong.

As to permissions, Haiku hard codes 0644 for all new devices, the behaviour of devtmpfs is to assign them 0600 and expect userspace to make appropriate changes. It seems strange to me to pretend that writing 0644 in the source code rather than 0600 is somehow real permission handling “without external help”.

56

[quote=spinach]pm is fine, this has nothing to do with pm but with the apps and documentation included in nightly releases.

assuming a steady and constant internet connection is not fine. downplaying the difficulty some might have in getting a connection in the first place is not fine.[/quote]

For me you are talking about Web++ loading a online page on default. I may have missed something but that’s the only thing I had to change. I don’t have a steady connection as I use my Haiku Laptop on the train to and from work so when I’m home I need to prep my laptop before going to work, these days it’s perhaps when updating the system.

What would be cool is an “internet of line feature” to save webpages with images etc.

I can’t image any other OS does it different, you always need to download stuff you want to use…

57

The problem is not that I have to download stuff to install. I have to download Haiku in any case in order to install it. The issue is that I can download Haiku when I am in town (where there is internet), but once I get to the farm (home), and install it, I can do nothing with it until I go to town again after a few weeks in order to install some application software. Or maybe less drastic (if I was living in town), once I have installed Haiku in my virtualbox VM, I struggle to get internet working (not Haiku's fault), and I cannot install it directly on my laptop (no EFI support yet). So I am stuck with a minimum of applications with which to test Haiku, no/very little help files, etc.

Having an image (like Senryu used to be) with most applications installed by default, or like many (most) Debian distros with a live version, will solve this problem. I will have something I can use and play with out of the box. And for those people with regular internet, they can install their favorite applications and remove the default applications they don't want. In the process any remaining bugs in Haiku are more likely to be found as well. I don't expect the nightly builds to include all the applications like this, but having something on a monthly basis that can be tested, will help a lot. And once you have the applications, if I understand correctly, updating Haiku will not require you to download them all over again.

58

The Alpha releases are usually bundled with a small selection of applications. However, the nightly builds are strictly for testing and bug fixing of the core system. What you describe is a good reason for Haiku to have a scheduled release cycle, even if it only once per year, like every November (the anniversary of BeOS Dano release). It would serve to keep interest in the project by putting Haiku into the public eye via reviews, which could attract more users and possibly developers who may otherwise be unaware of the project.

59

OK, I will try to summarize what we have said so far in this thread (and give some of my own thoughts)... But first one important question aimed at the current developers of Haiku that I think some of the previous comments suggested (and it might differ from person to person):
As a developer team working in your free time for free, do you see a user-friendly, usable for your average home computer user, Operating System working out of the box (like the original BeOS in its time) as your primary aim? Or do you see this only as a hobby OS that you can tinker on in your free time, learning interesting stuff in the process? In other words: if you have an interesting part of the OS that you can work on and that will be really cool, but not really critical from an end-user perspective vs a critical, but boring part of the OS that you personally could do without, but that your average user will want before the OS can be considered for general release, will a team member be tasked (or take it on himself) to work on the latter rather than the former?

Please read this in the right spirit; it is not meant as criticism for the great work already achieved. And I realize that getting the PM to work as well as it currently does, took a huge amount of developer time that was unanticipated. But I think it is an important question nonetheless to answer for yourselves. Nobody can blame you if you want to keep Haiku as a hobby OS. Some of the earlier comments suggested that this is what Haiku should be and always will be (e.g. NHFM). But as current and potential future users, it is something that we should also know, if only not to get up our hopes. I for one am convinced that the design choices of the original BeOS makes it an excellent primary OS for the home user (once it has enough good applications), but need to know if that is the same vision that (at least some of) the current development team have for Haiku.

For the rest...

  • It seems that most people here were in favour of the idea of a Debian-like division for the code: Stable, Testing and Unstable (except that we don't really have a stable version yet, unless we use the current BeOS R5 as such).
  • Binary compatibility with BeOS for Haiku r1, remains the most important immediate objective (together with modern hw support). But there is also a need to start looking beyond r1 (and maybe for some (new?) developers to start working on future features for r2). Current 64bit and GCC4 versions will fit here and should be part of the "unstable" branch (while current main Haiku will be the "testing" branch).
  • For the sake of backwards compatibility, future versions (r2+) should for the foreseeable future be hybrid systems with a GCC2 32bit compatibility layer. The aim should be that the situation should never arise where an OS upgrade breaks currently used applications. I.e. by the time that 32bit, GCC2 compatibility is dropped (r3 or beyond), there should already be better 64bit, new GCC4+, versions of all applications that are generally used (and for most specialist apps as well).
  • On Linux, compatibility is ensured by the use of distros where all the applications available for a certain distro are compiled and packaged for a specific version of the distro. By contrast, Windows have a situation where independent developers write a single version of the software that should run on a certain version of Windows and all newer versions of the OS. I think the Windows model is closer to the original BeOS model. But which model do we want for Haiku? The OS being Open Source, do we want proprietary, closed source, software to be able to run on it (making it more likely that software companies wanting to make money might target it as a platform, or do we want an essentially Open Source based application development model (similar to Linux and BSD)? The FOSS primarily option will have the advantage that we will have less need for backwards-compatibility on the binary level for r2 and beyond, because it will be easy to simply recompile all applications for the new versions of Haiku.
  • Haiku apparently no longer has the fast boot-up advantage compared to some stripped-down Linux versions. :-) Something that could be improved for r2? Or already for r1? This might simply be related to SSD hardware support for the Befs, however.
  • 3D graphics acceleration is not a requirement for Haiku r1, but many believe it should be part of a future r2 (including me). Gaming is important for a home user OS IMHO. Gallium3d might already be fitting the bill?
  • Bash and zsh are already working and should remain available in future versions of Haiku.
  • Although mobile devices are becoming more important, the desktop (and thus future Haiku focus?) will remain important for software developers, media production, (gaming?, office suits?, web browsing?) and other desktop applications?. A decent Office suit appears to be important and a port of one of the Linux options (Open/Libre Office, Calligra, Abi word with Gnumeric etc.) seems to be the best option for this. The consensus seems to be that in addition to the media production and development aspects, we want a general-purpose desktop.
  • There seems to be a general agreement that Haiku should aim for the home user instead of enterprise/office use. Therefore remain single user, k/b & mouse type Desktop OS.
  • Future alternative "Desktops" / User interfaces? My idea for one will need 3D graphics, but the current software emulation layers might be sufficient.
  • A request for full documentation to be included in the nightly builds of Haiku. Small change, big difference in user experience. A pinned news item on the homepage outlining "the state of package management"? Who will keep this up to date? I assume we don't want to add more to the work load of the developers. This information is already in the User Guide, so maybe just including it (and updating when needed) in the nightly builds should be enough?
  • Some requests for an annual/monthly testing (alpha) build with a full range of the most important apps included. Even with HaikuDepot available, this is still an easier option for many users to testdrive Haiku.
  • The idea to focus on a single or just a few specific hardware platforms where full hardware support is guaranteed instead of being a general-purpose PC OS. This has some merit as the original BeOS also started out like this with the BeBox (and Apple is still doing the same thing), before being ported to general IBM-compatible PCs. Raspberry PI and Intel Compute Stick have been suggested. Is this feasible/easy to do from the developers' side?
  • I think it is important to support at least one true PC-like laptop in addition to the previous suggestions. How will we decide on the best platform for this? I think some OEM agreement with a large company (e.g. Dell) will have to be negotiated then. There are 3 questions for this option, however: 1. Can Haiku with its current number of developers working in their free time, offer the level of support and bug fixes that such a OEM agreement will need? 2. What will happen with regards to other general-purpose PC's on which Haiku can already run? 3. How much work will it still be to get a completed Haiku r1 port for a single hardware platform (or only 2/3 specific platforms if we include the above low-cost options), compared to the current approach of general PC hw support?
  • The option of a small repair/maintenance/utility OS, while attractive, has 2 drawbacks: 1. It will need good out-of-the-box hardware support (already one of the issues with Haiku) and 2. the niche is already pretty much filled by Linux live distros like Knoppix and grml. Using a Linux kernel as a base for Haiku instead, will remove some of the advantages of the Haiku design, as well as require much rewriting, so it does not appear feasible. An alternative option would be to fork an existing project like BlueEyedOS or Cosmoe (but this will then be a different project to Haiku).

Anything I missed?...

60

“As a developer team working in your free time for free, do you see a user-friendly, usable for your average home computer user, Operating System working out of the box (like the original BeOS in its time) as your primary aim? Or do you see this only as a hobby OS that you can tinker on in your free time, learning interesting stuff in the process?”

Yes, I’ve been asking this for some time. Prepare to be blasted.

“It seems that most people here were in favour of the idea of a Debian-like division for the code: Stable, Testing and Unstable”

How many branches Haiku divides itself into is not that relevant. We don’t need a Debian. We need an Ubuntu.

“On Linux, compatibility is ensured by the use of distros where all the applications available for a certain distro are compiled and packaged for a specific version of the distro. By contrast, Windows have a situation where independent developers write a single version of the software that should run on a certain version of Windows and all newer versions of the OS.”

You forgot the Apple model. Every five to ten years, there is a two-year transition from one paradigm to the next during which two systems work concurrently. After that, compatibility is dropped with shocking abruptness, but within each major span of time, everything works, all the time. This happened with the 68000 to PowerPc transition (fat binaries) and again with the PPC to x86 transition (Rosetta).

“Haiku apparently no longer has the fast boot-up advantage compared to some stripped-down Linux versions”

Yes, well, it doesn’t take much to boot an xterm in a TCL/TK WM :wink: throw in a few apps you might actually want to use, and the formerly stripped down Linux slows down dramatically.

“The consensus seems to be that in addition to the media production and development aspects, we want a general-purpose desktop.”

The desktop will be whatever application developers wish to make it, and whatever users wish to use it for. A responsive, smooth environment is great for any kind of computing. “The Media OS” was always just promotional bumph.

“remain single user, k/b & mouse type Desktop OS”

As jessicah pointed out recently, there are ways to improve security without going multiuser. We are a three-person, six-computer family here, not counting phones and tablets. That may be extreme, I never could throw away and old computer that still works, but the old idea that there is one computer and hordes of people waiting to use it just is not holding water. If your kid needs a laptop for school, buy him one. We are not Nicholas Negroponte trying to kickstart the Third World.

Keyboard and mouse, certainly, including trackpads of course. I doubt we are anywhere near creating a proper touch interface.

“I think some OEM agreement with a large company (e.g. Dell) will have to be negotiated then.”

You mean we do what Be was unable to do and that Linux has not managed to do in thirty years? “Yes, we know that you get windows virtually for nothing and that Microsoft will kill you if you put anything else on your computers, but do it anyway.” I disagree. You are much more likely to succeed with a mom-n-pop business. But yes, we need a reference platform. Been saying that for years, too.

“Anything I missed?..”

Unless “Chavoux” is really Elon Musk and you want to one-up Shuttleworth with your own operating system, there are little questions like "Who is going to do this?’ and “Who is oing to pay for it?” :wink: