Specifically what is the behavior you’re seeing? I can’t guess exactly from the meme.

I’d guess that it’s most likely not systemd itself causing the problem, but rather something kernel- or hardware-side.

I assume that it’s legal to ride a gasoline-fueled moped in the bike lane. Does this make everyone happy?

Just giving an example; translate to your preferred environment!

If you use pixz, you can get indexing-permitting-for-random access, parallel compression/decompression and (generally superior to gzip’s LZ77) LZMA compression with tarballs.

$ sudo apt install pixz
$ tar cvf blahaj.tar.pixz -Ipixz blahaj/

If it honestly doesn’t permit the User password to be reset, is there a “factory reset the whole BIOS” option?

Phrases

Gotcha, thanks!

I’m assuming that it’s some sort of component from the air conditioner, but damned if I know what it is. Looks like power plugs on it, and someone else mentioned “caps”, so maybe a capacitor, though I wasn’t aware that there was some kind of plug standard for large removable capacitors.

kagis

Yeah, this capacitor looks similar.

EDIT: Apparently air conditioners can use large capacitors:

https://www.amazon.com/Capacitor-Conditioner-Multi-Purpose-Capacitor-5-Warranty/dp/B092ZQ3Y3N

Capacitor for Air Conditioner 5 uf MFD 370 or 440 Volt VAC, Multi-Purpose Round Capacitor for AC Motor Run or Fan Motor Start or Condenser Straight

EDIT2: Oh, I bet I know what it’s for, given the “Fan Motor Start” and what I assume is a misspelled “Condenser Start” text on the Amazon listing. Some hardware will draw a lot of juice when starting up. Laser printers are prone to this, for example. The references above are to mechanical things, moving components, and maybe one need extra power to overcome static friction, to get the parts in motion initially; once moving, they face (lesser) kinetic friction. One option is to just draw a ton of power from the line, but then that increases the peak power demands of a device. Another option, gentler on whatever circuit or external power source is providing the power, is to charge a capacitor for a bit and that’ll let you create a big surge of available power for a moment without having to have higher peak demands on the external power source. Adds to device cost, but limits its peak draw.

This is an amazing graph.

That’s an older version rendered by the GitHub project that does those.

https://github.com/FabioLolix/LinuxTimeline

Their releases page has current ones:

https://github.com/FabioLolix/LinuxTimeline/releases

PNG has terrible compression

It’s fine if you’re using it for what it’s intended for, which is images with flat color or an ordered dither.

It’s not great for compressing photographs, but then, that wasn’t what it was aimed at.

Similarly, JPEG isn’t great at storing flat-color lossless images, which is PNG’s forte.

Different tools for different jobs.

At least at one point, GIF89a (animated GIF) support was universal among browsers, whereas animated PNG support was patchy. Could have changed.

I’ve also seen “GIF” files served up online that are actually, internally, animated PNG files, so some may actually be animated PNGs. No idea why people do that.

On the “better compression” front, I’d also add that I doubt that either PNG or WebP represent the pinnacle of image compression. IIRC from some years back, the best known general-purpose lossless compressors are neural-net based, and not fast.

kagis

https://fahaihi.github.io/NNLCB/

These guys apparently ran a number of tests. They had a neural-net-based compressor named “NNCP” get their best compression ratio, beating out the also-neural-net-based PAC, which was the compressor I think I recall.

The compression time for either was far longer than for traditional non-neural-net compressors like LZMA, with NNCP taking about 12 times as long as PAC and PAC taking about 127 times as long as LZMA.

What’s next?

I know you all immediately wondered, better compression?. We’re already working on that. And parallel encoding/decoding, too! Just like this update, we want to make sure we do it right.

We expect the next PNG update (Fourth Edition) to be short. It will improve HDR & Standard Dynamic Range (SDR) interoperability. While we work on that, we’ll be researching compression updates for PNG Fifth Edition.

One thing I’d like to see from image formats and libraries is better support for very high resolution images. Like, images where you’re zooming into and out of a very large, high-resolution image and probably only looking at a small part of the image at any given point.

I was playing around with some high resolution images a bit back, and I was quite surprised to find how poor the situation is. Try viewing a very high resolution PNG in your favorite image-viewing program, and it’ll probably choke.

