Yeah, that’s bizarre. I’d never have guessed /home was created by tmpfiles
Yeah, that’s bizarre. I’d never have guessed /home was created by tmpfiles
There are reasonably frequent rebuilds of basically all packages as new versions of the compiler, gcc, come in
To expand - DirectX is a proprietary Windows solution. Any time you pick it on Linux, it will run through a translation layer
OpenGL/Vulkan are cross-platform
OpenGL is to DirectX 11 as Vulkan is to DirectX 12
Microsoft kept the same branding, but also followed in Vulkans/Metals footsteps of using lower level calls to the hardware. This makes the graphics drivers simpler, and can be way more performant because the CPU doesn’t have to do as much
Hey! Thanks!
I’ve installed Aurora to my new drive based off the comments here so far, and it’s been pretty smooth bringing my configs over :)
Immutable is new to me, so I’m wondering how you manage host daemons and cli applications, such as mpd for music and password-store for password management
Is the best practice to keep one Fedora <current release> distrobox with them?
Also, are there any issues with upgrading a distrobox to a new major release over time?
So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?
I also see brew
as another option. Perhaps that’s the preferred way for those types of tools? However, it seems like the system upgrade script updates distrobox and not brew?
Sorry for the rambling question - just trying to understand best practices with an immutable distro 😅
The developer image, dx, includes rocm-hip and rocm-opencl:
https://github.com/ublue-os/bluefin/blob/main/packages.json
The packages under “dx” are the main reason I’m considering it over stock Fedora
How does bluefin fit in the dependency chain here - is this just the repository that builds official uBlue images?
Part of my confusion is trying to understand how these projects are related to each other
Edit - oh, I guess bluefin is the Gnome variant
Wow! I didn’t expect sched_ext to be accepted based off historical precedent of not allowing multiple schedulers
I thought the focus would be on optimizing EEVDF now
Not to mention that even in the 60’s Nixon’s cabinet has stated he specifically started the war on drugs and marijuana in order to imprison black people and anyone against the war.
“We could arrest their leaders. raid their homes, break up their meetings, and vilify them night after night on the evening news”
They’re saying that it only works if your browser is installed natively and your password manager is sandboxed, which is the exact opposite of what you’d want
The browser is the vulnerable software that needs sandboxing
Both being sandboxed would be fine, too
The software has improved a lot since I got the phone in 2022 (I pre ordered it in 2017)
I would be willing to use it as a daily driver if it had better battery life
As the other poster said, the camera is kind of crap, but I don’t take many pictures. At least you don’t have to manually set the exposure/balance/focus to take a picture now, though
The updater has been a little flakey and I’ve just fallen back to update via command line frequently
Fairly thick, but it feels quite sturdy to me. SD card slot and headphone jack are great. Charging speed is kind of slow
Netflix is limited to 720p on Linux due to the DRM they use… maybe OP was confused because of that?
They do when Qualcomm wants to use their processors in Android phones
Qualcomm has, so far, been extremely against upstreaming drivers. Google has told them they can’t touch the kernel anymore over it
If that’s actually changing, it could be huge for a real alternative
I don’t use PIA, but /opt and /etc are both r/w in Silverblue/Kionite
At a high level, microkernels push as much as possible into userspace, and monolithic kernels keep drivers in kernel space
There are arguments for each e.g. a buggy driver can’t write into the memory space of another driver as easily in a micro kernel, however it’s running in the same security level as userspace code. People will make arguments for both sides of which is more secure
Monolithic kernels also tended to be more performant at the time, as you didn’t have to context switch between ring 0 and ring 1 in the CPU to perform driver calls - we also regularly share memory directly between drivers
These days pretty much all kernels have moved to a hybrid kernel, as neither a truly monolithic kernel nor a truly micro kernel works outside of theoretical debates
There was one on Reddit - I came to see if someone linked one