sreevisakh

Caste followers have a lot of undue social advantage over the oppressed groups (like in any other form of discrimination). Admitting that it exists would be the first step to giving up those undue privileges. It's perhaps that subconscious bias that leads them to 'caste denial'. People from most upper castes will swear that it doesn't exist outside of rural and uneducated areas of India. But ask someone from the lower (oppressed castes) and they will tell you the very many innocuous-looking ways in which caste based discrimination is meted out to them. Caste is never mentioned - but the treatment follows a predictable caste pattern. People in US are unlikely to hear these stories because a large population of Indians there are the wealthy privileged ones. So, these denials backed by anecdotal evidences should be taken with a lot of skepticism.

Rust has an undeniably steep learning curve which can cause a productivity penalty for beginners. However, there are some statements in this article I simply can't agree with based on personal experience. I'm using Rust to develop a few projects. At this stage, I would go for Rust for general development, irrespective of how useful manual garbage collection is. To put it in context, my other favourite language is Python.

> Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages, and there is a pretty steep learning curve, even for experienced programmers.

Rust's borrow checker system doesn't exist in isolation. It's designed to avoid problems that can occur with computing and memory model of programming - things like call stack frames (esp constant size), heap memory and other resource management, concurrency paradigms, etc. These are just the tip of low level computing models. There are things like cache coherence that Rust doesn't address directly. These are concepts that programmers must know if they want to do: a) Low level programming b) High performance programming. The problem raised by author may partially belong to the second category. Even if it is not, programmers should probably learn these, because they are likely to face such problems at some point and may gain from that knowledge.

There are two ways to learn the borrow checker rules. The first is to start with the rules itself. It's going to appear rather convoluted. The other approach is to understand the machine/memory model that I mentioned above first. Once you do, the rules are going to make much more sense - especially in the context of specific error messages during coding. These days, I'm able to connect every single error message that I see to some potential memory or concurrency problem, even though they are the result of some seemingly convoluted but simple borrow checker rule.

> Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below).

There were dozens of errors that I made today that were easily understood just by a glance at Rust's error messages. The help messages that accompany these error messages are often the solution that I needed. Even otherwise, the error messages point out potential low-level bugs as I mentioned above - allowing me to make proper corrections. This may just be anecdotal. What is not anecdotal is that the Rust team reworked the error messaging early in the project's life to make it that way. It's generally accepted that Rust's error messaging is top-notch. I find it disrespectful to all those early endeavors to call it arcane. Perhaps it's a good idea to try to learn those error messages. There is an entire index of errors with detailed explanations [1].

> We started having weekly “learn Rust” sessions for the team to help share knowledge and expertise. This was all a significant drain on the team’s productivity and morale as everyone felt the slow rate of development.

Perhaps this is the wrong way to approach the problem. The thing that may need learning is type theory. Type theory is often too esoteric with a theoretical mathematical approach. Perhaps we need an introduction to it that encourages people to see a bunch of bits as a storage for data with a particular meaning (the type). Next step would be to how to track types using software (type system) and then extend the idea all the way to include constant-size stack frames, generics, polymorphism and lifetime tracking.

> Libraries and documentation are immature

Library ecosystem is still growing - especially async programming. But documentation support is a first-class feature of Rust's language ecosystem. I find myself writing documentation much more often in Rust than with other languages. It's also equally easy to browse the documentation of the language, stdlib and other libraries. Sections are marked out clearly and navigation is well thought-out. Every search of a feature or API takes me through half a dozen links to the final target in a matter of minutes, if not less. It's a good investment to learn browsing technique for documentation in any language.

> Rust makes roughing out new features very hard

Somehow, my experience doesn't match here either. I use the same technique for trying out new features in both Python and Rust. Create a scratch project for each experiment. A single project may take up to a dozen such scratch projects. It's marginally easier in Rust than in Python, mainly because project management is another first-class feature of Rust tooling.

But what's really remarkable about Rust compared to most other languages I've encountered is that Rust's discipline gently nudges the scratch project to a proper design. By the end of the scratch project, the experimental code is often in a good enough state to be directly integrated into the main project. It's amazingly friction-less to integrate integrate external code into the main project.

I wouldn't blame the author for having a very different experience as mine. But I sure would like to know what makes Rust 'click' for some, but remain a tough nut to crack for others.

