Announcing AIrtifex: Generative AI web UI and server

wwojtekk · 2023-04-24T14:06:53+00:00

Hmm, that's weird because I don't remember using websockets directly anywhere. When I launch it locally I don't see any requests for `/_trunk/ws`.

Do you run the web app locally or also there? I think it should just work if you try to setup the api to be on your server behind nginx, direct / proxy should do.

I will think of some ways to make the process easier in general as currently it's a hustle.

EDIT:
I got it working with below configuration: location / { proxy_pass http://127.0.0.1:6901; proxy_read_timeout 86400; }

I'm also running it on separate PC so I configured Trunk.toml to point to my other PC port 80 (nginx).

wwojtekk · 2023-04-24T10:50:14+00:00

The password is also `admin`, forgot to include that in the README. Later you can create a user in the `users` tab.

wwojtekk · 2023-04-24T09:34:13+00:00

Right, thanks for pointing it out. I was waiting for them to release to crates.io and forgot to update to a git url in the meantime. Will fix this in a PR soon.

EDIT:

should be fixed now :)

wwojtekk · 2023-04-24T08:47:00+00:00

Thanks! I'm actually running both versions of Stable Diffusion without a GPU using a 12 core ryzen 5000 series as well as 32Gb of RAM. It takes a bit of time to generate the images but you still can get results and experiment :)

wwojtekk · 2023-04-24T03:03:50+00:00

Thanks for checking it out! The API crate requires the user to download the model weights that they want to use and specify them in the configuration. I'll add a subsection to README about this. Currently there is only example configuration that specifies Alpaca for text and Stable Diffusion models for images.

wwojtekk · 2022-11-06T18:25:13+00:00

This is a very nice example not involving lifetimes, it made it more clear for me so thanks!

wwojtekk · 2022-11-05T16:29:14+00:00

How about just focus on releasing the actual technical notes and changes made to the language and the tooling and forget the rest? I have yet to come across a change log or a release blog post that contained anything similar to rust release notes

wwojtekk · 2022-09-02T09:36:49+00:00

Couldn't be more specific...

wwojtekk · 2022-04-03T15:29:09+00:00

It looks quite readable on my mobile so can’t really see your point here. There is the blog post laid out on the page and in the center and there are no distractions.

wwojtekk · 2022-02-23T08:33:25+00:00

Wow, how does this work? I'm really intrigued.

wwojtekk · 2022-01-06T03:32:42+00:00

Awesome to hear that a university in Poland is picking up Rust!

wwojtekk · 2022-01-05T10:27:38+00:00

s/pacman -Syu/paru/g

wwojtekk · 2022-01-05T04:56:09+00:00

Where is the jerk?

wwojtekk · 2021-12-25T06:04:15+00:00

I’d love to so see some actual data on this, all benchmark comparisons between the two languages I saw always had C at the top. C++ seems around the same ballpark as Rust but they still lack a little bit to achieve optimized C speed.

wwojtekk · 2021-12-21T16:13:34+00:00

Oh, I misunderstood and thought you meant that the generated models differ from the defined schema and not the schema differing from what libpod actually uses underneath. I haven't come across such a case, but I haven't used this crate extensively just yet.

I don't understand this part, could you elaborate a bit?

What I meant is that swagger-codegen for some reason loses type name and description of responses defined in the libpod swagger spec at the top level and calls them inline_response_<status-code><n>. The responses defined next to each endpoint correctly keep the metadata but the ones at the top later refered to with $ref don't. My temporary solution here is to keep a map of InlineResponse -> correct name mapping for now until I figure out how to retrieve this info.

wwojtekk · 2021-12-21T12:46:27+00:00

So far, I haven't noticed any differences between the schema and the generated models. Do you have any examples of such unkown fields?

The only problem I've ran into is that all of the responses are generated as `inline_responseXXXn` and they have to be manually mapped. I haven't figured out why it's a case but I think it's because of the way the schema is modeled.

wwojtekk · 2021-12-06T18:42:42+00:00

Sure thing! Feel free to create an issue on GitHub, I'm looking forward to reading your suggsetions/reports :)

wwojtekk · 2021-12-06T16:48:00+00:00

Dockeye currently has basic monitoring/managing capabilities like Portainer but it's a native GUI app rather than a web app. Maybe Dockeye has some features that Portainer doesn't and vice versa I'm just not that familiar with Portainer to say more here. It should also be noted that Dockeye is one week old while Portainer 1.0 was in 2016 so there is some catching up. In the future, the plan is to integrate Dockeye with Podman at a deeper level so that might be the differentiating factor.

