That sounds backwards in a market that keeps selling AI as a real-time companion: copilots, side panels, floating prompts, chat boxes waiting inside every workflow. Some of those tools genuinely help. In coding, drafting, search, and synthesis, in-flow assistance can be the work rather than an interruption. The sharper bet is about a different terrain: support queues, finance operations, CRM cleanup, internal handoffs, and all the multi-system sludge that accumulates while people are busy doing the visible part of their jobs.

Daytime AI has to earn its keep inside a moment that already has an owner. A designer is mid-layout. An analyst is checking a number. An account manager is answering a tense email. A lawyer is choosing a word that may matter later. Even a good suggestion arrives with a bill attached: read this, verify that, compare the source, decide whether to trust it, then return to the original task. The interface looks light because the box is small. The cognitive bill shows up in the handoff.

The night shift offers a cleaner bargain because bounded, asynchronous work changes the shape of the problem. While people are away, a system can work a defined queue and return prepared material: duplicate support tickets clustered, CRM fields reconciled, invoices matched against purchase orders, long internal threads summarized, borderline cases routed into review. None of this looks magical in a keynote. It looks like a room that stopped accumulating clutter.

This is where the “isn’t that just automation?” objection is useful. Clean rules and ordinary workflow software should handle clean cases. AI earns a place only where the input is messier: ambiguous ticket language, partial record matches, duplicated requests phrased three different ways, long email threads with decisions buried in them, vendor documents that almost agree. The useful role is humbler than management cosplay: turn murk into a smaller set of human decisions.

The governance case only works under those limits. An overnight system is safer only when the input bucket is explicit, the allowed actions are narrow, and the morning evidence is real. Every run should leave receipts: a manifest of records touched, a diff of fields changed, confidence thresholds used, skipped items, escalations, and a rollback path. Without that discipline, unattended automation can simply make larger mistakes while nobody is watching. With it, the blast radius stays legible.

That discipline also forces better product design. Many organizations already have plenty of places to type questions. Their bigger pain sits in stale queues, broken handoffs, drifting fields, and work that rots between systems. A useful AI layer should start where the mess is measurable. Give it a bounded intake pile, a checklist, an exception lane, and a morning report. Make it a reconciler before calling it a colleague.

The strongest early deployments are likely to look boring from the outside. They will read from trusted systems, perform narrow transformations, write structured outputs, and leave evidence behind. People will notice cleaner inboxes, fewer duplicate tickets, shorter triage meetings, calmer dashboards, and reports waiting before the first coffee cools. The glamour metric in AI is delight. The durable metric in operations is silence — provided the silence comes with receipts.

Once a team trusts one reliable overnight shift, it can start redesigning work around preparation instead of interruption. People leave cleaner intake piles at the end of the day because they expect sorting before sunrise. Managers ask for morning exception reports instead of staging live status theater. Analysts begin with pre-joined context instead of opening six tabs to reconstruct yesterday. Some entropy moves into a scheduled lane with evidence attached.

That future is less theatrical than the talking assistant everyone keeps advertising. It is also more plausible. Offices already have enough entities asking to collaborate in real time. They need a dependable second shift that cleans, sorts, checks, and stages the next move while the building is quiet. The first useful AI employee will earn trust the old-fashioned way: by making the morning less stupid.

The newly reported 2016 Clean Power Plan memos matter because they expose the Court’s institutional self-awareness. When the Court issued a one-paragraph order halting Barack Obama’s signature climate policy before any lower court had ruled on the merits, several justices appear to have understood they were doing something unusual. Chief Justice John Roberts reportedly called the posture “not typical.” Justice Stephen Breyer reportedly described it as unusual for the Court to intervene while the court of appeals was still considering the case. Justice Elena Kagan reportedly said it would be unprecedented to second-guess the lower court without full briefing or a prior judicial decision.

That matters because it sharpens the real point. The emergency docket is no longer just where the Court handles genuine procedural emergencies. It is where the Court can act with maximum force and minimum explanation.

On the merits docket, authority comes with visible burdens: full briefing, oral argument, signed opinions, coalitions the public can inspect, and reasoning that can be attacked line by line. On the emergency docket, the sequence is reversed. The order comes first. The effect is immediate. The explanation, if there is much of one at all, is thin. The country changes anyway.

That is why the Court now operates in two tempos at once. One is public, formal, and ceremonial. The other is fast, tactical, and only partly illuminated. The first is how constitutional law is supposed to justify itself. The second is how national policy can be bent before that justification arrives.

