So I got accepted into GSoC again! I’m going to be working on WebKit2. But what is WebKit2, or even WebKit, for that matter? Well, WebPositive uses WebKit to render its web pages. Currently, we use the WebKitLegacy API to communicate with WebKit. It would be nice to switch to the newer version: WebKit2. However, our port of WebKit2 still needs work. At present, it has lost its ability to even render any webpage at all! So, getting WebKit2 to work will be the primary goal of my GSoC project. If there’s time left, I might be able to integrate it into WebPositive.
The advantages WebKit2 has for WebPositive will be mostly invisible to end-users. The code will hopefully be more maintainable than the deprecated WebKitLegacy and we’ll get access to several newer APIs such as the ad-blocking API. Perhaps the most visible change: problems in one part of the code should be less likely to crash the whole browser.
Zardshard on the Haiku website
The current state of WebPositive, the only native Haiku web browser, is emblematic of why I have personally lost all interest in the successor to what is still my favourite operating system of all time. Haiku OS supports several browsers, and if you read any forum post about which browser to use, or watch any of the enthusiastic Haiku videos by the insanely awesome Action Retro, they’ll all advise you to use any of the non-native Qt or GTK browsers instead – because WebPositive just can’t compete with the ported, non-native browsers.
Since everybody using Haiku is opting to use the better ported browsers, WebPositive has fallen even more by the wayside; now it has to play catch-up, and by the time WebKit2 has been properly ported and bug-tested, and has been integrated into WebPositive, which then has to be bug-tested as well, we’re going to be months, if not years, down the line. In the meantime, the ported browsers will have been regularly updated with newer, better versions. Unless the focus for the single most important application of any general purpose desktop operating system is placed solely on WebPositive, it simply won’t be able to keep up with the ported browsers. Why even work on WebPositive at all at that point? It’s not like anyone is using it, so why bother?
And this highlights a problem for people like me, who prefer to have native Haiku applications instead of ports of software I can already run elsewhere. As a former BeOS user, I am not interested in a vessel for running Qt applications that I can, in all likelihood, run better on Linux. Why would I go through the trouble of assembling a machine with hardware Haiku supports, only to then run the same applications I’m already running on Fedora or OpenBSD, but worse?
If you browse through Haiku Depot today, it feels like the vast majority of modern, maintained, and working software are ports of Qt (and GTK) software we already know and love from other, more mature, more stable, more usable, and more feature-rich platforms. Haiku has chosen to pour a lot of energy and manpower into becoming an operating system designed to run ported, often Qt, applications, but the downside to that is that new and maintained native Haiku applications, that play to the strengths of the platform, are few and far between.
A Haiku developer once told me that real people use Haiku every day, and they need real applications, and ported applications make it possible for not only Haiku developers themselves, but also normal users, to run and use Haiku every day. This is a valid argument that I fully understand and agree with – it just means Haiku isn’t for me. And while that’s sad for me, it’s entirely fine. Haiku’s developers have chosen to focus on building a daily-drivable operating system with tons of ported applications, instead of an ideologically pure operating system you can’t really use because it only has like 4 native applications and nothing else.
And that’s a valid, smart, and practical choice that I fully respect and understand, even if it means Haiku isn’t really a BeOS successor anymore.
If it was just some reactionary BeOS clone, it wouldn’t be terribly interesting – more of a mausoleum or windmill tilting. The fact it’s decided to embrace radical new things like the package-based filesystem means it’s closer in spirit to what BeOS was intending to be – innovative solutions for desktops.
It would help if the package management wasn’t acutally bad, and got in the way, and followed the principle of least astonishment.
Yes,
People forget about practicality, and pursue pet projects into their demise.
If this was the case with Linux, we would have no more install base than the BSD (or even Hurd!)
There are no native web browsers for GNU/Linux desktop distros other than a few webkit browsers. All the major browsers have been ported over from Windows to use the various native widgets. So in that regard there’s not much difference with Haiku, other than the widgets part.
But regardless, Thom’s “I now disown my formerly favorite OS because somebody ported some applications over to it” is pretty much on the Monty Python level of silliness. If you want an OS with all native applications then use ChromeOS. Although, once again, Chrome was made for Windows originally, so not entirely native. Thom could use TempleOS. Last I looked there were no non-native applications running in that.
andyprough,
Just a minor correction,
webkit is a fork of KHTML which was a native rendering engine for KDE on Linux.
I agree. Search for extreme purity is not rational. After all “perfect is the enemy of the good”
Chrome OS already supports Android applications and the Google Play Store:
https://www.aboutchromebooks.com/how-to/how-to-see-the-version-of-android-on-a-chromebook/
and Linux applications using a specialized container:
https://chromeos.dev/en/linux
And both of those systems integrate the applications with the desktop.
There are some really good native applications though. Vision is by far the best graphical irc client i have ever had the pleasure to use. BePodder is my favourite podcast application. That being said, i feel in my personal and very subjective take that Qt applications feels snappier in Haiku than on either Xorg or Wayland.
3dmix is also a very good program i use when listening to multichannel classical music to alter what parts of an orchestra/band i want to give more oomph without having to edit the file.
But for me the real killer app is the OpenTracker desktop, it just does things that no linux desktop does, and it feels much faster than any linux desktop at that.
Well, an OS is an OS and an application is an application. When there will be more non native applications, more people will use it, and when there are more users, it will make more sense for devs to create native apps. Win-win
Hear! I found the article – especially the opening sentence where the author claims to have lost “all interest” in Haiku – rather mean spirited. Self evidently not so, otherwise why is the author still giving us Haiku updates?
There is no reason that Haiku cannot thrive with any of these guest applications whilst the case for its native one becomes irresistible. We can compare the open borders of Haiku in an unflattering light with – say – Serenity which is trying to do everything itself, but it is clear which is the most usable for the most users as things stand.
I take it you mean Haiku.
Well the target audience at least for the moment is different. While Haiku seems to want to attract users Serenity wants to attract developers. What it does: Over 1000 compared to 256 for Haiku.
IMHO both have there merits.
I think it’s unfair to point to a web browser as the straw that breaks the camel’s back. That’s sort of like saying that a Commodore 64 or an Atari ST ceases to be a C64 or ST if you develop a communications adapter for it that allows it to connect to a modern networking technology.
Web browsers are quite possibly the most labour-intensive moving target to keep up with in the entire software ecosystem.
But it’s not the straw. There are so few native applications. There are so few Haiku developers. I used to write articles on developing applications for Haiku but no one would publish them. Not even Thom Holwerda.
This article has that feel to it. That’s why I said that.
“Better DOS than DOS, better Windows than Windows” much?
In any case, I love Haiku, and I’d run it as my main OS if security was a bit better – I need proper full disk encryption and to run applications under different contexts.
It’s clean, fast, and the user interface respects my screen real estate. Never thought my 30 inch screen would be small…
Yes,
Just speculating.
A good alternative could be a Xen based hypervisor, enabling virtual accelerated GPU for clients who are all isolated from each other, focusing on specialized tasks.
We can have Chrome running on BSD, media applications on Haiku, and terminals on Linux.
There aren’t any (or many) BeOS/Haiku developers doing native apps anymore. If anything, there isn’t much app development happening anywhere, really. Everything is web apps these days. So having Qt (and GTK+ 2) apps is normal, otherwise there would be no apps at all. My only gripe with the whole thing is that they aren’t well tested. None of the two Qt PDF viewers I downloaded worked for me, they crashed when opened a PDF. BePDF didn’t crash, but couldn’t display the table of contents either… So, it is what it is at this stage.
As a Haiku developer, I agree
We all idealize using WebPositive over non-native ports of other browsers. The reality however is WebKit as a project moves *FAST* (100’s of commits a day fast), and so far has been guarded to accepting any upstream Haiku patches. This means we’re always playing catchup to keep things merging and compiling, let alone improve the functionality and stability of our port.
Mix in the limited number of folks actively working on Haiku and it paints a bleak picture. We would absolutely love to have first-class native applications in all cases (I personally was a big fan of creating our own rendering abi around the BeOS opengl driver model… and look where that got us).
Browsers, Network device drivers, Video card device drivers + rendering pipelines. These are the things that small operating system development teams always struggle with. They move quick, and they are complex to implement and maintain.
If you’re working on your own operating system, heed my words. Outsource the above to compatibility layers and borrow the code from NetBSD or Linux. Us using FreeBSD’s wireless card drivers via compatibility layers was the best choice the project has made in a long time.
With the above said, i’m extremely hopeful the GSoC student can help us catch up, and make WebPositive a native first class browser. It’s important.
I refuse web apps and i detest and deplore them. Nothing good can come of it
They’re getting harder to avoid. Email clients? Web. News? Web. Video? Web. Hell, IDE’s are moving to the web.
The web is dumb, and its current direction is wrong. However, progress is unavoidable.
My last hold out is using gemini protocol, but that seems to be dying a quick death too
https://github.com/skyjake/lagrange
They aren’t all bad. PhotoPea is a great substitute for photo editing software in a pinch, its author does it for the love of it, and (to my knowledge) no one has tried to “Electron-ify” it. I prefer Pinta myself, but it isn’t available on all platforms I use so PhotoPea fills that niche when I need it.
I’m sure there are other projects like that which are labors of love and not corporate crap.
I get what you’re saying Thom, but Frankly WebPositive has always been crap. Even when it was “good” in the early days, it still was only just passable as a web browser, and definitely not something you could daily drive on the regular.
The QT browser ports aren’t the cause of WebPositive’s issues, they’re a symptom. Had WebPositive been a competent browser, then there would be no reason to port a QT one.
Don’t blame 3rd party software for the decline of 1st party software, when the 1st party software wasn’t usable in the first place.
I would tend to agree.
While it’s very gratifying that there are so many apps for Haiku compared to BeOS back in the day, I have argued with “Waddlesplash” about this before.
He considers Haiku to be a Unix and expressly wants to add full Unix API support. The _original point_ of BeOS was that eliminated the tonnes of legacy baggage of Unix, Windows, OS/2 etc.
I think he wasn’t there at the time and doesn’t understand this.
lproven,
I do see your point, and on many levels I think the appeal of alternative operating systems is that they aren’t just yet another OS doing the same thing as the market leaders. Everyone does that; it’s boring and uninspired. It’s more fun to focus on native innovation whiling staying clear of baggage that plagues other mainstream operating systems.
At some point though I think every alt-OS project encounters the same existential issue: few native apps with little likelihood of convincing masses of developers to support your OS natively. Diverting resources to support baggage from bigger operating systems is extremely distracting and counterproductive to what makes your OS special. But it may be a question of survival: if you don’t have enough real world software your users may end up being forced to run another operating systems anyway because they require software that isn’t available for your OS.
I’d really love to see more indy innovation and less cloning, but I’m very pessimistic about those prospects IRL.
Alfman,
Yes, this is a chicken and egg problem. For some niche applications, if you have an “exclusive” the OS could live, at least for a while.
I remember TV stations using Amiga for example for running their banners (not sure what the technical term is), until they moved to HDTV, which is no longer supported by the long abandoned system. Similar with OS/2 and some banking systems, and so on…
If you don’t have a broad app support, or very deep specialized apps, you stay as a curious research operating system.
I’m not really sure why Haiku is being singled out here. If you look at most other major OSes, you’re also increasingly seeing fewer native apps, with many opting to simply be an electron wrapper that feels native nowhere.
Good lord, that is depressing. Every single electron application i have ever tried has been complete and utter trash.
I hate the server based applications, and at work we now no longer have access to a mail client or office suite and have to use office365, and i am considering hanging myself because of it. Then i realized that i can use my own PC as long as it is registered by the IT department. Voidlinux and wps office suits my gui needs. But i mostly use teapot, green and emacs anyways.
The obvious solution here is to port Haiku OS to rust. Amiright?
Better yet, write a new memory safe language on Haiku, let’s call it “Kireji”, and then re-write Haiku in Kireji.
I had to Google this, I confess, but kudos for your use of poetic terminology to throw contrast on technical imagery.
https://thehaikuexperiment.wordpress.com/2014/07/24/what-the-heck-are-kireji-cutting-words/
A native webkit is needed for more than just the WebPositive browser. There is currently no way to embed an HTML view into an app using the native BeAPI, and a native webkit probably provides the best option for that. This is a huge hole in the API and means that Haiku doesn’t have a lot of modern apps that people expect, like an email client that can read HTML email, for one example.
And why do you think html has any place in applications out side of documentation?
That was Thoms whole argument of depending on external non-native programs. HTML/JavaScript and so on is poorly suited for making an application in ANY OS, and much less an os with focus on being snappy. Having “webapps” is not only counterproductive and slow and at the whims of application developers like google/microsoft and so on. No, local applications is the way to go for the future, where the files is actually stored on your PC instead.
I’m not sure where you got the impression that I was arguing for web based applications. My comment was in reference to Thom asking why bother continuing work on the WebPositive when ported browser engines that require Qt/GTK are available. There is a need for embedding HTML fragments in an app without writing the entire app in HTML/Js/whatever. You seem to be arguing that it has no place in app at all besides documentation, but I’ve already given an email client as one valid example. There are also various other reasons, like an app that needs to generate link previews, having a basic documentation browser built into an app, and so on.
This is the problem with I.T. nostalgia… We had a period we enjoyed the most and then miss the days and want to be back there. For some people it was Atari, some Amiga, for others OS/2, some now even Windows XP … But the truth of the matter is that things move forwards and those days never EVER come back. Sure, you have the TINY die-hard groups that try and keep platforms alive in some way shape or form – but they get grey hair and the generation below them have no idea what they are even talking about. .. nor do they even care. These people can spend (waste?) a life time trying to re-code and re-enact a bygone era where in their heads they strive to get back to the state of happiness they once had… I’ve seen it time and time again now.
I am completely gray, but the day i am forced to use windows 11 again is the day i check out. I have 9 years to retirement, and i could go early.
The Lone OSer,
While there is such a thing as nostalgia, it’s not always about a backwards mindset. The trouble is sometimes technology actually gets worse as NaGERST said. Consumers are actually experiencing a lot of regressions. A lot of us loved windows, it’s getting worse, a lot of us loved netflix, it’s getting worse, a lot of us loved google, it’s getting worse, a lot of us loved adobe, they’re getting worse. and so on. They coined a word for this, “enshitification” and it’s depressing as heck that corporations are actually making products worse on purpose. This is what happens when too few have too much power over the market – consumers suffer
As much as it is admirable to pursue “pureness”, unless you are a billion dollar company, you’ll never be able to offer a reasonable operating system that can be used by average people.
Yes, there are small examples like MinuetOS, https://menuetos.net/, with a limited scope that does exotic things. But once you reach the stage of “I want to support everyday multimedia devices, and want to be usable by inexperiences people”, things change.
So, I welcome the pragmatism of BeOS. This is a major milestone that leaves some people behind, but moves the ecosystem forward.
Even then, even multi-trillion dollar companies like Google and MS and Apple are borrowing tons of stuff to prop up their OS’s and their user experience.
Yes of course.
Even the “fresh” Fuchsia OS of Google that was built from the ground up was being geared to run Android applications: https://www.phonearena.com/news/google-fuchsia-android-apps-starnix_id141393
(And yes, that was also built on opens source as well).
I’ve said it before, but this is indeed the fate of pretty much all alternative foss operating systems except ReactOS. Not enough users/developers to write native applications, write a posix compatibility layer and start porting Linux userland. Inherit all the dependency/package manager problems of Linux, become essentially a worse version of Linux to end users.
dark2,
I’ve made similar points about POSIX compatibility layers. In terms of dependencies/package managers though, this is more of a criticism for traditional package managers. It’s been solved by moving to containers like snap/flatpak/appimage and that makes me wonder how easy these are be to port to other operating systems in practice.
Strangely, in practice this is leading to questionably sourced, and probably outdated Windows binaries being packed up with Proton/Wine libraries. With Win32 slowly becoming the defacto Desktop API for Desktop Linux.
dark2,
That’s not happening in my experience at all. Wine would have to get a lot more robust and popular before it would ever have a serious shot of becoming the defacto API for linux. Honestly the majority of publishers that support linux at all are actually providing native linux software,. That isn’t the problem, the problem is that most software publishers don’t support linux at all, period.
OTOH – An OS with no browser? I might even get some work done. (LOL…)
I would have 100% agreed with you, if most of my work did not involve looking at online documentation, browsing sites like stackoverflow, following our changes on github, and many many other tasks that require a browser.
Can’t use a blacklist or whitelist either. Sometimes the information I need is shared on a Tweet, or a forum post.
(Which then quickly becomes an endless rabbit hole of productivity destruction).
If you want people to use the native APIs turn them into a multiplataform SDK.
jgfenix,
Do you think niche platforms carry enough weight & momentum to push multi-platform APIs? Bare in mind that linux often experiences Not Invented Here Syndrome. The pressure in FOSS operating systems is to copy from linux because it’s the most popular, it doesn’t typically happen the other way around though.
I was a user of AUFS for nearly a decade (used by live cd distros including knoppix), the author diligently pushed for mainline inclusion for all that time, actively supporting it and making requested changes, etc. However in the end a linux kernel dev wrote overlayFS, which was earmarked for mainline from the start. I actually liked certain things about aufs better, but for better or worse being well-connected can be more important than an outsider’s dedication, time, and effort.
The point being, I don’t doubt for a moment that Haiku can design good APIs, I’m just extremely skeptical of their ability to get other larger players on board.
It doesn’t have weight but it’s the only alternative. Nobody is going to write native apps except Haiku enthusiasts but with good multiplataform development tools that can change. Many non-GNOME people are hating what GNOME is doing with GTK+. And perhaps Rust bindings would be a good fit to its massive multithreading design.
Non-native toolkits have almost never worked correctly. (like GTK on Windows, or Qt everywhere, or Swing UI for Java, and so on).
Because they don’t carry the UX (user experience), but only share UI. What I mean is, they do not conform to the expected norms of the target operating system.
That is why XUL was a massive burden for Mozilla. They had a cross-platform toolkit, yes. But they had to customize it for every platform to act “native”, in other words “speak the design language”.
And I’m not sure how Rust comes into this.
I absolutely loved BeOS when Be was still around. My biggest issue with Haiku is, “what’s next?”
BeOS was a future facing operating system; Haiku is just an echo of a long dead platform. It’s stuck in the past and misses the most important part of why I believe many people were drawn to BeOS: vision. It excited me to think of where it could go, what amazing future it could forge. The killer feature, its multitasking performance, was unmatched on the desktop back then, but that’s common now. So… what does Haiku offer besides nostalgia?
Who at Haiku has a vision of where to go next? Are they chained to the last version of BeOS?
I am waiting for a computer that I was going to to use to run Haiku. Actually my idea is to run the latest Sculpt release, running virtual machines within which I can run Haiku. What I expect to get from this is being able to run many separate instances of Haiku for different tasks, thus getting round the fact that it is currently single user.
Genode does apparently have a modern browser port of its own, so there is the option of doing much of my surfing in the host OS.
Actually I think the main risk to Haiku is missing out on ARM. Sure there is a lot of very positive work on RISC-V, but if that architecture does not make it (remember PowerPC?) and ARM takes over, there is no plan B.
The problem with ARM is fragmentation.
On x86 you can quite easily make a kernel that will boot on anything, and have generic support for IDE/SATA/VGA/USB. It won’t take full advantage of the hardware features, but it will boot and you can build on it from there.
With ARM there is no lowest common denominator, you pretty much need a custom kernel for every SoC you want to support. This is why many things with ARM support actually only support the raspberry pi family (and usually only specific models) because they are a fixed target and sufficiently well known. If you have a less popular ARM board you will often even have trouble getting Linux running on it, let alone anything else. You’ll often be stuck using the outdated kernel the manufacturer heavily patched and its difficult if not impossible to get a mainline kernel running.
bert64,
+1
This is a problem with arm. Systemready was meant to address this and it might have helped if manufacturers took it seriously but it’s late to the game and it seems manufacturers are happy to ignore it. From their perspective it may even be beneficial to impede the ability to independently install different operating systems.
While I am not a cheerleader for x86, all things considered I think we are lucky they are still around. x86 has grandfathered benefits from an era when personal computers and operating systems were much less coupled and more serviceable. Modern competitors might never be willing/able to replicate those properties.
> you pretty much need a custom kernel for every SoC you want to support
While this is true, and reflects what is called “choice paralysis” in real life, there is an easy answer.
1. Follow Be’s example. It stopped supporting Apple PowerMacs because Apple was actively trying to hinder it. So, look for the Arm platforms that are open and documented, and only target those.
2. Then, from that set, select only the most widespread. There are legions of phones and tablets and tiny one-off single-board computers, but they don’t even get new versions of their own native OSes. They are noise. Ignore them. Look for the million-sellers which keep selling and which keep getting updated.
That brings it down to a handful, and one is leagues ahead: Raspberry Pi. Millions of units, the best-selling model of computer since the Commodore 64, and a high-level of backwards compatibility from one model to the next. I have booted the same OS SD card on a 3 and a 4 and a 5.
lproven,
I don’t think “choice paralysis” is a good fit here. It’s not “choice” that’s the problem, but lack of openness.
For example, I was looking to invest in a good USB oscilloscope…plenty of “choices” until I apply my open source criteria and then the set that fit both my performance and FOSS criteria goes to zero. As much as I hate it, once again I’m facing the reality that I may have to give up on openness
The trouble is those unsupportable devices are the norm. I agree with OS devs targeting the hardware that is easiest for them to support, but in the meantime people are disposing of commodity devices all the time in a constant stream of e-waste there for the taking if only we could install our own software. independently. I guess “ignore them|” should be taken as pragmatic advice rather than a suggesting the status quo doesn’t matter…because our status quo is awful and indefensible.
I agree RPI stands ahead and am thankful we have them for DIY projects. Although we might have to overlook that for most of their existence they had zero stock aside from 100% markup scalpers. It’s so frustrating that many households are regularly disposing of powerful commodity mobile devices while on the other DIY builders have to go pay over $100-$200 for new hardware plus accessories/touch screens/speakers/gps modules/enclosures/etc. This really should not be! If only the devices we were throwing out could be easily repurposed it would be a boon to the DIY community! And to think that software incompatibilities are the main barrier, what the hell is wrong with our industry?
I think this gets to the very heart of why use an alternative operating system. For me its always been about practicality and novelty both. I used OS/2 because it was a better windows than windows. I used BeOS because it was better than windows, mac OS or Linux at the time for my hardware stack ( PC with tv capture card and video card) for doing av things. There were many cool technologies for getting that done, but the focus was on the things I needed to get done. So if that meant a unique operating system with some quirks, ok lets go. But the operating system has to enable unique applications that help me get stuff done. Haiku never was that for me, so I haven’t used it much at all. Linux has unique applications that I need. Novelty? I mean its fun getting other things to work on alternative operating systems but most of the time what is interesting is the windowing system. And lets face it, its easier to explore unique windowing on Linux where everything else just works.
My question is why we expect these apps to run worse on Haiku?
Linux has had to be dragged kicking and screaming into being a desktop OS and it is still not totally there yet. BeOS was designed as a multimedia forward, performant, desktop-first operating system. Haiku has been designed to fill the niche that BeOS left empty. I think it is doing a great job.
On the same hardware, I think Falkon runs better on Haiku than on Linux.
As for native apps, I think there are more of them and higher quality now than ever. Most likely that is because Haiku is more popular now than ever. A lot of that is surely because it is almost practical to use it. It is exciting. If Haiku had stayed “pure”, there were probably be 6 apps as you say and most of them would be largely abondoned. Instedad, Haiku can afford a full-time paid developer and independent YouTube channels are declaring it daily drivable. That attracts users and devs. Web Positive itself is likely in better shape than if the community was smaller.
Haiku is not OS/2. Open Source apps appear where there is a community. There will be native Haiku apps when there are enough Haiku users.
But what is a “native” apps these days. Is WebKit2, the future core of Web Positive, Haiku native?
I am writing this comment in the Ladybird browser. I cannot wait for a port to Haiku using the native Haiku GUI. If I can find the time, I may do it myself. Most of the code will be shared with SerenityOS though. Will it qualify as native?