2021-09-06 11:35 from Nurb432
Well this is neat. x86 emulation for ARM64.  It only will run linux
binaries so its not a 'true' emulator, and uses native ARM
interfaces/libraries to improve speed. ( so i guess sort of like wine
is for windows binaries ) Not sure why i never noticed this before. 
Could be beneficial to a lot of people. 

 

https://github.com/ptitSeb/box64

It looks useful for running printers with propietary plugins that are only released for x86 :)

So, here I am on my main desktop running the Wayland display server. I suppose it's a good thing that the experience is indistinguishable from X. Everything "just works" -- but I suppose a lot of that has to do with the fact that a rootless Xwayland server is running, so anything that needs X will go through that.

I have been playing around to see what works without X, by doing "unset DISPLAY" and then running various programs from the command line. Most of the system apps seem to be fine. My browser is Brave, which is a Chromium derivative; it wants to run in X by default, but I found that if you do "[browser_name] --enable-features=UseOzonePlatform --ozone-platform=wayland" it will use Wayland instead. According to [ https://tinyurl.com/yhznexse ] the new renderers will be enabled by default in Chromium-derived browsers in the next version, so it'll probably do that by default.

All in all, I think they managed the transition pretty smoothly. Most users are just going to be upgraded to Wayland in some upgrade in the near future and they won't even know the difference.

All in all, I think they managed the transition pretty smoothly. Most

users are just going to be upgraded to Wayland in some upgrade in the

near future and they won't even know the difference.

There's still a bit of annoying flicker in certain Java apps that use tooltip-like windows over Xwayland. So the X compatibility is not perfect, yet. Almost but not quite.

Java is not going to be a native Wayland stack any time soon.

Here's a link into the middle of a thread on a possible Java/Wayland port:

https://mail.openjdk.java.net/pipermail/discuss/2021-July/005855.html

They're still at the phase of figuring out which toolkits to use:

"And I think the first phase of the project needs to be an investigation

of the alternatives
and consideration of how well it matches all the requirements.
I would not want to see a "code first, figure it out later" approach.

This is going to be discussed in committee for a year before the project even starts ;)

Heh. It looks like there are some people who are part of a "just use GTK and let them deal with it" camp. That would work, but it would be nice to go native if they can. Then again, people sure do like their shortcuts. I'm still puzzled over the decision made by the WSL people to do Wayland using memory-mapped RDP instead of just making the compositor draw directly on the desktop.

2021-09-16 22:32 from IGnatius T Foobar
Heh. It looks like there are some people who are part of a "just use

GTK and let them deal with it" camp. That would work, but it would be

nice to go native if they can. Then again, people sure do like their

If you read the whole thread there are some comments about how wayland natively does much less than X did. So implementing "native wayland" doesn't implement all the extra protocols that you need to talk to your desktop environment do window resizing or drag/drop or whatever. That's all GTK.

I'm not enough of an internal expert to know one way or the other, but I can see how if Java were to go with GTK, they might need to submit a fair number of patches to GTK to expose all the lower-level stuff they need.

Right. And as I recall, part of the thinking behind Wayland was that they did *not* want to put a high-level graphics toolkit into it, because it would become obsolete like the graphics primitives in X11 did, but they'd be obligated to carry it around as technical debt forevermore. GTK and Qt don't use those graphics primitives; they instead draw on the canvas using libraries such as Cairo and Pango which can be upgraded at will.

And that might end up being the middle ground. GTK renders to Wayland by telling Cairo and Pango to draw on EGL surfaces, so perhaps Java could do the same thing.

Or I could be completely wrong -- it's been a long time since I've written a GUI program in Java.

I admit I'm not a fan of YAML, but I just became a fan of netplan, which uses YAML as its configuration syntax.

Not because of the syntax, but because the command "netplan try" is freaking awesome. It's what network gurus will recognize as "commit confirmed". It applies your new configuration, and then you have 120 seconds to commit the new configuration permanently, otherwise it assumes you locked yourself out and reverts back to the previous configuration.

