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!

The cost is not that high. There are plenty static site generators or things like pandoc. For example: https://pianomanfrazier.com/post/write-a-book-with-markdown/

You are asking for a responsive weblayout, which excludes any format that LaTeX outputs. Latex is a typesetting engine that does the job before presenting anything and not while presenting it. Its layouts are not responsive by design.

So your question if there is something like LaTeX for frontend is just misplaced, because the working method of LaTex does not fit into a responsive weblayout frontend. What LaTeX features do you want in a frontend? How do you want to write code and how do you want the layout to happen?

What you describe sounds more like static site generation with math handling and perhaps references. There are markdown extensions that can handle such things. For rendering there is e.g. https://www.mathjax.org/

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.

Sorry, I don't have it hosted or uploaded anywhere, since it is heavily changing still. Also the name is not decided yet

Just for fun, I'm writing an internet forum software from scratch, strongly inspired by phpBB and the likes.

It is split into an Angular UI, C# ASP.NET Core RESTful API and postgres database. I aimed to let EF Core handle the data model in the database and am pleasantly surprised by how well it works. Also updating the database is a breeze with its migrations.

The features of a forum seem easy enough, but I find it difficult to detail it out into the data model at times.

I like this a lot, thank you. Have to try it out in a project.

Is the default encoding when handling files UTF8 OR UTF8-BOM? Is both supported?

Another question: in the readme you have this example

`var joined = U8String.Join(',', boolean.Runes); // "T,r,u,e"`

Why is " T" of true in uppercase?

Well, not really.

The expansion of the universe is not responsible for explaining gravity, it was observed and aided in determining models and constants for the theory.

Start by looking at a particles property called mass. Mass interacts with the higgs field by exchanging a particle of information called the higgs boson. The interaction strength, corresponding to mass, determines how much the space time around our particle curves. Space time curvature dictates a particles movement. Now throw another particle with mass next to the initial one, also interacting with the higgs field. This is when you get into a huge loop of interacting movements and fields.

Locally and classically we approximate it by the classical law of gravity which loosely states that two masses attract each other, depending on how close they are, i.e. GMm/r^2

The universe expanding or contracting is a consequence of mass and gravotational fields, not the other way around. And calculating the expansion and thus curvature of the universe gives you a picture of the average mass distribution.

I am using it in a hobby code first project. Had no issues with it, but my data model is admittedly not complex and the the data is small in size.

The whole article reads like a strawman argument.

From a dev's point of view, timezones in real life are okay and much more annoying in data/software because sometimes, other folks don't care about capturing timezone offsets properly or converting to UTC.

We all just long for clean UTC timestamps that can be created, parsed or passed around without concern until they are displayed and formatted according to a local timezone where ever. Abolishing day time savings would simplify this even more.

I agree, but we gotta tell that to CI/CD engineering and yaml-pipelines

This is a nice writeup, but the definition and usage of determinant makes my nails curl.

A determinant is defined for matrices, not for vectors and from the purpse of your article I think you skipped over that part for simplicty/brevity. But really, introducing it once properly, then going to the more pragmatic definition of yours aknowledging that it is skipping some parts would be so much better for someone not knowing this field in depth. Or just not calling it determinant. And mentioning that determinants show a sort of scale factor of transformation, also for 3D, would be nice to connect to 3D rendering and such.

Since it is meant as intro/tutorial on implementation I would really point into all the right math-relates directions as a reference. Whoever wants, can read or skip those parts.

This article really doesn't get what LaTeX does. Of course it is overkill to have 5 lines of text rendered with LaTeX into a PDF. But the point of LaTeX is exactly to set the typesetting of an output document in stone. PDF is meant to do that and HTML cannot do that. A PDF conserves everything and that is precisely the point to have a set layout for printing or displaying on different devices.

Yes, there should be easy ways to display math on the web. No, this doesn't mean that LaTeX is obsolete.

Besides, what about references, both external and internal? Probably needs more "modern" tooling.

Yeah thank you, that summary is better than the article.

The definition of refracitve index in the article is also just wrong, since it is simply not an angle. It can be calculated from incidence and refraction angles of the light beam - very different. See https://en.m.wikipedia.org/wiki/Snell%27s_law

To add to your answer, the refractive index is not just wavelength dependent, but can also be depending on the polarization of light, leading to birefringence: https://en.m.wikipedia.org/wiki/Birefringence

I can't answer your initial question, but I do like to pile onto the package management points.

Package consumption sucks so bad, since the sensible way of using are virtual envs where you copy all dependencies. Then for freezing venvs or dumping package versions, so you can port your project to a different system, doesn't consider only packages actually used/imported in code, but it just dumps everything in the venv. The fact you need external tools for this is frustrating.

Then there is package creation. Legacy vs modern approach, cryptic __init__ files, multiple packaging backends, endless sections in pyproject.toml, manually specifying dependencies and dev-dependencies, convoluted ways of getting package metadata actually in code without having it in two places (such as CLI programs with --version).

Cross compilation really would be a nice feature to simply distribute a single file executable. I haven' tested it, but a Linux system with Wine should in theory be capable of "cross" compiling between Linux and Windows.

Still, like you, as a beginning I would prefer a sensible package management and package creation process.

Arguably, it is not the real history anymore if you make it prettier.

Do you put manual work into rebases? It sounds like a lot of effort and time when collaborating.

Yes, securing branches is very important, much like git-hooks if you are serious about the Git flow.

How do you specifically investigate the history with rebase and 10+ developers? Do you manually look into commits on the branch, or go by a single file history, or look at merge/pull requests?

Personally, I prefer looking at the context of a file change within a merge/pull request. The specific merged/pull request can be read from the merge commits. And in case a specific file history is of interest, I can backtrack from that file's associated commits.

I never use squashing, because the history would not be easily accessible afterwards.

In popular Git ecosystems like Github you have the option to add a merge commit. To me, this also helps understanding the history of the repo. Would the rebasing be equally visible?

Merging is a process that I like over rebasing exactly because it conserves the history.

With a repository server that supports merge requests and feedback from CI/CD tooling on commits/push you can motivate people to use merges rather cleanly.

If you add to that very simple rules like

- create branches for every feature

- commit often

- push often

- merge only via merge/pull requests

then even people new to Git can handle it just fine.

Merge conflicts happen when multiple people work on the same file and try to merge their different status. Imho, code bases where multiple people work on the same file at the same time have a more fundamental problem than Git.

Honestly, I still struggle to see the value in rebasing. Maybe because I haven't used it extensively. Superficially, to me at least, it does the same as a "git push -f".

I am curious to hear why it is supposed to be superior, especially with modern CI tools like Github and the likes.