A tool to simplify reprovisioning a fresh OS. Installs packages and manages dotfiles.

Related tags

System tools dotfiles configuration-management
Overview

Comtrya

Comtrya

This is better, yes?

Warning

This tool is ridiculously early in its development. I'm building out features as I migrate my dotfiles over.

Those dotfiles can be used as a "reference" for migrating your own.

Only for early adopters and masochists.

About

Comtrya is a tool to help provision a fresh OS with the packages and configuration (dotfiles) you need to become productive again.

I'm a serial OS installer, I wipe the OS on my machines every, approx, 30 days. I've primarily relied on SaltStack to automate this, but I've grown frustrated with the mismatch between configuration management and personal provisioning.

I've also tried Ansible, Chef, Puppet, mgmt, and probably anything else you're about to suggest; they all have a flaw that makes it too cumbersome to adopt for the trivial use-case.

Getting Started

You'll find binaries over on the releases page.

If you're not feeling risk-averse, you can use this one-liner:

curl -fsSL https://get.comtrya.dev | sh

If this doesn't work for your OS and architecture, please open an issue and we'll do our best to support it.

Usage

# Run all manifests within a directory
comtrya <directory with manifests>

# --manifests, or -m, will run a subset of your manifests
comtrya . -m one,two,three

# Show command usage
comtrya --help

Manifests

A manifest is a collection of packages and files, and this will likely be expanded upon later. A Manifest is a logical grouping of resources that can be applied to your machine, and fetched from remote locations or local.

Actions

  • directory.copy
  • file.copy
  • package.install

Directories

Directories must be within a files directory within each manifest location.

actions:
  - action: directory.copy
    from: includes
    to: /Users/rawkode/.zsh/

Files

Files must be within a files directory within each manifest location.

actions:
  - action: file.copy
    from: gitconfig
    to: /Users/rawkode/gitconfig
    template: false # Whether to interpolate {{}} variable syntax with contexts

Packages

Currently Comtrya supports Homebrew and Aptitude as package providers. It'll detect, based on your system, which should be used.

This can be tweaked per action, using the provider parameter. Each provider also supports a repository parameter, which can add Homebrew Taps or PPAs for Ubuntu systems.

Single package:

actions:
  - action: package.install
    name: git

  - action: package.install
    provider: homebrew
    repository: homebrew/cask
    name: docker

  - action: package.install
    provider: aptitude
    repository: ppa:longsleep/golang-backports
    name: golang-go

Install several packages with the list version:

actions:
  - action: package.install
    list:
      - git
      - minikube

Dependencies

Dependencies can be configured per manifest, not per action.

depends:
  - manifest_name

What's Next?

You should take a look at the issues page to see what's available to contribute. Below is a short list of the major features that are upcoming.

Better Output

Providing a --quiet or --summary option that restricts the output to the run time

Comtrya finished in 12.3s

Installed Packages: 12
Provisioned Files: 34

Async DAG

We're using petgraph to build out the graph, but we're not travesing it in a way that will allow us to concurrently execute manifests at the same depth. This is something I wish to sort out pretty soon.

Config

TODO: Allow manifest directory and variables to be configured in a Comtrya.yaml file. This will allow for comtrya with no arguments to function, as in the initial versions.

Package Provider Enhancements

Currently, we execute arbitrary packager install commands. The provider spec should be enriched to support:

  • List refresh
  • Upgrades
  • Version pinning
Comments
  • OpenSSL issue when compiling on NetBSD

    OpenSSL issue when compiling on NetBSD

    I am working on trying to port comtrya over to NetBSD and ran into an initial issue in the build process. Look like it has an issue with the vendored version of openssl.

    Here is the output:

    error: failed to run custom build command for `openssl-sys v0.9.72`

