thinkmassive

Sounds like a great improvement. I just installed it on my GT, looking forward to trying it out.

If you have more technical details I’m interested to understand how it works. In the distant past I started my career in a power electronics research lab, building motor drive systems among other things, so a deep dive into HapticBuzz would be amazing.

Yes that’s correct, the firmware update is to provide haptic feedback by modulating the motor to cause vibration. It sounds like a great idea, hopefully it works well.

It has a very obvious pushback effect. I haven’t ridden an EUC, but I suspect the difference is you only have part of each foot as leverage to counteract it, so the device can more easily counteract the rider trying to push through it. Turn the rider sideways with each point of contact about a foot out from center, combined with a much smaller tire and lower wattage motor, and it’s easy for the rider to counteract it all the way to the system’s limit.

Then again I’ve seen videos of EUCs doing nearly double the top speed of a Onewheel.

It’s all relative to the rider’s ability and willingness to continue stomping the accelerator as it increases in resistance.

Another good option for new riders is to learn to use a balance board first (like a Vew-Do). At the very least, step on the Onewheel while it’s powered off, slowly raise it to level and hold, then alternate slowly setting down each end and returning to level. If you can do that, you can recover from some situations that would otherwise result in a nosedive.

If the rider is actively balancing then it doesn’t need to immediately nosedive. In reality that’s the usual effect, but keeping a low center of gravity and trying to keep it balanced go a long way toward a smoother slide/roll instead of a faceplant.

You’re riding a Onewheel, you lift your foot completely off the back of the board. How is it physically possible for the Onewheel to continue self balancing in this state?

> there’s no obvious reason the balance-assist system couldn’t be designed to stay on for a while after the motor stops

Amazing, would love to hear how this works!

Yes, if you push through the pushback then you can get it going to the motor’s limit.

What do you think should happen at that edge case? Preferably in a way that adheres to physics…

They can also be extremely fun!

It’s unfortunate that so many people fail to recognize the inherent danger and choose to blame the device instead of their abilities.

Anyone who can’t control their balance on the fulcrum of a kart tire — under their own muscle power — trying to go fast on one of these boards is outright reckless.

I’ll also point out that I’m a FOSS fanatic, and I completely agree that single-wheeled self-balancing boards will gain increased reliability and performance thanks to the VESC community openly sharing their progress.

This is orthogonal to riders accepting they’re participating in a fun but very dangerous board sport.

That’s literally impossible. It can only balance within its operating limits.

The VESC community is extraordinarily impressive.

At the same time, I’m doubtful that software bugs in the proprietary code are related to the vast majority of these failures people describe. The only legitimate issues I’ve seen are caused by sensors (either the foot sensor itself, or improper mounting usually related to grip tape) or water damage.

A Onewheel attempts to self balance. To accelerate, you lean the direction you want to go. As your speed increases, the board starts tilting the nose up to signal it’s reaching its limit. Powering the motor requires energy, and self-balancing requires additional energy beyond that, so a safe amount of headroom needs to be reserved to accommodate for variations in terrain and rider movements.

When the noise starts tilting up, there’s nothing to stop the rider from leaning forward more, which also signals to accelerate. This is called “pushing through pushback” and it’s required to go more than ~16-18 mph.

Imagine the extreme case where you quickly lift your rear foot off the board. Obviously it’s going to stop suddenly, and you’ll fly through the air and smash into the ground. Every nosedive is exactly this scenario, just slightly less extreme.

Once I grasped this simple concept it became obvious that every fall was my own fault. This is why I recommend new riders practice balancing with the board powered off. If you can’t easily do that, you have no business pushing through pushback.

The boards being “fixed” by this recall are getting a new feature that makes the board vibrate at high speeds. This is done by modulating the motor, it requires no new transducer. The only “failure” is of the rider being oblivious to the signal the board is sending.

Source: own a V1, Plus, and GT; ridden thousands of miles on my own and other’s boards; ran a meetup and met a huge variety of rider types; once raced in the GoPro Games; crashed hundreds of times including the obligatory bone-breaking incident resulting in surgery

tl;dr: Future Motion is anti-consumer, haptic feedback is overdue, but there’s nothing inherently wrong with the Onewheel. Every nosedive is ultimately due to rider error.

Not specifically devoted to schematics or drawings, but manuals used to include those types of resources and they’re relatively easy to find:

http://bitsavers.org/

https://archive.org/details/computermanuals

http://www.retroarchive.org/

https://vintageapple.org/

The blockchain is transparent and immutable, but additional layers like the Lightning Network can provide a range of additional privacy.

As others have mentioned, swapping between chains is also an option.

Best attempt at an explanation of how it works that I’ve seen so far:

