Noodlings | BTRFS, Ultra Widescreens and Floppy Drives

Not having faded into the Podcast ether yet, I bring this nonsense to you almost a week late. At least, a week later than I wanted to complete this. In an effort to keep you interested

The 7th Noodling place of unrest

BTRFS

I have been using BTRFS on all of my openSUSE machines without issue. In my quest to build a new multi-roll system to act as a server, workstation and occasional casual desktop use, I wanted to have a storage solution that was very fault tolerant and would allow me to expand my disk size with minimal effort. That is in both replacing individual drives with larger drives and potentially adding another controller card to have more drives.

ZFS is in the news as the new “hotness” for a file system and it does indeed have a lot of the really awesome features BTRFS provides, maybe more but support in Linux doesn’t appear to be as robust as BTRFS. Could my mind change in the future? Absolutely, but for now, until I get the stability of BTRFS on root, the snapshot system and the ease of flexibility in altering the array of storage, I will stick with BTRFS.

https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices

Ultra Widescreen Monitors

I have been looking at doing an upgrade to my monitor situation, for numerous reasons. The monitors I am using are of unequal resolution, size and aspect ratio, it has been fine but I am becoming less satisfied with its usability. This is especially true since I started to use some of the tiling techniques built into Plasma. I just happen to need more pixels. Looking at my available options, I became interested in one of these 1440p monitors. My issue is, I am not interested in a curved monitor. I think they look just a bit silly and I don’t stand directly in front of the computer all the time. Interestingly, it seems as though the curved screens are less expensive then their flat counterparts with the same resolution and frequency. Although I would prefer a flat screen, it is more economical and of better specifications to go with the curved model.

I’m not prepared to make a purchase today as I need to do some more research on the subject but I am now very much interested in a single 1440p monitor rather than my two cobbled, odd lots hanging above my laptop.

https://ark.intel.com/content/www/us/en/ark/products/80345/intel-core-i7-4610m-processor-4m-cache-up-to-3-70-ghz.html

End to Floppy Drives

US military has been using 8-inch floppy disks in an antiquated ’70s computer to receive nuclear launch orders from the President. Now, the US strategic command has announced that it has replaced the drives with a “highly-secure solid state digital storage solution,” Lt. Col. Jason Rossi

The 8-inch floppy disks have been used in an ancient system called the Strategic Automated Command and Control System, or SACCS.

It’s used by US nuclear forces to send emergency action messages from command centers to field forces, and is unhackable precisely because it was created long before the internet existed. “You can’t hack something that doesn’t have an IP address.

Despite the age of the system, the Air Force is confident in its security and has a pretty good handle on maintaining it. By contrast, installing an all-new system isn’t as easy as it sounds. “You have to be able to certify that an adversary can’t take control of that weapon, that the weapon will be able to do what it’s supposed to do when you call on it,”

https://www.engadget.com/2019/10/18/us-military-nuclear-missiles-floppy-disks/?guccounter=1

Sad Commodore 64 News

My U13 Logic chip is likely failing. I am sure it’s not the RAM as I am having an intermittent problem with my system. Sometimes I get a blank screen and sometimes some garbled mess of characters in a range of colors. Based on the likely causes, I am quite sure it is the 74LS257A Logic IC. That should cost me less than $1 for the part and around $10 on shipping.

https://retrocomputerverzamelaar.nl/commodore-64-problems/
https://www.retroleum.co.uk/results.php?q=logic

BDLL Follow Up

I am late on the release of this podcast, not because I am fading out already, but because of life things. Regardless, I wanted to follow up on a BDLL from 19 October 2019. The discussion was about distro hopping, why Linux users distro hop. Often when people are new to Linux, they hop around and try new distributions. Some people like to jump around every time there is something new released.

Some Distros cater to some bits of hardware better than others. MX Linux on old hardware, openSUSE on newer hardware, Manjaro or Pop!_OS for gaming. Debian for obscure hardware. Ubuntu and its flavors for the mainstream.

I am not a distro hopper, embed myself, decided to stick around and help out to the best of my ability.

Between Mandrake / Mandriva fading and embedding into openSUSE I jumped around a bit. When I decided on openSUSE, I knew it wasn’t perfect, there were some issues but they were easily mitigated, I was most enamored with the friendly and helpful community along with the “ecosystem” of tools around openSUSE. The ease of installing software the graphical way and a pretty awesome wiki.

