Moving from Garuda

grimy1928

Hi there everyone I hope you’re all doing well. I’m new to big Linux and so far I love how stable and smooth it seems. I do have a couple of queries though if that is alright. Basically, I have moved from Garuda but there is a lot I miss. Is a lack of a custom update script like Garuda has ever any problem with manual intervention? And does anyone have any advice on setting some things up that are defaults on Garuda such as btrfs snapshots and fish shell etc? Would love to have an open conversation from those who have made the switch and what your experience has been with the different features and defaults and what you changed and configured. Thanks lots,
Adam

BIGBRUNO

I know little about Garuda, what is the advantage of the update script?

About btrfs with snapshots is already configured by default in BigLinux.

I don’t recommend Fish shell, we use Bash, most of BigLinux’s automations were done using Bash and there are some incompatibilities between it and Fish.

Anyway you can install Fish and change the konsole configuration to use Fish as default, so the system uses Bash by default, but your command line interface will be with Fish

grimy1928

BIGBRUNO Thank you for the reply sir. Essentially, the update script does a lot of things. It refreshes the mirror lists for example and applies hotfixes among other things like when there was that btrfs regression problem. It’s been very useful for me and I would struggle to do without it tbh.

Thanks for letting me know about btrfs is default. I had only run it in a live environment for a short time so couldn’t remember to be honest. And the kind old makes sense. Lots is done in bash but I prefer the fish shell for user interactions generally. I’m just trying to get an idea from previous Garuda users here what they may have done on top of their install to get some of the functionality and configurations that lots of us may leave behind when switching to big Linux. Btw, here is a link to the garuda update script on their wiki if you’re interested. I would love it if you guys implemented something similar as it’s one of the more unique parts of Garuda and really is a nice thing to have. Thanks again

grimy1928

https://wiki.garudalinux.org/en/garuda-update

BIGBRUNO

I downloaded Garuda and read the update script, at first I think that updating the system by pamac on BigLinux will have a similar result and with a more pleasant graphical display.

Locutus

BIGBRUNO I downloaded Garuda and read the update script, at first I think that updating the system by pamac on BigLinux will have a similar result and with a more pleasant graphical display.

Using psamac to do your updates is asking for trouble. It is one thing to use it to see what updates are out there, but using it to actually do your updates simply no. For some reason pamac doesn’t always find all updates, and it doesn’t always like to install items from the AUR. In the past I’ve seen pamac fail to install something from the AUR rather it be a update or simply something I selected to install, but launch Konsole and do it and it installs without issue.

grimy1928

Hm okay that’s a fair assumption I guess. Just a few thing’s different that I noticed such as no refreshing of the mirrorlist (afaik) and no implementation of hotfixes as the Garuda devs can push hotfixes through the update script to fix problems you have with pacman. However, I do not know how different something such as Paru may perform in comparison. Thanks for testing it out though as I do like the feature and would love something similar on every distribution I run but I know that’s asking a lot haha. Just would allow for the biglinux dev to have a bit a more control over things that might normally need manual intervention or when something needs a hotfix as explained earlier with the btrfs regression. Anyway though it’s just a small thing I guess although I consider it to have a major impact in tue longevity of the system. Thanks again!

grimy1928

Just to follow up on the points made, does Paru do any of the following? Because these are important tasks imo which are nice to automate after an update which pacman doesn’t do. Maybe Paru does although I’m not aware of that being a feature

“Common post-update tasks are executed. The mlocate database is updated, fish completions and micro plugins are updated.”

BIGBRUNO

The Paru that I know of does not make any of these interventions.

As for mirrors, we use CDN77’s repositories by default, for both Manjaro and BigLinux repositories, there are more than 80 mirrors around the world and CDN77 controls so that the packages are downloaded from the server that gives the most performance.

I did tests using my connection here in Brazil and also tests using some VPNs in the USA and Europe, in all places CDN77 had very good data traffic.

About hotfixes, the first point is that Garuda uses Arch repositories, which releases updates very frequently, in Manjaro there is already a package release process that takes much longer in testing.

And in BigLinux, you can check in pacman.conf the existence of the biglinux-update-stable repository, it is our hotfixes, the way pacman works is to give priority to the packages that are in the top entry of the .conf file, so if we need to add one modified package with a patch we use this repository. At the moment only the latte-dock package is coming from this repository.

We don’t have the mlocate update or the fish autocomplete, because by default we don’t use either of them.

About the micro plugins I have to look again and find out what it is.

