LWN: Comments on "The fast kernel headers tree"

Wow

mathstuf — Wed, 12 Jan 2022 21:16:07 +0000

Or perhaps more because there will be shorter coffee breaks while performing internal CI/QA prior to sending patches upstream and therefore patches can make their way upstream more easily?

What vendor is sitting there, planning on taking their stuff upstream but sees "oh, builds can be faster now" and decide "maybe we don't need to send things upstream"? If anything, I'd see a rush to get patches in first so that they can just be fixed when this lands (though I trust maintainers enough to not let that be an excuse to let crap in).

In any case, how would you suggest this be measured? It's not like the bottleneck is "not enough patches" anyways.

Wow

rahulsundaram — Wed, 12 Jan 2022 20:08:20 +0000

> Quite so! Plus, because it speeds up the kernel build so much, those of us who have to adapt out-of-tree patches to it are probably going to do so happily rather than moaning about it like usual.

Is that going to result in less upstreaming of patches?

Wow

nix — Wed, 12 Jan 2022 18:52:40 +0000

Quite so! Plus, because it speeds up the kernel build so much, those of us who have to adapt out-of-tree patches to it are probably going to do so happily rather than moaning about it like usual.

The fast kernel headers tree

mrshiny — Tue, 11 Jan 2022 14:43:53 +0000

I was half-way through your comment and thought "Because Internet is appropriate here", then finished reading. I recommend the book! But also, I recommend anyone who dislikes emoji or slang or kids these days to take a look at the state of modern linguistics, where there's a focus on understanding how language changes, and there's really nothing that can, or should, be done about it. As an armchair linguist, I love this! As a grumpy old man, I am grumpy about change!

The fast kernel headers tree

zdzichu — Tue, 11 Jan 2022 09:39:35 +0000

> Emojis almost universally break the interline spacing, and most of them simply look badly (probably due to lowest bidder effect). Two "sarcasm" emoji posted in the very thread are perfect example the first one with tears of joy is quite nice.

Emojis are just characters. How they are rendered depend on your system. You basically complain about your (or your system vendor's) font choice.

The fast kernel headers tree

jezuch — Tue, 11 Jan 2022 08:40:59 +0000

> emoji (...) the race to intellectual bottom

🤣

I believe future historians will argue that emoji are quite the opposite: they *enrich* the language. You're basically doing the same thing every conservative does when they can't keep up with the world: stop it from having fun and evolving (and call it "devolving").

I haven't read it, but I hear this book is highly recommended on the subject: https://gretchenmcculloch.com/book/

The fast kernel headers tree

flussence — Tue, 11 Jan 2022 06:24:38 +0000

> In some sense emojis return the world 100-150 years ago when most of the humanity wasn't literate so pictures were essential for the illiterate.

This is hilariously ironic to put in the middle of an outburst calling for conservatism and "return to tradition".

Change a handful of words around and it could be a stereotypical anti-systemd rant!

The fast kernel headers tree

adobriyan — Sun, 09 Jan 2022 11:08:03 +0000

Emojis almost universally break the interline spacing, and most of them simply look badly (probably due to lowest bidder effect). Two "sarcasm" emoji posted in the very thread are perfect example the first one with tears of joy is quite nice.

And then there are too many of them so inferring the intended meaning can be quite hard if not harder than inferring the meaning new word in foreign language. They were tolerable when there were like 5-10 of them but hundreds all slightly different in different corners of the Internet.

In some sense emojis return the world 100-150 years ago when most of the humanity wasn't literate so pictures were essential for the illiterate.

Each and every self respecting computer program which can render emoji should offer an option to disable the race to intellectual bottom. I hope Emacs has it. If it doesn't, I hope Gentoo ships "USE=-emoji".

The fast kernel headers tree

adobriyan — Sun, 09 Jan 2022 10:50:43 +0000

It may not be that bad. Given that C compile times are proportional to the total size of files read, you improvements will stand out more percentage wise!

The fast kernel headers tree

mbunkus — Wed, 05 Jan 2022 19:15:43 +0000

Emojis mirror real life. In real life different people use different gestures to signal the same thought or feeling (e.g. one might fist pump in triumph, someone else might raise their hands Rocky-style, yet another one might stand there in the typical superhero pose). The inverse is also true: the same gesture might mean different things to different people or even the same person (the aforementioned superhero pose might also be taken as an angry parent berating their misbehaving child, depending on the facial expression). And lastly, a lot of gestures or sayings aren't globally used (e.g. "crossing your fingers" in English has an Emoji that doesn't make sense to us Germans who use "Daumen drücken" = squeezing your thumb as the corresponding saying, and there's no Emoji for that, so either we know the English equivalent and use that one ore we're simply out of luck).

As ambiguous real life is, you cannot make they pictograms trying to represent them unambiguous.

Same as any other piece of language, really, 'cause that's all Emojis are, a type of language we can use or not along the other types of language (spoken, written, body language, images, dance…). NONE of that is unambiguous. Of course the Unicode people know that; of course they don't expect Emojis to be universal.

The fast kernel headers tree

mathstuf — Wed, 05 Jan 2022 15:26:44 +0000

Sure. Words change meaning over time too. Given that there's unlikely to be specific codepoints for what some food emoji[1] "mean" in typical usage, what do you suggest people use instead when they want to talk about…whatever they're talking about. They're going to use the tools available. Language is flexible like that.

- 😂 is "lol", sure. People have tears when laughing. I consider it more like "rofl", but it's in the same vein at least.
- 😤 is ambiguous in that the whisps could be going in (sure, "triumph" could work here though the eyes or eyebrows don't match what I'd expect) or out ("angry, but counting to ten").
- 💅 is depicting one of the things that someone expressing casual insouciance would do instead of fully paying attention to what you're saying or doing. I don't see an issue here; it's actually quite ingenious.
- 💁‍♀️ and 💁‍♂️ are fine for sarcasm (IME, in a "sorry not sorry" kind of way). I don't expect ‽ and ⸮ to be any more useful given the difficulty of finding them on keyboards compared to the emoji. Info desks aren't that common anymore anyways (at least in the US; I don't expect COVID to have made them more popular where they still exist with humans behind the desk instead of touch screen based phone tree-like kiosks), so repurposing existing codepoints is useful.
- 👌 Sure, and 🖕 exists too. What's your point? One can't say that Unicode refuses to make vulgar symbols for any one culture at least (government prudishness and pearl clutching is a different matter).

[1] 🍆 and 🍑

The fast kernel headers tree

Cyberax — Wed, 05 Jan 2022 09:24:50 +0000

To be fair, you can afford to increase the font size for CJK glyphs since they are so dense. A typical Mandarin word is just 1.6 characters long.

And they're also so much easier to type on a phone!

The fast kernel headers tree

sfeam — Wed, 05 Jan 2022 07:46:06 +0000

Well, the "characters are too small for these old eyes" problem is not limited to emoji. CJK glyphs with more than about 6 strokes start to become hard to distinguish at font sizes for which the English alphabet is perfectly legible. Of course context and familiarity help a lot, but even so I resort to toggling ever increased font size. And I can only dream wistfully of being able to read much of anything on a phone screen.

The fast kernel headers tree

neilbrown — Wed, 05 Jan 2022 06:47:16 +0000

This comment confirms something that I'd been suspecting. Emoji often are too small for those of us with imperfect sight.
I can read all your words just fine (with the correct glasses).
I can see the first two emoji look like faces and are different, but I wouldn't trust my guess as to the important difference.

I don't much like emoji, but I can say one thing in their favour: they are still much better than animated emoji.

The fast kernel headers tree

NYKevin — Wed, 05 Jan 2022 03:57:24 +0000

I would argue that emoji are far less universal than people have claimed. For example:

😂 is in practice almost entirely synonymous with "lol," but its official Unicode name is FACE WITH TEARS OF JOY.
😤 is FACE WITH LOOK OF TRIUMPH but most westerners understand it to mean something like "I'm angry."
💅 is generally understood to express casual insouciance, but it literally depicts a person painting their nails.
💁‍♀️ and to some extent 💁‍♂️ are used to express sarcasm or snark, but they are officially an INFORMATION DESK PERSON (followed by a ZWJ and a gender marker), and some people incorrectly(?) call it the "hair flip emoji." It's not at all obvious to me what these emoji-people are supposed to be doing, but "person tipping hand" seems to be the modern-ish name for them.
👌 as a hand gesture is already quite ambiguous even before you turn it into an emoji. Some cultures think it means "OK," and some think it's vulgar.
There are emoji* for each national flag, but they don't even work on Windows. But they do work on Twitter, and any other platform that does their own custom emoji rendering rather than handing Unicode directly to the browser like a sensible website.

And those are the clean ones. I could go on all day about the dirty ones...

* The flags are not directly mapped in Unicode. Instead, Unicode defines 26 "regional indicator symbols" and you spell out the two-letter ISO code for the country whose flag you want. This is because the Unicode stability policy would be incompatible with adding and removing flags as countries rise and fall. Also, there are a wide variety of political and cultural issues which would make this fraught to do in Unicode (e.g. there is no consensus on whether TW should display the flag of Taiwan - it is a valid ISO 3166-1 code, but ISO also has codes for Puerto Rico, Antarctica, and a variety of other "non-independent" territories, which is the same category they put Taiwan under).

The fast kernel headers tree

EnigmaticSeraph — Tue, 04 Jan 2022 22:20:22 +0000

I just wanted to say that I strongly appreciate the diversity of generations and experiences from LWN. It yields much richer results, solutions, evolutions, etc. Thanks, comrades.

While I'm dropping by, a further argument for emoji is that they express a broad and at times deep sets of readily-understood signifiers independent of language or ultimately medium; yes, the Unicode repertoire remains e.g. Euro & Japanese -centric, but it's getting better.

The fast kernel headers tree

tsoni.lwn — Tue, 04 Jan 2022 21:23:16 +0000

Believe me there is a huge amount of attention employers gives the build times including the full build and incremental builds.

The fast kernel headers tree

tsoni.lwn — Tue, 04 Jan 2022 21:21:16 +0000

fullLTO to be specific. ThinLTO is going to slow it down too but fullLTO makes it very slow.

The fast kernel headers tree

marcH — Tue, 04 Jan 2022 19:32:41 +0000

If you never got the "upstream first" memo, no chance of missing this one...

The fast kernel headers tree

simlo — Tue, 04 Jan 2022 15:56:09 +0000

In my book that is the job of the build system, not the CI. Due to lack of good build systems implementing reliable incremental builds, a lot of complexity is pushed to the CI system. In my book the CI system shall not perform anything that isn't a simple command which also can be called by an individual developer after closing or updating a git repository.

The fast kernel headers tree

flussence — Tue, 04 Jan 2022 03:19:46 +0000

The "☺" in most DOS codepages predates Unicode by a few decades too...

The fast kernel headers tree

sfeam — Tue, 04 Jan 2022 01:48:42 +0000

I'm not sure that implementing a custom character on a PLATO system counts as "creating an emoji" as that would commonly be understood now. PLATO used a vector display; any arbitrary shape could be defined, used, and reused. The same was true for the PDP/PDS-IMLAC terminals of that same era. My first summer job project back in 1971 involved teaching an PDP+IMLAC system to draw logic diagrams, and that started with creating a library of routines to draw individual logic gates (AND NOR XOR ...) essentially as reusable custom characters. Those were 絵文字 (emoji) in the literal sense of being "picture (絵) characters (文字)" but obviously not in the current social media sense of "punctuation marks conveying emotion".

On the other hand, I concede that if Bruce Parello's PLATO emoji were promoted for use by students or instructors as markup annotations for PLATO assignments, they might qualify under the modern sense of emoji as well as under the original technical sense.

The fast kernel headers tree

atnot — Mon, 03 Jan 2022 23:53:19 +0000

> In general, people do inline too much.

Agreed, especially these days with LTO being very widespread, it turns out that humans are usually significantly worse than compilers at deciding what would benefit from inlining.

Wow

david.a.wheeler — Mon, 03 Jan 2022 21:48:38 +0000

I agree, this is a crazy amount of work. Serious hat tip here.

The fast kernel headers tree

NYKevin — Mon, 03 Jan 2022 21:04:00 +0000

Wikipedia claims the following:

> Mary Kalantzis and Bill Cope write that the first digital emojis were created by Bruce Parello, a student at the University of Illinois, on PLATO IV, the first e-learning system, in 1972.

It cites a book as well as this open-access PDF: https://www.researchgate.net/publication/351400910_A_Litt...

If that year is correct, then it would predate the introduction of (digital) emoticons in 1982 by a full ten years (although Wikipedia again claims that emoticons have appeared in non-digital text as early as 1648).

However, there are a few caveats here:

1. To the best of my understanding, these emoji did not get incorporated into Unicode and therefore lack historical continuity with modern emoji.
2. The PLATO emoji can't have been very influential, because everybody and their dog incorrectly claims that Shigetaka Kurita created the first emoji in 1999.

The fast kernel headers tree

KJ7RRV — Mon, 03 Jan 2022 20:54:50 +0000

A browser extension would also work for Web sites (and any chat platforms accessed through a browser, as well as Web mail); that way it would actually be emoticons and not just look like them. An IRC bouncer could do the same for IRC.

The fast kernel headers tree

KJ7RRV — Mon, 03 Jan 2022 20:50:51 +0000

How hard would it be to create a font that shows emojis as emoticons? That, combined with existing emoticon-to-emoji converters, should make everyone happy.

The fast kernel headers tree

jezuch — Mon, 03 Jan 2022 19:28:22 +0000

As I understand it, this is mostly what maven-enforcer-plugin does in Java land. Good dependency hygiene is important, hard to maintain (especially without any tooling support!) and close to impossible to attain in an older project.

Titanic work!

The fast kernel headers tree

Wol — Mon, 03 Jan 2022 18:20:21 +0000

Are you *trying* to us exclude dinosaurs!?

I won't say I use emoticons much, but I don't use emojis AT ALL. I neither know, nor care, how to ... :-)

Cheers,
Wol

The fast kernel headers tree

EnigmaticSeraph — Mon, 03 Jan 2022 17:42:55 +0000

While I understand the sentiment, Emojis are far better than emoticons. For example, screen readers for the blind cannot interpret emoticons, but Emoji are fine. To be inclusive, we should really move past emoticons.

The fast kernel headers tree

jhhaller — Mon, 03 Jan 2022 17:25:54 +0000

That's going to put a substantial drop in performance in my post-retirement plan to modify gcc to use openat for -I directives instead of concatenating each of the -I paths and trying to open the files from root, which cuts out a number of inode lookups and the string concatenation. I doubt it would have improved performance more than a few percent, and now there will be a lot fewer files to open. At least for the kernel, anyway, it could still help other compilations. But, someone may beat me to the change, or perhaps someone has already done it.

The fast kernel headers tree

flussence — Mon, 03 Jan 2022 17:12:13 +0000

Easy: just build the kernel with LTO and you'll have enough time to go get lunch ;-)

The fast kernel headers tree

Sesse — Mon, 03 Jan 2022 16:06:16 +0000

I believe Ingo posted somewhere that he had run performance tests with no ill effects.

In general, people do inline too much. Some things absolutely must be inlined, and many things are just fine without. Even worse, some things are faster locally when inlined, but slow down the rest of the system (due to code bloat).

