Did Android Really Look Like BlackBerry Before the iPhone? - <AUTHOR> http://www.osnews.com/story/25264/Did_Android_Really_Look_Like_BlackBerry_Before_the_iPhone_

<comment><USER2> I don't get this article's logic. The original iPhone was unveiled in January 2007, 11 months before the timeframe of November 2007.

The grid of icons thing had been in mobile phones for years and years before Android or the iPhone. What Android borrowed was the capacitive multitouch- style interface of the iPhone.

I played extensively with the Android SDK public releases before it incorporated touch. So did perhaps hundreds or thousands of others. It clearly wasn't going the direction the iPhone was, at the time.

He talks about facts this and facts that. But the fact is, he's wrong. Android borrowed from the iPhone's new paradigms. Has it been that long ago that we've already forgotten history?

Note that none of his facts come from personal experience. They come from dug up videos.

And again, what's the big deal? Everyone's all of a sudden screaming theft. Iterative improvements are good. They promote evolution and competition (eg. one upping each other's designs).

<comment><USER3> I agree with everything you said but the one thing you didn't mention is he makes the mistake of dating the prototype to the Techcrunch post. When in fact the prototype was obviously from an earlier version (hence the SDK looking like an iPhone).

As he said in the article Android had been in development for years before Google bought the company.

What is noteworthy about the "Blackberry" phone is the entire paradigm is different. The navigation is different. The desktop-esque icons on the home screen are different (the blackberry prototype had a dock type system where as Android has the icons on the desktop). The resolution is different (notice Android phones with keyboards have smaller screens but a similar resolution ratio where as the blackberry protype had a wide, short screen)

Notice how the touchscreen in the video works like the keyboard prototype and nothing like modern day android. Look at the 3 minute mark. See he's navigating through a dock. See how the commands are through menus and not icons like modern day android. Notice no pinch and zoom (he uses a button on the side). Notice no swipe (he's using a button on the right hand side). It's as if they took a keyboard prototype and rushed out a touch version (and then added all Apple's look, feel and gestures later)

