Inception Rejection
(Why the dreams-within-dreams in the movie "Inception" could never happen as shown even if the technology worked as described.)
((Though this would have been a lot easier to do as an essay, the poeming was challenging and fun.))
The basis of "Inception", although it may leave you confused, is that in the brain while waking only five percent is used.
To process things in daily life this certainly has been plenty. That mental surplus means our dreams go faster by a factor of twenty.
The magic device that drives the film (the idea's at least sixty years old) allows dreams not only to be observed but changed as they they unfold.
When this device is dreamt of, unlikely as it seems, if used like in the real world, the result is dreams within dreams.
Inception's filled with dreams in dreams, each twenty times faster than before. Unfortunately, here's the problem this movie does ignore:
Level one's dream factor is twenty; four hundred at level two. Level three's factor's eight thousand - two hours there is less than a second for you.
In the first dream at twenty times the brain goes at full speed; there's no excess capacity that the next dream down would need.
A dream in a dream can only be dreamt by the real brain at the top. The faster brain that's in the dream is no more than a prop.
To go faster by four hundred, the dream at level two would need a brain twenty times as fast as the one you carry with you.
So the speed of the dreams that are further down could be no faster than the dream that's first. A quite ingenious plot device here has its bubble burst.
I have old paperwork for significant shareholdings in 3 extinct companies I worked at that tried to outsource all development. Out of 6 or 7 major outsourced projects I was involved in or responsible for, only one could be classified as "successful", a couple more ended up with somewhat usable code/systems that met requirements (mainly due to them being poorly written) but which were unmaintainable and replaced within 12-18 month timeframes. The rest were all complete throwaways and represent low 7 figures worth of money completely wasted (with, perhaps, the exception that I and others learned new ways that outsourcing can go wrong and a bunch of useful war stories.)
As I see it, when (most) companies have an in house dev team, what they _actually_ have but do not understand (at senior management levels) is a Solution Architecture and System Design team, a software development team, and a QA and Test team - all of which are likely to be the same people who do not have those roles listed on any org chart or job description.
Realistically, the best you can possibly hope for is to outsource the non team lead parts of the software development, and _maybe_ some of the testing work (if your in house QA is on top of things).
The "50% cheaper" off shore dev team is, in my experience, at best capable of doing something under half of what a typical in house dev team does. Given that the management and oversight of the off shored development and testing work needs to be done in house, and cannot possibly be done in the company's best interest by the offshore devs or an outsourcing company, you are going to need to retain in house staff to do those roles - and they're going to need to be the more experienced and more senior people from your existing in house team.
Anybody who thinks "half the hourly rate" translates to "half the cost for the entire project" has clearly never done it before. At best, you are going to be able to outsource 50% of the work. So at best you can save perhaps 25% of the development costs, and that requires you to have some very good inhouse technical skill who are experienced in system design and architecture, writing unambiguous requirement docs and User Acceptance Tests, and who have seen the sort of "tricks" outsourced developers do to pass tests instead of actually writing secure stable and maintainable systems.
We gave the external team explicit instructions that they should continue to use the existing framework, as they'd asked to rewrite it in a newer framework. Just add simple features and maintain what's there.
The project comes back very troubled, barely working and just feels janky. Things that have worked fine for a decade are broken. None of us look at the code, as that was the goal, but instead we just keep sending back revisions. Every time they fix something, something else breaks.
Well after multiple rounds of back and forth failing to get a very basic form working correctly, we decide to dig in and fix it ourselves. We discover that instead of using the existing framework, they'd written a giant janky adapter layer translating their framework of choice to satisfy the existing framework. It completely undermined the point of keeping the existing framework which was to keep changes to a minimum. We wanted maintenance, not a rewrite.
The whole codebase was a confused mess no person in their right mind would want to maintain. I have never been so frustrated in my life. After we confronted them about it, and they adamantly defended it, we ended up firing them.
delifue•7mo ago
The correct way of fixing SQL injection is to use prepared statement and parameters.
Other examples: Windows allows software to do bad things, having no proper permission control (to maintain compatibility). Antimalwares scan applications by matching patterns of virus code, but has many false positives and false negatives. This causes many troubles (kill innocent software, scanning cost performance, etc.) because it does not fix from root case (proper permission management).
userbinator•7mo ago
jagged-chisel•7mo ago
ameliaquining•7mo ago
jagged-chisel•7mo ago
ameliaquining•7mo ago
matsemann•7mo ago
Php users tried with addslashes(), realized there are cases it can't handle, made a sql variant in mysql_escape_string, realized it's open for abuse since you can mess with the character set. Then made mysql_real_escape_string and later mysqli_real_escape_string, which even them have some flaws depending on the db charset.
So if you find the concept easy, I'd wager it's because you don't handle some exploit path.
abanana•7mo ago
Several years ago, I showed a colleague that in the simple file-storage web app he'd written, just changing part of the URL from e.g. "/folder/23/" to "/folder/23 OR 1=1" would show every file ever uploaded by any user, ever. (He hadn't even added a clause to limit it to the logged-in user, but that's another matter.)
He was taking that folder number from the URL, passing it through mysql_real_escape_string() because he'd simply learned by rote that that's how you make any user input safe, then concatenating the SQL, without putting quotes around the variable in the query because it's meant to be an integer: "...WHERE folder_id = $folder_id".
It didn't matter how I tried to explain things, he just didn't get it. He still works there (I left, I'd had enough) - his job title is "senior developer".
userbinator•7mo ago
That's a common problem. A lot of people don't realise that if you accept user input, you can get every single byte and sequence of bytes possible. Validating that a parameter is an integer ([0-9]+) is even easier than escaping.
his job title is "senior developer".
Likely that's purely because of how long he's worked there, not how much he actually knows.
rileymat2•7mo ago
If we are talking about ransomware running in a user context, it'd have the permissions of the user to encrypt anything the user has access to.
If we are talking about extreme sandboxing, you make it hard for programs to work together without permission fatigue, or the user having no idea what they are allowing or getting used to allowing all permissions.