diff options
Diffstat (limited to 'content')
-rw-r--r-- | content/images/EFF.png | bin | 0 -> 696 bytes | |||
-rw-r--r-- | content/images/FSF.png | bin | 0 -> 893 bytes | |||
-rw-r--r-- | content/images/FSF.svg | 34 | ||||
-rw-r--r-- | content/images/GNU.png | bin | 0 -> 853 bytes | |||
-rw-r--r-- | content/images/ccbysa.png | bin | 0 -> 428 bytes | |||
-rw-r--r-- | content/images/glider-yellow.png | bin | 0 -> 225 bytes | |||
-rw-r--r-- | content/images/grid_noise.png | bin | 0 -> 4638 bytes | |||
-rw-r--r-- | content/images/icon16x16.png | bin | 0 -> 553 bytes | |||
-rw-r--r-- | content/images/icon32x32.png | bin | 0 -> 556 bytes | |||
-rw-r--r-- | content/posts/2015-06-28-it_s-alive-again.md | 75 | ||||
-rw-r--r-- | content/posts/2015-08-16-mystery-ds-record.md | 79 | ||||
-rw-r--r-- | content/posts/2015-12-02-malloc-realloc-and-sizeof.md | 87 | ||||
-rw-r--r-- | content/posts/2016-04-04-dnssec.md | 25 | ||||
-rw-r--r-- | content/posts/2018-07-18-n900-fast-gps-fix.md | 39 | ||||
-rw-r--r-- | content/projects/c-stuff.md | 22 | ||||
-rw-r--r-- | content/projects/dotfiles.md | 6 | ||||
-rw-r--r-- | content/projects/minecurses.md | 8 | ||||
-rw-r--r-- | content/projects/the-tk.com.md | 45 | ||||
-rw-r--r-- | content/projects/vav.md | 6 | ||||
-rw-r--r-- | content/style.scss | 153 |
20 files changed, 579 insertions, 0 deletions
diff --git a/content/images/EFF.png b/content/images/EFF.png Binary files differnew file mode 100644 index 0000000..9701d8e --- /dev/null +++ b/content/images/EFF.png diff --git a/content/images/FSF.png b/content/images/FSF.png Binary files differnew file mode 100644 index 0000000..c7cb606 --- /dev/null +++ b/content/images/FSF.png diff --git a/content/images/FSF.svg b/content/images/FSF.svg new file mode 100644 index 0000000..e3f8d47 --- /dev/null +++ b/content/images/FSF.svg @@ -0,0 +1,34 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> +<svg + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + version="1.0" + width="1115.9464" + height="490.18243" + id="svg2434"> + <defs + id="defs2436" /> + <g + transform="translate(232.25893,-284.41382)" + id="layer1"> + <g + transform="matrix(1.24994,0,0,1.24994,-232.25893,280.59622)" + id="g5" + style="fill-rule:nonzero;stroke:#000000;stroke-miterlimit:4"> + <clipPath + id="aiclp1"> + <path + d="M 0,0 L 3390.47,0 L 3390.47,395.159 L 0,395.159 L 0,0 z" + id="path8" /> + </clipPath> + <g + id="g10"> + <path + d="M 86.4,193.619 L 0,193.619 L 0,128.819 L 86.4,128.819 L 86.4,78.419 L 72,78.419 L 72,42.419 L 86.4,42.419 L 86.4,28.019 L 122.4,28.019 L 122.4,42.419 L 338.4,42.419 C 398.068,11.152 468.102,5.081 528.635,4.336 C 595.448,3.478 598.91,4.229 626.165,4.424 C 741.533,5.283 749.485,5.792 765.768,3.223 C 772.332,2.142 779.531,6.483 780.1,9.718 C 781.423,16.89 766.474,25.196 761.858,26.659 C 747.507,31.214 721.815,33.275 651.929,37.307 L 650.265,37.341 C 539.276,47.821 477.012,73.988 460.922,81.476 C 397.281,111.179 390.411,125.007 398.685,133.831 C 407.453,143.189 456.997,122.605 481.292,115.667 C 529.574,101.893 558.027,115.084 576,128.819 L 619.2,128.819 L 619.2,121.619 L 648,121.619 L 648,128.819 L 892.8,128.819 L 892.8,193.619 L 648,193.619 L 648,244.02 L 856.8,244.02 L 856.8,280.02 L 648,280.02 L 648,395.219 L 619.2,395.219 L 619.2,280.02 L 604.8,280.02 L 604.8,244.02 L 619.2,244.02 L 619.2,193.619 L 604.8,193.619 C 604.551,219.088 597.091,242.438 589.952,252.057 C 523.32,341.562 221.084,353.077 127.459,354.605 C 103.834,355.01 86.923,351.047 86.4,344.818 M 253.773,127.251 C 257.812,110.263 269.098,92.953 282.619,78.547 L 124.419,79.178 L 123.845,129.016 L 252.962,129.54 L 253.572,130.573 M 751.955,11.815 C 750.31,10.996 666.288,15.679 661.564,15.25 C 656.841,14.82 606.225,15.545 578.474,14.82 C 545.624,13.961 511.15,14.854 479.065,17.826 C 446.645,20.832 413.151,30.923 385.455,42.517 C 359.107,53.548 332.851,67.422 312.24,83.74 C 301.685,92.094 293.661,101.373 286.476,112.726 C 278.317,125.607 274.384,140.322 279.819,152.661 C 285.678,165.945 298.781,171.829 315.031,174.346 C 329.785,176.64 347.881,175.419 359.475,177.781 C 366.359,179.183 377.658,181.035 378.369,187.658 C 379.013,193.669 368.163,203.721 363.125,206.121 C 353.678,210.631 341.01,206.766 328.772,204.189 C 320.337,202.418 307.819,198.311 300.001,194.741 C 294.722,192.327 289.074,190.421 288,190.421 C 287.572,190.421 122.187,189.993 122.4,190.421 C 122.4,193.212 122.187,327.981 122.4,334.421 C 122.635,341.533 147.178,339.426 162.376,337.95 C 191.737,335.077 222.278,331.508 251.908,327.215 C 268.85,324.759 286.805,321.578 303.866,318.196 C 330.919,312.83 363.267,305.314 376.718,301.019 C 410.36,290.285 445.142,280.838 476.918,267.097 C 491.204,260.924 508.265,253.141 519.86,245.196 C 532.218,236.728 545.409,225.014 550.992,212.991 C 557.191,199.639 559.089,183.563 552.709,168.976 C 546.698,155.235 530.165,142.998 515.78,140.635 C 507.593,139.293 501.18,138.488 493.236,139.132 C 484.098,139.87 468.545,143.211 458.239,144.5 C 441.297,146.62 421.39,149.633 404.777,147.077 C 393.613,145.358 376.007,130.974 382.233,114.227 C 386.796,101.948 404.475,89.347 415.083,82.451 C 440.848,65.703 487.197,51.083 526.945,41.656 C 560.438,33.713 607.458,27.271 647.179,26.842 C 651.009,26.802 686.892,24.393 690.549,24.265 C 750.881,22.118 752.813,12.242 751.955,11.813" + id="path12" + style="fill:#b11107;stroke:none" /> + </g> + </g> + </g> +</svg> diff --git a/content/images/GNU.png b/content/images/GNU.png Binary files differnew file mode 100644 index 0000000..5382e18 --- /dev/null +++ b/content/images/GNU.png diff --git a/content/images/ccbysa.png b/content/images/ccbysa.png Binary files differnew file mode 100644 index 0000000..9c0b590 --- /dev/null +++ b/content/images/ccbysa.png diff --git a/content/images/glider-yellow.png b/content/images/glider-yellow.png Binary files differnew file mode 100644 index 0000000..4edeca1 --- /dev/null +++ b/content/images/glider-yellow.png diff --git a/content/images/grid_noise.png b/content/images/grid_noise.png Binary files differnew file mode 100644 index 0000000..30d1be4 --- /dev/null +++ b/content/images/grid_noise.png diff --git a/content/images/icon16x16.png b/content/images/icon16x16.png Binary files differnew file mode 100644 index 0000000..2c77bc3 --- /dev/null +++ b/content/images/icon16x16.png diff --git a/content/images/icon32x32.png b/content/images/icon32x32.png Binary files differnew file mode 100644 index 0000000..7ffd840 --- /dev/null +++ b/content/images/icon32x32.png diff --git a/content/posts/2015-06-28-it_s-alive-again.md b/content/posts/2015-06-28-it_s-alive-again.md new file mode 100644 index 0000000..ccc34a4 --- /dev/null +++ b/content/posts/2015-06-28-it_s-alive-again.md @@ -0,0 +1,75 @@ +$title "It's alive... again..." +$tags webdev + +After putting it off for a few months, and a weekend of trying to make the +perfect simple stylesheet, I finally got around to re-doing my website. It's +now simpler, easier to read and actually has a blog. + +$pre + +Initially I was going to write my own static content generator in python using +[Jinja2][jinja], pygments and docutils. I realise that doing this was going to +be a giant pain and I didn't quite have the time to actually try to make one. +I've heard about [Jekyll][jekyll] before and decided to investigate. I was +hoping it was written in python but was instead written in ruby, however, in +the end, this didn't matter. + +I was initially greeted by an _interesting_ layout and became worried that if I +went any further I would be here for the rest of the day trying to wrangle the +thing into submission. + +I started with the basics, I changed a few details in the config, this made +some text change and remove some other text so I went about exploring. I knew +Jekyll was using [Liquid][liquid] templates and having used Jinja before I knew what I +was looking for. + +I quickly discovered that `/_layouts` stored a set of "base" templates which +included a set of templates from `/_includes` to bring stuff together. This +wasn't too bad. + +I then found `/css` or more importantly `/css/main.scss`. I've never seen an +"scss" extension before but at first glance it looked a bit like CSS. At a +second glance it looked like a css generator. I didn't really need this, the +CSS for this website is in no way complex enough to warrant templating css, so +I got to work modifying the existing `_layouts` and `_includes`, and simply +copied in my usual css. + +Within about 10 minutes I had a working front page design but I noticed +something annoying; the generated HTML had about 10 line breaks in the middle +and generally looked like a mess. I realised that most of this space was +because of Liquid's tokens leaving space. After moving all the tokens around in +a way which meant that minimal breaks were introduced, I was left with +something presentable. + +But this wasn't the end of the weirdness, the next problem was that for some +reason, the indentation on the very first line of an imported template was +always correct, but subsequent indentation was broken. (I was hoping that, like +many text editors, Liquid might take the indent on the line where a block is +being pasted and copy it for every line of the block, but on second thought, +this might not be desirable for for example, `<pre>`). I had to fix this by +indenting all but the first line correctly in every `/_includes` template and +this managed to cover most of the cases. + +In the end, after pasting the syntax highlighting from +`/_sass/_syntax-highlighting.scss` into my stylesheet and manually "generating" +all the required entries. I was left with this very end result you see before +you. As a final verdict, I really do think that Jekyll is quite awesome even +though I've probably not used it in the most efficient fashion. All things +considered, however, this only took about an hour. + +Now, bask in the glory of the syntax highlighting: + +~~~.c +#include <stdio.h> + +int main(void) +{ + puts("Colours!!!"); + + return 0; +} +~~~ + +[jekyll]: http://jekyllrb.com +[jinja]: http://jinja.pocoo.org/ +[liquid]: http://liquidmarkup.org/ diff --git a/content/posts/2015-08-16-mystery-ds-record.md b/content/posts/2015-08-16-mystery-ds-record.md new file mode 100644 index 0000000..9757503 --- /dev/null +++ b/content/posts/2015-08-16-mystery-ds-record.md @@ -0,0 +1,79 @@ +$title "The mystery DS record" +$tags DNS DNSSEC + +So after transferring my domain from transip.eu to namecheap.com for WHOIS +privacy I realised that suddenly the Google public DNS servers were no longer +able to resolve my domain. Very quickly, I realised that quite a few things +seemed to rely on the Google public DNS services (and DNSSEC supporting +resolvers). Fun ensued. + +$pre + +DNSSEC is a fancy extension to DNS which allows resolvers to cryptographically +confirm, through the use of some public keys and signatures, that the records +they are looking up are in fact the records they want and not the result of +some MITM attack. This is explained well in multiple places, so I won't explain +it here. + +I transferred my domain from transip.eu who provide DNSSEC (no way to publish +DS records, everything is maintained in the background), but don't provide +WHOIS privacy, to namecheap.com who do provide WHOIS privacy but don't provide +DNSSEC. The DS record that transip.eu published to gtld-servers for their +DNSSEC was left published after I transferred which initially, for someone who +didn't know anything about DNSSEC, caused many confusing side effects. + +DS records have to be published in the parent zone, this means that it has to +be done through your registrar. (Unless you have a lot of money and time and +feel like bribing Verisign. If someone knows how to do this without bribery, +tell me!). Upon contacting namecheap about the issue, the person I was talking +to seemed confused about the issue. They seemed to think I was having issues +with A and AAAA records and DNS propagation. They tried to inform me that I +just had to wait. Of course, all the waiting in the world wouldn't get the DS +records to disappear so after explaining the situation a bit better (I still +didn't quite know much about it myself) I got them to contact their "upstream +DNS provider." + +Finally, a weekend later, the DS record was gone and Google's DNS servers were +serving my records again. Additionally, I switched over to using my own BIND +name server so I could have full control over my DNS. This proved to be quite +fun to set up. The second server is hosted by a good friend of mine and the +third one by a friend of that friend. So far, other than me accidentally +forgetting to enable named.service and rebooting my server to find that DNS +wasn't working very well, I've had no problems. +So after transferring my domain from transip.eu to namecheap.com for WHOIS +privacy I realised that suddenly the Google public DNS servers were no longer +able to resolve my domain. Very quickly, I realised that quite a few things +seemed to rely on the Google public DNS services (and DNSSEC supporting +resolvers). Fun ensued. + +DNSSEC is a fancy extension to DNS which allows resolvers to cryptographically +confirm, through the use of some public keys and signatures, that the records +they are looking up are in fact the records they want and not the result of +some MITM attack. This is explained well in multiple places, so I won't explain +it here. + +I transferred my domain from transip.eu who provide DNSSEC (no way to publish +DS records, everything is maintained in the background), but don't provide +WHOIS privacy, to namecheap.com who do provide WHOIS privacy but don't provide +DNSSEC. The DS record that transip.eu published to gtld-servers for their +DNSSEC was left published after I transferred which initially, for someone who +didn't know anything about DNSSEC, caused many confusing side effects. + +DS records have to be published in the parent zone, this means that it has to +be done through your registrar. (Unless you have a lot of money and time and +feel like bribing Verisign. If someone knows how to do this without bribery, +tell me!). Upon contacting namecheap about the issue, the person I was talking +to seemed confused about the issue. They seemed to think I was having issues +with A and AAAA records and DNS propagation. They tried to inform me that I +just had to wait. Of course, all the waiting in the world wouldn't get the DS +records to disappear so after explaining the situation a bit better (I still +didn't quite know much about it myself) I got them to contact their "upstream +DNS provider." + +Finally, a weekend later, the DS record was gone and Google's DNS servers were +serving my records again. Additionally, I switched over to using my own BIND +name server so I could have full control over my DNS. This proved to be quite +fun to set up. The second server is hosted by a good friend of mine and the +third one by a friend of that friend. So far, other than me accidentally +forgetting to enable named.service and rebooting my server to find that DNS +wasn't working very well, I've had no problems. diff --git a/content/posts/2015-12-02-malloc-realloc-and-sizeof.md b/content/posts/2015-12-02-malloc-realloc-and-sizeof.md new file mode 100644 index 0000000..ee3f508 --- /dev/null +++ b/content/posts/2015-12-02-malloc-realloc-and-sizeof.md @@ -0,0 +1,87 @@ +$title "malloc, realloc and sizeof" +$tags information C + +I spend a lot of time in ##c hoping to provide useful information to people +wishing to learn and understand C and almost every day I see malloc and realloc +code which appears to be straight from a horror movie. I've had to say what I +say in this post repeatedly to many people so I've decided that it's time to +write it once and simply give people a link every time I wish to explain why +such code is incorrect. + +$pre + +The code I'm describing is usually a combination of some or all of this: + +~~~ c +struct foo *bar; + +bar = (struct foo *)malloc(sizeof(struct foo) * 10); + +bar = (struct foo *)realloc(bar, sizeof(struct foo) * 20); +~~~ + +There are multiple issues with this: + + - Casting malloc can hide newbie mistakes such as forgetting to include + stdlib.h which can in turn cause strange issues down the line. + - Casting unnecessarily also gives you rather long lines, especially when you + have a rather complicated/long type (e.g. const struct foo * const *). + - You're having to type the same thing three times, when you could type it + once. + - If you screw up rewriting the same thing one of three times, you might end + up allocating the wrong amount of space and still end up with code which + runs, this can be dangerous down the line if some clever person finds a way + to exploit this. + - If you ever want to change the type of bar, you need to change it in 3 + places, if you forget to change it in one of these, you end up with the same + issue described in the point above. + - Finally (regarding just the realloc line) if realloc fails, memory is leaked + since bar's original value is overwritten with NULL, realloc doesn't + automatically free the original pointer when it can't realloc. + +The easy solution is simply: + +~~~ c +struct foo *bar, *tmpbar; + +bar = malloc(sizeof *bar * 10); + +tmpbar = realloc(bar, sizeof *tmpbar * 20); + +if (!tmpbar) { + free(bar); + /* error handling */ +} else { + bar = tmpbar; +} +~~~ + +This solves all of the outlined problems. + +----------------------- + +Here's the answers to two common questions: + +**Q**: _The compiler has always complained (warned) when I tried to assign a +pointer to one type to a pointer to another type. Would this not be the case +here?_ + +**A**: The C standard states (C11/C99 §6.3.2.3 and C11/C99 §6.5.16.1) roughly +that a pointer to void can be assigned to a pointer to any type, and vice +versa, freely without issuing a warning. This in turn means that the return +value of malloc (and any other function returning void \*) will be converted +without warning to the desired type without needing a cast. + +**Q**: _What's the deal with `sizeof *bar`? Don't functions need +brackets?_ + + +**A**: The sizeof operator can be given an expression as an operand as well as +the parenthesized name of a type. This means we can do `sizeof *bar`. Also, +since sizeof is an _operator_ and **not** a function, it doesn't require +parentheses when its operand is an expression, the C standard does however +require that for types, the type name has to be parenthesized. In the end, it's +a style choice whether the parentheses are always there or not, but personally I +think leaving them out is more consistent. (NB: The first example uses sizeof as +such: `sizeof(type)`, personally I prefer leaving a space between `sizeof` and +`(type)` as I would with most other operators.) diff --git a/content/posts/2016-04-04-dnssec.md b/content/posts/2016-04-04-dnssec.md new file mode 100644 index 0000000..13c1d60 --- /dev/null +++ b/content/posts/2016-04-04-dnssec.md @@ -0,0 +1,25 @@ +$title "DNSSEC" +$tags information DNS DNSSEC + +As of today my domain finally supports DNSSEC. It was much simpler than I +thought it would be. It seems namecheap now officially allows you to publish DS +records in the parent zone of your domain (limited only to TLDs which support +it). This is one of the last things that I wanted to set up on my server. + +$pre + +In the end, the process was made very simple by the existence of +[this][cheatsheet] which details exactly how to set up DNSSEC on BIND 9.10 or +higher. + +Currently the KSK is SHARSA256 1024 bits and the ZSK is SHARSA256 2048 bits, I +am considering moving to using a 2048 bit KSK but I'm not sure if there will be +much of a benefit. I am using NSEC3 with a SHA-1 hash with the opt-out bit +unset and 100 iterations. + +In any case, you can now rest assured that if your resolver uses DNSSEC +(Google's resolvers will return a failure in case they find a DS record but the +DNSSEC validation fails) you will be receiving signed and verifiable data. Of +course, I doubt many people care. + +[cheatsheet]: https://kb.isc.org/getAttach/122/AA-01311/DNSSEC-QR-B4.pdf diff --git a/content/posts/2018-07-18-n900-fast-gps-fix.md b/content/posts/2018-07-18-n900-fast-gps-fix.md new file mode 100644 index 0000000..33d3482 --- /dev/null +++ b/content/posts/2018-07-18-n900-fast-gps-fix.md @@ -0,0 +1,39 @@ +$title "N900 Fast GPS Fix" +$tags N900 GPS + +If anyone is, like me, still using the N900, they may have noticed that +acquiring an initial GPS fix can take minutes. The reason for this is that even +in the latest CSSU, supl.nokia.com no longer works as a location server. The fix +for this is actually relatively quick and easy and will make an initial GPS fix +take seconds rather than minutes. + +$pre + +The exact details of what needs to be done can be found in the last few posts of +[this][tmo-thread] Maemo forum thread. The problem is that supl.nokia.com no +longer resolves to an IP address. However, this doesn't mean that the server +behind supl.nokia.com is no longer running. Surprisingly, it still is. + +The long and short of it is this: + +1. Make sure you have the latest CSSU and a working N900 to begin with; +2. Go [here][certman] and download `libmaemosec-certman0_0.2.10_armel.deb`, + `libmaemosec0_0.2.10_armel.deb`, `maemosec-certman-common-ca_0.2.10_all.deb`, + and `maemosec-certman-tools_0.2.10_armel.deb`; +3. Install the above packages via the command line as root (you'll need gainroot) + by using `dpkg -i` (put all the files in their own directory and use `dpkg -i + *` to save time); +4. Edit `/etc/hosts` and change `supl.nokia.com` to point to `52.200.182.188`; +5. Check it all works by running `cmcli -T common-ca -v supl.nokia.com:7275` and + `cmcli -T location-proxy -v supl.nokia.com:7275`, both should say "Verified + OK."; +6. If this doesn't work, try `stop location-proxy` and then + `start location-proxy` (as root) and go back to step 5. + +GPS fixes should happen very quickly now. If it's the year 2023 and this didn't +work then good luck finding a new fix, hopefully you put the details on your +blog too. Alternatively, feel free to contact me and I might still be using the +N900 and might know how to help. + +[tmo-thread]: https://talk.maemo.org/showthread.php?t=90651 +[certman]: http://maemo.merlin1991.at/cssu/community-devel/pool/free/m/maemo-security-certman diff --git a/content/projects/c-stuff.md b/content/projects/c-stuff.md new file mode 100644 index 0000000..b310844 --- /dev/null +++ b/content/projects/c-stuff.md @@ -0,0 +1,22 @@ +$name c-stuff +$source https://github.com/EliteTK/c-stuff + +c-stuff is a large collection of small projects and snippets of +code. Numerous people have shown interest in these various snippets so +although this is not a project itself, it gets a notable mention. Most +of the code is licensed under the GNU GPLv3. + +$desc + +## Notable Mentions + +### timer + +timer is a simple command line beeping countdown timer. It has a very +simple interface: `timer n{s,m,h,D,M,Y}...` Despite this simplicity, +it's an incredibly useful tool, the source for it can be found +[here][timer-src] and there is even an AUR package which can be found +[here][timer-aur]. + +[timer-src]: https://github.com/EliteTK/c-stuff/blob/master/timer.c "c-stuff/timer at master · EliteTK/c-stuff" +[timer-aur]: https://aur.archlinux.org/packages/timer-git/ "timer-git" diff --git a/content/projects/dotfiles.md b/content/projects/dotfiles.md new file mode 100644 index 0000000..8c239e3 --- /dev/null +++ b/content/projects/dotfiles.md @@ -0,0 +1,6 @@ +$name dotfiles +$source http://github.com/EliteTK/dotfiles/ + +These are the files from my .config directory, the only things which are +actually useful may be the vimrc, i3 config and i3blocks config. These are +severely out of date. diff --git a/content/projects/minecurses.md b/content/projects/minecurses.md new file mode 100644 index 0000000..855ed59 --- /dev/null +++ b/content/projects/minecurses.md @@ -0,0 +1,8 @@ +$name minecurses +$source https://github.com/EliteTK/minecurses/ +$aur minecurses-git + +minecurses is a clone of minesweeper written in C using ncurses. The +code is quite awful in the current master branch and the redo branch is +not in any way able to be compiled. However, in the future this might +possibly improve. diff --git a/content/projects/the-tk.com.md b/content/projects/the-tk.com.md new file mode 100644 index 0000000..dc87f43 --- /dev/null +++ b/content/projects/the-tk.com.md @@ -0,0 +1,45 @@ +$name the-tk.com +$source https://the-tk.com/cgit/the-tk.com/ + +This website is an ongoing project of mine, an attempt at writing a simple to +maintain static website with html which tries to avoid putting <div>s +everywhere. I also hope that at least some of the stuff I write about can be +useful to some people. + +$desc + +## Older Versions + +The website is actually on its 4th revision. The files for the 1st revision may +be lost somewhere (probably for the best) but can find the source for v2 and v3 +of the website in the GitHub repository located [here][old-gh], the "old" branch +holds v2. v3 of the website relies on a slightly customized liquid, the nature +of this customization can be found [here][liquid-patch]. + +## IP Echo Server + +An IP echo server is hosted at http://ip.the-tk.com/. Before I was informed that +you could implement this functionality entirely within nginx (using +`return 200 $remote_addr`) I had written this short simple fastcgi IP echo +program in C: + +~~~.c +#include <fcgi_stdio.h> +#include <stdio.h> +#include <stdlib.h> + +int main(void) +{ + while (FCGI_Accept() >= 0) { + puts("Content-type: text/plain; charset=UTF-8"); + puts("Status: 200 OK"); + puts(""); + printf("%s", getenv("REMOTE_ADDR")); + } + + return EXIT_SUCCESS; +} +~~~ + +[old-gh]: https://github.com/EliteTK/the-tk.com/ "EliteTK/the-tk.com · GitHub" +[liquid-patch]: https://github.com/EliteTK/liquid/tree/replace_newlines "EliteTK/liquid at replace_newlines" diff --git a/content/projects/vav.md b/content/projects/vav.md new file mode 100644 index 0000000..786c6cd --- /dev/null +++ b/content/projects/vav.md @@ -0,0 +1,6 @@ +$name VAV +$source https://github.com/EliteTK/vav/ + +VAV is a C library which aims to provide neat looking vectors in C. These might +not be entirely practical since they cause quite an overhead in the creation and +calculations using vectors, but the code can be a source of interesting ideas. diff --git a/content/style.scss b/content/style.scss new file mode 100644 index 0000000..e1873b8 --- /dev/null +++ b/content/style.scss @@ -0,0 +1,153 @@ +html { + background-image: url(./images/grid_noise.png); + background-repeat: repeat; + background-color: #F3F5F7; + font-family: sans-serif; + text-align: justify; +} + +main { + max-width: 100%; + min-width: 60%; + width: 50em; + margin: 1em auto; + padding: 1em; + background-color: white; + box-shadow: 0 0 5px #888; + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; +} + +#copyright { + color: grey; + font-size: x-small; + text-align: center; +} + +nav { + overflow: hidden; width: 100%; font-weight: bold; font-size: large; + a { text-decoration: none; } + a:link { color: black; } + a:visited { color: black; } + a:hover { color: grey; } + a:active { color: darkgrey; } +} + +code, div.codehilite pre { + border: 1px dashed #DDD; + background-color: #FAFAFA; + padding: 0.1em; +} +div.codehilite pre { display: block; overflow: auto; } + +.fleft { float: left; } +.fright { float: right; } + +figure { + margin: 0 0.5em; + figcaption { + font-size: small; + color: #BBB; + text-align: right; + border-top: thin dotted grey; + } +} + +blockquote { font-family: serif; } + +img.icon { height: 0.8em; } + +a:link { color: grey; } a:hover { color: lightgrey; } +a:visited { color: darkgrey; } a:active { color: darkgrey; } + +footer { text-align: center; } + +hr { border: none; border-top: 1px dashed lightgrey; height: 0px; } + +article footer { + text-align: right; +} + +time { + color: #BBB; +} + +ul.taglist { + padding-left: 0; + list-style: none; + li { display: inline; } +} + +ul.postlist { + padding-left: 0; + list-style: none; +} + +ul.projects { + padding-left: 0; + list-style: none; +} + +/* Syntax highlighting mess */ +.codehilite { + .c { color: #998; font-style: italic } + .err { color: #a61717; background-color: #e3d2d2 } + .k { font-weight: bold } + .o { font-weight: bold } + .cm { color: #998; font-style: italic } + .cp { color: #999; font-weight: bold } + .c1 { color: #998; font-style: italic } + .cs { color: #999; font-weight: bold; font-style: italic } + .gd { color: #000; background-color: #fdd } + .gd .x { color: #000; background-color: #faa } + .ge { font-style: italic } + .gr { color: #a00 } + .gh { color: #999 } + .gi { color: #000; background-color: #dfd } + .gi .x { color: #000; background-color: #afa } + .go { color: #888 } + .gp { color: #555 } + .gs { font-weight: bold } + .gu { color: #aaa } + .gt { color: #a00 } + .kc { font-weight: bold } + .kd { font-weight: bold } + .kp { font-weight: bold } + .kr { font-weight: bold } + .kt { color: #458; font-weight: bold } + .m { color: #099 } + .s { color: #d14 } + .na { color: #008080 } + .nb { color: #0086B3 } + .nc { color: #458; font-weight: bold } + .no { color: #008080 } + .ni { color: #800080 } + .ne { color: #900; font-weight: bold } + .nf { color: #900; font-weight: bold } + .nn { color: #555 } + .nt { color: #000080 } + .nv { color: #008080 } + .ow { font-weight: bold } + .w { color: #bbb } + .mf { color: #099 } + .mh { color: #099 } + .mi { color: #099 } + .mo { color: #099 } + .sb { color: #d14 } + .sc { color: #d14 } + .sd { color: #d14 } + .s2 { color: #d14 } + .se { color: #d14 } + .sh { color: #d14 } + .si { color: #d14 } + .sx { color: #d14 } + .sr { color: #009926 } + .s1 { color: #d14 } + .ss { color: #990073 } + .bp { color: #999 } + .vc { color: #008080 } + .vg { color: #008080 } + .vi { color: #008080 } + .il { color: #099 } +} |