Monday, October 15, 2018

DOS for kids

Find out why my kid is learning DOS in 2018...

There are many great options to learn how to use computers. You could get any excellent Linux distribution, and install it on a spare machine. You could teach a child Python or Basic256. My kids use Linux laptops, and that works out well for most of their needs.

Recently, my son took an interest in other operating systems. His hard disk is going bad after years of use, and we started experimenting with alternate operating systems on USB sticks. He saw me reading about Haiku; we booted it up and played with it. We already used Dosbox to play a game that I really enjoyed as a child, so we installed Freedos on an SD card to play with it.

He loved FreeDOS better than I had expected. It is a very simple system: single user, no access control, no hidden or magic directories. Everything is right there in front of you. We installed QuickBasic and a typing tutor, and he loves the system. He even loves the spartan look of the default editor, which looks like edit.com.

Today, he practiced typing on a typing tutor from 1992.  Then we wrote a simple Basic program together, and compiled it to an EXE file. He loved every minute.


That made me reconsider tech's love of the new. The computing world is a slave to hot trends: Artificial Intelligence, Machine Learning, Virtual Reality, Augmented Reality, Internet of Things, Blockchain, ... Everyone wants to learn about new technologies, the old is an embarrassing relic.

But are new systems always the best to learn?


There are scores of videos showing how old systems booted up faster, and got the job done just as well. There's a hint of truth to that.
FreeDOS boots on a decade-old computer in less than a second. Quickbasic probably takes a second to start up. Compilation is quick. Everything is instant. Fast. No clutter. No notifications, no icons, no buttons, bars. The whole interface has been run through an optimizing compiler.

The system cannot connect to a network, so everything is child-safe. And there is no chance of my kid goofing off and playing a game, or being distracted by some pictures. My son said that FreeDOS was "an Xterm that became your full computer."

And to top it up, my son can modify whatever he likes and experiment to his heart's content. When he ends up messing up the system, we can reinstall FreeDOS in a minute by wiping the SDcard clean, and copying again. I have a stack of old SD cards.

All the knowledge gained is valuable in today's world: hierarchical file systems, writing source files, compiling, touch-typing. It is a simple system and a person can truly understand the fundamentals. Learning DOS might be easier than learning a very complicated architecture like Linux, where there is a kernel, but also userland utilities, X-Windows, browsers, multiple users, access control...

In the past few days of playing with FreeDOS my son has asked insightful questions, which make this experiment very satisfying for me.




Image: Courtesy Me.

Saturday, September 22, 2018

Autobiographies ...

I haven't read a lot of autobiographies, but here are a few that I've read in the last couple of years that made an impression.

Books about high-altitude mountaineering are exciting by definition.  But there's more to this one than just that.  It's the story of a woman who wants to climb high mountains in a time when it's mostly men who do that sort of a thing.

2. Tender at the Bone by Ruth Reichl
Ruth Reichl is a restaurant critic / cookbook author.  This is the story of her unusual childhood (dysfunctional family included), and her love of cooking.  It's peppered with recipes that I didn't really want, but I loved the story.

3. God's Hotel by Victoria Sweet
The author writes about her years working at San Francisco's Laguna Honda Hospital, which is one of the last few almshouses (a free hospital for poor and often chronically ill people) in the country. Dr. Sweet also talks about her research of pre-modern medicine (and be warned - those sections are not as interesting).  But overall, I found this book to be very insightful and very fun to read.

The three books above were all surprise finds.  I picked them up at the library and brought them home because I liked what it said on the back cover.  Didn't have them recommended to me by a friend.  Didn't look up the Amazon reviews.  What joy to run into a good book accidentally like that!

Tuesday, February 13, 2018

Game Review: TIS-100

TIS is a new game by Zachtronics. tl:dr; Geek? Buy it.

