jacquesgt

In Italian, the third person feminine is formal. The first person plural is also formal, but (I believe) it's archaic. So, when speaking formally, one would say "can she help me?" to mean "can you help me?"

The issue here is that the order of function argument evaluation is undefined. If the commas weren't inside of a function call, they would result in sequence points. So, this would be well defined:

   int a = 0, b, c;
   b = a++, c = a++;

But, there is no defined order in which to evaluate function arguments.

That’s not how public key cryptography works.

You don’t go and buy an SSL certificate from a CA. You pay for them to /sign/ your public key, presumably after verifying your identity. You generate the public/private key pair, and then you keep the private key private.

The CA could in theory sign Eve's private key along with metadata saying that private key belongs to you, but that just gives someone the ability to impersonate you. It doesn’t give Eve the ability to read emails that Bob sent to you with a key wrapped with your public key.

The founders have a post on Medium with more details: https://medium.com/p/6c2600e7bc38

I created a new account and didn't use the option to sign in with my Google account. The importer didn't ask me to sign in with my Google account, but is happily waiting for feeds to import from Google Reader. Surely it isn't able to do that without me authorizing it first?

Also, are there any plans for mobile apps? If yes, please tell me that you're going to charge for them.

But, with the higher tax rate, someone else might decide it's worth it to increase their labor by 40% so as to increase their post-tax income by 20%, whereas they only would have increased their labor by 20% without the tax effect. So, it really isn't clear that higher taxes lead to lower amounts of labor.

There's a large block of memory that's easy to slice up on your own. It's called the BSS section, which is where global and static variables without an initial value are stored. BSS gets zeroed before main() is called.

This isn't possible in all cases, but for embedded software especially it's often possible to create all data structures as global or static variables. The compiler takes care of alignment concerns for you, and you're guaranteed not to have heap issues because you never use the heap. Of course, you can run out of the objects you pre-allocated in BSS, but that's an easier problem to diagnose and fix.

Yep, you're right.

In response to the last paragraph, there's a tension between two different visions for the C language. One of the visions is what's sometimes called "high-level assembly language". In that case, undefined behavior lets implementors choose the behavior that makes the most sense in that situation. Someone writing software for a DSP is going to have different expectations for the behavior or integers than someone writing software for a general purpose processor. Forcing both implementations to use the exact same semantics is going to slow both of them down, because extra checks will have to be added to work around the differences in the underlying hardware.

The other vision for C is a portable systems programming language. When trying to write portable code, undefined or implementation-defined behavior is a big problem. I'm glad that compiler writers employ a take-no-prisoners approach here. People shouldn't be relying on undefined behavior when trying to write portable code, so compiler writers shouldn't be bound to implement consistent behavior in those cases. That's especially the case if code ever needs to be compiled with a different compiler, which might decide to implement different consistent behavior.

It's also worth noting that in some cases, the exploitation of undefined behavior doesn't always happen in a single place in a compiler. Instead, it can be a combination of applying a few different rules in different optimization passes that produces surprising results.

With that being said, it sure would be nice if the compiler writers figured out how to give more warnings when undefined behavior is detected. If x + 1 > x is optimized to false, tell me! If a dereference of a pointer that could be null leads to potentially dead code being eliminated, tell me about that too! It's the silently surprising behavior that causes the most problems.

That is the entire reason. Because the representation of signed numbers could vary from implementation to implementation, making INT_MAX + 1 (or any signed integer overflow) undefined allows for more efficient generated code. If it were defined in some way, the generated code would need checks for overflow wherever it was possible, which would lead to bigger and slower code.

INT_MAX + 1 is never 0 for unsigned int. (unsigned)INT_MAX + 1 is equal to INT_MAX + 1. You're thinking of UINT_MAX + 1, which is always 0.

On the example platforms described at the top of the quiz, CHAR_MAX (char max) is 127, which SCHAR_MAX (signed char max) is also 127. This is because chars are signed by default on those platforms.

The point being made is that the default signedness of char can be different from platform to platform, and the default can be confusing to people who associate the char type with binary data. Better to use int8_t and uint8_t when you want a portable signed or unsigned 8-bit number. int8_t is always signed, and uint8_t is always unsigned.

Here's a much deeper and more technical presentation Ralph Langner gave on Stuxnet.

http://vimeopro.com/s42012/s4-2012/video/35806770

