It seems to me that this could be greatly improved by displaying this information together on a glass MFD.
It's a trade-off. Tunnel vision isn't always bad, if you focus on this theoretical "omnibus" instrument you watch it more closely, but the other information is right there without you having to break your focus.... and of course you would still want the individual instruments for a variety of reasons from silly to serious.
Oh. It also tells the camera's software what kind of lens is attached.
I'd imagine some of that is a form of DRM (like in ink cartridges) but it also provides the camera useful data about the lens characteristics that is used by to tune/drive focus, exposure, etc.
Physical connections, for the most part. You'd have to make an adapter, and keep in mind that changes the element spacing (eg the lens is now a bit farther from the sensor/film)
There's also some extra bits. For example, the lens assembly for my Canon has an electrical connector to support the focus mode switch (that's on the lens body) as well as to drive the focus servos.
You could put conditions in to (effectively) apply this to only mass manufacturers.
How this is done I leave unstated, but I'd imagine you could do it by looking at a variety of factors.
This way, big companies making thousands of identical items can provide parts (because they have (require) the infrastructure to store/ship all the bits and pieces) play fair, but small folks like you or other "craftsmen" don't have yet more unreasonable demands placed upon them.
Geek points is Y, X is the complicated-geeky-contrived solution factor. Points go up as X does, to a point, but then it swings down in a negative slope and does not return.
NPR was talking about it on the radio on my commute this morning.
The skeleton also had the humped back and lots of evidence of battle wounds, and the nearby location, all matched up with what we understand historically. Finally, DNA testing with ancestors at least strongly indicates a relation.
Who would have thought that just randomly poking memory of a laptop would brick it. Long ago Samsung told me that it was just fine to be doing this, and that there would not be any problems (I based the samsung-laptop driver on code that Samsung themselves gave me.)
Hmm... so the firmware is so retarded that bad values in RAM can permanently break the hardware?
That sounds safe. Hope that thing comes with ECC RAM!
But most hackers aren't interested in your cable box, or your DVR. They want something they can use to brute force passwords with, send email to others through, force into a ddos, or just use to plain straight up steal personal data with.
They should be. Those kinds of always-on always-connected low-demand systems would make perfect botnet zombies in great numbers, and I'd argue there are more of them out there than computers. Hell even if the botnet slowed the thing down, how many folks would you expect to notice? Even fewer than that are the amount who could/would do anything about it.
Would it kill those (oracle) idiots to include the US JCE policy files in an installer so I don't have to fucking manually replace jarfiles every damn update?
Yea, because I -love- installing the US JCE policies manually for all 4 installs every damn update. (2 each, 32 and 64. One for the JRE, the other for the JDK's private JRE.)
Yes, the stuff I support needs it, and I need to be able to test with 32 and 64 binaries.
Slashdot Mirror
I invite you to go watch Mad Max.
I'd be more concerned about the misuse of the word "create" in this case, to be honest.
That was a typo. I had intended to write 180 grain (which is what I have sitting at home, for my 30-06)
Which is why all the critical functions can be performed via HOTAS.
It seems to me that this could be greatly improved by displaying this information together on a glass MFD.
It's a trade-off. Tunnel vision isn't always bad, if you focus on this theoretical "omnibus" instrument you watch it more closely, but the other information is right there without you having to break your focus. ... and of course you would still want the individual instruments for a variety of reasons from silly to serious.
Oh. It also tells the camera's software what kind of lens is attached.
I'd imagine some of that is a form of DRM (like in ink cartridges) but it also provides the camera useful data about the lens characteristics that is used by to tune/drive focus, exposure, etc.
Physical connections, for the most part. You'd have to make an adapter, and keep in mind that changes the element spacing (eg the lens is now a bit farther from the sensor/film)
There's also some extra bits. For example, the lens assembly for my Canon has an electrical connector to support the focus mode switch (that's on the lens body) as well as to drive the focus servos.
You could put conditions in to (effectively) apply this to only mass manufacturers.
How this is done I leave unstated, but I'd imagine you could do it by looking at a variety of factors.
This way, big companies making thousands of identical items can provide parts (because they have (require) the infrastructure to store/ship all the bits and pieces) play fair, but small folks like you or other "craftsmen" don't have yet more unreasonable demands placed upon them.
... which then results in the boycotted boycotting the boycotter... by wearing their skin?
No. Peak, as in local maxima.
Geek points is Y, X is the complicated-geeky-contrived solution factor. Points go up as X does, to a point, but then it swings down in a negative slope and does not return.
(also: probably this is a woosh)
There's a peak where you start losing points instead. This is well into that part of the function.
NPR was talking about it on the radio on my commute this morning.
The skeleton also had the humped back and lots of evidence of battle wounds, and the nearby location, all matched up with what we understand historically. Finally, DNA testing with ancestors at least strongly indicates a relation.
It's a "mock"-up, for sure.
What?
And that's not what I meant. It was in a flight manual or something. Various conditions that ended with "you will not be X today"
What's that based off of? Seems familiar.
Who would have thought that just randomly poking memory of a laptop would brick it. Long ago Samsung told me that it was just fine to be doing this, and that there would not be any problems (I based the samsung-laptop driver on code that Samsung themselves gave me.)
Hmm... so the firmware is so retarded that bad values in RAM can permanently break the hardware?
That sounds safe. Hope that thing comes with ECC RAM!
I'm pretty sure the JDK's debugger would do what you want, if you could figure out how to work it.
... and where do you think the code to display that button came from? Not from C#, but from the .NET or Mono environment... which is... more code!
But most hackers aren't interested in your cable box, or your DVR. They want something they can use to brute force passwords with, send email to others through, force into a ddos, or just use to plain straight up steal personal data with.
They should be. Those kinds of always-on always-connected low-demand systems would make perfect botnet zombies in great numbers, and I'd argue there are more of them out there than computers. Hell even if the botnet slowed the thing down, how many folks would you expect to notice? Even fewer than that are the amount who could/would do anything about it.
But it needs to stay away from the high risk environment of the browser.
FTFY. There's nothing wrong with Java on the desktop... but there's everything wrong with it running in the web browser.
Would it kill those (oracle) idiots to include the US JCE policy files in an installer so I don't have to fucking manually replace jarfiles every damn update?
(this is not directed at you)
The Book is wrong. Everywhere else 's means ownership, so fuck that stupid-ass rule.
You'd have to be a nimrod to use Nimrod?
3. Write up a change control document
Bwahahahaha that would be nice!
Yea, because I -love- installing the US JCE policies manually for all 4 installs every damn update. (2 each, 32 and 64. One for the JRE, the other for the JDK's private JRE.)
Yes, the stuff I support needs it, and I need to be able to test with 32 and 64 binaries.