SoylentNews

This is part one of a four part proposal for a trustworthy computer consisting of ALU, registers, memory interface, network cards and compiler. Part one concerns ALU and registers.

It is possible to prototype processors using FPGA [Field Programmable Gate Array] development boards. They have numerous advantages and dis-advantages. They are small, relatively cheap, relatively fast and can be re-purposed for other projects but they typically incorporate DRM and require the use of untrusted software. If the purpose of the project is to create a trustworthy computer, an untrusted FPGA would not be the final solution. Therefore, we have to "keep it real" and devise a solution which can be implemented without an FPGA. It may be common for the solution to be deployed on an FPGA but a solution which does not specifically require an FPGA has numerous advantages. For example, any solution which vastly under-utilizes an FPGA may be implemented as a multi-core processor. Whereas, any solution which is crammed into an FPGA may be expensive or impractical to implement in other forms. So, the intended scale of integration is DIP chips in sockets which can be hand soldered. However, trade-offs of other implementations are acknowledged.

There are numerous techniques to make minimal processors. It is possible to apply the design principles of the Apollo Guidance Computer to make something which can be programmed like a 6502 or similar. Unfortunately, it will be significantly slower than a 6502 because it will use 64KB EPROM or similar with 350ns access time. Further circuitry, such as counter chips, may require a system to run below 1MHz. A lack of instruction pipe-lining and 64 bit registers will also require significantly more clock cycles per instruction. It would be unrealistic to assume 10% performance of a Commodore 64. Regardless, in the same manner that it is possible to get a 6502 to add 64 bit numbers, a smaller data bus and ALU does not prevent 64 bit data from being processed on minimal hardware. Likewise, memory bank switching allows a very large amount of memory to be addressed by a processor. It would be faster and more efficient to not use multiplexing of an ALU, data bus or address bus. However, the minimal implementation is cheaper, more tractable and may be replaced with more substantial implementations.

The system will be based around one 8 bit ROM. One output from the ROM determines read or write. The other seven outputs determine which internal register to read or write into an internal accumulator. This has the obvious defficiency, described in NAND2Tetris, in which instructions will typically be a series of read then write operations. This can obviously be improved with the use of two ROMs and no intermediate accumulator. However, this incurs Amdahl's law because there are also cases where efficiency does not double.

The native machine has 128 × 8 bit read-only registers and 128 × 8 bit write-only registers. Of these, half of the read-only registers provide immediate constants. Therefore, any value from zero to 63 can be loaded into the accumulator. From this, it is possible to:-

• Short jump within a 64 instruction page.
• Medium jump within a 4096 instruction block.
• Long jump across the whole ROM.

Some of the registers provide access to ALU functionality. In particular, it is possible set or clear a carry flag by writing to specific locations. Within the native machine, the window to main memory may be eight bytes or less. However, the virtual machine is not aware of this restriction. Anyhow, a minimal system proposal requires:-

• 5 × 4 bit binary counter chips for the native program counter. This is arranged into six bits, six bits and four bits to allow page, block and global jumps.
• 2 × 8 bit latch chips so that the parts of a medium jump or long jump can be applied synchonously. These are not essential but they avoid a large number of trampolines in the micro-code.
• One 64KB EPROM or similar.
• One 8 bit latch for the internal accumulator.
• Numerous latches for all of the general purpose registers.
• Latches for general register selection.
• Latches for temporary registers.
• Latches and counters for the virtual program counter.
• Logic chips for the ALU. This includes internal flags which are not available via the virtual machine.
• Logic chips for register decode.
• Logic chips for virtual instruction decode.

Within the 128 × 8 bit write-only registers:-

• Three addresses allow the native program counter to be set.
• A range of addresses allow ALU flags to be cleared or set.
• A range of addresses allow ALU operands to be written.
• Three addresses allow register operands to be selected.
• Eight addresses allow writes to a general purpose register.
• Four or more addresses allow main memory address to be specified.
• One or more addresses allow writes to main memory.
• Four or more addresses allow the virtual program counter to be set.
• One address allows the virtual program counter to be incremented.
• Four or more addresses allow virtual stack pointer to be set.
• Virtual instructions may be written into specific addresses for the purpose of splitting byte-code fields. This functionality is copied directly from the design of the Apollo Guidance Computer.

Within the 128 × 8 bit read-only registers:-

• The first half of the address-space allows constants from zero to 63 to be loaded into the internal accumulator.
• A range of addresses allow ALU operations to be queried.
• 24 addresses allow reads from general purpose registers.
• One or more addresses allow reads from main memory.
• Four or more addresses allow the virtual program counter to be queried.
• Four or more addresses allow virtual stack pointer to be queried.
• A range of addresses conditionally provide a subset of known values. This allows bit-field decode, conditional execution and jump tables to be implemented within the native machine.

