friend-monoid

Are you expecting a public IPv4 from a VPN?

    # Arch Linux (btw)
    yay -S glow

Heh, nice take on the whole "I use Arch btw" meme.

This is really cool.

I’m not sure, im no compiler programmer but I prefer not requiring an allocator like malloc and copying data and reference counting. But I don’t know.

Signals have some wierd properties; a process-directed signal (i.e. the usual one you’d send with kill) chooses an arbitrary thread and invokes the signal handler. You can get in to some weird situations with signals and threads. If you’re using signals as an ipc mechanism, a useful tip is to just block the signal and register a signalfd on poll/epoll to regain control flow control.

Its GLSL, and yes, you can pretty much copy paste it.

I had this issue in a case I think is interesting; a customer had a database with incremental IDs of a certain product they sold. On a web platform, the product owner in turn could log in and view a list of their products and their status. The id of the product was part of the URL; /product/851. Of course, the product owners could not get any information on IDs they didn’t own, but the numbers gave away info on how many devices existed before them. And they wanted to hide that information.

Of course, there are many ways to solve that situation, but UUIDs is one.

Poettering makes some really valid points in this post; you shouldnt be using select. And the resource limits are weird. But I just want to consider that open fds are a resource hog, and you should also strive to close fds sooner rather than later. Most applications will stay well below 1024 fds, and if they consume more then that - it’s probably a bug.

Servers, sure; each connection can easily consume 2-3 fds, that’s 300-500 simultaneous connections - that’s nothing.

Systemd and other service supervisors, sure, with pidfds, timerfds, sockets, proc file sockets and whatever else.

But for your average image editing softwares, email clients, CLIs, etc; id think it’s probably better to keep the limit? That way you are saving yourself from badly written software draining too much resources.

epoll.

I'm not sure I buy the idea that "efficient and easy tooling around a technology makes the technology". We all went through the same Dreamweaver pains.

As a C programmer, I have definitely shot myself in the foot in the conversions between types on multiple occasions. This is a really welcome feature.

The reason why TimescaleDB is so fast relies really a simple concept; keep indexes small enough to keep in memory. If you have a small enough index, you only need to do 2 reads from disk; one for the index to locate the data, and then one for the actual data.

Fetching data becomes much, much slower once your index is too large to fit in main memory. TimescaleDB segments the indexes into chunks (the “hypertables”) and makes sure these chunks are all “small enough”.

This alleviated further by having the data sequential by time; inserting new data does not need to alter older index chunks, which is what makes inserts fast.

I can imagine that if that’s not the case and your inserts are altering “older” chunks so data needs to move between lots of chunks could make the database prohibitively slow.

So in what way does tau do worse?

I few like there has been a lot of attempts at this; the semantic web, html5 semantic tags (article, header, ...), stuff like robots.txt. Developers really like to generalise.

Getting everyone to cooperate is the hard part.

Coming from embedded Linux programming, I gotta say sometimes (for easier problems) the overhead in altering the init and spinning up a gdbserver is too much; just pushing a few prints to debug something is easier. However - just having learned about rr, which seems like an amazing tool - I think that can breakpoint might change...

I can imagine that it’s hard to keep up to date with maintenance practices and manuals when the manuals are explicitly unavailable, as is the case for McDonalds.

Right. Data management is a hard problem. Just look at SQL query planners, they are insane - but they are not perfect, and they only work on the premises you provide (schemas, indexes, memory, etc). The idea that you could introduce a library that fixes all data management issues for you is not well considered.

Did you read the OSL version of the same statement? It’s kind of beautiful in comparison. I think its an amazingly insightsful article. Like “clean code”, but it’s a license.

I bought it and skimmed through most of it, and I have a hard time recommending it personally. It’s really short on the crypto and offers no insight into why TLS behaves the way it does. I would like to at least see an explanation of the TLS handshake process, but there is none. It’s a lot of “using openssl s_client”-type of discussion; i.e. how to use it, not so much on how it works, and that applies to most of the book (including the ocsp parts).