Any functionality that brings improvements to BigLinux is welcome, I’m not opposed to the idea of making changes to the system.

grimy1928

BIGBRUNO BIGBRUNO BIGBRUNO Olay thank you for your thoughts on this. Yeah I didn’t think that Paru did any of this unfortunately.

Okay that sounds like a good option for mirrors. Generally people use something like reflector-simple which is able to refresh the mirorrlist. This is run when using the update script from Garuda.

Yes I understand that Garuda just uses Arch repositories with their own repository too just for a few things like specific software they have created.

Oh that’s definitely good to know that you have your hotfixes as a repository like that. I’m not sure how that may compare to Garuda, but with Garuda, I have had a notification from their system maintenance tool warning to apply a hotfix. So it seems they have the ability to push these to your system from a server without you needing to perform a system update. Shouldn’t be a big deal though as I update my system every time I turn on my laptop.

Oh you don’t make use of mlocate? I’m not too familiar with it to be honest but from what I understand it seems to be a useful tool for merging databases and keeping them up to date. Is there a reason for not using this or just because it hadn’t really been considered at any point? And with fish that makes sense as you don’t ship it by default so that’s fair enough. Maybe I can work out how to create my own systemctl service to update fish after an update or something for the meantime.

Micro plugins are basically any plugins used by the micro text editor. I’m not sure what text editor you guys use but micro is basically a newer and more functional nano which is why it is constantly replacing nano across many Linux distributions.

In regards to having an update script like Garuda, I really and truly believe that it would be very beneficial to the users of the system as it allows for so much more control. You can automate a lot of system tasks for example. You can also ensure that users update their systems properly by using this script. You can also do so much more by making use of if else statements. I think it would really improve the functionality of BigLinux by implementing something better than the basic Paru -Syu which doesn’t actually update everything or manage lots of tasks you would need to do manually. Because at the end of the day, users will have different software installed and configured which will become harder and harder to manage and to keep all the manual tasks up to date. With an update script you could have a check condition for certain installed software for example and what tasks to perform based on that. And honestly, I don’t think this would be too much hard work as I think you could adapt the existing script and make some changes based on repositories you have as opposed to what is present in Garuda. Hell, I’ll give it a go myself and if successful I’ll link my repository if you guys would like to give it a go. I’m very much a noob at coding however, so if you devs feel that there may be a benefit to using something like this as I do, then I hope you will consider looking into it. Here’s their update script code btw if you have any interest at all in adapting it. https://gitlab.com/garuda-linux/packages/stable-pkgbuilds/garuda-update

And btw, thank you for being so great with all the communication. I appreciate that you actually tried these things and tested some stuff out to see how it might be and how it might run. Really nice community so far it seems from a first glance which is great

BIGBRUNO

For the time being, we recommend updating the system using Pamac in graphical mode for most users, as it is used to update packages from the repositories, the AUR, Flatpak and Snap.

At some point we should use some update script, but we also have to think about including Flatpak and Snap.

Locutus

BIGBRUNO For the time being, we recommend updating the system using Pamac in graphical mode for most users, as it is used to update packages from the repositories, the AUR, Flatpak and Snap.

At some point we should use some update script, but we also have to think about including Flatpak and Snap.

Might want to have a look at topgrade and see if it will work for BigLinux or can at least be modified to work with BigLinux. In Garuda I run update which invokes garuda-update then when that is done I run topgrade which updates EVERYTHING else. In Arch and other Arch based distros I simply run topgrade.

Removido

Personally, my transition from Garuda to BigLinux has been great, I haven’t had any problems using Fish or Starship, and about snapshots I really only use the default one from BigLinux, and when I upgrade with significant changes I just do a manual snapshot and that’s it.

(I have to admit that I tried to configure Snapper but did not succeed, although I should try again.)

In terms of performance, BigLinux is much faster (in my case, with Nvidia GPU) than GarudaLinux, Garuda had the habit of lagging very easily (in X11), by simply putting a window with the sticky effect on one edge of the screen, the system was stuck for a second or two… Trying to solve this problem I came to nothing, deactivating effects, changing compositor, kernel, activating triple buffering and a thousand things more…

This is where BigLinux completely solved my performance problems (I have no idea how) that I had in Garuda, and even in pure Manjaro or Arch itself I suffered from that… In fact I had to migrate to Debian for a couple of months until I met BigLinux, which fixed all the problems I had, and now I can enjoy all the advantages of Arch, practically out-of-the-box, because I don’t need to apply many changes for those things that Garuda had, which I loved, to be adapted by BigLinux.

