MrResearcher

قبل 4 أشهرdiscuss

What is the roadmap to ML on FreeBSD? From what I could find, apparently neither CUDA nor ROCm is supported? And there are no short-term plans to address the lack of hardware support for ML?

MrResearcher

قبل 4 أشهرdiscuss

Running a ~20Kloc 0.16 Zig in prod, compiled and deployed as DebugSafe. No issues, superstable. This was rewrite of Node.js/Typescript computation module, and we chose Zig over Rust due to better support for f128. Zig/DebugSafe is approximately twice faster than TypeScript/Node.js 25 for our purpose, with approximately 70% less memory consumption. We were not impacted by WriterGate and other recent scandals much because we primarily rely on libc, and we don't use much of Zig's I/O standard lib.

Zig has a better support for sqlite/JSON serialization (everything is strongly typed and validated) than Node.js, so that was a plus as well.

Zig minuses are well known: lack of syntax sugar for closures/lambdas/vtable, which makes it hard to isolate layers of code for independent development.

We use Arcs (atomic reference counting) with resource scopes (bumper allocators) extensively, so memory safety is not a concern despite aggressively multithreading logic. The default allocator automatically detects memory leaks, use-after-free, etc so we are planning to continue running it in DebugSafe indefinitely. We tried switching to ReleaseFast and gained about 25%, which is not that much faster to lose memory safety guarantees.

MrResearcher

قبل 5 أشهرdiscuss

That will lead to the same set of problems currently manifested in bit torrent'ing:

1. You'll have to expose a port externally. God only knows who will attempt to take over it.

2. You'll have spammers advertising addresses of known businesses in attempt to get everyone to spam (initiate connections with) them.

3. Sooner or later people start distributing content not related to Zig, which will attract acute attention from law enforcement agencies.

Consider these to be my predictions.

MrResearcher

قبل 8 أشهرdiscuss

Don't forget to post the link here!

MrResearcher

قبل 8 أشهرdiscuss

No sir, but you have the honor of being the first!

MrResearcher

قبل 10 أشهرdiscuss

Could you please describe your remote access software stack in more details? What software/versions did you find more useful?

Can you connect e.g. from Windows to Linux and vice versa? Or from Android to Linux? I believe, KDEConnect was specifically designed to address this (https://kdeconnect.kde.org/), have you had a chance to give it a try?

MrResearcher

قبل 10 أشهرdiscuss

I've been using KDE-Plasma on Wayland (Debian 13) since release as a daily driver, and I'm happy to report that it is super stable, has no problems with waking up from suspend and hibernate, and is a superb all-around shredder. I didn't notice any glitches, or flickering, or bugs so far, despite intensive daily abuse.

MrResearcher

قبل 11 شهرًاdiscuss

It's not really a lie, it's so-called "make-belief", which entrepreneurs exude in order to justify their own time and money investment, as well as spreading it to the army of employees. This sort of delusion is necessary for the inaugural period of concept development, until you prove whether the concept is viable or not. Some people call it vision. It is an entirely fictional concept, of course. Sometimes you stumble onto something working that gets traction. Then this lie turns into reality, and the entrepreneur is raised to the rank of prophets.

In other words, he doesn't do it out of malice. These are the rules of the game.

MrResearcher

قبل 11 شهرًاdiscuss

Because DOS relied on BIOS interrupt 10h to handle I/O:

  mov si, GREETINGS_STRING
  print_loop:
    lodsb                  ; Load next byte into AL, advance SI
    cmp al, 0              ; Check for null terminator
    je done

    mov ah, 0Eh            ; BIOS teletype output
    mov bh, 0              ; Page number = 0
    mov bl, 07h            ; Light gray on black in text mode
    int 10h                ; Print character in AL

    jmp print_loop
  done:
    ...

  GREETINGS_STRING db "Hello, BIOS world!", 0

And linux doesn't rely on BIOS for output I/O, it provides TTY subsystem and then programs use devices like /dev/tty for I/O. Run $ lspci in your console: which of those devices should the kernel use for output? The kernel wouldn't know that and BIOS is no longer of any help.

MrResearcher

قبل 11 شهرًاdiscuss

If the flush (syscall) fails, it's not possible to recover in user space, therefore the only sensible option is to abort() immediately. It's not even safe to perror("Mayday, mayday, flush() failed"), you must simply abort().

And, the moment you start flushing correctly: if(flush(...)) { abort(); }, it becomes infallible from the program's point of view, and can be safely invoked in destructors.

File closure operations, on the other hand, do have legitimate reasons to fail. In one of my previous adventures, we were asking the operator to put the archival tape back, and then re-issuing the close() syscall, with the driver checking that the tape is inserted and passing the control to the mechanical arm for further positioning of the tape, all of that in the drivers running in the kernel space. The program actually had to retry close() syscalls, and kept asking the operator to handle the tape (there were multiple scenarios for the operator how to proceed).

MrResearcher

قبل 11 شهرًاdiscuss

Why is he wrong?

Here's an excerpt from the close(2) syscall description:

RETURN VALUE close() returns zero on success. On error, -1 is returned, and errno is set to indicate the error.

ERRORS EBADF fd isn't a valid open file descriptor.

       EINTR  The close() call was interrupted by a signal; see signal(7).

       EIO    An I/O error occurred.

       ENOSPC
       EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available storage space, but instead against a subsequent
              write(2), fsync(2), or close().

       See NOTES for a discussion of why close() should not be retried after an error.

It obviously can fail due to a multitude of reasons.

MrResearcher

Submissions

Supreme Court Considers Legality of Trump's Tariffs

comments