Filesystem error handling - <AUTHOR> https://danluu.com/filesystem-errors/ <comment><USER2> One trope I frequently encounter as a FreeBSD professional is "Linux is used by so many people, it doesn't have vast and sweeping bugs anymore".. the many eyes fallacy. In reality, you get bystander paradox.. everyone wants RedHat or IBM to do all the hard work and they reap all the rewards.

I find my field of systems pretty interesting.. there's so much to do and not a lot of people rushing in to do it as the heavy hitters retire or move to entrepreneurship etc. It's probably much cheaper to harden a *BSD or Illumos system in these domains, and much easier to get the results integrated into mainline. The financial and fame are much greater in doing it on Linux though.

<comment><USER3> > the many eyes fallacy

What do you mean by this? Do more eyes not find and point out more problems? Is the effect offset by some counteracting mechanism?

<comment><USER4> I think it's more along the lines of "Eh, I probably don't need to look, since someone else is surely doing that".

<comment><USER5> once it gets annoying enough - followed by "lets try a newer kernel and see if it goes away"

</comment></comment></comment></comment><comment><USER6> > This could happen if there's disk corruption, a transient read failure, or a > transient write failure caused bad data to be written.

Wouldn't transient I/O error get corrected by block driver itself by repeating the request a few times? Does a filesystem driver assume any error reported by storage device is permanent?

> The 2017 tests above used an 8k file where the first block that contained > file data either returned an error at the block device level or was > corrupted, depending on the test.

Are there any tests on how filesystems deal with metadata corruption or I/O error? Apart from NTFS "self-healing" introduced in Windows 7/2008, do modern filesystem drivers attempt to correct broken metadata completely on the kernel side, or just give up to avoid making things worse?

