nrr

Fossil (https://fossil-scm.org) is actually a proper grow-only set from what I can tell: merge conflicts upon synchronization are encoded in the DAG as forks of the history at the conflicting points in time. If no action is taken after a fork, all clones will eventually see the exact same view of the history.

The tooling will normally bail with a "would fork" message if a `fossil update` (and, hence, local resolution of those conflicts) wasn't undertaken before pushing, but this is not at all necessary to preserve useful operation.

The larger problem in my mind is that a lot of asset purchases bestow a lot of tax deferment privileges because of how the tax code is presently written.

Consider someone who holds a lot of capital with unrealized gains but nonetheless needs cash flow. A common practice is to borrow against those unrealized gains, which itself doesn't count as income even though it nevertheless tends to result in a greater accession of wealth.

The play, hence, seems to be that we consider the borrowing against unrealized gains to be the taxable event, not a wholesale tax on all held assets.

"It felt like procrastination, a tech version of a bullet journal." There's a lot out there that certainly falls under what I call "procrasturbation," but the Bullet Journal is ironically the thing I've stuck with the longest. Ryder Carroll came up with a formalization of the concept more recently, but I've been using it since 1999, prompted by the removal of our backpacks due to Columbine.

I think the thing that a lot of folks miss is that it's a framework that's meant to grow incrementally with how you go through life and work.

Without a bag to keep everything together, I got tired of misplacing my notebooks, one for each class, so I started living out of only one at a time, which then led me to set up a sort of table of contents and numbered pages so I could find things. It also let me cope with my as-yet-undiagnosed OCD and ADHD by giving me the permission just to start at whatever page and treat the bound pages as a linked list instead of an array. (Bonus: the table of contents became a sort of allocation bitmap.)

Homework due dates and holidays and birthdays begat calendars of various sorts, inconsistent study habits begat habit trackers, notes from class meetings begat dailies wherein I braindump about whatever, etc., but none of that happened overnight. It built up over months to years.

Journaling is about the stuff you want to remember later so that you can reflect on it. Most of my entries involve doting on my cats (so many days where I'm just like, "Valérian was an aggressively cuddly purrbucket again" or "Laureline brought me another sock from the hamper") and, like, "on a lark, I dug out my old ThinkPad to find it actually isn't inoperative."

I'm not and never have been NSA, but I nonetheless have a sordid past with what is arguably a related line of work. This is how I manage my passwords.

In environments where regular rotations are required, I print off a new "biscuit" via `(date ; pwgen $PWGEN_FLAGS) | lpr`. I then append to the candidate password something of a personal identifier that only I know.

I'm not sure I agree, particularly given that there's some incentive for us to get our relatives using these messenger protocols and clients. The Web made it work because everyone came together and gathered consensus (well, modulo some details) that enforcing HTTPS is, ultimately, a good idea given the context.

So far, I'm not seeing that same consensus from the XSF and client vendors. If the capital investment can be made to encourage that same culture, the comparison can perhaps be a little closer.

I don't see any practical difference between "it depends" and "no" here.

"You need to run your own platform people." What problem does this solve?

I'm someone who's been on the business end of a subpoena for a platform I ran, and narcing on my friends under threat of being held in contempt is perhaps the worst feeling I'm doomed to live with.

"XMPP is ..." not the solution I'd recommend, even with something like OMEMO. Is it on by default? Can you force it to be turned on? The answer to both of those is, as it turns out, "no," which makes it less than useful. (This is notwithstanding several other issues OMEMO has.)

What's funny is I remember when those Microsoft Management Console snap-in tools were brand new, and what came before them was a lot less nice to use.

(They might be MFC. Windows 2000 is about the right time for Microsoft to be C++ happy enough to push developers to use it over just using the bare Win32 C APIs. MMC was a pretty big deal when it first came out.)

"The only notable software produced ... is ... essentially a UML editor ..." Yes, correct. It's a CASE tool, at least when you have a computer to assist with using it. For harder-hitting software applications, I never took much stock in using it as much more than a better way to diagram out the basic blocks when analyzing the disassembly of something, and I'm usually doing that by hand, without computer assistance.

More broadly, I never expected much from my CASE tools actually generating code for me: the scaffolding was possible, but any sophistication beyond that just never materialized. That ship sailed right around the turn of the millennium, and none of what DRAKON does innovates on that.

"It's not verifiable." Thanks. I always figured that a lot of this chaff was just marketing.

I'll try being more direct.

I have a tightly-defined universe of discourse here, and you are operating almost completely outside it. Why is your engagement with my comment relevant beyond the connection to DRAKON?

So far, I've seen you write about cultists and Buran and, now, how sequence diagrams and state diagrams are superior. That final bit could admittedly make for interesting conversation, but I've heretofore not seen significant substantiation from you or, hell, any interrogation from you why I even use DRAKON.

Dare I say it, but I feel like I've been the target of your trauma response here, and I don't exactly appreciate it.

"The cultists claim that it IS a machine language." Cultists? I'm still left scratching my head as to how this is relevant to my comment.

I wrote about the Fregat upper stage, DRAKON's expressiveness as it relates to recursion with an example of an environment where it might be undesirable, and how the implementation of quicksort shown on Wikipedia is "perfectly fine."

Where are the cultists there?

Forgive me, but I'm left scratching my head. I can't find where I mentioned any of this.

Buran's cancellation predates (given my limited command of Russian, what I think is) the first evidence of DRAKON's production use in the engineering process for avionics systems by almost a decade. Nowhere did I bring up that particular orbiter.

I'm also unsure where I wrote that DRAKON by itself is machine consumable. I'm only familiar with it as a pattern language for drawing diagrams, and that's the extent of my experience with it.

I feel like the degenerate case is the happy path for basically any sorting algorithm: the computer doesn't need to do work. That'd make the leftmost skewer in the Wikipedia version of DRAKON quicksort perfectly fine.

As far as recursion is concerned, consider that DRAKON has exactly the expressiveness of assembly language. For environments where modified condition/decision coverage[0] is important (where analysis of branches at the object code level is commonplace), recursion is very likely undesirable, so not having a good way to express it is probably more a feature than a bug.

The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace has to do with the Fregat upper stage[1] (though, I don't read Russian beyond an elementary school level, so I don't know what is actually said here), but given what I know of DO-178B and applicable NASA standards for safety-critical systems, it'd make sense to have DRAKON as part of the tooling.

0: https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm2108...

1: https://www.laspace.ru/upload/iblock/db0/db01beb741f3e811d58...

You have a firm deadline and presumably something with a lot of unknowns that needs to be shipped. That's pretty risky. Here's how I've tried to get a handle on similar risks with a background in statistics and operations research. (Please forgive me for the length.)

For 1., 2., and 3., as frequently and synchronously as feels reasonable. Having a synchronous ritual of closing out the day (as opposed to opening it as is all too common) is tremendously helpful ("What did you all get done today? What warrants concern? Now, go home!"), and given that you're working in sprints, that reporting period should be good enough for most of the heavier-hitting touchpoints. Hijacking your sprint retrospectives for this is perfectly fine. If you need to meet synchronously more often for housekeeping, you'll know.

One-on-ones are a personal thing. Again, use your best judgment.

If the andon cord is pulled and kills the sprint early, say, kick your manager a quick email to let them know what's up. Their time is likely more valuable than yours, and it's worth trying to have trust that they'll let you know if they feel a synchronous meeting is necessary. Otherwise, the same advice on one-on-ones and other synchronous recurring meetings applies.

Everything else can be over email or your asynchronous messaging service of choice.

For 4., find someone with an MLIS degree. Seriously. Hire a librarian.

For 5., I'd strongly recommend adopting a practice that tries to minimize context switching as much as possible: just as in operating systems, context switches here are utter killers of performance and will slow you the hell down. Namely, if you have support obligations (for "site up," say) alongside needing to work on shipping and improving a product, establish a rotation (or possibly more than one) and include fixed-date product backlog items reflecting that/those rotation(s) to be considered during sprint planning that temporarily completely remove those individuals from product work. This will help keep those facts in front of you and make sure that the sprint workload commitment "feels right" given the regular reallocation of labor.

Completely removing those folks from product work will also help with bus factor concerns.

The team captain should run interference as much as possible for other interruptions like middle management drive-bys.

For 6., the name of the game here is what's called "one piece continuous flow:" the team is what ultimately ships things, not individuals, but it's the individual contributors coming together in lock step that enable each piece to be shipped. Folks going off on their own is fine in moderation (say, e.g., when reading and subsequently formulating comments to a design document or a report), but it can't be the norm.

Make your product backlog items trackable in a spreadsheet and try as best as you can to eschew relying on tools like Jira. I've had reasonable success with just giving suits an Excel spreadsheet with some VBA macros and pretty graphs: a lot of them know that tool well enough to make it work it turns out. Jira's nonetheless pretty familiar these days, but the complexity inherent in organizing work in epics and sprints and with tags and projects and workflows and screen schemes is a little too tempting when the actual work gets hard. Cut out as much meta-work as you can. Meta-work is expensive waste, and it, like context switching or rewriting your Emacs or fvwm configuration for the umpteenth time, will obliterate your performance.

As a corollary regarding meta-work, you can't scrub your bug tickets if you don't have bug tickets to scrub to begin with.

The team captain should have a habit of "management by wandering around" if they've doled out sprint work for the day to two or more subteams, albeit in a more systematic and regular and regimented fashion than the name implies. They should have a good "feel" for when folks are stuck and be willing to break through the bashfulness sometimes inherent with impostor syndrome by jumping in to pair with them. That feeling of not being good enough or a waste of time entirely evaporates when there's someone experienced roaming around to help proactively.

This all said, mobbing or pairing is only good to start, but you really need a collaboration of someone with proper product ownership (and not merely project management) and a sort of team captain on the development team itself to chart a course and make adjustments.

Hope this helps.

I've long used the US international layout with Alt-Graph deadkeys. (For the full experience, you can perhaps buy an ANSI format keyboard from the Netherlands?)

It takes some practice getting AltGr+y as ü and AltGr+w as ä and AltGr+p as ö into your muscle memory, let alone AltGr+circumflex instead of just circumflex to get the dead key (raison d'être requires AltGr+Shift+6 to type properly), but I've found it's otherwise a remarkably workable tradeoff.

No. On German and Swiss layouts, that key is a dead key: it doesn't type anything by itself when you press it. It's meant to combine with another subsequent keypress in order to yield a whole glyph with a diacritic as in, e.g., backtick followed by "e" giving "è."

It's been a while since I've been at a proper QWERTZ layout aus dem Sprachgebiet over a US QWERTY keyboard, but my memory is that the dead keys have odd behaviors when you try to incorporate them into shortcuts.

I suppose this makes sense if you have relatively few windows that each themselves encompass self-contained task state: one terminal window with a bunch of tabs, one VS Code window with a bunch of tabs, and so on.

I've always found this rather, uh, un-simple to deal with because I both suffer from attention problems and because I tend to want to consider a whole box of windows together as a complete task. macOS's per-appbundle model, inherited from NeXTstep, isn't perfect, but it does at least get closer to what I want.

I used to write software in Delphi, and Alt-Tabbing through several forms and code windows and panels and hypertext documents and compiler error listings and whatnot was just a gigantic pain. It really, really soured me on Windows' way of doing things: I could just never get the mental model down for how windows would stack in the Alt-Tab order given my need to flip between six or seven of them somewhat randomly in the course of working on something.

My argument is exactly about the ergonomics. If the goal is to target Gnome in particular and take advantage of C interoperability (ideally, without the overhead of a foreign function interface), Vala seems like a solidly ergonomic solution to that problem.

I'm talking beyond saturation.

There are actually quite a few resources for which I'd like to maintain something resembling steady-state saturation, like CPU and RAM utilization. However, it's when I've overcommitted those resources (e.g., for RAM, no more cache pages that can't simply be purged to make more room for RSS) that I start to see problems. (Of note, if I start paging in and out too much, that can also affect task switching, which leaves the kernel doing way more work, which itself can lead to a fun cascade of problems.)

"A desktop environment does not need its own language ..." I'm unsure that I agree. Given that part of Vala's raison d'être was interoperability with C and that it integrated well with the parts of the desktop environment that made it a desktop environment (i.e., the gadget toolkit and the accompanying services), if I wrote GNOME (Gnome these days?) applications, I'd probably be fine writing the UI in Vala and the rest of my logic in something that, at a minimum, spoke the C ABI.

Likewise, I used to write Windows software in Pascal with parts in C and C++ because I oddly both found Win32 and COM and found interfacing with third-party libraries easier to deal with that way.

One thing to be aware of is that up/down alerting bakes downtime into the incident detection and response process, so literally anything anyone can do to get away from that will help.

A lot of the details are pretty application-specific, but the metrics I care about can be broadly classified as "pressure" metrics: CPU pressure, memory pressure, I/O pressure, network pressure, etc.

Something that's "overpressure" can manifest as, e.g., excessively paging in and out, a lot of processes/threads stuck in "defunct" state, DNS resolutions failing, and so on.

I don't have much of an opinion about push versus pull metrics collection as long as it doesn't melt my switches. They both have their place. (That said, programmable aggregation on the metrics exporter is something that's nice to have.)

I used to work on this particular site (and all Turner properties more broadly), and there was a culture internally of talking about the site visitors not as customers but as the audience. Our real customers were the advertisers after all.

CartoonNetwork.com (and CNN.com and adultswim.com and so on) all had a reason to exist, and it was primarily funded by marketing and advertising. The interesting takeaway from Zaslav completely axing a site like this is that it's indicative of advertisers not being the cash cow that they once were.

Unfortunately, I have no idea what godot is. I would like to know more though if you're so inclined.

(Surely not the game engine? That's the only thing my disambiguation machinery can come up with.)

"... I think FP programmers seem to have a distaste for debuggers ..." I'm unsure that I'd make this assertion so broadly. For Haskell, I'm usually left using Debug.Trace because I've found the traditional symbolic-step debugger is less than ergonomic in the face of lazy evaluation. In Common Lisp, the debugger is my best friend.

"... and graphical debugging/development environments" The loud ones might be saying they use Arch btw (on ThinkPads no less) and lean heavily on using neovim inside the current popular Rust rewrite of tmux, but I personally don't care for it.

VS Code is neat. I mostly still use Emacs because that's where the tooling investment has historically been, but my ideal is definitely much closer to Smalltalk-meets-Oberon.

This has also been my experience, yeah. My interviewers were very interested in watching me rifle through that core dump. (:

Ultimately, it feels to me like selecting for people who both can navigate existing code and interrogate a running system (or, minimally, one that had gone off the rails and left clues as to why) is the right way to go. It has interesting knock-on effects throughout the organization (in, like, say, product support and quality assurance) that are direly understated.

It comes down to how the standard library makes you do things. I don't think there's any reason why a more stringly-typed way of handling JSON (or, indeed, a more high-level way of using HTTP) is outside of the realm of possibility for Go. It's just that the standard library authors saw fit not to pursue that avenue.

This variability is honestly one of the reasons why I dislike interviews that require me to synthesize solutions to toy problems in a very tightly constrained window of time, particularly if the recruiter makes me commit at the outset to one language over another as part of the overall interview process. It's frustrating for me, and, having been on the other side, it's noisy for the interviewer.

(In fact, my favorite interview loop of all time required that I use gdb to dig into a diabolical system that was crashing, along with some serious code spelunking. The rationale was that, if I'm good with a debugger and adept at reading the source that's in front of me, the final third of synthesizing code solutions to problems and conforming to institutional practice can be dealt with once I'm in the door.)

They do! A lot, it turns out.

Is this true? This doesn't jive with my lived experience, particularly when you consider walkability/wheelability.

The suburban shopping mall, oddly enough, is something of a counterexample. People in aggregate will easily put up with the agony of walking half a mile from a parking space, and extrapolating to a setting more urban, this is roughly what downtown St. Louis around Busch Stadium is like.

The MetroLink isn't the most convenient thing either, but Busch Stadium and whatever-the-Kiel-Center-is-called-this-time are very well trafficked for Cardinals and Blues games (particularly in light of very limited parking availability), and shopping and eating over on Washington Ave west of Broadway doesn't seem to suffer either.

When you conceive of Teenage Engineering first and foremost as a design firm that incidentally tends to release neat synthesizers, so much of what they do will make way more sense.

I'm honestly unsure whether djb would actually find anything other than his qhasm tolerable (yes, even Zig). I find this particular commentary from him unsurprising.