Rename blog

This commit is contained in:
Anthony Wang 2021-02-16 18:59:01 -06:00
parent d44c30458b
commit 5d24faf447
Signed by: a
GPG key ID: 6FD3502572299774
12 changed files with 34 additions and 34 deletions

View file

@ -1,3 +1,3 @@
# [Blog](https://ta180m.github.io/Blog/)
# [Blog](https://ta180m.github.io/blog/)
Some random blog.

View file

@ -8,7 +8,7 @@ tags: ["Random", "Linux"]
## Play videos in your terminal!
![On YouTube](/Blog/assets/tux-video.png){: height="300px" } ![In a terminal](/Blog/assets/tux-text.png){: height="300px" }
![On YouTube](/blog/assets/tux-video.png){: height="300px" } ![In a terminal](/blog/assets/tux-text.png){: height="300px" }
Assuming you have mpv, just run `CACA_DRIVER=ncurses mpv -vo=caca *path_to_video*`.

View file

@ -11,21 +11,21 @@ For many people, "virtual machine" is effectively synonymous with VirtualBox or
Let's try Debian first:
![Debian](/Blog/assets/debian.png)
![Debian](/blog/assets/debian.png)
Not bad! It seems much faster than VirtualBox or VMWare, or maybe that's just because of i3... The CPU is definitely running at almost-native speeds, the disk speed -- not so much, as expected. It's also detecting a paravirtualized graphics card, so the graphics aren't too bad, but there's no OpenGL unfortunately. Anyways, QEMU/KVM is going pretty strong so far.
Let's give Android-x86 a try:
![Android-x86](/Blog/assets/android-x86.png)
![Android-x86](/blog/assets/android-x86.png)
Pretty good! I don't think Android is detecting the paravirtualized graphics card, so that might explain the sluggish graphics performance. I can even connect to it using KDE Connect! It's using a lot of RAM, but my computer's fans aren't spinning like crazy like when I run a VM using VirtualBox.
Now time for some [OSX-KVM](https://github.com/kholia/OSX-KVM):
![Big Sur](/Blog/assets/big-sur.png)
![Big Sur](/blog/assets/big-sur.png)
Surprisingly, even Big Sur runs fantastically. OK, maybe not fantastically, since there's no graphics card, so the graphics are very sluggish this time, but other than that, it's much better than something I could hack together with VMWare or VirtualBox. QEMU might even become the optimal way for Hackintoshes, since Apple Silicon has spelled the end of running macOS on other processors. Big Sur also uses quite a lot of RAM, but I think using i3 on my host laptop helps. And it just happens to be the same resolution as my laptop screen, so when I go fullscreen... complete immersion! Just like a real Mac with a nonexistent graphics card, I guess?

View file

@ -13,9 +13,9 @@ Linux is pretty tricky. Here are a few actually useful tricks.
## GDB GUI, or should I say TUI
I've got some mixed feelings about VSCodium, the text editor that I use. It's not bad, but as an Electron app, it predictably has terrible performance issues. For instance, compiling a tiny C++ file can take 10 times as long in VSCodium versus compiling it in the terminal. However, one thing that it does great, with the help of the phenomenal extension [Native Debug](https://github.com/WebFreak001/code-debug), is the excellent (although slow) integrated graphical debugging experience, using `gdb` as the backend. People often decry GUIs for being bloated and not much more useful than the command line, but in this case, the graphical debugger helps me keep track of where I'm at in my code. ([Try watching videos in your terminal](https://ta180m.github.io/Blog/2020/10/28/random-tidbits.html)) Anyways, I've been trying to find a replacement, but no other editor seems to have this nice integration. Then I found out that `gdb` has its own GUI. Or more accurately, a TUI. Just run `gdb` with the `--tui` switch and it should start up with a split screen, with your code at the top and the `gdb` command line at the bottom. Perfect!
I've got some mixed feelings about VSCodium, the text editor that I use. It's not bad, but as an Electron app, it predictably has terrible performance issues. For instance, compiling a tiny C++ file can take 10 times as long in VSCodium versus compiling it in the terminal. However, one thing that it does great, with the help of the phenomenal extension [Native Debug](https://github.com/WebFreak001/code-debug), is the excellent (although slow) integrated graphical debugging experience, using `gdb` as the backend. People often decry GUIs for being bloated and not much more useful than the command line, but in this case, the graphical debugger helps me keep track of where I'm at in my code. ([Try watching videos in your terminal](https://ta180m.github.io/blog/2020/10/28/random-tidbits.html)) Anyways, I've been trying to find a replacement, but no other editor seems to have this nice integration. Then I found out that `gdb` has its own GUI. Or more accurately, a TUI. Just run `gdb` with the `--tui` switch and it should start up with a split screen, with your code at the top and the `gdb` command line at the bottom. Perfect!
![GDB Tui](/Blog/assets/gdb-tui.png)
![GDB Tui](/blog/assets/gdb-tui.png)
## `ip` color
@ -32,9 +32,9 @@ Easy. `cd`. That's it. No aliases needed; should work in basically any shell.
Sparse files are pretty much black magic. Enough said. Basically, only used space is allocated, so a 14TB file containing all zeroes can be represented with no additional storage. You can have all the 14TB files that you ever want!
![A 14TB file](/Blog/assets/sparse-file.png)
![A 14TB file](/blog/assets/sparse-file.png)
Here's a 7 exibyte file, produced using [this technique](https://rwmj.wordpress.com/2020/11/04/ridiculously-big-files/). Now you can brag to four friends about your 7 exibyte hard drive!
![A 7EiB file](/Blog/assets/ridiculously-big-file.png)
![A 7EiB file](/blog/assets/ridiculously-big-file.png)

View file

@ -10,26 +10,26 @@ tags: ["Random", "Linux"]
The. Best. Documentation. Tool. Ever. Seriously. Instead of pulling up a web browser, searching for the command, and scrolling through pages of documentation, you can instead use `tldr` to get most common use cases for a command. Sure, maybe 10% your particular use or flag won't be on there, but it's a great quick-and-dirty way to get a refresher about unfamiliar commands.
![`tldr 7z`](/Blog/assets/tldr-7z.png)
![`tldr 7z`](/blog/assets/tldr-7z.png)
# `fzf`
Like `find` but better and more powerful. For instance, `pacman -Qq | fzf --preview 'pacman -Qil {}' --layout=reverse --bind 'enter:execute(pacman -Qil {} | less)'` will start up cool two-panel search for your (Arch) system's packages. And that's just the tip of the iceberg; there's so much more you can do with `fzf`
![`pacman -Qq | fzf --preview 'pacman -Qil {}' --layout=reverse --bind 'enter:execute(pacman -Qil {} | less)'`](/Blog/assets/tldr-fzf.png)
![`pacman -Qq | fzf --preview 'pacman -Qil {}' --layout=reverse --bind 'enter:execute(pacman -Qil {} | less)'`](/blog/assets/tldr-fzf.png)
# `convert`
No need to upload your images to sketchy websites who could steal your data in order to do image conversions. Imagemagick's `convert` tool has got your back. It's just `convert image.jpg image.png`, or you can also throw in some flags to resize the images and do other kinds of manipulation. It's magic! Or should I say "magick"?
![`convert`](/Blog/assets/tldr-convert.png)
![`convert`](/blog/assets/tldr-convert.png)
# `last`
Ever wanted to know your system's installation date, or even better, the full history of shutdowns and reboots? Well, `last` can help. Typically found in the `util-linux` package, it will faithfully log every boot and shutdown. According to `last` my system was "born" on Thursday September, 3rd 22:18:55 2020. Great to know, so I can celebrate its cake day next year!
![`last`](/Blog/assets/tldr-last.png)
![`last`](/blog/assets/tldr-last.png)

View file

@ -6,22 +6,22 @@ tags: ["Linux", "Windows"]
---
![LibreOffice hate](/Blog/assets/libreoffice-hate.png)
![LibreOffice hate](/blog/assets/libreoffice-hate.png)
OK, LibreOffice may not be the most loved application out there, but it's enough for most people. I use LibreOffice even on Windows! However, there is one thing about it that bothers me: the hideous icons! At first, I thought it might be caused be anti-aliasing or my screen scaling (currently set at 1.5x so everything's not tiny) but nope! The icons stayed hideous no matter what I did. Finally, after a bit of digging around in the settings, I found the root cause:
![LibreOffice icon settings](/Blog/assets/libreoffice-settings.png)
![LibreOffice icon settings](/blog/assets/libreoffice-settings.png)
Can you see it? The icon style was set to `Breeze`, which presumably uses bitmap icons, while I was in fact looking for the infinitely scalable `Breeze (SVG)` vector icons. Switching to vector icons did the trick, and now LibreOffice doesn't look hideous anymore! The question is, why is the default the ugly bitmap icons?
![LibreOffice icons](/Blog/assets/libreoffice-icons.png)
![LibreOffice icons](/blog/assets/libreoffice-icons.png)
People bash LibreOffice all the time for its imperfect compatibility of Office documents, but the important thing to remember is that *LibreOffice is not Microsoft Office!* If LibreOffice had focused less on being a Office clone and more on developing its own unique features, it would probably be in a much better shape right now. Millions of people are still using the basically-abandoned OpenOffice in 2020!
## But I need Microsoft Office!
Fine. Well, here are the latest developments. Traditionally, you had the two options of Wine, the compatibility layer, or going the VM route. Both suffer from their own flaws: Wine compatibility isn't perfect enough for Office, and VMs are resource-intensive, even if you want to make a few quick edits to a doc, and lack good graphical acceleration. [WinApps](https://github.com/Fmstrat/winapps) will give you the best of both worlds: the seamlessness of Wine, and the compatibility of a VM, well, using a [QEMU/KVM](https://ta180m.github.io/Blog/2020/11/19/fun-with-qemu-kvm.html) VM. WinApps runs a background RDP server and integrates the VM apps into your host desktop. If Wine is the analog of WSL, then WinApps is WSL2. The only problem is that it's a just a VM underneath, so you still get all the disadvantages of VMs. Still, if you have some RAM to spare, it might be enough to free your dependency on Windows for Office or Adobe apps. It's still under heavy development, so we'll see where it goes.
Fine. Well, here are the latest developments. Traditionally, you had the two options of Wine, the compatibility layer, or going the VM route. Both suffer from their own flaws: Wine compatibility isn't perfect enough for Office, and VMs are resource-intensive, even if you want to make a few quick edits to a doc, and lack good graphical acceleration. [WinApps](https://github.com/Fmstrat/winapps) will give you the best of both worlds: the seamlessness of Wine, and the compatibility of a VM, well, using a [QEMU/KVM](https://ta180m.github.io/blog/2020/11/19/fun-with-qemu-kvm.html) VM. WinApps runs a background RDP server and integrates the VM apps into your host desktop. If Wine is the analog of WSL, then WinApps is WSL2. The only problem is that it's a just a VM underneath, so you still get all the disadvantages of VMs. Still, if you have some RAM to spare, it might be enough to free your dependency on Windows for Office or Adobe apps. It's still under heavy development, so we'll see where it goes.
![WinApps demo](https://raw.githubusercontent.com/Fmstrat/winapps/main/demo/demo.gif)

View file

@ -11,7 +11,7 @@ WM fans, don't kill me for saying this, but window managers suck. To see why, le
## Installing a WM
OK, I'll admit that this step is much faster. Most WMs are only a few megabytes and take a few seconds to install, even with slow package managers like `urpmi`. Try installing something like KDE Plasma on Mageia or even Arch. It's going to take a while. (Maybe go eat a snack while it's installing?)[https://ta180m.github.io/Blog/2020/08/25/wsl-2-gnome-desktop.html].
OK, I'll admit that this step is much faster. Most WMs are only a few megabytes and take a few seconds to install, even with slow package managers like `urpmi`. Try installing something like KDE Plasma on Mageia or even Arch. It's going to take a while. (Maybe go eat a snack while it's installing?)[https://ta180m.github.io/blog/2020/08/25/wsl-2-gnome-desktop.html].
## Configuring a WM
@ -20,7 +20,7 @@ Now that you have your favorite WM installed, what next? If you're hardcore, you
I'm going to use the example of KDE Plasma some more, since it exemplifies a nice, well-rounded desktop environment. One of the key benefits of Plasma is its excellent integration with the KDE application suite. Sure, not every DE has a very complete set of applications, but it's loads better than anything you can do with a WM, in addition to a drastically lower amount of tedious work to set everything up.
The most common criticism of desktop environments is that they are "bloated" and "resource-hogging". And yes, I'm going to have to concede this one to the WM fans, since window managers tend to be very spartan and minimalistic. I even use i3 sometimes when working with very intensive software, such as with the [MacOS VM](https://ta180m.github.io/Blog/2020/11/19/fun-with-qemu-kvm.html). But every time I use i3, I'm constantly reminded of the Plasma features that I take for granted: a consistent icon theme, screen scaling for my high DPI monitor so the text can actually be legible, adjusting the screen color, mouse scroll direction, Krunner, and much more. Never forget Krunner. The single most important KDE app. Too bad it's glitchy with i3. I did end up fixing some of those things, but it doesn't feel *right*. I could put in more time, but there's just something *missing* about i3. It's incomplete.
The most common criticism of desktop environments is that they are "bloated" and "resource-hogging". And yes, I'm going to have to concede this one to the WM fans, since window managers tend to be very spartan and minimalistic. I even use i3 sometimes when working with very intensive software, such as with the [MacOS VM](https://ta180m.github.io/blog/2020/11/19/fun-with-qemu-kvm.html). But every time I use i3, I'm constantly reminded of the Plasma features that I take for granted: a consistent icon theme, screen scaling for my high DPI monitor so the text can actually be legible, adjusting the screen color, mouse scroll direction, Krunner, and much more. Never forget Krunner. The single most important KDE app. Too bad it's glitchy with i3. I did end up fixing some of those things, but it doesn't feel *right*. I could put in more time, but there's just something *missing* about i3. It's incomplete.
If you go on Reddit or do a DuckDuckGo search, you'll find plenty of examples of beautiful, heavy-customized WM setups. The emphasis on heavy-customized. It takes hours and hours of work to create something like that! Sure, you can download their dotfiles and set it up on your own computer, but it still doesn't feel quite the same as using a mature, well-rounded DE like KDE Plasma. Desktop environments are designed to make your life easier, even if it doesn't feel like it sometimes. WMs are really for people who have too much time on their hands and *need* that ultimate customizability. For everyone else, stick with your desktop environment.

View file

@ -48,11 +48,11 @@ export DISPLAY=:0 # set the display
Here's SuperTuxKart in all its glory running in a container with full graphical acceleration!
![SuperTuxKart in a container](/Blog/assets/nspawn-supertuxkart.png)
![SuperTuxKart in a container](/blog/assets/nspawn-supertuxkart.png)
And that's it! Now you have a fast, simple way to test GUI graphically accelerated apps without messing with your host OS. (I still haven't gotten sound to work yet, but it shouldn't be *that* hard...)
Part of the simplicity of `systemd-nspawn` is that it is more of an extension of the age-old `chroot` instead of trying to virtualize too much like Docker. There's no need to worry about virtual network devices, virtual disks, volumes, or any of that stuff. Sure, that limits it in many ways, but it is still a very powerful OS virtualization method when the host and container are running the same OS. Previously, I had also experimented with [QEMU/KVM](https://ta180m.github.io/Blog/2020/11/18/fun-with-qemu-kvm.html) for this, but it seems overkill since the host and guest can share much the OS such as the kernel. Of course, full-blown virtual machines have their own horde of problems, such as terrible graphical acceleration unacceptable for testing SuperTuxKart.
Part of the simplicity of `systemd-nspawn` is that it is more of an extension of the age-old `chroot` instead of trying to virtualize too much like Docker. There's no need to worry about virtual network devices, virtual disks, volumes, or any of that stuff. Sure, that limits it in many ways, but it is still a very powerful OS virtualization method when the host and container are running the same OS. Previously, I had also experimented with [QEMU/KVM](https://ta180m.github.io/blog/2020/11/18/fun-with-qemu-kvm.html) for this, but it seems overkill since the host and guest can share much the OS such as the kernel. Of course, full-blown virtual machines have their own horde of problems, such as terrible graphical acceleration unacceptable for testing SuperTuxKart.
Here are a few possible use cases:
@ -74,7 +74,7 @@ There's one final thing I need to clarify, and that's the title. By worst init s
Whoa! That's a lot!
Much of the hate that systemd receives stems from these blatant violations of the [Unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy). systemd does not do one thing and do it well, unlike its predecessors. It does dozens of things, and arguably, it doesn't do them badly, but thought of systemd slowing expanding its grasp on your entire OS is unacceptable to some people. But of course, this begs the question of whether it is really necessary to adhere so strictly to the Unix philosophy, since most big, standalone apps like GIMP and [LibreOffice](https://ta180m.github.io/Blog/2020/12/25/linux-office.html) obviously violate it.
Much of the hate that systemd receives stems from these blatant violations of the [Unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy). systemd does not do one thing and do it well, unlike its predecessors. It does dozens of things, and arguably, it doesn't do them badly, but thought of systemd slowing expanding its grasp on your entire OS is unacceptable to some people. But of course, this begs the question of whether it is really necessary to adhere so strictly to the Unix philosophy, since most big, standalone apps like GIMP and [LibreOffice](https://ta180m.github.io/blog/2020/12/25/linux-office.html) obviously violate it.
Still, systemd is everywhere these days, so it might be better to get used to it. Many of its tools are quite good, and `systemd-nspawn` in particular is exceptional. After watching the proliferation of systemd in the past few years, it's undeniable that it's here to stay.

View file

@ -6,9 +6,9 @@ tags: ["Linux", "Virtualization"]
---
![Linux Mint with 255 cores](/Blog/assets/mint-155-cores.png)
![Linux Mint with 255 cores](/blog/assets/mint-155-cores.png)
As far as I know, there aren't any 255 core processors on the market. Yet. But that doesn't stop us from making a virtual machine using [QEMU/KVM](https://ta180m.github.io/Blog/2020/11/18/fun-with-qemu-kvm.html) and [SMP](https://en.wikipedia.org/wiki/Symmetric_multiprocessing) with an absurd number of processors, as shown above.
As far as I know, there aren't any 255 core processors on the market. Yet. But that doesn't stop us from making a virtual machine using [QEMU/KVM](https://ta180m.github.io/blog/2020/11/18/fun-with-qemu-kvm.html) and [SMP](https://en.wikipedia.org/wiki/Symmetric_multiprocessing) with an absurd number of processors, as shown above.
Why 255? Well, that's the limit apparently. Yeah, it sucks. I wish it was higher too. But if you're running more cores than the number of physical cores available on your computer, there's no benefit and you'll probably see worse performance. No one even has that many physical cores to begin with, so there's no incentive for QEMU/KVM to support even more cores. I'm pretty sure that only the first 64 cores are KVM acclerated, which adds another reason why you shouldn't do this. (virt-manager also warns you from against a VM more cores than you actually have. It's a bad idea.)

View file

@ -8,7 +8,7 @@ tags: ["Linux"]
Ubuntu (you thought this was going to be about Arch, didn't you?) is a great distro. Cue Reddit screaming. Look on any web forum and you'll find people patronizing Ubuntu. Why? For having a straightforward installer that I can use to get Ubuntu up and running in half an hour with my favorite apps? For being the most supported distro by third-party developers? (They always have a PPA) For dominating server OSes in terms of market share? Nope. *It's for n00bs and beginners.*
There are so many things wrong with that claim, but this post isn't about Ubuntu. OK, it kind of is, and Ubuntu sure has its share of problems, but let's get to the main point. I previously used Ubuntu for over a year, first in WSL, then as my primary OS. But then I met Arch. People sometimes ask me why Arch over Ubuntu, so I'm going to sketch a few reasons why. [Memes](https://ta180m.github.io/Blog/2020/10/04/arch-memes.html) aside, let's begin.
There are so many things wrong with that claim, but this post isn't about Ubuntu. OK, it kind of is, and Ubuntu sure has its share of problems, but let's get to the main point. I previously used Ubuntu for over a year, first in WSL, then as my primary OS. But then I met Arch. People sometimes ask me why Arch over Ubuntu, so I'm going to sketch a few reasons why. [Memes](https://ta180m.github.io/blog/2020/10/04/arch-memes.html) aside, let's begin.
5. **Hemorrhaging edge**: Oh what, it's actually bleeding edge? Oops. Anyways, Ubuntu has absolutely expansive package repositories that can be further augmented with PPAs, but they can be pretty stale (Er, I meant stable). As in one or two years old, especially with the LTS versions. You probably wouldn't want to eat most stuff that's that stale. Well, no problem with Arch. You get the latest and greatest, at the expense of stuff randomly failing and having to debug and fix it for an hour. Great tradeoff.

View file

@ -40,7 +40,7 @@ Oh, the terror, shriek the Linux fans! Some have predicted the [downfall of Linu
And the dream case: Linux for the win! Eric Raymond's argument is definitely the most bizarre and interesting endgame I've heard of resulting in this case, and it seems... un-Microsofty in my opinion. Even if it were to happen, it would definitely be at least five years away. It just doesn't really make sense for Microsoft to completely nuke their NT kernel, especially with Windows 10X right around the corner. Maybe this could happen 10 years from now though, but I still think it's kind of unlikely. But really, is the current situation *sustainable* in the long run? Linux has taken over the server market and a huge chunk of the mobile market, why not the desktop market next? If preinstalled hardware really becomes a thing, a big thing, and app support gets ironed out as more people switch, it could become a positive feedback loop!
Let's think in terms of a small disturbance, like in calculus. What if Linux market share, by complete chance, were to take a step in the upward direction, say, tick up from 3% to 3.01%? Assuming there are one billion PCs out there, that's an increase by 100 thousand! That's 100 thousand more potential consumers for your Linux app or hardware. And this could have an impact, a small impact, but one nonetheless, on the amount of effort that hardware companies spend on Linux compatibility, or developers making a few more ports to Linux, or just having a [larger community](https://ta180m.github.io/Blog/2021/02/14/i-btw-use-arch.html) of people to interact with. It could make people less likely to choose macOS over Linux. So those are all positive feedback things.
Let's think in terms of a small disturbance, like in calculus. What if Linux market share, by complete chance, were to take a step in the upward direction, say, tick up from 3% to 3.01%? Assuming there are one billion PCs out there, that's an increase by 100 thousand! That's 100 thousand more potential consumers for your Linux app or hardware. And this could have an impact, a small impact, but one nonetheless, on the amount of effort that hardware companies spend on Linux compatibility, or developers making a few more ports to Linux, or just having a [larger community](https://ta180m.github.io/blog/2021/02/14/i-btw-use-arch.html) of people to interact with. It could make people less likely to choose macOS over Linux. So those are all positive feedback things.
What about negative feedback? Well, there are quite a lot of problems with Linux right now, such as lack of apps in important areas, and the general need to be more technically capable. If this was a post about messaging apps, I would also bring up [network effects](https://en.wikipedia.org/wiki/Network_effect), which arguably applies here as well. There's quite a lot of negative feedback going on here, so it's hard to say whether we are in a stable or unstable equilibrium.

View file

@ -9,17 +9,17 @@ It's the day! Plasma 5.21 is out!
First, let me flex my `neofetch` to answer all your burning questions about my OS:
![neofetch](/Blog/assets/neofetch.png)
![neofetch](/blog/assets/neofetch.png)
Now, time for the update. The big one. The closest thing to a point update in a rolling release. And...
![yay](/Blog/assets/yay.png)
![yay](/blog/assets/yay.png)
Lots of updates, but Plasma 5.21 is not one of them.
Digging a bit deeper, it looks like it's still in [testing](https://wiki.archlinux.org/index.php/Official_repositories#Testing_repositories). Looks like we need to enable it first. Hopefully my computer doesn't explode or something when I do this...
![yay with testing](/Blog/assets/yay-testing.png)
![yay with testing](/blog/assets/yay-testing.png)
There we go! Looks like Linux 5.11 is part of this sweet deal too! Let's break our rolling release! I mean, what could go possibly wrong? It's *only* 1263.42 MiB of packages. And I don't have a backup ready. Great!
@ -27,15 +27,15 @@ A few minutes and a reboot later...
OK, the boot looks good, no black screens or anything. Plasma (looks like the X11 session got renamed from Plasma to Plasma X11) on X started up extra fast... and we're in!
![Plasma 5.21](/Blog/assets/plasma-5.21,png)
![Plasma 5.21](/blog/assets/plasma-5.21,png)
Some first impressions: The new Breeze Twilight theme looks awesome! I love hybrid light-dark themes! The application launcher is also organized a lot better now.
![The new system monitor](/Blog/assets/system-monitor.png)
![The new system monitor](/blog/assets/system-monitor.png)
The system monitor app looks pretty good too and seems infinitely customizable, although wasn't the old Ksysguard working just fine? Whatever.
![The firewall configuration settings](/Blog/assets/firewall.png)
![The firewall configuration settings](/blog/assets/firewall.png)
Now for the new firewall configuration settings... looks like I need to install a firewall first! A few minutes later... what a nice place to insert a giant picture of Konqi! Moving on.
@ -43,11 +43,11 @@ The settings app has generally been cleaned up some more. There's a few other ne
Now for some Wayland...
![Plasma 5.21 Wayland](/Blog/assets/plasma-5.21-wayland.png)
![Plasma 5.21 Wayland](/blog/assets/plasma-5.21-wayland.png)
Of course. The screen scaling is all wacko when I try to scale apps up 1.5x. Native Wayland apps look perfectly fine, but everything else, including much of Plasma, still looks pretty bad. Apparently it's a result of [this bug](https://bugs.kde.org/show_bug.cgi?id=389191) and it looks like two years later, it still hasn't been resolved yet.
![Plasma crash](/Blog/assets/plasma-crash.png)
![Plasma crash](/blog/assets/plasma-crash.png)
And finally, we got a crash! Hooray! Just like last time I tried Wayland. Looks like the next update will be the one where Wayland is finally usable?