• At least on Linux, it looks like the standard native image viewers don’t do a great job here, and as best I can tell, the norm is to use web-based viewers. These deal with poor image format support support for high resolutions by generating versions of the image at multiple pre-scaled levels and then slicing the image into tiles, saving each tile as a separate image, so that a web browser just pulls down a handful of appropriate tiles from a web server. Viewers and library APIs need to be able to work with the image without having to decode the whole image.

  gliv used to do very smooth GPU-accelerated panning and zooming — I’d like to be able to do the same for very high-resolution images, decoding and loading visible data into video memory as required.

• The only image format I could find that seemed to do reasonably well was pyramidal TIFF.

I would guess that better parallel encoding and decoding support is likely associated with solving this, since limiting the portion of the image that one needs to decode is probably necessary both for parallel decoding and for efficient high-resolution processing.

WebP had been kind of moving in on its turf, based on what I’ve been seeing websites using.

GNU cat

You mean GNU cat?

There are ISO country codes.

https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes

It’d theoretically be possible to run a straight GNU/Linux tablet or laptop

“GNU/Linux” is the full way to say what sometimes gets shortened to “Linux” — a family of operating systems based on the Linux kernel and a lot of software from the GNU project. This explicitly distinguishes it from Android, which also used the Linux kernel.

The former is not, in 2025, typically used to run smartphones. The latter is the most-common smartphone operating system in the world. If you buy a smartphone that isn’t an Apple smartphone, it almost certainly runs Android.

with a 5G cell modem for data

5G is the current generation of cell phone radio protocols. Communicating directly via voice over this protocol is not something that I believe is available to GNU/Linux in 2025. However, it can send non-voice data.

, use SIP service

SIP is a protocol for running voice over a data connection to the Internet. If you have an Internet connection, you can use SIP. There are companies, SIP service providers, which will, for a fee, provide a phone number at which one may be called or call others from a computer that can make use of SIP.

and a GNU/Linux dialer,

A dialer is the piece of software that on a smartphone, a user would probably call something like “the phone app”.

and then run Waydroid for any specific Android apps that one has to run.

Waydroid is a piece of software to run Android apps on a GNU/Linux system.

Idle power usage is gonna be a lot higher than on a phone, though.

Phone hardware and software has had a lot of work put into optimizing it for very low power usage. A larger device, like a laptop or tablet, will probably also have a larger battery, but it will consume more power as well.

And a lot of Android apps are made with a touch interface

Smartphones, due to physical space constraints in one’s pocket, typically have an entire side be a touchscreen. They do not have a keyboard. In general, software optimized for this works somewhat differently from software optimized for use with a keyboard and mouse.

Most GNU/Linux software is written with the intent that it be used on a system that almost certainly has a mouse and keyboard available. Most Android software is written with the intent that it be used on a system with a touchscreen available.

This means that even if one can run GNU/Linux software on a phone, much of the (large) collection of GNU/Linux software available will not be designed with an interface ideal for use on a phone.

and small screen in mind and are aware of things in a cell environment, like “only update X when on WiFi”. Not really common for GNU/Linux software to do that.

Smartphones have two widely-used mechanisms of accessing the Internet — connecting to the often slower cell network, or to a much-shorter range, but faster, WiFi network. Many people connect their smartphone to a WiFi network at some times and a cell network at others. Because this is so common, a lot of Android software has behavior designed to support this and act more-appropriately, like having an option to only transfer lots of data when on a WiFi netwprk. This is not the case for most GNU/Linux software.

I’m talking about stuff like pulling down new podcast episodes and such.

I dunno, man.

Android and all its apps have had a lot of work done on keeping stuff low-power.

The GNU/Linux laptop I’m currently typing this on is drawing about 10W (granted, with the screen on, which is larger). The Android phone in my pocket is drawing (checks) a little under half a watt.

Granted, I didn’t choose the laptop hardware to try to minimize power usage; you can certainly get laptops that will draw less. But there have been a lot of engineers banging on Android power usage for a long time.

And stuff like auto-suspension of background apps using CPU time and stuff doesn’t have a GNU/Linux analog that I’m aware of.

There’s a GNU/Linux phones community here on the Threadiverse at !linuxphones@lemmy.ca. Even the phones they talk about there — where the hardware is much less powerful than typical current Android hardware — don’t have amazing battery life as phones go.