<comment><USER7> I believe apfs (apple's new filesystem), btrfs, and zfs all checksum metadata and will attempt to correct it.

<comment><USER8> I recommend the OP article since it specifically mentions apfs.

<comment><USER7> The OP article mentions apfs does not checksum _data_ , but I assure you that it does checksum _metadata_ :

[https://en.wikipedia.org/wiki/Apple_File_System#Data_integri...](https://en.wikipedia.org/wiki/Apple_File_System#Data_integrity)

<comment><USER8> Even ext4 has check summing of metadata, it's a fairly boring feature by now.

<comment><USER7> ext4 only received checksumming of metadata in Linux 3.16, which was released in March 2016 -- not that long ago really. So I wouldn't call it a fairly boring feature since it's barely been two years since it was integrated and I imagine some Linux distributions might not even have it yet.

Furthermore, it's unclear to me whether ext4 just uses those checksums for integrity checks or whether it actually has any "self-healing" capabilities.

My understanding is apfs, btrfs, and zfs all have self-healing capabilities.

<comment><USER8> Checksums do not provide "self-healing". Ever.

They can only tell you if a piece of data is wrong or not.

In the case of BTRFS it's less a case of self-healing, the data is not healed, rather that metadata is replicated across the disk.

I believe ZFS does the same but I'm not sure of this. I'm certain that ZFS does this if it has several disks to replicate from.

I'm not aware of APFS being self-healing on a single disk.

<comment><USER9> Yes, ZFS also replicates metadata on a single disk.

<comment><USER7> You can even tell ZFS to do the same thing with user data with the ditto blocks feature.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> While neat, it's limited to Linux. It'd be nice to see how the BSDs behave, on their filesystems (such as HAMMER2). ZFS was also notably absent.

<comment><USER11> As usual, another example of the Linux echo chamber. It's just one constant inward gaze with that crowd. They learn nothing from anyone, only trial and error.

<comment><USER12> I don't know that I'd agree. As much as llvm+clang inspired gcc to improve, ZFS seems like a big part of the inspiration for btrfs. I'm not sure that it hits the whole ZFS feature set, but it's probably a step in that direction.

</comment></comment></comment><comment><USER13> Something to keep in mind is that by default writes go through the page cache. By the time I/O is initiated for a write(2), the application process can have exited.

<comment><USER14> This is why calling fsync(fd) before closing the file and exiting is a good idea if you need that kind of error to be handled. You should get it as a return of fsync if it happens after the write.

<comment><USER13> O_[D]SYNC is better than a separate call to fsync, since it is not supposed to suffer from the race condition inherent to fsync. Arguably pedantic.

<comment><USER9> I agree with using O_DSYNC to surface the error to the write call, rather than waiting until the fsync call, which is often not checked by the user.

I did some testing recently [1] with O_DIRECT + O_DSYNC and found some surprising performance results, on Linux it can be similar to O_DIRECT + fsync() after every write for hard drives. But as soon as you are doing grouped writes, performance is almost always better by using O_DIRECT + fsync() after the end of the group.

For SSD drives though, O_DIRECT + O_DSYNC can be faster than O_DIRECT + fsync() after the end of the group, if you are pipelining your IO, e.g. you encrypt and checksum the next batch of sectors while you wait for the previous batch of checksummed and encrypted sectors to be written out. Because SSDs are so much faster, you can actually afford to slow down the write a little more by using O_DSYNC, so that your write is not faster than the related CPU work.

[1] [https://github.com/ronomon/direct-io](https://github.com/ronomon/direct- io).

<comment><USER13> A more advanced (and somewhat easy to get wrong) option would be sync_file_range combined with fdatasync, which allows to roughly emulate O_DSYNC overall but without blocking synchronously for IO.

<comment><USER9> sync_file_range is different to fsync, fdatasync and O_DSYNC in that it does not flush the disk write cache (whereas the latter explicitly do on newer kernels):

[https://linux.die.net/man/2/sync_file_range](https://linux.die.net/man/2/sync_file_range):

      This system call does not flush disk write caches and thus does not
      provide any data integrity on systems with volatile disk write caches.

<comment><USER13> Hence "sync_file_range combined with fdatasync". sfr is only useful to get the kernel to start the write-out _now_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I can't see anywhere in the article where it says which version of linux this was tested on (beyond "2017"), which is a shame.

Is this the state of affairs after the improvements described at [https://lwn.net/Articles/724307/](https://lwn.net/Articles/724307/) have gone in?

<comment><USER16> second to last paragraph:

> All tests were run on both ubuntu 17.04, 4.10.0-37, as well as on arch, > 4.12.8-2. We got the same results on both machines.

<comment><USER15> That wasn't there half an hour ago :-).

That LWN article was from June 2017 and 4.10 was released in February, so I think that means these tests predate any of the changes it discusses.

<comment><USER17> Arch linux 4.12.8-2 came out in August.

</comment></comment></comment></comment><comment><USER12> > It's a common conception that SSDs are less likely to return bad data than > rotational disks, but when Google studied this across their drives, they > found:

>> The annual replacement rates of hard disk drives have previously been reported to be 2-9% [19,20], which is high compared to the 4-10% of flash drives we see being replaced in a 4 year period. However, flash drives are less attractive when it comes to their error rates. More than 20% of flash drives develop uncorrectable errors in a four year period, 30-80% develop bad blocks and 2-7% of them develop bad chips. In comparison, previous work [1] on HDDs reports that only 3.5% of disks in a large population developed bad sectors in a 32 months period – a low number when taking into account that the number of sectors on a hard disk is orders of magnitudes larger than the number of either blocks or chips on a solid state drive, and that sectors are smaller than blocks, so a failure is less severe.

Unfortunately "return bad data" is slightly ambiguous. IIRC these failures that are reported are ones where the drive itself claims that it discovered invalid blocks which were detected by error detection algorithms. The rate at which drives "return bad data" is likely only to be discovered by a well- controlled test that writes specific data to specific locations, or data patterns, then looks to see whether that data was preserved. This could tell us about data that was corrupted and escaped detection. Google's aggregate disk usage stats are a dump of the devices and their service activity with application-specific load, not the well-controlled test required for detection of the "returned bad data" symptom.

It's possible that you could scour application logs and try to attribute application failures to corrupt data from a disk, but it would be difficult to isolate.

<comment><USER18> Or any of the layers they run above the block device could be designed to detect it, or even correct it.

<comment><USER12> Some of them do precisely that. btrfs is designed to correct small errors introduced by the layers below it (this concept is tested in the article) .

</comment></comment></comment><comment><USER19> Pretty cool to see an update on the old analysis - and nice to hear, file systems have improved!

</comment><comment><USER20> Well, this certainly changed my opinion on btrfs. Now I can tolerate it's slightly slower performance, knowing that it is the only fs correctly handling errors.

<comment><USER21> That only goes for small files.

From the article: "Since the file was tiny, btrfs packed the file into the metadata and the file was duplicated along with the metadata, allowing the filesystem to fix the error when one block either returned bad data or reported a failure."</comment></comment>


Alexa outage in the UK - <AUTHOR> https://metro.co.uk/2018/09/26/amazon-alexa-is-down-in-the-uk-and-echo-gadgets-have-crashed-around-the-country-7980466/ <comment><USER2> I just thought my WiFi was busted. Any other regions down or is it just the UK?

</comment><comment> martin-adams Yep, been out for a number of hours now.</comment>


"Huh" exists in all human languages, according to research (2019) - <AUTHOR> https://thelanguagenerds.com/this-is-the-one-word-that-exists-in-all-human-languages-according-to-research/ <comment><USER2> Reminds me how the TRS-80 Level 1 Model 1 BASIC interpreter had just three error messages:

[http://www.trs-80.org/level-1-basic/](http://www.trs-80.org/level-1-basic/)

Error Messages

Level I BASIC had three error messages: HOW?, WHAT?, and SORRY. User's Manual for Level I described the error messages this way:

In general, a HOW? message means, "I understand your instructions, but they're asking me to do something that's impossible."

The WHAT? error message, on the other hand, means, "I don't understand your instructions — either the grammar is wrong or you're using words that aren't in my vocabulary."

The third and final error message is SORRY. It means "Sorry — you have run out of memory locations and must either cut down the program size or purchase additional memory."

<comment><USER3> Ah my very first computer to program was the Model I. The fun days of writing programs in BASIC and later assembly language, using a tape cassette machine to load and save programs/data, and using a 300 bps modem to connect to a BBS.

Actually I kind of miss those days as you really felt like you were discovering things and it was possible to learn so much about the computer and know what almost everything was doing. Not that I want to go back to it, but it was quite enjoyable at the time.

<comment><AUTHOR> Modem? Modem ???

Luxury ...

 _(I wish I 'd had a modem ... I wonder what I could have connected to in Australia in 1978 ...)_

</comment></comment></comment><comment><USER4> The researchers discuss the question whether "huh" is a word or just a grunt in the linked paper. ([https://journals.plos.org/plosone/article/file?id=10.1371/jo...](https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0078273&type=printable)):

> Huh? exhibits linguistic conventions that speakers need to learn in order to > use the form properly. A learner of Spanish has to know that repair is > initiated with the mid front unrounded vowel ''e8'', a learner of Cha'palaa > has to know that the form is more like ''aQ'' with falling intonation, and a > learner of Dutch has to know that a glottal fricative at onset is common: > ''h38''. Its acquisition follows a normal trajectory, at least in American > English-speaking children [37]. Second language learners' reports confirm > that the precise form of this interjection has to be learnt, and that > intuitions are not necessarily a reliable guide in this process [38].

> Perhaps there is a continuum from non-linguistic vocalisations like sneezing > and crying to prototypical conventional lexical items like bless you and > pain [39]. Our evidence suggests that huh? is more on the word side of that > continuum. Based on the fact that huh? is integrated in multiple linguistic > subsystems and conventionalised in language-specific ways we conclude that > huh? a lexical word.

<comment><USER5> It's definitely not a _word_ in all languages, probably not in most of them.

It's an utterance like "oooh" and "hmm" and "haha" which are pretty much universal as well.

<comment><USER6> Can the people who're downvoting the above comment mention whether it's factually incorrect ?

<comment><USER7> It certainly has more than a whiff of "HN commenter solves question experts have been discussing for some time" to it.

</comment></comment></comment></comment><comment><USER8> I'm not so sure about this... I speak 3 languages and it does exist in only two of them. The closest you can get to "huh" is probably "eh" in the last one, though that is still fairly close. Mind you, those are all European languages so they probably have influenced one-another significantly over the centuries (even the Slavic language of the bunch). I guess "huh" might have been transferred over to other parts of the world during the time of the colonial empires, making it more common. But all languages? I Doubt it. I happened to be chatting with an old friend who is originally from Lebanon and she said that's not the case in Arabic for instance(with a grain of salt since she also says she's anything but fluent in Arabic).

<comment><USER9> The table in the article considers "eh" (like in Spanish) and "a" (like in Russian) as equivalent to huh in a given language.

<comment><USER10> This is like saying 'yes' exists in all languages because there's an equivalent in every language... It's... a bit clikbaity

<comment><USER11> Irish doesn't have words for "yes" and "no" \-- answers must echo the verb: "Are you okay?" "Am." "Did you tell him to come over?" "Didn't tell."

<comment><USER12> Unsurprisingly, it's similar in Scottish Gaelic and Welsh. Mandarin and Cantonese (and probably other Sinitic languages) don't either, with much the same arrangement as the Celtic languages.

<comment><USER13> No Shi? I had no idea about Mandarin.

<comment><USER14> Shi means "is", not "yes" in Mandarin.

<comment><USER15> who sais yes isn't a contraction of i'is

<comment><USER6> Surprisingly, this is partially true. It's a contraction but an older one.

[https://en.m.wiktionary.org/wiki/yes](https://en.m.wiktionary.org/wiki/yes)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> >> They recorded bits of informal conversation from 31 dialects across 5 continents and suggested that the word 'huh' (and its variants) is possibly a universal repair initiator that exists in all languages, performs the same function and sounds roughly the same across languages.

Can we compile a list of more than 31 languages where this interjection sounds nothing like "huh"?

I'll start with Greek:

      - Αποφασίσαμε να μετακομίσουμε στην Αλάσκα (We decided to move to Alaska)
      - Ε; (/Ɂe/)

Here's an ipa chart where you can click the symbols to get the sounds:

[https://www.internationalphoneticalphabet.org/ipa- sounds/ipa...](https://www.internationalphoneticalphabet.org/ipa-sounds/ipa- chart-with-sounds/)

<comment><USER17> I don't speak or read Greek, but I do want to note that this counterexample does not prove there is no "huh"-like repair initiator in Greek.

In American English, there is "Eh?" "Huh?" and "Eh?" are similar in function but sound different.

<comment><USER16> The "h" sound (/ɦ/, I think) does not exist in Greek, but I agree that "Eh" sounds closer to the Greek exclamation than "huh".

On the other hand, the article seems to say that it's specifically "huh" that's universal. Anyway, I'm just curious to see how many counter-examples we can find.

<comment><USER18> Funnily enough, Ancient Greek did have a leading h- sound. It's since disappeared, along with tonal accents and some vowel sounds.

I'm not sure the h itself is really necessary for the main argument, but possibly it got dropped somewhere along the way? That's pure speculation though, I haven't seen any evidence for that in print.

</comment></comment></comment></comment><comment><USER19> I'm wondering if this isn't satirical. English is my third language & this word in particular confounded me & still does to some Degree. In my head I'm always trying to translate between languages & cultures & the word "huh" to me seems uniquely western.

Another giveaway is the awarding of the Ig Nobel Prize & then citation of that fact as evidence of the study's credibility & importance at the end (masterful comedic move if it was intentional)

</comment><comment><USER20> It's pretty clear that there are some grunts/vocalizations that are shared amongst all humans (and possibly primates) these would yes/agreement, no/disagreement, and question mark/surprise those aren't language dependent.

I'm not sure if it's actually convergent evolution like the research paper implies my bet would that these predate humans by quite a bit, and some languages have a stronger onomatopoeic relationship between the base grunts and their question word.

Even in English 'What' has the basic huh in it, wha/ha it wouldn't surprise me if the T was added to make it more distinct or allow for more tonal information be passed along such as surprise, displeasure, disappointment and even anger.

My non-linguistically educated opinion is that huh and and other grunts like a-ha (not the band) are probably much older than humans and they are universal just as female copulatory sounds are in humans and other primates (there is more to girls moaning in bed than just pleasure).

[https://en.m.wikipedia.org/wiki/Female_copulatory_vocalizati...](https://en.m.wikipedia.org/wiki/Female_copulatory_vocalizations)

<comment><USER21> What is "co" [tso] in my language and people here are making the same arguments with it

<comment><USER20> Well depending on the tonal formalization of it at least how I would pronounce it would probably be very similar to huh just a non-guttural version of it that may have evolved because the language itself is non-guttural.

The question really is if a non-English or any second language speaker of your language understand "huh" as in not the word but the grunt, my bet would be yes.

</comment></comment></comment><comment><USER22> All languages tend to use shorter words for things that are more common.

The more commonly the thing comes up in conversation, the shorter the word tends to be.

Given how vast the pronunciations are (even in the examples they chose), I think they are creating an illusory correlation.

<comment><USER23> french chien, german hund, italian cano, and portuguese cao are all dog. They all have vastly different pronunciations, but they all trace their origins to a single proto-indo-european word. And in english, we use that same word to mean hunt, because that's what dogs do for us.

so the question is not whether words are pronounced the same, but whether they can be traced back through a lineage. where the sound does offer clues when taken as part of a larger tapestry. Another comment here says that the french huh is written (and presumably pronounced) hein. Well isn't that interesting? huh-hunt and hein-chien? (french uses irregular phonetic spelling because it used to be pronounced differently than today) Can we find a pattern of similar changes that would lead us to believe that the historical ancestor word of huh-hien was in use by an early tribe of people before their descendents separated deviated, physically and linguistically?

so, that's in essence a good piece of what linguists study; as in all areas of expertise, non-experts have difficulty contributing as their anecdotal experience has frequently already been catalogued and is part of the hypothesis.

<comment><USER24> Interestingly, dog is unrelated to that root proto-indoeuropean word.

<comment><USER25> I can't remember where I read it but apparently the etymology of the word dog is not known. Old English used hund (or something similar) and sometime between then and now 'dog' turned up. Of course we could still say hound and people would most likely understand you meant dog.

</comment></comment></comment></comment><comment><USER26> Kind of reminds me of the satirical article that I've been contemplating writing for a few years about trying to recreate the language of Eden by finding words that are the same in all languages. It would assert that the thread Adam and Eve used to sew their fig leaves must have been polyester since the word is universal.

</comment><comment><USER27> Living in an international non English speaking city, I have noticed more and more people not only using English words when there are perfectly fine, sometimes even shorter local synonyms, but also English sounds embedded into the local language (e.g. "huh?" or "nom nom").

</comment><comment><USER28> In Israel I'm more likely to say "מה" (Mah? literally "what") than "הא" "Huh".

I catch myself when in the U.S. saying "Mah?" to English speakers.

But "huh" exists, as does "ok" (though people are just as likely to say "בסדר" (b'seder).

It's interesting reading about the history of "ok" \-- a very modern word with a traceable origin -- that now exists in all languages. Read Metcalf's book:

[https://www.amazon.com/OK-Improbable-Story-Americas- Greatest...](https://www.amazon.com/OK-Improbable-Story-Americas- Greatest/dp/0199892539/)

</comment><comment><USER29> I have grown up with Shanghainese as my second language, and never in my life have I, my parents, or my brother ever uttered anything remotely like "huh." Seems like a silly bit of clickbait.

<comment><USER30> I checked Wiktionary's category of Wu interjections [1] and 呵 (Wiktionary romanization hu (T1), Sinological IPA /hv̩ʷ⁵³/) "5\. Exclamation particle for expressing surprise." [2] seems like it would fit their loose pattern. (Although it might be that this particular meaning isn't actually used in Shanghainese.)

[1] [https://en.wiktionary.org/wiki/Category:Wu_interjections](https://en.wiktionary.org/wiki/Category:Wu_interjections)

[2] [https://en.wiktionary.org/wiki/%E5%91%B5](https://en.wiktionary.org/wiki/%E5%91%B5)

</comment></comment><comment><USER31> [https://en.wikipedia.org/wiki/Natural_semantic_metalanguage](https://en.wikipedia.org/wiki/Natural_semantic_metalanguage)

</comment><comment><USER32> I have never seen that word huh written or pronounced in Spanish, French o Italian.

... But know it exists. I suppose more than one reader has pronounced aloud, in his native language, so it exits.

<comment><USER33> Spanish equivalent I think it would be more like "hmm".

"Eh" in Spanish exists but is more to call for attention, kind of like "ahoy" [http://udep.edu.pe/castellanoactual/e-eh-y- he-2/](http://udep.edu.pe/castellanoactual/e-eh-y-he-2/)

<comment><USER34> And meanwhile, the difference between "hmm" and "huh" is pretty much whether or not your mouth is open when you make the sound. Seems plausible that even these might be related.

</comment></comment></comment><comment><USER35> Very misleading headline. The exact word "huh?" does not exist in every language, it's more that every language has a word that functions like the English language word "huh".

This is like saying every language has a word for yes. It's pretty obvious.

<comment><AUTHOR> Well, except that not every language has a word for "yes". If in doubt, search elsewhere in the thread.

<comment><USER35> Thanks for the 100% HN-style "whatabout" nitpick that's completely beside the point of my comment! It has advanced the conversation and enriched all our lives.

<comment><AUTHOR> OK, well, let's reply more "in depth" to your comment.

> _Very misleading headline._

It's hard to know what a better headline would be. It does cover quite well what the content of the original paper is asserting, and while it's not exact that the utterance we transcribe as "huh" exists as exactly that in all human languages, nevertheless, they cover that question in the paper, and the sense of their conclusions is fairly well conveyed by this headline, even if it's not absolutely precisely true.

> _The exact word "huh?" does not exist in every language, it's more that > every language has a word that functions like the English language word > "huh"._

The original paper seems to be saying more than what you are asserting here. Yes, there is something of that, and in places it's not entirely clear exactly what they're asserting in that regard, but even so, _there is something in the research._ It would be interesting to see people try to build on the research rather than just saying "Well, it's rubbish, isn't it. Clearly wrong."

> _This is like saying every language has a word for yes. It 's pretty > obvious._

Do you think it's obvious that every word has a language for "Yes"? If so, that's why research is needed, because what people think is obvious isn't always true, and this claim is one of them. Not all languages have a word for "Yes".

</comment></comment></comment></comment><comment><USER36> > Spanish: ke

Excuse me? "¿qué?" (ke) literally means "what?". That is like saying "what?" is the English equivalent of "huh?".

The Spanish equivalent would be "¿Eh?", which is also interpreted as not having heard well, triggering the repetition.

Had to read the paper to find this addressed:

> Huh? exhibits linguistic conventions that speakers need to learn in order to > use the form properly. A learner of Spanish has to know that repair is > initiated with the mid front unrounded vowel "e↗",

</comment><comment><USER37> Best way to study this is to write the English "huh" into Google translate and observe how this "expression of scorn, anger, disbelief, surprise, or amusement" is vocalized in different languages. Comparing various written forms is just stoopid. You can clearly see it is the same wide-mouthed grin which produces same wide back-vowel [ɛ] or "ä". "H" is just the associated btreath-sound.

</comment><comment><USER38> Do people interpret 'huh' as a literal phonetic? I've always interpreted it to mean a number of different sounds people make—unlike, say, "oh" which is a literal sound associated with english.

Naturally people literally do make the "huh" sound in some sort of feedback loop, but I can't be the only one who interprets it like this....

</comment><comment><USER39> Confusion is the most universal human condition.

</comment><comment><USER40> Their Ig Nobel prize acceptance speech is excellent.

I can't find it back right now (on mobile) but it's warmly recommended and not too long.

<comment><USER41> Huh?[1]

1\. [https://www.youtube.com/watch?v=nRsL9kCuZaA](https://www.youtube.com/watch?v=nRsL9kCuZaA)

</comment></comment><comment><USER42> I'd expect many more words to exist in all languages. It would seem that there is a core set of words that are absolutely fundamental to any sort of spoken communication (yes/no, for example), and would be very surprised if this word "huh" is the only one so far found to exist in all languages.

<comment><USER43> Isn't Mandarin a typical example without yes and no? You answer affirmatively but repeating the verb and negatively by negating the verb.

(it's not really that simple, but it illustrates the point)

<comment><USER44> In some situations, yes, but you can say yes and no. 是 (shì, roughly translates to "is" in most situations) and 不是 (bú shì, no is). It's definitely not as cut and dry as the English yes and no, and it gives Chinese kids hell when they're learning English (I taught there for 6 years).

<comment><USER43> Definitely and to add to that, to my understanding (better than basic, far from fluent), 是 is more of a fallback verb following the same pattern than it is a translation of "yes".

</comment></comment></comment></comment><comment><USER45> That's quite the click bait, given that the article then goes on to count words that don't even remotely sound like "huh", like "eh" or "a", just so they can claim it exists in every language. That's just straight up "not doing linguistics".

<comment><USER34> Say all three of those words out loud. Do you really think they "don't even remotely sound like" each other? That they can't possibly have come from a common ancestor word that's been morphed over thousands of years?

They sure sound similar and quite possibly related to me.

<comment><USER45> As someone who speaks five languages and took quite a number of linguistics courses: they don't sound the same at all if you pronounce them the way they're pronounced in their respective languages. And no, the further back in time you go, the likelihood of single ancestors giving rise to multiple descendants drops dramatically, and instead the likelihood of distinct roots giving rise to words that temporarily (because languages constantly change) sound the same skyrockets.

That might sound counter intuitive, until you remember that languages, like people, don't actually have a family tree. They have a family graph. For cataloging and quick classification purposes we pretend languages can be classified in trees, but the actual relations between languages both over time and in the moment, are highly connected, weighted graphs.

</comment></comment></comment><comment><USER46> Link to full article (PDF): [https://journals.plos.org/plosone/article/file?id=10.1371/jo...](https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0078273&type=printable)

</comment><comment><USER47> I don't think there's a word like "Huh" in Hindi.

<comment><USER48> Neither in South Indian languages.

</comment></comment><comment><USER49> The word is 'huh'.

<comment><USER50> Isn't it "juj" in Spanish? :)

<comment><USER51> We don't say that in spain, the closest would be "eh?" or "ah?", maybe in latin american they use something I'm not aware of.

</comment></comment></comment><comment><USER52> Are there equivalents in sign languages?

</comment><comment><USER53> Surprised no one has mentioned gynantonix

</comment><comment><USER54> I was thinking "mom " and "papa".

If "huh" is the standard for a word then also laughing words like "haha" are also universal.

<comment><USER55> The physical sound of "haha" might be the same everywhere (to some degree, people laugh differently obviously) but different languages write "haha" different. Spanish: "jaja" or "jeje", Japanese: "wwwww"

<comment><USER44> In simplified Chinese: 哈哈哈!

</comment></comment></comment><comment><USER2> My immediate reflexive reaction to reading the title was "huh"!

</comment><comment><USER56> Huh.

</comment><comment><USER57> I would say "haha" exists in all languages but what do I know?

<comment><USER58> That's not a word though, that's an emotive sound, like crying. Sure, "haha" is a word you can use on the internet but it's the English interpretation of the sound laughter makes.

<comment><USER30> Most languages probably have an "interpretation of the sound laughter makes" and across the languages I know it's a fricative-vowel syllable repeated several times. That's about the level of similarity shown for 'huh?' across languages in the study.

<comment><USER59> 'Huh?' is significant because it forms a communicative purpose, it forms a request from listener to speaker to recall the previous spoken phrase. The study is showing that all languages have a sound for that purpose.

</comment></comment></comment></comment><comment><USER60> What about ma the word for mother? That seems more universal.

<comment><USER14> The Georgian word for mother sounds more like "dayda", so no, not really.

</comment></comment><comment><USER61> Well, 'huh' is basically a grunt.

<comment><USER62> In the same way that TCP/IP wouldn't work without ACK/NACK, grunts are an important part of linguistics:

[https://en.wikipedia.org/wiki/Backchannel_(linguistics)](https://en.wikipedia.org/wiki/Backchannel_\(linguistics\))

</comment></comment><comment><USER63> ...all languages that we checked.

</comment><comment><USER64> Que?

<comment><USER65> I'm sorry, he's from Barcelona.

</comment></comment><comment><USER66> They must have missed Swedish. We don't have 'huh', we have 'va'.

<comment><USER67> Look at the table, non of the words are literally "huh", but they convey the same meaning. The title is confusing, I had the same thought as you at first.

<comment><USER68> Yeah the table has an Icelandic example: "Ha". Though I only lived in Sweden for a year so I can't remember but Norwegian has the word "Hæ" which certainly has the same meaning as the English "huh"

</comment></comment></comment><comment><USER69> Not sure I consider "huh" to be an actual _word_. If so, I'm pretty sure blowing raspberry also exists in all human languages, and some non-human.

</comment><comment><USER70> Hä? Watt?

</comment><comment><USER71> I'd edit the title, current one seems clickbait. Maybe:

The word "huh" exists in all human languages, according to research

<comment><AUTHOR> In the past I've edited titles, carefully crafting them to give a better indication of the content, only to have people complain that the title has been changed, and subsequently to have the mods change it back.

So I've given up even trying to put any thought into the title ... if the article seems like it would, should, or could be interesting to the HN community, I post it.

I've been trained not to put any work into it.

<comment><USER72> same. kind of absurd that when you try to un-editorialize some clickbaity bs into a tldr; it gets mod-reverted to the original vague crap.

this modding style has definitely discouraged me from submitting articles here with good content but unfortunate headlines.

</comment></comment></comment><comment><AUTHOR> _EDIT 2:_ TIL that the flame-war detector triggers a review by the mods, so this comment is irrelevant, and wrong. I was going to remove it and leave the thread tidier than it was, but I can't, probably because it has replies. So it will remain ... please ignore it and carry on. As you were.

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>= _Original:_

Huh ... more discussion than upvotes, I suspect this will trigger the "flame- war" penalty and disappear from the front page, possibly within minutes (10:42 BST)

Shame, I thought this was an interesting discussion. If you agree and haven't done so already, your upvoted is needed to keep this on the front page. If you disagree, let it get buried.

 _EDIT:_ as I say in a reply below, I'm just interested in the discussion. If you don't want to give me the karma that's fine, just find some comments of mine and downvote them in balance.

<comment><USER30> If the flame-war detector is triggered, the mods get alerted and decide whether they're actually dealing with a flame war or not. No need to beg for upvotes.

<comment><AUTHOR> Is that really true? I've not seen them say so, and it's never come up when I've discussed it with them. I'll have to ask ... thanks for the information/suggestion.

If people want to keep the item but don't want to give me the votes, feel free to downvote one of my comments. I don't care about the karma, I wanted to see the discussion develop and evolve.

<comment><USER30> Dang has said so many times: [https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20flamewar%20detector%20review&sort=byDate&type=comment)

<comment><AUTHOR> You're right, I hadn't seen that. I'll remove my comment.

Thanks for the information ... today I learned.

<comment><USER73> IIUC the penalty is applied automatically but they get a warning [1] and then they check if the penalty is correctly applied and may revert it.

[1] I guess by email, but it may be a SMS or a big red blinking light in the headquarter.

Also, perhaps they get the warning when a submission pass a lower threshold and the penalty is automatically applied with higher threshold.</comment></comment></comment></comment></comment></comment>


How Tokyo Is Different from Silicon Valley - <AUTHOR> http://www.makeleaps.jp/blog/en/2014/11/how-tokyo-is-different-to-silicon-valley/

<comment><USER2> Tokyo is a paradise for living but a desert for doing a traditional startup (see below). On the other hand, Japan is the most viral place on earth. Hypergrowth companies here are based on viral marketing (any exceptions? Let me know).

If you're working on a viral marketing opportunity in Tokyo, please get in touch with me.

[Tokyo is a desert for traditions startups because:

\- Exits are rare and at low multiples

\- Funding is hard to get and include irrational terms, like personal guarantees.

\- Customers prefer to buy from established companies

\- Employees prefer to work for established companies]

Companies based on viral marketing can route around these problems. It's really a terrific place if you are ready for it.

</comment><comment><USER3> This is a bit off-topic. I just moved to Tokyo a month ago and Jay was very welcoming. I met him at last month's Hacker News meetup. It was just two days after I landed so I was pretty nervous.

Since then I've gone to 5 meetups. One thing that I've learned is Business Cards are vital. So much so that I've decided to bite the bullet and print up some of my own even though I'm still job hunting.

He didn't mention it but from what I can tell the Taxis here are a world apart. Stuff like the doors automatically close for you and the drivers all wear suits. Sorry I've only been taking trains everywhere.

The trains themselves are also a major plus point for Tokyo. My house is along the Mita-line and almost everywhere I go is is just a single connection away. The busy hours are not that bad too since my head is above the crowd.

I still get a thrill everytime a 10 car train rushes past the platform.

Also half of everyone wears suits. Even people in otherwise "low-class" service jobs wear suits.

Anyway: if you are in tokyo you should 100% visit the next HN meetup on the 21st. If you're new feel free to email me and we can meetup and walk together from the station. First time I came here I arrived an hour ahead of time to find the place. That turned out to be a bit early and it got cold waiting outside.

</comment><comment><USER4> I've heard that Sendai is rapidly becoming the Silicon Valley/SF of Japan, so it would be interesting to see comparisons between those two.</comment>


Free Tools Every Female Entrepreneur Should Use - <AUTHOR> http://www.forbes.com/sites/chicceo/2012/09/10/10-free-tools-every-female-entrepreneur-should-use/

<comment><USER2> As a woman, I feel that there should also be step by step instructions on how to install these feminine applications while carrying a baby in my left hand.

</comment><comment><USER3> Love tools! :-) Great post. For android a great scanning app is Cam Scanner [https://play.google.com/store/apps/details?id=com.intsig.cam...](https://play.google.com/store/apps/details?id=com.intsig.camscanner&hl=en) and had never heard of Rock the Post and Hack Pad!!! Can't believe it

</comment><comment><USER4> Uh oh, I'm a guy and I didn't know until now that I've been using girl tools!

<comment><USER5> You and me both.

</comment></comment><comment><USER3> Love tools! :-) Great post. For android a great scanning app is Cam Scanner and had never heard of Rock the Post and Hack Pad!!! Can't believe it

</comment><comment><AUTHOR> Don't worry Cataclysmic - the list is agnostic, we just write about all things related to female entrepreneurs. You won't get cooties!

<comment><USER6> What exactly does one's gender have to do with using these tools?

<comment><USER7> It's written for Forbes Woman so the title is demographically targeted. That's all ;)

</comment></comment></comment><comment><USER7> Love this - especially Evernote</comment>


Material Design , Learning the Rules and Breaking Them - <AUTHOR> https://medium.com/@creatrixx/material-design-learning-the-rules-and-breaking-them-1787ee364094 <comment><USER2> Can't agree more about the importance of breaking the rules. In my foray to Windows Phone development, I spent a lot of time customizing components to implement the design language well in Reitit [1]. The early Metro/Modern design language had next to no UI chrome, so many apps that didn't do their app specific design work ended up feeling very empty.

[1] [https://www.microsoft.com/en- us/store/p/reitit/9nblggh093vj](https://www.microsoft.com/en- us/store/p/reitit/9nblggh093vj)

</comment><comment><USER3> Really enjoyed this article, thank you for sharing. I've seen time and time again engineers arguing to use a certain technology just because it is 'the standard' or 'everybody else is doing it'. As you pointed out, the most important skill is to first understand the problem you are trying to solve and then come up with a solution that solves it.

A blanket solution "just do x" is never a solution.</comment>


The Judgment Against Hakan Lans (2006) - <AUTHOR> http://mobergpublications.se/patents/ <comment><USER2> [https://en.wikipedia.org/wiki/H%C3%A5kan_Lans](https://en.wikipedia.org/wiki/H%C3%A5kan_Lans) is short and to the point.

<comment><USER3> So it looks like the guy is a patent troll. Why is this on HN?

<comment><USER4> I don't know enough about this to really have an opinion.

But why do you assume that he is a troll?

<comment><USER3> The wikipedia article mentions his "color graphics" patent from 1979 is for a framebuffer with memory controller, which has been around for years before that.</comment></comment></comment></comment>


Strider: Open Source Continuous Deployment Platform - <AUTHOR> http://strider-cd.com

<comment><USER2> Nice to see this get opensourced!</comment>


Interview: Lennart Pottering (2015) - <AUTHOR> https://www.linuxvoice.com/interview-lennart-poettering/ <comment><AUTHOR> I wonder why Red Hat attracts such developers, not only Pottering but also Sievers.</comment>


Rumors of Firefox's Death are Greatly Exaggerated - <AUTHOR> http://technologizer.com/2011/03/24/rumors-of-firefoxs-death-are-greatly-exaggerated/ <comment><USER2> > In the first 24 hours following the browser's official release, consumers > have downloaded it more than 4.7 million times

In fact, downloads on the second day after launch eclipsed the first day, breaking the record that Firefox set with the Firefox 3 launch for "Most Downloads in a 24-hour Period": <http://twitter.com/#!/asadotzler/status/50876424030130176>

</comment><comment><USER3> Set up a strawman ("zomg. Look at all these people saying firefox is dead!!!").

Hack it to bits.

Mission accomplished.

rubbish.

</comment><comment><USER4> > _These devices will help either Chrome (for Android devices) or Safari (for > iOS)._

Or, possibly, Firefox, which does run on Android. It still needs work--I have it, and it's a little slow, and still keeps burning CPU even after I leave the app--but I expect it'll get usable eventually.

</comment><comment><USER5> > Firefox 4′s success is evidence of the fact that consumers are still looking > past Microsoft when it comes to browsers.

Or evidence that:

* People who care enough about their browser to download a new version when it comes out are more likely to be excited about Firefox than IE; or

* FF4 is available on every platform and IE9 is only available on Vista / 7.

</comment><comment><USER6> Shame. [http://uk.gizmodo.com/5784454/browser-speed-tests- firefox-4-...](http://uk.gizmodo.com/5784454/browser-speed-tests- firefox-4-internet-explorer-9-chrome-11-and-more) and other reasons, such as Safari/Chrome/Opera extensions galleries.

I'd appreciate downvotes come with an explanation this time, so I learn.

<comment><USER7> I didn't downvote, but I can't tell from the word 'Shame' and that link what your point is. Shame about what?

<comment><USER6> It hasn't improved enough to actually be competitive in the way that is often dragged out as the measure to go by (speed), it doesn't look any better in my view and extensions are everywhere.</comment></comment></comment>


Build Yourself a Redux - <AUTHOR> https://zapier.com/engineering/how-to-build-redux/ <comment><USER3> If you're looking for something easier to use to help you manage state in your React apps look no further than Mobx. It's pretty incredible how stupid easy it is to use, it kind of feels like cheating.

[https://stackshare.io/mobx](https://stackshare.io/mobx)

I've tried to use Redux a couple of times but I just spent way too much time in plumbing code. Code I really don't care about. To be frank this code looks terrible (no fault of the author):

        const handlers = {
          [CREATE_NOTE]: (state, action) => { ... },
          // ... a thousand more of this
        }

Not to mention, I never not once felt happy working with Redux. I'm all about developer UX and working with tools that feel nice to use.

With Mobx you just declare a variable as Observable, then mark your components as Observers, and voila: You have crispy, no-plumbing reactivity.

In a way it kind of feels like Meteor where you save data on the database and it replicates everywhere it's being used.

<comment><USER4> I never understood why a lot of this was never handled with metaprogramming. I feel like it might have something to do with Redux using constants and imports as a type safety hack, but all the ceremony drives me nuts.

First we enumerate our actions as constants...

        const ADD_TODO = 'ADD_TODO'

Then we need to create an "action creator" somewhere:

        import { ADD_TODO } from '../actionTypes'

        function addTodo(text) {
          return {
            type: ADD_TODO,
            text
          }
        }

Then we need to import that action and dispatch it when we need it...

        import addTodo from './actions'

        dispatch(addTodo(text))

Now even the same nonsense for reducers...

<comment><USER5> Speaking as someone working in a large Redux codebase, I agree with you 100%. The amount of boilerplate required to do almost anything is staggering.

<comment><USER6> Dan Abramov has said that the Redux docs were written in a deliberately verbose style to get across the ideas, and he didn't really expect people to strictly imitate that style. There's a wide variety of approaches and utilities you can use to abstract things as much as you'd like - that's entirely up to you.

<comment><USER7> As a beginner in Redux, can you tell me about the other ways to handle these boilerplate?

<comment><USER6> A few possible options:

\- Put all the action types, action types, and reducers for a given portion of the application into one file. This is known as the "ducks" structure, per [https://github.com/erikras/ducks-modular- redux](https://github.com/erikras/ducks-modular-redux) .

\- Use a utility library like [https://github.com/acdlite/redux- actions](https://github.com/acdlite/redux-actions) to generate action types and action creators for you

\- Write middleware to manage common logic for your application such as API calls

\- Skip writing action creators and declaring action constants, and just have components do `this.props.dispatch({type : "SOME_ACTION"})`.

I don't recommend the last approach, but it's _totally_ up to you, especially because what you regard as "too much boilerplate" is going to be a personal opinion. One person's "too much boilerplate" is another person's "explicit and easy to trace through the system".

</comment></comment></comment></comment></comment></comment><comment><USER8> If anyone is interested in learning this content through an in-depth video tutorial, I highly recommend Dan Abramov's two-hour "Getting Started with Redux" [1] and the excellent follow-up "Building React Applications with Idiomatic Redux" [2]. This is a great article, but learning Redux more thoroughly directly from the creator himself may be of interest to some!

[1] [https://egghead.io/courses/getting-started-with- redux](https://egghead.io/courses/getting-started-with-redux)

[2] [https://egghead.io/courses/building-react-applications- with-...](https://egghead.io/courses/building-react-applications-with- idiomatic-redux)

<comment><USER9> I came here to point out the Redux course by Dan Abramov on Egghead.io as well. I believe it's free. It's amazing how easy Dan makes it seem. It was a light bulb moment for me and finally made me understand the importance of immutability behind the React philosophy.

<comment><USER10> Would you mind expanding on that?

<comment><USER6> React's default behavior is that when a component re-renders, _everything_ underneath it in the component tree re-renders as well. If you want a component (and its descendants) to skip re-rendering, you can implement the `shouldComponentUpdate` method. You can put any logic you want into `sCU`, but the most common implementation is to compare the contents of `this.props` and `nextProps` to see if anything actually meaningfully changed.

You _can_ do a "deep equality" comparison that recurses through every nested field in both `this.props` and `nextProps`, but that's relatively expensive. The alternative is "shallow equality", which uses pointer/reference equality checks for each field in both objects. However, in order for that to be useful, you need to manage your data in an immutable fashion so that each update results in a new object/array reference, rather than directly modifying the existing objects.

So, you don't _have_ to manage data immutably in React, but doing so enables performance optimizations, and also goes along with React's functional programming influences.

<comment><USER10> Gotcha - so you see it mostly as just a perf optimization based around SCU?

Funny timing. I was actually implementing SCU using deep obj equality for the first time earlier today. I did understand the desire for immutability, but it didn't seem to be a game changer.

<comment><USER6> Perf optimization is a big benefit, yes, but it also fits with functional programming principles in general.

React's `setState()` definitely doesn't care if you mutate or not - you can `.push()` right into an existing array in state, and re-set it into state to queue the re-render.

On the Redux side of things, immutability is important for several reasons. First, pure reducer functions are more easily testable. Second, they enable time-travel debugging - without immutability, jumping back and forth in state would cause the state contents to behave unpredictably, breaking time-travel. Third, the React-Redux `connect` function relies on immutability checks against the root of the state tree to see if it _thinks_ anything has changed, and against the return values of your `mapState` functions as well. If you mutate Redux state, your connected components usually won't re-render properly, because they think nothing has changed.

</comment></comment></comment></comment></comment></comment><comment><USER11> TFW you see a thread about Redux, and you just _know_ that the comments are going to consist of nitpick complaints.

Contrarian opinion (apparently): Redux is a lifesaver when it comes to complex applications. There's a little more ceremony, but a lot more organization, a lot fewer bugs.

<comment><USER12> Exactly. I ported something I wrote in angular to react+redux. The angular version was super short and worked most of the time, but I had a bunch of weird state/race conditions/display issues I could never resolve.

Porting it to redux meant:

Wire up the reducer with enough initial state containing dummy data so render() works correctly.

Add buttons that dispatch actions. Use the debug tools to verify that the proper action gets logged. If it's an action like `LOAD_EXAMPLE` verify that `example` contains the expected name of the example.

Once the action is being logged properly handle it in the reducer. Use the debug tools to verify that the state is being changed as expected.

At this point the feature should be working. old state -> action dispatched -> reducer -> new state.

Having things separated like this means that you only ever have 3 kinds of issues:

1) The wrong action is being raised. Solution: Fix the event handlers or the action generator that calls dispatch. If the action is wrong no need to look elsewhere.

2) The reducer is returning the wrong new state. Solution: Fix the reducer. If the action was right and the new state is wrong, the reducer is the problem.

3) The app is rendering wrong. Solution: Fix the component. If the new state was correct but things look wrong, the only possible place the problem can be is the component.

Is this verbose? YES!

Is this complicated? NO! It's a lot of very simple javascript functions that do one thing at a time.

</comment></comment><comment><USER13> I've seen and understand Redux TO DO examples.

However I develop enterprise CRM app. In db there are 200k client records, 500k sales calls records. It is implemented as a standard Ruby on Rails / Postgresql web app. It works quite well. It is also pretty straightforward to implement a such app in a Java/PHP MVC framework.

Let's say I would like to implement UI using React/Redux. How should I start? For example the app has calendar month view, for each day there are 20 sales calls. So the month view has 400 sales calls and clients data displayed (date, time, client name, target group).

Do I have to put 400 sales calls and 400 clients data to a Redux store to display the calendar month view? What about client data search results and pagination? In just few clicks a user can display hundreds of clients records (thousands in case of results map view). Do they belong to a Redux store? If a user modifies one sales call record, how it is persisted in central DB? What about edge cases where some uniqueness conditions have to be checked on central DB level?

Rails covers _all_ things needed to implement my medium CRM app. When I read Redux TO DO tutorials I have a filling that they cover just 10% of what is needed to implement a full CRM app. Could you please direct me to Redux examples / tutorials how to implement a full enterprise database app (SugarCRM scale).

PS. to down voters, please write a few words what is wrong with my questions so I can learn what is appropriate to post on HN

<comment><USER14> I upvoted you, because I think this is a total legitimate question and I don't get the downvotes either. This was exactly the question I had, when I read about Redux at first. After all, the Redux docs say that "don't worry about performance, unless you have tens of thousands of objects".

So, the answer I can give you as someone, who starts to get Redux, but I'm nowhere near being an advanced user:

In your Rails app, you wouldn't render all 500k sales records on the same page as well. You'd probably have some sort of pagination. With Redux, it's the same. You don't have 500K objects in store, but only the 30 sales calls you're currently displaying. Redux contains the state of the current view and if you want to load more data, you'd have some async methods to fetch data from the DB or an API and refresh the Redux store.

Your Redux store isn't:

        [sales_call01, sales_call02, ..., sales_call500000]

It's more like:

        { viewCalls: [sales_call452, sales_call453, sales_call454] }

But still: Many tutorials are way too simple and gloss over the details. They make it sound as if Redux _is_ the architecture and the store holds all data for the entire app.

What I haven't figured out: Say, you're using Redux on the server and need to update all 500,000 sales calls. With Redux, you'd have to write a reducer that modifies the state tree. But if 500,000 sales calls don't fit into memory, how do you do it?

<comment><USER15> it doesn't sound like redux is the right tool for the job. You're looking for a stream/file.

You could still have a redux store, but it's role would be to manage the stream(process updates, keep track of errors, kill the stream if there are too many errors) rather than store the data for the job.

</comment></comment></comment><comment><USER16> I like this article. It's probably a good idea to build your own simple todo app using Redux from scratch first, and then follow this guide. It would make a lot more sense.

Using this as a place to put some thoughts on Redux after having picked it up over the past few weeks.

I have been spending the least few weeks re-writing an "offline-first" mobx React app into Redux, after it started spinning out of control and becoming unmanageable. Mobx provided a lot less guidance on how to structure a larger app (read: more than a few pages with non-trivial remote interactions)

Like React itself, it took me a few weeks to grok the philosophy and architecture, and internalize the key components so that I wasn't getting lost every few lines of code.

I had evaluated Elm earlier in the year but passed on it, as there were some interop issues, and the component ecosystem wasn't as mature as react.

Redux has had the effect of organizing my code and helping me reason about the structure, as well as providing time travel for free.

Typescript to be very helpful when building with Redux, specifically when I did something wrong, and had to refactor.

I've also been pleasantly surprised at the middleware ecosystem, and how useful and easy to configure it has been.

<comment><USER17> First I pissed off on Elm, and have been observed many the leader's reasons behind things people do not like. However, it is hard to make arguments against reasons from his point of view (e.g. [https://github.com/elm- lang/projects/blob/master/roadmap.md](https://github.com/elm- lang/projects/blob/master/roadmap.md))

Now, it really makes sense to me that he made it hard on JS interop and discourage js-wrapped packages. We should move forward, even WebAssembly team, as I imply, want to ditch javascript completely (But people don't want to say it out for unhealthy discussion) Here is a talk about what/why/some how/ on WebAssembly [https://www.youtube.com/watch?v=OH9NYzH3-74](https://www.youtube.com/watch?v=OH9NYzH3-74)

We don't need "component" things in Elm, though if you mean "module", I'm sorry. I really don't understand why people still build things on top javascript that is fundamentally and practically wrong (No need to elaborate _this_!)

</comment></comment><comment><USER18> You can replace redux with any FRP library. Your state is a signal/stream/whatever that folds over an initial state with a signal/stream/whatever of actions/messages. Your top level view component should listen and render based on that. Example: [https://github.com/twfarland/sprezzatura-acto- mario](https://github.com/twfarland/sprezzatura-acto-mario)

<comment><USER19> Yeah, I'm pretty amazed at the amount of attention that a simple "fold"[1] gets in JS-land.

Yeah, OK, Redux (etc.) is also a little bit of a pattern for sort-of-algebraic data types, but really... I prefer using a language that actually supports algebraic data types natively like Scala.js, Reason, Bucklescript, js_of_ocaml or GHCJS.

I appreciate that these may not be an option for _everyone_ , but at least one of them _should_ be an option for the _vast_ majority of current frontend developers.

[1] Well, technically I guess it would be a foldM?

<comment><USER20> Yeah, it's pretty trivial to rebuild Redux with a couple of functional building blocks, or my personal favorite, with RxJS and the scan operator.

I'm surprised that didn't pick up more yet.

</comment></comment></comment><comment><USER21> I have to deal with Redux at work and I absolutely hate how much code I have to write to flip a binary in my React component!

I used MobX on the side projects and I absolutely love it! I might be biased but I think MobX is so much better for any size project. Redux is just too good at marketing and their "Hello world" looks very very interesting and reasonable but it doesn't scale. When you have multiple people working on the same codebase it becomes a hot mess!

If you're starting a project, give MobX a shot and see how it goes.

<comment><USER22> Oh man, everyone's talking about MobX in here, and I've never really looked at it. This looks pretty awesome. I don't particularly enjoy using Redux either, so I think I might try this out on my next project.

I'm looking for some replacement libraries from the Redux ecosystem. I've already found [https://github.com/pinqy520/mobx- persist](https://github.com/pinqy520/mobx-persist), which looks pretty good.

What do you use instead of redux-saga or redux-observable? E.g. for async stuff like ajax calls, or listening for events and emitting new events?

Concrete example: You want to listen to a variety of events in your app, and send analytics. Some of your analytics events require looking up parts of the state and doing some processing. This is really easy to do in redux-saga, but how would you do this with MobX? Or would you use something else for this?

EDIT: Ah, I think I was looking for "autorun": [https://mobx.js.org/refguide/autorun.html](https://mobx.js.org/refguide/autorun.html)

</comment></comment><comment><USER23> One advantage of Redux that people tend to miss is the serializable state object which is incredibly helpful for local logging and remote debugging. It's the reason we built LogRocket (though now we have a bunch of other features for general web apps).

</comment><comment><USER24> I wrote a similar article last month on the same topic but it's much more simplified with CodePens to detail the way:

[https://antjanus.com/blog/web-development-tutorials/front- en...](https://antjanus.com/blog/web-development-tutorials/front-end- development/build-alterdux-redux-like-redux-compatible-library-scratch/)

It covers only Redux and not React which I think is a little more useful. It DOES cover Enhancers.

Anyways, I've seen this article circulate and I'm glad people are interested in the inner workings of Redux!

</comment><comment><USER25> Am I missing something new with object literals or is this an error:

          window.state.notes[id] = {
            id,
            content: ''
          };

<comment><USER6> Looks like a standard ES6+ object literal to me. ES6 allows you to shorthand `{someVariable : someVariable}` as just `{someVariable}` (ie, create a key whose name is the variable name and whose value is the variable value). There's some good overviews of ES6's new syntax and features at [https://ponyfoo.com/articles/es6](https://ponyfoo.com/articles/es6) and [http://es6-features.org/](http://es6-features.org/) .

<comment><USER25> Thanks that is exactly what I was asking. I didn't know about that change.

</comment></comment></comment><comment><USER6> This is a great article! As I commented on the post itself when it was published, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at [0]. That includes a section of "Redux implementation walkthroughs" at [1]. This is probably the best article of that type that I've seen. It not only covers the core of Redux, but also builds miniature versions of Redux middleware and the React-Redux `connect` function. I already added it to my list, and definitely recommend it.

Readers may also be interested in my Redux addons catalog at [2], which includes links to hundreds of Redux middleware, utilities, and other useful libraries. That includes multiple ways to batch dispatching of actions.

[0] [https://github.com/markerikson/react-redux- links/blob/master...](https://github.com/markerikson/react-redux- links/blob/master/redux-tutorials.md#redux-implementation-walkthroughs)

[1] [https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links)

[2] [https://github.com/markerikson/redux-ecosystem- links](https://github.com/markerikson/redux-ecosystem-links)

<comment><USER26> I am probably going to get downvoted to hell for this negative comment, but please stop doing this. I am really tired of seeing your "big list of links" everywhere I go[0][1]. If I click on anything even mildly related to React, Redux etc., on Reddit, HN etc. I always find the same thing.

[https://www.google.com/search?q="I+keep+a+big+list+of+links"...](https://www.google.com/search?q="I+keep+a+big+list+of+links"+site:news.ycombinator.com)

[https://www.google.com/search?q="I+keep+a+big+list+of+links"...](https://www.google.com/search?q="I+keep+a+big+list+of+links"+site:reddit.com)

<comment><USER27> I upvoted you. This feels a lot like marketing spam. I think we instinctively upvote comments like this, but we really don't need it on every react/redux post here. Is the list popular because it's useful or because the author tirelessly promotes it? No way to tell.

Besides the above, both react and redux have excellent official documentation, and tutorials get stale.

<comment><USER6> I agree that both the React and Redux docs are good, although I'm biased - <USER2> wrote the Redux FAQ and "Structuring Reducers" sections for the Redux docs.

That said, the official tutorials and reference sections can only cover so much info, and other articles often go into more detail. For example, the React docs discuss the idea of "controlled inputs", but Gosha Arinich's series of articles on React and forms [0] go into much more detail on the concept and how to apply it. The React docs mention immutability somewhat in the "Optimizing Performance" section, but there's other articles that discuss the why and how in greater detail [1].

Similarly, the Redux docs try to teach the basic concepts and important principles, but articles like "Redux Step by Step: A Simple and Robust Workflow for Real Life Apps" [3] and "Advanced Redux Entity Normalization" [4] go into a lot more detail on some useful real-world concerns.

In the last couple big React-related threads on HN, some people complained that there were no all-encompassing guides for React, the way there are for things like Django or Rails. A lot of that is because Django/Rails are much more convention-driven, so there really is more of an "official" way to do things. With React, people are free to pick and choose the pieces they want, and that means that a single guide is somewhat impractical. (The React team also does not want to try to push or enforce specific tools as "blessed", partly because Facebook has its own ways of using React that are different than the community, and also because they believe in letting the community build things that solve their own use cases.) As a result, in a lot of ways my list is about as close to a "guide" as you're probably going to find for React best practices and resources.

[0] [https://goshakkk.name/on-forms-react/](https://goshakkk.name/on-forms- react/)

[1] [http://reactkungfu.com/2015/08/pros-and-cons-of-using- immuta...](http://reactkungfu.com/2015/08/pros-and-cons-of-using-immutability- with-react-js/)

[2] [https://hackernoon.com/redux-step-by-step-a-simple-and- robus...](https://hackernoon.com/redux-step-by-step-a-simple-and-robust- workflow-for-real-life-apps-1fdf7df46092)

[3] [https://medium.com/@dcousineau/advanced-redux-entity- normali...](https://medium.com/@dcousineau/advanced-redux-entity- normalization-f5f1fe2aefc5)

</comment></comment></comment></comment><comment><USER28> Wrote a similar piece last year if you like this kind of thing. I love learning stuff by implementing it myself:

[https://medium.com/@davedrew/lets-write- redux-975609b0358f](https://medium.com/@davedrew/lets-write- redux-975609b0358f)

</comment><comment><USER29> Shameless Plug: I gave a talk last year explaining similar concepts [https://github.com/neebz/react-redux- presentation](https://github.com/neebz/react-redux-presentation)

</comment><comment><USER30> [https://martinfowler.com/eaaDev/EventSourcing.html](https://martinfowler.com/eaaDev/EventSourcing.html)

</comment><comment><USER31> "Redux is a simple library" woah woah stop right there. How is this:

        const handlers = {
          [CREATE_NOTE]: (state, action) => { ... },
          // ... a thousand more of this
        }

simple? This looks horrible. Every time you want to work on code that modifies data, you have to switch to the one file where you keep all the data-modifying functions? Seriously?!

Freezer [https://github.com/arqex/freezer](https://github.com/arqex/freezer) is a much, much better experience. You just shove immutable objects down the component tree, and they just come with methods that modify "them" (by actually changing the data tree). It has an event system as well for when you actually want to centralize actions. Works great with Polymer, by the way!

<comment><USER10> > you have to switch to the one file where you keep all the data-modifying > functions? Seriously?!

Of course not - and I strongly urge you to think through things like this more deeply before writing them off.

Redux is a really good and well-thought-out library. I'm sure you could think of multiple solutions to the problem you just proposed, including splitting that file into multiple files. It would be a shame if you never took the time to understand the library because you got caught up on simple trivialities like this.

<comment><USER31> Sure you can split the file, but you still _have_ to separate it from the actual UI event handler.

It might be well thought-out but it's more complicated than it needs to be.

<comment><USER10> Of course, and that's the huge win of Redux. Forcing you to separate out state updates wraps them in a layer of indirection and allows you to operate on them at a higher level than otherwise possible. This makes ordinarily difficult operations simple and elegant. You can use the higher level of abstraction to get undo for free, or replay them to find bugs, time travel, or send them across a server to get a multi user app. What you're saying is "more complicated than it needs to be" is in fact _the_ revelatory idea of Redux.

I reiterate myself: you should try to understand Redux more deeply before writing it off. You are doing it a disservice.

<comment><USER31> Why do you need this separation to get these things?

In Freezer, you can do transactions directly in your view event handlers, and one transaction is one update, and .on('update', (currentState, prevState) => {…}) you can save the prevState into your undo log. And _when you want_ to separate a data manipulation action, you _can_ use custom events to do so — but you aren't forced to! It keeps simple operations simple.

<comment><USER10> Are you really just opposed to doing things in different files?

I'm going to divert the conversation away from Redux entirely if that's the case. You should invest in an editor with good "go to definition" support. I had a similar problem, but as soon as I did this, the pain threshold for switching files dropped to nearly 0.

(If that's not the case, do keep on mind that a file separation is totally unnecessary. You could write your state manipulators inline if you wanted. I feel it is a bit organizationally messy, but hey, whatever you like.)

<comment><USER31> go to definition is still an extra keystroke :P

I'm just excited about Freezer, and don't care much about Redux.

<comment><USER10> Well I hope you realize that coming onto a topic about Redux and claiming Freezer is better without really understanding Redux internals may not be the best way to proselytize. :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> I am not getting fully redux yet, but from my understanding it is sorta like app-wide message bus with message handlers. Is my understanding correct?

<comment><USER33> Not really. You have a state model, once you change it a new immutable slice is created, maintaining the nodes that didn't change. That makes it possible to check for changes with reference equality (old === new), which is fast. Components simply pick a portion of state they're interested in and render once it changes.

That makes your app transparent, meaning what you see is just a reflection of state. State changes, app reacts, state changes back, app is the same as it was. You can slide through your apps history in dev-tools and see it construct/deconstruct itself, it's also very easy to inspect and see what action led to which result: [https://camo.githubusercontent.com/a0d66cf145fe35cbe5fb34149...](https://camo.githubusercontent.com/a0d66cf145fe35cbe5fb341494b04f277d5d85dd/687474703a2f2f692e696d6775722e636f6d2f4a34476557304d2e676966)

Redux is a pattern basically, it's pure javascript, no magic, and little behind the scenes stuff.

</comment></comment><comment><USER34> Or do yourself a favour and use Elm.

<comment><USER35> Or [https://github.com/Day8/re-frame](https://github.com/Day8/re-frame)

</comment></comment><comment><USER36> Making simple things Complex !!

<comment><USER37> Yeah, while (hopefully) making complex things manageable.</comment></comment>


64 megapixel projection system opening this summer in Chicago - <AUTHOR> http://www.chicagotribune.com/entertainment/ct-ent-0622-focus-adler-20110621,0,6400616.column

<comment><AUTHOR> note the imagery is made by me and the Electric Sheep, they commissioned a segment for the premier as well as a 4-channel HD piece for the foyer.</comment>


Pixel Perfect - <AUTHOR> http://daringfireball.net/2012/08/pixel_perfect <comment><USER2> I find it quite surprising that the author is so passionate about typefaces, but serves his own blog in Verdana. Good thing it is not called JaringJireJall.net [1]

That being said, I really think the days of sans fonts are close to over. 10 years from now, we will all be reading on 300 dpi screens and taste in typography will return to being the dominate feature of design.

I can't wait until I can read the Economist online in the correct typeface. I can walk down an airplane isle and recognize that font in less than a second. The New Yorker also uses a font that seems to be unique. The Atlantic needs a custom typeface.

I am so excited that high DPI screens are going to be the norm. The web design world as we know it today is about shitty flourishing with artwork. 10 years from now it will be about designing beautiful glyphs that represent the brand.

[1] J is particularly gross in Verdana.

<comment><USER3> I'm interested in this. As someone who doesn't pay that much attention to typography (beyond the obvious 'Papyrus is bad' stuff) what makes individual typefaces preferable over a standard typeface for all similarly structured content?

(Besides branding, that is.)

<comment><USER4> It's pure marketing. There's no objective, measurable difference.

<comment><USER5> Yes there is. Certain typefaces are objectively easier to read than others, and some work better for certain content than others. Some are best for body text, some are best for headlines, etc. Some are optimized for low resolution screens, some for print (and as such work well on high resolution screens).

<comment><USER6> A great recent example that appeared on HN was the typeface designed for road signs, which the designers then put through Germany(?)'s test suite for legibility at distance in various road conditions and determined the new font was objectively legible at greater distance than all previous standard road- sign fonts with which it was compared.

[By request, I found the original article: [http://ilovetypography.com/2012/04/19/the-design-of-a- signag...](http://ilovetypography.com/2012/04/19/the-design-of-a-signage- typeface/) ]

<comment><USER7> Do you happen to have the link to that? Must have missed that and I'd like to read it.

<comment><USER6> [http://ilovetypography.com/2012/04/19/the-design-of-a- signag...](http://ilovetypography.com/2012/04/19/the-design-of-a-signage- typeface/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> So more pixels is great. Is it really _that_ great?

I feel like there are people who look at their devices and people who look at what's displayed on their devices.

For me, text is text is text. I'm looking at it, not so I can enjoy how crisp it is (or isn't), but so I can consume those words and get them inside my head.

I find (I've played around with high DPI devices) that while they do look nice, the niceness is quickly forgotten when I actually start using them for something _other_ than looking at how nice they look. Likewise, going back to use lower DPI devices you notice the difference, until you stop looking for it and actually get work done.

I'm not saying that I don't care entirely, I just... I wouldn't go and buy a new device solely because its resolution was higher. It will be nice when these devices eventually make it to me, but I'm not really bothered either way.

If we were to talk about recent revolutions in the home computer I'd rank multi-core CPUs as a much more important change. No longer can one broken app go on a rampage and block you out.

Anyway, tl;dr; it's great he's passionate about it, I just don't see it as such as important thing.

<comment><USER9> Some people make a point of appreciating the small joys of life. Others do not. Much effort and attention is lost on the latter.

<comment><USER10> Some people focus on the substance rather than the style. Others do not. Much effort and attention is lost on the latter.

<comment><USER11> I find myself a million times more "productive" in Sublime Text 2 with a "light" theme (Soda Light) than previously when it had a dark theme (the default one). I do look for substance, but we are all machines and can't fight over our limitations. My eye thanks me when it can visually see an "orange" function instead of having to look for a "black" (i.e. misspelled) fuction in code. It's not my fault - eyes appreciate semantically color-coded (or typeface-coded) blocks of code/article/etc ( _my last sentence is poorly phrased, as a non-English it's hard to articulate what I want to say but I'm sure you understand what I tried to say_ ).

</comment></comment></comment></comment><comment><USER12> I'm probably just blind, but I have trouble seeing the difference in display quality based on resolution. And I don't think I'm alone.

When I was at the Apple Store after they launched the new iPad, there were several people who confused the iPad 2 for the new iPad. And even after being shown they were looking at the wrong one didn't go, "Oh... this one looks much better!", rather I heard from multiple people a line like, "Oh, what's the difference?"

I've looked at the HTC Titan side by side with an HTC Rezound (one of the lowest PPI versus probably the highest PPI phones) and it's really hard to tell the difference unless you're really looking hard. I think in part because even the worst PPI on phones is actually quite good.

I haven't seen the retina display on the Mac Book Retina Display, but I do hope that it lives up to the hype, as I was sorely disappointed by how incremental the iPad retina display was (versus the iPad 2).

(Note, the iPhone jump to Retina Display was a visibly dramatic improvement.)

<comment><USER13> Your eye sight must be terrible. The retina iPad is a _vast_ improvement over the iPad 2 for me.

<comment><USER14> Note that the whole point of the "retina" branding is that at a _certain distance_ you will no longer see any improvement as you move further back. If those people were standing sufficiently far back (as you might when looking at a store display iPad) then the retina effect will kick in.

</comment></comment></comment><comment><USER15> I'm with Gruber. The display is sexy. And good typography is beautiful on it. But my experience with Safari at the Apple Store was that the FPS when scrolling through pages is noticeably low. (Also choppy enough as to be frown- inducing were native apps I tested, like REAPER.) I know it seems like a strange thing to complain about (who cares what FPS a desktop app runs at?), but it's something you have to see and feel to judge the impact on your overall experience, IMO.

Lion inverted trackpad scrolling so that when you drag your two fingers down, the content follows them, like there is a physical connection between your hand and the page. On the Retina MBP, that illusion was mostly lost for me. I'm actually curious to know if owners of the Retina display get used to this chugginess, or if it's still kind of a big deal, even after awhile.

I know only a little bit about hardware composition in WebKit—and webpages are definitely not assembled "entirely" on the GPU. I suspect that there are gains to be made there, just in terms of how much work is being offloaded. Even if desktop Safari were to do what my old iPhone 3GS would do—separate the thread handling scrolling from the thread doing the painting, so that you could actually scroll ahead of where the renderer had filled in content, and see a checkerboard pattern—might be a better feeling alternative. Then again, this could already be happening. I haven't kept up with WebKit changes. Credit to Apple for pushing the boundaries. But I want my buttery smooth page renders, damnit.

/end entitled whining

<comment><USER16> Was it running Lion or ML? I recall some reviews mentioning that ML had specific optimisations to improve scrolling performance.

<comment><USER15> It was Lion. I'll revisit my impressions. It'd be nice to collect some hard data too...

</comment></comment></comment><comment><USER17> Unfortunately, a laptop is still a laptop. Small keyboard, inferior mouse (or lack thereof), single display, performance constrained by battery life. The performance margins are getting slimmer, but for a little over the price of the high end MacBook Pro (about $3000 with tax), I could build you a 64-core AMD G34 with 64 gigabytes of RAM, that would utterly destroy the Macbook performance-wise. Obviously, to each their own. I don't think the author is protein-folding or raytraycing, so this computer probably suits his needs better. Alternately, I could build a six-screen Beowulf cluster using 6 Nexus 7 tablets for $1200 (Tegra 3 performance is getting close to Core-Duo performance).

<comment><USER18> > for a little over the price of the high end MacBook Pro (about $3000 with > tax), I could build you a 64-core AMD G34 with 64 gigabytes of RAM

Can you detail how you would achieve that ? 3000 $ seems insanely low to me.

<comment><USER17> <http://i.imgur.com/Gy9GU.png>

Just priced it out on Newegg.com (see screenshot above) -- does not include shipping, power supply, etc...but gives you a general idea of the price range -- overall, you could probably do it for around $3.5k-$4k, or easily 3k if you dropped 2 processors, which would still be a beast of a machine...

</comment></comment></comment><comment><USER19> It's a shame Google Chrome still doesn't render CSS3 fonts correctly on Windows. The strangest thing about it is that they barely even seem to acknowledge that it's an issue.

[http://stackoverflow.com/questions/8950164/horrible- renderin...](http://stackoverflow.com/questions/8950164/horrible-rendering-of- font-face-in-chrome)

If you've noticed that web fonts look terrible on Windows / Chrome, please star these issues!

<http://code.google.com/p/chromium/issues/detail?id=137692> <http://code.google.com/p/chromium/issues/detail?id=91899> <http://code.google.com/p/chromium/issues/detail?id=102371>

<comment><USER20> The keyword you're looking for is 'DirectWrite'. Here's a post from January this year indicating they're working on it: [https://groups.google.com/a/chromium.org/d/msg/chromium- dev/...](https://groups.google.com/a/chromium.org/d/msg/chromium- dev/5BQYLaalCoY/LiVE-A9RZpoJ)

</comment></comment><comment><USER21> _Think about that: a laptop with no performance tradeoff compared to a high- end desktop._

Compared to a high-end desktop which has barely seen updates since 2010, and includes a GPU released in 2009, sure.

<comment><USER22> The point being made was that it is a desktop- _class_ machine. Generally, laptops have always been convenience and portability, and desktops have had power and price point.

Obviously there are exceptions to any rule, but in this case, the display is actually _better_ than any desktop I've seen, and the SSD and CPU/GPU give it all the power necessary for 95% of users. The price point is definitely high, but otherwise it seems best of both worlds.

<comment><USER23> You've always been able to get a laptop that was as good as the desktops of 2-3 years ago, and never one that's as good as the current ones. Saying "desktop-class" is a nonsense; this is no different from previous efforts.

Now, if you're saying we've reached the point where the extra CPU etc. of a desktop are not worth it for most users, then I agree with you. But again that's nothing specific to the macbook air; any modern laptop will have the same properties.

</comment></comment></comment><comment><USER24> > Think about that: a laptop with no performance tradeoff compared to a high- > end desktop.

It helps if that high end desktop hasn't been updated in _two years_.

For CPU performance, laptops lagging a couple of years behind desktops is more or less business as usual.

<comment><USER25> Still, we're talking about a Xeon here, not your typical desktop-variant Core Something. It was a powerhouse.

<comment><USER24> The benchmarks were lightly threaded, for which Xeons basically offer no advantage - they let you have more cores in a machine, and that's about all. For rendering and encoding, the 12 core 2010 Mac Pros would still _slaughter_ a retina MBP. No competition.

There are many impressive things about the retina MBP, but CPU performance is not one of them.

<comment><USER26> I would say the CPU performance is very impressive, sure a 12 core will beat it at rendering, but the single threaded performance is amazing, and the super fast SSD makes it basically the fastest Mac ever in general usage.

</comment></comment></comment></comment><comment><USER27> I kind of had the same thought too, as I walked through the Apple Store today and took a gander at some of the Retina MBP's. I thought: in as soon as 5 years, people are going to look at the pre-Retina MBP's and wonder, how did we ever live with 160 DPI displays? All of these jaggedies, this unsharp text, these blurry textures in iCal -- all this ugliness that you have to squint your eyes to see. Who would want that?

And for a moment I regretted I'd gotten an Air instead of a rMBP. But then I realized... what I have is good enough. It is. It's great. And there will be better products to come. And I'm not going to lose any sleep over it.

But it is interesting to think about a future world where pixels are antiquities, merely "remember when's".

</comment><comment><USER28> One thing that I've noticed as pixel density is increasing, is many 3rd party UI elements _aren't_ increasing in size relative to monitor improvements. I remember using Photoshop on my old LC475 in the 90's and not having to squint and hold the mouse steady to select the tool I wanted.

Please tell me someone else has noticed this? Or am I just getting old.

<comment><USER29> Monitor pixel densities haven't increased that much, they've been limited by having to keep interface elements visible. It's only easy for apple because they just doubled the density in both directions. Any intermediate numbers of pixels would have impacted usability.

</comment></comment><comment><USER30> So, here's a question for those who actually have one of these mega-res displays... how's the terminal? Or any other typically aliased text? Secondly, how well does it work in a dual/2+ boot situation? Obviously other systems have the drivers for such large displays, but without knowing how to scale it... Is there any way to set the hardware to simply enlarge everything x2 in the absence of serious display drivers (for example, a desktopless linux or bsd)?

<comment><USER31> re: A terminal: probably fine, albeit small. Running at 2880x1800 without any scaling isn't terrible, but it would quickly drive your eyes to escape your skull. I can't say for sure what would happen under Linux given only a terminal, but I imagine things would be pretty small until you got it using a different resolution than the native resolution.

Terminal emulators are fine, but I assumed you meant the other kind. Terminal emulators look great, as does every text editor I've used (MacVim, vim in a terminal emulator, Sublime Text 2, TextMate 2, Xcode [looks great, but it's unfortunately still a lousy IDE], etc.).

re: Dual boot, also fine in my case, though I only keep Mac OS and Windows 7 installed right now. Windows 7 in particular is an issue, as DPI scaling only affects some programs (so where on Mac OS you'd get pixel-doubled views or text, on Windows you get windows that aren't scaled at all, such as Chrome). If you have dual monitors, Windows is particularly painful, as DPI scaling is system-wide rather than per-screen. I haven't tested Windows 8 and likely won't until after it's been released.

The best route I've found is to simply set the display to 1920x1200 or lower and scale it up on Windows. Windows 7 just doesn't handle high resolution stuff particularly well -- it's not bad, but things just aren't all there. I expect Windows 8 will be better.

I couldn't say what your options are on a desktopless Linux/BSD system, but I would imagine that there's something you could do, even if that something is just using a larger font.

</comment></comment><comment><USER32> I totally agree about the Lucida Grande thing. It's weird seeing fonts like Lucida Grande and Verdana on such a nice display.

<comment><USER33> The Retina MPB has opened up a whole world of fonts. It's amazing how much attention I pay to them when I visit websites now.

There is a downside to such a nice screen -- it makes me painfully OCD. On my previous laptop, the screen was such crap that it didn't bother me. On this one, I notice every subtle flaw.

For instance, image retention (which I'm now convinced that after swapping three of these things out eventually affects all of the LG panels used in the MBPR [Samsung panels do not seem to have the issue]).

Then there's the fact that it's just slightly not bright enough for my liking. I find myself hitting the brighten button a lot when it is at max. No matter that my old laptop looks downright dim next to this.

And despite the fact that it is an IPS display, the colors do change quite a bit with viewing angle. A solid white screen kind of shimmers in luminance and tint when moving my head.

And the black level isn't pure black.

And 220ppi isn't _quite_ enough to complete the no-pixel illusion for me.

And the color gamut could be a smidge greater.

It's like the uncanny valley of screens. It's so close to perfect, but not quite there, that it leaves me paying a weird amount of attention to it.

But I wouldn't trade it for any other.

</comment></comment><comment><USER9> I've recently been studying typography and it's been really heartbreaking to realize that what differentiates a good and a bad typeface onscreen is how it well it renders. Plenty of great typefaces are just unusable. Most fonts distort wildly as you step up/down in pixel size. I didn't start in print design, but man is web design primitive in comparison!

<comment><USER30> I have to admit that rage was starting to burn inside of me until I read your last sentence– that's one of the reasons why I take so few jobs for the web these days. I always thought that web technologies would far surpass what we could do in print (which, as a lead type junkie, sounded pretty amazing) and then I grew up, started dealing with W3C &c;– now here we are, only in the last two years or so getting a _reliable_ (and compliant) way of using more than just Times, Georgia, Helvetica, Arial, &c... It's slow, slow progress but it's great to see that while those issues are hashing themselves out that the pixel problem is practically resolved. (Though I should note that pixels or not, setting a spread to be displayed digitally was never that much of a problem if it didn't have to be displayed in the browser. Sure, some fonts have shitty hinting but the ball is at least in your court.)

</comment></comment><comment><USER34> > Dots were how computers rendered everything: pixels on screen, dots of > ink/toner on paper

The writer seems to ignore the world of X-Y plotters and vector graphics workstations, which have been around since the very early days of computing.

</comment><comment><USER35> Color me surprised to read another frothing fluff piece for an Apple product from arch-apparatchik Gruber.

Doubling the display density of a laptop screen qualifies Apple for the Nobel Peace prize now, or something.

<comment><USER11> I'm not sure what your critique is. He's not a politician or TV host _getting paid_ by the bad Apple to write/say nice lies about them... He writes about Apple, and people visit his website to read what he writes. It's that simple.

If you disagree with any of his points, please post them in this topic. But don't go dismissing it just because it's from _arch-apparatchik Gruber_.

<comment><USER35> As he himself has written on his blog, in exchange for this kind of PR he gets invited to private meetings inside Apple.

<comment><USER36> Does he? What are you referring to? The Mountain Lion presentation? Apple invited loads of journalists to that, they just also included Gruber there.

<comment><USER35> <http://daringfireball.net/2012/02/mountain_lion>

_And instead of a room full of writers, journalists, and analysts, it was just me, Schiller, and two others from Apple — Brian Croll from product marketing and Bill Evans from PR._

<comment><USER36> Sure. And? What's your point? Apple met separately with loads of journalists. I don't see anything special about how they treated Gruber.

<comment><USER35> Yeah you're right. An exclusive, face-to-face meeting with the senior vice president of marketing is nothing special. I'm sure things like that don't influence his writing about Apple at all.

<comment><USER37> That meeting happened in 2012. Gruber's been writing Daring Fireball since 2002. <http://daringfireball.net/archive/>

<comment><USER35> I've been reading him on and off the whole time. Once upon a time he was actually worth reading but I don't even bother now because I can practically write his tech-Pravda pieces in my head.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> My 2009 MacBook pro just died and I'm debating which Mbp to get. I'm leaning on the non-retina display because of the reports of FPS sluggishness. I'm very aware of frame rates.

Also, I keep hearing programs like photoshop and so on aren't optimized for retina yet. As much as I'd like to be bleeding edge, and even help develop for it... I can't help but feel it's at least another year before its more viable to go retina.

I don't want FPS lag. I'm probably going to pick up the 1,700 model and add 3rd party ssd + 16gb ram.

</comment><comment><USER39> I bought a new MacBook Pro during WWDC this year. I had the option to get the RMBP, but I didn't, and I don't regret my decision. The performance vs. cost ratio of this laptop is significantly higher (plus I get a disc drive), and honestly with the high-res screen, I have to be a lot closer than my normal viewing distance to notice a difference between this and the RMBP.

Only thing I think I think I'll regret in the future is not getting an SSD. Oh well. I like my storage space more than my speed.

<comment><USER38> Since you got a non retina MBP you can upgrade your storage to a SSD and at a discount.

</comment></comment><comment><USER40> I found this to be true with my phone. I currently have an iPhone 4 and I want to switch soon. However, looking at the other phone screens hurts my eyes. The image seems blurry.

</comment><comment><USER41> Gruber's full of shit. I had a 1600x1200 17" monitor in the 90s. LCDs were a step back in pixel density, and retina means they're JUST NOW catching up to where I was 15 years ago.

<comment><USER42> That's incorrect. MBPs were available with better density than your figure starting 5 years ago (1920x1200 @ 17"). I have one from 2009 and it continues to be a joy.

<comment><USER41> You still to this day can't buy a 17" 1080p monitor. LCDs are still behind my 15-year-old CRT.

<comment><USER43> my old T61p's 1920x1200 15.4" panel disagrees.</comment></comment></comment></comment>


Show HN: I made an app for coffee lovers. - <AUTHOR> https://play.google.com/store/apps/details?id=com.hawkinbj.Caffeine

<comment><USER2> I'm not a coffee drinker but most of my friends are. One thing you might want to add is reviews and ratings of K-cups for those that use Keurig brewers and the like. A friend of mine ended up having to buy a lot of different varieties before finding one he liked.</comment>