Emergency action at the Supreme Court predates 2016, and some emergency relief is plainly necessary. Governments do move fast enough to moot review. Lower courts do issue conflicting commands. The danger comes from normalization: emergency orders now reach fights that sit at the center of national power.

Those fights now include the core disputes of national power. Reuters has described a term already packed with questions involving presidential authority, birthright citizenship, tariffs, voting rights, and campaign finance. At the same time, the Court has increasingly used emergency orders to let major Trump administration policies proceed while legality remained contested below, including measures touching immigration, transgender service members, agency officials, federal layoffs, and foreign aid. This is governance in provisional form, dressed in the costume of housekeeping.

Justice Ketanji Brown Jackson put the institutional damage more clearly than most critics have. She said the Court’s expanding use of the emergency docket has had a “corrosive effect” on the judicial system and creates “zombie proceedings” in the lower courts. That phrase lands because it describes the split between paper process and real power. The lower courts continue to move. Briefs are filed. Orders are entered. Proceedings remain technically alive. Above them, the Supreme Court has often already changed the practical and political reality of the case.

A defender of this system could say the Court is simply adapting to a faster, more combative political order. Why wait years for a polished opinion if an immediate order can prevent what the justices see as unlawful action now? That argument has force. It misses the constitutional cost. Public power is supposed to come with public reasons, especially when the stakes are national and immediate. If the Court repeatedly chooses the channel that demands the least explanation in the most consequential disputes, speed starts looking like insulation rather than modesty.

The 2016 memos matter because they cut against the comforting story that this transformation was accidental, or merely the byproduct of hectic times. They suggest the justices understood the break with ordinary practice even as they made it. Ten years on, the pattern is clearer. Presidents learn that delay can mean defeat. Litigants learn that the shortest route to power may be an emergency application rather than persuasion on a full record. Lower courts learn that they may be managing aftermath while the real constitutional weather has already changed overhead.

The deeper issue is the bargain public power owes the public: reasons alongside force. When the Supreme Court repeatedly decides the terms of national conflict through fast, thin, partly inscrutable orders, it moves from refereeing the constitutional system to governing through the side door — and hoping the country mistakes that for restraint.

The sketch in Weather_New_4.0.ino follows a clean cycle: connect to Wi-Fi, sync local time with NTP, call OpenWeather One Call 3.0, parse a small set of high-value fields, render the e-paper UI, and sleep for 15 minutes. That sequence is what makes the project useful as a build pattern.

1. Define the appliance inputs in code

The sketch starts by fixing the operating context: network, API key, location, timezone, refresh interval, and clock format.

const char* ssid     = "yourwifissid";
const char* password = "yourwifipassword";
String openWeatherMapApiKey = "youropenweathermaponecall3.0key";

const char* CITY_NAME = "Memphis";
const char* LAT       = "35.1495";
const char* LON       = "-90.0490";
const char* TZ_INFO   = "CST6CDT,M3.2.0/02:00:00,M11.1.0/02:00:00";

const uint32_t UPDATE_INTERVAL_MINUTES = 15;
const bool USE_24_HOUR_FORMAT = false;

This gives the board a permanent home, a stable local clock, and a firmware footprint that stays simple enough to flash and mount without a setup menu.

2. Sync time before you draw the screen

The NTP setup is simple and worth copying.

configTzTime(TZ_INFO, "pool.ntp.org");

time_t now = time(nullptr);
while (now < 8 * 3600 * 2) {
  delay(500);
  now = time(nullptr);
}

That wait loop gives the screen a real Updated: time and keeps bogus startup timestamps off the panel. For a household weather panel, that detail matters.

3. Build one compact One Call request

The One Call API 3.0 docs describe the endpoint like this:

https://api.openweathermap.org/data/3.0/onecall?lat={lat}&lon={lon}&exclude={part}&appid={API key}

The project uses the endpoint in a disciplined way:

String serverPath =
    String("https://api.openweathermap.org/data/3.0/onecall?lat=") + LAT +
    "&lon=" + LON +
    "&exclude=minutely,hourly,alerts"
    "&units=imperial"
    "&appid=" + openWeatherMapApiKey;

According to the official docs, One Call 3.0 provides current weather plus forecast data, supports daily forecasts out to 8 days, and updates every 10 minutes. This sketch requests exactly what the panel needs and trims the rest.

