• 2 Posts
  • 112 Comments
Joined 1 year ago
cake
Cake day: June 8th, 2023

help-circle




  • I’d argue it’s better to use actual alternatives. Half of the issue with free and open source software is that it’s userbase is too small. If more people used it, it could actually improve in many ways.

    Lets take gaming on Linux as an example. The userbase on steam is somewhere around 5%. So there is almost no incentive for developers to make games that run nativly on Linux. Its actually easier to run the games in a compatibility layer then to get a Linux port of a game. And although wine and proton work incredibly well, sometimes even running a game better than on windows; a Linux native version of every game would be ideal. Which will never happen with such a small userbase.

    Next you have the terrible business practices of these companies. Even if you use the pirated versions. You are in their ecosystem and their community. You increase their profitability and their stock price simply by continuing the industry standard.

    Pirated versions of software like this is excusable if you need it for work or sometihing. But imagine if instead of staying with the status quo, you use and help improve actual free and open source alternatives. Versons of software that don’t steal your data or monetize how you use it by selling your input to others or stealing it for “AI” datasets.

    Imagine using free and open source software that gives you feedom because your data stays on your devices, your creations belong to only yourself or who ypu choose to share it with, and you work with others to improve it; even if it’s by just submitting bug reports. Imagine using something like that which you find so altruisticly beneficial that instead of pirating the software that has no respect for you, you donate money to the devs of free and open source software. Yes, I’m a pirate. But I do donate money to the right causes and something that protects my freedom is worth both my time and my money.







  • As someone that just started modding and playing FNV for the first time about 2 weeks ago in linux, I must say this is one of the best mods for FNV and if you are planning to play the game I would highly recommend all the Viva New Vegas mods including the extended mods. With New Vegas Reloaded installed afterwards. Also I suggest you use a user generated preset for Reloaded. The Reloaded mod fixes a lot of issues I had with Viva New Vegas only and it adds many more features than I thought it would. It also seemed to have made the game run with less crashes too but I would still recommend CASM with MCM to improve the autosave functionality of the base game.

    While I agree that the use of discord is mildy infuriating. I’d like to play some Devil’s avavodo for a moment as someone that uses git almost everyday and teaches trunk based development.

    1. Not everyone knows how to use git. As a modding community they want outside contributions from anyone that is willing to put the time in and make as low as a barrier to entry as possible.

    2. Most of these modders are using windows and even just installing git on windows isnt that easy for the average windows user. Infact i only just recently fugured out how to get mod organizer 2 working properly on linux so I could mod FNV using modorganizer2-linux-installer. For the average windows user, needing to make a git commit to contribute to a modding comunity would be more than mildly infuriating. So I especially see the user generated presets for this never leaving discord unless some kind of pipeline / serverless function was inplace that took the discord file uploads and did a git commit for the user.

    3. Most of these builds are not plaintext and would not benifit from using git versioning. They should also probably make use of use git lfs considering their size which even less people understand how to use lfs compared to normal git.

    I think the easiest solution is to try to copy both the stable and the nightly builds to their github on their own respective branches. And make set them as releases. Idealy this would be automated using guthub actions. This is not a trunk based development approach, but neither is having nightly builds and it would take time to change development philosophy.

    The user generated presets however will take a bit more consideration before moving to github as anyone can upload them and they are made often. But this ultimately should also use github actions and be commited to a different repository possibly in the same organization (or what ever github calls it) as to keep a bit of distance from the official releases.





  • I was running xfce for a while on my old laptop with only 8 GB of ram. Thinking that it was the least resource usage DE. (Which i think it still is but i havent tested in a bit).

    Then i got a new pc and tried kde and to my amazment it used just a tiny bit more resources than xfce did on my old laptop. I then installed kde on that old pc and it ran perfectly well. kde had a lot more QOL compared to xfce in my opionion, with none of the jank.

    Its intersting how much different our experiences are.

    What would you recomend for a DE?



  • I don’t understand why there is a bull market.

    Wouldn’t the latest CPI report mean that the FED is less likely to lower interest rates which in turn would mean the high APY cash accounts are going to stay in effect for longer? Meaning a 5% APY on liquid cash without risk.

    The only reason I can think of is that Boomers are trying to maximize their retirement funds and not reading anything, not even headlines.

    But this wouldn’t take into account the large banks and firms that are really leading the bull run.

    Is this really just because of the idea that there is a potential for “AI” to increase productivity?

    None of it makes sense to me, but I’m not an economist.



  • In TBD, it’s not a “release” until its production ready. The methodology and philosophy doesn’t prevent you from developing multiple feature branches at once or even deploying a work in progress feature branch to a dev environment.

    All TBD requires in that case is once the feature branch is production ready, it’s merged to the trunk. You may need to add a feature toggle if there are multiple release like for different architectures. And you also might benefit from using git tags and deploying to production from a git tag instead of the most recent commit on a branch.

    Exactly what you need to do is going to depend on the project’s exact needs but TBD is totally possible in that example.