kozaxinan

package foo

import androidx.compose.foundation.BorderStroke
import androidx.compose.foundation.background
import androidx.compose.foundation.layout.Box
import androidx.compose.foundation.layout.Row
import androidx.compose.foundation.layout.fillMaxWidth
import androidx.compose.foundation.layout.height
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.layout.size

grantbevis

{ config, lib, pkgs, ... }:

let

  minecraft-bedrock-server = with pkgs; stdenv.mkDerivation rec {
    name = "${pname}-${version}";
    pname = "minecraft-bedrock-server";
    version = "1.17.11.01";
    src = fetchurl {
      url = "https://minecraft.azureedge.net/bin-linux/bedrock-server-1.17.11.01.zip";

Ellivers

Good Data Pack Practices and Common Tricks

Structuring and Consistency

An organized structure to your data pack's folders and file names always helps you understand your code better and leads to less bugs. Place files that have something in common in the same folder, and name them based on what their purpose is.

Consistency in naming stuff like tags, files, and scores can help keep you sane. Always have a clear structure in place, such as prefixing tag and objective names with your namespace (namespace.name) and giving tags different categories (namespace.entity.name, namespace.block.name).

If you are unsure of how a good structure could look, you could take a look at some vanilla assets, such as the lang file or the built-in data pack, as well as get ideas from looking at data packs that other people have made.

markus1189

{ pkgs ? import <nixpkgs> { } }:

(pkgs.buildFHSUserEnv {
  name = "DungeonDraftFhs";
  targetPkgs = pkgs:
    with pkgs; [
      alsaLib
      libglvnd
      pulseaudioLight
    ] ++ (with xlibs; [

mainrs

{
  "labels": [
    {
      "name": "type: bug",
      "description": "Something isn't working",
      "color": "ee0701"
    },
    {
      "name": "type: enhancement",
      "description": "New feature or request",

comp500

This list has moved!

See https://github.com/comp500/fabric-serverside-mods for the latest mod list!

lu4nm3

use futures::StreamExt;
use std::error::Error;
use tokio;
use tokio::macros::support::Pin;
use tokio::prelude::*;
use tokio::time::{Duration, Instant};

pub fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut multi_threaded_runtime = tokio::runtime::Builder::new()
        .threaded_scheduler()

CRTified

VFIO Setup on NixOS

Disclaimer: Nobody else tested my setup so far, so this is a "works on my machine" scenario. I am not responsible for anything you break on your machine (although I'd not expect much harm).

Hardware

My system has the following hardware:

• Board: ASRock X570 Pro4

gusmacaulay

with import <nixpkgs> {};

stdenv.mkDerivation {
    name = "postgresql-inside-nixshell";

    buildInputs = [
        glibcLocales
        (pkgs.postgresql.withPackages (p: [ p.postgis ]))
        sqitchPg
        pgcli

CMCDragonkai

Linux Kernel Modules for NixOS

You can find what kernel modules are loaded using lsmod.

However some kernel modules are required at stage 1 boot. Basically preloaded in the initial ram disk before switching to the root filesystem. These kernel modules are mostly needed to deal with peripherals, storage devices, filesystems and network devices. You may need to be wary of these required modules:

• sd_mod - SCSI, SATA, and PATA (IDE) devices