cmdrk

Serious question, is the “source available but not open source” model working for Darklang?

It can be a little bit of both.

For what it's worth, for a time Google Chat federated other XMPP services and it worked just fine. They eventually shut that down for $GOOGLE_REASONS.

Companies aggressively going after open source 3rd party clients caused interoperability to suffer greatly. Mandating open standards can help mitigate the most user-unfriendly parts, which often turns out to be the "business model".

Who only gambles once?

name collision becomes a problem when at least one of the entities is willing to bring lawyers to bear. not saying that's happening here, but certainly more of a concern in a situation where you have a hobbyist going up against a big company.

"Fix it later", "TBD", "TODO" code should be treated as non-foundational scaffolding. Sometimes you've got to erect a temporary structure in order to get the ball rolling on building the rest of the house. Just remember to tear it down at the end.

I wouldn't be too quick to be down on Elixir. The entire BEAM ecosystem (Erlang, Elixir, Gleam, Luerl, LFE etc) are great! I think one could potentially sneak some Erlang into an Elixir job by building common libraries you want to share with other programming languages across the BEAM.

I don't get the hate for Erlang, either. It's a fun language with a community very willing to help folks out.

Someone made an effort to do a full protocol port to Erlang and I have a friendly fork I’m maintaining that makes it work better with the C version as used by Godot. Seems to work with unreliable/reliable/unsequenced packets but never tested in anger, much less production!

I don’t want to derail the thread but I have a link to my GitHub in my profile - I’m working on a few things: 1. the aforementioned Erlang ENet fork 2. My generic Erlang game server called Overworld 3. A client plugin for Godot that generates a lot of the boilerplate code needed to encode/decode messages between Godot and Overworld (protobuf used for serialization) 4. An implementation of a subset of GDScript called Gdminus written in Erlang, including a simple interpreter. The idea being to have a familiar language for Godot programmers to be able to script Overworld someday- or more generally as a toy white space significant language that runs in the BEAM.

Honestly they’re all toys right now but happy to chat more via email!

Fantastic news. I'm really looking forward to Godot 4.0 exposing more of the ENet wrapper into GDScript etc. I've been writing a game server in Erlang and very much looking forward to offering ENet as an option in addition to WebSockets!

There's always one more thing that you need to install to have a working cluster that comes out of the box in cloud.

You want networking? OK, go read about Calico, Flannel, Cilium, etc and choose one. If you didn't fully read the instructions for the networking plugin you plan to use, plan to blow away your cluster and set it back up from scratch with the correct RFC1918 address range for your network plugin that doesn't conflict with your presumably existing network. Plan to dive in and re-jigger things when you need IPv6.

You want a working LoadBalancer? OK, now you need MetalLB or PureLB, among others. Make sure your IPAM people know that you've blocked off several addresses or a CIDR range for K8S dynamic address allocation. IP's allocated via K8S aren't going to respond to ICMP packets and people will assume they're unused :)

You want ingress controllers? OK, well you can pick from Nginx or Traefik. There's actually a ton of them but those seem to be the most popular.

You want certificate management? OK, go install CertManager. You'll need to have programmatic access to your DNS providers if you want to use Let's Encrypt with wildcard certificates.

Oh, you need some kind of volume provider? Well.. there's hostPath but people generally don't recommend that for security reasons. I guess you could use the NFS volume provider but that's a little creaky for all of the usual reasons that NFS has been creaky for the last 30 years. You could go install Rook - but that's another entire complex distributed system ontop of your distributed system. (I love Ceph, BTW- but this is really overwhelming for a new person)

At this point you have essentially a working cluster, probably with a single master unless you set up something like OKD, in which case you already had to setup an entire HAProxy setup before even approaching the K8S parts.

Prepare to have a non-insignificant number of full time employees keeping the plane flying while you swap out the wings in real time to keep up with the fast K8S release cycle.

IMO, the complexity of K8S really incentivizes trashing all of your on-prem hardware and just paying for cloud. That's the end game.

I get that Oxide has a lot of ex-Joyent folks, but I can't help but wonder how much the choice of a Solaris-derived OS will hobble adoption, support for devices, etc. In many ways this feels like SmartOS all over again - a killer concept that will be eclipsed by a technically inferior but more tractable (for contributors, for management) solution.

Hello hackers. I've been working in high performance computing for a decade and I'm putting out feelers for new opportunities. I have deep knowledge of job scheduling systems, storage technologies, containerization, etc. I have a strong personal interest in the Erlang programming language and specifically building novel, mold-breaking distributed systems.

Location: Chicago, IL, USA

Remote: Yes

Willing to relocate: Within the Midwest, USA

Technologies:

  Prog. Lang: Erlang, Shell, Python

  OS: FreeBSD, OpenBSD, Linux

  Other: Object storage (Ceph), Containerization (K8S), Game development (Godot), 3D Modeling/Printing (OpenSCAD, Blender, Cura)

Résumé/CV: Available upon request

Email: username at protonmail