Mozilla Firefox 116 Now Available - Capable Of Wayland-Only Builds

[RejectModernity]

X11 will only die if it's replaced by X12, not Wayland.

Wayland is x12

[oldtimefighter]

Yes, until the major distros choose not to package it for X11, like how their agreement on "init system choice" turned out to mean "you won't hardly be able to boot up a modern GNU/Linux distro without devoting at least 1-2GB of ram to systemd and its many tentacles" and "oh by the way, we're making systemd a hard dependency for some of the packages you've been using". These "freedom of choice" decisions that exclude the choices people have already been making for decades always turn out so beneficially for all.

This is seriously an argument? Someday distros will drop X11? Yeah some day... X11 has no future as development as been almost non-existent for years now because their own developers abandoned it. Maybe take a hint? LOL No shocker the systemd complainers of the past have become the X11 complainers of today. Funny how history repeats itself.

Regardless, distros that don't use systemd still exist just like X11will be available a decade from now for people with 20 year old systems. Isn't open source wonderful?

[vtorri]

Why is that? lol

https://www.x.org/wiki/Development/X12/

[Myownfriend]

https://www.x.org/wiki/Development/X12/

I'm aware but it never got passed this point. It's just (one person?) dropping some ideas back in 2013.

Also...

Security designed-in from the start

Systems need to be secure. X12 needs to be designed with security in mind.

Multiple Platform Support

X12 should be designed with mobile phones, tablets, dumb terminals, netbooks and desktop workstations in mind; if it is to succeed, it must work well on all these systems.

Errors, Oversights and Omissions

Rendering model

Composited by default

Probably. Note that we can more or less accomplish this within X11, but there are probably simplifications to be had by making this explicit in the protocol.

Grabs can block too much

Popping up a menu and walking away can leave your screenlock unable to lock the screen since it won't be able to grab the pointer.

Server grabs are even worse when they lock out all other clients including those necessary for user interaction like compositing managers and accessibility helpers.

Borders are stupid

Which is really a special case of...

Implicit rendering is stupid

Borders and window backgrounds and the bg=None trick and backing store and saveunders and all that.

There's a speed/complexity tradeoff here, of course. Any time that implicit server rendering works, it saves you exposures and round trips. But the implicit mechanisms we have are poor fits for a composited model. Think very carefully about adding implicit rendering to the server process; it's probably a mistake.

...and probably more are changes that Wayland made. In fact, "Composited by default" is one of the things that people who hate Wayland have an issue with.

It also references Window System Design: If I had it to do over again in 2002.

In that document it's states that the Principles For A New Design are:

1) Acceleration is normal, not rare.
2) Shared libraries are everywhere.
3) The code path from the application to the accelerator needs
to be as short as possible.

Under "The Design" it says

Given these, the basic outline of the design falls out fairly
naturally. I would make the “window system” so minimal that it is
almost non-existent. Each graphical application gets direct access
to the hardware, and a window is nothing more than a clipping list
and an (x,y) translation. I would build a “device driver” that did
nothing more than manage the clipping lists and hand out graphic
device ports. This might actually be best done at user level, rather
than a device driver, using shared memory and semaphores

Wayland's minimalism is one of the things that X11 loyalists always seem to hate about Wayland. Yet the article for X12 references an article from 2002 arguing for the X11 successor's minimal. So this is yet another way that X12 would be like Wayland.

Let's continue...

Almost everything else would be done at user level, in the user
process: rendering, window borders, and the hard parts of
cut/paste/drag/drop.

I've heard X11 loyalists complain that Wayland runs at the user level.

Window borders - Do them in the application library!

The application library should handle borders? I thought that was Wayland/Gnome bullshit.

Now about X11 compatibility...

. One could just port an X11
server to this environment, much as it has been ported to OSX.
This would be pretty heavyweight, although quick and easy to put
together.

What? I thought a proper X11 successor would be completely backwards compatible with it. That's what X11 loyalists have told me. Why does this sound like XWayland?

How does that article end?

Would be a system that is both lightweight and fast. Everything
could move at the speed of a finely tuned video game. Advances
in rendering pipelines and library design would be easy to
accommodate. This window system design isn’t particularly
radical: it’s more just pointing out that this is the way that X is
going already, given the increasing predominance of application-
side rendering libraries. Once you accept that fact and admit that
it’s actually the right way to go, the design falls out, simply by
stripping away legacy stuff that isn’t needed any more

Stripping away legacy stuff? A minimal protocol isn't radical? An article from 2002 could kill an X11 loyalist of 2023... you know, the people who hate Wayland with a passion but don't really know much about it or X11.

[oiaohm]

Yes, until the major distros choose not to package it for X11, like how their agreement on "init system choice" turned out to mean "you won't hardly be able to boot up a modern GNU/Linux distro without devoting at least 1-2GB of ram to systemd and its many tentacles" and "oh by the way, we're making systemd a hard dependency for some of the packages you've been using". These "freedom of choice" decisions that exclude the choices people have already been making for decades always turn out so beneficially for all.

