Idk how versed you are on Bash Parameter Expansion or the find command, so I'd like to expand (pun intended) a little more on Jo Miran's explanation (if you already know, I'll leave this for others who may not):
find's -exec (and -execdir) option takes everything after it until a semicolon — which usually needs to be escaped, so the shell doesn't accidentally treat it as the command separator special character — as a command to run and arguments to pass to that command. Furthermore, when using the -exec option, find treats all instances of {} as places where it should substitute the files it matched
So breaking down -exec bash -c 'mv "$0" "${0/crunk/chunk}"' {} \; really just tells find to take the name of a file it found (in this example it would only match dir1/crunk) and put it after the command bash -c 'mv "$0" "${0/crunk/chunk}"'
So now the command to run looks like bash -c 'mv "$0" "${0/crunk/chunk}"' dir1/crunk
this command spawns a (sub)shell, bash, tells it to run the next argument as a command, -c, gives it that command to run, mv "$0" "${0/crunk/chunk}", and passes filename as an argument, dir1/crunk
So now let's talk shell parameters
Usually $0 is a special parameter that references the shell (or script) that invoked the command. In the case of using the -c option, bash actually changes $0 to be the argument after the command to run: dir1/crunk
So now the command looks more like
mv "dir1/crunk" "${0/crunk/chunk}"
So let's finally get to the finish line: shell parameter expansion. Shell parameters (aka shell variables) can be written with curly braces around the name, so $SHELL and ${SHELL} refer to the same thing. But the curly braces can also let the shell know that if it sees certain special characters after the variable's name, it should do some transformations to the contents of the variable.
In this case ${0/crunk/chunk} takes the contents of $0, searches for the first instance of the string ”crunk", and replaces it with "chunk" before inserting it into the command.
So now the final command to run looks like
mv "dir1/crunk" "dir1/chunk”
Also worth mentioning that the -name option of find accepts wildcards in its argument.
I would also recommend using the -execdir option instead of -exec in this specific case, because it will run commands from inside the directories where it finds the files. In this case, that means {} would expand to ./crunk instead of dir1/crunk; this will be relevant in about 3 paragraphs.
So now you can tweak the command to your needs. If you wanted to find more than one file that, for example, all had a "u" somewhere in the name, you could do so thusly
find dir1 -name ”*u*"
And then if you wanted to change the "r" in the filenames to "l", you could do:
Note that you could not do this with the regular -exec option, as it would try to mv dir1/crunk dil1/crunk and throw an error because that directory (dil1) likely doesn't exist... and even if it did, you don't want your command moving files to different directories without your knowledge
Notice that it also only changed the "r" in dir1 to an ”l”, and left the "r" in "crunk" alone? That's not a typo on my part, that's the intended behavior of Shell Parameter Expansion. If you wanted to replace all "r"s in filename, you would have to change the expression to ${0//r/l} (note the double slash)
Seriously, it's worth reading that page from gnu.org. Parameter expansion can get incredibly powerful, and it's much easier to use the right format (${VAR/%r/h}) than trying to combine the most simple ones to achieve the same goal (e.g. DO NOT DO THIS: ${${VAR//r/h}/h/r}; it won't even work as intended and it's unnecessarily complex to read)
Yes........ in my opinion. The real answer is that it depends on the intended use of the system and the users' needs. It's as legitimate to treat wheel as a catchall permissions group as it is to go around specifying permissions for specific users in your sudoers and udev rules
From my understanding, the kernel tends to reuse the same names when attaching devices, but it's not required to do so by the specs (i.e. there may be cases where the /dev file name changes depending on what you have plugged in). Hence why the common advice is to not specify /dev files in your fstab, and why people use udev rules instead of chmod and chown-ing the /dev files
I have a Lenovo Flex 2 15, which has an i3, 1080p display with intel graphics (although it's a 15" display) and upgraded to 16 GB of RAM
I use AntiX/MX Linux bc they're made with lower spec/older systems in mind. I started with AntiX-core to keep everything as lightweight (not a ton of background processes = low memory usage, low cpu usage) as possible
I use Sway bc 1. It's more lightweight than a full DE, and 2. Keyboard navigation is a must for laptops (trackpads only exist to inflict pain and misery on the world)
A couple great things about this setup is that it rarely overheats (as long as I keep it to a couple tasks at a time), and the battery can last for a 2 hours if I forget to plug it in
Even if you don't end up going with any of these suggestions, please take this to heart: never stop tweaking your system. You end up learning so much about it, and every little change makes it feel all that much more special to you
NAT stands for "Network Address Translation." The important idea is that when your guest machine (windows) tries to access the internet, it sends the traffic to your hypervisor (VirtualBox or qemu/kvm). Your hypervisor then passes it to your host OS, which changes the source IP address to its own, and changes the source port to one that will help it recognize traffic meant for the windows virtual machine. It then passes that traffic on to your router, which does a similar thing so that the broader internet can't just access any device on your home network willy-nilly. When the server your windows machine contacted responds, it addresses the traffic to your host machine's IP with the special port that lets your host know it's meant for the virtual machine.
To simplify this into an analogy with the postal service: 5 year old Billy (your windows VM) wants to write a letter to Ted (a server or device somewhere outside of your host machine). Billy writes his letter and addresses it to Ted, but in the return address field, he writes "Billy's Room." He then hands the letter to his mom (the host machine) to mail it for him; knowing that Ted probably doesn't know where the flying fuck "Billy's room" is, she quickly crosses it out and writes her home address. She then mails it. When Ted gets the letter, he responds and addresses it to Billy @ Billy's mom's house. She gets the letter, sees that it's addressed to Billy, and takes it to his room.
A bridge is a virtual interface that allows the virtual machine to send traffic directly to the hardware (networking card) without bothering the host machine. This allows it to get its own IP address on the local network, and for everything on that network it appears to be a separate machine from your host.
This is like if Ted and Billy get to writing letters all the time, and Billy's dad (you) realizes he can just set up a second mailbox outside the house for Billy and negotiate with the postal service so that the address on the mailbox is "Billy's room." Now Billy's mom never has to handle his mail or rewrite the addresses anymore, which is good, because Ted just mailed Billy a bomb (because no one, not even Billy, can know where Ted Kaczynski is).
"Can you make me download 150 MBs of .js files before I can read a single text-based article please?" - Software connoisseurs before AIs bloated everything
I realize this is the best option, since it centers my experience and needs better than anyone else's summary, but what to do if I don't have the time to daily drive enough init systems long enough to understand the scope and limitations of each?
E.g. Gentoo's wiki has a comparison chart of all the systems I'm aware of, but I don't know what some of the rows mean, so I would have to daily drive multiple types to get a feel for what it's like with and without those options and how that affects me as an end-user. It also doesn't include metrics that often get referenced but not quantified in the comparisons I find (stuff like boot times)
Furthermore, the only two times I've tried to switch out the init system on my PC, I've somehow managed to bork things so bad I had to do a fresh reinstall. Yes, I could do troubleshooting, but that's even more hours (or even days) of downtime up front.
All this to say: I'm just looking for a little bit of a shorcut to reduce the amount of documentation I have to read, and tweaking I'll end up doing.
On one hand, it's just a silly ad to get the point of "our medicine works so well that you can keep doing the thing that made you need it." But somewhere between the lines, there's the connotation of "sating your appetites matters more than your well-being."
You ever think it's wild how illness is our bodies way of letting us know that damage is being done internally, yet people are so inured to self-harm that they think it's a funny joke to regularly give themselves diarrhea?
When people say "AI," I assume they are talking about the large corporate Neural Networks that get branded as "AI" for marketing purposes.
I hate these because they're a grift. They're funded and maintained by a handful of ultra-rich idiots who saw no value in learning social sciences nor the humanities, and thus have failed to learn from history. The people pushing for mass adoption believe in a variety of unscientific pseudo-religious conspiracy beliefs about AI gods and devils leading humanity.
I hate that the cost of these cults are being foisted onto the rest of society by way of government and corporate contracts.
I hate that mass media is rapidly degrading in quality in order to justify the purchase of said contracts.
I hate that the people making important decisions that affect my life and well-being — doctors, the people who develop my software, my government representatives, news reporters, lawyers — are not just willing, but actively excited at the prospect of turning off their brains and letting black boxes controlled by opaque corporations make the decisions for them.
I hate that despite 3+ years of hype and 10+ years of public access, the only people who have demonstrably benefitted from it are Nvidia, scammers, and people who don't want to use their brain.
But mostly, and this is the clincher, I hate that we are literally destroying the earth to run these machines. Even if every other problem disappeared overnight, this should be an argument killer. We only get one home, and we are setting fire to it. I don't care if it improves the lives of millions of humans, because it is hastening the death of hundreds of billions of lifeforms.
I hate that people ignore this or conveniently forget it or are just apathetic about it. I hate that this argument just carries little to no weight for most fence-sitters. I hate that people treat feeling emotional about the destruction of our only home as being irrational. I hate ecoterrorism being excused by marketing babble and shitty faux-skeptical wishy-washiness.
Depends on how much privacy you need and how much tinkering to get things to work that you're willing to put up with.
In general, using a variety of services will be more private than going with a single entity like Proton.
Bitwarden is self-hostable, which makes it potentially more private than Protonpass... assuming you actually set up the self-hosting.
Signal isn't a good long-term plan, as it's entirely hosted in the US. I don't think there are currently any known compromises to the encryption model, but iirc the company can see all your communications metadata (which means the government could potentially as well). I don't mind it for talking with friends, but I would recommend against it for extreme privacy needs (e.g. the government starts getting overzealous with who it counts as enemies of the state, and you or your friends become targets).
At least some level of human review is going to be needed.
So... completely negating the point of a User Repository??? Introduce some kind of authoritative oversight, and it's essentially just another regular repository, erasing all the benefits of the AUR. The whole point of the distro slapping a huge disclaimer of "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." at the top of the homepage is because these kind of compromises are the trade-off one makes
Idk how versed you are on Bash Parameter Expansion or the
findcommand, so I'd like to expand (pun intended) a little more on Jo Miran's explanation (if you already know, I'll leave this for others who may not):find's-exec(and-execdir) option takes everything after it until a semicolon — which usually needs to be escaped, so the shell doesn't accidentally treat it as the command separator special character — as a command to run and arguments to pass to that command. Furthermore, when using the-execoption, find treats all instances of{}as places where it should substitute the files it matchedSo breaking down
-exec bash -c 'mv "$0" "${0/crunk/chunk}"' {} \;really just tellsfindto take the name of a file it found (in this example it would only matchdir1/crunk) and put it after the commandbash -c 'mv "$0" "${0/crunk/chunk}"'So now the command to run looks like
bash -c 'mv "$0" "${0/crunk/chunk}"' dir1/crunkthis command spawns a (sub)shell,
bash, tells it to run the next argument as a command,-c, gives it that command to run,mv "$0" "${0/crunk/chunk}", and passes filename as an argument,dir1/crunkSo now let's talk shell parameters
Usually
$0is a special parameter that references the shell (or script) that invoked the command. In the case of using the-coption, bash actually changes$0to be the argument after the command to run:dir1/crunkSo now the command looks more like
mv "dir1/crunk" "${0/crunk/chunk}"So let's finally get to the finish line: shell parameter expansion. Shell parameters (aka shell variables) can be written with curly braces around the name, so
$SHELLand${SHELL}refer to the same thing. But the curly braces can also let the shell know that if it sees certain special characters after the variable's name, it should do some transformations to the contents of the variable.In this case
${0/crunk/chunk}takes the contents of$0, searches for the first instance of the string ”crunk", and replaces it with "chunk" before inserting it into the command.So now the final command to run looks like
mv "dir1/crunk" "dir1/chunk”Also worth mentioning that the
-nameoption offindaccepts wildcards in its argument.I would also recommend using the
-execdiroption instead of-execin this specific case, because it will run commands from inside the directories where it finds the files. In this case, that means{}would expand to./crunkinstead ofdir1/crunk; this will be relevant in about 3 paragraphs.So now you can tweak the command to your needs. If you wanted to find more than one file that, for example, all had a "u" somewhere in the name, you could do so thusly
find dir1 -name ”*u*"And then if you wanted to change the "r" in the filenames to "l", you could do:
find dir1 -name "*u*" -type f -execdir bash -c 'mv "$0" "${0/r/l}"' {} \;Note that you could not do this with the regular
-execoption, as it would try tomv dir1/crunk dil1/crunkand throw an error because that directory (dil1) likely doesn't exist... and even if it did, you don't want your command moving files to different directories without your knowledgeNotice that it also only changed the "r" in
dir1to an ”l”, and left the "r" in "crunk" alone? That's not a typo on my part, that's the intended behavior of Shell Parameter Expansion. If you wanted to replace all "r"s in filename, you would have to change the expression to${0//r/l}(note the double slash)Seriously, it's worth reading that page from gnu.org. Parameter expansion can get incredibly powerful, and it's much easier to use the right format (
${VAR/%r/h}) than trying to combine the most simple ones to achieve the same goal (e.g. DO NOT DO THIS:${${VAR//r/h}/h/r}; it won't even work as intended and it's unnecessarily complex to read)