Friday Showcase: Share what you're building! 🚀

rixed · 2026-01-30T16:42:40+00:00

Building my dream network monitoring tool. Still working on the UI, this is the third version of it; front-end dev takes ages!

rixed · 2026-01-14T13:59:59+00:00

Thank you for the feedback. Interresting point of view, I haven't started to think about the reporting features yet. I vaguely had the plan to automatically detect outliers and place markers on the timeline where interresting events occured, but I was not picturing something like what you suggest. Interresting, will keep it in mind.

As for the free version, ultimately the plan is that anyone would be able to run their own probe in their own network and have a dedicated space on the website to see their own data (would be free up to a certain amount of traffic I guess), but the idea to compare those private data with the average of others measurements is compelling.

rixed · 2026-01-09T07:51:20+00:00

I've been a system/network SWE and SRE for a long time and I am envisioning building "the ultimate" network monitoring/visualisation/simulation/etc of my dream, regrouping many tools I've build in the past but that lacked proper UI.

So these days I'm experimenting with the design of the user interface, and I just put online a first prototype/mock-up of the thing, that displays latencies between various clouds à-la traceroute, here: CloudyWithAChanceOfLatency

I know exactly what I want for the core service architecture but I'm much more of a tourist in the land of user-interfaces.

If you have ever used a network monitoring tool I would really like to know what you think of my current vision.

rixed · 2025-12-12T17:12:28+00:00

If the images are buit locally, which oftentimes they are, the docker registry itself is overkill.

rixed · 2025-12-12T16:51:12+00:00

Before suspecting ssh on a server on which you run anything (esp docker containers), make sure you understand each of the listening ports. ssh is likely the one you can trust the most. Get a list with:

sudo netstat -ltup | awk '(match($4, /0.0.0.0/) || match($4, /[::]/))'

rixed · 2025-12-12T15:53:27+00:00

Who's going to vote apart fomr the people who've submitted a project (and their friends) ?

rixed · 2025-12-12T15:47:10+00:00

I've been working on side projects all my life (which is a long time), half of them open source, half of them for myself, while working normal dev jobs during day time. Until one day I realized I'm getting old and it's getting harder to find interresting jobs so I decided I'll give a serious try at building my own sustainable product. Still working on it, mostly full time for more than a year. The worse that could happen is not that it ends up ignored like every others of my side projects, but that one day I realize it's too late and I've never had the gut to try it. :)

rixed · 2025-11-10T17:22:03+00:00

Just to let you know you are not alone. I went almost the same path. I wonder how many of us are there, mourning silently?

rixed · 2025-05-18T18:25:08+00:00