Practical, not necessarily theoretical; but if that’s what you are looking for, then it’s a great book.

  e=${e//$se/$'\n'};set -- $e
  [[ $1 =~ ^(.*[^/])?(/*)$ 
  ]];z=${BASH_REMATCH[2]};p=/${BASH_REMATCH[1]}
  B=${p%/*}
  r=("${p##*/}$z" ${@:2})
  (($#>1))&&p=$p$'\n'${e#*$'\n'}
  p=${p//\/..\//$'\t/'}
  p=${p//\{/\\\\\{};p=${p//\}/\\\\\}};p=${p//\(/\\\\\(};p=${p//\)/\\\\\)}
  while [[ $p =~ ([^$'\f']|^)\? ]];do p=${p/"${BASH_REMATCH[0]}"/"${BASH_REMATCH[1]}[^/]"};done
  while [[ $p =~ ([^$'\f']\[)! ]];do p=${p/"${BASH_REMATCH[0]}"/"${BASH_REMATCH[1]}^"};done
  p=${p//./\\.};p=${p//\//$'\v'}
  p=${p//$'\v**\v'/$'\v(.\r/)?'}
  p=${p//\*\*/.$'\r'}
  while [[ $p =~ ([^$'\f']|^)\* ]];do p=${p/"${BASH_REMATCH[0]}"/"${BASH_REMATCH[1]}"[^/]$'\r'};done;p=${p//$'\r'/*}
  b=${p%%$'\n'*}
  p=${b##*$'\v'}$z${p#"$b"}
  b=${b%$'\v'*}

Nice.

Yeah, of course you can. It's just a freebsd with some configuration stuff on top, it can run hostap, switch, it can do lagg and span ports and all the other stuff you'd expect... not sure how common it is though

Me too, but not really an alternative - the original tomato isn’t even updated any more, and it’s only configurable in its web ui, so it’s really only for home use.

Is pfSense, vyos, stuff like that out of fashion? Or too hard to maintain? Automating that stuff with ansible should solve the central management bit...

Late reply here but yes, canbus is binary, so is midi. They are both pretty simple. When I say that Protobuf is harder then canbus what I mean is that you have to deal with e.g. variable length integers (“varints”) and key offsets. And yes, that’s very true, full spec parsing is a pain, but that’s also a very rare special case. “In the real world” you usually don’t really care about full compatibility. If someone can find and send your printer data to get it to print securely and your customers can browse and login to your web page and your app, and you can send your Kafka messages to your order service, then everyone is happy, and none of those things require a full spec parser for anything.

Mathematica 9 and above has had significant improvements in its unit support. I’ve found it to be really good.

I’ve written hundreds of parsers at this point, for many kinds of protocols - http, mqtt, canbus, midi, various strange binary stuff, cli’s, just lots and lots of parsing. I’ve found that text protocols are usually easier to parse, depending on the situation. Some binary protocols are easy because you can just cast the read buffer to a struct, but even that can fail when doing a partial read (which is the norm more then the exception in embedded spaces). And even in the best of cases you usually need to do a lot of post-processing to make sure that the data you read is correct. In the worst of cases you’re bitshifting and you have conditionals everywhere and you’re just not going to have a fun time. Canbus and midi are a lot easier to write parsers for then e.g. protobuf and mqtt. For text, stuff like http, redis, and those types of protocols are easy, but the text parsing world has json, which is the absolute worst of pains.

The linux programming interface by Michael Kerrisk. It’s incredibly good.

Same here. That book and the Linux api book are just invaluable resources.

Yoda mostly applies to equality comparisons

Yes absolutely. I tend to put my comparisons in order from least to highest always these days, so it’s “value < max” and “min < value”. Eases up on the headwork

I agree absolutely - just want to add that learning when not to use a db, which db to use when you need one, and which network protocols to use for an application, is also important