We have a ram cache already (that is implemented by WebKit without special efforts on our side). It is used when you navigate back/forward between pages. But I think it works only for full pages and not specific resources.
4 Likes
So expanding the use of cache (ram and disk) should definitely improve the situation âŚ
I remember, a few years ago, when the Mozilla team decided to rewrite everything a bit focusing exclusively on performance with the then project codenamed Servo, which if Iâm not mistaken is largely included in the new versions of Firefox, definitely improving its performance. Perhaps inspiration could be drawn from the research they did. (it is right to highlight an example)
There was a firefox port longtime ago, but no body maintained it.
There are not only porting that needâs to be done, Someone needs to keep the ported program updated. Even perhaps redo the port when the developers refactor the program.
2 Likes
With the most popular browsers, ports to OSes such as Haiku would probably be difficult to maintain because of the rate at which upstream updates are released. I think for Firefox/Chromium in particular, this would be an issue - I think they release updates for both of those every 2 to 4 weeks? That seems like it would be hard even for an entire dev team to keep up with, much less a single developer.
Of course Iâm not an expert in such things by any stretch, but I figured Iâd throw this into the discussion, since it seems nobody else has mentioned it yet.
1 Like
The return of investment for the ports will always be debatable at this stage, at this low number of daily driver Haiku users.
For such big efforts like Chromium and Firefox, it might be a better approach instead to modernise the OS under the hood, improving POSIX compatibility, stabilising the system, and making the Haiku experience overall more pleasant would lead to more daily-driver Haiku users, thus opening the door for more technical people that would potentially help in porting.
1 Like
And somebody will come and tell: âYou guys just pimping Haiku, but how come nobody attempted to port Cr/FF yet? That would bring more users, i think! Web is the most important factor! Do you agree?â
1 Like
The proper link to Servo is Servo.org. Itâs not finished yet but is written in Rust 100%. Maybe once we get Rust working 100% on Haiku, we can look into using it as an alternative or even a primary browser. Itâs currently maintained by the RedHat subsidiary of IBM.
At what point is Rust support on haiku?
Is it also as complex a situation as it is for browsers?
sometimes it seems you donât understand.
instead of thinking about a new port, download the NetPositive sources and start studying them.
the time you wasted writing these posts, maybe you would have already solved a bug⌠
2 Likes
Are you saying to me or is it a more general comment?
Because if you say me, once @PulkoMandy made me understand the situation more technically, I stopped thinking that a port of a mainstream browser would have been better.
The rest are questions for in-depth analysis.
Why do you think these posts are a waste of time?
there are many people of the low technical level like me, who will probably have clarified many issues by reading them. Then you tell me to go and study the netpositive code,
If it were 10 years ago, I might as well have done it, but I donât have a developer background. I have other skills and maybe what do you know, maybe Iâm already putting them in place.
3 Likes
Haiku has Tier 3 support for Rust. That means someone stepped up far enough to maintain a cross-development target for people to generate Haiku programs from the Tier 1 platforms: Windows, Mac, Linux and other more mainstream platforms. That minimal Rust support is x86 and x64 only at this point.
Do you have specific examples of POSIX functions that are missing in Haiku? Or is this just handwaving at a random problem that probably does not exist?
Also I am surprised that someones managed to put âPOSIXâ and âmonderniseâ in the same sentence. POSIX specifies the good practises from the 70s and 90s. Everything else is BSD or Linux specific extensions and it takes decades for them to agree on something and then add it to the standard after all the other existing POSIX implementations have caught up.
In other words, POSIX is there just to say âthis is already implemented everywhere, letâs add it to the standardâ, and not to add new things to operating systems.
1 Like
Maybe i am misunderstanding you, but i clearly remember to being able to compile programs with rust on Haiku, without crosscompiler, natively on Haiku.
We even have recipes using rust.âŚ
1 Like
Nah, just mentioning.
The buildbots cross-compile from another target but thanks for the link. Maybe I can get that to build on my Linux box.
Tier 3 is âdo it yourselfâ. Tier 2 is âcross compiler targets are hostedâ. Tier 1 is ânative support is providedâ.
I have an ulterior motive for adding WebAssembly support to Haiku: WASI has tier 2 support. That would be an upgrade for us.
I assume you are talking about the rust recipe. The builders downloads prebuilt binary artifacts and packages them, then using the resulting package a different recipe builds rust on Haiku.
The artifacts are probably made by crosscompiling, but the HaikuPorts build slaves doesnât cross-compiling them.
1 Like
@extrowerk Thanks for the tip! Rust is installed now!
@thread
WebKit isnât infallable, apparently. Either Microsoft is doing something funny with GitHub or WebKit needs an update. Neither Wayfarer on my MorphOS box nor WebPositive on Haiku can log completely into GitHub.com as seen below:
1 Like
What makes you think this has to be a webkit fault�
Wayfarer and WebPositive are WebKit based browsers. It could potentially be some JavaScript implementation for WebKit also.
Most issues will be due to problems in the Haiku WebKit port.
But I do see issues with Safari which I use on my work computer running macOS. Badly written websites which use things like Chrome-specific regular expressions wonât work on Safari (ironically this example is the major web application of my company 
.)
It also does not work well in Google Meet either, likely because Google is using features that only Chrome implements. In fact Google Meet also doesnât work well on Firefox. Overall Google Meet sucks so it is not really a good data point I suppose.
But there are things that donât work on WebKit but not that many.
2 Likes