I bought this card in Korea some years ago after having seen this theme - a tiger and a rabbit seemingly getting stoned together - in a number of places. There must be a story behind it, but my meager search skills have never managed to turn it up. I do still love the image, though...
They informed me that a replacement system would be $700, seemingly including installation. It'll be a little while before I can generate enthusiasm for spending that money, certainly...
Some new form of SunPower resurrecting the current hardware would be nice. I'd say that the chances of them making it work again without demanding more money are pretty small, though. Such is the world we live in - we only *think* we own that device...
Rather than putting an rPi system in the box, though, I just ran the Ethernet cable to a system I had with both wireless and wired interfaces; the WiFi sits on the home net, while the wired interface does DHCP to get an address from the SunPower box, then polls it to get the data out.
Once that was set up, getting it into Home Assistant was mostly a matter of installing the integration. Figuring out which power signals belonged to which panel took a while; if you don't have it yet, use the SunPower app to make a map of the serial number for each panel and its location.
I'm debating whether to stick with this system, or to take up Enphase on its offer and swap out the SunPower box entirely. The Enphase monitor would be a supported product, and it seemingly has much better Home Assistant support.
Another reward was the SunPower monitoring system that lets us track the performance of the system and see how each individual panel is working. Naturally, this system only delivers its data to some proprietary cloud system run by SunPower. Just as naturally, SunPower has gone bankrupt, and the monitoring system is now just a useless brick sitting on the wall.
...or at least it would be, had I not gone through the effort of integrating it with Home Assistant — a mildly difficult task involving hooking into a maintenance port on the device itself. So now I have the data out of the monitoring box stored on a local system, under my control, and I don't need to go scrambling for alternatives. I can obsess over my post-solstice data, waiting for production to reach decent levels again — that happens faster if I stare at it, I'm convinced.
Maybe there's something to this free software idea after all.
@jani@neil Indeed, we have been doing LWN's accounting locally with GnuCash for the last two years now, and I've never looked back. The OFX import is pretty good for bringing in data if you want to do that, but I've just written a set of Python scripts to import data directly and easily.
I really can't imagine trusting such a critical function to somebody else's web platform, both for reliability reasons (as the Bench fiasco has so nicely illustrated) and for privacy reasons as well.
I picked up Anybody's Bike Book sometime around the mid 1970s, after having discovered the freedom that a good bike gives to a kid who needs to move around in northern Wyoming. It taught me that there was nothing in my bike that I couldn't fix myself — an empowering lesson to learn. With a mixture of plain language, clear descriptions, and sharp humor, it was perhaps my first example of what technical documentation can be.
So, a belated "thank you" to Tom Cuthbertson for this outstanding book; there is no doubt it had a strong influence on all the words I have inflicted on the world.
@KasTasMykolas You need to look at least long enough to know what names have been assigned to the form elements. It would take less than a minute, but you need to do it for every site you want to attack.
Because I'm an obnoxious person, I changed the names of those elements today, conveniently bringing an end to all of those login failures. We'll see if they bother to update their script...
These do not correspond to LWN accounts, but somebody has looked at our login form for long enough to post the login attempts directly, without loading the form first. The attempts come from all over the Internet, suggesting that some sort of botnet is doing this.
I don't suppose anybody else has seen this sort of pattern, or has any idea what it is that they may be trying to accomplish?
@larsmb@tante I think the point in question was highly visible enough.
Had that conversation been allowed to continue, it would have gone on for hundreds of posts, and brought people out of the woodwork that you really would rather not know even exist. We've been there in the past, and it threatened to kill the site at one point. Thus our "no personal attacks" policy, which we had to enforce here.
Should we, instead, have just pulled down the article, as some are saying? That would have "blocked the discussion" too, of course. We also try not to hide our mistakes.
Things like this make me wish I'd made a career in JavaScript framework development or some such. Now if you'll excuse me, I have some kernel drama to somehow deal with.
@davidgerard First, what "mask" do you think has come off?
Second: if you look hard, you still will not find either of us "defending her honor". Please do not put words in our mouths.
We did do our best to close down the conversation; what good comes from hundreds of posts of people throwing names at each other? There are enough posts criticizing the person involved for anybody to get the point; there are almost none in the other direction. Trust me that this would not have been the case had we let the conversation run. *That*, perhaps, indicates an editorial bias, but it is not the one you are accusing us of.
Look, as I posted in the thread, had we known the backstory of the person involved, there is a good chance we would not have run that article. We are a small operation, we lack a biographical research unit, we will not have a background file on any of the hundreds of developers we write about over the course of a year.
@krzk@jarkko I could certainly consider adding per-employer test and review stats. If so, they are likely to show up in KSDB (https://lwn.net/ksdb/) first; I need to get back into that code anyway...
@kernellogger@torvalds I am almost certainly the person who wrote those words. Yes, they could be improved... but note that the text talks about failing to *respond* to the regression, not the revert. That was surely the intent there, and I think it remains true.
@kernellogger@jann It's not just "unusual" that a cycle takes longer than 70 days, it has only happened twice in the last 15 years: 3.1 (slowed by the kernel.org compromise) and 4.15 (the meltdown/spectre release). It takes an event of that magnitude to slow things down at this point.
I'm not sure if we can realistically make the cycle shorter - some problems just take time to turn up and to be fixed.