aeorgnoieang

Yes, it's supported. It's one of the "initialization" options when you start a new game.

I'm kinda curious why none of the third party app developers considered selling Reddit requests as in-app purchases – just charge the rate Reddit charges.

I think so? PostgreSQL is very well written software AFACT.

I've run into version incompatibilities before, but it was my fault – they were expertly documented in the release notes and I just hadn't read them (or sufficiently tested the upgrade before the live performance of it).

Sure – and fail to meet their constraints

Is that even true? I don't think I've seen or read a direct apples-to-apples comparison of the two.

There could be all kinds of reasons why that is tho (if it is in fact the case).

I wouldn't think using "standalone" versus whatever would make much of a difference.

If you're using a hosted DB service, you're (probably) stuck in needing/wanting to rehearse using the hosted service (which is what the blog post describes).

If they were running the DB on 'regular server' cloud instances, it seems just as good to me to rehearse with other cloud server instances versus "standalone" servers.

I'd think using built-in replication (e.g. PostgreSQL 'logical replication') for 'dual writing' should mostly avoid inconsistencies between the two versions of the DB, no?

What's the structure that your custom DB uses?

I found your comment amusing!

Many!

I've found, repeatedly, tho that this is the best way to really understand the common pitfalls without just receiving them as 'holy writ'.

I'd imagine your friend(s) would care if you called them with questions frequently enough!

Sure!

I'm guessing we have different 'threat models' in mind.

From my perspective, I know _I_ am a moral and ethical person and therefore won't "execute an action against the user's will".

But, also from my perspective, even if "that action is allowed according to the user's credentials", I can't tell, and thus my server-side code can't tell, that a 'user' is a real person or even a legitimate user of my site or app.

The comment I was replying to claimed that "The user agent is ... is not enemy territory.".

But what came to my mind on reading that was user agent's also (commonly) perform 'card testing' and 'credential stuffing' and, even if I trust that I can securely give them access to my front-end/client-side code, I have no way to know whether they're running that code. And, even if they're running my code, there's _still_ room for malicious or nefarious action on their part.

I was NOT disagreeing with this (in the comment to which I was replying):

> Yes, the server must assume that enemy agents also exist. But it should better not deliver one to all users.

> It requires constant effort in care and feeding.

Just like all of our 'natural intelligences' (each other)!

A 'user' can do all of the things you mentioned, e.g. "insert random HTTP headers", given that they have access to all of the stuff your code does too, so any code, of yours, that runs outside of _your_ systems, _is_ in "enemy territory", as none of the code _inside_ your systems can trust anything from 'outside', even if it possibly came from your code.

> Spotting bugs in code that has been generated by a GPT-3 derivative, with all the subtle mistakes that implies, is going to be even harder.

I'm kind of skeptical! I think your claim is reasonable tho so maybe I'm more skeptical of your confidence?

I'd love to read a follow-up from you after you tried using Copilot for an extended period; even (or maybe especially) if it's as bad, or worse, than you expect!

Even when I _do_ know "how to do the thing", I've learned, thru painful (and repeated) experience, that I can't trust myself!

(But I also have no interesting in using Copilot myself, tho maybe I should try it myself now, if only on some toy side project.)

> When it works most of the time, it lulls you into a false sense of security, and then when it fails, you aren't prepared and you die.

That still doesn't _necessarily_ imply that 'partially self-driving cars' are worse than actually existing humans. Really, anything that's (statistically) better than humans is better, right?

I don't think it's reasonable to think that even 'perfect' self-driving cars would result in literally zero accidents (or even fatalities).

> That's a crazy dependency to bring into your project if your own programming skills are above that of the median github user.

So, roughly half of programmers would be _better_ served just blindly using Copilot's suggestions then?

Personally, I find that I work with so many different things so often that I "googling" is often much quicker even than reading documentation or even searching my own existing code.

But I also have _zero_ interest in Copilot at all, so what do I know?

That's weird. I'm pretty sure routing numbers (the bank portion) in the U.S. are all public anyways. I've been routinely looking-up my bank's routing number via Google for a while!

I think I do that, on the off chance that a person might have multiple listings, and my general preference for precision. I probably also figured it'd be easier for them to know what I was referencing if I used the exact same text.

I can understand (in a very vague, general sense) why spare parts might be relatively expensive – it's probably fairly expensive to make, store, and maintain a distribution network for the parts, i.e. the price isn't just for the price of the part, but the entire system (e.g. customer support) to send it to a customer in response to their request. I'm _sure_ there's also an 'original manufacturer' premium too, and maybe that _is_ in fact most of the difference compared to 'unbranded compatible' parts.

He doesn't assume that "robotic life form[s]" would be more likely to perform future space exploration. He's written (before) about why he thinks that's much more likely.

I think a lot of people, myself included, don't know the nominal value of their total compensation. If their employer pays the full costs of their health insurance plans, I don't think many people know what those costs are.

Also, as others have pointed out, certain components of total compensation, like various forms of 'equity' in the employer company, are not reasonably equivalent to cash, and no one could feasibly evaluate the cash value at any particular moment in time given all of the relevant variables needed to even estimate those cash values.

> there's no practical way to stick an atmosphere, much less a civilization composed of life forms that depend on gravity, to the inside of the sphere

Why not spin the sphere? Given the immense surface area, it wouldn't even matter that the centripetal force would only be strongest around the 'equator'.

So, the plan would be:

1. Create a giant rotating sphere around our Sun.

2. Create a ring world around the 'equator' of the inside of the sphere (i.e. a ring of walls high enough to hold in the resident's preferred atmosphere).

3. Install solar panels everywhere else.

4. Profit!

Why isn't this an appropriate venue for this discussion? It seems perfectly germane.

I interpret his point being less about denying that some people will be harmed by global warming but that most (or 'all') people will be.

I agree with what I think Dyson believed: that it's NOT obvious that global warming is net-negative (long term).

Another ice age would be pretty terrible too.

Those drawbacks are only true on some (possible) timescales. The biggest drawback currently, for human settlement of the asteroid belt, is that we can't afford to send anyone there!

Freeman Dyson's the person after which the Dyson sphere is named, so the current (relative) "unusability" of asteroids or the fact that humans currently seem to "do really poorly in microgravity" are 'just' additional obstacles to be overcome sometime in the future from the perspective in which space megastructures are possible.

Using Vim has helped my finger/wrist/arm/shoulder/neck pain and soreness, but you're on to something in that the real problem is probably more repetitive motions than any specific motions.

But Vim (and emacs) solves the repetitive motion problem by providing several means of readily repeating commands.

Most people seem to both type and use their mouse much more slowly than I do. And they also don't often have to (or want to), e.g. cleanup thousands of rows in an Excel worksheet, or have to repeat some kind of action in an app or web app dozens of times.

But I hate using my mouse generally. There are very few times where I want to use a mouse and having to use one, instead of being able to use the keyboard, is endlessly frustrating.

Thankfully, there are several great 'vi-style' browser extensions and there's even [Vimac](https://vimacapp.com/) for MacOS, tho I haven't tried the latter yet.

For maps:

- [ColorBrewer: Color Advice for Maps](http://colorbrewer2.org/#type=sequential&scheme=BuGn&n=3)