Compare the phone shown in the video to the G1 ([http://www.letsgodigital.org/images/artikelen/681/tmobile-g-...](http://www.letsgodigital.org/images/artikelen/681/tmobile-g-1.jpg)) which had gestures, 4 icons per screen, swipe to get between screens and so on.

<comment><USER4> While the launcher changed quite a between the initial SDK release when that video was taken and what shipped on the G1, the version of Android shown did support a drag-scroll gesture for scrolling through the dock and app drawer. It did not support kinetic scrolling at the time though. You can still download the version of the SDK that was released back in November 2007 (when the video in question was released) and play with that early version in the emulator.

The G1 has never supported pinch-to-zoom or multi-touch in general except for in 3rd party ROMs and at least as of Gingerbread menus are still quite prevalent in Android (though D-pads and trackballs have fallen out of favor). The G1 also lacked an on-screen keyboard at its initial release (though this was added in an official update, Android 1.5 IIRC).

I don't think anyone would argue that Android hasn't been influenced by iOS, but it doesn't seem clear that they were solely focused on a non-touchscreen Blackberry clone and then did a complete 180 upon the release of the iPhone. It's certainly possible that they did so before they publicly announced Android, but we don't have any direct evidence of that.

</comment></comment></comment><comment><USER5> But November 2007 is still 11 months after the original iPhone was introduced.

<comment><USER6> I also found strange was the "Like the iPhone itself was standing on the shoulders of giants (iPhone to PalmOS: hi daddy!)"

But wasn't PalmOS at least inspired by the Newton?

<comment><USER7> At some point, you have a mobile device that you somehow have to interact with. Sorry, but I don't think Apple deserves credit for clickable/pointable/touchable icons (didn't that stuff come out of Xerox parc?).

<comment><USER8> (I think some of the current mobile stuff comes from the ubiquitous computing research that PARC did.)

They (Apple) deserve the credit for bringing those concepts to a lot of people.

And obviously it is true that interacting with objects/icons on a touchscreen is a general solution.

But the problem is not Android doing that, the problem is they lend all the aspects iOS makes original to include it in their concept. And Samsung copies the hardware look and feel.

That's the easy way to go for them. I think they could have come up with something different. Making the concept even better. But at the current situation, they will always be behind iOS, because Apple knows way better how to do great, usable interfaces. I guess iOS 6 will bring more widgets to the notification center and maybe animated/live icons or something like that.

These are the parts Google did new on Apples conceptual idea, and they will eventually come to iOS too, but more refined in a more cohesive way. Google needs to think differently.

</comment></comment></comment></comment><comment><USER9> I remember vividly back in 2007 all the Blackberry-clone screenshots of Android with multiple buttons and scroll wheel. Not just the one referenced in the article, but _many_ screenshots and no screenshots of a full touch interface. And then around the time the SDK was released in November, there started appearing the full touchscreen interface we see today.

<comment><USER10> Google was demoing the Blackberry-style configuration as late as February 2008, too. For a second, I thought I was going crazy, then I found this picture: <http://news.cnet.com/2300-1037_3-6230132.html>

</comment></comment><comment><USER11> Well, if you go back to 2003, there was the Motorola A760, which looked a lot like current android phone but without capacitive touch (resistive touch/stylus, no keyboard though). Oh, and it ran linux, and apps via java.

<http://www.gsmarena.com/motorola_a760-392.php>

<comment><USER12> Yeah, I had a P800 running UIQ back in the day. But I think the bottom line is that if you put a UIQ phone, a WinCE phone, an iPhone, and a G1 in a lineup, the G1 would be a lot closer to the iPhone than the others. And the similarity has only increased over time.

<comment><USER13> Know what would be a heck of a lot closer? A Clie TH55.

<http://reviews.cnet.com/sc/30733801-2-440-front-2.gif>

<comment><USER14> Which is not dissimilar to a Palm Treo, and Palms OS was very similar to Newton.

</comment></comment></comment></comment><comment><USER15> The article doesn't even speak to the obvious rebuttals: 1) the "touch screen" Android interface is mostly driven by buttons, 2) the iPhone was launched 11 months earlier, 3) the blackberry looking phone is the one the guy was carrying around for 6 mo.

Right or wrong, an argument that does not address obvious rebuttals is not an argument, it's wishful thinking in an echo chamber.

<comment><USER16> "the "touch screen" Android interface is mostly driven by buttons"

That's what I kept thinking while watching the video. Blackberry and Blackberry Pearl were all about pushing or selecting things using a rocker or ball, and that's what's shown in this video for making selections.

What the iPhone changed was direct interaction, making the OS interact and respond the way the spinning globe does in this video.

</comment></comment><comment><USER17> Anyone notice that Sergey uses the word "Apps" in the video. I find it incredible when people claim that Apple introduced the word App, and therefore the trademark "App Store" is valid. So glad that was squared away during the Amazon suit.

<comment><USER8> The term applications or apps is used on OS X too. And for a very long time.

<comment><USER14> I recall referring to 'apps' when discussing MacPaint and Hypercard in the late 80s. Apple have used the 'apps' term for many years.

<comment><USER18> It's actually a much older term than that.

[http://www.osnews.com/story/24882/The_History_of_App_and_the...](http://www.osnews.com/story/24882/The_History_of_App_and_the_Demise_of_the_Programmer)

[disclaimer: I'm the author of both the parent article as well as the article linked to in this comment]

<comment><USER14> I'm sure it is, I wasn't suggesting otherwise; just concurring with the poster I replied to that Apple have used the term for a long time and that they certainly used the term long before OS X was released.

Programmer, by the way, referred to their wares as 'software' and 'programs' (hence the nomenclature), not just apps. Your observation that "marketing and legal" call the shots is trite. And wrong. The issue, as with everything, is accountants and money men.

</comment></comment></comment></comment></comment><comment><USER19> The point I'd make is that you _still_ get BlackBerry style android phones, and crazy folding ones and many other form factors.

If you only compare a single blackberry-style phone from the pre-iPhone era and one slab phone (which doesn't look particularly iPhoney-except in relation to the hardware keyboard phone) then you'll make a good rhetorical point for people who already believe that Android is an iPhone clone. I don't know if you'll convince anyone else.

There was a similar, older comparison which resized the phones and kept hardware keyboards shut, which again, seems a bit disingenuous if the point is to show similarity.

</comment><comment><USER11> Also, what about Microsoft surface, which had some multitouch concepts, and had been talked up for years before the iPhone.

</comment><comment><USER20> TL;DR fanboy bullshit.

<comment><USER14> From which point of view?

<comment><USER20> It looks like Android, but that's not my point. My point is that only fanboys care about a discussion of whether or not Android looks like X, or if Apple copied Y, etc.

I think productive people who actually create things that people use have better things to do than fight these wars so I flagged it -- HN is supposed to be for such people, and so why do we have fanboy ammo on the front page?</comment></comment></comment>


Point your mobile website to this url for Mobile Browser Test - <AUTHOR> http://rng.io/ It tests for Mobile Website and would be released to the open source community soon. Developed by Facebook Engineers: https://developers.facebook.com/html5/blog/post/2012/02/27/announcing-ringmark--a-mobile-browser-test-suite/ <comment><AUTHOR> [https://developers.facebook.com/html5/blog/post/2012/02/27/a...](https://developers.facebook.com/html5/blog/post/2012/02/27/announcing- ringmark--a-mobile-browser-test-suite/)</comment>


3D WebGL Nyan Cat - <AUTHOR> http://dl.dropbox.com/u/6213850/WebGL/nyanCat/nyan.html

<comment><USER2> Former discussion: <https://news.ycombinator.com/item?id=3438513>

<comment><AUTHOR> Thanks. I did do a Google search prior to posting, but didn't see anything.

</comment></comment><comment><USER3> Funny example, but there is something about most three.js examples that bugs me, mostly the way in which they use the mouse position to move the camera. It sometimes makes it really hard to control the demo.

</comment><comment><AUTHOR> This may be old, not sure, but it's still great!

</comment><comment><USER4> test

<comment><AUTHOR> Mmm, yep, that test worked! :P</comment></comment>


Automating Drug Discoveries Using Computer Vision - <AUTHOR> https://ai.googleblog.com/2018/07/automating-drug-discoveries-using.html <comment><USER2> Protein crystallization also considered as a potential driver for building low-earth orbit labs and factories. It is conjectured that microgravity environments are more hospitable to the energetics of macromolecular long range ordering. Big Pharma as well possesses the capital intensive resources to fund these missions. And with re-usable rockets breaking the $10M per launch threshold, now may be an ideal time to pursue a 100% automated, space- based protein re-crystallization facility.

<comment><USER3> Big Pharma and NASA have already been teaming up on micro-gravity protein crystallization projects for several years now. When I was interning at Merck I attended a lecture by a staff scientist, Paul Reichert, who is doing this exact type of work in collaboration with NASA [0]. He has already had several successful missions. It's a very interesting field with a lot of potential.

[0]: [https://www.nasa.gov/mission_pages/station/research/experime...](https://www.nasa.gov/mission_pages/station/research/experiments/1320.html)</comment></comment>


The Rule of Silence (2006) - <AUTHOR> http://www.linfo.org/rule_of_silence.html <comment><USER2> To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text.

If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer.

This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other exotic ways of dealing with the problem.

Oh you don't like that output? Easy! pipe that crap into sed then awk then perl then cut then wc and you're golden!

When you get tot that point you have to understand that you have chosen to ignore the fact that the data you are dealing with must be represented in something much closer to a relational database than lines of ASCII text.

Logging is another area you see the consequences of this. A log is not a line of text. Repeat after me a log entry is not a damn line of text.

"Oh but isn't it neat you can pipe it to grep?" NO! No it's not neat, maybe it was neat 20 years ago. Today I want that damn data in a structure. Then you can still print it out in one line and pipe it to grep all you want.

Another area that you see the unfortunate side effects of this philosophy is with the mess of file-based software configuration.

Yes I get it, you like your SSH session and Emacs/Vim blah blah but that's short-sighted.

I want my software configuration stored in a database not in a bunch of fragile files with made up syntax that are always one typo or syntax error away from being potentially silently ignored.

The fetish for easily-editable ASCII files and escaping from structure is holding us back. Structured data does not automatically imply hidden and inaccessible, that's a matter of developing appropriate tooling.

<comment><USER3> In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy".

All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes.

I guess most developers on HN are also aware of the downsides of this philosophy. If not, try configuring IIS.

<comment><USER4> Surely you can reconcile structured representations and something like the Unix command line.

Imagine if the default wasn't bash, but something like Ruby + pipes (or some other terse language).

What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because _every single interaction_ between shell scripts has to include its own parser. How many versions of " get file created timestamp from ls" do we need?

Something Windows does get right is the clipboard. You place a thing on the clipboard, and when you paste, the receiving program can decide on the best representation. This is why copy-pasting images has worked so magically.

I could see an alternative system where such a mechanism exists for shell programs.

<comment><USER5> _> What is the argument for shell scripts not working on typed objects?_

Typed objects can make it harder to pipe commands together. How do you grep a tree when tree is an actual data structure and grep expects a list of items as input? You would need to have converters. Either specific converter between tree and list, or a generic one: tree->text->list.

 _> Something Windows does get right is the clipboard._

It useful, but the actual implementation is pretty bad. Opaque, prone to security issues, holds only single item, cannot be automated.

<comment><USER6> > Typed objects can make it harder to pipe commands together. How do you grep > a tree when tree is an actual data structure and grep expects a list of > items as input? You would need to have converters. Either specific converter > between tree and list, or a generic one: tree->text->list.

To be fair, untyped objects also require converters, but at _every_ boundary. That is, instead of having some pipes of the form `program -> mutually agreeable data structure -> program` and some pipes of the form `program -> unacceptable data structure -> parser -> program` (as happens with a typed language), you are guaranteed by a text-based interface _always_ to have pipes of the form `program -> deparser -> text -> parser -> program`.

</comment></comment></comment></comment></comment><comment><USER7> Note that the "rule of silence" (combined with the habit of writing documentation like longform essays) is also one factor that makes unix-like systems newbie-unfriendly. (Famous example: trying to exit vi)

I think the rule makes sense within the specific constraints *nix programs are usually expected to work in (two output channels with no structure except the one informally defined by the program and the convention that the output should be human- and machine-readable at the same time) but I don't see it as a general rule if better ways to filter the output are available.

<comment><USER8> _> Famous example: trying to exit vi_

To be fair, this has been fixed a long time ago. At least Vim (which is the Vi installed on most systems) shows the following message on startup:

      ~                     VIM - Vi IMproved
      ~
      ~                      version 7.4.1829
      ~                  by Bram Moolenaar et al.
      ~                          [...]
      ~        Vim is open source and freely distributable
      ~
      ~               Help poor children in Uganda!
      ~       type  :help iccf<Enter>       for information
      ~
      ~       type  :q<Enter>               to exit
      ~       type  :help<Enter>  or  <F1>  for on-line help
      ~       type  :help version7<Enter>   for version info

On the other hand, it doesn't show this message when you call "vi" with a filename. But at least a beginner running "vi" for the first time should be taken care by this.

<comment><USER9> Someone unfamiliar might just be dumped into vi because some other program thought it'd be great to open a text editor, e.g. for a commit message. You're unlikely to run vi intentionally unless you also know you want to run vi and how to exit, I guess.

<comment><USER10> Programs that put you into Vi, /should/ be calling $EDITOR, if $EDITOR is to to Vi(m), you should know how to use it.

Also, if you ^C in Vi, you get the message:

      Type  :quit<Enter>  to exit Vim

<comment><USER11> And what if $EDITOR is not set ? Vi is the standard POSIX editor, calling it makes sense.

<comment><USER12> Actually, defaulting from $VISUAL to vi and from $EDITOR to ex (or ed) is what -- strictly speaking -- makes sense.

Remember what the difference between $VISUAL and $EDITOR was intended to be. There's a whole range of places in Unix where there was, and even still is, a distinction between a _line editor_ and a _full screen editor_. Consider, for just one example, the ~v and ~e commands in BSD Mail.

Now enjoy the discussion at [https://news.ycombinator.com/item?id=13113556](https://news.ycombinator.com/item?id=13113556) .

</comment></comment></comment></comment></comment></comment><comment><USER13> Having debugged Linux kernel and userspace programs extensively, I'd say this rule is golden. Typical user don't need logs, unless something is really f*cked up. On the other hand, if you are running production or development machine, you can enable as many log messages as you want as most of it can be turned on via /proc/sys/kernel/printk (kernel messages), program parameters or writing your own specific messages in code if that's not enough. Actually, I more often encounter the opposite problem -- there are so many log messages, that it's hard to find a specific problem among them.

<comment><USER8> _> there are so many log messages, that it's hard to find a specific problem among them._

This is exactly my experience, too.

Some programs get this even worse: They spam you with lots of useless information, yet when something goes wrong, you don't get the information you need. Instead, you have to rerun it to increase the verbosity even more.

So ... if I have to rerun and having a hard time trying to reproduce the issue anyway, why did it spam me in the first place?

</comment></comment><comment><USER14> This is a part of the unix philosphy I often forget, but agree with just as much as the rest.

As an example: I love curl for piping the data to stdout per default, but I'm frequently annoyed by the progress bars I didn't ask for, especially if a script involves multiple curl commands.

<comment><USER15> Seconded. Though curl isn't the worst offender in that regard. Anything that touches TeX drives me nuts with its blatant disregard for this rule. Not only does every TeX engine spew pages of output while processing even the simplest documents, but there is no way to turn it off. (It's hardly the only way in which TeX makes my blood boil, but it's the most visible one.)

FFmpeg is also quite bad here, but at least you can use -hide_banner and/or -loglevel to alias the problem away and mostly forget about it.

<comment><USER16> Combined with the fact that they also spew out a number of files that you don't want, because it isn't capable of traversing the source more than once.

</comment></comment></comment><comment><USER17> Spolsky addressed this cultural difference between the Windows and Unix world in 2003: [https://www.joelonsoftware.com/2003/12/14/biculturalism/](https://www.joelonsoftware.com/2003/12/14/biculturalism/)

At its core, it is about putting humans before computers. Engelbart coined HCI as Human Computer Interface, not CHI. This philosophy steered my product designs ever since I read that as a teenager.

</comment><comment><USER18> Honestly, I don't know if the rule of silence is actually all that good of an idea. Unix already gives us stdout vs stderr; it's one thing not to write useless information to stdout, but it could be useful to have a stdinfo or stdlog or what-have-you.

Granted, with too many options it could quickly get confusing (should this message go to stdout or stdinfo; is that message more informational or more debugging?), but I think that it could be managed.

Similarly, I think that Unix fell down by relying too much on unstructured text (in the sense that the structure isn't enforced, not in the sense that it's altogether absent): because of this, every single tool rolls its own format, and even very similar formats may have subtle incompatibilities.

I'd love to see a successor OS which builds on the lessons of Unix, Plan 9 and other conceptually brilliant OSes, but I fear the world will never see another successful operating system.

<comment><USER19> > Similarly, I think that Unix fell down by relying too much on unstructured > text

This is what made Unix last. Text and keyboards are the universal computing interface that has survived since the 1970s.

<comment><USER18> Note that I'm not arguing for structured binary data. Structured text (e.g. s-expressions, JSON, even the-extensible-structured-text-format-which-shall- not-be-named) can last just as long. Indeed, S-expressions have existed since the 1950s.

There's no particular reason why /etc/passwd couldn't be:

        ((root nil 0 0 root /root /bin/bash)
         (daemon nil 1 1 daemon /usr/sbin /usr/sbin/nologin) …)

There are any number of similar dialects which could be used, of course, but the principle is obvious.

<comment><USER20> What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

Though I do agree with your overarching point that some of the formats/outputs could do with a more consistent structure. Perhaps something like YAML would strike a good balance between structure and conciseness/readability...

<comment><USER21> > What would your example achieve? You're making the format more verbose and > error-prone (someone might easily forget to match a paren), without > imposting any additional structure over what is already implied by line > breaks.

That particular example is fairly straightforward (at a simple level, passwd files aren't complex), but being able to express arbitrary nested structure would make various things a lot more straightforward. Line breaks and some sort of tab/colon/what have you work fine if everything has at most two levels of hierarchy, but it starts being painful after that.

Missing matched parens are a bit of a specious argument, since many of the random formats for files are fairly strict about what they parse, and the ones that matter (e.g. passwd, sudoers, crontab) are conventionally edited through tools that check the syntax before committing.

<comment><USER22> Maybe you shouldn't use arbitrary nested structures where you can go without?

</comment></comment></comment></comment></comment></comment><comment><USER23> One consequence of "the rule of silence" is that sometimes it is not obvious if a command is processing data or waiting for input, there is no visual difference.

<comment><USER24> That's more an occasional annoyance than a real problem though. The only commands that don't prompt when waiting for input are commands that are written specifically for stream processing from stdin. In which case the user should already be aware of it's behaviour because they're either already familiar with the command or have have consulted it's man page (or similar reference) before executing it. So the unprompted waiting for using input is a bug in a shell script / command line pipe and thus usually pretty quick to debug.

Going back to the man page point: I will granted you that not everyone does check what a program does before running it. Sadly in those instances there's little you can do to protect them from themselves. It's similar to how you cannot protect people from blindly copying and pasting code from the internet. If someone is willing to run a command "blind" then the usefulness of the output is the least of their worries.

<comment><USER23> I was more thinking of a situation where you have misunderstood the syntax of a command or forgot to type an argument.

<comment><USER24> I did cover that point. :)

</comment></comment></comment></comment><comment><USER25> "Rule of Silence" sounds so dark. Nope, I'll stick with "no news is good news".

<comment><USER26> I think it fits well into the whole monastery style type of UNIX philosophy.

</comment></comment><comment><USER27> > There is no single, standardized statement of the Unix philosophy

They could at least link to tAoUP[1].

[1] [http://www.catb.org/esr/writings/taoup/html/ch01s06.html](http://www.catb.org/esr/writings/taoup/html/ch01s06.html)

</comment><comment><USER28> I love this rule, as it is the opposite of what modern computing does. When i plug something into a Windows PC i get a multitude of beeps and popups saying it did everything right. But if something goes wrong there is a eerie silence and i have to dig into the error hex dumps to hope i find anything useful at all (or just reboot and hope it works right on second try).

</comment><comment><USER29> I wish _people_ would live by this rule more often.

<comment><USER30> Have you ever tried to talk to a person who gives _absolutely no nonverbal cues_ as to whether or not they're listening to you? It's infuriating.

Acks are important.

<comment><USER31> Yes I have. It's very common in some Eastern European countries, where the words stand on their own without embellishment. Jokes come with no intonation- based warnings. Similarily, listening is presumed and doesn't come with colorful Southern European–style cues.

It's not infuriating, it's just different.

<comment><USER30> What's infuriating is when seven times out of ten, you eventually say "hey are you listening?" and they respond that of _course_ they're listening, whyever wouldn't you think so? And the other three times out of ten they're actually not listening and they haven't heard a word you've said for the past few minutes, and you have to either repeat yourself or just stop trying to talk to the person.

</comment></comment></comment></comment><comment><USER32> Unfortunately, in too many cases, a lot of Unix network tools also abide by the Rule of Silence when they should be giving meaningful error messages instead.

</comment><comment><USER33> See also the following relevant chapters of _The Art of Unix Programming_ :

[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id...](http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878450)

[http://www.catb.org/~esr/writings/taoup/html/ch11s09.html](http://www.catb.org/~esr/writings/taoup/html/ch11s09.html)

</comment><comment><USER34> The Unix philosophy of small, modular processes feels right to me, as a user and a coder.

However the business and product developer in me wonders how I apply this to building more complex systems. Normally this involves building multiple functionalities. Does the philosophy say I shouldn't build "systems" that are complex and do multiple things? Or does it talk about how these should be implemented, as co-operating processes?

<comment><USER35> The 'do one small thing and do it well' philosophy is at least contentious in the general sense.

Reality: no unit exists outside the context of it's ecosystem.

Ergo, the API to that unit, and the degree to which it integrates with the other pieces is paramount.

The 'do one thing and do it well' ideal implies almost a kind of 'unit sovereignty' that in many cases does not exist.

In large, complex systems, 'units' can only view as parts of a greater whole.

'What they do' is almost less important than 'how well they fit'.

</comment></comment><comment><USER36> I appreciate the overall message the article is trying to communicate "Silence is golden, in many contexts for many reasons - be considerate before you make noise", but, as an aside, the third reason, "command line programs", should include the a reference to stderr keeping things out of view of your pipe and doing a good job of making sure you don't clutter your command pipes.

</comment><comment><USER37> I wish I could find that old thing about ordering a burger at the Unix restaurant, where the clerk keeps giving you cryptic responses when you order wrong and then, when you do successfully order, says nothing, leaving you wondering whether your order has been accepted or not.

<comment><USER38> Probably this:

[http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.h...](http://xahlee.info/UnixResource_dir/_fastfood_dir/fastfood.html)

I hadn't heard of it until now. Thanks for the good read!

<comment><USER37> That's the one.

</comment></comment></comment><comment><USER39> Can help falling in love with the irony that most smartphones have an underlying unix version with mostly an oposite philosophy

<comment><USER40> No irony there.

</comment></comment><comment><USER41> I think using the word 'philosophy' is like antimarketing. People have a kneejerk reaction to the word as something unchanging and stuck in the past and it lends itself easily to negative connotations.

Take an example. Build small components that can be reused. Its like SOA way before SOA came into use and makes perfect sense. Now criticizing that is much more difficult and will require technical depth than just dimissive comments about 'unix philosophy'.

In this case this is the first I've heard of a 'philosophy' of silence and it is often not golden. From a technical perspective its important for users to get feedback and not generic unhelpful error messages or commands disappearing. Fortunately on Linux logging is usually quite good and most experienced users can pinpoint errors quite quickly but options like -v, --v, -vv, -vvv far from helping often increase technical load.

</comment><comment><USER42> I always liked how MacOS loads silently without annoying the user even when it does some "hard" stuff like fsck.

Generally I think engineers need to fight the temptation to show off the importance and complexity of their software by spitting out all the unnecessary details and logs.

<comment><USER43> One way to completely break a Mac user out of their comfort zone is to switch the machine into verbose boot mode (sudo nvram boot-args=-v). Makes it look like old Slackware.

</comment></comment><comment><USER44> As with any rule it has good and bad consequences:

* good: easy to parse the result, easy to chain.

* bad: no progress report, annoying with long duration commands.

<comment><USER45> If your command is ongoing, you can argue that the time it is taking is in itself surprising.

You expect it to finish at any time. It continuing is the surprise. A marker for its progression is thus, IMO well within the range of respecting this philosophy.

</comment></comment><comment><USER46> It's often a stupid rule. If you have a process that is stuck, you type "kill <pid>" to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps <pid>" to see if it is still alive. If it is, you try again with "kill -9 <pid>".

I suspect the reason is that for most signals, kill can't determine if the signal was acted upon or not. But for KILL and TERM it could wait a few milliseconds and then print if the process is still alive or not.

Edit: those who are saying that I can write a wrapper script is missing the point. The point of computers is to be useful to their users, not to follow some philosophy people invented almost 50 years ago. Like if someone is bothered by kill showing messages, _they_ can write a wrapper script (kill > /dev/null how hard is that?) or beg the developers to add a -q option to kill (like grep has) or write a new tool for sending signals.

Also, the program is called KILL so one could be forgiven for assuming it's main purpose is to KILL things...

<comment><USER47> > It's often a stupid rule.

By the way, I haven't down-voted you, but I think I understand why others did. Before calling stupid a pillar of a (programming) philosophy with decades of useful outcomes, you should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance.

<comment><USER48> I think it's great that someone is questioning the way things have always been done, even it's just by calling it stupid. The hard part is coming up with something better. Unix at its core is still a product of the computing environment of the early 1970s. Not only that, it was a reaction to the complexity of Multics. What gave Unix an advantage at the time was how relatively easy it was to port to other architectures and how few resources it required. Universities and businesses could run it on cheap $50,000 minicomputers. It eventually outgrew a lot of its origins, but still. The rule of silence makes the most sense on a slow terminal or a teletype. Verbosity is wasteful and time-consuming in that environment.

<comment><USER49> Verbosity is wasteful and time-consuming in today's environment as well.

Most people on HN are developers and not as fluent as system engineers in shells and UNIX tools. The need for minimalist, "silent" UIs comes with fluency. This is also true for network engineers and database administrators.

<comment><USER47> > The need for minimalist, "silent" UIs comes with fluency.

No, it comes from wanting to reuse the tool!

Would you like your browser to open plenty of pop-ups with messages like _" Congratulations! The font XYZ was successfully loaded from C:\foo\bar"_ or _" That's incredible! I looked for a JPEG on server www.qqq.com ... and it was there!"_? No, you wouldn't. And I wouldn't like "mv" to babble every time it renames a file on the hard disk.

</comment></comment></comment></comment></comment><comment><USER50> I think this article gives good perspective regarding User Exp of system. Windows is made for much wider audience whereas UNIX is used by skilled people. I think its inappropriate to compare both philosophies with regards to this article.

</comment><comment><USER51> love this article. the past paragraph is great - i often claim that stores do their best to drive me away by playing horrible music and making sure i am as annoyed as possible with no hope of being able to focus on purchasing something.

</comment><comment><USER52> It's not some specific "rule of science" , it's basically occam's razor

</comment><comment><USER53> Simplicity is always a virtue.

</comment><comment><USER54> It is refreshing to see no author name attributed to the text.

</comment><comment><USER55> don't forget about the "rule of repair" :p

</comment><comment><USER56> [ ... ]

</comment><comment><USER57> Similar to this rule is POLA - the Principle of Least Astonishment. The idea is that if you ask a tool to do something, it should generally do just that and nothing else. If you were to run a tool without args or config, then it shouldn't do something unexpected.

Even if nothing else, this rule/principle/whatever is my favourite by name :)

[https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)

</comment><comment><USER58> May as well be called the rule of gratuitously hostile user experience.

<comment><USER47> It's clear you don't know what you are talking about.

\- _Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who it decides to make friends with._

</comment></comment><comment><USER59> This page looks very nice</comment>


Pharo Open Source Smalltalk Release 1.0 - <AUTHOR> http://pharo-project.org/pharo-download/release-1-0 <comment><USER2> I've made some projects with Squeak in the past.

This Pharo image seems really clean. And the tutorial is a very nice addition.

My only disappointment with Squeak is that all the multimedia related stuff was really outdated and the performance was poor.

I've been subscribed to the mailing list for a while and it seemed to me that very few people were concerned with this. All the development was focused on developer tools.

There was a guy (couldn't remember his name/website) who was working on really interesting graphical stuff. He was rewriting the Morphic gui from scratch. I hope his work will be eventually merged with Pharo. EDIT: found it: <http://www.jvuletich.org/Morphic3/Index.html>

With strong and updated multimedia capabilities this could become a modern HyperCard.

<comment><USER3> Juan forked is own version of Squeak call Cuis, <http://www.jvuletich.org/Cuis/Index.html>

</comment></comment><comment><USER4> I now only use Smalltalk a few hours a month but I have switched over completely to using Pharo instead of Squeak or VW (non commercial version). Pharo really is cleanly laid out and nice to use if you are (like me) a very much part-time Smalltalker. The Pharo book is very good, BTW.

</comment><comment><USER5> I built a seaside app on Squeak last year and ported it to Pharo in October. So far I've liked Seaside a lot better than Rails, and Pharo a lot better than Squeak. Pharo is a nice, clean smalltalk with a professional UI useful for the developer. We've even started selling the app. on a very small scale and have had great feedback on the flexibility we gained by using a Smalltalk, Seaside, and an object database

<comment><AUTHOR> Would you mind sharing a link to the app? Many of us haven't had a chance to see many Seaside apps out in the wild. I think DabbleDB and Auctomatic are Seaside apps, but other than that I can't think of any.

<comment><USER3> Go to kayak.com, search for a hotel somewhere, find a rate from Reserve Travel and visit it; that's a seaside app.

</comment></comment></comment><comment><USER6> I plan on migrating some Fat client apps to Pharo in the next 2 years as Sessile web apps.

<comment><USER5> You can actually build fat-client apps with just Pharo too. The only downside is it doesn't support OS native widgets or windows (its all inside one window).

<comment><USER7> Hopefully the wxSqueak project is still ongoing.

</comment></comment></comment><comment><USER8> Has anyone managed to get the whisker/stacked editor/browser working in pharo?</comment>


We need a better alternative to Web(& Electron) apps - <AUTHOR> https://firstname.lastname@example.com/we-need-a-better-alternative-to-web-electron-apps-1853ea32e8db <comment><USER2> Blame desktop OS vendors for insisting on parallel universes instead of getting together and coming up with a standard API. We have standard APIs for everything but UIs it seems.

Even huge companies find it prohibitive to develop an app two or three times. For smaller companies and indie vendors its unthinkable.

<comment><AUTHOR> The same is also true for mobile platforms, but we have pretty good cross platform frameworks for them. Flutter, Xamarin and React Native all have experimental support for Desktop operating systems and as they mature I expect more apps to be built for Desktop with them.

The only problem is that since they can't run inside of the browser, they'd need to be installed before they can be run. While this might turn out to be a better alternative to Electron, it really can't beat the convenience of an URL.

<comment><USER2> Nor can it beat the resource efficiency and unified platform look and feel that would be offered if platforms supported some kind of common GUI API...

Honestly I'm not a fan of any of the things you mentioned because they're so fat. They insist on making you build the UI within this humungous runtime that also usually forces you to use specific languages and tooling. These also (with the partial exception of React Native) do all their own rendering, so the user's machine now had to run a million parallel rendering engines.

GUI programming in 2020 is a fucking disaster.

</comment></comment></comment><comment><USER3> I recently discovered the Rust webview crate (library/framework). It makes use of libwebkit to render HTML strings and you can get your Rust app notified of clicks (or events in general?) in the DOM. This might be a cool idea for cross plattform GUI on desktop development, which follows some standard of HTML and CSS and probably JS.</comment>


Postmates is hiring generalist hackers - <AUTHOR> http://www.postmates.com/jobs/engineer

<comment><AUTHOR> We're obsessed with our product and customer service, we have a beautiful iPhone app, great advisors and amazing hackers in our team. Now we like to get to know you, so that we can grow together. ;)</comment>


Many People Wear Shoes That Don't Fit Right (2014) - <AUTHOR> https://www.wsj.com/articles/feet-are-getting-bigger-and-many-people-wear-shoes-that-dont-fit-right-1405466145 <comment><USER2> I think this might also be a problem of the fitting system. Using one of those foot measurement devices I'm supposed to be a 13 AA, which is laughably narrow. My actual size is a 13 wide. Now whether that's E or EE on the Internet is a different question. The sizing system needs a major overhaul.

<comment><AUTHOR> What if I told you that we are working on it. ;-)

<comment><USER2> I would reply: "please kind soul tell me more!!!"

<comment><AUTHOR> Fill in this form to get on the list: [https://atoms.typeform.com/to/vi9vxv](https://atoms.typeform.com/to/vi9vxv)</comment></comment></comment></comment>


Why am I not in full control as a cellular user? - <AUTHOR> http://kumarfeels.wordpress.com/2010/08/09/why-am-i-not-in-full-control-as-a-cellular-user/

<comment><USER4> I agree, I think control is something the user should have rather than the provider supplying the solution.

Technologically speaking, implementing something like this is pretty simple.But it will cost the provider money rather than make money - <USER2> makes this investment pointless (No company will invest money to loose even more....).

I currently own a N900 and i have an app to block calls (currently blacklist only) i think - though i am not familiar with the N900 incoming call API - <USER3> should be rather simple to implement a whitelist instead.

And i pretty sure the same goes for SMS etc...

But frankly i don't really want that kind of blocking, i would prefer blocking numbers of known spammers (which i have a list of) while occasionally letting one pass through the filter, rather than miss even one important call which could change my life (And it happens every day doesn't it?)

</comment><comment><USER5> This just outlines another spot where having a sufficiently open operating system on your mobile does make a lot of sense. In android, I could implement my own SMS application (maybe even just base it on the existing stock one if that's open source - I don't know).

This clone would only use the existing notification framework if the sender is in my address book.

Then I would just disable the built-in SMS application.

Of course this isn't as good as blocking the SMS on the provider level, but on the other hand it provides more granularity than a wholesale SMS block would provide.

<comment><USER6> He has a n900, one of the most "open" phones there is. If he had a "normal" Nokia with DRM, he'd probably be able to download that app mentioned in the comments.

<comment><AUTHOR> :) That's funny, but I guess I can find or develop something myself to block it on phone level.

</comment></comment></comment><comment><USER7> Most spam I get comes from my provider anyway, and I imagine that even if they did add something along these lines they would make their own messages get through regardless.

</comment><comment><USER8> My fear would be something like a friend or family member being in some emergency situation where they have lost their phone and need to reach me on someone else's phone but I never see the call/text. There's a danger in micro- managing your life without fully thinking about all the ramifications. This is why in my opinion it's better to just deal with the 1-2 seconds of annoyance to dismiss a spam call/text. It's not the end of the world. A child/SO/friend/family/co-worker not being able to reach you in an emergency is much worse.

<comment><USER9> There's always the middle ground:

If the number is blocked - a truly unknown number - send them to voicemail. Most marketers won't leave a voicemail - they'll just hang up.

I voicemail-screen every call I get from numbers that aren't in my address book. 99/100 times, blocked number calls don't even leave a voicemail.

<comment><AUTHOR> Sounds good

</comment></comment></comment><comment><USER10> <https://code.google.com/p/android/issues/detail?id=5900#c0>

I put this issue into Android some time ago. Google's probably in a position to make some change here, and carriers should be ramping up to deal with mobile spam.

</comment><comment><USER11> <http://i.imgur.com/uB7UI.jpg>

</comment><comment><USER12> tl;dr: there are no spam filters at (some?) SMS providers, and (apparently) no incentives and no mechanisms for SMS providers to filter unwanted traffic. For spamming or harassment or whatever the sender might want, based on the OP.

The poster will want to chat with the regulatory entities that have oversight of the SMS provider and over consumers. Given the reference to the (US?) DNC, that discussion would involve the US FCC, as well as the state-level commissions.</comment>


We Should Teach Music History Backwards - <AUTHOR> https://www.smithsonianmag.com/arts-culture/why-we-should-teach-music-history-backwards-180955053/?no-ist <comment><USER3> Not just music history, but history in general.

History told forwards is superstition: trying to show that what came after was inevitable, when in fact it was one future among an infinite number of different possible futures.

History told backwards makes sense: look for the seeds of post events, in the past.

However the human mind loves nothing more than causation; we see cause and effect everywhere even where it's not, we like "stories", we don't understand, don't believe in, and outright reject chance.

<comment><USER4> There was a great essay a while back that I can no longer find that summarized Guns, Germs, and Steel by continually asking the question "why?" It start with "Why is Western Europe and America so dominant culturally and economically?" Then regressed back to questions like "why did Europeans colonize the Americas instead of the other way around" to "why did the Europeans have steel, disease, and gunpowder but the Native Americans didn't?" down to "Why did agriculture develop in the fertile crescent and spread to Europe earlier than corn spread to the Americas?"

It's a wonderful rhetorical device. Human nature is to pay attention to conflict and we like to see how it's resolved. By asking a series of "why" you broadly expand a person's view and they understand why you're talking about, at some point, the minutia of zoological diversity in the middle east. I never did well in school because I always want to know the "why are we talking about this" up front, and teacher's answers were always just "it's in the syllabus." I like programming because it asks the problem first, then I have to solve it.

<comment><USER5> The problem with that approach is that you can end up begging the question and not realizing that your proposed answers start to deviate wildly from evidence.

For Jared Diamond, the answer to the question of European domination is solely that Eurasia won the agricultural jackpot [1] and the Americas lost it, and anything that happened in the intervening 10,000 years doesn't factor into it. But... the Americas won the agricultural jackpot (there's a reason why potatoes became a staple crop in much of the world). And the European conquest of the Americas was anything but preordained: the Spanish only conquered Tenochtitlan (which was a larger city, it should be noted, than likely any of the Spanish had ever seen before) with the help of their 20,000 Tlaxcala allies.

[1] The astute will notice that there's a related question that Diamond 100% completely ignores... why didn't China dominate?

<comment><USER6> > For Jared Diamond, the answer to the question of European domination is > solely that Eurasia won the agricultural jackpot

This is oversimplified to the point of either being disingenuous or misinformed, and China was discussed in the book. There are valid issues with the work, including environmental determinism[1], but it was a wide ranging pop sci book and as such has many surfaces and incentives for attack.

[1]: [https://en.wikipedia.org/wiki/Environmental_determinism](https://en.wikipedia.org/wiki/Environmental_determinism)

<comment><USER7> > _including environmental determinism[1]_

Why is this considered an issue? Is there a good discussion of this that you could recommend?

<comment><USER8> [https://www.livinganthropologically.com/archaeology/guns- ger...](https://www.livinganthropologically.com/archaeology/guns-germs-and- steel-jared-diamond/)

      I argue that although Diamond makes interesting points,
      his work from Guns Germs and Steel to Collapse is a
      distorting disservice to the real historical record.
      Diamond claims that the differential success of the
      world's nations is due to the accidents of agriculture,
      except when societies "choose to fail." This claim does
      not withstand scrutiny. [...] Unfortunately his
      story-telling abilities are so compelling that he has
      seduced a generation of college-educated readers.

</comment></comment></comment></comment></comment></comment><comment><USER9> I'm going to disagree with everyone! You should learn history — or any subject — by starting with the things that interest you and working outward from there. Studied that way, nothing is dry, because your motivation to learn stems from what you're passionate about. For example, I learned 20th-century world history based on its relation to aviation, and in the process gained a real, abiding interest in history; I learned medieval history based on my interests in the music and religion of the time. I'm weak in the Enlightenment, but I'm sure I'll get there. I strongly recommend this approach, not because it is systematic or comprehensive, but because it encourages you to _actually learn_ , not just bone up for tests.

Being old and curmudgeonly is fun, too.

<comment><USER10> This is the best answer, but it raises a difficult question, which is what do you do with a classroom of thirty students?

<comment><USER9> I don't have the slightest idea — that's why I teach my own kids.

<comment><USER10> Which is a great answer too, though our modern life puts it out of reach for most.

</comment></comment></comment></comment><comment><USER11> > We don't start our investigations at some arbitrarily chosen point in the > past; we begin where we are, from our current burning passion.

That reveals a problem with learning backwards-- rampant epicism in which students would rarely choose to learn about, say, dead ideas like sonata form.

Rather than requiring the student to learn linearly through time, the professor ought to select a handful of musical periods and/or case studies and then randomize the order in which they are taught. Make a big spectacle of picking numbered ping pong balls from a bingo machine in the lecture hall. In the U.S. these are usually elective classes so they are essentially an institutional form of entertainment, anyway.

In other words-- it shouldn't matter how you pick a period/style/composer. What should matter is that students improve their ability to use their ears and their growing knowledge to investigate any music, no matter its origin or time period.

Publicly using randomness to select from possible periods/cases would show good faith that the professor is skilled enough to leave the chosen topic up to fate. That would make it harder for profs who aren't fully comfortable with all the material, which is probably why nobody teaches this way. :)

Edit: clarification

</comment><comment><USER12> I disagree whole heartedly. This will end up putting an overemphasis on contemporary work, and not enough on classic works. Think about how often cirriculum never gets to the end of, when such seminal and formative composers such as Bach are fit into the last weeks you will inevietably gloss over them. We already make Gods out of our contemporary world view at the expense of downplaying the brilliance of past thinkers. I dont think we need to fan this flame. We will end up with an aesthetic that is so devoid of the basics that it barely comprehends itself, and if ever hits a dry spell will never be able to recreate its former greatness. The net effect will be to gradually turn our backs on the collective insights of the greats of the past

<comment><USER13> Why is it _always_ Bach? Every single time I hear the entirety of recorded music's history being dissected, Bach is the first - often the only - <USER2> brought to attention. Have this many people subjectively decided for themselves that Bach deserves this credit? Or do schools of music have a habit of teaching that Bach is objectively the best, as if it's a fact grounded in science?

Bach is to music as Shakespeare is to literature - if you don't nod your head in agreement like a brainwashed zombie when either of these men are stated to be the best in their respective fields, you're automatically dismissed by the crowd of "elitist snobs", for lack of a better redundant phrasing.

I don't side with contemporary works either. The current era (90s+) is so disgustingly cookie-cutter, superficially manufactured by record labels to shovel down our throats in bulk. The 50s through the 80s fared somewhat better; the studios still heavily controlled every aspect of the artists they signed, again following an (as-of-yet unperfected) recipe. At least back then, _some_ of the music managed to weave a story capable of evoking emotion and meaningful thought. I would agree that something has largely been lost over the past century: music no longer being composed, instead being "arranged"(?) to fit specific molds.

tldr; I suppose: a) Fuck record labels; and b) Stop with the "Bach is best" culture.

<comment><USER14> > "Or do schools of music have a habit of teaching that Bach is objectively > the best, as if it's a fact grounded in science?"

I don't think you're entirely accurate on why Bach is such a big name when it comes to classical music. It's not because he is viewed as some objective "best" as you seem to be so convinced of.

Western classical music as we know it today didn't really begin until Bach came around (the only exception that comes to mind immediately is Corelli who came a few decades prior). Music historians today recognize that Bach laid out the technical foundations on what Western music is itself. His development of the counterpoint is a major distinction between medieval music and the classical period that followed. As well, his Partitas for Solo Violin and Well Tempered Clavier for Piano have became and remain to this day, foundational parts of learning and improving violin/piano because they train and benchmark almost every technical ability of their instruments (at least in Western music) to such precision. To analogize to programming, it would be like a set of problems that ranged from basic recursion to debugging memory leaks and everything in between and beyond. There are of course other resources such as Kreutzer's etudes for violin but Bach is one of the first and one of the only to do so to such detail. There are numerous of other music elements such as figured bass and dance forms that Bach contributed heavily to, but I think you get my point.

So to summarize, no, I don't think most music historians "nod their head in agreement like a brainwashed zombie". It's not that they hail Bach as some "objective best", it's because they can recognize and respect the formative effects his work had Western Classical music. He is a father of his field much like Turing of Knuth are and that deserves his praise.

</comment></comment></comment><comment><USER15> "As a great Swiss historian once pointed out in another connection, history is the one subject where you cannot begin at the beginning." \- J. M. Roberts

<comment><USER16> Bill Wurtz tried: [https://www.youtube.com/watch?v=xuCn8ux2gbs](https://www.youtube.com/watch?v=xuCn8ux2gbs)

</comment></comment><comment><USER17> This is part of an enormous cultural trend in the US that has determined that people need to be tricked or somehow otherwise eased into learning, because otherwise learning is too boring! This trend is responding to a real issue, because capitalism has so successfully neutered the common man into a entertainment/carbohydrate consuming machine that the desire or need to learn is only associated with the need to earn an income, if at all.

> We don't start our investigations at some arbitrarily chosen point in the > past; we begin where we are, from our current burning passion.

Who said anything about choosing an _arbitrary_ point in the past? What the author tries to do here is to make the past arbitrary, not interesting, perhaps less relevant than it ought to be. But that's not the problem.

The problem is that this article talks about music history being taught in the first place. In what percent of schools is music history taught in any serious manner by a serious instructor? I honestly am fundamentally perplexed by this article because I would expect first it would establish that music history should be taught in schools at all. Then the author could get into implementation specifics.

But the United States hasn't been interested in music history since Leonard Bernstein's Omnibus[0] lectures aired in the 50s, if it was even then. Today, "Classical Music" isn't for old people anymore, it's for keeping vagrants away from your property[1].

So what the author is really attacking here is the past, because more than ever the past has been deemed too boring on a massive cultural scale. This is just one example of people attempting to make palatable "the past" or whatever else is now too boring, too nerdy or too impossible for regular people to approach.

[0] [https://www.amazon.com/Omnibus-Leonard- Bernstein/dp/B002OVB9...](https://www.amazon.com/Omnibus-Leonard- Bernstein/dp/B002OVB9Z8)

[1] [https://www.washingtonpost.com/lifestyle/style/blasting- moza...](https://www.washingtonpost.com/lifestyle/style/blasting-mozart-to- drive-criminals- away/2011/10/11/gIQAgDqPEQ_story.html?noredirect=on&utm_term=.6e475a06f4cd)

<comment><USER18> >The problem is that this article talks about music history being taught in the first place.

Music history is an elective required for music majors in US liberal arts colleges. For example, at Colorado College[0]: MU150 Music in Western Culture, MU212 Mozart and his Age, MU284 Beethoven, MU285 Music of the Baroque & Classical Eras, MU286 Romantic and Early Modernist Eras. [0] [https://www.coloradocollege.edu/academics/curriculum/catalog...](https://www.coloradocollege.edu/academics/curriculum/catalog/20172018/departmental/music)

<comment><USER17> If your first introduction to music history is in college, that's not a rich cultural upbringing.

</comment></comment></comment><comment><USER19> The author observes that _self-driven_ students of _very selective parts_ of Music History are "driven by emotion rather than obligation" and usually start from a passion for some current music. This seems true enough. The next step, however, is a giant leap:

> shouldn't music history writing and teaching be done in the same backwards > direction?

No, that doesn't follow, because we are now talking about _obligatory_ learning of _the rest of_ Music History, which will be what I just experienced for most of the author's text: An endless litany of names, names, names, names, names, some arrows drawn between them, some dates and places attached.

It doesn't matter which order you teach me _all the rest_ of Music History. It doesn't get better that way, although it probably doesn't get worse, either.

<comment><USER20> Exactly. It seems like this author got really into Sam Smith, did a deep Wikipedia dive, then somehow extrapolated that into a wide-sweeping theory of pedagogy, with bold assertions like "That's how we learn about music: backwards, always backwards."

There are so many counter-examples. I am instantly reminded of a childhood friend who was really into classical music. I don't think he arrived there working all the way back from present. I started listening to The Who because my dad had a CD of theirs in his car, which led to other classic rock. It had nothing to do with a backward time travel from whatever contemporary music I was hearing at the time. I think a lot of music learning happens more serendipitously like that, through friends, random encounters, etc. The historical research is definitely a part of it but this article way overstates it.

<comment><USER21> As someone who learned young to love Charlie Parker, & co., I suspect your friend loved what he grew up listening to at home. Classical music _was_ the contemporary context for your friend, just like your context included the Who.

If you didn't ever go back further than the Who, btw, I'm not sure you 'learned history' in the usual sense of the phrase, and I'm not sure you can teach a history class based on random encounters.

<comment><USER20> I guess I was thinking more along the lines of learning about the diversity of musical styles and cultures than specifically "music history" in a more academic sense. Random encounters can expose you to music you were not familiar with, in a way that a history lesson might not, and then you go and start digging into it.

</comment></comment></comment></comment><comment><USER22> As a terrible programmer my trick is to read statements backwards. Maybe programming should be taught that way too not just reading of it but the history of it all the way back to Charles Babbage, Ada Lovelace and even weaving looms.

<comment><USER23> As a product manager, I have often found it beneficial to write requirements backwards. Start first with the desired result of a feature or flow and work backwards to the necessary steps, options, preconditions, actors, setup/enrollment steps etc. that would have been required required to get there.

<comment><USER24> Personally I have to be careful of this....it's easy for me to focus so much on the solution that the problem is never even clearly articulated to the developers (who may have a better solution that I came up with once they grasp the problem).

I ran across an interesting essay on Medium recently on this topic, advocating a new approach to roadmaps focused on the problems: the problem roadmap. Instead of saying what new features the team will be working on in the future, map out what problems they'll be working on.

</comment></comment></comment><comment><USER25> Wouldn't this limit your study to only musicians that influenced current trends?

I've definitely discovered a lot of music from digging into the influences of groups I like, but this seems like a kind of survivorship bias to only focus on the ones that have direct lineage to what's popular at the moment you're engaging in study.

<comment><USER26> I don't understand how it could be different. There has obviously been way too much music in the past to teach in it's entirety. We have to decide what to teach based on what we currently think is "important". And though we can try to fool ourselves that there is some measure of objective importance, at the end of the day, I'm pretty sure it always boils down to popularity within some milieu.

<comment><USER25> Of course there have to be criteria for any course of study that leaves out plenty of artists that have to be considered not significant enough to cover.

If you were designing a course in either chronological order or in reverse, niether one might ever touch on groups like the Residents, Young Marble Giants, Donovan or Charles Ives--but what if you couldn't even get back to Mozart, Charlie Parker or Woody Guthrie from your current starting point?

<comment><USER27> The your current starting point is exceedingly narrow.

Don't take it too literally. E.g. don't assume you'd start at a single leaf and trace a graph only backwards, but looking at "here is this set of music trends that are common now. Why do this subset over here have X in common? Lets backtrack... " and then don't be afraid to take steps to the side as well.

The point of the article I took was that when we're exploring music (and other art forts) we tend to be exposed to current trends, and then we tend to explore backwards to something similar but not quite the same.

But we don't go _strictly_ backwards. We may very well e.g. trace an influence back to a wider genre and start exploring to the sides, and even then forwards again. started with.

I think the more important point is to aim to start with something that students are likely to be immersed in and follow threads that hopefully retain their interest because it retains their connection to something they enjoy, rather than e.g. jumping 500 years back in time and taking ages tracing things forwards before you've reconnected it to something they care about.

To take a very contrived example: If you like German electronic artist Zombie Nation, what's the odds you'll find starting with 40's easy listening interesting?

But go backwards: In 1999 they sampled Lazy Jones for Kernkraft 400 [1]. Lazy Jones was a 1984 game with a very memorable main track [2].

If you start poking around in mid 80's chip tunes, you'll pretty much _have to_ cover Monty on The Run [3] - one of the big things that MOTR brought, was a much more ambitious orchestral inspired score with heavy use of rapid transitions and vibrato to get closer to simulate real instruments despite only having three voices to play with. Compare Lazy Jones and MOTR with Kernkraft 400 - while Kernkraft 400 copies the tune, MOTR is at places surprisingly close to having a sound you might expect in modern electronic music.

As it happens, among many other references to earlier styles of music, the immediate influence on MOTR was the Dick Barton theme tune [4] from the late 40's.

If you dig deeper, you'll find many additional influences and threads to unravel in between.

[1] [https://en.wikipedia.org/wiki/Kernkraft_400](https://en.wikipedia.org/wiki/Kernkraft_400)

[2] [https://www.youtube.com/watch?v=eWxlYYA8yrg](https://www.youtube.com/watch?v=eWxlYYA8yrg)

[3] [https://www.youtube.com/watch?v=YIA_0cvS2gQ](https://www.youtube.com/watch?v=YIA_0cvS2gQ)

[4] [https://www.youtube.com/watch?v=F2eqX93umXo](https://www.youtube.com/watch?v=F2eqX93umXo)

</comment></comment></comment></comment><comment><USER28> I think music history should be taught thematically. Rather than going Bach, Mozart, Beethoven, etc. in chronological order, use music theory to make connections across all time periods in each lecture. For instance, one could teach about open chords, those containing 1 and 5 only. That might be illustrated in both 2001: A Space Odyssey or monastic music from medieval churches. One could examine how melodies are shaped, what makes music sing. Harmonic analysis could be the aim, looking at how dissonance was increasingly used to create tension and drama. There's also storytelling in music, whether through words or not.

All of this to say, I'd rather not use chronological time as the axis of any musical study. We love music for its beauty and power, which is not a function of time but of the intricate neurological systems devoted to hearing and musical thought.

</comment><comment><USER29> Geoffrey Himes comes at this from a popular-music perspective which doesn't really contemplate the reasons why music history is taught the way it is, but this is still an interesting idea. I say this as a classically-trained singer who studied music history at the undergraduate and graduate levels.

For Himes, the history of music doesn't seem to go back more than about 80 years or so. But the real history of course goes back many centuries further, even for notated "western" art music. So it would have been more interesting if he extended his idea further and tried to justify it based on an 800-year perspective, rather than 80 years or so.

</comment><comment><USER24> This reminds me of the hours I spend poring over the Allmusic Guide to Rock I had borrowed from the local library, tracing backwards from Van Halen, Nirvana, and Beastie Boys to discover their influences. I had taken piano lessons for several years and had learned Bach, Beethoven, Chopin, and Debussy — sometimes tracing back led me to what I had learned on piano.

I agree that working backwards can lead to wonderful discoveries. What can be difficult to grasp as you go back is what the music sounded like at the time—how an album sounded because it was the first time musicians had made that sound.

</comment><comment><USER30> If you start taking music lessons, you might learn some simple pop songs first and move your way backwards to older, often complex pieces that have stood the test of time. I don't think everyone just starts learning music playing Bach or medieval music. It's far far less of a straight path than this article suggests.

</comment><comment><USER31> Counterpoint: learning in this way is a good method of keeping attention ("you should learn this because your favorite artists liked these artist!") but if you actually listen to the old stuff first, you can also appreciate it in the RIGHT order of things. It is, however, pretty difficult to listen to much of what's come before. I think a healthy appreciation in both directions, digging into whatever node you happen to traverse is the preferred method.

<comment><USER9> What do you think is difficult to listen to about earlier music? I can't say that music of the past was difficult for me, except for music written before leading tones became almost obligatory, i.e. before the advent of functional harmony — and that was a pretty rapid adjustment. I suppose some of the medieval music that uses parallel fifths between raised 4/7 and 5/1 at cadences took a little getting used to, as well.

<comment><USER31> It's not the listening - it is the sheer volume. If you track backward you know there will be a connection. If, however, you attempt to start with the past you'll need to go pretty wide to get to all the things heavily influencing modern work.

I guess you could recommend a list. Start with medieval madrigals and then work your way to Stax records anthology? Haha

</comment></comment></comment><comment><USER32> Clickbait title. This is not teaching backwards, it is teaching it forwards but via recursion towards the causal factor. Good luck with that when the stack gets deep.

Same cautionary tale with the use of recursion.

There is a certain way that history progressed (the motivic force, so to speak) and it would make no sense to reverse the order. And given the stack issue, better not be faddish and just pick a time and go forward from there.

</comment><comment><USER33> Also playwriting. There's a really good book explaining that if you read a play backwards you can work out the causality much better and get a far greater understanding of the play:

[https://www.amazon.co.uk/Backwards-Forwards-Technical- Manual...](https://www.amazon.co.uk/Backwards-Forwards-Technical-Manual- Reading/dp/0809311100)

</comment><comment><USER34> That's an interesting theory, but it ain't the way I learned music history. When the music store in my home town was closing out 78 records, my dad went in and bought a big stack, a couple of hundred 78s with mostly classical music on 'em. At closeout prices.

As a little kid I was allowed to play those records any time I wanted to. And I listened a lot. Listening to that early music helped me, right away, to pick out what was good pop music on the radio, and what was bad. Cuz, I mean, the music on those records had stood the test of time for _two centuries_.

Happy father's day, pop. Thanks for the memories.

<comment><USER35> Just a nitpick: Classical music from 200 years ago is definitely not "early music" by any cultural tradition. Western music 200 years ago was a highly developed art form, and this is even more true for other classical traditions that exist today, such as Chinese classical music and Indian classical music.

200 years ago, the symphonic form was already highly developed, which most would argue is the most advanced form of Western classical music.

I don't think music from this period necessarily gives you any pointers for gauging the quality of modern pop music, but it might influence your tastes in a positive way. Just keep in mind that very advanced music is still being written, and it mostly doesn't sound anything like what was written 200 years ago.

</comment></comment><comment><USER36> Just like with programming, I start with the end result that I have in my head and then teach myself everything backwards thats needed to produce the end result

</comment><comment><USER37> I'm skeptical of this as a way of gaining a holistic understanding of music history, although it may be a helpful technique in the toolkit.

</comment><comment><USER38> That's how you should teach games. Start when the game ends, and the winning conditions.

<comment><USER39> Whenever I'm being taught a game, my first question is always "What's the goal?" I find that without knowing what I'm supposed to be trying to achieve, it's extremely difficult for me to remember all the rules explained to me beforehand because I have no context as to why they're important.

</comment></comment><comment><USER40> This is a very strange idea; I'd say everything should be taught based on how it has developed historically. (For example, I'd argue math should be taught this way.) This gives you a real notion of things (as opposed to a mere definition). A notion is a minimal working model of a thing in question and the best place to find those minimal models is to look at the beginning. Imagine you want to understand radio. Where would you start: with a minimal radio receiver that has like five parts or with a modern state-of-art radio station?

</comment><comment><USER41> [https://soundcloud.com/krazhtest-3/banhmi15nico15krazhtest](https://soundcloud.com/krazhtest-3/banhmi15nico15krazhtest)

</comment><comment><USER42> more simply, start by teaching things that people are currently interested in, and work back from them. if you like something, you are curious about where it came from

<comment><USER43> I couldn't agree more. It's very difficult, but in my opinion the most complicated part in teaching is getting the attention and grabbing the interest of students. If you have that, as long as you do it ok, people will learn. First, find the connections between the subjects and the students. Then, you can start teaching.

Of course, teaching some things in order might be important or useful, and students have some decent degree of attention too. And sometimes you need to explain boring things. Ok, but people learn the most when they want to learn. Curiosity can be induced.

</comment></comment><comment><USER44> I don't agree at all.

First, people do learn and process differently. No one size fits all here.

Adding this to the forms we have developed makes great sense. No argument.

I personally prefer to take it in mixed mode. If I'm wanting to do something, understanding related history helps. Maybe that's a backward progression back to roots.

But, it can be a chain of forward influences too. Who built on what and how, why?

In a more general sense, maybe narrative makes the best learning. What happened?

</comment><comment><USER45> This works fine until you reach back to early 20th century. That's when 20th- century classical music comes in and where the rock/blues goes away.

</comment><comment><USER46> Wouldn't we need to understand history forwards before teaching history backwards anyways, effectively nullifying this idea?

This idea reminds me of how artificial intelligence might conceptualize a subject, but doesn't make sense for the corpus of history.

</comment><comment><USER47> History - directed by Christopher Nolan, starring Guy Pearce

</comment><comment><USER48> Not just music. This applies to all of history.

<comment><USER49> It depends a lot on the specific field that you're talking about. I studied both music and physics in college, and I think that teaching the history backwards would work for music, but not for physics. You can understand modern harmonic theory without knowing the details of how it evolved out of contrapuntal theory. It would be easy to learn about the current state of music theory as is, and then extend your understanding afterwards by learning about the context and history which led to the current state. Physics isn't really like that. There's no way that you're going to understand general relativity first, and then learn afterwards that the theory evolved from Newton's laws. Some fields successively build on top of their own histories while others morph and change in such a way that knowledge of their histories is nonessential for understanding their current state.

<comment><USER48> Well, I suppose OK, fair enough. Maybe for the likes of technical history, Newtonian mechanics is easier to understand than Relativistic mechanics, and the same holds for a variety of other scientific theories. Though I'd put forward that in teaching the old ones before the most recent ones, we end up with lots of people who end up not studying the latter at all and not grokking how or why, insofar as we understand things at least, light speed is a speed limit in our universe.

But then, as you correctly point out, some fields change in such a way that knowledge of their histories is nonessential for understanding their current state.

As to history proper, explaining the cold-war era proxy wars warrants a dive into WW2 and the onset of the cold war at some point; which then naturally leads you to dive into GD and WW1 as to why there was a WW2 in the first place; and why there was a WW1 to begin with; and why there was so much German-French animosity then; and why Europe was a powder keg at the time; etc. One can go on and on all the way back to the Roman Empire and Classical Greek history.

I'm admittedly an armchair historian at best, but methinks reversing the arrow of time in history books might yield a very interesting take on the topic that is a lot more approachable to kids and teenagers.

</comment></comment></comment><comment><USER50> This makes sense. I've always been an advocate of teaching the majority of things backwards.

<comment><USER51> How would you teach mathematics or reading backwards?

<comment><USER52> "Backwards" is relative to the original way a subject was taught. My from my experience math is taught formula first rather than by starting with an intuition based on physical representation.

Starting with developing an intuition like 3B1B and then deriving a formula would be "backwards" to how I've been taught in the past.

<comment><USER53> Gilbert Strang's lectures on linear algebra work this way. He typically first gives a simple example (like for least squares, fitting a line to three points in two dimensions) and then over the course of the lecture susses out a broader generalization / formula from the simple example.

Unfortunately, OCW seems to be having some kind of copyright issue with YouTube, but here's a link to the video anyway. [https://ocw.mit.edu/courses/mathematics/18-06-linear- algebra...](https://ocw.mit.edu/courses/mathematics/18-06-linear-algebra- spring-2010/video-lectures/lecture-16-projection-matrices-and-least-squares/)

<comment><USER54> I generally agree with this approach, but sometimes even the 'simple' example isn't intuitive or motivating to someone; it highly depends on your audience.

E.g. a lot of math courses under my school's engineering curriculum would start off with examples from physics, but if you don't have the proper physics background or aren't interested in those applications, it's just another layer of abstraction to slog through.

My high school stats textbook would use classic problems from medicine (e.g. x/n people sampled are sick, what bounds can we put on the distribution of how many people are sick in population?), but that might not be particularly motivating to someone who has no interest in medicine or why an epidemiologist might care to know the distribution.

The best starting point to teach anything is the point that is closest to what the student understands and motivates them, but unfortunately that can vary a lot from person to person.

<comment><USER50> What you're saying makes sense and is one viewpoint. I could see it the opposite way too:

In school, it's good for someone who doesn't know or care about epidemiology to get a slice of what would be useful to an epidemiologist. Likewise in reverse.

The reason Macs have always had nice topography is because Steve Jobs happened to audit a calligraphy class taught by a monk (who stopped being a monk because he met a nice girl).

I'm not banging the interdisciplinary drum- we all already know learning outside our interests is good. I'm saying it's probably a good educational tool to force students to look at problems based on their utility to someone else.

Sometimes the further a problem is away from being directly useful to you, the wider your horizons will be once you understand how to solve it, and (more importantly) why to bother.

</comment></comment></comment></comment></comment></comment><comment><USER55> "If we had tried to tell this story forward, we would have lost most of our audience once they encountered Tharpe's old-fashioned dresses, twangy guitar and sanctified lyrics." This is an obnoxious piece.

</comment><comment><USER56> as an afrobeat devotee... who worshipped James Brown as a child... I would say 'f--k yeah' ... much later I learned that Fela Kuti hosted JB in Lagos... who knew? but it all makes sense if you listen to the music

</comment><comment><USER57> This applies to cooking as well.

</comment><comment><USER58> We should start with Black Sabbath and work forwards and back from there.

<comment><USER59> Monks -> Bach -> Mozart -> Beethoven -> Tchaikovsky -> Stravinsky -> Black Sabbath -> Gangnam Style

</comment></comment><comment><USER60> This is only tangentially related but I've been working on an ide for music. Sign up if you are interested [https://www.ngrid.io](https://www.ngrid.io)

<comment><USER21> definitely tangential, but i was interested anyway until i got to the no- detail, gimme-your-email web page. I think these prelaunch page things are over, and if they're not, they should be.

<comment><USER60> What would you like to know? Just FYI I set it up because people I talked asked if there was a way to be notified.

</comment></comment></comment><comment><USER61> Ah, but at what level of detail?

Should we start with the climax of the 9th symphony, then the Ode to Joy, then the prelude?

Or should each piece be played as its own crab canon?</comment>


I Hacked Play-With-Docker and Remotely Ran Code on the Host - <AUTHOR> https://www.cyberark.com/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host/ <comment><USER2> What an awesome hacking session. Very nice angle on writing their own kernel module. Thanks for posting this!

</comment><comment><USER3> TL/DR: Docker runs "Play with docker" service, and they did not block insmod there, nor did they block access to the boot disk. Wow! To quote the author:

> The reason is quite simple: PWD uses a privileged container

This is such an obvious failure that I wonder how it could even get into production.

<comment><USER4> They probably wanted to support docker in docker.</comment></comment>


Hypercritical: A Dark Age of Objective-C - <AUTHOR> http://5by5.tv/hypercritical/14

<comment><AUTHOR> tl;d(l): Because Objective-C's memory management (or lack thereof) is presently a benefit to iOS when mobile devices have limited resources, Apple has bought itself some time before relying on Objective-C for development of OS X and iOS applications becomes a serious problem for their business.</comment>


Online Courses Aren't Actually Democratizing Education - <AUTHOR> http://blogs.smithsonianmag.com/smartnews/2013/11/online-courses-arent-actually-democratizing-education

<comment><USER2> >>[...] 80 percent of MOOC students come from the wealthiest and most well educated 6 percent of the population," the authors of the paper write.

What about the 20% that didn't have undergraduate degrees? No doubt there's a lot of skew here, but the focus should be on this 20% that (now) have the opportunity to take a variety of free online courses. Perhaps this 20% wouldn't have had a chance otherwise.

Otherwise, the article is right that MOOCs could expand their reach further, but I think this is a great start and optimistic news. If people thought that early-adopter MOOC audiences would be primarily comprised of non-degree holders then now would be a great time to re-examine assumptions.

<comment><USER3> Quite. Big-ticket schools have a lot of incentive & budget & momentum to promote big-ticket degrees. MOOCs just don't have the visibility, so those who tend to participate are already plugged in enough for awareness of such obscure options. 20% being "new students" is pretty good.

MOOCs also don't yet provide confidence for all-in degree-scale participation, so they appeal more to those looking to fill educational gaps instead of building their academic career thereon. High-school graduates just aren't ready to pursue MOOC degrees en masse; they will as momentum & reputation builds, but not yet.</comment></comment>


CSS3 animated Christmas card - <AUTHOR> http://marynaaleksandrova.info/labs/christmas-card/

<comment><USER2> Thanks for the "there will be music" warning.

So this is base64 images that are animated with CSS3?

<comment><AUTHOR> :) 'So this is base64 images that are animated with CSS3?' true

</comment></comment><comment><USER3> Nice and clean. Well done.

<comment><USER4> It's nice, but it there are some drawing errors on Safari (6.0.2), the Christmas tree flickers and ends up behind the buildings.

I remember a few years back when animated Christmas cards using Flash became popular. It's nice to see that we're almost at the point you can do all of this without a plugin :-)

<comment><USER5> The trick is to never use IE or Safari for demos that use new technologies! =)

<comment><USER6> except that the iPad runs safari...

If a demo doesn't work on the iPad it's broken.

<comment><USER7> er no. iPad is broken. If apple provides a platform that doesn't respect standards _and_ disallows other browsers from working as they're intended to, it does not mean the entire world that does not feel like supporting the walled garden is broken.

<comment><USER8> There are two different forms of broken - something that doesn't conform to a published spec, and something that doesn't work on something with significant market share. The person you're replying to is referring to the latter.

It's a colloquialism referring to a users broken expectations. If a user tries to open a page and it doesn't render properly, the user will blame the page, not the device. If a website renders wrong, that's the websites problem.

If the site uses a feature that is unsupported (or poorly supported) by a browser with significant market share, then its the sites responsibility to fail gracefully. You can rant until you're blue in the face about how the iPad/Safari should handle these things better, but most users simply don't care about your particular definition of "broken". They only know the site doesn't work.

<comment><USER7> I want to see you ranting like that next time a technology demo doesn't work on ie. Also, do you have any figures for ad market share on browsers?</comment></comment></comment></comment></comment></comment></comment>


Uber Is Testing a Feature That Lets Some California Drivers Set Fares - <AUTHOR> https://www.wsj.com/articles/uber-is-testing-a-feature-that-lets-some-california-drivers-set-fares-11579600801 <comment><USER2> Brilliant. If they eventually transfer all fare setting to drivers, they can let the market take fares to rock bottom while washing their hands of the process.

</comment><comment><USER3> They should invest in a few "smart pricing" partners and offer drivers an option to select from these partners or set the price themselves. Most driers would opt-in to such a program, giving Uber the benefit of lower prices while allowing autonomy to drivers</comment>


The easiest way to say « Fuck » to Internet Explorer - <AUTHOR> http://fucking-ie.com/

<comment><USER2> That's just stupid. Welcome to the 90s. [http://www.anybrowser.org/campaign/](http://www.anybrowser.org/campaign/)

</comment><comment><USER3> I agree that this is pretty silly, but to those asking about ie 11, it doesn't detect ie 10 or 11 as "IE"

       MSIE ([0-9]{1,}[.0-9]{0,}

</comment><comment><USER4> Ie 11 is sweet. I would switch full time but my extensions are on chrome.

The pop up blocker is the best. Nothing gets past it.

Controls in ie are stuck in 1995. Extensions in ie are fucking hard to delete or sometimes undeletable.

Apart from this, ie's aite.

</comment><comment><USER5> I imagine it would be even easier with a conditional comment.

But... why is something so childish on the homepage of HN?

</comment><comment><USER6> This campaign is 3 years late.

</comment><comment><USER7> What is wrong with IE11?

<comment><USER8> Not everyone can upgrade to IE11 unfortunately. I'm on vista and stuck with IE9 so I don't even bother.

</comment></comment><comment><USER9> LMAO</comment>