Why are you bashing linux here on the haiku forum?
The linux developers wont see it, for haiku developers it is not relevant.
Offtopic:
Btw, it has gotten much easier, as long as you use a mainstream distro with systemd and flatpak support.
Between the ongoing bikeshedding fiasco in Wayland Protocols, the re-emergence of desktop-exclusive apps straight out of the pre-X days, and more DEs planning to undergo rewrites (e.g. COSMIC, Budgie, etc.) away from a shared tech stack (GTK), I wouldn’t exactly say that the Linux desktop ecosystem is currently working well or will assuredly continue to in the foreseeable future. There’s more, but it’ll probably derail this thread too much.
Besides, Haiku’s ecosystem is reliant on having a unified desktop platform to build upon. Being able to know exactly what’s available on every Haiku install greatly simplifies support and development. No need to have containerised package formats, multiple package formats, library runtimes, etc. There is also no need to consider differences in supported features between DEs (an emerging problem with the Wayland transition), package versions available in repos, or fallback to providing support through terminal commands to bypass people using different desktops.
Look, I like Linux enough to use it as a daily driver. However it does have a lot of issues as a desktop platform. Haiku’s focus on providing a complete and unified desktop system avoids many of the structural problems Linux has as a desktop platform, making it closer to Windows and macOS with regards to desktop cohesion.
1 Like
Comparing Linux and Haiku… Basically, there is nothing to compare here. Linux is a working system, with flaws, of course, but they are being worked on and progress is being made.
After all, from the user’s point of view, the most important thing in the operating system: it has to do the job.
If system do job good it is good system.
The benefits of system design and architecture, use of programming languages, licensing, and the like are secondary.
The technical details can actually matter for whether an OS can do the job. They cannot always be so easily dismissed.
Right now for example in Linux land, there’s a big debacle over having absolute window positioning in Wayland. A technical decision made for Wayland was to only have relative window positioning. This has caused issues for people in the scientific community and others using multi-window apps, as outlined here.
Coincidentally, a lot of multi-window apps from BeOS do work just fine in Haiku. 
Wayland still is experimental software.
For job done Linux has X11.
And if the Haiku app server turns out to be a really good thing, it can be ported or copied to Linux.
This is the advantage of Linux systems: competitive solutions and modularity.
Not true. There are stupid and easy to fix bugs in the system, and there are complicated packaging problem that takes years to get around (think about the Haskell or Go ports for example).
There is already some people working on haikuports for the purely “distribution” aspects of things. There are also some people writing their own apps for Haiku. They usually end up finding bugs in Haiku and fixing them, instead of making progress on their own apps. I know, because this is what happens to me when I try to write an application.
There can already be. Customizing Haiku is not hard, either by rebuilding it from source (this takes about an hour), or by manually extracting and repackaging the packages. If someone is working on such a thing, and they are unhappy about the way things are packaged in Haiku, they can send us patches to split things apart, and it’s quite possible that we will merge them. But if it’s one guy on the forum telling us what to do and expecting we do it ourselves despite no one actually planning to make use of it? Then it won’t happen. There are more important problems to fix (we all have our own priority lists, for me, splitting Haiku into smaller package and removing apps from there to save a few kilobytes from the disk image is not a high priority thing).
Here is the commit log for WebPositive: https://cgit.haiku-os.org/haiku/log/src/apps/webpositive
In 2023 there were 4 commits touching it. If that is “big maintenance”, then we have no problem at all 
Most of the work for it happens in WebKit, which is in a separate git repository. Updates to WebKit does not usually require any changes to WebPositive itself.
3 Likes
I will explain my position more specifically.
“Demos” should go in a separate folder under Haiku sources.
“Demos” should be optional during installation.
Programs from apps that are not fully functional or not relevant these days or are not essential should go to optional (or/and experimental) in Haiku sources and must be optional during system installation. Such programs should probably have their own separate folder in the Deskbar menu.
Following BeOS traditions, devtools should also go to a separate folder in Haiku sources, in Deskbar Menu, and must be optional in time of installation system.
What’s the point?
Better data organization is useful for system developers to manage and prioritize. Users will also have a clearer understanding of what to expect from apps included in Haiku.
Why do you, as someone who does not develop haiku, care where in what folder we put stuff in the source repo? it has absolutely no influence on how we distribute them.
Everything is already optional in a haiku installation. Just use an entryblocklist in the packages file and you are done. Nothing more needs to be done.
Honestly this discussion serves no purpose anymore.
@humdinger maybe close this topic?
4 Likes
And why are you asking me such a question? How does this relate to the matter at hand?
I don’t see how it affects you at all, there is no point to reorganize the sourcetree for people that do not use it.
1 Like
Haiku is an open source project. So, you shouldn’t care if I use Haiku source or not.
you are asking for something that in my eyes makes no sense, and is not relevant to you. It is important to understand why you want to change this.
1 Like
What do you not understand in this post?:
I don’t care about buzzwords, just claiming something is better does not make it better, you did not explain anything.
2 Likes
@humdinger, Motion Seconded ! This discussion has turned ( even more ) non-productive … 
1 Like
Open the dictionary and look up the meanings of all the buzzwords. This is one way to understanding.
While I’d prefer people would just ignore these, in their and my eyes, misguided advice to re-arrange our code furniture… I fear this distraction will jusy keep going on.
8 Likes