clayrisser

First they came for Gnome 2, replacing it with Unity, and I did not speak out... Then they came for initd, replacing it with systemd, and I did not speak out... Then they came for debs, replacing them with snaps, and I did not speak out... Then they came for X11, replacing it with Wayland, and I did not speak out... Then they came for sudo, replacing it with rs-sudo, and I did not speak out... Then they came for GNU coreutils, replacing it with rust uutils, and I did not speak out...

Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. This repository contains Debian packaging for Zig. Enjoy!

enjoy!

Just packaged Ghostty for Debian.

https://github.com/clayrisser/debian-ghostty

Here's the GitHub link. Please give it a star .

https://github.com/clayrisser/integration-operator

Introducing Integration-Operator for Kubernetes: A groundbreaking tool inspired by Canonical’s Juju Charms. This operator isn’t just another addition to your DevOps toolkit; it's a paradigm shift in how you manage and integrate your deployments. Forget the tedious manual configurations and the risk of human error. With our innovative plug-and-socket model, you can seamlessly connect different applications, ensuring they communicate perfectly within your Kubernetes clusters. It's not magic, but it might as well be. Share your thoughts on how this could revolutionize Kubernetes integrations, or if you're skeptical, let's discuss the potential limitations. Either way, your input could shape the future of Kubernetes deployment strategies!

openldap docker image based on bitnami openldap with ppolicy, password hashing and support for ldif migrations

The twitter algorithm will no longer give biased search results once this pull request is accepted.

Finally, real package management for Makefiles. No dependencies required other than a POSIX compliant Unix environment . . . and of course GNU Make.

The reason I didn’t use refracta is because I wanted a reproducible approach.

Yes, sorry about that. I need to work a bit more on the nix compatibility. Please file an issue on this.

- overlays (basically you can separate configuration into separate units)

- templating support

- configuration in yaml files

- it still fully supports live-build support, so it should be super easy to migrate. You just put the live build files in os/lb or in the lb folder of an overlay.

It’s easier to use. It actually uses live-build under the covers, and even supports enabling you to tap into the live build system directly.

A couple of things it supports that live build does not support.

- overlays (basically configuration modules)

- templating

- python hooks

As the author of Linux Factory, that’s exactly what I built it for. I would love to help guide you and get you started on your project. Please create an issue in the GitHub project and I’ll further guide you there.

I hope this is the easiest to use.

It’s essentially an easy to use tool around live-build. Live build is maintained by the Debian team and will always remain up to date.

This means Linux Factory is future proof.

This project is a product of 4 years of work, mostly learning the Debian ecosystem. I started with Ubuntu, I’ve tried Arch, I’ve tried Gentoo, but nothing beats the ease of Debian when it comes to custom distributions. Debian was almost built to fork. Their ecosystem is amazing. Their live build tool is super.

I built Linux Factory so everyone else can build custom Debian distributions easily without having to know the live-build tool. It’s really easy to configure and get started. Please give me feedback on how I can make it better.

Hey just noticed all the activity here. I’m the author of Linux factory. I just opened up issues on GitHub so more discussion can happen there.

I have been searching for a technology like this for a long time. I have several specific features I’m searching for in a technology like this, and I’m curious how many of these features Utopia supports.

- Extendable component library and property panel so it can support custom component libraries and styling systems

- Native integration with vscode (maybe as an extension)

- Tailwind style editor and theme ui style editor - Full TypeScript support

I was planning on building something similar. My first attempt involved trying to get grapesjs to work with react. This attempt was very cumbersome because grapesjs generated html, and I would try to manipulate the html into react.

https://github.com/artf/grapesjs

Later however, I discovered craft.js, which is basically a framework for creating systems similar to this (page/component editors). Craft.js was inspired by grapesjs, but is specifically made for react.

https://github.com/prevwong/craft.js

Of course craft.js only solves the UI editor, not the code parsing/generation part. Babel is an obvious choice for code generation/manipulation, but I found its imperative approach unnecessarily complicated, so I built react-ast to enable declarative and composable code generation using react.

https://github.com/clayrisser/react-ast

The part I had not figured out was using the code as the source of truth for the editor and syncing it back. I definitely thought about it a lot, but postponed solving it since I had more pressing problems.

So, I have a lot of curiosity about this project. How does it work? And how does it stack up against a technology like craft.js? I noticed it’s not using craft.js, so I’m guessing the developers rolled their own equivalent.

Yes exactly my question. How does the bloody thing work?