milesvp
And it gets worse, since equipment gets chained. If you add more than a few ms to the wet channel, it accumulates and can be very problematic if you ever feed the wet back into the dry signal.
Source: have shipped multiple digital pedals
Um… work is not important. Value is important. Your employer is employing you because they expect your value to be higher than your cost. Moreover, if you are busy, your marginal value is likely declining. You are not taking the time to think about things that will actually have high impact. This to me is the biggest problem I see with AI assisted work, it makes it very easy to feel productive, when in reality you only worked on the easy low value things.
What’s more, is I have a very distinct experience working on a team years ago that decided to do less work. The team actively started turning down tickets and commiting to fewer tasks each week. And the counter intuitive thing, was that not only did that force only the higher value tickets get closed, we actually ended up closing more tickets. Was really wild to watch and experience.
I was actually thrilled with my cola that year along with the required vacation time.
Honestly it was a very weird time. Less than a year prior I had worked in a real estate office, and there was a lot of scary stuff already starting to happen.
This is not wrong at the pop sci level of the video.
Your phone undoubtedly has a gyroscope, accelerometer, and magnetometer all in a single IMU IC. Data from this IMU can be used to create a position cloud.
Add in some other sensor data to help collapse the position cloud, and your phone absolutely knows its position in space. Incidentally part of why IMU have magnetometers is that it’s basically one more sensor data to help collapse position clouds from just the orientation and acceleration data.
I think the only leap is how precise your phone would be with only gyroscopes generating orientation and acceleration data. But the video sort of hints at this when talking about the first rocket design using this data.
Technological advancements in an owner controlled factory leads to fewer employees. The same advancement in a coop leads to more leisure.
I know it’s super simplistic, and ignores pluses and minuses on both sides, but it really seems to sum up a fundamental problem with increasing efficiencies in society, and I can’t help but wonder if we are failing to capture the leisure that society has made possible.
20 goto 10
I would love to see someone at the level of technology connections do a breakdown of the physics here, and where the likely crossover point point is for different kinds of fridges. My current (probably illformed) belief from the suction and imagined resulting air exchange of all the fridges I’ve lived with is that leaving the fridge open on the order of seconds is better than opening-closing-opening-closing in terms of cold loss.
Yeah, for me in these situations it’s often about messaging to stakeholders, and so management in general feels like the problem has been addressed. I do think there’s one important thing missing from the final statement of the post, that he sort of covered briefly when talking about too much process, and that is what is the tradeoff/cost of implementing the change we’re making. Engineering is fundamentally about tradeoffs, and any significant proposed change requires some tradeoff and all too often I see management not asking about this explicitly. I’ve had enough once in a blue moon errors have retros, where the team decided it made no sense to make changes, and others, where the cost was high enough it was worth increasing workflow headaches. I think these tradeoffs being explicit are important at the director and above level, since there are potential real impacts to the team, and that is the level to deal with morale or headcount pressures due to changes to processes.
That said, it never occurred to me to just cut up my book, so I could continue to read it comfortably. I think I might have chosen to do so though, since I find the tactile nature of reading a physical book to be more memorable than digital. Where the words sit on the page, and the act of turning the page, the smell, all does something to my neurons. For my junk novels, I don't really care, but for the authors I cherish, the closer to the printed word I can get the better the experience I have, and the more memorable the writing in general.
Also, the cost of screening ad responses is near zero compared to 30 years ago.
So we have economics that encourages ghost job listings. Personally I’d like to see big taxes on job postings scaling for company size, maybe duration too. Would solve this particular problem.
Today, I’d ask about more ways to push the responsibility away from the firmware to stop catastrophic failures. If the debugger pauses the CPU you can’t use the CPU to regulate things. I’ve worked on things where the failure mode can be explosive and it makes dev really harrowing if you can’t rely on hardware interlocks.
Ha! just looked up the video, seems it’s another practical engineering video I was thinking of
Fun fact. Lack of parking is not a legitimate reason to attempt to drive past this region. I was once flagged crossing into canada on a day they were interviewing a lot of travelers. I spotted parking in what looked to me like an overflow lot on the other side of a fence, and when I slowly drove that direction sirens blasted and guns were drawn. Nothing gives you clarity like a gun pointed at you.
This is generally true. What I find fascinating is the application of information that is not present in the data but that can be confirmed by the data. I’m thinking specifically of deblurring algorithms people use to recover text. If you can guess what font is being used in a screengrab with, say, someone’s bank account blurred out, you can take the i formation contained in the downloaded font and try combinations until you match the blur algorithm that may also be information not contained in the image.
What’s also crazy, is that even if all you do is black out the text, kerning alone can still be used to guess the correct text with some degree of accuracy. I worked on redaction software at one point, and these were very much the types of things we thought about when dealing with text.
There was a good keynote on the topic 5 years ago By Timothy Roscoe
https://www.usenix.org/conference/osdi21/presentation/fri-ke...
https://www.youtube.com/watch?v=0z5ixJIqbGY&t=267s
He's an odd guy who likes to investigate some really dodgy stuff. And I suspect many here on HN would appreciate him.
That led to 7-OH showing up in my feed at some point. In a nutshell, it's the strongest of the active compounds in the kratom plant, that binds to opioid receptors. 7-OH is the marketing name for the alkaloid 7-hydroxymitragynine that is being refined from kratom. It's not clear to me if it's simply extracted, or as some quick research suggests, it might also be a chemical alteration of the more commonly occurring compound in kratom mitragynine.
Anyway, this stuff looks super habit forming, and, of course, the refined version is that much more addictive.
I know it’s stupid, but I’m genuinely curious now.
There is one truth I have come to know, said by someone far wiser tha me: A queue is either empty or full. Which is to say a queue can either handle all the data coming in, or it can’t. When it can’t it will fill to capacity. This is a probabilistic thing, and you can only decide how many nines to plan for. And it’s worse than it looks at first, because queuing theory is very non intuitive with non linearities that make it very hard to reason about wothout having your nose rubbed in it.
So that means, that yes, you can keep doubling the size of your queue. And no, you can’t ever make it big enough to deal with a poisson distribution. And while you’re at it you will likely need to add workers. And you’re still back to capacity planning and deciding how much money to throw at the problem.
What you may be getting at, and what the article sort of failed at, is that queues are still super valuable for smoothing small spikes, or even large predictable ones. But a queue alone, without backpressure, or overflow will likely cause systems to fall over. Sometimes in ways that are hard to recover from, especially if you have some kind of microservices inspired architecture, where one thing going offline causes another queue elsewhere to fill. Or worse, bringing a failed service back online stresses another system causing it to fall offline. (not meant to be a dig on microservices by the way)