I finally got around to learn Rust. Well, starting to.
It’s amazing.
I’m comparing this to learning Basic, C, C++, Erlang, Fortran, Go, Javascript, Pascal, Perl, PHP, Prolog and Python. I wouldn’t say I know all these languages well, but I do know C, C++, Go, and Python pretty well.
I can critique all these languages, but I’ve not found anything frustrating or stupid in Rust yet.
Rust is like taking C++, but all the tricky parts are now the default, and checked at compile time.
With C++11 we got move semantics, so we have to carefully disable the (usually) default-created copy constructor and copy assignments, or if you have to allow copies then every single use of the type has to be very careful to not trigger copies unless absolutely necessary.
And you have to consider exactly when RVO kicks in. And even
the best of us will sometimes get it wrong, especially with
refactors. E.g. who would have thought that adding this optimization
would suddenly trigger a copy of the potentially very heavy Obj
object, a copy that was not there before?
--- before.cc 2022-12-28 10:32:50.969273274 +0000
+++ after.cc 2022-12-28 10:32:50.969273274 +0000
Continue reading
Network design discussions often involve anecdotal evidence, and the arguments for preferring something follow up with “We should do X because at Y place, we did this.”. This is alright in itself as we want to bring the experience to avoid repeating past mistakes in the future. Still, more often than not, it feels like we have memorized the answers and without reading the question properly, we want to write down the answer vs. learning the problem and solution space, putting that into the current context we are trying to solve with discussions about various tradeoffs and picking the best solution in the given context. Our best solution for the same problem may change as the context changes. Also, this problem is everywhere. For example: Take a look at this twitter thread
Maybe one way to approach on how to think is to adopt stochastic thinking and add qualifications while making a case if we don’t have all the facts. The best engineers I have seen do apply similar thought processes. As world-class poker player Annie Duke points out in Thinking in Bets, even if you start at 90%, your ego will have a much easier time with Continue reading
Hello my friend,
In one of the past blogposts we have highlighted the journey for automation for engineers, who is willing to develop further outside of their core remit, such as networking, compute, or storage. In today’s blogpost we’ll provide some of examples how the different moving pieces are coming along together.
1
2
3
4
5 No part of this blogpost could be reproduced, stored in a
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.
Yes, you do. Start today with our Network Automation Training programs:
We offer the following training programs for you:
During these trainings you will learn the following topics:
In my blog post The uselessness of bash I made a tool to improve pipes in shell, to assemble a better pipeline.
It solves the problem, but it’s a bit too different, with its own language.
While complaining with some people at work that one of the main features of shell (the pipe operator) is broken, someone joked that it should be replaced by a protobuf based protocol.
But on second thought it’s not really a joke.
How about instead of this:
$ goodpipe <<EOF
[
["gsutil", "cat", "gs://example/input-unsorted.txt"],
["sort", "-S300M", "-n"],
["gzip", "-9"],
["gsutil", "cp", "-", "gs://example/input-sorted-numerically.txt.gz"]
]
EOF
how about this:
$ wp -o gsutil cat gs://example/input-unsorted.txt \
| wp -io sort -S300M -n \
| wp -io gzip -9 \
| wp -i gsutil cp - gs://example/input-sorted-numerically.txt.gz
It doesn’t use protobufs, but a simpler regular protocol. This in order to avoid well known bugs types. Before implementing any protocol also see formal theory and science of insecurity.
First I hacked it together in Go, but I think the main implementation I’ll maintain is the one I made while porting it to Rust, as a way to learn Rust. The Continue reading
A few years ago, I downsized my personal infrastructure. Until 2018, there were a dozen containers running on a single Hetzner server.1 I migrated my emails to Fastmail and my DNS zones to Gandi. It left me with only my blog to self-host. As of today, my low-scale infrastructure is composed of 4 virtual machines running NixOS on Hetzner Cloud and Vultr, a handful of DNS zones on Gandi and Route 53, and a couple of Cloudfront distributions. It is managed by CDK for Terraform (CDKTF), while NixOS deployments are handled by NixOps.
In this article, I provide a brief introduction to Terraform, CDKTF, and the Nix ecosystem. I also explain how to use Nix to access these tools within your shell, so you can quickly start using them.
Terraform is an “infrastructure-as-code” tool. You can define your infrastructure by declaring resources with the HCL language. This language has some additional features like Continue reading
https://codingpackets.com/blog/publish-docker-image-to-docker-hub
Dear friend,
Our team wishes you all the best for the upcoming year. Let it be healthy, wealthy, interesting, joyful, and successful in all capacities. Thanks a lot for reading us and staying in touch with us, reading our blogs, attending our trainings and using our open source software.
We sincerely wish you Merry Christmas and Happy New Year! You are the best, dear friend!
Warm regards,
Team Karneliuk
Recently I’ve started listening to a new podcast all about the brain and behaviors called Hidden Brain. It’s got a lot great content and you should totally check it out. One of the latest episodes deals with complaining and how it can make us less productive and more likely to repeat patterns or shut people out.
Complaining is as old as language. I’m sure as soon as the first person to create communications around spoken words was able to teach another person one of the first things they did was complain about the weather or something they hated. Our mind is built to express itself about things we don’t like, such as bad drivers or silly behaviors at work.
The episode explores the ways that our brain can trap us in cycles of complaining simply for the sake of complaining. It also discusses how we should try to spend more time trying to be productive in how we address complaints. I’ve experienced this a lot in IT as well as in my career after being directly involved in IT and there’s a lot of merit in changing the way we complain about things.
Complaining without a suggested solution Continue reading