The native machine does not have subroutines or conditional instructions. It is not a general purpose 8 bit micro-processor. It is micro-code for the purpose of implementing one specific computer architecture. Conditional sequences, such as loading variable length instructions into a bit-field decoder, require a terminating jump at the end of the sequence and multiple jump tables for opcode and addressing mode. These conditional addresses can be obtained from dedicated register locations.

It is also possible to return to the beginning of the fetch-execute cycle via the use of a dedicated register. This allows an interrupt to be handled without incurring additional clock cycles to test an interrupt flag. Given that there are no conditional instructions, this is the most logical implementation. The read of the interrupt vector also allows atomic sampling of an interrpt signal and therefore it avoids the obscure corner case where a transitioning interrupt signal level causes indeterminate behavior across the hardware.

It is not strictly neccesary to implement the virtual machine's program counter with dedicated counter chips. However, omission would require a significant number of clock cycles to perform an increment operation via an ALU. This differs from the Apollo Guidance Computer in which all hardware counter increments stole bus cycles to perform increment via the ALU. However, in the case of the Apollo Guidance Computer, all counters were the width of the ALU. In the proposed design, all counters are significantly wider than the ALU and therefore increment operations require dedicated hardware or micro-code. While increment of the virtual machine program counter is an optional quick win, bi-directional increment/decrement of stack occurs far less frequently and is more difficult to implement as a dedicated unit. In both cases, the virtual machine's architecture constrains read and write operations within one instruction cache line and data cache line. Within a micro-coded implementation, this allows the bottom byte of the address to be incremented without concern for ripple carry into other bytes of the address. To achieve this, unaligned read and write operations are split into multiple virtual machine instructions. You'll see why this is important in the next section.

Many native instruction sequences will be read, write, read, write and the occasional poke to clear a flag or suchlike. This could be implemented with a pair of micro-coded EPROMs and no intermediate accumulator. However, this increases cost, slows development and doesn't double performance. Regardless, it is a trivial option to increase performance after initial development.

In response to CID634544 from UID791:-

I have no interest in price/performance anymore. Whatever it is, it is. I'm extremely interested in price/security/openness. How open is the architecture? Are there any blobs anywhere? Is there a security chip like the Intel ME? If so, do I have access to the source code? Can I compile my own security engine to run on this dedicated security processor?

Those are the questions I have now. I would build a system today with far less power than the bleeding edge processors out there, but all the security we want and need. I firmly believe now that security can ONLY be obtained with full and absolute transparency. No security is obtained through obscurity of the methods and processes.

Intel and AMD can both do whatever the hell they want, but the first company to deliver the security we truly need will start getting a lot of orders. Even if they're lower on the performance/feature totem pole.

I have been working on a paractical solution to your problem. It would have been preferable to have a solution prior to Dec 2017, when Spectre and Meltdown became widely known. However, a solution remains urgent. I have an outline design in which all components are open to inspection. This will be described in several parts.

The first part is a minimal, micro-coded system which implements a processor with 64 bit registers but, to reduce costs, not a correspondingly dimensioned ALU. You said that you would accept this solution irrespective of its speed. I am concerned that you may wish to place further constraints on your specification because my proposal is likely to be significantly slower than a Commodore 64 or Apple 2. Obviously, if computers with a 16 bit address bus were suitable, you'd be using them already. However, if you compare, for example, the market viability of Tandem's high-availability, 16 bit, stack processors against my concerns about transistor switching speed and ALU latency and system integrity, you'll see that a native, flat, 32 bit address-space is a beguiling false economy from which I have freshly emerged.

The second part is the memory interface and card bus system. this also covers physical considerations, such as enclosures.

The third part covers contemporary expectations about network interfaces. Unfortunately, this may require a workaround involving bit-banging with an Arduino or similar. Allowing such an untrusted unit into a system requires all data to be distributed across multiple network interfaces. In the trivial case, this only provides link layer security across redundantly wired LANs. In restricted cases, this may also work across WANs.

The fourth part concerns writing a compiler for such a system. I have a viable proposal which allows a complete bootstrap from an insecure environment. However, all of the work on trustworthy hardware is moot if trustworthy software cannot be maintained.

(The tools and materials lists look like a Dave Barry homage but this is not a spoof.)

Tools: bandsaw and all associated safety equipment, tape measure, coarse file, sandpaper.