I mostly try out other distros to see what else is out there. Nothing ever seems to capture me like openSUSE. There are many good choices of Linux and I would probably be content elsewhere but nothing quite gives me the excitement that the green chameleon clad openSUSE provides.

BigDaddyLinux Live 19 October 2019

openSUSE Corner

Lots of snapshots have rolled through with new software and subsequent bug fixes. Of note Plasma 5.17.0 has arrived in all of it’s Glory

Tumbleweed Snapshots 20191009 20191011 20191012 20191014

Firefox has been updated to version 69.0.2 which contained a single fix for Linux-only crashes when changing the playback speed of YouTube videos. Fwupd shipped at version 1.3.1, that is a daemon that allows session software to update the firmware. It now allows for disabling of all plugins and added support for thunderbolt interfae for kernel safety checks. Gstreamer and many of it’s plugins were updated to version 1.16.1 which offered performance improvements. nodejs12, python-packaging and tcpdump were updated to address more than two dozen CVEs.

Plamsa 5.17.0 arrived with some significant changes to the new version. The release announcement says that this new version is as lightweight and thrifty with resources as ever before. Notably, the start-up scripts were converted from a slower Bash to a faster C++ and now run asynchronously, which means it can run several tasks simultaneously, instead of having to run them in sequence. KDE Applications 19.08.2 improved High-DPI support in Konsole and other applications. Many bug fixes in Kmail and saving messages directly to remote folders has been restored. Many other KDE applications received updates as well. e2fsprogs update 1.45.5 addressed a CVE where an attacker would have been able to corrupt an ext4 partition. Updates to gnutls, Nano and php7 were also included.

Mumble was finally updated to 1.3.0 after getting through the rigorous legal review of the SUSE lawyers and now those crazy lips are gone.

The Tumbleweed Snapshot reviewer gives 20191009 a moderate score of a 90; 20191011 a stable score of 92; 20191012 a stable score of 96; and 20191014 a moderate score of 82.

The Project Name Change Vote Continues

The discussion around changing the name of the project is still continuing in the mailing list. The vote has been extended out to the 7th of November, 2019. It has been decided to create a wiki page to consolidate the information. The keypoints can be summarized by the following:

For Keeping the project name

  • If the name is changed, we would lose brand reputation earned over the years.
  • Many members and other contributors are strongly attached to the current name.
  • Changing the name might give the impression that the relationship between SUSE and openSUSE is strained.
  • A lot of work will be required to rename domains, OBS projects and metadata, GitHub namespace, packages trademarks, etc.
  • Rebranding requires a tremendous amount of communication (and money) over years to establish the new brand name.
  • SUSE can transfer or license relevant trademarks to an openSUSE Foundation.
  • The relationship with SUSE is part of our marketing strategy, e.g. Leap/SLE’s shared codebase.
  • Changing the project name will make current openSUSE swag (T-shirts, mugs, stickers, etc) obsolete.

Reasons in favor of the name change

  • openSUSE is often typed and/or pronounced incorrectly (e.g. OpenSUSE, OpenSuSE etc). Watch how do you say SUSE?
  • The Free Software Foundation (FSF) complains about the looseness of the term “open”.
  • The distinction between openSUSE and SUSE can be confusing to people new to either brand. Some people have been known to shorten openSUSE to SUSE.
  • If the community thinks that the project benefits from a new name then this is the moment to change it, i.e. before registering a new legal structure (like a foundation).

My thoughts on this, the reasons for a name change seams superfluous. Although I understand the there is some confusion and how it is typed is often wrong, those do not outweigh the marketing strategy of the Leap/SLE’s shared codebase, the amount of work that would go into rebranding, renaming and making all the cool things I have today obsolete.

I think it is good that we the openSUSE community have this discussion. It has been good for me as I can reflect on my reasons I don’t care for it and rather than just make it an emotional and close-minded decision, I can look at the facts and make a rational decision to keep the name just as it is.

If the name changes, I won’t be upset, disappointed, yes, but not upset. It is the community and the technology that I like, the name is secondary.

Advertisements

CPU Security Mitigation on openSUSE | Tuning it for Your Case

