Some words reverberate.
324 karma · joined June 5, 2014
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.
The agent passes the Turing test...
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)
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...
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.
* 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."
* 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.)
Speaking as an elitist left-wing hippie-business-geek-bro-demon in the Bay Area...
Kudos to the Columbus Area! Ohio, build it up!
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.
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...)
But... the article also says:
> ... it is not possible to install both OpenSSL and LibreSSL on the same system.
That combination -- not-compatible and not-coexisting -- sounds rough.
Anecdotally, for the project where I contribute most... the issue about fewer contributors is real. But you do still get contributors, and PR-workflow makes other aspects easier (like broad clean-ups/reorgs/scheduling/versioning). For contributors who come, you also get the opportunity to socialize/engage them during review. Overall, there are drawbacks/risks, but I'd say it was a net-improvement (wrt quality/clarity of the final docs).
Maybe look at it this way: Both workflows provide a way to organize open/community docs. Both workflows have positive role-models. In both, you need capacity+interest for editing, for socialization, etc. If you tend to these, you can do good. But if there's neglect... then that's where you'll see the starkest differences:
* In wiki-workflow, the likely symptoms of neglect are draft-quality content, bad prose, quirky TOC, drive-by edits that are out-of-place, etc.
* In PR-workflow, the likely symptoms of neglect are slow review/feedback, older content, would-be contributors who can't assimilate to the workflow, etc.
Let's make an example. Suppose a "rational investor" in a globalized market is considering whether to manufacture a commodity in San Francisco or Jaipur.
The cost of living in San Francisco is 200%-2000% higher than the cost of living in Jaipur.
https://www.numbeo.com/cost-of-living/compare_cities.jsp?cou...
The rational, by-the-numbers move is to put the factory in Jaipur because exchange rates make it radically cheaper. That's the real driver. Even if the would-be workers in SF made every conscionable concession and slogged for 25 hours a day, it wouldn't overcome the currency differences. Even if the workers in Jaipur had the most generous PTO and the most corrupt union boss, it wouldn't overcome the currency differences.
Of course, if you were pitching a town in South Carolina against a town in Pennsylvania, then maybe you'd consider numerically small differentiators like "how much extra do you have to pay for the 9th hour of work" - because small differentiators are the only differentiators available.
But that's not the issue with globalization. "Globalization" doesn't mean "moved from PA to SC to trim wages by 5% via lax overtime rules". It means they moved to Vietnam or China or Bangladesh to change the basic unit of measure with an aim to slash labor costs by 50% or 80%.
Yeah, no. I mean, I don't know this guy from Bob, but the above has neither citation nor argument, and everything I've seen disagrees with that assessment.
Skim the list of the board of advisors...
https://www.persuasion.community/p/our-board
Several names pop out - and not because they're alt-right / reactionaries / populist right-wingers. Some bios:
https://en.wikipedia.org/wiki/Anne_Applebaum https://en.wikipedia.org/wiki/Francis_Fukuyama https://en.wikipedia.org/wiki/Garry_Kasparov https://en.wikipedia.org/wiki/Sheri_Berman
Again, I don't have any personal knowledge here, but it's interesting to consider, eg, this bit from Wikipedia:
https://en.wikipedia.org/wiki/Yascha_Mounk#Political_positio...
> Mounk stated that he had changed his position on nationalism. He initially considered it a relic of the past that must be overcome, but he now advocates an "inclusive nationalism" to head off the threat of aggressive nationalism. On the German television newscast Tagesthemen, he stated that Germany is on a "historically unique experiment, namely to transform a mono-ethnic and monocultural democracy into a multi-ethnic one."
I suppose words like "nationalism" and "mono-ethnic" might appear in an alt-right missive, but IMHO the above doesn't sound anything like an alt-right perspective.
Suppose the initial implementation chose an ill-suited/fast/cheap hash (like MD5). The developer facepalms appropriately, changes course, and updates the implementation to support an expanded list of 4 hashes (1 old/weak/cheap hash and 3 new/strong/expensive hashes) - and you track the hash in the same way as the counter.
Fast-forward a bit. Mallory eavesdrops, learns an example password, and starts a brute-force attack for the master password. He doesn't know which hash to use, so he has to try all of them. On the surface, the choice of hash is just 1 or 2 bits of entropy... but the resource impact on Mallory is driven by the (in)efficiency of the new hash(es), so it has an outsized impact.
In anticipation of upcoming hardware, the developer issues annual updates with another (slower) hashing option (PBKDF2 w/100k iterations => 150k iterations => 200k iterations). This muddies the waters for new brute-force attacks. It's kind of a neat notion that the mere existence of a newer convention could retroactively raise the cost of a brute-force.
Alas, it's not real. Because we're not just concerned that Mallory is an eavesdroper listening to a random password - we're concerned that Mallory is a website-operator who takes user-registrations. In that case, he can simply log the time when the user or password was created -- and thereby rule-out future hashing conventinos.
There's one or two early comments which float the idea that Apple/Catalina's problematic technical change "may force us to drop support for macOS...". That prompted lots of -1's, and then there's a gigantic thread where people are trying to figure out how to adapt, and that's an on-going/non-trivial process.
Did I miss something? Is there actually a policy decision buried mid-thread that's hard to see?
In your comment, I pick up some fear/vulnerability. There's no reassuring voice to say, "macOS Catalina support will be fixed yesterday!" I share that sense of fear/vulnerability, but I think it's a natural trade-off when you sign up for free/open/transparent/community-driven software. For better and worse, you get to watch how the sausage is made in real-time.
From the peanut gallery, it looks like the ball is in ISOC's+Ethos' court to demonstrate their good faith as stewards...
It's interesting to compare ISOC's blog (https://www.internetsociety.org/blog/2019/11/the-internet-so...) and the followups like EFF's blog (https://www.eff.org/deeplinks/2019/11/nonprofit-community-st...) and SaveDotORG (https://savedotorg.org). They touch on a lot of similar themes of community and transparency - which, on paper, makes it sound like there's some meeting-ground.
As an outsider to the discussion, questions would be:
1. What are some specific problems facing the ".org" registration process for which capital/investment would be helpful? (Obviously, there's no perfect answer. But as an outsider, it looks like ".org" registration already works about as well as anywhere else, so one needs some examples to animate the problem.)
2. Would any of these folks care to improve their engagement/trust with each other? Talking more specifics about "Stewardship Council" and "Community Enablement Fund" might help. Or is some reason for bad blood?
3. What kind of track record does this private-equity shop have? Have they worked with other non-profit or socially-oriented endeavors? Maybe some founders/staff/customers can give some positive or negative testimonials?
* If everyone generally views both language frontends as equal and shared responsibilities with valid technical rationales and only some specific/reasoned differences, then it's probably sustainable.
* If the team becomes polarized, or if one subteam wants to substantially reinvent their language ("Let's make it purely functional too! Bring on the monads!"), then yes... they'll feel hamstrung.
It might be interesting for them to consider comparisons with other systems that support multiple language frontends, e.g.
* GCC supports C and C++ (not to mention C++11, C++14, ad nauseum).
* HHVM support(ed) PHP and Hack
* JVM and CLR both support a range of language frontends.
My guess is that GCC is a more favorable analog (it feels normal+realistic to support C99 alongside C++11 and C++14). JVM/CLR seems like an unfavorable analog (they've supported many very different languages... but involve many large teams and diverse technical specs).
HHVM is probably the most pointed analog. It's just... mixed. On one hand, HHVM succeeded in supporting two similar languages for a long time (in spite of significant idiosyncrasies of PHP). On the other hand, HHVM eventually gave up on PHP and went pure-Hack. But (as an outsider) I'm not really sure the reason. It could be that they got boxed-in on a technical issue of language-interop, or it could be they got boxed-in organizationally (being a separate team maintaining a secondary implementation amid a continuous drip-drip of external changes - not a great position).
I interpret the original link above as basically an assertion (crude paraphrase): "The HHVM folks were broadly right about PHP and Hack and technology and all that; but their implementation hasn't succeeded on organizational grounds, and we-here can do those organizational things better."
"SOA" means "microservices for Gen X'ers".
"Microservices" means "SOA for millenials".
I don't know what Baby Boomers called it.
I often wrestle with these dynamics when trying to respond to community proposals, and I think there's a hidden variable: the cost of the time to respond. As a sweeping generality, the short-term cost of writing a straight "yes" (agreeable, lax) or straight "no" (rude, firm) is cheaper than the short-term cost of writing a "yes...but" or "no...but" (politely acknowledging the other side while critically discussing the merits of particulars).
Sometimes, someone can quickly come up with an explanation that is both incisive and pithy. That's awesome, and it's a good skill to develop, but (for mere mortals like me) you can't bank on it all the time. There will be scenarios which require a trade-off (time XOR quality).
I'd wager that those two clusters ("agreeable, lax" and "rude, firm") have normal people who are pressed for time. I don't think people are generally stuck in one of those clusters, but getting out... takes time and attention.
A few clarifications/suggestions:
1. Does this verify the bundle's signature everytime one reads the bundle (ie everytime one uses `curl` + `getLatestBundle()`)? That would feel a little heavy-handed. Maybe it could check the signature everytime one downloads the bundle?
2. Does the default configuration (as written in the docs) really treat `vendor/paragonie/certainty/data` as a writeable data-folder? So downstream developers+admins need to set pretty liberal file permissions? (Or perhaps dig-up a way to use an alternative data directory?) Might be useful for the docs mention this.
I've been sitting on a bit of rhetoric in case that comes up, though I've been blessed not to need it. Regardless, let me share the rhetoric -- just in case someone finds use for it:
"Put bicycle wheels on a cement truck. Put airplane wheels on a skateboard. Put train wheels on a wheelbarrow. The metaphor about reinventing the wheel doesn't go very far -- because the wheel has been reinvented many times, and thank god for that. I like having trains and planes and bicycles and trucks and skateboards and wheelbarrows. The world would be poorer if they all used the same wheel."
I'm on the fence about that one. On the flip-side:
1. If they don't police it, then Facebook as a whole gets a reputation for disinformation. (When I look at Facebook, I personally ignore most shared articles because they're mostly crap, and I don't want to look at them. I only care about the personal goings-on of friends, and the signal-to-noise gets worse over time.)
2. If you take someone who doesn't care about truth, they're not going to introspectively seek-out a metric which might report "You're misinformed and stupid!" BUT If you're self-righteous about the truth, then you might want some objective metrics which say, "Look I don't spread misinformation or live in an echo chamber! But Cheryl does! Look, Cheryl, I'm smarter than you!" That might provide some basis for a viral dynamic.