There is quite a bit of misunderstanding with different “Virtual Private Server” implementations. I figured I’d go ahead and qualify the differences for those who might be interested, in the least technical way possible, for those who just want to pay for a service and get on with their lives..

OVZ: This is one of the most common VPS offers- its’ Linux only, and you are generally stuck with an old 2.6 based kernel, as it runs your process as a sub-process beneath the host kernel. The hardware isn’t completely virtualized, and usually that is oversold. This means that your 250GB storage may run out of space when you’ve only got 40GB used, or your 8GB plan chokes with systemd’s latest ‘adding the world’ process due to a “noisy neighbor” on the same node. These are generally the cheapest offer from any provider, as the service is commonly oversold. If you don’t have much to spend, or care about building your own system- this is probably where you will want to start. Have I mentioned yet enough that this is commonly oversold?

LXC: This is a slightly different ideology than OVZ – it works more like a chroot, or in the BSD world, a “jail”. It’s not as limited as OVZ, but still locked to the same Linux based hosting. This isn’t the most common form of “stuck on Linux” hosting OVZ, but does have several advantages. LXD is a slightly more advanced container of LXC. LXE does not yet exist, LXZ is a wheel (or possibly a capacitor), and LEDE has nothing to do with it (but is awesome, regardless).

KVM: KVM is considered one of the more preferable virtualizations, as it is not commonly possible to oversell RAM-it’s directly dedicated to the vitual host process, the hardware emulation is tolerable (if sometimes slow, when not using VirtIO), and you’re not stuck with the host kernel- or even host operating system. KVM is most commonly utilized for people who want a “true” virtual machine experience, as the x86 emulation has it’s own EFI/BIOS, and so forth. It can be slow, and with it’s resource uses, is usually the most expensive option for a virtual service.

Bare Metal (Lower End): This isn’t a virtual service at all! This is usually a piece of hardware that was awesome a few years ago, but is no longer all that great. I like to use WSI for this example. If you click that link, you’ll see Atoms, Core2Duos, older AMD processors, et al. This means you have access to the entire machine to yourself- but you may be stuck with whatever they offer. I have service with WHS, but there is no console access, and they won’t do basic troubleshooting for you- if you break it, you get to keep both pieces. This is often priced similarly to higher-end KVMs, as the resources offered are similar- but it’s not a shared resource at all.

I’ve tried to place these offers in not only expense, but ones’ general gravitation as their inner SysAdmin takes over.

If any of your are unhappy with the recalls only being performed by the few remaining SAAB/GM shops, you may wish to call (800) 955-9007, and dial 5#.

Then, politely tell the representative that this is a hardship due to time/fuel (my nearest shop is over 150 miles away), or if you are disabled and lack the ability to do so.

They’re keeping a list of those of us who don’t have the means to drive 3+ hours for a simple airbag module replacement, and claim that there might be something done in the future.

There was a reason Al Gore not only invented global warming, but the internet- and it doesn’t ONLY have to do with greed!

This. This is why the Internet exists.

I don’t have much to offer today- the weather has been awful, and I haven’t got much accomplished. So, have a tip for obtaining a list of local Linux device names which I did to simplify my own life:

%ip link | awk '/^[0-9]/ {print $2}'

This will give you a list of your network devices from Linux’ iproute2, in a similar fashion:

lo:
enp0s25:
wlp2s0:
virbr0:
virbr0-nic:

I use this with simple logic to obtain a local device name when I’ve done a Linux installation through a virtual terminal which replaces the current system (generally through QEMU), and the device names are not static, or even similar. There are ways around this, but considering I only need to use this once per system, it’s a welcome addition to my daily “spin up” regiment.

While trying to find an LEDE (OpenWRT) 802.11ac supported device, I stumbled upon the FS-WR106. After a bit of back and forth with their representative, I ended up acquiring one unit for testing.

It came preloaded with OpenWRT 14.07, which is old. They were kind enough to send me a build based around 15.05 (not 15.05.1), and it’s stable, but it’s a no-frills build with no enhancements- other than a slightly modified graphic for the router’s name- MediaTek OpenWRT.

As of yesterday, Jiawei Wang’s build for the ZBT-WE1326 were pulled into LEDE’s trunk. Yesterday.

There are minor bugs with this build- the GPIO pins are unknown for the LEDs, and the power light is not controllable at this time.

However, it’s not the right image. The ZBT-WG3526 (16MB) squashfs layout is what is current on this device:

[    2.230000] spi-mt7621 1e000b00.spi: sys_freq: 50000000
[    2.230000] m25p80 spi32766.0: w25q128 (16384 Kbytes)
[    2.240000] m25p80 spi32766.0: using chunked io
[    2.240000] 4 ofpart partitions found on MTD device spi32766.0
[    2.250000] Creating 4 MTD partitions on "spi32766.0":
[    2.260000] 0x000000000000-0x000000030000 : "u-boot"
[    2.260000] 0x000000030000-0x000000040000 : "u-boot-env"
[    2.270000] 0x000000040000-0x000000050000 : "factory"
[    2.270000] 0x000000050000-0x000002000000 : "firmware"
[    2.280000] mtd: partition "firmware" extends beyond the end of device "spi3
2766.0" -- size truncated to 0xfb0000
[    2.320000] 2 uimage-fw partitions found on MTD device firmware
[    2.330000] 0x000000050000-0x00000017e12e : "kernel"
[    2.330000] 0x00000017e12e-0x000001000000 : "rootfs"
[    2.340000] mtd: device 5 (rootfs) set to be root filesystem
[    2.340000] 1 squashfs-split partitions found on MTD device rootfs
[    2.350000] 0x0000006a0000-0x000001000000 : "rootfs_data"
[    2.360000] netif_napi_add() called with weight 128 on device eth%d
[    2.370000] change HW-TRAP to 0x17ccf

Also, I’m still having a wireless issue with this LEDE build, even though it claims I am in -HEAD, rather than 17.01.1. Need to do more research on this:

[   11.640000] firmware init done
[   11.810000] ------------[ cut here ]------------
[   11.810000] WARNING: CPU: 3 PID: 496 at compat-wireless-2017-01-31/net/wireless/core.c:763 wiphy_register+0x58/0x6c4 [cfg80211]()
[   11.820000] Modules linked in: mt7603e(+) ledtrig_usbport mt76 mac80211 cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables mmc_block mtk_sd mmc_core leds_gpio xhci_mtk xhci_plat_hcd xhci_pci xhci_hcd ahci libahci libata sd_mod scsi_mod gpio_button_hotplug usbcore nls_base usb_common
[   11.850000] CPU: 3 PID: 496 Comm: kmodloader Not tainted 4.4.61 #0
[   11.860000] Stack : 00000000 00000000 804c6862 00000036 00000000 00000000 80470000 804e0000
[   11.860000] 	  8fd023ec 8046dc83 803e8be4 00000003 000001f0 804c367c 00000003 8f7f4b78
[   11.860000] 	  8f7f52c8 80063fb8 80470000 804e0000 804721c8 804721cc 803ed50c 8f72fa34
[   11.860000] 	  00000003 80061d04 00000003 8f7f4b78 8f7f52c8 00000000 00000000 0072fa34
[   11.860000] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   11.860000] 	  ...
[   11.900000] Call Trace:
[   11.900000] [<80016844>] show_stack+0x50/0x84

Ah well.. back to the drawing board. I’ll mess with this later.