tsujp

Could you please elaborate, ideally in as much detail as you're comfortable sharing, on your Emacs and adjacent (org-mode, magit, any kind of syncing to your mobile phone with org-mode if that's done) workflow please. Often I find seeing people's real workflows (in detail and not wishy-washy) to be helpful since it gives me a concrete nucleus to crystallise off of... so to speak.

JS also has Crypto.getRandomValues()

The problem with the PGTK frontend is it is notoriously EXTREMELY slow. The latency on user input compared to the X11 (especially Lucid) version has some people reverting back to X11/Lucid.

When I do run Linux I run Wayland, I daily drive macOS, but better than both are what you already allude to: the Emacs widget toolkit which will focus on replacing the GUI frontend with SDL and also (equally potentially) introducing an actor-type framework (akin to BEAM's) for communication to decouple that GUI.

See: https://news.ycombinator.com/item?id=41821494

Understood, but in this (hypothetical) example his mother probably doesn't know exactly what angular velocity or torque are, so making things even simpler with a laymans "power" serves to get the point across.

One could include torque in the explanation to which the follow-up is probably "what's torque?".

The simpler one goes for that initial understanding, in most cases, the less technically correct one is; by design that helps the newbie learn and build up to a more technically correct understanding later on.

In general relying on excessive detail or jargon is symptomatic of not really understanding something when required to explain things in simple terms. I believe Richard Feynman said as much.

The general idea is people hide behind that detail/jargon precisely because they don't REALLY understand it enough to explain in simple terms what it is. That doesn't mean everything IS simple of course.

I assume you know now but in simple terms: the clutch connects the engine to the gearbox (transmission), so how well the clutch is engaged (connected) helps control speed. Gears multiply (increase or decrease) power from the engine depending on the gear you've selected.

I'll need to look into this but if anyone knows: is this available (easily) as a standalone package somewhere; think using the engine from a CLI without needing or contacting Google Sheets at all.

FINALLY!!

For 12 years visually vertically centreing text has required adding a padding or margin of a few pixels to the bottom or top, now (when adopted) it can be done properly.

Hey Jarred, big fan of your work on Bun.

Until recently I've been using Deno (mostly to avoid using Node and the tooling hell that entails) and it looks like for my use-cases Bun is getting there. I've had a pleasant experience using Bun as the basis of a test harness.

Here's my question (with a tiny bit of lead-in):

What I like about Deno is the integrated LSP (reducing tooling hell), are there any plans for Bun to feature this too? Bun already internally transpiles TypeScript which is great but having the LSP bundled too would give this single binary integrated experience a boon I feel.

Looking forward to Bun 1.0!

P.S. I'm starting to stretch my Zig muscles, you looking for Zig developers? ;)

Fines should be at least 100% of _revenue_ from these activities to actually punish the business. At the very least 100% of _profit_ from the activity. Anything less is cost of doing business since it's by definition a net profit.

This is the most disgusting thing I have ever read. My blood is boiling to the point where I genuinely don't see a bright future.

Ben Wiser (Google), Borbala Benko (Google), Philipp Pfeiffenberger (Google), and Sergey Kataev (Google) have got to be the most repugnant people on the planet for pretending this is anything but a scheme to destroy all privacy and freedom on the web all so fucking Google can sell more ads.

Location: Melbourne, Australia.

Remote: Yes, hybrid is also fine.

Willing to relocate: Yes: U.K (I'm a citizen), South Korea, Japan, Germany, Singapore, France, The Netherlands, U.S., or within Australia if it makes sense.

Technologies: {Java,Type}Script, Ruby (on Rails), Node/Deno, React, SolidJS, AWS, Azure, .NET, C#, F#, some C and Zig, POSIX Shell/Bash, some Python, Terraform, Ansible, SaltStack.

Résumé/CV: https://www.linkedin.com/in/tsujp/ (email for full PDF, references) and https://github.com/tsujp

Email: jc [plus] j [dot] yc [at] wz [dot] ht

I do DevOps and Software Engineering (particularly full-stack web but increasingly more systems programming). I will happily learn new technologies and enjoy learning in general as well as partaking in challenging environments where application of knowledge and skills solves problems.

The changes should be the main meat of most commit messages and if the intent or other options considered add value to that then they should be included below.

The reality is if the intent, other options, relevant notes etc are not valuable then they will be lost to time (no loss). If they are valuable where else are you going to put them? Some wiki or knowledge store for your project? How will you know that this specific commit and that (probably) sparse text in said knowledge store are related? Why not just put them together where they belong anyway.

Commit messages are not valuable when they are maximally short. They are valuable when they describe the changes the commit applies and ANY other relevant information for people (including the author(s)) in the future so that said people can understand the commits effect and other relevant information.

For an example of amazing commit messages look at PostgreSQL’s. They are sometimes long with the changes, notes, intent etc and sometimes short.