Please make a little effort and expand on why this article is interesting instead.
For instance, people are using micro frameworks for a reason. They want less clutter and a more direct grab on what the machine is doing. With the proposed theoretical solution we get to remove one big complexity element in the setup, it is very interesting.
I'm just pointing what's solved the problem for me, and how it can be useful for others. I'm aware there's a performance overhead.
> If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion and should be getting more experience
Conversely, there's also a huge gain in architectural simplicity which I hope you are aware of. Though you have neither acknowledged nor disproven that yet - based on your last comment, I think this is because you are an asshole. That's not an ad hominem attack, but rather an assessment of your personality after conversing with you here.
I have tried discussing with you technically, and not acknowledging other's points, then responding with "if you can't imagine my points, I can't tell you" is not how a rational, polite adult with a technical viewpoint converses with others.
This is also, what this article is actually about. It's just from a more "hermeneutic" perspective, rather than a bottom-up approach based on an analysis of the hardware.
Author here! Ha, I'm a big follower of Patrick, specially his microconfs! I didn't know he had an article an article on the subject, thanks for linking it!
However I agree with him!
What happens is that in my experience I've yet to encouter a case where what I suggest in the blog doesn't work. No doubt that there will be cases where it will not be enough. But by reading Patrick's article, clearly the complexity of the system needed to handle all the cases would be huge!
So I guess one has to compromise :)
So here's how I summarise the whole essay: "Hardware is cheap. Instead of making your software perform well, why not just throw more hardware at the problem."
I think they're arguing that you get a performance gain. Personally the systems if deal with wouldn't gain from such and optimisation as there is too little data. So I'll stick to the simplest approach.
Hi,
this answer feels immature and unconstructive to the discussion; I don't understand how and why you continue to treat my setup as "sub-optimal" when I described why it was that great, and you treated me as a "troll" while sourcing unrelated information. Could you please explain what is going on with you, and why you seem that upset by this discussion ?
No, I'm arguing against a universality of such a claim. There is a performance/complexity threshold above which hardware or hybrid solution is a way easier than a purely software one.
Right. If I understand it, it does seem to me to be an acceptable and reasonable solution, and I can't think of a better one.
But isn't it the "shared stateful development environment" the OP is saying is unacceptable? Since every developer doesn't get their own "last generation of hardware"?
But I may be misunderstanding the OP?
I am not trying to critisize what you did; I am trying to understand and possibly critique the OP. The OP seems unrealistic to me, despite it's protestations that it really isn't; but I may be misunderstnading the OP.
I don't mean to be harsh. Just reconciling the message with the article's observable facts. I agree with the message, if I applied it I would have a different stack comprised of general purpose tech choices so I could minimize dependencies. Not lots of specialized techs which is close to what we have here.
I tweeted to him to research IBM's zTPF before writing this, I guess it conflicts with the narrative he's telling though. In general, I agree with his sentiments, but there are no absolutes, only trade offs here. You can, for instance, hook a debugger into the kernel or through the hypervisor. And debugging hardware looks a lot like debugging a unikernel in that sense.
And that's why, in my original post, I wrote, "The benefit to the end user only shows up when building custom hardware, repurposing old hardware, or using a VM--things I care about but the average consumer doesn't."
Have you compared performance between your suggested solutions and what can be achieved using hardware vendor platforms? If not then whats kind of pathetic is how quickly you dismiss the people above who say the HAVE done this before.
If you have seen something we have not when it comes to performance then please by all means share it so we can learn!
Yes, tell me more about reasons I should ditch my e16 that I use for a dozen
years already, replacing it with an entangled mess of modules that don't do
what I want and I have no real control over.
Anyway, it's an abstract of a talk that's yet to be given.
Fair enough, there are some real benefits, but sometimes people do things just because they like doing them that way. The original person says "the setup I present here is simply what works well for me personally..."
Seems kinda overkill to make an entire blog post because you don't think someone did something the most optimal way ever with 1000% uptime.
edit: contrary opinions are good and encourage discussion, but framing it as "you are wrong and you need to change your mindset" doesn't necessarily support that goal IMO.
Please make a little effort and expand on why this article is interesting instead.
For instance, people are using micro frameworks for a reason. They want less clutter and a more direct grab on what the machine is doing. With the proposed theoretical solution we get to remove one big complexity element in the setup, it is very interesting.
reply