Some history about Firefox and BeOS. Before Firefox, there was Mozilla, which had a BeOS port (called Bezilla). Bezilla was bloated and slow. So the BeOS community tried to make a stripped version of Mozilla with only the browser (minus all the bloat). This project became an inspiration to do the same for Mozilla, and that product became Firebug (or something similar - edit phoenix, then firebird), which due to trademark conflicts got renamed to Firefox that we all know today. So in a round-a-bout way, we have come full circle after 20 years, Firefox is finally ported to the platform that inspired its creation.
Kind of poetic. We should write a 3-5-3 Haiku about this journey.
It wasn't Firebug, that was a developer tool extension. It was first Phoenix which hit trademark issues, and then Firebird which hit trademark issues, which then became Firefox.
From what I remember, Firebird was more related to the database open source project which was a fork of InterBase, so at that time it was relatively well known due to its roots with IB.
Maybe it hit trademark issues, but the reason I remember from slashdot was that phoenix was already a semi-popular open source project in the debian repository, so firefox had to be named from phoenix to mozilla-phoenix. But firefox at the time still named phoenix just ran so much better on windows than linux, it was funny.
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.
I thought Phoenix may have just made that up because they were miffed about someone in tech using their name, but no, they actually did have a "BIOS web browser"!
> We had two columns of names, forces of nature and animals and were pairing them up.
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.
Ah neat, I didn't realize it was the bios maker that was behind that one, I thought it was the IBPhoenix product, it's been way too long since all that happened and I think it's all gotten jumbled in my memory.
Phoenix was because of a challenge from Phoenix Technologies, the BIOS maker. Firefox was because of concerns about stomping on a small OSS project, the Firebird Database. I was responsible for all of this at Mozilla. Happy to answer any questions.
Thanks for clarifying! FWIW, I wasn't there, but that matches exactly what I remember from that time (I did follow all the different renamings in detail).
With a fraction of the userbase it had 20 years ago, thanks to everyone that keeps shipping Chrome with their applications, testing only with Chrome developer tools, and so on.
Anyway, congratulations to anyone involved in the port.
Wouldn't 20 years ago have less people using Mozilla/Firefox since everyone was still using IE6? I remember around that time i was still encountering several (public, not internal) sites that refused to work with anything that wasn't IE6.
I think at least nowadays people try to pretend they care about web standards.
Sadly I now see sites refusing to work unless you use Chrome even though there is no technical reason whatsoever why it should break under other standards-complaint browsers. I've seen all sort of tricks to detect non-Chrome-usage and the result is anything from a snarky message advising you to use Chrome (sometimes a very specific version and OS is specified as well!) at best or a blank page at worst. And yes every time I've seen this, it's happened on public facing sites -- I'm lucky that at $WORKPLACE we are a Microsoft shop, and Microsoft (ironically) seems to put some effort into ensuring their tools works across all the 3 major browser engines (with the possible exception of Teams but I reluctantly use the Electron app for that). Chrome has become the modern day IE. The mainstream population just haven't realized that yet to be fair, but this will become clear in the years to come and the next generation will wonder how the heck both IE and later Chrome become dominant.
> and Microsoft (ironically) seems to put some effort into ensuring their tools works across all the 3 major browser engines
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.
At the turn of the century, Mozilla are trying to ship a web browser (also to be called Mozilla) based on the work they've got from Netscape. They shipped a series of "M" numbered (ie milestone) releases, which preview what we today think about as normal dynamic HTML but at the time it commonly just crashes the entire browser.
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.
Yeah. We were all sick of loading a website with Internet Explorer and getting 1930201 hot toolbars, blinking 'desktop buddies' and 32 new system tray icons with programs running.
Konqueror says hello. I’m only half kidding, it was actually somewhat capable and I used it a lot. For those who don’t know, its legacy was khtml, famously forked into WebKit and Blink.
chrome eat their lunch for only one reason: everytime you were doing a google search, google literally begged people to download their browser while half of the smartphone were coming with google chrome by default.
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.
Firebug was amazing and one of the reasons I started doing front-end development again, after swearing it off because IE 5.x made it such a frustrating experience.
It flat-out made training people on CSS tolerable. I could have them install the Bookmarklet (before it became an Extension), show them how to use it, and boom, instant productivity boost. Being able to dig through the DOM and figure out what element was applying excessive margin or padding reduced 80% of my "heeeelp!" requests.
Within months I couldn't imagine working without it.
> Some history about Firefox and BeOS. Before Firefox, there was Mozilla, which had a BeOS port (called Bezilla). Bezilla was bloated and slow. So the BeOS community tried to make a stripped version of Mozilla with only the browser (minus all the bloat). This project became an inspiration to do the same for Mozilla...
I have said it before, Haiku feels like it is simultaneously 20 years in the future and 20 years in the past. The interface is so incredibly snappy but there is a lot of basics missing such as WiFi support.
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.
I absolutely adore the way that HaikuOS looks and feels. It's like a direct evolution of the classic Mac OS UI. So incredibly snappy and responsive and with minimal visual clutter. I keep an old thinkpad around with Haiku just for when I need to do word processing with no distractions.
Right but we need a dose of realism. They don't develop the drivers, and they don't make the hardware. If the manufacturer doesn't care, then that's that.
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.
Mac OS 9 felt pretty darned fast on my 400Mhz iMac G3 back in 2000. Same for Windows 2000 on my parents’ PIII 750Mhz Dimension 4100. The only time anything felt slow is when a significant amount of data needed to be loaded from their hard drives.
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.
I think the rule (at least while Moore's law was in force), was UIs start out boated but become fast as the hardware catches up. For instance, your example:
> 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.
Not only slower, right? I mean, for UIs, there is the same race to the bottom going on as in other parts of the industry.
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.
Same for MacOS 6 and 7 on period hardware. It’s anything but snappy. MacOS 7 on PPC was snappy compared to Windows 95 on Intel, and that’s it. Amiga was snappy, compared to Windows, but I have a working Amiga 600 and it’s not a great platform even for email.
The apps were snappy, but the hardware wasn't. Every menu/window opened immediately and without unnecessary animation... unless it needed some unexpected processing - then you were potentially waiting for the spinning rust to handle the swap file.
The UI was minimalistic, but with better hardware we also wanted nicer fonts, transitions, wobbly windows (I actually miss those) and countless other nice things that take time.
Also, it’s pointless to open a menu in less time than it takes the screen to refresh.
I strongly disagree with this statement. Every new version of Windows feels slower than the last one. Linux DEs are either very outdated and very snappy or somewhat modern and only barely snappier than Windows. I have zero experience with MacOS.
CRT screens were also 60Hz.
Look at the latency along all steps of the pipeline to get a keypress visible on the screen... https://danluu.com/input-lag/
Many were above 60Hz and it depends on resolution. An iMac G3 for instance could do 75Hz at 1024x768 or 640x480 at 117Hz. Someone recently got a CRT at 700Hz too:
No, an extra ~17 msec of delay is not even close to the cause of this. The speed difference between older and newer UIs is still apparent even at 60 Hz.
Future comes in at point were we actually circle back. "Black is always in fashion" kind of thing.
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.
That's actually amazing. Can't wait for dockable apps support. That could be a killer app for operators - half desktop, half monitoring dashboard, haha :) I can already see those dockable tiles with Prometheus metrics.
The thing I liked most in the NeXT was the sparing use of color. It was part necessity, but also usability. What does the color of the window bar being blue communicate?
I am an enthusiast for Gnome’s less is more approach.
I have 3 x64 boxes with 3 different wifi chipsets that work with no issues. The only chipset that doesnt work for me is the bm4360 chips used in Apple hardware. A 7$ usb wifi dongle solves that problem.
How would you use WiFi on Haiku if it were there? I thought people mostly use Haiku inside VMs like VirtualBox so network connection goes through an emulated fiber.
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.
The raspberry pie is a very odd computer which is hard to develop for. There are much better targets that are both simpler to develop for, cheaper, and easily available.
And we never really got any of them working, so I would contest that. Many years ago, I asked about Pi 2 support on the Haiku forums and there was a lot of ill will towards Broadcom closed binaries. I pointed at the Plan9 port and a couple more examples and nothing happened.
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.
The RISC-V port was done almost entirely by one developer who took an interest in it. It wasn't as though the project got together and decided to prioritize RISC-V over ARM; it was just that someone did a port, and then it got (mostly) upstreamed. Nobody has taken an equivalent interest in ARM, in large part because, well, the developers are all running x86 machines as you might expect, so that's what Haiku gets developed on. If someone comes along (or one of the existing developers takes interest) in working on the ARM port more, we will hardly reject the patches!
Opinions aside, they just don't have the resources for ports. That's the shame: that this project isn't more popular.
Linux doesn't have this problem anywhere close to the way Haiku does.
I am, although I do not use it as a daily driver, I have bare metal installs on two different computers. In my experience, it is very snappy, and always fast, except for some browsers, and wifi support for my specific wifi cards is there, and works fine, although not perfectly.
In regard to using it as a daily system, browser-wise, especially since Firefox has been ported, it works well enough. Webmail can be used fairly easily, but most of the email clients available only support regular pop/imap authentication, and not oauth.
But then, whether you can daily drive it depends on your specific use cases and hardware.
What would be interesting is if AppleBe still ends up merging with NeXT a few years later, and Jobs doesn’t immediately scrap the hybrid BeOS platform immediately…
Given the famous keynote where he announced killing OpenDoc and other efforts, I am not so sure about that, regarding scrapping the hybrid BeOS platform.
I had decent success with it on an 11th-gen Framework 13. Power management was finicky, but it was also finicky under OpenBSD, which makes me think it was a hardware or firmware issue. I haven't tried it since upgrading to the latest firmware, so maybe the combination of that plus whatever bugfixes have happened in the last couple years might've improved things.
My guess - BeOS and Haiku are not Linux based systems (not BSB, nor any other OS.) People that use Haiku probably do so out of choice and I guess they already know Linux exists. If they wanted to use Linux, they probably would. IMO, stating "just use Linux" therefore seems super obnoxious.
Beautiful to see such passion and great execution, especially for 20 years in a row.
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.
I think it's more likely the original BeOS source code contains proprietary code licensed from third-parties, which means someone would have to spend significant effort on figuring out what can and cannot be released.
Much worse, it's likely the BeOS code includes a bunch of unlicensed stuff. Be had been caught more than once "accidentally" including GPL'd code in their proprietary OS back when they existed. I doubt it's just GPL code that "accidentally" gets copy pasted into a codebase like that. If somebody has the code (e.g. from a previous job) it's getting pasted in "Just temporarily" and never being removed because there are always higher priorities.
(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...)
Just another proof that copyright laws must be heavily reformed asap because they continue to harm development also in cases where any reason of protecting some company's IP is long gone.
Is it though? I think there's scope to improve the laws around intellectual property, but I feel like it's a stretch to suggest that the lack of BeOS source code "harms development".
An open source desktop OS that was basically usable for day-to-day stuff and easy to install, released in 2001? I don't think it's hyperbole to say that that would have changed the course of computer history.
Were you there at the time? Because I was a big computer nerd at the time, huffing all the OS/OS fumes I could get my grubby little hands on. Windows 3 had already won the game -- and that was when non-computer-nerds were asking their computer-nerd friends for advice and getting PCs hand-built by the same. When win95 came out, the non-computer-nerds forgot that the command line existed. When win98 came out, even computer-nerds were losing interest in the command line. Win2k was (imho) the best windows operating system ever released. It was extremely stable and usable, supported everything but apple software and a few bits and bobs that nobody but us nerds cared about, and it took serious effort to buy a computer that didn't have it installed by default.
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.
Palm bought BeOS back in the day, but they didn't do anything with it. It was spun out with the PalmOS into Palmsource when Palm went to other OSes, so it didn't follow the rest of Palm into HP (and then LG). Palmsource was then swallowed by a Japanese company called Access, which was and apparently still is making a browser for embedded applications called Netfront.
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.
> 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
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.
That made me think how many non-Unix FOSS operating systems are out there? Haiku, FreeDOS, Genode, ReactOS, Plan9, AROS, and RISC OS comes to my mind quickly.
Arduino (yes I know it isn't really an OS, but still), Zephyr, Oberon, Active Oberon, Inferno, mBed, Android and Chrome OS (Linux kernel isn't really exposed to userspace as in an UNIX system), Azure RTOS.
I seem to recall trying Firefox on HaikuOS circa ~2011, though searching around now it seems it was based on an outdated version at the time. Kudos for a modern port project.
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)
Are you telling me Windows XP is out of support? When did this happen?! :-D
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.)
Its not that easy. Win32 API is not static, in evolves. While yes, it can provide great backward compat, new stuff is introduced ever new OS release (or Win10 update), so its pretty much easy to destroy portability to older version. To keep portability, you must target lowest API version you want, and keep it using like this.
Windows XP machines should not be connected to a network because they no longer receive security patches. They will get hacked if they are connected to a network (and please remember that not every piece of malware is obvious, some malware is stealthy, and just steal information from the hacked machine).
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.
Nostalgia is a powerful thing :) I have that for Windows 95 and 98. During the XP era I was mostly using Linux, though I did use xp for gaming every now and then.
And Retrozilla with the MSFN hacks to state TLS 1.3 at about:config
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...
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.
The question of "Is it more stable than other browsers" being "It can't render text" is somewhat hilarious.
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.
They didn't port it, but the first one (or rather the second one, but it doesn't matter) once we launched some new version via Wayland. So far, everything has not been tested enough and there are no implementations of different platform code, as a result of which it often crashes. This is still a draft port, not suitable for the average user.
Someone wrote an article much ahead of time.
Funny to see the main question in the forum is "How stable is it?" and does it crash less than other options.
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.
"Modern tech" often require significant corporate backing and/or significant amount of funds. I'm amazed that Haiku OS is still going considering it's surviving on donations.
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.
Beyond discussing what Modern C++ actually means, Andrei Alexandrescu book, C++11, C++14, C++17, C++20, C++23, this only goes to show how "modern" is the C++ code from companies that should know better as WG21 members, and C++ compiler vendors.
Let alone those that aren't neither WG21 members, nor C++ compiler vendors.
wtf? Now I am switching! :-) Oh, I get it "The current status is that no text can be shown due to some rendering issues,so it is not usable at all" (nine days ago). Still, if you got Firefox you are ready for mainstream adoption.
Kind of poetic. We should write a 3-5-3 Haiku about this journey.