VISION and a ROADMAP for HAIKU

Feedback Ideas
21

Thanks humdinger for this clear statement.

BTT:
comparing AROS and Haiku, I only see that AROS as well as Haiku needed too much time to get mature. All other aspects are quite different, IMHO. Being part of the Amiga community since the early years of the demo scene 1988 I can say that the Amiga community is too split up between “the red, blue and AROS pill” and the ongoing Amiga Next Generation OS war. AROS will never gain enough momentum to be the leading AmigaOS and “forge innovation”.

For Haiku my personal “wet dream” is a full blown 64 bit UEFI OS which maintains BeOS application compatibility as long as possible.
But as a first step I would like to see a Beta release this year, so that the developers can focus on new features :slight_smile:

22

My point of view as a developer: Haiku is free software, and it becomes what developers want to make of it. “wet dreams” are nice and all, but they are not going to happen if no one is interested in actually writing the required code.

It can go in many directions: improving our existing drivers for more hardware support, throwing away all the kernel and running on top of Linux or some *BSD Kernel as the Cosmoe project does, improving the web browser or writing/porting new apps, etc.

Over the last 2 or 3 years, the focus for me has been on stabilizing the OS (with my unfortunately limited skills for debugging the most low level stuff), making the web browser more useable for my daily needs (that was the main reason for me to keep another OS running), and then a lot of work on the side of HaikuArchives and HaikuPorts to show how many apps we actually have (not a lot in absolute, but still a reasonable number for such a small OS).

Yes, the progress is slow. What did you expect from a small team of people working 2/3 hours a day in the best days? Of course it goes much faster if you hire people full time and they can focus on what they are doing. So, all projects running this way are doomed to slow progress.

I don't think, however, this is a problem. Haiku is still my operating system of choice and none of the alternatives came quite close, despite them rewriting large parts of their user experience at each (or every other) version. Part of what I like about Haiku is that it reached a good balance of simplicity and efficiency in its design, and that it does not need this much changes on that side. I can see how it is frustrating to see it looking "mostly ready" from that side, and still, not much progress seems to happen because a lot of the remaining work is deep in the system internals with little visible changes, or boring system administration tasks.

Anyway, if you can write some C++, you are very welcome to write some code that brings Haiku in a new direction. If you can't, well, you'll have to learn, or convince other people to write the code for you. This can be achieved, with some persuasion and well-written bug reports/enhancement tickets. If you do all the design work, or data collection to pinpoint where and when a bug does happen, it is already more than 50% of the work. That makes it more likely someone will come and do the remaining 50% of writing the code to actually fix/make it work.

Thanks to all of you for reminding us that there are users around and that they do have an idea of what HAiku should be. And sorry we can't listen to all the ideas and go in all the directions in the same time.

1 Like
23

[deleted double post]

24

The “policy of not announcing anything until it is ready” is the last, tedious step in the lifecycle of Amiga vapourware. You ought to know about this as a practitioner, unless you’re a different “Samurai Crow” from the one responsible for Mattathias BASIC ?

Amigans are subject to the Dunning–Kruger effect on an awe-inspiring scale. People with no idea what they’re doing mistake their vague optimism about their hobby for a relevant skill, and then, unable to detect any obstacles since they’ve got no idea what an obstacle even looks like, they declare their goal easily obtainable and set an unrealistic timeline. After over-shooting the deadline by a few years, they declare a “policy of not announcing anything until it is ready” and it quietly fades away.

Back in 2013, ARIX was an “exciting” new project with a countdown page, and the promise that all would be explained once the countdown reached zero. After the countdown had been negative for a while their expert programmers put up a handful of crummy web pages on www.arixfoundation.com which basically said “Watch this space” and then it was abandoned completely.

There’s actually so much of this among Amigans that it becomes hard to discern where the fools end and the fraudsters begin. One useful metric is whether victims end up poorer or only disappointed. So the nice thing about Arix is that at least they didn’t try to convince anybody to part with cash, unlike say the bait-and-switch on the AmigaOne X1000.


