I switched to a large company from a series of startups (including my own), it is definitely a big change, and "efficiency" is not the thing anymore.
Now I can spend days fighting with some gnarly IT security problem to load an internal Python package cross-org with a Managed Identity token issued to Build Pipeline that is scoped to a Service Principal with a wrong checkbox, or something equally cryptic and useless. Nothing of it would be even remotely possible in a startup. Is it "performative"?.. I think not. Is it efficient or necessary? Probably not, but who knows. Chesterton's Fence and all that.
Surprised nobody mentioned Intel vPro AMT so far. It is basically an always-on KVM that's part of CPU firmware, powered by an always-on 5V PSU rail. There is a scary amount of options, including unattended periodic (or alarm based) phone home, user acceptance or full user override, boot media spoofing, Serial over WiFi... All built-in into consumer(-ish) CPUs.
I'm not surprised that nobody noticed it at all. That's because it's not a KVM that you can purchase and test, the subject to the article.
Instead, you're just talking about IMPIjr. These specific features are not in consumer grade CPUs, but in CPUs marked for workstations. Ain't no consumer buying fuckin vPro machines. These are enterprise IT management features, not user features. They're also subject to frequent insane rants by people obsessed with them as possible privacy issues.
Man, I wish that tool was available fifteen years ago. All of our machines in our half-Linux half-Windows manufacturing operation were Q chips with vPro motherboards, that we (I) chose on purpose, but we didn't have the IT bandwidth to ever sit down and learn how to use them properly.
Dude, I wish. I run a large homelab filled with consumer and small business grade intel hardware, and would love to have vpro on all my mid-high end consumer intel platforms. I have the experience and network environment to lock it all down securely, and it's very reliable high performance low level access from before boot.
It's true that some number of relatively expensive consumer-grade CPUs support vPro, but the catch is it also requires the motherboard's chipset to support it, and it has to be both implemented and enabled in the BIOS.
You rarely if ever see consumer hardware with a chipset that supports it. On all the systems I have that fully support vpro from soup to nuts, you have to intentionally turn it on because it's quite dangerous in the wrong circumstances.
It's fine. People will always find something to be publicly unhappy about.
Example 1. Someone reached out to me on LinkedIn "from HN", when I replied to their initial message they just said "You look like an AI trawler" and disconnected.
Example 2. I read a popular non-English tech blog aggregator which also encourages comments and discussion. Since ~1.5 years ago every other comment is "thank you author, but if I wanted to read AI I would as AI" or some variation thereof.
Being a weightlifter for 20+ years now, I'm working on a barbell speed and path tracking sensor based on newer IMU hardware technologies, which makes it both more precise and cheaper than camera- or actuator-based systems. Ultimately it helps you lift and train safer and better.
It's an intersection of industrial design, hardware, firmware, and software (and some sport science, of course). This intersection is not yet dominated by LLMs so it's a breath of fresh air.
In an early prototype stage as in "strap a Raspberry Pi to a bar", but it looks promising and I'm happy to move forward, also using connections from my previous 12+ years in China.
Wannabe powerlifter here of about 20 years as well. This sounds like an awesome project! Is bar-path the main metric for safety and "better" lifting? A project I had in mind, once upon a time, was an automatic "Form Check Friday" for myself using a Pi + Webcam.
As someone who has been very deep down this rabbit hole and hacked together multiple path and velocity trackers over the years (specifically for olympic weightlifting), there is no extra information that tracking bar path will give you that simply looking at the video won't, and often just adds more clutter. You don't need to graph bar path to see that the bar is looping too far forward after hip contact in the snatch.
Velocity on the other hand is a great metric to track and is used as a proxy for RPE. Mike Tuchscherer was the first one to systematize it for powerlifting a while back, if you've been lifting for 20 years you're probably aware of the name.
Thanks! I think for "canonical" lifts (squat, deadlift, row, to some extent military press) the vertical bar path is mathematically optimal, and for all kinds of lateral or sagittal movements you do more work with weak stabilizing muscles and load joints laterally too. Is it productive work that strengthens your core? Possibly, but it's hard to quantify. It it something that can lead to injury? Absolutely yes.
For more complicated lifts like bench press (J-shaped) or snatch (S-shaped), for example, I would rather set a "golden sample" path with a coach and compare to that.
It's unlikely to be the sole metric, especially given the inverse kinematics of different body types (long/short femur, etc), but together with bar speed, over time, it can provide a lot of good feedback.
It is not "absolutely" something that can lead to injury. Injury itself is difficult to define, and often the reason one experiences pain sensation is multifactorial. Within lifting contexts, generally the factor which has the strongest evidence for injury prediction is how sharply an athlete increases intensity compared to what they have previously adapted to.
No offense, but this post does come across as you only having a surface level understanding of the field. Especially surrounding injury/pain perception, I would be more careful of what you assume is true, there's far more nuance.
Side note: My LG Watch Sport smartwatch was able to determine what weight training workout I was performing and somehow figured the weight with astonishing accuracy.
Phone accelerometers don't have enough range and sampling frequency to even begin with. Raw, on some rare phones you can sample 800 Hz (enough-ish), but on most 100 Hz max, Web API is capped at 60 Hz, this is all way too low for any quaternion math. They also have much higher noise density which is the silent killer of all kinds of IMU navigation.
I've had the same idea for year. When google released their Fitbit Air few days ago I the first thing I tought was - can it be used as a sensor for weightlifitng and do they have API for that.
i'm curious about how effective path tracking can be in comparison with computer vision based inverse kinematics of the body itself. do all forms of bad form have detectable imu signatures?
i wonder if it would make sense to consider it as a data problem, capture a bunch of high fidelity inverse kinematics data for various forms of bad form/dangerous lifting along with the imu data and then work from there. there could be some interesting and unexpected features that are easier to detect than straying from straight line paths with some tolerance.
Hashing microservice deployment was blocked by random generator microservice stuck in Pending because it needed an UUID from UUID microservice which was blocked by hashing.
Sehr gut! I need to show it to my colleagues. Unfortunately half of them are on vacation currently and another half on sick leave. We decided to make a Teams call in August to discuss how to proceed with this.
I switched to a large company from a series of startups (including my own), it is definitely a big change, and "efficiency" is not the thing anymore.
Now I can spend days fighting with some gnarly IT security problem to load an internal Python package cross-org with a Managed Identity token issued to Build Pipeline that is scoped to a Service Principal with a wrong checkbox, or something equally cryptic and useless. Nothing of it would be even remotely possible in a startup. Is it "performative"?.. I think not. Is it efficient or necessary? Probably not, but who knows. Chesterton's Fence and all that.
reply