Caused by:
  process didn't exit successfully: `/home/todd/Projects/comtrya/target/debug/build/openssl-sys-dede6734a7187c76/build-script-main` (exit status: 101)
  --- stdout
  cargo:rustc-cfg=const_fn
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_NETBSD_OPENSSL_NO_VENDOR
  X86_64_UNKNOWN_NETBSD_OPENSSL_NO_VENDOR unset
  cargo:rerun-if-env-changed=OPENSSL_NO_VENDOR
  OPENSSL_NO_VENDOR unset
  CC_x86_64-unknown-netbsd = None
  CC_x86_64_unknown_netbsd = None
  HOST_CC = None
  CC = None
  CFLAGS_x86_64-unknown-netbsd = None
  CFLAGS_x86_64_unknown_netbsd = None
  HOST_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
  running "perl" "./Configure" "--prefix=/home/todd/Projects/comtrya/target/debug/build/openssl-sys-235ad40d71f59b42/out/openssl-build/install" "no-dso" "no-shared" "no-ssl3" "no-unit-test" "no-comp" "no-zlib" "no-zlib-dynamic" "no-md2" "no-rc5" "no-weak-ssl-ciphers" "no-camellia" "no-idea" "no-seed" "BSD-x86_64" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64"
  Configuring OpenSSL version 1.1.1m (0x101010dfL) for BSD-x86_64
  Using os-specific seed configuration
  Creating configdata.pm
  Creating Makefile

  **********************************************************************
  ***                                                                ***
  ***   OpenSSL has been successfully configured                     ***
  ***                                                                ***
  ***   If you encounter a problem while building, please open an    ***
  ***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
  ***   and include the output from the following command:           ***
  ***                                                                ***
  ***       perl configdata.pm --dump                                ***
  ***                                                                ***
  ***   (If you are new to OpenSSL, you might want to consult the    ***
  ***   'Troubleshooting' section in the INSTALL file first)         ***
  ***                                                                ***
  **********************************************************************
  running "make" "depend"
  running "make" "build_libs"

  --- stderr
  make: illegal argument to -j -- must be positive integer!
  thread 'main' panicked at '


  Error building OpenSSL:
      Command: "make" "build_libs"
      Exit status: exit status: 1


      ', /home/todd/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-src-111.17.0+1.1.1m/src/lib.rs:479:13
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

    OS: NetBSD 9.2 Arch: Amd64

    I have also opened an issue on OpenSSL's github.

    opened by martintc 29
  • Bug: execution of manifests random and exits unexpectedly

    Bug: execution of manifests random and exits unexpectedly

    Description

    when i run

    $ comtrya -v apply
    • I see that it picks a manifest to start with.
    • It's not obvious why it picks that manifest.
    • Each time i run comtrya -v apply It's never the same manifest that it starts with.
    • Each time i run comtrya -v apply The order of the manifests executed is never the same.
    • Each time i run comtrya -v apply Some manifests are not executed.

    Steps to reproduce Step by step explanation. Please add the output of with -vvv flag enabled (be careful not to include any secrets from your config).

    Expected behaviour What the expected behaviour in your opinion.

    Environment

    • OS
    • Version: comtrya --version

    Additional information Add more context which didn't fit in the fields above.

    first run :

    
DEBUG execute:{manifest="packagemanagers.scoop"}: Result of 'where' condition 'os.name == "windows"' -> 'true'
 INFO execute:{manifest="packagemanagers.scoop"}: CompletedDEBUG execute:{manifest="shells.powershell.fzf"}: Result of 'where' condition 'os.name == "windows"' -> 'true'
 INFO execute:{manifest="shells.powershell.fzf"}: Completed
