Approximately this with NVMe RAID: https://www.ovh.com/us/dedicated-servers/infra/173eg1.xml

tbqh, most the time we saved on compilation was lost to the GHCJS build later on. I was very sad.

It’s probably worth mentioning here that GitLab offers similar functionality with their GitLab CI offering. You can use their infrastructure or install runners (their equivalent of agents) on as many machines as you like. Disclaimer: I haven’t used either yet but attended a meetup event where somebody praised them highly and ditched their Atlassian stack for that single reason.

Their website looks intriguing could you elaborate on their security posture? Is it just an artifact of the on-premise build agent, or is there more to it than that?

I was asking cmhamill.

But, just to be clear: your builds take 8-14 minutes. What takes time for you is the low concurrency settings on travis public/free infrastructure. It’s a shared resource, you only get so many parallel builds. That’s precisely why I referred to their paid offering: travis is a vastly different beast when using the commercial infrastructure.

I also recommend not running the full matrix for every pull request, but just the stuff that frequently catches errors.

How long does it take on your local machine as a point of comparison?

Well… “scan”. They posted a screenshot of their network debugger tab :).

Travis (.org) uses Pusher, but not their tracking scripts. It integrates Google Analytics and as such, communicates with it. ga.js is loaded from google.

The page connects to:

• api.travis-ci.org
• cdn.travis-ci.org (which ends up being fast.ly)
• gravatar.com (loading avatar images)
• statuspage.io (loading some status information as JSON)
• fonts.googleapis.com (loading the used fonts)
• ws.pusherapp.com

All in all, it is considerably less messy then circle-ci’s frontend.

Also, Travis does not have your tokens or code in their web frontend, code is on Github, tokens should be encrypted using the encrypted environment: https://docs.travis-ci.com/user/environment-variables#Defining-encrypted-variables-in-.travis.yml

You’re right. I completely missed that.

I mean, on the one hand, fair enough.

On the other hand, symlinks (in comparison to hardlinks, I should have been more specific) remove the guarantee that the filesystem can be modeled as an acyclic graph. In addition, every program has to handle symlinks: make a decision whether to treat them like the files they point to or like stub files that point to a path name; deal with symlinks to non-existent files; properly follow symlinks to resolve files when needed — it’s not even possible, because of this, to correctly display the current directory in Unix 100% of the time. Bash tries to track where you last were before you ran cd so it acts like you expect, but there’s logic in Bash just for this. The Fish shell, for example, does not do so and always resolves symlinks in the displayed path.

Sockets are truly terrible, despite being an enabling technology for the Internet. You need a special set of APIs just for sockets, instead of following the Unix precedent and exposing a device file with a standard file API. This argument is more controversial, and others have made it better than I, but BSD sockets siloed network programming off from other kinds of I/O programming in a way that was unnecessary and, I think, left a lot of gains on the table compared to a (virtual) filesystem approach.

Yeah, thanks! It seems to be really difficult to engage with this topic in good faith, so I deeply appreciate your responses as well. As far as the debugging analogy goes, words are pretty thin air; borrow as you’d please. :)

To get to the meat of your reply, it’s… we’ll obviously have different heuristics we can match against the situation the author described here. Even in just our conversation, I don’t feel confidently equipped with a reasonable standard of evidence for water cooler discussions. In my experience these kind of informal conversations carry significantly more weight than expected, but that doesn’t seem to be the case for others. Or maybe I don’t have enough information to make that kind of judgement. And as far as things ringing hollow…

Let me back up a bit and lay out a few assumptions I try and operate with that are maybe(?) relevant.

• The author’s experience qualifies as an ongoing catastrophe. For her, for Github, and for the wider technical community regardless of race, creed, gender, sex, ability, age, etc, etc

• Any system with more than two components (be they individuals, management systems, technological systems, machines, et al.) is a complex system

• My piddly meat-brain does not have the computing power to fully model complex systems of any stripe

• Complex systems fail in complex ways

It’s that last part that I want to emphasize– particularly (from the linked pdf):

3. Catastrophe requires multiple failures - single point failures are not enough.

7. Post-accident attribution to a ‘root cause’ is fundamentally wrong.

15. Views of ‘cause’ limit the effectiveness of defenses against future events.

16. Safety is a characteristic of systems and not of their components

(and basically all the other ones, too. It’s a good read, highly recommend it if you have the time ¯\_(ツ)_/¯)