That exclude= list is a meaningful design choice. It keeps the response smaller and keeps the display focused on the few values the screen is built to show. A more safety-oriented version would likely keep alerts and add a dedicated warning state.

4. Retry with backoff when the network misbehaves

The fetch logic uses retries with exponential backoff.

const int MAX_RETRIES = 5;
int retryCount = 0;

do {
  jsonBuffer = httpGETRequest(serverPath.c_str());
  myObject   = JSON.parse(jsonBuffer);

  if (httpResponseCode != 200) {
    retryCount++;
    if (retryCount >= MAX_RETRIES) {
      return;
    }
    uint32_t backoffMs = 2000UL * (1UL << min(retryCount - 1, 4));
    delay(backoffMs);
  }
} while (httpResponseCode != 200 && retryCount < MAX_RETRIES);

That solves the most common field failure in small connected devices: a flaky network cycle. A missed refresh is tolerable. A board that hangs forever becomes a maintenance problem.

5. Parse only the fields the display actually uses

The parsing block is compact and clear.

weather  = String((const char*) myObject["current"]["weather"][0]["main"]);
int w_id = int((double) myObject["current"]["weather"][0]["id"]);
humidity = JSON.stringify(myObject["current"]["humidity"]);

double mph = double(myObject["current"]["wind_speed"]) * 2.23694;
wind_speed = String(mph, 1);

double vis_m  = double(myObject["current"]["visibility"]);
double vis_mi = vis_m * 0.000621371;
visibility    = String(vis_mi, 1);

double t = double(myObject["current"]["temp"]);
temperature = String(int(round(t)));

t = double(myObject["daily"][0]["temp"]["max"]);
maxtemp = String(int(round(t)));

Each piece has a job: – weather and w_id drive the icon and label – humidity, temperature, and maxtemp fill the main readings – visibility becomes miles for an imperial display – daily[0].temp.max supplies a useful High field without a second API request

There is also a valuable technical caveat here. OpenWeather’s docs say current.visibility is in meters, so the meters-to-miles conversion makes sense. The same docs say current.wind_speed arrives in miles/hour when units=imperial is set. This sketch still multiplies wind speed by 2.23694, which looks like a cleanup target. If you build from this repo, verify a sample response and likely remove that extra conversion.

6. Compress the weather codes into a small icon set

The sketch maps OpenWeather condition IDs into a handful of local icon categories.

if      (w_id >= 200 && w_id < 300) weather_flag = 2;
else if (w_id >= 300 && w_id < 600) weather_flag = 5;
else if (w_id >= 600 && w_id < 700) weather_flag = 4;
else if (w_id >= 700 && w_id < 800) weather_flag = 0;
else if (w_id == 800)               weather_flag = 3;
else if (w_id > 800 && w_id < 900)  weather_flag = 1;
else                                weather_flag = 0;

That keeps the UI simple and readable. A small display benefits from a tight icon vocabulary.

7. Draw the layout explicitly

The UI code uses fixed positions for each field.

snprintf(buffer, sizeof(buffer), "%s F", temperature.c_str());
EPD_ShowString(53, 171, buffer, 48, BLACK);

snprintf(buffer, sizeof(buffer), "%s%%", humidity.c_str());
EPD_ShowString(290, 171, buffer, 48, BLACK);

snprintf(buffer, sizeof(buffer), "%s mph", wind_speed.c_str());
EPD_ShowString(54, 273, buffer, 16, BLACK);

snprintf(buffer, sizeof(buffer), "%s miles", visibility.c_str());
EPD_ShowString(320, 273, buffer, 16, BLACK);

This solves the hierarchy problem cleanly: temperature gets the most weight, supporting values stay visible, and the panel works as a glanceable screen for a door, kitchen, or workshop.

8. Sleep after every refresh

The main loop ends the way a project like this should.

js_analysis();
UI_weather_forecast();

uint64_t sleepTimeUs = UPDATE_INTERVAL_MINUTES * 60ULL * 1000000ULL;
esp_sleep_enable_timer_wakeup(sleepTimeUs);
esp_deep_sleep_start();

That power model is a big part of the project’s engineering fit. The ESP32 wakes, does one cycle of useful work, updates the screen, and goes quiet again.

One more implementation detail worth keeping in view

The HTTPS helper uses WiFiClientSecure with setInsecure():

WiFiClientSecure client;
client.setInsecure();
HTTPClient http;
http.begin(client, serverName);
httpResponseCode = http.GET();