[1] https://doc.rust-lang.org/error_codes/error-index.html

I have a different experience with Rust these days. The errors that Rust throws are either the ones I had a vague hunch about or the ones I missed. It never feels like friction, but rather like helping guides. The error messages are informative and often very helpful in resolving problems.

The key, I believe is understanding the machine and memory model of low level computing. Rust errors immediately make sense in that context and it becomes easier to find a proper solution without having to work around it.

These days I feel much more comfortable with Rust than I'm with even Python. It feels like Rust does a lot of heavy lifting and thorough checking of a lot of semantics that's not possible in other languages. The worries about unforseen bugs are lesser (not zero, though) with Rust.

Edit: Phrasing

> an ethereal hourglass of orange and blue dust being shot out from a newly forming star at its centre.

Is there any standard way of describing images in non-visible spectra using color names from the visible spectrum?

These sorts of incidents would be far more common if bosses shit talked their employees in the public and tanked their brand image in the process in front of their users and future employees. Fortunately, almost everyone else is smart enough to know that it's bad.

Any plans to publish this on your blog? It's a much more elegant source of information. This also belongs there with the other great articles.

Indeed! The headline gave false hopes that the article may advocate for returning to plain text emails. It instead talks as if the biggest problem with email is the lack of even more complicated features. The introduction of html has already turned email it into a push version of attention seeking and pervasive user tracking on the web. It has made email ux bad for normal purposes like business communications. I for one really don't want any more of that.

You could use XCA [1] for small scale deployments, or step-ca [2] for a more comprehensive setup.

[1] https://www.hohnstaedt.de/xca/

[2] https://smallstep.com/docs/step-ca

Other commenters have mentioned interactive and patch staging. That is the standard way to ensure that only the lines you specify go into a commit. I want to add an alternative method that offers some extra advantages.

Patch stack management tools like stacked-git and topgit allow you to setup a number of patches (using git). You can then specify which patch each change goes into. This is sort of like having multiple staging area/indexes at your disposal. They also allow you to add commit messages to each patch at any stage of the development. You could also add, delete, split, squash or edit each patch at any time. And these patches are converted to regular commits at the end of development of the feature. You can also convert any commits into patches if you ever need it.

The attraction that I see in this workflow is that it allows you to combine the chaotic development workflow and final rebasing step into a single stage.

The ad is about a git tool (hiflux) that happens to be written in Rust. That is perfectly relevant in this context. Rust is also a good language to write such tools (as is Go). I understand why Rust evangelism can be a bit tiring. But the opposition to it shouldn't try to imitate the same quality.

The perfect commit is useful only when you're ready to publish. Development can be chaotic with all the half-done or possibly-wrong code. You don't need to worry about all those standards while you're still developing. The perfect commit is then crafted out of the chaotic development branch by editing the history. I keep the original development branch alive for reference, while the crafted commit is submitted to the maintainer.

Client certs as implemented on Gemini and IRC are self-signed. They are enrolled on the service after they're created. They don't need enterprise level capabilities. In fact, even the creation of these certificates are automated on many clients (eg: Lagrange Gemini browser, soju IRC bouncer). You don't even think of them as certificates. They're considered as identities.

And regarding the privacy. You can deploy as many certificates/identities as you want on multiple accounts and sites. It's not possible to track them across sites or even across accounts, since there is no CA involved.

I don't think I understand passkeys. The best I could make out is that it uses an asymmetric key pair for authentication. How is this different from self-signed TLS client certificates (like the ones used in Gemini protocol) or CertFP used in IRCv3?

I can confirm it works on MailInaBox. So it should probably work on any installation that uses Postfix and/or Dovecot.

I used lsp-mode for a while and then switched to eglot. The reason was that lsp-mode has quite a lot of dependencies including helm and hydra. This can be inconvenient when you use their alternatives likes the vertico-corfu stack. I didn't want more than one extension of the same type in my configuration. eglot uses native emacs APIs for completions and tooltips. This integrates very well with vertico and corfu.

> Also I wonder: if eglot is now part of Emacs, is there any incentive for the lsp-mode devs to keep working on lsp-mode?

I'm pretty sure that some people will stick to lsp-mode. There are a few builtin extensions which I replaced with more popular external packages (eg: projectile vs project.el). So, I think the lsp-mode devs should keep at it.