Materials: two or more ball pit balls, drain-pipe, sheets of wood or plastic, glue, (optional) piano hinge, (optional) suitcase latches, (optional) aluminium strips, (optional) Mecanno pitch 5/32 inch nuts and bolts, (optional) yoga mat or child safety mat, (not required) 60000 feet of tram cable.

In the 1970s, rounded corners were a statement of finesse and sophistication. In the television series, UFO, Colonel Edward Straker's office has a lava-lamp style mood screen and is white with rounded corners with one of the rounded corners being a mini-bar. Totally shagadelic. It also helped that they dressed like Sgt. Pepper's Lonely Hearts Club Band. The white, rounded corners are copied in UFO's submarine cabins. When the third season of UFO was cancelled and work started on the inferior Space 1999, Commander John Koenig's office had more than a passing ressemblance to Ed Straker's office. These design elements and others are often mis-attributed to a Steve Jobs wet dream but since the 1970s, audio and computer equipment has cycled around box colors of white, biege, brown, gray, silver or black. Everything except white, silver and black has been dropped from this rotation but rounded corners on physical products remain a neccesity when consumers are a danger to themselves. For example, consumers are barely able to operate a micro-wave oven safely. It is from this situation that website styling follows physical products. If all of your products have rounded corner then, for consistency, web site style may be similar.

For a very long time, I've wanted to make boxes of arbitrary size with rounded corners and I feel like a dumb-ass for arriving at a solution after so long. The answer came about two months ago and, since then, I've been loudly telling people about it. The answer is to use ball pit balls for corners, drain-pipe for the edges and arbitrary sheets for flat sections. If a ball has radius (or diameter) which is the same or larger than the drain-pipe then the ball can be trimmed to size. I was able to find ball pit balls and drain-pipe with 68mm diameter. Unfortunately, the palettes are horribly mis-matched. Drain-pipe is typically available in white, gray, brown, black and (rarely) green. Unfortunately, gray and brown tend to be large diameter sewage pipes. My local supplier only had 50mm and 68mm pipe in black. To contrast with edge color, ball pit balls are only available in garish kid colors, such as bright purple, lurid pink and lime green. So, edges and corners are likely to be in clashing colors. Regardless, it is relatively trivial to manufacture boxes of arbitrary size.

I assumed that ball pit balls are ridiculously cheap because they are required in such large quantities. With a two inch diameter or similar, a hypothetical 10×10×10 block of balls is quite small and 10000 balls would barely fill a closet shower. A typical ball pool must have hundreds of thousands of balls and therefore they must be cheap in volume. Indeed, they are. 200 are less than US$20 and volume pricing becomes increasingly favorable. I was also able to get 10 for £0.99 but many retailers don't stock them during winter. The plastic is presumably ABS, BPA or similar plastic commonly used for food containers.

Unfortunately, the balls are sold by diameter and not thickness. They are incredibly thin to the extent that two or more layers should be glued together. Given that they are incredibly thin and flexible, any two sections of ball effectively have the same radius. Therefore, two or more layers can be easily glued together. The balls are presumably manufactured with injection molding. The balls have two smoothed injection points at the "poles" and a seam at the "equator". This facilitates cutting one ball into eight demi-semi-hemi-spheres when only using blunt scissors. With a little practice, this can be achieved with tolerance of 3mm (1/8 inch) or better. However, the balls are manufactured very cheaply and the molds are not spun before the plastic sets. Therefore, one hemi-sphere may have notably thicker plastic. To compensate, place the four heavier pieces in one pile and the four lighter pieces in another pile. Then match a piece from each pile when gluing layers together. This achieves the most consistent thickness after gluing. If cutting tolerances are bad and a piece from the top of one pile doesn't match a piece from the top of another pile then rotate one pile around with the intention of improving tolerances. There is a permutation explosion of possible matches but rotating one pile should obtain fairly optimal matches.

I tried three types of glue and there is no particular preference. I tried unbranded crazy glue which is presumably an aroma compound because it smells of acrid mint. I also tried water-proof silicone sealant and kiddie PVA glue. All work well. However, all leak from the sides, all glue corners badly and all take a long time to set. Presumably, this is due to ingress of air mostly occurring between the thin seam between the layers of plastic and the liquid glue being quite deep behind this seam. Predictably, crazy glue makes the most mess. Silicone takes more than one week to set. PVA gives the brightest finish. I am concerned that layers may flake due to ingress of water. In which case, silicone may be preferable.