The fast kernel headers tree

atnot — Mon, 03 Jan 2022 14:09:17 +0000

I am pleased to say for the future of the kernel that there are in fact people below the age of 40 using this website

The fast kernel headers tree

metan — Mon, 03 Jan 2022 12:17:27 +0000

That really depends on the usecase. Some of the CI systems can identify, based on the patch, which parts of kernel were changed and tries to select minimal subset of tests that covers that exact area. Of course this is not bulletproof, but on the other hand it can identify bugs very fast and in that case the kernel build time may be significant part of the CI runtime. This is really about developers getting feedback fast in case that something is not right. Of course you want to run all the tests once this minimal set has passed, which will possibly identify more subtle problems, but that will also take much longer and the results will be produced probably after the developer has already started to work on a different task.

The fast kernel headers tree

micka — Mon, 03 Jan 2022 11:34:17 +0000

There is probably some gain on test duration but I expect most test suite to run far longer than the kernel build part.

The fast kernel headers tree

metan — Mon, 03 Jan 2022 09:15:57 +0000

Actually this makes a perfect sense from an employers point of view, as long as CI is concerned speeding up the build twice significantly shortens the CI feedback loop. That alone a big win for developers. It also allows you to test twice as much patches or enable more automated testsuites without increasing the hardware lab size and power consumption.

The fast kernel headers tree

zdzichu — Mon, 03 Jan 2022 08:54:03 +0000

Think about employer who tolerated working on such feature. Someone had to pay for this year of work :)

The fast kernel headers tree

smurf — Mon, 03 Jan 2022 08:50:38 +0000

Yes you can. In fact you'll have to, as it's somewhat far from finished.

The fast kernel headers tree

smurf — Mon, 03 Jan 2022 08:49:27 +0000

Yes. Your kernel build is now too fast to wait for the coffee machine, so you need another justification to hang out there.