Right, but if you don’t already know what those arguments mean, then its not exactly super obvious as to what they do.
For example, I’ve been told that you’re generally not supposed to do pacman -Syyu because it can result in partial upgrades (unless I’m remembering the wrong set/combination of flags, which would just be case in point…) - I tend to remember flags by associating them with words.
For example, the common flags for tar was brought up in one of the sibling comments here, but at least I can remember them by:
x: eXtract
z: Use gzip for the operation (which originally I remembered as “the file has .gz” in its extension before I knew what gzip was)
v: verbose, giving the details about what its doing
f: file, the file name you’re wanting to work with
c: create archive
t: test archive (I use this with the v flag to see what is in an archive before extracting it)
But with Pacman, even after using it on and off for a couple of years, I can try to estimate what the flag names are, but have no idea if its right without double checking:
S: Sync with repositories
s: No idea on this one
y: Also no idea on this one
Q: Query (search)
u: Allow upgrades (?)
Really I think its the fact that some of the flags can be used in different combinations which have different effects - like passing z to tar doesn’t change the effect of the flag whether you use x or c. Yet apparently -Syyu and -Syu are valid but one does a proper supported upgrade, and one does a partial upgrade which is not supported and is generally not recommended unless you know what you’re doing. I also know of no occasion where passing the same flag to tar multiple times mutates its behavior as well.
That makes it feel like an anti-pattern to me, similar to using magic numbers in programming. Maybe there is a valid reason for this decision (such as why the Linux kernel uses magic numbers in syscalls) but the result is still that it feels incredibly foreign to me, despite having 10 odd years of Linux experience under my belt.
I agree with that. My reply was to illustrate how cryptic sometimes the most common pacman commands are, and you have to refer to both –help and man pacman, though I find it easier to go to Arch Wiki or Google it generally. The tar flags are great! Pacman can be a bit confusing.
s is for search, I believe. When you add the S flag, so it becomes pacman -Ss, it synchronises the package database and search within that database.
y is refreshing local database or something like that? If you put pacman -Syyu, it will force refresh the master package database so that it can deal with corrupted databases or something like that. Pacman seems advanced to me but I just don’t really remember / know my way around it that well.
Q is for searching local package database.
u is for system update, since it is preferable to rebuild the whole package database in your system to synchronise against the database containing the latest packages.
I hope I’m somewhat correct. There are other flags but I don’t remember them. It is elegant if you already are familiar with the commands, but otherwise, other package managers and program commands like tar are much easier since they contain English language imperatives.
As for the magic numbers, that’s the first time I knew of that concept. Quickly looking at Wikipedia seems to suggest that there probably are accepted use cases, though that might be historical and not entirely logical.
Really, sometimes computers can be a mess, we’re just used to that mess.
Those definitions of pacman’s flags sounds correct to me, at least when I correlate them to my (admittedly rough) memory of using them in the past. I generally ended up using yay for handling both Arch and AUR package management, but I did most of my package searching via DDG’s !arch and !aur “bangs” to look at it on the web (or just yay likely-the-package-name) which explains my lapse in the Q/s flags.
As for the magic numbers, that’s the first time I knew of that concept. Quickly looking at Wikipedia seems to suggest that there probably are accepted use cases, though that might be historical and not entirely logical.
I won’t pretend like I’ve seen every possible API out there, but the only time that I personally know the use of magic numbers made sense from a developer standpoint was in Linux’s reboot system call which this question/answer does a good job of explaining the reasoning behind it but the quick rundown is that its a safety feature; A bit-flip could inadvertently trigger the reboot system call to be ran instead of something like say exec() which you definitely wouldn’t want to have done on your PC while you’re working (or even worse, something like a web server) . The magic numbers are required for the reboot system call to eliminate this possibility because its practically impossible to inadvertently pass in the exact correct numbers for the reboot syscall to another one in the same way that its unlikely you’d accidentally unlock the guard to a fire alarm and pull the trigger by just brushing up against it.
(Okay, maybe that rundown wasn’t quicker than the answer on stack-exchange… oops)
I suspect any other use cases for magic numbers are very similar to this (a safety precaution against accidentally calling a destructive API) or some silly (and weak) “security through obscurity” type of principal. Somehow I doubt the “magic arguments” for pacman are for either though 😅
Really, sometimes computers can be a mess, we’re just used to that mess.
Oh yes for sure, computers are quite the double edged sword - vastly handy and important tools but also a royal pain in the ass way too often…
That makes sense about the magic numbers! Though I suspect that that isn’t the case for pacman’s commands. This might be totally false but Arch is designed with simplicity and elegance in mind, and so short single letter commands to manage your entire system is preferred.
Just out of curiosity, are you a developer or sysadmin?
Just out of curiosity, are you a developer or sysadmin?
Somewhat both! Most of my background is software development, but I always felt it was important to have decent sysadmin skills so that I’d be able to fully understand the requirements of something that I could be in charge of developing (or at least, helping develop).
This idea was further cemented when I started hearing more and more cases of professional sysadmins having a disdain for developers not understanding things like DNS. And to be fair, I think the reverse is important too - that sysadmins should have at least some knowledge of the development world. At the end of the day, usually both roles have to coexist with each other in a symbiotic relationship of sorts or else it doesn’t work. If you don’t have people to make an application, then you have nothing to deploy - but if you have no one to deploy and maintain the environment an application runs in, there’s no point in creating it. It makes me sad to see that even to this day there still tends to be an “us vs them” mentality from both sides, but I guess that’s just humanity in general…
Funnily enough, at my current job my roles are the opposite - I primarily do a lot of system administration, but every now and then I do some of the development at my job as well.
It worked out though, because it got me more into the sysadmin side of things and I try to strengthen my knowledge of systems administration even in my personal time - that’s one of the reasons why I’m hosting the instance I’m commenting from 😁
Probably a longer answer than you were looking for, but there you have it!
Ah I see! So you were/are both, that’s why you can understand both perspectives. I see, you’re your instance’s host! Nah, thank you for sharing! I’m quite new to the free/open-source software and Linux world, and this meme sort of sums up my feelings about the different Linux distributions. I guess I’m still in that infatuation phase where I think of distros as cool and looking at new cool stuff and projects. I’m not a technical person, so this is a total noob’s perspective.
I guess I’m still in that infatuation phase where I think of distros as cool and looking at new cool stuff and projects.
To be honest, I don’t think I ever left this phase ahaha. I’ve been using Linux for quite a while now, about 10ish years on and off (definitely more the “on” over the last 4 years) and I still find it really cool to switch distros whenever I find something that looks neat/different. Right now I’m trying out Fedora Kinoite (An “immutable” version of Fedora’s KDE spin), but when the new “Orchid” release of Vanilla OS comes out I have a good feeling I’ll be switching again to try that one out!
I’m not a technical person, so this is a total noob’s perspective.
Well I think you’re selling yourself short here (checkout imposter syndrome which is very common in the tech field), you could’ve certainly fooled me! You had a really solid explanation of pacman’s arguments, and being able to explain them (rather than just memorizing “I use this combination in order to do X”, if that makes sense) is part of what makes someone stand out as more of an intermediate level rather than a beginner level in my opinion!
I have a good feeling I’ll be switching again to try that one out!
Ah, the eternal distro hopping. I can relate. Frankly, I do think that Vanilla OS and even something like NixOS are genuinely exciting development in the world of Linux distributions. I’m unfamiliar with Fedora Kinoite, but skimming thorough its page, it looks really good! In general, I do like this side of things where Linux distributions tend to focus on being “universal” and “reliable”, even if it means fundamentally pushing forward and away from the traditional this-distro-does-this-uniquely-and-manage-packages-like-this thing. I’m not super well versed in Vanilla OS but I did watch The Linux Experiment’s video on it. I believe that it is immutable and installing packages through GNOME software defaults to the Flatpak format. Another thing is that you can create/launch containerised systems inside your OS, perhaps for developers or tinkerers who want to mess with different OSes.
NixOS on the other hand, well I think it’s a package manager as well as a distro (?), and it basically builds packages in containers or in isolation of some sort. I do like this philosophy of containerising things to manage them by themselves individually (I think? sorta like Flatpak?), and NixOS also makes it immediately reproducible by its declarative system management. I think this sort of development is really good since it is a battle against the naturally occurring fragmentation in the Linux environment. Perhaps, there will be less “apt snap pacman yay zypper dnf yum emerge etc”, since the method of having unique repos for each distro can be a bit annoying and time-consuming for the overall Linux and open-source ecosystem, though I think it’s okay for the most part. Making the fundamental design and maintenance of the systems and packages modular is really great, since we’ll have better hardware and software in the future. It is pretty exciting, for me at least.
Well I think you’re selling yourself short here
Haha I’m flattered, thank you! I promise you I absolutely suck at all in these things, I just have some really minor interest in *-nix stuff. I’m not in the tech field (at least not right now), I’m just a postgraduate student studying solar cells. I used MX Linux for about a year during my final year of bachelor’s degree, and right now I’m toying around with Arch. I’m that new kid interested in Linux, you know? I think in general I’m more interested in the free / open-source software (FOSS) world. Throughout several years, I played around with Ubuntu/Lubuntu, Mint, Fedora, openSUSE, Debian, even tried FreeBSD, and experimented just a tad bit with Alpine. Read about UNIX, GNU, Linux, FOSS stuff, and then OS, software, programming, web, technology stuff. Then I just have my own setup using almost entirely FOSS for personal use (mostly browsing, writing, learning programming, and some light retro gaming for leisure), and also for academic work (LaTeX, Zotero, Taguette, just a little bit of Python). I’m also using Vim. Again, I’m that excited kid, ya know? Anyway, I’m just a science student, but only now getting quite interested in Linux, computers and software in general. No experience in the tech field at all. Thank you though!
NixOS is really cool! I’ve actually tried it out a couple of times, and I find the premise of a completely reproducible system to be incredibly intriguing. In the time that I’ve tried it, I’ve found that it strays a bit too close to the “The way this system is designed is getting in the way of the things I want or need to do with my PC” - but it will up there on the distros to circle back to every now and then to see if things change.
You’re correct that Nix is a few different things, it’s a language (the Nix language), a package manager (Nix as a package manager), and then finally a distro as well (NixOS) - when running NixOS you get the benefits of all of them wrapped up in a convenient package so that your whole system can be managed in a declarative way (even down to your home folder / “dot files” if you use Home Manager - which technically also works outside of NixOS too).
Your knowledge of the FOSS world is stellar, even if you’re not in the tech field - keep up the great work because I can tell you’ve got some wonderful adventures ahead of you!
Right, but if you don’t already know what those arguments mean, then its not exactly super obvious as to what they do.
For example, I’ve been told that you’re generally not supposed to do
pacman -Syyubecause it can result in partial upgrades (unless I’m remembering the wrong set/combination of flags, which would just be case in point…) - I tend to remember flags by associating them with words.For example, the common flags for
tarwas brought up in one of the sibling comments here, but at least I can remember them by:gzipfor the operation (which originally I remembered as “the file has .gz” in its extension before I knew whatgzipwas)vflag to see what is in an archive before extracting it)But with Pacman, even after using it on and off for a couple of years, I can try to estimate what the flag names are, but have no idea if its right without double checking:
Really I think its the fact that some of the flags can be used in different combinations which have different effects - like passing
ztotardoesn’t change the effect of the flag whether you usexorc. Yet apparently-Syyuand-Syuare valid but one does a proper supported upgrade, and one does a partial upgrade which is not supported and is generally not recommended unless you know what you’re doing. I also know of no occasion where passing the same flag totarmultiple times mutates its behavior as well.That makes it feel like an anti-pattern to me, similar to using magic numbers in programming. Maybe there is a valid reason for this decision (such as why the Linux kernel uses magic numbers in syscalls) but the result is still that it feels incredibly foreign to me, despite having 10 odd years of Linux experience under my belt.
I agree with that. My reply was to illustrate how cryptic sometimes the most common pacman commands are, and you have to refer to both –help and man pacman, though I find it easier to go to Arch Wiki or Google it generally. The tar flags are great! Pacman can be a bit confusing.
I hope I’m somewhat correct. There are other flags but I don’t remember them. It is elegant if you already are familiar with the commands, but otherwise, other package managers and program commands like tar are much easier since they contain English language imperatives.
As for the magic numbers, that’s the first time I knew of that concept. Quickly looking at Wikipedia seems to suggest that there probably are accepted use cases, though that might be historical and not entirely logical.
Really, sometimes computers can be a mess, we’re just used to that mess.
Those definitions of pacman’s flags sounds correct to me, at least when I correlate them to my (admittedly rough) memory of using them in the past. I generally ended up using
yayfor handling both Arch and AUR package management, but I did most of my package searching via DDG’s!archand!aur“bangs” to look at it on the web (or justyay likely-the-package-name) which explains my lapse in the Q/s flags.I won’t pretend like I’ve seen every possible API out there, but the only time that I personally know the use of magic numbers made sense from a developer standpoint was in Linux’s reboot system call which this question/answer does a good job of explaining the reasoning behind it but the quick rundown is that its a safety feature; A bit-flip could inadvertently trigger the reboot system call to be ran instead of something like say
exec()which you definitely wouldn’t want to have done on your PC while you’re working (or even worse, something like a web server) . The magic numbers are required for the reboot system call to eliminate this possibility because its practically impossible to inadvertently pass in the exact correct numbers for the reboot syscall to another one in the same way that its unlikely you’d accidentally unlock the guard to a fire alarm and pull the trigger by just brushing up against it.(Okay, maybe that rundown wasn’t quicker than the answer on stack-exchange… oops)
I suspect any other use cases for magic numbers are very similar to this (a safety precaution against accidentally calling a destructive API) or some silly (and weak) “security through obscurity” type of principal. Somehow I doubt the “magic arguments” for pacman are for either though 😅
Oh yes for sure, computers are quite the double edged sword - vastly handy and important tools but also a royal pain in the ass way too often…
That makes sense about the magic numbers! Though I suspect that that isn’t the case for pacman’s commands. This might be totally false but Arch is designed with simplicity and elegance in mind, and so short single letter commands to manage your entire system is preferred.
Just out of curiosity, are you a developer or sysadmin?
Somewhat both! Most of my background is software development, but I always felt it was important to have decent sysadmin skills so that I’d be able to fully understand the requirements of something that I could be in charge of developing (or at least, helping develop).
This idea was further cemented when I started hearing more and more cases of professional sysadmins having a disdain for developers not understanding things like DNS. And to be fair, I think the reverse is important too - that sysadmins should have at least some knowledge of the development world. At the end of the day, usually both roles have to coexist with each other in a symbiotic relationship of sorts or else it doesn’t work. If you don’t have people to make an application, then you have nothing to deploy - but if you have no one to deploy and maintain the environment an application runs in, there’s no point in creating it. It makes me sad to see that even to this day there still tends to be an “us vs them” mentality from both sides, but I guess that’s just humanity in general…
Funnily enough, at my current job my roles are the opposite - I primarily do a lot of system administration, but every now and then I do some of the development at my job as well.
It worked out though, because it got me more into the sysadmin side of things and I try to strengthen my knowledge of systems administration even in my personal time - that’s one of the reasons why I’m hosting the instance I’m commenting from 😁
Probably a longer answer than you were looking for, but there you have it!
Ah I see! So you were/are both, that’s why you can understand both perspectives. I see, you’re your instance’s host! Nah, thank you for sharing! I’m quite new to the free/open-source software and Linux world, and this meme sort of sums up my feelings about the different Linux distributions. I guess I’m still in that infatuation phase where I think of distros as cool and looking at new cool stuff and projects. I’m not a technical person, so this is a total noob’s perspective.
To be honest, I don’t think I ever left this phase ahaha. I’ve been using Linux for quite a while now, about 10ish years on and off (definitely more the “on” over the last 4 years) and I still find it really cool to switch distros whenever I find something that looks neat/different. Right now I’m trying out Fedora Kinoite (An “immutable” version of Fedora’s KDE spin), but when the new “Orchid” release of Vanilla OS comes out I have a good feeling I’ll be switching again to try that one out!
Well I think you’re selling yourself short here (checkout imposter syndrome which is very common in the tech field), you could’ve certainly fooled me! You had a really solid explanation of pacman’s arguments, and being able to explain them (rather than just memorizing “I use this combination in order to do X”, if that makes sense) is part of what makes someone stand out as more of an intermediate level rather than a beginner level in my opinion!
Ah, the eternal distro hopping. I can relate. Frankly, I do think that Vanilla OS and even something like NixOS are genuinely exciting development in the world of Linux distributions. I’m unfamiliar with Fedora Kinoite, but skimming thorough its page, it looks really good! In general, I do like this side of things where Linux distributions tend to focus on being “universal” and “reliable”, even if it means fundamentally pushing forward and away from the traditional this-distro-does-this-uniquely-and-manage-packages-like-this thing. I’m not super well versed in Vanilla OS but I did watch The Linux Experiment’s video on it. I believe that it is immutable and installing packages through GNOME software defaults to the Flatpak format. Another thing is that you can create/launch containerised systems inside your OS, perhaps for developers or tinkerers who want to mess with different OSes.
NixOS on the other hand, well I think it’s a package manager as well as a distro (?), and it basically builds packages in containers or in isolation of some sort. I do like this philosophy of containerising things to manage them by themselves individually (I think? sorta like Flatpak?), and NixOS also makes it immediately reproducible by its declarative system management. I think this sort of development is really good since it is a battle against the naturally occurring fragmentation in the Linux environment. Perhaps, there will be less “apt snap pacman yay zypper dnf yum emerge etc”, since the method of having unique repos for each distro can be a bit annoying and time-consuming for the overall Linux and open-source ecosystem, though I think it’s okay for the most part. Making the fundamental design and maintenance of the systems and packages modular is really great, since we’ll have better hardware and software in the future. It is pretty exciting, for me at least.
Haha I’m flattered, thank you! I promise you I absolutely suck at all in these things, I just have some really minor interest in *-nix stuff. I’m not in the tech field (at least not right now), I’m just a postgraduate student studying solar cells. I used MX Linux for about a year during my final year of bachelor’s degree, and right now I’m toying around with Arch. I’m that new kid interested in Linux, you know? I think in general I’m more interested in the free / open-source software (FOSS) world. Throughout several years, I played around with Ubuntu/Lubuntu, Mint, Fedora, openSUSE, Debian, even tried FreeBSD, and experimented just a tad bit with Alpine. Read about UNIX, GNU, Linux, FOSS stuff, and then OS, software, programming, web, technology stuff. Then I just have my own setup using almost entirely FOSS for personal use (mostly browsing, writing, learning programming, and some light retro gaming for leisure), and also for academic work (LaTeX, Zotero, Taguette, just a little bit of Python). I’m also using Vim. Again, I’m that excited kid, ya know? Anyway, I’m just a science student, but only now getting quite interested in Linux, computers and software in general. No experience in the tech field at all. Thank you though!
NixOS is really cool! I’ve actually tried it out a couple of times, and I find the premise of a completely reproducible system to be incredibly intriguing. In the time that I’ve tried it, I’ve found that it strays a bit too close to the “The way this system is designed is getting in the way of the things I want or need to do with my PC” - but it will up there on the distros to circle back to every now and then to see if things change.
You’re correct that Nix is a few different things, it’s a language (the Nix language), a package manager (Nix as a package manager), and then finally a distro as well (NixOS) - when running NixOS you get the benefits of all of them wrapped up in a convenient package so that your whole system can be managed in a declarative way (even down to your home folder / “dot files” if you use Home Manager - which technically also works outside of NixOS too).
Your knowledge of the FOSS world is stellar, even if you’re not in the tech field - keep up the great work because I can tell you’ve got some wonderful adventures ahead of you!