I also have to mention a single problem I had with BigLinux, and that is that one day I changed the default theme and used another one, and from that moment on it seems that all the performance improvements that are applied by default in BigLinux, were erased or something happened, because not even using Timeshift (which apparently did not save my files from the Home directory) or applying “Defaults” in the BigLinux control panel corrected this, I had to reinstall the OS completely to return that “improvement” in performance, because in fact I had the same problems as with Garuda. ..

Oh, and the BigLinux forums are God’s envoy for Arch newbies, they always try to help you and not only ask you for a complete log of your PC to tell you that your PC is too bad to run their OS, almost the same as Windows…

BIGBRUNO

Removido I’m glad BigLinux worked well on your computer, we are always trying to improve the system

It’s been 18 years of BigLinux and one thing I’ve learned is that no matter how much we know, there will always be many situations that we don’t have answers to, especially when it’s a hardware conflict, it’s often necessary to spend hours or days trying to find some configuration that make things work.

To have a more complete compatibility we maintain 3 isos with different versions of kernel and drivers table, this is not of today, in 2005 already had two different versions of kernel to maintain support to a larger amount of computers.

And it always depends a lot on users to find solutions and share, I have a desktop computer from 2014 and a laptop from 2013, it’s the hardware on which I do system tests, the other adjustments are made based on documentation and information brought by users that manage to solve problems and we will include them in BigLinux.

grimy1928

Removido

Removido Thank you for your reply! I’ve been really hoping to talk to someone who like me moved from Garuda as you will hopefully understand some of my questions moving. I have a few questions if that’s alright though.

First of all, I feel that BigLinux performs much better than Garuda. Like I love the performance so far I am experiencing. I’m not sure if this is due to the kernel being modified or if this is a system service not specifically tied to the kernel itself. Maybe @BIGBRUNO can give some clarification on this. I ask, because I always use a custom kernel such as Zen or Cacule or Bore, but I worry that if I do this then will performance benefits from BigLinux disappear? Or are these performance improvements not tied to the kernel meaning I can still boost performance using a more performance oriented kernel such as Bore?

Also, how have you found updating the system without the Garuda update script? And have you done any configuration such as copying over aliases from the fish config? I’m trying to get an understanding of how much work may be done as I love BigLinux but really want to customise it a bit like Garuda and their defaults but that may take some time. And have you tried wayland out of interest? Made me think about it as you mentioned your problems with Garuda on x11.

Also BIGBRUNO may I ask your thoughts on the ALHP repositories? It seems much more optimised and better performance than standard but just like using custom kernels, I’m not sure where your performance tweaks are set whether in optimised package installation or the kernel or some other form of system service. Clarification would be really useful if you don’t mind. Thanks lots

grimy1928

Removido oh btw I did get snapper setup without an issue so let me know if you need any help with that and I’ll be happy too

Removido

grimy1928 I usually update by simply pressing the small circular icon in the system tray that indicates how many pending updates there are, or I perform in the terminal a “Sudo pacman -Syu”, yes, on Fish, among other optional complementary commands to clean the system, which I remember that Garuda had a panel to do that automatically.

I have made some aliases settings in the Fish config to give it a more Garuda experience, so to speak, like changing the greeting message to “Neofetch”, replacing “ls” with “lsd -l” and adding “starship init fish | source” to make Starship work in the terminal.

I haven’t tried Wayland so far although I’m really interested in it, mainly because BigLinux has an easy way to do it!

BIGBRUNO

BigLinux uses the standard manjaro kernel, the difference in performance is all due to system configuration, both BTRFS and parameters that are in /usr/bin/startkde-biglinux and in /etc/sysctl.d and /etc/environment and /etc/default/grub

In addition, all the configuration of the system is thought to have good performance, for example, the theme of kwin, the configuration of the effects, the configuration of the included programs, mainly of the browsers.

I don’t think that changing the kernel to other versions will bring any really significant gains, ALHP is not compatible with Manjaro, but it also doesn’t seem to me that it’s a type of optimization that makes a big difference.

Anyway you can test other kernel versions, in our repository there are Xanmod and Liquorix kernel builds, you can also try to make your own builds.

For many years I was doing kernel compilations and I got very good results using the CFS and BFQ patches, but the kernel started to have much more efficient configuration options and the performance difference of versions considered optimized became very small and often even slower than the standard kernel.

