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.
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.
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.
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.
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.
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.
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.
There's also Boon which I like quite a lot but I opted against using mostly because of all the places I would need to type where I wouldn't have access to Boon unless I ported it (a plan I assure you but one lumped behind 1,000 other projects TODO).
Addressing just the capture: I don't see the problem with `||` at all, in-fact I think it's elegant. I do like (most of) Ruby's syntax so that's probably where my fondness of this comes from but I am not a veteran or seasoned Ruby expert by any means.
It is _technically_ cool but I feel like this existing is a definite step backwards with regards to Node.js' lack of modern web APIs.
Software like this relieves pressure in moving from Node.js specific APIs towards standardised web APIs and in addition to that itself boasts about portability by ignoring modern features too. From their WebContainer vs Nodebox FAQ:
Nodebox runs on any browser because it was built from the ground up with cross-browser support in mind, avoiding modern features like SharedArrayBuffer."
So now we've got an escape hatch for Node.js not having to implement modern APIs because software like this implements its runtime for the browser, and also this same software removes pressure on browser vendors bringing their implementations up to webstandard specifications by "... avoiding modern features".
While this is _technically_ cool I feel like it's a lose-lose for the overall ecosystem.
Honestly I hope Google go through with this as it will direct people to Firefox so they can continue using ad-blockers like uBlock Origin.
I don't know how many will come but if Google wants to implode their plugin ecosystem in favour of more advertising, and if that action increases Firefox adoption (and thus a healthy browser ecosystem via competition) then I am for it.
I haven’t used Heroku in a few years mostly because I haven’t had the need but also because it feels too expensive.
The 30 minute sleep is way too high and as others have mentioned will easily drain half your hours away. If you could configure it between say 10 and 30 minutes (I’d say as low as 5 but this is the Hobby tier) that’d feel a bit fairer.