I own all the pinephones and as much as I’ll go to bat and speak well if them… The tab support is super early. Lots of stuff doesnt work (wifi for one). That’s not to say that won’t change with time as the pinephone pro did
indias growth is so important, it’s such a dense country so growth will be rapidly exponential unlike 95℅ of other countries. it’s the perfect mixing pot of technologically literate, dense, money conscious, and distrustful of western influence for linux to thrive in. once india is dominated by linux, it will expand outwards so fast.
Seriously, I’m impressed on just how much influence Linux has in India, not only as an OS, but as a community. I’m in charge of some of the Fedora social media accounts and it really impressed me at first how India is consistently one the top 3 countries our followers are from in all of them.
I tried and failed to install it on my laptop last year. Couldn’t figure out the problem and went back to pop. I’m messing around with it in a vm, though, and liking it a lot. I may try again when I have some more time to troubleshoot.
it may be because you were using the default libre kernel, which is missing lots of microcode for your drivers. You need to add a substitute binary server that points to non-guix, which you can then use to supplant the libre kernel with the mainline one.
I thought that, but I had identical results using the stock install media and the modified nonguix one from systemcrafters.
The weird thing was that the initial install went fine, even after the first reboot. The problem was the next boot after my first system reconfigure.
Not only could I not boot my system after that, but I couldn’t boot the install media either. The only thing that would work was the installer for the most recent pop os.
That sounds like a BIOS issue. I sometimes get these on my laptop where I installed an EFI partition but my laptop was in some legacy mode, and I need to fiddle with my boot options and disable various features until the system “sees” the boot partition in the same way the OS “saw” it
I was thinking something to do with nonvolitile memory.
The real problem was that the guided install - guix pull - system reconfigure - reboot process took about three to four hours each time, so I gave up after a few iterations.
I did try playing around with bios settings a little, but I’m sure I missed some possibilities.
I’m pretty sure I was set up for substitutes, but this was a while ago.
I did end up replacing my router a few months after that, so it may have just been that my connection was very slow.
Also, every time I tried it and it didn’t work, I had to do a full Pop Os install in order for myguix install media to start working again, which added a few minutes to the process.
Your frame of mind is “dangerous”. If you are browsing on your servers as root, you need to not manage servers anymore. If that sounded harsh, learn about attack surface area first and then I might let you back in the server room.
You won’t find discussions about running browsers as root because it’s not something you should need to discuss. Also, you don’t need to be browsing “shady” websites to get compromised. Get that myth out of your head.
find it more convenient to use the command line from a remote desktop instead of directly SSH-ing into the system
How is extra steps and added latency more convenient? The latency of a console via remote desktop would drive me crazy. Hell, I haven’t installed any kind of desktop environment on Linux server for over 20 years. It’s not needed and a waste of resources. Who needs file managers anyway?
Your frame of mind is “dangerous”. If you are browsing on your servers as root, you need to not manage servers anymore. If that sounded harsh, learn about attack surface area first and then I might let you back in the server room.
You sir/ma’am hit it right on the head.
The “run root on Firefox” isn’t the issue, it’s the red flag. Security is a mindset. Failure to understand the core philosophy of why we have roles and permissions means you’re untrusted. It really isn’t personal. It’s security.
No, hibernation saves state to disk, and turns the computer off, drawing no power. Deep sleep is what was for me just sleep until recently: it uses power to keep data in ram, so it’s faster to wake up than hibernation. The amount of power used is really small, so unless you don’t use your lap top for a couple of days, it won’t deplete the battery. New hardware has this new “S2 Idle” state, that is basically an “On” state minus the screen and it’s OS’s job to try to use as little power as possible usually by telling each and every device to chill as much as possible (this is my understanding, but don’t quote me on this). On Windows, with the first party device drivers, this sorta works OK + OS drops to deep sleep or hibernation depending on battery or something.
My favorite part of this thread is everyone just saying copy and paste the commands so it will work. Like we should totally get users into the habit of running random commands off the net as root.
Most of the post is an “argument from authority”: Trust me, I have a PhD and maintain my own X server, and I assure you that Wayland is a pile of shit!
OP claims that “actually nothing will actually run” because the stable Wayland protocols lack so much important functionality. In reality, many people use Wayland every day, and multiple large distributions use it as the default display server. This doesn’t inspire confidence in OP’s knowledge.
Admittedly, the first bug they linked is a real issue and it should be fixed, but it’s not a Wayland design flaw. It’s an (arguably important) feature that hasn’t been implemented by all compositors yet. With the second bug OP laments that Wayland compositors are implemented in C, an unsafe language. This is true about X.org too, so I don’t really see the point. Arguably Wayland improves on X11 here, because someone could develop a new Wayland compositor in Rust, while in X11 this is a core part of the display server.
OP claims that “actually nothing will actually run” because the stable Wayland protocols lack so much important functionality. In reality, many people use Wayland every day
Are the Wayland compositors people are using every day exclusively using “stable” Wayland interfaces? Honest question, because I have absolutely no idea.
Neither do I. I’ve had a sensor net watching for Wayland news (because sooner or later I’m going to have to migrate to it, just want to know when) but so far there hasn’t been any executive summary.
There is no such thing as a 'stable' Wayland interface. Each compositor is responsible for their own interfaces, the Wayland protocol is there to make sure that applications written for Wayland play nicely with them.
It does give anti-SystemD “why make new when what we got now is good vibes”.
Their Java bashing was more a criticism of design patterns than Java, but fell into the meme bashing of tech based on one example. Find an old bug and say tech is dreadful as a result.
With the second bug OP laments that Wayland compositors are implemented in C, an unsafe language.
That’s not what they’re saying. They’re saying wlroots is full of race conditions, which will be very hard to fix because they’re part of a fundamental design problem.
That is a serious problem, but advocating X11 will not solve anything. Wayland is being improved every day, while X.org is in deep maintenance mode.
And let’s not pretend that X.org is perfect. Race conditions at least can be fixed, even if it takes a lot of time and effort. Worst case, someone will rewrite wlroots in Rust. But in X11 any application can kill other applications, install a key logger, pin itself to the foreground, etcetera. This is by design: it’s what makes window managers, xkill and xeyes work. It’s also a huge security flaw that can never be fixed.
That security argument is like advocating wearing a motorcycle helmet when walking down the street. It sounds like a great idea and super safe, but it’s also super impractical and the things it’s supposed to protect against are extremely unlikely.
But ok, more security isn’t a bad thing. But why not make it an option, like SELinux for example? That way users can choose a degree on a scale between security and convenience that suits their use case and circumstances. Why make it all or nothing?
It’s a valid concern IMO. Any application on X11 can install a key logger, record your screen, and influence other applications in a myriad of ways. With open source software from a trusted repository, this is not an issue, but an increasing number of people run random binary blobs from Steam, the Snap Store and Flathub. I am 100% certain that some less-conscientious publishers are already using X11 features to build ad profiles of their users; it’s a matter of time before the first ransomware will appear. The only sensible way to prevent this, is to confine applications to their own space.
But ok, more security isn’t a bad thing. But why not make it an option, like SELinux for example? That way users can choose a degree on a scale between security and convenience that suits their use case and circumstances. Why make it all or nothing?
Wayland simply doesn’t have protocols for most of this stuff. (Applications are supposed to use D-Bus and portals.) Developing new protocols that offer X11-like functionality is a large investment and will also need changes in the toolkits and apps to make it work.
xorg letting a malicious program to record keys is not a security issue, its a weakness
having that malicious program on the system, thats the security issue
if you are implementing a display protocol that aims to replace the xorg, the focus should be compatibility not fixing security weaknesses especially if you dont have any better solutions, and wayland does not have a better solution for global keys, compositors are just implenting it on their own hacky way
No one is advocating X11. It’s hard to have a constructive conversation about the shortcomings of Wayland when every apologist seems to immediately go off topic.
“I don’t want to listen because you don’t know the technical challenges. Oh, you have a long list of credentials? I don’t want to listen to an argument from authority. X11 bad, therefore Wayland good.”
OP even brings up Mir, but you never see Wayland proponents talk about why they think Wayland is better.
In the end this is also a pointless argument though. Like, sure: “Wayland is shit”, but also, “Xorg is even worse and ‘noone is advocating for it’”. And when there is no third alternative I guess we have to deal with (and improve) Wayland then?
OP’s expertise would then be better spent by contributing to Wayland.
Most of the post is an “argument from authority”: Trust me, I have a PhD and maintain my own X server, and I assure you that Wayland is a pile of shit!
It’s amazing that he’s so well qualified, even runs his own X fork, but isn’t volunteering to do any actual work to maintain the project.
Because that’s what this ultimately boils down to, isn’t it. Nobody’s forcing anyone to use Wayland or drop X. But, all the X.org developers have moved on to Wayland and aren’t coming back, and all the major DEs are also migrating to Wayland. So if you want to keep using X, you’re going to need to do the work that other people used to do for you.
For most users that’s a fairly empty statement, as most users don’t have the expertise to maintain X and window managers even if they wanted to. But apparently this guy is hot stuff; a highly qualified, highly experienced king of the display server world. So when are we going to see his X.org fork?
As swap is recommended just in case all RAM is maxed it’s better to have a swap partition as swap files have certain limitations when in combined use with BTRFS:
"subvolume - cannot be snapshotted if it contains any active swapfiles"
has a chance to fragment
has issues with hibernation (that I’ve personally encountered multiple times)
doesn’t this kinda defeat the purpose/benefits of using a swapfile?
This is true for all files. Is it a bigger problem for swap?
specificly swapfiles yes, for swap partitions nope
How long ago did you have these issues?
Dec 2022, was still using and testing with swapfiles then and said fuck it as it caused too much problems.
I can’t rule out user error till I retest and strictly “follow the guide to the T” as I made modifications while following the same Arch guide for swapfile with BTRFS
edit:
also for clarification, I’m still not sure which one is optimal/best as I initially thought that using swapfile was forward thinking for the future, I’m using and recommending swap partitions as it seems to be the easiest to implement once and use continuously without any problems atm.
The reason I use a swap file is so that I can have only one partition backed by LUKS disk encryption, rather than having to screw around with lvm which comes with its own performance overhead and all. I’ve personally never had issues hibernating to.it, but given how much buggy uefi firmware is out there I’m not surprised to hear that other have issues
I don’t see how swap has much chance to fragment. A swapfile has to be fully allocated up front and cannot be CoW. If it’s allocated well in the first place, it will stay that way.
The swap code doesn’t really do I/O through the filesystem. AIUI, it locks the file, gets the disk block #s from the FS, and after that it accesses those blocks directly.
Sounds like a heap of crap. X.Org developers moved to Wayland, they were the ones who made it happen. Now, I wonder where this dude with his XOrg Forks and PhD and shit was during all that 15 years it took to conceptualize wayland.
You all need a lesson in taking everything people say, including and most importantly their qualifications with a huge grain of salt.
Wayland has been working perfectly for years now. Many of the supposedly “impossible to implement” functions of the old hunk of junk Xorg were either found to be bogus anyways or have been made available on Wayland.
Sincerely– Someone who’s been using wayland since 2016
Most of the xorg “mistakes” are design choices in the x11 protocol and have been there since some MIT undergrad smoked too much ganja over Christmas break 1986 and wrote the implementation that became the de facto standard.
Not for every one. For example, I still get random black screens with only mouse trails, windows disappearing, and videos not playing properly. Why yes, I do have an Nvidia card, thank you for asking.
After finally realizing nobody is interested in EGLstreams, Nvidia seems to be on track to make their drivers less of a disaster for Wayland support, so thankfully it is bound to become better
I just want you to know, this isn’t a failure on anything other than Nvidia trying to force their own crap on everyone and failing
I'm on AMD and had so many issues with Wayland. A lot of games were straight up unplayable due to the amount of issues and some other applications straight up not compatible while scaling is also still a freaking mess. Saying Wayland has been working perfectly for years just feels like clownery and is kinda insulting to everyone who experiences those problems.
Interesting, what model is your GPU? I’ve been using Wayland for months on an RX 6650 XT and for about a year before that on an RX 570 and I’ve had so many less problems than I used to on X. Maybe I’m just lucky with my GPU choices?
This also depends on the desktop you use. GNOME is by far the most stable [In My Experience], and KDE spent the whole 5.x series getting their Wayland support into shape. What you’re describing could be XWayland failures (games don’t run on Wayland lol) and desktop environment bugs.
Depending on how long ago you’re talking about, your hardware, and your desktop of choice, things might’ve been improved a lot since the last time you used a Wayland session.
I made a post about my Gnome experiences already, which were just terrible due to how unstable the apps were and how it lacked a ton of even very basic features that I needed. So if their Wayland support is better, it's completely overshadowed by how shitty everything else is.
Most of the issues were a year or two ago, but I every now and then switched to Wayland to see if things got better and returned to X within like hours due to issues just around the "desktop".
Very good point. Mr x11 expert maybe seems pissed he’s gotta learn a new tech and refuses to, so will bash it and hope it goes away. But if they were an expert, they’d probably know the things you mentioned.
Using any UI application as root is a bigger risk. That’s because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.
So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.
Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.
Ideally you run the UI as a normal user and then use sudo to run individual commands as root.
Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.
There are non-UI applications with similar problems though.
Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.
nix is like the i3 of package managers. does it work sure but you’ll spend your 80% of your time learning code and configuration to make your sick packaging rice /sarcasm
That’s only true you succumb to the hardcore Nix fanatics and follow their recommended “declarative” way. However, Nix, as a package manager, is perfectly usable - and accessible - with the imperative way, without having to subscribe to their religion and learn their language and terminology.
In the imperative path, Nix is as easy to use as any other package manager, yet it still retains many of the unique Nix features such as versioned packaged, instant rollback, non-root user-based installs etc.
It’s a shame because Nix is actually really cool and very easy to use if used this way - and especially useful on immutable distros, locked-down systems or distros which have a limited number of packages - but unfortunately, most people are missing out because the fanatics keep preaching the declarative way as if it’s the only option out there.
Realistically it’s not super dangerous, and no you probably don’t have a virus just from browsing a few tech support sites, but you do eliminate your last line of defense when you run software as root. As you know, root can read/change/delete anything on your system whereas regular users are generally restricted to their own data. So if there is a security problem in the software, it’s made worse by the fact that you were running it as root.
You are right though that Firefox does still have its own protections - it’s probably one of the most hardened pieces of software on your computer exactly because it connects to the whole wide internet - and those protections are not negated by running as root. However if those protections fail, the attacker has the keys to the kingdom rather than just a sizable chunk of the kingdom.
To put that in perspective though, if there is a Firefox exploit and a hacker gets access to your regular user account, that’s already pretty bad in itself. Even if you run as a regular unprivileged user they would still have have access to things like: your personal documents, your ssh keys, your Firefox profile with your browsing history, your session cookies and your saved passwords, your e-mail, your paypal account, your banking information, …
As root, they could obviously do even more like damage like reading all users’ data, installing a keylogger or screengrabber, installing a rootkit to make themselves undetectable, but for most regular users most of the damage is already done when their own account is compromised.
So when these discussions come up, I always have to think about this XKCD comic:
They might have access to all that data once but a lot of the paths towards making that a persistent threat that doesn’t go away after the next reboot and most of the ones towards installing something even deeper in the system that might even survive a reinstall do require root.
I was trying to do that but I’m unsure what to edit to do that, since most tutorials are using either a Debian based or Arch distro.
I was using a similar guide, and it also talked about the locale.gen, but that file was never to be found, I just searched a bit more into that and this popped up. So it seems Fedora handles things differently, but now I’m unsure what commands to execute since I’m not sure the ones in that thread are also valid for me.
I was using a similar guide, and it also talked about the locale.gen, but that file was never to be found, I just searched a bit more into that and this popped up. So it seems Fedora handles things differently, but now I’m unsure what commands to execute since I’m not sure the ones in that thread are also valid for me.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.