They're presenting it as a "intro to electronics" device. I think they've missed though, as far as I'm concerned, learning to build a "nLab" equivalent device from a bare AVR MCU would be a far more informative and useful introduction then yet another "Babies First blink.c" kit.
Even worse, a fully formed lesson plan, parts, and prerecorded lessons could actually be worth $200. Unlike this widget, which is not worth half that.
The spec page says 100 kHz BW on the oscilloscope, the FAQ says 400 kHz. In either case calling it an "oscilloscope" is a stretch, its the ADC channels on an MCU.
I find it curious that all their promo shots seem to only show the back of the board. I couldnt find any of the component side, or any information about what components are used. My guess would be:
- a very small dual rail supply
- AVR or STM MCU
- Signal generator is PWM through an RC low pass filter
- Oscilloscope is potentially just the input through a resistor network to shift +/- 5V to 0-5V, maybe a buffer to keep input impedance high.
I just don't see $170-200 of value here, or anything close to that.
Even weirder: the Kickstarter campaign says it’s 4 MSPS per channel. 100kHz bandwidth with 4 MSPS per channel just doesn’t make sense. However, they have “verified” 400kHz on their Kickstarter. Not sure who verified it, but it’s verified.
The Kickstarter does have product photos of the back in a gif but be forewarned: they don’t include any chip designations.
The specs are underwhelming, but I could see the value to a beginner being in the software that accompanies it tightly integrated with parts kits and instructions. I'd honestly prefer to see a logic analyzer instead of a mediocre oscilloscope; I feel like the projects that most people learning want to do these days are digital, and simple logic analyzers are more amenable to being cheap while still being useful.
I feel like building an nLab would be a far more valuable learning experience then using one.
The caveat being not just as a DIY soldering kit but as a full "course" in the design and construction of it.
Its got a power supply, an MCU, analog I/O, digital I/O. Learning the theory of how to read a 100kHz analog signal is far more valuable then a device that can read a 100 kHz signal.
A company operating above board would be sure to carefully document the state of the rental before and after whatever work they were doing. Any tradesperson/installer/technician/repair person will have tales of how they were accused of stealing grandmas wedding ring from the bottom of the sock drawer while repairing a leak in the kitchen.
So either Bot Company damaged property and is trying to pretend they didn't. Or they are incompetent and failed to document the state of the property or handle the owners complaints appropriately.
Given that their training robots and would therefore be collecting as much data as possible, including camera data, I'm leaning towards malice instead of ignorance.
You are technically correct, the best kind of correct. However! That would be a terrible UX/UI experience. While showing distances on a linear scale is accurate, it fails to capture all the information a person in an interstellar ship may wish to see.
Something like logarithmic distances would better capture information like "Am I about to crash into the star or enter a nice orbit" while still showing the full picture of where you are in relation to where you're going and where you came from.
No idea of that's what happened here, just a thought, I'm not an expert in starship computer interface design.
For something like a transfer between Starships you can resolve a lot of those problems by (very) gently spinning the 2 craft. It won't take much force for the liquids to settle at the bottom of their respective tanks where you would presumably put the intakes.
Assuming you are talking about real physical dice and not an imaginary function that generates perfectly random die rolls.
They are actually pretty poor random number generators. For starters, dice are chaotic, not random, the outcome is based entirely on initial conditions. For humans rolling dice, the space of initial conditions can become surprisingly constrained, especially if the human wants to achieve specific outcomes.
I have 2 servers, Alice and Bob, Bob has a secret, I want Bob to be able to share that secret with Alice. However, I want Alice to be able to prove to Bob that it is actually Alice, that it is running the correct AliceOS, and that AliceOS was loaded on bare metal Alice without nefarious pre-book or virtualization hooks.
A TPM with measured boot (SecureBoot) does exactly this, remote attestation is how Alice proves to Bob that it is in a trusted configuration and wasn't tampered with.
That's the academic viewpoint, but in practice it's used for far more hostile purposes.
(One argues that since you own both of them, you should simply set up the two servers yourself with a key of your own choosing, asymmetric or otherwise, and then restrict physical access to them.)
Alice runs many services and has a rather large attack surface. I don't want Alice to persist those secrets, only to have them briefly at startup (think joining tokens). Bob however has exactly one job, verify that Alice-1 to Alice-N are in a trusted configuration before granting them access to the cluster.
Very recent events in the Linux kernel prove that it isn't safe to assume "0600 root:root" is sufficient to protect secrets from a misbehaving container.
As someone who wanted to improve users security, that’s exactly why I find this thread fanatical opposition to attestation baffling. Nearly everyone uses a device that supports hardware attestation. It’s the best available tool to protect users from malware. We do implement a fallback that lowers security but lets the few users who have devices not able to attest properly to continue, but that really lowers security since we can’t even know if the device cryptography is itself compromised and hence can’t really trust anything it sends. If you have a different solution, do share it! I would love to use something you guys don’t find abhorrent! But until then I don’t really see the reason for all this negativity.
Sadly, the problem isn't the TPM or Remote Attestation. It's Google et al choosing to only talk to devices and software they like without concern for what the user wants or trusts. Compounded by everyone else just going along with it.
A TPM where the device owner can't take ownership of the root key is worse then no TPM at all.
If the price to pay for security is freedom, then let users's devices be insecure. With time, they will learn good security hygiene. And if they don't, maybe they don't deserve it.
reply