The trouble with FreeBSD
lwn.net
lwn.net
Nothing in this article makes me want to change my mind. On the contrary seeing this article on a 'Linux' website generally lowers my opinion of both the 'Linux Community' and LWN. If LWN had fewer articles like this, and more articles actually communicating useful information to me, I might actually read it more.
I used to use Debian almost exclusively, but ever since this systemd BS I've gone FreeBSD as much as possible. This isn't about personalities, it's about me not caring about the problems that systemd is trying to solve.
The comments… yeah, there are people whining about "Marxists" "ruining projects" or something. Welp.
Another FreeBSD developer here. I pay for an LWN subscription to help keep on top of what's happening in Linux and to support the high-quality coverage.
None of it was meant to discourage you from using FreeBSD. I had nothing to do with the LWN summary but the whole point of the piece was to look at what FreeBSD could be doing better from a community standpoint.
A case in point: Baptiste Daroussin wrote up documentation for EVFILT_FS in kevent. FreeBSD actually has had this for a decade, not that one would know it from the doco (because contrary to the norm the code was patched without amending the doco to match). This was in 2010. The doco patch was never actually added.
* https://lists.freebsd.org/pipermail/freebsd-current/2010-Sep...
Don't get me wrong, I love FreeBSD, but some of the effort and friction is unnecessary.
There's nothing about EVFILT_FS in the 11.0 kqueue() manual.
As a occasional reader of LWN, I like the fact that they cover other topics apart from LWN. It's always good to learn/see how other communities operate.
I can understand it, I can edit it, I can fix it. IMO systemd and the like are too much like hand-waving voodoo.
It's like trying to interact with an adolescent AI: Computer run service abc123
I don't feel like it.
With config files: Computer run service abc123
Error on line #5 of abc123.conf
Bingo!
I wish they had just named systemd as HAL. It would have let me avoid months of hair-pulling.
There's already a HAL https://en.wikipedia.org/wiki/HAL_(software)
It's deprecated since its functionality was merged into udev. Then udev was merged into systemd...
=) It's jokes all the way down.
Thankfully for those of us unwilling or unable to make the jump to FreeBSD there is still Slackware.
My only gripe is we're still waiting for KDE Plasma 5...
Well, even in the worst case where FreeBSD community is trash, they have one of the best kernel implementations and one of the best open source OS documentation.
Let's remember that FreeBSD is an entire OS, not just a kernel. If you want to compare it to the linux world you have to imagine the kernel + the GNU userland + the distro specific utilities and package management of something like debian or red hat.
It's not really surprising that the codebase ends up being huge and that you can't just change the architecture and tooling around it to use the trending software stack of the day.
On the other hand the fact that FreeBSD is so comprehensive is the killer feature for me when compared to something like Linux. It's a full OS, with everything (usually) playing nice with each other, a single documentation for the entire base system etc...
I also find that the kernel code is generally a little nicer than linux's, although linux is more featureful overall.
Yes, FreeBSD is slower moving than Linux and generally more conservative. That's not a bug, that's a feature.
The whole idea of this talk was about the community side of the project. I make exactly the points you're making regarding code size but that just speaks to the difficulty of managing a community looking after a codebase of that size.
I'm also not criticizing the pace of FreeBSD development so much as I'm criticizing the pace of its leadership (of which I'm a member, don't forget) to deal with issues that would make FreeBSD more fun to work on.
There are three main points in this article: the issue of version control, the "Dragonfly BSD incident", and the GamerGate garbage fire.
Regarding the first issue, while it was sad to see a good dev like Matthew Dillon leave the project, what do you think should have been done better by the leaders of the project? Clearly there was an incompatibility here, maybe having Dillon work on his own project (and then sometimes have a back and forth between Dragonfly and FreeBSD) was the right solution? Would Linux for instance have dealt with the issue better? I recall many personality clashes amongst the Linux "elite", some not so long ago.
The migration away from CVS sure did take a long time, but as you mention yourself the technical challenge was pretty high. Lest we forget, Linus ended up writing his own version control system because the existing solution were not deemed satisfying. And FreeBSD is significantly bigger than linux's codebase. Regarding the test suite, testing operating systems is notoriously difficult (you can't easily abstract away from the hardware to run well contained unit tests). I don't recall Linux having an extensive test suite either.
The GamerGate thing I won't touch with a hundred kilometer pole. How an operating system project got dragged into that I still can't fathom.
So in the end, I don't think those issues are that big of a deal on their own. IMHO the main "trouble" with FreeBSD is simply that its market share is tiny compared to Linux. I'm a big fan of FreeBSD but my IRL job is linux kernel dev, not FreeBSD kernel dev. More and more first party vendors support linux, not any of the *BSDs. "Netcraft confirms it - BSD is dying". There's a momentum problem and I'm not sure switching to github or adding a test suite are going to solve it.
FreeBSD is betamax, linux is VHS. FreeBSD is mercurial, linux is git.
That being said, I don't have a solution either.
The migration to Subversion was given as a case where core could've made a decision and given direction but chose not to. Whether they're right or not is a whole separate set of arguments.
I think everyone would be happier if Gamergate had never been a thing.
The trouble with FreeBSD, as stated, is that like a whole lot of other community projects it's largely volunteer and its leadership is 100% volunteer. If we had more mindshare we might have more volunteers but then we'd need leadership to be more active.
If you think it has a small market share, you're looking at the wrong market.
1. Linux. "Over 13,500 developers", https://www.linuxfoundation.org/announcements/linux-foundati...
2. FreeBSD. I make this a little over 2,300 names: https://www.freebsd.org/doc/en/articles/contributors/article...
So I suggest it is a only a 6x difference, or at least in that vicinity.
I imagine that the column inches go overwhelmingly to Linux, but tech journalists are moths to a flame.
https://svnweb.freebsd.org/base/head/ -- 128 individual developers have committed to FreeBSD head in the last ~ten week window. (svn log http://svn.freebsd.org/base/head |egrep '^r[0-9]{6,6} \| ' | grep -B999999999 2016-11-25 | cut -d" " -f3 commits.log |sort | uniq | wc -l)
So Linux has more like 13x individual developer count in recent times. You can round that down to 10x if you like, but 6x doesn't tell the recent story.
Note that this is comparing the Linux kernel to FreeBSD base, which is like kernel + glibc + coreutils + binutils + other stuff.
I suspect a lot of open-source projects have similar issues.
The original proposal was this: https://wiki.php.net/rfc/adopt-code-of-conduct?rev=145194062...
Anyone have more info about this? Especially the "Perl script"?
It was, hands down, the single most clever and
effective use of a technical tool to increase
polarization and hostility online I have ever
seen.
This seems like a nonsensical assessment at best. Use of the script was voluntary, and GG was an organized mass-harassment campaign premised on polarizing and hateful nonsense. The whole social phenomenon consisted of a distributed wave of hostility.I wound up adapting the script myself at one point to mass-block followers of a YouTube/Instagram celebrity who shares my first name and triggers a neverending stream of namespace collisions. It's a reasonable brute-force hack in an environment that lacks real features for dealing with a large population of griefers.
< In comparison, Python started on CVS, moved to Subversion
< in 2004, then to Mercurial in 2009, and is now moving
< over to GitHub.
I used Python around 2004 and 2005, and never went back to it for my personal projects.I would rather prefer 'moving slow and preserving things'. Any body here remembered how things went when Linux moved from OSS to ALSA? And now there's this systemd.
Python is usually considered the one language that moves slowly, exactly to preserve compatibility. Can you explain why you "never went back to it"?
If they achieved another gain by migrating to HG, why shouldn't they have ?
If they achieved further gains by migrating to git, why shouldn't they have ?
How does the choice of VCS make a difference for your personal projects using Python?
Speaking as a python user, I guess your way of development is then to still code everything in C and sh? No thanks. I'm willing to update my code to newer, less insane, versions of a language - if the benefits outweigh the pain of course.
In the face of all the great things happening in Python during 2004 and 2005, why would you abandon it due to a change in their VCS, especially when SVN is so similar to CVS?
I don't have Python2 code to maintain, but if I had I would seriously consider updating it. Because I think the changes are reasonable for the most part.
Dou you write your C code in GCC C? Intel C? Microsoft C? C89? C99? C11? What libraries and what versions do you use?
As with all constructive criticism, you absorb what you feel will help you reach your goals, and reject what doesn't. It is always a good thing to have those insights and options though, I think.
Since Dillon was discussed in the article and given he split from FreeBSD 11 years ago ... which OS now is in better shape overall (technically)?
DragonFlyBSD or FreeBSD?
I also don't really consider "age" in and of itself to be a real factor at all here anyway. It implies (probably not intentionally, but the implication is there nonetheless) that things should be rewritten from scratch all the time in order to avoid "old" things, which would be silly.
Important free Software and Open Source projects are almost always community efforts. Ignoring bad behaviour which harms the community may have technical benefits in the short term (assuming the people behaving badly are skilled hackers), but in the long term their contributions may not be worth the harm they do by excluding and driving away other potential contributors.
A hostile work environment is rightly considered a problem that needs to be fixed in a professional context. For those of us doing FOSS as a hobby, it's even more important - few will spend time on a hobby where they are treated badly.
I also like the meritocracy concept. But I feel rather strongly that it is important that the "metrics" are not just technical, but social as well.
At what point do you deem social behavior unacceptable? It's a fine line to draw and one that might be difficult for many communities to do correctly.
What's considered "harassment" for example? Does 1 off comment count or does it need to be systemic? What if it was a heat of the moment situation and an apology was made afterwards? Does expressing an opinion less than the generally accepted one about a rape case for example count as misogyny? What about mental health comments not in line with generally accepted opinions, but which might still hold some validity? How about defending political opinions based on your religion?
There are too many questions that I know many people would respond very differently to.
I think if we take a step back and don't try to invent all the wheels ourselves, we'll find that almost all of these questions have established answers from the world of business and human resources.
We do have to get past the first step though, which is agreeing that these are problems we care to solve. The wider community is still divided on that, as illustrated by this thread and the comments on the OP.
Yet conspicuously absent in your post is a link to where those answers are. I suspect that because as soon as you link to one you've actually drawn a line in the ground. Instead of codes of conduct which sort of fuzzily describe that one exists "out there."
And once you start talking about where lines are really drawn, it becomes easy see how little agreement there actually is. Even among people that are more-or-less on the same page regarding which problems "we" care to solve.
But I do know people that do that sort of work, and I also know that when I went looking for a code of conduct for my own project, I found lots of pre-existing material to work with.
You guys are making this out to be a lot harder and more complicated than it actually is.
Often times this amounts to "don't be racist" and similar proclamations - these don't offer guidance as to what's deemed racist. Some people would say opposing affirmative action is racist - is that the standard the project goes by? Based just on those codes of conduct, who knows?
Heck, some people would say the president of the united states is racist, but over 47% of the voters wanted him. If you think that full 47% of the population is terrible and racist, on sheer population grounds you probably just rejected a lot of good people.
This is why I find codes to conduct to be extremely low value, they provide nothing beyond say "don't be an asshole" and a fear of reprisal for political reasons.
It's entirely possible to be racist to some degree while still being a good person overall. That doesn't mean racism is okay, or that it should be acceptable. But suggesting that opposing racism equals branding almost half of the American voters as terrible people is a strawman.
My point is, if you use a code of conduct that simply includes dumbed down provisions with no detail, you have no way of knowing what the views of the project leaders are - you might have risk that kind of treatment because you said something positive about Trump on Twitter.
I suppose you can argue this is a strawman on the grounds that it doesn't seem to be happening so far with projects which have implemented a code of conduct - but I'm worried it might have a chilling effect on political commentary in FOSS communities, causing more people to comment anonymously and disassociate their political views from their real information. This kind of chilling effect is hard to measure in many other cases already.
This is key. A large part of contemporary American (and, as I understand it, European) politics involves struggles over the size of the Overton window. This means that even people with little interest in the project will have a strong incentive to use the project's code of conduct as a tool for defining the boundaries of acceptable discourse in the communities that overlap with the project.
So, much like with debates over communism, I think we end up with a major disconnect between people who focus on love for the ideal and people who focus on hate for the implementations they've seen.
Seems like it should at least be an amicable goal.
There's also the fact that the participation of women and minorities in OSS is smaller than their participation in the technology industry as a whole. Granted, not every OSS project touts itself as a meritocracy, but it's probably the area where the concept is championed most vociferously.
I think that can mostly be diversity hiring. A company can hire women/minorities to increase diversity. A FOSS project can't accept code on the premise of diversity. I think the narrow scope of most FOSS projects (or the individual components that contributors wind up specializing in) also makes most of the benefits of diversity less relevant. Diverse teams do better on diverse tasks.
(I don't think diversity hiring is a bad practice as long as the people hired are qualified for the job)
No good way to know by speculating.
Unfortunately, the technology world has not had the same experience. When technology becomes more meritocratic (e.g., audition via github/coding tests/open source contributions rather than interviews), we get more Asians, fewer non-Asian minorities and fewer women.
Because meritocracy in technology fails to achieve the goal of "gotta catch them all", it must be opposed.
Blind coding tests would come the closest to the equivalent of a blind audition, but coding tests as hiring criteria have their own problems in general.
A non-peer-reviewed paper shows that women get more requests accepted than men. In one subgroup, unblinding gender gives women a bigger advantage; in another subgroup, unblinding gender gives men a bigger advantage. When gender is unblinded, both men and women do worse; it’s unclear if there are statistically significant differences in this regard. Only one of the study’s subgroups showed lower acceptance for women than men, and the size of the difference was 63% vs. 64%, which may or may not be statistically significant. This may or may not be related to the fact, demonstrated in the study, that women propose bigger and less-immediately-useful changes on average; no attempt was made to control for this. This tiny amount of discrimination against women seems to be mostly from other women, not from men.
http://slatestarcodex.com/2016/02/12/before-you-get-too-exci...
Most of the results of that study suggest open source is friendlier to women than to men. But the study isn't really that high quality, and the results aren't that strong, so I wouldn't draw a very strong conclusion from this.
When that study came out I asked the authors for their data set and analysis scripts. They categorically refused. Also not a strong indication of quality.
I think there are two factors at play:
* Generation and exchange of ideas and approaches is the most important part of software engineering on a team. Diversity of gender and background probably gives this factor a bump.
* People are biased, both consciously and unconsciously, against certain minorities. This means lower evaluation scores and weaker resumes (since the world shares the bias).
But whatever the reasons, Google and Facebook are pretty good at this whole data analysis thing, so I wouldn't discount their experiences.
Here's a hypothetical. Imagine google made an error and it turns out that their analysis has a sign error. Blacks/women actually underperform. Would you favor flipping the sign on whatever action you propose? If not, why not?
I ask this because in a number of other contexts, the sign is actually flipped. Blacks drastically underperform what would be predicted from college entrance scores, they are less likely to pay back loans (holding other things constant), and more likely to commit crime.
Generation and exchange of ideas and approaches is the most important part of software engineering on a team. Diversity of gender and background probably gives this factor a bump.
I'm the only person of my race/nationality at my current company, but I've never really observed this effect. Can you tell me how to tap into these powers?
I admit, I do sometimes provide ideas that no one else has, mainly in the area of bayesian stats, low level performance hacking and probabilistic data structures. Is that what you mean? Are these the secret powers unavailable if you don't have someone of my race?
No, because of the above point about diversity. It has an effect on more than just the individual. I don't know if Google has made any claims about the following, but it's been noted that, for example, diverse management teams tend to outperform nondiverse ones.
> I admit, I do sometimes provide ideas that no one else has, mainly in the area of bayesian stats, low level performance hacking and probabilistic data structures. Is that what you mean? Are these the secret powers unavailable if you don't have someone of my race?
You are being intentionally facetious. I know you're a smart person, that you're very probably aware of what diversity arguments are about, and this reply is thoughtless in a disrespectful way. I'm only spelling it out to avoid downvoters: the idea is that different approaches and attitudes are informed by race, culture, background and gender in ways that are difficult to measure in the interview process.
For the record, I would consider a white hillbilly or southerner as 'diverse' in most computer workplaces.
That point does not apply to lending or crime prediction. There is no collective decisionmaking on the part of parolees or borrowers.
Do you have any objection to using your same solutions, but with the opposite direction, in this areas? E.g., if google should try and hire more blacks (due to them overperforming), should BofA try to lend less money to them (because they underperform)?
Similarly, since we know diversity harms group cohesion, should companies which value group cohesion avoid it?
You are being intentionally facetious. I know you're a smart person, that you're very probably aware of what diversity arguments are about, and this reply is thoughtless in a disrespectful way. I'm only spelling it out to avoid downvoters: the idea is that different approaches and attitudes are informed by race, culture, background and gender in ways that are difficult to measure in the interview process.
I don't know why you find this disrespectful. Could you clarify?
I'm simply asking, concretely, how "race, culture, background and gender" inform different approaches and attitudes to detecting systematic failures in a sensor network? Or similarly, how does this inform different approaches to querying a dataset consisting of a normalized SQL schema together with a collection of very large structured files?
I'm being facetious because I consider this idea to be patently ridiculous. In most of my jobs I've been the only person of my race present, and it's literally never affected any professional task.
That's also why I'm asking for specifics, rather than vague allusions to some study you kind of remember reading.
I do of course know what the real argument is about. Diversity is a sacred value and all the arguments you've brought up are actually just post-hoc justifications for a behavior you virtuous. I'm just arguing that there is little more than that.
It's popular among computer nerds to dismiss other peoples' ideas. They might do something like attack someone's ideas with intentional misunderstanding, lazy thinking, and facetious reasoning. In short, they do not show the bare minimum of consideration for others' ideas, instead looking first for avenues of attack. Having ignored and attacked the other person, they then claim no disrespect was meant. They might say something like "I don't know why you find this disrespectful. Could you clarify?"
It does not occur to them that being able to attack peoples' ideas in this pompous way is actually a position of privilege. Anyone can do it, but people born a step ahead are more likely to not reflect on their position, or even feel entitled to it.
In my experience, women and people from disadvantaged backgrounds--people who were not praised to the moon for writing "Hello World" in eighth grade--are less likely to behave in this way.
This is self-evidently an enormous advantage on engineering teams.
Usual disclaimer: personal experience, your mileage may vary, this is just one example, privileged backgrounds have advantages too, yada yada yada.
On the contrary, the only person ignoring the other's points and making anything close to an attack is you. You've accused me of being disrespectful, called me lazy and accused me of intentional misunderstanding, while simultaneously NOT addressing any of my core arguments.
Quite entertaining, I must admit.
[1] Specifically, I think even if that argument could be proven false, it would not change your conclusion at all. So bringing it up is merely a distraction. See also: http://lesswrong.com/lw/wj/is_that_your_true_rejection/
If you're interested in Google's data, they make an excellent search engine that you can use to find that kind of stuff. I encourage you to do your own research, in part because I think I've done enough work leading you to the proverbial water.
In general I would agree that woman and blacks do have different experiences in life to most people in Silicon Valley. I fear that the push to improve 'diversity' will actually reduce true diversity. Companies in Silicon Valley usually hires people from the same universities who all have similar experiences. This crowds out the hiring from less famous universities, overseas students and other parties. There are no vocal activists to push that kind of diversity.
I still think we as a community should be open to all to participate. But we shouldn't have to lose what makes our community great in the process.
I don't know about you guys, but I don't care about the race, religion or sex of the other parties I work with. I only care about the quality of their work and that they aren't arseholes to be around.
> When technology becomes more meritocratic (e.g., audition via github/coding tests/open source contributions rather than interviews), we get more Asians, fewer non-Asian minorities and fewer women. Because meritocracy in technology fails to achieve the goal of "gotta catch them all", it must be opposed.
This seems to suggest that you don't want meritocracy. Was that sarcasm?
I don't think meritocracy (at least in tech) helps promote "diversity" (where diversity is a code word for "women and non-Asian minorities"). (The latter claim is broadly supported, albeit in convoluted language, by the social justice types who oppose meritocracy.)
I'm perfectly fine with this; "gotta catch em all" is not one of my goals. It is, however, the goal of many social justice types, so they necessarily oppose meritocracy.
Codes of conduct boil down to requiring members of the community to treat each other with basic decency, and defining a process for showing them the door when they fail to do so.
This is not a controversial concept in the real world. You'll be fired from your job if you treat your co-workers badly, you'll be ejected from the pub if you harass the other clients.
Sure, but there'll be a process. You'll have a right to a hearing, the right to your own union representative, and a right to appeal to a tribunal or similar. And the HR people themselves will have oversight. HR don't get handed a license to just fire anyone they want to.
> You'll be ejected from the pub if you harass the other clients
Pubs are not an institution to emulate. A project like FreeBSD should hold itself to a higher standard.
indeed.
and if the HR folks fire so many people that the damage the organization's ability to compete, they'll be out of work sooner or later. no such feedback mechanism is in place for conduct enforcement committees in open projects.
If only it were that easy.
I've seen codes of conduct for technical projects where they said things like "MUST be inclusive of trans, gay, etc.", along with political / ideological statements. And the kicker was a phrase saying "these ideologies are not open for discussion".
Why a software project needs an ideological statement, I have no idea. But it hits all of my red flags that the purpose of the code of conduct is not to treat each other with basic decency, but instead to push a particular ideology.
> you'll be ejected from the pub if you harass the other clients.
What about simple questions?
Q: Hi, I noticed you're a Democrat / Republican / whatever. I think I may disagree with your opinion.
A: THE SIGN SAYS NO QUESTIONING IDEOLOGICAL PURITY. GET OUT.
Uh... no. That way lies totalitarianism.
And yes, treating other people with basic decency is actually a tricky thing that needs to be spelled out for some people. A lot of people actually - you gave some great examples, whether you meant to or not.
Any selection of relative values is ideological; and every project is, inherently, based on an agreement to pursue some set of values. And the choice for those values to not include social inclusiveness is as much an ideological choice as the decision that the values should include inclusiveness (or that they should include exclusiveness, which is a third possible ideological choice.)
e.g.
> ... an ideological choice as the decision that the values should include inclusiveness
I explained why this is not just unnecessary, but also why it's wrong on a much more fundamental level.
When I get patches from people, I don't care what's under their clothes. I don't care what their political opinions are. I don't care what religion (or not) they belong to. I evaluate the patch based on it's engineering merits. I give them a review of the engineering work that they did, without reference to any of the above mentioned issues.
It's absolutely inclusive, in a way that perhaps you don't understand. It doesn't pervert the project by demanding that members adhere to a particular ideology.
I find naive attempts at "inclusiveness" to be repugnant. They are a back-door way of leveraging such "niceties" into taking over the group, and establishing an ideology-driven totalitarian dictatorship with Orwellian overtones.
And no, I'm not exaggerating here. Look at any number of groups which started out as goal oriented, and devolved into fights over ideological correctness. Very soon, the arguments over ideology overwhelm the group, and everyone who gets things done... leaves. What's left is the ideology-driven politicians, who then find out that they're in their an echo chamber. They turn on each other, and the group dies a flaming death.
See Atheism+ for a good example of this in recent years.
There is also the opposite, people who are busy communicating, who generate lots of noise and never do anything.
So yes, merit should be defined as getting useful things done with rough consensus and not as brilliant code that then split the community.
Being socially dysfunctional (as opposed to being malicious, which is a different problem) is often linked to an inability to pick up the social cues and clues that most people take for granted. A document which clearly explains and gives examples of unwelcome behaviour should help in these cases - assuming people actually read it!
Example: Wikipedia. The talk pages on that site, especially on politically charged topics, are detailed examples in how one can behave in a destructive fashion and drive off talent without ever dipping into base namecalling.
The question is "who judges" ?
A meritocracy is generally an engineering meritocracy. People who get things done, get more merit. And it's easy to judge who gets things done. No one cares if the contributor is black, blind, gay, trans, politically left or right. They're doing engineering. All other topics are off topic for the engineering project.
In contrast, "inclusiveness" is a vague concept. It's hard to judge "inclusiveness". So when the judging happens, it tends to be subjective, and driven by politics, ideology, or emotion.
This subject came up on the FreeRADIUS list last year. I made similar points here:
http://lists.freeradius.org/pipermail/freeradius-users/2016-...
I am actively opposed to most "codes of conduct", for reasons stated in the link.
From the main web site http://freeradius.org/list/
---
All mailing lists have a strict code of conduct:
The only permitted topic on the list is technical discussion related to FreeRADIUS.
Off topic messages will result in a warning. Continued misbehavior will result in the person being unsubscribed from the list, and permanently banned.
This code of conduct was defined after many years of experience running the list. It is simple to explain, and simple to enforce. Unlike other codes of conduct, it does not require people to be "inclusive" or "accepting" of certain topics. It requires people to be blind to non-technical topics, as those subjects are explicitly off-topic.
---
Such a "code of conduct" is easy to explain, easy to enforce, and easy to judge. No politics, ideology, or emotion get in the way of people doing engineering.
> The amount of discrimination is uniform across occupations and industries. Federal contractors and employers who list Equal Opportunity Employer' in their ad discriminate as much as other employers. We find little evidence that our results are driven by employers inferring something other than race, such as social class, from the names. These results suggest that racial discrimination is still a prominent feature of the labor market.
And isn't the only way to live in that goal of meritocracy to actually try to?
Consider Rawl's original position argument: https://en.wikipedia.org/wiki/Original_position -- sure, if you perceive yourself to be (or actually are) of high merit, a meritocracy sounds great. But defining a just society requires one to consider the possibility that one could be in the position of being incapable of meeting the demands that a meritocracy requires of its participants in order to flourish.