nitnelave

It's kinda what Rust forces you to do, except that std::move is implied. Anything taken by value is equivalent to taking by && unless the type is explicitly marked as Copy (i.e. it can be trivially copied and the copies are implicit).

But yeah, in a c++ codebase, good modern practices are often verbose and clunky.

I wrote LLDAP (https://github.com/lldap/lldap) after struggling to install and configure openLdap on my homelab. It's a simple and light LDAP server that only handles users and groups (which is all you need on a homelab).

I like the expression "Bad News Fast": it gets the message across very efficiently, and if it's correctly incentivized (even just verbal praise) it can be a powerful tool to have an accurate view of the situation.

To all the great answers here, I'd add another use case: sharing a password securely with family/team, and keeping it up to date when changing. I set up my family in a bitwarden organization, and I can share a password with several people (common access to a shared account).

Yes, in new code you should be able to replace almost all new and delete with unique_ptr, vector or, more rarely, shared_ptr. Placement new can still be useful, but delete not really. There are some patterns where you use new without a delete for a global singleton that is intentionally never deleted, as well.

It's still useful to learn about the concept when dealing with old code.

Leave it to a French revolutionary to theorize about the decomposition of a group into left and right Cosettes

Have you had a look at LLDAP for a super simple LDAP backend with SQL behind? That or kanidm if you want OIDC built in.

For single operations, maybe (and still it's a style, you get used to it), but the value comes from chaining. For me, the user/ageNext example is much more readable with monads. That might also be because I'm used to monads with Rust.

You could argue that an implementation of a function to which you added asserts to make sure that logical invariants are maintained is different from the implementation without. The asserts will never trigger because they enforce properties that are always true for this function.

As a side note, I actually do use an ORM to support multiple databases with LLDAP, since it's a self-hosted application that can be used with either SQlite (for the most light-weight), or PG/MySQL for a more HA-friendly setup.

Note that if you want to use KeyCloak for the OpenID but want to still have a LDAP source of truth, you can use LLDAP + KeyCloak together, with LLDAP as the source of truth and KeyCloak giving you the fancy features: https://github.com/lldap/lldap/blob/main/example_configs/key...

LLDAP author here, I'm glad to see it's useful! A homelab is exactly the use case it was built for, and low resources is among the goals.

I'm planning on continuing this vulgarization series of "Simply explained", for instance to cover how computers communicate, keep an eye out for them!

Regarding the speculation/destroy society, I was directly answering questions that I got from laypeople around me. The consequences on society I don't think are much speculation: it's going to have a big effect on many jobs, just like AI has started to have but much more. For the philosophical questions, I tried to present both sides of the issue to show that it's not just a clear "yes or no": some people will happily argue with you about GPT being smart/skilled/comparable to a human brain. Anyway, it's just an introduction to the questions that you might have about it.

I was trying to keep the article at a level that everyone understands, from middle school up. I thought about going a bit deeper in the structure and mentioning attention, but my problem is that the intuitive concept of "attention" is quite different from the mathematical reality of an attention layer, and I'm sure I would have lost quite a few people there. It's always a trade-off :)

That's true, but they both come down to some translation from the source code to instructions: one is done in advance, and the other on the fly. I felt that the difference was not crucial for this article, but it's a good point.

Not quite yet, but I'm working on a feature that will enable that: https://github.com/nitnelave/lldap/issues/67

I got fed up installing OpenLDAP for user management, so I made LLDAP, targeting the Goldilocks zone of the article: simple to setup/manage, but powerful enough for most self-hosting needs.

I think it stands for OOPerational Surprise.

I'm still hacking away at LLDAP (https://github.com/nitnelave/lldap), a light and secure mini-LDAP server made to be easy to configure. It's targeted at self-hosters, potentially on small hosts.

We have a growing community that keeps pestering me with bug reports for the integrations with the myriads of services that can talk to LDAP, so things are going well. I'm struggling a bit to find the time to work on bigger features, though.

Since we're being pedantic, I'd point out that pulchritudinous is only used for people of great physical beauty, it's not a generic replacement for beautiful.

I hear you, I initially didn't want to reimplement a whole server for that. And there are arguments for scrapping the API I slapped in front of it and make everything go through LDAP.

Eventually, what drove me to create this is that it's targeted at small self-hosted servers that just need <20 users and _don't want to learn LDAP_. People who either don't have the background necessary to learn LDAP or don't have the time to dig into it. That's why an important part of the repository is the list of example configs for many services that provide good defaults for easily setting up the connection with LLDAP. The server admins don't actually need to know LDAP to use LLDAP.

An additional benefit is that the resulting image is small and the software is fast, because it does way less than OpenLDAP. And the API/SQL DB makes it more easy to integrate with scripts or applications that manipulate users directly.

It only implements read-only queries and bind, plus password modification. User creation has to go through the web UI or API, and custom schemas are not supported. Any esoteric feature is probably also not implemented.

I'm not a DB expert so I don't know much about stored procedures. Given that I'm trying to stay compatible with all of sqlite/mysql/postgresql, it might be difficult to rely on stored procedures horizontally.

A read-only view would be possible, the schema is quite simple. If you want, you could create an issue for that! Keep in mind that the DB schema is more of an implementation detail than a public API, so I'm not going to consider an (automatically-migrated) schema change as a breaking change.

Glad you like it :) It seems LLDAP is a bit more lightweight than you expect, though: - You could easily implement one-way replication on top, it's just an SQlite database, you can easily copy it around (or rather use the built-in `.backup`). - I'm not sure what you mean by standards compliance, but I've tried to stick to the RFCs for the small subset of LDAP that is implemented. - The setup and admin is one of the strong points of LLDAP, it's very simple :) - Additional schemas are currently not supported. We have some plans, but they're kinda longterm and definitely not any time soon. It also will probably be loosely-typed, essentially just allowing you to store arbitrary key-value pairs.

SASL is a no-go, I don't plan on supporting it, it looks awfully complex.

Something cool that I didn't highlight since it's not the main point:

The web UI uses the OPAQUE protocol to log in/store passwords, so your password is never sent to the server (it instead stores just enough information for you to provide a cryptographic zero-knowledge proof that you have the correct password). It's a bit undermined by the fact that LDAP binds use plaintext passwords, but I thought it would be cool to implement :)

I'm not sure what you mean by intermediate packages, but roughly the main dependencies are: - Backend: sea-query to build the SQL queries, Sqlx to run them, actix for the http frontend, ldap3_proto to handle LDAP protocol, juniper for GraphQL - Frontend: built on top of the Yew framework. It needs updating but the new update is a very breaking change, so it's a major refactoring.

We're going to add support for more DBs (e.g. Postgres and MySql) in the next release, I did a lot of work on the underlying libraries to make that possible.

However, mapping the tables/field names is not planned. I think it's a can of worms that I don't want to open: How do you populate the fields you don't know about but are mandatory when creating a new user/group?

You could go the way of setting up a middleman service that listens to the binary queries to (e.g.) postgres and "tranlates" them by substituting the field names, but that seems complicated.

The data is stored in an sqlite database, it's very easy to backup/copy.

I'm planning on supporting alternate DBs as well.

From the front page, I have no idea what this project offers or what it does. Why should I log in with GitHub when I don't know what it'll do?

They are actually listed on the page, ctrl-F for them. They're listed under "mixed index".