I contemplated this last night as I sat and stared at the wall while waiting for my family to wake for their morning routine. After much deliberation and calculation and running many simulations I arrived at the conclusion that I am most probably not a robot.
The question was "GitHub CI YAML vs. pipeline.sh", not "GitHub CI YAML vs. other forge’s YAML."
What I’m trying to say is that if you keep your build logic in `pipeline.sh` (and use GitHub CI only for calling into it), then you’re going to have an easier time migrating to another forge’s CI than in the alternative scenario, i.e. if your build logic is coded in GitHub CI YAML.
Obviously. But then you still have caching, passing data/artifacts between stages, workflow logic (like skipping steps if unnecessary), running on multiple platforms, and exposing test results/coverage to the system you are running in.
Written properly, actually building the software is the least of what the CI is doing.
If your build is simple enough that you don’t need any of that - great. But pretending that the big CI systems never do anything except lock you in is a trifle simplistic.
Maybe it will actually slow down now that the webshit crowd are increasingly relying on AI copilots. You can't vibe code using a framework that the model knows nothing about.
Right but the actual problem is that the marketing incentives are so very strongly set up to pretend that there isn’t any difference that it’s impossible to differentiate between extreme techno-optimist and charlatan. Exactly like the cryptocurrency bubble.
You can’t claim that “We don’t know how the brain works so I will claim it is this” and expect to be taken seriously.
That's the neat part about lithium fires you just can't, they're self oxidizing so there's not much you can do to definitively put them out the best option is usually to flood them with water to cool them down and contain the damage they cause.
Yeah. Commercial home solar battery power as I understand is done with safer chemistries, such as lithium iron phosphate, which while they have a lower energy density (which is not a big downside for a stationary building) don't have the thermal runaway issues that labtop lithium ion batteries have. I wouldn't want to live next door to the DIY labtop battery array enthusiast.
He seems to be doing it fairly safely by having it housed in a building a whole 50m away from the main dwelling. A fire from there could spread to the house or elsewhere but it's no longer a metal fire so it's a lot easier to deal with and just contain the fire in/around the shed. I'd probably add a nice gravel buffer around it to help that and live in a reasonably well hydrated part of the country so there's not as big a fire risk from embers.
Minor note that installation via the launcher (Why a launcher!?!) seems a bit broken. Both the direct mac download, and installing from Cargo, installs Airshipper v0.15.0. This says that it's outdated and to install a new version. Clicking the button to do this takes you to the Github releases page, where the latest version is 0.14. There's a december release for v0.16 but it's a tag only and has no artifacts. Quit in frustration.
Edit: Despite having an issues page, the GitHub page of the launcher is apparently only a mirror of the GitLab repository. GitLab has artifacts for the latest version. I am mystified why they send people to the GitHub page on their officially linked and `cargo install` downloads.
The launcher was there to make it easier to pull the latest build without needing to check if a new version was available. A couple of years back the updates were irregular (sometimes a few days, other more than a week). We regularized the new builds once a week, but, still, the launcher now serves as a way to explore different unofficial or experimental servers that are being available (via registering in the GitLab project).
Most launchers I see aren't necessary for any technical reason. Most don't even bother to enable any functionality at all to the end user's benefit. They're instead used to exert some form of control in a way that's usually palatable enough to not cause a huge PR backlash. As a default stance, being anti-launcher as an end user seems reasonable.
To me launchers are / can be another pattern of dark-ui. Why is a launcher required?
Is the launcher spying on my system, sending information back to HQ?
Can't you tell me the game needs updating when I play the game and then update the game in-game?
Are you going to throw me advertisement banners when you're not making or being greedy?
What if the update fails?
It's one thing I have to wait upon to play the game but launchers come bloated. A carousel of graphics taking a gig of space then requiring an additional 10GB download for the actual game.
Because Veloren's update cadence for most servers is substantially more frequent than most package repositories are willing to handle (trust us, we've tried!). You can install the game without the launcher, but don't expect it to be compatible with most servers.
> Is the launcher spying on my system, sending information back to HQ?
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
That's exactly what the launcher is doing.
> Are you going to throw me advertisement banners when you're not making or being greedy?
Categorically, no. Veloren is open-source (GPL 3), and developed by a close-knit and dedicated community of volunteers. It's a hobby project and will always be free-as-in-liberty as well as free-as-in-beer.
> What if the update fails?
I'm not sure why it would (bar an iffy connection), but the launcher works in offline mode just fine too.
> but launchers come bloated.
Ours doesn't.
> then requiring an additional 10GB download for the actual game
I think we're up at a few hundred MB right now. Most of that is music. It's worth it :)
Yes, just that server and client are very much tied, and we have a release cadence of one new version per week. So, you would need to track the release of each week and compile it, to be able to connect to the official server.
> Is the launcher spying on my system, sending information back to HQ?
The game and the launcher is published by the same people. If they wanted to spy on you, there's no reason not to do that in the game as well.
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
While not impossible, this is way more difficult to do safely and reliably in-game. There's a reason most updaters live outside of the main app process.
> What if the update fails?
Then it's a lot easier to recover from this in a separate, dedicated, minimal app, than as part of the game itself.
Launchers have their place. For example Minecraft needs a launcher: different servers run on different versions (because of heavy customization that doesn't instantly update on a new game release), so being able to select an arbitrary version and launching it is essential. And the snapshot/beta channel works best if you make it easy for people to play the current, stable version, then quickly check out the latest release, then switch back to stable.
Many early-access games do the same via Steam's "beta" feature. If you don't use Steam, you have to replicate the same in a launcher. Or you do it like Adobe and have an entire separate "not a launcher" program to manage which versions are installed.
Verloren currently doesn't seem to actually offer much version management in the launcher, but it seems like a likely future requirement.
It's not clear to me how these are dark. You aren't being tricked, and all of these traits might be in the game client itself as well (game could phone home, auto update, fail to auto update, be slow, etc)
But I expect to play the game, when clicking the game icon. Not being thrown in to a launcher waiting for me while I then thrown advertisements for their next game.
Take a look at EA Origin, it's horrific. It updates then the whole launcher implodes with some alien error code like as one of a printer.
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
Can you explain this a little? Do you have any examples? Unless you're installing a completely new copy of the game, you're not going to be able to play while you update, making this look an awful lot like a launcher. I'm not aware of any games that are hot-updatable.
Q3 was from times without trivially available persistent internet connections. You had to hunt down the patches and mods yourself manually, hoping not to get malware instead. It was a different time. The updates also were much more spread out - last 3 were from 2001, 2002, 2006.
It's just not comparable to how things work today.
This article shows to me with the actual video that is a video - but a full mobile page before that, an ad that looks entirely like a video player, that opens a page looking like a full screen video player which _directly_ opens Apple Pay when you try to play it.
That is some extremely shitty and actively user-hostile design.
No, they are Objective-C only, and since there is this thing called Objective-C++, where one can combine Objective-C and C++ on the same source file, an alternative had to be chosen.
reply