FishFace

Ok, but a packet of peanuts costs a couple of bucks, so I think it sounds like a lot!

Idk what the commission has to do with it given the NIST investigation (and the others) which all point in the same direction.

Weird that you described this as "the official explanation"rather than, you know, “the explanation”

Or maybe it was expensive but recouped huge amounts due to enabling travel between the two countries, which facilitates all kinds of economic activity

My terminal with a comfortably large font, full screen at 1080p, has 238 columns. That should be enough to split screen 2x120 column editors for all but the very longest lines, and you have even more room if you reduce the font size a point or have a 1440p monitor.

Unburdened ebook stores that actually stock “everything” is a necessary component here.

For your first (long) journeys, definitely plan in advance. And don’t rely on searching at a certain SOC without scoping out the frequency of chargers on your route. Where I am, this would never be a disaster, but it may end up with having to take a long detour, or being stuck on a very slow charger to be able to make progress. I guess you’re in Germany, where I don’t know the situation - probably decent. But there will be less densely populated areas which may still cause issues. In North America there are major routes with no chargers for more than a hundred miles which then requires a lot of care.

What I’m just getting it is that this level of care is often not necessary once you’re familiar with an area. And then perhaps the impetus for OSS solutions is lowered.

Example here: https://stackoverflow.com/a/16012979

sorry I was talking imprecisely; I meant “extra steps” in the code, rather than as a practical workflow to follow.

For now I just use ABRP. It may be different for you, but I find that most journeys I do I only really need consider a subset of chargers - we are aiming to stop approximately every 2h to change drivers as my partner starts gnawing on the steering wheel before then. Those stops suggest a rough geographic area in which to look for chargers, and very often there are chargers exactly where we are stopping anyway. So I no longer feel like I need a really solid route-planner.

A model for energy usage at various speeds that you can apply across a route would still be really useful - I still use ABRP to tell me whether I can make a certain distance from a given state of charge. This will then probably not be as good on open data, as I don’tthink there are good open datasets for average traffic speeds (given time of day). The car’s own model of this is somewhat opaque so I don’t trust it too much.

I don’t know of one, but it sounds like something that could make use of the route-planning ability of Osmand with extra steps…

I don’t believe it’s easier than rsync.

It seems like you haven’t seen any evidence of them but still believe they’re here?

Was there a known issue there?

Are you really going to get defensively patronising over this? I think I’mma bounce, lol.

Yeah you might be right.

I should clarify I use GIMP. A lot! But this is one way it sucks. By this point I don’t know what other similar programs even have over it - it finally got adjustment layers after some decades. So if I can recognise this shortcoming anyone should be able to ;)

The other major thing was switching to single window mode. Floating windows for everything was absolutely batshit.

The first two sets of instructions are for drawing a disc, rather than a circle (a disc being a filled-in circle) and don’t extend to drawing a circle easily. The last method does, but it is about 10x as long. The traditional method for drawing a circle was to select the inner circle, save the selection to a channel, grow the selection by the pixel width of the stroke you want, subtract the saved selection, then fill. Wonderful /s

GIMP does not (unless I missed it in a ~recent update) have a shape tool like most image editors. The GIMP documentation in any case suggests using Inkscape for the purpose.