alchemio (u/alchemio)

alchemio commented on Stdio(3) change: FILE is now opaque undeadly.org/cgi?action=a... · Posted by u/gslin

notepad0x90 · 2 months ago

it's already not working that way in Linux, it's just that there is no rhyme or reason to it. Even on stable Debian I have to have pipx/pyenv/venv for python and juggle multiple versions of rust and go because of mismatches between software and distro versions.

alchemio · 2 months ago

Python, rust and Go aren’t beacons of software stability though.

alchemio commented on Memory Safety Features in Zig gencmurat.com/en/posts/me... · Posted by u/todsacerdoti

alchemio · 4 months ago

Zig’s general purpose allocator might detect use after free in debug builds, however zig appears to be ok with dangling (invalidated) pointers/slices and use after free for stack variables, which is more concerning, especially from a security standpoint.

```zig

const std = @import("std");

fn get_ptr() i32 { var a: i32 = 6; return &a; }

pub fn main() void {

    var x: ?*i32 = undefined;
    {
        var a: i32 = 5;
        x.? = &a;
    }
    std.debug.print("{} {}", .{ x.?.*, get_ptr().* });

}
``` These are trivial examples that Zig doesn’t even warn about, even though similar code in C or C++ gets a warning in gcc and clang.
This discussion:
https://ziggit.dev/t/what-makes-ban-returning-pointer-to-sta...
indicates that core zig devs aren’t interested in diagnosing such usage.

alchemio commented on Asahi Linux lead developer Hector Martin resigns from Linux kernel lkml.org/lkml/2025/2/7/9... · Posted by u/Mond_

steveklabnik · 7 months ago

It's nonsense because if his C code breaks the Rust binding or drivers, that is not his problem. It adds zero maintenance for him.

alchemio · 7 months ago

But it does. He has to notify R4L of what his changes were and how it broke the Rust driver. Even if he didn’t, he will still be contacted for information regarding these things.

alchemio commented on Asahi Linux lead developer Hector Martin resigns from Linux kernel lkml.org/lkml/2025/2/7/9... · Posted by u/Mond_

steveklabnik · 7 months ago

The person who quit was not the author of the patch, or a member of Rust for Linux.

alchemio · 7 months ago

So they stirred a whole lot of drama for not much, potentially harming R4L.

alchemio commented on ruffle-rs/ruffle: A Flash Player emulator written in Rust github.com/ruffle-rs/ruff... · Posted by u/rcarmo

alchemio · 8 months ago

Flash apps and Java applets (via Cheerp) can run again in browsers thanks to wasm.

alchemio commented on Microsoft donates the Mono Project to the Wine team mono-project.com/... · Posted by u/itherseed

alchemio · a year ago

Embrace, Extend, Extinguish, Endow

alchemio commented on Curl will be dropping Hyper due to lack of maintenance github.com/curl/curl/blob... · Posted by u/pjmlp

alchemio · a year ago

> It is undoubtedly hard work to fix these remaining problems, as they typically require both rust and C knowledge in addition to deep HTTP familiarity. There does not seem to be that many persons interested or available for this challenge. Meanwhile, there is little if any demand for hyper from existing (lib)curl users.

You might as well replace HTTP with OS, hyper with rust and curl with linux, and you get the current situation with Rust adoption on Linux.

alchemio commented on State of Text Rendering 2024 behdad.org/text2024/... · Posted by u/behdad

alchemio · a year ago

RustyBuzz is quite limited when compared with HarfBuzz. The Rust fonts scene also seems to lack the necessary momentum to drive things through. I’m not sure whether it’s because the Rust community is mostly interested in webtech or whether Rust itself makes it hard to solve such complex problems. But I don’t see the sands shifting in less than 10 years to come.

alchemio commented on The search for easier safe systems programming sophiajt.com/search-for-e... · Posted by u/praseodym

DanielHB · a year ago

My gut feeling agrees with you but I would really like more detailed reasons why this is the case. Is memory fragmentation that big of an issue? Are heap allocations more expensive somehow (even if memory is not fragmented yet)? Is there something else? Does re-arranging memory in the heap makes performance unpredictable like GC languages?

alchemio · a year ago

Memory allocation is slow and undeterministic in perf. Some allocations also require a global lock on the system level. It’s also a point of failure if the allocation doesn’t succeed, so there’s an extra check somewhere. Furthermore if every object is a pointer you get indirection overhead (even though small but existent). Deallocation as well incurs an overhead. Without a compacting gc you run into memory fragmentation which further aggravate the issue. All of this overhead can be felt in tight loops.

alchemio commented on Xmake: A cross-platform build utility based on Lua github.com/xmake-io/xmake... · Posted by u/flexagoon

lionkor · a year ago

You need a standard, and ofc if theres one standard, theres two, and then theres 10, and so on.

You endd a standard because you don't want everyone to have to learn a new tool every time.

If you just want a script, Make is the one to use. You just write your bash in there and it works.

alchemio · a year ago

Which make? I’m guessing you mean gnu make, well there’s several incompatible variants as bsd make and nmake. Also bash is not universally used, not windows, not current macos.

u/alchemio

KarmaCake day48May 18, 2023View Original