A fish cannon sounds like a idea Nintendo Super Mario Bros game idea.
Just to put "some time now" the time frame into perspective, the last mainstream PC memory form-factor to use asynchronous DRAM was 72 pin SIMMs.
When PCs went from 72 pin SIMMs to the first 168 pin DIMMs, in the mid-1990s, the interface changed to (non-DDR) synchronous clocking.
I find it amusing that Anarchy will supposedly spring forth from a technology that depends on highly refined, multi-disciplinary engineering and built from precision materials that are only manufactured and sold at affordable pricing in the context of a highly ordered society.
I'm the author of Teensyduino, software for an Arduino compatible board.
I sometimes use my Agilent scope when developing or porting Arduino libraries. Sometimes I just want to check the relative timing of stuff, so I'll set a pin high or low at some point in the code, then capture with the scope to see if the code is taking a long time. Often it's surprising how fast, or how slow certain code can be, and pretty often it's relatively easy to discover and fix performance problems. You can do quite a lot by normal software debugging processes, but pretty much all those approaches involve running the code much slower. When you're debugging real-time code, like libraries that synthesize waveforms by bit-bashing or tricks with timers or DMA channels, there's really no substitute for a good scope.
But admittedly, this is a pretty narrow fringe. Most people probably don't do this sort of low-level coding.
Really, you've written GUI programs using GTK's C-only API and liked it?
Did you really enjoy all that type casting of pointers? That's a lot of unnecessary trouble, when clearly some dialog box must be able to use the more generic window style setting functions. If only the compiler somehow could know your reference to the dialog box is compatible with all that other stuff the dialog box is built upon.... if only....
I've build programs with wxWidgets 2.8. It does automatically handle those platform specific style issues!
I used wxMenuBar, populated with a heirarchy of wxMenu and wxMenuItem objects. I just pass a point to the main wxMenuBar object to SetMenuBar, which is from the top-level frame of the GUI.
On Mac OS-X, it automatically appear at the top of the screen. One Linux and Windows, it automatically appears on the top of my program's window.
Likewise for toolbars, I simply used with wxWidgets objects as documented, without any specific style stuff. They automatically adapt to fit the style of each system.
That's the magic of wxWidgets. That work you mentioned, adapting things to fit the stylistic expectation of each system, is exactly what wxWidgets does so very well. It's vastly superior to other toolkits which attempt draw their own widgets, because the wxWidgets developers have gone to tremendous effort to actually use the native widgets from each platform. You just use the rather generic API for wxWidgets and you end up with really good native GUIs on all 3 platforms. Best yet, when the user customizes fonts, colors and whatever else, your program adapts like other truly native applications. Other cross platform toolkits fall down in that respect to the customized style, because they aren't really using the platform's native GUI.
wxWidgets 2.6 and 2.8 were pretty major releases, actually.
I use wxWidgets. Most of my experience is with version 2.8.
If you care deeply about making a native applcation that truly has a native GUI on Windows, Mac and Linux, wxWidgets is great. Nothing else even comes close. Java, QT, XUL, FLTK, TCL/KT and others all produce programs that aren't quite right on some plaforms.
The truth is wxWidgets is pretty much its own system, an SDK in itself. It has a tremendous amount of somewhat complex design, like sizers, which means you have to go to some extra effort. Of course, for making things work well on all platforms... not simply just work, and not work well on Windows but end up sub-standard on Mac or Linux, but work truly well on all 3, the extra effort to use wxWidgets is definitely worthwhile.
But the truth is you do have to put in extra effort. wxWidgets has great documentation to help, but the other truth is everything is heavily steeped in C++ class heirarchy. If you're good with C++, it'll feel pretty natural. If not, well, you'll get much better with C++ in the process, if you persevere. In the end, if your goal was a native application that truly works natively on all 3 platforms, the sort of thing users take for granted and never notice, you'll be rewarded.
But if you don't really, truly, earnestly care about targeting all 3, if only Windows has to be high quality and the others are afterthoughts, or if you just want to get things done as quickly as possible with minimal learning, you'll probably find wxWidgets to be far too much trouble.
I use wxWidgets. I've mostly used verson 2.8 with ansi strings.
As far as I know, wxWidgets is the only cross platform toolkit that compiles to program that use the native GUI widgets on Windows, Mac and Linux.
You can usually spot Java and QT programs. They work, but things look a little out of place. Firefox does a better job, but things start going wrong if the user customizes or "themes" their desktop. Emulating the look of native GUI controls just isn't ever as good as actually using the native ones.
wxWidgets isn't perfect. I've hit a good number of bugs. It has a pretty steep learning curve. It also doesn't seem like "new" technology. But it works. If you want to write a native application that truly looks and feels and actually is native on each platform, short of writing the code 3 times, wxWidgets is pretty much the only toolkit.
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.
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.
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.
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.
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
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.