In the past, I've used things with load-dependent (instead of temperature-dependent) fan speeds.
It can seem like it is a simpler method of control (why measure temperature if we don't have to?). But they were really very annoying to be around. It wasn't so bad with constant loads, but bursty dynamic loads created an audible cacophony that was very distracting.
Such a system also doesn't necessarily take into consideration other things that affect cooling performance, like ambient temperature and dust.
At least one of the problems (the annoying sounds) can theoretically be worked around by slowing down the rate at which a fan ramps up and down. But by the time that is done, fan speed is back to lagging again -- we're heading back to where we were before.
And then we still have variables like ambient temperature, dust, degraded thermal interfaces, and others to contend with.
So, the simpler method seems to be what we broadly already do today: We change fan speeds based on the temperature of the thing being cooled.
This temperature already has everything we need integrated to begin with: It includes thermal output, ambient temp, dust, old thermal goop, and everything else.
If thing is cool (for whatever reasons it is cool -- maybe it's idling in a shed in January in Minnesota), then: Fan can go slow or even turn off.
If thing is hot (for whatever reasons it is hot -- maybe it's doing real work in a shed in August in Minnesota and full of cat hair), then: Fan can go faster.
That seems to be a rather simplified view, as if stemming from the world of frictionless pulleys and rope that does not stretch.
These are self-propelled electric vehicles that have regenerative braking. Regen is miles ahead of just dumping momentum as heat [as conventional brakes must] but it can never be 100% efficient -- and it may not even be able to begin to try to capture 100% of that momentum in the first place, depending on the particular braking circumstance.
These characteristics weigh heavily on how such vehicles perform in the real world, especially when the terrain is not flat. (And in this test, the terrain was not flat.)
I wrote an electric vehicle power / efficiency / range estimation program back in college when I was very into building electric bikes. (More advanced version of the ebikes.ca calculator for an example). There were a whole lot of parameters that went into actually estimating the performance, but the general rule of thumb was rolling resistance is pretty much worth ignoring (for efficiency) until you have spent time optimizing aero and drivetrain losses.
It was pretty damn close to real world measurements.
I'm going to use rules of thumb rather than exactly calculating things for a colloquial conversation online.
I've had bikes stolen a few times -- in the midwestern US, and mostly as a kid where my bike was not generally stored very securely.
Usually, they're just...gone.
The police around here do collect bikes that they find dumped in places where they don't belong -- in parks or when reported in random folks' yards or wherever. These get auctioned off if not claimed first.
But I did get my bikes back a few times.
Most memorably, I was doing some random technical work at the local PD and was heading out to have a smoke, and I saw a bike that looked just like mine just standing there on the back dock. Same purple Caloi aluminum frame, same additions (like the 90s-style Control Stix bar ends), same everything, except it had an inventory tag on it.
Which very seemed strange to me, since I knew very well that my bike was safe at home. Or did I know that? Maybe my bike wasn't safe at home. Or maybe someone else had the same mods on their own bike, which wasn't particularly unlikely since I bought all of it from a singular bike shop in town?
So I asked about it. And they're like "Well, if that's your bike, then maybe you can tell us something about it that is identifiable. Something unique that you couldn't see in the five minutes you've been standing there staring at it."
I couldn't think of anything. But that ultimately didn't matter -- they were fucking with me for the lulz.
"Maybe you don't remember doing this," they continued, "but it's got your name, address, and phone number engraved on the bottom of it."
Fuck! I did put that on there over a decade prior, and I completely forgot. That certainly was convenient for future-me.
Anyhow, it took a couple of days for them to finish their bureaucratic paperwork dance, and then I had my bike (that I didn't even know I was missing) back. Thanks, in large part, to having some identifying features.
That's fun and a good outcome. I had registered mine in the local system, run by the police department. The first time I saw it after it was stolen it was just locked on the street so I could check the frame number. I called the police and they said there was no evidence, they weren't going to come check it, and that if I cut it loose and took it that would be a felony. I saw it a couple years being ridden in traffic but didn't bother to do anything.
On my main-driver desktop box that I hamfistedly switched over to Void Linux (on a ZFS root, even) a couple of months ago:
The output of df -h looks pretty sane and understandable.
I see some entries for /dev and /run and /, some stuff for EFI, a bunch of mounted ZFS datasets, and it's all very readable with no line noise in any column.
---
Now, that said: I have some docker containers. My own previous goto command of mount reports a complete clusterfuck, and all of the clusterfucked lines are due to docker doing docker stuff.
I don't know how things like 4UYSHHPFBZQNFZ9Z698JDLUZWJ, LK33RZTN5ZNFGPJNDUHM0HTSD1, 2G0A4YYUVCMP9HZSM5UXOJW0BX, ZH29C5YNZHJ22QMY63EWV5RF3P, and 32XOCXBUY41QQJTPPA8HE6EVZ6 add any coherency or clarity[1], but I assume that since the computer quite easily knows what this shit means then it needn't be bothered with dumbing it down so that a human can parse it in any sort of memorable or repeatable or communicable fashion.
(Which is, of course, bad behavior on the part of the computer. A UUID is also awful, but at least it has some punctuation so that it can have some cadence if it must be dealt with as-is.
It's like we learned nothing from DNS[2], or as if translation layers can't exist even within a filesystem[3].)
> Can we talk for a moment about the beef supply? Bird flu has now been found in both meat and dairy. The only guidance given so far by CDC is to cook meat to 160 deg. Well done. Let's put aside for a moment what that means about rare steaks...
We can start by talking about the fact that there seems to be no specific guidance from the CDC or USDA that suggests cooking steaks to 160F is necessary to kill bird flu, or that generally suggests this practice of cooking steaks to well-done.
In fact, a report on a very recent USDA FSIS study states the following about some intentionally-inoculated ground beef patties: "There was no virus present in the burgers cooked to 145 (medium) or 160 (well done) degrees, which is FSIS’ recommended cooking temperature. Even cooking burgers to 120 (rare) degrees, which is well below the recommended temperature, substantially inactivated the virus."
> What about the millions of workers who cook burgers and handle large amounts of raw meat on a daily basis, then rub their eyes or noses? These are probably thousands of daily opportunities for the virus to jump species and attack human lung cells.
Eh, here's the not-so-nice way of saying the same thing:
>> When the virus-laden beef patties were cooked to 120°F degrees (rare), however, the tests found evidence of the virus, but at much reduced levels [0]
Sorry, to your point about handling... if this is prevalent in fat and muscle tissue of otherwise healthy cattle then it is totally unlike pathogens introduced during slaughter, packing, grinding or food prep handling. Do you understand what I mean? Prior to this, other than prion diseases, pathogens inside muscle tissue basically did not exist in the modern beef meat supply. The only pathogens were introduced onto the outer surface during slaughter or handling. Cut away the outside and don't put it through a grinder and you can eat any piece of beef from a US supermarket raw. Up until now. Now we're talking about the interior volume of everything being loaded with a live virus.
That drastically increases risk in handling and consumption.
None of those words support the initial claim that the CDC has issued guidance to cook steaks to 160F, which is a claim that at this point I can only believe to be a fabrication that was made in bad faith.
I do not wish to spend any time at all determining which of your other claims may also be fabricated.
> None of those words support the initial claim that the CDC has issued guidance to cook steaks to 160F, which is a claim that at this point I can only believe to be a fabrication that was made in bad faith.
it was not the CDC but the USDA [0]:
> Bird flu virus particles were found in beef tissue taken from one dairy cow sent to be slaughtered for meat, and meat from the animal did not enter the food supply, USDA said last month.
> The agency has reported that no viral particles were found in samples of ground beef collected at retail stores, and that no bird flu virus was found after cooking ground beef to medium to well done, after it was injected with a virus surrogate as part of an experiment.
day by day, imo, this virus is inching closer to humans. recently house mice were found to be infected [1]. it's becoming a bit reminiscent of late 2019.
With AliExpress, my orders never feel like a negotiation. I put stuff in the cart, eventually push the "buy this stuff" button, give them money, and stuff eventually shows up -- just as with other e-commerce sites for decades.
Sometimes it's slower (months), and sometimes it's stupid-fast (a few days), but outside of things like Chinese New Year the sellers generally seem to be very prompt at handling the orders and getting things into the delivery stream.
I've come to expect most things to show up in a couple of weeks (at least here in the States).
I'm not doing anything particularly weird, I don't think. My order history consists of almost entirely of small electronics (sometimes components, sometimes populated PCBs) and 3D printer parts, from dozens of different sellers.
While it is certainly true that shipping from the US to China is expensive, it is my understanding that returns for many kinds of items are free these days, using a shipping label generated by AliExpress.
(How they handle that on their end is really not something that I think I need to worry about.)
If the answer to excessive in-rush current (due to capacitance) is to add series inductance, then: Isn't the more-efficient answer simply less capacitance?
I think the correct answer really depends upon what you are trying to do. Sometimes where board space and cost are not an issue people use a combination of larger and smaller bypass caps to reduce switching noise. I don't think there is a one size fits all solution because people power many different types of things from USB. It's more just a caution about USB power in general. Most people know the 500mA current limit, but in-rush compliance is something you don't really see in functional testing because typically you can get away with a violation and the board will still work.
Cars can be expensive, yeah. I live in a very car-centric area (zero public transportation, with many things too far away for realistically walking there).
To throw some numbers out: A "cheap" used car ($5k), financed over 3 years at 8% is $156.68 per month. At my middle age, decent full coverage insurance is around $100 per month (it would cost a lot more if I were still younger). We're at $256.68 monthly just to have a car that we may elect to drive.
But that doesn't include parking for the car (a place to live with good parking tends to cost more than a place with awful parking). It also doesn't include the costs of actually driving the car, like regular maintenance, stuff that inevitably breaks or wears out, fuel, washing the car, and so on. Let's just make up a number and say that these things average ~$150 per month, for a total of ~$406.68 per month to drive a car.
Now, suppose that a commute is 20 minutes each way using that car, or 1 hour if riding the bus. And that a bus pass costs $62 per month.
And let's say that a person "brings home" $25 per hour worked, and that they work 40 hours in a regular week (173.93 hours in a regular month), and that the commute time counts as unpaid work.
The car commute adds 14.49 hours per month, for 188.42 hours total time in work+commute at a cost of $406.68.
The bus commute adds 43.48 hours per month, for 217.41 hours total time in work+commute at a cost of $62.
The bus seems cheaper and slower at this point, which we all probably implicitly knew to be true.
--
But if my math is right: By the time transportation is paid for, the person commuting by car has an effective hourly wage of $20.92 for their time+commute. And the person riding the bus has an effective hourly wage of $19.73/hour for their time+commute.
So owning and driving the car may be a better option than taking the bus, depending on a person's specific situation and proclivities. And of course, it's more nuanced than that in ways that are harder to math out.
With a car, commute time is just lost time. A person driving a car must drive that car the entire time; they don't get to read a book or hang out on HN or whatever, but they're only doing that for 40 minutes a day.
With a bus pass, commute time might be productive time. A person riding a bus might decide to read a book or hang out on HN or whatever. So if a person chooses to do so, they can use some of that 43.48 hours riding back and forth to work doing something that has meaning to them.
On the other hand: Owning a cheap(ish) car means being able to travel to places where a bus doesn't go, and do so on a whim, and (optionally) take a mountain of stuff along with them if that is useful for whatever reason.
So yeah, cars are expensive. But buses are also expensive. (Life is expensive.)
It can seem like it is a simpler method of control (why measure temperature if we don't have to?). But they were really very annoying to be around. It wasn't so bad with constant loads, but bursty dynamic loads created an audible cacophony that was very distracting.
Such a system also doesn't necessarily take into consideration other things that affect cooling performance, like ambient temperature and dust.
At least one of the problems (the annoying sounds) can theoretically be worked around by slowing down the rate at which a fan ramps up and down. But by the time that is done, fan speed is back to lagging again -- we're heading back to where we were before.
And then we still have variables like ambient temperature, dust, degraded thermal interfaces, and others to contend with.
So, the simpler method seems to be what we broadly already do today: We change fan speeds based on the temperature of the thing being cooled.
This temperature already has everything we need integrated to begin with: It includes thermal output, ambient temp, dust, old thermal goop, and everything else.
If thing is cool (for whatever reasons it is cool -- maybe it's idling in a shed in January in Minnesota), then: Fan can go slow or even turn off.
If thing is hot (for whatever reasons it is hot -- maybe it's doing real work in a shed in August in Minnesota and full of cat hair), then: Fan can go faster.
reply