SoylentNews

(This is the fourth of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)

Via a fairly arbitrary process, I've got to a stage of explaining pragmatic problems with naming stuff in a computer.

Many naming schemes require a name resolution process. The process used by DNS is overly complicated. Although it would be easy to poke fun at systemd's repeated failures in this field, djbdns has been attacked with cache poisoning and steps have been taken to mitigate timing attacks by implementing UDP port randomization. An observation which could be made from djb's similar syncookies is that it is insufficient to implement baseline TCP or DNS because the Internet has become too hostile.

I investigated the implementation of Project Xanadu transclusion using DNS. The use of UDP to assemble small fragments of data in a fault-tolerant manner has obvious appeal. DNS's maximum fragment length of 255 bytes is unfortunate but can be overcome. However, popular DNS implementations, such as BIND are don't cache unknown response types. This means A records, TXT records or suchlike would have to be overloaded. Ideally, this should be handled carefully due to compressed encoding workarounds and record permutation compatible with the POSIX legacy singleton record interface.

It is possible to ignore these pleasantries and transport raw data as A records but this has two problems. Firstly, to obtain raw records, the local resolving has to be located without the benefit of the host's DHCP or suchlike. Secondly, administrators baulk at volume of data transported via their DNS infrastructure - and rightly so because this doesn't degrade gracefully. One user's browsing would be sufficient to cause intermittant or sustained host resolution failure within a local network. Video streaming over DNS is feasible to implement but would be anti-social to anyone sharing upstream infrastructure.

An erroneous assumption made by Project Xanadu is that multi-media can be handled almost as a corollary of handling text. I presume the logic is that multi-media is traditionally serialized and therefore can be subjected to similar constraints as paragraphs of text. However, I believe this is backward. If multi-media can be handled as three dimensional data (horizontal, vertical, frame number) or two dimensional data (audio channel, position) then one dimensional data (text) is the corollary.

So, an outline of requirements is as follows:-

• Simplified DNS is desirable.
• Traffic priority should be lower than legacy DNS implementation.
• Should allow server fail-over.
• Should allow 8 bit clean queries.
• Should allow 8 bit clean responses.
• Should have a compact representation.
• Should provide authentication.
• Should provide encryption.
• Should provide server delegation.
• Should provide a correct implementation of cache invalidation.
• Data should be served as UDP or similar.
• Should be optimized for small payloads but allow arbitrary volumes of data.
• Should permit addressing of one frame of video.
• If possible, should permit addressing of a range of video frames.

Although this looks like a system favoring a hierarchy of servers within one domain of trust, it remains possible to implement a federation of server hierarchies.

(This is the third of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)

How did we get to the current state of desktop computing and why is the future so uncertain? How did this veer so quickly into one of the deep topics of philosophy?

When Xerox PARC was founded in 1970, object programming languages, arbitrary bitmap displays, vector graphic storage formats, laser printing and ubiquitous desktop computer networking had yet to be developed. The development of a kid-safe computer which was no larger or heavier than a pad of paper was a futuristic dream. Nowadays, it seems laughably quaint. Unfortunately, continuous reference to paper has left us in a fascist dystopia of bureaucracy.

Our fundamental unit of information is not a bit, a factoid or a qubit. Our fundamental unit of information is a document, a form, a search, a sale or a recording. Unfortunately, with technology such as voice activated search, these units are often intertwined. In the broader case, this information is often used against a people who can or cannot be easily herded.

One future direction for technology is the full implementation of Ted Nelson's Project Xanadu. Ted Nelson is extremely irked by the current state of hypertext (a word he invented or popularized). However, his vision for orbiting satellites caching data paid with micropayments (another word he invented or popularized) remains outlandish after more than 40 years.

However, it is becoming less outlandish and is within the realm of tractable. Specifically, HTTP/1.0, as defined in RFC1945 reserved response code 402 for payment. When this was defined in May 1996, it was seen as a nod to our forefathers but with crypto-currency worth US$100 billion, implementation is a question which is being asked with increasing frequency.

It may be that Ted Nelson is fully vindicated and that the transition to DOI style tumblers and micropayments required a diversion via Zooko's triangle (however badly implemented). Prior to HTML and HTTP, hypertext was a knot of style, presentation, interface, content and transport. Systems such as Microsoft Help and AmigaGuide typically stored multiple documents in one annotated text file. HTTP/0.9 decisively cleaved storage, transport and presentation. However, it left a foreseeable trail of a trillion broken hyperlinks and an economic model which ate broadcast and print advertising.

If you've been following closely, you'll see that there are multiple possible formats for a reference to a resource. Typical formats include:-

