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.
1 and 2, I don't have any of these issues when I use torrents.
3, People already uses torrents for distribution of content unrelated to Zig, the Zig population is way smaller than the torrent population. Heck, people already uses git for unlawful content, that doesn't cause problem for the vast majority of git users.
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?
Right now I believe GNOME is literally the only Linux desktop environment in the world that can:
1.) Enable RDP connections to Wayland sessions, whether they are already running locally, or not (i.e., start a new session if none exist when logging in remotely)
2.) Set that up via SSH, for a remote machine that has no display and anyway is remote so you cannot physically log into it (still very fiddly, but possible)
My requirement is just that every system be remotely accessible via both GUI and CLI. So, RDP (or, theoretically, VNC over SSH would be OK) and SSH.
In the old X11 days, all major Linux distributions met this bar. XRDP worked most everywhere. But Wayland is a very different story.
The only Linux distribution that has Remote Desktop working on Wayland is Ubuttnu 25.04 ("working" per the above, not some "log into the GUI first locally, and then share your desktop" — that almost works in KDE but the experience is very buggy).
The previous editions of Ubuttnu with GNOME almost worked, but logging in remotely would kill any GUI sessions already running locally.
I can still achieve this using X11, so I do. But that doesn't work for my own personal workstation, because I have too many modern (4K or better) monitors for X11 to reliably work. So I need Wayland to drive my actual, physical monitors — and therefore am stuck with GNOME, because I really do need occasional remote access to the entire machine.
I connected to RDP sessions from Linux, macOS, and Windows. (And actually, iPadOS — using Microsoft's app which used to be named "Remote Desktop" but then they bizarrely renamed it "Windows" — leaving me in the rather ludicrous position of saying "I make a remote desktop connection from my Apple iPad to my Arch Linux workstation, using Windows from Microsoft..." ¯\\_(ಠ_ಠ)_//¯
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.
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.
Are you sure? IIRC :x only writes the file again if there's a change where :w(q) always writes again (which takes longer when editing a remote file via scp://). For a non-exiting version of :x there is :up. I bound :up to <leader>fs after I learned about it. I used to have :w on the same keybind so it was a straight upgrade. Now I can just quick hit it at any time and there's no waiting around if the file hadn't changed. Saves some time and annoyances.
Yes, through ":help wqa" which lists it as such and double checking with a quick test. It doesn't write unchanged files, same as :xa instead of being an exact "all" version of :wq
:P :Print
:[range]P[rint] [count] [flags]
Just as ":print". Was apparently added to Vi for
people that keep the shift key pressed too long...
This command is not supported in Vim9 script.
Note: A user command can overrule this command.
See ex-flags for [flags].
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.
I have to disagree. The differnce in in degree. salemanship and fraud are two different things. Painting a rosy picture of something is difference than lying about specific capabilities. Giving your production capacity using the most ambitious numbers is different than saying you can produce numbers you factually can't in any scenario. Having a future roadmap that is a goal and may not be achieved is different than promising a capability in the near future, as if it is almost ready, when there is no capability coming is lying. That's like saying a Ponzi scheme is just another investment.
reply