My efforts with a hand saw have been completely laughable. The cheapest saw was completely impractical. However, a really good hand saw makes an unbearable resonance when sawing a plastic tube. This is completely impractical in my apartment at any time of day. Unfortunately, I discovered this after purchasing a 2m drain-pipe. I didn't want to take the full length of drain-pipe to my local makerspace. This led to the humorous situation of me, wearing a Hello Kitty tshirt, in a quiet street, sawing drain-pipe. This allowed me to take six small sections to my local makerspace. This was enough to make two boxes or one disaster. Unfortunately, the bandsaw was unavailable and a wooden bench vice was unsuitable without use of rags to hold pipe in one place.

Anyhow, the plan is to cut pipe lengthways in to 1/4 sections. This provides four edges with a 90° curve. Admittedly, this requires very accurate sawing. In volume, a jig to hold the pipe would aid such accuracy. The best part is that it is possible to cut all of the pipes without measurement because sections of the same length are always used in multiples of four. Sections of a particular length are always parallel to each other. If it aids visualization, each dimension (length, width, height) may be regarded as one section of pipe exploded into four complimentary curves of the same length. From this, it is possible (or even desirable) to mix pipe colors to aid identification and assembly of pieces. It is only after cutting edges that accurate measurements are required. This is to make the flat sections of the box to the correct sizes. These may be a mix of wood or plastic of any any color and of varying thickness.

So far, I have only described the outer surface of the box. An unseen layer is required to hold the outer layer together. For this, I considered purchasing a US$50 flight case and diassembling it. However, a thought experiment of case asembly is sufficient. A flight case typically has eight molded plastic corners. Each of these corners has three tongues. Cut aluminium can be slotted over each tongue. The extruded aluminium also has flat edges which allows the visible external panels to be glued. The tongues and edges are all missing from my design. I've only described the external shell but it can be held together with a second layer of flat (or curved) pieces. This may be aided with foam. A thick and solid type of foam may be sourced from yoga mats or child play mats. The thickest, dense foam is intended to be used a gymnasium flooring or play area flooring. [Insert Mark Twain "but I repeat myself" joke.] This thick foam is available in continuous rolls or inter-locking sections.

A box can be made with two sections which are hinged together. This may be achieved with piano hinge which is, conveniently, available in piano length sections. It may also be cut to length without the hinge falling apart. (Indeed, it is possible to make unrounded boxes through the use use of piano hinge. A friend made transparent cuboid computer cases where all 12 edges used piano hinge bolted to plastic sheets. Where all eight corners are formed from freely hinged edges, none of the edges have any freedom of movement and the box is relatively rigid. On this basis, you may want to order surplus piano hinge.)

Alternatively, strips of aluminium can be used to make a card frame system. I originally envisioned a system which is a multiple of 2 inch × 4 inch × 4 inch (5cm×10cm×10cm) in a flat orientation with one inch or so of padding and rounding on all sides (left, right, front, back, top, bottom). Within one unit, it is possible to fit three or more separate circuit boards. This would be a minimum of 12 square inch (300cm²) of circuit board. Nowadays, across two units, is it possible to fit nine credit card computers. Some of those credit card computers are quad-core and 64 bit, 16 core processors are foreseeable. That would be 144 cores in 2 inch × 4 inch × 8 inch (5cm×10cm×20cm). It is also possible to make units where the external dimensions approximate 19 inch rack boxes. For example, 4 inch × 16 inch × 16 inch (plus 68mm diameter tubing) easily fits within 4U. (Note that this is entirely compatible with the car dash-board design and allows equipment to be used during journeys and then removed without drawing blood.)

I considered making a rounded box, stereo audio amplifier for a partially-sighted friend. We previously bought speakers to watch Breaking Bad. However, these speakers used impressively hair-thin wires and speakers which required the molded box to hold the magnet against the coil and cone. Cable strain relief was a knot in the wire. This only cost £1 (approximately US$1.50) and had no amplifier but I was unaware of the construction until I tried repairing a strained wire at my local makerspace. The response to my laughter was akin to "What are you laughing at? Have you not seen inside recent Chinese exports?" I was unable to repair the cable strain and my friend's attempt to fix it. So, we watched the end of Season 4 and all of Season 5 audibly squinting in monophonic. Now I can make a small box with a headphone jack, two speakers, one of 10 PAM8403 stereo audio amplifier purchased for robotics and a 5 Volt USB charger. Unfortunately, I've only got black drain-pipe which isn't particularly good. My partially-sighted friend who regularly loses his black, Casio F-91W terrorist watch and his black, Dell mouse. Regardless, it is possible to make four of the corners red [port, left audio channel] and four of the corners green [starboard, right audio channel]. Actually, I wonder why stereo phono leads don't follow international shipping standards.