• foo://host.domain.tld/path/to/res.ext - URL.
• bar:012345678abcdef - Hash of content.
• baz:9.17.2.6.22-24 - Tumbler range.

Each has limitations. All function within a string namespace, although, historically, inter-operability usually fails. Ignoring this, questions remain. What do we wish to reference? How do we wish to reference it? (Source. Destination. Quantity. Frequency.)

There are further complications with references and I intend to describe them next.

(This is the second of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)

Many of the limitations of computers occur because we have a poor simulation of paper popularized by a photocopying company.

However, there is another way. For this, I choose something which approximates a URL as a building block of information.

All problems in computer science can be solved by another level of indirection. -- Butler Lampson, Xerox.

By chosing a pointer in a namespace, we may reference legacy data (documents, multi-media files) in addition to data in the structure of our choice. If a URL, URN or URI was sufficient for this task then no further work would be required. However, a different approach is strictly necessary because:-

There are only two hard things in computer science: cache invalidation and naming things. -- Phil Karlton, Netscape.

In the current form, URLs, cookies and caching interact badly. For example, HTML requests made with different cookies cannot be shared among users. Whereas, image requests made with different cookies are handled as if the cookies were absent. This situation requires cache authors to implement a heuristic to ensure that most websites are compatible with one cache. Whereas, authors of popular websites implement a heuristic to ensure that most caches are compatible with their websites. The lack of fundamentals (no formal specification for URL caching) requires multiple parties to maintain complicated models. This is required so that a grammatically correct request for grammatically correct content behaves as expected.

A general problem with naming is Zooko's Triangle: Distributed, Secure, Human-Readable: Choose Two. However, even this would be an improvement. URLs incorporating DNS are not distributed. (DNS *servers* are distributed but a DNS namespace straddles one domain of trust.) URLs with or without SSL or TLS are not secure. 95% of users cannot read URLs.

Given an unconstrained choice, something like a Magnet URI would seem beneficial. However, this relies upon a chosen cryptographic hash function being a trapdoor function. If a practical quantum computer cracks the chosen trapdoor function then we have names which are neither secure nor readable. On the basis that security within a name cannot be guarateed, it may be preferable to err towards readable names and seek security elsewhere.

There are further complications with names and I intend to describe them next.

(This is the first of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)

Someone from my makerspace said "We're living in a post-Xerox world." and he didn't mean Xerox's business of photocopiers.

The original objectives of Xerox PARC are in widespread use. That includes object programming languages, arbitrary bitmap displays, vector graphic storage formats, laser printing, ubiquitous desktop computer networking and - most notably - ruggedized, kid-safe computers which are no larger or heavier than a pad of paper.

He believes that we're in a malaise because we've reached a widely known goal and there is no agreed continuation. Actually, he believes the problem is more fundamental. Collectively, we don't know that there was a set of ideas popularized by one organization nor do we know that we attained it.

I believe that we have a different problem. We've implemented digital paper rather than digital computing. This would be a problem if it stayed in a computer but it often spills onto paper too. A word-processor and rapid printing is contrary to a paperless workflow. Most significantly, it has continued the trend of increasing bureaucracy and forms. Even in the 18th century, people complained that there were too many forms. Now we have forms on paper, in HTML, PDF, apps and elsewhere.

This is tedious. It costs time and money. There is the obvious cost of time spent completing a form and time spent by administrators to process a form. Many types of fraud can be achieved merely by completing forms. As an example, a dental fraud cost UK taxpayers £1.4 million (US$2 million). It was achieved by completing about 30 forms per day describing fictious dental treatment.

Bureaucracy is organized around institional memory. This may be quipu storage, filing cabinets, file servers or databases. Bureaucrats perform ingress and egress filtering. Both may be infuriating. Ingress filtering should ensure that institional memory is accurate but this rarely occurs when the cost of errors is externalized. For example, when hundreds of large companies have read/write access to credit checks, the majority of credit reports are wrong. Egress filtering should restrict disclosure of sensitive information but, again, costs are externalized. Obtaining any meaningful change of state may be difficult. Ensuring an accurate round-trip of data may be impossible. Likewise for any inter-organizational change of state.

Block-chain enthusiasts claim that smart-contracts will significantly reduce these problems. It could make inter-organizatioal state atomic. However, unwinding bad states may require an individual with the skills of a lawyer and a programmer. Furthermore, the reduced friction of transactions could make state changes more frequent. Essentially, by Jevons paradox, this encourages more bureaucracy. Meanwhile, the interface between person and bureaucracy may become increasingly quixotic.

