I say go for it. I’ve been using it for about 2 years, and I no longer feel like distro-hopping (not sure if you fall into that category of Linux user), because it’s not opinionated about how it’s meant to be used. It gives you all the tools (and foot-guns) to do whatever you want with your computer.
You don’t need separate computers for a local mirror and/or build server to run Gentoo, I’ve never done that. I’ve never owned a Mac, so I can’t really offer any tips hardware-wise, but use a live USB of a distro that you’re already familiar with, so you can refer to the handbook as you go. The people on Gentoo’s IRC channel & forums are very helpful if you come against any roadblocks.
It does take a while, not gonna gloss over that. Once you have it installed, there are very few issues that would require a full re-install. Portage is an awesome package manager, the language of its warnings/errors took some time to wrap my brain around, but it’s very verbose in describing what’s going on.
As its name suggests, LogoFAIL involves logos, specifically those of the hardware seller that are displayed on the device screen early in the boot process, while the UEFI is still running. Image parsers in UEFIs from all three major IBVs are riddled with roughly a dozen critical vulnerabilities that have gone unnoticed until now. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process, which is known as DXE, short for Driver Execution Environment.
So, does disabling the boot logo prevent the attack, or would it only make the attack obvious?
Not necessarily, I guess. They’re talking about a firmware upgrade of sorts, and, at least on the machines I own(ed), performing it didn’t reset user settings (which disabling the logo is)
In short, the maintainers have made questionable decisions over the years, and the Arch Linux packages are held back by two weeks on Manjaro for… basically no reason.
If you want an out-of-the-box solution to Arch Linux, just use EndeavourOS.
So. I’m a happy Manjaro user. I don’t install a lot of things and have had AUR updates break stuff likely due to the 2 weeks delay Manjaro adds to their packages.
I’m still using it on multiple devices and I’m really happy. I considered moving to endeavour but I wasn’t sure how it would handle hardware updates. I mean, my understanding is that Manjaro is more “noob” friendly and I don’t consider myself an expert. I used the Manjaro hardware helper to fix my video drive several times and I like the simplicity of the command. Does endeavour require a more advanced user? Does it have the “easy to use” troubleshooting things that Manjaro has?
Ah. What about the Kernel uploader? I think the Manjaro one is unique to Manjaro right? Is there another one for regular arch/endeavour?
Endeavour has plenty of “beginner” tools, including a kernel manager (literally called A Kernel Manager) and a friendly GUI Welcome app that helps you update your system and your mirrors.
Real reason for the hate: The Linux community is overly focused on tribalism and has a console-wars mindset where what I’m using is obviously the best and everything else must be flawed and terrible. Manjaro is probably fine for most use cases.
…although I’d still suggest just using base Arch instead. :)
I have manjaro running on six machines. No problems that were not Just part of learning. Two of those computers were for testing different distros… All ended up with Manjaro.
Hate is for people that don’t create, or improve their own world.
While on one hand Manjaro is very polished. Some things they do is questionable. Like the time they suggested to change your date and time because they let their repo keys expire. Or accidentally DDOS the AUR. Just to name some. The Manjaro team has a rather bad track record of these things.
I knew that there existed different types of hardware video encoders, but I always thought that it would get installed together with your gpu drivers. Thanks will check it out!
I’ve been looking for a terminal with better bookmark support; I use mRemoteNG on windows for my RDP/SSH work, and I haven’t been happy with any alternative on Linux that handles session bookmarks like that. I’m curious to try this.
I manage a lot of systems, so just click to open a ssh session in a new tab. I usually have shell aliases, but a bookmark that could set the title of the tab to the hostname and account for easier nav would be my goal. Being able to dynamically open tab groups too would be good, like if I have a dev/prod/SQL server for an app I could 1-click to open a group of 3 tabs
Well, there’s this if you want to use it in Linux, I’ve used it before, liked it well enough, but not paying for it so I removed it (It’s sort of crippled if run free). I personally use Konsole on KDE which works quite well. I’ve read and think that Konsole also allows multiple bookmarked connections. I haven’t really tested it myself, I have roughly 10 machines I log into daily so I may try that further.
Before I made the leap to Linux years ago, I loved using MRemoteNG. Simply hands down the best. IMHO
I tesed the client posted here by the OP. While it looks pretty nice, it suffers the same thing as others I’ve tried. Nothing beats the simplicity of the plain 'ol shell in Linux or in OSX. :)
It's rare that I get to feel anything remotely comforting about not being able to afford new hardware, but if I understand correctly, my BIOS-only dinosaur can't be exploited.
Still vulnerable to thousands of other exploits no doubt, but not this one.
You’re right, that’s exactly what happened. If you look at the top of the trace, it says __handle_sysrq. Moreover, it’s in the sysrq_handle_crash. That gets called when a sysrq combo is pressed.
Either you’re trolling - in which case, sod off back to Reddit - or you have a woeful misunderstanding of how Linux user permissions work.
Please explain how someone might “simply change” someone else’s .bashrc without either already having access to that user account, or root access on the whole machine?
The idea is malware you installed would presumably run under your user account and have access. You could explicitly give it different UIDs or even containerize it to counteract that, but by default a process can access everything it’s UID can, which isn’t great. And even still to this day that’s how users execute a lot of processes.
Regarding Windows all I read is that this “admin permission dialog” is launched in some form of sandbox where no software can access it. Not sure about faking input devices though, and I am also not promoting Windows for Security
True, but that doesn’t necessarily matter if I can compromise the privileged app instead. I could replace it, modify it on disk, or really any number of things in order to get myself a hook into a privileged position.
Just injecting code in some function call which launches malware.exe would do the trick. Ofc signature checks and the like can help here - but those aren’t a given. There’s any number of ways you can elevate yourself on a system based off of user security if your threat model is malicious processes. Linux (and windows) will stop users from accessing each other’s crap by default, but not processes.
Or: supply chain attacks. Now your official app without any modifications is malicious.
If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the “alias sudo” trick extremely unlikely.
Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).
In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care. I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.
Yep! You can also get pretty far even without containers. At the end of the day containers are just sandboxing using namespaces, and systemd can expose that pretty trivially for services, and tools like bubble wrap / flatpak let you do it for desktop apps. In an ideal world every package would only use the namespaces it needs, and stuff like this would largely not be a concern.
Nearly all tools (with flatpak and portals progressing into better directions but probably never finished) have rw permissions everwhere.
The modern OS threat model is not other users, as private users mostly have single user systems. It is malware and software doing nasty things.
On Linux this always worked out somehow, but grabbing your sudo password is not hard, just alias sudo to a script reading your argument, reading your password, and piping the password to the real sudo. You dont even notice it but that script just got your sudo password.
It’s not about someone, it’s about something. A lot of us aren’t (only) using Linux as a server OS, but for desktop too, and desktop usage involves running much more different kinds of software that you simply just can’t afford to audit, and at times there are programs that you can’t choose to not use, because it’s not on you but on someone on whom you depend.
Then it’s not even only that. It’s not only random shit or a game you got that can edit your bashrc and such, but if let’s say there’s a critical vulnerability in a complex software you use, like a web browser, an attacker could make use of that to take over your account with the use of a bashrc alias.
I.e. how malware could easily catch your Sudo password without root access.
Peeps, bad news, Linux is damn insecure.
By simply placing an alias in your bashrc they could already grab your sudo password.
Another bad news, this Windows “okay” Button without any password is actually more secure.
In other words: a compromised system at the User level can easily compromised at the admin level if there are no additional checks/measures in place. Same for Windows. Just change the link to a Programm you commonly need the press OK to to you maleware. Profit.
The proper way to handle issues like these is process level permissions (i.e. capability systems), instead of user level. Linux CGroups, namespaces, etc. are already moving that way, and in effect that’s the way windows is trying to head too. (Windows has its own form of containerization called AppContainers, which UWP apps use. Windows also has its own capability system).
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.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.