smlacy

Actually, I don't really care what language. I was mostly making a comment on the lack of detail of the post. I had to click all the way down to the source code to see what language it was in, which to me seemed like the most important aspect of this entire project.

... In C#

Source code is not documentation.

The MuseScore XML files do not contain any link to a DTD, XSD or other XML DOCTYPE metadata, and thus, they are not self-documenting.

By comparison, the MusicXML format is open, because the following documentation is available: http://www.musicxml.com/for-developers/ Those zip files contain a complete and full specification of how to read & write MusicXML files, as I'm sure the MuseScore developers are familiar with.

I wouldn't consider the MuseScore 1.3 or 2.0 format "open" until there is available full specification of the XML file formats, and the ZIP-based container they're usually wrapped in.

Even the MuseScore core developers admit there is no save file documentation and warn against attempting to parse MuseScore's save file format: http://musescore.org/node/13837

This is not "open", and I think it's wrong to sell these engravings as "open scores" in this context.

Are there specs for the 1.3 version? Can you provide a link?

This specific project was engraved using MuseScore 2.0, and their files cannot be opened using MuseScore 1.3.

For me, this is contradictory to the notion of "Open".

"somewhat proprietary" = "Where is the specification of the XML format of MuseScore 2.0 save files"

All I could find was http://musescore.org/en/handbook/file-format

Without a full specification (ideally with parser implementation, example source code for reading & writing, etc.) the XML is essentially proprietary, although still human readable.

Fantastic stuff.

I find the choice of MuseScore and it's somewhat proprietary XML-based format an odd choice for "open" though. For example, I tried to open these scores using the MuseScore binary that comes with the latest ubuntu, and it was unable to open the files due to the fact that they're written using the pre-release 2.0 version of MuseScore.

Personally, I find LilyPond (http://lilypond.org/) a much better choice for these sorts of "open score" type projects. It's editable without a GUI, and produces best-of-class output. Think of MuseScore as "a drawing program for musical scores" and LilyPond as "a language for expressing scores in a human-readable, generic form"

The Mutopia Project (http://www.mutopiaproject.org/) has been hosting and re-engraving public domain scores for a very long time. All the source code including scores is on github via https://github.com/MutopiaProject/MutopiaProject Although MuseScore has a prettier UI, Mutopia and IMSLP have much larger and comprehensive collections.

Anyway, Kudos certainly to the recording and performers, they're great, and I look forward to score engravings that don't rely on the MuseScore software.

So this is basically OnLive but "consumerized" (as they are focusing on enterprise these days it seems).

Even your line "using GPU tech originally developed for video game streaming" makes me think you've actually licensed or are a subsidiary of OnLive.

Fails to explain what "opengenera" is and why I would want to run it.

"Siri's voice recognition is kind of bad some of the time. I've extrapolated this observation to all other voice recognition systems"

What's Gambit? Links like this without context aren't useful.

Although highly suspect and troubling, this does not necessarily require that they have all users original passwords stored in plain text. If they had originally used a hashing function that obeyed the following:

Hash(pw) + Hash(pw) := Hash(pw + pw)

(NB: Where '+' above is really just a stand-in for any pair of combining functions, not necessarily arithmetic addition or string concatenation.)

But, I agree with many others here that the likelihood of stored plain text passwords is very high.

A brief introduction to "polyfilling" and what that means would be pertinent.

I've never heard that term and have no idea what this is about, nor do I care.

Someone forgot Newton's 1st Law of Motion, and it's evident in all these videos. In other words: It's impossible to steer a device like this .

When I view your videos, all I can think is "oooh, he's using some kind of page-fault type engine to pull in and dynamically generate cubical subdivisions of space"

So, assuming that's what's happening, why not pre-render/pre-generate a larger area than the visible area so that this faulting in process isn't as visible for a typical viewport pan.

Also, if you were to reduce the resolution, would that make the faulting/rendering faster? Seems like that would be a good compromise, as many of the demos now feel like the terrain isn't generated fast enough to make a playable game.

Oh, can you also demo destructibility in a future video?

Or hide it's irrelevance? "Drawbridge: In-process visualization of Win32 Binaries" will get a lot less clicks.

It's actually more like a victorian stereograph, an idea from about 150 years ago.

Everything he shows here is accomplished already by a fairly nice set of buttons on my steering wheel. Each button has a unique shape, so finding them without ever looking down is very easy, and my hands never leave the wheel.

What I find hard about in-car UIs are things like entering and editing navigation directions or selecting music to listen to given a 32GB USB stick full of songs.

There's always some horribly designed onscreen keyboard or "iDrive" type knob controller, both of which are quite horrible experiences. To make matters worse, the UI is laggy and unresponsive, and in an effort to make things "easier" onscreen controls frequently dim & disable when not actionable or when the car is moving vs. stationary.

Well, yeah, that's the easy way. :)

This is mostly to illustrate a technique of "parallel processing using fifos and split input" It's almost like a miniature mapreduce running locally. See also "bashreduce" (https://github.com/erikfrey/bashreduce) which I didn't write.

Sort a file in "parallel" (note quotes!) in a multicore machine (note I'm showing 2 cores but this could be generalized to more):

    mkfifo split_aa
    mkfifo split_ab
    mkfifo sorted_aa
    mkfifo sorted_ab
    split -n2 input_file split_ & 
    sort split_aa >> sorted_aa & 
    sort split_ab >> sorted_ab & 
    sort -m sorted_aa sorted_bb > final_sorted

It's left as an exercise for the reader to determine if this actually saves any time, and if this technique could be used to implement a truly parallel sort.

If you're looking for a good deal, just get one of the Asus MeMo 7" tablets. Basically the same as the N7, but $99.

Why is this on HN? Flagging.

Agreed 100%. How did this end up on the front page? Flagging as well.

Interesting! Wondering if there's something in the space of MapReduce/BashReduce (https://github.com/erikfrey/bashreduce) where you could take this...

Cool, thanks! Care to share how you created this?

Blog post from Aug 9, 2012, so "old news".

Something that's new to you is old news to people following the space.

That's scaled down -- do you have a full full full resolution?

Congrats! Hopefully Android is coming soon! :)

The only value twitter provides is in the value of it's users. There's virtually no value in the platform itself.

Clearly, you've never worked in distributed systems, and your impression of Twitter (and other large "centralized" by your definition systems) are actually huge, loosely coupled decentralized systems.

The real difference is whether than decentralized, loosely coupled system is run by and owned by a single corporation, or not.

It's the design of the system itself that determines latency, not the centralized vs. decentralized argument.

You're speaking as if twitter.com is a single giant machine on a single IP address. In fact, it's thousands of loosely coupled machines and services all working in tandem across nearly the entire globe. Sounds like a typical decentralized system to me.

So, by that measure, "The Web" as a nonprofit (w3c.org?) will never work and should be a huge failure, right?