Hacker News new | past | comments | ask | show | jobs | submit | galdor's comments login

This space may be well established, but it still does not fullfill all needs. For my own:

- NGINX does not support ACME, and I'm fed up with dealing with Lego and other external ACME clients. Also the interactions between locations has never been clear to me.

- Caddy plugins mean I have to download xcaddy and rebuild the server. I really do not want to rebuild services on my servers just because I need a simple layer 4 reverse proxy (e.g. so that I can terminate TLS connections in front of my IRC server).

So I'm building my own server/reverse proxy (https://github.com/galdor/boulevard). Competition is good for everyone!


HA Proxy already exists and will do both. You can even redirect Layer 4 HTTP/HTTPS Ports to another reverse proxy server if you want to get inception levels of crazy.


Sure, but c'mon, HAProxy is the 800lb gorilla in this case when you just need something simple.


FWIW, it doesn't handle your use case of Layer 4, but for the people at Layer 7, another option is good ol' Apache: it is so flexible and extensible it is almost a problem, people tend to not know it long ago went event-oriented with mpm_event, and it supports ACME internally (as a module, but a first-party module that is seamlessly integrated). (I do appreciate, though, that it is critically NOT written in a memory safe language, lol, but neither is nginx.)


Layer 4 and 7? HAProxy will do that no problem.


> Competition is good for everyone!

Definitely!

But see how in your project the very first paragraph explains why it exists, and what it does differently. This is what I think is missing from Dito. It doesn't have to be super in depth.

I do disagree with your argument against Caddy, though. How often do you realistically rebuild your services? If it's anytime you would upgrade, then it seems manageable. xcaddy makes this trivial, anyway. Though you don't really need to use it. There's a convenient pro-tip[1] about doing this with a static main.go file instead.

Good luck with your project!

[1]: https://github.com/caddyserver/xcaddy#warning-pro-tip


Boulevard has to be compiled at some point. Wouldn’t it extremely simple to setup a GitHub Action to build Caddy in the way you desire?


Yes, it can be compiled and packaged so that I can one day install it as any other package, in my case on FreeBSD.

And of course it's not just about avoid recompilation, there are a lot of features I want to add.


> - Caddy plugins mean I have to download xcaddy and rebuild the server. I really do not want to rebuild services on my servers just because I need a simple layer 4 reverse proxy (e.g. so that I can terminate TLS connections in front of my IRC server).

I mean, you don't havse to "rebuild services" -- if you need the plugin, just deploy the binary with the plugin. It's not like it changes (other than upgrades, which you'd do regardless of the plugin).


If the plugin is downloadable from caddy's site, it can also be updated in place along with the caddy binary. (There's an option to keep the same plugins)


> Caddy plugins mean I have to download xcaddy and rebuild the server. I really do not want to rebuild services on my servers just because I need a simple layer 4 reverse proxy

That's why containers exist.


You would be surprised by how many infrastructures have software running without any container :) I'm running FreeBSD on my servers so containers are out, but even if I was Linux, why would I use containers for base services?


> why would I use containers for base services?

This is a supported feature of podman which can generate systemd units to make system services.

But, as for advantages (system has some of them too), sandboxing, resource constraints, ease of distribution, not being broken by system updates (glibc update on RHEL broke some Go binaries iirc).

My rule of thumb is that only system software (e.g. DE, firewall, drivers, etc) belong on the base system, everything else is going in a container. This is very easy to do now on modern Linux distros.


DE?


Presumably “desktop environment” e.g. KDE plasma or Gnome. You don’t really want to be containerising those.


Yeh. I know people have run DE/Compositors in containers, but it doesn't really have any benefits outside of testing.


I think they meant use a container to build caddy with xcaddy.

It is essentially a one liner to cross compile caddy for all your use cases as long as you have access to a container runtime to build it.


You can use kamal-proxy, recently released. It handles SSL and zero downtime deployments. It’s small and from what I checked the code is easy to read and understand.


