> In the US, not disclosing a password is explicitly protected (5th amndmnt),
That's great but of exactly zero help if you're trying to travel to the US and CBP (or ICE) are staring you down. Even if they don't gulag you, they can always just reject entry for any non-citizen (and these days even some citizens it seems.)
Any country can reject non-citizen entry, for any reason or no reason at all. In fact, part of a definition of a country is ability to practice control over its territory and who is and is not there. This necessarily includes border controls, which any country can decide to make as onerous as they please. No non-citizen of a country has any right to be present in it, except as permitted by its government, so any country if free to make it as hard as they wish to enter for non-citizens. This may not be a good idea, but control over a territory is literally part of the definition.
> Any country can reject non-citizen entry, for any reason or no reason at all. […] This necessarily includes border controls, which any country can decide to make as onerous as they please.
Or, a country could set rules that specify what they will and won't do as part of their entry controls. Just because it's a kind of an "absolute" power doesn't mean you can't still self-impose rules. The benefit being attracting more leisure and business travellers.
Yeah, it used to be that you could still make calls (particularly to emergency services) even in complete power outages, for as long as your local exchange has batteries for. (AFAIR that tended to be on the order of hours, but probably differs quite a bit across locations and regulatory domains/countries.)
Another thing we lost in the age of VoIP landlines, but then again mobile towers also have batteries. Just don't be unlucky and have a power outage with 3% battery on your phone...
> I then learned that the energy draw of running the low-volt transformer all the time - especially one large enough to supply an entire house of lighting - would more than cancel out energy savings from powering lower voltage fixtures.
That's not a constraint of physics, you can absolutely build a DC power supply that is efficient in a wide load range. (Worst case it might involve paralleling and switching between multiple PSUs that target different load ranges.) But of course something like that is more expensive...
> But of course something like that is more expensive...
More expensive than an inefficient unit, but it should still be a lot cheaper than 120 separate units, right?
And I expect one big fat unit to do a better job of smoothing out voltage and avoiding flicker than a bunch of single-light units. Especially because the output capacitors are sized for the entire system, but you'll rarely have all the lights on at the same time.
Though for efficiency I'd think you'd want 48v and not 12v.
"We went a little over the line to figure out where the line is, so, we can now guarantee you, dear shareholder, that we're extracting the absolute maximum possible value! Isn't that splendid!"
> If you went 48 straight to POL voltages then you would have horrific converter performance.
What's horrific converter performance in numbers?
An isolated flyback (to 12V) should be able to hit >92% and doesn't care if it's fed -48V or +48V or ±24V. TI webench gives me 95% though I'd only believe that if I'd built and measured it. What's the performance of your -48V → +48V?
[with the caveat that these frequently require custom transformers... not an issue with large runs, but finding something that can be done with an existing part for smaller runs is... meh]
-48 to 48 claims something like 97% (load dependent of course). It also needs to arbitrate between two input supplies for glitchless redundancy, plus have PM bus and other spec mandated stuff. There is no technical reason why you cant go -48 -> 12 as you state with good efficiceny, but we cant get hold of a part that ticks all the boxes.
Horrific performance by my definition would be 48v to say 1v. We only realistically use buck topologies for POL supplies. Such a ratio is really bad for current transients, not to mention issues like minimum on times for the controller.
I'm just surprised that either input isolation isn't on your spec, or it still somehow works out better with isolated to +48V than straight to 12V... but I guess if your spec requires other things, it makes sense.
Well if it's negative 48V the electricty flows out of your circuit and back to the grid, so you need to make it positive to have the electricity come in.
> Most modern interchangeable-lens digital cameras are designed for you to shoot RAW
I don't think I agree. The photos straight off my GH4 are perfectly fine as-is, it's quite a bit of work to get the same thing out of Darktable, let alone something better. I do still shoot in RAW, for those 1% where I do want to go in manually. (The GH4 isn't great in low light.)
> I wish I’d stopped shooting RAW sooner. Trying film led to that realisation.
I mean... yeah. But don't blame the camera for your personal habits ;)
This doesn't really have anything to do with async signal safety. You could perfectly fine capture the Ctrl+C in psql, stick a notifier byte in a pipe (or use signalfd to begin with) and handle it as a synchronous event in a main loop. You'd still need to establish a new connection purely to bypass buffered data. (or use TCP URG, but that seems generally a poor idea.)
Well, it does, because -- as the article notes -- psql creates and sends on the new connection inside the signal handler, and that doing the pipe-write thing instead (required since their TLS library is presumably not async signal safe) would require a major refactor of the code.
Likely psql doesn't even have a "main loop"; I expect it just blocks on recv() until it gets a response from the server. And on Linux, I think it will automatically restart/resume syscalls that were in progress when a signal fires, so you can't even rely on EINTR to get you out of that recv() so you could check a global flag that you could set in the signal handler.
Although, reading the sigaction() manpage, if you don't specify SA_RESTART, it shouldn't do this? (If they are using signal() and not sigaction(), it might always restart?) But still, not sure why they don't take that route. I imagine it would require much less of a refactor to set a global flag, and then always check it after a recv() fails with EINTR.
Sure, the "right" thing to do is have a global pipe, and instead of blocking in recv(), poll() on it with both the connection socket and the read end of the pipe. And I bet that would require a bit of a refactor. But a global flag is somewhere in the middle...
But who knows; I've never read their source code, so I expect they know what they're talking about when they say it's not a trivial fix.
> This doesn't really have anything to do with async signal safety.
TLS not being async signal safe is explicitly called out on the article as the reason the token is sent in clear text.
> Handle it as a synchronous event in a main loop
Of course of you rearchitect the client there are better solutions. But again, the article mentions that's not planned for now.
By comparison, delegating cancellation to a background background thread can be done non-intrusively. In principe no code outside the cancel path need changing.
Edit: the article mentions that there is a refactor in the works to implement cancel over tls [1]. Turns out that they decided to use a thread (with a pipe for signaling).
> By comparison, delegating cancellation to a background background thread can be done non-intrusively. In principe no code outside the cancel path need changing.
pthread_create() isn't async signal safe, though, so they can't simply move their socket code for the cancellation into another function and call pthread_create() on it. They still have to get the main thread to stop doing what its doing (usually via the pipe trick) in order to create the thread, which could easily be a big refactor.
> Edit: the article mentions that there is a refactor in the works to implement cancel over tls [1]. Turns out that they decided to use a thread (with a pipe for signaling).
Seems odd to me to bother. If you have to do the pipe thing, why not just do the new connection for cancellation in the main thread once it sees the data on the pipe? I guess that way they can return control of the CLI to the user while they cancel in the background, rather than blocking the user while the cancellation is going on. But as a user, I kinda would like to know that the query I just cancelled actually got cancelled, a property that the old code has, but the new code won't.
(Presumably the new code can print a warning if cancellation fails, but it could take a long time to fail, and in the meantime the user has moved on.)
I believe the suggestion is to have a TLS endpoint in the server, which demultiplexes the incoming CancelRequest and signals to the corresponding worker process via shared memory
The problem isn't on the server; the server already knows how to cancel things, and already supports cancellation over TLS. It's just that psql doesn't use it, due to the need for a refactor to make that work. Other psql-like frontends do already use it, as the article points out.
reply