vially

The number does not have to be zero for this to still have a net positive effect on society.

It was recently discussed in https://news.ycombinator.com/item?id=47855565

I prefer to avoid AppImages if I can but I gave it a try anyway and it still fails with exactly the same error. What made you think it's just a packaging issue?

Thought I'd give it a try and installed the latest version. Application crashes at startup on Linux (Wayland) with: "The window terminated unexpectedly (reason: 'crashed', code: '139')". Probably yet another instance of developers mostly testing and doing quality assurance on macOS/Windows.

> a privacy conscious company such as Apple

[citation needed]

For anyone considering buying the Pixel Watch 3, please keep in mind that Pixel Watch 2 has some long-standing issues where the GPS completely cuts out during runs or walks.

Some users believe it to be a hardware issue but it's still unacknowledged by Google and the forum thread where people have been discussing it has just been locked recently. Just mentioning it for awareness and visibility.

- https://community.fitbit.com/t5/Android-App/Google-Pixel-Wat...

- https://support.google.com/googlepixelwatch/thread/242833127...

I haven't personally used it, but I have seen cage [0] being recommended a few times for similar use-cases.

[0] - https://github.com/cage-kiosk/cage

I was also looking for a successor to the PC Engines APUs and came across https://teklager.se/en/ that lists some possible alternatives that you might find interesting.

Personally I was looking to build a router so I ended up buying a fanless N100 based mini PC from Aliexpress (e.g.: search term is "N100 firewall appliance") and have been very satisfied with it so far (Proxmox homelab with OPNsense running as a VM).

I've been using VSCode with devcontainers and podman for a couple of months now and everything seems to work fine for me. Is there a particular issue you're hitting?

I've toyed around with Smithay Client Toolkit [1] for Rust and I think it offers just the right abstraction for writing simple Wayland clients.

[1] - https://github.com/Smithay/client-toolkit

sway does all those things very well: https://swaywm.org/

Do you mean third-party apps on iOS? All web-based iOS apps are powered by Webkit/Safari so it makes sense that they all share the same bugs.

For what it's worth, most (all?) the comparisons in that phoronix article [1] compare the performance of apps running under XWayland (in a Wayland session) versus an Xorg session. That's because most steam games use SDL 2 which still uses XWayland by default (the default has been changed in SDL 3 though [2]).

So using the data from that article to conclude that "[Xorg] still generally outperforms Wayland" seems wrong. A comparison between native Wayland apps vs Xorg apps would have been a lot more relevant though.

[1] - https://www.phoronix.com/review/nvidia-510-wayland [2] - https://github.com/libsdl-org/SDL/pull/6362

I feel like I'm having a deja-vu. I remember having a similar discussion in the past and it turns out it happened exactly one year ago when Flutter 2 was released: https://news.ycombinator.com/context?id=26336657

Every framework has bugs and feature requests that are fighting for resources. And the ones affecting you _always_ seem more important than the ones that don't.

That being said, the fact that memory leaks in widely used components (e.g.: `<ion-img>` [1]) go mostly unnoticed both by Ionic developers and by the community [2] just doesn't give me confidence in Ionic being a framework used to build quality apps.

  [1] - https://github.com/ionic-team/ionic-framework/issues/19242#issuecomment-556182556
  [2] - the issue linked above has 5 upvotes in 3 years and no one even bothered to report a separate issue for the memory leak in `<ion-img />`, which seems even more serious and the developers have been made aware of it

For what it's worth I'm an Ionic developer and I find the grand-parent's description pretty accurate. I do like Capacitor though, but I think that's mostly because I've had to deal with Cordova before.

According to the official documentation [1], the 13" M1 MacBook Pro also has this limitation:

  > If you're using a Mac with the M1 chip:
  > 
  > On iMac, Mac mini, MacBook Air, and 13-inch MacBook Pro, you can connect one external display using either of the Thunderbolt / USB 4 ports.

[1] - https://support.apple.com/en-afri/HT202351

Not op, but for me the lack of native Wayland support is a deal breaker. And running it through XWayland has various issues (focus is broken, issues with HighDPI screens, etc).

If Fleet supports Wayland natively I might give it a try, otherwise it's dead on arrival for me.

> Good luck getting multiple different sized monitors to work well out of the box (e.g. laptop + external) on Linux, sometimes even with tinkering you are left with subpar scaling on one

It sounds like you might still be using Xorg?

These are all solved problems in Wayland (that is, as long as the applications are native Wayland clients, and not running through XWayland) but some people are still reluctant or unable (see NVidia EGLStream debacle) to migrate yet.

> If I try to connect headphones they'll invariably stop working before long.

Are you using PulseAudio or PipeWire? I've recently switched to PipeWire and all my bluetooth related issues went away. The progress that PipeWire has made over the last few months is amazing. At least in my case, it went from almost unusable to my daily driver in the span of two or three releases.

