There should be a political party for people who use opcode mnemonics as their nicknames or domain names.

I'm confused. Why is there gnuradio on the screen? The RPI seems to have power (micro usb), TX (two wires to the ethernet port on the laptop), and ... what is the third thing?

I thought my mmuniq holds the crown!

https://blog.cloudflare.com/when-bloom-filters-dont-bloom/

https://github.com/majek/mmuniq

better link https://www.tomshardware.com/tech-industry/semiconductors/al...

paper https://dl.acm.org/doi/10.1145/3731569.3764815

In simplest scenarios software is not aware of the IP space. Like you bind to 0.0.0.0:443 and move on.

In more sophisticated configs adding / removing IP's or TLS certs requires restarting server, configuring applications. This gets out of hand quickly. Like what if your server has primary IP removed, because the IP space is recycled.

At CF all these things were just a row in database, and systems were created to project it down to http server config, network card setting, BGP configurations, etc. All this is fully automated.

So an action like "adding an IP block" is super simple. This is unique. AFAIK everyone else in the industry, back in 2012, was treating IP's and TLS more like hardware. Like a disk. You install it once and it stays there for the lifetime of the server.

I totally agree. Early days Cloudflare was a great example of this. We treated IP addresses as data, not as configuration. New subnet? INSERT INTO and we're done. Blocked IP? DELETE FROM, and tadam. This was a huge differentiator from other CDN's and allowed us extreme flexibility. The real magic and complexity was with automatic generating and managing HTTPS certs (days before SNI).

Most of the responses here are knee-jerk.

I liked the article. It's close to my adverntures with containers. I think the invention of docker is indeed mostly packaging: Dockerfile (functional) is pretty neat, docker hub (addressing a container) is awesome, and the ENTRYPOINT in Dockerfile is great, it distinguishes Docker from .deb.

But indeed, beyond Dockerfile things are bleak. Docker compose never rose to my expectations. To get serious things you need load blancer, storage, addressing, and these are beyond traditional containers scope.

Hey! MPTCP again!

Back in Jan I wrote a piece about how to actually use MPTCP

https://blog.cloudflare.com/multi-path-tcp-revolutionizing-c...

But plenty has changed since then. It seems all my complains about the API are now addressed. Maybe it's a good time to actually run with MPTCP again :)

In my private affairs, I realised I need MPTCP less, since I started using tailscale. My SSH sessions tend to last longer when going over it.

> if you want to allow offline login, you need to keep the hash/token to the Microsoft Account locally,

I'm not following. I thought the whole issue is that users _do not_ want to use microsoft account locally and that microsoft fights that.

Lysk | Generalist Engineer (backend/frontend) | Warsaw, Poland / Paris, France | Onsite | Full-time

We are a young startup building modern software for European defence. Looking for generalists, especially with experience in: Web backend (FastAPI, Python), Audio processing (including Voice To Text models), Frontend (modern JS frameworks)

https://notion.lysk.ai/engineer

Email me: marek [@] lysk.ai

Nested functions are cool, although not supported by clang.

However they rely on Trampolines: https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html

And trampolines need executable stack:

> The use of trampolines requires an executable stack, which is a security risk. To avoid this problem, GCC also supports another strategy: using descriptors for nested functions. Under this model, taking the address of a nested function results in a pointer to a non-executable function descriptor object. Initializing the static chain from the descriptor is handled at indirect call sites.

So, if I understand it right, instead trampoline on executable stack, the pointer to function and data is pushed into the "descriptor", and then there is an indirect call to this. I guess better than exec stack, but still...

I always assumed that when one warp waits for results from a long latency instruction, another warp, potentially from another block can be scheduled in.

I guess this post assumes the need to use all the gpu resources from within a single block.

When I was playing with arduino geiger counter, apart from of course breaking the tube, I struggled with counting the results.

On one hand it's trivial - counts (ticks) per second. However, this (of course!) can be very spiky. I ended up using pretty simple EWMA to smooth the results for user interaction. Anything really works, short decay is fine.

