Wait... what's broken?

WebKit is used by Safari on Mac and others. It’s already cross-platform. The catch is, we’re still using the same single-threaded version as MorphOS. Time has passed and a multithreaded sequel to it exists. The one WebPositive has is WebKit Legacy. To use the new WebKit would be a major ordeal in terms of time outlay and require more than one person working on it.

2 Likes

I need your color theme. It makes me infinitely happy.

These issues should be solved @bronzie94 … if you update and are still seeing them, please report on the haikuports bugtracker. BePodder might need a rebuild.

2 Likes

Webkit2 and Webkit legacy are simply apis to webkit. The webkit version we have isn’t old, it’s rather recent actually. The api we use is the older one indeed.

Using webkit2 would indeed need at least one person to work on it, pulkomandy already does a big ammount of work rebasing webkit.

I wanted to work on webkit2 and upstreaming more of our code, but life slmetimes gets in the way : )

I feel better to switch to rolling release model and forget R* releases.

3 Likes

It’s a good point. I think we should get to R1 “at minimum” since that has been the plan over the last 20 years. Then post R1 we consider making Haiku a rolling distribution?

The “scary / final R1” target generally keeps us from releasing R1 since in our minds we’re trying to “make something 1:1 the best experiences we had with BeOS”.

It’s why I keep mentioning the browser. I think if we spend some time making WebPositive “even greater”, we might be “good enough” to say R1 is done.

13 Likes

“World Class”? What even IS that? The BEST? Better than Firefox, Chrome, and Opera? Sometimes I think people throw “big” words (like “World Class!”) around, just to sound impressive. I’d, frankly, be happy if it was just as good as other web browsers, like Firefox. “Good Enough” sometimes HAS to be good enough. I’m not expecting the world… just one small island on it. :grinning:

1 Like

As I tell people, “I’m at my best, when I’m obsessed.”. That single thread means the processor is TOTALLY devoted to accomplishing what the browser is doing! Isn’t that a good thing? :rofl:

1 Like

User use their smartphone for browsing these days!
What Haiku can offer could be a great development experience!
All students at Universities and High Schools need to learn programming!

Haiku is late to become a BeOs Multimedia OS or Gaming platform atm.

Thanks for the correction. Maybe next week or so I’ll see what I can look at in it. It sounds pretty complex but maybe I can figure some web-related stuff out after gaining some experience with it.

Hey - sorry for the delay; 56590 wouldn’t boot on my machine (happens every other hrev) - BePodder works beautifully under 56595 :slight_smile:

2 Likes

All good now :slight_smile: - thanks

With permanent ABI changes or with a frozen ABI that we can never change?

Working on a rolling release has a lot more constraints to it. You need some “staging” branch to test changes before they get into the release branch still. It’s not just “give the nightly builds to all users, done”. I think some people here have a distorted view of this. Either because they are developers or because we are generally surrounded by early adopters who don’t mind running nightly builds and hitting bugs because of this. But there are, and there will be, users who do not want that. And our current policy of pushing everyone to use the nightlies results in much frustration for these people, as I think Luposian has greatly explained.

We are already way past BeOS both in terms of features and stability, so that’s not really the case (if you don’t agree, try to run BeOS and do some work with it, you’ll see how broken or limited it can be at times, even if nostalgia makes us forget that).

Pretty much no one is working on the serious remaining compatibility issues such as running games released for BeOS which still don’t work. The focus now is more on polishing, fixing bugs, improving performance, and, of course, the elephant in the room, drivers for modern hardware and it would be great to see more people poking at webkit :slight_smile:

6 Likes

I think that 3 release channels are needed:

  1. LTS (current Haiku releases).
  2. Stable (current nighties).
  3. Testing (experimental patches applied, nothing is guaranteed, may become completely broken on some configurations and may cause data loss).

With frozen API and ABI and only backward-compatible changes/extensions allowed. Incompatible changes are allowed only to solve serious design flaws. API implementation components that become obsolete and rarely used may be separated and become optionally installable like GCC 2 library set.

1 Like

The reason it’s called LTS not “A bunch of old crap from years ago” is that it has Long Term Support.

Nobody will believe you until you’ve actually delivered that support for at least a couple of years. That’s a bunch of thankless work, but the clock doesn’t start until belief catches up to costly reality. Somebody (or most likely more than one person) has to put their dreams to one side and keep stuff you wished was forgotten working for years. Or else this will not happen.

I don’t entirely agree with you, or rather, I do not think that Haiku is too late for multimedia, but yes, it is a challenge. I plan to incorporate my Haiku install into my music studio work running a synth, if nothing else, just to see how it goes. I can at this point run Haiku and use it as a basis for writing projects. I personally hate phone browsing, but you aren’t entirely wrong.

I do not code at all, but I enjoy the alternatives available to me for an os, and Haiku so far is the least restrictive and most appealing to me.

We have kept large parts of userland compiling with GCC2 (and GCC2 itself patched when we it needs to be to keep things running.) We have also backported critical fixes from the nightlies to the beta releases, including some as recently as a few months ago to beta3. So, while we could probably stand to improve in this area for sure, we already do more than some more stable projects do!

5 Likes

Oh, come on… don’t you like looking back at posts from me, ages later (Google “Luposian Bug”), and getting a good ol laugh out of it? If I’m not mistaken, I may be the MOST vocal of all posters. But that is passion in play, not trolling. And, right about now, my interest has hit a high note once again… I think I learned something I did not know/realize/remember before… stick to the betas (or “solid” releases) and THEIR updates, and stay away from nightlies… mighta kept things a lot quieter (but far less… “interesting”), if I’d have done that. :rofl:

1 Like

I think I MAY have touched on this a time or two… maybe. :rofl:

As you noted in another reply to me, deleting old code adds more complication/breakage than building new code. But I think very few people even use BeOS anymore. Unless you do the EXACT same things with it, as you did, back when it was really useful (I have MacOS X 10.3.9 running on my G4 QuickSilver and use it for only ONE thing… composing music with an obsolete program called iPiano - it’s useless for going online), you will find it’s horribly “broken” for modern use. So, the question becomes… at what point is even keeping/maintaining the BeOS compatible branch worthwhile? Who still uses it? Or do you keep things around, indefinitely, purely for nostalgia sake? Or is the 32-bit branch still a strongly desired one? I wouldn’t know… I jumped onto the 64-bit Haiku bandwagon as soon as it was a thing, and haven’t looked back since!

  • nightlies - latest Haiku changes (target: early adopters, developers, testers).

Nightlies are meant for experienced users with technical knowledge and familiarity with Haiku. Nightlies consistently change, fail, and are not firmly established yet. Therefore, Haiku’s nightlies are considered “unstable”.

Haikuporter/haikuports, changed my running systems to R1B4 earlier today.
After then running a build for new xapian failed because of packages not being able to fetch, a run for minidlna was fine, but for xapian it wasn’t able to fetch the base package (which it shouldn’t).

Failing hrev: *** Failed to find a match for "haiku_x86>=r1~beta4_hrev56588-1": Name not found

I’m guessing quite some packages need a rebuild to be able to solve this, switched back to nightly and things are running fine now.

EDIT strike that, I had my local zlib package still in */haikuports/packages that got picked up with xapian, all good now :slight_smile: