Setting up a M93p mini offsite backup server, with power and cost calculations

2024-07-03T00:00:00+00:00

This blog post will cover:

what I'm doing for my offsite backup system using a M93p mini PC;</li>
how much energy it uses;</li>
how much it costs every year; and</li>
how that compares against commercial services.</li> </ul>
At the end, there are some bonus scribbles about:
- how I fixed a problem with suspend (it would keep turning off instead of suspending);</li>
- how to reset the BIOS variables / 'CMOS memory'; and</li>
- how I configured my BIOS.</li> </ul>
 Motivation🔗</a></h2>
 I need to do a better job at keeping backups, because realistically it's only a matter of time until something bad happens and I lose something that I consider sentimentally important.
 I think basically everyone should consider having off-site backups — backups that aren't in your home — which would not be lost in the event of a fire, theft, or so on, alongside your main home for the data.
 Perhaps an obvious solution would be to rent some online storage space at some server provider / cloud provider.
 This can work, but the following issues arise:
 - You may not trust the privacy of such a provider.
 - If you have a lot of data, costs quickly add up.</li> </ul>
 For a while I have been renting space at HostBrr (5 TB, approx. £8.83/month) and iHostArt (7 TB, approx. £8.42/month) — having two in order not to keep all my eggs in one basket! This has been fine as a medium-term 'something is better than nothing' solution, but:
 
 Although these are actually CHEAP providers, this is costing me roughly £207 per year for 2 offsites.</li>
 These providers feel a bit less professional than major providers, so without wanting to be mean, I am not sure how much confidence I have in relying on them.</li>
 My internet speed is poor, which makes backing up (especially the initial backup) awkward and if I ever need to do a full restore, that will also take a long time.</li> </ul>
 Bring it under control: Bring it in house 🔗</a></h2>
 It occurred to me that buying my own hardware is probably the only way to cut the cost here.
 Yet, because I want to keep the backups automatic, an online solution is needed — i.e. I need to be thinking of buying a server or two, not just external hard drives that I could pretend I remember to plug in every so often.
 The whole point is having it off-site, so I'll have to beg friends/family to take in the servers. That then means they need to be compact/unintrusive and not too electrically thirsty!
 For my first mini-server I've found a second-hand Lenovo ThinkCentre M93p on eBay — for a little under £50 (including power supply, bought separately — all the sellers of these things don't seem to include the power supplies for whatever reason).
 Size-wise, this fits the bill; it's truly tiny as far as PCs go and it shouldn't be too intrusive. Specs-wise, this has an Intel i5-4590T, 8 GB of DDR3 RAM and a 240 GB Solid State Drive. This sounds ample. The power supply is rated for 65 W and it has the rectangular connector that I see on some Lenovo laptops (kind of funny to see it on a desktop).
 
 Figure 1</a>: My M93p Tiny ThinkCentre and its power supply.
 Front: 2 USB 3.0 ports, headphone port, microphone port, power button.
 Back: Rectangular DC input, DisplayPort++, 3 USB 3.0 ports, VGA, another DisplayPort, Ethernet, antenna connector for WiFi antenna (not shown) </div> </figure>
 Since the Solid State Drive is just 240 GB and there isn't space inside it for any big 3.5 inch hard drives, I'll use the SSD for the operating system and connect an external 8 TB USB 3.0 hard drive.
 I purchased this ('Seagate Backup Plus Hub') for £130 from Currys in 2019; there might have been a deal going on at the time. I can find 8 TB for £144 these days, or 10 TB for £180. (Interestingly you can even get 4 TB NVMe SSDs for £200 these days...)
 Power characteristics🔗</a></h2>
 Electricity is expensive in this country, so it seemed worth trying to figure out how much of other peoples' leccy I was going to end up spending.
 I am using a cheap mains power meter — not laboratory-grade calibrated equipment, but it should be fine for an illustration.
 Standalone🔗</a></h3>
 First I started with just the M93p PC — no external hard disk. I performed a few basic tests:
 
 how much power is used with the computer off?</li>
 how about when it's suspended?</li>
 how about when it's on, but not doing anything taxing (idle)?</li>
 how about when running single-threaded sysbench cpu run</code>, using the powersave CPU governor (cpupower frequency-set -g powersave</code>)?</li>
 how about when running single-threaded sysbench cpu run</code>, using the ondemand CPU governor (cpupower frequency-set -g ondemand</code>)?</li>
 how about when running 4-threaded sysbench cpu run --threads=4</code>, using the powersave CPU governor (cpupower frequency-set -g powersave</code>)?</li>
 how about when running 4-threaded sysbench cpu run --threads=4</code>, using the ondemand CPU governor (cpupower frequency-set -g ondemand</code>)?</li> </ul> Test</th> Power consumption</th> Relevant metric</th> Comparison</th></tr></thead> Off</td> 0.3 W</td> </td> </td></tr> Suspend</td> 1.2 W</td> </td> Compared to Off: +0.9 W</td></tr> On/Idle</td> 9.7 W</td> </td> Compared to Off: +9.4 W</td></tr> cpu sysbench (1 thread, powersave)</td> 11.5 W</td> 240 events/s</td> Compared to Idle: +1.8 W</td></tr> cpu sysbench (1 thread, ondemand)</td> 19.8 W</td> 892 events/s</td> Compared to Idle: +10.1 W Compared to 1 thread, powersave: +72% power, +271% performance</td></tr> cpu sysbench (4 threads; powersave)</td> 14.1 W</td> 958 events/s</td> Compared to 1 thread, powersave: +2.6 W (+23% power), +299% performance</td></tr> cpu sysbench (4 threads; ondemand)</td> 29.4 W</td> 3119 events/s</td> Compared to 1 thread, powersave: +17.9 W (+156% power), +1100% performance Compared to 1 thread, ondemand: +9.6 W (+48% power), +250% performance Compared to 4 threads, powersave: +15.3 W (+109% power), +226% performance</td></tr> </tbody></table> Table 1</a>: Power consumption measurements (no external hard disk connected) </div> </div> I suspect that sysbench is not a great substitute for a domain-specific benchmark, but at the moment this is the best I can easily do — just don't read too much into the performance upticks. Disk Connected🔗</a></h3> I then connected the external hard drive, including its own mains-fed power supply (output rating: 12 V @ 3 A). The measurements are for both the PC itself and the external hard drive's power supply. I measured the power consumption with the PC off and with the disk connected (both power supplies for the PC and the disk were connected to the mains and under measurement). The disk isn't spinning at this point.</li> I booted the PC and instructed the disk to spin down with hd-idle -t /dev/sdb</code> and measured the power consumption of the whole system.</li> I then spun up the disk but otherwise left the machine idle. I measured again.</li> I then started a full sequential read of the disk with dd if=/dev/sdb of=/dev/null bs=1M</code> and measured once more. Although the CPU won't technically be idle in this situation, I assume for the sake of simplicity that it also won't be loaded enough to matter.</li> </ul> Test</th> Power consumption</th> Relevant metric</th> Comparison</th></tr></thead> Off</td> 1.0 W</td> </td> Compared to Off (Standalone): +0.7 W</td></tr> On/Idle, Disk Spun down</td> 11.2 W</td> </td> Compared to On/Idle (Standalone): +1.5 W</td></tr> On/Idle, Disk Spinning</td> 16.4 W</td> </td> Compared to On/Idle (Standalone): +6.7 W Compared to Spun down: +5.2 W</td></tr> Sequential Disk Read</td> 21.4 W</td> 190 MB/s read speed, CPU in powersave</td> Compared to Idle/Spun down: +10.2 W Compared to Idle/Spinning: +5.0 W</td></tr> </tbody></table> Table 2</a>: Power consumption measurements (with external hard disk connected) </div> </div> I didn't want to disturb the data on the disk so I didn't perform a write test. However, I hope these numbers are illustrative enough anyway. Rough calculations for my expected usage pattern🔗</a></h3> I expect my usage pattern to include, each day, 23 hours in the Off state and (up to) 1 hour receiving a backup over the network. In the absence of measurements in real-world conditions, let's build a somewhat pessimistic estimate: During the active hour, disk activity will be the main type of load, perhaps with some CPU intensive cryptography to handle the encrypted TLS or SSH connection. Let's take the 21.4 W reading from the Sequential Disk Read test (as my closest illustration of disk write) and add 10.1 W, which is the difference between Idle and the single-threaded ondemand cpu sysbench (my best pessimistic guess for an illustration of the CPU use/cryptographic operations). This gives us 31.5 W total. During the 23 other hours, the Off (with Disk Connected) reading for 1.0 W applies. Approx daily consumption is therefore: 44.5 W·h (Watt-hour). Approx annual consumption is therefore: 16.3 kW·h (kiloWatt-hour) At a rate of 22.36p/kW·h (including VAT, taken from a MoneySavingExpert article about the July 2024 price cap</a> — thankfully less than the last rate I remember), this gives an annual electricity cost of about £3.64. I may have been working with rough numbers but I feel happy enough calling it £5 for the sake of simplicity. It shouldn't break the bank to bribe someone that much to adopt one of these servers into their home :-). The bottom line — does this make sense to do?🔗</a></h2> It's hard to put an exact figure on the cost of one of these systems, because hard drives fail, usually unpredictably. A pessimistic take could be that we should expect to replace the disk every 2 years since the warranty is 2 years long. On the other hand, I would have higher hopes and expectations for the M93p mini PC itself — say 5 to 10 years. What</th> Cost</th> Expected Annual Cost</th></tr></thead> Replacement of 8TB HDD every warranty period</td> £144 every 2 years</td> £72 per year</td></tr> Replacement of M93p Mini PC every 5 years</td> £50 every 5 years</td> £10 per year</td></tr> Electricity</td> </td> £5 per year</td></tr> </td> </td> </td></tr> Total</td> </td> £87 per year</td></tr> </tbody></table> Table 3</a>: Sum of expected costs for this 8 TB M93p system </div> </div> Let's have a quick comparison against some of the other providers. Storage System/Service</th> Annual Cost</th> Annual Cost per TB</th> Note</th></tr></thead> This 8 TB M93p System</td> £87 [expected]</td> £10.89 [expected]</td> Cost will vary depending on luck/hardware failures.</td></tr> iHostArt 7 TB Storage VPS</td> £101</td> £14.42</td> </td></tr> Backblaze S3-compatible (US$6/TB·month)</td> varies based on usage</td> £56.76</td> Unlike a fixed-disk system, you don't pay for space you don't use!</td></tr> Wasabi S3-compatible (US$6.99/TB·month)</td> varies based on usage</td> £66.12</td> Unlike a fixed-disk system, you don't pay for space you don't use!</td></tr> Amazon S3 (US$0.023/GB·month)</td> varies based on usage</td> £260.98</td> Unlike a fixed-disk system, you don't pay for space you don't use! Price inclusive of VAT. Minimum 90 days of storage per object. Upload and download requests are chargeable. Seems like roughly £85.10 to actually transfer a TB back to your computer over the Internet.</td></tr> Amazon S3 Glacier Deep Archive (US$0.00099/GB·month)</td> varies based on usage</td> £11.23</td> Unlike a fixed-disk system, you don't pay for space you don't use! Price inclusive of VAT. 12 hour restoration time. Minimum 90 days of storage per object. Upload and download requests are chargeable. Seems like roughly £2.36 to retrieve a TB in 'Bulk' mode, plus £85.10 to actually transfer it back to your computer over the Internet.</td></tr> </tbody></table> Table 4</a>: Cost comparison of this 8 TB M93p system against commercial services </div> </div> Under this model, there isn't that much difference between this and renting space from iHostArt (mentioned in the intro — 7 TB not 8 TB, but close enough) which is £101 per year. It mostly comes down to which system you trust more, or whether you're feeling lucky at dodging disk deaths. I suspect the self-hosted system will win with larger storage volumes though; for example 16 TB disks (e.g. Seagate Exos) are readily available for less than twice the price of the 8 TB disks, you just need to find a caddy to use it as an external drive. Compared to the bigger name commercial providers, there is quite a drastic difference. Amazon's S3 'Glacier Deep Archive' service is the only big name I know of that appears to come close — it has a 12 hour retrieval time but almost matches my system on expected cost. That is, unless you actually want to read your data out, at which point you can expect to pay £87 per terabyte(!) to pull it out of Amazon's deathgrip — mostly due to Amazon's standard egress fees rather than the actual cost of retrieval from the archive. For a backup of last resort which you hope to never need to restore from, I am sure it could make sense for some, but it's not for me. I admittedly can't be sure I haven't missed some more hidden fees buried in fine print. The £85.10 egress fee was pretty non-obvious to me until I looked at online comments talking about it, only the £2.36 fee (already costly enough) was discoverable to me as a non-Amazon specialist. Overall, I think I'm happy with the theory of my system and I'm willing to go ahead with it. What will be particularly useful to me is the ability to have physical access to the drive from time to time, meaning I can bypass stuffing my backups or restores through my narrow Internet pipe and can do bulk loads much quicker. Scribbles🔗</a></h2> Some of this information may be useful to me or others for reference. Problem with suspend🔗</a></h3> I was having trouble with suspending the M93p ThinkCentre: it would reboot instead of resuming from suspend. The solution that worked for me was updating the BIOS. Without Windows installed, the option that worked for me was to do this within FreeDOS. I can't remember anymore if I tried the CD image on a USB stick or not You can get the BIOS upgrade files from Lenovo's site</a> (direct .zip file</a>, direct instructions .txt</a>). The DOS one is called 'Flash UEFI BIOS update – EFI Shell utility'. From the name it sounds like it is supposed to be used from the EFI Shell but I am not sure how to get to the EFI Shell on this machine... The readme calls it a DOS package though and it worked for me, so you can overlook that. Install FreeDOS on a USB stick (I put it on my Ventoy USB stick)</li> Put the BIOS files on another USB stick</li> Plug in the BIOS files USB stick before booting FreeDOS. This is needed because the BIOS 'mounts' the flash drive first and then hands it over to FreeDOS. In the short time I used FreeDOS, I did not figure out how to mount the USB stick within FreeDOS but in either case it is more effort, so don't bother.</li> Switch to the drive with D:</code></li> flash2 IMAGEFB.ROM</code></li> </ol> I noticed there are other fun options like being able to edit the serial number, machine make & model, boot logo, etc but I didn't bother with that. I have read online since doing this that on some other Lenovo models, setting the serial number and machine model to 'INVALID' will bypass some boot-time restrictions on which PCIe network cards you're allowed to use, but I suggest you search around for someone else's blog post where they tried that if you want more information. Other than that, there seems to be an option to clear the BIOS settings: /clr</code> After the BIOS upgrade was complete, it then rebooted itself... And happily resume now worked!!! BIOS Settings to set🔗</a></h3> Settings in bold are the ones I consider most important. Advanced Intel(R) Manageability Control → DISABLED (I don't need/want IME stuff as far as I can avoid it)</li> Intel(R) SIPP Support (Stable Image Platform Program) → DISABLED (I don't want to present an old CPU/Chipset revision ID to the operating system, that just sounds needlessly self-misleading. Maybe it makes sense on some other OSes but I trust Linux to know how to use revision IDs best.)</li> </ul> </li> Power After Power Loss → Power On (Otherwise a power cut will knock my system offline and need manual intervention)</li> Enhanced Power Saving Mode → Enabled (Says it will reduce power use in the off state, at the cost of disabling any wakeup source other than the RTC Alarm. Great, that's actually exactly what I want, particularly since it knocks off the IME in the Off state)</li> </ul> </li> Security Secure Boot → Disabled (I don't care to have life made hard by Secure Boot; it's mostly only there for Windows 8 Certification anyway)</li> TCG Security Feature → Disabled (I don't think I want anything to do with the Trusted Platform Module; nothing I do uses it, may as well disable)</li> </ul> </li> Startup CSM → don't care, can disable for all I want. But having it enabled is useful for booting FreeDOS etc.</li> Boot Priority → UEFI First</li> Quick Boot → Disabled (I like the splash screen because it helps you to know what buttons to push)</li> Keyboardless Operation → Enabled (Otherwise using it as a server will be troublesome; without switching this on, it will trigger the Error boot sequence instead when there's no keyboard)</li> Startup Device Menu Prompt → Enabled</li> </ul> </li> </ul> The button to get the menu on boot is Enter, but the menu has a self-destructing timer that is paused/resumed by the Enter key as well, so if you spam it blindly you will just keep resuming the timer and eventually it will continue the boot sequence anyway. Light Teardown and 'CMOS memory' reset🔗</a></h3> As part of my suspend troubleshooting, I opened the machine and reset the 'CMOS memory', the battery-backed volatile RAM which stores the time for the real-time clock and BIOS settings. Note this did not solve my issue, but it's always nice to have a look inside anyway. The case was pretty elegant, needing just one screw to come off before you could slide the top case off at an angle (this is all described in the manual). Figure 2</a>: M93p ThinkCentre with top of outer casing removed. The jumpers mentioned next are at the bottom-right. </div> </figure> The jumper header for resetting the 'CMOS memory' was pretty fiddly as it was recessed and I had to use some fine tweezers to pull it out (being careful not to drop it...) and they would just slip against it most of the time. Figure 3</a>: Pin headers with the jumper moved to the reset position. </div> </figure> The manual has the full procedure for this, but you just boot with the jumper in the reset position and wait until it beeps multiple times. Then you turn the power off and move the jumper back. My First Ludum Dare Game: Olive Harvest in Ludum Dare 52 2023-01-16T00:00:00+00:00 skip to play game</a> Introduction🔗</a></h2> The weekend before last (6th–8th January 2023), I participated in Ludum Dare 52. If you haven't come across it before, Ludum Dare is a competition in which participants write a game in a short amount of time — 48 or 72 hours (depending on entry type). You might have heard of this format being called a 'game jam'. There's no prize for 'winning' but of course you get to keep your game at the end of it and the experience itself has been quite fun for me. Ludum Dare has multiple different types of entry: 'Compo': solo developer, 48 hours, must release source code, have to make all your assets yourself</li> 'Jam': teams allowed, 72 hours, can use assets from elsewhere (within legal constraints) but must opt out of ranking categories if you didn't make them yourself</li> 'Extra': much more relaxed with much more time (3 weeks) — I'm not sure of the details since it doesn't really interest me, but seems like you don't get a score at the end. I would say that in general, the relaxed time frame is probably a negative for me, but it may appeal to some.</li> </ul> This was my first time taking part in a Ludum Dare — the closest thing being a game jam at University but it was outrageously short (8 hours, if memory serves me correctly) and I had an idea that was just way too cool and ambitious :/... Since it was my first time (and I couldn't arrange for any friends to join me in time), I decided to treat it as a practice run and I decided to make an entry for the 'Jam' because of the 72 hour time frame. I took it a bit casually — I didn't skip any sleep or anything like you might expect from a timed event like this. In retrospect, I wish I had aimed for a 'Compo' entry instead and taken it a bit more seriously. The event started on Friday night in my timezone and ended on Sunday night (Compo)/Monday night (Jam). Since I had work on Monday, I didn't end up getting that much extra time anyway! Not only that, but I created all the assets myself since, to me, that's part of the fun :). My intention was to do future rounds with friends. I would still like to do that if the chance arises next time, but if I can't arrange anything with friends, I won't be afraid to have a crack at a 'Compo' entry :-). Ideas🔗</a></h2> Every Ludum Dare has a theme, which is voted on by interested participants in the week or two leading up to the event and then announced at the start of the event. This Ludum Dare's theme was 'Harvest'. When the clock struck eight and Ludum Dare started, I was somewhat worried; I couldn't quickly think of an interesting idea. Games like Stardew Valley and Harvest Moon popped into mind but they are obviously too complex to make in a game jam (and besides, I wanted to aim for something original). I wanted an idea for a game that wasn't trivially basic (gameplay-wise), was fun and yet was going to be achievable in the short time (knowing full well that this event was going to flash by). Maybe you call this 'simple but good' and I don't know about you, but I find it hard to come up with ideas in that category :-). I eventually narrowed down into a game about farming olives and processing them into olive oil, whilst under attack by forces of evil (slugs, mould, thieves, ...?). I thought it'd be interesting to put some tower defence aspects in there — I always liked games that made you think about 'buying' structures and thinking of where to place them to defend you from the forces of evil. (I never actually got around to any tower defence aspects in the game but it was in the plans.) In a sense, I was lucky, because the flow of ideas started and I soon had a handful of ideas that, together, sounded like a game I wanted to play and show to others. I was perhaps even luckier that these ideas were flexible enough to let me pivot away from the overcomplicated 'tower defence' aspects into a less complicated idea that meant I could still package up a game at the end of the event. Thoughts on the Godot game engine🔗</a></h2> It was time to get cracking. The excellent open-source game engine Godot</a> was my tool of choice. I had already messed around with it a few years ago (for my previous / failed game jam at University) so I had a tiny amount of familiarity, but otherwise I'd be coming at this with fairly fresh eyes. I should have learnt beforehand but I didn't — I only skimmed documentation on the job. Godot is very intuitive once you know that it's 'Scenes' all the way down. Its engine-specific scripting language, GDScript, can feel a bit wonky at times but it's also very fit for purpose — as long as you don't fall into the trap of thinking that it's Python despite its syntactic similarity. I can see it being useful to drop down into a different language at times (C#, C++ are supported but others are available, including Rust), but GDScript was perfectly adequate for me and I'd probably advise against getting too complicated in a short event like this. Godot Traps and Tricks🔗</a></h3> Basically every tool has quirks and a good craftsperson would do well to become aware of them. Here are a few traps I fell into and a few tricks I learnt about. yield</code> and SceneTree timers combined seem dangerous🔗</a></h4> At some point if you dig deeply enough, you'll run into GDScript's yield</code> keyword which lets you defer execution until another event triggers. You might be tempted, as I was, to use this sort of snippet for inserting a sleep into your code to make something happen later: yield(get_tree().create_timer(5.0), "timeout") # wait 5 seconds before next event </code></pre> This works, but it turns out that if the current object/Scene gets removed from the world during the sleep, the resumption of the script will lead to an error: Resumed function after yield, but class instance is gone.</code>. I didn't actually notice any ill effects from this — just an error in the console and everything else continued as usual, but it's poor to have errors showing up when things are working correctly and I can't guarantee that this wouldn't lead to some footguns in other situations either. The slightly unfortunate workaround for this is to use an explicit Timer</code> node as a child of your Scene</code>. If necessary, this means creating a Timer and remembering to remove it afterwards. var timer = Timer.new() timer.one_shot = true $Timer.add_child(timer) timer.start(time); yield(timer, "timeout") $Timer.remove_child(timer) </code></pre> It's safe to use yield</code> on this timer node because once the current Scene</code> is destroyed, the Timer</code> will also be destroyed as it is a child and the script will never be resumed as a result. Note: a Timer</code> can't have multiple timeouts, so you need one per task... I'd be tempted to wrap this up in a neater package if I was writing a proper game and needed to make use of this, but for the purposes of the game jam I took the lazy way out. Source for this trick on the Godot Engine Q&A site — thanks k2kra!</a> z-ordering is hard, at least in a game from this 2D perspective🔗</a></h4> My game is 2D but set with a perspective that I don't know the term for, but the best I've found is 'top-down oblique'. It's as though you have an orthographic camera (so no vanishing point and no concept of things getting smaller as they get further away) angled so you can see the top and front of things. It's convenient for drawing because you can draw terrain as thought it was top-down, characters as though you are looking at them from the front and structures as a bit of both — and everything will look fairly reasonable. Structures can be built out of reusable tiles (in Godot: use a TileMap</code>!) which greatly cuts down on time needed to produce levels. A slight problem emerges because characters can walk in front of and behind other characters and objects in the world. Despite thinking you had a 2D game, you now need to worry about ensuring that everything renders in the right order so things that are logically in front appear in front. I never got this exactly right during the event itself, but I at least know some tricks. The biggest trick: use the YSort</code></a> node. YSort</code></a> sits in your scene tree and re-orders its children depending on their Y-position. For example, when the player walks in front (below) of a tree, they show up in front, but when they walk above, they show up behind the tree. For this to work properly, you absolutely must make sure the origin point of your child scenes/entities matches where you want the ordering to be decided! Examples that would seem typically correct would be to put the origin at a character's feet, or at the base of a tree, or the base of a wall. Essentially: wherever the entity touches the ground. In my case, I started off my game with little regard for the origin positions of objects, using explicit z-indices to solve all my ordering problems and designing levels so that you never noticed any discrepancies. Eventually, I ran into a case I couldn't design away and learnt about YSort</code></a>, but then it was difficult to rework all my objects and I released the game with some broken Z behaviour (switching to YSort</code> fixed some of my issues but broke at least one case I worked around manually beforehand). An especially tricky case, present in my game, is that of objects which can have other objects walk or sit inside: for example, the player can walk in the back of the postal van/truck and the olives can sit inside the wheelbarrow. It's easy enough to split the front and back of these container objects into different sprites (if you drew them with layers in Krita, you can just export different layers/layergroups), but z-ordering them is tricky. I still need to research the proper way to support these 'container' objects, particularly the ones in the world: maybe there's a trick hidden by clever z-indexing or the 'Show Behind Parent' option? I'd also note that I don't know how to make TileMaps interact with the YSort</code></a> node's sorting such that you could have walls that occlude the character behind but do not cover the character in front: I just made it so that you couldn't walk into any section of the walls. Navigation isn't well-documented and it's a bit fiddly to draw a correct mesh🔗</a></h4> To make my game come alive a bit, I wanted at least one kind of 'enemy' character: in the time available, this turned out to be slugs. They wouldn't add much to the game if they couldn't walk around though, so I needed pathfinding. Godot provides the 'navigation' system for this purpose. With that said, I found documentation a bit hard to come by for this. Most online sources point you to the Navigation2D</code> node (you'd use it as a parent of your world). At least in Godot 3.5.1, this node is deprecated with a (somewhat misleading/unhelpful) message pointing you to the Navigation2DServer</code>. But the online sources I came across, even for Godot 3.5.1, still use that node claiming it is more configurable. I know it's a game jam, but I didn't particularly want to drop a deprecated component in my project. I had a few cases of the navigation system randomly not working, but here are some rough notes: Put a NavigationAgent2D</code> node in your enemy (or whatever it is that needs to walk around) scene </li> In your levels (or potentially in the tiles, but I didn't figure this out in time), add some NavigationPolygon</code>s that cover the area in which the enemies are allowed to walk. Keep the gap between them quite tight and also don't overlap them too far — it seems like the lines need to be close together for them to join up. I also set the 'Travel cost' to zero in each one, because otherwise I was having slugs walking the long way around the buildings just because there were fewer mesh polygons in the path that way(!) despite being a longer distance.</li> </ul> </li> Because you're (likely) a human — who didn't make an absolutely perfect and gapless navigation mesh — increase the edge connection margin of the navigation system: # random place to put it, but needed to get our navigation working: var w2d: World2D = get_world_2d() Navigation2DServer.map_set_edge_connection_margin(w2d.navigation_map, 10.0) </code></pre> (In this case, this means 10 pixels is the allowed margin between two polygon's edges for an enemy to be allowed to walk across.) If you don't do this, your navigation polygons need to be extremely-well (perfectly?) lined up. This is the reason that some sources are still using Navigation2D</code> nodes, because you can easily configure this in the editor there. I couldn't find anywhere to configure this on the Navigation2DServer</code>, so I put the above in the _ready</code> function for my UI code (which is present on every single level). Messy, but works... </li> Occasionally (on a timer) poke the NavigationAgent2D</code> to navigate to your target (in case the target moves, like a player) and have your physics processing code steer the enemy towards the next point</a> — crucially, you call NavigationAgent2D.get_next_location()</code> to get the global position of where you need to go to follow the path. </li> </ul> I'd recommend that anyone interested in this feature experiment with it before a game jam if they're interested in not wasting an hour or two learning it on the job... Structuring a long-term project is not obvious🔗</a></h4> I don't know enough about the right way to structure a Godot project and especially not about how to effectively reuse code/component Scenes. For example, if I wanted to add an upgraded wheelbarrow that can hold more olives, I'm not sure about the cleanest way of doing that. Proliferating use of collision layers🔗</a></h5> For my game, I used a lot of collision layers despite it being a short project. Although you can name them (which is a nice touch!), there are a finite number so I'd probably want to think more carefully about how to share layers for multiple uses in a proper game. Other tools🔗</a></h2> Here are the other tools I used: Krita</a> for digital painting.</li> jsfxr</a> for sound effect generation (a re-implementation of sfxr usable straight from the browser).</li> lazygit</a> for version control (a text user interface for Git).</li> </ul> Submission🔗</a></h2> There's an extra hour for submission. I used it for packaging up my game and writing up a description. I did not know that I would need a cover photo, so I just took a screenshot of the game, but in future I would try to make a bit more of a polished cover photo (observing the size requirements for submission). I used Godot's 'Export' wizard to create a HTML5 export with the main name of index.html</code> (as needed for Ludum Dare's embed). I also placed a copy on my personal website so people could play the game fullscreen. Note that there's a fairly chunky download to complete before you can export a HTML5 game for the first time; if on a slow network it'd be a good idea to have that already done in advance. Rating other games🔗</a></h2> Don't make the mistake of thinking that the event only lasts 73 hours... because after the deadline, it's time to play other people's games and rate them! By doing so, you also encourage your game to show up at the top of the list for other players to find (which then leads to getting more ratings); note that you need 20 ratings to get a rank at the end of Ludum Dare! I'd say, based on just my experience, you should expect to play and rate about fifty games in order to attract enough attention to obtain your basic 20 ratings — but I noticed other games had a much better ratio, so perhaps my game was just not very enticing (hint: maybe a better cover photo would have helped!). There were many interesting and well-polished games with interesting takes on the theme, but of course there were also some games you might consider underdeveloped, unoriginal or buggy. Playing the other games was also a good chance to reflect on my own game. Some rough points: I appreciated having HTML5 builds of games. I'd propose any participant to try and provide this option if they can. It means I don't have to download questionable executables for a start, but also saves a lot of effort. That said, some games' HTML5 builds were said to be degraded compared to the main build, such as having rendering bugs. I'm definitely guilty of not having done this, but it'd be a good idea to test the HTML5 build of the game earlier than the publishing hour. I didn't do anything too specialist so I got off lucky, I guess?</li> </ul> </li> I noticed that games built with Godot 4 do not work in Firefox-based browsers, which was a shame. Easy trap to fall into — I just got lucky that I used Godot 3.5.1 really!</li> </ul> </li> Many games had no audio, which is a shame. The games that had audio definitely felt more alive. Even just sound effects will help with this — but tasteful music was good in the games that had it. (My game did not have music as it's not in my skillset and I didn't have time to experiment.)</li> </ul> </li> Some games didn't do keybindings based on physical keys, so I had to change keyboard layout to play them. Many games did this right, though — so for the others, it's likely just a matter of finding out the trick to do it in their game engine of choice. Godot offers you the ability to map 'physical' keys to an input, for example.</li> Most games documented their controls in the description of the game. Some games did not and this was a shame when I couldn't figure out how to get them going. Ideally (for me) they would be within reach whilst playing the game because I can't remember more than a couple of controls in my head when I'm not used to them.</li> Some games were difficult to understand from the text alone. But some games had the right idea: they had illustrated diagrams telling you what to do. Based on this, I'd suggest taking 10 minutes to throw together illustrated instructions for your game — it should really only involve pasting together a few of the existing sprites and writing text, but it could really help players. Many games, including mine, had planned to have an in-game tutorial but didn't get around to it. Avoid that altogether! There's basically never going to be time to do that in a jam, so take 10 minutes to put together an illustrated diagram instead.</li> </ul> </li> Leaving off the cover photo entirely is very unfortunate! At least put a screenshot on!</li> It's unfortunate that the Ludum Dare site doesn't give you the option (that I could find) to filter out Windows-only games etc. At some points during the event, the top of the board was full of games that I couldn't even run on this machine.</li> </ul> Some of my favourite games from Ludum Dare 52🔗</a></h2> Poppy Defence</a> — a tower defence-style game where you fight off waves of enemies by strategically planting various plants. Exceptionally well-polished and I had fun playing this one for hours!</li> Agricultural Ascension</a> — an excellent puzzle game. The programmer in me liked how you would easily be able to generate challenges for this game programatically if you wished.</li> Harvest Hell</a> — harvest melons. If you're too slow, they turn into monsters that need shooting down. Simple, but especially well-themed music that really brings it alive. I like how some subtle constraints of the game were put together.</li> Horticulture</a> — buy seeds, then plant and harvest plants for customers. The customers give you paper slips with their orders on and you need to cut the right parts of the plants whilst trying to be efficient. I'm afraid I am much too slow for this game — I get drowned in paper notes — but it was a good idea and I found it fun!</li> No Harvest</a> — rebelling against the theme in quite a fashionable way, this is a puzzle game (I guess) where you try and avoid nasty plants building up on a field, by casting spells. I liked how the games challenges you and forces you to consider your choices, as some spells will actually help some of the pesky plants grow!</li> Revengetables</a> — this is a game where you control the vegetables (and fruit!) in their uprising against the farmers who want to eat them. I'm not usually a fan of voiceovers but the voiceovers in this game were hilarious (and the game would be worth it for that reason alone). But even besides that, I found it thoughtful how the different characters had different benefits and you could switch between them during the fight.</li> </ul> After the jam🔗</a></h2> It seems that some people will continue working on their games after the jam. I know I was intending to, but reality gets in the way. Ludum Dare is a special time. My recommendation (mostly to myself) is to make time for it, then make the most of it — because that special time is not forever. I'd suggest trying to get your game to a state you are content with, before the jam ends and real life resumes. Play Olive Harvest🔗</a></h2> Play original jam game on my website (recommended option due to window size)</a></li> See the listing on Ludum Dare</a> (you can also play there, but the embed size is likely too small for the game)</li> Get the source code</a> (or: permalink to the version submitted to LD52</a>)</li> </ul> QuickPeep: My work-in-progress small-scale web search engine 2022-07-02T00:00:00+00:00 Frustration🔗</a></h2> I have a few points of frustration with the common modern web search engines. For one, they tend to get gamed by content mill sites that specialise in Search Engine Optimisation (SEO). These very sites tend to be the ones that don't respect the reader, hammering them with nagging pop-ups, adverts, trackers and other distractions. I'm not even sure that many of these sites are actually written by a thoughtful human as opposed to being chucked together in a rush, or perhaps even by machine. It's not that sites authored by individual people have gone away. If you know where to look (which is difficult), they still exist and I much prefer those. I suppose those people don't care about chasing all the latest SEO tricks and so they fall to the bottom of the results. That's understandable; it's enough effort to put a site together in the first place, why should they have to be bothered with the SEO games as well? What I'm up to🔗</a></h2> I thought to myself something along the lines of 'it's about time that someone makes a search engine which is specifically targeted at small websites and doesn't give you any rubbish'. Unfortunately, I then had to take personal responsibility for that statement and start such a project myself. :-) I call it QuickPeep — 'quick' because it should be fast to get to desirable content and 'peep' because 'peep' means 'a quick look'. 'Peep' also describes one of the sounds made by some birds, so it's a perfect excuse to have a cute bird on the logo. A few guiding principles of the project are: Modest hardware requirements. The search engine should be operable with modest hardware requirements. Storage space is a particular concern. We obviously can't index the whole web, but even individual pages should be 'shrunk' down as much as possible so we can fit many pages into our search engine. Time is also quite limited: I simply don't have enough computers, or enough bandwidth, to trawl the entire web! I may be quite extreme about this goal. I won't turn my nose up at a 5% space improvement, for example — just because it's not an order of magnitude doesn't mean it's not worth doing (to me)! </li> No rubbish sites. Rubbish sites are not welcome. To minimise resource wastage, the best way to keep them out is to 'simply' not index them. This obviously comes with the implicit problem of somehow being able to know which websites are rubbish. Maybe someone clever could come up with a machine learning approach, but for now, I manually collect a set of sites that are allowed to be in the index. This is obviously quite 'human-intensive'. </li> Does what it's told. Some search engines will ignore your attempt to exclude terms, or they may disregard "multiple word phrases"</code> if they think they know better than you. QuickPeep doesn't do this. It should do what you say. </li> Flexibility. This is quite difficult to provide when trying to cut down storage space, so it's a bit of a 'best-effort' point. QuickPeep should provide convenient features to help the reader in filtering out unwanted results. This may take the shape of being able to exclude terms within a query, or being able to exclude results for sites that don't respect them. </li> Open and free. It should be possible for more or less anyone to operate their own search engine based on this software. Ideally, they should be able to obtain some kind of data dump to avoid the hassle of crawling everything again if that's not what they want to do. </li> </ol> QuickPeep's pipeline and what it looks like to operate and use🔗</a></h2> Seeding the search engine🔗</a></h3> To start this project off, I assembled a collection of seeds — URLs that point to pages that I want in my search engine. Each seed implicitly vouches for (allows the crawling of) the same domain (or, in some cases, only some URL prefixes). I also came up with a handful of weeds — these are the opposite of seeds and correspond to URLs that we don't care about tracking, either because the site is too big to be practically indexable or the site doesn't belong in our focussed search engine. Early on, I added a seed collection webpage to QuickPeep's web interface so that I could easily enter seeds (giving them tags) and even collect a few from friends and colleagues (thanks folks!). I only have about forty right now, but it's still enough to be interesting. Raking the web🔗</a></h3> Obviously, we need to get the content of interesting webpages into our search index so we can answer search queries. The first half of this — retrieving content from webpages — is what the QuickPeep 'raker' does. The raker maintains its state as a libMDBX database and emits Zstd-compressed 'rake packs' which contain the page contents, references, site icons and errors. The operator first imports a collection of seeds and weeds into the database using qp-seedrake</code>. Each seed becomes an entry in the rake queue and also generates an entry in the set of allowed domains. Each weed creates an entry in the set of weed domains. The operator can then start the raker itself (qp-raker</code>). The raker splits off into separate tasks and will shut down when there is no more work to be done. Each task selects a rakeable domain at random from the database and then processes queue items for that domain. A queue item is an instruction to download a URL, perhaps with an 'intent' for that URL (which determines what kind of document we're expecting). The raker is capable of understanding HTML webpages, RSS and Atom feeds and XML Sitemaps. Common image formats are also supported, but only if the raker is downloading a site's icon (becoming an image search engine is outside the scope of this project). If we run into trouble whilst downloading from a domain, the raker can either generate a 'rejection' entry for that URL or, for temporary failures, we can back off from that domain until a later time. For feeds, sitemaps and webpages, the raker extracts references to other URLs. These are emitted in the 'references' rake pack and: inserted into the queue (if the domain is allowed);</li> inserted into the 'on-hold' queue (if the domain isn't one of the allowed domains); or</li> discarded (for weeds).</li> </ul> For HTML webpages, the raker applies a few steps of pre-processing: Advert (and other troublesome content) blocking and detection. The adblock engine from the Brave web browser is written in Rust and so was relatively easy to embed. We use it for a couple of reasons: First of all, we can detect disrespectful (to a reader) 'nasties' such as adverts, trackers and 'annoyances' (including stupid cookie pop-ups1</a>). Second of all, we can trim extraneous bloat from the webpage content that we're aiming to index. ^{1 Cookie pop-ups are almost always a sign that the site is doing something disrespectful. They're not needed for legitimate use cases. The vast majority of them are also infuriatingly difficult to dismiss without accepting; very few give easy rejection options. In any case, they take your focus off the content (quite often covering a large portion of the screen) and so we will count them all as 'evil' for the pursuit of a pleasant experience. I'm relying on existing adblock rulesets here and definitely don't have the time to maintain one myself, anyway. </div> </li>} Readability extraction. If you're aware of Firefox's Reader Mode, this is basically that. In fact, it's more or less exactly that — I use a (tweaked) Rust fork</a> of Mozilla's readability.js</a> project (thanks paperoni). If you haven't heard of Reader Mode, then just know that it's a heuristic algorithm for extracting an article's main content from its web page. This could be a very useful technique for cutting down the size of the content that we need to index: we have no interest in being able to search for what's visible on the site's navigation menu, so why store it? However, as this technique is more or less educated guesswork, I haven't entirely stripped away the content that isn't extracted as readable content, out of paranoia that some sites may not extract well. Instead, I'm considering ranking words in the 'readable' section more favourably than words elsewhere. It's also possible to alter the ranking so that webpages with a relevant readable section are preferred over others, which could be nice for people that much prefer reading pages in Reader Mode. I still haven't decided exactly what I'm going to do with this; I'm not sure how I feel about being 'unfair' to webpages that don't fit in well with this non-standardised technique. If it turns out that my concerns are unfounded, I may just strip out the non-readability-extracted content altogether and save some space! </li> Conversion from HTML to a denser, less structured, format. Many of the bytes in a webpage are used to represent HTML tags that don't have any useful meaning for a search index. For example, we don't care about the CSS on the page or most of the attributes on the tags. Similarly, tags like <div></code> often don't mean anything to us (especially not if they're nested); they're basically just there to make styling rules useful. This conversion pass reduces the structure of the page to text nodes, headings and links, plus some metadata (e.g. page title, page description and URL to the icon). (Headings could be useful to bias ranking. I haven't entirely decided about whether I should scrap links yet.) This pass usually achieves a 80%+ reduction in document size and is a big part of making it cheap enough to store the content of so many web pages. </li> Language detection. Many (maybe even most?) webpages don't seem to declare their language. On these, we sniff the language using Lingua</a>. We don't actually discard non-English pages here (but we could...?). Most likely, it might be useful to discard non-English pages when indexing, or to put them in a different language-specific index using the correct stemming rules for the language. </li> </ol> The document is then emitted into the 'pages' rake pack. For icons, we decode the image, convert it to a lossy WebP with an unreasonably-low quality value (5%) and then emit it into the 'icons' pack. I'm sure I could afford to be more generous with the icons, but I've been impressed enough with the quality for the tiny size that I haven't bothered to. The rake packs are compressed with Zstd (using a high compression level). Keeping the types of documents separated into different rake packs is good for two reasons; it improves the compression ratio as e.g. the pages rake pack contains mostly human-language text and doesn't have WebP icons randomly interspersed. The separation also means that you don't have to download all the rake packs if you don't need them; someone operating an indexer likely doesn't care about the references rake pack, but someone operating a raker may do if they want to rebuild their raker's state without reraking everything. The raker can export Prometheus-compatible (or BARE Metrics-compatible, though I prefer Prometheus & Grafana for this situation) metrics. This gives you a way to see that it's making progress, as well as an idea of the sizes of various database tables (both in numbers of rows and in bytes/disk usage). Figure: Part of a Grafana Dashboard for QuickPeep Raker. This is showing the slowest part of raking: the end, where only a couple of sites have not been finished. A quick aside about anti-features🔗</a></h4> The raker identifies and tags pages with 'anti-features'2</a>. These are aspects of a page or its site which may be undesirable for a potential reader. For example, the presence of pop-ups (e.g. cookies, e-mail subscription nags, etc) or adverts may be reasons to avoid a site. The raker also tries to identify sites that are sitting behind CloudFlare. This is because sites behind CloudFlare are often unbearable or even totally unusable for users of Tor; many sites impose at least a series of CAPTCHAs but some deny access to the content outright. This can be extremely frustrating and seems to fit into the 'disrespectful to the reader' category. Tor users should be able to use QuickPeep and exclude or down-rank these results if desired, to avoid wasting their time. ^{2 The inspiration for the term 'anti-features' comes from F-Droid, which applies this to Android applications. </div>}Indexing web pages🔗</a></h3> If someone wants to operate a search engine, they first need to set up an index. QuickPeep is intended to support multiple index/search backends; currently Tantivy</a> (an embedded search engine) is implemented but I'm interested in trying MeiliSearch</a> (a search engine server) to see how it compares. The operator configures their index of choice (Tantivy is easy as there's no need to set up a separate server). The operator can then download and import the rake packs, either from their own raker or from a public repository of rake packs (e.g. mine! — once things are a bit more stable). The operator uses qp-indexer</code> to index the entries from the rake pack (this also imports icons into a small key-value store so that the web interface can find them). There is a command-line tool, qp-index-search</code>, to search the index, which can show that things are working. Figure: A search for 'bee counting' using qp-index-search</code>. This tool is also interesting because it shows the relevance score of each result. Searching the index🔗</a></h3> The quickpeep</code> binary serves a web frontend to the index, offering a simple text box and button-based interface for performing searches. The layout is quite minimal, which I like here (but it currently looks rubbish on light mode, I'm afraid. If your browser doesn't advertise a preference for dark mode, be warned :-)). Right now, I just pass my query in to Tantivy fairly directly and don't try anything too intelligent or sophisticated to refine the results. Luckily, Tantivy also supports common search operators (such as +word</code>, -word</code>, "multiple word phrase"</code>, etc), so we get these 'for free'. I also take Tantivy's excerpts/snippets directly. There is no PageRank algorithm or anything, it's all just plain full-text search ranking. A quick play with the search engine reveals that it doesn't feel like it's giving me as much 'relevance' as other search engines do. I imagine some refinement could go a long way to improving this. That said, I've also compared a few queries to DuckDuckGo and some of them aren't really any different. Naturally, only having about forty sites in the index rather than ...millions(?) is bound to mean that some queries struggle to find much relevance, though. I've also found some interesting articles through QuickPeep and I've enjoyed reading them, so it's not that much of a flop! Once I can think of how I can improve this, I'll give it a go. Trying MeiliSearch may be interesting as a point of comparison and I may get some ideas along the way. Figure: A search for 'CRDT' in QuickPeep's web frontend Figure: A search for 'rant' in QuickPeep's web frontend Brief comment on disk usage🔗</a></h3> Ideally I should try and get at least thousands of sites into the index before thinking too much about this, but again, disk usage is an obvious concern when operating a search index. How much space am I using for these ~forty sites? Search Index Tantivy index: 150 MiB (I don't know how this will scale and how much of this is overhead that is exaggerated on a small database.)</li> Icons store: 76 kiB (Much of this will be overhead since the database is so small and it uses 4 kiB pages.) Icons themselves are typically about 200 bytes.</li> </ul> </li> Rake packs: 28 MiB (note that these can be deleted after they've been indexed; they're just a data transfer format. But it'd be useful to be able to host them for others to operate their own search engines.)</li> Raker database: 17 MiB (Much of this is 'on-hold' URLs. This could be reduced by marking some of them as weeds if we're not interested in indexing them.)</li> </ul> The size of the Tantivy index seems to be the most worrying, especially since you can't really delete it if you still want to search for things! It may be worth adding Zstd support to Tantivy's document store (currently it uses LZ4, which is fast but has a much lower compression ratio) and using it to compress entries. Training and using a Zstd dictionary should give us a good compression ratio. Decompression will be slower, of course, but it's still likely good enough. Alternatively, I believe it's possible to not store document text itself in Tantivy's datastore. The biggest files in Tantivy's index seem to be .pos</code> and .idx</code> files, so I'm not sure improvements in the document store are going to buy much anyway. I note that zstd</code> can cut one of the .idx</code> files down by 50% and one of the .pos</code> files down by 20%. Perhaps it's worth using a compressed filesystem? I presume the large .pos</code> files are indices of the positions of all the terms in the document (primarily useful for "multiple word phrase"</code> search terms, as far as I know). I suppose those could be turned off altogether at the cost of making "multiple word phrase"</code> queries slower (as they'd have to find the positions in the document itself). According to Paul Masurel's blog post about Tantivy's indexing</a> (which I just submitted as a QuickPeep seed :^)), it should be possible to make the index itself smaller than the document, if term positions are disabled. Barely usable🔗</a></h2> ...but open! QuickPeep is open-source: quickpeep</a>. My collection of seeds and weeds is open data: quickpeep_seeds</a>. If you'd like to give it a try, you can visit https://quickpeep.net</a>, but don't get your hopes up :-)! Known problems🔗</a></h3> Quality of excerpts is usually poor.</li> Ranking can be a bit poor.</li> Pages without favicons show an ugly broken image.</li> Duplicate webpages show up as duplicate results — QuickPeep should try and canonicalise URLs a bit and look for similar pages. It's probably quite easy to deal with the most common culprits: canonicalise a URL (for deduplication purposes only) by removing trailing /</code>, ignoring the protocol scheme (https://</code>) and ignoring a www.</code> subdomain if present.</li> I have some vague plans to use SimHash</a> to try and tackle the duplicate page problem more generally.</li> </ul> </li> Dynamic 'category' or 'home' pages should be favoured less than the pages that they contain excerpts for. Some simple heuristics will probably help a lot here, e.g. favouring the longer URL.</li> </ul> </li> Antifeatures are not used at all. They're not even displayed.</li> The size of the Tantivy index is slightly worrying, but there are ways to improve it. Try and add in Zstd support; use Zstd with a dictionary?</li> </ul> </li> URL fragments (#blah</code>) should be stripped when raking.</li> </ul> Aside: other uses for the 'references' rake packs🔗</a></h3> When a lot of sites have been crawled, it'd be fun to load the 'references' rake packs into some kind of graph database and be able to answer queries like 'which pages refer to my page'. Reverse references like this could be quite interesting for finding extensions or different points of view to an article you are already aware of. (This would be gamed for SEO purposes in a heartbeat on a conventional search engine!) Because these rake packs will be available for download, it should be quite possible for someone to do this if they like. Thanks🔗</a></h2> QuickPeep is built on top of many great quality, open-source libraries. Many thanks to all their authors for putting their work out into the open for fools like me to enjoy! Forgot10: My application for note-taking and general information tracking 2022-05-25T00:00:00+00:00 I've been working on a 'note-taking' system for a few months now. I think I have some interesting ideas and I thought it'd be worth a blog post so that I can look back and remember what I did these past few months... Motivation and rough idea🔗</a></h2> I'd like to do a better job of making notes of things and being able to retrieve information that I've come across. All too often, I've been stuck trying to remember something that I know I've done before, or that I know I've seen somewhere (probably on the Internet). It'd be useful to me to have a system that lets me take notes in a natural way and then lets me search those notes and anything else that might be useful. I currently use Zim</a> for my notes. It's a cracking tool that calls itself a 'Desktop Wiki'. The pages themselves are stored in a textual format</a>. With that said, it has a few limitations and I have a few itches for extra functionality which tempted me to roll my own tool... Peer-to-peer sync🔗</a></h3> I use Syncthing</a> to synchronise my Zim notebooks. It's peer-to-peer and files synchronise directly between my computers (and 'smart' 'phone'). I really like it, but I have occasionally ran into sync conflicts when I modify my Zim notebooks on two different machines concurrently (e.g. because often only one of them is on at once). Sharing a Zim notebook with a friend can also lead you to the same problem if you try to concurrently update the same page. As a result, a wish for my tool is to not only allow near-flawless offline use (since I'm often offline), but also to synchronise my different computers when they have the opportunity. To this end, I want to use Conflict-free Replicated Data Types (CRDTs). Streams, Pages and inline actions🔗</a></h3> My tool should be able to adapt to at least two frames of mind: sometimes, there's a need to quickly get a note down or 'stream' thoughts from mind to page. In this situation, the tool should ideally get out of the way and pose as little interruption as possible to getting those thoughts on the page! At other times, collecting nicely-polished notes together is desirable and I wouldn't mind putting some time into organisation. In this situation, the tool should give options to 'cultivate' a structured repository of information. For the first case, I came up with the concept of a 'Stream' (although if it seems sensible, it would be possible to have multiple of them). A Stream is just a chronologically-ordered list of entries (small rich text documents). It's intended for off-the-cuff journalling. The application should let you enter commands as you write an entry, so that e.g. you can easily schedule a reminder for yourself, without needing to even take your hands off the keyboard or leave the Stream at all. So far, I have /reminder</code> (aliased as /r</code>) which lets you schedule a reminder, potentially recurring, using plain English 'syntax'. See: Video demonstrating its use: Video unsupported in your browser? Do you want a direct link? MP4 here</a> </video> When you're not making rapid-fire notes, the tool should let you write to a hierarchical tree of note Pages. These can be navigated to like Zim's pages. They have a (required!) slot for a page title and they are intended for me to come back to time and time again. Screenshot of a Page: Search... everything!🔗</a></h3> A tool like this would benefit from good search to be useful. It's tempting to take this one step further and pull in extra sources of information to be indexed. For example, it may well be interesting to dig up browser history and archive the contents of the pages that I've been reading. It might be useful to archive e-mails and Matrix messages and index those, too. I haven't gotten anywhere with this yet, but it's a wish for the future. Multiple libraries🔗</a></h3> I want to support multiple 'repositories of information'; I decided to call them 'libraries'. Rather than being completely separate notebooks, though, they should all be merged into one unified view when desired. The tool should let you enable/disable them at will. A crucial point is that it should be possible to support different devices having different libraries (e.g. my work machine may only have relevant notes on there) and they should be able to go 'missing' without causing any harm (so that you can use an encrypted filesystem to store private notes and only unlock it when you need access). I note that it may be interesting to support a device having a partial/limited portion of a library, especially once it's possible to embed media like photos/videos, so that e.g. a PinePhone with limited storage can be used to some extent, even if it means not having access to bulky media (or having to pull it over the network from a 'full' device). How it began (6 months ago)🔗</a></h2> Causal trees as a CRDT (Conflict-free Replicated Data Type)🔗</a></h3> I finally started this project after reading Data Laced with History: Causal Trees & Operational CRDTs by Archagon (blog post)</a>. I had been keeping an eye on CRDTs for a while and saw this blog post as a way to finally get my hands dirty — by implementing one! It's a little bit lengthy and requires a bit of focus to get through, but I do highly recommend it. (This section may not make much sense if you (understandably) don't read the blog post, so skip if desired.) I learnt a lot by actually writing some code; some of the trickier parts in the blog post started to click into place. Once I had something basic that looked plausible, I took a bit of time to make it generic so that the causal tree logic itself was able to accept any 'atom' type (and they could have their own rules about priority, so that it was possible to support the special ordering rules for atoms like 'Delete' and some others that would be useful for a rich text schema later on). Too much detail about causal trees and the types of atoms I used. (Click to expand)</summary> It was highly satisfying to have the basics working (insert, delete and the merge of two documents), even just in plain text at a command-line prompt. pub enum PlainTextCausalTreeValue { /// The root of the document. Null, /// A text character; 1 unit wide. Comes after the atom that it points to. Character(char), /// Delete the unit to which this atom points. Delete, } </code></pre> Illustration of plain-text causal tree atoms and how they fit together: Extending this to rich text required a bit of thought. I decided to have 'descriptors' for marks and embeds; these descriptors precede the content of the document and only store attributes (e.g. the target of a link). This allows you to move the embeds or start and end of a mark, without having to copy all the attributes and duplicate the data. EmbedHere</code>, MarkStart</code> and MarkEnd</code> are added as extra kinds of atoms that can be used within the content of the document, along with Character</code> (and Delete</code>!). They have an additional reference to their descriptor. The priority rules are extended so that the descriptors come before the content of the document and so that Attribute</code>s cling tightly to their parent descriptors (but no tighter than the Delete</code>s). This allows you to read the document's atoms sequentially and populate a map of all the descriptors and their attributes easily. pub enum RichTextCausalTreeValue { /// The root of the document. Null, /// A text character; 1 unit wide. Comes after the atom that it points to. Character(char), /// An anchor positioning an embed, with reference to an embed descriptor. /// Embeds are 1 unit wide. Comes after the atom that it points to. EmbedHere(StorageAtomLocator), /// Delete the unit to which this atom points. Delete, /// Start a mark. /// 1 unit wide. Comes after the atom that it points to. MarkStart(StorageAtomLocator), /// End a mark. /// 1 unit wide. Comes after the atom that it points to. MarkEnd(StorageAtomLocator), /// Out-of-band descriptor for a Mark. Points to Null. MarkDescriptor(MarkType), /// Out-of-band descriptor for an Embed. Points to Null. EmbedDescriptor(EmbedType), /// An attribute on a Mark or an Embed. Points to a MarkDescriptor or EmbedDescriptor. Attribute(Attribute, AttributeValue), } #[derive(Copy, Clone, Debug, PartialOrd, PartialEq, Ord, Eq)] pub enum RichTextPriority { NormalText, NormalMark, HugAsChildValue, HugToDeleteParent, } impl AtomBody for RichTextCausalTreeValue { type Priority = RichTextPriority; fn priority(&self) -> Self::Priority { match self { RichTextCausalTreeValue::Null => RichTextPriority::NormalText, RichTextCausalTreeValue::Character(_) => RichTextPriority::NormalText, RichTextCausalTreeValue::EmbedHere(_) => RichTextPriority::NormalText, RichTextCausalTreeValue::Delete => RichTextPriority::HugToDeleteParent, RichTextCausalTreeValue::MarkStart(_) => RichTextPriority::NormalText, RichTextCausalTreeValue::MarkEnd(_) => RichTextPriority::NormalText, RichTextCausalTreeValue::MarkDescriptor(_) => RichTextPriority::NormalMark, RichTextCausalTreeValue::EmbedDescriptor(_) => RichTextPriority::NormalMark, RichTextCausalTreeValue::Attribute(_, _) => RichTextPriority::HugAsChildValue, } } } </code></pre> Illustration of rich text causal tree atoms and how they fit together: Thoughts about supporting undo/redo made me also allow cancelling a deletion by deleting the Delete</code> atom. (In this case, to undo some operation, you just need to track which atoms are created for that operation and create Delete</code> atoms for them. Redo is the same as undoing the undo!) Because Delete</code> clings the tightest to its cause/parent atom, you can easily check whether a particular atom is 'not deleted', 'deleted', 'deleted but the delete was deleted' and so on — merely by more or less scanning ahead and counting the number of Delete</code>s that follow (with the main exception that you need to be careful not to double-count concurrent Delete</code>s: two people deleting the same thing doesn't mean it should come back!). I'm not sure whether the idea of being able to un-delete is overall sensible or not (I haven't used this enough in practice), but I thought it was interesting nonetheless. </details> Rolling my own rich text editor🔗</a></h3> I was keen on using the egui</a> GUI library. I had used it for a couple of projects and it felt pleasant to write code with it. This lead to weeks of rolling my own rich text editor in egui (using the causal trees as a backing representation). It was a fun exercise and I got a half-decent starting point working! That said, it was quite tricky to come up with a simple enough plan to efficiently update the rendering state for incremental changes. I got something decent working for a line-based editor — you can just follow the causes of atoms until you find the start of the line and then reflow only one or two lines at a time! On the other hand, I really struggled to come up with an efficient method to lay out and render rich, nested structures (with incremental updates) without shedloads of effort or fiddly code and I had quite a few dead ends. Eventually, I realised that, if I wasn't careful, this would be an uphill battle for the entire project, especially as this is for a media-rich application and that just maybe it wasn't the best idea to write my own layout engine when you get one for free in a modern web browser. I also knew that supporting photos and videos would likely involve quite a bit of fiddly code to interface with decoders and manage GPU textures, whereas modern HTML is able to handle media with relative ease. In short: egui is great, but HTML and a web browser engine really wins for this use case, at least if roll-it-yourself complexity is on the list of concerns. A new plan (3 months ago)🔗</a></h2> Realising how much I'd gotten myself into and wishing for faster progress, I made the decision to abandon the hopes and dreams of a native application and switch over to doing something in the browser. I learnt how to use Vue.js and how to embed my web application into a webview using Tauri</a> (like Electron, but lighter weight) so that it could eventually become 'close enough' to a plain desktop application. I learnt how to write TypeScript because I thought it'd be sensible to have a little bit more rigidity and safety than JavaScript typically imposes. On the frontend, I picked up the Tiptap</a> rich text editor and used its built-in support for the Yjs CRDT</a>. The frontend connects to a daemon over a web socket in order to load and store data; in the future, it may be possible to use Tauri's messaging interface, but I wanted to leave the doors open to using Forgot10 outside of Tauri as well in order to support some future ideas. The Forgot10 daemon is responsible for notifying any connected clients (frontends) about document updates, storing data in SQLite databases and synchronising with other peers. Other peers are discovered using mDNS (by publishing and listening for advertisements with Avahi). Peers are identified by the hash of their TLS certificate, which they also advertise in their mDNS advertisement (so they can be identified before trying to connect). All changes to documents are pushed through an event bus (which allows listeners, such as syncing peers and connected clients, to receive updates in real time) and into a buffer that will occasionally flush them to disk. (The disk flushing operation just stores new fragments of the document and will occasionally coalesce them together if there are too many.) All of the documents' metadata are stored in the Yjs documents themselves, but a separate 'derivation' pass extracts or derives metadata (such as the title of a Page, or the timestamp of a Stream entry) from the Yjs document and caches this in the SQLite database. Caching the metadata in the SQLite database is crucial as it prevents us from needing to load all the Yjs documents in order to display a list of pages or in order to sort Stream entries chronologically. The derivation pass is also the time at which special nodes like reminders can be tracked in the database so we actually get notified in the future, or (one day) when the search index could be updated with the document's content. As the Rust port of Yjs is not ready enough yet, I resorted to running a Node.js process to load documents into Yjs on the daemon and perform various operations on them. (I tried several embeddable JavaScript interpreters but alas, this was the best solution I could get to work for now. At least it doesn't segfault :)) Once the Rust port of Yjs is ready, I'm looking forward to ripping this out. Rough architecture of Forgot10 at the moment: It's a start...🔗</a></h2> What I have at the moment is a multi-document rich-text editor, that works entirely offline but then will also work as a peer-to-peer collaborative editor, with impressively-live updates. Seeing it work for the first time and then having the chance to use it with someone else was very satisfying. Yet, frankly, most of what I've written so far has just been glue! It just goes to show what high-quality libraries are around these days and the cool things you can do by gluing them together. The cherries on top for my project have yet to come, but the foundation is there. What I'll be taking a look at doing soon is: Using it in practice and trying to get a feel for what's nice and what's awkward to use.</li> A LOT of cleaning up... The document store could be a little more self-contained and have an easier interface to use. It's tempting to pull it out into a library that can be reused for other projects, if that could work without making it too difficult to track the extras.</li> The GUI frontend needs some love. There are a few bugs I'm aware of that I've left until now, in trying to focus on getting something working.</li> </ul> </li> Implementing reminders properly: pull them out of the document during derivation; show an overview of upcoming reminders; and actually notify when it's time.</li> Search.</li> Media (photographs etc).</li> Export to HTML, to PDF and to Markdown. (I have experience with this from a prior project where I used ProseMirror, the library Tiptap is based on, and exported to HTML & PDF when necessary.)</li> Improvements to the build scripts and packaging so that it's easy to build and install. (There are a few manual steps at the moment, which arguably Cargo should be doing for you.)</li> </ul> There's a lot to sort out before I'll feel comfortable opening it up for others to use (or even to read the code). That said, this is a serious project that I intend to keep around for the long term (it's not just an experiment or a proof of concept), so given time, I will get there. An analogy between Rust's closures and structs 2022-04-11T00:00:00+00:00 Rust's closures may use funny syntax and may seem a bit magical, but they're actually little more than syntax sugar for a struct with a method. This conceptual correspondence might help you to transfer your intuition about structs to closures. A simple analogy🔗</a></h2> A closure such as... let z: i32 = 42; let closure = |x: i32| -> i32 { x * z }; assert_eq!(closure(2), 84); </code></pre> could be approximated as... struct MyClosure1 { z: i32, } impl MyClosure1 { pub fn call(&self, x: i32) -> i32 { x * self.z } } let z: i32 = 42; let closure = MyClosure1 { z }; assert_eq!(closure.call(2), 84); </code></pre> Notably, we create fields for the 'captured' local variables, using self</code> to access them within the call</code> method that represents the closure's body. Although we now need to write closure.call(2)</code> instead of closure(2)</code> to call our 'closure', this starts to paint a picture. It does, however, leave some details behind. Capturing local scope🔗</a></h2> Using a Copy</code> type such as i32</code> was perhaps not the best example. Let's take a look at some closures that actually hold on to the local 'scope'. Immutable references🔗</a></h3> From the land of contrived examples, I pluck out this closure which will return the sum of some numbers, multiplied by the provided factor. The closure needs to borrow the Vec</code> of numbers</code> so that it can sum them on demand. let numbers: Vec<i32> = vec![1, 2, 3]; let sum_times = |factor: i32| -> i32 { numbers.iter().sum::<i32>() * factor }; assert_eq!(sum_times(2), 12); </code></pre> Expressed in our struct analogy, this would look something like this: struct MyClosure2<'a> { numbers: &'a Vec<i32>, } impl<'a> MyClosure2<'a> { pub fn call(&self, factor: i32) -> i32 { self.numbers.iter().sum::<i32>() * factor } } let numbers: Vec<i32> = vec![1, 2, 3]; let sum_times = MyClosure2 { numbers: &numbers }; assert_eq!(sum_times.call(2), 12); </code></pre> Note that the struct is now parameterised with a lifetime (because it holds a reference to numbers</code>), but is otherwise much the same. This boilerplate really makes you grateful for the syntax sugar that is the || {}</code> syntax for closures... Mutable references🔗</a></h3> Much the same, except you sprinkle mut</code> in the places that make sense. Also note that call</code> now takes &mut self</code>, so in effect would need to be represented by our equivalent of FnMut</code> (let's get to that later). Before: let mut numbers: Vec<i32> = Vec::new(); let mut push_if_even = |x: i32| { if x % 2 == 0 { numbers.push(x); } }; push_if_even(2); push_if_even(3); push_if_even(4); assert_eq!(numbers, vec![2, 4]); </code></pre> After: struct MyClosure3<'a> { numbers: &'a mut Vec<i32>, } impl<'a> MyClosure3<'a> { pub fn call(&mut self, x: i32) { if x % 2 == 0 { self.numbers.push(x); } } } let mut numbers: Vec<i32> = Vec::new(); let mut push_if_even = MyClosure3 { numbers: &mut numbers }; push_if_even.call(2); push_if_even.call(3); push_if_even.call(4); assert_eq!(numbers, vec![2, 4]); </code></pre> Note that this example requires non-lexical lifetimes: push_if_even</code> has to die before we get to the assertion, since otherwise push_if_even</code>'s mutable reference would prevent us from being able to read numbers</code> (due to borrow checking rules). If you wish, try adding push_if_even.call(5);</code> after the assertion; in either case (closure-style or struct-style), the example will no longer compile :-). The move keyword🔗</a></h3> So far, the examples haven't moved anything into the closure (i32</code> is Copy</code> and doesn't need moving; the other examples have shown references). Moving things into the closure is a necessity when we want the closure to outlive its scope — often I find myself needing that when spawning threads or async tasks. For completeness, let's show an example here — using the example of returning the closure to justify moving things into it. fn make_closure(numbers: Vec<i32>) -> impl Fn(usize) -> i32 { move |idx: usize| { numbers[idx] } } let closure = make_closure(vec![10, 40, 90]); assert_eq!(closure(1), 40); </code></pre> (Please forgive the pointlessness of the closure body!) Note how we have to use impl Fn(usize) -> i32</code> as the return type — closures don't have a type that you can explicitly write, so we either have to do this or resort to dynamic dispatch with a Box<dyn Fn(usize) -> i32></code>. Carrying this example over to our analogy, we have: struct MyClosure4 { numbers: Vec<i32>, } impl MyClosure4 { pub fn call(&self, idx: usize) -> i32 { self.numbers[idx] } } fn make_closure(numbers: Vec<i32>) -> MyClosure4 { MyClosure4 { numbers } } let closure = make_closure(vec![10, 40, 90]); assert_eq!(closure.call(1), 40); </code></pre> In short: things being moved into the 'closure' is the same as a struct</code> field that isn't a reference! The Fn</code>, FnMut</code> and FnOnce</code> traits🔗</a></h2> This analogy is perhaps most useful once you consider the Fn</code>, FnMut</code> and FnOnce</code> traits. What exactly do they mean? Let's make our own de-sugared traits for those. Note that, for simplicity, we'll restrict ourselves to single-parameter functions. pub trait MyFn<A, R> { fn call(&self, arg: A) -> R; } pub trait MyFnMut<A, R> { fn call(&mut self, arg: A) -> R; } pub trait MyFnOnce<A, R> { fn call(self, arg: A) -> R; } </code></pre> The key message to take home here is that the only thing that changes is whether the self-parameter is &self</code>, &mut self</code> or self</code>! We then would want to implement these traits for our ad-hoc struct-closures — for example, using the last example: impl MyFn for MyClosure4 { pub fn call(&self, idx: usize) -> i32 { self.numbers[idx] } } </code></pre> We can now use impl MyFn<usize, i32></code> in lieu of impl Fn(usize) -> i32</code> in cases where we want to accept an arbitrary kind of closure. We can also use Box<MyFn<usize, i32>></code> in lieu of Box<Fn(usize) -> i32></code>! Implied traits🔗</a></h3> One thing worth noting is that, in plain Rust, an Fn</code> is also an FnMut</code> and an FnOnce</code>. (Further, an FnMut</code> is also an FnOnce</code>.) We could make this easier in our system by automatically implementing those, as follows... impl<A, R, T: MyFn<A, R>> MyFnMut<A, R> for T { fn call(&mut self, arg: A) -> R { MyFn::<A, R>::call(self, arg) } } impl<A, R, T: MyFnMut<A, R>> MyFnOnce<A, R> for T { fn call(mut self, arg: A) -> R { MyFnMut::<A, R>::call(&mut self, arg) } } </code></pre> (In practice, this might get annoying since all the methods have the same name, leading to the unfortunate need to disambiguate which call</code> we mean (as you can even see in the implementation!). Perhaps they should be called call</code>, call_ref</code> and call_mut</code> or something?) Under the bonnet: plain Rust's traits🔗</a></h3> Out of interest, if you went to look at the definition of Fn</code>, FnMut</code> and FnOnce</code></a>, you'd find something not entirely dissimilar to what we've written above: pub trait Fn<Args>: FnMut<Args> { /// Performs the call operation. #[unstable(feature = "fn_traits", issue = "29625")] extern "rust-call" fn call(&self, args: Args) -> Self::Output; } pub trait FnMut<Args>: FnOnce<Args> { /// Performs the call operation. #[unstable(feature = "fn_traits", issue = "29625")] extern "rust-call" fn call_mut(&mut self, args: Args) -> Self::Output; } pub trait FnOnce<Args> { /// The returned type after the call operator is used. #[lang = "fn_once_output"] #[stable(feature = "fn_once_output", since = "1.12.0")] type Output; /// Performs the call operation. #[unstable(feature = "fn_traits", issue = "29625")] extern "rust-call" fn call_once(self, args: Args) -> Self::Output; } </code></pre> Some of that is magic; magic which is out of scope for this document which was intended to make things simpler, but this is just to show that the approximation we're talking about in this post isn't that poor. Summary🔗</a></h2> If you imagine closures as just being structs with a trait implementation, you won't go far wrong. If you'd appreciate a source file with tests demonstrating the code samples included in this post, click here</a>. Otherwise, this table summarises the analogy: Plain Rust closures</th> 'Struct-closures'</th> </tr> </thead> Fn(A) -> R</code> FnMut(A) -> R</code> FnOnce(A) -> R</code> </td> pub trait MyFn<A, R> { fn call(&self, arg: A) -> R; } pub trait MyFnMut<A, R> { fn call(&mut self, arg: A) -> R; } pub trait MyFnOnce<A, R> { fn call(self, arg: A) -> R; } </code></pre> </td> </tr> closure(42); </code></pre> </td> closure.call(42); </code></pre> </td> </tr> let numbers: Vec<i32> = vec![1, 2, 3]; let sum_times = |factor: i32| -> i32 { numbers.iter().sum::<i32>() * factor }; </code></pre> </td> struct MyClosure2<'a> { numbers: &'a Vec<i32>, } impl<'a> MyClosure2<'a> { pub fn call(&self, factor: i32) -> i32 { self.numbers.iter().sum::<i32>() * factor } } let numbers: Vec<i32> = vec![1, 2, 3]; let sum_times = MyClosure2 { numbers: &numbers }; </code></pre> </td> </tr> let mut numbers: Vec<i32> = Vec::new(); let mut push_if_even = |x: i32| { if x % 2 == 0 { numbers.push(x); } }; </code></pre> </td> struct MyClosure3<'a> { numbers: &'a mut Vec<i32>, } impl<'a> MyFnMut for MyClosure3<'a> { pub fn call(&mut self, x: i32) { if x % 2 == 0 { self.numbers.push(x); } } } let mut numbers: Vec<i32> = Vec::new(); let mut push_if_even = MyClosure3 { numbers: &mut numbers }; </code></pre> </td> </tr> fn make_closure(numbers: Vec<i32>) -> impl Fn(usize) -> i32 { move |idx: usize| { numbers[idx] } } </code></pre> </td> struct MyClosure4 { numbers: Vec<i32>, } impl MyFnOnce for MyClosure4 { pub fn call(&self, idx: usize) -> i32 { self.numbers[idx] } } fn make_closure(numbers: Vec<i32>) -> MyClosure4 { MyClosure4 { numbers } } </code></pre> </td> </tr> </tbody> </table></div> RSVR: Experimental Virtual Reality in Rust 2018-12-21T00:00:00+00:00 Introduction🔗</a></h2> Virtual Reality</a> is an interesting concept but all current implementations (at least the ones that I found) are inaccessible, either due to their dependency on non-free software (e.g. Google Cardboard) or price (e.g. HTC Vive). I decided to start my own project, called RSVR (Rust VR), with the following goals in mind: Uses inexpensive or already-owned hardware</li> No dependencies on non-free software</li> </ul> With these restrictions in mind, it seemed quite clear that the most accessible route would be to make use of existing head-mounts for mobile phones, such as those used with Google Cardboard. I went for an Intempo-branded VR head-mount that was available for about 10 pounds at a relatively-local bargain shop. Because these head-mounts require mobile phones, I will eventually need to get visuals on an Android mobile phone. I should note that Android development is not something that I have done in about 4 years and it is also something I would like to avoid, because I hope to cease usage of Android in the next year or so! (After all, I want to clear RSVR's dependency on non-free software, which all Android phones I am aware of use. I also find the platform lacking in flexibility.) Proof of Concept🔗</a></h2> To test the feasibility of the concept, I first modified one of my university graphics course's practicals to render stereoscopically, yielding this visual: When viewed in a gallery application on a phone, my eyes were able to focus on it, though I could feel that tweaks would need to be made for comfort. Still, this was a good sign, so I decided it would be fine to start the RSVR project. Research🔗</a></h2> The head-mount I purchased did not come with any parametric information, but I did find a QR code for a different Google Cardboard viewer online. It turns out that these QR codes contain a goo.gl</code> URL shortener URL, which then redirects to a Google URL which contains a base64-encoded parameter p</code>. Knowing Google, I assumed they would be using Google Protocol Buffers to store this information, which would make it non-trivial to read without the protobuf definition file. Luckily, I was able to find CardboardDevice.proto</a> in a GitHub repository. It even contains descriptions of the fields! I used the protoc</code> tool on the CardboardDevice.proto</code> file to generate Python code to decode the viewer profile, then dumped the information into my notebook: /tmp$ mkdir pyout /tmp$ protoc --python_out=pyout CardboardDevice.proto /tmp$ cd pyout/ /tmp/pyout$ python3 >>> import CardboardDevice_pb2 >>> profile = base64.decodebytes(b"[… insert base64-encoded profile here …]") >>> devparams = CardboardDevice_pb2.DeviceParams() >>> devparams.ParseFromString(profile) >>> devparams [… profile values were dumped here …] </code></pre> Development🔗</a></h2> At this point, I had an inkling that I would need to write a few crates: rsvr_profile</code>: Crate to parse profile definitions, which I decided to keep in RON (Rusty Object Notation) for now.</li> rsvr_opengl</code>: Crate to be used by OpenGL applications for stereoscopic rendering.</li> rsvr_tweak</code>: Interactive tool to tweak the profile definition in real-time until it feels 'right'. (I would need this because my viewer did not come with a profile of its own.)</li> (potentially in the future) rsvr_vulkan</code>: Crate to be used by Vulkan applications.</li> </ul> I decided that I would first start by writing rsvr_tweak</code> to load and render Wavefront OBJ model files monoscopically. I found this well</a> on OpenGameArt.org. One More Eye🔗</a></h2> I implemented stereoscopic rendering and also added keybindings to change the viewer parameters on the fly. Now, just get it on the phone...🔗</a></h2> With rendering to a local window working, I now had to come up with some method of streaming the video to the phone (granted, it could be possible to run the VR applications on the phone, but I would expect a desktop GPU to far outperform that of a mobile phone!). Taking into account my reluctance to write anything Android-specific, I decided it may be worth a shot to try an in-browser solution using WebRTC (and VP8). Luckily for me, GStreamer has grown a WebRTC implementation</a> and I heard, from a FOSDEM 2018 talk, that GStreamer had some nice Rust bindings. I was pleasantly surprised by GStreamer; the bindings are as well supported as they are made out to be! A few days later and I had something 'working' but frankly unusable. I only managed 32 fps (or 6.2 fps in debug mode), as measured on the computer. Unfortunately, frames were being dropped more than they were transmitted and the latency would be on the order of 10 seconds or more... Not a good result! Using the excellent gst-launch-1.0</code> tool, I played around and found that hardware encoding gave a much lower latency. My graphics chip doesn't support hardware VP8 encoding but does support hardware H.264 encoding, so this may be an avenue that I need to explore. Still, I'm not sure if this will solve the issues because even the software vp8enc</code> encoder (with deadline=1</code>) performs markedly better than the results I've been getting! For the future🔗</a></h2> This project is far from its conclusion; I would definitely like to see it become usable. When I get time to work on it again, I will potentially look into the following: Having GStreamer perform the GL texture download using the gldownload</code> element or otherwise optimising the texture download process.</li> </ul> </li> Hardware video encoding for lower latency.</li> Replacing WebRTC with GStreamer's UDP sink & source elements, if this proves advantageous.</li> Cleaning up the Rust crates – right now, they are very messy! I find it hard to build abstractions in Rust where lifetimes get involved.</li> </ul> </li> Running RSVR applications directly on a mobile phone. Under Android</li> Under Halium (as long as GPU hardware acceleration is available)</li> </ul> </li> </ul> I hope to follow up this blog post in the future.

My First Ludum Dare Game: Olive Harvest in Ludum Dare 52

QuickPeep: My work-in-progress small-scale web search engine

Thanks 🔗</a></h2>
QuickPeep is built on top of many great quality, open-source libraries.
Many thanks to all their authors for putting their work out into the open for fools like me to enjoy!</p>

Forgot10: My application for note-taking and general information tracking

An analogy between Rust's closures and structs

RSVR: Experimental Virtual Reality in Rust

Olivier 'reivilibre'

Setting up a M93p mini offsite backup server, with power and cost calculations

Olivier 'reivilibre'

Setting up a M93p mini offsite backup server, with power and cost calculations

My First Ludum Dare Game: Olive Harvest in Ludum Dare 52

QuickPeep: My work-in-progress small-scale web search engine

Known problems🔗</a></h3> Quality of excerpts is usually poor.</li> Ranking can be a bit poor.</li> Pages without favicons show an ugly broken image.</li>

Forgot10: My application for note-taking and general information tracking

An analogy between Rust's closures and structs

RSVR: Experimental Virtual Reality in Rust