Firefox Browser Ported to HaikuOS
discuss.haiku-os.org
discuss.haiku-os.org
Kind of poetic. We should write a 3-5-3 Haiku about this journey.
Phoenix Technologies, the BIOS maker sent me an email telling us they made a BIOS web browser and our name would confuse things. Under advice from our legal support, we agreed to change the name.
We changed to Firebird and the OSS database project bombed my inbox (and Mitchell's too) for a week with hundreds of nastygrams and though we were in the clear on TM, we didn't want to stomp on the little OSS project so we changed again.
I was at the whiteboard when Jason Kersey of mozBin, mozillaZine, and later Chrome fame came up with Firefox. We had two columns of names, forces of nature and animals and were pairing them up.
https://web.archive.org/web/20020618092004/https://www.xbitl...
which if you're interested—Cathode Ray Dude on youtube has several episode series all about that weird and wonderful point of computer history
Nice. Now I wonder if the ~0.8? era extension "Firesomething" was directly inspired by that whiteboard. IIRC it randomly combined two components from lists.
For firebird, https://www.cnet.com/tech/tech-industry/mozilla-holds-fire-i... and https://www.cnet.com/tech/services-and-software/mozillas-fir... in this case it was AOL Time Warner that owned the Firebird trademark for the database.
2) For Phoenix, https://web.archive.org/web/20070914035447/http://www.ibphoe... the main reporting on it seems to be lost but wikipedia still backs it up
Anyway, congratulations to anyone involved in the port.
I think at least nowadays people try to pretend they care about web standards.
I don't know why that's ironic. The Microsoft web teams have always had a focus on being fairly standards compliant. The Microsoft Browser team themselves definitely went down a route of stagnation with IE6, but a lot of that had to do with W3C's stagnation as much as Microsoft's anticompetitive behavior. They also implemented massively useful technologies that are ubiquitous today, such as XHR.
They get a bad rap, for deserved reasons, but that decade of stagnation and non-Standard ActiveX controls wasn't fully on them.
Like, a colleague was working on code that would reach into the DOM and just tweak the CSS for a bunch of items, delete other items, move things around, and maybe 40% of the time it would work as intended, and 60% of the time, boom, dead browser, segmentation fault.
React, where it's just normal for Javascript to rewrite the entire page in response to a keystroke, would have been completely unthinkable, there's no chance you could fill out an entire form before the browser crashed if you do that.
We are talking about V8 being released in 2008, Chackra in 2011, and SpiderMonkey in 2009.
With GCs that can handle the amount of stuff that React throws away on each update.
Relevant: “A Visual Browser History, from Netscape 4 to Mozilla Firefox” https://www.andrewturnbull.net/mozilla/history.html
Phoenix saved us.
From a community perspective, it would have been a great thing to push it forward further, spend resources on it, and have at least one web browser that isn't somewhat wicked.
Admittedly, back then, we all hoped that Firefox would be that 'friendly' browser, and it probably truly was at that time.
Time has changed. Now I'm forced to like a browser that is always just slightly less evil than a one that would even IE look friendly. And with every version we are now waiting when they also will drop the manifest v2 support for dubious reasons. And even if that will never happen, they will continue to find other ways to disappoint me.
Yes, khtml was at least a nice time to remember. :)
PS: My personal feeling is that "impressive but not good enough as a daily driver" was and is true for some more KDE apps. This is why I use Plasma Desktop, but barely any more of their apps than Dolphin and maybe kate to some degree. I know all you're going to say now about free software and how it works and so on, and you're right, but technically, it would be sooo much better if just half of the email client projects (or office suites, IDEs, photo editing, ...; you name it) would exist, but with more developer powers behind it. But I'm digressing......
Shame it hasn't kept up.
Google was force feeding Chrome to everyone at google.com.
Unfortunately Mozilla’s refusal to implement process-per-tab, combined with Flash’s instability, let Chrome eat their lunch.
In the head of people google and chrome slowly became a synonym of internet the same way the ie icon used to be in the previous decade.
What you mention was certainly a major reason, but not the only one. Another one was that Chrome was simply a better browser for many years for normal users (mainly because of its performance).
Native front ends like Galeon on Linux and Chimera/Camino on Mac inspired Firefox (m/b->Phoenix->Firebird->Firefox, my bad that naming mess was also my fault, see Chimera->Camino for more of my handy work with AOL lawyers right before Netscape shuttered and we got our independence with MoFo.)
We kept XUL because Dave made it great on Windows so no native front end but that let us preserve extensions and re-used a few key widgets in XPToolkit easily.
Bezilla was just another Mozilla suite port, one of about a dozen at the time, one that never got any core Mozilla team attention except as a niche port we were happy to host, so suggesting it was inspiration for what Blake and I did to get Firefox going (and later Ben, Dave and Joe and others) is a bit off-track.
Within months I couldn't imagine working without it.
I see no mention of that on the Firefox Wikipedia page: https://en.wikipedia.org/wiki/Firefox#History.
wings then fox feet now return
whence they were kindled
There wasn't a trademark issue, the Mozilla team opted to change the name out of respect for the other OSS project (Firebird SQL).
Through BeOS becomes
Firefox
It might be very useful
But now it is gone
Seeing a modern browser supported does fill a big gap however. Who knows maybe one day through a series of silly unpredictable events it will be the OS of choice and running Ladybird browser in a similar fashion.
Edit: https://www.haiku-os.org/docs/userguide/en/workshop-wlan.htm... here wifi seems to be working (which another commenter pointed out as well)
[0] https://lore.kernel.org/all/20070405163434.GA18477@gollum.na...
It's a network problem. Manufacturers aren't gonna care unless it's a big OS with lots of users. Your OS won't get a lot of users unless it has drivers. So the result is stagnation, and only the Big 3 OS continuing. Well... really the Big 2. Mac OS is a unique situation.
So that feels like its 20 years in the past
> there is a lot of basics missing such as WiFi support.
So that sounds like 20 years in the past too
Where does the future bit come in?
Try using the old analog control systems where responses are basically instant. It feels like the controls are reading your mind.
Not all machines were like this though, we also had a Compaq Presario with some kind of Celeron running 98SE and that thing did feel slow more often than not, especially after several months of usage with the cruft buildup that comes with that.
> Mac OS 9 felt pretty darned fast on my 400Mhz iMac G3 back in 2000.
You were using a UI that (at its core) was built for 1984 machine, with sixteen additional years of hardware performance improvements.
Every once in a while I boot up a Mac from 1989, and Mac OS is definitely not snappy on it.
I think if you want speed, you need to find something built for a system far more constrained than the one you're actually using. The choices the developers made to make the system merely usable under those constraints will make it fast once they're removed.
We could have really snappy stuff today, but have gotten enamored with our latency inducing abstractions and haven't really gone back to fix it.
80s and 90s bloated UIs sure seem snappy and miniature by today's standards.
It needs to be a big show, and everybody must be able to directly understand it without any learning curve or even rtfm.
Everything else (ergonomics, features, ...) are too often secondary values.
I wouldn't say that UIs were great in the 90s. They weren't. It was also harder to implement them. The programming languages were more tedious, low-level, etc.
But as so often, it's disappointing what we do with our additional power today. Snappiness wouldn't even be my first concern, though.
https://news.ycombinator.com/item?id=36446933 - Windows NT on 600MHz machine opens apps instantly. What happened? (2023-06-23)
Follow up to the above by the original author:
https://news.ycombinator.com/item?id=36503983 - Fast machines, slow machines (2023-06-28)
Also Windows NT was released in 1993 when typical PCs were more like 100MHz, so this is getting a 6x speedup from the designed experience.
https://jmmv.dev/2023/06/fast-machines-slow-machines.html
The point is that the good old days aren't just pure nostalgia, some parts were genuinely good compared to modern bloated software.
Now we don't have such excuse, at least for non networked apps.
If you're gonna do that, then remember how much faster a well-expanded Amiga was. Even faster than any real 68k Mac when emulating Mac.
Also, it’s pointless to open a menu in less time than it takes the screen to refresh.
No, that would be the goal.
Once should be quite enough.
https://userbase.kde.org/Tips/Enable_fun_desktop_effects_on_...
I am pretty sure this is good old resistance to change. You would disabled them on all your systems, then force yourself to use them that way for a month and I am pretty sure that "disorientation" would quickly disappear.
My 22” Diamondtron went 2048x1536 @ 85Hz or 1600x1200 @ 100Hz (which is what I usually ran it at)
Ditch modern ad endpoints (a.k.a. operating systems) and go back to those distros we used 20 years ago. Accept that those don't support DRM, carefully choose our hardware (as its barely supported), and stick to it until it dies.
The thing i miss most from that time is Window Maker. I'd love to have again those tiny tiles with small graphs and buttons, but for more modern use cases.
I am an enthusiast for Gnome’s less is more approach.
Small nitpick: it was 2-bit and could do two greys in addition to black and white.
I use WindowMaker as a daily driver. Still.
I dream of Haiku being ported to Raspberry Pi and I even was sadly surprised it isn't - to me the primary value of Raspberry Pi seems it being an uniform standard hardware platform, this sounds like a great enabler for alternative OSes as lack of need to support all sorts of different hardware makes the thing a lot easier.
I tried the same thing several times with the Pi 3 and the Pi 4, and someone more vocally pointed towards RISC-V. Some four years later, there is a somewhat working RISC-V port, but in the meantime there is still no working ARM port of any real use.
On the whole, I was not overly impressed with the Haiku OS community where it regards exploring widely popular platforms that, despite having some challenges, would provide them with a larger audience. It's their call, but as an original BeOS user (and who can actually spot the Be Book from my couch as I'm typing this) and someone who's spent the past two years delving into the Rockchip ecosystem, I'm quite saddened by the way things went. It's not as if they lacked other ARM options, they just a) didn't have the resources and b) were perhaps a tad too opinionated.
However in this universe Steve Jobs never rejoins Apple, and most likely it closes doors a couple of years after Be's acquisition.
I guess certain laptop models, those that the devs use, might be allright.
Works on my old Thinkpads.
It's like a piece of art.
I suspect the company that created BeOS actually lost the source-code and that's potentially the real reason they don't want to share, because from an economic perspective there does not seem anything of value there.
(though to be honest, Android has a lot of BeOS concepts in it because the same engineers ended up working on it too. It has Binder, and Intents are basically BMessages - there are all the Loopers, Handlers and Receivers too...)
So a year after win2k is released, your selling points are "basically usable" ( vs "highly compatible"), "free/[nerd-shibboleth]" (vs "hidden in the cost of a computer"), and "easy to install" (vs "already installed"). I think it's hyperbole to suggest that BeOS being open source would have dramatically changed the course of computer history. If anything, I think it's worth considering what would have happened to the already-paltry Linux Desktop experience if BeOS absorbed developer attention.
My point was basically what you're saying: BeOS was not nearly where Windows was, but it was miles and miles ahead of Linux, and it provided a unified graphical OS instead of the fragmented Linux base with all its duplicated efforts. Now, it's hard to say whether we the cascade of attention-deficit teenagers would have united behind an MIT/GPL BeOS and succeeded in producing something actually usable by people who were interested in doing more with their computers than setting up Conky and Fluxbox to post screenshots online, but I think the landscape might have looked different if it'd been an option. BeOS when I used it in 2005 or so was already curiosity, an antique, but if you take all the people who were working on Haiku (which started as OpenBeOS around the end of Be, Inc.), and throw in a handful of the people who were working on KDE and XFCE, starting from everything BeOS could do in 2001, instead of Linux and raw X, what do you have in 2005-6 when Ubuntu started picking up steam?
The conclusion one draws from this is that "commercial development" (which is centered around intellectual property and copyright) is progressing faster than open source. In other words it's a kinda A/B test and copyrighted software is progressing faster.
From that point of view it's then hard to be convincing that adding another open-source operating system to the mix (one which has by this point failed commercially) would somehow improve development (as a whole).
(I'm referencing the original assertion in this thread; "Just another proof that copyright laws must be heavily reformed asap because they continue to harm development ")
Now clearly Linux has become a player in the server space. And the BSD's have some small market share. Would the addition of BeOS dilute those already megre resources? Can one, hand on heart, look at open-source development and say it's developing faster than commercial software? Is Firefox leading development in Browsers or is it Chrome? [1] Is Linux (even today) leading desktop development? Or is it Mac and Windows? Generally speaking, if we look at the "big improvements" over the last 20 years, are they happening in the commercial space or the open-source space?
I'm as big a fan of Open Source as the next guy. But I don't think "copyright harms development". I think Open Source is a superb benefit to humanity. But I don't think of Open Source (generally) as a hot-bed of innovation. The tag line of "xxx is an Open Source clone of yyy" seems more common than the reverse.
Do I think intellectual property law needs reformation? yes. There's a lot which could be improved. But claiming that BeOS is "proof" that copyright is holding us back is, in my opinion, a weak argument for said reformation.
[1] Yeah, I know Chrome is "open source" - but it's resourced by a very commercial company for very commercial reasons.
[2] It's also worth noting that _abandoning_ things like copyright law would affect GPL code as much as commercial code. Making everything into effectively "public domain" allows for GPL code to be shipped in binary form _without_ supplying source code.
I don't really think your idea of A/B testing commercial vs. open source holds water. Look at what happened to OS X vs. Windows during the 00's, there's no comparison. There are so many other things at play.
And after they lost to NeXT, regarding being acquired, not much else happened in regards to OS development.
You also have most of the Intent system, the Receivers and Handlers as well as a lot of the general Android API to thank Be Inc for. When you look at the Be API, you can find analogues to most of the Android API, and once you realise that a bunch of the key developers were ex-Be Inc refugees it becomes a lot harder to see what is independent development, what was influenced by and what is a straight up clone of the Be API.
Nope. The source code exists. You can find rather corrupted chunks of it archived on a very famous archiving site. The other posters are correct - it belongs to someone and they don't want to release it because it contains a lot of proprietary code and cleaning it up to make it releasable would neuter it in a way that makes it pointless. That and the ~24 years where nothing was done to it making is way past useful even to Haiku.
https://discuss.haiku-os.org/t/progress-on-porting-firefox/1...
https://discuss.haiku-os.org/t/progress-on-porting-firefox/1...
I.e.: "... /13493/143#post_143"
(If you need a modern browser on XP, in the meantime try the Chrome port:
what does this even mean???, I remember using firefox on windows xp back then, the reason they stop make a release version for windows xp because its too old and people already move on to newer windows 7 (microsoft already stop supporting it)
But to answer your question seriously. Is a river today the same it was before? Is Firefox today the same it was when XP roamed the Earth with the dinosaurs?
The answer is, no, and yes, some of it. So it's a cheeky way to point out that someone managed to get Firefox running on a presumably very different OS HaikuOS, before getting it to run on Windows XP, which arguably must be pretty similar to say, Windows 10, when it comes to Win32 APIs.
(But of course, also Windows 10 is a slightly different river to the Windows XP creek.)
Also, you connect a machine which can be hacked, you are not just hurting yourself. That machine can be used for a lot of malicious purposes including DDOS attacks, sending SPAM, allowing attackers to hide their true location, etc.
Altough with Gopher and gopher://magical.fish (and invidious instances plus Gopher services to search in Youtube and such) most of the web modulo complex logged sites can be avoided if the user wants to read some news without bogging down its machine.
Even http://portal.mozz.us works well against Gemini services such as gemini://gemi.dev to read Ars Technica, The Register, most newspapers...
El Reg: https://portal.mozz.us/gemini/gemi.dev/cgi-bin/waffle.cgi/vi...
Ars: https://portal.mozz.us/gemini/gemi.dev/cgi-bin/waffle.cgi/fe...
Wired: https://portal.mozz.us/gemini/gemi.dev/cgi-bin/waffle.cgi/li...
BBC: https://portal.mozz.us/gemini/gemi.dev/cgi-bin/waffle.cgi/li...
No videos, but you can read the articles and see the images. Pretty cool for a Pentium 2 for instance.
Anyway, Synchro.net with some NNTP client against FIDO/Dove and the actual Usenet will give and XP user far better talks on retro and current news.
Also, old IRC clients can connect to http://bitlbee.org against public servers and use current protocols such as Discord and modern IRC (TLS) and Jabber, among others.
As of five years ago I still had an open ticket for a bug in BeOS Mozilla in their bug tracker from maybe the year 2000. I tried to search for it more recently and couldn't find it.
Haiku is fantastic and seeing it still developed after 20 years is awesome.
But maybe it would benefit from some modern tech. Given the recent discussion on Swift for Ladybird, since huge parts of Haiku are written in C++ it might make sense to gradually introduce Swift to benefit from the language safety features.
Sometimes pre-standard C++ and sometimes C++ 98. There's a lot of "C with classes" and stuff that C++ proponents will insist isn't now "really" C++ because that no longer suits their understanding of the language. As is common for that era it has its own custom string type, BString, and so on.
So Swift is about 20 years over their horizon, and modern Swift is even further.
Apple, Google and Microsoft "modern C++" frameworks also use their own types, instead of the standard library.
See Android NDK, IO Kit / Driver Kit / Metal bindings, C++/WinRT and WIL.
Let alone those that aren't neither WG21 members, nor C++ compiler vendors.