Just in case it helps anyone else, tio (https://github.com/tio/tio) is a great featureful alternative to picocom.
1,519 karma · joined July 7, 2012
Shame that the new workflow doesn't work well for your particular camera and setup - but I would encourage other people to try it, because it works great for mine.
We know :-) It very much seems there is no dt developer currently interested in this sort of correction, i suppose none are using such devices.
Just two reminders:
Such "missing support for my camera" started me to get into darktable code. A lot of code to be reused is there, there are already some hints, just go ahead :-)
Some comments above i suggested something ... :-)
If you want a hardware upgrade it's actually reasonably inexpensive to build something direct drive (which is how the real sub-30kg ones work). This gives you many advantages over the plastic gear type including a much faster response time and more accurate positioning.
Look for "gimbal motors", basically a large skinny pancake brushless motor. Combine those with a storm32, simplebgc or odrive and a magnetic encoder. A 3D printer will help.
You can also have a look at low cost suppliers of cheap UAV stuff if you want something fully integrated for you. A basic Gremsy, Viewpro or Siyi isn't that much more than your Amazon thing. Various software bugs but they can be worked around. The DJI units can sometimes be had used and some of the protocols have been RE'd already.
Nowadays this type of diving would be done using an eCCR (and backup open circuit), where some software on a microcontroller controls the amount of oxygen in a breathing loop. A scrubber (hopefully) removes the CO2. Changing the gas mixture as you go is required to reach these sorts of depths because oxygen becomes toxic at pressure, and gas density itself can cause issues with breathing.
https://valetudo.cloud/pages/general/supported-robots.html#i...
Every Rolls-Royce gas turbine FADEC runs ADA binaries on a custom processor [1].
It's also used extensively at Airbus. Lots of DO-178C (safety critical aerospace).
1: https://www.his-conference.co.uk/session/visiumcore-a-high-i...
He also runs an excellent ISP in the UK called AAISP which I can highly recommend (https://www.aa.net.uk)
AAISP build their own core & customer networking devices/routers from scratch (not Linux based) in the UK. They are fascinating to use - a completely different evolutionary tree to any other networking kit I've used. Some unique features.
Also, no mandatory login walls for toolchains and datasheets gets them a lot of goodwill in my book.
https://n-fuse.co/devices/tinyCurrent-precision-low-Current-...
https://www.hlsnewforest.org.uk/2024/10/24/reflective-collar...
You can write custom c++ modules for bits they don't have already, although that's pretty rare. Often used with HA but it works fine standalone with MQTT too, and deployment doesn't have to be from a server.
I use the "cab404" one and very impressed with it.
This is presumably a totally uncritical lazy press release copy paste. For goodness sake, NASA's Ingenuity is not exactly a secret and that's only the latest in a very long line of commercial coaxial UAS.
Looks like a perfectly nice coax, but exactly the same tradeoffs of much higher mechanical complexity for a slightly smaller operating footprint which make them less appealing for most use cases. The article completely glosses over the fact that most traditional X/+ designs fold for transport.
Pluses of my Pebble Time:
- A lovely always on e-ink screen (the Pine Time has a TFT that relies on wrist detect to be visible, like an apple or pixel watch)
- Much better battery life
- A perfectly crafted UX full of lovely little touches, it's hard to explain if you haven't used one. It's full of animations but somehow they aren't annoying. Bit like using BB10. You can tell the dev-years & care that went into knocking off all the rough edges. It's the opposite feeling of "f you you're the product" I get from using most modern "tech" (Windows/Pixel watch/etc etc).
- Brilliant timeline view
- Rock solid connectivity (again, better than android/pixel watches)
- Much nicer HW feel in terms of build & fit/finish
- Huge user base who created a massive range of apps & watch faces
- You can't print from Office you need to export to a PDF
- Then use our SecurePrintTM application to send your PDF to the printer. It uses a hard coded mTLS key to talk to our cloud so it's super safe.
- Also SecurePrintTM sends all your PDFs through our servers where we could read them because we control all the keys. We promise we won't though. Don't worry, they are mTLS encrypted on the way to our cloud!
I do understand your point - the current implementation of LAN mode would not be suitable for enabling on a network with very high security requirements. I just don't understand how Bambu think this improves things.
Why not add user controlled OAuth/mTLS to the X1E? Hell, make it additional paid extra. Right now, it seems like their new approach is worse for everyone.
While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.
Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.
https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.h...
Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.
The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.
I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing?
Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1E model has an ethernet port, all the others are WiFi only.
https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md
Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.
I can't personally see any fundamental issue with this design assuming the implementation is correct, but I'm curious if others can.
They are proposing requiring a secret signed certificate to carry out any actions beyond monitoring for both the cloud and local (on printer) MQTT servers. These certificates would be issued at the discretion of Bambu by their CSR, currently only for "Bambu Studio" their slicer, Bambu Handy (their mobile app) and "Bambu Connect" which will enable upload G-Code generated by third party slicer (a workaround for existing functionality being removed). This "secret" certificate has already been extracted from the Bambu Connect application as per the article as their new security model requires embedded this certificate into desktop applications.
The current design:
https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md
Connecting to their cloud MQTT requires a username and token already. These details are obtained via a HTTPS request to their login server using your bambu account (which requires a valid email & possibly captcha) to obtain a token. The cloud MQTT is TLS secured, although this is just to encrypt the traffic (aka HTTPS), it is not mutual authentication.
Connecting to the MQTT server hosted on the printer (aka LAN mode) requires a fixed username and a local access token (a random 8 digit number). This can be found via the physical display of the printer in a menu (or apparently cloud MQTT!?). This access token can be refreshed via a menu option again physically at the printer. To be clear, this token only allows to you connect directly to the local MQTT server running on the IP address of the printer, so in most environments this should only be the local network. This is also the password for the FTP server that can be used to upload/download sliced 3mf/gcode files.
Personally - this design seems ok to me? With an MQTT service properly configured to isolate user accounts from each other, this is a pattern widely deployed for embedded devices (Azure IoT, AWS IoT etc).
I don't see how the "DDOS" related issues they are claiming would be related to this specific design. If the issue is in the login server - well, that's prior to authentication anyway so nothing they are doing here will fix that.
If it's problems with your cloud MQTT service not being properly isolated - maybe fix that? If the DDOS is at L2, auth isn't going to help. You require logins tied to an email, you can block clients that misbehave once they are logged in.
Nobody is brute forcing the local MQTT server via XSS or something, because JS doesn't allow for raw TCP connections. Are they concerned about malicious software already on the network? Then rate limiting on the printer side or switch to a random length alphanum LAN token to increase keyspace.
I'm curious what more qualified people think, I cannot see any justications for their proposed design improving security. So either;
a) They've decided they are incapable of properly securing their MQTT cloud stuff and instead of fixing that just want to assume every client connected to their cloud MQTT servers is fully trusted. I'm sure that'll work great. Doesn't justify adding this to the local MQTT servers on the printers - if anything that reduces security, as to roll certificates you now have a long tail of printer firmware updates.
b) It's not about security
http://www.statsmapsnpix.com/2023/04/the-longest-line-part-2...
https://quinled.info/2019/06/03/what-digital-5v-12v-rgbw-led... good intro to the subject.
The mottramlabs or QuinLED boards don't have this problem.