You can actually count to 12 on your fingers using one hand. Use the thumb as a pointer, then for each of your other fingers you have three joints. So 3*4=12.
It's hard to actually count using more than 4 bits/hand though. The quickest methods that require the least dexterity are those that count the knuckles (which are actually used in some counting traditions, unlike binary finger-counting).
> There were many older models of BMW that had an electric water pump. If that sounds silly, well, it is. And it failed frequently and was again, very difficult to replace.
On the face of it, it's not actually a bad idea. The electric pump can run at an optimal speed regardless of engine rpm. This means the pump can be downsized, because otherwise if it's driven directly from the engine it'd have to be sized for the worst case scenario of low rpm and high load.
Same reason why many vehicles nowadays have electric radiator fans rather than driven directly from the crankshaft like in the "good ol' days". (Of course with transverse mounted engines a crankshaft driven fan doesn't really work either, so that's another big reason to go for an electric fan.)
Now, of course this concept can be badly implemented, just like any other part of the design.
As much as I'm gung-ho about the world electrifying transport, I agree with you here. Those Porsche SUV's just look awful, whatever the drivetrain. If I'm gonna splurge on a Porsche, I'll want the real thing. And if I don't want a 911, well there are a lot of other brands making more sensible vehicles.
(Of course, if a lot of other people share my extremist views, that's pretty bad for Porsche the company. They likely can't survive just producing 911's. Oh well, I'm not here for corporate charity anyway.)
Unfortunately children playing in the yard have ample time to get behind the car between you checking it, entering the car, starting it, and reversing.
Yes, in principle one could take whatever other measures necessary to prevent such accidents. In reality, backup cameras save lives. Just like seatbelts, anti-lock brakes, crash safety standards, and other safety features that "Real Manly Drivers" protested against back in the day.
> And if you take into account how China has treated its own people, it’s not much better or worse than the United States. Maybe worst, actually, since Americans do have a legal right to protest.
In "The Great Leap Forward" they killed tens of millions of their own. Granted, that was a long time ago, but while the current leaders may be wiser little suggests they aren't as ruthless.
In the US the average car is 12 years old. I don't know Norway, but I expect similar. Which is to say I don't expect this to have made any difference in the number of gas stations yet. Gas station owners are watching numbers, but and are likely to open less in the future (not zero, some new development/locations will be important, but some locations that previously would have got one will not longer be worth the investment. Or maybe they put in the station without gas pumps - people still need those snacks (again I don't know the market in Norway, in the US that is how it would be).
Gas stations are also trying to figure out how charging fits in. While people are expected to charge at home, there will still me some demand for on the road charging. This is a place that hasn't worked out yet (I personally expect people will go for a nicer meal and sit down for an hour charge - but this might be my bias)
Quick AI search suggests average car age in Norway to be 11.1-11.3 years, so indeed quite similar.
As for what would happen with gas station when EV's dominate, what already seems to be in progress here (not due to EV's, but other factors in the market) is that the "traditional" gas station serving stale coffee, snacks, and windshield wiper fluid are on the way out, replaced by either unmanned cold stations with just the pumps, or then by major roads large full-featured mini shopping malls with groceries, half-decent restaurant (sometimes several), and other shops. I think in a future EV world the cold stations would disappear but the higher end service centers would do fine.
They seem quite intent on inching their border closer to the Philippines mainland by building military bases on some shoals that belong to the Philippines.
> no manual fence support; a bad but common way of distributing workloads is e.g. to compile a test on one machine (on an NFS mount), and then use SLURM or SGE to run the test on other machines. You use NFS to let the other machines access the data... and this works... except that you either have to disable write caches or have horrible hacks to make the output of the first machine visible to the others. What you really want is a manual fence: "make all changes to this directory visible on the server"
In general, file systems make for poor IPC implementations. But if you need to do it with NFS, the key is to understand the close-to-open consistency model NFS uses, see section 10.3.1 in https://www.rfc-editor.org/rfc/rfc7530#section-10.3 . Of course, you'll also want some mechanism for the writer to notify the reader that it's finished, be it with file locks, or some other entirely different protocol to send signals over the network.
> In general, file systems make for poor IPC implementations.
I agree but also they do have advantages such as simplicity, not needing to explicitly declare which files are needed, lazy data transfer, etc.
> you'll also want some mechanism for the writer to notify the reader that it's finished, be it with file locks, or some other entirely different protocol to send signals over the network.
The writer is always finished before the reader starts in these scenarios. The issue is reads on one machine aren't guaranteed to be ordered after writes on a different machine due to write caching.
It's exactly the same problem as trying to do multithreaded code. Thread A writes a value, thread B reads it. But even if they happen sequentially in real time thread B can still read an old value unless you have an explicit fence.
> The writer is always finished before the reader starts in these scenarios. The issue is reads on one machine aren't guaranteed to be ordered after writes on a different machine due to write caching.
In such a case it should be sufficient to rely on NFS close-to-open consistency as explained in the RFC I linked to in the previous message. Closing a file forces a flush of any dirty data to the server, and opening a file forces a revalidation of any cached content.
If that doesn't work, your NFS is broken. ;-)
And if you need 'proper' cache coherency, something like Lustre is an option.
It wasn't my job so I didn't look into this fully, but the main issue we had was clients claiming that files didn't exist when they did. I just reread the NFS man page and I guess this is the issue:
> To detect when directory entries have been added or removed on the server, the Linux NFS client watches a directory's mtime. If the client detects a change in a directory's mtime, the client drops all cached LOOKUP results for that directory. Since the directory's mtime is a cached attribute, it may take some time before a client notices it has changed. See the descriptions of the acdirmin, acdirmax, and noac mount options for more information about how long a directory's mtime is cached.
> Caching directory entries improves the performance of applications that do not share files with applications on other clients. Using cached information about directories can interfere with applications that run concurrently on multiple clients and need to detect the creation or removal of files quickly, however. The lookupcache mount option allows some tuning of directory entry caching behavior.
People did talk about using Lustre or GPFS but apparently they are really complex to set up and maybe need fancier networking than ethernet, I don't remember.
I did set up GPFS tadam... almost exactly 20 years ago. I wouldn't say it absolutely required fancy networking (infiniband) or was extraordinary complex to set up, certainly on par with NFS when you hit its quirks (which was the reason we went off experimenting with gpfs and whatnot).
reply