DEBUG execute:{manifest="shells.zsh.install"}: Result of 'where' condition 'os.name == "linux" || os.name == "macos"
' -> 'false'
 INFO execute:{manifest="shells.zsh.install"}: Skip manifest, because 'where' conditions were false!

    second run :

    DEBUG execute:{manifest="shells.xresources.xresource"}: Result of 'where' condition 'os.name == "linux" || os.name == "macos"' -> 'false'
 INFO execute:{manifest="shells.xresources.xresource"}: Skip manifest, because 'where' conditions were false!

    third run :

    DEBUG execute:{manifest="devtools.vscode.config"}: Result of 'where' condition 'os.name == "windows"' -> 'true'
 INFO execute:{manifest="devtools.vscode.config"}: Completed
DEBUG execute:{manifest="devtools.asdf.setup"}: Result of 'where' condition 'os.name == "linux" || os.name == "macos"' -> 'false'
 INFO execute:{manifest="devtools.asdf.setup"}: Skip manifest, because 'where' conditions were false!

    why is it random?

    opened by airtonix 17
  • feat: Add yay provider

    feat: Add yay provider

    Hey! Very cool project! :smile:

    Was setting up an old laptop at home and came across this very promising project. My wife and I are using Arch/Manjaro and having support to yay/pacman would be great!

    Type::Enhancement 
    opened by knelasevero 15
  • Plugin and Hooks arquitechiture

    Plugin and Hooks arquitechiture

    Looks like you already have a good modularization in Comtrya. It would be nice if it supported plugins. Actually, since I don't know Rust and had some issues with using Comtrya to run the manifests I almost created a clone of it in Typescript hahaha. I could help with the plugin architecture design if you give me some pointers on the current architecture.

    Here are some extension points I think could be created if you decide to add plugin support:

    • Custom Actions
    • Custom Contexts
    • Custom Providers
    • Custom top-level "things" (not sure what you would call depends and actions at the top of the yml file)

    If you want to go further and turn Comtrya into a framework, you could also add extension points to:

    • Manifest parser which would allow creating parsers for other languages. I think JSON can be useful in certain contexts
    • Cli commands I created a script called pack_stuff that could became a plugin. It exports PPAs, repositories and user installed packages list that can then be read by the move_in.yml manifest in the new system
    • Hooks for many points of the process, e.g.:
      • on_start - that would allow setting up logging
      • before_action - could allow me to define a rule that asks for confirmation before running and cancel execution
      • on_dependency_require - could enable custom dependency processing like downloading a yml from github and returning the path to the local file

    Anyways, these are just examples. The point is that with plugins and hooks you don't have to implement most of the feature requests

    opened by svallory 10
  • Stow-like recursive symlinking

    Stow-like recursive symlinking

    Given this directory, with stow I can run stow nvim from the root of my dot files repo to recursively symlink all the files resulting in ~/.config/nvim/{coc-config.vim,coc-settings.json,init.vim} existing.

    I see that file.symlink was implemented (side note: looks like it didn't make the readme yet. I can PR that.). Would this behavior be more aligned to a directory.link? Or maybe an option on the directory.copy action?

    Type::Enhancement Actions::File 
    opened by eddiezane 8
  • Feature request: Package provider for FreeBSD

    Feature request: Package provider for FreeBSD

    A little background for any reader who might not be familiar with Unix-likes besides Linux:

    Modern FreeBSD and DragonFly BSD use a package manager called pkg which has been available as an alternative from FreeBSD 8.4 onward and as the only supported pm since FreeBSD 10.0. It replaced what was known as the pkg*_ tools. The latter (or rather a re-implementation thereof) is still used on OpenBSD. On modern Solaris / illumos the "Image Packaging System" is used and the package manager for that is also called pkg.

    Depending on how far Comtrya wants to take portability, it makes sense to consider this when choosing a provider name. Since Solaris and BSD use different manpage sections, a common differentiator is to use these when referring to either BSD's pkg(8) or Solaris' pkg(1). I'd probably call the provider "bsdpkg" or something; it's just helpful to be aware of the potential name clash upfront.

    To allow for more rapid development, pkg(8) is not part of FreeBSD's base system. The system ships with a script, though, which transparently does the actual bootstrap and acts as a wrapper afterwards. FreeBSD's default shell is not bash but the C-shell variant called tcsh. This requires setting environment variables with env $SOMETHING=$VALUE $COMMAND-TO-RUN instead of $SOMETHING=$VALUE $COMMAND as you'd do with a bourne shell.

    One thing to take into account regarding pkg(8) is that you are supposed to read the summary of actions to be taken before acknowledging it. The reason is that pkg deals with conflicts by proposing package removal of already installed packages. This is perfectly expected if e.g. installing Salt 300x on a system that still has Salt 2019 installed: As both install files to the same location, they are in conflict.

    However in certain situations (due to interesting dependency issues) you can install a new package and end up having e.g. Libre Office or Firefox deleted. This definitely does not happen very often with the official FreeBSD repo, but somewhat more frequently for people rolling their own packages (which is a common thing to do). Since an automation tool cannot decide if pkg's proposal is the right thing for the system, this is a potential problem (I've had Salt screw up systems like this a couple of times over the years). Might make sense to choose safety by default here and allow for a special variable like "tolerate_remove" or something which defaults to "no".

    To give the reader an impression of what that looks like, here's the output for trying to install the old version of Salt on a system that has a current version installed:

    Checking integrity... done (1 conflicting)
  - py37-salt-2019-2019.2.8 conflicts with py37-salt-3002.5 on /usr/local/etc/salt/master.sample
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        py37-salt: 3002.5

