Stop blaming everything on WebKit2. The current regression in WebKit is entirely my fault, and I “just” need to make a new release.
You misunderstood - I was not blaming you or webkit but merely referring your own words as I often read in the forum here that “with webkit2 this would not be a problem since only the tab’s render thread would die and not the entire application”.
You’re doing a great job with webkit and I’m happy to use WebPositive for quick and easy surfing the web. Previously it was only really useful for local docs simple web sites, but now it’s already usable for a lot of web sites.
I wanted to say that webkit2 could benefit from Haiku’s pervasive multi-threading and show off the system for R1.
Everything can be done. Who will do it? Personally I think it is not very useful and I don’t expect to still be running 32 bit apps in 2038.
The compatiblity will not stop because of unsolvable technical challenges (we can always, in theory, add symbol versionning, write a compiler that emits GCC2 ABI, etc). It will die of lack of interest and people chosing to solve other problems.
Nowhere I suggested that.
The data-centric way of working does not have to stop at the local filesystem. My plan for this (but I had no time for it yet) is to fork imuse (IMAP FUSE filesystem) and have it expose the emails in a format understandable by existing Haiku mail tools. Then I can mount my mailbox when I need to access my mails, and I don’t need the complex synchronization with the local filesystem. And if I need a local copy of some emails, it can be implemented as a simple file copy operation (either manual, or scripted to always have the last 100 or 1000 mails locally) using standard tools (Tracker, query, rsync, find, …).
Yes, but not in this specific case. There is a bug that would affect both versions here, and I’ll ship a fixed version soon.
It doesn’t. It uses multiple processes, not multiple threads (or at least, not more than in any other operating system). So there’s nothing really Haiku specific in that area. O nthe contrary, being forced to handle multiple threads makes things a little bit more complex in WebKit (and most ported applications).
Be marketing team was surely very good at turning any design decision - good or bad - into a marketing selling point that lasted for 30 years
I hope that Haiku project will not refuse accepting patches to keep compatibility.
Also interest in retrocomputing is much higher than you expect. Many Haiku users are use Haiku on old 32 bit machines. For Windows, community managed to implement 3rd-party compatibility layer to run 16 bit applications on latest Windows versions, including 64 bit. It even have 2.7k stars on GitHub. Hobbit Bebox emulator was made. I would be not surprised if someone will reverse-engeneer Hobbit BeOS app_server etc. protocols and make possible to run Hobbit BeOS executables on modern Haiku. Or make possible to run BeOS R3 PE executables on modern Haiku using Clang compiler in MS C++ ABI mode. Many open source contributions are done just for fun, because it is interesting and challenging, not because it have big practical importance.
Yes, of course, as long as someone is working on it, it keeps working. As I said, it will die by lack of interest at some point, but that is hopefully far in the future.
I don’t think you know my expectations in that area very well. I am very much involved in that as well, making new hardware and software for Amstrad CPC computers for example.
So, as long as someone wants to do the work, no problem from me (and, I think, from other members in the team - we would not be basing our work on BeOS and maintaining compatibility for so long already if that wasn’t the case).
You can get to that place other ways - it isn’t the killer feature of the mail daemon. Unless I’m missing something here, all you need is an email application that can fetch all your mail, and store it with attributes. Don’t even need IMAP.
I use it for a mail archive. I don’t want to move current mail to my Haiku partition, but before I delete old stuff, I copy it to a USB drive - in Email style, so I can query into my old emails. Other users may want all mail downloaded right away, or none. A good email client will offer those choices, and it doesn’t have to be “Thunderbird” size. My proof-of-concept client is implemented in Ocaml and comes up ca. 9/19 Mb, compared to say Deskbar at 7/17.
of course, we are on the same page then.
I was referring to the data storage side - often the kind of applications I was talking about insist on using their own SQLite or similar isolated storage when it’s not needed with such a fast file system.
The only benefit I see to rushing towards an R1 release is so the BeOS backward compatibility can be dropped. It’s good to keep that (in the 32 bit x86 version) until an R1 release.
As for necessary features… for me it would be virtualization and VPN (openvpn and/or wireshark) support. But they aren’t hard requirements, just the things holding me back from daily driving Haiku.
The thing is, once R1 is released and a lot more media coverage is coming this way, a lot more support is going to be expected for when issues do arise. Also possibly more funding, but that’s not guaranteed. If people run into things like “my 3D card is not working”, and “how do I install Chrome” … the publicity might become a curse instead of a blessing people will lose interest just as quickly.
It’s not a bad strategy to aim for another couple of Beta releases in the next few years. In my opinion, for a project like this “when it’s ready” is good enough.
It’s not my decision, though… just my 2 cents… I feel like the decision makers are capable enough to decide what’s best.
I think this is a misconception as well. If we ant good media coverage, we have to build it, and that’s done with press releases, communication kits, writing articles to be published, etc. It has little chance of happening on its own. Our usual supporters/followers in the press can only do so much, and they already do their part with every beta release. But you won’t suddenly get the attention of the mainstream press just because a version of your software is numbered differently than the previous ones.
Web browsing, watching videos, using your monitor at the native resolution, compositing, video editing, 3D modeling, all benefit from 3D acceleration. Even GUI toolkits these days expect 3D acceleration.
Also, while I get that some people dismiss video games as unimportant, a huge chunk of computer users actually do care about gaming. Most young people especially will not use an OS if it can’t do gaming.
Security: Windows has always had pathetic security, especially back in the XP era, and everyone kept using it anyway. It won because it was pleasant to use.
Web browser: This issue seems to be largely settled.
So yeah, the driver situation (especially 3D acceleration) is the biggest issue right now.
We already have this, and with @kallisti5’s latest changes to Haiku in the nightly builds and OpenVPN itself, it should work out of the box with no extra configuration required.
Working on 3D acceleration drivers is still on my TODO list, so eventually I do plan to get to it (maybe even this year), but there are other things that are higher on the list, like the “general system stability” items (some people may not have seen KDLs in months, but there’s some that are still easy to trigger with Iceweasel, for example, so there’s more work to do here) and things like that. I’ve spent most of the last month on virtual memory related changes, mostly tied to Iceweasel and other browsers but also just general cleanups paving the way for a future switch of the libroot malloc implementation (more on this in the activity report, which I intend to complete today.)
Having 3D drivers would be nice, but there are other things impeding more people from using Haiku more or from switching to Haiku entirely which are “lower hanging fruit” than 3D, so that’s what’s been my focus and will probably continue to be my focus, for contracted work.
Current definition of Haiku R1:
“Essentially, a fully working and stable operating system. A viable replacement for BeOS R5 (and later).”
Key words: “viable replacement”
Win 95/98/Me product support ended around Y2006. These were all fully working and stable operating systems. Windows 10, a recent and modern fully working and stable OS release, will have product support ending Oct 2025.
I’m using the MS Windows product offerings for comparison - in terms of stable and fully working OSes and OS-related software bugs. Haiku has provided 20 years of support of BeOS R5 compatibility and application support - which is quite an accomplishment. If I look at macOS 9.2.2, product support ended 23 years ago - by comparison.
macOS 8 and 9 only lasted 2-3 years after product release. Some of these OSes had over 500+ software engineers supporting them. Haiku’s users are using most of the same native BeOS R5 applications for 20+ years.
There was a virtual BeOS R5 desktop service and BeOS R5 Personal Edition is still available online for 100% software compatibility. I’m sure a VM within Haiku x64 can do a decent job providing BeOS R5 x32 support if needed.
As for 3D drivers, mainly provision the OS to support the “certified” drivers directly from the 3D graphic card providers - provided for FreeBSD and/or Linux (if not native).
I would love to have 3d acceleration for Haiku-OS. We try to start a 3d gaming business++ and would love to be able to use Haiku for development. The games would also be available for Haiku then. It would require support for at least one current(2018+) graphics board. Also nvmm would be required a bit to be finished. Meanwhile I just follow Haiku’s progress.
For me, it will do with the following:
1- Better wifi and wired ethernet support (a laptop I have for haiku needs a usb-wifi adapter).
2- Better video support. I mean recognize the display aspect ratio and resolution properly.
3- Better trackpad support. Same as 1
4- Multi monitor video out.
5- Working sound
And of course stable. That for R1 will do.
Nonetheless, I’m leaning more towards a 2 model release:
Haiku R: Haiku Release, stable, rolling
Haiku N: Haiku Nightly, not so stable, testing, rolling, when packages stable, move to Haiku R
And of course, but these for later:
Security (encryption, login, …), Lock the computer. I don’t want suspend nor hibernate nor sleep. Always turn off, keep the drive encrypted and login.
3D accel for Blender, videogame, …
Option to remove demos, and other “system” software. Even though hard disk space is cheap, I don’t like to have installed things that I don’t use. At least I should have the option to remove them. Not like allowing users to remove kernel, servers… or system critical stuff, but CodyCam, Deskcalc, MidiPlayer, TV, Poorman, … Destkop applets not used, like Launchbox . Actually I don’t like desktop applets. Had enough of them by the time of Karamba and SuperKaramba.
Compatibility with older software could be achieved in many ways, from running inside a special haiku virtual machine, to adding an API compatibility layer used by old software, or to running inside a chroot (thinking about Fedora’s toolbox). Then again, manpower has its say. What I want to get and what I can get don’t necessarily match each other all the time.
Then again, I might need old software to deal with files made using said old software, and this, depending on how the developers of the said software code the filetype version. Some programs import older version files better than others.
Then again, what the devs mark as R1 is going to be R1, so that will do too.
Everything except 4 is already working if you have compatible hardware. I think it is never become possible to achieve 100% hardware support coverage, even Linux have problems with some WiFi adapters.
