I had no idea ppl actually cared about any fetches, not like it stopped working though. Just a guess but it’ll work for a good while, because it’s a damn fetch script:D
I’ve been using a custom version of paleofetch for NixOS for a while, but I decided to write my own clone of neofetch in Rust when I heard about the archival just for fun.
It has (or I suppose will have) parity with everything neofetch can output, supports dynamic plugins, is super fast bc compiled, and looks up information using asynchronous fetches. It’s configurable via a config file (JSON) to choose what you want to show (I think this is better than using CLI options for this kind of app).
I have the app’s framework/architecture up and running, I just need to finish implementing the rest of the data lookup and add more distro logos.
Once I get the data lookup feature complete, I’ll make the repo public so people can add their distros’ logos and use it, but I’m treating this as more of a pet project, so I doubt people will be that interested in using/contributing since plenty of other fetch programs exist, so I don’t care if it lives or dies; it’s just fun to make things :)
Tenatively named fetch-rs, but I’m sure something like that already exists.
I tried fastfetch which was very fast, but didn’t work correctly for me. It told me I had 16 flatpaks installed, but I don’t even have flatpak! On another preset it gave the wrong number of pacman packages installed. The coloured bars also rendered with visible seams in between because it uses characters instead of colouring the background. It also didn’t show my terminal font at all. I can’t open issues because I didn’t bother to activate 2fa on my github account. I ended up writing a simple fetch for fun, it shows pacman and rust packages, learned a few things about terminal escape codes.
I guess that is pretty funny, didn’t notice it while writing lol. When it comes to those seams, I think it depends on your font whether it will have seams or not. Colouring the background is more consistent in my experience.
Why are everyone suddenly aware that Neochat is unmaintained. I mean, the last commit was 3 years ago and the last release alsmost 4 years ago. Just because the git repository got archived on a date does not mean that it was maintained up to that point.
Most people aren’t going around checking the commit history on every piece of software they use. The git repository being archived made the Linux news rounds, so now a bunch of people are newly aware. It’s not complicated.
I don’t get people being worried about an offline application designed to run one shot as the current user not receiving updates. I do get maintainers dropping the package from package repos now that it is officially archived though…
Yeah, but if it hasn’t reached that point then is it really dead?
Edit: Instead of downvoting me, consider this. What if the only update this program receives in years is one to make sure its still compatible with the libraries and APIs you refer to? Would that make it alive, or dead?
It seems like you guys are advocating for updating just for the sake of updating, also bandwagoning a bit.
Neofetch is literally a bash script. There aren’t any libraries or APIs it depends on, and there is basically no chance of it not working in the future. Some people just like to try and sound smart.
The actual problem with Neofetch is that it’s not being updated with new ASCII art for new distros, and not adding new options to show things like a line for display server or other things some people might be interested in. It’s just getting out of date in regular boring ways.
Uh huh. You think that some cloud computing processor just randomly can’t run a bash script? What, does the uname command not work on their processors or something? That would cause problems a lot worse than just Neofetch not working. I obviously don’t have one laying around to check, but I find that highly unlikely.
Systemctl edit: create an extension for the unit file and add some changes S edit --full: edit the full unit file (and timer too iirc) S enable --now: enable + start S disable --now: disable + stop
PCLinuxOS, an offshoot of Mandriva (itself the child of the Mandrake/Conectiva union, both a long derivative of RedHat), still avoids systemd to provide a distro with massive versatility and fast boots.
If you have a system with long-running leaky browser instances, Alt-SysRq-F is a lifesaver. It calls oom_kill, sacrificing one process to save the rest.
I do, and used it today as well. My AMD gpu sometimes when booting fails to set the correct resolution on the 3rd display, and that causes the graphical session to freeze for some reason and I have to force a restart with sysreq and start the graphical session with a weird script that sets a custom res lol.
This is somewhat related to the article but also a little off topic.
I started using Linux about 6 months ago now and I feel like it’s been a continual learning experience (in a positive way). I was comfortable enough with Windows that I was on autopilot with most things.
I’ve used systemctl previously but I love seeing articles like this, so freely available, where I have the chance to learn a lot more about my system.
Tangent over, just had this on my mind for a while and needed to share.
I agree - it can be overwhelming to constantly be reminded of areas in which one is lacking in knowledge (like when having to learn how to solve a relatively simple error), but the availability of learning resources really helps avoid demoralisation.
itsfoss.com
Newest