same here (Poland)

No, because root has already an established, clear meaning in Unix world.

I wanted ‘trunk’, like SVN. That ought to be safe, since there's no one speaking for the trees.

I look forward to the tech sector getting into fights with The Lorax, or more seriously, the Sierra Club.

The Lorax would like a word with you.

It's not an indirect reference. Word "master" in BitKeeper was used for context where word "origin" is used in Git.

It is an issue if I need to rewrite my scripts specifically for macOS and they are no longer cross-platform.

Yeah, you can alias all utilities called g<something> to <something>, but you can't reasonably expect all users of your scripts to do so as well.

Using macOS is PITA.

If you're using GNU extensions, then you are not writing cross-platform scripts in the first place.

AFAIK Gnome and KDE already have EGLStreams support in place, but it does not work for XWayland because incompatibilities in NVIDIA-maintained libraries.

From a fellow maintainer of open source software (currently not being paid for the work at all) - I agree 100%.

Users are always demanding things: new features (which sometimes are very bad ideas), merging patches (which sometimes were never tested), expecting answers for questions that were asked and answered thousands of times before…

> It's just that if you don't like something, you need to step up and do something about it to improve the situation, instead of just complaining.

Exactly. Users who want to say on X (for whatever reason) should start contributing instead of spending time blaming the devs. If they want to switch to Wayland, but are missing something - they should work towards fixing it instead of dragging everyone else back.

But then the only users who get the features they want are programmers, who are a fairly atypical type of user. I understand that you don't owe users anything, but if you don't want to create software that's useful and pleasing to them, why bother creating open source software at all. You could get the same enjoyment from coding for profit or doing logic puzzles.

Hire, we have money for that specific reason.

> why bother creating open source software at all.

I create features for myself, I share it for free, that's gift, not pleasing.

> expecting answers for questions that were asked and answered thousands of times before

I don't mean to seem ungrateful for the work that open source maintainers do every day, but I think this sort of complaint is usually a symptom of a problem with either the documentation or the interface being unclear. These pain points are usually an opportunity for improvement in the product. On the other hand, there are probably more such opportunities than there are available maintainers...

A quick summary of new features:

  - Upgrade to SDL 2.0
  - Support FLAC, Opus, Vorbis, and MP3 CD-DA tracks
  - Pixel-perfect scaling mode
  - AUTOTYPE command
  - Changed rendering defaults
  - Expand mouse control methods
  - Nuked OPL v1.8
  - Resizable window
  - Reload key bindings in runtime
  - Improved configuration file handling (Linux, macOS)
  - Modem phonebook
  - 64-bit dynarec
  - CGA emulation improvements
  - GLSL shader support
  - DATE and TIME commands
  - Mount overlay support

Features:

  - Lower input lag (compared to DOSBox inside Proton)
  - Steam features working as expected (e.g. Steam Cloud,
    Controller settings or recording of time played)
  - Better fullscreen support, especially on multi-monitor setups*
  - Steam Overlay working out of the box*
  - More configuration options and better defaults*
  - Automatic detection of MIDI hardware, with software
    synthesiser used as fallback
  - Automatic MIDI setup for supported titles
    (click Play and enjoy pre-configured MIDI music)

* - compared to vanilla DOSBox

This project is developed in parallel to https://github.com/dreamer/luxtorpeda - Steam Play compatibility tool for running games using native Linux open-source engines.

For me, it works perfectly on both FF and Chrome (Linux), but I wonder how WebRender will deal with it; can you test Firefox Nightly with "gfx.webrender.all" set to true?

Thanks! gfx.webrender.enabled (not .all) alone does indeed solve the performance issues, however only in Nightly (v62), not in the Beta (v61) channel.

Work on WebRender started before Vulkan API was widely available (even now there are lots of users, that can't use it) and right now they focus on integrating it in Firefox. Vulkan support is kept to be implemented "later", as it should enable further opportunities for parallelization in future.