New packages to be INSTALLED:
        gmp: 6.2.1
        py37-pycrypto: 2.6.1_3
        py37-salt-2019: 2019.2.8

Number of packages to be removed: 1
Number of packages to be installed: 3

The operation will free 1 MiB.

Proceed with this action? [y/N]:

    Here's some thoughts on an actual pkg provider:

    Bootstrapping function:

    • Check whether /usr/local/sbin/pkg exists
    • Yes: Already bootstrapped, nothing to do
    • No: Execute "env ASSUME_ALWAYS_YES=1 /usr/sbin/pkg bootstrap" to bootstrap without having to press "y"

    Updating repository catalogue function (probably not even needed - pkg does this automatically if the catalogue is too old):

    • Execute "pkg update"

    Installing a package:

    • If tolerating package removes on install: Execute "pkg install -y $PACKAGENAME"
    • If not tolerating removes: Execute dry run "pkg install -n $PACKAGENAME"
    • Parse output for "REMOVED", fail if encountered
    • Execute "pkg install -y $PACKAGENAME"

    Removing a package:

    • Execute "pkg delete -y $PACKAGENAME"
    Type::Enhancement Actions::Package Component::Actions OS::BSD 
    opened by kraileth 8
  • [#217][feat] add doppler.com variables include

    [#217][feat] add doppler.com variables include

    I'm submitting a

    • [ ] bug fix
    • [x] feature
    • [ ] documentation addition

    What is the motivation / use case for changing the behavior?

    My feature contribution is all about having doppler.com secrets being variables in comtrya.

    The schemas are:

    • doppler://<project>/<config>/<secret>
    • doppler://<project>/<config>

    The code checks, if you're logged in or not.

    opened by icepuma 7
  • Initial implementaiton of user management targeting FreeBSD

    Initial implementaiton of user management targeting FreeBSD

    Initial code redone for the rewrite. Implements basic user management with adding users to a system. The initial PR will target FreeBSD to flesh out the general idea with user management. After this has been done, work can happen to support adding users on different systems that comtrya support.

    Should introduce no breaking changes and just add functionality.

    opened by martintc 7
  • Bug: binary.github prevents further manifest actions from running when it thinks no action is required.

    Bug: binary.github prevents further manifest actions from running when it thinks no action is required.

    Description

    If I have:

    files/enact/enact.service

    [Unit]
Description=Enact Auto configures Xrandr

[Service]
ExecStart=$HOME/.local/share/bin/enact --pos top --watch

    enact.yml

    ---
where: os.name == "linux"

actions:
  - action: binary.github
    name: enact
    directory: "{{ user.home_dir }}/.local/share/bin/"
    repository: chmln/enact
    version: v0.1

  - action: file.copy
    from: enact
    to: "{{ user.home_dir }}/.config/systemd/user/"

    then:

    • 1st run both actions run
    • 2nd run binary.github attempts, fails and nothing else in the manifest is processed.

    If I switch to:

    ---
where: os.name == "linux"

actions:
  - action: file.copy
    from: enact
    to: "{{ user.home_dir }}/.config/systemd/user/"

  - action: binary.github
    name: enact
    directory: "{{ user.home_dir }}/.local/share/bin/"
    repository: chmln/enact
    version: v0.1

    Then it works.

    This would obviously force certain workflows that depend on the installed binary to be split into two manifests.

    Steps to reproduce

    Try the above two manifests.

    1. The first one will succeed on first try, never attempt to copy the files on the 2nd try.
    2. The second one will always run both actions.

    Expected behaviour

    binary.github should never cause the current manifest to bail/error/exit/prevent-further-actions/prevent-further-manifests

    Environment

    • OS: Fedora release 36 (Thirty Six) 5.19.15-201.fc36.x86_64
    • Version: 0.8.0

    Additional information Add more context which didn't fit in the fields above.

    opened by airtonix 6
  • feat: initial build of github releases support

    feat: initial build of github releases support

    This really needs some integration tests, so I'm going to take a look at something @icepuma shared recently:

    https://github.com/aelsabbahy/goss

    I'm also not super keen on directory: /usr/local/bin being mandatory and I think we can be smarter about this by peeking into ${PATH} for a XDG /bin directory or /usr/local when missing. Curious what BSD users would expect here too, cc @kraileth and @martintc

    Though this PR is available for testing

    Closes #24

    opened by rawkode 6
  • [feat] variables context

    [feat] variables context

    • variables are added via "Comtrya.yaml":

      variables:
  fkbr: "sxoe"
  kuci: "xhpv"

      which yields

      DEBUG context="variables" key="fkbr" value="sxoe"
DEBUG context="variables" key="kuci" value="xhpv"
    opened by icepuma 6
  • Feature: Context command

    Feature: Context command

    Description We have a new command comtrya contexts [--show-values] which shows the given contexts and optionally their values.

    This issue is a placeholder for future discussions and it is linked in the output of the command.

    Type::Enhancement Actions::Command 
    opened by icepuma 2
  • Major Docs Overhaul

    Major Docs Overhaul

    Description

    We've (I) have done a seriously poor job at maintaining and keeping the docs up to date.

    I believe this is, in-part, because the docs are in a separate repository and as such are often neglected.

    I'm proposing that we bring the docs into the main repo, which will work with now that we're a multi-crate project anyway.

    This would likely mean that we move away from Gitbook, as I'm not sure if we could support that structure (maybe?).

    However, there was chat about moving to mdBook or something also on a contributor call.

    Opening for discussion.

    cc @comtrya/maintainers

    opened by rawkode 2
  • Feature: all actions should have a parameter that allows for opting into / outof error === exit/skip

    Feature: all actions should have a parameter that allows for opting into / outof error === exit/skip

    Description

    Some actions are inconsistent with respects to how they handle errors.

    Some will :

    • print error, and continue on with next action in the current manifest.
    • print error, and cause rest of manifest to be ignored.
    • print error, and cause the rest of the entire repo to be ignored.

    Perhaps we should think about a way to make this behaviour official and obvious to the user by:

    • providing a flag on each action on_error: die | skip_manifest | continue
    • default to die
    • when a fatal error occurs, print the error with something like :
    <the error spam>

if you want to ignore this error, declare: `on_error: continue`, read more: https://comtrya.dev/blah/blah/blah

    I'm not sure what you consider the the correct wording and formatting, but essentially it should do two things:

    • show the error
    • help the user get past the error
    • give a link to the deep dive

    Additional information Add more context which didn't fit in the fields above.

    opened by airtonix 4
  • Bug: Tera should only evaluate templates after all where clauses have been analysed

    Bug: Tera should only evaluate templates after all where clauses have been analysed

    Description

    When I try to evaluate this manifest on linux or macos it fails because it can't find the envvar:

    ---
where: os.name == "windows"

actions:

  - action: file.copy
    from: winget.json
    to: '{{get_env(name="LOCALAPPDATA", "")}}\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json'

    on windows LOCALAPPDATA is effectively ~/AppData/Local.

    I'm working around this by doing this instead which doesn't cause an error:

    ---
where: os.name == "windows"

actions:

  - action: file.copy
    from: winget.json
    to: '{{user.home_dir}}\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json'

    Steps to reproduce

    comtrya -d https://github.com/airtonix/ComtryaProblemRepo#master:tera-evaluates-all-templates-before-where-plan apply

    Expected behaviour What the expected behaviour in your opinion.

    Environment

    • OS: windows 11
    • Version: 0.8.0

    Additional information Add more context which didn't fit in the fields above.

    Type::Defect 
    opened by airtonix 1
  • Feature: Load

    Feature: Load "files/**/*" as Tera templates so we can use {% include %}

    https://github.com/comtrya/comtrya/blob/54095b34419efcfe1af469866925f35ea76b4758/lib/src/actions/file/copy.rs#L46

    Any chance we can use this form instead?

    https://tera.netlify.app/docs/#usage

    let tera = match Tera::new("files/**/*") {
    Ok(t) => t,
    Err(e) => {
        println!("Parsing error(s): {}", e);
        ::std::process::exit(1);
    }
};
    Type::Enhancement 
    opened by airtonix 1
  • Feature: package.install (provider:winget) sometimes requires additional arguments for automated package install

    Feature: package.install (provider:winget) sometimes requires additional arguments for automated package install

    Description

    For example to install the latest powershell (v7+) comtrya would complete instantly and succesfully.

    ---
where: os.name == "windows"

actions:

  - action: package.install
    provider: winget
    name: Microsoft.Powershell

    which is wrong because installing it with :

    > winget install --id Microsoft.Powershell --source winget
    • produces a loading bar
    • sometimes requires the user to accept terms and conditions
    • (for me) takes quite a while to download, probably because MS are rate limiting the bandwidth on their server.

    It wasn't until i switch the action from package.install to command.run :

    
  - action: command.run
    command: winget
    args:
      - "install --id Microsoft.Powershell --source winget --silent --accept-source-agreements --accept-package-agreements"

    That I got the expected behaviour.

    So perhaps there's two things here:

    • allow package.install to accept extra args some how?
    • detect if a package manager is waiting for user input, fail (unless we have a flag i guess) with an error that says something like:

    manifest failed because package manager expected user input, provide arguments to facilitate non interactive installation"

    Additional information Add more context which didn't fit in the fields above.

    Type::Enhancement 
    opened by airtonix 3
Releases(v0.8.3)
Owner
Comtrya
Comtrya
GitHub https://comtrya.dev
idf-env tool helps set up and manage ESP-IDF installations

idf-env Tool for maintaining ESP-IDF environment. Quick start Install serial drivers for ESP boards on Windows. Execute following command in PowerShel

Espressif Systems 19 Dec 4, 2022
It is a backup tool that creates backups and stores them on an object storage

Hold My Backup It is a backup tool that creates backups and stores them on an object storage. By default it uses minio but you can use AWS: S3 as well

Taylan Dogan 13 Feb 17, 2022
Terminal bandwidth utilization tool

bandwhich This is a CLI utility for displaying current network utilization by process, connection and remote IP/hostname How does it work? bandwhich s

Aram Drevekenin 7.5k Dec 31, 2022
Everyday-use client-side map-aware Arch Linux mirror ranking tool

Rate Arch Mirrors This is a tool, which fetches mirrors, skips outdated/syncing Arch Linux mirrors, then uses info about submarine cables and internet

Nikita Almakov 196 Jan 2, 2023
Another tool you didn't know you want

colorful-uname Another tool you didn't know you want Examples: Default operation: "All" operation: Help message: Building and installation: Build proc

S0ra 4 Oct 5, 2022
A tool for quickly switching between different file configurations, using symbolic links.

config-loader A tool for quickly switching between different file configurations, using symbolic links. Usage To use it, download the latest release f

Zacchary Dempsey-Plante 3 Aug 22, 2022
A simple rust-based tool for fetching system information

?? azf a simple rust-based tool for fetching system information you need a patched nerd font and the material design icons font ?? compiling you can c

Pedro Henrique 3 Dec 17, 2022
A simple and fast download accelerator, written in Rust

zou A simple and fast download accelerator, written in Rust Zou is a Snatch fork by @k0pernicus. Snatch is a fast and interruptable download accelerat

Antonin Carette 173 Dec 4, 2022
GTK application for browsing and installing fonts from Google's font archive

Font Finder This project is a from-scratch implementation of TypeCatcher in Rust. It is a GTK3 application for browsing through and installing fonts f

Michael Murphy 252 Dec 26, 2022
Linux Kernel Manager and Activity Monitor 🐧💻

Linux Kernel Manager and Activity Monitor ?? ?? The kernel is the part of the operating system that facilitates interactions between hardware and soft

Orhun Parmaksız 1.7k Jan 5, 2023
A project for automatically generating and maintaining Debian repositories from a TOML spec.

Debian Repository Builder A simple utility for constructing and maintaining Debian repositories. Configuration of a repo is based on the directory hie

Pop!_OS 52 Feb 7, 2022
Utility that takes logs from anywhere and sends them to Telegram.

logram Utility that takes logs from anywhere and sends them to Telegram. Supports log collection from files, journald and docker containers. More abou

Max Eliseev 85 Dec 22, 2022
A safe and ergonomic alternative to rm

rip (Rm ImProved) rip is a command-line deletion tool focused on safety, ergonomics, and performance. It favors a simple interface, and does not imple

Kevin Liu 781 Jan 7, 2023
A simple, fast and user-friendly alternative to 'find'

fd [中文] [한국어] fd is a program to find entries in your filesytem. It is a simple, fast and user-friendly alternative to find. While it does not aim to

David Peter 25.8k Dec 30, 2022
Untrusted IPC with maximum performance and minimum latency. On Rust, on Linux.

Untrusted IPC with maximum performance and minimum latency. On Rust, on Linux. When is this Rust crate useful? Performance or latency is crucial, and

null 72 Jan 3, 2023
CLI utility to move (or rename) your files to a new location and redirect all of its symbolic links, to the new path

Move Links CLI utility to move (or rename) your files to a new location and redirect all of its symbolic links, to the new path (or name). Usage execu

Ben Mefteh 18 May 22, 2022
Parallel finance a decentralized lending protocol built on top of the Polkadot ecosystem. Our unique approach will allow users to earn "double interests" from staking and lending their tokens simultaneously.

Parallel Finance A new Cumulus-based Substrate node, ready for hacking ?? Getting Started Follow these steps to get started with the Cumulus Template

parallel-finance 100 Dec 17, 2022
A system handler to get information and interact with processes written in Rust

A system handler to get information and interact with processes written in Rust

Guillaume Gomez 1.1k Jan 3, 2023
OCI Runtime, Image and Distribution Spec in Rust

oci-spec-rs Open Container Initiative (OCI) Specifications for Rust This library provides a convenient way to interact with the specifications defined

Containers 119 Dec 29, 2022