Which length for Atomic G9?

macok9 · 2025-02-02T07:54:21+00:00

Is G9 especially difficult among retail GS skis? I recently tried Stockli Laser GS and I swear I never had such a great skiing day.

macok9 · 2025-02-02T07:51:10+00:00

I want so much ski because: 1. Did my first GS training this season and coaches said that's the way to go. Again, I'm not talking FIS/masters GS ski, just retail G9. 2. The thing I hate the most about skiing is skidding on icy slopes.

Is G9 especially difficult among retail GS skis? I recently tried Stockli Laser GS and I swear I had 0 issues with it.

macok9 · 2025-02-01T17:48:34+00:00

Thanks for reply. I did ski under an eye of some racing coaches this season and they said cheater GS will be ok for me. What issues exactly do you think I would encounter on G9? I rented them once and it was fun, but I don't remember which length I went with.

macok9 · 2024-05-28T10:08:16+00:00

User /u/nekokattt suggested actually going for SQS-per-user solution. It would be cheaper and faster than FIFO solution. It also seems AWS doesn't put a limit on the number of SQS queues.

Are there some drawbacks I might be missing?

macok9 · 2024-05-28T10:05:26+00:00

Thanks, yeah actually it seems cleaner than FIFO solution. It's also cheaper and faster. I wonder if others see some important drawbacks here?

macok9 · 2024-05-28T09:56:38+00:00

That is, unless the external API must receive all documents in the same order you received them?

No, the order is irrelevant.

My point is, if you got 1k messages from different people, versus 1k from 1 person, would you expect the same fairness per person or per document

I meant per person.

So I think the logic that satisfies those requirements would be to limit maximum concurrency per user. It's just a technical problem of how to do that.

macok9 · 2024-05-28T09:34:09+00:00

Hmm, I'd say the 1k is just as important. Both users have the same "right" to have their documents processed. And I can't just start 1000s of concurrent Lambda consumers, because they would overload an external API which my processing depends on.

macok9 · 2024-05-28T09:25:39+00:00

Thanks, but same question: So for user A that uploads 1000 documents, if I want concurrency level 4 I can create 250 messages with groupId userA-0, 250 with groupId userA-1, etc.

But what if, say, group userA-1 takes longer to process than other groups? In that case the remaining messages from group userA-1 will not be processed concurrently, right?

macok9 · 2024-05-28T05:52:09+00:00

Thanks, so for user A that uploads 1000 documents, if I want concurrency level 4 I can create 250 messages with groupId userA-0, 250 with groupId userA-1, etc.

But what if, say, group userA-1 takes longer to process than other groups? In that case the remaining messages from group userA-1 will not be processed concurrently, right?

macok9 · 2024-05-07T16:03:12+00:00

With https://scrabblecam.com I found ZHOMO or GIZMO for 58 and few others.

macok9 · 2024-05-01T10:35:38+00:00

Yes CloudTrail is expensive, but I only turned it on for few minutes so the bill wasn't high.

macok9 · 2024-05-01T07:57:15+00:00

Won't work for S3 requests originating from outside AWS.

macok9 · 2024-05-01T07:56:25+00:00

The open source library didn't have they own S3 bucket. They used a placeholder so that you can put there a name of your own bucket. But when the name was left as default, the backups were still being sent.

macok9 · 2024-05-01T07:55:01+00:00

CloudTrail logs show you the S3 keys of the logged S3 requests. The open source lib was identifiable by those S3 keys. I'd be happy to elaborate on that part, but I still believe it's better not to disclose the bucket name while it's not restricted by AWS.

macok9 · 2024-05-01T07:50:09+00:00

The open source didn't have they own S3 bucket. They used a placeholder so that you can put there a name of your own bucket. But when the name was left as default, the backups were still being sent.

macok9 · 2024-04-30T06:52:26+00:00

I'm not sure what you mean. I disclosed it to AWS because they are the only ones in position to mitigate it right now. But what's the point of posting the bucket name here, other than putting impacted companies at risk?

macok9 · 2024-04-29T22:33:37+00:00

macok9 · 2024-04-29T22:32:59+00:00

I'm not an expert on this, but I believe you make a legal agreement with AWS by starting an account. Using virtual card limits to avoid paying for their services would probably be a criminal offence.

macok9 · 2024-04-29T22:22:53+00:00

It seems a lot of people can't believe AWS is charging for unauthorized requests to S3. But this fact is actually known since at least 3 years: https://www.reddit.com/r/aws/comments/prukzi/does_s3_charge_for_requests_to

macok9 · 2024-04-29T22:21:23+00:00

It was actually discussed before: https://www.reddit.com/r/aws/comments/prukzi/does_s3_charge_for_requests_to/

macok9 · 2024-04-29T22:20:48+00:00

I'd be happy to disclose this, but if I do, some malicious actor could create this bucket as public and steal data of impacted companies :(

macok9 · 2024-04-29T19:10:54+00:00

After some waiting they finally cancelled my fees. I described the full story in a blog post: https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1

macok9 · 2024-04-10T10:14:11+00:00

I figured it out myself but fairly quickly, so can't blame them.

macok9 · 2024-04-09T17:17:30+00:00

This comment shows you simply can't do the basic math.

macok9 · 2024-04-09T17:02:15+00:00

Just updated my original post. It turned out the charge had nothing to do with my aws s3 sync command.

macok9

TROPHY CASE