This is a little outside of my normal blatherings format but after stumbling upon a video from Red Robbo’s YouTube channel. I wanted to investigate his claims that maybe, just maybe the security mitigations that I have chosen they are a bit excessive for my use case. Recently, openSUSE has added a feature to make this easily user adjustable. Since they made it easy, obviously, someone far smarter than I am has decided that some of the mitigations may be excessive and not worth the performance loss for all use cases. I written about the mitigations some time ago and how it is fun to see all that is being implemented. Maybe it’s time to dial it back.

This is the video that made me pause and think about the choices I’ve made.

Red Robbo made the statement, “how many people are actually impacted by this, not potentially impacted but actually…”

Fair statement, what is my actual risk. not imaginary but actual risk. So that got me thinking. My setup has been to keep the mitigations on “Auto”. That seems fair to me. Let the system decide how many mitigations I need to have in place. Then this video came out and It got me thinking…

“How many mitigations do I really need to have to protect my system?”
“What are the threats against my main machine, a laptop, that does not run any services?”
“How much of a performance improvement would I have if I switched the mitigations off?”

According to SUSE, by leaving the mitigations to Auto, “All CPU side channel mitigations are enabled as they are detected based on the CPU type. The auto-detection handles both unaffected older CPUs and unaffected newly released CPUs and transparently disables mitigations. This options leave SMT enabled.”

It was time to explore this further. Do some, self-discovery, as it were.

In reading all the CVEs on the subject, they are worded as either, “Local attacker”, “In theory”, “…a possible approach”, “could be made to leak”.

I couldn’t help but think, golly, this is all… speculative… isn’t it. I now wonder what the actual threat is. I appreciate how the fixes were very much preemptive before any attacks were made but it almost seems like building my house so that it is meteor proof, just in case of meteor strike.

What I’ve done

So I did as Red Robbo suggested, not on all my machines, just the machines that that, I shut them off. I am not on anyone’s target list. I don’t run any kind of service that has tons of people in this system and it doesn’t often face the scary internet directly as it is going through a firewall that filters most of the scary traffic away. Making the change was really quite easy and underscores the beauty of YaST. To get to the right module, I go into YaST and select the Boot Loader module under System.

Within the bootloader module, select the Kernel Parameters tab and under the CPU Mitigations, I selected the drop down and the Off option.

After selecting okay and rebooting the system I can’t say I noticed any major improvement to performance. I tested Auto vs Off and I couldn’t actually tell the difference in performance. There may be some improvement but either I am personally too slow or nothing I do on a regular basis is affected by the mitigations.

Final Thoughts

For “desktop” machines, I am pretty confident that the other security features of Linux is quite adequate to keeping you safe on the Scary Internet. This desktop machine doesn’t provide any services to anyone outside of me as I am using it. I don’t have an Internet facing web service or database that has a risk in being compromised by bad actors.

For my personal server, that really doesn’t do a lot, I am keeping the mitigations to Auto. Although it does not face the internet, it is on all the time, I am not asking too much of it and it has a great chance at getting poked by something. Though, since I am not a target, the chances of that machine being compromised is also rather slim.

Your situation is dependent on your level of paranoia. Crank up your mitigations to 11 if you think it is best. As for this particular machine and the other little laptops and netbooks I use, I don’t see it as necessary.

References

SUSE.com Centralized CPU issue Mitigation document
Red Robbo’s Workshop YouTube Video: Improve Intel CPU performance on openSUSE
CubicleNate.com Spectre and Meltdown Vulnerability Status
TID 7022512 – Security Vulnerability: “Meltdown” and “Spectre” side channel attacks against CPUs with speculative execution.
TID 7022937 – Security Vulnerability: Spectre Variant 4 (Speculative Store Bypass) aka CVE-2018-3639.
TID 7023075 – Security Vulnerability: Spectre side channel attack “Bounds Check Bypass Store” aka CVE-2018-3693.
TID 7023076 – Security Vulnerability: Spectre side channel attack “Lazy FPU Save/Restore” aka CVE-2018-3665.
TID 7023077 – Security Vulnerability: “L1 Terminal Fault” (L1TF) aka CVE-2018-3615, CVE-2018-3620 & CVE-2018-3646.