Kinda reminds me of the Rational suite of programs from early 2000's that did UML modelling and other aspects of software requirements & project management.

They were some of the buggiest most crash-probe applications I've ever used, whilst the whole time their marketing trumpeted about how much better the quality of your software would be if you used them.

Oh the irony!

Although this does make you sound a bit like Wally from Dilbert, but done in the right amount I think it does make sense as taking on too much is the quickest way to never getting anything 'done'.

I like the comparison :)

Well I would say that Wally is a true pragmatist, whilst Dilbert is an eternal optimist - despite the reality of his actions never meeting his expectations. Wally has learnt his lessons unlike Dilbert.

It's kind of the cliche of work smart not hard. Easier said then done but the sentiment being to elevate your status whilst simultaneously reducing your actual deliverables (or delegating them elsewhere) - isn't that ultimately the goal of career progression. Is there anyone that does less actual "work" than a CEO.

Is this not just as simple as recommending to use an input mask, or date picker or lookup list so it's impossible to end up with an invalid value in your system?

I always took it as such.

Actually any sufficiently imaginative and slightly evil tester could have also thought of that one too, which means Apple are either missing that skillset or rushed it out.

A useful addition to the kernel could be a flag that disallows a thread from launching child processes.

Then when doing any of this risky stuff like handling gif/png/ASN.1/etc data from outside sources you can handle it in a worker thread that simply isn't allowed to launch external processes and thus sidestep a lot of these exploits.

Please get on that Apple kernel devs...

To make more money. More is more even if it is not making their most important thing make more money.

Just like Apple has not killed most of their desktop offering just because they are not a very significant part of their income.

Also a big chunk of it is probably just Tim Sweeneys personal opinions (he owns over 50% epic by himself so what he says happens pretty much). Basically he is rather strongly (and very openly) against any walled garden platforms.

> Basically he is rather strongly (and very openly) against any walled garden platforms.

Is that why he doesn't support the only real open platform on the desktop?

From his perspective Windows and Linux are equally open in that he can have his own marketplace in each.

This is about the future of the metaverse.

Longread: https://medium.com/gamemakers/the-economy-of-the-metaverse-i...

because if they won the fight it could have become a significant source of income?

The Agile Manifesto itself is actually a fantastic set of tenets. Unfortunately most people I've talked to who are trying to push 'agile' have neither read it, or have enough experience in software development or projects to understand why it's so insightful.

They do love to straw man waterfall though.

Would maybe be nice if there was a static check in C++ to verify whether something was declared on the stack, then that could be used to eliminate some of the potential RAII mishaps.

I kinda get the feeling that most of the issues with these projects are well understood and already solved.

Basically it's probably at a stage where somebody just needs to 'do it' - like on the moon as a starting point, and see what happens.

And on the moon you could park an escape ship nearby if things went really badly South, and get back home in reasonable time.

Anybody got a heavy lifter so we can start bringing up the prefabbed bits? :)

>Sending multiple queries from your web server will likely put more load on the database server than using a stored procedure.

Lots of people seem to not realize that db roundtrips are expensive, and should be avoided whenever possible.

One of the best illustrations of this I've found is in Transaction Processing book by Jim Gray and Andreas Reuters where they illustrate the relative cost of getting data from CPU vs CPU cache vs RAM vs cross host query.

Except for open and writing to files, it's about the heaviest action on a backend server.