simple-base64. It works the way you'd expect:
use simple_base64 as base64;
...
let decoded = base64::decode("YmFzZTY0")?;
simple-base64. It works the way you'd expect:
use simple_base64 as base64;
...
let decoded = base64::decode("YmFzZTY0")?;
No, you're right that it has scripts, they're just not the scripts used by SysV-style init systems. They have different names, are in different locations, and are executed differently.
I used Slackware for several years back in the 90s, and from that experience I'd recommend against learning it. I mean, with VMs today it's simple to try new distributions, so go for it, but I'd put it waaaaay down the list of distributions/operating systems to try. If you have anything else you're interested, put it first. Slackware is standard Linux so there's nothing really special you'd find when using it, and it's just a painful experience in general. I think some people will argue that it helps you "really learn Linux", but I don't think so. It just helps you learn Slackware's idiosyncrasies, and learning pretty much any other distribution would be more beneficial than that.
Slackware has advanced from when I used it in the 90s, but only barely (they have a network-based package manager now, I guess, although it proudly avoids dependency resolution!)
Slackware uses the sysvinit program, but doesn't have System V-style scripts. Which is somewhat confusing, but sysvinit is a basic init program that will just do whatever /etc/inittab
tells it, so you can write your startup scripts to work however you want.
Slackware uses what people tend to call a BSD-style init, but it's nothing like the modern BSDs, nor the older BSDs, not really. If you use Slackware, you'll learn how Slackware's init system works, but that's about it.
When The Orville came out, I hadn't watched much Star Trek. Growing up, TNG was the one television show that my parents would break the "no TV at the dinner table" rule for, though it happened rarely enough that I really have no memory of it.
About 20 years ago I watched several episodes of TOS and liked it well enough.
I always wanted to like Star Trek, so ~10 years ago I tried season 1 of TNG, which I now realize is rather universally considered an error; and as a result, I didn't much care for TNG. But I still wanted to like it, and Star Trek in general! So when I saw The Orville, I decided to give it a shot. And while I agree that the early mix of comedy with more serious material was a bit off-putting, I thoroughly enjoyed the show. This was what TNG was trying to be (I mean, that's not really fair, but it was my initial sense).
Which then led me to season 3 of TNG, which I started watching last year. And I absolutely love it, and find it overall better than The Orville (which I still really like); but The Orville was basically my gateway to actually enjoying Star Trek.
So maybe I'm coming inside-out from most viewers, but I really like The Orville, and as a bonus, it got me "back" into Star Trek proper.
I can second Beelink here. I bought a Beelink SER5 for US$380 as a gaming computer for my kids. It's an AMD Ryzen 7 5800H with a Vega GPU, 16G RAM and a 500GB SSD. It probably won't work well with the latest graphics-intensive games, but it's been great so far with a bunch of games my kids like.
That one worked so well that when I needed a new desktop computer for their schoolwork and similar, I got another Beelink, this time a Mini S12 for US$200. It's an Intel N95 with 8G RAM and a 256G SSD. Works absolutely fantastically for its purpose.
Both are tiny and silent.
Just a quick note, I generally use the packagekit backend (via Plasma Discover) and it works fine the vast majority of the time (including taking snapshots).
The only time I've seen problems with it is when user intervention is required, e.g. if there's some conflict on upgrade. Discover, at least, seems to silently fail, at which point I hit the terminal and do sudo zypper dup
.
I'm not sure if Yast works better, as I prefer Discover since it integrates (mostly) seamlessly with Plasma, and using the CLI doesn't bother me. I could see it being an issue for somebody who wants things to "just work" and/or is not well-versed in Linux. So, I agree that it may not be ideal for newbies; just wanted to give some info on the current packagekit status.
I used Solus for a while on my laptop. One day a minor kernel version bump caused my display to stay black. I reported it to the Solus bug tracker and they told me it's not their problem, and I should deal with the kernel devs. But of course the kernel devs reasonably tell you to deal with your distribution if they've modified the kernel, which Solus had.
So I installed Tumbleweed and never looked back. I don't miss Solus. It was fine, but I don't trust it now, the way I do trust Tumbleweed.
Ultimately, of course (according to the article), he does, sort of, admit it was motivated by race:
“1. The Tulsa race massacre is a terrible mark on our history. The events on that day were racist, evil, and it is inexcusable. Individuals are responsible for their actions and should be held accountable.
“2. Kids should never be made to feel bad or told they are inferior based on the color of their skin.”
I guess he is claiming that saying "people of race X murdered people of race Y because they are race Y" will make kids of race X feel bad? That's the only (tenuous) link I can see here. It's absurd on its face, of course.
According to the article, he really weasel-worded things:
Ryan Walters … said teachers could cover the 1921 massacre … but … should not “say that the skin color determined it”.
It's weaselly because he didn't outright say that it wasn't racially motivated, just that teachers shouldn't say that it was. Because of some kids' feelings, apparently.
The best bit is his word salad response to the question of why the massacre doesn't fall under his definition of Critical Race Theory:
“I would never tell a kid that because of your race, because of your color of your skin, or your gender or anything like that, you are less of a person or are inherently racist.
“That doesn’t mean you don’t judge the actions of individuals. Oh, you can, absolutely. Historically, you should: ‘This was right. This was wrong. They did this for this reason.’
“But to say it was inherent in that … because of their skin is where I say that is critical race theory. You’re saying that race defines a person. I reject that.
“So I would say you be judgmental of the issue, of the action, of the content, of the character of the individual, absolutely. But let’s not tie it to the skin color and say that the skin color determined it.”
What does this even mean? It's fine to say that there was a reason for an action, and that the action was wrong... but if you say that the action was racially motivated, that's not OK, because (here's a massive leap of logic) that means race defines a person?
"Let's not tie it to the skin color and say that the skin color determined it" is really just arguing that we shouldn't care about motive. He acknowledges the massacre was wrong, but doesn't want anybody to know why it occurred. I wonder if he's as critical of racial motive when it's black-on-white violence, for example...
Others have covered PRIMARY vs CLIPBOARD (the separation of which I find to be extremely useful).
For Vim, you have access to these both via the registers +
(CLIPBOARD) and *
(PRIMARY). So, for example, to paste from your CLIPBOARD selection, you'd do this:
"+p
(or P
). Similar for yanking:
"+yy
for example.
I’ve noticed that some settings don’t persist after Connect is updated. I’m not sure if that’s because the settings pane changes with new options hence it can’t be persisted but just something I noticed
This happened with the last update as well. It took me a bit of time to figure out why some things seemed a little off. At least with this update I realized immediately why things weren't right. Despite seeming kind of small, I think this is a somewhat serious issue, since it feels like the update did a lot to change the interface, even though it didn't.
That being said, Connect is awesome and this certainly isn't a deal breaker for it.
There is a Qt interface for libvirt, called qt-virt-manager. This is a rough analog of virt-manager. Unfortunately, it hasn't seen a release since August 2021, nor a git commit since the same time. The good news is that it's written in C++: if you're so inclined, you ought to be able to get up to speed at least a bit faster than you would with a project in another language.
As much as I'd like a KDE-native VM GUI, I still just use virt-manager since it's maintained, and gets the job done. Generally I'm just using ssh to access VMs anyway, so it hardly matters. But if qt-virt-manager made a comeback, I'd definitely give it strong consideration.
openSUSE also has a simple FDE setup. Just check a box and enter a passphrase during install. It's not default, but it's about as easy as possible to set up.