tottenhm
Joined 12 years ago
Karma
324
Submissions
47
Member since
Jun 5
Recent submissions
Comment · 25 days ago
Some words reverberate.
Comment · 7 months ago
In Scotland, they close an issue by taking a vote of "OK", "Broken", or "Not Proven".
I believe they also have attorneys. Perhaps that's how Apple could make bug-tracking more effective -- hire a prosecuting attorney and a defending attorney for each bug.
Comment · 9 months ago
> In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it.
The agent passes the Turing test...
Comment · 11 months ago
Frequently use both `github.com` and self-hosted Gitlab. IMHO, it's just... different.
Self-hosted Gitlab periodically blocks access for auto-upgrades. Github.com upgrades are usually invisible.
Github.com is periodically hit with the broad/systemic cloud-outage. Self-hosted Gitlab is more decentralized infra, so you don't have the systemic outages.
With self-hosted Gitlab, you likely to have to deal with rude bots on your own. Github.com has an ops team that deals with the rude bots.
I'm sure the list goes on. (shrug)
Comment · 1 year ago
Same basic question -- at the price of $100k/ea, it does seem cheaper to build-out more satellite offices.
But there's a parallel push around taxing American firms using foreign labor (https://www.moreno.senate.gov/press-releases/new-moreno-bill...).
If multiple new policies are put in place at the same time, then... I dunno... it seems harder to predict...
Comment · 2 years ago
I enjoy this metaphor of the cow and the papier-mâché.
Presumably, there is a farmer who raised the cow, then purchased the papier-mâché, then scrounged for a palette of paints, and meticulously assembled everything in a field -- all for the purpose of entertaining distant onlookers.
That is software engineering. In Gettier's story, we're not the passive observers. We're the tricksters who thought papier-mâché was a good idea.
Comment · 3 years ago
Yes. But look at the bottom. There's an image with the PR review screen. There's one change:
* Normally, the big green button says "Merge pull request"
* Now, the big green button says "Merge when ready"
In a large project with lots of activity, a stampede of people pressing "Merge" at the same time will cause trouble. "Merge when ready" is supposed to solve this.
It seems to mean:
> "GH, please merge this, but take it slow. Re-run the tests a few extra times to be sure."
Comment · 3 years ago
One should make a distinction between:
* The general idea of mixing together filesystems+folders to achieve re-use/sharing/caching.
* The "Dockerfile" approach to this - with its linear sequence of build-steps that map to a linear set of overlays (where each overlay depends on its predecessor).
The "Dockerfile" approach is pretty brilliant in a few ways. It's very learnable. You don't need to understand much in order to get some value. It's compatible many different distribution systems (apt-get, yum, npm, et al).
But although it's _compatible_ with many, I wouldn't say it's _particularly good_ for any one. Think of each distribution-system -- they all have a native cache mechanism and distribution infrastructure. For all of them, Dockerization makes the cache-efficacy worse. For decent caching, you have to apply some adhoc adaptations/compromises. (Your image-distribution infra also winds up as a duplicate of the underlying pkg-distribution infra.)
Here's an alternative that should do a better job of re-use/sharing/caching. It integrates the image-builder with the package-manager:
https://grahamc.com/blog/nix-and-layered-docker-images/
Of course, it trades-away the genericness of a "Dockerfile', and it no doubt required a lot of work to write. But if you compare it to the default behavior or to adhoc adaptations, this one should provide better cache-efficacy.
(All this is from POV of someone doing continuous-integration. If you're a downstream user who fetches 1-4 published image every year, then you're just downloading a big blob -- and the caching-layering stuff is kind of irrelevant.)
Comment · 4 years ago
The whinging hits everyone. Look at any HN story involving the Bay Area, and you'll see a dozen subthreads about how it's a post-apocalyptic hellscape. (But it's home, you know.)
Speaking as an elitist left-wing hippie-business-geek-bro-demon in the Bay Area...
Kudos to the Columbus Area! Ohio, build it up!
Comment · 5 years ago
I can’t wait to watch Integration Test Email #2 at the same time next week.
Comment · 5 years ago
> What are we ejecting?
Ourselves, it seems. A Javascript framework is like a jet, and we are the human payload. You can stay in the jet, zooming over the constantly changing landscape. But if you get tired of this zooming around (or if you get scared of hitting a mountain), then you can activate the ejection seat (https://en.wikipedia.org/wiki/Ejection_seat). Of course, now you're a mile high without a plane, but the ejection-seat comes with a parachute, so the descent will be pleasant (or, at least, non-fatal - which is a style of pleasantness).
Erm, wait, I think you were soliciting a more literal answer. :)
"create-react-app" is the Javascript framework/jet. If you want to go for the ride, then you declare a single-dependency on "create-react-app", and they will decide when/what/how to upgrade components in the framework. If you don't want to ride along with "create-react-app"s framework, then you "eject". They'll give you a little bundle (the concrete list of dependencies) and send you off on your way.
Comment · 5 years ago
In case anyone is interested in that recall effort: https://www.recallsfschoolboard.org/
Comment · 5 years ago
In fairness, it does give choices -- https://www.php.net/manual/en/spl.datastructures.php
Comment · 5 years ago
Right, sprinkling #if's across a dozen downstream codebases sucks.
Consider an analogy to shell-scripting -- there are different shells ("bash", "dash", "zsh") which have substantial overlap (insofar as they largely support traditional POSIX). Someone writing a script/program can target a specific flavor ("#!/usr/bin/env bash") and get more features, or they can write conservative code and let downstream policy determine the shell ("#!/bin/sh"). General-purpose distros (like Debian/Redhat) don't seem to have a problem with supporting them side-by-side.
I'm more than a little rusty on the mechanics of dependency-management in C... but shouldn't it allow some analogous arrangement where an app either (a) signals a requirement for a specific implementation or (b) signals ambivalence/deference (and limits itself to common APIs).
(This, of course, only makes sense if the developers of LibreSSL/OpenSSL and of the distros believe that it's better to coexist+compete than to consolidate. The tenor of the LWN article seems to convey a XOR mentality, but if both projects have independently healthy teams, then... maybe they prefer friendly coopetition...)