http://www.cnet.com/news/googl... seems similar. They claim 99.9% effective utilization through their per-server battery backup system, compared against 95% for a centralize lead-acid UPS based system.

http://hackaday.com/2014/11/11... might also have some nuggets. a lead acid battery is going to be heavily de-rated at the energy rates required. lead-acid will likely not have the same charging efficiencies.

holding the batteries around 70% is no big loss for this use case, given that the alternative is shortening the battery life.

Launchd is the young whippersnapper on the block. Solaris has had daemon administration for years.

The old guard is a huge fan of PID1 doing it's thing then going away: it's up to everyone else to manage the world after PID1 kicks everything off. The new world- the people who like systemd- are enthusiastic beyond belief to have a PID1 which serves as a master control point where the system can continue to be managed. Every systemd subsystem has a DBUS API we can program and talk to, we can schedule coordinate and manage processes over systemd's core DBUs endpoint- this speaks of the new dawn where we might not be able to hack our shell scripts to do whatever, but we can write higher level code to effectively manage their operation. Which is something that royally sucked egg in the old guard's world.

Sure some of this could sort of be dealt with by continuing to add more shell scripts. But the init script world is mess. Individual daemons have radically different ideas of what kind of responsibility they need to handle in their init scripts and even though for the most part the skeleton is visible across all, it's a hack job that outsiders have to wrack their brain to understand. Conversely, systemd gives us uniform control over the system: the master control program PID1 that is systemd will let us start/stop things, AND will tell us the status of things (over either shell interfaces or DBus).

I look at this more like the innovation of steering- which permitted four wheel vehicles- than I do a particular engine configuration (different muscle, same end). Sure you could get there with the old two wheel drive cart, but as it turns out you have a lot more flexibility when the platform has consistent stability that permits being added to. Where the cam goes is an argument that affirms the lie that systemd is just a really complex initscript: it's not, it's a resident system control daemon.

Where is the source? The Github repo says "This repository contains the core OpenBCI hardware and software frameworks," but there's no schematics, no board layout, nothing.

The $500 price tag seems absolutely absurd for what is essentially an already-made $30 ADC and it's breakout board.

Don't buy anything today. Wait until there are media boxes with quad Cortex A15/A17 chips and buy one of them. They'll be out any week now. Rockchip RK3288 is coming, should be affordable, and the company is spending a lot of effort making sure it's well supported in mainline.

Cortex A9 hails from 2007. It's ancient. The GPUs are at best old Mali-400's. The compute/watt is not-great.

If you want to go really low power- if battery life is your concern and you don't actually have serious CPU use (you mention MSP430, so it sounds like you don't have real CPU use needs) get a Cortex A7 or Cortex A5. There are dozens of dual core Allwinner A7 boards out there. A5 has slimmer pickings, but will get you pleasantly below the one watt range, and the boards come with more embedded targeted peripherals that might not be included on media devices.

Yes, well, the terminal was a much more sensible sane client that could take care of itself. We should _definitely_ go back to that on-the-line paradigm.

These are such tiny little warts. A) don't use global variables, perhaps 'use strict' if you want to be good. B) most languages have arbitrary bit limits. Holding up the floating point limit of 52 bits and making mock of that, but not holding up the 64-bit limit of integers? That's weak sauce accusations from sore fucking whiney babies. Oh you want to insist on arbitrarily deep numerical precision? Have fun crossing off a huge section of people that need moderately performant math.

Languages are all basically the same shit, with slight flourishes that everyone gets zealous and overblown about. Get serious. Go find something real to fight about, like how vim is so much better than emacs.

Yes, but the proliferation of tools makes it harder to make sensible decisions about which one's are directly applicable. Copy pasting random stack overflow answers in and hoping they work is a regular practice, and it's the very embodiment of what's happened in the technical realms: information glut.

Worse: a lot of information, very little sense. Very few projects out there bother spending the time to trace their genetic roots, to find historical context where sense-making of information can even begin.

I don't want to agree or disagree about web or web apps being kludgetastic or not, but I do want to point out- there were a lot less people doing programming and they'd built themselves a lot less tooling. What had to be understood was far less, and what it could be done was yet far less still.

A diverse technical ecosystem springing up is, in my view, a healthy thing: a natural awakening and striving for new potentials. That the many technical societies and practices don't all form themselves towards the same careful deliberate ends, one free of subcultures and instead pushing towards one unified culture, is natural.

This claim of elegant understandable tools of old is more likely to be the unavailability of other signals out there cluttering up the programming spectrum. Thrown into the mess of programming, it's hard to discern relevance of the many things one is being exposed to.

-LM

