DEV Community: Bob Nadler

VirtualBox 6.1.x Windows 10 2004 Upgrade Problem Resolution

Bob Nadler — Thu, 28 May 2020 22:08:13 +0000

Original post: Virtualbox 6.1.x Windows-10 2004 Upgrade Problem Resolution

This is just a quick note that will hopefully save someone time.

When I upgraded Windows 10 (64-bit) from 1909 to 2004 I found that Virtualbox 6.1.x no longer worked properly. All of my guest instances (Ubuntu, Mint, etc.) failed to start. Specifically, they just hung with a blinking cursor and there were no errors in the logs.

There were no reports on this problem on the VirtualBox on Windows Hosts forum.

It turns out that when Windows 10 2004 is installed it enables the Windows Hypervisor Platform feature.

To check this setting run OptionalFeatures.exe from a Windows command shell. You'll see this:

The resolution to the hang problem is to disable this feature. Doing this is simple:

Uncheck the Windows Hypervisor Platform checkbox (above).
Reboot. Even though it's not indicated when you do step #1, a reboot is required to disable the feature.

That's it!

Exploring Clojure (and FP vs OOP)

Bob Nadler — Tue, 29 Jan 2019 16:15:30 +0000

I’ve always viewed functional programming (FP) from afar, mostly because object-oriented programming (OOP) is the dominant development methodology I’ve been using (Java, Ruby, C#, etc.) for many years. A majority of the articles I’ve read on FP have statements like this:

If you’ve never tried functional programming development, I assure you that this is one of the best time investments you can make. You will not only learn a new programming language, but also a completely new way of thinking. A completely different paradigm.

Please read the entire article here: Exploring Clojure (and FP vs OOP)

Ubuntu 18.04 Upgrade Problem Resolutions

Bob Nadler — Sat, 18 Aug 2018 21:45:57 +0000

Original post: Ubuntu 18.04 Upgrade Problem Resolutions

I recently upgraded my 3-year-old Lenovo X1 Carbon from Ubuntu 16.04 TLS to 18.04 LTS. I think I ran into the two most common upgrade issues, and since both of them are show-stoppers, I thought it would be worth sharing the resolutions that worked for me.

Here are the two problems:

"Login Loop": After a valid authentication on the login screen, the display goes black momentarily, and then returns you to the login screen.
systemd-udevd CPU usage: On my system, it consumed about 20% of the CPU. I've read that it can be much higher on other systems (like 100%).

The Upgrade

Simple: From Software & Updates on the Updates tab, select 'For any new version':

After the next update, the Software Updater will offer the 18.04 upgrade option.

Just click on the Upgrade... button and follow the instructions from there.

Login Loop

After the upgrade is complete, this problem will prevent you from logging in to a Gnome desktop. Use Alt-Ctrl-F2 to drop to a terminal and login. Execute the following:

$ sudo apt-get purge gdm*
$ sudo apt-get purge lightdm
$ sudo apt-get install lightdm
$ sudo apt-get install nvidia-352

Just removing gdm and re-installing lightdm was not sufficient to resolve this issue for me. Installation of the Nvidia driver (line 4) was the key. Later versions than nvidia-352 (like nvidia-384) will also probably work.

systemd-udevd CPU Usage

Now that you can login to your desktop, you may notice high CPU usage. If top or htop show that systemd-udevd is the culprit, confirm that UDEV events are being generated with udevadm. For me the output looked like this:

$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[33.704228] add      /module/nvidia (module)
KERNEL[33.704784] add      /kernel/slab/:0012288 (slab)
KERNEL[33.705062] remove   /kernel/slab/:0012288 (slab)
UDEV  [33.705332] add      /kernel/slab/:0012288 (slab)
UDEV  [33.705659] remove   /kernel/slab/:0012288 (slab)
KERNEL[33.724214] remove   /module/nvidia (module)
KERNEL[33.755768] add      /module/nvidia (module)
KERNEL[33.756482] add      /kernel/slab/:0012288 (slab)
KERNEL[33.756764] remove   /kernel/slab/:0012288 (slab)
UDEV  [33.757642] add      /kernel/slab/:0012288 (slab)
UDEV  [33.757981] remove   /kernel/slab/:0012288 (slab)
KERNEL[33.772269] remove   /module/nvidia (module)
UDEV  [33.792191] add      /module/nvidia (module)
UDEV  [33.807097] remove   /module/nvidia (module)
KERNEL[33.830290] add      /module/nvidia (module)
...

This can be resolved by stopping the systemd-udevd service:

$ sudo systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket

The CPU usage will drop and udevadm stops reporting events.

If needed, the systemd-udevd service can be started again:

$ sudo systemctl start systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket

I found that the CPU issue did not re-appear after the service was restarted.

Startup Changes

This is great, but you don't want to have to manually run a command every time you log into your system. Here is how to execute this command automatically at startup.

First, you need to be able to execute the systemctl command as root without having to enter a password.

Create a script and set the correct permissions as follows:

$ echo 'systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket' > stop_systemd_udevd.sh
$ sudo chown root.root stop_systemd_udevd.sh
$ sudo chmod 4755 stop_systemd_udevd.sh

Next, run:

$ sudo visudo

and add the following line at the bottom (this is important) of the /etc/sudoers file.

bob ALL=(root) NOPASSWD: /home/bob/stop_systemd_udevd.sh

Of course, change bob and /home/bob as needed.

Now you should be able to run

$ sudo ./stop_systemd_udevd.sh

without being prompted for a password.

The last step is to add execution of this script when your system starts up. Use Startup Application Preferences and add the follow (change /home/bob, of course).

That should do it! Reboot your system and the systemd-udevd service should not be running.

Hope this helps. Enjoy!

Embedding Angular Components into a Legacy Web App

Bob Nadler — Wed, 25 Jul 2018 20:36:57 +0000

Original post: Embedding Angular Components into a Legacy Web App

Note: Code samples do not include line numbers in this version.

In a perfect world, you'd be able to create a greenfield Angular SPA from scratch. In the real world, that's usually not the case. That legacy web application has way too much baggage to realistically convert it to an SPA in a single shot. This is particularly true if you're currently using server-side rendering with (e.g.) JSP or Rails technology.

The only real solution is to incrementally move/upgrade pieces of UI logic and data access patterns (i.e. converting to REST interfaces). If you are planning a move to Angular*, a good starting point is to first embed small pieces of Angular-implemented logic into your existing application. This approach also allows the new Angular components to share CSS styles for seamless visual integration.

NgInterop is a simple TypeScript class that allows a legacy Web application to have two-way communications (via pub/sub) with embedded Angular components. The underlying MessagingSerivce class is an implementation of Message Bus pattern in Angular 2 and TypeScript.

Source code for the demo project is here: embedded-angular

NgInterop.ts

import {Injectable, NgZone} from '@angular/core';
import {AngularEvent, EventCallbackFunction, HtmlEvent, LogEvent} from './event.types';
import {MessagingService} from './messaging.service';

@Injectable({
  providedIn: 'root'
})
export class NgInterop {
  public static readonly ANGULAR_EVENT: string = 'AngularEvent';
  public static readonly HTML_EVENT: string = 'HtmlEvent';
  public static readonly LOG_EVENT: string = 'LogEvent';
  private typeClassMap: any = {};
  private readonly initCallback: any;

  constructor(private ngZone: NgZone, private messagingService: MessagingService) {
    this.typeClassMap[NgInterop.ANGULAR_EVENT] =  AngularEvent;
    this.typeClassMap[NgInterop.HTML_EVENT] =  HtmlEvent;
    this.typeClassMap[NgInterop.LOG_EVENT] =  LogEvent;
    this.initCallback = window['NgInteropInitCallback'];
    window['ngInterop'] = this;
    this.init();
  }
  private init() {
    if (!this.initCallback) {
      console.warn('NgInterop.init: No NgInteropInitCallback found!');
      return;
    }
    this.initCallback();
  }
  public subscribeToClass(className: string, callBack: EventCallbackFunction): any {
    const self = this;
    this.ngZone.run(() => {
      self.messagingService.of(self.typeClassMap[className]).subscribe(callBack);
    });
  }
  public publishToClass(className: string, source: string, value: string): any {
    const self = this;
    this.ngZone.run(() => {
      self.messagingService.publish(new self.typeClassMap[className](source, value));
    });
  }
}

Highlights:

6: Side note on the new Angular 6 providedIn syntax. This saves from having to add every service to the app.module.ts @NgModule providers list. Very handy!
19: This saves the native JavaScript initialization callback function (see index.html below). This example only has one callback function, but it would be easy to extend this functionality to support multiple initialization callbacks.
20: Add the NgInterop instance into the window object so that external JavaScript can simply call methods on window.ngInterop (again, see index.html below).
32 and 38: Wrap the MessagingService subscribe/publish in a NgZone.run() call. This allows the external JavaScript to execute these functions in the Angular zone.

Other notes:

The typeClassMap object maps a BaseEvent class name (string) to a real class. The public static *_EVENT names provide safer access to the NgInterop functions from the Angular code.
There's no way to do type or parameter checking on the native JavaScript side, but it is still good practice to strongly type the BaseEvent derived classes. This provides good documentation and catches problems early on the TypeScript side.

Here is the stripped down index.html that shows how the external JavaScript code interacts with NgInterop.

index.html (snippet)

<script>
  function subscribeToEvents() {
    ...
    window.ngInterop.subscribeToClass('AngularEvent', function (event) {
     ...
    });
  }
  ...
  function clickMe() {
    window.ngInterop.publishToClass('HtmlEvent', 'clickMe', getRandomString());
  }
  ...
  window['NgInteropInitCallback'] = subscribeToEvents;
</script>

Highlights:

4: After subscribeToEvents() is called by the NgInterop constructor, this function subscribes to AngularEvent messages. AngularEvent messages are published when the Angular 'Toggle Remove Button' is clicked in the AppComponent class.
10: On an HTML click event an HtmlEvent message is published. The subscriber to the HtmlEvent messages is also in the AppComponent class.
13: The callback function is added to the window object. This is executed prior to Angular being started up.
All logging is done by publishing LogEvent messages. These are displayed by the LogComponent class.

The example app has two Angular components that interact with the native JavaScript as well as with each other with NgInterop. The rest of the code should be self-explanatory.

Screenshot of the example app:

This project uses the following:

Angular CLI -- Of course.
RxJS -- Used by the MessagingService.
Bootstrap 4 -- For the pretty buttons and "card" layout.
Moment.js -- To more easily format the log timestamp.
Protractor -- For running the Angular e2e tests.

Enjoy!
*There are probably similar integration approaches for React and Vue. I just don't know what they are.

Should I accept a Linkedin connection request from a candidate we didn't hire?

Bob Nadler — Thu, 22 Mar 2018 18:27:36 +0000

The candidate wasn't bad but the consensus was thumbs down. There's always the possibility our paths will cross again in the future but for some reason accepting feels awkward.

What would you do?

Did you know that Google is an Evil Monopoly?

Bob Nadler — Sat, 10 Mar 2018 22:47:03 +0000

See: The Problem With Google And Why You Should Care

Reading the Medgadget article was a real wakeup call for me, but I suspect that most people do not realize that Google's behavior continues to have a significant impact on innovation and online content. This has been going on for a long time but still seems like a well-kept secret.

Questions:

For Google employees: Did you know you work for an Evil Monopoly?
For everyone else: Did you even know that Google was an Evil Monopoly?
Have you ever been directly affected by this (e.g. a failed startup)?