where Gates & Jobs got all their ideas from.

Actually, Jobs just brought people over to see the demo. No one actually saw any code.

It's why Woz had to invent (and patent) "regions" which was needed because it's the way to handle overlapping windows. (Woz got in a plane accident a short while later where he supposedly told Jobs when he visisted, "Don't worry, I didn't forget regions").

It was only after it was all said and done did someone from Xerox tell Woz their Alto didn't have overlapping windows.

For years, these MCX folks allowed NFC payments, meaning potentially Google Wallet payments. Apple Pay comes out with an EMV based solution, and instantly block all NFC, taking Apple Pay and Wallet down together. So, Google was never seen as a threat, or at least never passing the threshold of needing-to-ban, even after years of use, but Apple is seen as a potential threat from literally Day One.

I wonder why Apple is seen as a threat more? Their network of friends? Number of potential users can't be it - many more Android phones than iPhone 6s. Number of cards already in iTunes? Ease of use (i never even tried Google Wallet)? Did Google leak some of the info back to the retailers where Apple is balking at that info leak?

Because Google Wallet and Apple Pay work in opposite ways.

For a retailer to support Google Wallet, they need to work with Google and their merchant processor to support Google Wallet. Because what really happens is the transaction details are forwarded to Google who then charges your payment method (credit card, debit, Paypal, bank account, etc). This is why Google knows everything about your transaction whenever you use Google Wallet. (Basically Google gets to know everything about what you're buying).

Apple Pay is nothing more than EMV so it's just an electronic credit card. Once you register your card through Apple Pay, Apple is no longer in the transaction. As long as the retailer takes credit cards, and has an NFC reader, Apple Pay will work. Most of the retailers listed by Tim Cook? They did diddly squat to support it. They just had working readers and probably someone came over and tried it and was successful.

Because to support Apple Pay means you need an EMV compatible terminal (swipe, chip+pin, NFC) and processor, and because of October 2015 legislation, people are supporting it by default since practically all new terminals have it. So all a retailer needs to do to get Apple Pay support is make sure their hardware (terminals) is upgraded (which they're doing anyways over the next year) and their processor supports EMV (which if they're doing chip+pin, they're going to have support for).

However, for Apple Pay to work, Apple needs to work with banks to ensure when a user scans a credit card,, they can get a token assigned in its place (the token is private between the user and the bank, and is basically just an index so the bank can determine who to bill).

So Google Wallet requires no effort by banks, etc., and effort by retailers to support. Apple Pay only requires hardware updates they're doing anyways which is minor, but effort by the banks to support EMV.

That's why Google Wallet's penetration has been low - there are probably more retailers that support Bitcoin than Google Wallet just because. (Though if your processor is adding support for Bitcoin, they probably have Google Wallet support as well).

For Apple Pay, because for retailers it "comes for free", which means its market penetration is far higher than what Tim Cook had in his presentation. Because retailers who already have NFC terminals practically already support EMV and that makes them Apple Pay compatible with zero effort.

So retailers may be inadvertently supporting Apple Pay when they don't want to because Apple Pay just shows up as a credit card.

What if the first thing that shows up in a google search about you is a court filing about someone else that shares the same name as you? Any HR department that takes a google search at face value isn't doing its job.

I think the "right to be forgotten" idea has good intentions but the problem is similar to the RIAA's resistance to the internet. A better reaction would be to give an alternative to people treating search engines and random internet sites as authoritative sources of information and instead give people something that they can trust that includes all relevant information. It could be similar to a credit score or a government run webpage that includes every individual's public information.

Sure, that's great, if you have a common enough name that millions probably share it. But if you have an uncommon name, or a unique spelling such that Google only turns up a few people, it's rapidly very easy to see who's who.

The right to be forgotten does not remove source articles. Just because you submit a request, doesn't mean the newspaper is forced to remove the article from its archives. No, the right to be forgotten applies to links. Perhaps if you Google your name, it brings up a DUI from 20 years ago you did (you were a young, reckless college student). All it means is that if people do the search of your name only, that no longer shows up. If they search by DUIs, then yes, your name shows up because it's true. But it shouldn't be the first damn thing that shows up if you've lead an exemplary life from then on.

In fact, rich people don't need this right because they hire "brand managers" that do this very thing. These companies use SEO and other techniques to bury bad news later on in the search because they know only about 30% of people make it to the second page of results, maybe 10% to the third, and 1% to the fourth. If you can get some bad thing put on page 10, it's "forgotten".

Do you not have any laws regarding the use of medical data in the US? In most of Europe businesses that handle medical data are controlled very strictly, and not allowed to share it with "affiliates" unless there is a medical need and you give your consent.

In theory yes. However, this is Google we're talking about, and this sensor isn't being developed from the goodness of Google's heart. No, Google makes money gathering information and knowing as much as possible about you. (It's interesting people think Facebook is worse, even though most of the data on Facebook was provided voluntarily by users of it. Google, OTOH, collects data involuntarily by your actions and by how big Google is ("too big to fail" anyone?)).

At the very least, Google will datamine your health information and suggest its affiliates target ads towards you, perhaps for ways to ensure your insurance premiums don't go up (and I'm sure Google would love to provide insurance companies with information on who saw that kind of service...). Or maybe show you ads for fitness equipment or something.