I can also make a box for the alarm clock project. A friend kindly ordered 15 large, red, seven segment digits. That's two sets of six for HH:MM:SS (or YY/MM/DD) plus spares. However, this is a case where I received significantly more than I expected. The description said one inch *segments* but I assumed that the entire seven segment module would be a metric inch tall. Oh, no. The segments really are one inch and therefore the digits are more than two inches tall. That should definitely be readable when I'm drowsy and bleary. However, digits this size don't fit into the hummus tubs which I use for credit card computers and prototyping. I now require corresponding lengths of drain-pipe to be cut without incurring serious injury.

My attempts at hardware hacking may be slow and abysmal but, to one of my friends, I look like a fricking wizard; especially after a friend stepped on a Casio F-91W watch and I repaired the catch with a blue paper-clip (to match the watch's blue trim).

Tools: scissors, (optional) drill.

Materials: six bamboo sticks, string, (optional) washers, (optional) nuts and (optional) bolt.

A friend suggested making a camera tripod from bamboo and the result was surprisingly good to both of us. I only wanted three bamboo sticks for testing and maybe a few spares. After some comedy at my local hydroponic shop, I purchased one pack of 25 bamboo sticks rather than three packs of 25 sticks. Optimistically, this was enough to make two or more tripods with plenty of opportunity to make repairs.

Bamboo sticks taper and therefore sticks can be used in pairs such that the cross-sectional area of the bamboo remains fairly constant along the length of each tripod leg. At the splayed end of the tripod legs, string should be knotted around each pair of sticks and the knots should be spaced so that sticks lean by about 15°. At the center, all sticks should be closely knotted in pairs and then knotted together and/or held together with elastic bands.

The platform for a camera can be made from an off-cut of wood. Cut three tapered ridges which take into account the off-centeredness of the stick pairs. With sticks wedged into the wood block, this platform is sufficiently stable to rest a camcorder. Although the picture may not be level, it is more than sufficient for motion capture. A level picture can be obtained with the use of a Gorilla Grip or similar. Alternatively, it is possible to add a standard camera clamp by drilling a hole and adding one bolt, one or two washers and a nut. Apparently, there is one standard bolt size for still cameras and one standard bolt size for motion cameras. The extra sturdiness was required for the weight of film cannisters. However, as digital cameras are decreasing in size, the small bolt size is becoming increasingly common for still cameras and motion cameras.

"NXIVM is a multi-level marketing organization that offers personal and professional development seminars. Based in Albany County, New York, NXIVM was founded in 1998 by Keith Raniere. News reports and former members have described NXIVM as a cult."

Founder of “NXIVM,” a Purported Self-Help Organization, and Actor Indicted for Sex Trafficking and Forced Labor Conspiracy

Allison Mack, Smallville actress, charged over Nxivm sex trafficking

Smallville's Allison Mack Allegedly Forced 'Slaves' Into Sex Acts After Luring Women Into Controversial Group

NASA to Discuss Demonstration of New Space Exploration Power System

Media are invited to attend a news conference at NASA’s Glenn Research Center in Cleveland at 9:15 a.m. EDT Wednesday, May 2, to discuss a recent experiment to demonstrate a new nuclear reactor power system designed for space.

News conference audio and presentation slides will stream live on NASA’s website.

Kilopower could provide safe, efficient and plentiful energy for future robotic and human space exploration missions to the Moon, Mars and destinations beyond. The experiment was conducted November 2017 through March 2018 at the Nevada National Security Site (NNSS).

Previously: NASA's Kilopower Project Testing a Nuclear Stirling Engine
NASA Kilopower News Conference on Jan. 18
Initial Tests of NASA's Kilopower Nuclear System Successful

Over the last few months, my access to the Internet has been very restricted. I reverted to reading heavily. In particular, after a few iterations of selecting interesting web pages from Wikipedia.Org, I have more than 7000 web pages to read. I thought that I could read through the bulk of long pages with the aid of text-to-speech software. Unfortunately, I fall asleep while pages are being spoken. It is also difficult to pause. This isn't a huge productivity gain and it also leads to less rested sleep. It is fairly similar to sleeping with a radio switched on.

After bothering to implement a script which pipes text to espeak or similar, it seemed like a waste not to use this functionality. I wasn't sure what should be spoken but large quantities of text aren't received verbatim and are likely to be detrimental. Perhaps something in a loop would be more effective? Or timed? Ah! It is possible to make lucid dreaming hardware with a micro-controller and was one of many possible projects when my ability with micro-controllers improved. However, this project has now been reduced to a script for a laptop or desktop computer and the optional use of headphones. (Indeed, it appears that I've had the ability to do this for many years but only had the imputus due to lack of bandwidth leading to a huge backlog of text. If I had more bandwidth, I'd probably be listening to podcasts or similar.)

In my local makerspace, there were a few issues of Make magazine. One issue had instructions for making a lucid dream machine from sunglasses, a micro-controller, red LEDs and a momentary switch. Before going to sleep, wear the sunglasses with the micro-controller and push the switch. The micro-controller is programmed to do precisely nothing for four hours. It then blinks the LEDs a few times every five minutes. If a person is dreaming during one of these blinks, it may be interpreted within the dream as car brake lights or similar. After several incidences over many nights, this should be sufficient to prompt "Ah! I'm dreaming!" and in the long-term, this should be sufficient to bootstrap lucid dreaming without a micro-controller contraption. The micro-controller (or script) aids the relatively difficult first step of lucid dreaming.

The article in the magazine noted an unusual side-effect which is definitely worth repeating. I have not encountered this problem but it is entirely plausible. People using lucid dream aids are more likely to experience false awakenings and this greatly increases the chance of urinating during sleep. Apparently, this is worse among the type of people who keep a dream diary. Apparently, after a lucid dream, a person "wakes", writes in their dream journal, goes to bathroom, "wakes", writes in dream journal, goes to bathroom, "wakes", skips journal because urination becomes more urgent, goes to bathroom, "wakes", bathroom, and suchlike. This cycle can occur eight times or more and you only have fail a reality check once with a full bladder before waking in a urine soaked bed. Welcome to reality. Make sure that you note the incident in your dream journal.

With downsides noted, it is possible to obtain similar functionality with a small script to sequence text-to-speech messages. From experiences in dreams, I suspected this would be more effective than LEDs. One night, I fell asleep with 24 hour news on television. In the dream, I was in an attic with other people. I attempted to watch the television in the attic in the dream but the view was repeatedly obstructed by items in the attic or other people. Despite continual obstruction, I did not leave the attic. This was how a brain integrated an audio channel without its video channel. It could not fake the video channel nor mask the audio channel and so was in a situation where it required the presence of a plausible audio source without video. From this, I know that it is possible to convey more information than blinking LEDs - up to 100% fidelity with zero feedback. However, interpretation is extremely random.

The micro-controller design stays dormant for four hours. In Perl or similar this would be sleep 4*60*60. LED blink is replaced with echo "This is a test." | espeak or similar. I recommend that default rate of speech is slowed from the default. Despite this, I've found that framing errors occur with a repetitive prefix. For example, "Alert! Alert! Alert! Alert! This is a dream!" gets interpreted as "Lerta! Lerta! Lerta!" and the message is missed while you ponder "What's 'Lerta'?" This may be a semi-deliberate action from a brain which is attempting to hold together a coherent experience.

I mentioned my project to a friend. My friend suggested writing a phone app because accelorometers can be used to estimate a dream period. I may have further conversations with my friend because I have more ambitious plans. Said friend introduced me to the SCP Foundation, which is a mix of Cthulu mythos and a warehouse of artefacts; possibly inspired by a scene from an Indiana Jones film. My plan is to make stateful messages which can picked up at any point and prompt a dream narative akin to SCP: Containment Breach or Five Nights At Freddy's. You may ask "Are you insane? Deliberately inducing nightmares?" and I would answer "People watch horror films and play zombie games. Bang for buck, this may be much more effective." At the very least, it should be obvious that lucid dream software (or any closed source accelorometer app) should be inspected very thoroughly; in a manner which does not apply to other software.

Since mentioning the project to my friend, I've conducted four nights of testing. The first was a complete failure due to incorrect insertion of a headphone jack. The third night was unsuccessful due to timing being completely wrong. I suspect this experiment makes me more sensitive to auditory input from other sources. On the third night, I may have interpreted some drama among house-mates. However, making enquiries about events which may or may not have occurred may induce more drama.

The second night was quite good. In the dream, I was in my local makerspace despite it not looking like my local makerspace. After receiving one of the messages, I recall being slouched over a chair, with headphones around my neck, talking to a person in the dream about lucid dreaming software. There are numerous logical faults with this situation. Most significantly, if I hear a message from the software, it is because an instant of the software is running and the reason it is running is to provide auditory prompts while I am dreaming. The fourth night was a long science-fiction dream. At one point, I was Captain Janaway and Neelix told me that I looked ill. When I gained some notion that it was narative, the dream shifted to an office dream where the text-to-speech was interpreted as a hateful door entry system and therefore ignored. It then shifted to a scenario where a house-mate who creates drama was attacked by a giant with Thor's hammer.

Overall, I've made more progress in four nights than would be expected with blinking LEDs. Unfortunately, I may not have anything further to report on this topic for an extended period. Regardless, here is some example code which can be adapted:-

#!/usr/bin/perl

# Example Prompts For Lucid Dreaming
# (C)2018 The Consortium.
# 20180417 finish

# requires espeak to be installed.

$wait=3*60*60;
$rand=90;

$pre="Alert!";
@say=(
  'This is a dream.',
  'You are dreaming.',
  'This is not real.'
);

while(0==0) {
  sleep($wait+rand($rand));
  $wait=$wait/6+30;
  open(OUT,"| espeak -s 60");
  print OUT join(' ',$pre,$pre,$pre,$pre,$say[rand(scalar(@say))]),"\n";
  close(OUT);
}

Addendum 1: The micro-controller implementation may induce photo-sensitive epilepsy. Risk may be reduced by avoiding flashing sequences from 2Hz to 55Hz and only using LEDs which are either red, green or blue. Risk of epilepsy can be eliminated by using the audio implementation.

When I was a kid I used to really hate all the "old" people droning on and on about how wonderful the 1960s were. The TV was full of nostalgia programmes, especially music, and even the radio had seemingly endless programmes of tinny and inane pop songs. Then there were the hippies. They had sideburns and flared trousers! Argh! What's more, adverts on TV all seemed to have 1960s pop songs as soundtracks. There was no escape.

At about that time in the 1980s I discovered Bay Area Thrash. That was my thing. One of my favourite bands of all time is Slayer who are doing their farewell tour this year. A couple of years ago, I had my hair cut short. I still love the music. Mrs Turgid and I went to see Testament playing in London a couple of weeks ago.

Last week I was watching TV in the evening and I was most pleasantly surprised when an advert came on for a company (OVO Energy) which sells electricity apparently from only renewable sources which used Raining Blood by Slayer as the soundtrack! Ladies and gentlemen, Slayer are in an advert on mainstream TV in the UK for renewable energy! The advert starts with a load of clips of politicians and the like stating that they do not believe in climate change.

I am now my parents. I have short hair and my favourite music, frequently accused of being Satanic and antisocial, is now used to sell things on TV. I am the Establishment. I have arrived.

And while I'm at it, allow me to VIRTUE SIGNAL loud and clear: I just got myself a hybrid car. You should see the mileage I'm getting. My dirty old turbo diesel is off to the breakers yard.

I'm quite impressed with the concept of an exo-kernel. It is one of many variants in which functionality is statically or dynamically linked with user-space code. This variant could be concisely described as applying the principles of micro-controller development to desktop applications and servers.

In the case of micro-controllers, it is typical to include what you need, when you need and deploy on bare hardware. Need SPI to access Micro SD and read-only FAT32 to play MP3 audio? Well, include those libraries. Otherwise don't.

In the case of desktop applications, it is possible to include stub libraries when executing within one process or a legacy operating system or include full libraries to deploy on bare hardware or a virtual machine.

In the case of a server, the general trend is towards containers of various guises. While there are good reasons to aggregate under-utilized systems into one physical server, peak performance may be significantly reduced. For x86, the penalty was historically 15% due to Intel's wilful violation of Goldberg and Popek virtualization requirements. After Spectre and Meltdown, some servers incur more than 1/3 of additional overhead. Ignoring performance penalties, container bloat and the associated technical debt, the trend is to place each network service and application in its own container. This creates numerous failure modes when they start in a random order. This occurs because init systems avoid race conditions within one container but if each service runs in a separate container, this trivial safeguard is defeated.

Regardless, in the case of a server, an application may require a JavaScript Just In Time compiler, read-only NFS access to obtain source code for compilation and a database connection. All of this may run inside a container with externally enforced privileges. However, there is considerable overhead to provide network connections within the container's kernel-space while the compiler (and application) run in user-space. In the unlikely event that a malicious party escapes from the JavaScript, nothing is gained if network connections are managed in a separate memory-space. If we wish to optimize for the common case, we should have application and networking all in user-space or all in kernel-space. Either option requires a small elevation of privileges but the increased efficiency is considerable compared to the increased risk.

Running an application inside in a container may require a fixed allocation of memory unless there is an agreed channel to request more. People may recoil in horror at the concept of provisioning memory and storage for applications but the alternative is the arrangement popularized by Microsoft and Apple where virtual memory is over-committed until a system becomes unstable and unresponsive. The default should be a system which is secure and responsive as an 8 bit computer - and having an overview of what a system is doing at all times.

Similar arrangements may apply to storage. It is possible to have an arrangement where a kernel enforces access to local storage partitions and ensures that file meta-data is vaguely consistent but applications otherwise have raw access to sectors. If this seems similar to the UCSD p-code filing system, a Xerox Alto or my ideal filing system, that is entirely understandable. Xerox implementations of OO, GUIs and storage remain contentious but storage is the least explored.

The concept of an exo-kernel makes this feasible at the current scale of complexity and has certain benefits. For example, I previously proposed use of an untrusted computer for multi-media and trustworthy computers for physical security and process control. Trustworthy computers current fall into three cases:-

1. Relatively trustworthy micro-controllers of 40MHz or more. These have limited power dissipation and may be programmed on-site to user requirements. This limits the ability to implement unwanted functionality. It may be possible to access micro-controller memory via radio but this is a tedious task if each site has a bespoke configuration.
2. Legacy 8 bit computers of 2MHz or less. Tampered firmware must work within very limited resources. It is also slow and difficult to tamper with a system which is constructed 10 years or more after an attack.
3. A mini-computer design which is likely to run at 0.1MHz or less. Cannot rely upon security by obscurity but a surface mount 8 bit micro-coded mini-computer simulating a 64 bit virtual machine is, at present, an unusual case for an aspiring attacker.

In the previous proposal, there is a strict separation of multi-media and physical processes with the exception that some audio functionality may be available on trustworthy devices. This was limited to a micro-controller which may encode or decode lossy voice data, decode lossy MP3 audio or decode lossless balanced ternary Ambisonics at reduced quality. Slower devices may decode monophonic lossless balanced ternary audio at low quality. The current proposal offers more choices for current and future hardware. As one of many choices, the Contiki operating system is worth consideration. It originally a GUI operating system for a Commodore 64 with optional networking. It is now typically used on AVR micro-controllers without GUI. I previously assumed that Contiki was written in optimized 6502 assembly and then re-written for other systems but this is completely wrong. It is 100% portable C which runs on Commodore 64, MacOS, Linux, AVR, ARM and more.

How does Contiki achieve cross-platform portability with no architecture specific assembly to save processor registers during context switches? That's easy. It doesn't context switch because it implements shared-memory, co-operative multi-tasking. How else do you expect it to work on systems without super-user mode or memory management? I've suffered Amiga WorkBench 1.3, Apple MacOS 6 an RISCOS, so I know that co-operative multi-tasking is flaky. However, when everything is written in a strict, subset of C and statically checked, larger implementations are less flaky than legacy systems.

Contiki's example applications include a text web browser and desktop calculator. Typically, these are compiled together as one program and deployed as one system image. The process list is typically fixed at compilation but it is possible to load additional functionality into a running process. This is akin to adding a plug-in or dynamic library. Although it is possible to have dynamic libraries suchlike, this increases system requirements. Specifically, it requires a filing system and some platform specific understanding of library format. Although there is a suggested GUI and Internet Protocol stack, there are no assumptions about audio, interrupts or filing system. Although Contiki is not advertised as an exo-kernel, it is entirely compatible with the philosophy to iclude what you want, when you want.

With relatively little work, it would be possible to make a text console window system and/or web browser and/or streaming media player with the responsiveness, stability and security of an Amiga 500 running Mod player on interrupt. It is also possible to migrate unmodified binaries to a real-time operating system. In this arrangement, all GUI tasks run co-operatively in shared memory in the bottom priority thread. All real-time processes pre-empt the GUI. If the GUI goes astray, it can be re-initialized in a fraction of a second with minimal loss of state and without affecting critical tasks. This arrangement also allows development and testing under Unix via XWindows or Aqua. In the long-term, it may be possible to use Contiki as a scaffold and then entirely discard its code.

If media player plug-ins are restricted to one scripting language (such as Lua which runs happily on many micro-controllers), it is possible to make a media player interface which is vastly more responsive than Kodi - even when running on vastly inferior hardware. As an example, an 84MHz Atmel micro-controller may drive a VGA display and play stereo audio at 31kHz. Similar micro-controllers are available in bulk for less than US$1. Although this arrangement has a strict playback rate and no facility for video decode, it is otherwise superior to a 900MHz Raspberry Pi running Kodi.

Cardi B’s Money Moves

Cardi B’s ‘GQ’ Profile Slammed For “Objectification” And “Fetishization”

Cardi B

Jango Raid: Bodak Yellow