You can profit from GPL software. The only restriction is if you distribute it you also need to distribute modifications under the GPL.
GPL also does nothing for software as a service since it is never distributed.
GPL even explicitly allows selling GPL software. This is effectively what redhat do. They just need to distribute the source to those that they sell it to.
There is also little reason not to try out different ones to compare if you want to. Nice to see what they are like for yourself if you have the time to.
I am not afraid of some tech journey, but even though arch seems the coolest, with Wayland, kde, hyperland customization, i am not confident enough to use it for work.
The only way you will gain confidence in it is to try it out. But also, most distros use wayland these days and it is more up to the desktop environment you use rather than the distro you use. hyperland is a wayland compositor and is in the repos of most if not all major distros. You should be able to install it on anything really. You can replace the desktop environment or install multiple ones side by side if you want to on just about any distro. The biggest difference between them is which ones they come with by default. But really if you are looking for a highly customized experience then Arch tends to be the way to do as you have less extra fluff you have to remove or work around when getting the system exactly as you want it. The hardest part of Arch is installing it the first time. Really after that it is not any harder to use or maintain. IMO it is easier to maintain as you have a much better understanding of how you set up your system as you are the one that set it up to start with.
I heard it can completely crash your system if your a noob.
You can break any distro if you mess with things. The only big difference is Arch encourages/requires more messing around at the start then other distros. And IMO is easier to fix if you do mess things up - you can always just boot a live USB and reinstall broken packages or reconfigure things without needing a full reinstall again. You can basically follow the install guides again for the bits that are broken to fix just about anything. And that is only if you break something critical in booting. In my early days I broke (requiring a full reinstall) way more ubuntu installs then I have ever broken my Arch ones later on. It is really just about how much you want to tinker with things and how much you know about what you are tinkering with as to if they will break or not rather then what base distro you use.
And you can always try the install process and play around with different distros in a VM to get a feel for them and learn what they are like. So don’t be afraid to try out various different ones and find the one you like the most. Your choice is never set in stone either. Just ensure you have good backups of everything you care about and the worst that will happen is you need to reinstall and restore your backups every once in a while.
but my main needs are not really discussed
…
So in essence i need something stable that is relatively easy to use and has great ue5 and gaming perf.
That is probably the most common set of requirements people ask for. In reality, with a few exceptions, there is really not that much difference between distros given those requirements. UE5 is newer so the biggest change there would be that you might find distros that ship newer versions of stuff might run it slightly better then distros that ship older software. In practice I think it has been out for long enough that you wont see much difference unless you want to play something new on the day of release (but these days those are all buggy messes anyway… not sure your choice of distro will make as big a difference as waiting a few weeks/months for the initial patches to rollout).
Remember, all distros are essentially based off the same software, the biggest difference being what desktop environment they ship with and what versions of software there ship (and how how long they stay on that version). By far the biggest difference you will see if what desktop environment they use and all distros essentially package the same set of desktop environments - each might come with different ones by default but they typically contain all the popular ones in their repos.
i need something stable… great gaming perf
In particular these two points. Do you know what you are asking for here? These are the most bland and wishy washy requirements. Everyone wants something stable and fast, never seen anyone ask for something that crashes all the time and is slow. But worst these tend to be on the opposite ends of the spectrum in terms of requirements, if you optimize for one you tend to trade off the other.
Even stability has multiple meanings. In terms of crash stability you will find all distros to be about the same. No one distro wants to ship buggy crashy software. But at times they do. And it is really just the luck of the draw as to when this might happen to you based on what software you use, how you configure your system and what hardware you have. Some combinations just don’t work for some weird reason and you wont know until you hit it. This is why you hear some people claim one distro is a buggy mess while some other one is rock solid while someone else argues the exact opposite. All main stream distros are just as good as any other in terms of this and you are just unlucky if you ever do run into that type of issue. The biggest problems in this regard tends to be when a new major version of something comes out - but like with gaming it can be beneficial to wait a few months for any issues to be patched before jumping to the latest big distro version.
The other side of stability is API stability - or the lack of things changing over time as new versions of stuff get released. There are two main types of distros in this regard, point release distros which freeze major versions of packages between their major releases so you wont get any new features during the release cycle that version of the distro. Then you have to deal with all the breaking changes from newer versions of software once every so often when a new distro version comes out. Vs rolling release distros that upgrade major versions constantly and so generally follow a lot closer to the latest versions of things than point release distros. Really the big trade off here is not if you encounter breaking changes.
Any distro will need to deal with them at some point, the choice is how often you deal with them. You can wait years on the same version of a point release distro and only need to deal with all the breaking changes once every few years, or once every 6 months. Or you can deal with things as they come out with a rolling release distro. But while it might sound nice to only deal with it every few years it also means you need to deal with all the changes at once. Which can be much more disruptive when you do decide to. Quite often I find the slower upgrading distros are better off with just a full reinstall on the latest version than upgrading from one to the next. Personally I prefer dealing with small things frequently as they tend to be easier to fix and less disruptive over longer periods of time. When I was running kubuntu I used to end up reinstalling it ever 6 months as the upgrades never worked for me (though this was a long time ago), but my oldest arch install lasted probably probably 5-10 years or so.
And at the same time how frequently you get the latest versions of things means you get any performance optimizations and support for newer hardware or newer games as well. But also any bugs or regressions. It is a double edged sword. Which is why stability and performance tend to be a leaver you can tune between rather than two separate things to can achieve. Just like overclocking, the more performance you can get out of a system tends to result in the system becoming less stable overall. Everyone wants the most stable and fastest system, but in reality everyone has a different limit on how much or what types of stability they are willing to give up on to achieve different levels of performance.
But out the box, you will find most distros to be very much within a couple of % of each other and which is fastest will vary depending on which games you want to play and what hardware you have. But they all tend to have quite a bit of head room to optimizes for specific use cases as they all are optimizing for the general use case which is typically just trading off performance in one thing for another. But again, we are talking about tiny difference overall.
There is not really one best distro out there - or else there would only be one distro. But for someone new you will find basically any mainstream/popular distro good enough for your usecase. The best one for you will come down to personal preference and will likely - at least at the start - be centered on which desktop environment you like the most. KDE will probably feel more like Windows. Though gnome I think tends to be the default on most distros. You will find popular distros have multiple flavors with various desktop environments as well. Your best bet is to download a few and put them on a usb and try them out before installing. That will give you a better idea of what you want.Or just pick one and go for it if you don’t care that much - it will probably be good enough.
From what I can tell xbps-src are just the source packages to the main repos in Void. That is not what AUR is. We have access to the main repo sources in Arch just like Void. The main thing about AUR is anyone can contribute without any gated approvals. That is the big difference between the main source repos of either distro and AUR. Unless I have misunderstood what xbps is.
but looking at templates they can actually understand its kinda simple script and get the idea of how it works
Same exact idea with PKGBUILDs. No benefit to Void here. The way Void does things will not change people looking at or understanding the packages they install. You have the same optitunities on both systems for looking at the source of packages. So that argument for Void is void :)
Also void has runit so this mean u have to get more simple programs to run system like seatd dbus and etc.
Not really a good argument either. Systemd and runit are different but that doesn’t make runit better in terms of learning anything. If you want to learn how most Linux systems boot and operate you need to learn systemd as that is what the vast majority of distros use. Learning runit instead only means you are learning a niche way of booting a tiny fraction of systems.
Neither of these arguments are a very strong case for Void over arch.
XBPS-SRC does not look like an alternative to AUR at all. It looks like Voids alternative to https://gitlab.archlinux.org/archlinux/packaging/packages - where Arch maintains all its packages. Nor is comparing the number of packages in AUR to Void main repos a good idea - Arch has its own main repos that are a better equivalent. The Void templates do not look dissimilar form what a PKGBUILD file is either and you can do the same things with writing your own PKGBUILD or pulling them from repos if you really want to. I don’t see how void is any better then Arch in anything you have described here. IMO it just looks like it does more of the same things with a bit difference in syntax/commands you run. Nothing you have said here is really a solid argument for using Void or Arch at all.
The AUR is not even that great. I think most people seem to get confused between what is in the AUR and the main packages since they just use tools like yay that install from both. But most people only use a couple of packages from the AUR - it is the package selection in the main repos which is what is so nice about Arch. The AUR is just nice for more niche things that have not made it into the main repos yet.
I hope u don’t use AUR blindly and just do yay -S something without looking what pkgbuild is doing, it might be dangerous not knowing what program can do and what script that is downloading it too right?
Same goes for Void? Most people wont read the source of third party packages they install. No matter what distro they are on. AUR tooling does try to help with this but most people ignore it. Same will go for Void. It is not a distro problem - just a humans are lazy problem. Plus even if people did read them there is only a small subset of people that actually understand them enough to spot obviously malicious packages - though that can spot hidden malicious packages are vastly smaller.
252 of that 592 used memory is buffers/cache, not application memory. That is used by the kernel for kernel buffers and the filesystem cache - IE files read by something at some point. The kernel keeps them in memory in case they are needed again to speed up file reads. You can effectively ignore these vales as they will always grow to fill your ram and will be evicted when programs require memory and there is not enough free.
These tools are not lieing to you, just telling you something other then what you are reading into them. Tracking and reporting on what is using memory is a complex topic and here used is just what is physically allocate. It doesn’t mean much over all as it always tends to be full of your system has been running for a decent amount of time. Available is typically the more useful one to look at as it is an estimate about how much the kernel can reclaim now if an application request it without needing to swap things out.
Can you share the output of free? There are multiple values to read from that.
IMO the best thing is to just start using it. You will start to pick things up fairly quickly then. Puzzles don’t often ingrain different ways todo things and often focus on weird or niche things that don’t come up as often. They can be a nice supplement to not a substitute for just using it in real world usescases.
I do also find it helpful to read the shortcut keys on their site to get a feel for what is available. You won’t remember everything but it can be useful to know what is possible. Then when you hit a problem you may remember reading about something that can help and go look it up again.
Just dont format the drive when installing a new distro. BTRFS or not you can delete the system folders manually first if needed but I believe that some if not all distros will delete the system folders for you (at least ubuntu used to do this last I tried). And if not you can do it manually.
It does not matter if you have a separate partition or not for /home installers won’t touch it if it already exists except to create a new user if needed. Remember, all the installers do is optionally format the drives, mount them then install files into those drives. If you skip the formatting and manually do that partitioning (or using an existing partition layout) it will still mount and write to the same places regardless of it they are separate partitions or not. So a separate partition does not add any extra protection to your home files at all.
But regardless of what you do you should ALWAYS backup your home data anyway. Even with separate partitions or subvolumes the installer can touch or delete anything it wants to and you can easily click the wrong button or accidentally wipe thing. At most preserving your home saves you from restoring from a backup it should not be done instead of backup.
There is no problem with having home on a different disk. But why do you want swap on the slower disk? These would benefit from being on the faster disks. Same with all the system binaries.
Personally I would put as much as possible on the faster disk and mount the slower somewhere that the speed matters less. Like for photos/videos in your home dir.
/boot can be anywhere though if you are getting a grub error that suggests the UEFI firmware is finding grubs first stage but grub is having issues after that. Personally I don’t use grub anymore, systemd-boot is far simpler as it does not need to deal with legacy MBR booting.
What you have listed is a good start. https://www.rust-lang.org/learn has additional resources as well once you have gotten through those.
Realtime is important on fully fledged workstations where timing is very important. Which is the case for a lot of professional audio workloads. Linux is now another option for people in that space.
Not sure Linux can run on microcontrollers. Those tend to not be so powerful and run simple OSs if they have any OS at all. Though this might help the embedded world a bit increasing the number of things you can do with things that have full system on chips (like the Raspberry pi).
And how did you, advanced Linux user, get to the stage your at now?
Incrementally over time by reading the documentation and/or manuals of the commands I need to run and looking up how others solve the problems that I need to get other ideas about things (even, periodically, for things that I already know how to do to see if anyone has found a better way to do it or if a new tool has come out that helps). And trying things out/experimenting with different ways of doing things to find out what works well or not.
It is quicker to list everything that has not been linked to causing cancer:
There, I think I got everything.
For reproductive outcomes (sperm quality) and digestive outcomes (immunosuppresion) we rated overall body evidence as “high” quality and concluded microplastic exposure is “suspected” to adversely impact them.
For reproductive outcomes (female follicles and reproductive hormones), digestive outcomes (gross or microanatomic colon/small intestine effects, alters cell proliferation and cell death, and chronic inflammation), and respiratory outcomes (pulmonary function, lung injury, chronic inflammation, and oxidative stress) we rated the overall body of evidence as “moderate” quality and concluded microplastic exposure is “suspected” to adversely impact them.
We concluded that exposure to microplastics is “unclassifiable” for birth outcomes and gestational age in humans on the basis of the “low” and “very low” quality of the evidence. We concluded that microplastics are “suspected” to harm human reproductive, digestive, and respiratory health, with a suggested link to colon and lung cancer.
Future research on microplastics should investigate additional health outcomes impacted by microplastic exposure and identify strategies to reduce exposure.
None of that is very definitive or quantitative at all - even the high quality data only gives a suspected adverse impact. Overall not really very actionable. It is probably not very good for us and something we should be working to reduce. If for no other reason than all the other problems we know excessive plastic production is causing.
Linux From Scratch (aka LFS) is a set of documentation and resources that describe one way in which to build everything on a Linux system yourself. It is not the only way though. Embedded systems is one place you might build every image from scratch but if you go down that route you are typically using something like yocto or buildroot which are designed to compile simple embedded distros for specific projects using an existing system for the build process. These are useful as embedded systems are often resource constraint and you don’t want to include things that are not required and often on different architectures from the host systems (such as ARM CPUs).
These days there is very little commercial purpose to creating your own distro from scratch that are not for embedded systems. It is a lot of work and generally not worth the effort unless building a distro is the point of your business - but even then you better have a good reason that using an existing one as a base is not a good idea. Packaging everything for a general purpose distro is a lot of work with very little benefit for a company to do. It is vastly easier to use what others have done as the base until you can justify the expense of managing everything your self (if it ever makes sense to do that).
So the only real place that you would go down building a distro from scratch is if you have a new or different idea about package management. Arch Linux did this with pacman, Gentoo with emerge, Alpine with apk, and Nixos with nix. These types of things typically start out as hobbyist projects and grow from there rather than with a commercial intent in mind.
The only other thing that makes sense is from a very high threat model for security reasons - thinking nation state level actors not your every day home user. You may want to build everything from scratch if you want to absolutely trust everything on your system and have the time and resources to do this.
That beaker does not look half full to me. Many like 1/3rd full, or at least somewhere between that and half full.
Generally speaking you shouldn’t be poking around running containers. It is rare that I have ever needed to do that. If you want to inspect the contents of an image then tools like dive are helpful. If the container produces some useful output that you might need then put that into a volume, you can then mount that volume to a debug/inspect container to read the files without messing around with the rest of the container.
Shell-less containers are a great security feature - it is extremely hard to get a reverse shell on something that does not have any shell. And if you must have a shell to debug something docker already has a feature for that docker debug which works for shell-less containers as well.
Coreutils has little commercial value to take can create a proprietary fork of. There is little value that can be added to it to make it worthwhile. The same is for sudo - which has had a permissive licence from the start. In all that time no one has cared enough to fork it for profit.
Not saying that is true of every project. But at the same time even GPL software has issues with large companies profiting off it and not contributing back. Since unless you are distributing binaries the GPL does not force you to do anything really. See mongodb and their move to even more restrictive licences.
The GPL is not the only thing that stops companies from taking open software. Nor does it fully protect against that.
Not does everything need to be GPL. It makes sense for some projects and less sense for others. Especially libraries as that basically forces no company from using them for anything. Which is also not what you want from a library.