Add in a hack of the CurrentC system for its health data (and you can bet insurance companies would buy that data off hackers "off the books") and by the time the law comes around, it's too late.

It should be possible for Apple to actually make money from these donations.

In 2013, IHS estimateed Apple's costs to produce an iPad were between $274 and $361. Current retail price on an iPad Air w/ cellular is $829. Add in high-margin accessories and software, and it is quite possible that Apple could write-off a donation of around $1000 per device against $350 in cost. This $650 reduction in taxable income could save Apple about $227.50 in taxes... if they actually paid a typical 35% corporate tax rate.

While it's nothing to sneer at, realize that Microsoft, Adobe and O'Reilly are offering stuff that costs them far less. Apple's only making tax credits off their margin of 50%-ish. Software has margins of 90%+ because the incremental cost is practically zero (a CD that costs 5 cents in bulk and some paper materials).

And O'Reilly just has to basically front the cost of a basically free online service to them. Heck, they probably can fudge the author royalty numbers a tiny bit and it'll cost them barely anything.

For what an iPad costs, Adobe/Microsoft/O'Reilly don't have direct costs of nearly half that to actually build the thing.

Of that $100M in products Apple donated, it has a "real value" of over $50M. I'm sure of the $650M split between Microsoft/Adobe/O'Reilly, it barely equals that.

As for arguing about what they really need, well, they may not have direct access to a good teacher, but they certainly can use that stuff to interact with good teachers through video conferencing and other things.

