I have read the entire spec, except a few parts about the physical molding/construction of cables and some parts of the last chapter about hubs. I've read many of the change notices that come in the zip file with the main PDF. I've also read the entire HID, Mass Storage class specs, most of the CDC class spec, substantial parts of many of the others, and a good portion of the OHCI spec. I've also read the datasheets for numerous chips, API documentation for Mac, Windows and Linux (at least libusb on Linux), and numerous other related documents.

Yes, there's a lot of documentation. No, I haven't gouged my brain out.

I have implemented 2 USB device-side stacks on microcontrollers (a.k.a. "bare metal") from scratch. Both are commercially successful and in widespread use on Teensy 2.0 and 3.0 and numerous projects and products people have designed and incorporated my code.

While you've done neither, I most certainly have done both: read the specs and implement portions of USB. I would disagree with your opinion that summarizes USB as "horrible".

It's actually a pretty well though out system.

All you have to do to say "thanks" is get hooked on some show, and then occasionally pay iTunes' high prices for early access to new episodes. That's all. Simple, really, isn't it?

My site uses vBulletin.

This vulnerability is MUCH older than the 1 week mentioned in Slashdot's summary.

Several weeks ago the vBulletin folks sent an email advisory to all registered users (eg, people who actually paid for the software) . In fact, they sent 2 messages. The first warned of this vulnerability and suggested immediately deleting the install folder, if it wasn't already deleted as recommeded. The 2nd message, only a couple days later announced a new version which fixed this bug, even if the install folder was not deleted.

vBulletin has a web-based admin control interface, separate from the main forum. Even in the old, vulnerable versions, the admin section will not work if the install folder still exists. It just displays a message saying you must deleted the install folder before you're allowed admin access to your own forum. Any sites that were vulnerable to this bot must have been set up by just unpacking the zip file and then running the wizard to set up the database. It specifically tells you to delete the install folder at the end of that process. So anyone who got hit not only ignored that instruction, but also never even used the admin section of their forum, because it's intentionally disabled to force people to properly delete the install folder.

Sure, there may be 30-some thousand forums out there with this problem, but every single one of them was set up so poorly that the forum owner never even accessed their admin interface.

Well, there is an Arduino with 84 MHz clock, called Arduino Due. It's 32 bit ARM, not 8 bit AVR. It sells for $49.

My little company makes an Arduino compatible board called Teensy 3.0, which is technically spec'd 48 MHz but overclocks to 96 MHz without any trouble. It sells for $19.

There are also other less compatible alternative boards, like ChipKit, Maple and Fubarino, with clocks speeds in the 50 to 80 MHz range, and attractive prices. Their compatibility isn't as good, which might be a factor if you're using libraries or code from websites. If you're wring all your project's code, that's less of a concern.

These boards also tend to have more RAM and other built-in resources.

The "someone" mentioning 230 Hz is INTEL, in their Galileo FAQ.

http://www.intel.com/support/galileo/faq.htm

The question is near the end, specifically "What is the maximum rate at which GPIO output pins can be updated?"

The answer, which you'll see if you click that link and expand the question to see the answer, is:

The GPIO output pins on Intel® Galileo are provided by an I2C Port Expander that is running at standard mode (100 kHz). Each I2C request to update a GPIO requires approximately 2ms. In addition to software overhead, this restricts the frequency achievable on the GPIO outputs to approximately 230 Hz.

The datasheet, linked from this Slashdot article, shows a full-page diagram on page 3. On the left side are the usual 6 analog inputs. On the right side are the usual 14 digital pins, with 6 clearly indicated as PWM capable.

On page 4, it says:

  14 digital input/output pins, of which 6 can be used as Pulse Width Modulation (PWM) outputs;
          o Each of the 14 digital pins on Galileo can be used as an input or output, using pinMode(),
                digitalWrite(), and digitalRead() functions.
          o The pins operate at 3.3 volts or 5 volts. Each pin can source a max of 10mA or sink a maximum of
                25 mA and has an internal pull-up resistor (disconnected by default) of 5.6k to 10 kOhms.
  A0 A5 - 6 analog inputs, via an AD7298 analog-to-digital (A/D) converter (datasheet)
          o Each of the 6 analog inputs, labeled A0 through A5, provides 12 bits of resolution (i.e., 4096
                different values). By default they measure from ground to 5 volts.
      2
  I C bus, TWI, with SDA and SCL pins that are near to the AREF pin.
          o TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using the Wire library.
  SPI
          o Defaults to 4MHz to support Arduino Uno shields. Programmable up to 25MHz.

