91–100 of 201 posts
Earlier quoted context omitted.
Definitely a use case for blockchain ;-) Too subtle for HN but I don’t mind.
Ah apologies for not realising this was /s, I see people who genuinely advocate this sort of stuff on HN so it went way over my head!
Then there will be more and more interesting work to do for you and others, either rediscovering and properly documenting the config, or, hopefully, architecting and coding its replacement! In the aftermath, the organization will be more robust. If it actually collapses bc of this, then it deserved to die anyway, you only helped accelerate the outcome and reduced the suffering.
Some things and processes need to be "helped to fail faster", everyone will benefit from the renewal in the end, even if most will hate it ;)
https://unix.stackexchange.com/questions/268247/recover-file...
capture packet's and see what kind of traffic it receives most commonly The modern solution would be to capture the incoming packets as a training set then apply machine learning to create a model that can perfectly recreate the outgoing packets. It’s still an inexplicable black box of course, that is the nature of ML, but at least you can run it in the cloud now.
Sorry that nobody else got it, but I like that joke. Do you think we can put some crypto in there, too?
No, plenty of us got it. It's just not funny right now.
A person is trying to find a real solution to a real problem they have. Every comment in this thread represents a potential hope that someone knows how to fix it. When someone comes in to a serious thread that is spitballing ideas and tries to make it about them by cracking jokes and being fun and clever, it's annoying. I know this because for about 8 years I was the guy trying to crack jokes in these threads.
This is not the time to make some kind of point about the state of modern software engineering - do that in a thread where people are bullshitting, not trying to work a problem. It's not ever really funny. It's noise. It doesn't help anything. It's not too subtle, it's just obnoxious.
Hire a consultant to do a full-memory dump. 1. That gives you a pretty good chance of attaching a debugger (to the offline memory file) and extracting the config from memory without touching the running system. 2. You are safe in case things turn awful, which seems likely. As for the source code, if it is an interpreted language like Java or Python or C#, your chances of recovering a fully-working source code tree ar…
Java is a compiled language; as is C#.
My advice: 1. Suggest that the work to replace it is prioritized commensurate with the business impact caused whilst re-establishing service as if it went down right now 2. Remind them that it will go down at the worst possible time. 3. Ensure your name is attached to these two warnings. 4. Promise yourself you wouldn't run your business this way. 5. Get on with your life.
I’ve been in similar situations, but never without an immediately obvious solution.
That system WILL FAIL. Even as we speak the time-to-failure is shrinking.
Even if one of the solutions described below actually works, you won’t get 100% recovery.
I recall a story years ago - from MIT, if memory serves - where they rebooted a system because they had many generations of Sybase backups. When they tried, it didn’t work. Nobody had actually tested recovering from a backup.
Grit your teeth; cover your ass; and get on with it. The clock IS ticking.
Unpopular advice: find a subtle way to make it crash, preferably stealthy, but if not possible, at least in a way that can be attributable to mild innocent incompetence instead of malice! Then there will be more and more interesting work to do for you and others, either rediscovering and properly documenting the config, or, hopefully, architecting and coding its replacement! In the aftermath, the organization will be…
You assume you not only have all the relevant information to predict the outcome, but also that your analysis of the situation is superior enough to trump those who actually own the process and will be responsible for the aftermath of your destructive actions. You demonstrate you know this by suggesting stealth.
Thinking about the fact that people like this are out there makes me paranoid about my hiring all over again.
capture packet's and see what kind of traffic it receives most commonly The modern solution would be to capture the incoming packets as a training set then apply machine learning to create a model that can perfectly recreate the outgoing packets. It’s still an inexplicable black box of course, that is the nature of ML, but at least you can run it in the cloud now.
This is not a reasonable approach at this point. You'd need to know the whole state required for processing. That includes precise time, any local storage, any remote dependencies, randomness seeds, etc. Even then, we're not even close to full synthesis from examples. This is not a modern solution. This is made up, beyond toy examples.
I'm not sure that 55 months of up-time indicates it's more or less likely to go down in the next month, but I'd guess more likely. Surely there are options, have you tried de-compiling the source from the binary? >but the physical config was accidentally overwritten and there are no backups Any old dev PCs lying around somewhere? It's worth reaching out to the old developers to see if they have a copy, in really old…
> I'm not sure that 55 months of up-time indicates it's more or less likely to go down in the next month, but I'd guess more likely. Less likely https://en.wikipedia.org/wiki/Lindy_Effect > The Lindy effect is a theory that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining l…