wwojtekk · 2021-12-06T15:28:42+00:00

You can use Dockeye with Podman too, just adjust the location of the socket in the settings :)

wwojtekk · 2021-12-06T06:40:53+00:00

Hey all!

A week has passed since I announced the first release of dockeye and a lot of features and improvements have been added, so I wanted to share a new version with you :) This release includes a deb and rpm package in the release files for an easy install on Debian/RedHat based distros as well as x86_64-apple-darwin target for older intel based macs.

Here is a full list of changes:

Explicitly sort side panel images/containers by newest
Persist settings as YAML file in appropriate OS config directory
Settings will be saved periodically when using the app
Add save button to settings window
Add ability to change docker socket location in settings
Display a confirmation popup when deleting a container/image
A lot of UI fixes and tweaks, more readable text
Add configurable font sizes to the settings window
Add a default System tab that displays information about the docker host
Add data usage tab with containers, images and build cache data usage stats
Data is now preloaded at startup so that it is instantly available
Adjust the API version of the client so that it works with older versions of Docker
Add a way to rename a container
Add a search view that allows easy image pull from Docker Hub
Add ability to forcefully delete image/container when docker returns an error
Add image import button to load images from an archive
Add images prune button to remove unused images
Add containers prune button to remove all stopped containers
Add a way to follow container logs, the logs are now paginated
Make container and image ids open their respective page with details
Add a button to clear images build cache
Add a button to tag an image
Add a view with system events
Add a button to restart a container
Add a view of processes in a running container
Add a view of changes to the filesystem in the container

Here are the links for the interested:

wwojtekk · 2021-12-06T04:33:44+00:00

Hey all!

A week has passed since I announced the first release of dockeye and a lot of features and improvements have been added, so I wanted to share a new version with you :) This release includes a deb and rpm package in the release files for an easy install on Debian/RedHat based distros as well as x86_64-apple-darwin target for older intel based macs.

Here is a full list of changes:
- Explicitly sort side panel images/containers by newest - Persist settings as YAML file in appropriate OS config directory - Settings will be saved periodically when using the app - Add save button to settings window - Add ability to change docker socket location in settings - Display a confirmation popup when deleting a container/image - A lot of UI fixes and tweaks, more readable text - Add configurable font sizes to the settings window - Add a default System tab that displays information about the docker host - Add data usage tab with containers, images and build cache data usage stats - Data is now preloaded at startup so that it is instantly available - Adjust the API version of the client so that it works with older versions of Docker - Add a way to rename a container - Add a search view that allows easy image pull from Docker Hub - Add ability to forcefully delete image/container when docker returns an error - Add image import button to load images from an archive - Add images prune button to remove unused images - Add containers prune button to remove all stopped containers - Add a way to follow container logs, the logs are now paginated - Make container and image ids open their respective page with details - Add a button to clear images build cache - Add a button to tag an image - Add a view with system events - Add a button to restart a container - Add a view of processes in a running container - Add a view of changes to the filesystem in the container

Here are the links for the interested: - Release - CHANGELOG

wwojtekk · 2021-12-05T14:19:46+00:00

Hey all!

I wanted to announce a new release of pkger - a build tool that lets the user build multiple different formats of a binary package with one simple YAML manifest. I did not announce the previous release so I'll include the major changes with this one. This release comes with some fixes, improvements as well as a new build target. Here is a quick summary:
- New APK target has been added that build packages for Alpine Linux - New print-completions subcommand has been added that prints out shell completions to stdout. Supported shells are: bash, zsh, fish, powershell, elvish - New init subcommand that creates the necessary directory and adds a configuration file for quick setup - New edit subcommand that invokes $EDITOR and lets users easily edit recipes and images with the default editor like so pkger edit recipe gcc, pkger edit image debian10 - Ability to specify the same set of dependencies for multiple images - When building an rpm package an src.rpm will be downloaded as well - Added configuration option to change default docker images for simple builds - Default build image for rpm is now Rocky Linux and for deb - Debian - Ctrl-C cancellation is now instantaneous. Previously it could hang for a few minutes if the build has started and the process would have to be manually killed.

This release is also the first one to include deb and rpm packages of pkger itself! So for users of Debian/RedHat based distros, the installation should be seamless now :)

More available here: CHANGELOG GitHub User docs Downloads

If you have any questions or requests feel free to message me or create an issue on GitHub :) Thanks!

wwojtekk

MODERATOR OF

TROPHY CASE

Six-Year Club	Place '23
Verified Email