Docker image layering and nightlies for the heavier installs has worked pretty well for me. Dependencies from things like npm, composer etc are all build time still but more of the base stuff is on a weekly build cycle. We just do notifications if the nightlies fail to manually resolve it which is very very seldom
radau
joined 2 years ago
I've been loving Bazzite as well, I didn't have to install ANYTHING to have it working, no Nvidia drivers that try to force that stupid Game Ready crap, just installed the OS and steam and my games and it worked, it's better than windows with ninite ever was as far as getting a usable OS was.
The Steam Deck was a big convincing point for me, after seeing how well it worked I just had to go for it. Last time I tried switching to Linux fully for gaming was ~2012 and it was a LOT rougher, Garry's mod worked but had issues with filename casing and things like that
I didn't go through these phases I just pray to the Omnissiah and sacrifice an HP printer when it doesn't work
I deployed a ton of changes wish me luck
What issue are you having with Battlefield 3/EA? I just installed it last week I think I did it via Lutris
Proton with a domain you control and use their Simplelogin which you can self host down the line should there be a rug-pull event. I think you need to manually export this so make it a habit as you add them!
You can put your eggs in one basket, just make sure you have a plan B if the basket catches on fire, using their domain in my eyes you're going down with the ship, if you control it you're just repointing records to a new host and getting simplelogin going.
This is part of the reason I like to keep ALL of my emails on disk still as well, if you can't decrypt your mailbox for some reason they're about as good as gone.
I switched off of BSD about a decade ago so I can't weigh in on it's current state at all. I generally avoid Flatpaks at least in Qubes. I do have a template that supports it but it's only running on my Music VM currently which is offlined, the rest follow the traditional template+AppVM approach which I keep updated on a schedule.
I have never operated under the assumption that flatpaks are sandboxed or secure because they really aren't. It's a system to bundle packages with your software without contaminating the host environment. The big issue really is in the package maintainers shipping outdated packages, containers were never a security measure in my eyes due to the shared kernel and especially not with the default share of the homedir for flatpaks. If you need that kind of isolation you really need a VM. I treat them as a standard install personally without any expectations of isolation, and really with Silverblue I'm leaning more towards installing apps directly in Distrobox and exporting them to the host, it still has the shared homedir issue but you're getting up to date packages in a desired environment that you fully control (this is both good and bad since maintenance is on you).
I think it's a good idea if there were stricter requirements, maybe vulnerability scanning as a requirement to releasing and pulling stale flatpaks after a period of no releases to start. It's difficult to appease everyone in this situation and breaking changes would be inevitable so it is difficult to fully solve now that it already exists as it does. I do think supply chain attacks will only get more common though so they definitely need work.
As someone who does a lot of infrastructure work on AWS, Azure, GCP etc, it's just about the only operating system I'll use at this point for that kind of work. The isolation I get per-client and per-environment is unmatched. There's a little more upfront work to get everything the way you like (putting ZSH configs on /etc/skel of your templates for example) but once it's set up it's really solid. Having the windows named and color coded really helps me keep from crossing wires when stuff gets chaotic and I'm jumping around a lot.
It's obviously MUCH worse at certain things such as CAD, but they're still workable in it. HVMs can remedy this pretty easily but it's not quite as seamless as the standard Qubes unfortunately but it's progressed a LOT in a short amount of time so we'll see what the future holds!
If you've used it in the past it's MUCH better now but there are still hiccups and certain apps you have to force to use X but they do typically run well still, at least the ones I've encountered
Immutable was the only thing that got me to switch back from QubesOS on my desktop. I was doing Qubes with a win10 HVM with my 3070 passed through and it was a couple frames off from native performance. Still keep Qubes on my T480 for infra specific work but my "dev" machine with no creds is the desktop now.
Couldn't get the performance quite right for a Linux based HVM and was wanting the HW accel for some of my work (CAD, figma) so I loaded Bazzite with KDE which runs Fedora Atomic and it's been amazing for both gaming and work.
Distrobox with boxbuddy and rootful containers where needed has been extremely pleasant and they all live as a subdirectory of my home with a ZSH install script I have to load the terminal styles I want into any new containers. Any apps you install in the container you can export to your start menu and launch seamlessly without tainting your host with any weird dependencies you might need for a project.
We use ddev a lot so needed a rootful container for Docker but other projects I just treat like a VM almost (R projects for instance), install whats needed to get an env going real quick and fire up the IDE in the container and get to work.
EVERYTING I care about is in /var, including my home which makes backups and snapshots stupid simple which I love coming from a traditional Linux distro
If everything extracted you should be able to add the main .exe from the game folder to Steam now as a non steam game and use Proton that way (or do similar via Bottles or Lutris if you prefer).
Tricky part sometimes depending on the game is getting the right exe. I like bottles since you can do the Run executable to install which auto adds the .exe to bottles at the end, I needed this for Boltgun since I was picking a way wrong exe.
The same reason they won't let you buy the dealership scan software for under 10k. Almost every maker has an in house scanner and due to standards they only need to provide certain data to non dealer level tools and I believe the standard only exists for gas powered vehicles that need to provide OBD2 data. Plenty of makers (BMW is horrible about this) stuff away data where a normal obd scanner just won't access and it's gotten much worse with the overuse of CANBus (I sure love when my trunk lid sensor prevents my fucking car from starting).
Thats where your snapon and other third party scanners start bringing a gap, but even those are extremely pricey and need to be updated constantly and even those usually won't do EVERYTHING.
Fwiw the cheapest and best way I've found is basically to pirate the dealer software and get a compatible knockoff scanner (vxdiag for example). I have Ford IDS and a couple others this way but assume that the software is gonna install something malicious and dedicate an old Thinkpad or something to it.
Depending on the age of your vehicle something like Torque Pro is extremely useful. I have mine monitoring transmission temp, long and short term fuel trims, O2 sensor signals, voltage, mass air speed, intake temp. It's more than enough data to see something coming long before it becomes an issue.