Hi, Fedi.
I need your help. This project is based around the fundamental ideal of driving audio over a layer 3 IP network, *open source*. No Dante, no AES50, none of that. Open source only. To that end, I have run across Ravenna and AES67 as the only serious contenders, and I have Questions that need answers from people who understand the underlying protocol and possible implementations.
So, one... are there any other *serious* options for a/v-over-IP that i have missed (AVB doesn't count)?
Two, can anyone put me in touch with somebody who actually understands AES67/Ravenna in more than a passing way?
Please boost this and help me find answers.
Thank you.
After replacing the original 240V motor in my blower with a 120V one, and testing the concept (strapping it to a board and aiming it at some leaves in the yard), the first task was making the shape more manageable. I made a mount / chassis that matched the curve of the blower for it to mount into, a few small screws are all that is needed to lock it into place.
$2000 device with UNSERVICABLE battery "for your safety" randomly accelerates into people at 30mph π€
I love the fact that the #VAX tag refers to the actual DEC VAX machines in the Fediverse, while on Twitter, it's all about vaccines... The real anti-vaxxers are developers who exclusively use RISC processors like Alpha, ARM or MIPS. #retrocomputing
been using the format " tar -rvW video-tarball.tar &> /tmp/backup-results.txt" to take tarballs of my video projects and move them to tape. Problem is the verifying process, it tries to not only verify the tarball I am pushing to tape right now, but the entire rest of the tape, which it of course balks about since the point is to transfer to tape, not backup on tape. Thought I could use the -A to concatenate multiple archives, doesn't work that way tho. Now I see how to do it using MT to move around, but realized 2 things:
1) its WAY to easy for me to overwrite stuff on the tape this way.
2) should have coughed up the extra $$ to get LTO-5 and have LTFS.
4. Free Software client and server + federation (Example #Matrix and #Quicksy/#XMPP): respects users' freedom (as a user or as a community) and no vendor lock-in
5. Free software client + peer to peer design (Example GNU #Jami, #Briar, #Tox): respects users' freedom and no vendor lock-in
Vendor lock-in: Ability to switch service is too hard because it reauires convincing every contact to move to a new service.
#P2P messengers need both users online at same time to exchange messages.
1. Non-free software client and server + centralization (Example #WhatsApp): does not respect user's freedom and creates vendor lock-in
2. Free Software client but non-free server + centralization (Example #Telegram): client software respects freedom, server software does not respect freedom and creates vendor lock-in
3. Free Software client and server + centralization (Example #Signal): respect user's freedom but creates vendor lock-in
(1/2)
Right on!! Unfortunately this year I'm going to have to finally do some major cleanout, I have around 10 pcs, and about as many laptops in my storage, desktops range from p4- to athalon 64 (single core) I already culled P1 - P3 desktops last year, but I'm beyond out of space to its time to scrap some more stuff :/ It's amazing how little resources you need to run debian + windowmaker :)
those rca and scart connectors ^_^
The CRT-Bot Portable!
The latest in entertainment-companionship, now on the go!
π¦π: https://twitter.com/Thdark101/status/1335816473856663553
π ποΈ π οΈ πΊπ² π
I make stuff, modify stuff, fix stuff, maintain stuff, and occasionally I break stuff.
Middle aged Transwoman, Debian user since 1.1, vangirl, tractor rider, mountain biker.
(account is locked for creeper/scumbag control)
- Follow requests welcome
- DM's open to friendly people
- Iβll likely post project stuff here:
(van stuff, tractor stuff, bike stuff, computer stuff, & other stuff)
personal stuff at my alt (https://cybre.space/@KayEllen_CH41)