I trained as a linguist and you hit the nail on the head.
Word meanings are fuzzy clouds of references and nuances, and every language has slightly different clouds. There is nothing magical about this, despite the recurrent lizard-brain notion that words or names are somehow mystical and intrinsic, and that these differences must somehow be meaningful.
Differences are quite common with colour terms - you don’t need to go to Japanese (blue-green) or Ancient Greek (wine dark sea) for this. My own (European) first language draws a slightly different word cloud around the colours pink and purple than English does, for example. One word is only for hot pink, and the other is for purple and non-hot pinks.
I assure you I see these colours the same as you do. If I were to use the English word “purple” to refer to more of a pink hue, it would be a mere language interference error, not some mystical Saphir-Whorf insight into the culturally-conditioned operation of my retinas.
Words are not perception. This is such a pernicious bit of nonsense, and journalists and writers are especially susceptible to it because it flatters them, in their role as word-smiths. Languages are way more interesting than this pseudo-intellectual mysticism.
The Japanese are just as capable of distinguishing blue and green as anyone else, and they use blue traffic lights for the same reason they drive on the left - because it doesn’t actually matter what convention they pick, so long as everyone agrees on it and sticks to it.
An interesting backronym is Wine being "Wine Is Not an Emulator". That one has an interesting history.
The original author first was going to call it winemu, but didn't like that. He shortened it to "wine", which led him to think of "whine" and "whinny". He liked "whine" but thought that was too long so "wine" it was.
The first suggestion of "Wine is Not an Emulator" was in 1993, when there were concerns Microsoft might raise trademark objects to "Windows Emulator". No one took that name suggestion seriously.
It wasn't until 1997 that it was adapted, as an alternative. In late 1997, the Wine FAQ said
> The word Wine stands for one of two things: WINdows Emulator, or Wine Is Not an Emulator. Both are right. Use whichever one you like best.
The shift to not mentioning it being a Windows emulator happened later. The release notes for 981108 said
> This is release 981108 of Wine, the MS Windows emulator.
and for 981211 said
> This is release 981211 of Wine, a free implementation of Windows on Unix.
As far as I've been able to glean from old Usenet posts, there were two reasons they stopped mentioning it being an emulator.
1. It could be used for more than just running Windows binaries under Unix. If you had source to a Windows program you could compile it on Unix and link it with Wine to give you a port of the Windows program. Wine was now a Windows compatibility system that included more than just an emulator. It was an emulator and a porting library.
2. Computers were getting fast enough that people were starting to run hardware emulators to do things like run game binaries from old consoles or old personal computers. Such emulators were not very fast. This might lead users to think that emulation was inherently slow, which might turn them off from trying Wine under the mistaken impression that it too would be slow.
Wine, when used to run Windows binaries rather than as a library when porting, is in fact still an emulator just like it was when Bob Amstadt first wrote it. Nothing technical changed when they added the backronym, or changed the text for the 981211 release notes.
But now we have plenty of people who have only ever seen the backronym, and the only emulators they have used that call themselves emulators have been emulating hardware, and so will insist that for something to be an emulator is must be emulating hardware.
> This eliminates the need for an on-battery or plugged-in performance mode because it changes frequencies so fast, you're no longer losing performance by waiting for the software to speed up the cpu. So you can keep it on all the time.
Here's my /etc/rc.d/rc.local script:
#!/bin/sh
for policy in /sys/devices/system/cpu/cpufreq/policy*
do
echo "power" > "$policy"/energy_performance_preference
done
Here's available preferences:
$ cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_available_preferences
default performance balance_performance balance_power power
Basically I can choose between "performance" and "power" (low performance) modes. I'm choosing power, so my fans are silent. And they're silent indeed, no matter the load.
A pathway to understanding TrueSkill could be first getting an understanding of factor graphs and Minka's expectation propagation algorithm [1][2]. I only have a superficial understanding of those things, but I think I've got an understanding of things that are close enough to give some idea of a pathway:
To understand Minka's expectation propagation algorithm you might first need to get a little intuition about assumed density filtering. One way to understand assumed density filtering could be to read a few tutorials about hidden Markov models [3] or Kalman filters and try to get a feel for why and when and how people might want to approximate posterior probability distributions. It might be hard to build enough intuition without trying to actually apply the things (implement the algorithms) or prove the theory yourself, and then try to come up with your own ideas for how to improve the algorithms.
I completely agree that there are basically infinitely more things to learn than available lifetime. It helps a lot to have a concrete application or goal in mind: then you can focus on learning the tools and theory that move you closer to the goal, rather than learning bits and pieces of unrelated knowledge that don't connect together in a useful way.
This is a great post and so spot on. At some point in my career my 'review prep' (which was the time I spent working on my own evaluation of my year at a company) became answering the question, "Do I still want to work here?" I categorize my 'review' in four sections (which are each rated at one of five levels, needs improvement, sometimes meets expectations, meets expectations, sometimes exceeds expectations, or consistently exceeds expectations)
I start by reviewing how I'm being managed, I expect someone managing me to be clear in their expectations of my work product, provide resources when I have identified the need to complete jobs, can clearly articulate the problem I am expected to be solving, and can clearly articulate the criteria by which the solution will be evaluated.
Second I review my co-workers, using a three axis evaluation, can I trust what they say to be accurate/honest, can I count on them to meet their commitments, and are they willing to teach me when I don't understand something and conversely learn when their is something they do not know.
Third I review what level of support do I get to do my job. Am I provided with a workspace where I can get work done? Do have have the equipment I need to do what is being asked? Is my commute conducive to the hours required? And finally and most important, does this job allow me to balance work obligations and non-work obligations?
Fourth I review whether or not the company mission, ethics, and culture is still one that I wish to be a part of. Am I proud of the company's mission? Do I believe that the leadership will make ethical calls even if doing so would mean less profit margin? Can I relate to and am I compatible with the values that my co-workers espouse and the actions they take? (this is the "company culture" theme, is it still a company that fits me culturally)
A company that receives lower than a 3.0 rating I put on a 90 day "company improvement plan" (CIP). I bring issues to the leadership who are in a position to address the situations that I've found wanting and try to secure their commitment to change. If after 90 days they haven't been able to (if they choose not to they're done right away), then I "fire" the company and work to process my exit as expeditiously as possible.
A simple syntax (kind of Markdown) for complex argumentation, defining complex dialectical relations between arguments. Your document is transformed into an argument map while you are typing.
Word meanings are fuzzy clouds of references and nuances, and every language has slightly different clouds. There is nothing magical about this, despite the recurrent lizard-brain notion that words or names are somehow mystical and intrinsic, and that these differences must somehow be meaningful.
Differences are quite common with colour terms - you don’t need to go to Japanese (blue-green) or Ancient Greek (wine dark sea) for this. My own (European) first language draws a slightly different word cloud around the colours pink and purple than English does, for example. One word is only for hot pink, and the other is for purple and non-hot pinks.
I assure you I see these colours the same as you do. If I were to use the English word “purple” to refer to more of a pink hue, it would be a mere language interference error, not some mystical Saphir-Whorf insight into the culturally-conditioned operation of my retinas.
Words are not perception. This is such a pernicious bit of nonsense, and journalists and writers are especially susceptible to it because it flatters them, in their role as word-smiths. Languages are way more interesting than this pseudo-intellectual mysticism.
The Japanese are just as capable of distinguishing blue and green as anyone else, and they use blue traffic lights for the same reason they drive on the left - because it doesn’t actually matter what convention they pick, so long as everyone agrees on it and sticks to it.