jack12

They did own Direct2Drive to buy, download, and (manually) install games, FilePlanet to (manually) update games and download demos, and GameSpy to chat with friends and find multiplayer servers. That covers most of Steam's functionality, I guess.

But it was all spread out and I don't think they ever made any moves towards trying to pull it all together into a single offering. It was just a bunch of separate websites / programs that happened to be owned by a common parent company. Which might be a good sign for Humble's continuing independence, if IGN is still running things the same way (but OTOH, all of those separate sites eventually just withered and died under IGN's ownership).

This is exciting, but I'm new to Keybase and don't entirely understand it yet. How can I clone a Keybase-hosted repository on a remote server? Can gpg-agent proxy through ssh similarly to ssh-agent to allow access to GPG keys (and is that what keybase uses?), without having to store my keys on the remote server? Or would I need to create a new Keybase account just for the remote server, with that account's private keys stored on the server but at least segregated from my account's full access to communication, team-management, etc? Or would the best approach be to clone the Keybase-hosted repository locally and then push it to the remote server over SSH?

Items shipped by sellers in China often have such asymmetric shipping costs that the cost of returning them to China might be more than the entire item is worth.

Just a heads up: on the US Amazon site Feitian has a USB-A + NFC token for $16 (and there's a one-per-customer coupon on the amazon product page to knock it down to $10).

Feitian also have a BLE + NFC + USB token for $24 (with a coupon to buy it for $16), but that requires charging a battery, is less rugged, and the USB requires a cable to connect to it.

It's not as cheap as USB-only (there used to be a $6 USB token sold), but NFC support doesn't have to cost much more (especially as the secure element chips they're built around all move towards having NFC support as a baseline anyway).

Also there seem to be a handful of Java Card implementations of U2F on github already (one of them is even sold as a Fidesmo app, if you want to pay for easy installation), so an NFC-only U2F token could presumably be had for as cheap as any javacard-compatible NFC smart card, and then just registered as a second token.

I don't think it's enough to help push U2F forward by itself, but I think if webauthn can get solid cross-browser support for U2F implemented, price won't continue to be a big problem. Having just read up on webauthn, and seeing how many browsers already have test implementations shipping, I'm pretty optimistic U2F is going to be seeing a lot more interest soon.

Aside from the obvious reason why (iOS support looks unlikely to ever happen), I imagine seeing the list of supported browsers read nothing but "Chrome" discourages implementation too.

Though U2F's javascript API situation makes a lack of adoption a bit of a mixed blessing. Because sites need to include browser-specific code to access a browser's U2F support, that means any site adding support for Chrome right now will have to go back and modify their code to add support for Firefox when it comes, etc. (From the spec: "RPs [Relying Parties, i.e. web pages using U2F] interact with the FIDO client through a MessagePort [WEBMESSAGING] object. [...] This specification does not describe how such a port is made available to RP web pages, as this is (for now) implementation and browser dependent.")

Google and Yubico provide an example wrapper around the Chrome-specific method for getting access to Chrome's U2F messageport (at https://github.com/google/u2f-ref-code/blob/master/u2f-gae-d... in the function u2f.getMessagePort), but the wrapper gives up if it's not running in Chrome (the else branch just tries hitting the old Chrome extension by hardcoded chrome-extension:// URL).

Even if Google's wrapper someday adds support for other browsers, every site will need to update its copy of the wrapper before that site will support the other browsers.

If very many sites were adding U2F support right now, I suspect a lot of them would remain Chrome-only even as more browsers added U2F support. Maybe if adoption only happens after more browsers already have their U2F support available, more sites will end up supporting those browsers than if it was getting adoption right now.

I think it's possible to view the tweet as general bemusement rather than an attack, though I obviously don't know exactly what is intended. The next tweet is "I'm sure there's a perfectly rational explanation for why this happens, but it's logged in an issue on Github, which I cannot read".

I mean, it is a bit amusing to get an HTTP error as a result of asking a local interpreter to perform addition.

I'd say it's not unusual for modern languages, particularly those integrating package managers, to lazyily download libraries and/or check for updates on the first run of a REPL. But it is a bit odd or unexpected that elm's REPL requires a network connection for every launch and doesn't fall back to a cached copy of the core library packages from a previous run when the connection fails.

It still seems to need to at least check for the latest version after that first install, I have a ~4 second wait before evaluation of the first expression on every single launch of the REPL while it hits up their package server.

And if you have no internet connection or the package server is down, the REPL will not evaluate any expressions at all, it just shows an HTTP error message on every input (after a timeout).

The only option for offline usage seems to be running the REPL inside a configured elm project directory which has had the core packages downloaded/installed: https://github.com/elm-lang/elm-repl/issues/54

It required 60 votes, and received 59 (officially 58 because McConnell switched his vote to retain the ability to reintroduce it). It only needs one more vote to pass, in other words. Feinstein was absent today, but will presumably be vote number 60 next time.

I think the ESP8266 supports operating in SDIO mode, it's the descendant of a chip used to add wifi to low-end tablets. So it could be used as a literal replacement for an on-board WiFi module, if SDIO pins are available on the Orange Pi board.

The same store has the Orange Pi Lite, which is essentially the same as the One but with wifi instead of ethernet (plus a microphone, ir receiver, and a 2nd usb port). It costs $2.01 more.

They also have the Orange Pi PC Plus, which has both ethernet and wifi, 1GB of RAM instead of 512MB, and an 8GB eMMC. But that's getting up in price to ~$25 shipped.

The nrf51 is available with 32K RAM, but only in combination with 256K of flash, designated with the AC suffix (AA: 16K/256K, AB:16K/128K, AC:32K/256K). The 32K chip has been shipping on Adafruit's boards for a while, and is now even shipping on some of the generic Chinese dev boards and modules, so I assume it's widely available.

I imagine the main reason for going with the cheaper chip is that micropython was a pretty late entry to the list of supported coding environments, and the hardware was probably already pretty settled before the port started. Also BLE+4K of ram is probably usable in the other official (compiled) languages, and micropython does otherwise work aside from something that's a fairly advanced feature. So it would have been a tough sell increasing the cost of every board when most students and lesson plans will never use BLE and there are other languages available if they do want it/need it.

It looks like the smallest of those WizNET W7500 boards is only $30[1], and includes a magjack on a carrier board (not shown in the mbed pictures) which is still fairly compact overall. The W7500 seems to include a Cortex-M0 that you can run your own code on, so it could be more interesting than the W5100 chips. I doubt it will end up being available in a $2 module, though.

[1]: http://www.shopwiznet.com/wizwiki-w7500econet

Just to be explicit, while this competes in the "tiny but breadboard-friendly microcontroller" market, it's not a nRF51 board (it's actually a more powerful chip, CPU-wise) and it does not have any sort of radio, bluetooth or otherwise.

The support from PJRC is great, though. And if you want to use the Arduino environment, I don't think anyone puts more work into making it work flawlessly on a non-AVR platform than Paul does, not even the Arduino guys themselves with their own ARM boards.

And in the least elegant, but cheapest, form factor WaveShare make a module they call the Core51822[1] that is cloned by tons of folks and is basically the generic nrf51822 module you'll find for ~$5 on ebay. It's the most awkward compromise of 2mm pins (and in double rows too) that make it wholly incompatible with a breadboard yet it's also bigger than any other "embedded" module. But there's also a BLE400[2] "motherboard" which breaks the module's pins out to 2.54mm-spaced connectors, along with a few LEDs and buttons and a USB serial chip (all of which can be disconnected via jumpers), and one of those old, giant, 20-pin JTAG connectors.

It's not able to plug straight into a breadboard, but it does allow full access to every possible IO pin on the chip, and it's probably the cheapest setup you can find. A combination of a Core51822 and BLE400 seem to be easily available for ~$15-$20 shipped, there's even stock available through an Amazon Prime seller for $22.

If you do go for cheaper options, keep the chip differences in mind. The nRF51822 is currently available in three variants, and the differences are big. AA has 16K RAM and 128K Flash, AB has 16K RAM and 256K Flash, and the AC has 32K RAM and 256K Flash. The AC variant was only introduced recently, so some options might still have the older/cheaper variants. But some examples and tools (such as Nordic's BLE sniffer firmware and tools) are starting to require the latest chip with the 32K of RAM, so make sure whatever you're buying explicitly promises you'll get the 32K RAM chip (the AC variant), like this OSHChip does.

[1]: http://www.waveshare.com/wiki/Core51822

[2]: http://www.waveshare.com/wiki/BLE400

BLE "tags"[1] cost ~$2 shipped and seem to send a notification every time their button is pressed. I'm not sure if they perform well in the case of powering down and then back up, though. It seems like they might need a button press to allow a host to reconnect to them, which would present the same problem as in the article. And they have awfully annoying beepers in them that beep with every button press, and beep multiple times before powering down.

1: https://github.com/sylvek/itracing2/issues/5

When you say IoT applications, do you mean phone apps which are dealing with data which originated from a "thing" in the IoT, but that the data has already gotten to the phone or cloud through some other, non-Couchbase Mobile channel?

Or is it possible to run or communicate/sync with Couchbase Mobile directly from a "thing" itself?

This article is very confusing in the way it refers to "early backers", I think it's leaving people with the wrong impression of what is shipping. They are shipping "alpha" CHIP computers only to the 150 people who backed at the "KERNEL HACKERS" tier for $150+S/H [1]. They've also announced that they'll be shipping an unexpected second alpha unit to each of those 150 backers again next month, partly because the first batch won't have any boot images programmed.

This initial shipment of 150 was scheduled for September from the beginning of the kickstarter, but it's not until December that the "$9" tiers begin to ship, and not until May 2016 that the majority of their rewards are due. It's nice to see them more or less on schedule with the roadmap in the original kickstarter, but this isn't anything unexpected.

There are people who say the $9 price point is unrealistic, and that the company will have to start taking additional "preorders" at higher prices just to afford to manufacture the preorders they already have, or that it's relying on corporate partnerships and funding to sell at a loss until enough interest is built up that they can increase the price. This is a fairly small shipment, which probably won't change any minds on that subject.

[1] https://www.kickstarter.com/projects/1598272670/chip-the-wor...

Supposedly, biometrics at points of entry have already decreased the ability for an individual operative to claim more than a single identity in a lifetime [1]. I imagine having to deal with the change from being able to use agents many times to only getting a single use out of all that recruitment and training was a much bigger deal than this set (CIA+OPM background checks) of single-usage agents going to zero-usage.

[1] http://www.wired.com/2012/04/cia-spies-biometric-tech/

Could be LEON, which is still closely associated with the ESA: http://en.wikipedia.org/wiki/LEON

All About Circuits (www.allaboutcircuits.com) is an expanded version of this open-source textbook.

It looks like any corrections and additions made on All About Circuits feed back to this source too, but AAC has a slightly more web-like layout and links to additional materials (forums, worksheets, video lessons, etc.).

Except that there are reports (http://forum.arduino.cc/index.php?topic=307397.0) that the boards from official distributors are shipping with Arduino Srl's USB Vendor ID, indicating that purchasing any "official" Arduino is likely funding the attack on Arduino LLC.

Hence the GP's observation that buying a 'no-name' clone seems to currently be the least-harmful option available.

From the comments on the question, it's actually for a joke/complaint about the cost of that very logo: http://pvp.comeze.com/brandgenerator/ (type in Halifax and it shows a message about the cost).

It would be pretty funny if the libraries made to help out this joke end up being used for official uses of the logo, but at present the logo's only rendered inside an image at the official branding site, http://halifaxdefined.ca/#new-logo

The thing is, the only tool provided for using the PRU is an assembler[1]. So trying to make an AM335x into an "Arduino" required at a minimum: a friendlier real-time IO system / PRU toolchain, the creation of an Arduino sketch and library API compatibility layer, and circuitry to deal with 5V IO.

Solving all that by just bolting an ATMega beside the AM335x isn't the least bit elegant, but Arduino has never seemed to be too bothered about elegance.

_1: https://github.com/beagleboard/am335x_pru_package

Both the BeagleBone and the Minnowboard are made by the same company, CircuitCo. I'd say that the Arduino announcements today must have been a bit painful for them, except I'd guess they're probably also the partner company behind the TRE.

>BTW: If anyone invents a time machine, please go back and get the original Arduino header alignment fixed.

The TRE has all of the arduino signals on a 2x17 0.1" header, the one with a white background around it (which seems to mean 5v-safe / AVR-connected on the TRE). Then there's also the remaining double-row headers, which I'd assume are arranged on a 0.1" spacing in relation to each other, and are possibly a new Arduino standard for a 3.3V-only header layout.

It's still not perfect, though. Personally I wish they had made the new standard headers closer together than the old headers instead of further apart, to make it possible to at least bridge across some of them with a $10 5x5cm PCB (even the existing Arduino header standard is just a bit too large to fit on a 5x5cm board, and that's the standard lowest-price tier at all of the super cheap chinese PCB services). But I guess if you only need access to the Uno-era Arduino pins, you can now fit everything into a ~4.4cm long double header. But it's a double header, so you can't make your 'shield' able to pull double duty by plugging directly into a breadboard, which you could have if there had been two close rows of 5V headers instead of a single double-row.

But it is an improvement, and the form factor does have a history of working, a single double-row header is the basis for the entire Pi-Crust/Plate/Shield ecosystem.

High-resolution photos at http://e2e.ti.com/blogs_/b/toolsinsider/archive/2013/10/03/i...

I'm looking forward to seeing some reviews of these when they start arriving. I'm especially curious to see how well (or rather if) they achieve that Arduino IDE/sketch compatibility, it seems like a point that a lot of ARM-based "arduino compatible" kickstarters have been promising but glossing over. I know that PJRC's (ARM-based) Teensy 3 has had an enormous amount of work put into truly making it compatible, hopefully a lot of that is feeding back into the libraries and main Arduino project in ways that will help all ARM-based Arduino-compatibles.

Even without support for Arduino/Wiring, that NRF51822 should be fun to play with! But it looks like NRF51822 breakout boards are already showing up on ebay at about the same price (and with more pins broken out). So I'm not sure if preordering is too interesting at this point if it doesn't deliver on something above and beyond a mere breakout board.

Interesting the way it has circled back around. ISTR it was deliberately started as a paid mac-only app by Steve Streeting / sinbad after he switched to macos and decided trying to do the added services thing wasn't his favourite, after years of running a consultancy service for the (primarily win32) open-source project he had started, ogre3d.org.

It says it's listed on a blacklist of domains involved in spam. But it's not clear if all the folks pointing at the one blacklist are examples of it being relisted multiple times or just people rereporting that it's on that list. It's not listed in the last 30 days of additions at http://www.joewein.net/bl-log/bl-log.htm so I'd suspect that 2013-02-07 'event' listed on WOT is meaningless.

Considering the time of its first listing was right around the time of the domain's registration, and that the blacklist is apparently a list of domains /mentioned/ in spam, I wouldn't be too sure it's not just a case of some spammer copy/pasting a list of 'recently expired / created domain names' in a pitch for domain registration or something like that. Seeing as it's just the one blacklist, the current owner might be completely unaware of it.

Hard to guess, though. His MXs aren't listed on any of the usual blacklists, though that's not necessarily where spam would be coming from. On the other hand, spammers don't usually list their name and employer on the front page of their site.

I'd love to see support for writing directly into distribution's package managers' databases added to things like pip, npm, gems, etc. too but I'm curious what playing nicely with automake gains here. I'm not too experienced with it, and I don't quite see where it would fit into that process.

I think of automake as being more part of the build process. But if things worked as you and inopinatus suggest, and you have taught something like pip 2.0 to bypass the rpm package manager and instead add records directly to the RPM database for a binary wheel package that pip has installed, aren't you kind of routing around any problems of a distribution's compatibility with a language's custom build process entirely?

Or did you mean to reply one level up? Though, again, I'm not sure where automake would help with converting one binary package format into a distribution-specific binary format.

On Arch the 'gvim' package also includes a more featureful console vim, including python (2, not 3) support built-in. The downside is that the dependencies for gvim include GTK and a good chunk of X11.

If you do need a console-only vim on arch, it's probably best to build it by hand as you did, since the PKGBUILD in abs for the vim/gvim/vim-runtime set of packages doesn't lend itself well to custom builds.