Fix a few typos. (#5)

Co-authored-by: Hoel Bagard <hoel.bagard@gmail.com>
Reviewed-on: ayo/website#5
Co-authored-by: hoel <hoel@ayo.tokyo>
Co-committed-by: hoel <hoel@ayo.tokyo>
This commit is contained in:
hoel 2023-09-14 15:32:55 +09:00 committed by corentin
commit e5c6ae1061

View file

@ -3,9 +3,9 @@
## Preambule ## Preambule
This month I had to setup a new server to host this very website as well as additional subdomains for self-hosted Git and Doc/Calendar sharing application. All of this doesn't require any big hardware and can be handle by a small IoT in my office. This month I had to setup a new server to host this very website as well as additional subdomains for self-hosted Git and Doc/Calendar sharing application. All of this doesn't require any big hardware and can be handled by a small IoT in my office.
Deploying a server, even a small and simple one, has some caveates that need to be taken into consideration. I will share the setup I just did for the last server I am using to host my application in-house. Deploying a server, even a small and simple one, has some caveats that need to be taken into consideration. I will share the setup I just did for the last server I am using to host my application in-house.
## Hardware consideration ## Hardware consideration
@ -13,13 +13,13 @@ The first name that is probably coming to everyone is Raspberry-pi. It's capable
Here's a quick overview of the problems I know: Here's a quick overview of the problems I know:
* GPU capabilities were not great because the vendor Broadcom wasn't helpful with the FOSS (Free Open Sourced Software) community and the driver was lacking. This means that outputing realtime images/video and overlay would be very slow unless you swtich to the experimental driver. The experimental driver has issues such as stability and I even got noisy output (bearable, only few pixels here and there but weird nonetheless). * GPU capabilities were not great because the vendor Broadcom wasn't helpful with the FOSS (Free Open Sourced Software) community and the driver was lacking. This means that outputing realtime images/video and overlay would be very slow unless you switched to the experimental driver. The experimental driver has issues such as stability, and I even got noisy output (bearable, only few pixels here and there but weird nonetheless).
* No real ethernet but ethernet over USB (was fixed from version 3 or 4), coupling with a single not-so-powerful USB controller, this would lead to USB congestion. For instance you couldn't use 2 webcams in 720p resolution at 30 fps (not even sure about 480p, I had to tune down the resolution and FPS a lot). During USB congestion any SSH session would get stuck working with such a device. * No real ethernet but ethernet over USB (was fixed from version 3 or 4), coupling with a single not-so-powerful USB controller, this would lead to USB congestion. For instance you couldn't use 2 webcams in 720p resolution at 30 fps (not even sure about 480p, I had to tune down the resolution and FPS a lot). During USB congestion any SSH session would get stuck working with such a device.
* SD card reader was extremely slow (version 1 and 2, probably 3 too) * SD card reader was extremely slow (version 1 and 2, probably 3 too)
* With time the value proposition gets worse for the price : the raspberry-pi started as a cheap computer experience for educational purposes and prototyping. But now the price is quadruple for performance that is not even above average compared to other devices * With time the value proposition gets worse for the price : the raspberry-pi started as a cheap computer experience for educational purposes and prototyping. But now the price is quadruple for performance that is not even above average compared to other devices.
* Version 4 opted for a micro-HDMI instead of full-sized * Version 4 opted for a micro-HDMI instead of full-sized
There are many alternatives I looked at, among them one caught my attention : Odroid. This device was widely known for a long time and the company, base in South-Korea, is now named hardkernel. The proximity of the company is very nice and the catalog they offer is very interesting. Here are a few points that made me, over time, look mostly at them for my IoT needs: There are many alternatives I looked at, among them one caught my attention : Odroid. This device was widely known for a long time and the company, based in South-Korea, is now named hardkernel. The proximity of the company is very nice and the catalog they offer is very interesting. Here are a few points that made me, over time, look mostly at them for my IoT needs:
* Very focused on making hardware and not selling other things * Very focused on making hardware and not selling other things
* Great value proposition for the price : especially for the accessories (power supply, cases, etc) * Great value proposition for the price : especially for the accessories (power supply, cases, etc)
@ -42,9 +42,9 @@ Long story short : I eventually have ended up using the Odroid-N2+ device multip
### Distribution Choice ### Distribution Choice
Finding a good Linux distribution can be troublesome too. For me the choice is not to hard to make : I come from a Debian background and most of the corporate-minded distributions such as CentOS(discountined now)/RHEL have no appeal to me. I can fix my issues and contribute back if needed, I don't need support. Finding a good Linux distribution can be troublesome too. For me the choice is not too hard to make : I come from a Debian background and most of the corporate-minded distributions such as CentOS(discontinued now)/RHEL have no appeal to me. I can fix my issues and contribute back if needed, I don't need support.
[Debian](https://wiki.debian.org) is amazing at it's job : being stable. The people maintaining it are probably the most professional and rigorous I've seen. There is one drawback of the distribution : everything is ~3 years old. Because of my bias with deep learning engineering needing more recent libraries and issues that I had in the past with too-old databases (namely MySQL) to get very important features, I am choosing another distribution. Also note that official Debian do not offer a lot of possibilities for [Arm ports](https://wiki.debian.org/Arm64Port). [Debian](https://wiki.debian.org) is amazing at its job : being stable. The people maintaining it are probably the most professional and rigorous I've seen. There is one drawback of the distribution : everything is ~3 years old. Because of my bias with deep learning engineering needing more recent libraries, and issues that I had in the past with too-old databases (namely MySQL) to get very important features, I am choosing another distribution. Also note that official Debian does not offer a lot of possibilities for [Arm ports](https://wiki.debian.org/Arm64Port).
For IoTs [Armbian](https://www.armbian.com/) is amazing and definitely a strong choice. I am using this in some of my devices, it has very interesting defaults that I will get inspiration from (like on-memory logs). For IoTs [Armbian](https://www.armbian.com/) is amazing and definitely a strong choice. I am using this in some of my devices, it has very interesting defaults that I will get inspiration from (like on-memory logs).
@ -54,15 +54,15 @@ Being familiar with ArchLinux, [ArchLinuxArm](https://archlinuxarm.org/) is a pe
### Installation ### Installation
Compared to PC installation, installing ArchLinux for Arm platforms is way more straightforward. The boot sequence of Arm devices is very different and I have never seen UEFI on Arm. Also Arm devices boot thanks to device tree (declared is .dts files in the kernel code directly and compiled to .dtb files), those describe all the hardware and the initialization values to make the device works. This means that the Linux project has hundred, if not thousand, of those files to be able to run on any device (the dts can be targeting a family of devices shared thus far). Compared to PC installation, installing ArchLinux for Arm platforms is way more straightforward. The boot sequence of Arm devices is very different and I have never seen UEFI on Arm. Also Arm devices boot thanks to device tree (declared is .dts files in the kernel code directly and compiled to .dtb files), those describe all the hardware and the initialization values to make the device works. This means that the Linux project has hundreds, if not thousands, of those files to be able to run on any device (the dts can be targeting a family of devices shared thus far).
Installing Linux on an IoT usually means copying a prepared image on an SD card or other storage. Sometimes with the DTB files given in a separate boot partition for linux to boot with. Also additional initiazition values can be set in the boot partition in a `boot.ini` files. The boot sequence usually starts not from linux but from a boot loader : on PC Grub is a common one, on IoT you may encounter `u-boot` and more rarely `petitboot`. Those are usually already prepared so nothing needs to be done on that part. Installing Linux on an IoT usually means copying a prepared image on an SD card or other storage. Sometimes with the DTB files given in a separate boot partition for linux to boot with. Also additional initiazition values can be set in the boot partition in a `boot.ini` files. The boot sequence usually starts not from Linux but from a boot loader : on PC Grub is a common one, on IoT you may encounter `u-boot` and more rarely `petitboot`. Those are usually already prepared so nothing needs to be done on that part.
For ArchLinuxArm preparing the partition on the storage is the biggest part of the installation but only requires ~10 commands and is nicely documented. For the Odroid-N2 the procedure is described [here](https://archlinuxarm.org/platforms/armv8/amlogic/odroid-n2). For ArchLinuxArm preparing the partition on the storage is the biggest part of the installation but only requires ~10 commands and is nicely documented. For the Odroid-N2 the procedure is described [here](https://archlinuxarm.org/platforms/armv8/amlogic/odroid-n2).
Additional commands you probably want to do at first, as root, would be: Additional commands you probably want to do at first, as root, would be:
* **Edit pacman (the package manager) configuration** : `vim /etc/pacman.conf` (here's with `vim` but `nano` would also work fine). Uncommenting the `Color`, `VerbosePkgLists` and `ParallelDownloads` is a must have. * **Edit pacman (the package manager) configuration** : `vim /etc/pacman.conf` (here using `vim`, but `nano` would also work fine). Uncommenting the `Color`, `VerbosePkgLists` and `ParallelDownloads` is a must have.
* **Update all packages** : `pacman -Syu` * **Update all packages** : `pacman -Syu`
* **Installing sudo** : `pacman -S sudo` * **Installing sudo** : `pacman -S sudo`
* **Create sudo group and add your user to it** : `groupadd sudo` and `usermod -aG sudo myuser`. * **Create sudo group and add your user to it** : `groupadd sudo` and `usermod -aG sudo myuser`.
@ -73,6 +73,6 @@ Additional commands you probably want to do at first, as root, would be:
## Conclusion ## Conclusion
I hope this instroduction to the hardware and software used for self hosting was interesting and maybe gave you some thoughts about trying it yourself. There are many topics from here that I will present : security, server software installation and configuration, DNS, certificates, etc. Stay tuned for the next post. I hope this introduction to the hardware and software used for self hosting was interesting and maybe gave you some thoughts about trying it yourself. There are many topics from here that I will present : security, server software installation and configuration, DNS, certificates, etc. Stay tuned for the next post.
Corentin Risselin. Corentin Risselin.