LinuXY

Zettlekasten with git and https://github.com/foambubble/foam - if I'm mobile I use WorkingCopy to paste links into an inbox file that I organize later.

IMO Zig right now is fairly buggy. And the rate of bug introduction has been greater than the fixing of said bugs over the past few years. (Not a knock on the project.) Move fast and break things. Trying to develop production quality software in Zig is like trying to hit a moving target. Zig is not production ready, and they mean it. The ABI is not stable and features are removed/retooled from version to version. (eg. removal of async.) This is all stated upfront, however. Zig is a WIP. That being said, if you've read the warning labels and are still excited there's /tons/ of promise. They are on the right track to being a modern C replacement/augment/mux with an integrated build system. And it's a joy to program in. And the community is pretty great. The best way forward is joining the community and contributing in one way or another, because Zig will be quite special once it's done. Bun is a clear indication of this.

I have fond memories of learning Pike and Roxen as a kid by perusing the Stellar Crisis source code (released, 1993!) I think there's still some servers around today. https://strategywiki.org/wiki/Stellar_Crisis

SRE. Learning to build the automation that makes changing the kernel a change to a config file (Ansible/Salt/Nix/etc.) and pushing a button.

The NanoPi R4S has a RTL8169 controller with MSI-X capabilities. Post irqbalance setup I verified it's properly distributing IRQs. I'm using mine as a transparent bridge and network monitor. https://news.ycombinator.com/item?id=27236081

        Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-

Any chance we can get a scalable network backend to go along with the render enhancements? Fan-out workers on actors and a KCP implementation would great!

const std::string unusable = "unsuitable";

For more inspiration I'd check out the Quake engine source. It's quite the masterpiece. There's also been some modernization over the years by LordHavoc of the DarkPlaces engine https://icculus.org/twilight/darkplaces/ - I'm constantly impressed how well the HD remaster on DarkPlaces looks on modern 4k hardware.

I've never quite understood the allure of wanting to reinvent the wheel by creating a "distribution." There was one time where the Linux kernel did not support enough abstraction or a project was brought under some less open licensing that these niche "OSes" made sense. I would much rather see less package managers rolling other projects' packages and more unity on a single declarative platform. Today it's systemd vs SystemV, apt vs yum vs pacman vs... ad-infinitum. The Linux kernel is finally at a point where not every snowflake needs to be made. I'm waiting for the day where the concept of a distribution is rightfully pedantic. Maybe by then we may have a real shot at Linux on the desktop. A collection of packages not an OS does make.

Minus CP/CMS and OpenVZ, here's an article on the concepts and tech Docker is built on. https://www.kentik.com/the-evolution-of-docker/

https://windirstat.net/

Have you considered running individual containers with supervisord? It's init system agnostic, and works pretty great. Here's a pastebin to get you started. http://pastebin.com/4a9wRfBJ included are some hooks for systemd journald.

Apparently you've never experienced repeated netsplits under DDoS.

Right- Though the point of the post was to dispel the fallacy that the Linux kernel can only handle 50k pp/s per core. Using RDMA effectively bypasses the kernel. He's also testing with a SolarFlare card which doesn't support DPDK, though it does support RDMA with OpenOnload. What I've found is that RDMA is the "easy" part to get right, as it's fairly simple. Not every network card is created equal with respect to how many packets it can actually pass through to the kernel however, partially in part to the kernel driver (whether it's using NAPI or not, driver efficiency, MSI-X support, interrupt coalescing) and the card itself (onboard buffer, latency characteristics, etc.) 10g cards max out at around 14Mpp/s @ 60 bytes when the kernel is involved and everything is perfectly tuned. Which should be where the card he's using falls. A generic onboard Intel card generally maxes out around 8-10Mpp/s. But both would most likely be able to hit 16Mpp/s @ 60 bytes if using RDMA in any form.

While I agree that systemd does not play nicely with syslog, you quickly realize that journald can be exported as JSON, filtered, described as time ranges, chunked and easily imported into ELK. My users (mainly developers) with less sed/awk fu have come to rely on these features heavily. I'm not really sure what there is to miss about syslog or syslog-ng when you have a robust ELK+journald system.

There are a lot of parallels in serving hundreds of thousands of small HTTP requests a second and HFT. This, and the ability to instrument the onboard FPGA to mitigate against DDoS attacks is one of the reasons I speced SolarFlare for CloudFlare. http://blog.cloudflare.com/a-tour-inside-cloudflares-latest-...

Welcome. Never had any issues with their gear.

http://www.unixsurplus.com/

Debian testing (Jessie is really top notch.)

We chose SolarFlare+Onload over Intel with pf_ring+DNA or DPDK mainly because of the fully featured TCP stack. While it may make sense for us to develop our own in the future, it does not currently. Additionally the SolarFlare cards gave us the benefit of 16MB buffers which could allow us to go with switches that have shallow buffers (cheaper.) There's also processing done on an FPGA on the card itself which allow us to drop packets on the card before they reach the machine all together, which is /really/ a boon under DDoS. SolarFlare has been a great partner in their willingness to work on our (non-standard) use case, which is something that is hard to find when dealing with larger vendors.