วีดีโอ

Sway & Waybar (plus bemenu, but most of my commonly used programs are in the terminal or directly bound to a key combo), at some point I'll do a full setup & config video

No problem! If you run into anything you don't understand, can always come back and pester me too. 😉

Cheers, glad you think so! 🙂

That would definitely be one solution 😅

Hope my bank database has this feature so I can generate infinite amount 😂

@@KassiopeiaYT great question! (Pseudo)random data is by its nature not very compressible. Given a specific piece of 'random' data, different compression methods *may* yield nontrivial compression ratios, but it's coincidental when this is the case. One example is the Bitcoin blockchain; hundreds of gigabytes of mostly signatures, public keys, and hashes, results in poor compression ratios. Mixed in are compressible bits, like arbitrary data stored in OP RETURN, but there's a good reason no compression mechanism is included in block storage despite chain growth being a serious concern. Specifically, with *encrypted* data, the advice is always to compress the data prior to encryption. But if you have large amounts of encrypted data for which you don't hold the keys, you're pretty much out of luck. In the case of, say, end to end encrypted messaging, the work of compression, where it's performed, is offloaded to clients. This can be limiting, as there's an inherent tradeoff between how much data you're compressing at once, allowing for more patterns to emerge, and how much data you're willing to send down and re-ingest, if you're a third party storing end to end encrypted data. There *are* some techniques with homomorphic encryption; schemes designed to allow certain mathematical operations on encrypted data, but they're fairly novel and I honestly can't speak to their viability in real world scenarios.

the emojis

echo "whatever the message is" | gpg --sign --armor TH-cam's descriptions collapse non '\cr\lf' whitespace, and multiple hyphens result in strikethrough styling, rendering some of the hyphens invisible. To make the messages copyable, I pasted the message, replaced the two newlines after the BEGIN PGP MESSAGE line, and the one newline before the END PGP MESSAGE line, then added a \ to the beginning of the BEGIN and END lines to prevent strikethrough. There must be a newline, and a blank line, after the BEGIN header, and a newline before the END footer. The other newlines aren't necessary. It's then possible to copy the message from a TH-cam description, paste into: echo "[PASTE HERE]" | gpg --decrypt but you need to remove the escaping \s.

@@0x15aac Thank you, this worked flawless. Its similar to a PEM Boundary when working with RSA or ecdsa keys or a tls certificate (with the boundary and the 4 dashes). \-----BEGIN PGP MESSAGE----- owGbwMvMwCX2fovXmdrtlkcYT0snMaSbuWuHZCTmZStU5pcqlKUWVSrkliZn8HJ1 lLIwiHExyIopsvSuTww/m9Ord3NBdixMMysTSCcDF6cATGT/fob//ufuLqvd3LCK y+p03VXXULkjR5nnKZockFqeeOHlWme1SoafjDOfPdaeHp9z9PTDk9NC+OPKxUXv dj9/8n1+Z079Ef59DAA= =x5me \-----END PGP MESSAGE-----

Glad you're enjoying the videos! As far as the audio goes, I plan on building myself a little booth, but I'm in the process of rebuilding a partial ruin, so there's a few steps before I get there. 😅

There are actual advantages to little endian ordering. For example, downcasting an integer on a little endian machine is a noop; you don't even need to calculate an offset. Similarly, addition and subtraction, which work smallest byte to largest byte, are simpler when I[0] is the smallest byte. There are advantages to big endianness for certain tasks too. The difference is usually very small, so when choosing an endianness for a general purpose computer, you go with the endianness which has the minor advantage for the extremely common operations (eg: downcasting, addition). Virtually every modern, widely used computer is little endian; ARM and Risc-V allow for big-endianness, but it's rarely used.

I plan on covering entropy collection from real-world sources like coinflips and dice, with Von Neumann skew correction, very soon. Also HMAC and PBKDF2 (tomorrow's video is a high-level explainer of hashing, as a base to move on to these), which is commonly used for key stretching of passphrases for AES. I'm actually working on some bootable airgapped UEFI tools for this, among other things, so those topics are super important to me. As for the actual mathematics of AES, I *do* plan on covering them, but given it's quite an advanced and in-depth topic, it may be a little while before I get there; my goal is that topics I cover can be understood from the ground up by watching the right set of my videos for any prerequisite knowledge. Similarly I plan on getting to the maths of various hashing algorithms, maybe explore Linux's CSPRNG, etc, but they'll take a while to build up to.

@@0x15aac You are cooking something great pal I can smell it. I wish you all good luck with all that.

Cheers for the feedback! For some reason the end cards were showing up much later on my phone than on my computer, so they seemed OK when I tested them, but in a couple videos they completely blocked the last thing shown for the entire time it was shown. I've tweaked them all so where they're covering something, it shows for a good amount of time before they appear.

Fair question! The answer is yes, but 'decoding' is just a verb, while 'encoding' is a verb and a noun. The process of writing video data to a file with a defined format to disk is 'encoding', and the process of reading said file, and interpreting it so it can be turned into pixels on a screen is 'decoding'. What you're missing is 'an encoding' is the ruleset which defines how to do both actions.

@@ProgrammingWithJulius cheers! I'm enjoying your CS geoguesser video. 😅

@ it certainly was a lesson for me. Worked really hard on it for weeks (next to my full time job) and it got less than 1k views for the initial period. No more large projects until I have a bigger following 😂

Glad you found it helpful! I definitely plan on going more in depth on specific formats, including PNG, JPEG, and exploring h264, h265, etc for video. There are super interesting computer science and mathematical concepts to explore in doing so. I can't say exactly _when_ I'll get to that stuff though-there's a lot I want to cover.

'Encoding has less to do with binary than it does with general data formatting.' I totally agree, and that was the point I was trying to get across by using 'ruleset' as almost a synonym for encoding. There are 5 videos (currently planned) in this particular little 'Data' series, the last of which is compression, in which I explicitly call out that compression can be thought of as an additional encoding layer. The implication I'm *hoping* to put across is that 'wait, this is all just different expressions of the same concept'. Calling this particular video the 'encodings' video is perhaps a bit of a misnomer, because the only video in the 'module' which covers a topic which can't be thought of as a *sort* of encoding (even binary and number systems can fall under that umbrella IMO), is hashing which is covered tomorrow. Otherwise, it's all 'at a high level, how do computers interpret and work with data'. The main reason I wanted to start with binary is mentioned in that video; it's easy for anyone to conceptualize, one they understand what binary is, that binary is the natural number system for computers because a basic electronic switch is high or low, on or off, and from that we can build everything else.

Next one will be out tomorrow! Pacing myself a with these shorter explainers as a lot of the practical 'here's how to actually do X, Y and Z' video ideas I have planned can't be condensed nearly so much. 😅

Thank you, glad you liked it! 🙂

Haha, I'm happy I could surprise you. It's a new channel; everyone starts at zero. Apparently TH-cam has decided to bless this particular video with recommendations, so I can't complain.

Glad you enjoyed it ☺️

Glad you like the style! More is definitely on the way.