I'm going to buy this just to support Valve for their continued support in making Linux desktop a viable gaming platform. Their reasons may not be entirely altruistic, but there's no doubt that they had a tremendous impact on the Linux gaming ecosystem.

And it's not just the Linux gamers that are benefiting from their work. They also seem to be doing good work on lower-level parts of the stack (e.g.: graphic drivers, Flatpak, etc) that are improving the Linux desktop in general.

> Systemd docker-replacement on a non-systemd Linux would need to run in a VM, though.

Would it? There's no reason this hypothetical systemd-docker-replacement couldn't be architected in a way that would not have a runtime dependency on systemd-the-init-system.

In any case, I'm not even sure if systemd wants to be a docker replacement (although it does seem to pick up more and more container features lately). But there's definitely some overlap between the two projects (in particular around process/service management) but podman is a much more direct competitor to docker than systemd.

> A systemd solution would need a VM running Linux w/ systemd even on Linux, in some cases.

But that's exactly what happens with docker anyway (e.g.: Docker is still running in the Linux VM when running it from a different operating system). And considering the widespread systemd adoption throughout the Linux ecosystem, it's far more likely for systemd to be already installed in the VM than docker anyway.

I built a website for making it easier to read Wayland protocols documentation (which are originally published as XML): https://wayland.app/protocols/

> GNOME is an open source project, asking them to reconsider a position doesn't make sense -- the default response to every feature request is "no" unless someone volunteers to implement it

I don't think GNOME would accept a pull-request adding SSD regardless of where it came from (I'd love to be proven wrong though). In fact, someone asked this exact question [0] and it got no reply. But after reading the whole thread a while ago my takeaway was that such a pull-request would not be accepted.

> [...] it will work on any window manager that doesn't provide decorations, not just GNOME.

GNOME is the only real desktop compositor that doesn't support SSD. The main reason no one is complaining about Weston not supporting server-side decorations is because there aren't many (any?) people running Weston on the desktop. Also, there's no technical reason why SSD couldn't be added to Weston too.

Again, as I've mentioned before I think both SSD and CSD have their use-cases. GNOME thinks otherwise and that's okay. But it doesn't seem to be (only) due to lack of resources.

[0] - https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3569...

My impression is that there will always be apps that don't care enough about decorations and would just prefer to use the operating system defaults and SSD provided a reasonable way to do that. But then there are also applications that do care enough about it, in which case CSD is way to go.

Usually implementing CSD properly for each platform requires a bit more work than just relying on the toolkit's default or on SSD. This shouldn't be a problem for applications that have the resources to do this properly, as in your examples. But I'm a bit afraid that, given Linux desktop's market share, smaller app developers might not have the resources to do this right and then Linux will start inheriting the look and feel from Windows and macOS. Maybe this won't be a problem in practice, but if this starts happening, then the experience for Linux desktop users will be worse than just using SSD.

In any case, we'll have to wait and see how it all plays out. I think both SSD and CSD have their use-cases and I still wish GNOME's would reconsider their position on this.

I've been using it for a couple of months now (by patching the applications which haven't upgraded to Electron 12 yet) and it's been working great for me.

Is there anything in particular that is broken and/or missing from Electron's Wayland implementation? Or are you referring to GNOME's refusal to implement server-side decorations [1][2] as a limitation of Electron?

[1] - https://gitlab.gnome.org/GNOME/mutter/-/issues/217 [2] - https://github.com/electron/electron/issues/27522

I can definitely see the point in choosing XML for the Wayland protocols for the reasons you've mentioned (e.g.: strictly typed information) because one of their purposes is to be able to easily generate bindings and libraries from them.

However, that still doesn't make them a good format for human consumption as in reading them as a reference. That was the main motivation for creating this website.

I've been trying to learn more about Wayland recently but most of the protocol documentation is found in XML files which makes for a poor reading experience.

Therefore I created a website which extracts the data from these protocols and publishes it in a format that's (arguably) better suited for reading.

https://wayland.app/protocols/

Source code on GitHub: https://github.com/vially/wayland-explorer

> Do any desktop system handle mixed DPI well?

This works today out-of-the-box in Wayland as long as the applications are Wayland native (e.g.: not being run through XWayland).

> and I haven’t heard anyone singing it’s praises yet about how happy they are to use it

As is often the case, people are much quicker to go to forums to complain about issues than to sing praises so I'm here to add a data-point trying to balance the scale.

I've been using Wayland for a few years now and it does everything I need it to do. I understand that everyone has different needs and maybe it doesn't work for everyone, but then again, neither did X11.

Some of the things that work out of the box in Wayland which didn't work in X11:

- proper HiDPI and mixed DPI support (e.g.: you can finally move windows from one screen to another in mixed DPI setups and everything scales properly)

- variable refresh rates/FreeSync (for all apps and all screens)

- no more tearing

- no more hot-plugging issues