riperoni

So hanging on the sidewalk is cool if non-homeless people do it?

To be honest, some of your points can be a hindrance, but as a GitLab user, others are solveable without massive efforts.

- env vars can be scripted, either in YAML or through dotenv files. Dotenv files would also be portable to dev machines

- how is security a joke? Do you mean secrets management? Otherwise, i don't see a big issue when using private runners with containers

- jobs can pass artifacts to each other. When multiple jobs are closely interwined, one could merge them?

- what dependency installation do you mean? You can use prebuilt images with dependencies for one. And ideally, you build once in a pipeline and use the binary as an artifact in other jobs?

- in my experience, starting containers is not that slow with a moderately sized runner (4-8 cpus). If anything, network latency plays a role

- not being able to modify pipelines and check runners must be annoying, I agree

- everything from on-prem license to SaaS license keeps costing more. Somewhere, expenses are made, but that can be optimized if you are in a position to have a say?

By comparing dev machines to runners, you miss one important aspect: portability, automation and testing in different environments. Except when you have a full container engine on your dev machine with flexible network configs, there can be missed issues. Also, you need to prime every dev to run the CI manually or work with hooks, and then you can have funny, machine-specific problems. So this already points to a central CI-system by making builds repeatable and in the same from-scratch envirnment. As for deployment, those shouldn't be made from dev machines, so automated pipelines are the go-to here. Also autmated test reporting goes out the window for dev machines.

I agree with wrapping things like build scripts to test locally.

Still, some actions or CI steps are also not meant to be run locally. Like when it publishes to a repo or needs any credentials that are used by more than one person.

Btw, Github actions and corresponding YAML are derived from Azure DevOps and are just as cursed.

The whole concept of Github CI is just pure misuse of containers when you need huge VM images - container is technically correct, but a far fetched word for this - that have all kinds of preinstalled garbage to run typescript-wrapped code to call shell scripts.

At this point, just pause with Github Actions and compare it to how GiLab handles CI.

Much more intuitive, taking shell scripts and other script commands natively and not devolving into a mess of obfuscated typescript wrapped actions that need a shit ton of dependencies.

Interesting, thank you!

The spirit of forgejo is great, but the whole CI component of both Gitea, forgejo und Github is absolute garbage. Just compare it to GitLab and it becomes clear.

Why the hell are Actions and 20GB "containers" used? It all makes simple command line installs in a container so hard to do. Actions overcomplicate simple stuff like git clone by burying it in mountains of TyseScript to the point of no recognizability or transparency. And having an external dependency on someone others otherworldly wrapped shell script. A singe-purpose container does not exist in that type of world which utterly defeats the whole point of using containers.

Is there a similar CI implementation to GitLab out there?

Yeah, that part reminds me of the flatteringly named "Call to Action" buttons. There was a nice blog article named something like "Button presses You" which i can't seem to find. Essentially, it goes on the trajectory of the purpose of any application telling you what and how to do instead of you, the user, deciding what the programm should do.

High-level is good enough for me for the beginning, thanks!

Can someone explain to a C-noob how this differs from and compares to LLVM?

The UI looks great in the screenshots, gives me a warm feeling of 2000-era UIs.

Will definitely check it out, thanks for posting!

HTML is made to be flexible by using CSS, LaTeX is a typesetting program. It sets the whole document to look nice in one specific view, which is the final PDF. Or mre precisely, LaTeX works best for printed media

There are efforts for web maths, which would close the gap considerably for rendering science articles.

Most of the other LaTeX features can be achieved with HTML, CSS and maybe JS. Or even Markdown + preprocessor.

Firefox with some extras might he nice, but the structure of that web page raises the question:

Who is the target audience? That website has so many oversimplified marketing claims that are about security and customization. It seems wholly undecided if the target audience is people who fall for buzz words or someone actually interested in quantitative improvements over Firefox.

And yet the comparison is just checkboxes and not even including base Firefox. How about bar graphs for comparison and some actual pictures of the advertised customization, layout and workspaces?

To me this still feels a little shady, even though the features seem nice.

Either i overread it or one major quirk is totally not touched on: PowerShell is case-insensitive in as many places as possible, except file paths or the likes.

You can actually call .NET methods with completely nuts casing: "asdfg".tOupPer() works.

Also variable names with only different cases resolve the same, i.e. $var is the same variable as $Var.

String comparison with PowerShell operators is case-insensitive and it has special operators to match case sensitivity. RegEx operators behave the same way. Using the .NET methods however conserves case-sensitivity.

I enjoy using PowerShell a lot. In many of places for scripting processes (Windows server adminisitration) it has an easier entry point than Python. And handling complex objects is kind of trivial. The Windows PowerShell really shows its age by now though and I hope the new PowerShell will be included by default, too.

The title is clickbait, as the laws of cosmology are effectively made up to follow hypotheses made upon observations of the cosmos. If anything, the observations have led to imcomplete models that need more refinement. But it apparently sounds less exciting to many.

Twisting the causality of calculations just in order to make an attention grabbing title is garbage though.