They updated the ride after the movies, so… It’s kind of circular at this point.

Raster images do not need to be rendered - see Rendering:

Rendering is the process of generating a photorealistic or non-photorealistic image from input data such as 3D models…Today, to “render” commonly means to generate an image or video from a precise description (often created by an artist) using a computer program.

Note that “render” is a fairly generic term, and it is sometimes used like “render to the screen,” to just mean to display something. Rasterisation may be a better term to use here, since it only applies to vector graphics, and is the part of the process I am referring to.

In any case, except for possibly reading fewer bytes from disk, the vector case includes all the same compute and memory cost as the raster image - it just has added overhead to compute the bitmap. On modern hardware, this doesn’t take terribly long, but it does mean we’re using more compute just to launch/load things.

It’s also worth noting apps have to ship higher resolution assets now, due to higher resolution displays. This can include video, audio, images, etc. Videos and images may be included at multiple resolutions, to account for different sized displays.

For images, many might assume vectors are the answer, but vectors have to be rendered at runtime, which increases startup time in the best case scenario, and isn’t even always supported on all platforms, meaning they have to be shipped alongside raster assets of a few different sizes, further increasing package bloat. And of course the code grows to add the logic to properly handle all the different asset types and sizes.

All this (packaging dependencies, plus assets/asset handling) to say it isn’t always malware, ads, electron, etc. Sometimes it’s just trying to make something that looks nice and runs well (enough) on any machine.

Many apps ship both vectors and raster images. It is worth nothing that vectors save space, but increase compute (the image now has to be rendered at runtime), contributing to slower startup times.

Worth noting is that “good” database design evolved over time (https://en.wikipedia.org/wiki/Database_normalization). If anything was setup pre-1970s, they wouldn’t have even had the conception of the normal forms used to cut down on data duplication. And even after they were defined, it would have been quite a while before the concepts trickled down from acedmemia to the engineers actually setting up the databases in production.

On top of that, name to SSN is a many-to-many relationship - a single person can legally change their name, and may have to apply for a new SSN (e.g. in the case of identity theft). So even in a well normalized database, when you query the data in a “useful” form (e.g. results include name and SSN), it’s probably going to appear as if there are multiple people using the same SSN, as well as multiple SSNs assigned to the same person.

I’ve personally lived in places where the closest convenience store was 2.25 km, and the grocery store was nearly 18km, as well as places where a convenience store was literally a part of my building, and grocery stores were walkable distances.

The U.S. is enormous and varied. Take a look at truesizeof and compare the U.S. and Europe (don’t forget to add Alaska and Hawaii - they won’t be included in the contiguous states). Consider how different London is from rural Romania.

Are they Bluetooth headphones? If so, check the protocols supported by your phone, and by the headphones, e.g. aptX vs LDAC vs SBC. It’s possible that it’s not a “downgrade” on the new phone, but rather an upgrade to a better protocol, but unfortunately not one compatible with your headphones, so you end up using a low quality fallback.

You may also want to check your settings, and see if you can select a specific protocol. Sometimes a lesser protocol is chosen by default, if the better protocol uses more battery. This may be available to you in the phone settings, or as an option in an app for the headphones (e.g. my Anker Soundcore app allows choosing between two protocols).

it doesn’t unravel the underlying complexity of what it does… these alternative syntaxes tend to make some easy cases easy, but they have no idea what to do with more complicated cases

This can be said of any higher-level language, or API. There is always a cost to abstraction. Binary -> Assembly -> C -> Python. As you go up that chain, many things get easier, but some things become impossible. You always have the option to drop down, though, and these regex tools are no different. Software development, sysops, devops, etc are full of compromises like this.

I think that applies to the others as well, except in some cases when they are tuned to the same fundamental, e.g. Bb Trumpet, BBb Tuba. But tubas commonly come in C, F, and Eb as well (trumpet variants also exist, but are less common).

Because of the rotary valves and trigger? Or for some other reason?

If that’s the only difference you’re calling out, it’s worth noting rotary valves and triggers show up on other instruments as well. In particular, tubas often have rotary valves, and it’s not uncommon to see trigger valves on trombones.

Having played both piston valves and rotary, the difference is negligible.

Not sure what landscape features you’re looking for, but I’ve been pretty happy with Voyager. I switched from liftoff/jerboa after lemmy.ml took the 0.19 update and they broke. It’s been good enough that I think even if the others hadn’t broken, I’d still choose Voyager over them.

grep -r string .

The flag should go before the pattern.

-r to search recursively, . refers to the current directory.

Why use . instead of *? Because on it’s own, * will (typically) not match hidden files. See the last paragraph of the ‘Origin’ section of: https://en.m.wikipedia.org/wiki/Glob_(programming). Technically your ls command (lacking the -a) flag would also skip hidden files, but since your comment mentions finding the string in ‘any files,’ I figured hidden files should also be covered (the find commands listed would also find the hidden files).

EDIT: Should have mentioned that -R is also recursive, but will follow symlinks, where -r will ignore them.

I would imagine the source for most projects is hosted on GitHub, or similar platforms? Perhaps you could consider forks, stars, and followers as “votes” and sort each sub category based on the votes. I would imagine that would be scriptable - the script could be included in the awesome list repo, and run periodically. It would be kind of interesting to tag “releases” and see how the sort order changes over time. If you wanted to get fancy, the sorting could probably happen as part of a CI task.

If workable, the obvious benefit is you don’t have to exclude anything for subjective reasons, but it’s easier for readers of the list to quickly find the “most used” options.

Just an idea off the top of my head. You may have already thought about it, and/or it may be full of holes.