It won’t teach you about the kernel, it’s just a tool that papers over the existing tools for building and debugging the kernel.
If you want to learn then follow a tutorial for building the kernel by hand. Going through the kernel configuration (it’s long) and searching details for the entries is what teaches you the most.
Fair warning, it’s a very deep rabbit hole about computer architecture, networking and lots of other things. But it’s an amazing teaching source.
I’m not tied to anything at this stage, but I don’t have a lot of free time for trying different stuff. Can I install this DE alongside cinnamon, like I have with i3?
Kind of… The problem with full DEs like GNOME and KDE is that they pull in a lot of dependencies and make a lot of changes. So it can break visuals or change icons in each others environments or install apps with duplicate functions. Something like i3 has a lot less clutter because it expects the user to build their own environment.
The best way to try out KDE would be to install it under a new user on your system so it doesn’t conflict with your original home directory. Or you could boot up a live image of Kubuntu or some other KDE flavored Linux distro and mess around with it a bit to see if you want to commit to it.
While you can install KDE on mint without issues (apt install kde-plasma-desktop) I would recommend installing a KDE focused distro because sometimes they have better default configs.
But Plasma should be able to do win + arrow keys out of the box and current versions of Plasma should have basic tiling functions by dragging a window around and holding shift. If there’s anything you don’t like it’s a very configurable platform.
Always did on my hardware at least. When I was using Windows, my old laptop started lagging very much and it was becoming unbearable. I could not get a new one immediately. I got to know about Linux one day and installed it to try it out because there was not really anything else I could try.
I could not believe myself how buttery smooth my laptop became after that. 95% of the games that I used to play on Windows run with more performance on Linux.
I’m typing this on an 8-or-9-year-old laptop that used to be a Windows machine years ago. Exact same experience–it got too sluggish so I wiped it and installed Linux and it’s been fine ever since.
It’s not a “shitty title”, because Ubuntu Linux is the thing they actually tested.
Whether Debian or Fedora or Alpine or Void or whatever would do better or worse is not a given, and isn’t something the OP can comment on because they didn’t test it.
We can probably infer that gains of a similar amount would be seen on most mainstream distros (as they’re all pretty similar under the covers), but that’s not on the OP.
In particular, Ubuntu ships with various non-free drivers and kernel patches that will be present in some, but not all other distros.
If course it’s not on the OP, it’s on Phoronix. This is a shitty title from any party, but from them last least I would have expected more, instead of just attributing the performance to a specific distribution, the most corporate-y one no less.
Linux, the kernel, doesn’t operate in isolation. The system under test was Ubuntu, which comes with specific packages, package versions, patches, kernel configuration, and so on. It is reasonable to say that the combination between this specific operating system and hardware led to the observed outcome. Different combinations of software and hardware may yield other results or replicate the same outcome. The certainty of these outcomes can only be established through testing. Therefore, your outrage seems unwarranted, and your assertion is not only baseless but incorrect.
Some computer games and other graphics intensive apps are using vulkan, and they will now work with an nvidia card without needing to go get nvidias proprietary driver, which is often buggy due to not being properly tested with your desktop and system in general.
If the Chromebook is your property, you can do whatever you want with it, and it’s unlikely that anyone will notice or care. I assume you’re in the US, since you appear to be worried about DMCA encryption-related provisions. Don’t be. Even if it were 100% guaranteed illegal with all necessary precedents, Google has better things to do with its time than track down individual jailbroken Chromebooks. It isn’t like you’re going to be selling them in quantity or using them to facilitate ransomeware attacks or something.
However, I’d invest in a used laptop instead, since it’s likely to have more internal storage even if it lacks the !!shiny!! factor. Chromebooks are meant to store as little as possible locally, and that isn’t how a normal Linux works. I suspect you’d start to get data claustrophobia pretty quickly.
You’ve messed up partitioning and EFI partitions. There are leftovers from Debian and Windows. Wipe both drives, star fresh. Make one EFI partition on the NVME drive, 512MB, and use the rest for the main OS. Use the entire SATA drive for the other boot option (no need for EFI partition on that one). When installing the second OS, skip the bootloader install. Boot into the main OS, set grub to search for other OSes installed on the laptop and update grub afterwards. The second OS should appear in grub’s menu.
I would start fresh but I got data on my sata. Also sometimes it boots in grub. I think it’s from Debian. Can I use that or do I need to be in a system?
OK, then here’s what you do. Wipe the NVME, install your main OS on it. Boot to it, it should read the SATA drive. Mount it, copy whatever you need from it to the NVME drive. Then wipe the SATA drive (dd or any other program of your choice). Install your second OS on the SATA drive, but skip installing the bootloader. Reboot, boot to your man OS, set grub to search for other installed OSes on the laptop, update grub. The second OS should appear in grub’s menu.
If the data on the SATA drive is bigger than what the NVME can take, use BTRFS with compression (zstd=10 should do it, after the copy, you can drop the compression to 5 for better performance) on the main OS. It will compress binaries or plain text/document files quite nicely. Media, not so much, but it will cut down a few % off it.
Also, when you update the kernel on the second OS, grub won’t detect that. You have to manually switch to the new kernel, but from the main OS. Also, removing old kernels on the second OS will become more complicated, since there is no bootloader installed for it.
I’ve got this now, looks pretty cool, thanks! Gonna keep looking over the documentation, but I can’t quite see the particular behaviour I’m looking for. It has the snapping (and better options than Win10), but I want to be presented with the list of other available windows for snapping on the other side.
i.e file is created (as non-root), trying to remove the file (once again, as non-root) gives me a “rm: cannot remove ‘dir/file.name’: Permission denied” error message.
OK I see. Can you create a new file with nano and then do an “ls -l” so we can see the permissions it’s given? Also provide the output of the command “umask” as the user you’re working with.
That is not an elevated permission, your user should be able to delete that file, do the same in another directory if it works it might be a permission, or more likely an attribute, problem on the directory itself or something on the path to it.
What are the permissions on the directory? What is command are you running to edit the file? What command are you running to delete it? (Have you got selinux turned on? What filesystem is this directory on?)
Try an ls -l $(which nano) and look at the permissions section of the output.
Most files only have hyphens, r’s, w’s, and x’s. (Like -rwxr-xr-x or some such.)
Particularly if there’s an “s” in the output (it’ll be in place of an “x”), that could explain what’s going on.
Basically, that “s” means “when a user runs me, run me as root even if the user running me isn’t root.” It’s useful on programs like “su” and “sudo” which let you run a command that (after authentication) do things as root.
But if that flag is set on nano, that’s pretty weird.
Maybe try alias nano and LC_ALL=C type nano. Those test whether you have an alias or function named “nano” in bash that might be being run instead of /usr/bin/nano.
Oh, also, whoami and id. Maybe there’s something weird with how you’re logged in and despite not having the username “root” you’re still uid 1 or something strange like that?
Oh! Also maybe while you’ve got nano running, do a ps aux | grep nano and see which user is reported to own that process.
Alright, first one returned me “bash: alias: nano: not found”. Second one, “nano is hashed (/usr/bin/nano)”. Third one, my sudoer username. And the fourth one shows my sudoer username at the top of the list, with both uid and gid at 1000.
And I honestly can’t really think of much to add, other than the username in the docker image being completely nonexistant (It’s just a bunch of numbers, and it doesn’t even have a name). I don’t know, maybe someone managed to breach the container and gave this “nonexistant user” root privileges but haven’t managed to do much or something like that. I’m not that much of a tech savvy, but I guess it doesn’t hurt to try to guess something. Maybe there is something inside the container? Idk, I’m gonna (try to) check it out (It’s a “distroless” image – it doesn’t even have a shell in it.).
It returns that while you have nano running? If so, maybe try ps aux (without the grep part) and just look through until you find “nano” listed. Just to make sure whether it’s running as root or your non-root user.
(And just to be clear, “my sudoer username” means the non-root user that you’re running nano as, right?)
Just a gut feeling, but it feels to me so far like this probably isn’t a hack or security thing. But of course, once the (no pun intended) root issue is found, that’ll provide more info.
No. ps aux remains the same. And yes, “My sudoer username” is my non-root user with sudo privileges. Therefore, the “sudoer”.
And I’m not really “pulling my hair out” because of this, honestly – just curious if this can be mentioned as a hack, a hack attempt, or whatevertheheck. Because this is the first time in my entire life that this happened with me, so yep.
Could I set that for Docker? I often forget to run docker-compose as sudo and it can’t be used without sudo, so it’s a bit silly to always have to prepend sudo there. This magical “s” you describe could solve that.
And, of course, because I want to learn: why is this a really bad idea?
If you can’t run docker-compose without sudo, there’s something wrong with your setup. The specifics would be specific to your distro, but most likely there’s a user group you could add your user to with sudo gpasswd -a user group to make the docker run and docker-compose commands work without sudo. (Might have to log out and back in as well to make it take effect if you’ve ran that command during the current session.) To find the name of the group, you’ll probably have to do some research about your distro in particular. On Arch (insert hate here ;) ), I think the docker group does that, and it’s not unlikely that the equivalent group for your distro has the same name.
The “magical s” (called the “SUID bit”) shouldn’t be required to be able to run docker run and/or docker-compose without sudo. Theoretically if you did want to do that, you could do it with sudo chmod u+s /usr/bin/docker. But again it’s probably better to just add yourself to the proper group (or otherwise take the correct steps for your distro.)
But also, running docker-compose (or the docker run command more directly) without sudo won’t necessarily make things inside the docker container run as your user. Making it do so is a little complex, actually, but I’ll go through it here.
So, most Docker images that you’d get from Docker Hub or whatever usually run by default as root. If you do something like docker run -v /path/to/some/directory/on/your/host:/dir -it python ‘touch /dir/foo’, even if you’ve got your groups set up to be able to run docker run without sudo, it’ll create a file on your host named “foo” owned by root. Why? Because inside the container, the touch /dir/foo command ran as root.
Honestly, I’d be thrilled if Docker had ways to tell it to be smarter about that kind of thing. Something that could make Docker create the file on the host owned by your user rather than root even if inside the container, the command that creates the file runs under the user in the Docker container that is root/uid 1.
But that’s not how it works. If root inside the container creates the file, the host sees it as owned by root, which makes things a little more of a pain. C’est la vie.
Now, this is a bit of an aside, but it helped me understand so I’ll go ahead and include it. It seems impossible that a command run by your user (assuming you’ve got your groups set up correctly) shouldn’t be able to create a file owned by root, right? If without sudo you try to chown root:root some_file.txt, it’ll tell you permission denied. And it’s not the chown command that’s denying you permission. It’s the Linux kernel telling the chown command that that’s not allowed. So how can it be that the docker run command can create files owned by root when docker run wasn’t run by root, but rather by a more restricted user?
Docker has a daemon (called dockerd) that by default runs all the time as root, waiting for the docker command to direct it to do something. The docker run command doesn’t actually run the container. It talks to the daemon which is running as root and tells the daemon to start a container. Since it’s the daemon actually running the container and the daemon is running as root, commands inside the container are able to create files owned by root even if the docker run command is run by your own user.
If you’re wondering, yes this is a security concern. Consider a command like docker run -it -v /etc:/dir/etc alpine vi /dir/etc/sensitive/file. That command, theoretically, could for instance allow a non-root user to change the host’s root password.
How do you get around that? Well, there are ways to go about running the Docker daemon as a non-root user that I haven’t really looked into.
Another concern is if, for instance, you’ve got a web service running as root inside a Docker container with a bind volume to the host and the web app has, for instance, a shell injection vulnerability wherein a user could cause a command to run as root inside the docker container which could affect sensitive files outside. To mitigate that issue, you could either not bind mount to the host filesystem at all or run the web service in the Docker container as a different user.
And there are several ways to go about running a process in Docker as a non-root user.
First, some Docker images will already be configured to ensure that what is run inside the container runs as non-root. (When making a Docker image, you specify that by having a USER directive in the Dockerfile.) Usually if things are done that way, the user will also be present in the relevent files in /etc in the image. But as I mentioned earlier, that’s usually not the case for images on Docker Hub.
Next, if you’re using docker-compose, there’s a “user” option for setting the user.
Another way to do this is with the -u argument on the docker run command. Something like docker run -u 1000 -it alpine /bin/sh will give you a shell process owned by the user with id 1000.
Another way is to create the user and su to that user as part of the command passed to docker run. I’ve been known sometimes to do things like:
<span style="color:#323232;">docker run
</span><span style="color:#323232;"> -it
</span><span style="color:#323232;"> alpine
</span><span style="color:#323232;"> sh -c 'adduser tootsweet ; su tootsweet -c /bin/sh'
</span>
The only other thing I can think to mention. Sometimes you want not just to run something in a Docker container not as root but in fact to run it as a user id that matches the user id of a particular user on the host. For instance so that files written to a bind volume end up being owned by the desired user so we can work with the files on the host. I honestly haven’t found the best way to deal with that. Mostly I’ve been dealing with that situation with the last method above. The useradd command allows you to add a user with a specific user id. But that’s problematic if the needed uid is already taken by a user in the container. So, so far I’ve kindof just been lucky on that score.
Hopefully that all helps!
Edit: P.S. apparently the way lemmy.world is set up, you can’t mention certain standard *nix file paths such as / e t c / p a s s w d in posts. The post just isn’t accepted. The “reply” button grays out and the loading graphic spins forever with no error message and the post doesn’t get saved. I’m sure this is a misguided attempt at a security measure, but it definitely affects our ability to communicate about standard Linux kind of stuff.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.