Forms continue to proliferate without satisfactory user testing and each form remains an oblique signal for a bureaucracy to change state. That's increasingly irrelevant when nation-states are falling apart and corporations are increasingly untrustworthy. Indeed, while peons are completing each other's forms and contact each other in telephone call centers, our overlords collect data in bulk and transform it into structured data. The most benign example is marketing analytics for the purpose finding the local maxima of a business model. Another example is an opt-out, keyword aggregating marketplace which skims value from millions of parties. This is commonly called a search engine. Then there is the fascist, totalitarian panopticon of signals intelligence which treats every citizen as an enemy.

However, there is another way. It requires a more suitable building block of data. I intend to describe this next.

This article has almost nothing to do with a promised series of articles. Instead, this is a continuation of motor control using audio amplifiers.

I previously discovered that a commonly available PAM8403 stereo audio amplifier board is sufficient to control two small motors. This is possible because the amplifier is intended to drive speakers with 4 Ohm or 8 Ohm windings. A speaker is a special case of linear motor and many small motors similarly have 4 Ohm or 8 Ohm windings.

The major advantage of this scheme is that *any* headphone output may be sufficient to control two motors. This includes pre-recorded sound or any programming language which can play sounds. That includes programming languages aimed at kids, such as Scratch and Squeak.

In some regards, a PAM8403 is an overkill for hacking. Regardless, it has advantages over an H-Bridge. For example, a linear amplifier allows forwards and backwards operation of two motors at variable speed. The major catch is that audio amplifiers expect an RTZ [Return To Zero] signal and therefore sending a continuous positive or negative signal fails to have any sustained impact. This can be overcome by sending a square wave of arbitrary amplitude and arbitrary duty cycle. A quirk of this encoding is that the square wave frequency isn't hugely important. We'll be using that property next.

A member of my makerspace asked if it was possible to control four motors using two audio channels. (Specifically, he's obsessed with quadcopters, drones and suchlike.) After some false starts, I found that an audio channel can be partially split into two by using an analog low-pass filter.

In this arrangement, the majority of an audio channel's amplitude is allocated to a low frequency square wave. This is directed to one pair of motors and allows the pair to be driven at almost maximum speed. The remainder of the audio channel's amplitude is allocated to a high frequency square wave which may have a complimentary or opposing bias. This is directed to one motor of the pair and provides stabilization of the platform in one axis.

For each audio channel, the audio filter consists of one resistor in series followed by one capacitor to ground. The product of the resistor and capacitor in the RC network determines the resonant frequency of the filter in radians per second. (Adjust by 2π to obtain cycles per second.) Optionally, use multiple RC networks in series to increase signal discrimination. However, for this application, it isn't particularly important.

Worked figures are as follows. Low frequency signal is 440Hz. Cut-off frequency is low frequency times four. High frequency signal is cut-off frequency times four. Resistors should be 470 Ohms. Capacitors should be 220pF.

I assumed that two stereo amplifiers would be required. By chance, another member of my makerspace was making an enclosure for stereo speakers and re-chargable batteries. The audio amplifier is a TDA7379 which is a quadraphonic amplifier which can be ganged into stereophonic. As a quadraphonic amplifier, it provides 13W per channel. I haven't gone through figures in detail but that should be sufficient to lift a computer, gyroscope and batteries. This is an extremely dangerous project but it is also shockingly accessible.

I have difficulty collaborating with other people. It may be that I'm a cantankerous curmudgeon but I suspect this is (also) a wider problem.

I write software. I dabble with analog and digital electronics. I do computer system adminstration and database administration. I prefer to write in C (for speed) and Perl (because the interpreter is everywhere). I greatly prefer to avoid proprietary environments. Although I've been described as being to the left of Richard Stallman, my interest in open licences comes primarily from not being able to use my own work. (Others take a much more hard-line approach and refuse outright to work on anything which won't be GNU Public Licence.)

I'm willing to work almost anywhere in the world. I'm willing to work with micro-controllers, super-computers, Lisp, PHP, bash, Linux, BSD, ATM, SPI, I2C, CANBus and numerous other concepts. I prefer to work with content versioning (any is better than none) and repeatable processes. However, I'm willing to work in an environment which scores 4 out of 12 on the Joel Test.

I have difficulty getting enthused about:-

• "Apps" where Apple or Google take 30%. This isn't a good deal for me or many clients.
• node.js or other JavaScript - especially in conjunction with robot control.
• C++, C#, Objective C, D or any other derivative of C.
• Anything over radio - especially IEEE802.15.4
• Block-chain systems in their current form.
• Facial recognition.
• Neural networks.
• "User experience."
• "Cloud."

I'm more enthused about FPGA and GPU programming but I like to have an abundance of hot-spares and, for me, that significantly increases a barrier to entry. This hardware also makes me edgy about being able to use my own work in the long-term.