> My understanding is it's CONNECT-IP / MASQUE where the encrypted & HTTP encapsulated IP request is sent to Obscura and the details of the request are forwarded to what they're calling a "Blind Relay" which only knows Obsucra's IP. 2-hop onion routing with pre-defined routes. No Tor consensus. Very simple. https://datatracker.ietf.org/doc/draft-ietf-masque-connect-i...

- bitgould from https://stacker.news/items/268728/r/031ef7d322

Impossible to say without seeing the source code though.

I’m not seeing the relevance. If you’re going to move the goalposts, you could at least explain why.

I suppose where I was going with all that is: hopefully, as people are exposed to superior solutions within a smaller context, they might be open to considering similar alternatives for other purposes.

This is spot on. My brief exposure to Jsonnet made me realize how superior it can be, especially for k8s manifests. Unfortunately the learning curve is steep, to the point that I've held off on attempting to introduce it anywhere new.

Recently I discovered kpt (https://kpt.dev/), which attempts to improve the k8s manifest situation and seems to have a lot of good ideas. Considering how long it's been under development though, it may also never catch on among mainstream k8s users.

Grafana recently switched their dashboard DSL to one based on Cue. I haven't yet dug into learning it, but it seems potentially even more powerful than Jsonnet. They also have the advantages of a much smaller audience (relative to k8s manifests) and of putting in the work up front to define the new language and a sample implementation (useful out of the box), not to mention making it a requirement going forward.

From today, or from when they first joined?

Also consider that a project needs to not only have existed, but to already have an established track record of being vendor-neutral before it can join.

Kubernetes joined CNCF on March 10, 2016. Prometheus joined May 9, 2016.

In 2017, these 10 projects joined:

    - Linkerd
    - gRPC
    - CoreDNS
    - Containerd
    - rkt
    - CNI
    - Envoy
    - Jaeger
    - Notary
    - TUF

Of those 12, only one (rkt) has been archived. Do you honestly believe the majority of these will be unsupported 10 years from now, let alone 10 years from when they were added (or started in the first place)?

One of the main reasons to donate a project to a foundation, such as the Cloud Native Computing Foundation (CNCF), is to protect the community against this type of rugpull. A requirement for them to even consider adopting a project is that it isn’t under majority control of one single commercial entity.

Do people honestly believe none of these projects compete with commercial solutions, or are they mostly oblivious these exist at all?

https://www.cncf.io/projects/

If you need a Zookeeper drop-in replacement then I suppose there’s limited options, but many of the same needs could be met by etcd.

My apologies, I didn’t realize those were links.

Hopefully anyone interested for more than academic reasons does their research on the range of solutions more widely available.

Congrats, you just defeated the attack by manually downloading the script before running it!

What tools are you seeing offered for download there?

Yeah it’d be better to use https since it lists some checksums, but it was last updated in 2018, and Debian packages are verified anyway.

The autoplay is extra annoying when listening to an older episode too. When you go to the full list it automatically jumps to the one last played. Scrolling long lists in Spotify is very buggy.

The only way to fix it is mark the newly-started episode as played, then mark as unplayed. So many extra steps that shouldn’t even be necessary in the first place.

Signing keys can be derived from a root key that allows for rotation and revocation. Multiple keys can sign the same content.

Also important to add: using prometheus as the tsdb is good for short term use (on the order of days to months). For longer retention you could offload it elsewhere, like another Prometheus-based backend or something else SQL-based, etc

The most basic setup, and the one typically used until you need something more advanced, is using Prometheus for scraping and as the TSDB backend. If you ever decide to revisit prometheus, you’ll likely have better luck starting with this approach, rather than implementing your own scraping or involving TimescaleDB at all (at least until you have a working monitoring stack).

There used to be a connector called Promscale that was for sending metrics data from Prometheus to Timescale (using Prometheus’ remote_write) but it was deprecated earlier this year.

Interesting, apparently it used to mean either, without prescribing a timeframe:

https://en.wikipedia.org/wiki/Layoff

I think the meaning has fully shifted to imply permanence, for at least a couple decades now. The word that comes to mind for a temporary situation is furlough, although I’ve mainly heard that used in a government context.

Maybe the difference is that most people now change jobs often enough, that the government is the only entity that would promise to re-employ those they temporarily couldn’t pay.

Prometheus has become ubiquitous for a reason. Exporting metrics on a basic http endpoint for scraping is as simple as you can get.

Service discovery adds some complexity, but if you’re operating with any amount of scale that involves dynamically scaling machines then it’s also the simplest model available so far.

What about it doesn’t work for you?

Edit: I didn’t touch on logging because the post is about metrics. Personally I’ve enjoyed using Loki better than ELK/EFK, but it does have tradeoffs. I’d still be interested to hear why it doesn’t work, so I can keep that in mind when recommending solutions in the future.