Starlark does allow for much more concise and powerful config specification. I am building https://github.com/claceio/clace, which is an application server for teams to deploy internal tools.
Having a single process web/app server simplifies things operationally. I am building https://github.com/claceio/clace, which is an application server for teams to deploy internal tools. It runs as a single process, which implements the webserver (TLS certs management, request routing, OAuth etc) as well as an app server for deploying apps developed in any language (managing container lifecycle, app upgrades through GitOps etc).
Another option you could consider is a tool I have been building for deploying webapps across a team. https://github.com/claceio/clace has the usual deployment related functionality like gitops, TLS certs.
It has some unique features like supporting OAuth authentication for the apps, staging env for each app (code and config changes are staged before deployment), supporting declarative update, supporting hypermedia based apps natively etc.
This is so cool! The scope is a bit broad (it’s a build tool, DevOps tool and a hypermedia app framework?) – maybe you could split this into multiple projects and start a whole ecosystem?
I’m also working on a deployment tool, though not nearly as ambitious – it’s just a Docker dashboard based around Compose files: https://lunni.dev/ (though it does everything Traefik does, and GitOps are also definitely on the roadmap)
Thanks. Clace is built for teams to be be able to deploy internal tools (Streamlit/Gradio etc). That use case requires some extra features (OAuth/Auditing/Declarative config etc). Kubernetes with ArgoCD plus IDP seems to have become the default solution, which is overkill for such use cases.
The Hypermedia based app support was added to be able to build a management dashboard for Clace itself, without going down the SPA route. It made sense to expose that for end uses to be able to build their own apps.
I have been building a platform [1] which makes it easy to deploy internal tools. Instead of taking the config file approach, it allows you to install each app at a unique location (domain name + url path). Within its location, the app owns all the URLs and can managing request routing without requiring a global config update.
The advantage is that new app installations cannot interfere with an existing app. I wrote more about this approach at https://clace.io/blog/webserver/
Web server config which is a blob of text is a pet peeve of mine. This makes every config update risky and simultaneous updates by multiple users is difficult to coordinate.
This presents an alternate approach for handling web server config, providing app-level isolation.
IIS has been doing this for eons. A single machine config which only an administrator would touch, likely through CLI or GUI tools, and from there on out each application/website can have it's own web.config which the developer can manipulate as required.
Yes, it would be great if this approach becomes more common for web servers.
Since Clace is built for internal tools, even new app installation can be done by regular users. If the namespace is available, a new app can use that without conflicting with other apps.
Discusses an alternative approach to updating web server routing rules. Multiple apps can be installed, each owns a namespace (domain:path). Within its namespace, the app can update routing rules, without conflicting with any other apps
The "Costlier Tobaccos" tag line looks strange now. Products which want to show sophistication no longer promote the fact that they are more expensive.
In 60 years time it will look just as strange to see product advertisements from today boasting '10% reduced CO² impact' or 'climate neutral'. I don't have a clue what they'll advertise with by that time but I do know it will look strange to those about half a century later. The advertising industry was never about objective truth, always about subjective emotions and I do not see that change other than advertising becoming ever more targeted.
KubeCon 2024 talk, talks about difference between source code license and distribution license. From description:
Join Adam Jacobs, founder of System Initiative, as he explores an innovative approach to open source software (OSS) licensing and monetization. This session will dive into:
The limitations of traditional OSS licensing models
Introduction to Fair Source licensing and its principles
Balancing open collaboration with sustainable commercialization
Potential impacts on developer communities and business models
Real-world applications and case studies of Fair Source in action
Learn how Fair Source licensing aims to create a middle ground between fully open and proprietary software, potentially reshaping the OSS landscape. This presentation is essential for developers, project maintainers, business leaders, and anyone interested in the future of open source sustainability.
NonStop Kernel (NSK) is the OS for the Tandem hardware which had fault tolerant hardware (dual everything) and software (process pair with checkpoints) https://en.m.wikipedia.org/wiki/Tandem_Computers. The OS is not posix compliant, very different from HP-UX. It is used now mainly in financial systems, competes with IBM mainframes. I used to work on NonStop SQL databases.
I’m the one who posted the article. This is the first time I’ve ever even heard of NonStop.
From the entitle I assumed it had something to do with discussions that had been going on for a long time or kept coming up and it was just a typo or something.
Interesting to find out there was a an OS I never heard. Unfortunately the Wikipedia page isn’t very comprehensive.
The original company was called Tandem Computers. They called their systems NonStop. The OS was originally called Guardian, then it was Guardian 90, then NonStop Kernel, which had both Guardian and POSIX "personalities". Tandem got purchased by Compaq, then Compaq got purchased by HP.
I don't know how complete it is, but NonStop has had POSIX support since the mid-1990s. It's called Open System Services. It's got ksh, and various unix/posix apis/utilities, and a hierarchical filesystem.
This discusses an error handling mechanism implemented for https://starlark-lang.org/, which combines the benefits of exceptions (conciseness of code) and error return values (control of error behavior)
Clace uses Starlark for defining apps, instead of something like YAML. https://github.com/claceio/clace/blob/main/examples/utils.st... is a config file which defines around seven apps (apps are downloaded and deployed directly from git).
Clace uses Starlark for defining app level routing rules also. This avoids the need to use a nginx like DSL for routing.
reply