Dunedan

Some customers got such an email, but not all of them (also see https://news.ycombinator.com/item?id=34255721). The only email received by people in my org was the email pointing to the post-mortem, which went out on 2022-01-13.

Which is in fact what they did (or even worse they didn't delete them at all): https://discuss.circleci.com/t/circleci-security-alert-rotat...

> On January 4, 2023, at 18:30 UTC, we shut down production access to nearly all employees, limiting access to an extremely small group for operational issues.

Shouldn't that have been the case from the beginning? Why did more than a small group of employees have production access at all?

Check out pip-tools [1] which does exactly that, albeit in a slightly more polished way.

[1]: https://github.com/jazzband/pip-tools

While featuring a smaller screen the 11" MacBook Air wasn't smaller than the 12" MacBook!

Here are their sizes for comparison:

    MacBook Air 11"    300 mm x 192 mm x 17 mm          1,08kg
    MacBook 12"        280,4 mm x 196,6 mm x 13,2 mm    0,92kg

One killer feature for me aside from usability for less-technical people are comments. While comments are not be necessary for certain types of websites, I consider them essential for anything you might call a blog.

As USB-C becomes more and more ubiquitous, I'd love to see every device with a USB-C port and a display to support incoming DisplayPort alternate mode. That would be a worthy successor to Apples target display mode and would offer a great way for using devices like tablets as secondary displays.

> I hate metered API billing, and I don't want to use it.

> Instead, I want to do credit-based billing: you buy credits, and when you get to 0 credits, you are cut off (with an auto-refill option for the "metered billing experience," but with strict spending limits). This is, in my opinion, a much better UX than metered billing.

How do your customers feel about that? Have you researched if your customers are comfortable spending their money upfront to buy credits they might only use much later (if ever)? For small amounts of money that might not be a big deal, but if we're talking about thousands of dollars that might look different.

> The plant will operate two 9 1/2-hour shifts per day, down from two 11 1/2-hour shifts currently

Isn't that more likely to be a measure to improve employee retention instead of a sign of a possible demand issue as suggested in the article? 11½ hours shifts don't sound very sustainable and would even be illegal in many other countries.

As the algorithm used in the example is straight-forward I figured that using UNIX command line tools might be an even simpler way to implement it. Here is what I came up with:

  time cat kjvbible_x100.txt | tr "[:upper:] " "[:lower:]\n" | sort --buffer-size=50M | uniq -c | sort -hr > /dev/null

On my machine this turned out to be ~5 times slower than the provided Python implementation. Nearly all of the time is spent in the first invocation of `sort`. Further increasing the buffer size doesn't make a significant difference. I also played around with the number of threads `sort` uses, but didn't see any improvement there either.

I'm quite puzzled why `sort is so much slower, especially as it does sorting in parallel utilizing multiple CPU cores, while the Python implementation is single-threaded.

Does somebody have an explanation for that?

> That is of course an easy solution but I would argue that this is just throwing more resources at the problem. Not a very impressive optimization.

You could say the same about the existing implementation as that reads the whole file into memory instead of processing it in chunks.

> Nope, the GIL will make that useless.

In Python yes. I missed that. The Go implementation would still benefit from multiple threads, wouldn't it?

> I haven’t shown an optimized Python version because it’s hard to optimize Python much further! (I got the time down from 8.4 to 7.5 seconds). It’s as fast as it is because the core operations are happening in C code – that’s why it so often doesn’t matter that “Python is slow”.

An obvious optimization would be to utilize all available CPU cores by using the MapReduce pattern with multiple threads.

I believe that'd be necessary for a fair conclusion anyway, as you can't claim that I/O isn't the bottleneck, without utilizing all of the available CPU and memory resources.

That's surprising to me, given how much effort AWS put into emulating old instances types using newer instances to still be able to offer instances with the characteristics of old instance types to customers. [1]

Do you have additional information about that you can share (maybe an announcement regarding this made by AWS)?

[1]: https://perspectives.mvdirona.com/2021/11/xen-on-nitro-aws-n...

If you work directly in the source repository that works actually really well on Github (if everybody works on its own fork instead, you're unfortunately out of luck). When opening a pull request, you just select the branch the pull request should be based on to be the previous branch in your stack. If one of those pull requests gets merged, Github will automatically rebase the stacked on onto the base branch. This way every pull requests contains exactly the changes you want it to contain, while you're still being able to stack changes by opening multiple pull requests, with each one being based on the branch of the previous one.

Google not so much, as they still accumulate losses with GCP. [1]

[1]: https://www.computerweekly.com/news/252523200/Google-results...

How is warning that the company can't afford losses forever a false peril? It's just saying out loud what everybody knows anyway.

Somebody on Reddit recently did collect what one gets for donating blood in different areas of Germany: https://www.reddit.com/r/de/comments/xoqyay/aufwandsentsch%C...

What you can see from that is that a "Aufwandsentschädigung" of ~20€ is pretty common.

There is also `parameterized` [1] if you want to do it by using decorators.

[1]: https://pypi.org/project/parameterized/

> This makes two partitions, one for GRUB to inject legacy BIOS boot code into and one for the ESP.

Why do you still need the legacy BIOS boot logic?

Out of curiosity: Could you please elaborate what such challenging environments can be?

Up to a certain degree they work, as humans can drive in fog or heavy rain/snow as well. If visibility is so bad that a human wouldn't be able to drive, I wouldn't want to sit in a self-driving car either, no matter if it does use vision only or has additional sensors.

Proper naming of variables/functions is important, but would only tell a part of the story. In the example you'd loose the context why that port might be already in use.

Using comments instead of commit messages is of course always possible, but if you'd note all relevant information you'd otherwise put into comment messages in comments, you might end up with more comments than actual code, which IMO hinders readability significantly. Take the Linux kernel for example. git commit messages there are very informative and often pretty long. Putting this information into comments would make the code pretty hard to read. Also sometimes there isn't a clear place where you'd put such a comment at, as it only makes sense when looking at multiple changes in different locations (= a git commit) at once.

I believe having the explanation why certain aspects of the code are as they are in the metadata in form of the git commit messages with an occasional comment in the code for important information is a good compromise between readability/verbosity of the code and having all relevant context available.

AWS supports up to Python 3.9 right now: https://aws.amazon.com/about-aws/whats-new/2021/08/aws-lambd...

> A good example was the broadcast industry. Entire branches of that industry doing post-production, colour, transcoding, and whatnot moved it all out to AWS. After price hikes, they wanted to go back to running their own services.

Do you know what exactly increased in price? AWS usually doesn't increase prices, so I'd be interested if that was an exception or if that's a reason just given to cover another issue they had with AWS.

> Have you taken a look at the website?

No, I haven't, because the parent comment was referring to registering these domains, not about what they serve.

I also don't want to judge whether whatever happened at that C3 was justified, but rather that it's not clear from just domain names if there meant in a sarcastic way or not.

> You don't get a timestamp from nowhere without knowing the kind of time it references: local or UTC or fixed to anything like client time.

Imagine you have a software which deals with CSV files sent by clients. Clients are international corporations. What's the timezone the datetimes in the CSV files belongs to?

CloudWatch at least lets you choose in which timezone to display datetimes. Other AWS services don't let you choose and don't even show in which timezone they display datetimes, which is somewhat infuriating to me, when I'm in a hurry anyway and suddenly have to wonder which timezone the shown dates are in.

I also remember that AWS used to display some datetimes in Pacific Standard Time, which is completely useless to somebody outside the US, however I haven't seen that in a while anymore.

Similar to the global language switch I wish the AWS Management Console would allow setting in which timezone to display datetimes globally as well.

> Not that I've ever had to spend a day trying to troubleshoot a bug that was alerted by our monitoring system at 2020-11-09T09:11:05Z (as it was defaulting to UTC), but the relevant logs were timestamped at 10:11:05 09/11/2020

It gets even more fun when such events happen during the switch between daylight saving time (like CEST) and standard time (like CET).

People associated with the CCC most often do responsible disclosure. Therefore you can expect vulnerabilities revealed during C3 to be already known in advance to the vendor. AFAIK an exception to that are jail breaks, which have quite a history of getting announced during C3 without disclosing them to the vendor first.