summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEkaitz Zarraga <ekaitz@elenq.tech>2020-07-30 16:59:13 +0200
committerEkaitz Zarraga <ekaitz@elenq.tech>2020-07-30 16:59:13 +0200
commit19ed330f5067a393839d983252d4a8799e296ad2 (patch)
tree30d2d566406550ab4cfd979777a7f8928bbf627d
parent6b9f5b47ea5da451a9307f50ce312d013f873030 (diff)
Update contents
-rw-r--r--content/donations/01-Gnu-Guix.md2
-rw-r--r--content/donations/02-Chibi-Scheme.md130
-rw-r--r--content/git-setup.md350
-rw-r--r--content/pages/about.md5
4 files changed, 486 insertions, 1 deletions
diff --git a/content/donations/01-Gnu-Guix.md b/content/donations/01-Gnu-Guix.md
index d9c4e0a..8624edd 100644
--- a/content/donations/01-Gnu-Guix.md
+++ b/content/donations/01-Gnu-Guix.md
@@ -7,7 +7,7 @@ Lang: en
Summary: Recent ElenQ Technology donation to the great GNU Guix package manager
and software distribution
-> Read all the posts about [ElenQ Donations here]({tag}donations).
+> Read all the posts about [ElenQ Donations here]({tag}elenq-donations).
I consider my work part of my responsibility to make this world a better place
so since the early beginning of the company I decided to donate as much as I
diff --git a/content/donations/02-Chibi-Scheme.md b/content/donations/02-Chibi-Scheme.md
new file mode 100644
index 0000000..501fa1e
--- /dev/null
+++ b/content/donations/02-Chibi-Scheme.md
@@ -0,0 +1,130 @@
+Title: ElenQ Donations — Chibi Scheme
+Date: 2020-05-31
+Categories: Series
+Tags: ElenQ Donations
+Slug: donations-chibi-02
+Lang: en
+Summary: Donation to Chibi Scheme programming language
+
+> Read all the posts about [ElenQ Donations here]({tag}elenq-donations).
+
+In a previous post I already talked about why I consider important to donate
+money or time to Free Software projects.
+
+This time I want to talk about my recent contributions to Chibi Scheme's
+standard library.
+
+Chibi Scheme is a R7RS scheme implementation that was designed to work as an
+extension or scripting language. It's just a small library you can embed.
+That's similar to Lua, but with *a lot* of parenthesis[^1].
+
+For those that are not familiar with Scheme: it's just a programming language
+you should read about. You'll probably discover all those new cool things you
+have in your programming language of choice are not that new[^2].
+
+There's a detail I'd like to talk about, though. Contrary to other programming
+language definitions or standards, Scheme's R7RS report is something you can
+read yourself. It's less than 100 pages long[^3].
+
+If you combine that with the design decisions that Alex Shinn (who also took
+part on the R7RS definition) took on Chibi Scheme, you end up with a *simple*
+programming language you can actually read.
+
+That's important.
+
+You might wonder why should you care about the readability of a programming
+language if you are just a user. The answer is simple too: free software relies
+in the fact that you can audit and improve or customize it. If you are not able
+to read it you can't exercise your rights by yourself and you'll always need to
+rely in someone else. That's not intrinsically bad, that's the only solution
+that non-programmer users have. Programmers need to trust other people in other
+things as well so that's not a major issue.
+
+Problems come when projects get so complicated —and I mean
+millions-of-lines-of-code complicated here— only large companies have enough
+resources to tackle the task of editing the code. In those cases, software is
+not really free anymore, because *in practice* you are unable to use your
+rights and you can't afford to find someone else to do it for you.
+
+We started to get used to that, though.
+
+Something I learned as a sculptor is the tools that fit you better are those
+that you made, you hacked or you get used to. As programmers, we are supposed
+to know how to program, so we are supposed to be able to make and hack the
+tools but we are deciding to get used to the ones that others built.
+
+The first step to control your workspace, and consequently your own job is to
+control your tools[^4].
+
+I'd love to say those are the reasons why I use Chibi Scheme, but that's not
+*totally* true. I don't know why I use it. I just *like it*.
+
+Anyway, the other day I realized Chibi Scheme's JSON parser was unable to parse
+Spanish accents so I was unable to control [ElenQ
+Publishing's](http://en.goteo.org/project/elenq-publishing) book's metadata
+correctly. That's a problem.
+
+As the language is simple, I was able to read the standard library and propose
+a change that would let the JSON parser use UTF-8 characters.
+
+<https://github.com/ashinn/chibi-scheme/pull/643>
+
+During the process I checked [CPython's JSON parser
+implementation](https://github.com/python/cpython/blob/master/Lib/json/decoder.py#L117)
+and I realized I could do it better adding surrogate pair support. So I decided
+to add it too.
+
+<https://github.com/ashinn/chibi-scheme/pull/644>
+
+Once my changes were merged, I realized it was a good idea to keep going and
+add a JSON encoder, that wasn't developed yet. So I did.
+
+<https://github.com/ashinn/chibi-scheme/pull/648>
+
+While I was testing my JSON encoder I realized there was an issue with floating
+point numbers in the JSON parser. So I fixed that too.
+
+<https://github.com/ashinn/chibi-scheme/pull/647>
+
+I also fixed some random indentation issue I found:
+
+<https://github.com/ashinn/chibi-scheme/pull/646>
+
+I didn't really need to do all what I did, but I did it anyway. I just wanted
+to keep Chibi Scheme healthy while I was opening the door to some future
+contributions. Now I have a little bit more control on my tooling, and I feel
+more comfortable with the fact that I might need to make some changes on
+Chibi's code in the future.
+
+It doesn't need to be perfect, neither. I'm sure it isn't, because I didn't
+write C code since I was at university and I had zero experience working on
+Chibi-Scheme's internals. My code was just enough to make the features happen,
+now with Alex's changes the code is running fine and **everyone** can benefit
+from this.
+
+So, the message I take from this can be summarized in these points:
+
+- Use tools you can read and edit like Chibi Scheme or even CPython, which is a
+ large codebase but is surprisingly easy to read.
+- Programming languages (or their stdlib) should never be considered something
+ untouchable. Touch them, change them, make them fit your needs.
+- Don't be afraid of tackling something that may seem hard on the first look.
+- You don't have to be perfect.
+- Spend time and energy on stuff that matters.
+
+Hope all this —the post and the code— is useful.
+
+Being useful is the greatest goal of an engineer, after all.
+
+Take care.
+
+[^1]: And no `end`-s. Less typing for sure: good for your hands.
+
+[^2]: And maybe not that cool neither.
+
+[^3]: I'm not going to talk about the implications of that fact. It's obvious
+ there must be some kind of trade-off comparing to other standards that are
+ more than one thousand pages long. I'll just recommend you to read it, it's
+ pretty good: <https://small.r7rs.org/attachment/r7rs.pdf>
+
+[^4]: In fact, that's the second. I'm supposing we all know what we are doing.
diff --git a/content/git-setup.md b/content/git-setup.md
new file mode 100644
index 0000000..e4f5b06
--- /dev/null
+++ b/content/git-setup.md
@@ -0,0 +1,350 @@
+Title: Our own git server
+Date: 2020-07-09
+Category:
+Tags:
+Slug: git-repo
+Lang: en
+Summary: How to set up a git server with simple tools
+
+Having some rest these days after some really hardworking months... I decided I
+wanted to solve something that was on my to-do list for a long time. Really
+long time.
+
+I wanted to have my own git repository for ElenQ and my personal projects
+(which are the same thing because I take ElenQ *very* personally) and so I did.
+
+You may think: so you installed Gitea or something and you are done, right?
+
+But the answer is no.
+
+That would be the normal approach if I didn't have the arbitrary constraints I
+imposed. This text is about those weird constraints and random thoughts I have
+about this, and also about what's my current setup and how to make it. Serving
+the second part as a *tutorial* for myself if I screw up and I need to start
+over and also as a way to consciously think about what I did.
+
+### Context: random thoughts
+
+For me code is not a social network and it shouldn't be. I understand why
+github is the way it is but for me it's just code. I don't need to show how
+much I code, I don't need to follow, like, star, fork, or even share my opinion
+about other people's work publicly. That's completely unrelated to the job.
+
+Large projects like github are changing the way we collaborate. I'm not against
+that, but looks like we start to forget that git doesn't need anything else to
+function. There's no need for pull/merge requests, for web servers or anything.
+
+Web interfaces for code are cool, but nothing is better than your own editor.
+I realized I just clone the repositories I want to dig in and search with my
+own tools in my local clone so... Why bother to have a powerful[^powerful] web
+interface?
+
+I don't like to be forced to register in a platform just for sending patches or
+taking part in a project. Why do I **need** to have a github account?
+
+ElenQ Technology currently uses a free gitlab account, but recently I've
+started to be concerned about gitlab's business practices so I prefer to start
+migrating out of it. I've seen they always send you to login page when you hit
+a 404, and all that kind of weird behaviours that don't look they have been
+done by accident[^gitlab]. Of course, there's also the fact that they are a
+startup and all that. I don't really trust them. But that's a different story.
+I still like the fact that their community edition is free software. It's a
+business model we should do more.
+
+Gitea and Gogs are easy to install, which is a must for me, and they are simple
+and useful, but replicate the same model. It's much better to self-host your
+code than relying in a third party, no doubt. But that makes the login problem
+even harder: more gitea or gogs instances we create more separate places to
+register in[^forgefed].
+
+Those free software tools solve the problem of the centralization in different
+scales, but they are small social networks, still.
+
+### Possible replacements
+
+I'm ok with sending an email and I'm ok with receiving emails from people.
+
+With git's email workflow (`git sendmail`, or `git format-patch` if you don't
+want to configure your connection to your email account) you can send patches
+via email that can be applied in the code directly. That's more than enough for
+many projects.
+
+Issues, suggestions and questions can be sent via email with no hassle, too.
+
+The possibility to clone the repositories via git protocol gives people the
+chance to check the code freely in their editor of choice, without being
+tracked while they browse[^editor].
+
+### Problems
+
+Issue management makes perfect sense to me and it's a process that is cool to
+have in the open. It helps people take part in projects, check what's the
+status of the project, collaborate more effectively, share the bugs they find
+and so on. But, for the kind of projects I have, issue management is more of a
+problem than a solution. I've been receiving spam in my gitlab issues for a
+while. To be honest, there have been more spam than real issues in my gitlab
+account.
+
+There's not any easy way to fully replace an issue management tool, though.
+Maybe a good use of the `README.md` and some extra files in the repository can
+help. People are still able to reach and share their bug reports via email
+without being publicly exposed.
+
+That's also a thing: if you let people interact freely on an issue board you
+need some moderation (which requires skills and effort). It is true that people
+may come to very interesting ideas if working together, but it's also true that
+only happens in very popular projects[^popularity]. Handling that privately
+helps to avoid misunderstandings you can't control.
+
+Apart from that, we have to admit only sharing repositories via git protocol
+has exactly `0` discoverability, so we have to share them in a website or
+something. Maybe not for interacting with them, but at least to show them.
+
+Git is able to handle a website via gitweb too, but it's simple, a little bit
+hard to configure and not too fast. Also, it can be more visually appealing by
+default.
+
+On the owner's side, it's interesting to be able to decide which repositories
+you want to share with the public. Being able to give permissions to specific
+people without giving them permissions to the whole server is also nice. If
+the permissions can be set in specific branches of the repositories better.
+
+### Other option
+
+[Fossil-scm](https://fossil-scm.org/home/doc/trunk/www/index.wiki) is really
+interesting. It comes with support for issues and wikis, and devnotes are a
+great idea I'm sure I could take advantage of.
+
+But the tool itself is not as good as git in my opinion.
+
+Fossil uses SQLite databases for its things (it's developed by SQLite's
+developers) which is cool sometimes but in other times is not as good as it
+sounds. I'm getting too used to plain text files maybe?
+
+I tried to configure a multi-repository fossil for the server and I gave up in
+the past but it's probably my fault rather than theirs.
+
+If you are interested on trying something new, you should take a look to
+fossil. If you do, please, [contact
+me](https://ekaitz.elenq.tech/pages/about.html) and tell me your experience
+with it.
+
+### My solution
+
+For the permissions I used Gitolite, which is an authorization control that
+makes heavy use of ssh. It uses a management repository where the administrator
+can add users' public keys and each project's permissions and metadata.
+
+It basically creates ssh pseudo-sessions that are locked in gitolite-shell,
+which decides if the user has access to the repo or not. Interesting use of ssh
+for this. [Read more in the website][gitolite], they explain it much better
+than I can.
+
+For the website I chose `cgit`, which is famous for being fast (cached by
+default) and reliable, and turned out to be easy to configure.
+
+Both projects are in the order of some thousands lines of code, which is an
+amount I could manage to read and edit if I want to.
+
+### How to configure
+
+Well, this is the reminder for myself, but it can be useful for you too.
+
+I installed both of the projects using debian's package repository.
+
+#### Gitolite
+
+By default, debian package creates a `gitolite3` user so you have to take that
+in account if you want to make gitolite work in a debian machine (other
+machines will have other details to check).
+
+Gitolite's debian package also asks for administrator's public ssh-key so you
+have to provide it sooner or later. Once that's done you'll get a fantastic
+`/var/lib/gitolite3` folder with everything you need. You'll see that folder
+contains a `projects.list` file, that lists the git repositories, a
+`repositories` folder with the repositories, a `.gitolite` folder and a
+`.gitolite.rc` file. The last one needs some changes in order to work correctly
+with cgit:
+
+#### Enable cgit access to the repos
+
+Set `.gitolite.rc`'s `UMASK` to `0027` to give group access to new repositories,
+that will let other users in the group (cgit and git-daemon) access the
+repositories.
+
+You probably don't want to share the gitolite-admin repository so leave it with
+the permissions it came with. If you screw up here or there don't be afraid to
+`chmod` any repository later.
+
+You also need to make `GIT_CONFIG_KEYS` more permissive (`.*` if you are crazy
+enough) if you want Gitolite to be able to load git configuration. That way
+you'll be able to set gitweb description in the repository that cgit can read.
+
+#### Enable git unauthenticated clone
+
+There are a couple of ways to do this. The first is to set the HTTP mode, that
+is something I didn't do but you can check how to do it in the docs.
+
+I used git-daemon for git based unauthenticated clones. It's simple but you
+may need to create your own systemd service or something:
+
+ ::systemd-service
+ # git.service file
+
+ [Unit]
+ Description=Start Git Daemon
+
+ [Service]
+ ExecStart=/usr/bin/git daemon --base-path=/var/lib/gitolite3/repositories --reuseaddr /var/lib/gitolite3/repositories
+
+ Restart=always
+ RestartSec=500ms
+
+ StandardOutput=syslog
+ StandardError=syslog
+ SyslogIdentifier=git-daemon
+
+ User=gitdaemon
+ Group=gitolite3
+
+ [Install]
+ WantedBy=multi-user.target
+
+Once you do that you should add it to systemd with `systemctl enable
+/path/to/git.service` or something like that. Once added you can start it.
+
+But that's not going to show any repository because you didn't export any. If
+you want to export them, Gitolite has an specific configuration option you have
+to set in the `gitolite-admin` repo. You have to give the user `daemon` read
+access:
+
+ ::perl
+ repo testing
+ # daemon is what adds the daemon-export
+ R = daemon
+ # You should add some extra people too...
+
+ # This is for cgit:
+ config gitweb.description = For testing purpose.
+ config gitweb.owner = Ekaitz
+
+When you add the `daemon` access Gitolite adds a `git-daemon-export-ok` file to
+the repository that says to git-daemon the project can be shared. It won't be
+possible to push to it anyway because we didn't allow it in the git-daemon
+configuration.
+
+
+#### cgit
+
+Some cgit configuration does the rest. This is my example configuration on
+cgit. I'll probably change it soon, but there it goes:
+
+ ::bash
+ # cgit config
+ # see cgitrc(5) for details
+
+ css=/cgit.css
+ logo=/cgit.png
+ footer=/usr/share/cgit/footer.html
+
+ repository-sort=age
+
+ # if cgit messes up links, use a virtual-root.
+ # For example, cgit.example.org/ has this value:
+ virtual-root=/
+
+ clone-url=git://$HTTP_HOST/$CGIT_REPO_URL
+ # gitolite3@$HTTP_HOST:$CGIT_REPO_URL
+
+ enable-index-links=1
+ enable-index-owner=1
+ enable-git-config=1
+ enable-gitweb-owner=1
+ remove-suffix=1
+
+ # Readmes to use
+ # readme=README.md
+ # you can set more of them here like README.rst and stuff, but all of them
+ # require some rendering I didn't want to configure.
+
+ # Set title and description
+ root-title=ElenQ Technology
+ root-desc=Software repository for ElenQ
+ root-readme=/usr/share/cgit/root-readme.html
+
+ project-list=/var/lib/gitolite3/projects.list
+ scan-path=/var/lib/gitolite3/repositories
+
+ # Mimetypes
+ mimetype.gif=image/gif
+ mimetype.html=text/html
+ mimetype.jpg=image/jpeg
+ mimetype.jpeg=image/jpeg
+ mimetype.pdf=application/pdf
+ mimetype.png=image/png
+ mimetype.svg=image/svg+xml
+
+But cgit is still unable to see the projects because it's not part of the
+`gitolite3` group. Make it part of the `gitolite3` group with `usermod` or
+something.
+
+Also, cgit is a web server you have to add to your stuff. I have an nginx based
+config so I need to add cgit to it. Cgit can work with uWSGI or fcgiwrap. I
+chose the latter for no real reason:
+
+ ::nginx
+ server {
+ listen 80;
+ listen [::]:80;
+ server_name git.elenq.tech;
+ root /usr/share/cgit;
+ try_files $uri @cgit;
+
+ location @cgit {
+ include fastcgi_params;
+ fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
+ fastcgi_param PATH_INFO $uri;
+ fastcgi_param QUERY_STRING $args;
+ fastcgi_param HTTP_HOST $server_name;
+ fastcgi_pass unix:/run/fcgiwrap.socket;
+ }
+ }
+
+
+Also you may be interested on HTTPS support, but you know how to add that
+(certbot does, and it's not hard to do).
+
+### Closing words
+
+Now it's live at [https://git.elenq.tech](https://git.elenq.tech). If you were
+wondering, cloning and pushing from there crazy fast, and the server that hosts
+it is the cheapest server possible. It's much faster than github, or that's at
+least my impression.
+
+So yeah... That's most of it.
+
+I just wanted to share some thoughts about software development workflow and
+find an excuse to write down my configuration since I had issues to find any
+explanation that had all the points I needed together.
+
+And I think I did, didn't I?
+
+Stay safe.
+
+
+
+[gitolite]: https://gitolite.com/gitolite/overview.html
+
+[^powerful]: There's no power for free. Powerful also means resource-intensive.
+
+[^gitlab]: cHeCKiNg YOur brOWsER bEfOrE AcCeSsIng gitLAB.cOm.
+
+[^forgefed]: Maybe not. Forgefed is doing a good job:
+ <https://forgefed.peers.community/>
+
+[^editor]: It also depends on the editor you choose. Choose wisely.
+
+[^popularity]: If a project I make reaches that kind of popularity, I'll open
+ a tool for that kind of discussion or maintain a mirror somewhere else.
+
+
diff --git a/content/pages/about.md b/content/pages/about.md
index 473b5c2..d3dc298 100644
--- a/content/pages/about.md
+++ b/content/pages/about.md
@@ -32,6 +32,11 @@ my thoughts and my decisions, but it's also a way to represent the way I work
and the things I like. Sometimes, I use this space to share stuff I learned
thanks to the R&D projects or as a backlog of what I do.
+### Contact
+
+You can find me in the fediverse at
+[@ekaitz_zarraga@mastodon.social](https://mastodon.social/@ekaitz_zarraga) and
+you can contact email me to [hello@elenq.tech](mailto:hello@elenq.tech).
<figure>
<img src="{static}/static/images/ekaitz.jpg">