Nuclear, gas, coal, etc doesn't run out.

Tell that to Texas who "ran out" of natural gas during the last big freeze forcing multiple power plants to shutdown for several days. :)

All sources of power generation can run out. The trick is to diversify your power generation across multiple types of sources (nuclear, gas, solar, hydro, wind, tidal, etc) so that an outage in one source won't affect the overall grid. And interconnection between grids, between regions are also needed (again, see Texas for reason why).

And how are they going to know if you've unplugged them or not? The servers they communicate with are offline, so there's no remote way of knowing if the kiosks are still plugged in.

All the tap-to-pay terminals around here present a tip option first where you can choose a pre-set %, enter a custom %, enter a custom $ amount, or skip. It displays the new total, you click OK, and then tap the terminal to authorise the payment.

Signatures aren't required for anything payment related in Canada. Signatures are required for paper contracts.

Please don't lump Canada and Mexico in with the US when it comes to anything financial. :) They're a third world unto themselves when it comes to banking. Canada moved to chip+pin back in the 90s, and enabled NFC (tap) transactions in the early 2000s. (Not sure about Mexico, but considering how backward the US is, pretty much anything is more forward-looking.)

I mean, Americans think Apple invented tap-to-pay, which tells you a lot about how far behind they are in payment tech.

Prices at the pump are currently lower than they were prior to the new carbon tax increase coming online.

In BC, it's almost 20c/L less expensive now than in April.

In Alberta, it's only 5c less, but that's still lower.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fcharts.gasbuddy.com%2Fch...

Roku Premiere+ and Ultra models (the larger square boxes) support 100 Mbps Ethernet via built-in RJ45 ports.

The soundbar models also support Ethernet, albeit via a USB adapter.

It's only the Express, Streaming Stick, and similar models (the "sticks") that are wireless only. These are also the crappiest hardware in their lineup and should be avoided except as test setups.

Don't ever upgrade the firmware on that Samsung printer, especially if it's a laser printer.

Samsung makes awesome printers ... but their latest firmware updates (at least for the laser printers) lock them down to only using official Samsung toner cartridges.

Our ML-10 (I think that's the model number) is essentially a paperweight now. Samsung toner for it costs over a $100 CAD (regular capacity); the 3rd party ones we were using for years were around $50 CAD (high capacity).

Samsung is doing the same thing as HP. Had 2 different Samsung laser printers that worked beautifully for many years until the parts wore out in one. The replacement I made the mistake of doing a firmware upgrade (for security issues) that prevented it from working with non-Samsung toner cartridges. :( Seems the lastest firmware versions for Samsung laser printers require the little security chip in the toner cartridge to match.

We replaced them with a Brother HL-3170CDW, which has been running beautifully for a couple years now, using 3rd party toner cartridges. Had to replace the waster toner cartridge once ... seems we do a lot of printing here for school. :D

This year, we added an MFC-3710CDW colour copier/scanner/printer, also using 3rd party toner.

The Brother iPrint&Scan Android app and printer driver are also much nicer to work with than the Samsung app was. Scanning documents to your phone for easily sending via e-mail is great!

Tripwire: install system, run tripwire to get a checksum of every file on the system, save that somewhere immutable, run tripwire repeatedly and flag any files that have changed. But how do you compare the original file to the changed file to see what was changed?

ZFS: install system, take a snapshot. Take snapshots on a schedule. Run "zfs diff snap1 snap2" to get a list of all files that have changed between snapshots, and you can directly compare the two files using your normal tools (cd, ls, diff, cmp, etc).

You can even schedule sending of the snapshots to a remote server where you can run tripwire in the background if you really want. :)

Every time you read a file on ZFS, the checksum for all the blocks for that file are computed and compared to the checksums stored in the metadata for those blocks. If they are different, you know the file has been corrupted. If you have a redundant vdev (mirror, raidz), then it will read the "corrupt" block from the other disk (or compute the block using parity), and compute the checksum for that. If it matches the checksum in the metadata, then the corrected data is written out to the "bad" disk.

How is tripwire going to help with that?

Incorrect.

In the past (in the day prior to feature flags, so ZFS versions up to v28), if you filled a pool to 100%, you were pretty much screwed. You can't deleted files, as it wants to write metadata changes to the snapshots, but there's no space. You can't delete snapshots, as it has to write metadata to other snapshots, but there's no space. And so on. Sometimes, you can get lucky and find a filesystem without snapshots where you can delete files, or you can "cp /dev/null somefile" to truncate a file, to free up space.

Back then, the recommendation was to create an extra filesystem, and set the reservation to 1 MB or 10 MB or thereabouts. If the pool ever reaches 100% full, you could change the reservation on that extra filesystem to make space available to the pool so that you could delete snapshots.

Somewhere in the past few years, though, they added an internal "reserve X% of the pool" feature where a 100% full pool actually only uses 98% of the space, such that you can always delete snapshots.

Just like there used to be a requirement for replacement disks to have the exact same number of sectors (or the replacement needs to have more sectors) or the replacement would fail. Nowadays, ZFS reserves around 1 MB at the end of each disk for slack space, that can be reduced automatically to allow replacement of disks with different numbers of sectors.

From the sounds of it, there's been a lot of changes to ZFS since you last used it.

That's where something like rsync comes in. It's file-based, so it still needs to read every file in the filesystem and compare them to every file in the destination (so it can take awhile to run), but it only sends the data that changed within the file.

It's much, much, much slower than a ZFS snapshot send, as ZFS knows exactly which blocks are different (no read/compare needed) and only sends those blocks.

Both rely on an external transfer mechanism that can be tuned to the network (SSH if you need encryption, bbcp/netcat if you need raw throughput).

But using rsync on an LVM snapshot is the generic/standard way for "transferring" an LVM snapshot between systems.

The problem with LVM snapshots is that you have to specify a size for it at creation time, and there's a lot of extra IO involved (changed files are written to the snapshot first before being updated in the running filesystem). Screw up the size, and you'll actually lose changes when the snapshot fills up. And LVM isn't designed for keeping lots of snapshots around (can lead to cascading IO as you update files that exist in all the snapshots); it's more for the "snapshot, backup, destroy" workflow, where snapshots are temporary.

We tried using MD, LVM, ext4/XFS, hardlinks, reflinks, and rsync to make a backup server for our Linux and FreeBSD servers. We had a "workable" solution in place, but it was fragile, and still required copying data off to CD/DVD/tape for long-term storage. We wanted to keep 3-5 years of daily snapshots around for easy file recovery, and have an off-site replica, but ran into all kinds of issues with LVM (it's really not designed for that purpose).

ZFS made it "just work". We now have 3 backups servers running (1 for each "class" of remote site) each with 1 ZFS pool made up of 24-90 drives (in 6-disk raidz2 vdevs) depending on the server. Separate filesystems for each site. Separate directories for each server. rsync runs every night to backup the remote servers into their specific directory. ZFS snapshot taken every morning. That snapshot is sent to a remote/off-site ZFS server during the day (giving us 3 copies of all data; the server itself, the primary backup server, the off-site backup server).

We keep between 1-3 years of daily snapshots on the primary ZFS servers, and 5 years of daily backups on the off-site backup server. That way, we have quick and easy access to every file in every server using simple, normal filesystem commands (cd, ls, cp/mv/scp), and can restore an entire server from scratch using any day from the past X years.

We considered btrfs a few times, but the lack of working RAID5/6 and all the issues around running degraded arrays kept us away from it.

FreeBSD+ZFS has been working great for us for almost 12 years now.

No, it's not.

FreeBSD currently uses the OpenZFS repo for their ZFS implementation, which is based on the code from Illumos (which is a continuation of OpenSolaris). That's what was released with FreeBSD 7 through 12, and is still in the source tree for what will become FreeBSD 13.

The OpenZFS repo is in the process of migrating away from/ the Illumos repo and rebasing on the ZFS-on-Linux repo. OpenZFS has not "died out", nor is it going anywhere. Once the rebase is done, it'll still be OpenZFS.

Once the rebase is done, all the downstream consumers of OpenZFS will be brought into the OpenZFS repo under separate project directories, to provide 1 canonical, master repo for everything OpenZFS related.

iX Systems has an initial prototype port of ZoL-based OpenZFS (codenamed ZFS-on-FreeBSD aka ZoF) that people can test and play with (sysutils/openzfs and sysutils/openzfs-kmod). It's not up-to-date atm, and doesn't work on FreeBSD-CURRENT due to some changes in the kernel, but it should work on 12.x (not sure if it supports 11.x).

Once the OpenZFS repo rebase is done, there will be work done to update the FreeBSD implementation to use that, which might (no guarantees) make it into FreeBSD 13.0. They may also run parallel versions of ZFS in FreeBSB 13.0. Nothing has been set in stone as yet.

The Windows GUI has always prompted for a full reboot to update the network stack with any changes, even as trivial as the IP/netmask/gateway. However, it was never required. If you cancel the reboot prompt dialog, open a command prompt, and type "ipconfig /all", you'll see it has the new IP and everything already set.

And you could always just unplug/reconnect the network cable to force a reset of the network stack.

Saved a *lot* of time waiting around once I discovered those tricks. :)

We moved away from individual parking meters next to each parking stall to a single parking kiosk at each intersection. You enter your license plate into the kiosk, select how long you want to park, and pay with coins or credit card. There's also an iOS/Android app that lets you do it remotely, which is really handy if you pick too short of a time and need to feed the meter.

By-law officers wander around with little handheld devices, snapping pictures of license plates that get OCR'd and checked against the list of registered "parked cars". System flags the ones that have been parked too long, or where the time has expired, or haven't paid at all. The handheld then prints out a ticket.

Much less hardware in the field, less time needed by by-law to track issues. And they can even use car-mounted cameras for taking pictures of license plates. And it's easier for people to track their parking times (via the phone app).

However, outside of the metered parking stalls (meaning neighourhood street with 2 hour parking limits), they still wander around chalking tires as there's no central database to check against. I think they're looking into updating the parking handhelds they currently use to keep a database of license plates and times so they can track things that way, but not sure if that's been implemented yet.