That keeps the networking code short and straightforward on an ESP32. It also marks the next engineering pass clearly: stronger certificate validation and safer secret handling.

This repo is valuable because it gives you a working pattern you can actually extend. Keep the fixed-location model, the compact One Call request, the retry loop, and the fetch-render-sleep cycle. Then tighten the security path, revisit the wind-speed conversion, and decide whether alerts belong on the screen for your own geography.

The real problem in synthetic image work is continuity under revision. What matters is object persistence, spatial relationships, lighting logic, material rules, character identity, and memory across iterations. A camera does not manage those things. A production does. Someone has to decide what the room is made of, what color the hallway light should be, whether the same jacket still exists in frame four, whether the poster on the wall belongs to this world or drifted in from another one, and whether the machine on the desk is still the same machine after the angle changes.

A simple thought experiment makes the distinction obvious. Imagine an illustrated essay, a short motion package, or a product explainer that needs twelve related images. The goal is not twelve individually impressive pictures. The goal is twelve pictures that belong to the same visual civilization. The hallway in image eight should feel like it belongs to the building from image two. The object on the desk should not become a different species every time the camera “moves.” The mood can evolve, but the world has to hold. That is not a photography problem. It is a coordination problem.

This is why so many image-model interfaces feel stronger in the demo than in the workflow. The demo optimizes for the first gasp: a striking frame, a clever style transfer, a photoreal face conjured from nowhere. Real work begins one minute later, when someone asks for three more versions that keep the same object logic, or a wider scene that preserves the same spatial relationships, or a new composition that still looks like it came from the same campaign. At that point the system is not being graded as a camera. It is being graded as a department with continuity problems.

That also explains why prompt discourse so often turns into a dead end. Prompting matters, but it matters the way a note to an art department matters: as direction, not as total control. If the whole workflow still depends on one perfect paragraph typed into a blank box, the system is being asked to behave like a magic lens. Serious visual work needs reference sheets, character bibles, locked palettes, prop lists, texture rules, approved assets, and revision memory. The useful systems will be the ones that help teams manage those ingredients across time instead of restarting from a clean-room miracle on every generation.

This should change product design. The default interface for image generation should not be an empty prompt box plus infinite retries. It should look more like a continuity bench. Show the character sheet. Show the approved materials. Show the forbidden drift. Let users pin an object so it persists across scenes. Let them compare variants against a world-state baseline instead of against pure vibes. Expose lineage, not just outputs. A good system should help a team say: keep the concrete texture, lose the chrome rail, preserve the red transit icon, do not let the skyline drift into generic luxury sludge.

None of this makes image models cameras, and it does not make them substitutes for documentary or evidentiary photography. A documentary image is constrained by a scene that existed and can be testified to, checked, or disputed as a record. A synthetic image workflow is doing something else: maintaining an invented world well enough that it survives revision. That distinction matters, and keeping it clear makes the argument stronger, not weaker.

Once that boundary is clear, the replacement argument gets less theatrical and more useful. Image models will absorb some tasks that used to require photography, illustration, rendering, or compositing. But their most interesting role is not as fake cameras. It is as synthetic production partners for people who need worlds, not just frames. They are valuable when the job is visual logistics, coherence, and iteration at a speed most teams would struggle to match by hand.

The strongest systems, then, will not win by pretending to be perfect cameras. They will win by becoming reliable art departments with memory. The real magic is not that they can make one beautiful image from a sentence. It is that they can help build a visual world on purpose, keep it coherent under revision, and make every later frame cheaper because the world already has rules.

The first step is to make sure you have Windows Subsystem for Linux installed.

Open settings on Windows 10 and select Apps:

From there make sure you are in Apps & Features:

Scroll to the bottom and select the related settings:

Once the Programs and Features windows opens, on the left hand pane choose “Turn Windows features on or off”:

That will bring up a dialog that allows you to select Windows Subsystems for Linux.

Once selected and you hit ok, you will need to reboot.

Once you log back in, open the Microsoft Store, search for Ubuntu and install it.

Once Ubuntu is installed, you can open the application and assign a username and password for your use. The user will have ‘sudo’ access so you can update and run application as a super user in the Ubuntu environment.

When the setup completes type ‘cd’ to move into your home directory

cd

Now update the environment before beginning:

sudo apt update && sudo apt upgrade

We will install a few pre-requisites before beginning:

sudo apt install python3
sudo apt install python3-distutils
sudo apt install wget
sudo apt install unzip

Once updates are complete and the pre-requisites are installed, we can begin installing platformio.

We will start with downloading the platformio.

wget https://raw.githubusercontent.com/platformio/platformio-core-installer/master/get-platformio.py -O get-platformio.py

Once it downloads, we can install it with python.

python3 get-platformio.py

After that installs, we need to update the $PATH variable to find the platformio /bin directory. To do that and make it permanent, we will modify your .profile.

vi .profile

Move to the bottom of the .profile file and add this line:

PATH="~/.platformio/penv/bin:$PATH"

Now you can logout of the Ubuntu environment and log back in to add that path os simply type this command:

source .profile

That will tell your current shell to update the $PATH variable.

Now you should be able to type ‘platformio” on the command line and it will work without specifying a full path.

Let’s download Marlin and build it real quick.

Either copy your Marlin working folder to the home directory you are working in or get a new copy from the Marlin github:

wget https://github.com/MarlinFirmware/Marlin/archive/2.0.x.zip

From here you need to modify your build files and your platformio.ini that are specific to your board. See the instructions for your board vendor.

I am building today for a BigtreeTech SKR Mini E3 so my build commands will reflect that board below. Please substitute your correct board.

After you have made the recommended changes to the Marlin folder for your specific board, you can clean and build the environment.

To clean the environment:

platformio run -s --target clean -e STM32F103RC_bigtree (or your specific board that you set in the platformio.ini file)

To build the environment:

platformio run -s -e STM32F103RC_bigtree (or your specific board that you set in the platformio.ini file)

Remember once the build is done, your firmware bin file can be found in the ~/Marlin/.pio/build/YOURSPECIFICBOARDfirmware.bin

Place that .bin file on your SD card and reboot your 3D printer. You can also upload that file to many types of 3D printers over Octoprint.

Mastodon

/dev/nvme1n1 -> GPT

/dev/nvme1n1p1 -> Windows Recovery (NTFS)

/dev/nvme1n1p2 -> EFI System Partition (vfat)

/dev/nvme1n1p3 -> Microsoft reserved partition

/dev/nvme1n1p4 -> Windows 10 Install (NTFS)

/dev/nvme1n1p5 -> Ubuntu Install (ext4)

This was a 512GB NVME drive. Windows and Linux each had roughly 256GB of space, not enough for either really. The windows install was mainly for the occasional gaming session and the linux install was my main work environment. To fix this major problem, I purchased a 1 TB PCI NVME drive for the linux install.

Now I had a problem, how do I move my perfect setup without messing it up. Here’s how I did it.

Install the new NVME or hard drive or SSD. Now get started.

First get a Ubuntu live boot CD. If you have a Ubuntu 18.10 USB key or CD you are all set. Boot up into the live environment, not the install option.

Open a terminal.

Type:

sudo blkid

This should provide a list of the block devices on you system

You should see your original disk. Mine was /dev/nvme1* (n1p1, p2, p3, p4, p5, etc.). You should also see your new disk. My new disk was /dev/nvme0.

Make sure you are clear on which disk is new. Use fdisk to create a new partition on the new disk.

fdisk /dev/nvme0

Type ‘n’ to create a new primary partition. The defaults should create a partition that fills the new disk. If you want to delve deeper in the commands for fdisk check out: https://www.tldp.org/HOWTO/Partition/fdisk_partitioning.html

Once you have the partition created type ‘w’ to write it to disk. If you issue the ‘sudo blkid’ command again you should see your new partition. In my case the new partition was ‘/dev/nvme0n1p1’.

Now mount the old partition and the new partition.

To do this type

sudo mkdir /mnt/old

sudo mkdir /mnt/new

sudo mount /dev/nvme1n1p5 /mnt/old

sudo mount /dev/nvme0n1p1 /mnt/new

Now we need to copy the data from the old disk to the new disk. Keep in mind that in my case I had a single partition that kept ‘/’, ‘/boot’, and ‘/home’. If you have separate partitions for those directories then you will need to wither create the same format on your new drive or collapse them onto the single partition during the copy process.

To copy the data do this (preserving permission and owners):

cp -av /mnt/old/.* /mnt/new/

I use the ‘-v’ option so I can check the stream of what is being copied. It may slow down the copy since you are waiting on terminal character buffers in some cases.

Now, you can reboot into the old environment and it is time to update ‘grub’ so your system will boot into the new environment.