But that’s not even Haiku’s problem, that’s an Amiga problem. What is Haiku’s problem that causes people to ask for a “roadmap” as in this topic? One problem is this…

Haiku’s core developers grasped after the Alpha 4.1 debacle that despite their strong preference for “feature releases” the only way to actually get things delivered is to commit to a regular pattern so that something goes out the door. They bargained themselves down to once a year. But then they just didn’t deliver. A year passed, eighteen months, two years. Excuses were made.

And gradually the value of the lesson is lost. The sentiment returns to how it was in mid-2012, and Haiku’s developers literally start saying “when it’s ready” again, as if they hadn’t experienced what that means for themselves. It will never be ready. So that’s why I bothered with the Amiga stuff. It’s the same mistake, more or less, just a different aspect.

25

I find the possibility of Haiku running on a BSD derived kernel such as NetBSD intriguing. It will not suffer the license incompatibility that a Linux derived work would, yet it would be more portable. It’s like ARIX but better.

Regarding Mattathias, it has been superceded by 3 other projects. PortablE is an OOP language that works on several Amiga derived OSs. Hollywood, as mentioned above, has a VM for 11 variants of 4 OSs. And the AmosPro environment has been released as open source software thus development of the original has resumed.

26

Hi All,

I like Haiku, because of its simplicity. Sadly enough there are a few things that make Haiiku hard for people that love to work with new and alternative operating systems. Haiku misses the installed and ready to use experience. I feel like Halku could be usable, but there is to much work that needs to be done, before it supports my daily work.

SInce this is about vision and roadmap, I propose the following roadmap.

Step 1

  • finalize the kernel as-it-is and bump it up to the newest GCC environment
  • focus on a list of must have application ( Media player, Mail, Browser, Photo Management, a calculator, SMB support, firewalll, a more up-to-date terminal)
  • QtCreator as the standard development environment, well documented, good support so porting software becomes a trivial step

Step 2, choose where Haiku should live: in real hardware or virtualized

  • If virtualized : start working towards integration with Virtualbox, KVM or VMWare like: VirtIO,2D/3D acceleration, Shared Folder support, screen support for the virtual machines etc.
  • if real hardware: USB3 support, wireless support, etc.

Step 3

  • Ditch support for old hardware. Sure: perhaps it will boot on a Pentium2 500 Ghz with a 3Com950 10MB network card, but who uses it.

Perhaps its a development no-go, but if you could design your driver architecture in a way that it can work with linux drivers, that would broaden the list of supported systems. Another possibility is splitting development in two groups: A kernel developers list and an Apps group.

From the end-users perspective the kernel is a non-existent object. Users see apps, and the availability of cool-apps makes users happy. If a 5 year old kernel can still support that, there is (from the users perspective) no use to upgrade the kernel.

I hope, this post sparks some positive fruitful discussions.

1 Like
27

I’d agree that Haiku is a great system, is simple, easy to use, and agree with some of your points. On others, I digress.

Haiku already supports gcc5 + gcc2 as well as x64; try a Nightly with said support – on that note, Haiku just doesn’t “stay still” and can’t afford to. I agree features will need frozen to reach R1 soon, but the team is very good and well aware of what they are doing. Haiku does have the default application set you’re mentioning: MediaPlayer, WebPositive, ShowImage, etc. But if you’re talking about a flagship or featured app like Lotus 1-2-3 in its day, it’s true that Haiku needs one. I’d think it’d be up to the Depot… and not the main OS to satisfy that burden. As for Terminal, there’s fun stuff in the Depot you can install if you add third-party depots in Repositories; if you’re talking the default shell you’re using (bash), then switch to zsh, etc. instead.