It can be hard to get a teacher to come to the underprivileged areas (they're just like you and me and know where their job prospects are, too). But it doesn't mean they can't make themselves available using technology.

Any commit message that is only a single line other than "fix typo" is a bad commit message

"Fix typo" is a bad commit message. After all it doesn't explain what it was. Did it not build (in which case it would be "fix broken build"? Was a variable renamed because its name had a typo (in which case it should be mentioned in case it broke something)? Was it merely a typo in a comment?

Was it a bad #define that suddenly works and exposes new code?

I tried to set this up for my wife's great grandmother, but the otherwise modern facility had no Wifi and no 3G. We could barely get a cell signal of any kind in her room. The only internet in the facility was on a few dedicated computers. Cell reception was just fine outside though.

Actually, modern buildings are more likely to be like that because the windows and such have metallized tinting to try to block heat from entering and all that (where it'll get way too hot in summer).

Of course, this also means that RF is often blocked as a side effect.

Who do you trust? The merchants who want to use you as the product or someone who sells you the product.

  Everyones data mining and everyone's selling everyone's data. A business like Facebook its painfully obvious, the user is the product. Apple they are both so is MS. So unless you pay for everything in cash you are being mined by everyone. What we lack and our lawmakers are dragging there asses is forcing them to give us real options as in opt-in. If they were forced to give that option they dam sure would make it easy to find as apposed to digging to find an opt-out. Ever notice almost all of our public servers were/are businessmen and women many millionaires ..IMO taking care of there own.

Except Apple Pay can't. Apple Pay is a glorified credit card in the end. Apple is out of the loop other than knowing that you have at one point registered a Visa or MastterCard or something because Apple had to interface with the bank. But once you use Apple Pay, Apple doesn't get any information. Because it's a virtual credit card, so all the transaction information is shared between the retailer and the bank.

Google Wallet does, but that's because Google Wallet is a payment processor like Paypal, in that they get charged by retailers and they have to charge you, so they're a middleman.

And that's why Apple Pay IS more successful - because retailers have to do nothing to support it. If they have an NFC credit card reader, they automatically support Apple Pay, because it's a glorified credit card.

Sure there's a lot more security using tokens which can be revoked and reissued (so breaches just mean you shrug, get a new token and continue on with life because the old one is now invalidated), but in the end, that's it. It's a credit card.

Which is why Apple Pay is more likely to succeed than CurrentC - there is zero retailer investment (they're upgrading their terminals anyways), it integrates with current life much easier (it's just a credit card, a safer one than a traditional credit card, but it's juts a credit card) and it's dead simple to use, like a credit card.

Supporting Google Wallet requires retailer support (they need to make sure their payment processor supports it) - just like supporting Paypal or Bitcoin. Supporting CurrentC requires retailer support as well.

A lot of retailers mentioned by Apple had to do NOTHING in order to get Apple Pay to work.

Anyhow, let's see, we had Target, Home Depot, and many other big retailers breached. I don't know about you, but having all that data required for CurrentC seems rather ripe for stealing - full access to bank accounts, medical records and history and information (probably just skirting the boundaries of HIPPA).

And if Apple Pay doesn't work, then I'll whip out my old school Visa or MasterCard.

Really? How can systemd be sure that Apache has started completely and is ready to serve pages?

The answer is...exactly the same way every init script is "sure" that a service has started. It checks for the running instance, it checks PID, etc. But, unless it actually connects to the correct IP and port from a permitted IP and retrieves a web page that says something like "yeah, I'm running", systemd doesn't know.

I written service-monitoring scripts, and what systemd does isn't it, and is fundamentally no different from what is done by current init scripts. The difference is the current init scripts won't kill and restart Apache because they "think" something has gone wrong.

And that shows how little you know about init.

Init KNOWS/strong. when processes exit. In fact, the Unix process model is that there is ALWAYS a parent process (except for the first process, but that's usually treated as a special case in the kernel is the parent). In other words, it doesn't matter how you start programs, in the end, init, the first process, is the parent of all of them.

And parent processes get SIGCHLD whenever a child they spawned dies. In fact, init is the parent to all of them, so it knows exactly when a daemon dies. Especially if it spawned them.

Heck, init is called upon when there is no process waiting on a process because otherwise a dead process is still "alive" and has state the kernel is tracking (the exit code, namely). Init reaps such processes. (And perhaps you're familiar with "zombie process"? That's an unreaped process where the parent hasn't yet retrieved the exit code).

So no, systemd doesn't rely on PID files. It does note the PID of the service it started, and when the kernel notifies it that the process died, it can check to see what it should do - restart, log, alert, etc.

In fact, PID files can be trouble because PIDs are reused. Hopefully it takes a while and someone notices, but maybe not.

So something like Apache? systemd would know when it dies and how to restart it. Heck, it even knows if it fails too quickly, it can suspend restarting for a few minutes!

Oh, wait, did you not notice that even regular SysVInit has that feature? Because guess what - SysVInit is a daemon manager as well! You normally know it to run "getty", but that's just another daemon. When getty dies, init restarts it so you can get your login prompt back. If something nasty happens and getty dies too often, init suspends restarting it. (And given init may spawn 5-6 instances of getty - it doesn't use PID files to track them, but its internal database it created from /etc/inittab to track which instance of getty belongs to which line).

Init is far better at managing processes than trying to manage PID files manually in scripts. Especially if the PID files get desynced and you're having to ps your way to figuring out how to get the daemon killed and restarted properly.

Init is a process manager, in the end. Sure it also handles starting up, shutting down and going between runlevels, but that's secondary to the fact that the kernel uses init for various functions in order to maintain the Unix way, and that is every process has a parent, and in the end, that parent can be init.

We're going to need more vomit bags. People who were prune to motion sickness will be worse off without the windows since they are cut off from the last piece of sensory information that tells them that they are moving.

I'm sure while there are no windows, what they mean is no regular transparent plexi windows. They'll have virtual windows that are tied to a camera feed on the outside of the aircraft.

One big reason for this is windows suck. You ever wonder why they're so small, and in such strange shapes? It's because over the years, that's the only way to have windows without causing stress issues around the opening. (The first pressurized commercial passenger jet had big square windows. Within a year though, they were suffering catastrophic breakups due to airframe fatigue caused by cracking around the window corners).

By getting rid of these portals, you eliminate a major stress area in the airframe around the pressure vessel. Doesn't mean you can't have "windows" on the inside, it just means you need a camera and monitors. And it's possible that everyone can have a "window seat". (the equipment may even be lighter as you don't need to have as much reinforcing structure that you do to have windows)

when most of your subscribers have an upstream bandwidth of 1mbps or less, does it matter whether their storage limit is 1 TB or 100000 TB?

Actually, I think a lot of customers aren't consumers, but companies. And I've seen reasonably big ones move to O365 as well. These could conceivably make good use of the added space.

I don't think the average home or small business user would even fill up 1TB of space with all the documents they generate unless they distribute movies in PowerPoint or something.. On the plus side, I'm assuming it's versioned and backed up so at least the data is probably safer there than on whatever rickety computer they have.

After reading 2600 off and on for at least 20 years, it's getting hard to find. Their publisher went insane, B&N doesn't seem to want to carry it. Frustrating.

The printed version is hard to find, but the electronic version (DRM-Free!) is easily available in the B&N Nook Store.

Autumn 2014.
Summer 2014
Volume 30 (2013-2014).

Yes, it's DRM-free .epub,

Amazon has it as well, though since I don't use Kindles, I don't know if it's DRM-free.

Many places have laws that say if an emergency vehicle is coming by with lights and sirens (note "and"), then you are required by law to pull over and allow them to pass.

It would be helpful to know if the siren you hear (very annoying because in urban areas, sound carries) is on a cross street, a parallel street, or really on your street so you can find a spot to slow down and pull over safely.

Yes, many emergency services are experimenting with different sounds - the most effective ones appear to be broadband noise because it's unusual AND has enough spectral energy to permit easy location because the higher frequencies get very directional. So much so that in Europe, where broadband noise reversing indicators are common, narrow band alerts (the reversing "beep") can be banned on construction sites because they're not directional enough.

This is an interesting ruling because, currently in the US, playing a radio station over speakers in a business is copyright infringement. This is very close to the meatspace equivalent of embedding a copyrighted work. Since this is an EU case it obviously would not hold a great deal of weight in a US court (though international rulings are considered in some cases), but it brings up an interesting dissonance in copyright law.

Embedding is something unique only to the "cyber" world. About the closest equivalent is not playing a radio in a store, but having the radio station broadcast from your store - your patrons gets to hear the music, the content is managed by the radio station, and it's available elsewhere (over the radio). And radio stations have mobile studios for this purpose - they park in front of a business and play music from that location. It's backhauled to the station proper as it has the powerful radio transmitter and antennas, but for the moment, the station is "embedded" on the property. Copyright concerns are handled by the station since it's their content.

Basically it's who retains control of the content. Your radio in the business doesn't work because if the radio station doesn't want you doing that, they can't shut off your radio. Whereas they can shut off embedding on their own video, or stop playing content on the mobile studio.

Companies that are for profit that want to take an even bigger cut of your money, run on public networks, and make money selling your data.

I can't say about Google Wallet; but Apple Pay takes no cut of your money, nor does it sell your data, because a sales transaction is between exactly two parties: Your bank (as your agent), and the merchant (as the other "end point"). And the Merchant doesn't get anything but a one-time transaction approval code. The Merchant has no data to sell in the case of brick and mortar stores (nor does Apple). In online transactions, you probably will be giving up your name and shipping address to the Merchant, though (duh!).

  Apple does act as the intermediary between you and your bank during the setup process for a new card; but does not sell that information nor can it even decrypt the information sent back through them to update the Secure Enclave in the iOS device. Then, nothing and no-one can retrieve it directly.

Google Wallet and Apple Pay work in different methods.

Apple Pay works as you described, which can be summarized as "electronic credit card". Basically Apple Pay is a representation of your credit card. As such, it gets preferred "Card Present" rates (it IS a credit card), and works with may retailers off the bat - if they have NFC hardware and their payment processor supports EMV, they're all set to accept Apple Pay. Even if they do absolutely nothing. That's why Apple Pay works in a lot of places already and since people are upgrading thanks to "lowest security liability" coming in October 2015, getting EMV support rolled out is easy and with that comes Apple Pay.

Where Apple Pay fails is on the signup side - because it's an electronic credit card, Apple has to work with issuers to be able to get the token from them. And there are a lot of issuers and banks out there and each one needs to have APIs for Apple to request a token.

Basically, Apple Pay slots in neatly into how the system works already.

Google Wallet is different. It's like Paypal or Amazon Payments in that it is a payment processor. It handles payment requests from retailers, then charges account holders appropriately.

This means that Google will see every transaction - they have to as retailers have to submit transaction information to Google since Google needs to provide their account holders with enough details to identify the transaction so Google can charge your payment method.

This means that retailers themselves have to support Google Wallet as a payment method (just like supporting Paypal, Bitcoin, etc). If it doesn't support Google Wallet, then they can't bill Google.

The upside of the Google mechanism is it can work with practically any payment system available - Google's developers simply have to adapt the Google Wallet to the payment API of whatever new payment system they have. (Interestingly, that includes Paypal now...). So as long as you have a supported payment method (which is practically all - credit card, debit, etc), it'll work.

Note - Apple does get a kickback from every transaction - about 0.12% or so. However, that comes direct from the banks, so they just lump-sum it to Apple and Apple has no way to identify if they're being ripped off or identify the transaction amounts.