color blocks in the terminal after booting iso

callmejoe · 2022-10-30 02:42:21

anyone know the point of these colors being displayed? i've searched the wiki and forum and can't find any reference to it.

I see they get printed from the escape codes in /etc/motd, but the trail goes cold after that.

mpan · 2022-10-30 03:11:40

That has been introduced in configs/releng: Improve motd to fix the bug of Arch ISO missing an easter egg for April 2022.

nl6720 wrote:

Just like last year (#90 (closed)), we should prepare something a little amusing for April's official ISO (archlinux-2022.04.01-x86_64.iso).

Last edited by mpan (2022-10-30 03:12:27)

callmejoe · 2022-10-30 19:34:24

mpan wrote:

That has been introduced in configs/releng: Improve motd to fix the bug of Arch ISO missing an easter egg for April 2022

thanks. has anyone deciphered it? i can't figure it out. will have to keep at it.

mpan · 2022-10-30 21:16:09

Deciphered? I don’t think there is anything to decipher. It’s just a colorful decoration.

What makes you think there is any message hidden there? In particular since the capacity is just 126 or 108 bits⁽¹⁾. What would be the constraints, and why those in particular?

---edit: the bar is including black and white, so the fragment about 56 bits is invalid.
---edit: corrected values (there is 42 codes, not 22).
____
⁽¹⁾ Each SGR 4x code can encode 3 bits, there is 42 of them. If we limit the values to something actually colorful, it’s under 2.585 bits per code, yielding even less: below 109 bits.

Last edited by mpan (2022-10-30 23:25:05)

jasonwryan · 2022-10-30 21:42:05

callmejoe wrote:

has anyone deciphered it? i can't figure it out. will have to keep at it.

It's a recipe for tacos...

callmejoe · 2022-10-30 22:59:16

mpan wrote:

Deciphered? I don’t think there is anything to decipher. It’s just a colorful decoration.
What makes you think there is any message hidden there? In particular since the capacity is just 66 or 56 bits⁽¹⁾. What would be the constraints, and why those in particular?
____
⁽¹⁾ Each SGR 4x code can encode 3 bits, there is 22 of them. If we limit the values to something actually colorful, it’s under 2.585 bits per code, yielding even less: below 56 bits.

the word decipher is in the comments

cfr · 2022-10-30 23:41:22

callmejoe wrote:

the word decipher is in the comments

Yes, but it is from April ....

mpan · 2022-10-30 23:52:07

Note: I made important corrections to my previous post, as it contained some mistakes.

If someone finds entertainment in grinding various arbitrarily chosen encodings, one will certainly find some meaningful interpretations. One of them may even match what the author was thinking about. Personally I find that boring and pointless, but I do not stop anyone from doing so.

The problem is: none of the solutions is more valid than any other, unless some constraints are given. I can claim this bar writes “bush hid the facts”, “callmejoe will ask” or “mpan is right here”. I can prove this is a valid interpretation⁽¹⁾ in more than one algorithm. That’s an unavoidable consequence of what encoding is.
____
⁽¹⁾ Though the proof will be unentertaining. Likely dismissed for not matching reader’s expectations, no matter how unfounded those expectations are.

Last edited by mpan (2022-10-30 23:52:49)

klausenbusk · 2022-11-02 18:11:56

mpan wrote:

Deciphered? I don’t think there is anything to decipher. It’s just a colorful decoration.
What makes you think there is any message hidden there? In particular since the capacity is just 126 or 108 bits⁽¹⁾. What would be the constraints, and why those in particular?

You would know right away, that you got the correct result.

mpan wrote:

---edit: corrected values (there is 42 codes, not 22).

Correct.

mpan wrote:

⁽¹⁾ Each SGR 4x code can encode 3 bits, there is 42 of them. If we limit the values to something actually colorful, it’s under 2.585 bits per code, yielding even less: below 109 bits.

Incorrect, but close

schard · 2022-11-02 19:11:30

Maybe it's a Piet program.

klausenbusk wrote:

mpan wrote:
---edit: corrected values (there is 42 codes, not 22).
Correct.
mpan wrote:
⁽¹⁾ Each SGR 4x code can encode 3 bits, there is 42 of them. If we limit the values to something actually colorful, it’s under 2.585 bits per code, yielding even less: below 109 bits.
Incorrect, but close

Well we have established that there are 42 color codes.
Only background colors are used.
There are 8 available background colors: 40..47.
We can normalize them to 0..7.
The numbers from 0..7 can be encoded in 3 bits.
What about that is incorrect?

Last edited by schard (2022-11-02 20:47:38)

mpan · 2022-11-02 21:50:31

klausenbusk wrote:

You would know right away, that you got the correct result.

Ignoring the and speaking seriously: I would not. Without constraints, which are not stated in here, there is no way to tell if any given decoding is valid.

I can invent a decoding that produces something seemingly sensible, yes. I gave examples above. But there is no way to prove any of them valid or not. Kristian Klausen may say, that this isn’t what he used. But that can’t be derived from the color bar itself.

Coding is an injective relation. There is infinitely many injective relations. Even with a single given codomain. Even for a single given image. Without additional constraints there is no way to tell, with which of infinitely many relations we’re dealing with. And we do not even know the image: we only have a single element, which may belong to any image in the very big (theoretically infinitely big) family of images.

People do find fun in finding possible decodings. I don’t oppose such entertainment and I said that in my previous post. I can even appreciate interesting, humorous or elegant solutions! But such things are found two ways: either through toilsome searching, or by ignorance. Internet fame is not motivating enough for me to engage in the former, while the latter would be too degrading. Hence I do not play that kind of games.

OP may still find it fun and, if that’s their wish, I will not stop them. But, writing a post here, I explain what the situation is.

klausenbusk · 2022-11-02 22:20:22

schard wrote:

klausenbusk wrote:
mpan wrote:
⁽¹⁾ Each SGR 4x code can encode 3 bits, there is 42 of them. If we limit the values to something actually colorful, it’s under 2.585 bits per code, yielding even less: below 109 bits.
Incorrect, but close
Well we have established that there are 42 color codes.
Only background colors are used.
There are 8 available background colors: 40..47.
We can normalize them to 0..7.
The numbers from 0..7 can be encoded in 3 bits.
What about that is incorrect?

Sorry, I misread @mpan's response. Sounds like it is a octal.

schard · 2022-11-02 23:03:05

So the question remains, what compression you used....

mpan · 2022-11-03 00:44:28

schard: the initial (invalid) value of 66 bits can be heuristically assumed to not contain anything meaningful, unless hinted otherwise. However, 126 bits is a different story and that is enough to hold some simple message. No compression needed. “bush hid the facts”, “callmejoe will ask” and “mpan is right here”, which I provided earlier, are examples of such messages.

For 66 bits, word “heuristically” is the key. 66 bits is enough to hold any 5-word DiceWare passphrase or most simple statements in English. But that is getting into the territory of encodings so specific, one would generally not assume a presence of anything meaningful in a value that short.

In either case, it has been hinted that something is there. Which makes heuristics irrelevant.

Last edited by mpan (2022-11-03 00:49:45)

seth · 2022-11-03 06:53:43

The colors a deceptive, the black slots indicate separators and then you count the colored blocks for the index of the latin alphabet.
Reads "cajak ai" which is Bengali for "This is the job/task/challenge".
Fits.

schard · 2022-11-03 09:29:09

Well, if I feed

$ echo -n I love Arch Linux | ./color_encode.py

to my script, it has a striking similarity to the color code of the motd. However, decoding the latter results in something scrambled.

Last edited by schard (2022-11-03 10:12:27)

seth · 2022-11-03 10:25:36

111 040 165 163 145 040 141 162 143 150 040 142 164 167

is octal ASCII of "I use arch btw", but you could also encode 64 glyphs in 2 octals or convert the entire thing into a bit stream and read that as bytes or god knows what.

The thing that kinda hints at the encoding is the black/blue/black pattern - the only really repeating pattern and it fits into the triplets and is suspiciously spread.
Then you know the audience is
a) supposed to decode it, so it cannot be a completely arbitrary encoding, but must be something common
b) likely speaking english, rather than, say, bengali
c) and archlinux user (narrowing on the likely content)

