@occhiolist TBH, I had to do a web search to find out what systemd-homed even is :-) So I guess I don’t possess that information.

My guess is that systemd-homed should not need to support at least when having LVM on top. User space is unaware that there even is encryption for the most part (except tools that specifically communicate with firmware/UEFI/MOK for e.g. grabbing a recovery key). For me it is pretty hard to make a corner case but I don’t have hard data. on this one. Hope this helps.

I use now #TPM2 sealed LVM/LUKS2 encrypted partitioning in my Linux desktop. No need to type password anymore when booting up great. #Linux #TPM

I switched to #helix editor because three advantages weight me more than disadvantage of having to learn away for #vim shortcuts:

1. Too much legacy.
2. Too many plugins.
3. It is a varying challenge to install the latest version #neovim, which anyway needs to be done in order not to break init.lua (and that big pile of plugins).

So for the price of few weeks inconvenience I can stop spending time on text editor configuration and/or figuring out on how to install it.

I used #vim and later on neovim fo the period 1998-2023, even before using Linux. I switched to vim in MS-DOS from text editor called #QEDIT :-)

Does Rust #Linux already have bindings for network drivers? I’m thinking of making #lowRISC Ethernet driver because the one provided by OpenHW Group is a corpse. It is like made for v5.7 and since not updated. This is the one that is used in #CVA6.

#rustlang

I think I fixup lookup tables for escaping #zmodem traffic by intercepting traffic from lrzsz with “defacto” parameters, i.e. send large chunk of uniform distributed random data. That way I can be sure that I have all the cases, including those not in the specification form 1988.

Later on I can use that as a CI test for my crate. Sort of fuzzing approach. I just need to record all bytes that follow ASCII 24 and that builds my table.

nice that #github allows to turn off issues, if only "pull requests" could also fully disabled #microsoft

I’ve been using Rust professionally way or another for about 2 years now and at least this and also lack of e.g. BufRead abstraction (sorry trait) has been something that I’ve been cursing to this day because it enforces you to do totally unproductive boilerplate and glue for everything you do with Rust. So definitely a huge improvement is this… Doing some RidiculousError type for every no_std thing is just terrible IMHO. For 95% of stuff I’d rather use just predefined error codes. It also improves productivity by factors when all your crates communicate with same error codes.

Abstraction only ever make sense if they have some meaningful functional use. Otherwise, they are just code bloat.

@ukuli ei mua ihan kauheasti kiinnosta sannan asiat :-) lähinnä kiinnostaa oman elämät ilot ja surut. live and let live ja näin päin pois...

embedded-io and embedded-io-async seem to be something i would want to use also for crates meant to be used with std just to future-proof portability. great that there is solution for std::io issue finally. for me the disability to e.g. not being able to use std::io::Error in no_std code has been a huge turndown.

and since these are provided by the Rust HAL team there’s some trust for long-term lifespan. 3rd party solutions in the basic error types and BufRead is a maintenance risk imho.

this is good enough as far as i’m concerned

#rustlang #embedded

@monsieuricon just like netflix used to work as a postal service

Little known fact: first kernel releases were shipped via the postal service.

I don't really understand why the original ZMODEM spec did not specify these with charts in the first place (like ASCII charts):

https://github.com/jarkkojs/zmodem2/issues/7

Super complicated, inefficient branching and no good reason, not even then:

```
pub const fn escape(value: u8) -> u8 {
match value {
0xff => 0x6d,
0x7f => 0x6c,
0x10 | 0x90 | 0x11 | 0x91 | 0x13 | 0x93 | ZDLE => value ^ 0x40,
// Telenet command escaping, which actually necessary only when preceded
// by 0x40 or 0xc0, meaning that this could be optimized a bit with the
// help of previous byte.
0x0d | 0x8d => value ^ 0x40,
_ => value,
}
}
```

Overwriting data is the new "goto" sort of looking at more modern languages than C :-)

This is my ultimate goal with #tior: a multiplexed #TTY and file transfer through serial. It won't happen fast I'm barely gettting #ZMODEM together and need to finish the UI for my client after that.

Here I've carved up high-level goal what I have in mind: https://github.com/de-vri-es/serial2-rs/issues/6#issuecomment-1837024452

IMHO this is totally modern world thing. When I was still working e.g. with Nokia Linux phones security, earlier that on #Symbian, serial port was used a lot. Then it sort of phased out for a number of years in my work life but today with the maker community, all sorts of #SBC's and affordable #FPGA's the stocks are rising again. Of course if you've been all the time working on embedded, serial has been around for all this time. It is pretty weird that minicom and lrzsz still rock the world in that arena.

When you work on a a power on for a new hardware device, it is the first channel that gets usually enabled. And e.g. like any FPGA design or something you put to let's say to Arduino it is simplest route to get some communications on going.

So yeah, I really think this sort of endeavour does matter.

@epicEaston197 All cool. I don't mind. It was a bit culminated statement I made :-) I don't mind growing outreach but being like it is not bad either.

@epicEaston197 Fun fact: Google+ was hugely popular among kernel developers. That does not give a good prognosis for the success of Mastodon :-) For me it is not an issue tho because I care more about this as a productivity application than social media :-) Only social media account I've ever had has been Facebook (OK, couple of short spin offs to Twitter too) and that for the most part staying in contact with relatives.

I care exactly about Mastodon because social media madness, influencers etc. do not exist here. I'm happy that Mastodon is unpopular sort of TBH

So I did a pull request to the hex crate:

https://github.com/KokaKiwi/rust-hex/pull/83

This sort of scenario is not too uncommon in data flows especially when you want to squeeze everything bit out. E.g. for something like #ZMODEM you’d prefer the implementation to scale from microcontroller to Intel Xeon.

Usage example in my crate:

        if encoding == Encoding::ZHEX {
            hex::decode_in_slice(&mut out).or::<io::Error>(Err(ErrorKind::InvalidData.into()))?;
            out.truncate(out.len() / 2);
        }

#rustlang

E.g. if you have a hex string in stack, you could convert it to a binary to either head or tail of that memory block by overwriting it as you iterate. Further any data conversion where you convert any data from more sparse format to more compressed format.

E.g. I could have saved 7 bytes of stack by doing that sort of thing but do not want to do the effort because of inconvenience :-) Making world bloat again

One thing where #Rust is pretty inconvenient to use IMHO, when you want to optimize your code in a way that you want to modify data "within its space". I.e. purposely overwrite the same data chunk that you are iterating. Totally doable but not something you tend to do. Sort of thing that is against its design principles. #rustlang