Within these parameters, I'd like to describe some failed explorations with other techies. Without exception, I first encountered these techies at my local makerspace.

One techie is a huge fan of Mark Tilden, inventor of the RoboSapien and numerous other commerialized robots. Mark Tilden has an impeccable pedigee and has been featured in Wired Magazine and suchlike over 20 years or more. Mark Tilden espouses a low-power analog approximation of neurons with the intention of the neurons forming a combinatorial explosion of resonant states. When implemented correctly, motor back-EMF influences the neurons and therefore a robot blindly adjusts its (resonant) walking gait in response to terrain.

Anyhow, my friend was impressed that I'd used an operational-amplifier as an analog integrator connected to a VCO [Voltage Contrlled Oscillator] for the purpose of controlling servo motors without a micro-controller. My friend hoped that we'd be able to make a combo robot which, as a corollary, would perform a superset of 3D printing functionality without using stepper motors or servo motors. This is fairly ambitious but it would be worthwhile to investigate feasibility.

To complicate matters, I'm in a situation where modest financial success in this (or other) venture would gain my full-time attention. Whereas, he's currently receiving workman's compensation due to an incident at his electro-mechnical engineering job. So, I have every reason to commercialize our efforts and he has exactly the opposite motive.

There's also the scope of robot projects. They tend to be fairly open-ended and this in itself is cause for project failure. Therefore, I tried to nudge my friend into a project with a well-defined scope, such as high-fidelity audio reproduction. It is from attempts to make this situation work that I found that PAM8403 audio amplifiers were ideally suited to control motors. However, this discovery and further discoveries around it have not enthused my friend. (Note that the specification, as it exists, was to make an analog robot and avoid the use of stepper motors or servo motors. Admittedly, this fails to incorporate back-EMF but it is otherwise satisfactory.)

He's had personal problems which include his cheating Goth girlfriend dumping him and giving away his cat. He's also got his employer asking him to come back to work. Understandably, our collaboration has stalled.

An ex-colleague wants to collaborate in different projects. So far, we've had one success and one failure. The success contributed to a mutual ex-colleague's first Oscar nomination. The failure (his PHP, my MySQL) completely failed to mesh but led to a customized aggregator responsible for many articles on SoylentNews.

He's currently proposing an ambiguous deal which appears to be a skill-swap where we retain full rights on projects that we initiate. However, many of his projects involve tinkering with ADC and/or LCD. This would have been highly lucrative in the 1980s. Nowadays, it is somewhere between economizing and procrastinating. He previously worked on 100 Volt a monophonic valve amplifier but that was about three years ago and he never bothered to commercialize it.

Prior to this, I worked with friends on LEDs for an expanding market. We worked through the tipping point where the NFL and Formula 1 switched to LEDs. Two years ago, we were four years behind the market leader. Since then, we have completely failed to sell any LEDs to anyone. The majority have been using the venture for resumé padding and I've been out-voted on features even though I'm the only person who worked in the industry and worked with customers on a daily basis. After verbally being offered less than half of an equal share in my own venture, I haven't seen one of the active co-founders for 10 months. It would be reasonable to say that people are avoiding me. I find this bizarre.

Regardless, my task was to make a secure controller. The primary resumé padder wanted something which looked like an Apple TV. (This is for an industrial controller which may be exposed to 100% humidity and is required to meet ISO 13850.) I tried various options while being resource starved. I found that the software specification has yet to be achieved on a modern system. I found that the hardware specification is very difficult without an obscene budget. I also found that development on ARM has been difficult until relatively recently. The most accessible ARM system, a Raspberry Pi, didn't gain hardware floating point support under Linux until May 2016. Parties with successful projects (mostly phones) like these high barriers to entry. (How did Cobalt Networks launch successful RISC products in 1998? By using MIPS rather than ARM - and then switching to x86.)

In recent discussion about Raspberry Pi usage, you'll see how I've been influenced over the last two years or so about long-term support, hardware and packaging, micro-controller code density and other matters. I've also added options for documentation and training. However, without aligned collaborators or sensible resources, I'm not progressing. I suspect others are in diverse but analogous situations. Do you want to collaborate?

I sent something similar to a friend who gave me two audio amplifier boards:-

I've failed with the PAM8403 audio boards. Removing the 22nF capacitors seems to tie output to supply Voltage. This may be due my poor unsoldering or the 22nF capacitors having oscillator functionality in addition to blocking DC drift from audio input. It may be possible to connect the 22nF capacitors to ground (for the purpose of oscillation?) and connect signal behind the capacitors (for the purpose of permitting DC drift for motor control).

