How many different model cars have you driven lately? Sure, some have useful handbrakes, but many have "push on/push off" foot activated emergency brakes. Try modulating one of those.
Unless your nation has a track record of spying on its citizens web traffic
Who did you have in mind that doesn't fit that description? I'm having a hard time thinking of anyone.
The original point was valid. Perhaps it's time to change the cert infrastructure so that two geographically and politically disparate authorities must sign them.
Or, maybe get rid of "authorities" altogether, and move to a global "web of trust," a la GPG. Forget that, I don't think I want to trust a cert just because it's accepted by 1,400,000,000 Chinese.
Probably because, based on UI, speed, size, sheer awkwardness and oddball behavior (does it still act like you're doing a reinstall when you change a config option?), Acrobat consists mostly of unmaintainable spaghetti code - leaving it full of potential exploits.
they are a founding member of the OHA, and claim to have 10% market share ("one out of ten phones in the market today") with their Jbed Java Mobile platform.
So, it's not like it's some startup with no experience in that market, trying to make a name for itself. In fact, they would seem to have more to lose than gain by making overzealous claims.
and if it weren't for the summary here, you'd have no way of knowing that WTF he was reviewing. His article references "Voice Encryption," but nowhere does it mention that he's talking about software interception of cellular or mobile phones. From his description of Flexispy - "simply tap the microphone and it can be used in a wiretap mode to listen in to an active phone conversation or simply as a remote electronic bug for proximity eavesdropping" one might think that it's a hardware solution which wiretaps into the microphone. It's not. There is no "wiretap."
His point is correct, although the details are a bit misleading.
Just to give an impression of the magnitudes involved, I2C high speed (here's the spec) signals have rise/fall times in the 10-80 ns range. The setup time, which depends on the synchronization between the data and clock lines, has a minimum spec of 10 ns. If the implementation puts things in the center of the window, there's about an 80 ns setup time, so their might be 70 ns of slop available on either side.
Twisted pair cables will have a velocity factor in the 70% range. i.e. electricity travels through them at about 210 000 000 m/s. In 10 ns, electricity would travel about 2.1 meters.
How much margin any particular I2C implementation has depends on many things, but it should be clear that any decent implementation won't be affected a 10 ns delay to either signal, which equates to a couple of meters of additional wire.
In C, "0x10" just represents a bit pattern. Sure, the "10" in that construct is in hex, but what "0x10" represents is simply a bit pattern, it's not hex, or decimal, or anything else until you apply some meaning to it. The exact same bit pattern can be represented by the literal "16".
The bit pattern that it represents, if interpreted as BCD, is the decimal number 10, not 16.
You seem very confused. One could take your statement
0x10, by definition, is a hexadecimal value. So expressed in BCD it would be 16.
and change it, by the same logic, to
0x10, by definition, is a hexadecimal value. So expressed in decimal it would be 16.
But, that completely ignores that BCD and binary encoding of decimal numbers is very different, and that's what the issue originally presented appears to revolve around.
The pattern of bits represented by "0x10" is 10 if interpreted as the BCD representation of a decimal number and 16 if interpreted as the binary representation of a decimal number.
0x10 is 16 decimal, when interpreted as the binary representation of a decimal number (i.e. an int). 0x10 is 10 (hex) when interpreted as the binary representation of a hexadecimal number and is 10 (decimal) when interpreted as the binary representation of a BCD number. There is no "bcd/hex" mismatch in this case.
It's a mismatch between BCD encoding and binary encoding.
As the OP pointed out, you're confusing the C literal expression with it's datatype.
"0x" preceeding a C literal simply means that the literal is being expressed in hexadecimal. It tells the compiler how to interpret the literal, it doesn't type it. The type is given separately (e.g. "int 0x10" is the same as "int 16"). C doesn't provide binary literals, because it doesn't need to. Expressing as hexadecimal is more compact, and well understood (by most). One could equally well express that same literal as "'\020'" (which expresses a character of ordinal 10 decimal, and is expressed as an octal number), or by simply "10". They're all the same thing, the differences just make source code easier to read, they have nothing to do with how the data is actually used (encoded) by that code.
But, it would have no doubt confused you even more if I had said that "16 is 10 decimal in BCD."
The C literal "0x10" has the meaning "00010000" when interpreted in binary, 16 in decimal, 10 in BCD, and might mean "the clueful flags are off and the pedant flag is on" for a bit field.
No, I meant exactly what I said. I didn't say 0b01. 0x10 is the hexadecimal notation for "00010000" binary, which is 16 decimal.
I used 0x10 because that's standard ANSI C (and ECMA-334 C#), and C is what seems to be spoken on/.. 0b00010000 is non-standard (but allowed by some compilers).
Each contracting State agrees that all aircraft of the other
contracting States, being aircraft not engaged in scheduled
international air services shall have the right, subject to the
observance of the terms of this Convention, to make flights
into or in transit non-stop across its territory and to make stops
for non-traffic purposes without the necessity of obtaining prior
permission, and subject to the right of the State flown over to
require landing. Each contracting State nevertheless reserves
the right, for reasons of safety of flight, to require aircraft
desiring to proceed over regions which are inaccessible or
without adequate air navigation facilities to follow prescribed
routes, or to obtain special permission for such flights.
Now, I suppose the US could legitimately demand that any flights crossing its territory make a landing, hence subjecting passengers to inspection per Article 9(b-c), but that's only supposed to be available on a temporary basis.
Your point is correct. "The story of human exploration" and seafaring was purposed on finding the distant shore, and what was there. On Earth, other than finding new life forms, the surface of the sea is pretty uninteresting. For a space mission, you can go to that distant shore directly. Not much chance of finding life in a sea of methane (and if there were life, you'd expect it to be everywhere in that sea).
Other than providing a gimmick to make this different than previous missions, what's the point? Land something in a sea of methane and look for what? Sail around to find more liquid methane?
When crossing into Canada, you do not encounter any US Border Patrol at the Blue Water Bridge. At the Port Huron crossing, when crossing into CA, there's a toll taker (it's a toll bridge) on the US side, you cross the bridge, then stop for Canadian border inspection.
The process is reversed when entering the US (pay toll on CA side, go through border inspection on US side).
Slashdot Mirror
How many different model cars have you driven lately? Sure, some have useful handbrakes, but many have "push on/push off" foot activated emergency brakes. Try modulating one of those.
nt
Just record the stream the first time, and play it back for testing.
Yeah, and Generalissimo Francisco Franco is still dead.
You mean the fact that Outlook "creates unusually large e-mail files that take up too much space" is new?
Silly me, thinking 3K of HTML/header overhead to send a one sentence email fell into that description, because Outlook has done that forever.
Unless your nation has a track record of spying on its citizens web traffic
Who did you have in mind that doesn't fit that description? I'm having a hard time thinking of anyone.
The original point was valid. Perhaps it's time to change the cert infrastructure so that two geographically and politically disparate authorities must sign them.
Or, maybe get rid of "authorities" altogether, and move to a global "web of trust," a la GPG. Forget that, I don't think I want to trust a cert just because it's accepted by 1,400,000,000 Chinese.
Probably because, based on UI, speed, size, sheer awkwardness and oddball behavior (does it still act like you're doing a reinstall when you change a config option?), Acrobat consists mostly of unmaintainable spaghetti code - leaving it full of potential exploits.
they are a founding member of the OHA, and claim to have 10% market share ("one out of ten phones in the market today") with their Jbed Java Mobile platform.
So, it's not like it's some startup with no experience in that market, trying to make a name for itself. In fact, they would seem to have more to lose than gain by making overzealous claims.
and if it weren't for the summary here, you'd have no way of knowing that WTF he was reviewing. His article references "Voice Encryption," but nowhere does it mention that he's talking about software interception of cellular or mobile phones. From his description of Flexispy - "simply tap the microphone and it can be used in a wiretap mode to listen in to an active phone conversation or simply as a remote electronic bug for proximity eavesdropping" one might think that it's a hardware solution which wiretaps into the microphone. It's not. There is no "wiretap."
Mod parent up.
His point is correct, although the details are a bit misleading.
Just to give an impression of the magnitudes involved, I2C high speed (here's the spec) signals have rise/fall times in the 10-80 ns range. The setup time, which depends on the synchronization between the data and clock lines, has a minimum spec of 10 ns. If the implementation puts things in the center of the window, there's about an 80 ns setup time, so their might be 70 ns of slop available on either side.
Twisted pair cables will have a velocity factor in the 70% range. i.e. electricity travels through them at about 210 000 000 m/s. In 10 ns, electricity would travel about 2.1 meters.
How much margin any particular I2C implementation has depends on many things, but it should be clear that any decent implementation won't be affected a 10 ns delay to either signal, which equates to a couple of meters of additional wire.
Your desciption also explains why things worked just fine in 2009.
So, the date was (taking baseline as Y2K) Hex "9" which got translated to decimal "9" which was again translated to decimal (Hex "9" = dec "15").
Oh, wait. It doesn't.
The bit pattern that it represents, if interpreted as BCD, is the decimal number 10, not 16.
You seem very confused. One could take your statement
and change it, by the same logic, to
But, that completely ignores that BCD and binary encoding of decimal numbers is very different, and that's what the issue originally presented appears to revolve around.
The pattern of bits represented by "0x10" is 10 if interpreted as the BCD representation of a decimal number and 16 if interpreted as the binary representation of a decimal number.
0x10 is 16 decimal, when interpreted as the binary representation of a decimal number (i.e. an int).
0x10 is 10 (hex) when interpreted as the binary representation of a hexadecimal number and is 10 (decimal) when interpreted as the binary representation of a BCD number. There is no "bcd/hex" mismatch in this case.
It's a mismatch between BCD encoding and binary encoding.
That should read:
" '\020' " (which expresses a character of ordinal 16 decimal, in turn expressed as an octal number), or by simply "16".
As the OP pointed out, you're confusing the C literal expression with it's datatype.
"0x" preceeding a C literal simply means that the literal is being expressed in hexadecimal. It tells the compiler how to interpret the literal, it doesn't type it. The type is given separately (e.g. "int 0x10" is the same as "int 16"). C doesn't provide binary literals, because it doesn't need to. Expressing as hexadecimal is more compact, and well understood (by most). One could equally well express that same literal as " '\020' " (which expresses a character of ordinal 10 decimal, and is expressed as an octal number), or by simply "10". They're all the same thing, the differences just make source code easier to read, they have nothing to do with how the data is actually used (encoded) by that code.
But, it would have no doubt confused you even more if I had said that "16 is 10 decimal in BCD."
The C literal "0x10" has the meaning "00010000" when interpreted in binary, 16 in decimal, 10 in BCD, and might mean "the clueful flags are off and the pedant flag is on" for a bit field.
No, I meant exactly what I said. I didn't say 0b01. 0x10 is the hexadecimal notation for "00010000" binary, which is 16 decimal.
/.. 0b00010000 is non-standard (but allowed by some compilers).
I used 0x10 because that's standard ANSI C (and ECMA-334 C#), and C is what seems to be spoken on
BCD/binary mismatch?
0x09 = 9 decimal when interpreted as either binary or BCD.
0x10 = 10 decimal when interpreted as BCD, as 16 when interpreted as binary.
Now, I suppose the US could legitimately demand that any flights crossing its territory make a landing, hence subjecting passengers to inspection per Article 9(b-c), but that's only supposed to be available on a temporary basis.
It's simple. Just use a dial-up ISP, and... oh, nevermind.
Right. We haven't sunk a capsule since Liberty Bell 7.
Your point is correct. "The story of human exploration" and seafaring was purposed on finding the distant shore, and what was there. On Earth, other than finding new life forms, the surface of the sea is pretty uninteresting. For a space mission, you can go to that distant shore directly. Not much chance of finding life in a sea of methane (and if there were life, you'd expect it to be everywhere in that sea).
Other than providing a gimmick to make this different than previous missions, what's the point? Land something in a sea of methane and look for what? Sail around to find more liquid methane?
this one better.
this is exactly what the US Congress has been doing for years (Price-Gouging the Least Influential).
When crossing into Canada, you do not encounter any US Border Patrol at the Blue Water Bridge. At the Port Huron crossing, when crossing into CA, there's a toll taker (it's a toll bridge) on the US side, you cross the bridge, then stop for Canadian border inspection.
The process is reversed when entering the US (pay toll on CA side, go through border inspection on US side).
There's something not right with this story.
will it blend?