index.txt (22790B)
1 Hello! I am Cem, and this is my little blog that I rarely ever use. I am a 2 Software Engineering student at the Berlin CODE university, the maintainer of 3 Carbs Linux, and I occasionally compose music (mostly jazz and classical). 4 5 My repositories are really scattered, so see the [software] section if you 6 are looking for one of my works. 7 8 This page is curl friendly! Just replace '.html' with '.txt', and you will be 9 able to view this site in your favourite pager! In your terminal simply type: 10 11 curl -sL cemkeylan.com/index.txt | less 12 13 14 [software]: /software.html 15 16 [RSS Feed](/rss.xml) | [Blog Index](/blog.html) 17 18 ******************************************************************************** 19 20 My thoughts on execline 21 ================================================================================ 22 [Permalink](/blog/20211012-execline.html) 23 24 Date: Oct 12 2021 25 26 27 With the gaining popularity of the [s6-rc], I have recently decided to check out 28 [execline]. It is a shell-like scripting language that is built around chaining 29 commands together. There is no interpreter, there is no 'built-in' functionality 30 even though the docs might make you think there are. Execline is best described 31 as a suite of tools that imitate the functionality of a shell. 32 33 There are a ton of information on the execline's page, especially discussing 34 why skarnet prefers execline instead of `/bin/sh`. Those points are mostly 35 valid, shells are a nightmare, and they suck at being compliant to the POSIX 36 specification. What I don't agree with the [why not sh] page, however, is the 37 part on performance. Even though execline does not have an interactive shell 38 implementation of its own, it is still much slower than other shells simply by 39 its design. Since the design of execline is built on process chaining, it 40 requires spawning new processes for things as basic as variable declaration. 41 Variable manipulation is the cheapest operation you would expect from a shell, 42 but in execline, every operation costs the same regardless of how simple it is. 43 44 Throughout my weeks of toying around with execline, I have came to the 45 conclusion that execline is much better in simple scripts only. Execline is 46 as usable as any shell out there, but even with its advantages over `sh`, 47 execline is only better if it's simple. Execline is really good for certain 48 specific situations such as service scripts (as used in s6-rc), or where you 49 were already meant to chain a couple of commands together. After all, skarnet 50 already presents these limitations on the website of execline. 51 52 Execline can be leveraged as how s6-rc compiles service databases with other 53 utilities, but I don't think it can be used as a shell replacement itself. It's 54 not the next shiny thing to jump on to replace all your shell scripts with 55 (unless you have really basic shell scripts). It does not have the flexibility 56 nor the performance of the shell for scripts that can be considered a little 57 over than the "basic". 58 59 60 [s6-rc]: https://www.skarnet.org/software/s6-rc/ 61 [execline]: https://www.skarnet.org/software/execline/ 62 [why not sh]: http://www.skarnet.org/software/execline/dieshdiedie.html 63 64 ******************************************************************************** 65 66 Reimplementing `sysmgr` in C 67 ================================================================================ 68 [Permalink](/blog/20201002-reimplementing-sysmgr-in-c.html) 69 70 Date: Oct 02 2020 71 72 73 For a while, I have been thinking about implementing [sysmgr] in C. I started 74 thinking about the inefficiencies of sysmgr. POSIX sh isn't particularly 75 designed to have ultimate control over child processes. There are basic job 76 management features that are _just enough_ for sysmgr to do its job. The 77 biggest pain is having to use tools like `sleep(1)` and `kill(1)`. Calling 78 sleep every second, and using the kill command to check whether a process is 79 alive or not is extremely inefficient. Some shells _do_ include these commands 80 built-in, but it isn't specified by POSIX, but one should never take this as 81 granted. 82 83 Lately, I have been adding C utilities to sysmgr to make it more efficient. This 84 defeats the initial purpose of sysmgr, being a service manager in pure POSIX 85 shell. My main purpose, however, is making sysmgr efficient and simplistic. It 86 mostly imitates `runit` without dealing with all the complexity of the 87 over-thinked `supervise` directory, nor the logging stuff. Most of these can be 88 handled by the service script itself anyway. That's why instead of this ugly 89 C/POSIX sh hybrid, I decided to implement it all in C. 90 91 I am not a C expert or anything, I am learning a lot as I am writing the 92 program. I want it to be C99 and portable (for BSD). It's currently not 93 functional at all, but, you can see its current state [here]. 94 95 [sysmgr]: https://git.ckyln.com/sysmgr 96 [here]: https://git.ckyln.com/sm 97 98 EDIT Oct 10 2020: 99 100 I did the initial release of this C version of sysmgr, which is more stable, 101 and performant than the POSIX sh version. It still has rough edges, but is 102 completely usable. 103 104 ******************************************************************************** 105 106 Trust in Distributed Environments 107 ================================================================================ 108 [Permalink](/blog/20200908-trust-in-distributed-environments.html) 109 110 Date: Sep 08 2020 111 112 113 A few days ago, in the `#kisslinux` IRC channel, jedahan mentioned an 114 implementation for trust in the package manager. While I was intrigued by the 115 idea initially, I decided not to implement this for the upcoming 4.0.0 release. 116 That is because the package manager and the distribution itself is already 117 centered on trust. However, this idea made me think a lot about "trust" in 118 distributed environments. 119 120 Who and what would you trust? Would you trust Microsoft? Would you trust a 121 binary? Would you only trust a so called "reproducible" build? 122 123 Jedahan mentioned the possibility that a repository maintainer could create a 124 package that would be normally in the distribution so they could mess your 125 system up. He suggested a "source" system where you know where each package 126 comes from. This way the package manager can warn you when the source of a 127 package is changed. As I have said this idea intrigued me at the beginning, but 128 here is why it is complex and unnecessary. 129 130 The package manager would warn you every time you fork a package and apply your 131 changes. Both with kiss and CPT, you already see git logs when the repositories 132 are fetched. Those logs address each and every file that has been edited, added, 133 removed, or renamed. CPT also has support for rsync, which is called verbosely. 134 While not as descriptive, rsync also shows what's changed/added and what's 135 deleted. 136 137 Also, back on April, I have added submodule support to my fork of kiss, which 138 Dylan adapted on May 19. I have added this feature because it solves a similar 139 issue. I want to have only some packages from a repository and leave the rest 140 of them. This way I am the one in control of what goes inside my repositories. 141 142 Minor annoyances aside, would this solve the issue of trust? Maybe this evil 143 repository maintainer decides to botch a package that was already in their 144 repository not provided by your distribution. Should we then track the source 145 files, build files as well? But those change all the time. 146 147 I believe that this environment is as trustworthy as it can get, a repository 148 system with package build instructions that easy to read and understand, easy to 149 history check, easy to limit, and easy to allow. KISS and Carbs Linux have a 150 single maintainer. I maintain Carbs and Dylan maintains KISS. You are not 151 trusting an organization, you are trusting individuals that you can easily 152 converse on the internet. The same goes for most community repository 153 maintainers out there. Trying to implement more would be a "security theater" 154 that would be a hassle for the maintainers, the users and the package manager 155 without a noticeable benefit to any. 156 157 ******************************************************************************** 158 159 wpa_add script 160 ================================================================================ 161 [Permalink](/blog/20200828-wpa-add-script.html) 162 163 Date: Aug 28 2020 164 165 166 I have this script named `wpa_add`, which I use to easily add new WiFi when I 167 am outside, possibly in a cafe. I have written this script because I don't like 168 the way my girlfriend looks at me while thinking that I am an absolute moron for 169 not using Windows 10, and the entirety of Linux is a circlejerk. It is only 170 natural that she thinks this way. I use my own distribution that doesn't have 171 things like `dbus`, or `NetworkManager`, or one of those common desktop 172 environments. You could install it by creating a simple package, but I am happy 173 to not have any of those in my system. 174 175 This script uses wpa-supplicant to add a new network and reconfigure. It uses 176 dmenu for input, however you could replace dmenu calls with some command line 177 prompts. I am doing the following assumptions: 178 - You can manipulate `wpa_supplicant` without root access. 179 - The configuration is on `/etc/wpa_supplicant.conf`. 180 - You can edit `/etc/wpa/supplicant.conf`. 181 182 If you want to ensure the above just do the following (as root): 183 184 ```sh 185 # Add yourself to the wheel group if you aren't already. 186 adduser user wheel 187 188 # Change the ownership of /etc/wpa_supplicant.conf 189 chown root:wheel /etc/wpa_supplicant.conf 190 191 # Make sure the configuration can be edited by the wheel group. 192 chmod 664 /etc/wpa_supplicant.conf 193 ``` 194 195 Your `wpa_supplicant` configuration must include the following line (or something similar): 196 197 ```plaintext 198 ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel 199 ``` 200 201 202 Here is the script 203 204 ```sh 205 #!/bin/sh 206 # Script to add wpa_supplicant networks through dmenu 207 208 if [ "$1" ]; then 209 name=$1 210 else 211 name=$(dmenu -p "Please enter network name, leave empty if you want to search" <&-) 212 fi 213 214 [ "$name" ] || { 215 wpa_cli scan 216 name=$( 217 wpa_cli scan_results | sed 1,2d | while read -r _ _ _ _ ssid _; do 218 # Hidden wifi are not to be returned 219 [ "$ssid" ] || continue 220 echo "$ssid" 221 done | sort -u | dmenu -l 10 -p "Please choose WiFi") 222 [ "$name" ] || exit 1 223 } 224 225 pass=$(dmenu -P -p "Please enter your password, leave empty if the network has open access.") 226 227 if [ "$pass" ]; then 228 wpa_passphrase "$name" <<EOF>> /etc/wpa_supplicant.conf 229 $pass 230 EOF 231 else 232 printf 'network={\n\tssid="%s"\n\tkey_mgmt=NONE\n\tpriority=-999\n}\n' "$name" >> /etc/wpa_supplicant.conf 233 fi 234 235 wpa_cli reconfigure 236 ``` 237 238 239 As I have said, you could do something similar in a command-line-only tool as 240 well. This one uses `fzf` on WiFi selection. 241 242 ```sh 243 #!/bin/sh -e 244 245 stty="$(stty -g)" 246 trap "stty $stty" EXIT INT TERM HUP 247 248 if [ "$1" ]; then 249 name=$1 250 else 251 printf 'Network Name, leave empty if you want to search: ' 252 read -r name 253 fi 254 255 [ "$name" ] || { 256 wpa_cli scan >/dev/null 257 name=$( 258 wpa_cli scan_results | sed 1,2d | while read -r _ _ _ _ ssid _; do 259 # Hidden wifi are not to be returned 260 [ "$ssid" ] || continue 261 echo "$ssid" 262 done | sort -u | fzf --prompt "Please choose WiFi: ") 263 } 264 265 [ "$name" ] || exit 1 266 267 stty -echo 268 printf 'Please enter your password, leave empty if the network has open access.\nPassword: ' 269 read -r pass 270 271 if [ "$pass" ]; then 272 wpa_passphrase "$name" <<EOF>> /etc/wpa_supplicant.conf 273 $pass 274 EOF 275 else 276 printf 'network={\n\tssid="%s"\n\tkey_mgmt=NONE\n\tpriority=-999\n}\n' "$name" >> /etc/wpa_supplicant.conf 277 fi 278 279 wpa_cli reconfigure 280 ``` 281 282 These scripts can be found as a gist [here](https://git.io/JULL6) 283 284 ******************************************************************************** 285 286 Static linking 287 ================================================================================ 288 [Permalink](/blog/20200828-static-linking.html) 289 290 Date: Aug 28 2020 291 292 293 While I was working on a new initramfs generator for Carbs, I was once again 294 reminded of the advantages of static linking software. Previously, I was using 295 some really dumb script that was just basically using the package manager as a 296 library for building the whole initramfs system from scratch. This system 297 structure was completely statically linked, and the whole thing weighed around 298 1.3MiB. 299 300 Now, while `rd` (the small script that I had written) was good enough for me, it 301 wouldn't be a fit to distribute with the system. It doesn't deal with dynamic 302 binaries, kernel modules or library installation. So I have written this script 303 that deals with those (kernel modules aren't done yet, though). 304 305 The issue with build systems today are that the binaries are built dynamically 306 unless you build the whole thing static. As long as there are shared libraries, 307 the binaries will be dynamic as well. That's why the core repository of Carbs 308 still contains dynamic binaries for gcc, binutils, util-linux and some other 309 packages. 310 311 The size of the new image with exactly the same binaries is a whopping 1.9MiB. 312 While a size increase of 600KiB might not seem like a huge deal, I just want to 313 tell you that busybox is static in both images, leaving ONLY TWO binaries that 314 I install to my image; fsck and e2fsck. By switching from a static binary to 315 dynamic + lib for only two programs, you require 600 KiB more space, and I have 316 been talking about a gzip compressed cpio archive throughout this whole post. 317 318 ******************************************************************************** 319 320 Starting X without Xinit 321 ================================================================================ 322 [Permalink](/blog/20200812-starting-x-without-xinit.html) 323 324 Date: Aug 12 2020 325 326 327 Most people who don't use a desktop environment use the `startx` command to 328 initialize their X windowing system. Now, `startx` is a shell script that runs 329 the C program `xinit` which basically runs `xorg-server`. Using xinit obviously 330 has some nice perks. It makes some checks and runs your .xinitrc file. We don't 331 need any of that though. Here is my X launcher: 332 333 ```sh 334 #!/bin/sh 335 336 export DISPLAY=${DISPLAY:-:0} 337 trap "$HOME/.xinitrc" USR1 338 339 ( 340 trap '' USR1 341 342 exec X -keeptty :0 vt1 343 ) & 344 345 wait 346 ``` 347 348 You need to keep in mind that your .xinitrc should be an executable. 349 350 ******************************************************************************** 351 352 Why I dislike Arch and Gentoo 353 ================================================================================ 354 [Permalink](/blog/20200508-why-i-dislike-arch-and-gentoo.html) 355 356 Date: May 08 2020 357 358 359 Over the years, I have used many many Linux distributions. The reason I am 360 now using a distribution maintained by me, is because I am never truly satisfied 361 about other people's work. Not that they are bad at they do, it's just that 362 they don't share the same vision as me. And I have felt this way with almost 363 every distribution I have used. 364 365 366 Arch Linux 367 -------------------------------------------------------------------------------- 368 369 Arch Linux itself feels like it became a 'meme distribution'. Their user-base 370 is a cult-like community that think they are superior for using Arch Linux. 371 Now, you might be an Arch user, and might not be like this. I used Arch for 372 a long time, and didn't feel this way, ever. I only see this level of cultism 373 for Arch and systemd. 374 375 If you ever call Arch bloated on an online community website, you will get 376 lots of crap for it. But in fact, Arch Linux is bloated. Now this isn't due 377 to having too many packages in the base installation. This is because of their 378 packaging of software. 379 380 Arch enables almost every single option in the package configuration, meaning 381 lots of unnecessary dependencies, and packages with humongous sizes. 382 383 Pacman is a rather slow package manager, and missing alternatives. For me, 384 an alternatives system is a must. 385 386 If you want to use a better binary distribution, use Void Linux. They have 387 saner package configurations, and the environment just feels more UNIXy. xbps 388 is really fast, and has an alternatives system. 389 390 391 Gentoo Linux 392 -------------------------------------------------------------------------------- 393 394 This will be the longer part, because my dislike for Gentoo is bigger than 395 my dislike towards Arch. If you want to see how NOT to maintain a distribution, 396 check out Gentoo. 397 398 I've used Gentoo for a few months, and I'm saying this right out of the 399 gate. Portage is the slowest piece of software that I have ever used on 400 Linux. Maybe that's because I deliberately avoid software using Python, 401 but Portage is most probably the slowest package manager that is being 402 used. 403 404 Portage depends on Bash, Python, and GNU wget. I have got a line count from 405 `cloc`, doing a `find . \( -name '*.sh -o -name '*.py' \) -exec cloc {} +`. 406 The source code of just `*.sh` and `*.py` files are over 100k lines of code. 407 Then I got curious and runned cloc against the whole repository. Here is 408 the output. 409 410 ``` 411 -------------------------------------------------------------------------------- 412 Language files blank comment code 413 -------------------------------------------------------------------------------- 414 Python 703 20009 21411 102180 415 Bourne Shell 13 643 678 3911 416 Bourne Again Shell 44 583 434 3172 417 diff 17 31 298 574 418 YAML 6 32 80 573 419 XSD 1 27 27 494 420 C 2 56 128 291 421 make 1 7 6 19 422 INI 1 1 0 15 423 reStructuredText 1 5 4 9 424 XSLT 1 0 0 5 425 -------------------------------------------------------------------------------- 426 SUM: 790 21394 23066 111243 427 -------------------------------------------------------------------------------- 428 ``` 429 430 That's quite a lot. 431 432 Portage is a package manager that tries to ease the configuration process of 433 packages, but at the process makes it terribly complex to compose packages, 434 and adds billions of portage configuration options. Configuring your first 435 kernel is literally easier than configuring portage in a way you want. Users 436 just do not know that they would be better off doing an LFS build for a much 437 stabler system. My system was broken countless times while using Gentoo. 438 Maintaining a Gentoo system is honestly harder than maintaining my own 439 distribution. 440 441 **EAPI**, probably the worst thing about the Portage ecosystem. It is the most 442 complex, hard to read, hard to learn packaging system ever made. Creating a 443 USE flag system shouldn't have been this hard. 444 445 ******************************************************************************** 446 447 Editor Wizardry 448 ================================================================================ 449 [Permalink](/blog/20200413-editor-wizardry.html) 450 451 Date: Apr 13 2020 452 453 454 To this day, I have tried lots of IDEs and text editors. Visual Studio, PyCharm, 455 Sublime, Notepad++, Vim, Emacs, Pico, Atom, etc. The list goes on. I have even 456 unironically used ed, and ironically used cat for a while. 457 458 I have settled down after years and years of "editor-hopping". I now have 3 459 main editors that I use on a daily basis! Yeah, you have read it correct. I use 460 3 editors on a daily basis. Those are, 461 462 - sed 463 - vi (not vim) 464 - emacs 465 466 467 Emacs 468 -------------------------------------------------------------------------------- 469 470 Emacs is a beast. Defining Emacs as a text-editor is wrong. It is a lisp 471 interpreter, with text manipulation abilities. 472 473 Now, I do like the concept of Integrated Development Environments. It's a shame 474 that all of them suck. With Emacs I can fine-tune everything according to my 475 taste, install the packages I need, configure them the way I like. With IDEs you 476 get some nice plugins, and a tiny bit of customization, but that's it. You get 477 an environment limited by the vision of someone else. Not to mention that most 478 IDEs are proprietary software. 479 480 I have stopped using Vim, because it is only meant to be a text editor. You can 481 extend its features with plugins, but you can really see the impact with just a 482 few of them. Vimscript is also really primitive, that's why people write plugins 483 with Python, JS, and such. This further affects the speed of Vim. Most Emacs 484 packages I have encountered are written in pure lisp. I have over 70 packages, 485 yet my load time and overall speed is better than when I had Vim with 8 plugins. 486 487 488 ### Cons 489 490 - **It comes with too many unnecessary features** Emacs comes with multiple IRC 491 clients, a mail reader, rss reader etc. I don't think they are badly 492 implemented or anything, I would just prefer building up as I want to instead. 493 - **The defaults are not intuitive** Now, I haven't actually tried any of them, 494 but there is a reason "Emacs distributions", such as "Spacemacs", "DOOM 495 Emacs", "Centaur" exist. The base of Emacs, even with its unnecessary 496 features, is unintuitive and complicated. 497 498 Also, let's not forget that Emacs uses an ancient Lisp dialect. 499 500 501 Vi 502 -------------------------------------------------------------------------------- 503 504 I mostly use Emacs when I am dealing with projects. If my aim is to just make 505 simple changes when I am on the terminal, I just pop up vi provided by busybox. 506 I just like that it is fast and featureless. It barely gets the job done, and 507 that's why I like it. 508 509 510 ### Cons 511 512 - **No syntax highlighting** Syntax highlighting is an important feature for me 513 but I have learned to live without it. Since I don't edit large files with it, 514 this is not the biggest con. 515 - **Hard to configure** Busybox vi only has a limited featureset, which makes 516 it hard to configure. It doesn't read an `rc` file, it uses the `$EXINIT` 517 variable instead. Available options are limited. For example, you cannot 518 convert the "tab" action to use space instead of tabs. 519 - **No visual selection support** Sadly, `v/V` isn't implemented in busybox vi. 520 521 522 Sed 523 ------------------------------------------------------------------------------- 524 525 I use sed for when I am making small changes to small files, because it is 526 faster than opening a file, making a change, saving, and exiting. Using regular 527 expressions are much faster and efficient at such things. 528 529 ### Cons 530 531 - **Risky unless you know what you are doing** Since sed is operated on regex, 532 you need to be extra careful. You are running that regex on the entire file 533 without an option to 'undo' (unless you have a sed that has a backup 534 implementation).