I like jrnl I never get to actually use it continuously…
I wrote a cron job that uses espeak and notify-send to tell me “Please make a log entry” every half hour. I was going to put it in the article, but people always give me funny looks about it so I left that part out ;-)
Maybe I will make a part II to this article.
That probably helps in the beginning but it seems like it would be very annoying and it would break concentration efforts.
I’ve solved this with a physical journal. I find it’s harder to forget when it’s in front of me. Downsides, my handwriting could be better, so it’s not the easiest thing to review. Plus it’s organised chronologically, rather than by task.
A random anonymous rumour? I hope this isn’t true, but I’d be somewhat disinclined to believe it on this basis…
That was not a particularly good article–my impression is basically “shill for datacenter container company…shills containers for the datacenter”.
“Cloud Advocate” did it for me
Point taken. I’ve removed the ‘Cloud’ bit from all my social media profiles. Dunno why I used it in the first place.
Author of said article. I’m sorry if shill for xxx is the only thing that came out of it. Certainly not my intention, it was just a brain dump, something that came to mind during a Saturday afternoon walk and I thought it might be worth it sharing this observation. Clearly, I fudged up ;)
My problems with this piece:
1) You use different definitions of POSIX throughout - the bits about DCOS refer to the idea of a general standard, while the bits about Distributed Filesystems are talking bout the difficulties of implementing actual POSIX, the real standard.
2) Lots of these things aren’t linked. The post about “Don’t build private clouds” and the posts about running kubernetes have basically nothing in common with one another. They’re just articles vaguely about cloudy things.
This bills itself as “This is a brain dump of thoughts about emergence of standards for running distributed systems” which would be a good & interesting article. In practise it seems to be more “This is some things I read recently about containery/cloudy stuff”.Which could potentially be interesting (but in this case, looks a bit shoehorned around a very poorly fitting theme).
All fair points. They certainly are/were linked in my brain. And I take it I did a poor job communicating them ;)
What alternative moniker (re POSIX) would you suggest?
I’m not sure, because I’m not 100% sure what you’re actually trying to talk about. If it’s “emerging standards for containerised scheduling”, then maybe just call it that?
So, the problem with using POSIX is that it immediately triggers in the reader (at least for me!) the standardization of a runtime environment, by defining system headers, system facilities (signals, shared memory, etc.), and system utilities (guaranteed shells and programs).
It’s basically saying “Hey, look, programmer–this is what you’ll have available to talk to. Hey sysadmin, this is what you can script with”, and then stopping.
When I read something called “dPOSIX”, I expect to see some kind of document describing:
…and all of that quite aside from containerization, and quite aside from any particular language prescription.
Your link to the modern stack anatomy shows something that is indicative of the whole problem: it’s basically a catalog of different vendors to pick from, without really explaining the problems and what motivates them. Most of the modern writing on this topic suffers from that: it supposes that microservices and containers and everything are what are needed, without really explaining under what circumstances they’re desirable.
Even when they are desirable, it’s not obvious that simply switching to a better ecosystem (cough erlang cough) wouldn’t solve the majority of pain points.
EDIT: Oh, and thank you for doing the writeup and then asking for feed back here. Good luck in future articles :)
… the problem with using POSIX is that it immediately triggers in the reader … the standardization of a runtime environment, by defining system headers, system facilities … and system utilities
And this is something I think is positive and useful for interop. Not sure why I get the impression that it sounds like something negative when I read it from you ;)
Exactly. You are already a step further, hammering out the details. I was just leaning back and squinted a bit: asking myself if I see a pattern here. Not even that I’m sure of ATM.
Standard network topologies or messaging systems programs can rely on
OK, so a few candidates in this space: CNI, Calico, Weave as well as Kafka and RSMQ and many more via http://queues.io
Standard mechanisms for handling tim
Assuming you mean ‘time’ here: NTP and if you’re fancy TrueTime
Standard interfaces for accessing stuff like block storage or whatever
REX-ray, Flocker for on-prem and no clear winner for public cloud (?)
Standard RPC mechanisms (yuck) and protocols for communicating across POSIX systems
Well here I do have a strong opinion: gRPC (/me ducks)
Hmmm, not sure if that was meant sarcastic or not but if not I take it and say thank you.
I don’t mean it in a negative way–it’s just that for me I kinda expect a discussion of problems and concrete patterns of solutions, rather than a display of different vendors solving things in different ways. If I had to put my finger on it, I’d say that it’s almost a signifier of a more academic/engineering discussion than we get just by comparing existing technologies.
Or PTP, in some cases.
No sarcasm intended! I genuinely appreciate you discussing the feedback on your article.
Thank you, @angersock for clarifying this. I’m always interested in learning and hopefully making new mistakes every day rather than repeating old ones ;)
Let’s see what comes out of it, but I’m already now grateful that due to the post I stumbled upon this wonderful site here, win!