You're thinking of high-availability, which registers the vmx file of the VM to a physical server that isn't dead, then powers the VM back on. Whereas vMotion is either a cold or live-migration of the VM + memory state (if the VM is powered down, there is no memory state to migrate).
It's been awhile since I tested this but I had played around this on Cisco 5108 blade servers. We'd test vMotion by pulling out blades during testing to see the VM migrated. Isn't that what vMotion is for.
Thanks for the great feedback. I've updated the main page and how pages giving a bit more detail about how this service would work.
What happens: we review the DB and send you an email starting a discussion.
Is there a profile? Not currently, if there is enough of a client base in the future I will add them.
Does rejecting a date count as a strike? Yes, rescheduling does not.
We are in market discovery right now - so if there is no interest in this type of service, we have saved ourselves a lot of time. Time better spent on other ideas. If there is an interest in like you said 'low-cost real-human matchmaking', this would tell us.
Establishing trust is difficult and takes time. I don't expect it to come from anything on a website but from a few users who take the plunge, and form that bond, then by word of mouth.
Thank you for the feedback. I was hoping the tagline of 'Date, don't swipe' would do that to differentiate us against apps, but I can also add more information to differentiate us against other matchmaking services.
HN, I never had any success using dating apps and eventually found my way to using a matchmaking service to find my partner. Matchmaking services are prohibitively expensive for the general public and I'd like to see about changing that.
Please let me know any thoughts you may have as this is in the market discovery phase. Thank you.
For the tech stack:
Docker: To have self-contained services running easily.
Go with Gin web framework: For the web server, it's what I know already and thankfully it's scalable to huge levels.
Frontend: Is very basic, there is no JavaScript. Only HTML/CSS with a form that makes a request to back to the web server.
Thank you for the question, that will be left up to the clients. Trust between individuals can be built from a virtual date, so there is no problem there. If matched individuals want to continue seeing each other offline (or if both are comfortable with a offline date initially), that's great too.
I'm not huge on taking the Wikipedia entry at face value and prefer to look at the references used for the entry. In this case the reference CHAPTER 25 TYPOGRAPHY AND THE PRINTED ENGLISH TEXT, page 6, does mention that y/ye was used in place of both eth and thorn.
I used a MAC address generator to get those two, but I think two is enough to make the discussion. Current reality aside, would you be able to identify those with binary math as being on the same network device, different network devices, across the world? MAC addresses on physical NICs are provided by the manufacturer, sure you can adjust them but I think that leaves the good-faith portion of this discussion.
So if you wanted to have those to communicate no matter what you would have to have a network device state: "I'm network device A, I have this device 0C:F9:31:D2:DB:51" then another state: "I'm network device B, I have this device AB:33:C6:C6:19:74". Then whenever 0C:F9:31:D2:DB:51 wants to talk with AB:33:C6:C6:19:74 it's network device will have to just send it to the next upstream network device or if there are multiple network devices that could be upstream you could send it to them all which is just not great for security whatsoever or you now have to do a recursive lookup for whatever n devices might yet be upstream and wait for a response to see if one of those has it. Overall trying to send ethernet frames globally without an IP network sounds like not a great idea.
So it seems like the primary use of IP, as you describe, is to define a way to narrow the search to sub address groups so as to not require enumerating every address in the scheme.
Still, there's doesn't seem to be any reason you couldn't just say "device 1 gets MAC 00:00:00:00:00:01" and "device 2 gets 00:00:00:00:00:02" and the gateway controller gets :::00 and there's a special address on :::FF that can be used to talk to everyone...
Is that it? Is that all there is to IP? A loose pattern for reducing search scope, a couple reserved addresses for special cases, and a balance between address bitsize and total number of unique addresses (without requiring additional routing complexity)?
You could. Assuming all your equipment supports setting the MAC, and you make sure to operate on prefixes so you can route by prefix. There's nothing stopping you from doing so.
The reason we don't is because at the time IP was introduced, there were many alternative physical layers in active use. And while Ethernet is near ubiquitous now, what we learnt from that was that it is unreasonable to assume that all your data will go over the same physical layer. And so you need a standard addressing format that will work elsewhere too.
Nothing stops you from stripping it back locally and using MAC addresses for everything internal to you, and ditching IP, and "just" gateway to/from IP. Lots of people did gateway between different protocols before IP became the dominant choice.
But you won't get everyone else to change because it'd require new firewall and new routers, and all kinds of software rewrites, and you can see how long the IPv6 transition has taken, so you'd still need to wrap and unwrap TCP/IP and find a way to address IP for everything that isn't 100% local, and even for lots of local-only stuff unless you want to rewrite everything.
There would be potential ways. E.g. you could certainly use a few bits to say "this is external" and then have some convention to pack an IPv4 address into the MAC or let an IPv6 address overflow into the data, and use that to make gatewaying and routing to external networks easier, while everything else just relies on the MAC. But you'd still need a protocol header for other things too, and then the question is how much benefit you would gain from ditching pretty much just ARP, which isn't exactly complex, a lookup table, and replacing the IPs in the header with just a destination MAC. Because the rest of the complexity is still there.
And you can gain most of the benefit of that by getting an IPv6 EUI64 address [1]. They'll work with "normal" IP equipment, and you can optimize in your own software by having the IP stack ditch ARP lookups when they see a local EUI64 address. Whether that optimisation actually makes a difference is another question.
Then you realize doing some action ends up being O(n^2) so you add some workaround in your switch and cache some things. And you know what they say about cache invalidation. And vendor A implemented it wrong in 1993 so you have a special case for their systems. And then you want to handle abuse cases. And authentication. And you're competing against the whole rest of the world and your thing isn't enough better.
Then how do you send traffic to device1 on another network? You need globally unique addresses and hierarchy. Go back to the drawing board and come back when you’ve ended up inventing a worse IP protocol.
> It all seems so... simple
Because you haven’t even thought through basic use cases.
This kind of development is a terrible experience if the overall infrastructure isn't setup to support development also.
To have it be successful you need to not have persistent VMs that individuals are connecting to individually but rather ephemeral VMs that get created/deleted when a user needs one.
Those ephemeral VMs then need to be able to connect to the rest of the infrastructure that supports development - your artifact repositories, version control system, docker nodes, k8s clusters, etc.
Your artifact repository then needs to mirror public repositories where your source packages can be found, be it pypi, github, golang, helm, docker hub, etc. You will now have to setup your IDE or shell package manager to use this artifact repository as a proxy.
The developer tooling is usually an entire team and the infrastructure for the VMs is also.
Not an easy or cheap thing to setup. But it can be done so that the developer experience is good and so that you don't have developers running random versions of software.
Text messaging, yes is asynchronous - but you don't know what the settings of the persons device are. They could have forgotten or not have quite hours set and now it is very much a synchronous notification even if it's not synchronous communication.
Sending delayed - again things happen. I would rather send a delayed message when I am in full control of the situation rather than possibly not the next morning due to any chain of events from weather, traffic, family, etc.
I feel like this comes from my philosophy of even if individuals are correct, it doesn't mean they are kind. We live in a community with individuals and we should compromise and balance things where needed.
Some people, including myself unfortunately, are uncomfortable with unread messages. The biggest problem is, you’ll read the message, but not respond right away to avoid creating the impression “keep messaging me at this hour”. Then, when the appropriate time to answer comes, whatever your definition of that is, you’ll forget to actually answer.
I don’t have this problem with email, but messaging platforms create this with read receipts, online/offline status, etc.
Yeah but that assumes you know better than your recipient whether they should like to know that you’ve texted them. That’s a bad habit to get into.
Let people manage the settings on their own devices - whether they’ve forgotten to set their quiet hours is not your concern. Trust other people to take care of their own responsibilities. If they mess up, they deal with the consequences - it’s not your problem. If they feel the need to answer your text immediately when for you it wasn’t necessary, let them choose for themselves. Don’t presume to take that choice away from them.
It is my concern because relationships are built on trust. One can assume that everyone has a smartphone today and they know how to manage the settings on their devices. This is not the case. Technology agnostic - settings are either there or not. It is up to me as the sender and the one that would like to maintain respect, to be respectful with my communication. Which is to not begin or continue communication when it is not of the appropriate time.
Kindness starts by not immediately assuming the motivations of others to be malicious, and to understand why someone else would perform their actions. Here, it's very clear from how all paths are laid out that sending messages to you early even if you won't act on them is only ever a net-benefit if you remove your ego from the equation. Soothing fragile minds and compromise aren't the same thing.
He didn't just feel trapped and scared in the book. There was also depiction of him and Julia being kidnapped by members of the Party when they rented a room above the shop. Winston was then tortured both physically, mentally, and emotionally - he never sees Julia again (from what I recall).
He does, they just don't care about each other anymore. By thr end of the book he has been permanently defeated, he could do whatever he wanted, and he didn't want to anymore.
