Is the copied file going to a usb? Is the usb fake? Otherwise I’m pretty sure your source is bad. Probably the disk sector if you’re sure the file was at some point complete.
Something like btrfs probably does block cloning or similar so a copy to the same disk probably just points at the same disk blocks as the original.
fpm is not a complete solution. It just creates a package from your files, however you need to build them in the environment of the distribution where it is supposed to work, with the same versions of dependencies. OBS is the best solution I know, but with it you need to write packaging scripts compatible with each distro you are targeting. It is quite time consuming and requires a good knowledge of native packaging tools.
You can also use any CI system that is able to execute builds in containers with your target distros. This requires a bit more scripting (just a bit), but modern CIs are easier to setup than OBS in case you need your own instance. This also allows you to use your favorite VCS and workflow you are comfortable with.
I like Netdata because it’s web based, has a large number of metrics, you can pan/zoom the graphs, and it doesn’t use much CPU power. Console UIs are nice but they’re more limiting than something web-based.
Chimera aims to eliminate legacy cruft where possible to deliver a modern, general purpose, fully featured operating system that is simple but complete.
While on their Community page:
Our primary means of communication is IRC. […] We ask you to refrain from using advanced Matrix features, such as reactions, editing, message removal, markup and multi-line messages while using the chat. This is because users on IRC side will either not see that or it will clutter the channel. Stick to simple, plain text messages, like you would if you were on IRC.
Do you think they’re aware of the irony of relying on crusty old IRC while touting about Linux having legacy cruft and their code being better?
@entropicdrift would you mind elaborating how the choice of a chat protocol is connected to technical aspects of an operating system? i feel like i'm not galaxy brain enough for that
Over on the OS side they’re dedicated to making a fresh start and leaving behind crufty old standards, but on their chat server they’ve limited their chat tech to the capabilities of IRC, a chat protocol so old it pre-dates Linux.
I’m about to jump from Ubuntu back to good ol’ Debian. I was planning on testing, but I’ve heard a few times recently that people are running unstable for day-to-day desktop use. Is there any particular reason you went with unstable instead of testing? Any issues so far?
I’m using debian unstable as a desktop OS on all of my 3 regularly used systems: 2 notebooks and 1 desktop. And debian 11 on citrix virtual desktop at work. debian stable on around 200 servers.
I rarely have bigger issues in my day to day usage of unstable which includes surfing, gaming and coding. at the moment my bluetooth headset microphone doesn’t work, which i guess is due to some changes to pipewire but only on my desktop. both my work and private notebook seem to not have issues.
this is one of the worst problems i had in the last 8 years. other then that, if you use apt-listbugs to exclude any updates with serious bugs by pinning them until a bugfree version gets released, you wont have any more issues then you get with arch for example.
Void was a great experience last time I used it. A minimal set of tools/software were installed(for some reason, I dislike ISOs/distros that fill everything from Libre Office to an FTP client in it; I will just download them if I want it), the package manager seemed pacy enough and system was fast. It is definitely one of the better distros I have tried.
It would be excellent if he could get fully funded through Patreon. I chipped in a bit, and I don’t even use it–looks like a cool approach, though. There have to be enough enthusiasts out there to pitch in enough cups of coffee to cover his dev time.
I’m not sure how much of a cut Patreon takes, but it seems like there would be better options out there for non-profit foss projects, no? Liberapay maybe?
Even though librapay doesn’t take a cut, the providers they use do. Someone is taking a cut; I just try to make it smallest with the least-shitty company. :) But it’s tough, as a buyer, to find ways to pay people. I really wish creators would have obvious tip jars, and there was a standard way to tag them in HTML so search engines could find them.
Interesting take. I wonder if the amount of platform dependent bugs is generally that low for games. I’m a developer, but not a game developer. I would assume that platform dependent stuff comes into play a lot more, when using shiny new tech like direct storage, which is probably used more by AAA titles and less by indie games?
I made games primarily for Windows which we also compiled for Linux. It is mostly input/output stuff, aka hardware issues. That is, audio issues, input issues, storage issues, dependency issues. Modern game engine mostly handle the rest. It wasn’t such a big deal to fix, but most gamedev lacked experience with Linux, and most projects are already over budget and late, so fixing Linux for an extra 2-5% of sales didn’t make much sense at small scale. Proton kind off fixed all of this tho.
In my somewhat limited but relevant experience, the amount of platform specific bugs is indeed that low. I mean, there’s of course a layer of platform-specific low level stuff which is highly subject to platform specific issues, but once you go above that layer and into game code proper, most bugs are just bugs.
I didn’t fix 400 “Linux-only” bugs, but I did fix dozens of “seems Linux specific” and “only happened when at least one Linux client was connected” bugs, and a grand total of 2 were caused by platform differences. And of those two, zero were Linux specific. The platform difference in this case was about how different compilers optimise non-crashy types of UB.
Of course, we don’t want UB at all so the fix is to remove it.
The difference is money. Vulkan is an incredibly terse spec compared to dx12. You’d think that would make it much more consistent to work with, but really, it’s all it can do to keep up with msft and IHVs who pour money into coaxing AAA devs to use dx12. Then, even when the app gets something wrong and causes issues for end users, the IHV just makes a special case in the driver to correct it, because having a big important dx12 title run correctly on their hw is important to sell units.
Meanwhile, the same IHVs barely bother to support anything beyond the basic vulkan requirements, because it doesn’t gain them anything to do more. If a vulkan game experiences issues, IHVs don’t care because it won’t sell well anyway.
Yes, and the primary reason any of gaming on Linux is viable (steam deck, proton, etc) is due to Valve dumping money into it. AMD probably didn’t care about the miniscule number of chips they sold to Valve for the deck, valve just wanted a vendor who had the performance, and had decent Linux support.
But Valve is the one eating all the vulkan costs that msft normally eats on the dx side. To be clear, it’s never out of the kindness of their hearts, it’s purely because a msft dominated gaming ecosystem on PC is steam’s biggest weakness. They don’t want steam on windows to reach the point of EGS on the apple store.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.