IIRC most of the ARM based ReadyNAS products have mainline'd kernel support already, and I believe the bootloader is uboot... but yeah for a managed product rolling your own isn't the best way to fly.
I limit my use of them to very specific, simple scenarios. Two VLANs max, no need for monitoring, etc. If I need more than that I'll move up the food chain to something with proper enterprise functionality.
On the ReadyNAS issues, have you considered blowing away Netgear's firmware and putting vanilla linux on them?
Netgear GS108PE run about $100, give you 8 gigabit ports, four of which support up to 15w of PoE. Management is via a self hosted web int, the docs say you have to use their crappy windows app to configure them but that's bunk.
Toyota style Hybrids have been doing that from the start. I've got an 06 Highlander Hybrid, when it decides to fire the motor up for the first time it'll extend the run to make sure the catalytic converted and coolant come up to temp. This actually results in a noticeable dip in MPG in the winter...
It's not an Epoch time bug, it's a lazy programmer bug. If you're going to use X time system, do so intelligently. If you're going to use Y time system... etc.
It's not the first time that idea has been floated: http://kxan.com/2015/04/02/cit...
UEFI isn't required for ARMv8 mainline kernel support. Devicetree is.
That RPM drop isn't from closing the throttle. It's from cutting spark, ignition cutout at first, and then from the inertia of the car overcoming the torque of the motor and DRAGGING it down to rev match. The throttle linkage controls the shift points and weather or not the transmission 'kicks down' a gear when you stab the throttle.
Modern cars that are full electronic don't use a mechanical linkage to signal the transmission to alter shift patterns now.
For an example of this, look at this vid: https://www.youtube.com/watch?...
Note how the kickdown lever is operated and adjusted, it's pushed by the throttle when you floor it. Not the other way around.
https://www.youtube.com/watch?... GM uses a different setup, again you can see how the setup is to signal the transmission as to what's going on. Alternate methods GM used were vacuum sensing, no physical linkage.
http://www.jalopyjournal.com/f... has a discussion on using C4 transmissions without the throttle linkage, note no worries about the transmission not somehow closing the throttle on shifts, 'cause it never did in the first place.
https://en.wikipedia.org/wiki/... has a paragraph on the governor in the transmission that is controlled via either a mechanical throttle linkage or vacuum, aka the part we've been discussing. Note the lack of any comment about it closing the throttle.
Ultimately though, if you want to see this in action, drag out your ye-olde automatic with a mechanical throttle linkage and get it on a lift so the drive wheels are off the ground and the car is stable and secure. Pop the air filter off so you can watch the throttle body butterfly(s) while a friend runs the car up through the gears. You won't see any movement during shifts.
No, it doesn't. (And yes, I drive stick, and also road race motorcycles and am familiar with clutchless shifting using the throttle there.) The ignition cut out is what temporarily unloads the transmission making for a smoother shift, the linkage doesn't 'pull back' on the throttle. Think of it this way, have you ever felt the throttle pedal 'push back' more during a shift? You actually don't need to unload a traditional planetary gear automatic to shift anyways, the gear change is accomplished by bands restraining outer gearsets. Again, to demonstrate this unplug the ignition cutout feed from the transmission, floor it and hang on as you get hard but functional shifts.
You've got it backwards. The linkage between the throttle and the transmission was how the automatic determined 'demand' or load. Light input, upshift occur sooner. Put it into the floorboards and it'll wait to upshift until the last moment. Unloading the transmission was done via an ignition cutout triggered by the transmission.
I didn't know OpenNTP added server support recently, so new info for me today.
I'm assuming the 'BSD NTP client' is OpenNTPd. The 'Linux NTP client' is NTPd that we all know and is not linux specific.
Primary differences between the two:
OpenNTPd just cares about getting the local clock close to the remote NTP's supplied time. Nothing more.
NTPd wants to get the local clock as closely as possible to actual time as well as disciplining the local timesource such that 1 second is accurately 1 second, while weeding out faulty or maliciously bad sources of time. It also can act as a server, or as a peer in a server group. It can also directly interact with multiple reference clocks.
In short, you're comparing a simple client that just looks at the time on the wall vs something that's trying to be accurate and can act as the server side of the equation.
Um, that's exactly how it works. That's why movies can put restrictions on DVDs: You can watch the DVD in your house with your family, but if you want to show the movie to a large group, you'll need to get a separate license for that showing from the copyright holder. This is also why you can't record a movie at the theater, or record an entire stage performance to put up online without potential repercussions later, etc.
But... Ford's system IS Toyota based... they licensed the HSD system from Toyota.
"You tweachewous miscweant!" -- Elmer Fudd