motiejus

It's fascinating that cURL is becoming a genericized term:

- search it on a search engine -> google it

- fetch it from an API -> cURL it

Too big to recover.

When I was there at aws (left about a decade ago), us-east-1 was considered least stable, because it was the biggest.

I.e. some bottle-necks in new code appearing only _after_ you've deployed there, which is of course too late.

It didn't help that some services had their deploy trains (pipelines in amazon lingo) of ~3 weeks, with us-east-1 being the last one.

I bet the situation hasn't changed much since.

in Nix it's the same for as long as I remember, both on NixOS and nix-managed home-manager on MacOS and Linux:

      neovim = {
        enable = true;
        vimAlias = true;
        vimdiffAlias = true;
        defaultEditor = true;
        plugins = [
          pkgs.vimPlugins.fugitive
          pkgs.vimPlugins.fzf-vim
          pkgs.vimPlugins.vim-gh-line
          pkgs.vimPlugins.vim-gutentags
          pkgs.vimPlugins.nvim-lspconfig
          pkgs.pkgs-unstable.vimPlugins.vim-go
          pkgs.pkgs-unstable.vimPlugins.zig-vim
        ];
        extraConfig = builtins.readFile ./vimrc;
        extraLuaConfig = builtins.readFile (pkgs.replaceVars ./dev.lua {
              inherit (pkgs) ripgrep;
            }).outPath;
      }

I've been running jakstys.lt (and subdomains like git.jakstys.lt) from my closet, a simple residential connection with a small monthly price for a static IP.

The only time I had a problem was when gitea started caching git bundles of my Linux kernel mirror, which bots kept downloading (things like a full targz of every commit since 2005). Server promptly went out of disk space. I fixed gitea settings to not cache those. That was it.

Not ever ddos. Or I (and uptimerobot) did not notice it. :)

My combination for photo hosting is:

- headscale+tailscale

- immich

- syncthing

I am not using native immich photo upload due to historical reasons and old habits. I set up native upload using immich to my child, will see in a couple of months how it pans out.

I've been using immich for ~3 months and am really happy so far. It was so good that I bought a server license[1]. ;)

Setting it up is quite simple. Most of the LoC comes from sharing the folders between my user (which owns the photos) and immich: https://git.jakstys.lt/motiejus/config/src/commit/6ecb1625e0...

[1]: https://immich.app/blog/2024/immich-licensing/

Your flake is very helpful, thanks! I cargo-culted tlp configuration, will see how it goes.

> and letting powertop run in the background while on battery for a few hours to identify the worst offenders.

How do you do the analysis after running powertop in the background?

You are not alone with both issues. Framework12, i5, NixOS. My milleage is 2.5~3h, but usage is light (vim mainly, often not even a browser).

I spent quite some time trying different things to optimize it, but never got more than realistic 3 hours.

Happy with other aspects though.

OK, a Django update from me.

I heavily used Django since version 0.96 (2007) until 1.5 (2014) (with Python 3)! Then came a long break with lower-level infrastructure work: linux kernel, perf tuning, some C, some Go and zig.

Last week I picked up Django again. After 10 years (!!!) of not even looking at it. It felt like meeting a good old friend: they are the same, but older and more mature. Conversations are the same. But better.

Things change in the tech world, often for the worse. Django changes, as it matures, for the better. The website layout, tutorial, colors, excellent release notes, `./manage.py runserver` are all the same as I remember them.

Except today it's easier, since I am much wiser in deploying and maintaining things than I was a decade ago. :)

I am upset by this.

I have used awesome for >10 years now, and the way awesome does multi-monitor support has grown into me. No other WM, wayland or X11, has offered it.

I am upset not because of X "deprecation" (still not convinced it will happen, hopeful it won't), but rather that I will, again, need to invest time and energy into something that had worked just fine for more than a decade.

Rk3588-based are gaining traction. Upstream support for uboot and linux has been improving rapidly.

I bought orange pi 5+ to replace my x86-based odroid-h2+. Will start the installation in the next few weeks. I have seen enough anecdotes people running NixOS on this chip, so feel pretty optimistic about it.

Also, #nixos-on-arm Matrix channel is amazing.

One thing that bit and puzzled me was autoloading of the extensions.

If you are compiling applications with clang (or zig), some (all?) extensions will not work, because C++ does not have a stable ABI. And thus an application linked with lld/zig cc will fail to load an extension linked with ld/gcc (aka the official duckdb extensions).

We found this the hard way after enabling zig-c++ as the C++ compiler in prod. Took some time to recompile (and statically link) the extensions we actually use, but now the system is much better off.

I would prefer a default that does not download anything from the internet (especially .so files), but that's quite easy to change when you know it.

Still wip to actually poke with duckdb for myself. :)

I was responsible for bootstrapping arm64 at Uber[1] and no longer work there. I am ready to consult companies who are considering or have just started onboarding to arm64 (and running into issues). I am open to strategic, technical advise and hands-on as necessary.