This is a life saver when you're working inband. I'm in the process of moving my Raspberry Pi to a different VLAN on my network, and it's headless so I don't have a screen and keyboard on it. The first time I attempted it, I was on Raspberry Pi OS, in which you set a static IP address by entering it into the DHCP configuration (boneheaded!). Needless to say, I messed it up, locked myself out, and then broke the SD card while attempting to remove it. This time, I installed Ubuntu Server (64-bit!) and I was able to use "netplan try" to safely move from DHCP to static, and then from untagged to a VLAN. Nice!

Ok, so it looks like Mikrotik RouterOS doesn't seem to handle BGP on VLAN interfaces, either that or I'm doing it wrong, so I put the Pi back on the main network. Oh well.

The reason I've always been hesitant to deploy PiHole is that if the PiHole server stops working, your entire network stops working. But I've created a clever way around that.

My DHCP hands out 1.1.1.1 as the DNS server, of course, because it's far more trustworthy than the creeps who run 8.8.8.8. I now have a full DNS server running on the Pi, with root hints and everything so I don't have to forward to anyone. The Pi also has a secondary address of 1.1.1.1.

I installed ExaBGP on the Pi, and gave it a script to test the host for a working DNS server. If DNS is working, it announces 1.1.1.1 via BGP into the main router, effectively hijacking 1.1.1.1 and attracting all DNS requests to the Pi instead of going out to the real 1.1.1.1. If BIND dies, or if ExaBGP dies, or if the
Pi itself dies, the BGP announcement is withdrawn and DNS requests are sent to the "real" 1.1.1.1.

The next step will be to actually install PiHole on this server, of course.
I'm sick of seeing ads on YouTube when we watch on the big screen. If I have to see that stupid kid vaping scraps of metal one more time I'm going to drive to Mountain View and start yanking hard drives out of their servers until it stops.

Incidentally, ExaBGP is awesome for this sort of thing. This past summer I built a fairly large scale environment that needed its own resolvers, and I announced 10.10.10.10 as an anycast address from multiple regional servers using this method. You used to need a load balancer for that.
s

Yes, most ad blockers will take care of YouTube at the desktop, and on Android there's "YouTube Vanced" which is a hacked client that skips the ads (and allows you to turn off the screen to listen to audio only).

In our home we watch YouTube for an hour or two after dinner, just about every night. Trains, airplanes, instructional videos, cooking shows, a dude in Australia unclogging drains, whatever's available. It usually takes the form of my son and I joining the queue on the main TV in the living room, but sometimes the ladies will throw some vids in as well. The problem is, there is no adblocker for the TV. So we see the ads. They're up to THREE pre-roll ads at this point, plus interstitials in the longer videos.

By installing PiHole on the network, I will be able to block ads on every device in the house, with no software on the client.

The reason I've always been hesitant to deploy PiHole is that if the

PiHole server stops working, your entire network stops working. But

I've created a clever way around that.

I think I would have just set a second DNS server up and used a protocol like CARP to get some failover for DNS. BGP is nice but it sounds a bit overkill :)

2021-10-04 09:27 from IGnatius T Foobar
Yes, most ad blockers will take care of YouTube at the desktop, and on

Android there's "YouTube Vanced" which is a hacked client that skips
the ads (and allows you to turn off the screen to listen to audio
only).

I solved the problem of Youtube ads by not watching Youtube. If somebody sends me a link to a video I absolutely should see I may use youtube-dl and that's it.

BGP is nice but it
sounds a bit overkill :)

Apparently, facebook agrees with you BWAHAHAHAHAHAHAHA

BGP is second-nature to me because I'm a data center architect and I use it all the time. I actually *don't* have a big network at home, and I wanted to be careful to make sure that if the Pi goes off the air, everything just reverts to being "a regular home network".