I've proposed X talks at a few conferences. Modern X is a fairly black art but has some really nice features.
They've been 100% rejected. Linux conferences seem to only care about things like containers and automation these days.
X is like emacs. Doing it well is hard but there's a lot of power and flexibility under that hood if you spend the rather significant effort to discover it.
Its 40th birthday is coming up. Like JavaScript, CSS and PostScript, it's an imperfect system with compromises that gets the job done.
I'm probably just going to do the talk proposals as a write-up.
«only care about things like containers and automation these days»
In all fairness these seems to me the reason Linux has become more popular, rather than lets call it the “black arts” of Linux. However those with extensive knowledge of Linux seem to be highly in demand (scandinavia) because of the popularity of Kubernetes. And lets be honest, kubernetes is best operated by “hackers/makers/tinkerers” :)
It's one of the current commercial applications with arbitrage opportunities on the skills front, the other big one being AI.
The education and conference industry are driven by those deltas because that's where the lucrative jobs are
These things tend to fall in on themselves. Ten years ago for instance, large scale data stores were the rage. Everyone was rolling out petabyte solutions for megabyte problems. This went on for years before people realized it was absurd.
You're finally starting to see this in containers. It's container overload for really simple problems - like hiring earthmovers and cement mixers when your construction job is installing a bookshelf.
People want to expand their resume and use their current job as a stepping stone but they're also creating messes by using inappropriate tools.
Not sure Kubernetes hype is going down anytime soon, what is the alternative? A bunch of windows servers in a cluster? Good luck with that. One of the problems is that k8s tutorials often end up installing a silly app, and then yes… k8s is overkill for that. But autodeploying infrastructure from a repository with a private registry including other readily available tools for metrics and secrets is a big feat.
I'm having to deal with multiple applications that are essentially an API that consolidate responses from a couple of other services.
Each one is it's own container, with all the baggage that comes along with configuring your helm charts, managing egress, dealing with people who want to manage security with IP address references, etc.
Considering how simple a lot of these things are they should be a serverless function until the point is reached where there is a strategic advantage to the overhead of managing K8s.
I would say that >50% will never reach that stage and all that it is adding is overhead of configuration, and overhead of managing the container security.
Nomad[1] is one alternative that gives you the same infra-as-code warm and fuzzies but isn't a behemoth like k8s. It's simple to deploy, simple to operate and unless you're truly scaling big, it probably does everything you need.
I'm sure there are others in the same league that I don't know about. Maybe I'm just getting old but I'll never understand the rush to use k8s in teams of <100 developers.
They've been 100% rejected. Linux conferences seem to only care about things like containers and automation these days.
X is like emacs. Doing it well is hard but there's a lot of power and flexibility under that hood if you spend the rather significant effort to discover it.
Its 40th birthday is coming up. Like JavaScript, CSS and PostScript, it's an imperfect system with compromises that gets the job done.
I'm probably just going to do the talk proposals as a write-up.