LennyWhiteJr

I used to play on a pretty popular MMO-style server called [CivCraft](https://www.reddit.com/r/Civcraft/) that unfortunately became a victim of its own success due to the large player count. It would often have 250+ players who would build these massive redstone machines and the server TPS would grind to a halt making it unplayable.

After a few years it attempted a re-launch using an approach similar to to the first one mentioned in the article. There were multiple worlds and as you approached the border of one world it would teleport you to another adjacent world. It was cool, but was jarring and suffered from its own complexity issues.

Anyway, this project is super cool. I would have loved to see something like it 10 years ago.

It has nothing to do with 'trusting them' and everything to do with the threat model because it significantly increases the attack surface area.

Just because I want to grant system access to a relatively simply USB driver doesn't mean I want to grant the same access to a 150MB UI app.

> Yeah, WTF is wrong with that.

Nothing is 'wrong' with it. You just do it at the detriment of your own career.

Remap caps lock to escape.

The sad reality is that if your app serves any real business value and you can't afford to hire a team that can quickly handle scaling attacks, simply running your own server isn't really a viable option anymore.

The internet's original distributed nature just isn't compatible with the sheer scale of billions of active users.

It's almost like we've turned yaml into some sort of primitive assembly file that must be compiled by a higher-order language. What was once created for human readability, has now turned into a machine generated and machine parsed format.

Great explanation, thank you!

About time. Developers have been asking for the ability to write cross platform C# desktop apps for two decades now.

If .NET Core is any hint, it will be.

Yeah, going and flying over the small rural farm I grew up on I was disappointing since Flight Simulator had procedurally generated a whole compound full of random buildings that made it look like some cult compound.

Absolutely. Kotlin is *widely* used for backend code at Amazon.

Kotlin is widely used internally at Amazon. In both AWS and retail.

This is a bad idea for so many reasons.

The front-end and back-end data models are vastly different for any non-trivial application.

Remediation for this vulnerability basically caused complete gridlock for the internal tools at a certain FAANG company today.

How are the curves defined? Is there a 'standard' curve that's generally used or is the curve itself randomly generated along with the keys?

it more so prevents people from retroactively going back in time and scraping data they wouldn't have in the moment. Many of my chats expire all messages after 24 hours because of this.

Most people will not archive all texts they get in the moment, it's only after some fallout or event happens they there's motivation to dig up old messages.

At my company, if you don't check into an on-call ticket within 20 minutes your manager will get paged, who will then likely need to page one of your peers to actually fix the problem.

So it's not like you can just ignore it until morning.

May want to check out https://freight.amazon.com

In case you live in a northern climate and want to catch some rays through a window. Glass filters >90% of the rays that cause vitamin D production.

Just us-east-1.

Related - C#9 will finally support covariant return types after 2 decades of people asking :)

https://stackoverflow.com/questions/5709034/does-c-sharp-sup...

That's a bit misleading. Amazon has up until now used their own Chime app for internal chat. Only last month was the Amazon/Slack partnership announced.

The Omnibus package is literally a one line install.

$10k in hardware + $150/month electric + a noisy/hot room :)

This isn't just an issue with GCC but embedded compilers as well. On embedded systems its common to work with packed data structures to maximize serial protocol efficiency.

Lets say you have a packed structure with a type of

    struct MyPackedStruct {
      uint8_t byteValue;
      uint32_t intValues[5];
    }

Normally a compiler would add 3 extra bytes between the uint8_t value and the uint32_t array to keep alignment of the int array, but that won't be the case if you force it to be packed. This results in uint32 values that span two word boundaries. If you access one of those array values in code directly, the compiler is smart enough to perform 2 separate memory reads and combine the resulting value so you don't have to really think about it.

But if you do something like this:

    uint32_t *intValues = myPacktedStruct.intValues;

The compiler allows this, but the resulting intValues pointer loses all packed awareness, and trying to dereference that pointer will result in an unaligned memory access exception.

Moral of the story - only use packed data types when serializing/deserializing a protocol stream. Avoid using packed data types 'at rest', because it can cause subtle issues like this. The downside is that it results in extra parsing work when converting between packed and unpacked types.

The 50 days is arbitrary - the owners of GetTickTime should have written tests to handle what happens when the tick value rolls over. (Maybe they did, and allowing it to roll over was the desired behavior.)

But more to the point - the consumers of GetTickTime should have also had tests to verify that the consuming code appropriately handles time rollovers.

Granted, this was Win95 so I'll cut them some slack, but that should be standard procedure for any code that consumes an incrementing counter API. First question should always be - 'how will this code handle a rollover value'?

The same way you test for leap-year bugs, write unit-tested code that tests all your boundary conditions.

> This is a huge disparity from web development workflows where file watchers are prevalent—you save a file and instantly see the results of the change.

> Pigweed’s pw_watch module solves this inefficiency directly, providing a watcher that automatically invokes a build when a file is saved, and also runs the specific tests affected by the code changes. This drastically reduces the edit-compile-flash-test cycle for changes.

Eh, no thanks. Web dev environments can get away with this because the turnaround time is so quick, but even a medium sized embedded C++ project can easily take minutes to build, plus 30+ seconds to download, even with a debugger.

Please don't try to bring webdev workflows into the embedded space. This isn't javascript.

The number of classes isn't necessarily indicative of the size or complexity of an app.

Damn that sounds like an incredibly exhausting experience, and all he got out of it was... a hugely expensive bill.

All I can say is props to him to keeping his principles, I really hope he's be able to grow HIBP into a sustainable gig for himself and a small core team.