Try
lsblk to list them
The Linux Thread
- Thread starter Narekatsi
- Start date
You can do this in a variety of ways. The most popular one would be is to host your
.config folder on a git server then just do a git clone on the home directory of the new Linux box whenever you need it. But that wouldn't solve the "installing programs" bit of the initial setup. For that, it would be a bit tricky. I haven't done that on all distros and UNIX-likes but on the ones that I did (Gentoo, OpenBSD) they provide a way to create "installation lists" that you can just pass to the package manager (portage/pkg) to autoinstall your third-party packages.For Gentoo, you can create portage sets and just copy that over to the new machine then do
# emerge --ask @your-set.For OpenBSD, you can use UNIX pipes to create a package list for your current install to a text file:
$ pkg -mz | tee my-list then just pipe the list in to your new OBSD install: # pkg -l my-list.The issue that arises in this is making it public, or having a password on it that would require fiddling with. I'm not sure in general, I barely use git. I know cloning is pretty easy, though.
I tried writing a .sh script, but that would be tricky to change from flash drive to the home directory on a minimal install. The video I posted on this thread has a shell script like that as well.
Thanks for bumping the thread by the way.
One issue I'm having right this moment (technically fixed a few moments ago) is screen tearing on that same laptop. Fixed it with picom, but picom by itself uses up resources. What do you guys use for setup with a compositor? I never had an use for it, but this screen tearing was troubling a few things.
One issue I'm having right this moment (technically fixed a few moments ago) is screen tearing on that same laptop. Fixed it with picom, but picom by itself uses up resources. What do you guys use for setup with a compositor? I never had an use for it, but this screen tearing was troubling a few things.
Yup. You could create a private git repo in Git{hub,lab,tea} to solve that but then you're just adding complexity on top of an already complex chain. What I personally do for quick and dirty setups is just create a dump of my latest
/home/$USER/.config using tar and just transfer that using a USB stick or over the network using scp. For a more consistent solution, I would probably just deploy a NAS on my local network where my hosts periodically tar -> rsync their /home and have those timestamped.Shell scripts are alright, but my issue with them is that they require upkeep whenever you update the programs on your minimal install. Portage sets are a bit that way, as well, and I find that cumbersome after a while. I prefer the OBSD way of doing things:
$ pkg -mz | my-list, then # pkg -l my-list but as long as your approach works for you then you should keep at it.Picom is probably the best that you've got if you're going to use xorg.
In this context I mean of a shell script of pacman or apt installing all the packages you need. Updating is just a matter of -Syu or just update on Debian.
Yeah, no I mean when you decide that your minimal install list needs tweaking where you add or remove packages from that list.
The thing with the list is that I try to keep it basic. Stuff like bluetooth you just need one package, and no one will really say "ah jeez, I gotta remove Xorg to avoid the bloat!" This is kind of an exaggeration, but that's also kind of the point. Packages are really the thing I update the least, and when I really need to replace them, I just slightly modify the script with stuff like switching PCmanFM for Thunar, or simple changes.
I always check on a new install if I'm installing something bad on the script, but I barely get that. Issues arise only when I'm switching distros, or Debian having the proprietary list that you have to comment out.
GUI is bloat, run your entire computing experience from the TUI, you username would then check out
It seems to not affect most distros, only those on testing or bleeding edge - and most already have a remediation for it, thank goodess.
Could have been a massive breach though because of how widespread the compression software is, and ships as default to most flavours of Linux.
Ended up hopping from testing to Debian 12 after the abominable NVidia updates incident happened again. Breaking Xorg is par for the course with the nvidia drivers.
have you tried the solutions discussed here:
I'm only an occasional linux user, Windows does an adequate job of high resolution scaling. Macos is better. What is it about the scaling that isn't working for you? Is it blurry? Still the wrong size?
Kingdom
Orthodox
Plasma seems to do fractional scaling well. I don't use scaling so can't confirm though.
https://www.dedoimedo.com/computers/plasma-5-20-scaling.html
https://www.dedoimedo.com/computers/plasma-5-20-scaling.html
I have honestly had zero issues with drivers on Arch. Arch desktop, Debian stable for the server for me is the go to, I can't really see that changing.
Narekatsi
Oriental Orthodox
Windows does a phenomenal job, as far as I'm concerned. Most of what Linux achieves, manages to provide me with an abundance of headaches.
I did discover recently that the latest version of Fedora appears to be a bit easier on my eyes, but still uncomfortable. I've heard good things about scaling in the new KDE Plasma 6, so I'll need to find some time to give that a try.
Fedora is releasing new versions every six months, I think. Maybe CentOS Stream or RHEL is much more appropriate for your use case. Or maybe you skip a version instead? i.e: 38 -> 40 since they guarantee support for 13 months after a version's release.
I do think you mean window manager rather than distro here, but will say a bit more below.
Well, I'm not really the right person to advise on this as I don't care much for screens and resolution. It could probably be VGA and I wouldn't care although I'm sure it's probably more than that. I care more about the quality of speakers and headphones (and amplifiers...)
That being said, Cinnamon Desktop seems to be quite powerful. You can hold control and scroll the mouse in a window and the icons change size. Actually the other day I even noticed a whole array of settings and options I was not even aware of for style and colouring of icons.
At one point on RVF Linux thread I think it was I was even complaining that Cinnamon was using too much processor on my decade old machine and for a while experimented with about three different more minimalist desktop environments / window managers before coming back to Cinnamon. I managed to tweak something else to cut down on processor usage. If you have a modern machine it will make no difference.
Cinnamon is customisable both through menus and stuff in the gui and through various config files hidden away in a system folder somewhere. I have tweaked it in both ways.
It is originally made for the Linux Mint distro but I use it as a desktop of choice with Debian. Stopped using Mint years ago. There are a number of desktop environments available for Debian. The default is Gnome but I hate it as it is like Apple Mac and I never got used to those. But after using Windows for a long time, Cinnamon was the most similar. Good luck, but not sure what will happen with Cinnamon and the high DPI screens. Probably has something to do with having a graphics card which has a linux driver available and installed. That sort of detail does not necessarily happen automatically upon installing linux but unless you're unlucky with your graphics card, the driver is probably somewhere there to be found in your distro.
Your problem is likely that you're using the discrete GPU & ignoring whatever on board performance GPU your laptop comes with.
Most modern laptops have 2 GPUs, a discrete on the CPU & an an onboard soldered to the mobo. Windows & OSX have closed source, proprietary drivers that can seamlessly switch between the 2 GPUs, no linux kernel I'm aware of has that. You have to use 1 GPU & use it for the duration of the system uptime, meaning if you want to switch between discrete/onboard (like windows/osx automatically does) - it requires a reboot.
This also means if you unplug your laptop while you're using the onboard GPU on linux, you're going to destroy your battery & it's near guaranteed you'll cause heat damage also. This is why the windows drivers will switch between the 2 GPUs based on battery usage, general workload, heat, etc.
Nvidia/intel discrete onboard combo is the most common, you'ld start by installing nvidia-smi (by compiling it or using a package manager) & verifying which GPU is in use, you can also do this by monitoring power consumption via a tool like powertop. It sounds like you're defaulting to the discrete, so for nvidia you'd use nividia-smi to turn on the onboard, then reboot, for amd IIRC it's an echo filesystem ("$> echo 1 > /dev/....").
While it's 100% possible to achieve anything on linux your windows installation does, linux is not designed for general purpose, everyday end user computing on a laptop. This is why no manufacturer supports it, Dell was the only one I know of that did & they recently dropped all linux support. Unless you understand everything that is happening, you know how to interact with drivers, etc you're very likely to reduce the hardware life of your laptop by using linux on it.