And… why Qt? I somewhat dislike Qt for varying reasons; particularly because of its history and because the APIs used by Haiku and also Gtk are better. I know Qt is widely used, it’s good to have choice, etc. but if Haiku were to choose something for third-party app developers to quickly bind to and join, the best choice is clearly to target Web applications using HTML5, CSS, JS, etc. Maybe support Vala, Python, etc.

Also, why “ditch support for old hardware”? Debian already dropped 32-bit PowerPC and vintage i386 (still supports i586+), and several major Linux distros are beginning to relegate 32-bit editions to legacy use or the bin. Why? I like that my old computers can run Haiku OS; it’s something that nothing else, (save for Minix, ReactOS, *BSD, or a smaller, random system) can do nowadays. It’d be a strength for Haiku to maintain support for older hardware, all while supporting SSDs, EFI, etc. as it is currently trying to do.

As for drivers, Haiku appears to prefer BSD (correct me if I am incorrect) because it is more compatible with Haiku’s license and vision than Linux is. Kind of sad… because Linux is more widely known and supported – but the logic makes sense. And I agree: there should be a group for maintaining and coding applications and for developing the core system (kernel, etc.).

But for all of my (probably worthless) ramblings, my opinion really doesn’t count for much. I imagine another’s will supersede this one with much better points and experience. I’m just another random Haiku user, and otherwise, a spunky app developer. Back when alpha 4 was being phased out, I tried to fork Haiku; the only thing left of my royal failing (which I think the FOSS world laughs over) is a flavor/distro now reduced to Poem’s Vintage app image. But here’s the reality about attempting such an effort for the uninitiated: one can’t change the way the Haiku system truly works due to restrictions in the distro guidelines. If one could dump needing gcc2 support entirely, change the system layout, etc., and freely rebuild Haiku, I believe it could take on Mac OS. Insane as it appears, yes, I really believe Haiku could do that. I love Mac OS, but there needs to be a good alternative. Because I can’t utilize Haiku for that purpose, I guess that’s why I’ve switched to a Linux core and am trying to work on a Be-like environment (facade) instead.

That said, I still appreciate and like Haiku… and would softly say to have patience – it will someday reach R1 and meet all your goals and those of the project. Right now, it’s barely at beta stage. In the meantime, have you checked out the Glass Elevator concepts for after Release 1?

28

You can’t really be a multimedia OS these days without support for at least accelerated OpenGL and some form of video acceleration probably OpenMax, VDPAU or VAAPI. In addition to video encoding acceleration…

Upcoming standards like AV1 will be completely impractical to encode without acceleration… 2 FPS per minute was what I read last when running on a fairly fast intel CPU… HEVC/H265 etc… really are already too slow to encode without accelerators.

Hopefully the GSoC project this year for hardware drm graphics acceleration goes far… it opens the doors for OpenGL, Vulkan and OpenCL! All things which are needed these days for a multimedia OS.

29

Patches welcome!

Also, “2 FPS per minute”? FPS means “frames per second”, so that makes no sense :wink:

30

You have a point, even if it is being a bit pedantic :-). I meant 2 Frames rendered per minute of course.

It would be extremely cool if Haiku picked up some Plan 9 features… like namespaces and the method of resource sharing they do between machines (so you could fire up an ad hoc render farm in seconds etc…) These are features that still don’t have a user friendly GUI in any OS as far as I know even though operating systems like Plan 9 lay the ground work and ideas for that.

31

I have a dream… of a Haiku that is far beyond what anyone currently envisions in an existing OS. Security so secure, NOTHING can touch it. Not viruses, malware, spyware, trojans, DOS/DDoS attacks, etc. OS responsiveness so untouchable, every app could be bogged down to crawling, but Haiku zips along like nothing is wrong. Data transfers faster than the fastest HDD or SSD.

