Recently I used Google maps to search for the nearest DHL near me so I could return a package. DHL is not that popular near me and when I specifically typed for DHL, I would get only their competitors in the search results.

There was a DHL service center near me and I had to scroll a bunch to find it. Oh, and apparently big box stores (or anyone) can pay Google to come up in the search on maps, even if unrelated.

I don’t think they have skin the in shipping game but their algorithms are over optimized that they don’t even show what your searching for, but trying to infer why you’re searching for it. That or whoever pays them more. Certainly a search risk

was it ever? I participate in interview rounds at my company (several tech screens a month) and I must say a candidate’s email was not something that drew attention

you’re able to unsubscribe from all those protomtions . . . that is in settings. Personally, a once-a-month newsletter of everything that is new is helpful bc I don’t need to put in the effort tlinto keeping up

For backup and sync I use Syncthing. I can specify which folder on which devices I want to sync to which folder on the server.

I use a folder based gallery on my phone so when I move stuff around on my phone (or on my server) it gets replicated on all my devices.

I also have a policy to sync specified folders (and subfolder) with my family’s devices. No more " hey can you send me all the pics from the XYZ trip"

We take a trip. Make a subolder for that trip in a shared folder dump all our pictures there, get home and open the folder on the computer and prune together.

simply put, programming is glorified automation. There are jobs where the process that needs automating makes money.

Debian has the advantage of not using snapd like Ubuntu does. You have to not only remove snaps but also instruct the package manager not you pull in snaps as dependencies and not to favor snap packages.

I have fond memories of Ubuntu being my first distro many years ago but pushing snaps onto users to compete with flatpak is a nuisance.

I don’t think I am well positioned to answer that question given my experience. Ill give it my best.

I believe the advantage of more abstraction of gRPC was desireable because we can point it at a socket (Unix domain or internet sockets) and communicate across different domains. I think we are shooting for a “microserves” architecture but running it on one machine. FFI (IIRC) is more low level and more about language interoperability. gRPC would allow us to prototype stuff faster in other languages (like Python or go) and optimize to rust if it became a bottleneck.

Short answer is, we are able to deliver more value, quicker, to customers (I guess). But I don’t know much about FFI. Perhaps you can offer some reasons and use cases for it?

At work, we started the c++ migration to rust doing the following:

1. Identify “subsystems” in the c++ code base
2. Identify the ingress/egress data flows into this subsystem
3. Replace those ingress/engress interfaces with grpc for data/event sharing (we have yet to profile the performance impact of passing an object over grpc, do work on it, then pass it back)
4. Start a rewrite of the subsystem. from c++ to rust
5. Swap out the two subsystems and reattach at the grpc interfaces
6. Profit in that now our code is memory safe AND decoupled

The challenge here is identifying the subsystems. If the codebase didn’t have distinct boundaries for subsystems, rewrite becomes much more difficult

hey, that’s what the internet is for; information sharing :)

for the dummies (like me) that can’t read the room, especially online, a sarcasm tag /s goes a long way 🙃

you sound like a Microsoft engineer ;)

hahaha good point.

That colleague, keep in mind is a bit older, also has Vim navigation burned into his head. I think where he was coming from, all these new technologies and syntax for them, he much rather prefers right clicking in the IDE and it’ll show him options instead of doing it all from command line. For example docker container management, Go’s devle debugger syntax, GDB. He has a hybrid workflow tho.

After having spent countless hours on my Vim config only to restart everything using Lua with nvim, I can relate to time sink that is vim.

Had a distinguished collegue (from the Bell Lab days) say to me recently:

“IDEs take up a lot of RAM on my machine. Vim takes up a lot of squishy RAM in my head. I need squishy RAM to hold info relevant to problem solving, not options available in my tool chain.”

As a former Vim user myself, I have to say I really dislike screensharing with coworkers who use Vim. They are walking me through code and shit pops up left and right and I don’t know where it comes from or what it is I’m looking at. Code reviews are painful when they walk me through a large-ish PR.

These days, I tend to bring my vim navigation/key bindings to my IDE instead of IDE funcs to Vim. Hard to beat JetBrains IDEs, especially when you pay them to maintain the IDE functionality.

code is just text, so code editors are text editors.

What sets IDEs apart are their features, like debugger integrations, refactoring assists, etc.

I love command line ± Vim and used solely it for a large portion of my career but that was back when you had a few big enterprise languages (C/C++, Java).

With micro services being language agnostic, I find I use a larger variety of languages. And configuring and remembering an environment for rust, go, c, python etc. is just too much mental overhead. Hard to beat JetBrain’s IDEs; now-a-days I bring my Vim navigation key bindings to my IDE instead of my IDE features to Vim. And I pay a company to work out the IDE features.

for the record, I am in the boat of, use whatever brings you the greatest joy/productivity.

don’t insult children like that.

There is a very effective approach (34:00), that big companies like cloudflare use, to ship a product in a fast and quality way. It bears parallels to what you are describing. In essence engineers should not get hung up in the details to trying to solve everything.

1. Just build a proof of concept
2. Discard the prototype no matter what and start from scratch keeping the initial feedback in mind
3. Build something internally that you yourself will use
4. Only once something is good enough and is used internally, then release it to beta.

So that tedious process in trying to flush out all the details before seeing a product (or open source effort) working end to end, might be premature before having the full picture.

i take a Phoenix approach with my dotfiles.

Once a decade when my computer crashes and burns, from the ashes emerges a blank slate of dotfiles that is purged of all unnecessary hacks that have accumulated. With a tear and a hopeful outlook, I rush to set the settings I am actually dependent on.

I really need to take more interest in backing up my dotfiles 😭

I will admit reading the reasons against Linux made me a bit butthurt given how much it has accomplished and the ubiquity of it running on servers that host our services.

However, a (real time operating system) RTOS is distinct from a time-sharing operating system, such as Unix, which manages the sharing of system resources with a scheduler, data buffers, or fixed task prioritization in a multitasking or multiprogramming environment. And a time-sharing kernel is likely not suitable for the demands of real-time feedback that airplanes, especially fighter planes, are under. Admittingly I don’t work on the kernels so I might be out of my league talking about it if there are ways to optimize them for RTOS applications. And I also don’t work on airplane but hobby learning about them.

In an airplane, the pilots are voting members. If they they are nose diving and tell the airplane to pull up, the airplane will calculate how much of the full range of motion to allow the flaps to “bite” the air so that the plane doesn’t desintigrate. This takes into account speed, altitude, air density, load on wings, load on frame, G forces pilots would experience, etc etc.