Remove projects directory
This commit is contained in:
parent
6a29c0b11e
commit
94f84da78b
|
|
@ -20,15 +20,10 @@
|
|||
pageRef = "about"
|
||||
weight = 20
|
||||
|
||||
[[main]]
|
||||
name = "Projects"
|
||||
pageRef = "projects"
|
||||
weight = 30
|
||||
|
||||
[[main]]
|
||||
name = "Articles"
|
||||
pageRef = "articles"
|
||||
weight = 40
|
||||
weight = 30
|
||||
|
||||
[[main]]
|
||||
name = "Source Code"
|
||||
|
|
|
|||
|
|
@ -1,4 +0,0 @@
|
|||
+++
|
||||
title = "Projects"
|
||||
showPosts = false
|
||||
+++
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
+++
|
||||
title = "ITD"
|
||||
date = "2022-09-13"
|
||||
summary = "Linux companion daemon for the PineTime smartwatch"
|
||||
weight = 20
|
||||
+++
|
||||
|
||||
# ITD - InfiniTime Daemon
|
||||
|
||||
[ITD](https://gitea.elara.ws/Elara6331/itd), short for InfiniTime Daemon, is one of my biggest and most-used projects. It's a companion daemon for the PineTime smartwatch on Linux, functioning similarly to the Watch app on iOS, but on Linux and for the PineTime instead of the Apple Watch.
|
||||
|
||||
The daemon runs in the background and manages Bluetooth communication with the watch. Upon startup, it exposes a UNIX socket to accept API requests from the frontends, including `itctl` (a CLI frontend) and `itgui` (a GUI frontend).
|
||||
|
||||
ITD implements all features exposed by the InfiniTime firmware, including some not yet available or without frontends on the watch.
|
||||
|
||||
I've collaborated with InfiniTime firmware developers to design and add new features to both the firmware and ITD, and they've also used ITD to test new features they were implementing. ITD is mentioned in various places, such as the InfiniTime README, Pine64's wiki pages for PineTime, and blog posts from Pine64 (the manufacturer of the PineTime).
|
||||
|
||||
This project showcases a lot of my knowledge, utilizing SQLite for storing metrics (e.g., step count, heart rate), Bluetooth Low-Energy for communication with the watch, DBus for communication with the Bluetooth daemon and various other system components, UNIX sockets for Inter-Process Communication between frontends and the daemon, and several REST APIs to get information such as weather and location.
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
+++
|
||||
title = "LURE"
|
||||
date = "2023-02-12"
|
||||
showSummary = true
|
||||
summary = "Distro-agnostic AUR-like build system for Linux"
|
||||
weight = 30
|
||||
+++
|
||||
|
||||
## About
|
||||
|
||||
[LURE](https://lure.elara.ws/) is a major project that I'm currently working on. It allows Linux users to install software not otherwise available in their distro's repositories. It functions in a similar manner to Arch Linux's AUR, but works for any supported distro.
|
||||
|
||||
## How it works
|
||||
|
||||
LURE uses various techniques to abstract package formats and package managers, enabling the creation and installation of packages automatically built from bash scripts similar to the AUR's PKGBUILD scripts. It uses the package manager already present on the system, making it possible to manage LURE packages as you would any other distro package.
|
||||
|
||||
## Motivation
|
||||
|
||||
Arch Linux has a feature called the AUR, which allows any user to submit a package for other users to install. This means any user interested in a piece of software can package it for everyone, providing a repository of just about any software one could want to install. I feel this feature shouldn't be constrained to just Arch Linux, and should be available for everyone to use, allowing people to install software with a complicated install procedure, without having to worry about performing that procedure, as LURE handles it automatically.
|
||||
|
||||
## Problems with this approach
|
||||
|
||||
Trying to handle the various differences between the software available on each distro, especially library versions, is very difficult. This is not a problem LURE intends to solve. It simply provides a way for developers to automate the procedure of installing their software, so that their users don't have to figure it out themselves. This means that developers will have to handle some of those differences, such as dependency naming. However, LURE will help wherever it can, providing helper commands to create packages that adhere to the guidelines of the distro the package is being built for.
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
+++
|
||||
title = "PCRE"
|
||||
date = "2022-09-13"
|
||||
showSummary = true
|
||||
summary = "CGo-free port of PCRE2 to the Go programming language"
|
||||
weight = 10
|
||||
+++
|
||||
|
||||
## About
|
||||
|
||||
[PCRE](https://gitea.elara.ws/Elara6331/pcre) is a CGo-free port of the PCRE2 regular expression engine to Go. Being CGo-free means that rather than just being bindings to the PCRE2 library, this is a pure Go implementation of PCRE2.
|
||||
|
||||
## How it works
|
||||
|
||||
The implementation leverages a remarkable tool known as [ccgo](https://pkg.go.dev/modernc.org/ccgo/v3), which is a compiler that converts C code into Go. The source code of PCRE2 was converted to Go using `ccgo`. I only have `linux/amd64` and `linux/arm64` systems, so cross-compilation using various C toolchains was performed and tested using `qemu-user-static` to emulate the desired CPU architectures.
|
||||
|
||||
For macOS, the process was more intricate as there is no suitable cross-compilation toolchain from Linux. Therefore, a macOS Virtual Machine was created using [OSX-KVM](https://github.com/kholia/OSX-KVM) and used to build PCRE2 for `darwin/amd64` and `darwin/arm64`.
|
||||
|
||||
Once the code was converted, a memory-safe interface was created on top of it. This interface adheres to the conventions used in Go's standard library `regexp` package, so it can be used as a drop-in replacement.
|
||||
|
||||
## Motivation
|
||||
|
||||
Go's standard library [`regexp`](https://pkg.go.dev/regexp) package lacks features like lookaheads and lookbehinds. This was intentional, as it guarantees that regular expressions cannot be exploited for a Denial-of-Service (DoS) attack, known as a ReDoS attack. However, there are cases where these features are necessary, and the expression is compiled into the program or provided in a configuration file, so the source is trusted.
|
||||
|
||||
## When to avoid
|
||||
|
||||
It is important to note that PCRE2 is vulnerable to ReDoS attacks because of its extra features, such as lookaheads and lookbehinds. If the source of the expression cannot be trusted, it is advisable not to use PCRE2, and instead use the Go standard library `regexp` package.
|
||||
Loading…
Reference in New Issue