MrResearcher

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?

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.

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.

Don't forget to post the link here!

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

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?

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.

Can we get an atom or RSS feed for that blog, so it would be possible to check for future posts?

I generally recommend to exit either via :xa (save all & exit) or :qa! (discard all and exit), bound to ZZ or ZA respectively. If you exit via :q or :wq, it just closes the current buffer, and moves to the next one. E.g. if you have a neotree open along with the editor, you type :wq, it closes the editor buffer and moves you into the file tree, which can be very confusing for beginners.

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.

The powertrain warranty is usually 5 years or 60K miles. Bumper-to-bumper warranty is around 3 years, I think. I would be OK with the loan for as long as powertrain is covered, at the very least. The modern day turbo engines have exceptionally low reliability, it will blow while you still owe quite a bit for the car.

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

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).

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's still not clear to me how you can make two comptime closures with different contents and pass those as a functor into the same function. It needs to have a sort of VTable to invoke the function, and yet since the contents are different, the objects are different, and their deallocation will be different too. Defining VTable in zig seems to be a pretty laborious endeavor, with each piece sewn manually.

I'm afraid to host my web sites myself simply because I don't trust my ISP. It's rather reliable, but it does go down ~once a quarter, and relying on them would be highly inconvenient. Therefore, I have to choose between Hetzner vs VPS vs cloud (AWS, GCP, etc) vs colocation. After doing all the math and judging my ability to deal with hardware and software upgrades, at the end of the day hosting in the cloud isn't really that much more expensive and it's the least troublesome.

Even for a simple web site.

And I'm telling you that your position is suboptimal and in the long term will lead you nowhere. You won't be able to switch any noticeable number of consumers away from Amazon by telling them that they lie, nor would anyone listen to you.

However, if you teach people how they can obtain DRM-free material, store it, and consume it in that format, that and only that can make the difference.

Amazon is effectively a monopoly at this point. Many books are available exclusively through them. I doubt that the US court system would look into this segment of market any time soon. They still can't decide what to do with Google, and that took them how many years? I doubt we will be able to resolve this problem in our lifetime.

There are well-known ways to extract Amazon books as PDFs, iTunes videos as DRM-free video files (with subtitles and audio tracks!), download youtube videos and movies, etc. Plenty of instructions on certain popular web sites that shall not be listed. So, there's an opinion that the audience you're referring to is, in fact, "buying" the books and movies, and not renting them, for as long as you are willing to exercise your technical "prowess".

What is the purpose of DisposableStack.move()? Can it be used to transfer the collected .defer() callbacks entirely out of the current scope, e.g. up the call stack? Probably would be easier to pass DisposableStack as an argument to stack all .defer() callbacks in the caller's context?

That still requires the usage of dev tools and linear source code mapping between the original and the generated WASM, correct? Would it be possible to avoid dev tools, and implement the debugger in Javascript? Or the WASM technology doesn't provide such an opportunity? I'd like to break on breakpoints, jump back into Javascript, unroll it into the original location in the source code, and display it all in an IDE-like window all within a browser page, and without involvement of dev tools (that can't handle non-linear conversions between source code and generated JS/WASM).

Sadly, no, I'd like to write a ~Prolog interpreter (compiler into WASM that would dynamically replace parts of the implementation as source code evolves), and have the debugger and WASM memory inspector as part of the web page written in Javascript, which was used to compiled the code in the first place. That is, would it be possible to implement a debugger and memory inspector in Javascript without resorting to dev tools? Prolog doesn't map 1:1 to WASM/Javscript via source maps, making it nearly impossible to properly debug it in dev tools.

Is it possible to "instrument" the WASM code to enable in-process debugging? In other words, would it be possible to generate WASM based off some input string (my custom language) on-the-fly, and then run it with breakpoints and memory inspection, all within the same Javascript script hosted on, say, a web page?

<a aria-hidden="true"> ... </a> will result in a link ignored by screen readers.

The biggest tragedy with Apple iPhones is that you can't install GrapheneOS on them. Non-profit 100% open source is the only feasible way forward for cellular devices.

we probably won't ever reach the "whole stack is open top to bottom" future that people like RMS dreamt about

We will because that is the only sustainable mode of operation in the long term. Every proprietary stack goes through ups and downs, and is eventually displaced. You must be open to persevere.

It's just a matter of time.

Damn, you really got me scared there for a second. Just re-checked by Debian 12 systems on AWS, I don't have any files residing in *.d directories. So I confirm that if you used the official AWS Debian image, you wouldn't get it.

And if you downloaded and installed the authentic Debian 12 image from debian.org, you don't get it either. Must be a Ubuntu thingy.

I'd love to see a memory efficient and performant implementation of lock-free skip lists written in Haskell, and it'd better beat my C++ implementation!

Laziness incurs amortized costs all over the place, and makes reasoning about the application state more difficult, can you help me justify the cost for the extra electricity?

And, btw, last time I wrote a web server in Haskell, I was very much surprised that the standard way of implementing it was to use lenses, which mimic imperative style of assignments to a variable. And logging. Turned out you need logging for anything real, and in Haskell they are side effects implemented via a dirty hack that can be invoked anywhere.

Finally, you can pry my Knuth tomes from my dead cold hands.

On a more serious note, if you are really into immutability and functional style, F# is deemed to be a far better and practical choice. I reserve only praise for Common Lisp and Clojure, although I typically prefer static typing.

It's more akin to limiting the size of each shoe, rather than the number of shoes. The client might need memory for computational purposes. I routinely have more than 7 GB worth of inference output to be displayed. I can only display a portion of it at a time, and I react to every mouse move to render the ML annotations, which rely on that underlying 7GB array.

Laptops handle it just fine. I have no problems with macbook, for as long as there's no memory caging enforcement. I'd imaging, running it on a cell phone or a tablet should be feasible too.

Same problem with the modern-day Chrome. Gotta recompile it without memory caging just to let the web app to allocate more than 4GB of RAM.

You may argue that you don't want it. You might say that you don't want a damn web page to consume more than 4GB. And I agree, it's true for many applications. Up until the moment you decide to start dealing heavily with ML datasets, and all sort of high-resolution images, time series, bayesian inference etc. And now the limit is no longer sufficient.

We already had folks thinking that 64KB are surely enough for everyone. Then we introduced segment registers CS, DS, ES, SS to address more than 64KB. You remember that sad story? Then we got a breathing with 64-bit mode, with all pointers able to reference the entire memory (well, at least in ring 0.) Are we sure that 4GB are enough for everyone? Aren't we coming into the same trap again?

I vaguely remember back during my university days, the Discreet Math professor proved mathematically that base e=2.71828... was most efficient. And concluded that the optimal base would that of 3 or 2. Unfortunately, I no longer remember the basis of his argument, nor the entailing proof.