http://natisbad.org/NAS4/index... has notes, I've verified that the 4.4 kernel has a dts file for the ReadyNAS 2120 so he was able to get support mainlined.
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.
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.
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'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.
You don't need to worry about car complexity creating that scenario. An idiot wrench can absolutely wreck his ability to stop by sucking air into a caliper while 'bleeding the brakes' leading to a failed panic stop or fail to lock down cables on a carb leading to a stuck open throttle, etc.
On the flip side, we're using an old P4 based HP to test Windows 10. 1GB of RAM, Intel chipset integrated graphics and the darn thing is actually quite responsive using IE/etc. Chrome takes forever to load but I want to toss the 64bit beta on there to see if that improves things at all. That's circa 2005 hardware. I need to research to see if my i810e chipset based e-Machine can run it next...
Um, no.... You still have to go over all the same hops with your encapsulated packet to get to the VPN endpoint, THEN the hop to the game server in the farm. Just because the trace looks different in the tunnel doesn't mean you've magically bypassed the internet. Sans VPN you'd be skipping encapsulation and that VPN endpoint to game server hop.
The AUP spells out their definition, and as noted has terms that specifically cover TOR directly. How their interpretation vs yours or others would play out in court I've no idea.
The merchant policies from Visa/etc actually instruct them NOT to ask for ID even if that's on the card. If you don't sign your card they're not supposed to accept it at all.
I want to say this was all debated once in the past back in the dialup era. If you advertised 'unlimited' dialup, you had to deliver and couldn't back door in per hour charges, etc. What makes this any different?
Slashdot Mirror
http://natisbad.org/NAS4/index... has notes, I've verified that the 4.4 kernel has a dts file for the ReadyNAS 2120 so he was able to get support mainlined.
http://www.openstora.com/wiki/... has actual instructions on interacting with U-Boot on those devices.
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 don't need to worry about car complexity creating that scenario. An idiot wrench can absolutely wreck his ability to stop by sucking air into a caliper while 'bleeding the brakes' leading to a failed panic stop or fail to lock down cables on a carb leading to a stuck open throttle, etc.
Finally we know why Ebon and Co stomped on the Odroid-W.
My core duo Mac Mini and MBPro, neither are supported by Apple, haven't been for quite awhile. I can throw Win10 on both of them without challenge.
On the flip side, we're using an old P4 based HP to test Windows 10. 1GB of RAM, Intel chipset integrated graphics and the darn thing is actually quite responsive using IE/etc. Chrome takes forever to load but I want to toss the 64bit beta on there to see if that improves things at all. That's circa 2005 hardware. I need to research to see if my i810e chipset based e-Machine can run it next...
Um, no.... You still have to go over all the same hops with your encapsulated packet to get to the VPN endpoint, THEN the hop to the game server in the farm. Just because the trace looks different in the tunnel doesn't mean you've magically bypassed the internet. Sans VPN you'd be skipping encapsulation and that VPN endpoint to game server hop.
The AUP spells out their definition, and as noted has terms that specifically cover TOR directly. How their interpretation vs yours or others would play out in court I've no idea.
This is also covered by their AUP and explicitly listed as an OK use of XFINITY.
http://www.comcast.com/Corpora...
No, but they can reference their TOS and note preclusion against running 'servers' on residential service.
Actually, they have a few rules in their Acceptable Use Policy that specifically go after TOR: http://www.comcast.com/Corpora...
The merchant policies from Visa/etc actually instruct them NOT to ask for ID even if that's on the card. If you don't sign your card they're not supposed to accept it at all.
I want to say this was all debated once in the past back in the dialup era. If you advertised 'unlimited' dialup, you had to deliver and couldn't back door in per hour charges, etc. What makes this any different?