[HN Gopher] Show HN: Dead man's switch without reliance on your ...
___________________________________________________________________
Show HN: Dead man's switch without reliance on your infra
I wrote this Go project to implement a dead man's switch that
didn't rely on cron jobs, timers, databases, etc on the infra it
runs on. Deadcheck integrates to PagerDuty and keeps a long running
incident snoozed until expected check-in times where it'll alert
unless a check-in occurs.
Author : adamdecaf
Score : 115 points
Date : 2024-10-11 14:40 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 9dev wrote:
| I'm not sure I understand what the application itself does; as
| far as I can see, it basically configures the external services
| to carry out the actual checks and ensures this configuration is
| up to date?
|
| Wouldn't it be better to do this as part of a Terraform script or
| something? Not to take away from the project, it sure looks neat
| --just wondering if I really want to deploy yet another,
| independent IaC tool.
| hiatus wrote:
| There is a pagerduty provider for terraform, too.
| https://registry.terraform.io/providers/PagerDuty/pagerduty/...
| pigeonhole123 wrote:
| It doesn't look like PagerDuty supports sending out alerts on
| missing heart beats
| hiatus wrote:
| That's exactly how escalation in pagerduty works.
| adamdecaf wrote:
| The idea is an app checks in after scheduled jobs, which
| extends the snooze
| bryanlarsen wrote:
| AFAICT, that's a better description of the project for people
| like us. It's a way to add a missing heart beat alert to
| PagerDuty.
| adamdecaf wrote:
| It sets up expected check in times for an app/job. The job is
| responsible for checking in, but the alert will fire regardless
| of your infra.
|
| Doesn't require a start command and your infra can completely
| fail and you'll still get alerted.
| wil421 wrote:
| Any support for something besides pager duty? I work for a telco
| and there are so many different heartbeats we rely, this project
| seems very useful for something like that. The config file looks
| much better than the python/perl/bash whatever scripts we have
| scheduled on our systems.
| adamdecaf wrote:
| Yea I want to support other vendors. What do you use?
| hiatus wrote:
| Do the people on the receiving end of a pagerduty notification
| require pagerduty accounts?
| adamdecaf wrote:
| No, you can get text, email, slack, etc alerts from PagerDuty
| without installing their app.
| lopkeny12ko wrote:
| I don't understand this. You're still taking on a dependency on
| some infra, but now that infra is Pagerduty. What problem is this
| even solving
| zeroq wrote:
| It's a cloudification of dead man's switch.
| hypeatei wrote:
| That's what I thought; this tool is "kicking the can" to
| whatever third party service you're using. So, it's essentially
| just a tool that will ping stuff for you in a slightly more
| convienent way?
| adamdecaf wrote:
| Systems always rely on something. PagerDuty has been very
| reliable for years and we use it for alerting, so relying on
| it more isn't a big ask. I plan to support multiple
| integrations so you could get alerted from multiple streams.
| hooverd wrote:
| Your infra is relying on an ISP and colo and the power company
| and maybe even the Post Office. You're always relying on
| something that's not you. Personally I'd rely on pre-paid AWS.
| If all of us-east-1 goes down for days then we probably have
| bigger problems.
| ellyagg wrote:
| Now two isolated systems have to fail. Redundancy is fault
| tolerant. Nothing is fault proof.
| siliconc0w wrote:
| A possible integration are messaging apps that support send
| later. I sometimes set these up if I'm going hiking.
| adamdecaf wrote:
| Yea, and you would delete the pending message. Good idea...
| herpderperator wrote:
| So... like BetterStack's heartbeat monitor? [0]
|
| [0] https://betterstack.com/docs/uptime/cron-and-heartbeat-
| monit...
| tnolet wrote:
| or Checkly's heartbeat check
|
| https://www.checklyhq.com/docs/heartbeat-checks/
| adamdecaf wrote:
| I don't see how to configure anything but an interval (e.g.
| every N minutes) in checklyhq. Deadcheck allows you to expect
| check-ins at arbitrary times (e.g. 9am, 1:15pm, 3:15pm on
| weekdays).
|
| https://developers.checklyhq.com/reference/postv1checksheart.
| ..
| neilv wrote:
| Better Stack got on my disapproval list, for spamming me with a
| series of automated sales emails 15-20 minutes apart, which
| seemed designed that way. "One more thing.", etc.
|
| They should've sent _one_ welcome &upsell email, not several.
| And not abused contact info that was intended to reach me
| reliably and promptly.
|
| For my immediate very simple need, Uptrends didn't spam me, and
| so far they've reliably and promptly notified me whenever my
| site is down even briefly (e.g., rebooting for kernel update),
| so they'll be getting money from me as I grow.
| https://www.uptrends.com/
| herpderperator wrote:
| Sorry to hear. I didn't have that experinece; it's been
| pleasant for me (there was a billing snafu while they changed
| their plan structure but it was resolved with a support
| email) and their monitoring has been very reliable since I
| signed up a year ago. Their service also seems to be better
| (4 checks/locations vs Uptrend's 2.)
|
| Anyway, tl;dr is I never had an issue that resulted in not
| getting alerted about something that I needed to be alerted
| about, which, above all else, is the point of their offering.
| rozenmd wrote:
| The term of art you're looking for is: "heartbeat
| check"/"healthcheck", or most commonly: "cron job monitor".
| herpderperator wrote:
| Yeah I thought "dead man's switch" was such a weird name for
| this.
| LorenPechtel wrote:
| It's something that happens if you fail to take action to
| prevent it at some specified frequency. Looks a lot like a
| dead man switch to me.
| adamdecaf wrote:
| There's no crontab for banking days. Deadcheck also requires
| checkins within a delta of the expected checking time.
|
| Deadcheck also doesn't rely on your infra to alert.
| bravetraveler wrote:
| Seems very similar to a _' watchdog'_, just... reporting
| instead of doing anything about it.
| vivzkestrel wrote:
| uptime monitor?
| rozenmd wrote:
| Uptime monitors ping your server, this seems to do the
| opposite.
| turtlebits wrote:
| I'm not sure running an additional service plus a SaaS
| requirement is better than relying on infra. Standing up this
| service is going to rely on your infra. What if it goes down?
|
| If you're going to have to write a scheduled check-in anyways,
| why not use something like cronitor and reduce the complexity?
| (they host the check-in endpoint)
| psnehanshu wrote:
| If the infra goes down, you fix it while alive, otherwise the
| snooze timeout on the PagerDuty incident will expire and that
| will trigger the configured tasks. If PagerDuty goes out of
| business before that, then that's a different discussion.
| adamdecaf wrote:
| Exactly. At Moov we rely on PD, so if they're down we have
| bigger issues anyway. I plan to support additional
| integrations so a check-in could update multiple
| turtlebits wrote:
| My point was - if you're going to rely on a SaaS (Pagerduty),
| why not just use one that includes health check monitoring
| (ie cronitor) and cut out this self hosted webhook service?
| adamdecaf wrote:
| Deadcheck handles calculating the snooze durations for you.
| It could be a library as well.
| remram wrote:
| If you call this a "dead man's switch" I'd expect it to turn my
| app off when I die. E.g. "switch" something when something
| happens to a "man".
|
| Your own README links to this definition: "A dead man's switch is
| a switch that is designed to be activated or deactivated if the
| human operator becomes incapacitated".
|
| This is a watchdog timer / monitor / heartbeat, setting off an
| alert if a timer elapses.
| aftbit wrote:
| The "original" dead man switch as I heard about it was a pedal
| on a train that would apply the brakes if the operator released
| it.
|
| I've often wondered about how to reliably take software actions
| after my death or dishonor. After all, you can't really rely on
| me being able to pay my bills. I'm not looking to do something
| expensive, more like delete my accounts and send some messages.
| DowagerDave wrote:
| >> after my death or dishonor
|
| honest question: why do you care?
| vincnetas wrote:
| if you care about people that you leave behind...
| nurettin wrote:
| From experience, it is a huge inconvenience to people
| surviving the deceased leaving without any way to pay their
| debits. And if you don't care about what happens after you
| die, why did you even care when alive? Why not always be a
| dick? At least it is consistent.
| hotspot_one wrote:
| Under US law, the debts die with the person. You are
| under no obligation to repay your parent's debts. Now if
| the debt is tied to a house (mortgage) or a car (car
| loan), you might lose the house/car if you don't pay, but
| you do not have an obligation to pay. Likewise failure to
| pay will not impact your credit.
|
| So if I die in debt up to my eyeballs, and if I am sole
| signatory on those debts, I have only hurt my creditors,
| not my family.
|
| caveats-- if my family was counting on the house and I
| have an unaffordable mortgage, then yes I have caused
| them harm. Likewise other irresponsible debts.
|
| -- at the end of the chain, creditors are also people. It
| is their job to loan money at risk, so their loss is
| their problem, but this assumes I was dealing in good
| faith when I took the loan.
| groby_b wrote:
| The debts very much don't die with the person - the
| estate is on the hook to pay your debts before
| distributing to heirs.
|
| Obviously, with some "it depends" nuance - but if the
| difference between this and your world view would make a
| significant difference to your loved ones, you might want
| to talk to an attorney.
| SoftTalker wrote:
| Correct, but if you die broke, nobody else is on the hook
| to pay your debts, unless that person cosigned a loan or
| something like that.
| PeterisP wrote:
| Sure, but it would be reasonable to assume that most
| people in this forum won't die broke.
| SoftTalker wrote:
| Dying broke is a goal for many people. And a lot of
| people who earn a lot of money still end up broke because
| they never really learned how to manage it and are easy
| manupulated by "managers." See esp. professional
| athletes, celebrities, musical artists who hit it big --
| anyone who jumps from near or actually in poverty to very
| wealthy in a short period of time.
|
| I am sure that there is no shortage of developers who hit
| a big payday at a FAANG or startup and then spent like it
| would never end.
| Roscius wrote:
| Dying broke is the optimal way to die.
|
| The definition of broke could be the residual after the
| planned distributions to heirs. Or if no heirs, dying
| flat broke makes the most sense. Getting there is tricky.
| LorenPechtel wrote:
| How to pay??
|
| Two experiences with this. Companies don't particularly
| care who pays the bill. They send a bill, they get money,
| they don't care if the person who paid is the person. In
| fact, in my recent brush with such matters the company
| specifically knew the person was dead when they accepted
| the payment.
|
| What's hard is getting access to their money to pay debts
| with.
| fragmede wrote:
| I cared about these people when I was alive, why would that
| stop because I'm dead? If a meteor struck me dead in my
| bed, I'd want the survivors to be able to use my stuff to
| make their lives better.
|
| I had a friend pass and his fiance was in need of money but
| he didn't leave the password to access the crypto, so it's
| lost forever. If I die unexpectedly, I'd at least want it
| to not be lost forever.
| adamdecaf wrote:
| Yea the idea is that if your service doesn't check-in then a
| preconfigured alert triggers.
| edm0nd wrote:
| Would be cool to have some kind of "deadmans infra AI or bot"
| that would auto fund your server bills for X amount of
| additional months/years and then send out emails and post a
| notice you have died and your service EOL is estimated to be
| X or Y.
|
| I also suppose you would have to also roll in some kind of
| automated patching and etc into it which would be rather
| difficult and break a lot of thing if went bad but some kind
| of "self healing" bot could perhaps also look after this part
| to fix anything should it break.
|
| Also kinda opens up an entirely new attack vector. Threat
| actors could scan for these notices and go "hey this person
| is dead. lets hack their stuffs".
| LorenPechtel wrote:
| In the US we already have a system that could be used and
| would be hard to spoof but I am not aware of anyone
| implementing it. It has a delay of months built into it.
|
| Specifically, the Social Security Death Index. Some months
| after you die your Social Security number gets listed. It's
| meant to prevent impersonating a dead person but could be
| used to shut down accounts etc.
| xnorswap wrote:
| > I've often wondered about how to reliably take software
| actions after my death
|
| This is actually fairly simple and well understood: leave
| instructions in your will.
|
| "Notify <Provider> to delete my account" is a perfectly valid
| instruction to leave for an executor.
|
| You could leave behind a password cache with a master
| password left in your will, but I suspect much of this still
| runs on trust. I'd imagine (I haven't tried), that "X has
| died, please take action Y" is a fairly reliable social
| engineering vector if you have a convincing "proof" that X
| has died.
|
| It's worth noting that the executor isn't hard forced to
| carry out your wishes, the legal recourse for them not doing
| so comes from other beneficiaries ability to take legal
| action against the executor. If those other beneficiaries
| don't care much for enforcement, then you might prefer
| technical methods such as the submission.
| ryandrake wrote:
| I keep a "death README" with all of my online and offline
| account credentials and phone unlock codes, PII that might
| be needed to authenticate w/ various companies' services,
| copies of wills, trusts, powers of attorney, health care
| proxies and so on, copies of all vital docs like marriage
| certificate, birth certificates, home router SSIDs and
| passwords, information about doctors, health insurance,
| life insurance, all financial accounts and brokerages,
| approximate balances, bills and how to pay them, tax
| returns and how to file them, a list of recurring expenses
| and how to pay them, property w/ approximate values, and so
| on. A hardcopy is kept in our house where next of kin can
| find it if needed without knowing a safe combination, but
| casual robbers wouldn't stumble across.
| fragmede wrote:
| Why without the safe combination? Not to out myself but
| mines in a safe. If I'm dead I expect my next of kin to
| crow bar it open but if I'm not, I'd rather not have
| anybody else access that.
| echoangle wrote:
| The ,,X has died, please take action Y" thing also only
| works if the service reliably knows that the account
| belongs to X. My executor can't delete my HN account
| because he can't prove it's actually my account (without
| getting the password).
| ssl-3 wrote:
| Can it not be cryptographically proven?
|
| Leave a public key in your HN bio.
|
| And leave a matching private key and validation
| instructions in your will.
|
| If the keys match along with a death certificate, then:
| The account owner is validated as being dead.
| echoangle wrote:
| If I prepare for it, sure. At that point, I can just
| leave my password though. I was responding to the point
| that you don't need to leave the password because a death
| certificate would be enough.
| ssl-3 wrote:
| Aye, indeed.
|
| But maybe I don't want to leave my password behind
| because I'm weird that way or something, and instead I
| just want my account nuked.
|
| Cryptographic proof of ownership by the dead guy + death
| certificate should allow for account nuking, without
| allowing for a third party to do something else with my
| account.
|
| (Not that I'm worried about it, myself. In fact, I've
| found all of these dead man's switch/after-death
| automations pretty amusing every time I've seen them pop
| up in the past couple of decades.
|
| I mean: When I'm dead, my HN/Google/whatever accounts
| will become idle, and I'm dead AF so I don't care if
| someone hacks the passwords some time later. It's a non-
| refundable one-way ticket for me.)
| PeterisP wrote:
| It's not about it being impossible to cryptographically
| prove/validate it, but rather about services choosing to
| not attempt to try to validate it. They generally don't
| provide such an option, because it's tricky, somewhat
| manual, has certain costs and risks, and no benefit to
| the service provider.
|
| If some law prescribes that after following a certain
| verification process, the operator is required to delete
| the account, then that legally mandated process would
| work, but in the absence of such a law literally no
| process can be sufficient, because the operators can and
| will choose to ignore it, no matter how reliable it is.
| BrandoElFollito wrote:
| What is "dishonor" in that context? (Sorry, not a native
| speaker of English)
| meindnoch wrote:
| It doesn't mean anything, because it is wrong. The correct
| idiom is "death before dishonor", which means that one
| would choose death instead of doing something
| disgraceful/shameful.
| superb_dev wrote:
| That doesn't make sense in the context
| eep_social wrote:
| As a native speaker, I don't think the phrasing is
| idiomatic but I read it to mean imprisoned or otherwise out
| of society without actually being dead.
| aftbit wrote:
| Yes, you got it 100%. I agree, it is not idiomatic, but
| was intended to call back the "death before dishonor"
| trope that your sibling commenter mentioned. I intended
| "dishonor" to cover a number of cases short of my death
| where I might be unable to continue to care for my
| obligations for a long period of time. For example,
| imprisoned, deplatformed, critically injured in a coma,
| lost in a serious mental health crisis, etc. In some
| ways, handling that is a harder challenge than handling
| death, as there are fewer well-worn paths to follow.
| LorenPechtel wrote:
| (Native speaker) Wrong, but the intent was clearly that
| they were out of it for whatever reason. And since the true
| purpose of language is to communicate and it does that is
| it truly wrong?
| greiskul wrote:
| Google has an option for what to do with your account if you
| are inactive for a set period of time. So you can choose what
| to delete, and what to give access to someone you want. You
| can also have it send emails to up to 10 people, with
| whatever message you want.
| Muromec wrote:
| > After all, you can't really rely on me being able to pay my
| bills.
|
| Bit that's exact trigger you wat.
|
| Make something that keeps running while you pay bills and
| stops running after you no longer pay them. Pay those bills
| from your current account.
|
| Make another something that periodically checks the status of
| the first system to be operational. After sufficiently long
| periode of failures activatie the cleanup crew.
|
| Pay for the second system from a savings account, trust, llc
| or some other way that is not deactivated once you die
| IIAOPSW wrote:
| As a point of interest, trains still have these. Though it
| usually takes the form of a somewhat sporadic alarm and an
| acknowledgement buzzer. Reaction time to the buzzer somewhat
| influences the interval of the next one.
| vorpalhex wrote:
| Wire in pagerduty to whatever your action is. Ideally
| distributed on multiple infra pieces. This is just the switch
| side not the action side.
|
| Normally deadmans switches can be compromised by disrupting the
| deadman switch hardware. This removes that attack vector and
| pushes it further up the chain (which may or may not help you).
|
| It's certainly very clever.
| adamdecaf wrote:
| Thanks. We already rely on PD so preconfiguring the
| alert/snooze isn't additional risk for us.
| asdfman123 wrote:
| I thought this was going to be some way to exact retribution on
| your employer after being laid off
| John_Cena wrote:
| Naw, in the modern world only people like Bench Simmons get
| guaranteed contracts. :|
| duggan wrote:
| Routinely surprised that there are adult human beings that do
| this, but so it goes.
| asdfman123 wrote:
| I would never do it myself. Move on with your life!
|
| I did know a guy who worked at a major corporation explain
| his dead man switch like it was the most normal thing in
| the world, though. Extremely cursed.
| hinkley wrote:
| I could see people in a somewhat toxic situation do
| things like this but it's better to get out.
|
| Especially if there's some complex onerous task that
| needs to happen and you get no credit for doing it well.
| Leave, and let them find out what it's like being one of
| the other characters in It's a Wonderful Life in the
| worst timeline.
| hinkley wrote:
| That is the typical scenario in the context of software.
|
| Not that it happens often, but that the incidents are so
| memorable.
| jbverschoor wrote:
| Not to be confused with deadmanssnitch.com
| roshan8 wrote:
| Nice one! Do you have any plans to support something else apart
| from Pager duty. I have been using Squadcast.com for my hobby
| project monitoring. Integration with that would be nice. I'm open
| to create a PR if you are interested.
| adamdecaf wrote:
| Thanks, yea I'd like to support other vendors. Haven't heard of
| Squadcast
|
| I have https://github.com/adamdecaf/deadcheck/issues/12
| tracking additional vendors
|
| Edit: I'm open to a PR if you're willing. Curious, but would
| you use their delayed notification config to implement?
|
| https://apidocs.squadcast.com/?version=latest#7742a9af-29fe-...
| focusedone wrote:
| I feel like posting a software project to HN and meeting
| criticism is some near-end-stage of programming mastery.
| wcallahan wrote:
| Was thinking the same!
| encoderer wrote:
| Cool trick using PagerDuty like that.
|
| If you don't want to use a service like Cronitor, you can self-
| host this without the usual fear that an outage will also take
| down your monitoring.
| adamdecaf wrote:
| Yep. I looked at Cronitor and thought about using it, but
| direct to PD removed a step for us at Moov.
| EGreg wrote:
| Speaking of not using anyone's specific infra, we deployed
| software on blockchains to do this.
|
| We had to implement a "heartbeat" and "succession" in our
| blockchain-based solutions for organizations to control things
| together.
|
| It's part of our "application suite for organizations" where each
| one is sort of this general-purpose LEGO block that could be used
| to build a custom solution.
|
| In each case, you'd enter some parameters and create an instance
| from a Factory. We made it simple and secure for any organization
| to use this.
|
| In this specific one, ControlFactory is used to create
| ControlContract instance that can be used to control an address
| together (to sign off things collectively, like transfer tokens
| or call an arbitrary method on a different address)
|
| We had to handle what happens if the M of N people don't show up
| for a while. And we said they have to call a heartbeat() method
| every so often. If they fail to call it then control temporarily
| passes to the next group in succession, until the OGs can finally
| call the heartbeat() method again.
|
| Here is more info on the why:
| https://community.intercoin.app/t/intercoin-applications-con...
|
| And here are the rest of the blockchain apps for organizations:
| https://community.intercoin.app/t/applications-of-intercoin-...
|
| You can go ahead and use it, the factory it's been deployed on
| many EVM blockchains, at the same address.
|
| PS: fun fact, you can configure a ControlContract to also manage
| calling methods on itself, thereby creating custom "policies" for
| organizations when it comes to granting/recoving rights of other
| people to the quorum.
| joshbetz wrote:
| Very clever. I have Alertmanager in a second region so it can
| check on my first Alertmanager, but this is much nicer.
| jrockway wrote:
| I ended up going this route:
| https://github.com/jrockway/alertmanager-status
| adamdecaf wrote:
| Yea I've setup multiple Alertmanagers that all check each other
| before. That setup is useful to detecting route failures
| between sites.
| grahamj wrote:
| Neat. We use OpsGenie to monitor our alerting infra and it has
| deadman/heartbeat support so something like that is another way
| to go.
| adamdecaf wrote:
| How are they triggering the alert when the dead man's switch
| isn't tripped in time?
| cduzz wrote:
| I guess I'm an oldster shaking my fist at clouds, but ...
|
| Depending on where you live, and if it matters, give it to an
| attorney.
|
| Maybe use this to trigger the notification to your attorney, with
| instructions on how to double check things before doing things.
| danbruc wrote:
| I agree, I think people underestimate the importance of
| actually checking why the heart beat was missed, double
| checking is important. You might think you can easily click
| some button once a week and it is no problem to take some
| drastic and maybe irreversible actions after a week without any
| event. And then you get into a serious accident and end up in
| hospital for weeks. Or there is some bug unintentionally
| triggering the actions.
| cuu508 wrote:
| The configuration example in README has "Reports Finalized",
| so I assume this is more for IT infra monitoring, than for
| taking irreversible actions when you become incapacitated :-)
| xyst wrote:
| I'll use this for my next wormable vuln instead of hard coding
| DNS checks ;)
| christina97 wrote:
| I sometimes think about a "dead man service": you leave
| instructions (that you upload to the service), then when you pass
| away/etc, the service operators go and follow your instructions
| and do whatever you asked for. You'd pay some pre-agreed sum,
| possibly annuity-type subscription, and at the end we go and
| follow your wishes. Basically a technically competent will
| executor. It's probably too much to expect your family to know
| how to operate your systems. Maybe you encrypt the instructions
| and give fractional keys to family etc.
| INTPenis wrote:
| I've thought about this too but I think the type of business
| best suited to execute this is a law firm, or you know, the
| normal executor of people's wills. They just need the IT bit.
| lancesells wrote:
| This is an attorney. No subscription, no tech, no bugs, no
| encryption, less hackable.
| mhink wrote:
| > Basically a technically competent will executor.
|
| I don't think OP is saying that an attorney *can't* get these
| things done, but that it would make them feel more
| comfortable knowing that a technically competent person
| and/or service will be performing the actual actions.
|
| I do think there's a place for an attorney here, in the sense
| that they could be the trusted individual responsible for
| notifying DeadManService, Inc. that a particular person has,
| indeed, passed on and wishes DeadManService to run their
| instructions.
| ufmace wrote:
| I'm not sure what value adding a DeadManService would have
| then. Probably simpler to just have the attorney's
| instructions say, "Hire a technical consultant to carry out
| the following:".
| INTPenis wrote:
| I did something similar years ago when I was working with
| observability. Prometheus alertmanager triggers a special alert
| constantly that calls a lambda (or any webhook), so when
| alertmanager dies or is unable to alert then the lambda will send
| an alert over a 3rd party push service to notify ops that
| alertmanager is down.
|
| We called it a dead man's switch but it was really just a way to
| monitor alertmanager.
| adamdecaf wrote:
| Yea I've setup two alertmanagers that check each other before.
| It's useful for multi site deployments.
| v3ss0n wrote:
| Better have something that runs off the cloud. PagerDuty is not
| something under your countrol. A stuff as imporant as dead man
| switch should not rely on someone's service.
| tatersolid wrote:
| Okay, so now your dead man's switch depends on your home or
| colo's power, internet connection, compute hardware, storage
| hardware, network hardware, software stack maintenance, plus
| the ability to pay bills for those on time?
|
| Pre-Paying a cloud service pennies per month to do all that for
| you will likely be more reliable and much simpler.
| PeterisP wrote:
| I'd argue entirely opposite, that a dead man's switch should
| 100% rely _only_ on someone else 's services and should avoid
| any dependencies on your stuff, as something happening to you
| is correlated to something happening to things you run or own,
| and the whole point of such a switch is that it should function
| properly when e.g. all your stuff burns down or gets
| confiscated or whatever.
| ForHackernews wrote:
| I don't know about the rest of the people here, but I aim to
| outlive PagerDuty.
___________________________________________________________________
(page generated 2024-10-11 23:01 UTC)