Yikes, you are absolutely right, but I think the way that language is fluid we are at most 5 years away from "kids" not being able to recognize the term "smiley". Emoji is becoming the defacto catch-all term.
Well now I have to ask... Presumably that's ascii art, and :) is an emoji. And :-) is also an emoji. So how many characters/rows before an emoji becomes ascii art? Also, I take it emoji is the ascii, and emoticon is the image. Also, emoji sounds plural to me - I take it it's not.
In Japanese, they call ASCII-art style smiley and a pictogram separately. The ASCII-art one is "kaomoji" (where kao means "face" and "moji" is letter) while the pictogram is strictly an emoji (where "e" means "picture").
Of course, one could argue that since the word is now being used internationally, it's not necessary for them to be interpret in the same way as its roots.
The term emoticon refers to a series of text characters (typically punctuation or symbols) that is meant to represent a facial expression or gesture (sometimes when viewed sideways), such as ;-).
Emoticons predate Unicode and emoji, but were later adapted to include Unicode characters.
An emoji is the name for an image/drawing which represents a single specific unicode character, not a series of characters. The name comes from Japanese e (絵, "picture") + moji (文字, "character") [1]
Multi-character ones would be called smileys, emotes, or emoticons. The confusion comes from the fact that many messengers will automatically replace multi-character emotes with an emoji.
¯\_(ツ)_/¯ is a type of emoticon referred to as kaomoji common in Asia (and now worldwide), but like the happy face :-) it is an emoticon (kaomoji use a wider character set than the ASCII commonly used in Western emoticons)
Emoji is a Japanese loan word 絵文字 (literally picture character), you can read more about them:
Emoji are the images that you often see spammed all over the place: , , , , , ...
And "Emoji" is actually plural. "Emojis" is sometimes used as plural, but it's actually wrong.
Emoticons are then usually made up out of multiple ASCII-symbols, although general Unicode is by now also in use: :), :-), :|, :[ ...
And then for the "ㄟ(ツ)ㄏ"-Emoticon, you can get more specific about it and call it "Kaomoji". Kaomoji are not Emoji, even though the two sound related, and are actually a more horizontal style of Emoticons, so basically any Emoticon which you can read without turning your head: ㄟ(ツ)ㄏ, ^^, (っ´▽`)っ, (╯°□°)╯︵ ┻━┻, ఠ_ఠ ...
The process seems to change every version of OS X for some reason. So basically this script runs the appropriate command for whichever version you are using.
I've personally found myself Googling it at least once for each version.
It gets more annoying if you want to explain it to a non-technical OS X user. Maybe this little repo will help them converge on a command alias for the future
The content is that it's tricky to truly flush the DNS cache on OS X and the command to do it gets changed a lot with new releases. It's very annoying because it makes working with DNS very painful.
Any time I need to flush dns cache, I simply google "flush dns cache mac" and top result shows you the simply command to run: https://support.apple.com/en-us/HT202516
Having a simple command such as "reset dnscache" or something of course would be nice, but since it can already be done in a matter of seconds with a quick google I can't imagine it's that much of concern for apple of many developers compared to other issues.
Could someone add some context please? I see that apparently the method to flush the DNS cache changes between versions. Is there a deeper reason why this is necessary?
The command doesn't fail but does it actually flush the DNS cache, or does it flush the Directory Cache which isn't used for DNS anymore (or possibly at all, on my El Cap machine flushing succeeds but any query of the cache content or its statistics replies "Unable to get details from the cache node")
The command did flush the Directory Service cache, but DNS is no longer part of it. You can still use its query command though.
dscacheutil -q host -a name www.example.com
On the topic, easiest way to see if dscacheutil -flushcache work or not is to probably do something like:
dscacheutil -q host -a name www.example.com
# Make sure it's in the cache prior to running.
sudo dscacheutil -flushcache
dscacheutil -q host -a name www.example.com
# Notice if there's a slight delay for the lookup.
sudo killall -HUP mDNSResponder
dscacheutil -q host -a name www.example.com
# Notice if there's a slight delay for the lookup.
"macOS" has a tendency to cache stale DNS. But over the years they have changed the commands to flush the cache, so you end up googling how to clear the cache, checking your version of osx, and pray to the DNS gods that it will work this time.
* Snow Leopard and earlier use lookupd for DNS resolving (`dscacheutil -flushcache`)
* Since Lion, they switched from lookupd to mDNSResponder, presumably for Bonjour protocol support (`killall -HUP mDNSResponder`)
* Yosemite switched to discoveryd that basically is a rewrite of mDNSResponder (`discoveryutil mdnsflushcache`)
* Due to a lot of problems with discoveryd, they switched from discoveryd back to mDNSResponder since v10.10.4 (so we're back to `killall HUP mDNSResponder`)
In 10.10 Apple replaced the then 12-year-old mDNSResponder, which does DNS (apart from other things) with "discoveryd", which had issues so they reverted the change.
How is that any different than installing any opaque binary app?
It all comes downs to whether you trust the source.
At least with the "curl http://xxx | sh" method you can also examine the contents of the script before running it, and even opt to run it after downloading it and checking it locally.
With binary apps off of internet sites, which is what people install and use dozens of times a month, no such luck.
In this case, you have no idea if the connection is MITM'd because of http. You must assume the source untrustworthy, because you don't know who it is. Additionally, assuming the page's source (from which you copy this command) is over http, you must assume the website has compromised (e.g.) your clipboard on copy and you're pasting in malicious unicode characters or whatever. People should have an inherent distrust of binary blobs, too, for whatever that's worth. Same caveats over serving the download over http, with the added benefit of not being able to read the source (necessarily), with the added bonus of now having to assume the build machine has not been compromised.
>People should have an inherent distrust of binary blobs, too, for whatever that's worth.
All you said are true for binary blobs as well. The page could be MITM, etc.
"curl xxx | sh" style deployment has all the same disadvantages of binary blogs, but has the added advantage that you can download and check the code before executing it.
Why is changing names seen as a negative thing? My company also changed its name a month ago, and several customers leaving negative feedback said included this phrase or something similar, while to my recollection none of the positive feedback (which we have way more of) took mention of the name change.
When a company renames itself, everyone that works with that company needs to make changes. Financial records, password and account management, , internal documentation, integrations, etc all have to change. Plus, eduction on the change takes time. People who occasionally interact with the company are going to be confused for months afterwards. It's very rare that something positive comes out of the name change for existing customers. The same thing is likely for product renames - platform version detection in software, browser/OS categorization in analytics tools, documentation, etc. It just makes work for everyone involved.
And what's the point? MacOS X was a decent name, with good recognition and trust. If people were interested in understanding the back story to the name, they could, but the 'X' didn't scream '10' to people who weren't familiar with the history, so there wasn't a ton of confusion.
It's not seen universally as a negative thing (by people who know about branding and marketing).
It is, however, used as a negative thing by people who would vent regardless of the name change, and just want to emphasize they care so little about you that they can't even remember your name("or whatever you're called"). It's just some classic disgruntled customer stuff.
What a worthless link. How about an explanation of the problem? Stop what? Not resetting? Why is a reset necessary? And why the double-negative? Why not "noreallyjustfuckingresetitalready"?
Well if you had ran into that problem the link would be very touching to you too. The stop is referring to the constant changing and difficulty in diagnosing resolution under os x (or whatever it's called)
Maybe, except the author doesn't clarify what exactly the problem is, or that s/he's offering a solution. A solution is only viable if it's both discoverable and understandable.
We did. The original title, "Please OS X (or whatever your name is) just fucking reset your DNS cache please", is obviously baity, which means it breaks the HN guidelines. Please read
https://news.ycombinator.com/newsguidelines.html. When a title is misleading or linkbait, one should change it to something accurate and neutral.
Thanks for the update.
Would the removal of "fucking" allowed the original title to remain?
I feel that the title spurred the interest, as evidenced by the amount of discussion. The new title is not nearly as interesting, nor does it convey the author's vision and rage accurately.
The title rather than the content spurring the interest is pretty much the point of the 'no clickbait titles' guideline. The content itself is hardly in the 'gratifies intellectual curiosity' category.
> Would the removal of "fucking" allowed the original title to remain?
No, it isn't the profanity we care about, but the baitiness. Titles that stir up drama or controversy aren't a good fit for HN—the discussions are inevitably primed by the titles, and those are the kind of discussions we hope to avoid.
Too bad they didn't address the DNS problem in the Keynote. This is a bit of an exaggeration, but I do feel I've spun mDNSResponder more often than using their Messages app.
That's not a positive feeling. Especially if you're with a client and your browser stops resolving and your client is watching you open up terminal to spin mDNSResponder
Could OSX just have a way to disable negative caching completely? All it does is troll me when I'm on bad wifi and the DNS lookup for www.google.com gets dropped and that negative response is cached. Can we just stop doing that?
I can't recall the last time I had a positive cache entry issue, but the last time the dropped DNS lookup for www.google.com happened to me was like 2 days ago...
87 comments
[ 4.5 ms ] story [ 153 ms ] thread> There is also the \(°O°)\, indicating a hooligan or crazed behaviour, and the (ﾉ◕ヮ◕)ﾉ*:･ﾟ.
Of course, one could argue that since the word is now being used internationally, it's not necessary for them to be interpret in the same way as its roots.
Emoticons predate Unicode and emoji, but were later adapted to include Unicode characters.
http://unicode.org/reports/tr51/#Emoticons
Multi-character ones would be called smileys, emotes, or emoticons. The confusion comes from the fact that many messengers will automatically replace multi-character emotes with an emoji.
[1] https://en.wikipedia.org/wiki/Emoji
Emoji is a Japanese loan word 絵文字 (literally picture character), you can read more about them:
https://en.wikipedia.org/wiki/Emoji
Emoji in English can used as a singular or plural word but you can also write emojis.
Emoticons are then usually made up out of multiple ASCII-symbols, although general Unicode is by now also in use: :), :-), :|, :[ ...
And then for the "ㄟ(ツ)ㄏ"-Emoticon, you can get more specific about it and call it "Kaomoji". Kaomoji are not Emoji, even though the two sound related, and are actually a more horizontal style of Emoticons, so basically any Emoticon which you can read without turning your head: ㄟ(ツ)ㄏ, ^^, (っ´▽`)っ, (╯°□°)╯︵ ┻━┻, ఠ_ఠ ...
It gets more annoying if you want to explain it to a non-technical OS X user. Maybe this little repo will help them converge on a command alias for the future
Having a simple command such as "reset dnscache" or something of course would be nice, but since it can already be done in a matter of seconds with a quick google I can't imagine it's that much of concern for apple of many developers compared to other issues.
So I see absolutely no point here.
* Snow Leopard and earlier use lookupd for DNS resolving (`dscacheutil -flushcache`)
* Since Lion, they switched from lookupd to mDNSResponder, presumably for Bonjour protocol support (`killall -HUP mDNSResponder`)
* Yosemite switched to discoveryd that basically is a rewrite of mDNSResponder (`discoveryutil mdnsflushcache`)
* Due to a lot of problems with discoveryd, they switched from discoveryd back to mDNSResponder since v10.10.4 (so we're back to `killall HUP mDNSResponder`)
https://support.apple.com/en-us/HT202516
http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-i...
http://arstechnica.com/apple/2015/05/new-os-x-beta-dumps-dis...
https://support.apple.com/en-us/HT202516
Nothing bad could possibly happen. [1]
[1]: http://thejh.net/misc/website-terminal-copy-paste
Install with
curl http://issh.it/yadummy | sh
It all comes downs to whether you trust the source.
At least with the "curl http://xxx | sh" method you can also examine the contents of the script before running it, and even opt to run it after downloading it and checking it locally.
With binary apps off of internet sites, which is what people install and use dozens of times a month, no such luck.
All you said are true for binary blobs as well. The page could be MITM, etc.
"curl xxx | sh" style deployment has all the same disadvantages of binary blogs, but has the added advantage that you can download and check the code before executing it.
In short, `curl https://www.example.org/foo.sh` and `curl https://www.example.org/foo.sh | sh` can do different things :(
Why is changing names seen as a negative thing? My company also changed its name a month ago, and several customers leaving negative feedback said included this phrase or something similar, while to my recollection none of the positive feedback (which we have way more of) took mention of the name change.
basically, it's a no-feature change, so an unnecessary one, so a "bad" one.
And what's the point? MacOS X was a decent name, with good recognition and trust. If people were interested in understanding the back story to the name, they could, but the 'X' didn't scream '10' to people who weren't familiar with the history, so there wasn't a ton of confusion.
Branding changes product names all the time. MacOS X was nonsensical. I'm glad they changed it.
It is, however, used as a negative thing by people who would vent regardless of the name change, and just want to emphasize they care so little about you that they can't even remember your name("or whatever you're called"). It's just some classic disgruntled customer stuff.
Besides he is right, and those are useful additions to almost any script that you want to stop on error, undefined vars, etc.
They just put it out there, which is more than other people did.
If someone feels it needs an added explanation, they can add it themselves.
Some, who had faced similar issue at some time or another, will understand immediately what this is, anyway.
No, it isn't the profanity we care about, but the baitiness. Titles that stir up drama or controversy aren't a good fit for HN—the discussions are inevitably primed by the titles, and those are the kind of discussions we hope to avoid.
That's not a positive feeling. Especially if you're with a client and your browser stops resolving and your client is watching you open up terminal to spin mDNSResponder
I can't recall the last time I had a positive cache entry issue, but the last time the dropped DNS lookup for www.google.com happened to me was like 2 days ago...