Spotify's extensibility is really good! Their API is great, very flexible, and extends the common-est platform on the planet. Playing with Spotify made me a better programmer, for sure.

The ability to use language (the command line) to express complex tasks is indeed it's highlight, but there's absoluetly nothing magical about this task-constructing that makes it uniquely UNIX'y in nature IMHO. Noflo, Node-RED, jBPM, IFTTT &c demontsrate user-authored task composition at the GUI level. Android Activities are themselves a kind of pipe to "?", where the GUI asks the user to complete.

The difference with UNIX is that the shell is a language, one that has very wide expressibility, and one that has multiple levels of grammar: the shell itself has a grammar, and the programs each have their own argument grammar, and this multi-level flexibility has proven robust, durable, & capable for expressing a very wide range of things. Which I don't see as uniquely UNIX, as uniquely CLI, but as a characteristic & not necessarily a good one that explains it's survival & persistence as an expressive tool.

HTML presents a graphical first environment that humans can come in to an enrich with code: declare your content, then orchestrate and manipulate that media via an API for the media.

HTML+DOM is awesome in that it's media-first, API second. The DOM is verbose, certainly, but it gives a much richer, more tangible surface than a standard library that is strings, vectors, ints, floats: so, we can get good at this platform without programming (HTML) and the DOM standard library, for when we do want to start programming/manipulating things, is a rich-media standard library as opposed to a primitive one.

<quote>A wrong character at some position might cause a lot of unexpected behavior and leave a good mess to clean</quote>

Absolutely!

The user experience in the command line is very demanding: a user has to marshal up the strings that describe their action. They have to be able to form sentances that say what they want.

Having the leeway and room of a language, a syntax, is the point: as long as you have the grammar, it's expressive. And whether that expression does what you want is question #2. But this chain, being able to form sentances that mean what you intend: that mastery of language is very much something I do wish to see advanced as a worthy cause, as indeed more important an experience than whether or not you know X or Y menu option in Z application.

Computer literacy can begot in a meaningful way only by calling upon people to form their own thoughts, not tap thoughts made available to them.

How do we promote electrical engineering when we're surrounded by an increasingly software & solution based world? Microcontrollers and increasingly so, full-blown microprocessor system-on-chip designs integrate a bedazzling array of top-notch analog and digital peripherals. Watching electronics parts catalogs, there's an ever growing profusion of special-purpose ICs, a low cost on hand solution to every problem. And in this state of being well served, I'm curious how we maintain proficiency, expertise, and interest in hard electrical engineering when soft skill-sets can carry us so far, when so much is provided. It seems great to me that we have NodeBots and AVRs &c &c that get people excited and spooled-up so quickly doing hands on work in amateur and professional electronics projects, but at the same time it seems cause for worry.

Reflecting on myself: I've gone through a number of high speed signals and systems books but still cower in fear for that day when I'll have to wire up DRAM to a microcontroller: I keep fingers crossed that my vendor will include an application note specifically for wiring RAM, that I'll have reference designs I can crib from, and I look forward to the day when RAM comes package-on-package with my micro. I want to have a better mastery of electrical engineering, want to be better equipped to face these challenges, but education has only taken me so far. Or, another example, I can carefully step through design of a flyback converter to plan out the behavior of that analog based system, but these days I'd tend to rely on some microcontroller functionality: take advantage of some comparators and timers, and begin with a much less carefully planned out and much more stripped down set of hardware components that I can fudge into near working order with software.

I'm wondering what the response is, if any, to this shift in skill set, and how we ourselves in touch with and unafraid of first principles, hard as that hardware-oriented knowledge might comparatively be.

Get rid of power cables. We don't need them. We're reasonably close, at least.

USB Power Delivery (USB-PD) specification allows for either-directional power transfer (host->device or a new device->host mode, say, monitor->laptop) of 20V@5A: 100 watts. Two connectors would power any laptop out there just fine with room to spare.

GET RID OF POWER CABLES. Pfawh on your faster horses IEC, your seemingly noble intent masks the superior result. Strategically there's a lot to love about USB's move as well: most laptops use 19V for charging, and the 20V power delivery target allows for a fantastically small & efficient buck regulator to clean that power.

Resistance is a function of conductivity times length, and sure, USB connecfors's conductivity isn't all that high, but neither is the length it has to work across. With active cooling of the connector jacket and "no limit" cabling on either side, it'd be interesting to see what amperage could be shoved through various well made connectors.

Ethernet is of course way smarter and way happier to throw piles of money at the problem than USB is: PoE+ will negotiate up to 60V using two pairs, albiet at what is typically a very mild current rating. USB Powered Device spec tops out at 20V but pushes 5A, which is a fine balance given the very short run USB has to travel.