It will be mine as well but only because consumer agentic AI became available and good. Only it makes all quirks and hardware incompatibilities bearable. I tell it to investigate the problem and it does an incredible amount of digging to help find the cause and eventually, after several iteration, either fix it or implement a good enough crutch. Even then it takes minutes to hours and I would take months.
How does this work? Do you give the AI read permissions on your system, or is it just running arbitrary commands?In the latter case, is it prompting you before each?
What's is the deal with Linux and suspend? It seems only a select few combinations of hardware and software can handle suspend and resume. AMD is commonly praised for their Linux drivers but my all-AMD system crumbles down on power state transitions and especially suspend-resume. I never though words "data", "fabric", "sync" and "flood" can be used together, but now they are a common sight in my logs.
It was so thoughtful of them to use IR tracking. Bed time gaming becomes much easier. I wonder if there was a choice between color passthrough and IR tracking and they chose the latter. Good choice!
- buy a custom build - have industrial build quality;
- barely any movement - good blood flow;
- avoid rolling - type fast;
- concave keyboards - tenting;
- fewer keys - minimal;
- uniformly shaped keys - touch typing feedback;
- keep hands on the keyboard - move pointer precisely;
- custom layout - conventional shortcuts.
This is ridiculous. I no longer take this field seriously. I get it, we get bored and need a new toy sometimes. Some indeed acquired a medical condition and need medical equipment to type now.
I noticed when I exercise I can sit comfortably on a firm basic stool, and when I don't I become a princess on a pea.
How about we start with the basics? Good posture, correct hand positions, monitor at the right level, exercise, nutrition. Then an IBM Model M would suffice.
This actually exists in every field to some extent.
Humans get bored and at some point, we need to make complicated answers/explications/justifications to stuff that are actually very simple.
Saying, just practice, pay attention and measure/test progress doesn't cut it for many; especially since some don't want to come to the realization that they'll probably never get better because of their own limitations.
This is why there are always people selling "solutions" that are mostly snake oil, the promise is always that it'll get better, faster, stronger, whatever.
One area that is ripe with those sorts of things is weight loss. It is an extremely simple problem, just eat less calories than you consume and you'll be good. But since humans are faillible and sometimes have hard time making progress, you get all kinds of protocols/tools and whatnot that only achieve the same goal but in a roundabout way.
If people believe in them, sometimes it helps (most of the time not). This is the exact same with keyboards, the problem is not at all with the keyboard, it's all lack of physical activity and bad posture. But saying: just take breaks, do calisthenics (or swimming or any full body workout sport really) and it will get better doesn't satisfy many. Those who want a "quick fix" they can buy are disappointed and those who want to sell a "solution" can't push their snake oil that would make them money (they often are believers themselves, so it doesn't matter if it doesn't really make a difference).
Not to be a Debbie Downer, but even if you use all of the correct postures, correct movement, and everything is done correctly, you can still end up with issues if you just do the same thing over and over.
It's relatively agreed upon nowadays that there actually is no "correct posture". The issue is primarily exacerbated by being in the same posture all of the time, doing the same movements all the time, and especially so in positions that aren't so natural for our body - and typing is not a natural movement/position for the wrists.
I developed issues despite always standing or sitting on a supposed ergonomic char, moving my hands a lot while typing, working out and exercising consistently, etc.
Until I started having issues I probably would have also been in the same camp that "oh this is ridiculous". Now I take anyone with chronic pain much more seriously.
One limitation of JSON is its limited set of types. For example, for decimal numbers one has to resort to stringly typing representation because DB connection libraries assume that JSON numbers are floating point. Note that JSON numbers are just sequences of digits, nothing more. There is no attached precision semantic.
Another example is UUIDs. Instead of transferring 16 bytes, the libraries deal with wasteful string representation. I'm sure you can bring another examples.
Nonetheless, for majority of data JSON as DB output format is alright.
Yeah, json is annoying because of the limited types, but postgres arrays/rows are annoying because of the lack of sum/union types (if your UI has a heterogenous list of elements).
I haven't yet given jj a proper trial, so pardon the ignorance. All I've seen are conveniences regarding the working the copy. Besides the subjectively terrible UI, my biggest gripes with Git have to do with collaboration. A rebase may unintentionally overwrite someone's work. A force-push to trunk breaks every other developer's working copy. With "distributed" being in the name of this whole class of VCSes, I would expect that such things just wouldn't happen, but here we are. As I understand it, jj inherits all of these problems and adds better concepts and UI for manipulating the working copy. I'm not sure this alone is a good enough justification for a switch. Of all the Git's features I use a tiny, proven subset and stay on the beaten path. It makes it bearable enough.
Working copy handling differences is certainly an aspect of jj, but, at least for me personally (esp. given me having grown up with git), it's probably my least favorite difference from git. And yet I've moved most of my personal things from git to jj (albeit with a bunch of custom scripts to make the working copy stuff more git-y).
A significant other thing jj does is introduce change IDs (i.e. a (randomly-generated) ID that stays stable even as a commit is amended), with which it should be easier to track changed commits across forks/rebases/edits/pulls/fetches, though I've yet to use jj for collaborative projects to see how much that pans out.
Generally jj makes rebasing things, and generally editing history so much more easy than git, so force-pushes messing with branches is much nicer to "fix" however needed. Being able to leave commits in a conflicted state and resolving only when actually needed also should help.
Technically, it's z-k (z=0, k=15). It makes for a nice root change ID: zzzzzzzz. Less choking than kkkkkkkk.
The relevance, btw, is that you can use git commit IDs in place of change IDs anywhere and they won't conflict; jj knows which you mean by the character set. (They could still conflict with bookmark names, sadly. But I haven't heard of that being an issue in practice.)
Bookmarks take precedence over change ID prefixes. And indeed if you add a bookmark "xyz" and a change had a unique prefix "xyz", the change's unique prefix will grow by one. (the unique prefixes can already grow or shrink semi-arbitrarily so this doesn't "break" anything more)
I am think you are misunderstanding the entire premise of git. There is no "force push to trunk breaks every other developers' working copy." There is no central repo/trunk where all the commits are pushed. You are probably thinking of svn.
In git, your repo is the canonical repo and that is where you work. You work on a new feature and when you are ready, you "git format-patch" and "git send-email" to the community via the mailing list or other developers. A discussion may happen and people may or may not decide to apply the patch to their own repositories, with "git am." This doesn't break every other developers' working copy because they decide how to apply the patches they got in their email. No central repo, no trunk, guaranteed by the d in git dvcs.
Not sure if you’re trolling, but with the benefit of doubt: that isn’t how almost everyone works, though. Almost everyone treats the repository which runs CICD as the central hub repo and everything else is a spoke.
I don't think they are misunderstanding the premise. They're just thinking at a higher level than you are. It's not too hard to imagine a VCS where rebases can't unintentionally overwrite someone else's work. In fact, Git has flags to avoid that! They're just off by default.
> A rebase may unintentionally overwrite someone's work
Since you're rebasing, you're intending stuff; nothing is lost until you force-push.
> A force-push to trunk breaks every other developer's working copy.
Which is why you avoid it and set the remote main branch to protected. You can't force push by accident, you intend to forcibly overwrite the remote branch.
JJ let's you have multiple "versions" of the same branch, although not directly. Typically it comes about when you've made changes and someone else has made changes, and the conflict resolution can't happen cleanly, due to each path taking a difference, unreconcilible approach. You'll have to resolve those and unify the different "branches", but it's no harder than any rebase in git land (generally easier because jj's conflict markers are even better than git's 3 part system)
In practice e2e tests don't cover all code paths and raise a question: what is the point? There is a code path explosion when going from a unit to an endpoint. A more low-level test can cover all code paths of every small unit, whereas tests at service boundary do not in practice do that. Even if they did, there would be a lot of duplication because different service endpoints would reuse the same units. Thus, I find e2e tests very limited in usability. They can demonstrate that the whole stack works together on a happy path, but that's about it.
You are testing that the software works. I think that is higher value than testing all possible code paths in isolation, and then still not having the guarantee that it all works.
I wish manufacturers of ergonomic keyboards would pay more attention to pointing devices. After all, with modern UIs we have to use the pointer. Having a hand jump to a mouse all the time is, at least, distracting.
Another factor is skeletal symmetry. Reaching for a mouse changes the natural balance of posture. I'm not a doctor, but it cannot be healthy over decades. That's why after many years I'm now using the pointing device with my non-dominant hand most of the time. My dominant hand only takes the mouse when I have to do precise or graphic work. This approach makes my back, neck and shoulders feel better.
And the last major gripe I have with most of ergonomic keyboards is how they misunderstand tactile feedback. They try to make all keys feel the same. Glove80 takes it to the limit with its uniform and flat key shapes and identical switches. I don't think this is helpful. Notice how F and J on most keyboards have bumps. Every key should have a bump, a unique shape, a unique surface texture. I want to subconsciously know I hit the right key.
For me, what has solved definitively the pointing device problem, after experimenting for many years with various mice, trackballs, trackpoints or touchpads, is switching to the use of a stylus on a small Wacom tablet as the pointing device (under Linux).
I use the tablet configured in the "Relative" mode, where it behaves identically to a mouse. The tablet has about the same size or somewhat smaller than a traditional mouse pad.
In comparison with a mouse, holding and moving the very light stylus requires much less force than with a mouse, the hand position is much more comfortable and the speed and accuracy of the movements are much higher.
Because the stylus is extremely light, I can keep it between the fingers while touch-typing with all fingers on the keyboard. Therefore when I alternate between typing and pointing the transitions are faster and more comfortable than with a mouse, because I do not have to grasp the mouse every time.
When I type longer texts, I drop the stylus on the tablet. I configure the stylus so that touching the tablet causes left mouse click and the 2 buttons that are on the stylus cause respectively right mouse click and double left click.
Regarding your complaint about key shapes, many decades ago I had used a high-quality keyboard, with Hall sensors for the keys, and where each key had a different shape and height.
Unfortunately, after assembling my first IBM PC/AT compatible computer, I had to abandon that keyboard, because it was incompatible (it came from some kind of DEC-compatible video terminal). Otherwise, I have no doubt that this keyboard would have still worked finely even today, as it did not have any parts sensitive to wear, unlike modern keyboards.
Svalboard can have various kinds of pointing devices integrated into it, within reach of your fingers without having to change your hand position, but it's a pretty extreme keyboard design even by modern standards.
