In what is called inflation, the space-time of the initial event immediately expands into the enclosed space created by curvature, as it transitions state from infinite empty to finite space-time. As it does so the total energy of the universe rapidly increases, along with total curvature, so the actual area also shrinks. When the thus rapidly shrinking universe meets the inflating event, inflation ends; the latent energy driving inflation becomes matter. This part is well explained elsewhere.

The simplest answer for what makes a universe is the enclosed space-time area even of a very slight curvature created by any tiny quantum flux or event which breaks symmetry as it immediately inflates to fill the enclosed area so created.

The universe also dissipates, though different mechanism, is analogous to how black holes do. As the universe dissipates, it's total energy content becomes smaller, so the total curvature of space-time decreases and the enclosed space-time becomes larger; it expands. The rate of dissipation is proportional to the total enclosed "surface area" of space-time. Eventually it returns to the uniform empty symmetric and infinite flat state it began in.

The origin of symmetry breaking, initial inflation, as well as the eventual fate of the universe can all be described purely though the total curvature of space-time alone. Gravity cannot be quantized because it is a product of geometry, not mythical gravitrons; there are no bosons on this bus.

That @google employed people spent close to a decade actively opposing any support for reprudicable builds and vendoring, only to finally grudgingly introduce a marginal and rather incomplete module system, shame on them. @golang

The main thing I see holding back @go is @google. Once you disregard what people said about how to use , such as having a common ~/go directory for all sources (dumb) and always building from tip (dumber) as utter nonsense, and just use go modules with a project level makefile or cmake to run go build and make up for the utterly stupid lack of proper project level metadata in the go mod file, it actually becomes somewhat sane and convenient to actually use.

@codeberg so I just learned there was already a very simple way to do this all along 😍

Show thread

I decided to also talk about the need for per repo default merge policies in and why this is particularly relevant to shared gitea hosting services like @codeberg

C++20 would change the way I make applications with modules and the ability to really use type inference universally for function returns without the header vs source split which limits use to inline or local functions. This is the one real disappointment I find in in that they chose not to do type inference for function returns, though they already have what modules now does for C++20, and very similar reasons to have done so since complex types are often returned in rust.

I am happy to have completed migrating to @codeberg so I am going to finish and next. is nice because its and there is community help. This is how I think should generally work.

Whether living in a tent in the woods off a bicycle trail, sleeping under the boardwalk, or when more urban finding an abandoned train station to live in assuming you don't mind the rats, no matter who you are or what you do this is often all that the US economy may really have to offer you.

@codeberg In my normal workflow, I prefer to have items disappear from visibility in project boards when they are completed (closed, merged, etc). My suggestion is adding a slider on project boards to show/hide completed items.

Well, I joined @codeberg as a supporting member of the non-profit. It just seems too good not to support a EU-hosted, modern code forge.

I am not put off by rapid changes as I hear Stallman seems to be, since I think this is already addressed by specifying rust "editions", which only changes every few years, as specified in cargo toml, unless there is something I am missing.

At least I now have all of my current packages relocated to @codeberg . Now I just need to update many repos with corrected links in documentation and things like that.

@Venezuela Colonial economics never died. Venezuela has sufficient urbanization, diversity, and now access to education to develop and sustain a vibrant and advanced tech economy, but was never permitted to do so last century. Colonial capitalism also favors concentration of industry in only limited domains that can also be controlled under a few hands.

@codeberg I am happy, I have finally been able to take my first repo () thru a production release cycle hosted on , as I had to update my release workflows and deployment support scripts. This will make it much easier to start migrating my other repos to codeberg now. One quirk is that tags are out of order in the repo branch|tag chooser, with the new tag on the bottom of the list, after the imported ones, but are correctly ordered on the release page itself.

@ilyess gitea makes it easier to run pr's without having originating issues because they can have all the properties of an issue, be together with issues on project boards, and have non-overlapping id numbering. This changes how I use issues to avoid unneeded duplicate tracking of issues and pr's on boards and feels different than gitlab which prefers having all pr's tied to issues and assumes branches will be named based on an issue #, too.

@codeberg this actually also touches upon workflow. In github, of course, forking to work in personal repos is the common practice, and gitea seems to follow this. gitlab usually has everyone work in the project repo directly so all work is public if the repo is. In the case of codeberg policy, while the main project repo obviously should be public, do the personal developer forks need to be as well?

Show older

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.