On page 5, the list continues:

          o Note: While Galileo has a native SPI controller, it will act as a master and not as an SPI slave.
                  Therefore, Galileo cannot be a SPI slave to another SPI master. It can act, however, as a slave
                  device via the USB Client connector.
  UART (serial port) Programmable speed UART port (Pins 0 (RX) and 1 (TX))
  ICSP (SPI) - a 6 pin in-circuit serial programming (ICSP) header, located appropriately to plug into
    existing shields. These pins support SPI communication using the SPI library.
  VIN. When using an external power source you can supply 5V through this pin.
          o Note: When using this pin to supply power to the board, it must not be greater than 5V.
  5V output pin. This pin outputs 5V from the external source or the USB connector. Maximum current
    draw to the shield is 800 mA
  3.3V output pin. A 3.3 volt supply generated by the on-board regulator. Maximum current draw to the
    shield is 800 mA
  GND. Ground pins.
  IOREF. The IOREF pin on Galileo allows an attached shield with the proper configuration to adapt to the
    voltage provided by the board. The IOREF pin voltage is controlled by a jumper on the board, i.e., a
    selection jumper on the board is used to select between 3.3V and 5V shield operation.
  RESET button/pin
          o Bring this line LOW to reset the sketch. Typically used to add a reset button to shields that block
                  the one on the board.
  AREF is unused on Galileo. Providing an external reference voltage for the analog inputs is not
    supported.
          o For Galileo it is not possible to change the upper end of the analog input range using the AREF pin
                  and the analogReference() function.

Several articles have appeared claiming "under $60".

For for free if you're one of about 50000 students or apparently about 400 people who attended a talk at Maker Faire last weekend in Rome.

However, if you check out Intel FAQ, there are a number of Arduino compatibility caveats. Probably the main on is the I/O pins are controlled by an I/O expander with approx 2ms latency. That's pretty slow compared to Arduino's slow digitalWrite() function, which run about 4us on 16 MHz AVR, or direct AVR register access, which takes 125ns.

The processor runs Linux and Arduino sketches are compiled to native Linux userspace programs, so it probably will open up a lot of possibilities.

Having created and published projects using both Raspberry Pi and Beaglebone Black, and speaking as someone who regularly publishes electronic projects and open source code (largely on the Arduino software), I'd echo what others have said... this thing really misses the mark, considering the high price and lack of I/O.

Beaglebone Black is really the one Linux-based board that's doing everything right (except for the head start Raspberry Pi enjoys). The price is under $50, size is small, there's a LOT of I/O with advanced capabilities, performance is ok, and the feature I love the most on BBB: it has a decent performing 2 GB flash disk soldered to the board.

As someone who publishes code for projects, a built-in flash disk with dependable performance a huge benefit. With a Raspberry Pi, you have no idea how their system will perform if disk I/O matters. They might use a SanDisk Ultra card (or whatever SanDisk is calling them now), which can do about 1 to 2 Mbyte/sec with random seeks, still slow by PC standards, but fast enough to be useful. But odds are they'll use a cheap SD card, where the random I/O performance can be as slow as 20 kbytes/sec.

If Intel really wants to rule this Linux-based project world, they'll need come out with something in the $40 to $60 price range, maybe with high-end options approaching $99. A good performing built-in SSD, enough RAM, lots of I/O, and good connectivity (USB, Ethernet, Wifi) are the killer features people need for real projects. A faster x86 processor on an overpriced, feature-poor board without SSD is never going to compete with great products like the Beaglebone Black.

I run a small business. Very small, only 3 people. Like virtually all small businesses, we use a payroll service. There are so many laws and regulations regarding payroll that it's crazy not to use a service. They add value by taking care of all those little details, so we're in full compliance with the many regulations. Of course, the service charges fees. There are several of these payroll processors out there, so they do have to keep the fees reasonable to compete, but they do incur real costs. If it were so easy, nobody would pay the fees, but indeed payroll processing is one of the main business functions that's outsourced. The fees are real.

The main fee is per pay period. If you pay weekly, the fees are twice as much as every 2 weeks, which in turns is roughly twice as much as monthly. It doesn't matter if you use direct deposit or live checks, the fees are the same either way. When it's an actual check, we write the physical check based on their calculations.

