They both use YAML, but I find the Gitlab doc to be better. If you don’t want YAML, you can try Dagger.IO which forces you to write code and can be run in any CI. Haven’t used it yet though as it requires a change in thinking that I haven’t managed yet.
Tell a normal gamer to install bazzite. I bet you the majority will stop at “put the installer on a USB stick” or any other step in the installation. From getting the PC to boot from the USB stick, figuring out MBR vs UEFI, or “install $distro” or “install $distro (OEM)”, partitioning, or whatever other technical stuff pops up. Most people want it to Just Work ™ . Nothing more, nothing less.
I am increasingly disheartened by the obsession over “Desktop SteamOS”. People don’t want Linux or even “a desktop computer”
My guess is that people how the installation will be made easy enough for noobs that they aren’t even aware they’re installing an OS, or it will be the default on devices. The latter is much much stronger than forcing some poor sod to deal with installing an OS and Valve also makes money in the process, which they can hopefully dump into Linux.
My hope is that the linux community wises up and learns about the power of defaults + not estranging noobs. The elitist “oh eternal september” and “but muh terminal” users can get fucked. Linux needs more people, not less.
Fucking… Goddammit Gitlab!
I don’t know if they need more funding or contributors or something, but that has been on the roadmap for years now. I think all they can federate now are stars.
But I do hope that it’ll arrive soon. Github needs a federated alternative and gitlab isn’t going to give it to us. Radicle already has federation, but only within its network, so not exactly optimal.
Gitlab CI is so far ahead of github actions… The only thing it doesn’t have is a marketplace, but otherwise it’s superior in nearly every aspect.
It’s not the self-hosting part that sucks about github actions 😉
I literally just need dumb search. No regex, no nothing, but just for that you now need an account. Especially on mobile, I’m not going to clone every repo I come across. It’s a hassle already.
If I really do care and dependent on the repo, I’ll clone it. Otherwise I just drop it most of the time or use a third party service. But ever since Microsoft bought github, it’s been really annoying.
Oh, that’s a pity. So there is no public instance? If not, I’ll just remove it from the list. code.onedev.io is thus a dogfooding instance?
What do you mean? Github has remotes and you can push to all of them at once. Or dk mean something else?
Yeah, nix is utterly dependent on github and there have been many discussions about it. The majority of the community is very against migrating and refuses investing in anything else.
I remember a project abused github as their CDN, and github shut that down. Can’t remember the name but it was something plant-related (the name). Pods or something. If nix ever scales up massively, github just might rate limit the repo.
nobody is really dependent on Github
If that were true, moving away from github would be ezpz.
The features like searching might not be optimal
Requiring an account to find a project = not optimal is an understatement, IMO.
I’m also just a little guy who does scripting and small CLI tools. So it does not matter at all what I do
That sounds an awful lot like a fallacy. If you wait longer, then when something does drive you to say “I should switch”, you’ll run into the sunken cost issue. If you think you’re unimportant, that’s great for github because they have thousands of people that think they are unimportant but it adds up. You could be part of the solution, no matter how small.
Pretty resilient tortoise. Took 3 to the chest and still talking. 6 more and it could make a rap album.
Isn’t it because SteamOS is based on Arch?
So it’s the implementation that has to ensure a NonEmpty is returned, but that’s up to the developer, correct? The developer still holds the gun to shoot themselves in the foot by returning an empty list, IINM.
data NonEmpty a = a :| [a]
Note that
NonEmptya is really just a tuple of an a and an ordinary, possibly-empty[]. This conveniently models a non-empty list by storing the first element of the list separately from the list’s tail: even if the[]component is[], the a component must always be present.
Wat? How can I “store the first element of the list separated from the lists tail” when the list is empty? Whether a list is empty or not is a runtime possibility, not a compile-time possibility.
Someone care to explain this part? It does not compute at all for me.
Agreed. Every time somebody links this to “prove” or underline their argument, I roll my eyes. There are a lot of subjective things there and many that are actually valid code.
Why are we doing this again?
We’ve experienced some pain with C++. In short:
- tools and compiler/platform differences
- ergonomics and (thread) safety
- community
Preach. make install is the biggest source of “works on my machine” ever. (obviously exaggerating). You could point me at 99% of all C++ projects that have dependencies and it ./configure && make install wouldn’t work on any of my machines. “Oh of course you need to install the dependencies, just sudo apt get” let me stop you right there, I don’t have debian. And with that you’re on your own with C/C++ projects.
Everything else in that chapter plays a big part in my departure from C++. ~30 years of existence and they have barely learned from their missteps.
We’ve succeeded. This was a gigantic project and we made it. The sheer scale of this is perhaps best expressed in numbers:
- 1155 files changed, 110247 insertions(+), 88941 deletions(-) (excluding translations)
- 2604 commits by over 200 authors
- 498 issues
- Almost 2 years of work
- 57K Lines of C++ to 75K Lines of Rust 5 (plus 400 lines of C 6)
- C++–
Wow. What an amazing job 👏
Lemmy drama? Why post it in this community?
Anti Commercial-AI license