People at my makerspace are quite amused that a turtle or tank robot could be controlled with stereo audio output and an 80 cent audio amplifier. Four or more PAM8403 chips multiplexed with a 4052 chip or suchlike and controlled with two or more GPIO pins would be particularly cheap but effective.

After a technical argument at the makerspace about Lego motor specifications, it was determined that approximately all Lego motors (from 3V to 9V, excluding servo motors) may be compatible with a PAM8403. This applies much more generally - if a PAM8403 chip can be made to work with a DC offset.

Also, two of the amateur radio enthusiasts and electronics experts at the makerspace were particularly impressed by the size and cost of PAM8403 boards. However, they confirmed that D-Class amplifiers cannot be ganged.

If anyone can get this working then you'll be *very* popular.

I've been documenting work (and re-using some code from an under-funded project which came to a grinding halt when my last SD card burned out). As part of the documenting process, I've been dubbing audio on OpenOffice presentations. I've automated this process and the workflow is conceptually simple: .odp -> .pdf -> .png -> (quite a few more steps) -> .mp4 container with H.264 video at 10 frames per second and MP3 audio at a maximum of 128kb/s quality.

Software requirements are as follows: Unix type operating system with bash, make and perl on command path, OpenOffice or LibreOffice on command path, pdftocairo or pdftoppm on command path, ffmpeg or avconv on command path.

The directory structure is relatively simple (compared to previous projects). Populate a leaf directory with the given Makefile and an OpenOffice presentation with any name. (Or a PowerPoint presentation, if you really insist.) If multiple presentations exist in a directory, the one which numerically sorts last is chosen. This allows crude versioning to occur within a directory. Anyhow, with these two files present, type:-

make slides