When you're driving someone else's car, their collision/comprehensive insurance covers damage to their car (although there's a chance their insurance company will decline to pay or decide to sue you depending on the circumstances). Your liability insurance covers personal injury and property damage that you cause to others.

Drivers are listed for two reasons. The first is because a big chunk of car insurance is liability insurance. The second is because the probability of the insurance company having to pay to repair or replace your car depends on the likelihood one of the drivers will cause an accident.

This is all made more complicated by the fact that personal injury lawsuits are a numbers game. If the driver didn't have insurance and their estate has very little money, it doesn't matter that making them liable is a slam dunk case. It's not worth the effort. On the other hand, if the car owner has insurance, is alive, and has a lifetime income potential in the tens of millions of dollars, that's worth a lawsuit even if the probability of success is lower.

It feels scummy, but most personal injury lawyers are investing in cases. They'll be happy to take a lower probability chance on a bigger return. It's not all that different from venture capital, although you could argue pretty easily that VCs are a more positive force for social good and value creation.

That actually is how car insurance works. There's a property insurance component ("collision" and "comprehensive") that insures you against loss or damage to your property. Then there's a more expensive liability insurance component that insures you against liability as a driver of any car. The property insurance portion is optional as long as you own your car outright.

A first order filter will attenuate at a rate of 20 dB per decade away from its cutoff frequency. For example, at a frequency 1000 times higher than its cutoff frequency, a first order filter will attenuate by 60 dB.

An n-th order filter will attenuate at 20*n dB per decade.

Let's assume based on your numbers the GPS band is 20 MHz away from LightSquared's 1.5 GHz-ish band. That's log(1.52/1.5) = 0.00575 of a decade.

We need 180 - 70 = 110 dB of attenuation to push the LightSquared signal amplitude well below the GPS signal amplitude. Solving for n above, 1/0.000575 x 110/20 = 956.

An order 956 filter is not something you can design for a buck or two. It's certainly not something you would design if you expected to filter out other space-based -160 dBm signals. Plus, the numbers above are very aggressive. You're going to need to do even better if you don't want to distort the signal you care about.

Combine the adaptability of fountain codes with feedback, and you can vary the transmission rate as the channel quality changes. With applications like cellular radios, this lets you use just enough power to transmit messages intact, optimizing the power usage across a range of interference levels.

Reed-Solomon and similar codes correct for bit errors in a particular block by transmitting extra bits in each block. Fountain codes correct for missing blocks by transmitting extra blocks.

If you just used RS, the only way to overcome really long bursts of errors (thousands or millions of bits long) would be to either to request acknowledgements from the receivers and retransmit unacknowledged blocks. If acknowledgements weren't possible, you would need to transmit everything multiple times. And, if you had enough receivers, all missing random packets, you would end up retransmitting everything even if you had acknowledgements. By using fountain codes, you can transmit an extra few percent of blocks and still succeed in the face of long dropouts.

Is there a way to export data from Parse? If not, how do you address developer concers about getting locked in to the platform?

Errr, right. MAC addresses are sent in the clear, so filtering is pointless.

See my response below. I think they're trying to protect against potential weaknesses in the HMAC by requiring both sides to prove they know part of the PIN before sending information derived from the second part of the PIN. If a weakness is discovered in the HMAC, this scheme is supposed to allow either side to bail without leaking the whole PIN. This (supposedly) protects against someone spoofing the AP and selecting nonces that allow the PIN to be recovered.

Neither. This doesn't affect WPA2 in any mode, as long as WPS (WiFi Protected Setup) is turned off.

WPA has known vulnerabilities that an attacker can use to cause a router to leak data over its WAN Ethernet port, so it should be considered unsafe at this point. But, that has nothing to do with this attack.

There's a detailed description of the weakness in the WPS protocol here: http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf

It looks time there are two issues here. The first is that the pin is confirmed in two stages, each of which can be individually NAKed. That brings e complexity down from 10^7 to 11,000. It seems like this could be fixed by always ACKing the first stage and then ACKing/NAKing the second stage based on the result of both stages (unless doing so would somehow lead to leaking information about the PIN).

I think the first issue comes from an attempt at doing mutual authentication. Basically the device (like a wireless printer) wants to tell an access point (AP) that it knows the PIN. But, the device wants to make sure the AP also knows the pin. Otherwise, someone could spoof the AP and say for any connection attempt "yup, that's the PIN, now here's your (fake) configuration". I think they're also trying to cover the case where the HMAC they're using has a vulnerability, allowing a fake AP to discover the secret key by using nonces that expose a weakness in the HMAC.

Instead of just trusting HMACs to do their thing, they break the mutual authentication into stages. The AP and the device each prove they know the first half of the key. If either side fails that test, then the other side refuses to move on, supposedly protecting the second half of the key even if the HMAC is found to be broken. In reality of course, it leads to the attack described above. If both sides just always ACK the first stage, everything is fine as long as the HMAC is secure (which it most likely is). If you're worried about the HMAC being broken, you could use a dummy PIN for the second stage if the first stage fails.

The second issue is that most vendors don't implement lockouts after too many failed attempts. Even if they do, the issue above means a brute-force attack is still possible in a few months' time because of the greatly reduced complexity. Fixing both issues would probably make a brute force attack impractical.

Until both issues are fixed, the best solution is to disable pin-based WPS. Unfortunately many low-cost wireless printers and similar devices require WPS to connect to a secured wireless network. Turning off WPS may make such devices unusable.

It's possible that enabling MAC address filtering will also solve the issue(actually... not).

Opportunity cost means exactly what he thinks it means. The idea is that it might look cheaper to develop technology in-house, but if it takes longer to build than buy, the company is losing out on sales during the time it's building. It also could be losing out on early-mover advantages. Those reductions in revenue are called the opportunity cost (because the size of the opportunity is smaller).

Factoring in the opportunity cost may make buying a more attractive option. Keeping opportunity cost in mind can help the seller get a much better price than they would if they just considered the acquirer's cost to duplicate heir technology.

Which metrics are you using to figure out how many visitors see the link at the bottom of the page, understand what it means, and decide "no, I prefer the Onswipe version of this page"?

Yes, it's needed. People with less than perfect vision appreciate being able to zoom in on small text to make it more readable.

A few other things that are needed (and work in the non-Onswipe version of pages):

1. Rotating the iPad to landscapes houldn't trigger a choppy relayout that takes five seconds. It should show the exact same content as in portrait mode, zoomed to fill the width of the screen. Users can then decide whether to zoom out and show more content, or stay zoomed in to take advantage of the increased horizontal resolution.

2. The back button should work. Pro tip: If I tap the back button 20 times, and nothing happens until the 20th time, the back button is broken.

No, 5% are opting to remove it. You have no idea how many are leaving in frustration, and how many don't know how to turn this thing off. I can assure you 95% of people aren't "opting" to keep it.

I think the difference is that it's a lot easier to opt out of online tracking. You can turn on private browsing mode. You can decide not to shop online.

With this kind of tracking, there's much less that you can do, especially if more essential shops like grocery stores start to implement it. Sure, you can turn your phone off, but I at least feel like merchants should be polite enough not to track my every movement without my explicit permission.

Once you have this data, you can correlate it with records of purchases to link a given phone to a given credit card number. I'm guessing it would take just two or three purchases at the mall to be able to do a match with high confidence.

But we all know retailers care too much about their customers' privacy to pool that kind of information, so there's really nothing to worry about. And anyway, the fact people are reading the little signs and then continuing to shop without turning off their phones is a pretty clear indication that they're opting into this kind of data collection anyway.

The big industrial automation and SCADA companies all provide some level of application engineering/system integration services. But, it's only practical to do the integration work in-house for large (millions of dollars in revenue annually or tens of millions of dollars in revenue one time) customers. Managing thousands of local teams of integrators all over the world to take on smaller jobs would be prohibitively expensive.

For smaller, "one-off" jobs, the integration work is done by distributors or by 3rd party integrators. Distributors will often do the integration for free and cover the integration cost and their profit from the discount the manufacturer gives them from list price. Most integrators do fixed-price bids for work, and may also make money from equipment markups. In both cases, there is a lot of incentive to do the minimum possible, especially since the projects tend to be poorly specified.

This is all made worse by the fact that the customers tend to be technically unsophisticated. That makes it hard for them to effectively manage projects, and hard for them to make informed judgements when selecting suppliers. Suppliers are usually picked based on personal relationships with the sales team (manufacturer's or distributor's) and the in-house engineer's familiarity with a given supplier.

Finally, the whole industrial automation industry isn't terribly glamorous. The typical problems being solved on any given job have been solved thousands of times before. The technology is often old and clunky (the most common language is called ladder logic... look it up, it's good for a laugh). Being successful requires a mixture of software, electrical engineering, mechanical engineering, and sales skills. Since most distributors and integrators live almost hand-to-mouth, sales skills tend to be emphasized, even among the engineers. The engineers who are good at sales find they can make more money doing sales. The ones who aren't salesy find there isn't much room for advancement and move on. I'm over-generalizing, but the overall trends don't encourage high-quality software engineering.

I typically answer with a range where the lower end is the amount of money I'm hoping to make and the high end is $5k to $10k above that. Then I add on, "but I'm getting great benefits, so that would have to be factored in as well." My current salary doesn't really figure into my answer.