Earlier, I had written about the lack of diversity in games. The world doesn't need another action adventure first person shooter. What it needs is creative games, games that make you evaluate, to think new thoughts. I loved a game that made you burn stuff, and a gem by Zachtronics called Space Chem. I have been interested in Zachtronics' catalog since SpaceChem. For background, SpaceChem was about splitting and combining atoms to make new molecules.

TIS-100 is about parallel programming. But that's as vacuous as saying Chess is about moving wooden pieces on a board. TIS is about writing good code, about making magic with very little, about learning how best to utilize a small instruction set.

It is about reliving 80s computing: complete with a ratty manual, an uncertainty about what to make. Walk away with an appreciation that you can do a lot. Learn the system, and you can bend it to your will.

You write assembly language programs for a computer that has multiple stream processors, where multi-processor communication is a one-cycle primitive, and you choose how to achieve the objective.

You don't need to know assembly, you don't need to know programming. You don't need knowledge of Chemistry for SpaceChem, you don't need to know programming for TIS-100.

But at the end of it, you appreciate programming and you learn how much fun programming can be.

TIS is an absolutely amazing game. A game that I will be recommending to many friends, and their young kids.


Here's a video showing the different processors (little square boxes). The highlights are on executing lines, and the left side shows inputs and expected outputs.


Video courtesy: me.

Saturday, December 23, 2017

Laser cutting: Creating a phone stand

For the holiday season, I wanted to make my co-workers something useful.

Everyone has a cell-phone at work, and we are mobile developers.  To reduce desk clutter, I thought a phone stand might be perfect.  I had recently learned how to use a laser cutter, and looked around for a good project to grab from usual websites like thingiverse.  Despite looking online, I didn't find anything that suited my needs.

The goals:
  1. A simple material, hopefully sedate and elegant.
  2. Fewer pieces was better.  I wanted to make more than 30 holders, and simplicity would allow me to make many of them.
  3. Ability to fit a wide variety of phones.
  4. Tablets would be a plus, but not required.
I had cut some wood in an Epilog cutter before, so I decided to continue using 0.125 inch plywood.

Step 1: Prototype

This was my first experience designing a physical object.  Being a true engineer, I grabbed a pencil, a pen-knife and some cardboard from discarded packaging.  I started with a simple design with two pieces: one for the face plate, and one for the bottom.  The bottom would poke through the face plate and hopefully lock in.

I worked with various widths and lengths, to see what would hold a phone comfortably.  The first cut was made from a cardboard case, and was too short, and the base wouldn't lock tight because I made the base too curved and the cardboard was too weak.

Calculating the weight of a usual phone (adding 30% for future growth), the inclination, and the rough springiness from wood, my son and I worked out the lengths of the various segments.

With some iterations, I arrived at two perfect rectangles: the face plate was taller, the base had long prongs that would stick out.  On one cardboard prototype, we were able to hold a real phone without flopping.  This is the first prototype holding up a phone.


That night, I drew one face plate and one base on Inkscape, learning about Inkscape as I went. To personalize them, I added a co-worker's name to be etched (marked in red) while lines in black were to be cut.

Finally, 12 x 24 inches plywood at 1/8 inch thickness was bought.

Step 2: Test on Paperboard

To confirm the measurements, the first draft was loaded up on the laser cutter with some quarter inch paper board.  I added inch markings along the side to diagnose any deviations in the cut.  This is the desk area as I was waiting for the cut to finish.


To my utter shock, the first cut on cardboard was absolutely perfect. It measured exactly to spec, the two pieces locked together, and it held up my phone.

Step 3: Test on Wood

With the success of the paperboard run, I decided to calibrate the laser cutter for engraving and make a single test run on wood to see how well it held up.

I loaded up my wood, and sent the same .svg file, this time calculating laser intensity for wood instead.  The power on the first run was too weak, so I just repeated the run without moving the wood. It led to a working model, this time in wood!  The face plate is to the left and the bottom plate is to the right. Notice the inch markings along the left edge, still visible.


This is what it looks like with a phone on it.





