Omacom foundation is behind the project Omarchy which is not only from a technical perspective bad but even worse on the political side.

You can read these thing [here](https://stopomarchy.org/) and this [reddit comment](https://www.reddit.com/r/linux/s/paUNJl2mgg)

Omacom has publicly said that its against the FOSS ideology and want to induce Proprietary/commercial software as a norm.

DHH, the Creator of Omarchy is an Far-right extremist and racist which you can read [here](https://stopomarchy.org/)

They are trying to destroy the linux community Culture and norms, ethical values, and the free software movement.

You might think that omarchy is open-source but there a difference between free software and Open source software which you can read [here] (https://www.gnu.org/philosophy/free-software-for-freedom.en.html)

Many Big corporation who already hate and want to end the FOSS ideas are donating to Omacom foundation and they have raised a total of 21 million dollar for there trash dotfile.

This is an Culture war againt the whole linux/FOSS communty not just another bad distro.

Come forward and save the FOSS ideology, not all but many proprietary software are an social problem and mixxed with these extremist right-wing ideology, there are terrorist!

Come together to save the FOSS culture

Long live the Free software movement!

The original reason I got into Linux was because I was forced to reinstall Windows after an update broke my system. And while I knew nothing about Linux, or NixOS, at that time; that impetus inevitably led me to appreciate reproducibility.

Now I can finally say, after 3 months of configuring, ricing, and testing - I’m at the point of being able to reinstall my NixOS setup from the minimal ISO, using a single command.

I’m fortunate enough to have an old laptop from work to actually test everything on bare metal, rather than relying solely on results from a VM. And after some trial and error, I have to say that it really feels like magic to just have everything set up, with minimal effort.

None of this is to say I’ve got the best setup or the coolest rice. This is just me appreciating all the work that went in to create such an amazing OS.

Thank you, NixOS for my first 100 days of pure enjoyment, and absolutely everything else.

Six months ago I posted here about the NixOS setup I built for the 30-PC computer lab where I teach.

At the time, it worked well for me, but it was still very much my setup: tied to one lab, one network, and a lot of assumptions I had accumulated along the way.

Since then I've been trying to turn it into something other people could actually install, understand, and maintain.

Today I released Nixorium 2.1.

The idea is still simple:

• one NixOS machine acts as the controller
• the lab is described declaratively
• clients can be installed and updated over the LAN
• only the controller needs Internet access
• applications still run locally on each PC
• student environments return to a clean state between lessons
• machines can be replaced and brought back to the same configuration

A lot of the work since my original post has been on the less exciting parts: separating private site configuration from the reusable framework, safer installation flows, recovery from interrupted operations, backups, diagnostics, VM-based release validation, CI, and documentation.

I also made a short 1-minute explainer, because describing this only in Nix terminology makes it sound more complicated than it is:

https://nixorium.org/

The source is here:

https://github.com/giovantenne/nixorium

One caveat I want to be clear about: Nixorium grew out of a real 30-PC lab, and I test releases in VMs, but hardware is hardware. Different firmware, NICs, switches and disk layouts can still expose things that virtual testing won't.

So now I'm especially interested in real-world feedback.

If you run a homelab, classroom, training room, makerspace, or just have a couple of disposable machines around, I'd be very interested to hear:

• what would stop you from trying this?
• which parts of the deployment/recovery story still feel unclear?
• what would you want to see before trusting it on real hardware?

And if anyone actually tries it on hardware different from mine, even a failed attempt would be genuinely useful feedback.

For context, this was my original post from six months ago:

https://www.reddit.com/r/NixOS/comments/1rqtu0j/i_built_a_reproducible_nixos_deployment_system/

-----

EDIT:

A lot of Nixorium is basically an attempt to automate and simplify the workflow I originally did by hand. If you're curious about where it started, the old v1 README from six months ago describes that setup and the manual steps much more directly:

https://github.com/giovantenne/nixorium/tree/11b87a9ca185b0d2a0f2f32bdd342dfba0677d55

I know three languages(Lua, Python and rust), which I know isn't a lot but at this point in my journey it's very easy to learn a new one. But nix just escapes my grasp, there are so many weird things and the documentation is so horrible. The complex packages like VSCode fhs and the fhs that wraps other packaged are insanely confusing and then there's complex flakes which have tests and have them run a vm. And then it just stops working and it spews forth a unreadable error message that makes you want to clamp your balls in a vise. Not to mention dentritic pattern with all It's helper flakes that have god awful documentation so you just end up reading the source which is incomprehensible.

Maybe it's just because I am not used to functional programming.

Nevertheless I am still going to keep using NixOS and with each year that passes I will understand more.

Disclaimer: Re-post approved by u/matthieum, as previous post was erroneously removed.

I’ve been working on a specialized string type called ColdString. The goal is to create the most memory-efficient string representation possible.

• Size: Exactly 1 usize (8 bytes on 64-bit).
• Inline Capacity: Up to 8 bytes (Small String Optimization).
• Niche Optimization: Option<ColdString> has no memory overhead
• Heap Overhead: Only 1–9 bytes (VarInt length header) instead of the standard 16-byte (pointer, length) pair.

(Since my last post, the 8th inlineable byte and null-niche optimization were suggestions from the community!)

ArcColdString

I'm presenting ArcColdString, a reference counted ColdString with 8 bytes overhead (inspired by arcstr).

• Same size and inlining rules as ColdString. Inlined strings are copied instead of reference counted.
• Heap Overhead: 8 bytes for the AtomicUsize reference count (in addition to the VarInt header).
• Smaller Reference Counts: ArcColdString32, ArcColdString16, and ArcColdString8 use AtomicU32, AtomicU16, and AtomicU8 counts respectively.

Usage

Available in https://crates.io/crates/cold-string/0.4.0

use cold_string::ArcColdString;

let first = ArcColdString::new("a string longer than one machine word");
let second = first.clone();
assert_eq!(first, second);

Memory Comparisons

Theoretical overhead on a 64-bit target, excluding the UTF-8 payload:

RSS bytes per unique string in a pre-sized Vec:

(If I'm not mistaken, string_cache is not a 1:1 comparison since it has to hash string contents, which is 40 bytes overhead?).

Reference Counting Performance

ArcColdString's primary goal is memory and portability. Second to that, my goal is to have ArcColdString's referencing counting performance comparable to Arc<str> and arcstr::ArcStr. While drop and clone speed is comparable now, there's still room for improvement.

Below are single threaded clone and drop measurements, done using criterion on AMD Ryzen 9 5900X 12-Core Processor (3.70 GHz):

Below benchmarks measured 4 threads cloning and dropping strings in a shared size pool of 1024, 16, and 1 string(s), using criterion on Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (2.59 GHz). The more strings in the pool, the less contention:

You can read more benchmarks and implementation details in https://github.com/tomtomwombat/cold-string

This is a fairly new article from Daniel Lemire (the SIMD expert, author of simdjson).

It seems to_string() need to use the same trick.

C++ wins by a wide margin at 5.4 ns per string. The trick is the small string optimization: a std::string stores short strings, directly inside the object. Our strings have at most eight digits, so C++ never calls the memory allocator.

Talk from recent Kernel Recipes about bug reports and fixes.

Interesting view on how bots report things, also interesting breakdown of certain "79 issues" which really were not that many in reality.

i quit oxy i’m on subs now but i still have fun here and there. love you guys!

Hey guys!

I've been building a GPU compute platform on pure stable-rust to let you write compute kernels directly in standard rust, Built entirely on Vulkan 1.3 (Compute) for the host api runtime & MLIR/LLVM for the backend JIT compiler.

It can make you write iters-enums-generics-etc.. in your function, and run it across GPU silicon, because the syntax is literally rust, It can execute on native CPU.

Here is a simple example:

```rust use enki::*; use glam::Vec2;

const COUNT: usize = 5;

// Declare the compute kernel with #[nam]

[nam]

fn scale_vectors(_space: &Space, input: &Vec2, output: &mut Vec2, factor: f32) { *output = *input * factor; }

fn main() { // Initialize the headless GPU runtime let enki = Enki::init();

// Allocate physical data directly in GPU VRAM
let in_gpu = gpu_vec![
    Vec2::new(1.0, 2.0),
    Vec2::new(3.0, 4.0),
    Vec2::new(5.0, 6.0),
    Vec2::new(7.0, 8.0),
    Vec2::new(9.0, 10.0),
];
let mut out_gpu = gpu_vec![Vec2::ZERO; COUNT];

let factor = 2.5f32;

// Record and dispatch directly to GPU silicon
enki.flow(|_| {
    scale_vectors.run(
        &Space::gpu_x(COUNT),
        &in_gpu,
        &mut out_gpu,
        GpuParam::new(factor),
    );
});

// Dual Execution: Run the exact same function on CPU native rust
let in_cpu = vec![
    Vec2::new(1.0, 2.0),
    Vec2::new(3.0, 4.0),
    Vec2::new(5.0, 6.0),
    Vec2::new(7.0, 8.0),
    Vec2::new(9.0, 10.0),
];
let mut out_cpu = vec![Vec2::ZERO; COUNT];

for i in 0..COUNT {
    scale_vectors(&Space::cpu_x(i, COUNT), &in_cpu[i], &mut out_cpu[i], factor);
}

// Verify bit-for-bit equivalence
assert_eq!(&out_cpu[..], &out_gpu.to_vec()[..]);
println!("\nGPU Results: {:?}", out_gpu);
println!("\nCPU Results: {:?}", out_cpu);
println!("\nCPU and GPU outputs match.");

} ```

Result:

``text enki_matmul on  master [✘!+] is 📦 v0.1.0 via 🦀 v1.98.1 ❯ cargo run Compiling enki_matmul v0.1.0 (/home/mohiman/Projects/enki_demo_pack/enki_matmul) Finisheddevprofile [optimized + debuginfo] target(s) in 1.86s Runningtarget/debug/enki_matmul`

GPU Results: [Vec2(2.5, 5.0), Vec2(7.5, 10.0), Vec2(12.5, 15.0), Vec2(17.5, 20.0), Vec2(22.5, 25.0)]

CPU Results: [Vec2(2.5, 5.0), Vec2(7.5, 10.0), Vec2(12.5, 15.0), Vec2(17.5, 20.0), Vec2(22.5, 25.0)]

CPU and GPU outputs match.

enki_matmul on  master [✘!+] is 📦 v0.1.0 via 🦀 v1.98.1 took 2s
❯ ```

I've verified it on Linux (Docker Container Testing) & Windows (Wine) & colab T4, and my intel UHD laptop, every thing was great, i'd really love your help testing across more diverse hardware (AMD, Nvidia, Intel)

You can test SDF showcase in 3 commands:

bash git clone https://github.com/enkiruntime/enki_sdf.git cd enki_sdf cargo run --release

(pressing space will toggle execution from GPU (Enki) to CPU (rust-rayon))

• GitHub Repo: https://github.com/enkiruntime/enki

Enki is currently in Public Alpha (v0.2.x) release, I would really appreciate any feedback, architectural thoughts, or bug reports.

Titan Army only ships a Windows tool for the P275MV PLUS, so I reverse-engineered the monitor's DDC/CI protocol and wrote a Linux app (Rust, GTK4/libadwaita) that does the same from your desktop. It is free and open source (MIT).

What it controls

• All 15 picture modes with their Custom settings (brightness, contrast, gamma, color temperature and RGB, hue/saturation, Color Enhance, Shadow Balance, Night Vision, Dynamic OD, local dimming, Halo, DyDs)
• HDR (and it switches system HDR on KDE Plasma along with it), Adaptive-Sync, game overlays (crosshair, stopwatch, magnifier, HawkEye)
• Inputs, PIP/PBP, USB hub, volume, LED lighting, OSD settings
• Tray menu with favorite modes and settings, and it follows changes you make with the monitor's buttons

Extras

• The protocol notes and every VCP code I found are documented in the repo, with small Python tools (getter, setter, table reader)
• The repo also has both official firmware packages with an English translation of the update guide

Install: deb, rpm, AppImage and tar.gz on the Releases page.

Please note: it is alpha software, it writes settings to your monitor, and you use it at your own risk. I tested it only on one monitor (P275MV PLUS), so I'd love feedback from owners of the regular version. The code was written with the help of an LLM, which the README says openly.

Repo: https://github.com/mkarenko/titan-control
Support: https://buymeacoffee.com/mkarenko

original post

For a few weeks now, I've been taking anxiety pills in the hopes that they would help me feel calmer and more in charge. But I don't feel much different so far. I still feel anxious when I wake up and quickly get stressed out. I also act the same way I did before I started them. There hasn't been a precise moment when I thought, This is working.

For some reason, I keep hearing that supplements need time to work. This makes it hard for me to decide whether to keep taking them or stop. How long did it take for you to notice a real, long-lasting change after taking supplements for anxiety? What did you see that they were working for you?