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.
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.
I'll add a disclaimer here that I don't buy new cars or trucks, so this doesn't really apply to me anyways.
My family's limited experience with powertrain warranties is that they don't mean anything. The manufacturer put a junk engine in my Dad's truck at the factory. When they replaced it, they replaced it with a junk engine. When confronted with this, the dealer claimed it was not reasonable for a replacement engine to run without issues. Neither made it 30,000 miles.
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.
It's unfortunate that the original authors of this interface didn't understand how important infallibility is to resource deallocation, and it's unfortunate that NFS authors didn't think carefully about this at all, but if you follow the advice of the text you pasted and read the section about how you can't retry close() after an error, it is clear that close is, in fact, a fundamentally infallible operation.
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).
If the tape drive failed close() in a way that did not deallocate the file descriptor, that was just straight up a bug.
Retrying close() is dangerous, if the file descriptor was successfully deallocated, it might have already been re-allocated by another thread. I'd guess the program you're describing was single threaded though (it can still bite there though)
> 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.
Why can't the OS itself do the prompting in this case, as part of processing the original close()? MS-DOG had its (A)bort/(R)etry/(I)gnore prompt for failing I/O operations, and AmigaOS could track media labels and ask the user to "insert $MEDIA_LABEL in drive".
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.
> which of those devices should the kernel use for output?
Whatever facility it uses for showing kernel panics, perhaps. Though one could also use IPC facilities such as dbus to issue a prompt in the session of whatever user is currently managing that media device.
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.
There was a recent Zig podcast where Andrew Kelley explicitly states that manually defining a VTable is their solution to runtime polymorphism [1]. In general this means wrapping your data in a struct, which is reasonable for almost anything other than base value types.
