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.

Because it's tapping your checking account directly, customers are not going to like this. And to use CurrentC, you have to open up an app on your smartphone and scan a QR code to make the transaction; with NFC, you just bring your phone up to a point near the register until the register recognizes a near-field chip, ready to ring up the sale as soon as you authenticate, which in Apple's case means placing your thumb on your phone's reader. NFC transactions are so fast that customers are going to want them used for everything. There are already vending machines that support it.

Actually, the QR code is because iPhones didn't come with NFC. And Apple isn't allow app access to NFC yet (most likely because the NFC APIs aren't stable yet, but we can pretend it's to kill bad ideas like CurrenC as well).

The only reason for the fingerprint reader usage is because EMV demands it to access the secure element (Note: iPad Air 2 actually has an NFC chip in it, but no NFC antenna! It's suspected at least part of the secure element is the NFC chip, otherwise why have a completely useless chip htere?).

Apple Pay is just a fancy implementation of the EMV payment spec - it actually doesn't really have much "Apple" to it other than spiffing it up to make it all shiny and usable Apple-style. The spec is from EMV and that dictates how it all works.

People didn't and don't want single companies like Visa or Google or Mastercard or Apple having all the power doing this.

Apple doesn't control squat. All Apple Pay is is a virtual credit card implementing the spec with EMV. That's why it works practically everywhere with ZERO retailer involvement - as long as their terminals can do NFC purchases, Apple Pay will work. It does require the payment processor and the banks to have their end of the EMV spec done, which is why it only works with a few banks right now.

This is unlike Google Wallet, which is a payment system like Paypal - Google gets all your transaction information because they need to charge you. In Apple Pay, it's just using another representation of your credit card, which means Apple doesn't get involved in the transaction. It's why Apple Pay gets charged out at Card-Present rates, while Google Wallet only gets Card Not Present (higher fees because higher fraud).

Apple seem to be pushing their mobile CPUs forward quite fast - they're also way ahead of the curve in adopting 64-bit ARM. I wonder if there's a longer term strategy to start migrating devices like the MacBook Air over to their A-series CPUs, instead of Intel. That could tie things together quite nicely for them.

Unlikely.

The whole reason for 64 bit ARMs was because on ARMv8, AArch64 code runs significantly faster than AArch32 code. So if you want speed, you have to move everything to AArch64 - ARMv8 is only around 20% faster running 32-bit code as ARMv7 is. But if you get the same (or similar) code running on AAtch64, you get massive speedups. And that ignores the fact the 64-bit code takes more instructions because conditional execution is no longer present. (Those features don't work very well in a superscalar architecture, so ARM really threw out a bunch of legacy moving to 64-bit).

64-bit for Android is coming soon - the processors are arriving in quantities by the end of the year and mass saturation should happen middle of next year. And Android will get a massive speedup then as well.

Of course, I myself worked on the beginnings of a 64-bit SoC, to be sampled mid-2014 and in production end of year 2014 to mid 2015. (The project was cancelled though). So when Apple announced 64-bit 3rd quarter 2013, we were shocked - Apple basically got in production something that no one was going to be mass producing for nearly a year and a half, and having software running on it nearly 2 full years before Android was supposed to migrate. Apple got out the door 64-bit ARMs, even before ARM themselves had the core completely ready (Apple had the 64-bit core ready by the time ARM quoted us as when they'd have final production versions of the ARM code ready and synthesizable).

And yes, we had 10 systems with 4 $30,000 FPGAs on them (some had 8!) to simulate the ARM core. Those cost half a million each. Never mind the Cadence Palladiums (logic simulators, they are entirely common in the industry - nVidia has plenty of slides that show how they bring about the next-gen GPUs, and they show their boolean logic accelerators - that's Palladium).

FPGAs are faster, but even the biggest Spartan 7s at $30K each and 4 or 8 of them, we could only run it in 32-bit mode. Palladiums we could use the whole thing, if you were willing to wait - they were basically hardware-accelerated simulators.

I'm actually kind of curious as to what hardware Apple uses to design SoCs with - do they just have massive banks of Palladium units? (Because our FPGA systems were so new the software wasn't quite ready for them, so Apple's design would've happened while that hardware was being built).

How much OS-specific work needs to happen, and how is it distributed?

I'm assuming that the HDMI-in is fairly normal, unless they really broke the EDID/DDC or something(but obviously not going to be very pleasant unless the application drawing to the '1920x1080 monitor' knows that each of my eyes is only getting half of it).

Barring very good reasons(probably involving latency), I'd assume that the camera is just a UVC device; but that actually using it as anything but an expensive webcam requires the OR-specific head-tracking software to have access to it (the meat of which is presumably cross-platform; but DirectShow vs. V4L2 and other interacting-with-the-system stuff won't be).

The headset's USB interface presumably needs a specific driver, since 'read the outputs of a bunch of sensors and also firmware update' isn't exactly a USB Device Class; but would presumably be a comparatively lightweight 'wrap the sensor outputs and get them to the host as quickly as possible' thing, with the bulk of the motion and position tracking logic being mostly OS independent except for the layers it has to interact with to get headset and camera data.

Is this largely the extent of it (2 mostly standard interface, one device specific driver, plus having the motion and position tracking software running on Linux and interacting with the OS-specific interfaces to the drivers)? Do I fundamentally misunderstand how work is broken up within the Oculus system? Do I basically understand it; but it turns out that latency demands are so stringent that a variety of brutal modifications to the typical OS graphics system and GPU drivers are also required?

The problem isn't the OS support - in fact, it's possible the OR uses standard USB interfaces.

E.g., you say the sensors and firmware update aren't standard - in fact, they are. The sensors are typically just USB HID devices (HID devices are more than just mice/keyboards/joysticks - they include UPSes, sensors and many other devices. Basically all the device needs to do is send a "report" on its conditions, something sensors can do easily).

Firmware update has the DFU mode - device firmware update. You may remember it from "DFU mode" on an Apple iDevice, which is exactly the same thing - it's a USB device class that's simple enough to be implemented in a boot ROM (so you can never really "brick" it).

The problem I think is Linux' media handling just hasn't be up there. Sure, you need to port your software to use V4L2 (which can be a challenge to begin with). But OR prices itself on low-latency handling and all that, so I think there was a lot of optimizations that had to be done specifically for Linux to get the low-latency they require. The OR software was highly optimized for Windows to get low-latency, so it has to be re-done on Linux. And quite possibly it bypasses some of the Linux stack just to avoid abstraction layers to get even lower latencies. Maybe even doing some of the work in kernel mode.

It's not easy at all - sure to get it working initially is easy, but then OR works because it has low latency between the sensors and the display updates, and that's the hard work. Getting it "to work" is trivially easy, but you want it to work well.

Ease up, Android will be one of the few Linux distros by 2016 not using systemd. :-)

Because Android was probably the inspiration of systemd. Android's init system combines a daemon manager, udev, a property manager and init, among other things.

Granted, given the limited number of tools on Android, you pretty much need init to do these things because it's very difficult to manage daemons and other things.

The interesting thing is Android's init still cannot run a file. You can run something as a one-shot service to get around it, then start the service every time you need to run the executable, but it's a workaround to a bug that's been present since the beginning.

And no, Android's init doesn't even support sysvinit as a fallback.

. For example, FedEx and UPS could not handle the volumes of packages that each handles per day without automation. FedEx employees about 100K persons due entirely to the technology of automation. The same is true of airlines. The automation of pilot responsibilities and tasks has made flying much safer and easier (at least before the TSA).

UPS and FedEx are poor examples, actually. USPS is far better - in one day, USPS handles more mail than FedEx in a year. For UPS, it takes under a week. (Yes, everyone loves to rag on the post office, but given the volumes involved, UPS and FedEx won't be much better if they could scale up).

The post office realized it needed to automate way back in the 19th century because it knew the current methods were not scalable anymore. Indeed, the modern post office is actually VERY automated - including reading the address labels and deciphering them (handwritten too). Sure it's a bit of constrained input, but it's still automated. FedEx and UPS don't auto-read labels - the addresses are entered in manually or by the sender at time of sending, so a human always reads the address.

For airlines - pilots have increasing automation, but it's also lead to decreasing flying skills - many accidents have occurred because pilots needed to do manual flying to which they simply haven't done in ages so their skills have rotted.

There's a backlash going on in that while US carriers suck, at least in general a lot of pilots there do their own flying where all the automation simply doesn't exist or in very limited forms, so they do have to keep those skills up, so pilots from countries with a strong GA fleet will be better equipped to handle oddball landings when the automation can't, or won't.

Other places where pilots have never had to fly a little Cessna under VFR and land without assistance other than that provided by a Mk. 1 Eyeball generally have pilots rely on automation a bit too much, and when that automation encounters situations it can't handle or where it can only partially handle, they do a poorer job.

Things like ILS - smaller airports may have only one end of one runway equipped to take you to minimums, while using the other end the ILS will get you close, but you need to go and manually hand-fly it to use the other end (or another runway). It's interesting how many pilots feel very uncomfortable with that (it's a basic VFR maneuver, and as long as you can do VFR, you can do it. However, a lot of those pilots have never done VFR since flight training).

No idea why this has a Sony image with the post, the article is in large part about Apple and doesn't provide any proof of what exactly Apple consumed in Sony's supply chain.

There was a lot of argument over the floppy drive in the original Mac - Jobs wanted their own "twiggy" drive (that never worked right) over Sony's 3.5" drive (also new and proprietary at the time). Except Sony's drive was more reliable and well, it worked.

http://www.folklore.org/StoryV...

Heck, you could cause a lot problems on a classic Mac by having a file named ".sony" on it.

No, the privacy implications of this are downright creepy. Because the most unsettling thing is governments and corporations feel they have a right to this information.

And, it's not like you can opt out .. unless you simply don't fly.

And, then what does Cisco et al do with this information? Oh, right, sell it for profit.

Assholes.

Well, I fail to see how people taking note of information that you're basically shouting out loud to everyone around you can be considered creepy.

I mean, you phone is basically saying "Hi I'm John Smith the <48 bit MAC ID> and I'm looking for WiFi, anyone offering some?" over and over again.

So you're saying it's not right for someone to overhear it and write that down? "I just heard a John Smith out there".

You must be real fun at parties when people overhear your conversations.

Well, it must see some traffic ... I see a lot of users posting here on Slashdot which apparently authenticate as their Google+ users.

Using Google+ for authentication (really, just using your Google Account) is different from using your G+ account as a social network account.

You can use Facebook to log in to a lot of services as well, but that's not really "using" Facebook because you're not doing anything with what Facebook offers. You're just telling a website that you are who you say you are.

Hell, some sites even let you use Twitter to log in.

It's really a more fancy version of single-sign-on than anything. You could use your Google account (which is the same as a G+ account), Facebook, Twitter, etc as your online credentials.

I think today's the day Harper is about to ram his CSIS spying power bill through Parliament, as well. You know, the one that's increasing the ability of CSIS to spy domestically.

Even though the two soldiers who were run over were already well known. They already have the power being enacted (the ability to keep sources secret - a power they've actually never invoked, either),

Heck, one could argue it's to justify it all...

It actually is as part of 911-NG (next generation) which is meant to better handle next-generation telephony systems as well. Right now cellphones and VoIP 911 is more of a hack than anything in the current system, while the next-gen system switches to a completely VoIP (over a private network) system with failover and tagging and all that.

So the next-gen system will allow 911 to be contacted in many ways, including texts and SMS, VoIP (both private and internet), POTS, cellphones and all sorts of other mechanisms. And support for metadata is better, so GPS location information is available to everything (right now positional information is a hack for cellphones and non-existent for VoIP which often relies on just sending the subscriber's address info).

And load balancing as well - a center can go down and its calls get switched transparently to another center to take the excess with all the information the local center had being displayed as well (it's metadata is forwarded with the call).

Of course, it's supposed to only be deployed in a few year's time because it's a massive overhaul - it's going from circuit switched (POTS primary) to a packet switched (POTS secondary, but compatible) network and all that.

http://en.wikipedia.org/wiki/N...

Really? Who installs PowerPoint on the server? Cause you are gonna be all like, hold up let me unrack this server and connect a projector to it...right.

If your process involves generating Office, documents, it's generally the easiest way. The server automation tools for generation of Office documents are basically scripts and wrappers around.... Office. So if you want to generate some report that spits out an Excel file at the end, you can bet it was generated in Excel the first time around because the reporting tool actually called Excel to fill in the fields.

This can also apply to tools that email documents to users in the specified format - especially if it's to watermark a presentation or something.

It would be fairly fast, but the graphics part was a bit overstated. The Alto didn't support overlapping windows (Wozniak, who did the overlapping windows implementation on MacOS, later found that out after he did (and patented) regions (and after his plane accident).).

Given the Alto was the inspiration for MacOS (and Apple did license the idea from Xerox by giving them stock), I wonder how many other things we thought the Alto had, but it really lacked.