Where did you get the original 'example' of 沌 / 屯 from? Most people prefer to use examples that they have some kind of personal knowledge of.
> There are other meanings to it. [沌]
Not as many as you might expect. It's (part of) a mythological term referring to the state of the universe before it took the form we can observe today. It has a couple of other metaphorical meanings coming from that, or from traditional sayings related to that.
I see that wiktionary lists 沌がる as an alternate spelling of 塞がる "be blocked" [塞 - obstruct / block / plug], which looks like the closest thing we're likely to find to your earlier claim. Obvious problems using this to support your comment are:
- There's still no "gathering" or "accumulating" sense. (Nor is there an "obstruct" sense of 屯.)
- This is a meaning assigned long after the character came into existence, which means it cannot have informed the construction of the character.
I learned about 沌 quite a while ago when I studied the first few chapters of Genesis in Japanese (混沌 was used to describe the earth in Gen 1:2) and something jogged my memory when I was looking for examples.
The dictionary link I posted had あつまる、水があつまる in the first definition. I don't know if that's a reliable dictionary. Maybe you think it's not?
> - This is a meaning assigned long after the character came into existence, which means it
> cannot have informed the construction of the character.
I don't know anything about which meanings were used first and which were added later, but what you say sounds believable.
> - There's still no "gathering" or "accumulating" sense. (Nor is there an "obstruct" sense of 屯.)
Let me clarify. Even without the first sense for 沌 in the above dictionary (あつまる、水があつまる) some of the other definitions for 沌 had "gather" included in it conceptually, namely clog and joined together without distinction.
I confirmed a few, and they seem correct. I thought 界 was the most easily understood example. 介 means being between two things and contributes the pronunciation. 界 means region, span, separate, division.
> This phenomenon we are talking about is called 会意兼形声文字
There are no kana in that word, but if you search baidu for it you'll find a total of zero uses. It's not difficult to understand what the phrase means - "a character that is simultaneously 会意 and 形声" - but it's not an existing term. It looks more like a joke, the way English speakers will sometimes talk about "autoantonyms".
There is a list of six traditional categories of character construction, and we still understand what five of them mean:
象形 - a character that literally pictures its referent, as 日 depicts the sun or 木 depicts a tree.
指事 - a character that metaphorically pictures its referent, as 刃 indicates the edge of a blade by placing a mark next to 刀 ["knife"], or 本 indicates roots by placing a mark at the bottom of 木 ["tree"].
会意 - a character whose meaning derives from the interaction of two semantic components, as 明 ["bright"] pictures the sun and the moon, or 休 ["rest"] pictures a man next to a tree.
形声 - a character with one component indicating the meaning and another component indicating the pronunciation. The vast majority of characters are in this class, but we may use the example 河 ["river" or specifically "the Yellow River", today pronounced hé], in which the semantophore is 氵["water"] and the phonophore is 可 [a modal verb having to do with permission or ability, today pronounced kě].
假借 - a character that is borrowed from some other word (because it shares the same pronunciation). These have tended to be "corrected" over time, but an example would be the tendency in ancient texts to write 女 ["female"] for the word that is today written 汝 ["you"].
(The other category is 转注. We don't know what it means, but we are given an example - it means whatever the relationship between 考 and 老 is.)
> I confirmed a few, and they seem correct.
Really?
Really?
--- EDIT - my discussion of 与 is flawed. There is an ancient 与, and it is given as sharing its pronunciation with 與, while 與 is said to be 会意 with 与 as one of the components. 與 could be fairly called "both 会意 and 形声", though 与 can't. ---
The first example on the page is 与. This is a simplified form (from 與) and it doesn't carry any phonetic or semantic weight. It's a representation of that bit in the top middle of the older form. I can be sure that the page meant to list the simplified form, though, because it's in the category of "three strokes".
----------------------
Moving to the "four stroke" category, we can see 切 ["cut", today qiē]. This is as clear as they come: it has a phonetic component 七 [today qī], and a semantic component 刀 ["knife"]. There is absolutely no possibility that it could be interpreted as 会意, because the meaning of the phonetic component is "seven".
円 is another simplified form. It means "round" (like a circle). The older form is 圓, which does have two components: the semantic component 囗, and the phonetic component 員. The meaning of the phonetic component is "staff; personnel". I'm not seeing the case for how that contributes to expressing roundness.
攴 ["strike; beat"] is another 形声 character with a phonetic component 卜 and a semantic component 又 ["again" - the connection here isn't obvious to me]. The phonetic component on its own refers to divining the future, a concept unrelated to 攴.
(仁 appears to be a fair call. It is identified as a 会意 character for what I assume are good mystical philosophical reasons. But equally it's true that 仁 shares its pronunciation with its lefthand component 人 (and this was also true in the past).)
In the "five stroke" category, we find 氷 ["ice"]. This character doesn't have two components and therefore cannot be 会意 or 形声. Today it is more commonly represented as 冰, which does... sort of... have two components. However, it's a weird case, because the component on the left, 冫, is usually understood as the combining form of 冰 itself, making this character infinitely recursive. The ancient form of the character had 仌 on the left, but I haven't been able to determine to my own satisfaction what that signified. As best I've been able to tell, 仌 by itself is now considered an archaic variant of 冰, and it means "ice", making the ancient character self-recursive in the manner of the modern one. 冰 (or rather the older form 仌水) is identified as a 会意 character, and I guess you can see it that way - you have a character meaning "ice" built from components meaning "ice" and "water" - but since it seems to be identical with its own left component I have difficulty calling it 形声.
At this point, I really don't see any value in looking further into the page.
> Moving to the "four stroke" category, we can see 切 ["cut", today qiē]. This is as clear
> as they come: it has a phonetic component 七 [today qī], and a semantic component 刀
> ["knife"]. There is absolutely no possibility that it could be interpreted as 会意, because
> the meaning of the phonetic component is "seven".
Originally, 七 meant to cut vertically and horizontally (confirmed on a few sources).
Regarding 與 and 与, the site shows the breakdown for the former and shows how it was the older form for the latter. I guess you didn't actually click on the characters and look for the explanation. The analysis shows it comes from 牙+口+舁. The last is the meaning as well as pronunciation, the meaning being "hold up, carry together"
> > I confirmed a few, and they seem correct.
> Really?
Yes I did click through and read a couple of explanations.
As for 圓, according to the site the inner portion actually represents a picture of a 鼎 (ding). It is surprising to me, and a lot of this is theoretical and there will be more than one opinion. That same site doesn't say 員 itself is related to ding.
> if you search baidu for it you'll find a total of zero uses
If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)
This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.
Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy:
> Obviously the proper solution is to adjust your system thermal management / power targets,
My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway.
I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.
The proper solution for non-technical people is to ask the expert to fix it
This isn't something the developer has any meaningful control over. Scheduling policy is the responsibility of the host system, running faster usually consumes less power, and the developer has no way to know when an operation will kick in the undesirable fans because it depends on what else the system is running. The best they can do is a checkbox that runs the old code or adding sleep calls instead
It is sorted FIRST by radical and SECOND by stroke order. This is roughly equivalent to the Unicode codepoint sort if you stay in the basic multilingual plane. The order also puts literary chinese afer wu Chinese, which breaks with a pure stroke-count sort:
Dictionary lookup is done first by radical and second by stroke count. Collation is not. Stroke count is first.
For example, I have a book of 成语 stories that gives its table of contents in non-alphabetical order. (Since nobody understands the traditional ordering, I also have several such books that put their table of contents in alphabetical order.)
Note that 三's radical is 一, the first Kangxi radical, and that 一 is listed first. Your theory is wrong. 三 isn't even first among the 3-stroke characters, which start (among these) with 口.
Why did you make up a false answer to this question?
The Wikipedia sort for the languages is as I stated above, with Literary Chinese and Japanese between Wu Chinese and Yue Chinese. I explained why it was sorted that way, because radical is considered first. You could not explain why Japanese appeared between Wu and Yue because you insisted and continue to insist that radicals are not used.
I didn't say sorting is never done by stroke count alone. But I have seen radical+residual stroke count much more often than stroke count alone. Probably a result of the content I'm accessing. It's mostly Japanese and not intended for children.
The dictionary and non-dictionary sorting distinction that you make doesn't sound like a real thing. The audience, the country, and the number of items sorted are bigger factors. But you're not wrong in that stroke count is sometimes used alone.
> You could not explain why Japanese appeared between Wu and Yue because you insisted and continue to insist that radicals are not used.
I can't explain that because it's part of a different logical group, with its name written in a different script.† This puts it parallel to the Chinese options and to Korean.
> The Wikipedia sort for the languages is as I stated above
I took you to be describing the sort order for characters, not for wikipedia. Wikipedia doesn't obey that order either. You can check the page for Jiangsu, where all of the languages mentioned so far appear before the "Latin alphabet" style languages, but 閩南語 and 閩東語 appear after them.
† I also can't explain why wikipedia seems to have chosen 吴语 but 粵語, 客家語, and 贛語. Jiangsu is on the mainland... and so are Jiangxi and Guangdong.
> all of the languages mentioned so far appear before the "Latin alphabet"
> style languages, but 閩南語 and 閩東語 appear after them.
Could it have something to do with Minnan and Mindong Chinese articles being written in a Latin script, (despite the language name showing in both Chinese characters and Latin letters) ?
Chromium is merely Chrome with only the open source parts. Chromium components are still implemented in a Google-controlled repo. So it has Google-oriented features and defaults.
Note I work for Google and I've contributed to Chromium, though I'm not necessarily an expert on Chromium forks.
1. Google Chrome
This is offical Chrome you download from google.com and also comes on ChromeOS devices.
2. Chromium
This is what you get when someone builds Chromium from the official repo without access to confidential source.
Source is confidential for various reasons, and some code that seems should be confidential actually isn't, like Android-for-ChromeOS integration, some of which is here: https://crsrc.org/c/chrome/browser/ash/arc/
3. Ungoogled Chrome?
This seems a contradiction of terms. Only Google can build Chrome, so they are not likely to e.g. set Bing as default or remove Google password manager support.
4. Ungoogled Chromium?
A particular project run by a particular team which forks Chromium and removes pro-Google behavior and settings.
5. Googled Chromium?
I don't know the original context of the use of this term, but possibly this just refers to official Chrome.
This is the default font of my browser-based terminal emulator, http://github.com/google/werm, along with a handful of other retro fonts (uses the int10h.org ttf's--converted to bitmaps--which I suspect has all the same characters as Neue)
IMO it still looks rather nostalgic. I do remember using cmd.exe or command.exe in Windows 95 and later and this being the default (but it would different if you had a different legacy code page set, IIRC). Of course cmd.exe just rendered the pixels as-is, no emulation or retro effects.
Yes, let's take dozens of terminal emulator projects out of maintenance mode so app devs can individually and capriciously overload my shift and escape keys, because modern.
> Context: Bitcoin miners have just adopted a 50% pay cut for themselves.
Miners don't decide the consensus rules. The nodes validate blocks, and the miners generate them.
The halvening timing was coded a long time ago, and in order to change it, the nodes would need to adopt the new code by installing updated clients, and at that point, you have a hard fork, because there will be nodes on the old rules, either accidentally through not updating or intentionally through using a modified core distro, and you have the new rules' valid blocks is a disjoint set from the old rules'.
The new rules' block set being a subset of the old rules' is a strictening of the consensus rules. A strictening consensus scheme is a soft fork and can keep the network in one piece.
So, there is no real way for the miners to avoid the halvening without a hardfork and a great risk to the network.
If we're going to talk about unnecessary extra processes like useless cat, we should merge the head and grep commands into a sed, and possibly just merge everything into perl:
<access.log sed -n '/mail/p; 500q' | perl -e ...
If perl is processing the file line-by-line then filtering lines by regex and stopping at line X is trivial, and you don't even need sed.
I think your point is valid and I don't dispute it, but if I had a nickel for every time I said "just do it all in perl" and regretted it, I'd be... well, perhaps not a rich man, but I'd have lunch covered for a few weeks.
Perl has the advantage of only having one implementation, unlike sed and grep (e.g. BSD or GNU) and /bin/sh (can be one of many POSIX shells), so upgrading this pipeline to 100% perl is safer in some respects. The example in the article is light on details so it's hard to comment very deeply.
I have heard snarky Perl putdowns ad nauseam at work and on HN and may have regretted using it a handful of times but I can say worse or similar for other popular tools, languages...