An important point to remember is that the slowest part of the system is the one that usually slows down the entire system.

And the slowest part is almost always the storage device, which is why we spend a lot of time testing configurations for BTRFS, which are in /etc/fstab, /usr/bin/big-btrfs-balance and /etc/udev /rules.d/60-ioschedulers.rules

And to complete the BTRFS optimizations there’s this part that as far as I know no other distribution uses something like this: https://github.com/bigliux/disable-fsync

There are certainly more settings that bring performance gains, however, this is what I could remember

grimy1928

BIGBRUNO Thank you for the information. It is good to know what the default kernel is and what is making the performance as good as it is. Btw, when you say about the configuration of the included programs such as the browsers, are you talking about Brave Browser? And are you saying that it would run better than Microsoft Edge or Chrome for example because of its configurations or something you may have tweaked?

I did try changing the kernel and honestly it did make a big difference to me. I think that programs open and load faster and that the kernel really compliments your tweaks and configurations to allow for amazing performance. I would really recommend trying it via running “paru -G linux-bore linux-bore headers” or through yay. And then simply makepkg -sri and it will autodetect your CPU to optimise it during building. Wasn’t aware of ALHP not being compatible with Manjaro so thank you for telling me that. It did make some difference on Garuda with loading times of software like Dolphin for me etc.

Xanmod and Liquorix are good kernels but I prefer ones from the CachyOS team such as Cacule and as I said Bore. Definitely recommend trying it. For better performance in the future you might consider using something such as Zen as the default kernel? I mention that as Zen is considered very stable but better in performance than the standard kernel or the one Manjaro ships from experience. Bore is the best for me but it isn’t necessarily as stable so not worth shipping with imo.

Anyway it is very interesting to read some of the configurations you have made including disabling fsync. I am not sure it is a good idea due to the potential of data corruption if the system crashes or something weird happens but I’m all about performance so I went with that option as opposed to pattern and compatibility as ext4 is solid but I like my snapshots.

grimy1928

Removido Oh okay that makes sense. I try and make a habit of not updating by GUI like that though as it adds another variable to the update and can sometimes be buggy I have found as opposed to just running an update through terminal. I basically copy and pasted the Garuda fish config file over in its entirety and now it feels amazing. Even made a few of my own for completely removing software and dependencies as well as an rsync alias.

Wayland is amazing honestly, all you need to do is install plasma-wayland-session and logout and select from the dropdown menu wayland. Just be aware that it isn’t stable on Nvidia cards.

BIGBRUNO

grimy1928 About browsers, you can see in /usr/local/bin the scripts that add settings that improve their performance.

About the file corruption caused by fsync, don’t worry, the difference is precisely by deactivating it in the application layer using ld.preload and not through the configuration of the file system itself.

The file system itself continues with fsync as usual, just the commit at the application layer which disables the timeout in programs.

We have been using it for more than 1 year, with several tests disconnecting the computer directly from the socket and without any corruption, what can happen is to lose a few seconds, for example, save a file and in 5 seconds disconnect from the socket, it may be that when you turn on the computer that file has not actually been saved, but without file system corruptions. In /etc/fstab we are using the 10 second commit by default, so there is virtually no negative effect in disabling fsync at the application layer as it is done in BigLinux.

grimy1928

Oh and before I forget, I just wanted to follow up on the update script I mentioned previously that came from Garuda. I modified it so that it does not depend on the Chaotic AUR, and it no longer tries to add Garuda repositories which made it fail. It works exactly the same other than these changes though in that it will refresh the mirrorlist and then update the system and update plugins and other tasks you might do manually after an update. If you would like to try it, then download the garuda folder and place it in /usr/lib and download the two individual files and place them in /usr/bin. Then update your fish alias with this line:
alias upd /usr/bin/garuda-update

Have a great day guys! And below is the link to the folder and files if you would like to try it.

https://drive.google.com/drive/folders/1Yp1aZwmQSLEUSxBm05G4PAftttee3RPW?usp=sharing

Muttley

grimy1928 Hi there I recently installed BigLinux, could you please give me a guide how you do Snapper setup, on all my distros I tried I always do OpenSuse layout and snapper snapshots, like on Rosa Linux od Nobara?
I wanna set default snapshot like Suse do, but I do BTRFS Layout on system installation, on BigLinux I dont know how to do that. For other distros I mainly follow that guide and do some modifications so that I can set it up for distro specific setup.

Próxima página »