We pay every 2 weeks to our 1 hourly employee (and we would NEVER use bank card payment with hidden fees), and monthly for the 2 of us owners, because paying ourselves only every month saves on the fees.

The trouble with microtransactions is they'll create an incentive for content publishers to "nickel and dime" readers.

Just look at phone and tablet games with "in app purchase" models. A great idea in theory. In practice, it drives the entire game design from "pay to play" to "pay to win".

If the content industry figures out how to make microtransactions work (a pretty big if)... just watch. Content will adapt from trying to attract and genuinely appeal to readers to a "nickel and dime" them to the maximum extent possible!

When I *really* don't like something, I vote with my dollars AND by influencing others not to spend their dollars either.

I'm sure EA would greatly prefer if dissatisfied customers merely voted with their dollars, but kept quiet so as not to build a public awareness and cause others to do the same. Well, that's not how things work, especially in the modern times of widespread internet connectivity and online social networking.

I personally don't play video games much. But I recently tried a few on an iPad. My first experience, Plants vs Zombies, was fun. It seems to have been designed before this in-game purchasing became a big deal. But then I tried another, and another, and yet another... and it quickly became clear they were designed to force you to make in-game purchases. One even had 3 times of in-game resources, plus 2 types of time limits, which you could pay your way around.

Those games just aren't much fun. That's the problem. if you don't pony up real money, they're incredibly boring and repetitive... pretty much being stuck in a purgatory of inadequate resources to play the game. I tried paying on a couple. Guess what... then you've got everything you need and the game quickly becomes not very interesting either. It's a low quality experience either way.

When you make a poor product, word gets out. When an entire industry moves in a direction that's initially profitable, but ultimately results in poor products that people don't enjoy, eventually the marketplace wises up and demand for those products declines or evaporates. That's simply how free markets work.

Critical public commentary is simply part of that free market process. EA may not like it, but that's too bad. Sooner or later, as enough people vote with their dollars, EA will respond with better products, rather than wishing their dissatisfied customers would quietly go away.

My own Kickstarter project, used to launch Teensy 3.0 (a low-cost Arduino compatible board with a 32 bit ARM chip), shipped on time.

http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a

We had 2 levels of rewards shipping, half within 2 weeks, the other half the next month. We did end up shipping the last several September rewards on October 1st, so technically we slipped 1 day for small group of rewards. Otherwise, all the September rewards actually shipped in September, and the rest shipped before the end of October.

Of course, a tiny number of backers didn't respond with their address or had other logistical problems with their info. Most of those shipped late, but even then, we resolved nearly all of them in October.

Much of the reason for USB's slow disk performance is the simplistic bulk-only transport protocol used by virtually all USB mass storage class devices on the market today. The problem is bulk-only transport is a synchronous protocol, where every transaction must be fully completed before the next is begun. Even though it's transporting SCSI commands, you don't get important performance enhancing features, like command queuing. It's impossible to make best use of USB scheduling by sending the next command before the previous fully replies with the status code.

There is a new protocol called UASP (USB Attached SCSI Protocol) which aims to fix all this. But who knows when or if Microsoft will ever support it?

"The FCC's rush to takeover the Internet is just the latest example of the need for fundamental reform to protect big cable companies".

There, fixed that for you Jim (Sen. Jim DeMint)

I really wish flash advocates would stop saying "write once, run anywhere" until Adobe actually releases a Linux flash player with quality on par with the Windows version!

Truly, if you're a Flash developer/designer/artist who only tests on Windows, and there obviously MANY out there, you have no idea what a completely buggy piece of shit Abobe's Flash is on Linux. On all but the largest of sites, even trying to play video on many sites other than youtube and vimeo, Flash regularly crashes the entire browser. Yeah, Linux API are a moving target and audio is notoriously messed up, but there's no reason any plugin should ever completely lock up the browser, ever!

In reality, Adobe Flash is "write once, runs well only on Windows".

As a Linux user, I'm glad Apple is causing Adobe so much pain and I hope the horrible code that is non-Windows Flash becomes unnecessary someday. Alternately, Adobe could write a quality Flash player for Linux, but that seems to have a snowball's change in hell, especially with this horribly wrong mindset that Flash actually works well on anything other than Microsoft Windows!