simplotek

> It particularly interested me that Twitter under Musk is trying NOT to discuss Ukraine, and PENALIZES people who attempt to interact with those outside of their general political circle.

While Musk's Twitter explicitly censors references to Russia's genocide of Ukraine, Musk himself feigns ignorance and false indignation accusing the "western press" of insisting "on pushing such a lopsided view of the conflict".

https://twitter.com/VsimPohuy/status/1645699649003569152?t=v...

If that was remotely true then why wouldn't the topic be handled at the training level? Instead, Twitter is censoring references to Russia's invasion of Ukraine through the same mechanism used to kill DMCA violations. This is not an approach motivated by "engagement".

> All social media algo timelines have an editorial voice.

Sorry, that's a bullshit excuse. Russia's invasion of Ukraine was hardcoded to be downranked like DMCA violations and high toxicity content.

This has zero do to with "editorial voice" or other bullshit excuse. This was a blatant attempt to smuther any reference on what Russia is doing to Ukraine.

I was disappointed by this article and how it omitted the fact that Twitter hardcoded how references to Russia's invasion of Ukraine should be downranked.

https://news.ycombinator.com/item?id=35410841

> Lets start by the way one has to explicitly create indexes

I never heard anyone complain that they had to explicitly create primary keys when creating tables in RDBMS.

> or query types for what one can search for.

I never heard anyone complain that they had to put together SQL queries to get data out of a RDBMS.

It seems your only complain boils down to pointing out nosql databases aren't SQL databases, and you didn't bothered to onboard onto the tool you knew nothing about. That's hardly insightful.

> We were comfortably supporting millions of jobs per day as a Postgres queue (using select for update skip locked semantics) at a previous role.

That's very refreshing to hear. In a previous role I was in a similar situation than yours, but I pushed for RabbitMQ instead of postgres due to scaling concerns, with hypothetical seilings smaller than the ones you faced. My team had to make a call without having hard numbers to support any decision and no time to put together a proof of concept. The design pressures were the simplicity of postgres vs paying for the assurance of getting a working message broker with complexity. In the end I pushed for the most conservative approach and we went with RabbitMQ, because I didn't wanted to be the one having to explain why we had problems getting a RDBMS to act as a message broker when we get a real message broker for free with a docker pull.

I was always left wondering if that was the right call, and apparently it wasn't, because RabbitMQ also put up a fight.

If there were articles out there showcasing case studies of real world applications of implementing message brokers over RDBMS then people like me would have an easier time pushing for saner choices.

> The problem with a queue on SQLite is that every successful read implies a write.

SQLite also supports in-memory databases with shared cache.

https://www.sqlite.org/inmemorydb.html

If a message queue does not require any form of persistence, writes don't sound like an issue.

> It's just odd to me that I had to make this change in the first place. I wonder how many millions of dollars AWS is raking in just because devs are unaware of things like that.

What "things like that"? Do you mean the basics of querying data with DynamoDB?

https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

This is literally the second topic in any intro to DynamoDB course, that comes right after creating your first DynamoDB table. Even that covers explicitly the basic requirements of running queries.

> It's not particularly good as KV store let alone something more serious.

Nonsense. DynamoDB is a pretty good KV store, and a killer feature as part of AWS' free tier. I dare you to present a cheaper and more performance KV store.

> (...) "desktop" (and then "laptop") are going to become niche platforms (...)

Will desktop and laptops become niche, or are smartphones/tablets finding a far broader and popular market?

You can grab your smartphone and even tablet while you're riding the subway/train/bus/whatever, but you would never use a desktop I'm that scenario. Same goes for the line in your supermarket, a quick trip to the restroom, during lunch, etc.

The smartphone didn't replaced the desktop. It replaced the newspaper/magazine/mobile phone

The truth of the matter is that the smartphone form factor is far more suited for a broader range of usages than your desktop/laptop, and the combination of those use patterns with technology limitations do warrant specialized app life cycles and UX patterns. Desktop/laptops are suited for entirely different use patterns.

> There are fewer and fewer reasons to buy new PC hardware as the decades have marched on.

If Apple provided a way to use Mac minis to serve as distributed compile caching and distributed build tool, I'd have a reason to buy some.

Also, mac minis are expensive when compared with other miniPCs in the market. There are some ryzen5/core i5 systems with 16 and 32GB of RAM shipping with Windows 11 being sold right now on Amazon for 300-500€. If all you want to do is run stuff in a browser and do work then you'd be hard pressed to find a reason to buy a Mac mini, let alone a Mac studio.

> Yes, they should have. But they did not.

That's their problem.

I fail to see how anyone could think that an intelligent answer to that issue would be "let's prevent everyone from serving static content from S3, specially those serving their sites exactly like it's advertised in the S3 how to guides", specially considering that solutions like AWS Config were simply ignored.

> These problems continue to happen

I want to continue to serve my sites from S3.

How is that my problem? Why should anyone else's oversight or even outright incompetence should stop me from using things right?

> In the grand scheme of things, I imagine that those data exfiltrations from corporate and government customers is a larger net negative for S3 (...)

Not my problem, and not S3's problem. Why are you pretending it is?

AWS is very clear in their shared responsibilities model. You, as the customer, need to have your shit together. If you do not, that's your problem. Not AWS's, and specially not mine.

Read the manual. Learn from your mistakes. Don't drag everyone else down just because you failed to read the freaking intro tutorials. And own up to your mistakes.

> You could still do that with Cloudfront.

