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.

You've written hobbyist-targetting books with Radio Shack that work through hands on projects hobbyists can do themselves. My question is, for those seeking to carry your mission in writing those books over to computer-aided or simulation based learning, what things of value did you create that will be the hardest to carry forwards and what are the greatest things of value that computer-assistance will uniquely be able to take & make it's own & go furthest with?

Personally I would've gone for a mention of Mantle, the proprietary API they are introducing that sidesteps OpenGL and DirectX. I don't really know what it does yet, haven't found good coverage, but DICE's Battlefield 4 is mentioned as using it, and the description I've read said it enabled a faster rate of calling Draw calls.

http://www.xbitlabs.com/news/graphics/display/20130924210043_AMD_Unveils_Next_Generation_Radeon_R9_290X_Graphics_Card.html

And once one has started playing BF4 ($60 value), one can either pay for DLC individually or spend $40 more for Premium.

I'm pretty displeased BF4 is a $100 game.

"They also fail to recognize that technology may radically change humans in the next century or so.'"

What does humanity changing have to do with robotic exploration or not? Why are you insisting everyone acknowledge this point? What is it being made for? Why do we have to recognize this possibility? What possibilities for radical human change are interesting in the framework of the space-development debate?

Stop trying so hard to insist on being right and spend more effort helping people discover what is in their own imagination.

It's possible to use a hottened egrep by booting up one egrep, checkpointing it, then restoring that checkpoint again and again whenever you need an instance.
http://ask.slashdot.org/comments.pl?sid=4150171&cid=44759217

The problem is not using egrep, the problem is not using an existing already launched copy of egrep. Which, you CAN do. And I'd even recommend doing so, because it's manageable and uses sane well known and unfancy tools that are decoupled from each other.

Thanks for writing GIT. So many in this thread immediately jump into alternative options without discussing what's really at the heart of this problem. Grep is fine software and is known to do it's job well. As you say, the problem is simply that grep has startup costs, but those can be near totally ameliorated out.

Use CRIU (Checkpoint Restore in Userspace) to checkpoint a hot version of grep that has been started and given a couple seconds to load in the dictionary and build it's pattern matcher and is thus just awaiting stdin (which you haven't given it). Restore a fresh instance for every new email, and pass the new email into the just-opened stdin for that restored, hot, waiting to go instance.

Instead of launching a fresh grep and initializing it with your corpus, this will create a grep that you can online which will be ready to go, awaiting input.

Ma-fucking-gic.

Traditionally one could achieve this effect by forking child workers, but that's a fucking huge pain in the ass as far as program design goes, making things really complicated- instead of a single program doing a single thing, it couples many uses of a program into a single programs lifestyle. Daemonized apps require system level management and have to be running. Service apps require complex interfaces to handle the different servicings they are performing. Decouple concerns (stay unix'y: stdin->program->stdout), and CRIU the bitch. Just use a hot program, rather than a cold one.

If the problem persists: fuck grep, it's pattern matching is rubbish and it's worthless. Please let us know. You might also consider 'head' 'ing the first 64k or some such of your email to avoid pattern matching the entire doc.

I'd love to be helping to polish and work on Pandora, AnonymousCoward, but after placing an order two months in, early December 08, I have no hardware and little hope.

OpenPandora has not disclosed how many units have made it out into the field.
OpenPandora has not told us anything about the current rate of fulfillment for backlogged units.
OpenPandora claims to be out of funds.
OpenPandora claim to be using new sales to fund the backlog.

But we've been strung along for four years already, and I'd be shocked if I ever saw a thing from the $330 I mail ordered to them.

Get classic OpenPandora preorders fulfilled? Um, no, not at all. My guess is they've fulfilled considerably less than 1/2.

The devs state they don't have funds to fulfill orders, and that they're using new revenue to help fulfill the massive backlog they presently cannot afford.

I was in fairly early in the queue, early December `08. I've listened to hopeful progress report after hopeful progress report, but I'm skeptical I'll ever see a thing from the $330 I mail ordered them. If OpenPandora disclosed any information about the backlog fulfillment rate, I might have a hope, but they've left pre-orders hanging indefinitely and provided no solid information to build expectations or hopes against.

I'm not upset at what seems like my loss of $330: it was a good notion, I'm sure it's been a wild adventure, and I doubt anyone's going to bed on large piles of money, but getting strung along for four years, being told they've run out of money, and are trying to use sales to earn themselves back into the black... after four years of being strung along, I don't believe I'll ever see a thing.