What IDE/extensions do you use for open-source LLMs? I tried VSCode with ollama and lm studio, and the experience is very subpar to the built-in copilot. It's not very usable.
65 karma · joined April 11, 2023
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.
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.
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?
In other words, he doesn't do it out of malice. These are the rules of the game.
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, 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).
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.
Even for a simple web site.
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.
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.
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.
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.
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.
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?