Once you are logged into your old environment lets update ‘grub’.

Remember, in my scenario /dev/nvme0 is the new disk, /dev/nvme0n1p1 is the new environment, and /dev/nvme1n1p5 is the old environment.

First let mount the new partition:

sudo mkdir /mnt/new

sudo mount /dev/nvme0n1p1 /mnt/new

Now we need to mount the efi partition that we identified back in the first steps.

sudo mount /dev/nvme1n1p2 /mnt/new/boot/efi

The efi partition will be important later.

Now mount using the ‘-B’ option to bind the following filesystem into the new environment ‘/proc’, ‘/dev’, ‘/dev/pts’, and ‘/sys’.

mount -B /proc /mnt/new/proc

mount -B /dev /mnt/new/dev

mount -B /dev/pts /mnt/new/dev/pts

mount -B /sys /mnt/new/sys

Ok, time for the magic. Chroot into the new environment.

sudo chroot /mnt/new

In the new environment you will run this command to update and install grub on your original volume since you want to keep that grub install.

sudo update-grub

sudo grub-install /dev/nvme1

Remember /dev/nvme1 was my original disk and I did not want to change the grub location.

Now you can reboot into the new environment.

After you validate the update you can delete the old install. I did this by booting into my windows environment and deleting the old install and expanding the window partition back to it’s full 512GB glory.

Installing Kubuntu / Ubuntu on the Alienware 17 R5 Laptop NVME Drive

To get the NVME drive or M.2 drive to show up as an installation candidate for the installer, you need to make a small BIOS change and modify two kernel arguments at boot time.

First, boot into the BIOS on the AW 17 R5. To do this, press F2 when booting up.

Change the SATA setting in the BIOS from RAID to AHCI. Save and exit.

Reboot and press F12 to select the boot disk image. I used a spare USB key as the boot image.

Based on the information from the link below, I needed to load the NVME driver to recognize my M2 drive. To do this I need to follow two steps.

1. Wait until the UEFI/BIOS has finished loading, or has almost finished. (During this time you will probably see a logo of your computer manufacturer.) Note: UEFI fast boot may be to fast to give time to press any key.
2. With BIOS, quickly press and hold the Shift key, which will bring up the GNU GRUB menu. (If you see the Kbuntu logo, you’ve missed the point where you can enter the GRUB menu.) With UEFI press (perhaps several times) the Escape key to get grub menu.

Now that you are in the grub menu, you can edit the kernel parameters. Press ‘e’ to edit the kernel parameters.

At the end of the line containing the “quiet splash —” option, add “nvme_load=YES” and remove “quiet splash —“.

Press ctrl-X to accept the change and boot into the installer as normal. You should see the NVME drive as an option for installation.

Link information:

https://www.dell.com/support/article/us/en/04/sln299303/loading-ubuntu-on-systems-using-pcie-m2-drives?lang=en

Installation Notes

Do not encrypt, or at least know how to proceed

During the install, do not choose to encrypt the filesystem. For some reason I cannot fix yet, the password screen is loaded but not visible after a reboot. I can type the password to decrypt the file system as normal, but the process is not visible. After I type the password and press enter, the reboot proceeds and I load into SDDM to select my user and enter my account password.

Use a USB Mouse

Also, during the install you will need to use a USB mouse. The trackpad will not work reliably until we make a few changes post install.

Post Installation

Fix the trackpad

We can fix the trackpad drivers after the install by following the instructions below.

Open a terminal window and type the commands below:

sudo su
echo 'blacklist i2c_hid' >> /etc/modprobe.d/blacklist.conf
depmod -a
update-initramfs -u

More detail is available from this link:

https://fzheng.me/2017/05/11/fix-touchpad-ubuntu-1604/

Fix the Media Keys (X-5 on the left hand side of your keyboard)

sudo vi /etc/init.d/keyremap

Put this text in that file:

sudo setkeycodes e011 146
sudo setkeycodes e012 148
sudo setkeycodes e013 204
sudo setkeycodes e014 203
sudo setkeycodes e015 149
sudo setkeycodes e016 184

Save and quit that file.

Then make it executable.

sudo chmod a+x /etc/init.d/keyremap

Next step.

sudo vi ~/.Xmodmap

Put this text in that file:

keycode 154 = XF86Launch0
keycode 156 = XF86Launch1
keycode 157 = XF86Launch2
keycode 211 = XF86Launch3
keycode 212 = XF86Launch4
keycode 172 = XF86Launch5

