@echo_pbreyer die Fragen sind halt schon sehr offensichtlich so gewählt, dass die ansprechendste Meinung mit der der Piraten übereinstimmt. Enttäuschend, aber wenigstens wird nicht zu sehr versucht es als neutral darzustellen.
XMPP - seems neat, but is obviously an old protocol :p
Some paint points trying to set it up in my cluster:
Requires certificates available to the software (Prosody) directly. Not a huge issue but minor gripe.
XMPP requires non-HTTP ports open. Not a huge deal, but more hassle in Kubernetes.
Wants to use on-disk state for some things. More Kubernetes annoyance.
This would all work fine if I wasn't trying to cram it into Kubernetes. Oh well, would've been nice to have but I probably have enough chat apps available to me right now anyways!
@arch yes, these all seem like kubernetes problems first and foremost :p if you're having fun, by all means continue, but it happens way too often that people waste a bunch of time with such things when they could just be running a single binary with its single config file and single data directory.
@arch the fact that your alternative is "... and Docker Compose it" says a lot :D no, I meant just installing the distro package, setting up the config, and starting the systemd service. If you need a reverse proxy or database, do the same steps for those as well. Much less hassle in the long run than anything Docker or even more abstract in my experience.
every month, to request a refill on my meds:
• go to website
• GDPR cookie prompt, click sign in
• enter password (the “stay signed in” box doesn’t work)
• enter code from SMS
• skip reminder to enable TOTP
• cookie prompt 2
• click re-order
• delete the “you logged in!” email
@Ninji that's pretty terrible, but it feels like most of those issues could actually be improved by adding just a little more software on top (Consent-O-Matic, password manager autofill for TOTP, email filter).
@whitequark @Ronflaix hah, I figured - you should give Element X a try if you haven't already, it's starting to be actually usable (and it's significantly less janky than eledroid)
Thinking more about firmware update mechanisms and provisioning for the trigger crossbar (and my future open T&M projects).
I want something that is freedom preserving but also secure (i.e. ensures the owner can do whatever they want and outsiders are kept out). Thoughts so far, open to suggestions:
Out of the box, serial console is the only administration interface and is wide open (no login required), and the instrument is not reachable via network.
Once you log in via serial the first time, you can configure static or DHCP IPv4/v6 addresses and add a SSH key (or several) to enable SSH administration. There will be, by design, no support for password login.
Serial console may support password locking in the future for console concentrator type use cases, but generally speaking physical access implies you are the owner or authorized by them. You have access to all of the analog/RF signal ports anyway. JTAG/SWD on all devices will be left open for advanced users making custom firmware.
SCPI and waveform data will be unencrypted as is industry standard for performance, but may eventually support IP-based firewalling. At some point in the indefinite future I may support a SCPI-over-TLS control port but this is not on the near term roadmap.
Firmware updates will be performed by SFTP'ing a binary to a magic path (one path for each updateable MCU/FPGA in the system). No rollback protection or authentication required other than having a valid SSH key for the admin interface.
At some point in the future I may separately sign update images. If so, access to the admin interface will allow you to remove upstream signing keys and/or add your own. This is explicitly not intended as a DRM mechanism, it's to allow users to ensure their images haven't been tampered with. There will be no secure boot (verification of images each power up), only secure update (images verified before being written to flash or before marking the flash partition as bootable)
@azonenberg I think it's always nice to have a trusted environment that's higher-level than JTAG, but with less attack surface than the entire application firmware, i.e. a write-protected bootloader. It can do image verification and flashing, key management, etc. via serial console, basically everything you need to bootstrap a marginally reduced chain of trust without having to get out the JTAG.
My Matrix account was discovered the same day I put it online and hadn't announced it anywhere (except for a link on my website). :woozy_cat:
I figured I'd give it another chance since my first time was 4 or 5 years ago. Even though I do find it concerning that a chat protocol can have phenomena such as "split-brain situations". :drgn_woozy:
@Foxboron you see, HN isn't as much a link aggregator as a headline aggregator. People contribute their favourite headlines and use them as inspiration for creative writing in the comments. The fact that the headline also links to the publication in which it first appeared is more of a byproduct.
every game with vehicles must have an "arma mode" where a fender bender makes your huge truck just instantly explode and launch the people inside ragdolling towards the skyline
@whitequark well there's different types, the cheap "IR sensitive camera + LCD" ones really do have crap resolution, image intensifiers are much better.
@whitequark I can't recall which kind I used, but it really was astonishingly good even in moonless nights - in combination with a cryogenic thermal imager it was basically like day, just with a very narrow FOV.
hey RTL developers: would you be interested in a simulator integrating with a VSCode extension that shows you the values of all wires/regs inline in as source code annotations, lets you navigate back/forward using IDE shortcuts, and on each cycle highlights the assignments that are going to be taken on that cycle? (with the values also annotated on that line)
@Em0nM4stodon I don't think there's a particular job title for this, but it feels like it'd be relatively common in any compliance-heavy industry. Certainly takes a particular kind of person.
Ok, realized I was already a day late for #AdventOfCode that i wanted to do in #rust this year, to finally get some practice at it.
It's probably not the most beautiful rust code, but i didn't use chatgpt, only the compiler output and the documentation, and it is quite pleasing. Although there are still things that seem very pedestrian compared to Python, but it might be because i've a lot more experience with the latter, and don't know the nice tricks with Rust yet.
Will see how it goes.
@tshirtman oh, please don't post pictures of text :/ For most people it's harder to read, for some straight-up impossible. It also makes it impossible to try out modifications before suggesting them without typing it all out.
For rust specifically, there's https://play.rust-lang.org/, which allows not just sharing code snippets, but also running them right in your browser.