It's a cold call here, I know, but I am increasing my leads. :)

Location: EMEA.

Technologies: arm64, C/C++, Go, various build systems and schedulers.

Resume: https://jakstys.lt/resume.pdf

Contact: https://jakstys.lt/contact/

[1]: https://www.uber.com/en-LT/blog/bootstrapping-ubers-infrastr...

> (I used to work on Protobufs, a long time ago.)

What and understatement. For those unaware, Kenton made protobufs to what they are today.

Protobuf was my first dip into what are IDLs; it seemed like a magical idea at the time (having discovered protobuf ater writing my own rudimentary IDL first, protobuf was amazing).

The language docs are OK: https://ziglang.org/documentation/master/

Zig taught me to read stdlib source, which I do at my $dayjob now too.

It is perfectly fine to read stdlib source. Start with lib/std/mem.zig after reading the docs about the language.

It is much more readable than the C "docs" ISO/IEC 9899:2011. I am so productive now. :)

That's why I use Lenovo keyboards. They have this amazing red thing in the middle of the keyboard. You can't ask more than that.

Hi!

No plans yet. In my opinion, it needs a good reason to be picked instead of C (which we have sizable) to overcome the "number of developers" argument.

Introducing a new general purpose language into a large company carries a significant cost, especially into the future. The company is rightly cautious.

Author here.

I am proud what we've achieved. Unfortunately I will cease working on this soon[1], but, if you are interested and location suits you, I highly recommend Uber's Platform Engineering as a great place to work.

Happy to answer any questions about what's in the blog post, and, if you come to SYCL in Vancouver, BC on 2023-06-08[2] — in person.

[1]: https://jakstys.lt/2023/7-years-at-uber/

[2]: https://softwareyoucanlove.ca/talks/zig-at-uber/

Judging from my past experience working with Zig — now it will get many eyeballs, some of which are the best in the field.

Allowing API to change, sometimes drastically, and somehow having a way to attract best contributors does lead to a great outcome.

This interview and the one with Richard Hipp about sqlite[1] resulted me in downloading and listening to all past podcasts from corecursive. I found some other gems there too[2]. Adam, the host, really knows how to get the most out of his guest, in the best way.

[1]: https://corecursive.com/066-sqlite-with-richard-hipp/

[2]: https://jakstys.lt/2022/my-favorite-podcast/

I think this marks a cross-road: you build a "batteries included" programming language (python, Go style) or an artisan one (like C, Rust).

Zig is the batteries included one, with an optional standard library. Makes it truly versatile in my opinion: I have played with pure systems programming[1], played with bpf and will run it on a microcontroller in the upcoming workshop[2]. After 15 years being a professional in tech I am excited about a technology again. :)

[1]: https://git.jakstys.lt/motiejus/turbonss [2]: https://softwareyoucanlove.ca/talks/intro-to-zig-on-embedded...

I need the eSim. :) Obviously removing the filter yields more.

Google removed jack from Pixel, and I went shopping for an alternative when my last pixel broke down. Here is my filter:

https://www.gsmarena.com/results.php3?chk35mm=selected&sSIMT...

Ip68 is important. I went with xperia 10, and am positively surprised. Fits all the checkboxes and less undesired software than google. I don't have the mandatory search bar in the front screen!

Currently x86_64 to aarch64.

It's a bootstrapping problem. It takes a lot of infra to run the first build host. We can transition to aarch64 for build hosts if we see the need later.

Having cross-compilation makes things much easier from get-go.

I have been working to move Uber's stack to arm64 during 2022[1]. We are quite far ahead. I can say the ecosystem to compile stuff is pretty good, at least for our primary targets C++ and Go.

We don't have performance numbers to show yet (and not sure if we will be able to publish them when we will), but I can say I am pleasantly surprised with how much cross-compiling is easier than it was ~10 years ago. Especially with zig cc. :)

[1]: https://jakstys.lt/2022/how-uber-uses-zig/

Folks, there is a good reason this is a subscriber-only content. It takes time and effort (and money!) to keep us up to date. For such a long time.

This is the 5'th SubscriberLink over the last week on HN: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Please, folks, subscribe, and let Corbet put the subscriber links here himself. The LWN weekly editions are definitely worth every penny.

Edit: I am paying LWN since 2012 and intend to keep paying for as long as there is LWN.

If we ignore the proposal, this gives at least an awesome overview of the state-of-the-art of logging in go. That was the best part. Thanks for the heads up!

My blog was hugged once. Static webpage served with golang's net/http. Not more than 2% cpu load (single core), 20-30 requests/second. The problem was the default number of file descriptors. Once bumped that, all went well for the next few hours.

A tarball of tarballs, layered using barely documented rules (e.g. you can add a directory, remove it on upper layer, and re-add something else on top).

Constructing them is easier than unpacking. :)

Nice, thanks! I won't. :)