But, unfortunately, this comes at a price. You cannot have 100% security and 100% access. You cannot have 100% responsiveness and 100% resources. You must decide if you are willing to compromise for security and responsiveness. Is being able to boot up your system and NEVER having to worry about all the evils that exist “out there”… EVER… worth not being able to tinker with all the deep crevices of your OS? Is having a system that is as fast/responsive as it possibly can be, worth a few less resources to do with as you please?

What is the most important thing in your computing experience?

Can these two things actually be accomplished? I believe so, but we’ll never know if we don’t buck the conventional wisdom and “go crazy” just for the sake of giving it a shot.

Unfortunately, what I propose WILL break Haiku in every way possible. It will most likely require rethinking and recoding just about everything, because it will fundamentally change the way Haiku interacts with the user as well as all software. But, in order to accomplish what I envision, it’s absolutely necessary.

The gauntlet awaits… :smiley:

32

You can get only a complete secure system then you unplug the internet and network

2 Likes
33

Why should it be up to Haiku to do this then? Why not some other (existing or started from scratch) OS?

34

Just saying what I envision for Haiku and seeing if any willingness exists to try and make it a reality. We can always dream, but when dreams are striven for, to make them a reality, THAT’S when the fun really begins.

If I did not have such an affinity for BeOS/Haiku, I would suggest these things elsewhere. And this is also why I have a much older version (pre-PM) of Haiku x86_64 sitting in a laptop. Less stuff to have to “break down”, to start with.

There have been other OS’s I’ve considered these ideas for (and it would, technically, be easier to accomplish). But they’re not as complete as Haiku nor is there as much of a community around them.

Just thought I’d toss my hat in the ring while the topic was going in weird directions. :smiley:

35

You’d think so, but then you have a nigh worthless lump of circuits and software sitting in your desk. I’m saying I believe it’s possible WITHOUT that crude isolationist approach. :smiley:

36

[quote=“cb88, post:28, topic:3979”]
You can’t really be a multimedia OS these days without support for at least accelerated OpenGL[/quote]
yeah you can, most media doesn’t touch a graphics card. good file i/o, fast and plentiful RAM and a means of getting synced or isochronous streams into or out of the system are all you need. that’s all handled by generic usb drivers, internet protocol, filesystems, media frameworks. an accelerated videocard can help sometimes – being able to drive a couple extra video outputs is always nice – but even compositing doesn’t strictly need hardware accelerated graphics.

37

No you can’t. While I didn’t state it getting OpenGL on Haiku involves getting 95% of the things required for OpenCL, Vulkan and OpenMAX for instance as well… you can’t in practice call your OS a multimedia OS without hardware acceleration of video codecs these days.

A guy sitting in an airport with his “multimedia OS” and a dead battery… are all that is needed to disprove that idea. Not to mention that you can’t even decode redcode for production in software at anything higher than a few FPS and very low resolutions, while with hardware acceleration on VEGA card you can do 8k at full frames.

Even in the days of BeOS a large amount of the performance was owed to the fast/optimized codecs. If your OS can’t handle production work then it’s still in it’s infant stage honestly. For this to take off something more than nostalgia has to take over.

38

i’ve been cutting video without hardware acceleration for years, for television and cinema, and transcoding entrants’ films for festivals. there’s not much that makes use of hardware acceleration in video production whether it’s hardware opengl or opencl. concurrency is what gets jobs done quicker and at higher resolutions and haiku already handles as many cores as anybody’s been able to throw at it. if, for whatever reason, you’re working in a higher resolution than your computer can handle, there isn’t a motion picture workflow in the history of them that hasn’t relied on proxies instead, and people have managed for over a hundred years. the only things that matter are timing, file management and stream i/o.

i have no nostalgia for this system. i came to haiku in 2012 and never touched beos. i’m here because doing the things i want to do is easier in haiku than in any other system.

2 Likes
39

rocket,

It sounds like your are doing quite a number of things using Haiku. Could you elaborate a bit on which things you are using Haiku because it is easier to do them with it than with any other operating system?

40

designing and building a modular video production system.