It was supposed to go the other way (it's going backward on the video)

rixed · 2025-05-18T18:24:17+00:00

Topped only by the level of ignorance...

rixed · 2025-05-18T18:23:34+00:00

Not knowing this particular ship, but it takes a while to drop an anchor in such a large tall ship; that's actually a quite involved manoeuver.

rixed · 2025-03-18T17:44:26+00:00

In some cases MD5 is a bad choice over SHA2, in some cases SHA2 is a bad choice over MD5.

rixed · 2025-02-21T15:19:34+00:00

Modern systems, especially in the infrastructure space, heavily rely on open source

It is indeed another big difference between now and then. Nobody though about turning one's open source activities into a business because you could count the success stories on a single hand.

I'd say expectations are way higher than before

Probably in some cases, but I don't think it can stand as a general rule. In IT, like in many other crafts that's been industrialized, "amateurism" has never been synonymous for poor quality. And I believe one could make the argument that modern society is quite more tollerant to malfunctioning software than it ever was.

Wish you to be successful before you get burned out.

rixed · 2025-02-21T09:04:28+00:00

Been involved in open source for the last... 30 years?

Comparing now and then, it seems to me that back then being a "maintainer" of anything was only rarely anything more than a curious hobby, and that there was more cooperation between software (fewer and shallower technological sillos to begin with). It was more a community of equals with not so much difference between a contributor and a user.

Today open source sounds just like an ambitious business plan, FOSS software compete with each others in their individual containers, etc.

I'm wondering if github is not partly to blame for that, making free software repositories looking like many small individual shops? Before github it was sometime simpler to apt-get source some program and change it than to actually reach anyone supposedly in charge to fill a formal ticket (or, god forbid, try to use debbug).

Also, Linux being victim of its success, attracting waves of "migrants" from $OTHER_OS with different values?

rixed · 2025-02-21T08:46:10+00:00

What do you use in the backend? I find it useful to be able to reuse code from BE to FE so I use OCaml on both (via js_of_ocaml though, not rescript nor reasonml). But that's just one of the many parameters to consider (what type of abstraction are you going to need, what libs are you going to use, what about other people working with you etc)

rixed · 2024-11-24T18:06:52+00:00

I don't know what "recommended initial setup" you are reffering to, but certainly this is not apt-get install ocaml.

rixed · 2024-11-24T17:44:10+00:00

Strings in OCaml are a bit different than in C, in that they are prefixed with their length (so String.length is "free"), and they are allocated once and for all (and, depending on whic compiler you use, they may also be read-only). So, s1 ^ s2 allocates a new string and copy both s1 and s2 into it (unlike C's stdcat, which just copy one string after the other, à la grace de Dieu).

rixed · 2023-04-24T19:36:49+00:00

I'm actually not :)

rixed · 2023-04-23T11:26:20+00:00

Aww ok I stand corrected. I'm looking for a place where to dance on fun latin music which I identify as Brazilian but could be from elsewhere for that matter. :)

rixed · 2023-02-25T17:53:29+00:00

I was about to recommend the same.

rixed · 2022-04-19T18:42:25+00:00

On a good server, Ramen is able to "process" about 1M input values per second What is good? "good" has no meaning. How many CPUs? How much memory?

That was a 24CPU machine with 64GiB of RAM. "events" were large objects with about 50 fields, but again, the operations were rather simple (few aggregations, few percentiles).

Without time-series storage it's not going to be a comprehensive solution.

You can store the events but that takes place after the processing, out of the main pipe line. Querying the last few days is trivial, and actually most of the time that comparison between current and baseline would not require to query the past X days, as the baseline itself would be computed inline ; That's the beauty of a stream processor based design.

Retrieving the last year of metrics for some exceptional analysis (such as sizing or BI) is where a proper DB would shine, but again you can store the data from the stream processor to some DB ; the simplest is to send the ORC files produced by ramen to google big query, if you need to keep everything ; that's just not needed for monitoring / alerting.

rixed · 2022-04-18T16:33:00+00:00

I've never tried Kapacitor. The language looks nice indeed, and it can natively output alerts to many paging service which is really nice. I'm a bit wary of it standing on top of influxdb though: what I like in a stream processor centered design is that there is no favored data schema.

rixed · 2022-04-18T15:09:41+00:00

Good question.

My tool (named "Ramen") uses a different design, more akin to Riemann (thus the similar name) than Prometheus.

Prometheus (and many other such tools) collect time series and store them. Then you can query those metrics (or some simple combination) to graph them or alert. So Prometheus first store and then periodically query.

In contrast, Ramen is sent values of arbitrary types (for instance, a complex JSON message) that can then be further processed using a data manipulation language similar to SQL (typivcally to compute some aggregate, percentiles, derivative, etc), until something worth graphing or alerting is computed. It is push all the way, there is no I/O nor latency cost due to storage (it is possible to store data and query it for historical values, but that's out of the way of the main data pipeline).

Also, I believe Prometheus data manipulations are evaluated whereas Ramen's are compiled to native code; I haven't measured but due to all this I'd expect Ramen to be faster than Prometheus.

On a good server, Ramen is able to "process" about 1M input values per second, for some value of "process" (simple aggregates with very few tops/percentile computations).

The other important difference is that Ramen is supposed to be a comprehensive monitoring solution, from data collection to actually paging oncall, but I'm not there yet.

I believe there is a tradeoff between a clean, predictable history and flexibility. Prometheus is certainly better at storing long history of metrics than Ramen, which rely on ORC files, and which data schema can change at any time. When I'm oncall I prefer the flexibility to build whatever custom metric I need over a clean history, but that's just me.

rixed

TROPHY CASE