Yeah, I have a script that toggles my Dell XPS between full charge and 80%, as I’m usually on mains and only need full charge occasionally.

A kind of ‘super’ print screen, in fact.

They’re also rapidly making their way and taking a long time.

How were they able to reduce sinusoidal depleneration though?

That mb appears to have 8 channel audio on the backplane (7.1) and maybe another stereo header for the front panel headphones? That would make 10 channels in total which fits…

Interesting. Is the orange line on the board separating the audio section from the rest?

You’re probably right—I searched for ‘20 mosfets in parallel’ or something like that and it came up near the top. But I didn’t read the whole thing.

I guess there’s got to be some reason for using so many though?

My gut feeling is they didn’t put 20 there in case you scraped one off. But likely the others will have enough leeway to cover for it. If the power rail gets stressed enough, it might well fail sooner than it would have.

From the TI briefing note:

Paralleling power metal-oxide semiconductor field-effect transistors (MOSFETs) is a common wayto reduce conduction losses and spread power dissipation over multiple devices to limit the maximum junction temperature.

It would also provide redundancy in case of a failure—if you had only one, and it failed (or was scraped off by an over-enthusiastic GPU installation), you would probably not be going to space today.

The back of my envelope says that if a 50Wh laptop battery gave you 5 hours of run time, an average of 10W, then reducing that to 7W whilst keeping everything else the same would give you just over 7 hours. But it likely wont be quite that much in practice because all the components are constantly changing their power requirements and my envelope has a corner torn off at that point.

Be careful—he may understand as a German.

Hope this email finds you in a well.

This one still seems to be there… See this example where many times a small drag activates the controls.

Sometimes the drag moves the image, sometimes it doesn’t (not sure if the screen recorder can capture taps / drags?).

Would it be too much to simply disable the controls overlay when zoomed in? Just thinking that might be easier than wrangling the gestures.

Edit: forgot to say that disabling might also solve the issue of accidental single tap before zooming, which currently leaves the controls visible and no simple way to get rid of them without zooming out again.

Maybe it should try standing incredibly still?

Thank you for all of that—I’ve tried very hard, but can’t get it to misbehave at all now :) Which means the only thing be got left is the layout between feed and post, which honestly isn’t a huge deal but might be good to have an option like for link previews to keep the order consistent—see this:

Vs:

But even now, the media experience is so much smoother and more enjoyable.

Wait, so it’s ok for you to avoid having to pay for art, but not companies?

Better?

How are you averaging the humans? Or are you averaging testicles?

To build if you’re doing this a lot and can’t use a brand lens with known correction data in darktable, set up graph paper and phone camera on a tripod to keep everything consistent, then photograph the empty paper. Create a transform in gimp to make the paper completely flat / square, and then just reapply that transform for every object you need to capture.

On the video side, pause on dismiss is working perfectly, but I did see 2 other problems (great!). One is the zoom on rotate issue—I still see that on first rotation, although it doesn’t get ‘worse’. It ends up showing by about half the media.

But in testing that I noticed that scrubbing the paused video in either full screen or feed view does not appear to affect the playback position where unpaused again—it restarts from where it previously was, not the new position.

Again let me know if recordings would help illustrate.