and the directory will be populated with .png files - one for every slide in the presentation. (This workflow specifically doesn't work with animated images or embedded video. Feel free to add features as required. Likewise, script may fail to batch convert .odp to .pdf if OpenOffice or LibreOffice is running in foreground. Feel free to detect or correct this problem.)

With your preferred image viewer, step through slides and record audio for the presentation. Edit audio and place .wav or .mp3 with any name in the same directory. If multiple audio files exist in a directory, the one which numerically sorts last is chosen. This further allows crude versioning to occur within a directory.

Next comes the tricky part: slide transition times defined in a .csv file. The .csv file should be in the following format:-

01,1:06
02,2:33
03,5:04

where the first column is the slide number and the second column is the absolute time within the audio at which the slide should be *discarded*. (So, the last entry should be the duration of the audio plus maybe a small margin of error.) Times may be specified in seconds; minutes and seconds; hours, minutes and seconds; all with or without fractional values. Times are rounded down to the nearest 0.1 second.

Numbers in the first column should follow the numerical format of pdftocairo and therefore some slides may require one or more leading zeros.

With the audio track and transition times present, type:-

make this

and wait for the presentation to be made at 1024×768 pixels, 512×384 pixels, 256×192 pixels and audio only.

If making multiple presentaions, the second optional Makefile provides additional functionality for directory recursion and consistent titling across multiple presentations. Specifically, branch directories form sections and subsections. Each section (and suchlike) may optionally have one slide (plus audio) which prefixes every video and may optionally have one slide (plus audio) which suffixes every video. These "bookends" may be nested such that a video may be of the form:-

• common title
• section prefix
• subsection prefix
• content
• subsection suffix
• section suffix
• further info

However, this configuration is significantly more fiddly and knocks all of the timings in the .csv files.

I'll be using these scripts to process about 800 slides in 60 presentations. However, I've yet to record the accompanying audio. This will require about two minutes of audio per slide and, for me, before audio editing, that requires at least five minutes per slide with a hot microphone plus additional time to practice. So, I've got at least 4000 minutes of talking and I'll require significantly more time to edit and check my work.

Understandably, this task got me thinking about accelerated learning and it is my belief that 400 hours of finished presentations could form the vast bulk of a rigorous degree education.

Script to make one presentation:-

begin 644 Makefile.gz
M'XL(`!6B'UD"`[T8:7/;MO)S^"MV:+DB)8&'?"5RE,AM_5)/ZR23>-+WQO*+
M*1*24),$'T'*<FSWMW?!0P=U.)V7-!F3Q![8Q6)/[9BIB,T!"TT:3B!P;JBB
M[,"[B(;OAD/F4C@+HI@*`1<<3E*/<?,3\RB']PBD8>(DC(?P$P\G-!;XB;S:
M3WK;LH_@8DPE0O`X86E@*#N(DPBK;=L@$B=.YH`V"&="Y^N#ROJPLCY:6N]7
MZ/<K]/M5^O9^95VA;U?H]ZRE]8&UK.^!O5]9/\_7"/"92`Q73$",>>I[,*#`
MAY"@;88\#CH$23B`R_TT",'N0)@&-&:NXX-(\0*FDEKX:'*X9<D8?.IX+!S!
M%QIS82PQMSO@I7%^(;@W>$Q$OG,'+`1!71YZ`F['-$;!L>-**I0Q<?R4"G`0
M&O,T]*@''K\-(>%@F[95,!KR(*G(-#<].C%%@DJ`$WKY4BJ#KG.'APU8`A'>
MN#-@/DON,DXW\XX$S,A)QF;"S2'GYL")R<#Y8OXO3:=2W)1&!.%$PB6"2(1R
M<7;QVZG5I>Z80[VFO?_]9[T.#ZB6!R2&NN@9#5.[_*]YU307GGJMUL/]S+[=
M6Z;62%/OD66PZ)G-'NF-E--_7YR^M;O.A.6?>]T@VE?^]>'D_-3NVI:B.+[?
MP9MC0E%<O(?P,[,ZRC,2!T"&P((1:1A1.*I`$C$#".9CQ"Q"T#*)!-6T7+@^
MP]A6>W]Z=/B\1.W-40=V>[KW?'\-IGUP.+5?M-=@8LX3(XCV9H":EIG6ULD6
M27.BS3+G-)NESV@R%7+CH>7H5'H*Y+CN=4%EZ=?PPP_(<W[RZZD.I:45)8L"
M@7QSCS*X%TGG,2)OJ#P3/,]8A(PQ2GR9M`@I2`E2(1%<^PC$>Y]`(V/&*XN2
M_#E%GT@<Y@.QKZ']*G?M,/5]>'B`OO*,8T[\OA)\-HCI]Q4Q='Q!I0EYE*<`
M_ZZ5?0<,XSNW8W%KBU*DU/G&?R(-0I!M"]$3_,%D&\$6W+J(6_`(29QYA(3C
M(N&NPS`]$00`$9A8*9J13&6$'2X`[N#HR`()!_S&Q^]9#`+Y!3`XMIT3]2B,
MFXF+HN`?$9;?I"+SD4Q$>:#DI4(L6P1U08M,9-E6GBW:;B'M[,"0Q2)IS=BH
MXXYGO.?O3]^0BX]Y"7)Y'%,WF14;`P].8U2/8HJN)5WK6$:*=O:VI;Z<E3]5
M/[X=8_[3/#ID(?6T6LWOOCQ[^TK7[^7GG\*\[(?]^*I9JYDF%\<]VM7TXR@5
M8ZU'6[5:4\_Y,^+@7L6LWU?[_:N&]KK3[QOE2F_H:NOU`V);6`?PJ_4XTH][
M7C>FLD.A@#61)9K9,7%/>FE?Z<>UFM?%OTOKJF$WY8=]U3BTLJ_V56/OT+((
M'@O)6%>5=I-\UI4TC8I`O@1,A'HL[D1"`TUU)M*60'S.(WG'#.HJ_L=]LC<0
MMS-!^PRF[4.\^:3$>@4V8M//PR"!NW2RW[8B6:IJ6EZ-])*69V^T+1NB85[K
M]Z7LX3"(Z.@?D?V(QFE*`SZZ/A<4[UVOYVX65V(T;R8R%W,=K'OXEWLEMBCH
M9#S$VTEBZF"O^`P)9@447BV6SFIQW9$E.<9MO70`CNQ0D;VT/9MSRL5B8`U]
MQ\77K3.IY,EYL)'`B<!"2V4?=L>IV&W1*HAQ`,O;:DTOX[6XDN^KT@`7MI7]
M^[OZ%95AJ5=9SA`\C9-Q"W`>D(VI;/^*'C6[Q<4\@/UG%JG/,4+\5Y@2\$6(
M#'4,(L,PU2D"##7?:2Y%E8Z,_$BFW\]CG^F/C^5*7=$?W;\4E\EYF0EM-E>D
MY<I^E;1J#!?QDWMN1S7^X"S4U`>UU:.ZH:Z+*6ENET=W:SJYA7BE4TQ&MOY8
M+RO(/)%&&%.G;S_=9YMCXYN]'X^_B65C##A0AWC'931'9ID;^J&*UEY'L6+Y
MDOZ;V/])G63/7@:1<(84K**%EKD";VAA,B'N)MNO=?8U;;BLAT/I['(BQ@R3
M!H,08U`LY98UVS^1(#*MB"A[^-5>?B59_/\REG+"1H&Y0;[%V8HY8'4:^89G
M*V4LG6VCP++G%6PZN]*L4D""H_#-5]QI(;D<H[[R)!NX9NI@2Q+.%'+'U+T1
M:2!:P(8X0PO!!CY%W4B)(>,[S`]N.J#$Q3*)U;,J%LU4N6"$5,R"D/DTN`.4
MC<8S'7P6WD@7)WZX[DA/#(W(M.I>VV=(9%F]M>TC);+,#+H\6&Y0VQB[]E;5
M)<$&]2N\:_$;CE%A78M?/LXR1PG)6_RO'9>+<4!1J,>2SGPFKHZ,"RW%RG3[
M).WBG/HD<3&GR$%@09_9SV+;!^UM9(M:;*,K%!AP?D-##RVI>$C]F;51'<WU
MP#"D`8,;C\7R-Z8?3SZ>ZG7T-!?[WBB&!M2QA)7P19;$B7$V+WZP(_PVI+&L
M/%A0RFT,)*EG)JII;WY[]Z.^I-]UF:"6MW3_-G^148J>>UG=T1>&YWB1:35'
MY!OGW`.D:&\GF7[9CD_BE)9FM3MK^L!*8X#@;+[$J0&TWLF'-Y_R!@QZHU;>
M]:A2AOIHJ*9JJ(VB@Y!#QF.!E^90'[MY(P;8B.&81Z?4U=0R%(I;5O4ZG&-R
MRSL+Z:2C>OZ.LC=Z3?:6S7?V@>UWO3R,-8\[J5`7-__Y[(-.));("#P_U=7%
M^"MLD///F9&IJUY'MU[QNZ.8&@US.BU6=6'F.UY:Y,55(WOFWQL?<DJN7V>B
F9WGA'/6[]F1=:.[^9S?8]<CN+[OGNQ^OUVB(&>(O29%TT_H7````
`
end

Optional script to make multiple presentations:-

begin 644 Makefile.gz
M'XL(`#NB'UD"`\U7>5/;1A3_&WV*5R%'DD&'Q6$P<0:2>A*F)702AK9#&"Q+
M*WN#KM%*PN;(9^];R?(%>*"E3&!&N_ONW[ZWN\^KOQ@92XP>#0T2YA#8ET00
M5N$X)N&QYU&'P&$0)X0Q.(G@('-I9)Q2ET3P!Q))F-HIC4+X$(4Y21A.45?Y
MH%IFHPDG`\(9+$I2F@6ZL(H\SC"MA@4LM9-T2F@"LW,R65O6W'IS@;]I;<^O
M-\RY]98YK[_5V%Q8[Y1K)&2,0.2!X9+<8*E+0[!#MUQ>DR3"'1F!3P.:0HQ`
M[![U:3K2!:'SUTGG<Z-MYU00;-]O@>,3.[R@)J0#RH2554B(DR6,Z,)*3!(?
M-`+RU8#Z1'&)1T/B*I(T:+^M&T>XYQ[2WZGJ#2?]8,:W"=$P(K;'1BPE@2(Z
M+L@B_J-4,>X5^0)T+ZIWLB!4(;2$E20`S0,:]+6Z'H?]BH"I].A0EY0R?+6B
ML\R;IY>VIJ@0T*OA*7R6B/A>MOAF.D6%I:!';@QI!'KL>L(*B\H:U;0!L5V?
MEZFFC44UE$(AZ/I(=$'+H5XHWT)J4PR_T87;6_@FK$18ZR]AQZ>]A+R$(<_V
M&>&@HYB?+DSO:+V8!Q2+M42NE7F;M<5M3VW]`.M=6<9AYONH@&RTL41CF3'4
M#_*EWA[G38*=J<:9A'+A(J&<CHLTBF,4QR5HS+%]@ONF#:%AXJ&?$D;0;)K`
MZ8!S_/S))39!^P3-[9UE*#&*\3X7SAR;XBE_#7>3M$ZAHU.$GO,+%7?)SCD'
M-#^*8NZ#%CO6*,0TIY7C/=0;6MOH-<5[#&.FPPLO2&&4Y9N6&8.68%!CG<E)
MKIQ[04SZ_Y/M$M@C\5O_PH?UQ/A?R':5&#?K@<W?.'T&#;V'&DFS"?=\V\'A
MRL[GCAP6`>DG)`99.;.UZ_,S4]L]KY]AU6SOG&NWY4VLRK.UH@5V#":"*2:-
MEKT`K<"`)!N">`.K<X`O$F'IO5M]8<]^7@0]Y#7,XN\)<!;*C-Y+YW^"U=C8
M:NXBK/(I?)G$+#ZK#R;F9T3P<&(>@U,D1NA%T24)7=:J.J!7:Q@JSV7/P'R\
M3XNNX=4"*%V6[HE+T]:T-7E.^_&L%N.);83@4I9>4`M#4C!Z78<W;R"X=&D"
MLJ2\/_C:465L`QV\(N,$ZB#KNE'19U6P7\=6)LP"DE!'BZY"@FN'/^N5&1U%
MY"(L2?GX^_%[=:YFNU6US)MTGJT_O@9X2Y%X"^'VKRGBV"VBFC)*PZ5V#R6L
MY2+#Z^7\-,DFV]IHS=26%R5847[;W,/OVQW^75M3;Y!,;&<`DN2"LG_PY>.I
M>A-G;`#[_75)ZGP^O1&Y#_%.%PU1%^N&.$1-'<7O[L9\OAWB7?M[1$-%!'%]
MOZ_ND2%Q%%%2C@Y^ZZ@PSK*(I[XJ7)!Y8?3E<HR+T6%Y,?*+I9C@U2)78/CO
M!C+D/W.`!]1&X[\>?E$USM4DY>3PJ*.*/''S3ANE_E09E=IB-[YRL289<8$-
M];HQ'(Y7,C-*B]5S@M]R_NA'D@Q#[A:NQRYX+.C#M5,":[6_:T'-U6J?:D>U
0K]T'(C0%X1^4/-2PZ`X`````
`
end

(Usual instructions for uudecode process.)

I haven't posted a journal entry in a while and it's a slow day at work, so buckle up; here we go!

In my last entry, I said that my wife was pregnant, and I was pretty bummed because this girl that I had barely started seeing decided to end things. It's been almost 9 months since then.

The pregnancy went pretty well. I found it really interesting to see how my wife's body changed and read about all the developmental milestones of the little bundle of cells that was growing in her belly. She downloaded some phone app that every week would list some things that were being developed that week, and then would compare the size of the fetus to a vegetable. This week, your baby is the size of an avocado. The next week might be an orange, then eventually pineapple, and finally a small watermelon.

Throughout the pregnancy, we would go in for ultrasounds. We wanted the sex of the baby to be a surprise, so we made sure to tell the technicians not to tell us anything we didn't need to know. As the pregnancy nears completion, the doctors appointments get more and more frequent (Thank Jeebus I live in socialist Canada). During on of those appointments, the doctor wheeled in this ancient ultrasound machine and started looking to make sure the baby was upside down and in position for delivery. The doctor wasn't able to see the baby's head in the right position, and so scheduled us in for a modern ultrasound to see what was going on. We learned that our baby hadn't flipped yet.

As soon as it was confirmed that we had a breech baby, they gave us the option to schedule a c-section. My wife really wanted to have the natural birth experience, so we looked into other options. Apparently, there is a procedure that can be done where the woman is given muscle relaxants, and then a doctor massages the belly to manually manipulate the baby into position. This procedure is quite painful, and doesn't have a very good odds of success (something like 60%) and there is a chance that you might go into labor, or they may have to do an emergency c-section if the baby is in distress.

We decided to try it out. I took the day off work and we headed to the hospital. Before the procedure we went for another ultrasound, and it was found that the umbilical cord was wrapped around the baby's neck, and there wasn't enough slack to allow for them to flip it. With no other choice, we scheduled a c-section delivery.

As delivery day inched closer, we were getting more and more excited to meet our baby. Finally the big day arrived, and we were at the hospital bright and early at 7:00am. We waited for quite a while, but around noon, we were told it was time to get ready. They took my wife away and gave her the epidural, then I was allowed into the operating room. The next thing I remember is holding my baby girl. She was (and still is!) so beautiful, with lots of copper hair! I cried. It was amazing to finally hold her in my arms. My wife was still strapped to the operating table and was being sewn up, so I got to show her to my wife.

We were released from the hospital a day later. It was surreal experience bringing her home for the first time. We had a steady flow of friends and family coming over, and it was actually pretty stressful (we are both introverts).

Our little girl is now 3 months old, and cute as a button (when she is not crying, anyways). When she looks into my eyes and smiles, my heart melts.

Just before the birth, I volunteered here at SN to be an editor. Just as I started actually posting stories, we found out our baby wasn't in birth position, and then things have been crazy ever since. Now, when I have a moment, I don't really have the energy/motivation to actually do the editing/posting work here. I'm really sorry guys, but it looks like you have done just fine without me. Maybe one day I'll be able to contribute again.

Anyways, I think I'll end things here. Maybe next time I'm bored at work, I'll post my experience with being a first time father (hint: the first 3 months, at least, are mostly terrible with moments of joy).

Got to say, the green look on the site is actually *really* nice. If it was a few shades darker though, we'd be too close that the site that shall not be named.