My difficulty with the author’s work, and a lot of similar work, is that it suggests that these catastrophic experiences are the result of a singular category of root cause. Call it sexism, racism, general discrimination, patriarchy, systematic oppression¹, etc, these all pattern match to me as “individuals of this outgroup inherently don’t like people in my ingroup and because of this treat us badly”. Which is a huge problem! It sucks, it’s counterproductive, and I really wish I knew the words to express that without marginalizing it with the inevitable, “and also…”. Because to me, even with the grossest delineation of components possible, we still wind up with interactions between the author’s past self, Github the sociotechnical organization, and the community discussing the author’s work. Considering I am nowhere near intelligent enough to model three things in my head, I’m comfortable describing it as a complex system. And because complex systems fail in complex ways, there’s significantly more unique faults here than Github’s poor behavior as an organization as written.

At the end of the day, I can’t solve discrimination or stereotypes or the million billion of microaggressions the technical community lavishes onto anyone who isn’t easily type-classed as cis-white-hetero-male-college-graduate-under-thirty-enjoys-social-drinking-reads-hacker-news-check-out-this-cool-framework-docker-docker-mesos-startup-docker without fundamentally solving the disease that we call the human condition². I don’t even know where to begin with that, but the author’s work puts a lot of emphasis on the selfsame identity of individuals they interacted with. To be clear: I think it’s important that we accept this as a candid reflection of her subjective experience without significant evidence otherwise.

And then also, there are other factors that contributed to this catatrophe. Many of which are easier to solve and significantly more productive to discuss than the ways in which identity interacts with bias. For example, we could talk about what respectful, workplace feedback between individuals of any identity looks like– the author’s written communication style seems rather blunt to me, and I can understand why the data scientist described early in the post was upset. A Crustacean elsewhere in this thread had feedback on the survey question itself that I found surprising; it would be interesting to read other opinions on that, too. What kind of tradeoffs should we be making between factually correct and emotionally sensitive feedback? When is it possible to get both, when is it not? Another Crustacean brought up that PIPs were not for improvement, despite the goals clearly stated in the name. Is this a widespread practice and/or can we avoid working for companies who have such policies?

Discussions along these lines lead to contributing factors that are easier to solve or work around than the widespread mistreatment of classes of people by classes of other people³. Above all, it frustrates me (and likely many others) that much of what good, actionable work we can source to make things better feels like it immediately gets tossed out the window when we start discussing identity in these contexts.

¹ - That *-isms are an emergent property of the complex web of social systems we engage with is the most interesting view to me in that it at least acknowledges the wider context in which we all interact. Unfortunately, it also seems like it’s easy to short-circuit on that description and throw up your arms in learned helplessness at the idea, too. Don’t know of any good solutions though, only tradeoffs.

² - Poe’s law warning.

³ - This is a defining and unfortunate trait of humanity as a whole. My fear is that it’s not entirely maladaptive, either.

I’ve also heard, but not investigated - so consider these unsubstantiated - claims that many of the Itanium specifIc features that are unlike x86 were made to keep parity with and this ease transition from PA-RISC chips. This seems likely as PA was very popular with large enterprise, and supported HP-UX, etc.

The other take on that history I’ve heard is that Itanium was used as a testing ground for weird features, prior to potentially bringing them into x86, without risking getting the huge customer base hooked by backwards compatibility on something that might accidentally turn out later to not be useful enough to justify the expense in transistors, mm², design effort, power or whatever. I have no clue about whether that’s true.

I currently know 3 employees and have know Dr. Gersch personally for a couple years. Let me shoot some emails and see if I can get a response.

EDIT: I also noticed that they have some x86 devices in the Datasheet section: https://secure64.com/resource_library/data-sheets/

Oh wow, I’m way wrong, thanks!

In Python you can do some odd things like:

import sys


def abomination():
    # get the stack frame of the function which called me
    fr = sys._getframe(1)
    # create a global variable visible to caller
    fr.f_globals['z'] = "z wasn't defined, but it is now."
    # spy on caller's local variable
    print ("Supposedly hidden value of x: %s" % (fr.f_locals['x'],))
    # spy on caller's name
    return "I was called by a function called %r" % (fr.f_code.co_name,)


def victim():
    x = "Some hidden secret, never to be revealed."
    y = abomination()
    print ("y = %s" % (y,))
    print ("z = %s" % (z,))  # note the lack of 'z' in scope!


if __name__ == '__main__':
    victim()

Which will output:

Supposedly hidden value of x: Some hidden secret, never to be revealed.
y = I was called by a function called 'victim'
z =  z wasn't defined, but it is now.

Lots of code in real-life libraries that people depend upon in production (transitively) depends on code that does all of these things, and more. (Very little code does this directly, but projects have dependencies which have dependencies which have…).

Making odd things like these work (and programs that sometimes do them run fast) requires either a somewhat naïve execution strategy that materialises a lot of these objects all the time and leaves a lot of performance on the table (e.g. touching global variables is noticeably slower than local variables in CPython), or a really complicated execution strategy that materialises them only when precisely necessary.