Which Caddy plugins are you using?


Microsoft Entra having first class support for OIDC really helps; I remember seeing a decision diagram in their documentation recommending using OIDC for new projects, it can help negotiating. Google Workspace also works just fine with OIDC, and so does Okta.

I've been told that the only source of problems is going to be companies using Shibboleth, even though there seems to be an OIDC plugin.


OWASP recommendations for Argon2id are 19MiB memory, iterations 2, parallelism 1. And following OWASP is not only a good idea for security but also makes it easy to justify with IT security, compliance, etc.


It's been a little while since I've looked carefully but I would not take OWASP especially seriously on matters of cryptography. It helps to understand that OWASP is more of an affinity group than a carefully structured authority, and some of its official recommendations are more akin to wiki pages than real standards.


Could you distribute it? I'm not a huge fan of ASDF complexity and have had many headaches trying to make some custom components work. I would welcome any simple alternative, even though I will probably end up writing my own.


In technical organizations (all organizations really), simplicity is also a hard sell: you need people in charge with the ability to say "no" to a lot of ideas. And no one wants to be on the receiving end of a "no".

Those who favour simplicity will always be outnumbered, and their position will be untenable unless the entire top management team agrees. Good luck with that.

It is also one the reasons why the BDFL model works so much better: you need the ability to say "no" a lot.


I’ve not found this to be the case.

I’ve argued at work before for us to deliver a simpler subset of a feature, that delivers most of the value sooner, then to assess later whether we actually need the rest of the feature.

This is also why I’m confident about my continued employment in the age of AI: CEOs are always asking how we can deliver faster. They might not be able to afford more software engineers, but they can always use more.


In kitchens as in plumbings:

- There are rules, and clear established practices that allow you to follow these rules. In software the rabbit hole goes so deep that your average developer cannot even be aware of all the risks.

- You do not have to rely on millions of lines of code you have no control on.

As a simple example, if you are using network communications, you are probably using OpenSSL, GnuTLS or one of the few other TLS implementations. All of them have regular security issues, and simply selling support on an Open Source software you built using one of them will make you liable for these issues. There is no choice: you need TLS, and you're not going to implement it yourself. What are you supposed to do?

The fact that a solo developer selling 100€/month of support is treated the same way than a billion dollar company demonstrates the complete insanity of this act.


Most regulations work like that. For example, just because you are cooking in a food truck does not exempt you from basic hygiene requirements. Also CRA will not put you into hot water because of a vulnerability in your dependencies. You may get in trouble if you refuse to provide a security update during the lifetime of your software product.


For some reason I can't seem to open the text right now, but from my previous reading I remember a smaller variant of annex V for small businesses. So the solo dev is not treated the same.

As I read it, and with the caveat that the exact requirements are not yet determined: You will need a SBOM stating you use openssl, and how you plan to update openssl if it contains security bugs.

Update: found it, paragraph 46a: In relation to small and micro enterprises, in order to ensure proportionality, it is appropriate to alleviate administrative costs without [...]


> The fact that a solo developer selling 100€/month of support is treated the same way than a billion dollar company demonstrates the complete insanity of this act.

But they're not treated the same way. Both by the law itself and the standards courts and regulatory agencies use throught Europe.


The text of this act treat them the same way unless I'm missing something (feel free to point me the text saying otherwise). A sane legal text would put in place thresholds with different levels of expectations and liability depending on the size of the company, who you are selling to (companies or individuals) and its revenues, respecting the principle of proportionality.


The principle of proportionality is a mandate of courts and regulatory agencies too. You're implying that they would act in bad faith by putting all their might on small/one-person businesses, while it's just not the case with EU bodies.


It seems the author is refering to the EU Cybersecurity Act that should be voted early 2024.

The last draft clearly excludes open source software as long as there is no commercial activity associated. If voted in this state, it won't affect the vast majority of developers releasing some code under an Open Source license. But it will wipe out all small businesses: if you're a solo company selling support or feature development on some Open Source software you wrote, paperwork and liability are just not worth it.

