General First Impressions of an Absolute Newb

1

I hope you find this insightful…

First, a log of my experience so far. Note: I have never used beOS, or even heard of it until a few days ago. I have experience in windows, mac, and linux, but not much in mac.

-first heard about it on wikipedia a few days ago

-today, install disk failed to boot on my new Dell Inspiron laptop with Dual-core Athlon CPU, 4GB RAM, ATI Radeon graphics card.

-today, successfully installed in a small partition on my old Pentium 4, tried it out a bit.

Now for my first impression of the pros, cons (aside from general alpha-state bugginess) and a few general comments and suggestions.

Pros:

-lightweight runs, fast even on old hardware

-nice UI, more elegant than the X11 stack of Linux/BSD

-surprisingly, 3D acceleration works better here than on the Debian Linux on my laptop.

-seems to have a strong “breakout potential” of suddenly becoming relevant and mainstream (mainstream in the sense that linux and BSD are mainstream, not necessarily Windows mainstream), if only more focus was put on making high quality native-ui ports of recent opensource software.

Cons:

-Development seems to have misplaced (in my opinion) priorities. Very devoted to getting binary compatibility with 10 year old closed-source software, even if it comes at the expense of focusing on facilitating the porting of recent open-source software.

-I’ve heard that it’s using OpenGL 1.5 or something like that. I’m no expert but I think that means that programs relying on newer versions of OpenGL won’t compile, or at least won’t run, on haiku.

A suggestion: I think it would be a good idea, while this is in alpha, to get some “infrastructure” ports in place, of shared libraries such as native ports of the gtk+ and the Qt which call directly on haiku’s native windowing system, a newer version of OpenGL, etc. so that modern apps can be easily ported later on. In fact, I think that someone has already has made a port of Qt, as part of a full package port of KOffice which I saw on haikuware, so it is possible. I think that more of a focus should be put on that sort of thing than is put on it now, if haiku is ever to become relevant. Without software, the OS will not thrive. If the OS does not thrive, neither will native development. The only way to break the chicken-egg dilemma is through ports, and lots of them. Ironically, the only way to get native development thrive is by making as many ports as possible, in my opinion.

I’m not an expert of course, and not very invested in this, but that’s what I think, and you can listen to me, or ignore me, whatever you think is best.

2

Always good to get a pair of fresh eyes on our obsession. But if I want to run KOffice, I can do it on any of a hundred Linux distros not to mention the BSD’s. I can even use ZevenOS and get that nostalgic BeOS appearance. I can do it on Windows and OSX though emulation layers. What do I need Haiku for?

Porting backend utilities is one thing and must be applauded. But porting userspace apps would be a waste of our extremely limited number of developers’ time and effort. I want to see a native HaikuOffice that will play to Haiku’s strenghts and abilities. A word processor that knows how to park footnotes in extended attributes. A presentations app that creates a workspace for itself and puts itself on there as a replicant. Lightning fast database managers that leverage the built-in attributes and queries. The file system IS a database, what do you need SQLite for?

All that is just off the top of my head. All of it is certainly possible. But right now, all the people with suffcient skill to write this sort of thing are really busy hacking away on the OS itself (tip o’ the hat, guys). The third-party software now arriving on Haikuware is by lesser lights, mostly ported SDL games and small things written in yab (disclaimer: some of those are my own attempts). Perhaps things will look up when more languages get access to the Haiku API. I’m sorry, but C++ drives me into a rage. I think I could learn to live with Python or Lua. Once those get (properly documented!) hooks into the API, who knows what may be possible?

3

Thanks for sharing your first time experience with Haiku R1A3.

Some remarks/answers :

  • Please report your issue to install from disk on your newest machine on our Trac bug tracker at http://dev.haiku-os.org.
  • Binary compatibility efforts were time-consuming some years ago, but not that much now. The freed time was used to build a solid POSIX compliant support and to port several third-party *package* (see HaikuPorts project at http://ports.haiku-files.org)
  • There is no 3D *acceleration* yet :-), the 3D renderer is pure software currently.
  • Haiku relies on Mesa3D 7.4 as its OpenGL implementation. It supports up to OpenGL 2.1, but due to lack of hardware acceleration, using shaders while possible (there is even a shaders test program that runs) is not pratical. The issue is not OpenGL API version itself, but the heavy task that is to support hardware 3D acceleration. Until that eventually comes, there no point to export OpenGL 3.x or latest 4.0 API...
  • I agree with you that to get enough native applications momentum Haiku first needs software ports momemtum.
  • The Qt port is done as a third party open source project, and AFAICT is working well.
  • As a sign that we're conscious that ports are important for the platform future, we've selected porting SDL 1.3 as one of our GSoC projects...

Again, thanks for your feedback, and please fill a ticket about your install failure. It’s maybe fixable or a quick workaround could at least let you enjoy running Haiku on an actual SMP computer, which is in itself a way better experience.

4

Alright, signed up with Trac and ticketed the boot problem. I might see about ticketing some of the other bugs I found messing around with it on my old computer also, but I’ll have to get more familiar with the old comp’s hardware specs first, before I can make a usable ticket for any of those.

5

Quite surprising indeed… :wink:

Well, people work on what they want to work on. And porting software is seldom as easy as one would wish, particularly larger projects which often have very large dependancies, which in turn can be a whole porting project in themselves. I agree on you that ports of strong open source applications with a native gui would be wonderful, but someone has to do it.

I’m not sure how much effort is really being placed on that these days, AFAIK once r1 is out, beos binary compability will be gone in future releases (as in r2 and forwards).

Quite in agreement with you here. There’s been those who has expressed a dislike against ported apps, claiming that they hinder native development. What native development one might ask? In order for Haiku to attract developers there must be software on the platform to begin with for them to even be interested in using the OS. The important thing in native vs ported software is to make the native software shine when it comes to making good use of what the Haiku system offers. Even so, there will be certain types of programs which lends itself better to native software and others which might aswell be ports. And it’s not as if a port with a native gui (as you suggested) can’t appear/feel 100% native to an end user depending on what the application does.

Also it’s not even remotely likely that Haiku will ever have it’s own native equivalents of stuff like Libre Office, Blender, Inkscape, Gimp, Firefox/Chrome etc. There may be native apps which offers some of the functionality of the above mentioned, but likely alot of users will want/need features which a similar native application (if there ever is one) isn’t capable of offering. So to put it bluntly, Haiku will always be dependant on ports, might aswell accept that and see what can be done to make them appear/feel more native. But before that they obviously need to be ported at all.

6

very well said, Michel.

7

I had fun dealing programming languages but sometimes I got tired so sometimes I end up giving up on them. Lols…
buy soundcloud plays