I use a terminal whenever I'm doing work that I want to automate, is the only way to do something such as certain parameters being cli only, or when using a GUI would require additional software I don't otherwise want.
I play games and generally do rec time in a GUI, but I do all my git and docker work from the cli.
If you have a root account that allows logging in in text mode (no X no Wayland, no GUI), you would do that instead. These instructions are for that case. The home of root is /root , so it would not be affected.
Mount the new drive in an emty dir, if it isn’t already.
Make sure the other drives file system supports everything /home does.
Set the exact same permissions as /home/ in the new drives top level directory.
Add a line to fstab defining the other drive to be mounted automatically as /home .
Move the contents of /home over to the other drive.
Umount the other drive.
Enter just: mount /home
This should work without errors and if you peek inside, you should see user dirs and it should show up if you enter just: mount
No reboot necessary, you could just log out, switch to the GUI login and log in as regular user. After your next boot you will find out if you edited your fstab correctly to auto mount it. If not just log in as root in text mode again and fix it.
I still prefer to run everything built directly from reliable deb sources.
As an end user… sure, flatpaks and appimages and snaps are I guess neat if you are constantly distro hopping or something, at least in theory.
But uh, I have already found the ability to play games, develop games and other software, use basic daily software for everyday needs, and have a stable and predictable OS that doesnt crash or have insane misconfigurations caused by some esoteric conflict by just basing everything directly off of deb sources.
Every once in a while I will have to compile my own build, but this is rare and usually only occurs when trying out something experimental, or, also rare, something that doesnt have an actively and well maintained deb source. In that case its just a matter of doing a build from github when a new version comes out.
And I can do builds from github because I have saved a lot of storage space from not using bundled installers for all my software, allowing me to store the sources. This is also neat because it allows me to quickly /use/ one of those sources in a project, after I have already seen that it is stable via the software I use that is built on it.
Finally there is the security angle. Using a myriad of different containerized installers for everything is convenient in that you don’t have to directly worry about source management… until you do, when a source lib is discovered to have a critical flaw.
When a serious flaw is found in a source library… what’s gonna get updated faster? A containerized installer that you have to wait for the devs, who are busy managing tons of cross platform dependency issues and have to do a new safe stable build everytime any of their many dependencies for their many supported platforms? Or an app specifically built from source libs that either doesnt focus on cross platform, or has different teams specific to maintaining its different supported flavors?
In my experience, literally all of the time, the ‘direct from source’ software gets updated more quickly than the cross platform bundled installer.
Further, this whole approach here gives you experience with software that is built on source packages that, as you become more familiar with, and tinker with yourself, gives you insight into what source libs are well coded in terms of cpu/gpu/ram optimization, and which are resource hogs and should be avoided if youre interested in promoting and using software built off of efficient code. I enjoy learning from the good coding techniques of stable, lean and fast programs, and avoiding code that is comparatively unstable, boated, or slow.
Use anything you want, because all of them are safe and speedy.
Flatpaks allow packaging together all dependencies with specific versions with the package. Snaps take it to the next level by allowing to run system integrated sandboxed programs, because Flatpaks cannot have system integration. Appimages are simply the equivalent of portable USB software on Windows.
That is not how it works though, because I have been a part of these religious cults for basically forever. The hobbyist enthusiasm has a threshold, the cultism does not. It is animalistic nature to form and live as tribes. It does not become different just because the congregation tool is virtual instead of real.
Capitalism is not human nature. It is formulated around abuse of human psychology. The documentary Century Of The Self by Adam Curtis will be something you love.
Except Western imperialist countries have exploited hundreds of trillions of dollars from rest of the world, kept them subjugated for centuries, causing these luxurious software development cultures to not formulate in them. You are falsely equating software and politics being affected similarly and to a similar degree.
I had been a Gentoo user for a couple of years on MacBook Pro. I can say only this: it takes a lot of time, don’t do it. Rather: go out with family, have a beer or two.
Of all the reasons you could have chosen for Red Hat you chose “they killed a dead corpse”?
X11 was already dead, it isn’t getting updated, and its maintenance is gonna end eventually. Sure Wayland still has issues but once it’s ready for widespread use (which it is, save maybe for gaming on PCs with like 6GBs of RAM) the jump is unavoidable. In fact by doing this they got more people to work on fixing the issues in Wayland
Wayland on its own may be ready but you can’t build a whole desktop with just Wayland. The rest of the stack needs time to catch up.^(*) And no, not everybody is willing to use KDE and restrict themselves to whatever combination of elements happens to work right now.
^(*) Because the bright people who did this decided they needed to throw the baby out with the bathwater on X. They couldn’t possibly find a way to ditch only the obsolete parts and fix the problems and maintain compatibility as much as possible. No, everything had to be rewritten from scratch.
So here we are 15 years later, with another 5 or so to go until the whole Linux desktop ecosystem will be thoroughly redone.
as a matter of fact Cinnamon is also working on wayland (and here by wayland I refer to the whole thing not just the compositor), with the first release having come out recently iirc or coming very soon anyways and so are other desktop environments, and if they aren’t likely someone else will port them over if enough people care (such is the beauty of open source). It’s not just KDE and GNOME (which still account for a vast majority of users btw, if you choose a less popular DE you should expect slower development and less support it’s not something new or crazy or wayland’s problem it’s normal).
Because the bright people who did this decided they needed to throw the baby out with the bathwater on X. They couldn’t possibly find a way to ditch only the obsolete parts and fix the problems and maintain compatibility as much as possible. No, everything had to be rewritten from scratch.
If that was something possible/sensible to do, someone would have done it in the past 11 or something years of xorg being well on its way to the shitter? Like I get that companies make a lot of shit decisions due to money but clearly if abandoning deadware was chosen over resurrecting parts of it there’s a good reason. Also pretty sure all of it is outdated my dude so your point doesn’t stand. To my knoweledge Xorg isn’t very modular but I may be wrong here.
So here we are 15 years later, with another 5 or so to go until the whole Linux desktop ecosystem will be thoroughly redone.
Not a bad thing. Just like it wasn’t a bad thing when computers went from just the shell to a GUI, from tapes to eventually hard disks, unix to linux, etc. Xorg can’t support HDR nor lots of other things and in all these years nobody has managed to add them, not a company, not the community, not some schizo programmer with led unix socks and a custom tailored furry suit, that’s why wayland was invented and what eventually will run on everything minus abandonware. Xorg has been on its way out for years now, Wayland is perfectly usable (with notes to be made for GNOME’s implementation on the developer’s side and Nvidia on the regular user’s side) for the vast majority of users. What RH (Valve, and others) are doing is simply pushing people to get a move on and focus on wayland instead of passively waiting for it to just get better while they just stay in Xorg forever.
And btw nobody is gonna be stopping you from putting Xorg on your machine if you want. I’m using Xorg right now, merely for the sole reason my laptop with its 6GBs of RAM is too weak to run games on wayland yet due to XWayland (which again would be an easily solved issue if instead of having to make things for Xorg in mind they were made with wayland). But the switch to wayland is inevitable, not sure what you were expecting honestly you can’t keep a service from the 80s running forever when a better alternative finally arrives.
In fact, as I mentioned, keeping something on life-support this long has only been damaging as it doesn’t incentivise people to actually develop for wayland as much (even if they wanted, most its users were on Xorg and havng to choose one or the other thing they’re forced to choose Xorg, for example), granted it’s not the only disincentive there are some that are due to wayland’s implementations and particularly GNOME’s but without the move RH and others made the decisions on how to address these issues were just gonna be postponed ad infinitum.
it's on those applications to support wayland, not the other way around. X certainly wasn't developed to support upstream.
adopted an extensible standard, regardless of how it makes you feel.
more secure and resilient to a variety of attacks, including keyloggers. Yes very bad.
how about the fact that nearly all X developers founded and are now supporting Wayland, and X hasn't had meaningful development aside from break/fix patching for over a decade?
Securing the desktop protocol against keyloggers on Linux is like wearing a helmet when you’re walking down the street… yeah in theory it’s a good thing and would improve your safety, but it’s also wildly impractical and the things it protects you from are extremely unlikely.
And even if keyloggers were a huge everyday threat, you still have to allow for legit explicit uses of the technology (automation, accessibility etc.) But nah, they just said “we’re not implementing it at all”. What sense does that make?
You're proving that your hate is founded on word of mouth instead of facts. There was an accepted RFC for secure sharing of desktop resources years ago. It's solved. Many applications have already ported in.
Yes, but I can still play steam, any Valve game and atm any Linux steam game on X11.
I don’t hate Wayland as a project, I just don’t like Wayland as it current state. Give me better stability, better support with multiple monitors and a compositor with more customization, and I’ll be happy.
But, in my opinion, Wayland is by design opinionated. Some ideas are good, such as the security model, some are both good and bad, such as the Compositor VS Server+WM debate (both good systems in my opinion), some are just bad (no unified screen management option; obviously there are LOTS of protocol extension, but not all are supporting everywhere)
So, imo, WayLand just needs a stable, (really) customizable Compositor with all useful extensions and designed to put other components together; I’m still on my X11+awesomewm+rofi+polybar, and I want a customizable, stable and module approach on Wayland.
There’re discussions to drop the X11 backend with the release of GTK 5. That’s still many years away and I really don’t think there’ll be much of reason left to use X11 by this point.
What is actually still missing for Wayland?
Absolute placement of multiple windows for some scientific applications (multi-process, multi-window apps are places arbitrarily on Wayland atm, excluding compositor specific solutions).
Proper colour management support
VRR working while the cursor is shown. Needs hardware cursor (?) support in the kernel and drivers. FPS games usually don’t show cursor, so VRR works in the games which benefit the most from it.
Both are likely to get fixed in the coming years and are pretty niche.
Obviously I’m excluding compositor specific issues, like VRR, server-side decorations and global shortcuts not being implemented on Gnome. Generally they would work, if implemented.
There’re discussions to drop the X11 backend with the release of GTK 5.
A question of what will happen to the X11 backend is not the same as an active push for the removal of X11 just for the sake of it, as it was claimed.
Chances are at least the Valve side of Wine development work will not care for Wine’s X11 support either after SteamOS will only run Proton natively on Wayland instead of XWaxland as is the case now.
Yes, but I can still play steam, any Valve game and atm any Linux steam game on X11.
I don’t hate Wayland as a project, I just don’t like Wayland as it current state. Give me better stability, better support with multiple monitors and a compositor with more customization, and I’ll be happy.
But, in my opinion, Wayland is by design opinionated. Some ideas are good, such as the security model, some are both good and bad, such as the Compositor VS Server+WM debate (both good systems in my opinion), some are just bad (no unified screen management option; obviously there are LOTS of protocol extension, but not all are supporting everywhere)
So, imo, WayLand just needs a stable, (really) customizable Compositor with all useful extensions and designed to put other components together; I’m still on my X11+awesomewm+rofi+polybar, and I want a customizable, stable and module approach on Wayland.
It’s important to note that the CLA does not take ownership of your commit. To quote the CLA:
(a) You retain ownership of the Copyright in Your Contribution and have the same rights to use or license the Contribution which You would have had without entering into the Agreement.
All the CLA does, is say “I agree that Canonical can use my code under another license if they want to”. Your contribution is still yours.
I would also argue that by enforcing AGPL rather than Apache, the community gets more ownership. I’d rather have seen Canonical not require a CLA so they can sell the software you’re contributing, but AGPL forces everyone but Canonical to open up their custom versions to their customers, which are free to rehost it elsewhere and help bring the changes upstream, of course.
As for ownership: LXD was started by Canonical. The name and trademark is theirs, and they control the upstream project. Like always, you can reject their terms and provide your changes under another license, but as the article states, Oracle is free to take your Apache2 changes and use them for practically any purpose as long as they put a copy of the license next to their code and give you credit. That includes selling the software. Not just Oracle either, of course; IBM/Red Hat and Oracle can do the very same.
The community should own everything.
In a perfect world I agree, but then the community should take over doing the actual work. Right now, almost all of the work on open source is done by companies and organisations such as KDE and Gnome with their own committees and politics.
Software for some products don’t have company-supplied software (i.e. Asahi Linux, although they do have parts of the Darwin kernel for reference) but those devices also often take ages to become usable. There are also plenty of projects funded by charities and such, but most of those form some kind of organisation that owns the copyright by default.
the only REALLY good company for the Linux ecosystem as of right now is Valve
They brought Linux to the mainstream by locking down most of the customisability and by promoting running proprietary software. That’s just the way things need to be, but I’m not sure if the Linux ecosystem should be that happy about these developments.
Canonical fucks us with snap
It takes two minutes to install Flatpak and remove Snap. Their apt-to-snap transition is stupid and annoying, but it’s a very minor issue.
Red Hat kills X11
Red Hat stops maintaining X.org for free now that a better replacement is (almost) ready. The community is free to set up an effort to prolong X11’s life span, of course.
Google is closed
More and more closed (mostly on Android, because as it turned out, the people taking the Android source code and distributing their own forks didn’t contribute back much), but Android and Chrome are still almost completely open. Your alternatives are iOS (closed for all but the reference kernel), Sailfish (Android app support necessary for real world use but closed and paid), Ubuntu Touch (using the Android HAL, so about as open as Android), and the various Linux distros that can barely do power management and often lack features such as “placing a call”; Google still provides some of the best open source software for mobile devices.
Google’s ChromeOS is perhaps the weird exception here, being basically a closed-ish source Linux distribution. All the components that power it (Linux, Chromium, Android) are open source, but the special sauce that makes those useful for end users is closed.
nVidia is closed and buggy
Buggy? Yes, 100%. One day I will be able to use Wayland without random stutters and crashes!
Closed? Not for recent GPUs. Starting at the GTX1650/1660, the drivers are completely open source, with only the firmware being closed like on every other GPU. The closed nature of earlier cards (which still requires something like the GPL condom) still sucks, but they’re clearly improving.
Can you install MacOS by Zorin™ on something else? I suppose there’s a source repository somewhere and you can always compile it if you really want it…
Lolcat, yt-dlp, hyprland. Honesty though most of what I find cool these days wouldn’t make any sense to a Windows user. Like DWM, ST, XBPS, lf, ly, neovim, etc.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.