I'm leading a small infra team at a really neat company. We're rolling out mgmt config, and we want your help! You'll be writing mcl, golang, and also helping out with other company infra tasks.
Please do NOT apply if you do not have solid golang concurrency experience.
oh neat! I was a voracious Douglas Adams reader and when this game came out, I bought a copy. I don't think I could ever get it working on my machine, and I eventually gave up and have probably lost the copy.
Is it worth buying a new one and giving it a go? (I'm on Linux-only these days.)
looks like it's natively supported on Linux, and apparently runs even better running the Windows version under Proton: https://www.protondb.com/app/467290
Yup, and it's available on both Steam and GOG, usually pretty cheap. It's not running the original code underneath - some amazingly dedicated soul spent over a year porting its custom engine into ScummVM, and that's what the versions on sale now use.
And that dedicated soul (dreammaster) would really like to know who wrote the final star map puzzle, because there was sooo much matrix math his head almost exploded :)
I'm leading a small infra team at a really neat company. We're rolling out mgmt config, and we want your help!
You'll be writing mcl, golang, and also helping out with other company infra tasks.
I'm glad you enjoyed it, the person who made the video is amazing! I didn't ask for anything specific, she just did it on her own! <3
I am going through the applications... We got a good number, so if you're waiting for a reply, please forgive the delay...
What's slightly unfortunate is that a lot of people seem to have applied who clearly don't have anything remotely close to the basic requirements in the posting. This tells me they did not read it or they are bots.
But it does take time to go through those since I actually read everything and am not using any sort of ML stuff or automatic processing.
My advice to those people: Stop doing this! You're permanently burning your reputation since we now know that you're being lazy with our first impressions of you!
Yeah, sounds good until you see in practice how so many veterans are forgotten, let alone the millions without any healthcare at all. Healthcare should be a human right for everyone.
I served from 1998 to 2005. You only get "VA for life" if you incur a permanent service-connected disability. Everyone else who uses VA pays for it and are prioritized lower than disabled veterans. Retirees do not have access to VA care unless they too have a disability.
If you read this section, the author gets a lot of things right, but clearly doesn't know the space that well since there have been people building things along these lines for years. And making vague commentary instead of describing the nitty-gritty doesn't evoke much confidence.
I work on one such language/tool called mgmt config, but I have had virtually no interest and/or skill in marketing it. TBQH, I'm disenchanted by the fact that it seems to get any recognition you need to have VC's and a three-year timeline, short-term goals, and a plan to be done by then or move on.
If you're serious about future infra, then it's all here:
Looking for coding help for some of the harder bits that people might wish to add, and for people to take it into production and find issues that we've missed.
I remember seeing your presentation many years ago, at Fosdem. Very cool project and if I would have to manage classic OS deployments I would definitely give mgmt a try. That being said, I think the world is moving to more immutable systems similar to how Talos works (https://talos.dev).
I would be hesitant to claim "the world is moving to" anything, really. Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time.
And not only because of legacy systems that are hard to migrate to a modern platform. At my place of work there are workloads that can easily run on Kubernetes and it would be wise to do so. On the other hand there are systems that are not designed to run in a container and there is frankly no need to, because not everything needs to scale up and down or be available 100% of the time at all costs.
I think configuration management systems like mgmt (or Ansible and Puppet) are here to stay.
>Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time.
I think there is even a widening talent gap where you can't get people excited about doing something that maybe should have been done years ago (assuming VM -> containers makes sense for a thing). The salary needs to go higher for things that are less beneficial to the resume.
The industry at large asks most developers to stay up-to-date, so it starts looking suspicious when a company doesn't stay up-to-date too. For C# in particular, companies who have only recently migrated to .NET 5+ are now a red flag to me considering how long .NET Core has been out.
I think we have to make a distinction between "concepts" being out of date and tools being out of date. I would not consider the concept (or architectural decision) to run a system on a fleet of VMs as outdated. However tools (e.g. compilers) absolutely go out of date once they are being deprecated and need timely migrations.
In the latter case I would consider it a red flag if some long-deprecated tool turned up in the tech stack of a company, but there might be perfectly good reasons to stick to the former, a bunch of VMs, instead of operating a Kubernetes cluster.
I ran a small Kubernetes cluster once and it turned out to be the wrong decision _at that time_. I think I would be delighted to see a job ad from a company that mentioned both (common hypervisors/VMs, containers/Kubernetes) in their tech stack. Without more information I would think that company took their time to evaluate their needs irrespective of current tech trends.
I'm hiring for a company that is building a tech stack of VM's. My username at mastodon or twitter has the details, and it's about working with https://github.com/purpleidea/mgmt/
Not disagreeing with you there; technology lingers for many years. But in terms of market share and mind share, configuration management has shrank in dominance and I suspect it will continue to do so.
> I think configuration management systems like mgmt (or Ansible and Puppet) are here to stay.
I think so too, however "mgmt config" builds a lot of radical new primitives that Ansible and Puppet don't have. It's been negative for my "PR" to classify it as "config management" because people assume I'm building a "Puppet clone", but I really see it as that space, it's just that those legacy tools never delivered on the idea that I thought they should have correctly.
> I think the world is moving to more immutable systems
Mgmt doesn't care whether or not you want to build your system to be immutable, that's up to you! Mgmt let's you glue together the different pieces with a safe, reactive, distributed DSL.
Regarding your Talos comment, Kubernetes makes building things so complicated, so no, I don't think it will win out long term.
It's good to actually see even a mention of control theory.
My degree was electronics and control theory and whilst I've only had one job that involved either electronics or control theory I often think about software in these terms: I genuinely think that as an industry we need to seriously consider the systems we build in control theoretic terms.
Those who oppose the GPL are precisely the people it was designed to protect against.
I think we found a good example of your wishes here. You are against the GPL if you have an ulterior motive to make something proprietary and avoid contributing back!
Though I don't favor the GPL for my own code, I would not call it "antithesis of free software". The GPL does not impose any use restrictions, and meets a reasonable definition of a free license in other ways also.
The fact that they aren't mentioning their CLA which gives them extra rights that everyone in the community doesn't get means they're disingenuous in writing this article...
As an analogy it's as if someone was selling you a new car, but neglected to tell you that it doesn't come with a steering wheel or tires.
Be transparent and tell the whole story, don't be sneaky.
The previous iteration got killed right when it could have started gaining traction due to Microsoft's shift to "cross platform" and PowerShell Core.
The previous iteration of the Local Configuration Manager for Linux was written Python while the Windows version was a distinct codebase entirely.
But even regardless of that I have zero confidence that Microsoft can break into this space and that the Windows culture would shift in this direction. The mentality is just not there with the typical (majority of) admins.
I use a Chef setup based on how Airbnb did config management in 2013. It ain’t broke, and Ruby is an amazing language for DSLs like system configuration. I never got along with Puppet because I’m annoyed I can’t use Ruby for everything.
DSC has a really really wide variety of windows modules and unfortunately there isn't really anything comparable, Puppet and Ansible do have interfaces to DSC modules but it's kind of janky compared to just using DSC.
Huge news! I hope the new leadership remembers that keeping golang small and simple was its greatest strength. Adding generics was too much, and while I think there are some important small cases when it's valuable, in practice people are using it when they shouldn't. I'd also like to see less google control of the project.
> Adding generics was too much, and while I think there are some important small cases when it's valuable, in practice people are using it when they shouldn't.
Strongly disagree.
Beyond very simple codebases lack of generics means either duplicating a bunch of code or eschewing type safety - neither of those things are particularly attractive to me. I can't imagine writing code in a strongly typed language that doesn't have support for generics.
Even if you don't use them directly it's almost certain you're using libraries that would be forced to be less ergonomic or type safe because of a lack of generics.
We get first class functions and compiled closures with zero syntax overhead. It's entirely manageable.
> or type safe because of a lack of generics.
Case in point: sort.Slice(). It lacks ergonomics, otherwise, entirely usable.
That being said, the generic version is faster and easier to use, so they are not without purpose, but they're not fundamental to large scale design either. Used without caution they can become a burden in and of themselves.
I like them just fine, but I could completely live without them.
Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.
I guess what I'm caught up on is the idea of "usable" is entirely subjective. To my eyes and fingers, Go has been fine without generics, and since their addition I've only used them once to clean up an odd bit of code around instantiating "module" like initializers.
> and makes developing in it a miserable experience.
Subjective or not I find this a bit harsh. I spent years in an environment where C was the only option that could be used and Go is a complete dream compared to this. You may dislike the environments, you may find fault with them, but there are many examples of both of them being used to build large and complex systems that aren't completely "miserable" to work on.
I wonder if the split is something like "batteries must be included." I don't feel this way. I'm content to mine up Zinc and Copper and forge my own batteries if needed. I'm not at all put out by this.
Please search/replace all `map[x][y]` in your Go projects with `map[sting]interface{}` in order to be honest and consistent with your opinion. And explain to all your stakeholders that you have done so because generics is bad.
You have been using a generic data-structure since Go 1.0 but did not realize this.
> in order to be honest and consistent with your opinion
Did you mean replace `map[string]string` with `map[string]interface{}`? You should take a look at Go's runtime map code. This is not a "generic" data structure. It's an unsafe data structure with some thin compiler sugar on top of it which is also something worth taking a look at.
For example see how it handles something like `m["x"]` versus `m[12]` or a map using structs as keys. Put it in Godbolt then chase down the various runtime implementations you encounter. Unless I'm misunderstanding you, then I apologize, but what else did you mean?
> explain to all your stakeholders that you have done so because generics is bad.
I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers. I'm more concerned with the results they experience when they use the software.
> generic data-structure
What we call "go generics" has nothing to do with "typed go maps." To the extent that I've needed something "generic" up until they were formally introduced into the language careful interface design was enough to cover 90% of use cases. For the ones that weren't a map holding a function which wrapped a type-checked cast operation did the rest.
So all we're left with is the ability for the current go generics to automatically populate functions into your compiled image based upon instantiated and optionally constrained type usage rather than some explicit and planned mechanism implemented through interface.
Apologies for the stupid typo. Anyways, I think we will need to simply agree to disagree because of this statement:
> I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers.
I believe that difficulty of explaining code to "my peers or customers" is a basic engineering principle.
Also, I consider what the compiler does behind the scenes as irrelevant as long as you have reasonable performance and usability qualities. That's one of the fundamental principles of abstraction after all.
Btw, the inventor of the C programming language also said this. Dennis Ritchie -> "Code should be written for humans first, machines second"
Interesting that they write "I don't use Go" but are still convinced that "developing in it [is] a miserable experience". So, which one is it now? I think many people would be positively surprised if they tried Go approaching it with an open mind, but all the FUD spread on HN and similar forums prevents that...
The thing people dislike, I think, is that actually implementing generics and handling all the syntactical and compilation edge cases is complicated and ugly.
But generics as a high-level concept are wonderfully simple and useful ("let me use different types with certain code constructs without having to manually duplicate them, and stop me from doing anything that doesn't make sense"). It would be a far easier call for languages to add them if they were just a bit of syntactic sugar instead of a whole new section in the manual. (I do think adding generics was a good call; practicality trumps a fussily clean design, in my book.)
Yeah I agree. Due to Go's slow moving approach we'll see the biggest impact of generics much later, when they become more prominent in the standard library. A lot of those APIs are necessarily not type safe now and generics would close that gap quite nicely
> I'd also like to see less google control of the project.
That doesn't look like is going to happen — the leadership change announced here seems to me to continue on the Google path. Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.
> Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.
I don't believe this is true at all. They are both highly active in external Go development, far more active than I have been these past few years. (It's true that neither gives talks or blogs as much as I do.)
I understand and respect your perspective on Austin and Cherry’s involvement in the Go community. Their contributions may indeed be less visible but still impactful. However, the community’s perception of leadership is crucial, and visibility plays a big part in that. For instance your long form blog adds context to decisions you’ve taken in the past. I hope their active roles will become more apparent, fostering a stronger connection with the broader Go community.
> I'd also like to see less google control of the project.
What does this even mean? Google basically just finances the project, but doesn't really "control" anything, never mind that "Google" isn't a monolithic entity in the first place.
> They could let the community vote on who new leaders are, etc...
Who is "they"? Who is "the community"? Who qualifies for a vote and who doesn't? I never contributed any code to the Go compiler or stdlib, but have contributed to some aspects of the "wider ecosystem", including some things that see fairly broad usage, and am (coincidentally) wearing a 2018 GopherCon t-shirt as I write this. Do I qualify? Does someone who has been writing Go for a year qualify? A week? Someone who never even wrote Go code? Someone who sent in a single patch to stdlib? And how do you verify all this?
Saying "let the community vote" is easy, but if you think about it for more than a second you will realize there's tons of difficulties and that it doesn't really work. I also don't really know of any project that works like this: it's pretty always a fairly small group of "core contributors" that get to decide.
What do you mean it doesnt really work? There are a large number of programming languages and open source projects and a large number of approaches to this problem.
Python, Postgres, Rust..
A small amount of core contributors doesn't mean they all have to come from a single corporate entity either.
The notion that only Google could shepherd a programming language is hilarious.
> The notion that only Google could shepherd a programming language is hilarious.
I never said anything of the sort. I said that "let the community vote on who new leaders are" doesn't work. Python, PostgreSQL, and Rust don't work like that either; it's just members of a fairly small "core team" that can vote, or some variant thereof. I have no inside knowledge here, but I'll stake a good amount of money that the Go core team had a lot of discussions about this, and de-facto, it's more or less the same as having a vote – except maybe a bit less formal.
And Go would obviously be fine without Google, just as Rust was fine without Mozilla. But why bother? It's working fine as it is and Google wants to spend the money on developer salaries, so why not let them? People get far too hung up on "Google bad". I say this as someone who doesn't even have a Google account or Chrome installed.
> I think Googles good will in recent years is the problem.
I don't really follow what you mean with that.
People keep going on that Big Tech needs to invest more in open source projects and maintainership. "But no, not like that!" Hmkay...
In the end, the people doing the work get to decide. That's how it works everywhere. Go originated at Google and many (though far from all) of the core people working on it are still paid by Google. The people doing the work seem to have no problem with this relationship, so standing on the sidelines shouting "no no, do the work differently!" is not really brilliant IMO.
And as I said, I don't see Google "controlling" anything. What does that even mean? Larry Page deciding what happens in the next Go release or something?
It is tempting to look at the election in the US and ask what will determine the outcome - who has the policies that will make peoples lives better or who can come up with the most effecive derogatory nickname for the opponent and stoke the most fear.
I've worked at Google, I've used Go for about 8 years at this point and I've met a few of the key Go figures at some point. I have to say that I have _no_ idea who would be best to run the project. And neither do you.
This isn't politics where the winner gets to vanquish their enemies and make themselves and their friends and family rich. It's developing and maintaining a programming language. The only real reward you'll get is admiration IFF you do a good job. Do a crap job and you ruin the project and/or become a pariah.
I would rather have those people who make up the core leadership tell me who should run the project since they not only know the technology, but they know the people and they know how to provide continuity. Continuity and discipline is all-important.
I'd prefer it if whoever runs the project works for Google since that is where Go was born. In part for continuity reasons and that Google has proven to be a very good home for Go, but also because it is good to have direct access to an organization that has resources to support you.
Mini hiring video about the job:
https://mastodon.social/@purpleidea/113075362647034036
I'm officially hiring!
Want to work for me improving mgmt config and using it to do infrastructure automation? https://github.com/purpleidea/mgmt/
I'm leading a small infra team at a really neat company. We're rolling out mgmt config, and we want your help! You'll be writing mcl, golang, and also helping out with other company infra tasks.
Please do NOT apply if you do not have solid golang concurrency experience.
Fully remote. More details here:
https://miaplaza.recruitee.com/o/infrastructure
Feel free to ping me if you have questions!
reply