krab

Oh, thanks a lot!

Hmm, what I had in mind was rather a tool that would generate a new access key (or some other way to correlate the requests) and record and show me in real time what permissions I need and let me play with that and simulate what API calls would fail with a policy that I'm just writing. Very low volume.

This goes in the right direction. Still it's not 100% reliable (e.g. S3 isn't logged by default to cloudtrail, probably due to volume). Also, not really interactive. I'm talking mostly about ergonomics. Obviously we can solve the issue and create the right policy - but it's not as easy as it could be. That in turn leads to some people skipping the process and staying with too powerful keys.

> mapping some of the apis to iam as its only 85% 1:1

Yeah. Try to create an Elastic beanstalk app with only EB permissions.

This doesn't cut it. That tool helps if your role/user has a lot of policies that might interact between each other. But you already need to know the exact "actions" and context.

On the other hand, I have a tool that calls some AWS services that may in turn call other AWS services. Now if something fails because of IAM denial, I have to go through the logs to figure out what it needed, sometimes it's not even in the logs (S3). Then add it to the policy and repeat to see the next failed call.

I imagine being able to call real API calls, make them succeed and record what permissions it needed for each of those API calls. I don't need that as a permanent log, just as a development tool.

For me personally, it would be much more useful if I could play with the policies interactively - issue requests with some tagging (a special access key maybe?) and see what permissions they need, what context they have and which of them are allowed/denied by the policies. And what if I edit this part, would it affect the recorded requests?

At the moment, it usually takes me several iterations to tune the policy.

Why should the SDK be install-less? IMHO it's enough if the app makes it into the Windows store, Apple store and any Linux format.

It's still easier to bring a cryptography implementation to work there than doing this for all your code, all your libraries AND cryptography.

That's mostly Google's decision. :shrug:

Anyway, I see a difference between hiring and laying off vs. not hiring in the first place with regard to disruption in worker's lives.

Hiring many people and firing them shortly after isn't very productive use of human minds. Those people were doing probably something more valuable instead.

These three things aren't mutually exclusive but they go against each other.

For example paying people less might impact your ability to improve your money stream. Similarly having fewer people may lead to some missed opportunities.

> Genetic stuff always seemed not easily parallelizable

Not really. Processing one sample may take a few hours but if you have hundreds or more samples, it's an obvious axis for independent parallelization.

The cool kids use Nextflow or CWL these days. It's something like `make` - it remembers what you've already computed and what the dependencies are - but it uses a batch engine like SGE/Condor/AWS Batch to actually execute the jobs.

That's a different category of big data. I worked for a big pharma and they were building their big data department with Spark and friends. I was quite surprised that their biggest dataset had something like 200 GB.

At the same time, though, there was a lot of DNA sequencing data, we were designing CRISPR probes etc. But Spark and Hadoop aren't really that helpful in this area, so the Big Data team wasn't involved in those.

If JavaScript is disabled, most of the offending cookies are not loaded. Session cookies are usually fine wrt GDPR.

This is in line with my experience of lower pay offers for embedded SW development compared to business applications.

What does it mean that it's an "Access-restricted-item"? For example TI-81 https://archive.org/details/ti81-calculator

Cloud-init as well. The CLI utility you can use is ssh-import-id.

    ssh-import-id gh:$USERNAME

Growing carrots in an arid area is wasteful, because you could grow them at a place where water is more abundant. Then, carrots can be transported and they don't need almost any water anymore.

Doing the same with taxpayers would be problematic.

With IPv6, you can have all public IPs (the same as early days of IPv4). However, if you have apps that are tightly coupled and often with strict latency requirements such as Web <-> DB, then it's better to communicate only over private links. You can control latency and you have better reaction time when something breaks down. That is in addition to security concerns.

I remember a failure of one transatlantic line that was used for one direction of packets we were sending between EU and US. I spent a night on a phone trying to convince AWS and our other datacenter operator to work around the problem by changing their routing and to push the backbone operator to fix the problem - we didn't have any relationship with the backbone of course.

You don't want such disruption to happen in a core part of your app. These disruptions can also be intermittent and "random" and you have no way to fix.

A great one!

Better quality here: https://www.youtube.com/watch?v=xzS5xdSeS10

Not really. You actually may have other legal requirements to keep the data but you shouldn't use it for daily business because of GDPR. Imagine banks and long closed accounts.

Moreover, technical backup solutions, where only a very limited set of people have access, are fine. If you store DB backups, you don't have to rewrite or delete them because a customer that used your service for a week decided to ask for deletion under GDPR.

In the examples, they show S- strings. If I understand it correctly, s"random_function(a)" does what you want. The question is whether you can rely on `a` that you reference being still named `a` in SQL.

Mind blown, thanks! Next time, I'll look for this option!

I don't mind hotel check-ins but the car rental process has never, ever been pleasant for me.

They'll lobby for a ban of these chemicals, showing there's a safer alternative. That's a risk for the competitors and their customers.

I worked on a financial product in a startup. The billing and collection features were so closely tied to the product that it would be quite risky to outsource that when you're still trying to find out what your product is exactly.

In fact, we outsourced part of the software for the late payments collection process to a reputable SaaS and the results were not great.

My take is that if your needs are fairly standard, you can benefit from such service. Especially your time to market will be shorter. But you won't face any disaster should you decide to do it yourself. If you want to innovate how you bill people (most Fintechs do), you should develop in house.

Moby is Docker.

A simpler (IMHO) Python version, plus lazy and working on any iterable. Also, it's quite easy to adapt it to work on any number of iterables.

    def myzip(x, y):
        x, y = iter(x), iter(y)
        try:
            while True:
                yield next(x), next(y)
        except StopIteration:
            return

> Phone calls aren't really a thing anymore

Aren't they? What have I missed? Messages are async - if you don't want to disturb, calls are sync - if you need confirmation from the other side or you need several exchanges back and forth.

I text much more than ten years ago but I call (and receive calls) the same or perhaps slightly more.

Are we heading towards voiding most of current copyrights or is there a way out of this mess with another patch to the laws?

While an interesting take, it doesn't apply directly. In my opinion, the situation is more similar to search engines bringing you code snippets - they shouldn't be stripped of their original licenses. At least that's the legal framework we used to operate in.

Sure the legal framework can change, but such profound change will have surely many consequences we won't foresee, for good or bad.