So similar to kakoune? I tried that for a while, but it was missing some features so I went back to vim/neovim.
I need to know vi anyway, because that is available everywhere (as part of busybox), so using vim/nvim for bigger systems just fits.
So similar to kakoune? I tried that for a while, but it was missing some features so I went back to vim/neovim.
I need to know vi anyway, because that is available everywhere (as part of busybox), so using vim/nvim for bigger systems just fits.
What about Lua/Luajit?
In most scripting languages you have the interpreter binary and the (standard) libraries as separate files. But creating self-extracting executables, that clean up after themselves can easily be done by wrapping them in a shell script.
IMO, if low dependencies and small size is really important, you could also just write your script in a low level compiled language (C, Rust, Zig, …), link it statically (e.g. with musl) and execute that.
Nothing about mod support or releasing the toolkit, like they did in DA:O.
I started using Fedora Silverblue on a tablet, seems to work fine so far, but requiring a reboot in order to install new system packages is a bit cumbersome and the process itself takes a while, but ordinary Fedora also doesn’t win any races when asked to install a new package
I think switching to FCOS or Flatcar on servers that just use containers makes sense. Since it lessens the burden of administrating the base system itself. Using butan/ignition might be unusual at first, but it also allows to put the base system configuration into a git repo, and makes initial provisioning using ansible or similar unnecessary. The rest of the system and services can be managed via portainer or similar software.
I also do not have long term experience with FCOS, but the advertised features of auto-update, rolling-release, focus on security and stability makes it a good fit for container servers, IMO.
An alternative to Debian on servers might also be Apline Linux. Which also has more a focus on network devices, but some people use it on a desktop as well.
If you have many different systems, and just want to learn to operate them all, maybe NixOS might be interesting. Using flakes, you can configure multiple machines from just one repo, and share configurations between them. But getting up to speed on NixOS might not be so easy, it has a steep learning curve.
So generally the pro of coreboot is that it is open source, but the con is that it is open source.
What I mean by that, you can fix any issues yourself, however, if you are unable to do it yourself, you have to wait until someone does it for you and often what features are available and stable are a hit and miss.
Compared to proprietary bioses, the company has some kind of standardized process for developing the bios. So you often get want you would expect. However, if the money flow from the pc vendor to the bios vendor drys up, you, or the community of owners. will not be able to fix any issues.
Linux support should be the same, regardless if you choose proprietary or open source bios. But that depends on how well the coreboot was ported to the platform. So officially supported coreboot bioses are likely better than others.
Personally, if all other attributes are equal, would go with coreboot, because I like to support vendors that offer that choice, and IMO a open source solution, that you can review and build yourself is intrinsically more secure than a binary blob, where you have to blindly trust some corporation. But other security minded people might disagree, which is fine.
Sure, it is largely the fanbase, however I also think that the game industry seems to sometimes do somewhat of a “woke-washing”, meaning opically supporting the LGBTQIA movement because of financial, shitstorm-prevention or other reasons than just wanting to create more diverse and inclusive games.
For instance I like Hogwarts Legacy, but it also takes place in the Victorian era, and it seems to project the modern tolerant society ideals onto the wizarding world of that time.
Depicting the society as inclusive and diverse is somewhat history revisionist. If you play as a non-binary or trans person at that time, then you should have to deal with prejudice and marginalization, otherwise it is just “woke-wash” the history.
So, IMO there are some cases, especially in historic (fantasy) games, where injecting modern ideals and standards might not fit or needs to be better addressed, than just let it be cosmetic.
They shouldn’t do a halfhearted job.
Well… cults with an exit are just groups of people.
Apple looks more like a cult, similar to Scientology. Linux user as well.
Check if you find anything about this in the kernel log (dmesg
).
Depends a bit on what the default cloning url will be. If the domain is in control of mozilla, which forwards it to github, then fine, if most people start using the github url, then it is still a vendor lock in, because many people and projects will use it, and that is not so easy to move away.
Update: To the people down-voting my comment, I would love to hear why you either disagree with me, or find that my that my contribution to this discussion is worthless.
The upstream URL of a project or repo is important, because it will be used in other projects, like in build scripts for fetching the sources. If a projects changes that URL in the future, and the old URL is no longer available/functional, all those scripts need to be changed and the old versions of these scripts do not work anymore out of the box.
If the project owns the URL, then can add redirect rules, that might help alleviate some of these issues. I don’t think github allows projects that move away from it to do that. So this is a sort of vendor lock-in. The project needs to maintain the repo on github, because they want to break the internet as little as possible.
Its a bit old, but the last reports for DA:O on wine look good: https://appdb.winehq.org/objectManager.php?sClass=version&iId=33926
I don’t know why you are so aggressive.
You made a good point, this is actually DLC, I just forgot about it.
I bought BG3 when it was in EA, so I got this DLC automatically, so I never really thought about it recently, I don’t even remember seeing it on any shop front.
But now that you mentioned it, I think I thought that they should probably release it for free for everyone at that time. Just like CDPR released some cosmetic ‘DLC’ for free after launch.
If I had to buy it, I probably wouldn’t.
AFAIK, modding is the main reason for Skyrims long term success. Sure, it did its part in inspiring people initially, but what keeps at least me coming back is my interest in trying new mods.
But it also didn’t start there with Elder Scrolls series. Morrowind, Oblivion, Fallout 3 and New Vegas use a very moddable predecessor of the Skyrim engine, and thus build the community up for Skyrim and later games.
Modability of KC:D was rather limited, so there isn’t a community around as big as the Skyrim one. That means with Skyrim, you get what you can mod into it, while with Kingdom Come, you mostly just get what you buy.
So I don’t expect it to be the next Skyrim, but never the less I am interested in it.
I don’t remember that. AFAIK Larian has not made, and will not make any DLC for BG3.
What do you mean?
Not the drama itself should influence your judgment, but how they will deal with it.
Whenever people work together on something, there will be some drama, but if they are dealing with it, then that should be fine.
Nix and NixOS are big enough, that even if it fails, there are enough other people that will continue it, maybe under a different name.
Even it that causes a hard fork, which I currently think is unlikely, there are may examples where that worked and resolved itself over time, without too much of burden on the users, meaning there are clear migration processes available: owncloud/nextcloud, Gogs/Gitea/Forgejo, redis/valkey, …
No, the consumers are never to blame for stuff like this!
This is something that is just that we get told by the people that are lying about and hyping up a product, putting up manipulative incentives for buying it before letting us inspect it. Then releasing trash, but still appealing on our empathic nature and promising that it might get fixed later. And when things turn to shit, then it is our trust and empathy, willingness to support them, that is to blame for it. No!
If the industry exploits our good and trusting nature, then we need to fight them with regulation and laws. Our civilization and the human nature is built on trust, and that should not be undermined by short profit oriented, exploitative companies or business practices.
A customer wanted to used Teams couple of days ago, I couldn’t make it work on my companies laptop, trying three different browers. I just loaded an empty white page.
I had to use a laptop from another customer, that also use Teams, to do so, which worked, but gave me toothache, in terms of security.
Both laptops where on the same network and both ran Debian and I tried the same browsers, without any plugins and jitsi-meet works fine on my companies laptop. So apparently the system need to be specially configured for Teams to work.
I am staying with jitsi-meet, thank you very much.
The customer, I got the laptop from, knew what they did and provided managed Linux Systems for people to be able to use Teams.
“next-generation PC” whatever that means.
I do hope that there never will be a next generation of PCs, i am quite happy with my old-gen Ship-of-Theseus-PC, where I occasionally replace some parts.
As I said, it is not impossible to move away from gh compared to many other cases in other industries, just that it is more difficult than necessary because vendor-lockin is allowed.
If vendor-lockin was illegal, companies had more incentives to use established or create new standards to facilitate simpler migration between software stacks, without changing the external interface.
For instance allowing your own DNS name to be used as the repo/project basepath instead of enforcing github.com, Allowing comments, reviews, issues and pull requests via email or other federated services, instead of enforcing github accounts to do so, providing documented, stable and full-featured APIs for every component of their software, so that it is easy to migrate and pick and choose different components of their while stack from possible different vendors, …
There are so many ways that would improve the migration situation, while also providing more ways for other ideas to compete on a level playing field. If a bright engineer has an idea for improving one component from github, they should not be required to write a whole separate platform first.
AAAA games are clearly inferior to AAAAXY games.