Making a single phone holder is easy, and takes forty minutes to print the face plate, then readjust origin, print the base plate, and ensure the cut is good.  Making many copies without mistakes would be time consuming.  I did not want to manually adjust the origin, and find where the start from.  I would have to automate it to make all the holders in time for Christmas.

Step 4: Production!

Over the next few days, I used the wooden prototype, and learned:
  1. The prongs were too short, which led to the phone sliding off. This was bad.  The prongs needed to be longer.  To allow for a phone charger cable, gaps were cut at the bottom of the face plate and the bottom plate.
  2. To minimize wastage and manual effort, I had to fit 30 face plates and 30 bottom plates on as few sheets of plywood as possible. Eventually, I ended up fitting the face plates together on one run, while bottom plates would go in another svg file.
  3. After completing #2, I realized the laser cutter might not cut perfectly near the edges of the wood, and all wood warps over time. In addition, I might not set the origin perfectly, and the board might be smaller if it was at the edge. So all sizes were reduced by a small amount to leave a thin border of wood as a precaution for these issues.
  4. A friend came over and suggested that usernames worked better than first names for our office.  All first names were changed to usernames.  This was a great idea since there are people with the same name.
  5. Since I had increased the prong size in #1 and reduced the overall board in #3, we'd have to create another PVT to confirm before a final production run.
  6. The inch markers were left in the final run, adding a minimalist elegance to the design.
  7. I had just enough wood to make all holders, but no spare planks if I messed up.
  8. Kids fell ill, leading to production delays.

With all these lessons, three new Scalable Vector Graphics (.svg) files were created: two containing 15 faceplates each in a 3 x 5 grid. Since these had names for engraving, they had to be different files. The font sizes were reduced for longer usernames to make them fit on a line.   The inch markers and names are in red for engraving (less time at 100% intensity).  The black lines are for cutting through (more time at 100% intensity).



The bottom plates were not personalized so a single sheet with 21 bottom plates (3 x 7 grid) was made.  Ordering spare wood would have been wise, but I aimed for perfection instead.




Finally, I went over to the laser cutter with wood, .svg files, paperboard, pen-knife and tools.  After confirming that the new measurements with longer prongs and overall reduced size still held up a phone, I loaded up a full sheet of 12 x 24 inches plywood at 1/8 inch thickness.


Engraving all the names and inch markings took the most time: 40 minutes for each face plate sheet.  Here's the engraving, in progress.  The sound is the ventilator at full-throttle.  The laser cutter itself is relatively quiet.  You can see how painfully slow the progress is.  There are three other names that you don't see, which is why the arm is swinging far out of these two usernames




Cutting took 10 minutes, and just to ensure a precise cut, I ran the job again with just the cutting again.  Even so, some sheets were warped around the sides and some plates were loosely attached and had to be scored with a pen-knife to separate.

Here's a video of the cutting in progress.  You can see the inch markings along the left wall as the cut lines up perfectly against them.



The bottom plates were faster, having no engraving.  Here's the start of the bottom plate run.  You can see the narrow border left, which was to allow for some error while setting the origin of the run.



My co-workers got a personalized phone holder each, and I still had wood left over.  There was one hilarious mistake where a username were incorrectly spelled, and another where a natural knot in plywood marred the username.  These face plates were cut again, individually.

With that, production was complete.  The delight was not just in having a personalized gift for everyone, but the satisfaction of a job well done.

Images: courtesy me.

Saturday, February 18, 2017

Learning Blender


I have been learning Blender the last few weeks. Here is the video I made today.  There are four glass spheres moving with a wooden cube in the back.  It took about two hours to render on my Linux computer.  Each frame takes about two seconds to render, and there are 1800 frames.  The video has 24 frames a second.

Blender is a 3D modeling software that is freely available on Mac, Windows, and Linux.

Monday, December 12, 2016

KernelOops on Nvidia 367 with dual monitor setup

