Bordeaux is a fairly complex driven project. I think someone even on would be able to drive this kind of docker build and participate in development. It certainly also proofs out source to deploy on even for something very complex and not easily containerized.

Show thread

It takes some 15 minutes with the limited hardware I have, but indeed I can go from a pure git source checkout to publishing a small optimized multi-architecture (amd64 and arm64 currently) oci container without any local build tools or dev env using buildx and a multi-stage Dockerfile that builds a statically linked server for . A natural friend to this would be docker, , or maybe , on a .

I may complete the 2nd milestone release of over the weekend. This will solidify the build and deploy cycle for os packaging. My packaging matches , not . I will also show how I will deliver containerized voice in the future.

I have come to appreciate that @SUSE is more interesting than I initially thought. k3s on , whether x86 or arm, and the related potentially makes @opensuse rather irrelevant. also makes it easy to test or run k3s style anywhere without high resources.

Object oriented programming, to me, in a pure sense, is not class programming, but rather first about composing the objects you will use, defining how they are organized, and then expressing their actual functional relationships. This makes sense in a declarative language with strong type inference when you are looking to express and solve problems rather than iterate specific operations.

So the Canadian government is looking to expand existing broadcaster regulatory powers to the internet in C-10. Those powers though reference media; such as sound and video broadcasts. In theory , of all things, would be legally immune.

Some things I still wish to do would seem to be unwelcome, and likely to be made illegal, by governments in the US, Europe, and Asia. Now what do I do?

I believe it is essential to push far more intelligence and autonomy down stack from the cloud to the facility and the endpoint device than any provider presently wishes to do.

Maybe it is time to talk about what I think about for 21st century . is for delivering containerized and device resident voice applications.

will re-imagine residential phone services and home automation. will do the same for small offices and facility automation. Both focus on messaging first communications and sip inter-operation. will provide secure collaboration built on . All will use Bordeaux.

The project will essentially just be a modern rebuild of my simpler telephony projects from the 90's, which were originally written in C/C++, such as the PBX mml server, the cdr logger, and my DBS papi server. Originally I was going to do that in to better learn it, but it is now clear to me that makes more sense to explore. Well, would also be far better than go...

I am rather happy the project team has tippled in size rather recently. There is opportunity for more people to become involved.

It's not just that is a no-go for me, its that I think serves the same needs, and does so far better, too. But there are things I do where no garbage collected language will ever meet my needs, and I did want to explore more than just C (C++). Hence .

Having done a few things in now, I do find it and the ecosystem just too overshadowed and damaged by insider choices and needs (though not as badly as poor Objective-C / had been destroyed by ) to "go" any further. , on the other hand, I have finally come to like, and that I will use and experiment with in the project instead of go, and maybe to realize , too.

While I had moved a tiny bit forward with developing containerized voice services in a new micro-service, I am interested in using it on devices with ai driven voice response, not just for intelligent agents, but as a democratized platform for a "Voice of Things" ().

Often alone and too often without internet either, I had to figure out what I think are best or effective practices by myself. I do not know if some practices I may choose are even used by anyone else.

I suppose if we can have rubyists we could have had rusticians, but sadly we somehow got rustaceans instead. I so wish they had gone full funk, as rustafarian! Thankfully at least they didn't go full-on incel, as in perlmonks...

There is which gives some idea of how I put these C++ principles into practice. I was going to introduce Bordeaux last year, but then I was in the hospital and had been somewhat limited to what I could do.

I my C++ work I now favor writing thin header only wrappers around legacy C libraries to automate resource management, and to create much smaller stand-alone, often header-only, C++ libraries to address very specific needs, such as system logging, printing formatted output, config file parsing, string handling, etc, rather than using massive frameworks like , which also often tie to legacy C++coding practices.

Maybe I was fortunate, being isolated without connectivity, losses from flooding, etc, last decade, I no longer have much legacy code around to hold me back. Starting over I picked C++17 for new things, and found little need for producing complex bulky supporting libraries like I used to do. I also explore things like and much more now, too.

Show older

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