I've noticed that when I switch virtual temrinal CTL F4 for example, it has this nice little diagram of the Artix 'A' and some stats on the machine and they are wrong. They have only half my ram.
neofetch when I run it by hand, however, is correct.
I guess the /etc/issue file was generated a long time ago (during the installation?) and was never updated after the amount of RAM changed.
so it is lieing to me :)
It is, Dave.
Put 'neofetch >| /etc/issue' in /etc/rc.local to have it updated at every boot or in a /etc/cron.hourly script if you like to have an
accuratish uptime.
This form of output redirection always rewrites existing file no matter how configured noclobber option.
OK - teach me something new. How do you do a no clobber option on a file other than chmod 000
I was interesing because I didn't use the bar and it said, despite using sudo, that I didn't have permision. I had to su - in to overide it. So there is some wrinkle in file permissions I failed to understand.
noclobber isn't a file permission, it's a shell option (see
man 1 set,
-C option). What you're experiencing isn't related to any permissions on the file itself, but to the fact that redirections like
> and
>> are done by the user's shell, before
sudo is executed. Since
sudo is an external command while the angled brackets are keywords, the latter get processed first.
For instance, despite echo running as root,
file is created under my user because it was created at the shell's permission level.
$ sudo echo > file
$ ls -la file
-rw-r--r-- 1 carlos carlos 1 abr 15 20:24 file
That's you you had to switch to
su, which gives you a root shell; with it, the redirections are done as root. Another way is to embed the redirection into a sh snippet that is then called with
sudo.
$ sudo sh -c 'echo > root_file'
Online guides tell you to
something | sudo tee root_file instead of just using the redirection operators for a similar reason:
tee runs as root, and then opens the file for writing.
As an s6 fan, I can't not mention one could use execline's chain-loading commands (which can replace shell operators) alongside
sudo:
$ sudo redirfd -w 1 root_file echo
Neofetch is discontinued. Fastfetch would be a better choice.
Optional dependencies for fastfetch
chafa: Image output as ascii art
dbus: Bluetooth, Player & Media detection [installed]
dconf: Needed for values that are only stored in DConf + Fallback for
GSettings [installed]
ddcutil: Brightness detection of external displays
directx-headers: GPU detection in WSL
glib2: Output for values that are only stored in GSettings [installed]
hwdata: GPU output [installed]
imagemagick: Image output using sixel or kitty graphics protocol [installed]
libdrm: Displays detection [installed]
libelf: st term font detection and fast path of systemd version detection
[installed]
libpulse: Sound detection [installed]
libxrandr: Multi monitor support [installed]
ocl-icd: OpenCL module [installed]
python: Needed for zsh and fish completions [installed]
vulkan-icd-loader: Vulkan module & fallback for GPU output [installed]
xfconf: Needed for XFWM theme and XFCE Terminal font [installed]
zlib: Faster image output when using kitty graphics protocol [installed]
That is NOT encouraging. There is NO REASON for all of this.
flatbush:[ruben]:~$ sudo pacman -S neofetch
warning: neofetch-7.1.0-2 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (1) neofetch-7.1.0-2
Total Download Size: 0.08 MiB
Total Installed Size: 0.33 MiB
Net Upgrade Size: 0.00 MiB
Yeah that is MUCH more sensible of a design. no depenecies
There is a reason. To add features. If those features are desired some would say it's folly to reinvent the wheel and completely replicate/rewrite the code needed to implement them, hence the dependancies. Some would disagree and prefer to have total control over the code used.
From what little I know about yourself, and your distrust of the progression of the the Linux ecosystem, I'd say stick with neofetch.
This is in no way intended as criticism .
There are no system characteristics that can't be read by either reading the proc directory or other system source.
There is no logical reason for this spaghetti dependency for a simple commandline program.
The emotional reason is because if you are Nat Freidman or Miguel de Icaza et al ... it is a hammer/nail problem. Everything is a dependency because if your a free desktop coder you learned all this dependency and you probably don't even know how to read proc files or the system libs. It is not just feature bloat... it is bad programming design being covered up as a "new" way to do it.
FWIW - and it is not worth all that much, where is it written that neofetch is discontinued. It seems active enough in the repo.
It is appreciated, but I am way past worrying about personal criticism. I stopped worrying about these things when I was targeted by a large group of people who wanted to kill me and my entire family for being Jewish. It was a sobering moment about the overall state of humanity. You merely have an opinion which I disagree with based on deep history and lifetime of learning about how to a execute technological problem to create a pretty picture on the boot up of a workstation. I would never hate you for your opinion. I do appreciate you being a gentleman about it.
Are you honestly comparing fastfetch's optional dependencies (most of which are already needed for a desktop anyway, and you've already got installed) with neofetch's mandatory dependencies?
fastfetch + yyjson is an order of magnitude smaller than neofetch + bash.
BTW, try looking into the dependencies of the programs neofetch calls sometime. You'll be horrified to find... fastfetch's optional dependencies.
...the very top of the upstream URL. Last commit was to bid farewell in 2024, and the second to last commit was 4 years prior.
https://github.com/dylanaraps/neofetch
Add 'easily' to that and you are right. Clearly the dependencies are achieving it programmatically.
IMHO not all dependencies are evil attempts to sully my system but I respect your right to disagree.
You don't know the meaning of "optional"?
Of course not. Being an absolutest is not just crazy but impedes real progress. Unix is designed to be built on dependencies, as is the C programming language. That doesn't change that KISS is not just a design choice, but a necessity to secure and efficient design. This is just a little program to make an informational ascii picture.
Good thing it just continues to work then...and it probably will long after I am dead. It does what it needs to do and is not broken. BTW - there is nothing wrong with shell scripts to do system tasks. They didn't bid farewell, BTW. They just locked it to read only and finished working on it.
You were just waiting and hoping for an argument of Javascript versus shell scripting. But you aren't going to get it from me.
My point was not that shell was the right or wrong language for a task, or that neofetch was broken (well, it's already broken for distros that changed logos or started development in the last four years, but that's not yet true for Artix anyway).
Just that claiming fastfetch adds needless dependencies is pretty narrow-minded. Fastfetch is a C program; using libraries directly makes far more sense in that context than using an external program (which, often, ends up calling the library, so in the end you didn't save a dependency). I'm sure you understand this, given your response to gripped.
For people who want a maintained shell fetch: the hyfetch package (despite the namesake script being in python) includes a script called neowofetch, which essentially a maintained fork of neofetch. If you really don't want to install python-setuptools (which is a common requirement for building AUR python packages anyway), or don't want to type two extra letters, download it directly from upstream here: https://raw.githubusercontent.com/hykilpikonna/hyfetch/refs/heads/master/neofetch.
Yep. With very few dependencies:
Depends On : glibc yyjson
But extra features over neofetch if you choose to install the the required libs and programs..
I like this methodology of programming. Where features I don't intend to use aren't all hard depends because the programmers couldn't be bothered to dynamically check if a library was available.
An instance which springs to mind was when powerdevil used to hard depend on networkmanager and you had to install a forked version from AUR which removed this and a few other hard depends if you didn't want the bloat. Having a power management tool depend on a particular network manager, when more than one is available and none generally necessary, was beyond dumb. powerdevil has since been fixed to avoid such nonsense.
A number of years ago suse had a hard dependency of postfix for cron. It made me crazy.... or was that sendmail.