My home Linux display setup is complicated.  The Linux desktop has two monitors, and one of the monitors is connected to the desktop via a KVM switch.  The KVM is also connected to a non-Linux desktop.  I use a Nvidia GTX950 card on the Linux machine, which needs proprietary Nvidia drivers to run. In the last few weeks, I started getting Kerneloops when suspending the Linux machine.  The problem seemed to be the nvidia modules of the kernel.  I didn't have kernel oops earlier, so I started to track down the cause.

I finally found the issue was nvidia not being able to modeset correctly.  My previous Xorg config forced a specific screen layout.  The new Nvidia binary driver undid this, and that is roughly when the suspend problems started happening.

I have two screens: DFP-0, and DFP-4.  You can see your own list of screens by looking at the file /var/log/Xorg.0.log.  The relevant lines that show you which screens are connected is here:

[  6615.937] (--) NVIDIA(0): Ancor Communications Inc ASUS VS247 (DFP-0): connected
[  6615.937] (--) NVIDIA(0): Ancor Communications Inc ASUS VS247 (DFP-0): Internal TMDS
[  6615.937] (--) NVIDIA(0): Ancor Communications Inc ASUS VS247 (DFP-0): 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-1: disconnected
[  6615.937] (--) NVIDIA(0): DFP-1: Internal TMDS
[  6615.937] (--) NVIDIA(0): DFP-1: 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-2: disconnected
[  6615.937] (--) NVIDIA(0): DFP-2: Internal DisplayPort
[  6615.937] (--) NVIDIA(0): DFP-2: 960.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-3: disconnected
[  6615.937] (--) NVIDIA(0): DFP-3: Internal TMDS
[  6615.937] (--) NVIDIA(0): DFP-3: 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): Acer K272HUL (DFP-4): connected
[  6615.937] (--) NVIDIA(0): Acer K272HUL (DFP-4): Internal DisplayPort
[  6615.937] (--) NVIDIA(0): Acer K272HUL (DFP-4): 960.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-5: disconnected
[  6615.937] (--) NVIDIA(0): DFP-5: Internal TMDS
[  6615.937] (--) NVIDIA(0): DFP-5: 330.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.937] (--) NVIDIA(0): DFP-6: disconnected
[  6615.937] (--) NVIDIA(0): DFP-6: Internal DisplayPort
[  6615.937] (--) NVIDIA(0): DFP-6: 960.0 MHz maximum pixel clock
[  6615.937] (--) NVIDIA(0): 
[  6615.938] (--) NVIDIA(0): DFP-7: disconnected
[  6615.938] (--) NVIDIA(0): DFP-7: Internal TMDS
[  6615.938] (--) NVIDIA(0): DFP-7: 330.0 MHz maximum pixel clock
[  6615.938] (--) NVIDIA(0): 


In the above example, you can see that DFP-0 and DFP-4 are connected to the graphics device while the others are disconnected.

In my case, the graphics card was trying to determine which screens were still connected.  This is the incorrect behavior when I switch to the non-Linux computer through my KVM switch.  My Linux desktop resizes and all windows move to the screen that is still connected to the desktop.

To force X to force both screens to stay connected, you can use the magic 'ConnectedMonitor' option.  This goes in the Screen section.  It is confusing since the screens that you refer to in the Connected Monitor line are DFP entries that you get from Xorg, while the metamode lines refer to screens in the same terminology as the output from xrandr.  DVI-I-1 is the first DVI device, while DP-2 is the second DisplayPort device.   I suspect DFP means Digital Flat Panel, to distinguish it from Cathode Ray Tube (CRT) and Liquid Crystal Display (LCD).

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "DVI-I-1: nvidia-auto-select +2560+0 {rotation=left}, DP-2: nvidia-auto-select +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    Option         "ConnectedMonitor"   "DFP-0,DFP-4"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Using the example above you can force DFP-0 and DFP-4 as connected devices. Once you add the line in red, you need to restart X, and then the Nvidia driver will not reallocate the desktop when a screen is disconnected from the display (when the KVM switches).  As a happy side-effect, the Kerneloops while suspending are gone as well.