That a bold face lie on the 1-2GB of ram to systemd and it tentalces.

https://www.reddit.com/r/linux4noobs/comments/wrekmg/can_a_different_init_system_improve_ram_usage_and/

Non optimised for memory systemd compared to sysvinit/runit/openrc... at worst is 300MB difference that is basically manually starting everything vs systemd starting it. Systemd and it tentacles does not use 1-2GB of memory.

Systemd setting up all the cgroups and other things does cost boot time. Systemd is a problem for sub 1G systems.

andyprough one of the big catches here some of the old distribution implementations of sysvinit used to eat up 500 to 600 megs of memory. Yes some distributions changing from there custom crud sysvinit implementation to systemd in fact reduced their memory footprint. System init choice from before systemd was not ideal either. Lot of badly reinventing the wheel was going on.

Also you have the case that commercial applications on Linux had hard dependacy on sysvinit or upstart ... what ever redhat distribution was shipping.

Something to be very aware of:

https://www.sysgo.com/press-releases/focus-on-boot-optimization-and-sustainable-cybersecurity

Specialist embedded Linux distributions. Why are these important they package systemd up differently to how our common distributions do they package systemd up way more modular and have other tools to detect when you are running parts of systemd you are never using that are optional and can be turned off to improve boot and memory usage.

Yes those parties put busybox head to head with systemd and they have found that once you get to using cgroups around services memory cost goes up resulting in no more memory advance. .Problem here there is a min cost to correctly working service supervision using the Linux kernel.

Think about when systemd provides a kit of all the parts you need for the core certified to work with each other without major issues it makes sense for lots of distributions to use them particularly when at best doing their own they they can save 200-300 MB at cost of having to deal with broken service management and software incompatibility issues at worst have a solution using 3 times as much memory as systemd and have broken service management and software incompatibility. Basically you had it backwards 1-2GB of extra memory is what you risk on some of the distributions that don't use systemd.

Freedom of choice does have a labor cost. andyprough spend some time trying to find a non systemd service management system on Linux that does in fact work correctly with Linux kernel know issues.
1) Linux kernel recycles PID numbers. This is what goes wrong with sysvinit and many different alternative service management solutions where you will have sysvinit script saying a service is still running when it crashed out days ago just something else is now running at that PID number.
2) Linux kernel does not maintain stable PID tree this comes problem for killing services. This why systemd starts each service in it own cgroup so that when you kill a service all parts started by a service also get killed. Items like freebsd don't need todo this because they have a stable PID tree.
3) Linux resource controls are cgroups/name spaces.

Yes point 2 is where Linus going by the old Unix books went a different path. Linux is only Unix like some places it has it own quirks. This is why lot of alternative init systems on Linux they go lets follow the rules of Unix/Posix and attempt to have this alternative work on linux and now things don't work.

[JEBjames]

Michael

Another typo

"allowing Wayland-only -r X11-only" should be "allowing Wayland-only or X11-only"

[Myownfriend]

Is andyprough not being sarcastic?

[justinkb]

How's limiting freedom become "interesting"? A pure Wayland Firefox build is not any "faster" or "better" than the one which supports X11 as well. Oh, it will save you a hundred of kilobytes of code. At the same time:

$ du -hs /opt/firefox
224M /opt/firefox

That's the official Firefox 116 x86-64 Linux build. Yeah, that's really something ... I mean absolutely nothing to talk about.

That's not what software freedom is. Your comment is so dumb.

[aviallon]

i would prefer to use FF flatpak, but i have a problem with fonts on some (few) sites, for example facebook, in these rare sites the fonts really suck, they are fine and grainy...on all other sites they are normal, however this is really annoying.
For completeness ... firefox flatpak, installed in Tumbleweed - KDE Plasma wayland session.
Has anyone had the same problem and found a solution?

Yes, it is a known issue sadly. This can be worked around by giving read-only access to your system fonts:

flatpak override - -user --filesystem=/usr/share/fonts:ro

[mdedetrich]

That's an option to create a non-portable Firefox build. How's that "freedom"? What if the user suddenly has an urge to run Xorg? Get wrecked? No Firefox for you? One of the reasons commerical OSes are successful is because they do everything possible to preserve backward compatibility. Linux users on the other hand are obsessed with breaking what used to work in the past. Look where it's got Linux on the desktop so far. Pretty fucking nowhere. Let's celebrate that!

Im sorry this is sensationalist whining. Your distro's package manager will handle this automatically (assuming you are using a non s**t distro). More specifically if you happen to be using X11 it will resolve Firefox's X11 built package and if you are using Wayland then it will resolve Firefox's X11 wayland package.

There are plenty of other examples with such splits (i.e. x86 vs x86_64 binary builds) and everything was handled just fine, and this specific example is way worse than an X11/Wayland split.