You can also expect users to audit what they do with S3, which is something they should already be doing, and that does not force anyone to suddenly refactor their whole deployment workflow.

It makes absolutely no sense at all to argue that public access to S3 should be shut off and those who use it should start paying for CloudFront just because you feel that its too hard to check if your bucket is set to grant public access.

Also, there's already AWS Config for those who feel they need guardrails to enforce a specific configuration. AWS Config even let's you put together a Lambda to switch off public access to a bucket if some sloppy fingers indavertentlh set it on.

https://aws.amazon.com/config/

It boggles the mind how anyone could suggest with a straight face that your personal usecases should be automated away even though it screws over everyone else using it.

> If users need to expose an entire bucket to the public Internet, make them go to the effort to put a service in front of the bucket.

This would defeat the purpose of using S3 to serve static content, which is one of the main usecases for S3.

> But a lot of businesses fail for reasons other than the directors "mistakes".

All the more reason why entrepreneurs should not take lightly the prospect of filing for bankruptcy, and should focus their energy on ventures where they can minimize the chance of burning through cash right into bankruptcy. Otherwise it starts to sound like these serial entrepreneurs are just flinging crap at a wall to see which one will stick with little to no effort. This is a massive disservice to investors and employees alike, if not outright fraud.

> Really? 5 years? That seems really harsh.

Bankruptcy is not a mild consequence. People can and often are ruined by a bankruptcy, not to mention the harsh impact that it has on employees who are suddenly forced out of a job. Declaring bankruptcy should not be considered as something mundane or yet another run-of-the-mill managerial decision.

Also, not being able to found a company is not what I would call "harsh". Even in a purely capitalist view of society, a entrepreneur needs to focus on ventures to ensure they are successful, and "failing fast" does not mean it's ok to file for bankruptcies.

It would be possible to implement a solution based on locks similar to the one in place in Panama canal.

Among all the outlandish ideas, this is the least crazy of them.

> But this type of Lichtenstein work never sat well with me. The transformation is extremely minimal - minor changes to the scene, a new cropping, and conversion from ink to painting. If I handed something like that in in school I’d get eviscerated in reviews (or worse!).

If Lichtenstein applied the exact same approach to the Nike logo and plastered it on tshirts, he would be sued to bankruptcy and beyond.

To me it's obvious it's blatant, shameless stealing.

> Do you have any proof?

You only see a single and very specific brand name being pushed, and pushed relentlessly.

I repeat, this is blatant marketing even if it's a single person effort working pro bono. There is no way around it.

It might be the cynic in me talking, but I doubt this wave of Balenciaga ads is just the outcome of a random guy overusing a set of parameters. It would be trivial to find any other theme to exploit, but this is too focused on a single brand and relentlessly pushing it's name. It's guerilla marketing no matter of where you look at it.

Inefficient is not the same as problematic. They turned what otherwise would be a linear increase in memory usage into an exponential increase, which expectedly resulted in memory exhaustion problems.

There are plenty of problems to go around this approach and overall system design, but the weakest link is undoubtedly how JSON was used.

> We seem to be leaving the Industrial Age in the dust.

I wouldn't say that. My take is that producing small metalic pieces is such a trivial task nowadays that it makes far more sense to subcontract this instead of maintaining a full blown factory.

I know people in aerospace that can order custom pieces with tight tolerances in whatever alloy they choose, choose the production method and treatments, and get those pieces delivered to their doorstep in a matter of days.

A Meccano set doesn't even come near regarding demand and tolerances, and I'm sure that it can be as expensive to assemble as plain old nails, and requiring far less specialized equipment.

Lego's secondary market works for the benefit of diehard fans, but it doesn't help finance Lego the company.

The non-diehard fans can simply buy Lego knockoffs.

I'd like to support Lego but I don't get to do that by buying used sets or knockoffs, but Lego's pricing also prices me out of the market.

> The whole Balenciaga shtick felt like a metaphor for the rising tide of machine-generated content (..)

To me it just looks like plain old guerilla marketing devised to force a specific brand under the pretext of "AI".

Yes I was. Thanks for plugging the link.

> And the problem here wasn't JSON in the first place anyway

Yes it was. They stored state in a huge JSON dump which ended up working like a zip bomb by the way they had to escape a string. This alone resulted in an exponential increase in memory that quickly became a problem.

Think about it for a second: would they experience this issue if they stored an in-memory stack per user? They wouldn't.

Heck, it seems that they could live with their JSON choice if they replaced '/' with any other inescapable character and converted it back to '/' when reading.

> I think the biggest threat to the generic lines is the fact that they have to compete against other generic stuff that's produced cheaper.

I'd say the biggest threat is Lego's pricing. Even Lego's small generic sets are sold for over 20€. Even Lego fans pause when faced with that kind of price tags.

Ninjago is Lego's own production.

The Friends Lego set seems to be in line with their investment in adult demographics, in the sense of being product lines that are decorative show pieces instead of play things.

> Every time I went into a shop looking for Lego, I no longer see many generic Lego sets

That sounds like an issue with the stores you go to. Even in big department stores I see generic Lego sets (City, Technic, Duplo, etc) next to licensed ones.

> (...) slightly more than half of those homeowners haven't paid off their mortgage.

A mortgage is far cheaper than rent. Even though that hypothetical cohort still has debts to pay, their cost of living is far more affordable than renting an equivalent place on the same spot.

Also, due to the ongoing rural-urban migration and gentrification, a house bought a couple of decades ago in the outskirts tends to be far more central and with far more benefits than those in the market right now with an equivalent cost.