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.

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).