As much fun as it is to believe that, and while that may be the case sometimes, the more likely scenario is that people - even smart people - are susceptible to subscribing recursively to their own belief system because *it feels good*.
I suspect that there are intelligent people who believe in faith healing despite God's spectacular inability to heal amputees... Doesn't make them stupid, but instead makes them wishful and clearly wanting the world to be a certain way.
This. Exactly. They don't teach Computer Science, they teach programming and some of the soft areas around programming. There's absolutely nothing wrong with that - but it's not Computer Science as defined at the collegiate/university level.
Actual computer science would likely bore the bejeesus out of high school students and yield little benefit except to those already determined to pursue a CS oriented path after graduation.
Seriously. Considering the amazing amount of sh** up there for dubious, stupid, or accidental reasons - they're pissed because a PR/Goodwill gesture that will end in 9 months was launched in a way that virtually no other group of humans will be able to replicate?
Ignoring the issue that cops seem to (a)see guns when there are none and (b)lie their asses off to cover up fellow officers misdeeds - motherf***ers that intentionally send a bunch of amped up, over militarized, SOCOM wannabes to someone's house deserve either attempted murder or conspiracy to commit murder charges and sentences.
It's so godd*** chickensh** and the odds are ridiculously high (again because of endemic police problems) that someone is going to get seriously injured or killed.
Originally Seawolf reactor was sodium cooled, later replaced with more conventional water cooled reactor. It's still distinctly detectable (I've heard) in the dumping area near the Farralon's.
It's why Seawolf wasn't launched before Nautilus, even though it was laid down first.
I was mixing salt cooled with salt fueled, not you, apologies. I was lumping them together for some reason.
They did - the Seawolf (SSN-575) had a molten salt reactor in the 50's. Hell, Russian Alfas had them in the 70's/80's/90's. BTW, I heard they dumped the Seawolf's off the Farallon's at some point and replaced it with the more common water cooled version. It wasn't thorium based though.
If you're an independent software vendor (you make software intended to address markets/verticals - not a specific company) then PROJECT Managers are useful for coordinating deliveries and dependencies between teams (e.g. platform/middleware/sdk coordination) if you don't have high quality PRODUCT Managers. Sadly, finding quality product managers for an ISV is both very difficult and very expensive. Product Managers at ISVs are supposed to have domain expertise - unfortunately, many do not.
If you're a product development group that builds software either for internal corporate use, or a services group that builds software at the behest of an external customer then you're likely to use a form of Project Manager called "Product Owner" - which is supposedly some form of "Product Manager" but it really isn't. The person is basically responsible for tracking the project (the job of a Project Manager) and managing inputs taken from the customer - which makes them think that somehow they're Product Managers...
Ironically, it's much easier to come across a quality project manager today than it is to find a product manager that has any idea what their job actually is. Most modern product managers (most, not all) seem to think that they exist to 'ideate' and sit back and let people discern what exactly they meant - "What's an MRD?" "What's a PRD?" Lol...
Encrypt each user's information with an individual AES256 key. Then perimeter penetration, while still bad, is limited in scope, and while keys like that can be broken, it's expensive at a per-user basis (rather than free for millions of users.)
This requires a key management system, but they exist today. How do you avoid all the keys being stolen? That's actually vastly simpler and easier than securing the rest of the network. How to keep the thieves from cracking the interfaces/APIs to the KMS? That's actually simpler and easier than other approaches as well - and is easily monitored and requests can carry requisite AND encrypted meta-data to use against a policy engine on the front of that KMS.
Long story short - all enterprises are going to be doing something like this in 5-10 years (banks are doing it already.)
There's absolute ZERO chance he wasn't aware that there were/are significant problems in this regard at Uber. He simply didn't care enough to actually face inward. Many CEOs who were with the company before it scaled have this critical flaw.
They think that what brought them to scale was that they were almost exclusively outward facing - so they never make any effort to embrace scale properly.
All software/internet oriented companies that tend to scale very rapidly need to scale in THREE distinct ways. Many only scale in one, some scale in two, the truly successful scale in all three. Those three ways (and the order in which companies are likely to scale) are:
1. Technically - Ensuring your technology is scalable in a manner that it not revenue negative 2. Organizationally - Staffing and organizational hierarchy (adding people.) 3. Operationally - Process and delegation/responsibility (having a scalable plan.)
The vast majority of found CEOs fail to do anything other than #1, then orphan #2 to somebody they personally trust but have no actual idea as to their ability to accomplish the job.
This kind of sh** is in all the standard 'please learn from my suffering' books (such as 'The Hard Thing About Hard Things' and 'The Art of Scalability.') The problem is, most people read those books so they can randomly throw out a quote, they don't think it actually applies to them because - hey - "I'm a unicorn. My investors tell me how great I am all the time." Stop thinking you're going to write your own book someday - and execute first. Pontificate later.
If this type of separation of concerns works for you, then use it. I would argue that your architecture was poorly designing in the first place if you find yourself having to do this.
The biggest caveat? Be careful that you don't microservice and simply scale up your single points of failure. We had an engineering group break up a monolithic worker, not because they couldn't scale workers, because the lead read a book/article (I forget) from 2006 talking about how microservices are the answer to everything.
The only problem was that each of his microservices depended upon a previous service (not feeding off a queue) and when one went down, they all went down. Usually in the one not well instrumented;). Ops wasn't particular happy about this either as it made deployment, maintenance, testing, and other issues more difficult/complicated when there was no discernible benefit (it didn't let us change our instance sizes like in the article.)
Again, it may be exactly what you need - it may not. Make sure it's right for you.
This works when creating an account, not just password resetting - it's just likely to be easier with password resetting because of the similarity of process between sites.
The only way to prevent this (under any protocol) is client identification against a list of known (not a priori) clients (e.g. published client certificates.)
If you want anonymity, then you're going to take the risk of being impersonated sadly...
The hardware? YES. Sheer fscking awesomeness. The software? Really, really crap.
For all the *nix users out there who think we don't have a "Windows ME" in our history - you clearly missing out on 6.x series IRIX, especially in the early days. Crashing like SGI got $1 for everytime it crashed (and boy did SGI need the money from 97 onwards...)
I miss the SGI IR2 that was in my office (they had to put it somewhere and I won the lottery) and would love to have it heating my office today - but the software? LULZ...
...clearly these are people who know absolute f*** all about creating software.
C supposedly died long ago, and yet I find myself using it in critical situations to use libraries such as xmlsec in order to build the underpinnings of an IDP mechanisms - now, those underpinnings are used by golang, but that's been the way of software since the early 90's.
I don't dream of writing C, and I think golang,.NET, Rust, et cetera, are great and useful languages; but, just because I've got some sexy new impact wrench, I still find myself reaching for my 30 year old adjustable wrench on occasion...
...like any zealot he's easy to undermine due to his rigidity.
He does a lot of good, and that's what's important. People look at him and think "if only he was perfect" - that's missing the point. He's not perfect, he's weird, obsessed (compulsively so), rigid, and he does have ego problems they're just once removed from himself and buried in what he has replaced 'the self' with in his mind - his mission.
But that doesn't mean what he says isn't true. Much of it is.
The irony being that what RMS calls "free" doesn't mean what almost anyone else would use the term to describe.
Software, to RMS, is to be controlled absolutely with a very specific set of limitations and qualifications. It's, actually, the opposite of what anyone, in my opinion, means as 'free.' - and no - I'm not confusing 'free as in beer' with 'free as in speech' - because RMS doesn't believe in either. He believes in 'free as in whatever RMS thinks free means - usually meaning available...'
Important, borderline crackpot, zealot - the world is a better place because he's in it. Quite an amazing man actually.
If you want your files encrypted 'at rest' so that if someone comes and pulls your HDD (or software equivalent) then you can implement a strategy similar to:
(a)Encrypt all content with individual symmetric keys (one key per piece of content) - prefix each piece of content with a key ID (for key lookup on exit) - there are many ways to associate content with a key - prefixing is just the simplest (b)Encrypt those keys (which you'll need stored locally for performance reasons) with a randomly generated one-time pad stored on a removable hardware device (HSM/USB for example) (c)Decrypt files as appropriate as they exit your webserver - observe the key ID of the content, ask a process on your machine to give you the symmetric key for that ID, decrypt the content, send it back to the requesting connection.
Don't store the master key and/or one time pad locally, simply have a daemon/service/long running process on your web server require (at startup) you to plugin your hardware device (e.g. read a file from a mount that is only there when you plug the thing in.) This means that stealing the content doesn't do them much good (if they crack a key it's only for that particular piece of content, they'll have to crack lots of keys), and if they get the locally stored symmetric key file it doesn't do them much good either because you're protecting that with a VERY strong key and/or cipher which is stored air-gapped - they'd have to not only steal all the files involved, they'd have to inject into the service/daemon that issues symmetric keys.
This type of approach has performance implications of course, and to make it truly close to unbreakable requires more specifics (process injection prevention, signing and impersonation attack prevention, both on the key request side and the service/daemon unlocking scheme, et cetera) - this would be quite a discouraging system to attempt to break.
About two seconds of googling. I'm sure that, if I gave a sh** about Kurzweil, I could come up with dozens and dozens examples of his horsesh** that hasn't happened...
Slashdot Mirror
As much fun as it is to believe that, and while that may be the case sometimes, the more likely scenario is that people - even smart people - are susceptible to subscribing recursively to their own belief system because *it feels good*.
I suspect that there are intelligent people who believe in faith healing despite God's spectacular inability to heal amputees... Doesn't make them stupid, but instead makes them wishful and clearly wanting the world to be a certain way.
This. Exactly. They don't teach Computer Science, they teach programming and some of the soft areas around programming. There's absolutely nothing wrong with that - but it's not Computer Science as defined at the collegiate/university level.
Actual computer science would likely bore the bejeesus out of high school students and yield little benefit except to those already determined to pursue a CS oriented path after graduation.
Seriously. Considering the amazing amount of sh** up there for dubious, stupid, or accidental reasons - they're pissed because a PR/Goodwill gesture that will end in 9 months was launched in a way that virtually no other group of humans will be able to replicate?
Chill, the, f***, out...
Ignoring the issue that cops seem to (a)see guns when there are none and (b)lie their asses off to cover up fellow officers misdeeds - motherf***ers that intentionally send a bunch of amped up, over militarized, SOCOM wannabes to someone's house deserve either attempted murder or conspiracy to commit murder charges and sentences.
It's so godd*** chickensh** and the odds are ridiculously high (again because of endemic police problems) that someone is going to get seriously injured or killed.
As a white male I can only say - cry me a fucking river...
Don't be such an idiot next time.
Seriously...
Originally Seawolf reactor was sodium cooled, later replaced with more conventional water cooled reactor. It's still distinctly detectable (I've heard) in the dumping area near the Farralon's.
It's why Seawolf wasn't launched before Nautilus, even though it was laid down first.
I was mixing salt cooled with salt fueled, not you, apologies. I was lumping them together for some reason.
Sodium is a metal. Maybe you shouldn't have dropped. I noticed how you tried to disqualify it though.
You seem to be confused between molten salt fueled versus molten salt cooled reactors.
Uhhh... That's exactly what a molten salt reactor is...
They did - the Seawolf (SSN-575) had a molten salt reactor in the 50's. Hell, Russian Alfas had them in the 70's/80's/90's.
BTW, I heard they dumped the Seawolf's off the Farallon's at some point and replaced it with the more common water cooled version.
It wasn't thorium based though.
...you produce.
If you're an independent software vendor (you make software intended to address markets/verticals - not a specific company) then PROJECT Managers are useful for coordinating deliveries and dependencies between teams (e.g. platform/middleware/sdk coordination) if you don't have high quality PRODUCT Managers. Sadly, finding quality product managers for an ISV is both very difficult and very expensive. Product Managers at ISVs are supposed to have domain expertise - unfortunately, many do not.
If you're a product development group that builds software either for internal corporate use, or a services group that builds software at the behest of an external customer then you're likely to use a form of Project Manager called "Product Owner" - which is supposedly some form of "Product Manager" but it really isn't. The person is basically responsible for tracking the project (the job of a Project Manager) and managing inputs taken from the customer - which makes them think that somehow they're Product Managers...
Ironically, it's much easier to come across a quality project manager today than it is to find a product manager that has any idea what their job actually is. Most modern product managers (most, not all) seem to think that they exist to 'ideate' and sit back and let people discern what exactly they meant - "What's an MRD?" "What's a PRD?" Lol...
YMMV
...the risk/damage.
Encrypt each user's information with an individual AES256 key. Then perimeter penetration, while still bad, is limited in scope, and while keys like that can be broken, it's expensive at a per-user basis (rather than free for millions of users.)
This requires a key management system, but they exist today. How do you avoid all the keys being stolen? That's actually vastly simpler and easier than securing the rest of the network. How to keep the thieves from cracking the interfaces/APIs to the KMS? That's actually simpler and easier than other approaches as well - and is easily monitored and requests can carry requisite AND encrypted meta-data to use against a policy engine on the front of that KMS.
Long story short - all enterprises are going to be doing something like this in 5-10 years (banks are doing it already.)
There's absolute ZERO chance he wasn't aware that there were/are significant problems in this regard at Uber. He simply didn't care enough to actually face inward. Many CEOs who were with the company before it scaled have this critical flaw.
They think that what brought them to scale was that they were almost exclusively outward facing - so they never make any effort to embrace scale properly.
All software/internet oriented companies that tend to scale very rapidly need to scale in THREE distinct ways. Many only scale in one, some scale in two, the truly successful scale in all three. Those three ways (and the order in which companies are likely to scale) are:
1. Technically - Ensuring your technology is scalable in a manner that it not revenue negative
2. Organizationally - Staffing and organizational hierarchy (adding people.)
3. Operationally - Process and delegation/responsibility (having a scalable plan.)
The vast majority of found CEOs fail to do anything other than #1, then orphan #2 to somebody they personally trust but have no actual idea as to their ability to accomplish the job.
This kind of sh** is in all the standard 'please learn from my suffering' books (such as 'The Hard Thing About Hard Things' and 'The Art of Scalability.') The problem is, most people read those books so they can randomly throw out a quote, they don't think it actually applies to them because - hey - "I'm a unicorn. My investors tell me how great I am all the time." Stop thinking you're going to write your own book someday - and execute first. Pontificate later.
...not be good for you.
If this type of separation of concerns works for you, then use it. I would argue that your architecture was poorly designing in the first place if you find yourself having to do this.
The biggest caveat? Be careful that you don't microservice and simply scale up your single points of failure.
We had an engineering group break up a monolithic worker, not because they couldn't scale workers, because the lead read a book/article (I forget) from 2006 talking about how microservices are the answer to everything.
The only problem was that each of his microservices depended upon a previous service (not feeding off a queue) and when one went down, they all went down. Usually in the one not well instrumented ;). Ops wasn't particular happy about this either as it made deployment, maintenance, testing, and other issues more difficult/complicated when there was no discernible benefit (it didn't let us change our instance sizes like in the article.)
Again, it may be exactly what you need - it may not. Make sure it's right for you.
...and always will work.
This works when creating an account, not just password resetting - it's just likely to be easier with password resetting because of the similarity of process between sites.
The only way to prevent this (under any protocol) is client identification against a list of known (not a priori) clients (e.g. published client certificates.)
If you want anonymity, then you're going to take the risk of being impersonated sadly...
...helmet.
...any of the associated software.
The hardware? YES. Sheer fscking awesomeness. The software? Really, really crap.
For all the *nix users out there who think we don't have a "Windows ME" in our history - you clearly missing out on 6.x series IRIX, especially in the early days. Crashing like SGI got $1 for everytime it crashed (and boy did SGI need the money from 97 onwards...)
I miss the SGI IR2 that was in my office (they had to put it somewhere and I won the lottery) and would love to have it heating my office today - but the software? LULZ...
Dead man walking...
...clearly these are people who know absolute f*** all about creating software.
C supposedly died long ago, and yet I find myself using it in critical situations to use libraries such as xmlsec in order to build the underpinnings of an IDP mechanisms - now, those underpinnings are used by golang, but that's been the way of software since the early 90's.
I don't dream of writing C, and I think golang, .NET, Rust, et cetera, are great and useful languages; but, just because I've got some sexy new impact wrench, I still find myself reaching for my 30 year old adjustable wrench on occasion...
...like any zealot he's easy to undermine due to his rigidity.
He does a lot of good, and that's what's important. People look at him and think "if only he was perfect" - that's missing the point. He's not perfect, he's weird, obsessed (compulsively so), rigid, and he does have ego problems they're just once removed from himself and buried in what he has replaced 'the self' with in his mind - his mission.
But that doesn't mean what he says isn't true. Much of it is.
The irony being that what RMS calls "free" doesn't mean what almost anyone else would use the term to describe.
Software, to RMS, is to be controlled absolutely with a very specific set of limitations and qualifications. It's, actually, the opposite of what anyone, in my opinion, means as 'free.' - and no - I'm not confusing 'free as in beer' with 'free as in speech' - because RMS doesn't believe in either. He believes in 'free as in whatever RMS thinks free means - usually meaning available...'
Important, borderline crackpot, zealot - the world is a better place because he's in it. Quite an amazing man actually.
...$$$ to them.
...not the symptoms.
Crypto everywhere.
If you want your files encrypted 'at rest' so that if someone comes and pulls your HDD (or software equivalent) then you can implement a strategy similar to:
(a)Encrypt all content with individual symmetric keys (one key per piece of content) - prefix each piece of content with a key ID (for key lookup on exit) - there are many ways to associate content with a key - prefixing is just the simplest
(b)Encrypt those keys (which you'll need stored locally for performance reasons) with a randomly generated one-time pad stored on a removable hardware device (HSM/USB for example)
(c)Decrypt files as appropriate as they exit your webserver - observe the key ID of the content, ask a process on your machine to give you the symmetric key for that ID, decrypt the content, send it back to the requesting connection.
Don't store the master key and/or one time pad locally, simply have a daemon/service/long running process on your web server require (at startup) you to plugin your hardware device (e.g. read a file from a mount that is only there when you plug the thing in.) This means that stealing the content doesn't do them much good (if they crack a key it's only for that particular piece of content, they'll have to crack lots of keys), and if they get the locally stored symmetric key file it doesn't do them much good either because you're protecting that with a VERY strong key and/or cipher which is stored air-gapped - they'd have to not only steal all the files involved, they'd have to inject into the service/daemon that issues symmetric keys.
This type of approach has performance implications of course, and to make it truly close to unbreakable requires more specifics (process injection prevention, signing and impersonation attack prevention, both on the key request side and the service/daemon unlocking scheme, et cetera) - this would be quite a discouraging system to attempt to break.
My $0.02, YMMV
https://www.forbes.com/sites/a...
About two seconds of googling. I'm sure that, if I gave a sh** about Kurzweil, I could come up with dozens and dozens examples of his horsesh** that hasn't happened...
I will admit that on a few occasions I have encrypted something I could then later not decrypt... ;)