Out of context the color stream is meaningless and "decipher" is misleading since it's not a cipher.

Edit: btw. what told me the encoding is that the black/blue/black translates to 040, which is the space in octal ASCII.

Last edited by seth (2022-11-03 10:26:44)

schard · 2022-11-03 14:07:22

Well the encoding of the triplet-triplets is surely a potential solution.
However, it is also suboptimal, which is why I did not come up with it.

Last edited by schard (2022-11-03 14:35:21)

seth · 2022-11-03 14:30:57

https://www.youtube.com/watch?v=VLf76wRTDzI

Arch Linux

#1 2022-10-30 02:42:21

color blocks in the terminal after booting iso

#2 2022-10-30 03:11:40

Re: color blocks in the terminal after booting iso

#3 2022-10-30 19:34:24

Re: color blocks in the terminal after booting iso

#4 2022-10-30 21:16:09

Re: color blocks in the terminal after booting iso

#5 2022-10-30 21:42:05

Re: color blocks in the terminal after booting iso

#6 2022-10-30 22:59:16

Re: color blocks in the terminal after booting iso

#7 2022-10-30 23:41:22

Re: color blocks in the terminal after booting iso

#8 2022-10-30 23:52:07

Re: color blocks in the terminal after booting iso

#9 2022-11-02 18:11:56

Re: color blocks in the terminal after booting iso

#10 2022-11-02 19:11:30

Re: color blocks in the terminal after booting iso

#11 2022-11-02 21:50:31

Re: color blocks in the terminal after booting iso

#12 2022-11-02 22:20:22

Re: color blocks in the terminal after booting iso

#13 2022-11-02 23:03:05

Re: color blocks in the terminal after booting iso

#14 2022-11-03 00:44:28

Re: color blocks in the terminal after booting iso

#15 2022-11-03 06:53:43

Re: color blocks in the terminal after booting iso

#16 2022-11-03 09:29:09

Re: color blocks in the terminal after booting iso

#17 2022-11-03 10:25:36

Re: color blocks in the terminal after booting iso

#18 2022-11-03 14:07:22

Re: color blocks in the terminal after booting iso

#19 2022-11-03 14:30:57

Re: color blocks in the terminal after booting iso

Board footer