Strangely enough, that's one of the big draws for me. I'm "on the spectrum" and often find face-to-face socialisation and making new contacts very draining. I tend to prefer systems to people - although as time went on, I realised one of the things I really enjoy about DN42 is making the human contacts!
After getting started with the various "auto peering" systems, I've been making much more of an effort to find individual operators[1], and add myself to the peerfinder and hang out on IRC.
It really does feel like the "old internet" and while the technology and learning opportunities are great, it's the people that really make the network.
Thanks for sharing, your projects look really neat!
Reading your page I realize I know very little about networking at that level of the stack.
That might be a good thing to dig into as a way to work around my "AI dread" (or whatever we call the feeling of "what's the point working on that project when an LLM can make it faster" I've been feeling too much lately).
That was where I started, too. I was fine with VLANs, routing in general and so on from datacenter/DevOps/Sysadmin work, but BGP and how the wider internet fitted together beyond the basics was mostly beyond me.
DN42 is a great playground for this thing - as long as you're prepared to put the effort in, it's a very friendly and helpful community. It's fun to build things for the heck of it and there's a lot of weird and wonderful stuff being worked on there.
I have also uploaded it to my TNFS site[1], which you can also access through an emulated Speccy in a browser (or a real Spectrum if you have a Spectranet/Spectranext card fitted):
Press option 4 on the main menu when it loads for recent uploads.
It's really cool and very, very smooth. I wasn't quite sure what to categorise it as on my site, so I filed it under "demos" as I think it's a very impressive bit of code :)
Thanks for sharing!
-Mark
[1]=More details at https://tnfs.markround.com or on my "DevOps for the Sinclair Spectrum" series of articles which are linked from both sites.
"We have been made aware of a potential incident and are shutting down all issuance" seems to lean towards the latter and not simply a technical issue :(
You don't get kicked out of trusted roots for non-compliance, you get kicked out for continuing to knowingly issue non-compliant certs, failing to revoke non-compliant certs in a timely fashion once discovered, etc.
Pausing issuance immediately upon discovery of a compliance issue is the absolute correct response so as long as they do their followup appropriately there is absolutely zero risk of being distrusted.
You didn't actually respond to what the preceding comment argued. They were just pointing out the distinction between Symantec and WoSign and ordinary compliance events.
That's really not good. Fortunately I'm not using any short-lived certificates like the recently announced 6 day certs, so have some breathing room. Without further details, I'd imagine anyone with a short-lived cert is getting a bit sweaty right now.
Let's Encrypt has become one of those pieces of critical Internet infrastructure that just quietly hums away in the background, the fact that they've stopped ALL issuance is deeply concerning.
Stopping all issuance is an pretty standard response if a CA thinks what they are issuing might be non-compliant in any way. It's an action we're required to take. It's not necessarily a sign of a more dramatic failure mode or key compromise. That said, the impact is the same for as long as the downtime lasts so it is unfortunate and we're sorry for the disruption.
I don't think the premise behind short lived (six day) certificates being viable is that CA issuance never goes down. Sure, the runway is shorter, but not that short. Most down time is a few hours or less, which is not a problem for six day certificates that should be renewed every three days.
Short lived certificates are optional though, so if it's not worth it to you there are longer lifetime options.
Considering the open source nature of Letsencrypt, I wonder what the barriers/costs would be (theoretically) to a wealthy benefactor who wanted to duplicate its server side infrastructure and a core staffing level of persons, and fund a "parallel" equally trusted, alternative entity with a solid governing board. Same general idea how Acton funded the Signal foundation.
Somewhere that none of the physical infrastructure/hosting environment overlapped with existing Letsencrypt stuff so that the failure of one entity would have zero blast radius affecting the other.
I know there's a long and complicated process to go through to become a trusted root CA and get your CA public cert auto-installed in every OS and browser trust store. Indeed in the early days of letsencrypt I recall their root CA certs were signed by other older root CAs.
I understand there's probably a big thorny problem of duplicating the corporate process/policies on the human level that ensure compliance, but is the back-end software pipelining stuff to CT logs not also something that can be replicated? Or is it not part of the server side stuff which has been open sourced?
Our code for sending stuff to CT logs is fully open source. But that's the tiniest slice of our compliance regime -- the vast majority of it is things like audit logging certain events, preserving audit logs in specific ways for certain amounts of time, ensuring dual-controls on all systems, being both audited and penetration tested annually, maintaining firewalls and vulnerability scanning tools, etc.
It's absolutely possible to spin up another new CA; lots of folks have done so over the years. But having time, and money, and prior experience all help a lot.
They implied it used a GCP account. It would require to give Google personal information, a phone number, and automatic payment permission. And Google not disable your account because your spouse uploaded images for your child's doctor.
I just find it incredible that in 30+ years the industry hasn't adapted one bit to the brittle failure modes of certificates. I did some subcontract work with Verisign to deploy their CA infrastructure back in the early oughties and it felt like a solution was overdue way back then. I was at Google in the teensies when gmail broke due to expired SMTP certs. WAAAY overdue by then. Here we are, a decade later and it's still the same lol.
The number one thing for me would be to standardize methods to implement soft failures. Minimally in standard clients and libraries the ability to warn when certs are nearing expiration. Cert extensions to declare lifecycle expectations and possibly even warning endpoints for notification. Basically some way to empirically look at a valid cert and know something is wrong before it fails.
There are all sorts of potential privacy/security issues with any feature built in this area so it would have to be done carefully, but I think useful improvements could easily be made.
I'd like to see better support for networks that aren't connected to the broader internet, or moving away from X.509. Note that these are contradictory. X.509 was intentionally designed to support offline verification and has a lot of elaborate ceremony to support it (like all the rest of the OSI stack). The industry just doesn't, so we get the worst of both worlds.
The NSA needed some certs to expire, so you can send plain text. Just to test it. They already have access to the CA, but, if it works easier, why not. /s
I do really enjoy working on the site, it's great to have an outlet and playground for ideas and do things just for fun. There never was (and never will be) any commercial angle for this, as I said in a footnote in the "Sloppy Copies" post, I have other motives for writing code and I appreciate I am very fortunate that I have the opportunity to be able to do that.
There's always been a tendency amongst the "priesthood" of any in-group to hoard knowledge and use it to maintain their position. So, regarding the "democratizing" of creating software - I mostly agree with you, and also agree that it's probably a good thing. I think it's pretty neat that someone without any coding experience can create their own bespoke tooling to solve a problem. I have caveats and concerns, but that's a topic for another day.
I also agree with the "that's art" part of your comment. I learned to program by reading other people's code, learned to build infrastructure by watching what my peers were doing, and learned to play an instrument by listening to and copying musicians I admired. Heck, I play in a covers band!
The problem is that this isn't just someone being inspired to create their own thing and put their own spin on it, which could be cool.
Even "nice idea, I'm going to do that and see if I can charge for it" isn't really an issue, free market and all that. This is cloning and copying on an automated, industrial scale, apparently sometimes for malicious, criminal purposes too.
I posted more or less the same thing in a comment over on lobste.rs[1] - being able to create your own bespoke software tools, without any developer experience is (mostly) a really cool thing.
This isn't someone being inspired to build something: It's the automated "drive-by" cloning and scammy, dubious nature of these clones that bothers me along with the copying of personas & identities to spam them across social media.
You're about the 5th person now in as many days who has recommended Elixir when I mentioned I was building a project in Ruby. I'll definitely have to check it out for my next project (whatever that may be!)
Can you expand on why you found it so appealing or "holy crap, this is awesome" things I should look at first ?
Not the guy, but I used rails at my old job for one and a half year, and used it in some personal projects. I looked into Elixir(and Phoenix) during this time, and Phoenix felt like it was designed for more modern websites, where RoR is built for older and tries to adapt to handle modern ones. It just feels that when you want to do something more responsive in Elixir, it's designed for it, but in Rails, it feels like you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got.
Elixir is also a very cool language in a lot of ways. I wouldn't go all in on Elixir/Phoenix, but that's because there's not a huge demand for it, at least where I reside. I would 100% consider it for some smaller projects though, if I stood between that and Rails, and I wouldn't mind having to get more comfortable with Elixir.
Edit: I haven't used Rails 8, and haven't followed the ecosystem since a bit before, so not sure how this feels nowadays. I *really* enjoy Rails backend though, but the frontend stuff never quite clicked.
Counterpoint on the "going all-in": we have a 7 year old Elixir/Phoenix project that currently sits at ~100K LOC and I couldn't be happier.
It has been absolutely wonderful building this with Elixir/Phoenix. Obviously any codebase in any language can become a tangled mess, but in 7 years we have never felt the language or framework were in our way.
On the contrary: I think Elixir (and Phoenix) have enabled us to build things in a simple and elegant way that would have taken more code, more infrastructure, and more maintenance in other languages/frameworks.
Not OP, but I made the move from Ruby/Rails to Elixir years ago, so I'll try to answer from my perspective.
Elixir is a functional programming language based on the "BEAM", the Erlang VM. We'll get back to the BEAM in a moment, but first: the functional programming aspect. That definitely took getting used to. I remember being _very_ confused in the first few weeks. Not because of the syntax (Elixir is quite Ruby-esque) but because of the "flow" of code.
However, when it clicked, it was immediately clear how easy it becomes to write elegant and maintainable code. There is no global state in Elixir, and using macros for meta-programming are generally not encouraged. That means it becomes very easy to reason about a module/function: some data comes in, a function does something with that data, and some data comes out. If you need to do more things to the data, then you chain multiple functions in a "pipe", just like how you chain multiple bash tools on the command line.
The Phoenix framework applies this concept to the web, and it works very well, because if you think about it: a browser opening a web page is just some data coming in (an HTTP GET request), you do something with that data (render a HTML page, fetch something from your database, ...) and you return the result (in this case as an HTTP response). So the flow of a web request, and your controllers in general, becomes very easy to reason about and understand.
Coming back to the BEAM, the Erlang VM was originally written for large scale (as in, country size) telephony systems by Ericsson. The general idea is that everything in the BEAM is a "process", and the BEAM manages processes and their dependencies/relationships for you. So your database connection pool is actually a bunch of BEAM processes. Multi-threading is built-in and doesn't need any setup or configuration. You don't need Redis for caching, you just have a BEAM process that holds some cache in-memory. A websocket connection between a user and your application gets a separate process. Clustering multiple web servers together is built into the BEAM, so you don't need a complex clustering layer.
The nice thing is that Elixir and Phoenix abstract most of this away from you (although it's very easy to work with that lower layer if you want to), but you still get all the benefits of the BEAM.
Something I never quite understood: differentiate between BEAM process and operating system process. The OS has launched one (in theory) BEAM Erlang VM runtime process with N threads; are we saying “process” here to try to emulate the OS process model internally within the BEAM OS process, when really we’re talking about threads? Or a mix of threads and other processes? I’m imagining the latter even cross network, but am I at least on the right track here?
A BEAM process is not an OS thread. The way I understand it, a BEAM process is just a very small memory space with its own heap/stack, and a message system for communication between BEAM processes.
The BEAM itself runs multiple OS threads (it can use all cores of the CPU if so desired), and the BEAM scheduler gives chunks of processing time to each BEAM process.
This gives you parallel processing out of the box, and because of the networking capabilities of the BEAM, also allows you to scale out over multiple machines in a way that's transparent to BEAM processes.
When I first started out with Elixir, it was more the overall architecture that first sold it to me. It is remarkably robust, my impression is that you can more or less yank RAM modules out of the server while it is running, and the last thing which will crash is Elixir. And it is absolutely top in class when it comes to parallel processing and scaleability. Not only how it does it internally, but also how it abstracts this in a way that just makes sense when you are working with it.
When it comes to web development specifically, what really got me hooked, was LiveView from the Phoenix framework. It keeps a persistant WebSocket connection to the client which it uses to push DOM updates directly. Instead of the usual request/response cycle on the client side, the server holds the state and just pushes the diff to the browser. It just made so much sense.
I am/was a huge Ruby fanboy, and I used Rails a lot and loved it (though had some criticisms around too much "magic"). I made the jump to Elixir/Phoenix around 8 years ago, and have loved it. Phoenix to me basically "fixed" all the things I didn't like about Rails (basically opacity and hard-to-find-where-it's-happening stuff due to someone metaprogramming aggressively). I will admit that I've been a functional programming fan for a very long time too. I always write my ruby code in a functional style unless there's a good reason not to (which is increasingly rare).
I still love and use ruby a ton for scripting, and still reach for Sinatra for super simple server needs, but Phoenix is my go-to stack these days.
I've also found the Elixir community to be amazing in the same ways the Ruby community is/was. It's not all roses, for example there's not as many libraries out there. Distribution is also not awesome so for example I currently use ruby or rust when writing CLIs. But for anything distributed (especially web) Phoenix is amazing.
This is a self plug, but I did a conference talk introducing Ruby veterans to Elixir/Phoenix some years ago. It's probably aged a bit, but should still be pretty accurate. https://www.youtube.com/watch?v=uPWMBDTPMkQ
The original conference talk is here (https://www.youtube.com/watch?v=sSoz7q37KGE), though the made-for-youtube version above is better because it's slightly updated, and I didn't run out of time :-)
The "one-person framework" thing is a big draw. I'm amazed at how productive I was in it, and it's not just at the code level. Even though I've been doing sysadmin/devops/architect work for over 25 years now, it's just so damn nice now not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis and deployment is largely a solved problem.
Author of the article here (hi! Anxiously watching my Grafana stack right now...)
I've only just noticed that on the Rails homepage, and while I acknowledge everyone's chasing that sweet sweet AI hype, I gotta say that's... disappointing[1]. The reason I fell in love with Ruby (and by extension, Rails) is because it enabled me as a human to express myself through code. Not to become a glorified janitor for a LLM.
[1]=Well, I had a stronger response initially but I toned it down a bit for here...
Definitely. It really makes me wish it was getting more attention - and I know I'm late to the party having only picked it back up over a year after Rails 8 was released! It's just such a smooth experience and I haven't found anything like it that compares.
The thing that really impresses me is how it's become a "one person framework"[1] and thanks also to the "batteries included" approach, you can run everything with zero external service dependencies. I have no problem with managing other services like a cache or DB, but it's just so damn nice to be able to focus on the code and not have to context switch!
After getting started with the various "auto peering" systems, I've been making much more of an effort to find individual operators[1], and add myself to the peerfinder and hang out on IRC.
It really does feel like the "old internet" and while the technology and learning opportunities are great, it's the people that really make the network.
[1]=If you're interested, I'm more than happy to peer with you - details at https://markround.com/dn42
reply