Save and quit that file.

No create a script you can run on startup. I have a long startup script that sets several items. How you run the startup script is up to you, but put these lines of text in there:

# Run the remap key commands for the Alienware Macro keys
/etc/init.d/keyremap
sudo xmodmap ~/.Xmodmap

Save and exit the startup scripts

chmod a+x your startup script and ./yourstartupscriptname

Install NVIDIA Drivers

Installation of the NVIDIA drivers work like normal on Kubuntu/Ubuntu.

Open a terminal window and type the commands below:

ubuntu-drivers devices
sudo ubuntu-drivers autoinstall

The output should look similar to the information below, except I did not need to install the drivers:

rich@PortableServer:~$ ubuntu-drivers devices
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd00001BE1sv00001028sd0000088Cbc03sc00i00
vendor   : NVIDIA Corporation
model    : GP104M [GeForce GTX 1070 Mobile]
driver   : nvidia-driver-390 - distro non-free recommended
driver   : xserver-xorg-video-nouveau - distro free builtin

rich@PortableServer:~$ sudo ubuntu-drivers autoinstall
[sudo] password for rich: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

That should install the correct NVIDIA drivers and they will be active after a reboot.

I’ve recently been looking at building instruments using a 3D printer. I’ve been playing the guitar for over 40 years but most of the builds for 3D printed guitars seemed a little daunting as a place to start.

I found a couple of 3D printed ukuleles that looked like quicker one day builds. I finally settled on chuckbobuck’s soprano ukulele found on Thingiverse.

I built a few to get started and found that instead of the friction tuning pegs used for his design, I wanted geared tuners. I originally used a drill to widen the mount points for the geared tuners, but that weakened the mount points. Once I had decided on the size of the new holes, I modified the left and right ukulele halves with larger, reinforced mounting holes. I have liked the original design, download those STLS, and then I linked my modified parts.

The parts list and STLs are linked below.

Parts List:

Ukulele Tuning Pegs: https://amzn.to/2zTJpqI or https://amzn.to/2Oz734f

Soprano Ukulele Strings: https://amzn.to/2pD2kAd

M6 x 1MM Hex Lock Nuts: https://amzn.to/2C1PsLE

M6 x 35MM Bolts: https://amzn.to/2BWrXU5

#6 x 1/2″ Flat Head Wood Screw: https://amzn.to/2pBSMWa

M6 x 75MM Bolt (Acts as a Truss): https://amzn.to/2BX1IN8

Ukulele Strap: https://amzn.to/2Pd2qtt

Download the STLs:

Original design: https://www.thingiverse.com/thing:1367923

Modified for geared tuning pegs: https://www.printables.com/model/19731-modified-ukulele

This is not super detailed but it should get the job done.

Grad the 64-bit version of the Arduino IDE (or the 32-bit version if you absolutely need it).

Open a terminal and let’s do a few things.

Uncompress the software (cd to your Downloads directory) using ark:

ark arduino-*-linux64.tar.xz

I moved the resulting folder to /opt so it would not litter up my home directory. You will likely need to use sudo.

sudo mv arduino-*/ /opt/

Since we will be working out of that directory now, let’s move into it.

cd /opt/arduino*/

Again, we will leverage sudo to get this installed. Run the install.sh script.

sudo ./install.sh

Once the script completes you should have a new electronics category in your Applications menu with the Arduino IDE.

Open the IDE and make sure it opens appropriately. You are not ready to compile and upload to your board yet. We have a few more steps.

Open the preferences in the Arduino IDE (File -> Preferences). Here you can modify the interface scale to make sure you easily read the screen and code.

Now close the IDE and let’s make sure you can write out across the USB serial line.

Open a terminal again and let’s look at a few things. First notice that your home directory now has an Arduino directory. Inside that directory is the libraries directory. That is where you put your downloaded arduino libraries if you need to download any. That is outside the scope of this document, but now you know where they go.

You should connect via /dev/ttyUSB0 (or 1 or 2, etc.). To make the Arduino IDE work, we will need to add your user to the dialout group and make sure you can read and write to /dev/ttyUSB0. Here are the commands to do accomplish those tasks.

sudo usermod -a -G dialout $USER

sudo chmod a+rw /dev/ttyUSB0

Now reopen your Arduino IDE and compile a sketch. Yuu should be able to write it to your board.