How familiar are you with Lisps? I heard somewhere that it's easier for a complete beginner to start learning programming with lisps than with traditional languages. I started with more mainstream languages, but my experience tends to agree with that observation. The small set of various lisp forms and their semantics are easy to learn and reason about, compared to synatx and semantics of more traditional languages. Same when s-expressions are used for representing data. The syntax closely matches the logical structure of a program or data.

Keeping this in mind, I find the Guile scheme syntax used by Guix quite intuitive and pleasant. It reduces the cognitive overhead to configure the system, at least for me.

Yes, that's certainly possible - especially with tools like kind. However, the reason I prefer LXD over Docker/OCI is that the former behaves more like a full OS. LXD containers are system containers which are like VMs except for the lack of guest kernel. So it allows me to experiment with some K8s deployment configurations that's needed on a proper cluster.

I use Kubernetes within an LXD container with Btrfs backing storage. This isn't anything special. But it has two advantages. The first is that you could try out multi-node K8s clusters on a single system. The second is that the containers can be deleted and rebuilt easily without affecting the host system. Both are very useful when you're learning multi-node K8s. I plan to expand my homelab to true multi-node setup. However, I will probably retain K8s inside LXD. It is useful to run certain applications that demand full control of the system - like PiHole or MailInABox. There are probably better ways of hosting them. However, LXD gives me a lot of flexibility to experiment and make mistakes.

I use LXD these days and I love it. It's easy enough to deploy without knowing too much internal details. Its CLI is also intuitive and well designed. It's true that LXD doesn't support installation outside snap. However, many distros like Alpine, Arch and Gentoo support its installation on bare metal from their software repos.

I was hoping to see a more modern alternative to the VTE terminal protocol and its derivatives. Does anybody have any good suggestions and possible implementations?

Oh! I missed the 'uncrewed' part! Nevertheless, the video itself has a good view of the failure. I can't wait for the public domain failure analyses based on it.

> On the positive side, it looks like if there was a real emergency the crew could have escaped.

Looking at the video, it seems like the BE-3 engine was having some trouble for about 3 seconds from T+01:01 to T+01:04 - just before the escape system was triggered. In fact, it looks to me like the entire aft section of the vehicle just disintegrated before the escape system plume covered its view. It might very well be that the escape system saved the crew.

Edit: Looking further at the video, it looks like the vehicle also lost attitude control and started tilting at that instant. It could easily be due to the loss of propulsion and thrust vector control. However, it also happens at a very critical stage - close to maximum dynamic pressure (Qmax). Any increase in angle of attack at that stage would put enormous aerodynamic loads on the airframe.

So, you're supposed to avoid doing factory reset on a phone once your account is banned? Sounds like an essential feature being held hostage.

You could set up auto-renewal. Good registrars also remind you when the domain is about to expire. In any case, using a custom domain is safer than relying on a single email provider.

The danger occurs when a human body is touching surfaces at different potentials. In fact, shorting all electric points together during a strike (using gas discharge tubes or something else similar) is the way to avoid accidents. You could ensure that the same applies to you when you're grounded - that is, anything else you're touching is also grounded.

Interesting! I will try out that tip. Thank you!

Thank you for the pointer! Definitely something worth looking deeper into. However, I was talking more about the software side of things - so that we won't be locked into a hardware platform. That said, they do have an idea in the right direction.

That's a problem with very easy solutions, considering what's at stake. Use a paperkey, NFC card, smartcard or even a printed data matrix sheet to store the keys and/or password DBs. The reason why all these aren't popular enough is that people don't consider privacy to be important - until something goes seriously wrong, like in this story.

Honesty, I wish self hosting was easy enough for ordinary people to do. Then there would be no reason to recommend people to fragment their digital life among dozens of ad-funded SaaS platforms. There is no reason why it has to be so hard. But not enough effort has gone into developing such systems due to obvious reasons. Sandstorm project, for example pioneered a model where users could deploy web apps like they would install mobile apps on their phone. Sadly, it didn't achieve the level of popularity it needed.

In addition, backing up the services isn't that costly these days. Backblaze provides massive storage space at cheap rates and integrates well with encrypted backup software like Duplicity, Borg or Restic. Recovery from failure is usually a breeze with these software.