that "hello world" is still shorter than this ludicrous thing

acorn 6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-5 (https://bugs.debian.org/940708)

— Jon

I agree that low popcon alone should not be a reason to remove a well-maintained package.

The unfortunate reality though is that many packages in Debian are not well-maintained. They are kept on life support by rc bug squashers and by the people whose progress they are blocking. Ultimately a decision has to be made which packages are worth keeping on life support and which are not.

Popcon isn't a great tool, but it's about the best we can have while keeping to our principles.

I read this with interest as it's pretty relevant for my situation, but with a totally different climate. In Crete we have a problem with power cuts, but even though it's a dry climate we have a stable water supply. Also we run a co-op of a few of us to pump well water for irrigation, into our own tanks. This seems a ideal case to intermittently pump using solar power, since we get so much sunshine. Also the lowest recorded temperature here is 0.8C so no worries about frost damage.

Dave

If i just switch off ports via uhubctl and not bother removing the /dev nodes for it, then something in the system will later access the /dev node, which leads to I/O error, removal of the dev node from the file system, but also in powering on the port again and then recreation of the dev nodes. Aka: not good to ensure that ports will be powered off reliably. For example on my system, udisksd itself wakes up disks something like every 10 minutes for SMART check.

When using udevadm or any other tool to just remove the /dev nodes, then the risk of unintentionally powering up the port/disk still exists when there are any appliation with still open files to the dev nodes i think. Worse yet, when all dev nodes are removed and one wants to power the port up again with uhubctl, then the system will not recreate the dev nodes - because the kernel never saw the disk to have gone away. Only the dev nodes where removed.

udiskctl actually does the correct job: It removes the kernel notion of the disk, which then removes the dev nodes. Example:

udisks-Message: 22:56:40.318: Successfully sent SCSI command SYNCHRONIZE CACHE to /dev/sdd udisks-Message: 22:56:41.088: Successfully sent SCSI command START STOP UNIT to /dev/sdd udisks-Message: 22:56:41.174: Powered off /dev/sdd - successfully wrote to sysfs path /sys/devices/pci0000:00/0000:00:08.1/0000:38:00.4/usb6/6-1/6-1.3/6-1.3.1/remove

So the correct solution for me is to use udiskctl to remove dev nodes, then power down port with uhubctl. After powering up with uhubctl the kernel will correctly recreate the dev nodes. And in between, the only remaining risk for unintentionally waking up the disk is anything in the kernel resestting the whole hub.

The water pump will be shut off and drained to winterize and probably only run a couple of times over the winter to refill tanks. I may eventually automate that with an arduino, temp sensor, and a couple of servos.

The water tanks are unlikely to get more than a few inches of ice in them over a winter, which will not damage them, and I'm also going to paint them black to maximize solar heating. (And prevent algae growth.)

My main concern is the buried line back to the house, which is on the marginal side of deep enough for this area, but probably deep enough.

That's an impressive project!

Curious, what happens in the winter? Is it warm enough there that the tanks & lines don't freeze, or does it all have to be drained?

out of curiosity how much solar do you have installed (how many 100w panels)

also I noticed that the panel looked cracked, are you putting this in series with the other panels? This might reduce your yield by quite a lot.

Nice write-up by the way.

Hi joeyh,

thanks for expressing that; maybe this will have some weight.

Despite initial reluctance, I adopted dh for some of my packages, but I still wish to have the flexibility to not use it (sometimes, a rules file with dh is longer and more complex than one without, due to the need for too many overrides; sometimes, buildsystem detection works against you, etc.), let alone the idea of being forced to use something turns me off of things.

Being able to choose is good. (No matter what some people say about this not being about choice, I disagree there.) Monocultures have inherent problems.

[Disclosure: I wrote sshdo which is described below]

There's a program called sshdo for doing this. It controls which commands may be executed via incoming ssh connections. It's available for download at:

http://raf.org/sshdo/ (read manual pages here)
https://github.com/raforg/sshdo/

It has a training mode to allow all commands that are attempted, and a --learn option to produce the configuration needed to allow learned commands permanently. Then training mode can be turned off and any other commands will not be executed.

It also has an --unlearn option to stop allowing commands that are no longer in use so as to maintain strict least privilege as requirements change over time.

It is very fussy about what it allows. It won't allow a command with any arguments. Only complete shell commands can be allowed.

But it does support simple patterns to represent similar commands that vary only in the digits that appear on the command line (e.g. sequence numbers or date/time stamps).

It's like a firewall or whitelisting control for ssh commands.

I've had a negative Amazon review removed because the seller reported my review. I was able to submit a new review that was not removed, after contacting Amazon support. Also, when I contacted Amazon support they explained why my review had been removed, which I found very helpful. Here's what Amazon support said:

Hello Nathan,

I apologize for the confusion you experienced in this case.​

We encourage customer content on the Amazon.com website, both positive and negative.

However, your recent contribution doesn't comply with our content guidelines.
Specifically, your contribution contains comments related to the seller and not the product itself.

I'd recommend submitting your review again, restricting your comments to the item. For your convenience, I've included your original Review below:

The battery I received did not work at all. I returned it for refund. The seller was responsive, and offered me $10 to remove my bad review. 

Please take a look at our Community Guidelines for information about acceptable content:

https://www.amazon.com/gp/help/customer/display.html?nodeId=201929730

If you'd like to leave feedback for the seller you ordered from, visit this page:

http://www.amazon.com/feedback

I hope this helps!

Best regards,
Alice Y.

Note my original review from above:

The battery I received did not work at all. I returned it for refund. The seller was responsive, and offered me $10 to remove my bad review.

I feel that mentioning the seller in this way was very relevant, but I guess Amazon disagrees. The positive reviews also mentioned the seller, but of course the seller didn't complain about those. I then asked Amazon about the double standard but they ignored me:

Hi Alice,

Thanks for explaining that my review was rejected because I mentioned
something about the seller. However, notice that these other two
reviews of the same product also talk about the seller:

https://www.amazon.com/gp/customer-reviews/R1SUR5G7FDAO80/ref=cm_cr_dp_d_rvw_ttl?ie=UTF8&ASIN=B01I1IY1SY

https://www.amazon.com/gp/customer-reviews/R3GVDST5W3UDEM/ref=cm_cr_dp_d_rvw_ttl?ie=UTF8&ASIN=B01I1IY1SY

Why are these reviews allowed and mine is not?

But at least they didn't remove my updated review:

The battery I received did not work at all.

Maybe you could contact Amazon support and find out what technicality allowed the seller to have your review removed?

I would allow for a battery on a timer that would run the refrigerator for a minute after opening and closing it. Or a mechanical timer that one'd manually set after use.

Would at least deal with humidity, and stabilize temperature somewhat.

Hi Joey,

For your next off-grid fridge project, consider:

http://www.sciencemag.org/news/2017/02/cheap-plastic-film-cools-whatever-it-touches-10-c

I wonder if your comment tripped a spam filter, rather than a coverup? 'Google "keywords" for more' is a phrase I see in a lot of comment-spam I get where they're trying to avoid rules that quarantine comments with links in them by instead including carefully selected search keywords which will turn up only the target site.

Your information about censored Amazon review of Sandisk Ultra 32GB Micro SDHC Card is very helpful, thanks! You could get it much higher in search results with a search results optimization service, Google "Wolfgang's Amazing Search Trick" for more information.

The documentation (quoted below) is a bit vague about exactly what it does, but it seems like does more than just disabling the port and probably does better at flushing caches than just unmounting.

power-off Arranges for the drive to be safely removed and powered off. On the OS side this includes ensuring that no process is using the drive, then requesting that in-flight buffers and caches are committed to stable storage. The exact steps for powering off the drive depends on the drive itself and the interconnect used. For drives connected through USB, the effect is that the USB device will be deconfigured followed by disabling the upstream hub port it is connected to. Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives. As such there are not a lot of guarantees associated with performing this action. Usually the effect is that the drive disappears as if it was unplugged.

@pabs3, udisksctl power-off --block-device /dev/disk/by-label/passport does cause udev to remove the device file, it does not seem any better than udevadm trigger --action=remove in this situation though, because systemd has already unmounted the disk before that runs.

The only difference I notice is that it disconnects the hub port, but that leaves it powered on, so uhubctl is still needed to power off.

Unless it's better at getting caches flushed to the disk or something like that?