1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
What I'm working on (Fall 2014)
===============================
---
date: "2014-09-11"
---
I realized today that I haven't updated my log in a while, and I don't
have any "finished" stuff to show off right now, but I should just
talk about all the cool stuff I'm working on right now.
Static parsing of subshells
---------------------------
Last year I wrote a shell (for my Systems Programming class); however,
I went above-and-beyond and added some really novel features. In my
opinion, the most significant is that it parses arbitrarily deep
subshells in one pass, instead of deferring them until execution. No
shell that I know of does this.
At first this sounds like a really difficult, but minor feature.
Until you think about scripting, and maintenance of those scripts.
Being able to do a full syntax check of a script is *crucial* for
long-term maintenance, yet it's something that is missing from every
major shell. I'd love to get this code merged into bash. It would be
incredibly useful for [some software I maintain](/git/mirror/parabola/packages/libretools.git).
Anyway, I'm trying to publish this code, but because of a recent
kerfuffle with a student publishing all of his projects on the web
(and other students trying to pass it off as their own), I'm being
cautious with this and making sure Purdue is alright with what I'm
putting online.
[Stateless user configuration for PAM/NSS](https://lukeshu.com/git/mirror/parabola/hackers.git/log/?h=lukeshu/restructure)
------------------------------------------
Parabola GNU/Linux-libre users know that over this summer, we had a
*mess* with server outages. One of the servers is still out (due to
things out of our control), and we don't have some of the data on it
(because volunteer developers are terrible about back-ups,
apparently).
This has caused us to look at how we manage our servers, back-ups, and
several other things.
One thing that I've taken on as my pet project is making sure that if
a server goes down, or we need to migrate (for example, Jon is telling
us that he wants us to hurry up and switch to the new 64 bit hardware
so he can turn off the 32 bit box), we can spin up a new server
from scratch pretty easily. Part of that is making configurations
stateless, and dynamic based on external data; having data be located
in one place instead of duplicated across 12 config files and 3
databases... on the same box.
Right now, that's looking like some custom software interfacing with
OpenLDAP and OpenSSH via sockets (OpenLDAP being a middle-man between
us and PAM (Linux) and NSS (libc)). However, the OpenLDAP
documentation is... inconsistent and frustrating. I might end up
hacking up the LDAP modules for NSS and PAM to talk to our system
directly, and cut OpenLDAP out of the picture. We'll see!
PS: Pablo says that tomorrow we should be getting out-of-band access
to the drive of the server that is down, so that we can finally
restore those services on a different server.
[Project Leaguer](https://lukeshu.com/git/mirror/leaguer.git/)
-----------------
Last year, some friends and I began writing some "eSports tournament
management software", primarily targeting League of Legends (though it
has a module system that will allow it to support tons of different
data sources). We mostly got it done last semester, but it had some
rough spots and sharp edges we need to work out. Because we were all
out of communication for the summer, we didn't work on it very much
(but we did a little!). It's weird that I care about this, because
I'm not a gamer. Huh, I guess coding with friends is just fun.
Anyway, this year, [Andrew](https://github.com/AndrewMurrell),
[Davis](https://github.com/DavisLWebb), and I are planning to get it
to a polished state by the end of the semester. We could probably do
it faster, but we'd all also like to focus on classes and other
projects a little more.
C+=1
----
People tend to lump C and C++ together, which upsets me, because I
love C, but have a dislike for C++. That's not to say that C++ is
entirely bad; it has some good features. My "favorite" code is
actually code that is basically C, but takes advantage of a couple C++
features, while still being idiomatic C, not C++.
Anyway, with the perspective of history (what worked and what didn't),
and a slightly opinionated view on language design (I'm pretty much a
Rob Pike fan-boy), I thought I'd try to tackle "object-oriented C"
with roughly the same design criteria as Stroustrup had when designing
C++. I'm calling mine C+=1, for obvious reasons.
I haven't published anything yet, because calling it "working" would
be stretching the truth. But I am using it for my assignments in CS
334 (Intro to Graphics), so it should move along fairly quickly, as my
grade depends on it.
I'm not taking it too seriously; I don't expect it to be much more
than a toy language, but it is an excuse to dive into the GCC
internals.
Projects that I've put on the back-burner
-----------------------------------------
I've got several other projects that I'm putting on hold for a while.
- `maven-dist` (was hosted with Parabola, apparently I haven't pushed
it anywhere except the server that is down): A tool to build Apache
Maven from source. That sounds easy, it's open source, right?
Well, except that Maven is the build system from hell. It doesn't
support cyclic dependencies, yet uses them internally to build
itself. It *loves* to just get binaries from Maven Central to
"optimize" the build process. It depends on code that depends on
compiler bugs that no longer exist (which I guess means that *no
one* has tried to build it from source after it was originally
published). I've been working on-and-off on this for more than a
year. My favorite part of it was writing a
[sed script](/dump/jflex2jlex.sed.txt) that
translates a JFlex grammar specification into a JLex grammar, which
is used to bootstrap JFlex; its both gross and delightful at the
same time.
- Integration between `dbscripts` and `abslibre`. If you search IRC
logs, mailing lists, and ParabolaWiki, you can find numerous rants
by me against
[`dbscripts:db-sync`](/git/mirror/parabola/dbscripts.git/tree/db-sync).
I just hate the data-flow, it is almost designed to make things get
out of sync, and broken. I mean, does
[this](/dump/parabola-data-flow.svg) look like a simple diagram?
For contrast, [here's](/dump/parabola-data-flow-xbs.svg) a rough
(slightly incomplete) diagram of what I want to replace it with.
- Git backend for MediaWiki (or, pulling out the rendering module of
MediaWiki). I've made decent progress on that front, but there is
*crazy* de-normalization going on in the MediaWiki schema that
makes this very difficult. I'm sure some of it is for historical
reasons, and some of it for performance, but either way it is a
mess for someone trying to neatly gut that part of the codebase.
Other
-----
I should consider doing a write-up of deterministic-`tar` behavior
(something that I've been implementing in Parabola for a while,
meanwhile the Debian people have also been working on it).
I should also consider doing a "post-mortem" of
[PBS](https://lukeshu.com/git/mirror/parabola/packages/pbs-tools.git/),
which never actually got used, but launched XBS (part of the
`dbscripts`/`abslibre` integration mentioned above), as well as
serving as a good test-bed for features that did get implemented.
I over-use the word "anyway."
|