Then the really fun bit, was trying it with more serious radiation source, and guess what.... interrupt per tick, is... really bad! I was easily able to overwhelm the arduino, too many interrupts. Fun project to understand interrupt masking.

Can you expand on the “immobilizer regulations”? I wasn’t aware any of this was regulated in.

Internal blog is another thing, but indeed related to chat. Once we figured some techical thing out, I often put it under "personal blog" on wiki under something like ~marek/date-slug. (I'm actually quite upset about jira removing slug from the url and replacing it with random number, this makes url completion much worse. I often titled the wikis funny/witty to make it easier to remember and find)

These were usually quite short notes. Like I did this and that. Or here are instructions I've run. Pretty much a "lab notebook".

Again, this was often useful to people. Folks new what I was working on at that time. Over time more people adapted this style of public note taking (within company), but I have the impression I was more consistent than others.

I did it for many reasons. I genuinely forget things. It was always nice to see comments (like James complaining that I shouldn't do `dpkg -i x.deb`, and instead finally install the package repo in apt-sources!). So again - searchability (a form of documentation), reach (getting feedback), and work log (for planning).

The format was also nice - short, without specific audience in mind. Zero drama, zero effort. Plentiful and low quality. Because it was "blog" and not "pages", this meant it was obvious when the note was written and nobody expected old blogs to be up to date. The lower the friction in note taking - the better.

Finally, I was working with an SRE team, which was tightly knit and communicated very often over daily checkins (which I wasn't invited to) and other informal channels. And I worked from home a bit. This meant I had to find an asynchronous way to communicate with the team. My personal blogs worked nicely. I highly recommend this style to anyone working remotely.

Although I must admit the personal "lab notebook" wiki thing is not scaleable. It's impossible to "follow" more than a handful of people.

I kept statistics. It's fairly obvious when I was most productive. Here it is, my internal blogs on the wiki per quarter:

  2013-Q4 |  0 | 
  2014-Q1 |  0 | 
  2014-Q2 |  2 | ##
  2014-Q3 |  3 | ###
  2014-Q4 |  2 | ##
  2015-Q1 | 14 | ##############
  2015-Q2 | 15 | ###############
  2015-Q3 | 57 | ###################################################
  2015-Q4 | 60 | ######################################################
  2016-Q1 | 70 | ######################################################################
  2016-Q2 | 71 | #######################################################################
  2016-Q3 | 17 | #################
  2016-Q4 | 23 | #######################
  2017-Q1 | 13 | #############
  2017-Q2 | 22 | ######################
  2017-Q3 | 16 | ################
  2017-Q4 | 25 | #########################
  2018-Q1 | 12 | ############
  2018-Q2 |  9 | #########
  2018-Q3 | 23 | #######################
  2018-Q4 | 14 | ##############
  2019-Q1 | 14 | ##############
  2019-Q2 | 20 | ####################
  2019-Q3 | 18 | ##################
  2019-Q4 | 36 | ######################################
  2020-Q1 | 19 | ###################
  2020-Q2 | 13 | #############
  2020-Q3 |  4 | ####
  2020-Q4 |  3 | ###
  2021-Q1 |  4 | ####
  2021-Q2 |  8 | ########
  2021-Q3 |  3 | ###
  2021-Q4 | 21 | #####################
  2022-Q1 |  4 | ####
  2022-Q2 | 12 | ############
  2022-Q3 |  4 | ####
  2022-Q4 | 28 | ############################
  2023-Q1 | 14 | ##############
  2023-Q2 | 16 | ################
  2023-Q3 | 10 | ##########
  2023-Q4 |  6 | ######
  2024-Q1 | 12 | ############
  2024-Q2 | 22 | ######################
  2024-Q3 |  0 | 
  2024-Q4 |  2 | ##
  2025-Q1 | 20 | ####################
  2025-Q2 |  3 | ###

Total 784 over 11 years.