verandaguy_alt

You could print the warning out to STDERR when the Python runtime finishes parsing and before it executes your script.

This will likely break some people's workflows, but honestly, it's the de-facto way of notifying users of a deprecation in many Python frameworks (Gunicorn did this recently with gunicorn-paster vs gunicorn --paste).

They could also include this in a "What's new in Python (4?)" since this is unlikely to be introduced in a minor version bump.

A cryptocurrency implementing a zero-knowledge proof, like ZCash, may be a better choice here.

That varies from brand to brand, but generally, yes. Given that it's happened to devices whose manufacturers have a long history of being part of large enterprise security mechanisms, flaws are still being found and actively exploited.

While this isn't an indicator of the quality of newer brands specifically, I believe it's reflective of the state of the industry as a whole -- in that digital physical security as a whole is still immature and shouldn't be trusted to keep bad guys (determined adversaries) at bad.

If you're comfortable using a totally (physical) keyless solution, try a hotel-style mag strip-based access card, or an NFC alternative like a ProxCard.

AFAIK, most code-based locks include a physical lock cylinder as a backup.

Coming from an infosec background and having touched on physical security, just don't use a smart lock:

- Best case, even with a responsible implementation, you're introducing more variables than are necessary into a supposedly secure system. If one of your dependencies fucks up, your lock is exploitable.

- Worst case, you have a typical IoT device, where the "S" stands for "security."

- In _either_ case, you're likely still going to include a physical lock mechanism for keys as a backup -- so you're basically just increasing the attack surface (significantly, I should add) by doing this.

Smart locks are currently high-risk appliances, and I'm fairly confident that most others with a security background will agree with me on that.

What most companies have is access controlled by an organizational superuser team.

At large companies, this means that each team has full or near-full control over their "jurisdiction." IT has full control over LDAP accounts, and since they're a team, one person going AWOL won't affect the org as a whole. There are also infra teams that control domain routing and hosting providers.

Are the feature comparison tables in this article supposed to reflect the state of SQL databases as of several years ago?

I've been using Postgres very consistently for the past half decade (as a dev, not a DBA) and it's had a `GROUP BY` and `WHERE` clause for at least as long.

I'm not totally sure what "base table `UNIQUE`" is supposed to mean in this context, but if it's just the bare `UNIQUE` constraint, Postgres has also had that for a long, long while.

That's actually reassuring, I'm glad they looked into this.

My follow-up concern is, what if, under these salty and wet conditions, something causes a short circuit between the powered rails?

e.g., either a defective vehicle-side contact where the anode and cathode allow for the water and salt to close a much smaller gap, or if someone deliberately sticks a piece of metal on there.

I haven't heard of vulture investors before. Is this just someone who aims to profit from an eventual asset sale (somehow)?

Asking as someone less involved in reading about the funding side of starts than probably many of you, can someone explain this quote?

>The most viable option that we have identified to forestall a near-term sale or a potential default under our credit agreement is further investment by one or more of you.

Surely, the company can't in earnest expect any more VC or angel funding after their most recent round of layoffs, right?

Is it common for startups to ask for funding when it's very clear that the company is in such bad shape, with very little chance of recovery?

Is it appropriate to be concerned that this will result in infrastructure being approved without sufficient review, potentially resulting in dangerous infrastructure?

Not all countries have whistleblowing protections, and even fewer will offer fiscal rewards for the act.

Leaking corporate data or trade secrets to the general public is not the solution for a couple of reasons.

- Depending on the actual contents of the leak, people might panic; this is basically never useful.

- Depending on the outlet, the contents may get distorted before being published in order to fit some narrative -- potentially causing a panic. See above.

- You or the original leaker may be traced back using even editorialized data, or without the corporation seeing the data. This would land you and/or the original leaker in a lot of legal hot water.

- A side-effect of that is that you'd become unemployable in many cases, and you might find yourself running from the law in other cases.

So, yeah -- quitting facebook probably isn't a bad idea as a user. Refusing work as a contractor or an employee may be difficult, but because absolute morality doesn't exist, it's really up to the person in that position to make the call about quitting.

Lots of edge cases with an extremely large base case -- I'd guess (conservatively) that at least 9 out of 10 sites you go to use shared hosting or a CloudFlare-style CDN.

Also worth noting that an ISP will generally go for the low-hanging fruit, but if your threat model includes a determined opponent then this probably isn't for you.

It's hard to argue that this isn't a net improvement over the status quo, though.

>Why do you need an HTML renderer?

Because it's objectively easier to do cross-platform GUI development using a single, well-defined and portable API that someone else maintains.

That that API is nowadays de-facto WebKit supporting a HTML/CSS/JS stack is a natural, but unfortunate choice, and it's got a much lower barrier of entry and much less maintenance overhead than, say, Gtk+ or Qt.