abathur

Two thoughts:

I agree most of the compatibility concerns mentioned are moot, but I guess it will cause small amounts of one minor ~forward-compatibility problem: people working on Fedora hardcode new paths that won't work on other distros unless/until they follow suit.

---

In late 2019 I started work on a tool for ~wrangling external shell script dependencies to help us package shell better in the nix ecosystem. (the tool itself is generic, but it's currently only packaged for nix.)

The main goal is to identify external dependencies in a ~source script, require them to be specified/present, and output a rewritten script with absolute paths.

It handles existing hardcoded paths by treating them as an error that the user has to address by either telling it to just resolve them as if they were bare, or to keep as-is.

Perhaps by coincidence, there's a good post on treeshaking+wasm on the front page this morning: https://news.ycombinator.com/item?id=40023319

I imagine the answer's ~yes from the perspective of something you build and deploy (and I agree it's relevant to the article--but I'll caveat that I read xamuel to be asking the question very broadly).

Relying on a post-build process to avoid deploying unused code and dependencies still exposes you to a subset of problems with most if not all of the dependency graph.

Sufficiently-rich correct-by-definition metadata on the internal and external dependencies of each package might let you prune some branches without requiring the dependency to be present, but in the broad there are a lot of cases where that can't really help?

> Some package managers have "features" (e.g. Rust's cargo) or "extras" (e.g. Python) which might be what you are talking about.

I don't think so (though I agree that mechanisms like this are one way to approach the problem).

AFAIK both of these examples are mostly used to provide ~optional behavior (usually to exclude dependencies if you don't need the behavior). This can minimize the set of dependencies, but it's resting on the maintainers' sense of what the core of their library is, and what's ancillary. Said the other way around, both require the software's maintainers to anticipate your use case and feel like it was a good use of their time to split things up very granularly.

In xamuel's hypothetical of library A using one minor thing from library B, this almost certainly means reusing less of library B than its maintainers anticipate.

I can imagine this working in cases where the package is a true bundle of discrete utilities that almost no one will need all of (the package itself is an incredibly small core/stub and each utility is a feature/extra), and the maintainers want to intentionally design it for modular consumption.

But it's hard to imagine many maintainers going through the work of dicing a cohesive library up into granular units when they think most users will be consuming it whole?

I guess there's a hybrid model where you're able to select exactly what you're depending on and pull it in dynamically at build/package time.

I've thought a little about, for example, building something that could slice just the needed utility functions out of a Shell utility library. (Not really for minimizing the dependency graph--just for reducing the source-time overhead of parsing a large utility library that you only want a few functions from.)

Would obviously need a lot of toolchain work to really operationalize broadly.

I can at least imagine the first few steps of how I might be able to build a Nix expression that, say, depends on the source of some other library and runs a few tools to find and extract a specific function and the other (manually-identified) bits of source necessary to build a ~library with just the one function, and then let the primary project depend on that. It smells like a fair bit of work, but not so much that I wouldn't try doing it if the complexity/stability of the dependency graph was causing me trouble?

Thread a few months ago ~about a risk associated with getting habituated to automatic dependency-update PRs and looking at them less critically:

https://news.ycombinator.com/item?id=37680443

Sure. I don't recall seeing one, but the near-inevitability of this is why I didn't assert they don't exist.

Rarity speaks to how poorly suited the material is for building durable fences and the ~irrelevance of the cost of plywood in this subthread.

I can't recall ever seeing a plywood fence in North America.

I'm not sure it's intrinsically bad news for the diet (but I won't dispute that it's a challenge for how it's usually followed). I haven't met one, but I've at least heard that there are vegans following ketosis-inducing diets.

Oblique, but since this topic might be catnip for people who'd know:

Anyone aware of a Python parser for the Awk language?

I found a number of Awk-alikes implemented in Python, but they all sounded like they took enough liberties that I wouldn't expect them to have a parser worth trying to lean on to parse wild Awk scripts.

Since your definition seems to be a sharp enough razor to triage 50 comments and I'm not read-in enough to tell from the OP, can you help elucidate? :)

Are we talking about work on so-called intelligent agents (something with a primitive OODA loop?), a specific ~pattern of conversational AI chatbot, or something else?

FWIW, I tend to find that it doesn't have to be a full brain idle. Some active component seems to be helpful, but I think it needs to be easy to pause and that there's a sweet spot on the amount of engagement.

Reading actual books or other longform documents is usually pretty fertile/generative. Watching youtube or a movie or listening to a podcast doesn't do the trick. Writing and editing are both also pretty good.

Walks are good, but biking/running/swimming don't seem to be.

Programming can be good in the sense that it regularly reveals missing tools/libraries, but I don't find the work itself all that generative.

Can you elaborate on why to see it, also, since they look like forks of the same project?

When adhering to if+keto well lines up with a period where social pressures don't compel me to eat, it's not terribly hard to go 2 or 3 days without eating just by not eating until I feel hungry.

Not directly related to leap year, but a couple weeks ago I set up a script for testing notification behavior that used libfaketime to simulate runs at different times.

I guess this might be less-trivial if you've got a distributed multi-service architecture and perhaps also depend on APIs that aren't under your control in the first place.

I wouldn't try to insist anything I sketched out is the ~right approach. I was just trying to imagine one path through the possibility space, and then reason a bit about what kinds of information it might be able to convey.

There are almost certainly better paths through, and I suspect the idea isn't broadly usable without different kinds of tests that have different kinds of rules. It's probably not helpful to have to increment your major version just because you use snapshot testing and some dependency update causes a trivial shift in the output.

I also fiddled around a little with an idea I called "earmarks", which are basically just version-bound tests. You could use these to express the idea that, say, test_x shouldn't pass or fail until the version is >= a.b.c.

This would make it easy to deprecate an API today and go ahead and ship a test that requires the API to be present and functioning until the next major release but not after. Or, for example, to make a commitment device that asserts the project will hit some doc/lint/typing goals by some clear point.

Since it's an open-ended mechanism, I imagine something like it is the lower-friction way for a real project to explore applying these concepts without full toolchain support.

I fiddled around a little with the idea of test-driven versioning a while back. Maybe you'd find it interesting. https://github.com/abathur/tdver

I did draft a git-based implementation (https://github.com/abathur/tdverpy), but it just obviously can't be as compelling as one that was part of a language's native tooling/ecosystem could be.

Since you're apparently here to play semantics games: if you aren't willing to pay your employer for the opportunity to solve their problems, you don't want the job.

I doubt it?

My willingness to practice leetcode isn't correlated with my interest in new work or the work any given job post describes. It's also not correlated with my willingness to invest time in exploring the position.

6 hours of leetcode practice teach me nothing about a position, the work it entails, the problems the company is grappling with, and the people I'd be in the trenches with. 6 hours in conversation or working close to real problems are higher leverage.

I have meaningful open source work with real users in the queue, and blog posts that won't write themselves. I feel like it's pretty reasonable to sort positions that don't compel low-leverage busywork that doesn't help me assess the position above those that do.

Sure, they might mean to exclude me, but I'm skeptical.

The interview the post describes actually sounds like a good format for me, but I do have some problems adjacent to the ones you mention.

As someone who struggles with ~parallelizing some tasks (especially when anxious), it would be great to have an up-front check in about how comfortable I am with the format of any technical ~challenge. (And even better to discover there's some wiggle room to accommodate.)

For example, I find it very difficult to code my way through a problem and narrate what I'm doing and take feedback while I know I'm being evaluated and the clock's ticking. If the interviewer says something important in the middle of this, I often have to put down any plates I've managed to get spinning (and maybe go offload some adrenaline) and then ask them to repeat before I can even parse the words they said, let alone figure out how they apply to the problem.

> was willing to submit to it for the approval of this company

I abstain, myself. I have too much real work that I'd like to push forward to be able justify spending weeks of free time on fake work.

Definitely sounds like something a Russian bot would point out

Home alone seems to be perpetually recombinant. Over 10m :)

There are also some of us who are just not great at demonstrating intelligence by narrating our thought process while under an adversarial spotlight with a timer running.

I realize there are time/resource problems on the interviewing side, but I'd be happy to have conversations that are as long and technical as it takes for an interviewer to feel like they've found bedrock.

Whether they pass me to the next phase or not, it's frustrating to spend 30 minutes or 3 hours trying to start a fire by rubbing wet twigs together and never get to walk away feeling like I've communicated more than a few percent of what I bring to the table.

I don't think it's mostly good or mostly bad in the abstract.

DRYing code repeated for the same reason is mostly good.

DRYing code coincidentally repeated for different reasons will sow code churn or inadvertent behavior shifts.

Just a general recommendation from someone who keeps a long history: if your shell loads a histfile, don't let it grow unbounded.

It isn't massive, but there's real shell startup latency associated with loading lines from your histfile. A few hundred isn't really noteworth, but tens and eventually hundreds of thousands of lines can add up.

(In my case, i store them in a database and I synthesize histfiles from the db. Keeping the permanent storage in a separate file also probably works.)

> Where I struggle is coming up with an affirmative argument that an artist should benefit from automation of medicine or farming, but that an alienated lab tech or food factory worker should not benefit from automated art.

> Another way to look at this is: the less you pay for art-as-entertainment, the more resources you have to buy free time to produce your soul-work (whatever that may mean to you).

Ah, yes. The alienated workers of the world will warm their weary souls at the hearth of derivative algorithmic creativity units. The reduced price and efficient delivery of each drone's creativity units will obviously give them more free time.

Perhaps we can even come up with a pill that'll let the drones feel entertained without any content at all. If the side effects are well-tolerated, they can take it before work.

I suppose I don't really disagree with you, but a fair fraction of us would be likely to mourn, in fora like this, the end of the ability to sustain a middle-class existence via the craft of making software.

Idk if it would out of the box, but it should be possible. I know that Whisper (and some variants) run on both x86 and silicon macs.

At least in my opinion, the leverage here isn't about directly saving time in some hypothetical universe where you set up new devices every week.

It's about confidence in your ability to quickly bootstrap a productive system and the relative freedom/security that flow from knowing it.

When you know you can be productive this quickly without access to a backup or a working device, you have relative freedom and security from a decent spectrum of manufacturing defects, hardware failures, disasters, accidents, thieves, and so on.