I switched to VALinux in 1999 when I got tired of bringing my HP workstation home every day. Prior to that I has using various unix workstations running X10/11.
I don’t know if I’m ready to switch my main PC over to Linux just yet but I may give it a try with my media server PC. I mostly just torrent and run Plex on. Would be a good environment to test it in. It’s basically just a PC made from old parts and it’s running windows 10 right now.
Got a new M.2 drive and installed Linux on it, still run windows on my old disk (no dual boot, only go to bios when I need windows).
Experience has been amazing so far, biggest issues for me are the following
Had to get used to Gimp instead of my very legally acquired version of Photoshop
Discord screen share does not have audio and is laggy as hell (an alternative discord-screenshare application exists but gives my voice a 1-2 second delay which upsets my gf when we’re in voice, although it can stream entire desktop with audio which is amazing for watching shows together)
Some games with anti-cheat don’t work, so if I want to play those I still have to jump on windows.
No HDR (but it looks to be coming to KDE and Cosmic soon)
Apart from this the experience has been amazing. I’m using Nobara and mostly gaming. As a dev terminal, scripts and ssh to my raspberry pi:s is just such a seamless and nice experience.
Had your same exact issue, and after jumping through hand-made solutions and countless clients i finally found a client that works perfectly out of the box for screen sharing with audio, has no other issues and comes with the big plus of having customization plugins Vesktop (i think its on flathub too so if your distro ships that probably get it from there).
Had the same issue here too and yes, while my “main” game got recently proton verified and i could finally get totally rid of windows, there are some few (BattleEye mostly) games with no anticheat support.
I would recommend using Vesktop instead of the official client - it’s faster, has better privacy, and best of all, screensharing including audio works like a charm.
You could run your games thru gamescope - and as a bonus, you can use features like FSR for better quality or performance.
What surprised me especially is that it was seemingly so simple to compile and boot a modern Linux kernel and graphics drivers for this obscure >10yo CPU.
I have a lot of respect for Valve for making Steam have such good Linux compatibility. I still haven't found a game I couldn't run (though I don't play a ton of games).
apparently having all the logic inside firmware (like Nvidia does)
Based on this part of the quote, the nvidia implementation has a lot of the functionality inside not open source binary firmware blobs. And that includes the functionality that the HDMI forum wants staying secret. It’s in the closed source firmware, so this is ok, since the open source part only has to send instructions to the firmware, and not include the implementation.
AMD has less functionality inside the firmware. Which means the drivers are “more” open source. But any proprietary stuff that the HDMI forum wants staying secret would have to be in the open.
Separate daemon & GUI processes… Permissions aware… Modular installation of modprobe config… It looks like the author understands the basics of designing a tool like this. Nice.
I have a couple of reservations from a security perspective, though:
The daemon and GUI are the same executable, which means a lot of complexity in the binary that runs in a privileged context. I would suggest splitting the daemon into a separate, minimal binary.
Wow I when you said 268 dependencies I figured JavaScript was involved…
Is the culture of Rust/Cargo getting as bad as JS/NPM these days or is this developer just using an insane amount of dependencies? I don’t have any experience working with Rust so I’m genuinely curious. I stay away from JS in part due to the insane amount of dependencies every non-trivial project has.
I’ve built projects in many languages and other than a few JS/React/ReactNative projects which seem to have unavoidably massive node_modules folders, I’ve never had more than maybe 10 dependencies in a project ever…
Is the culture of Rust/Cargo getting as bad as JS/NPM these days or is this developer just using an insane amount of dependencies?
From a quick glance through the files, I see maybe a couple dozen direct dependencies. That’s not what I would call conservative (especially for a privileged daemon) but the bulk of those hundreds seem to be sub-dependencies.
I’ve seen similar in the other Rust projects that caught my attention. I suppose this is a predictable result of Rust’s Cargo culture: When pulling in other people’s code is convenient, automated, and normalized, it tends to happen a lot, and the transitive nature of dependencies amplifies the effect.
So even a small project can easily include code from hundreds of random people other than the author, with practically no accountability, as we see here. And since it’s a long tail of small and often obscure projects, rather than a handful of well-known ones like a standard library, there is little hope of meaningful auditing.
There also seems to be a culture of statically linking all those dependencies. That means security patches will never reach a user through OS updates, and with so many dependencies involved, chances are slim that every upstream vulnerability will be patched on the user’s machine soon after it’s discovered (if ever).
I would find Rust more appealing if it had a standard library (and maybe a few high-profile well-maintained external libs) comprehensive enough to cover most needs, and if the tooling and culture encouraged minimizing dependencies. I think the former might develop with time. I fear the latter might not ever appear.
I’ve been thinking about learning Rust after hearing about it’s benefits, but was put off by its ugly type syntax that I hate from C++ and the whole “fighting with the borrow checker to do simple stuff” thing. But now it seems it also has the terrible bloated dependency culture I hate from JavaScript too!
IMO any security benefits from the increased memory safety are immediately nullified by the security nightmare that is hundreds of statically compiled dependencies…
I guess I’ll keep waiting on the sidelines and see how the standard lib and dependency culture evolves.
You’re not alone in finding the syntax awkward and ugly. :)
Rust’s promise of lifetime management that can (with help from the programmer) be guaranteed correct is very appealing to me, but that feature alone is not enough to justify excessive code complexity or bad ergonomics.
IMO any security benefits from the increased memory safety are immediately nullified by the security nightmare that is hundreds of statically compiled dependencies…
Rust undermines itself in another way, too: A systems programming language that’s difficult to use encourages switching off the safety features when they get in the way. That’s frowned upon by the community, but the incentive is there, so it happens nevertheless. The result: overly complex software that’s annoying to write/maintain and doesn’t always deliver on the language’s defining promise.
And then there’s the fact that not all dangerous bugs are solved by memory safety. It’s no panacea.
I guess I’ll keep waiting on the sidelines and see how the standard lib and dependency culture evolves.
If you’re interested in something that improves on C++, you might have a look at D. The basic syntax is similar, the advanced syntax is better, it offers memory safety tools less burdensome than Rust’s, and has an optional garbage collector. I find the standard library a bit rough, but an improved next edition is in progress. The dependency management tool (Dub) supports not only libraries from a community repo, but also OS-provided libs, git repos, and plain old directories. After using it actively for a month or so, I feel the language itself is sane, and the maintainers seem to be making good decisions about polishing it up in future versions.
Is the culture of Rust/Cargo getting as bad as JS/NPM these days
Thanks for saying it.
When I see some rust projects, they looks like they where managed by JS devs (“1 need, 1 package”) that want to do compiled language… The amount of dependencies can be utterly insane.
For me, it mostly means rust have a strong package system, not that rust have good devs.
I’m doing Python at work and you have to use a many pypi package for financial reasons (yet, I restrict myself as much as possible), but seeing this mindset is scope specific open source project is crazy.
All of this does not means all rust (or JS) devs are bad, its just a consequence of bringing code to the masses: Its a good thing in many way. Lets acknowledge this and not being impressed by badly engineered dependency choices.
Will probably get flamed to death for this, but… a few months ago I’ve decided to try Ubuntu on an older Intel MacBook Pro, just to try it out after many attempts in the past. (Mac user here)
Then I tried to use the trackpad. After 30 minutes of fiddling I gave up. Say what you want about Apple’s UX choices, esthetics and business practices. But boy do they know how to produce a computer and UX combo that fits like a glove.
In comparison, the Ubuntu experience was like eating nails.
And before y’all go off; I would like to switch. I’m getting tired of Apple’s business practices.
After years of using linux distros and settling on an arch based distro for my daily use, I switched jobs and they allowed me to have “linux” as my laptop OS.
They put Ubuntu 22.04 LTS on the laptop. Admittedly I hadn’t used it for a few years, maybe 18.04 outside of server use cases maybe.
The experience is horrible. It throws errors about Ubuntu, about Visual Studio Code or any program every hour, without those programs having any trouble whatsoever to function.
It reminds me so much of Windows, and even though I prefer it over that system, I can’t shake the feeling I’m serving the OS, rather than the other way around, just like in Windows.
And don’t even get me started on Snaps over DEB packages. Had never tried them before and I can say with confidence the hatred is deserved. Code didn’t even start up in the snap version and Firefox was so slow and laggy I was thinking the laptop was broken somehow.
No flaming here, but your first mistake was trying Ububtu - it’s not the best in terms of hardware compatibility, and they (Canonical) often make controversial software/development decisions, which makes it one of the most hated distributions in the Linux community.
Your second mistake was trying it on a Mac. Now don’t get me wrong, many people do run Linux on a Mac, but it’s not quite plug-and-play (compared to PC), and not everything may work as intended. Since you’re new to Linux, I wouldn’t recommend your first experience of it to be on a Mac. And to be clear, this isn’t Linux’s fault - since Apple (or whichever chipset maker) doesn’t provide Linux with any official drivers/code, the devs have to figure stuff out themselves by reverse-engineering stuff, and as expected not everything may work.
If you’ve only got Macs around and you don’t have the patience to troubleshoot Linux issues / read manuals etc, then the easiest way to try it out is in a virtual machine like Parallels or VirtualBox. The performance might not be the best, but at least everything should work out-of-the-box. As for the distro, since you’re a Mac user, you’d probably feel more at home with elementary OS. Other options you could try include Pop!_OS, and Zorin (the Pro edition even has a macOS-like layout).
Once you’ve tried Linux in a VM and decide you’d like to use it full-time, the best way to experience it is on native Linux-first hardware - basically PCs which come with Linux out-of-the-box, such as those made by System76, Slimbook, Star Labs, Tuxedo etc.
Yeah, I have a similar experience. I used a bunch of operating systems in my years. From C64 GEOS over Atari TOS Amiga OS, DOS, Windows (pretty much all of them since 3.1, except Vista and 8), Android, MacOS and iOS to Linux (several distros)
I don’t know why, but MacOS and iOS are for me just the worst user experiences. I feel completly trapped and helpless when using either one. Guess they are just not for me.
I used to greatly prefer MacOS until I switched my desktop from Windows to Linux and got comfortable there troubleshooting and installing things. Now I feel exactly the same as you with MacOS. Trapped.
Same. I hate the unintuitive keyboard shortcuts, the nonsensical drag and drop everything UI, and their ridiculously over complicated development system.
In case nobody has mentioned Asahi Linux yet, I’ll bring it up. I haven’t used it, but I have a friend who does.
Asahi Linux is a project and community with the goal of porting Linux to Apple Silicon Macs, starting with the 2020 M1 Mac Mini, MacBook Air, and MacBook Pro.
Our goal is not just to make Linux run on these machines but to polish it to the point where it can be used as a daily OS. Doing this requires a tremendous amount of work, as Apple Silicon is an entirely undocumented platform.
Asahi Linux is developed by a thriving community of free and open source software developers.
I believe they have a Fedora-based distro that should be solid for daily use, but again I haven’t used this myself.
Is this able to maintain its profiles between reboots? I use amd-clocks as its low profile set and forget unlike corectrl which would need to launch its ui each boot and ask for polkit auth
Yes, it maintains its config across reboots, it uses a systemd daemon that handles the backend. On most distros it should just work automatically, but if not you can edit the config.yaml file to set up your permissions there.
It’s great software. I’ll have to try editing the permissions because on Tumbleweed it only works when run as root. It complains that the service isn’t running as a user.
Also, I noticed that series 7000 gpus have serious problems under the most recent stable kerne when using an egpu setup. LACT shows that they cannot draw enough wattage, so they never get up to speed. Older gpus work fine.
linux_gaming
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.