adamckay
It's probably the right approach to onboard a few independent security companies and task them with reviewing multiple OSS projects than it is to onboard each project individually.
 with a wordy 3 or 4 paragraphs of text, including a healthy amount of business-speak.
Your recipient will then have an email land in their inbox and probably have their AI read the email and automatically summarise those 3 or 4 paragraphs of text into 3 or 4 bullet points that the recipient then sees in their inbox.
An Xbox was ordered that's classed as a "high value" item so requires a OTP being given to the driver to release the package.
The package was hand delivered to the customer when the customer provided the OTP, but it turns out the contents of the package were swapped out with junk.
Thanks for letting me know (embarrassingly I did load up the PEP page to make sure I remembered the right number but I didn't check its status).
Was hoping that it would make things simpler for smaller projects and newbie developers but the rejection reason is solid.
I was asking if they are also suggesting that this second-degree insider trading be stopped somehow?
It's rather a useful tool and I'm personally using it for dependency management and packing for all my projects moving forwards, though for venvs I'm using `pyenv` and the `pyenv-virtualenv` plugin.
Once you figure out your workflow it can be quite nice, but it's figuring it out that's a huge mess in Python at the minute. Hopefully PEP 582 (Python local packages directory) solves it a bit...
But you can lock session tokens to specific IPs or user agents. I've implemented similar in the past for a B2B admin-panel, and whilst there were the occasional false positive with browsers updating in the middle of a session (incrementing the user agents version number) and people's IP changing if they switched networks (or in one instance, a badly configured office network that randomly routed through 2 proxy servers with different outbound IP addresses) which then made it demand MFA again, it was fairly rare and didn't attract too many complaints.
A monolithic codebase doesn't have to be deployed as a single artifact to be a single point of failure.
There's nothing stopping you from deploying a monolith application across a distributed number of machines in a highly available manner, including making machines favour some types of work (e.g. web workers and background job workers). Nor is there anything stopping you from performing blue-green deployments or A/B testing if you want to interpret single point of failure as a bug is deployed to all machines simultaneously and affects your entire application.
You would be correct if the ID were an integer being serially increased. I can sign up to your website today and get an ID X and then sign up again in a week and get ID Y, I can then calculate the number of new users you've had by performing Y-X.
If this ID is a timestamp then there's no such information I can get out of it from a small sample. I sign up today and get todays timestamp, then I sign up next week and get next weeks timestamp..?
Wherever it makes sense for you and your organisation. There's not a list of approved "boring technology" and unapproved "exciting but scary technology". It's not about the age of the technology, but your level of experience with it. If you know it inside out, understand its failure modes and can easily find information when something goes wrong it's "boring".
If your team can configure AWS services in their sleep but have never touched a bare metal box then AWS is boring. On the flip side, if you're a bunch of Linux greybeards and wrote the book on iptables but can barely spell VPC then on-prem is boring.
This is also where the concept of "innovation tokens" comes in. C++ is well established and quite far from innovative on its own, but if you're building a web app and your team is full of new graduates and interns that have only ever touched Javascript and Python then using C++ would spend one of your "innovation tokens" as your team is busy learning it instead of learning the business domain.
And unless your jobs are trivial then it's highly likely that they interact with your app in some way so it doesn't really matter if your workers are distributed and up, they're not able to complete their work because your app is down because of a single-node Postgres.
1 - https://github.com/yapret/toolship/blob/main/src/node/functi...
Then why is it overwhelmingly this breed that attacking people?
We accept that certain breeds have innate instincts and traits - border collies herd, labradors retrieve, greyhounds run, pointers point, small terriers chase - but you argue that this breed of dog that was (when you trace its lineage [1]) originally bred to bring down bulls and be aggressive and fight can't possibly be aggressive because of its breed?
It's been recently reported that half of all of these XL Bully dogs in the UK are descended from a single dog called "Killer Kimbo" which itself was inbred [2] and its first and second generation offspring were responsible for killing a 4 year old child and a grown man respectively.
1 - https://en.wikipedia.org/wiki/American_Bully#History
2 - https://www.telegraph.co.uk/news/2023/09/14/britains-xl-bull...
Probably so when you upgrade/lose your phone you don't otherwise lose your MFA tokens. Yes, you're meant to note down some recovery MFA codes when you first set it up, but how many "normal people" do that?
No, it's not, for exactly the reason you state:
> You're not actually getting that on say, a single low-end instance over the Internet
Some languages are, of course, more efficient, but it doesn't matter - you can get very good performance out of any language/runtime - it's all about your architecture and infrastructure.
If early/small, who wants to worry about putting another piece of infrastructure (RabbitMQ, Redis, etc) in your stack that you have to operate?
It will probably surprise you how far you can go with just Postgres.
I don't mean this to be a "well actually" comment, but because I found it interesting when I learnt this a few weeks ago - some limits for SQLite [1] are actually higher than the limits for Postgres [2] (specifically the number of columns in a table and the maximum size of a single field).
When you've got plenty of money in the budget it's not beyond poor managers to hire more for no other reason than to grow their "kingdom", as a bigger headcount equals bigger importance.
No, I don't think so. Sprinkling a little client side JS can certainly be beneficial and doesn't invalidate it being a RESTful HTML API. _hyperscript [1] was created by the htmx author for that purpose. There's a book [2] that you may not have seen written by some core htmx dev's that goes into this [3] in more detail.
[1] - https://hyperscript.org/