And good luck selling anything relying on existing Open Source libraries, because you're now liable for them too. Given the cost of a security audit, you may as well stop trying and just sell SaaS (which is explicitely excluded from the bill, funny).

Larger companies of course won't care and will continue shipping buggy software riddled with security holes because they can afford the paperwork and absorb the legal risk.


> as long as there is no commercial activity associated

My recollection, from previous discussion on HN, is that the definition of "commercial activity" is far more broad than the open source community would like it to be. And by "open source community", I mean the people that run various foundations and non-profits and things like that.

I don't think that throwing up a virtual tip jar on your Github page counts, but offering paid support would. If you collect telemetry and then sell "usage insights" that would also count as commercial activity. Advertising on the download page is commercial activity. If you have a Patreon account? I actually don't know about that. Anyone know?


Correct. I would be perfectly fine with some amount of control and liability proportional to the size of the company, excluding tiny ones as it is often the case.

With this new act, even selling 100€/month of support for a piece of software you are contributing to makes you subject to the full force of the bill (and the full force includes scary numbers, millions, with zero information on how precise amounts will be calculated).

We can only hope that it is not voted in this sorry state.


Yes, proportionality, or at the very least some sort of clarity on where the line is drawn. Nobody wants to be the test case that determines if something is commercial or not.

An acknowledgment that it costs some small amount of money to host a website for the code, or that you may from time to time want to hire someone to do something specialized (design a logo?) and need to raise some amount of money for that to happen.

By world-wide standards (though not necessarily by Silicon Valley standards) I am fairly wealthy and thus could afford to support a completely commercial-free open-source project out of my professional salary. And this would make my project liability-free in the EU. But someone else, who didn't grow up in the USA at a time when university tuition was cheap, would not be able to do the same and their otherwise-identical project is subject to legal liability.

How is that fair? Isn't this just going to further concentrate open source contribution and leadership in a handful of rich countries (that are mostly not in the EU)?


He’s probably talking about the Product Liability Directive reform.


Normal Computing | https://normalcomputing.ai | New York or full remote | Full Time

Normal Computing is making AI both scalable and useful.

We are looking for a senior web backend developer (8+ years experience ideally in Python, PostgreSQL) to join the Core Engineering team and work on a variety of projects.

Pros:

- Full remote.

- A lot of autonomy with a focus on deep work and minimal process.

- Working on applications more interesting than the average CRUD software.

If you like to build and have the skills that go with it, you may like it here. Contact us!

https://jobs.ashbyhq.com/Normal%20Computing%20AI/2cb7e085-a0...


I might be missing something, but the appeal of gradual typing to me is that I can mostly type functions, providing safe input/output boundaries, and avoid having to type every single variable (unless I have to do so for performance reasons, as I do in Common Lisp).

This approach is comfortable to me both in Erlang and in Common Lisp, I see it as a balance between safety/performances and development speed (and I'm saying that as someone using Go for all professional development and being really happy with its full static typing).


> avoid having to type every single variable

Most static languages don't make you type every single variable anymore. Java, C++, Rust, C#, and many others let you make the compiler infer types where reasonably possible. That's still full static typing.

My Python and Rust have about the same kinds of explicit type annotations in roughly the same places. My C++ has a little bit more, just because `Foo obj{a}` is more idiomatic than `auto foo = Foo{a}`.


You can do that with type inference and a strong, static type system.


> Google runs some very sensitive applications for paying enterprise customers, and they still tend to not expire sessions.

For Google Workspace, web applications (e.g. Gmail or Calendar) will regularly force you to re-authenticate "for your security". It's not a daily thing fortunately, but it is common enough to be frustrating.


Session expiration length is a configurable setting by the domain admin, it's not enabled by default.


Oh is that why it asks for re-auth all the time? I thought it was built in. Nice, I’m going to disable that.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: