621–630 of 714 posts
Earlier quoted context omitted.
> Lots of Linux distributions is its strength. Unless you want to ship something, troubleshoot something, or figure out how something works without hours of googling.
Would you better not able to solve at all? Ship and troubleshoot solved by distro maintaires. Niche products solved by Flatpak and its runtimes.
Earlier quoted context omitted.
> The [compositor] I use is fast. [...] I've been happy with a wlroots based one (Wayfire) for a few months wlroots performed very poorly on my i5-3427U with 4000 series iGPU. Very poorly. I ended up using neither X nor Wayland and instead having mpv render straight to the frame buffer (--vo=gpu --gpu-context=drm)
I'm a wlroots developer, and I'm using an old Sandybridge mobile i5 CPU daily. So I'm pretty surprised about this. I'd be interested in a bug report if you were to try again.
X.org, Firefox, and Xterm all work very well on it though. As do other apps like gschem and openscad.
Earlier quoted context omitted.
Would you better not able to solve at all? Ship and troubleshoot solved by distro maintaires. Niche products solved by Flatpak and its runtimes.
I'll stick with platforms that don't require third party volunteer maintainers just to be able to run software, thanks.
What I find strange is sitting on the place one does not like. There are so many choices around.
Earlier quoted context omitted.
Let me fill in with my perspective as a Mac user: I expect the vendor (i.e Apple) to supply a decent desktop environment. The did a quite good job at it. I didn’t need to pay extra, it was included in the sale of the computer.
But X.org isn’t a hardware vendor. It’s not owned by any hardware vendor. It’s not even owned by an OS vendor, or by an OS at all. Apple is a multi-trillion dollar company. Microsoft and Google are close behind. Of course they can give away their desktop environment away for free. System76 (et al) can’t compete with that. X.org can’t compete with that. I mean, this is exactly the reason I use Mac, because it ships wi…
Earlier quoted context omitted.
> 1) Wayland is really slow. I don't know if it's the compositing or what but it's unusable on lighter hardware that X ran fine on. Presumably your compositor is using llvmpipe software rendering if it's so slow. Unaccelerated Xorg using something like the vesa driver is slow too.
I own machines that have no hardware acceleration (I had to remove the kernel modules and use the efi framebuffer because the drivers would crash.) Xorg is absolutely usable on such machines with compositing disabled, wayland is not.
For this comparison to make any sense at all you need to state which Wayland compositor, Wayland is a protocol.
Earlier quoted context omitted.
You left out GGI/KGI. But most of this stuff is basically irrelevant in a post-KMS/DRM linux world. So few apps were ever written targeting directfb and libggi it's as if they never existed. SVGAlib apps frequently performed direct hardware access requiring root and disrupting graphics hardware state WRT other graphical apps like X or fb. Unfortunately we have a significant collection of old demos and games targeting…
I think directdb stuff is KMS/DRM compatible. Mplayer on the fbdev2 driver works perfectly. So is DirectFB Links. >Unfortunately we have a significant collection of old demos and games targeting SVGAlib, but at this point it's probably best to just run them in a virtualized linux environment lacking any graphics drivers so SVGAlib can run the show on a faked VGA. Or a wrapper trapping SVGAlib calls to SDL/SDL2.
That works for programs limiting their operations to SVGAlib calls.
As I mentioned, but you omitted in the citation:
> SVGAlib apps frequently performed direct hardware access requiring root ...
How do you trap those directly accessing VGA IO ports via inb/outb instructions? I clearly recall writing modex routines in assembly for SVGAlib demos, and I'm pretty sure I wasn't the only ex-DOS graphics coder doing that to make things happen on Linux in the 90s.
Earlier quoted context omitted.
It took python community 10 years to migrate to python 3, and the migration process from python 2 to python 3, while tedious, is certainly a lot easier than porting a gui app from xorg to wayland. It could take some time until most app developers finally migrated their apps from xorg to wayland.
Python 3 changed nothing * print is function * string is unicode by default Should have been clean and easy migration path # python 2 from __future__ import print_function print(u"foo") u"" # was u"" b"" # was "" But u"" was not supported in Python 3 until PEP 414 (python 3.3) [1]. That's four years [2]: Python 3.0.0 Dec. 3, 2008 Python 3.3.0 Sept. 29, 2012 Ruby string switched from codebytes to codepoints with encod…
The situation with wayland migration seem to be somewhat similar with the python 3 migration. Many gui apps that uses gui toolkit probably don't need major modification, or no modification at all. But some apps that requires platform-specific access are heavily affected and might require some major refactor, and they probably won't do it until the benefit of migrating to wayland outweigh staying on xorg.
Also, unlike python 3 migration where most of the community agree that the move is justifiable will have to happen eventually, in the case of wayland migration, the community opinion seem to be split which certainly harm wayland migration progress.
Earlier quoted context omitted.
Detaching flamewars so that they languish at the bottom of the page is standard HN moderation and the reason we do it should be obvious. If you don't want that to happen, nothing is easier to avoid (from a moderation point of view): simply provide corrective information respectfully. Of course that is not so easy from a personal frustration point of view—that is something every HN user (certainly including me) has to…
The commons are full of propeganda and misinformation at the hands of your policies to "protect" them. Your guidelines are not holy writ, and are unfit for this task.
* If phoronix made test maybe we need to make another one.
* If people say it is hard to make application we can show that GTK+ works on both X.Org and Wayland.
* If they say it is impossible to make screenshot show grim.
* If they say X11 networking show bitmaps traveling by network.
* If they say no Wayland improvements show video of tearing.
My arguments buried here too.
Earlier quoted context omitted.
I believe you assert that Wayland failure is that is not ready for end user. Strange point, it should have been burned 10 years ago than. I use X.Org, works perfectly in Arch Linux, some claim problems on in their distribution. It should be critique of that distribution. > Chromium is making its first shy bumbling steps towards actually working on Wayland And Firefox support is behind MOZ_ENABLE_WAYLAND=1 flag. Clear…
this is all going to end in X12.
Earlier quoted context omitted.
Saying Wayland is just non-functional for reasonable use-cases without significant user workarounds (usually going back a decade in execution and clarity) isn't toxic culture, it's the truth. Yes, people can work on what they want. By the same logic, anyone can say that the direction they're taking is bad.
I strongly disagree. Since switching to Fedora almost 4 years ago, I've only booted to X.org once, three years ago. I haven't needed it since. I do browser-based screensharing (of both individual windows and the whole screen), I have a mixed DPI monitor setup, I've played games on Steam, &c. I need no workarounds. GNOME just works. About the only things I don't use are nvidia's crappy drivers.
Hope it works out for you.