That would be giving into the Linux kernel and wayland driver bigots who set out to destroy NVidia on Linux, simply because of the driver's license. Linus, the kernel dev team, and wayland devs sought to break NVidia at every turn. A company that provided us with the best graphics cards on Linux for over a decade, because they couldn't get in and mess with NVidia's code and steal their secrets from their drivers. Don't give into to that level of zealotry. If anything, NVidia and their users should sue Linus and all the wayland devs for the years of crap they've pulled. All over a license. I love Linux, and am forever indebted to Linus for starting it... but this zealotry over licensing is why GNU never got off the ground itself; and they should be spanked for what they did to us. Wayland devs especially, they should be banned from opensource dev work forever and crippled financially for the crime they've committed.
I suspect you use them more extensively, than I. Mine are limited usually to the extended acls, which I then use getfacl to generate a dump of all the acls of the files and sub directories I am transferring or 7zipping, and include that file in the transfer or 7z bundle. Then use setfacl to apply all those permissions on the receiving end after everything has been copied or extracted.
I'd like a GUI app for generating CLI's for other GUI apps that don't have them already. An application is never complete unless everything can be done via a CLI and/or API.
man -k printf
Search the short descriptions and manual page names for the keyword
printf as regular expression. Print out any matches. Equivalent to
apropos printf.
From the system's DMI. You can check it yourself with dmidecode. Those values are largely unchangeable, and those that are, will probably require a tool from the vendor to change, which are usually for internal use only within their company.
I'm picturing Daffy Duck and Bugs Bunny swapping hunting signs on a tree... "Linux season!" "GNU season!", back and forth. The rest of us just watching like Elmer Fud.
Don't know about everyone else, but here are some of mine:
Stick to posix compliance shell code, wherever possible
Please wrap your variables with { }. Just please.
Global variables being exported in all caps
Local variables in lower case
$() instead of
Comment anything complicated, comment what section, comment usage
Include usage output if options are not recognized
Use case instead of if / elif, where possible
80 characters or less per line, where possible
HERE docs in designated section, marked by comment blocks
Comment your functions immediately above it's definition
Add comment "#End of function Xyz" at line immediately below a function, with replacing Xyz with name of that function
2 space indentation
Multi-line strings: First line open with quote and first line of string, followed by a backslash subsequent lines properly indented and backslashed. Last line, properly indented and close quoted.
Break up multiple piping of commands with |\ and a new line where it makes sense to look nice, assisting readability
Echo what the script is doing once in a while if the user will be waiting for a while
Please don't do shar archives, or byte located binary extractions, make a script and a separate tarball - Helps a ton if we have to change it, like say... swapping out a bundled java runtime built for x86_64 with one for aarch64
If the script will run for a very long time, check for tmux or screen and also the TMOUT variable... Give a warning to the user their connection might time out before the script is done if they don't unset TMOUT, and try using tmux or screen to allow the script to continue in the background, even if you do get disconnected
Make use of logger
I try to organize a script this way: 1. Shebang, 2. Initial variable definitions, 3. Functions, 4. runtime execution code, which might be best outside of a function, and calling functions. 5. Clean-up (remove pid and lock files, tmp files, etc etc.)
Books, periodicals, internet searches, practicing everything at home on a personal equipment until you've got it all mastered. If one can't learn that way, take courses. The way the rest of us did it. Once you've got that, you have the ability to learn anything new coming... and can hit internet forums with well formed questions, complete with context. Staying on nano/pico, there is just no excuse if you've already been heavily using linux for 3 years or more. It's an editor for those who are still in the beginning of the SELF learning phase. It should never be included in any distro's default install except for school classroom centered distros. Just because something is easy to use doesn't mean it's installed as a standard everywhere. Folks learning this as their craft need to learn how to sit in front of any Linux or Unix and use standard tools to achieve what they need to do. That means learn your Vi. Learn your Posix shells like Ksh, Bash, Zsh, Dash, not the nano of shells, fish! Learn your Python, your Perl. Learn your SysV 'isms in addition to your SystemD. Learn your csh (tcsh will do). Learn your terminal control codes. Learn your SysRq funtions. Learn your tmux, your gnu screen. Learn with and keep handy your books for awk, sed, patterns, perl. Learn your mkfs', the different filesystems and their benefits, their options and tools, how to resize. Learn your MD raid. Learn your LVM. Learn various encrypt at rest options. Learn containers. Study and remember the differences between gnu, bsd, and sysv tools like tar, cpio, find, and even ps. Books books books! Practice practice practice! Study study study!
And when you got that done, look up and see what you've missed while you were doing all that, and start in on all that new stuff. Wash, Rinse, Repeat. Never stop reading, studying, practicing, learning.
Could have been, if Linux kernel devs and wayland devs weren't trying to break it all the time.