I attempted that. I attempted to use XCB (because Qt wasn’t an option in my case).
But in the end I gave up and that’s why I will be moving to Haiku: Quick-and-easy development of UI-based software without the bloat. 
This is the most detailed response I have had yet and thank you so much, This has hit a lot of crucial points that I myself had questions of
all that animosity just to waste your time to type that out is disappointing and pitiful behavior, with that being said if you are not gonna help me in my survey and my two circle Venn diagram please don’t comment at all
Not at the moment, and not any more. There have been attempts to spin off Haiku distros over the years, including attempts by people still somewhat active on this list (No names, you know who you are). And there is absolutely nothing to stop anyone from trying it again. The license allows it and the developers are cool about it.
And if I ever do create my own Haiku distro, I am totally stealing the name “SaucyBluePepperHaiku“
7 Likes
I don’t see where is the problem here. There are tons of tried-and-true libraries to make this a piece of cake, e.g., in one of the simplest ways, and omitting error proofing (which will just add a few lines of code):
#include <GLFW/glfw3.h>
...
GLFWwindow* window;
glfwInit();
window = glfwCreateWindow(1366, 768, "My window", NULL, NULL);
...
… and there you have it, a new window with a perfectly working OpenGL context. Fast, very “newbie friendly”, and works not only in X11 but also whatever else as well (including Haiku).
The difficulty here, if any, is the low-level nature of OpenGL, not the creation of a window.
Count me in! Senior Haiku spinof! 
Agreed, except it should be “SaucyRedPepperHaiku”. I mean, it’s saucy, but should also be spicy, right? 
On a more serious note, I am guessing (almost) everybody agrees forking Haiku is sort of pointless right now.
As for the original thread question, the answer is more or less obvious for me: Today’s “Linux” (actually, GNU/Linux) became bloated and took a direction I really don’t like. This happened years ago, and I don’t see them changing route anytime soon, if ever. Perhaps “BSD or Haiku” would be a “better” question.
1 Like
A very important point. We need agreement on this, because the first order of business will be to replace the blue leaf in the Deskbar with a saucy pepper.
Right now, yes. The time for that conversation will be just before R1.
Depends on the distro. They range from easy to boot and use (like gamer/newbie/switch-over distros which usually are bloated so you don’t have to worry) over power user distros (Gentoo and other build package manager distros) to server distros all the way to low spec optimized versions (you get the minimum required, the rest is up to your use case). So no, Linux is not bloated. You choose bloat or not depending on your use case.
As above, just take a look at Tiny Core Plus, for instance, as against Ubuntu Gnome….
That’s only partially true. Linux (the kernel itself) is bloated. Yes, you can use a somewhat debloated and/or libre kernel, but very few distros do so. Not to mention the vast majority of them are bloated otherwise. Of course, you can build your own Linux kernel and do “Linux from scratch” but come on now… And yes, you can use Tiny Core or something similar, but that simply won’t be your daily driver.
Where’s the problem? With Gentoo I have a custom kernel since many years. When you use a prebuilt kernel then you do this for convenience so it can handle all potential devices and system you might be throwing at it. Obviously this “catch-all” builds are loaded with lots of drivers to get you covered. If you ask for a car that can fit in any number of people and luggage then you do not have to be astonished if you get a huge, slow van instead of a sports car.
I used Tiny Core Plus as my daily for many months, & quite often install it on low powered computers, it does everything that I need as a regular computer user…..it just takes a little bit of setting up, that’s all.
So do you like choosing between distro that are build for specific tasks and area or do you like having a unified system but better bit support like haiku
I love this, but how did you customize your haiku so much it look so colorful and like you been working for a while to make it this beautiful, so basically the question I have is do you have fun learning about Linux and haiku or one or the other and what is common error you experience from both 
Had been using Linux for years (first one was RehHat 5.1 IIRC), lately been trying some dual booting with other distros, but always end up with a borked system, for Haiku … came a long way from BeOS up to todays beta5 (keeping it up there to make sure I’m on par with buildmasters for the haikuports packages).
Desktop changes from day to night schemes, and background is changed from time to time, other then that only a few default replicants supplied by the system)
1 Like
The problem with a unified system is the “one size fits all” problem. I’m a game developer so I have to competing desires. For development work I need a system which is bleeding egde where I can deal with experimental software not existing in package managers, which I can easily customize and tailor to my workflow and where I have full control. On the other hand for packaging and testing end users systems are used which are usually dumbed down, locked into “carefree” package managers. Users do not want to deal with the gears of their system as I need to as developer while as a developer I need access to those gears regular users do not want to even see. And on my server I want to have a distro which is geared for this task, meaning console only, no UI libraries polluting the system and requiring constant updating. So yes, at least 3 distros makes sense: server geared, development/poweruser geared and casual user geared. I’ve not seen yet an OS which manages to get all these three usage types under one hat without becoming a chore to use for all of those use cases.
2 Likes
Predictably, I am about as far-removed from the exclusivity of this because running any software in the proper environment by using a scripted import of a .WAPM (WebAssembly Package Manager) to avoid duplication, is a necessity, IMO. There is no reason that this couldn’t be made practical, it just doesn’t have sufficient interest or compiler support to make it happen.
Lately, I’ve been tinkering with a totally new and unprecedented processor architecture to install on my MiSTer Pi computer that uses Wasmer and it’s package manager as an install medium. The hardware instruction set is deliberately kept unstable so that there will never be bloat within the instruction set. (Have you ever tried to run AVX512 software on a 3rd-gen i7 from 2014? I have had to install patches to software emulate missing vector ops on that configuration. Running MMX on anything modern is equally impossible without patching.)
you make a interesting point but for this comparison we will be look on system architecture to see if this is this file format actually good and if the concept is better executed than said so using the OS native file format and running it on the same hardware will only allow the OS, to be fairly comparable as it’s coming from the operating system’s kernel, scheduler, drivers, and software stack, not from different components and lastly using native file formats keeps the comparison fair, Ubuntu using its own packages and Haiku using its own packages means neither system is slowed down by translation layers or compatibility tricks. Each OS is running software the way it was designed to run it.
but you’re right it would be a lot more easier if every single OS uses the same apps
so basically you like the ability to have complete, specialized control over a system’s especially in your case when developing, while maintaining a lean, interference-free environment for servers and a stable, “carefree” experience for end-users which is actually a good thing and a lot of great point for me though I love having unified system but more bit support I feel like bit support is important especially when I’m trying to tinkerer on weaker hardware device in the case of haiku having separate bit version(32/64/live) help me place a lot of my work on older devices and allow me to really expand my work across many device and test haiku in many ways also if there 32 bit support that mean I can run it on a 16 bit device