geofft

I was about to post roughly this comment, but then I remembered reading https://www.gwern.net/Nicotine a while ago:

many asso⁣ci⁣a⁣tions with harm are con⁣founded by past or present to⁣bacco use [...] but when pure nicotine is ex⁣am⁣ined [...] the harms ap⁣peared min⁣i⁣mal: like all stim⁣u⁣lants, nico⁣tine may raise blood pres⁣sure some⁣what, and is ad⁣dic⁣tive to some de⁣gree, but the risks do not ap⁣pear much more strik⁣ingly harm⁣ful than caffeine [...] There is lit⁣tle ev⁣i⁣dence from the NRT [nicotine replacement therapy] lit⁣er⁣a⁣ture that ‘never-smokers’ like my⁣self are all that likely to be⁣come highly ad⁣dicted

(To be clear, I understand why the medical community would be hesitant to endorse this without it rising to the level of a "cover-up," but it seems like it's not as bad an idea as it intuitively sounds. But it's also unclear if the stimulant levels mentioned in that article are anywhere close to the levels relevant for covid.)

I believe NixOS does not (there's a "nixos-rebuild switch" command that sounds vaguely like it requires a reboot, and NixOS does aim for declarative confgs, but it knows how to restart services etc. without rebooting your whole machine - see chapter 3 of the NixOS manual: https://nixos.org/manual/nixos/stable/index.html#sec-changin...)

But the proposal here isn't about running NixOS as your OS, since we're talking about macOS. It's about using Nix as an additional package/environment manager on top of another OS/kernel, in this case macOS, though of course Linux is well-supported too.

Each file in Nix is stored in a path that's computed based on the hash of the relevant source code, and depends on other files (e.g., libraries) via their hash-based paths, too. So you can straightforwardly have multiple execution environments with their own dependencies that don't interfere. It's an alternative solution to the dependency problem: containers leave paths alone, but create a new root filesystem for each container. Nix programs all share one root filesystem, but modify the paths so nothing uses e.g. /usr/bin or /usr/lib.

Precisely because Nix binaries isolate themselves from /usr and carry their own dependencies, the Nix packaging repo "nixpkgs" can be used on any Linux machine, not just NixOS ones. And the Nix folks also build nixpkgs for macOS, so most software in nixpkgs can be installed on a macOS machine too. This gets you a solution to the dependency problem on macOS itself (because there are no Linux-style containers on macOS). If you want, it also gets you a relatively consistent dev environment for applications that will be eventually deployed on Linux: although the kernel is different and of course the binaries are compiled for different kernels, the entire userspace can be the same on macOS and Linux.

The link seems to be down, but this is the speech itself: https://www.marxists.org/archive/debs/works/1918/canton.htm

This is an excellent point from the comments, from one of the signatories:

If you as a public university had no power against racism beyond the nobility of your intentions, your mission statement wouldn't matter a damn anyway. The public university's power against racism is the inherently anti-racist power of genuine knowledge.

And I think it actually refutes some of the more simplistic comments by other signatories about e.g. a desire to keep politics out of science or whether a university's goal should be truth or social justice. Such a phrasing implicitly claims that social justice (however one defines it) is a separable goal from truth. It reminds me a little of the "non-overlapping magisteria" non-solution to conflicting claims from science and religion, that either science determines truth and religion determines, I dunno, vibes, or alternatively that religion has real truth and science is limited to some subset of reality - it solves the problem by refusing to take either one or the other seriously.

The claims of politics and social justice are claims within the domain of truth, just as the claims of science are. Either climate change is happening and merits a response, or it isn't. Either diversity brings conflict or it doesn't. Either the implicit association test is good science or it isn't. Either social Darwinism is good science or it isn't.

The goal of the university should be to seek the truth because it helps humanity. This is why the research university publishes its research and the teaching university opens its doors to the public, after all. There are enough places (as we tech folks know!) where you can pursue the truth about many things for private gain.

Those of us who are on the side of "science" and "truth" must say that when the pursuit of truth has brought us somewhere, we need to do something with that conclusion. It might take us a long while and to false places on the way (as with social Darwinism), but once we've landed on the shores we sought, we need to build something there. And those of us who adhere to the cause of "social justice" as widely understood (and I certainly count myself as one) must believe that the claims it makes about the world we live in are in fact true, and that the pursuit of truth will keep us focused on what actually benefits the people or causes we support, and we need to not cede ground to the idea that our pursuit of truth is somehow a different thing from the ordinary pursuit of truth.

This is not pointlessly-spent energy! It is part of the job of software engineering, in much the same way as fixing compiler errors and debugging is part of the job of software engineering. Your work isn't done just because you have a program that makes sense to you.

Think about technical discussions as a thing that you need to spend extended amounts of time and energy on - probably more than programming, once you get senior enough as an individual contributor.

(So, yes, I think it's a lack of skill, largely because of a lack of recognition that it's a skill worth developing. I can't say whether the "blame" is yours or theirs, but it is highly likely that everyone has a lot of room to get better at it.)

Yeah, but I think the term "self-host" is a little bit conditioned on the HTTP model itself. If we had some sort of Usenet-style distributed infrastructure, you could imagine two ways of publishing content, either running a static site generator locally and using that to push content to the world (and you would be directly negotiating with people about whether you're a spammer), or using some helper online tool a la WordPress to render the content and have them do the push (and they would take responsibility for making sure it gets pushed). In that world, where the end-to-end model of our world's HTTP is uncommon, I think people would still call the first way "self-hosting."

In fact I think we do use the term "self-host" in exactly that way when talking about "self-hosted newsletters." I can (and do!) run a newsletter where I generate the HTML and the MIME document locally, find an SMTP provider of my choice, and instruct it to directly mail recipients. I maintain the mailing list (in a text file in a Git repo) and pass it to my SMTP provider every time I do a mailing, and people contact me directly to sign up. I could also use Substack/Tinyletter/Buttondown/etc., which would have various advantages and disadvantages; the hosting provider would handle most of this for me, including maintaining the list of subscribers. You can also talk about "self-hosted Mailman," etc. In these cases, the self-hoster sees the email addresses of subscribers but not (necessarily) their IP addresses.

I don't think I'm conflating TCP and HTTP. NNTP, UUCP, and SMTP all use TCP, but they're designed in a way that doesn't have this property. In fact it's not even HTTP per se that's a problem. It's mostly about what I called "direct HTTP" - though you posted your comment to me over HTTP, there's no HTTP (nor TCP) connection to me.

(Also other comments claim that the CLOUD Act means that if GH the US entity runs EU servers, that doesn't actually solve the problem - it'd have to be a non-US entity not subject to US jurisdiction. That's why I think the old-school-web model of mirrors is a better example; they're generally run by universities or other entities with no legal relation to the site they're mirroring.)

My personal website is a publicly-accessible static site. Blocking people from it is not meaningful.

It might be meaningful under the model of direct HTTP, where you could be DoSing me or trying to exploit my web server. But if you don't contact me over HTTP, then that problem doesn't arise. There's no meaningful concept of blocking people from a Usenet post I write. Even for indirect HTTP, I don't need to block people from my GitHub Pages or from my HN comments. They're public.

If I add dynamic feature like a comment system or discussion forum to my website, then it becomes meaningful, but also at that point I can implement a way for you to consent to sharing your IP address with me as part of signing up.

Honestly, I think if the GDPR had been around before HTTP, we would have seen HTTP as the unreasonable part in this system.

You don't have to make a direct TCP/IP connection for two people to communicate. We had systems like Usenet and UUCP that replicated data through a series of servers. Even today, when you use email, you talk to your email provider who talks to the recipient's email provider, and they have no need to share your personal IP addresses in the process. Some providers used to include this in Received: headers, but many today do not, rightly seeing it as a privacy concern. And even on HTTP we had (and still have, in some cases) mirrors, where legally-unrelated entities host copies of each others' data. Someone in the EU can visit http://ftp.icm.edu.pl/pub/linux/Documentation/ and never have their connection known to the US-juridiction host of TLDP.

It is both socially sensible for these providers to consent to sharing their own infrastructure IP addresses with other providers (but not share their customers' IP addresses) and legally practical for them to make that consent under the GDPR.

Why should it be the case that when you visit my personal website, which I happen to self-host, I have access to your IP address? I don't want that information. I don't even get that information when using higher-level services like Hacker News or Twitter or GitHub, even though those services operate over HTTP. It's weird that I get it, honestly.

I understand there's a huge planetary investment in HTTP, and so the collision of abstractly-reasonable privacy rights with that reality is an extremely hard engineering and policy problem. But that doesn't make the privacy rights unreasonable.

From GDPR article 2:

2. This Regulation does not apply to the processing of personal data:

(c) by a natural person in the course of a purely personal or household activity

My sense (I am neither a lawyer nor European so this is certainly not European legal advice) is that you cannot use GDPR to compel someone to delete your contact info if they're solely a social acquaintance, but you can use it to compel them to delete it if they're a one-person business of some sort (contractor, Etsy seller, lawyer, etc.).

https://github.com/twosigma/libvirtcpuid works around this.

(But in practice, we mostly rely on the fact that if you are in Google Cloud and specify a minimum CPU version, Google masks CPUID in that VM to exactly match that CPU, even if the underlying hardware is newer. They do this so live-migration of the whole VM works, but it also helps for process migration. I'm not sure where this is specifically documented but see e.g. https://stackoverflow.com/a/44507857 .)

In general "factual information" is not a defense to a whole bunch of things that society generally recognizes as not protected by free speech (the broad concept, not solely the legal right). I cannot claim to be lawyer and provide you with legal advice, even if that legal advice is correct. I cannot redistribute copies of Taylor Swift's latest album, even if (perhaps especially if) it is a faithful copy. I cannot make a public list of all the black people at my company who show up late to work and leave the white people off that list, even if I'm accurate about when they're showing up. If I am a doctor, I cannot publish transcripts of all the conversations I have with patients.

And a few of these aren't even heinous! If I happen to be self-taught in the law and I am particularly good at giving wise and helpful legal advice, but I am not actually admitted to the bar, nobody is directly hurt by my advice, but society has decided the potential for harm in this situation is high enough that I still shouldn't be allowed to do that.

Then how do you decide what is (or should be) a right and what is not? Suppose someone claims a right to gay marriage, or a right to employ only people of their race, or a right to bear arms - how does society (the citizenry, the legislature, and/or the courts) decide whether that is indeed a right?

Absent a holy constitution given to us by the divine, the way we decide what is and isn't a right is we look at its effect. Places that recognize a right to bear arms, for instance, do so because they believe that arming the citizenry protects them against abuses of the government. Places that don't do so because they believe that disarming the citizenry protects them against crimes from other citizens. To the extent that one of these views is correct and the other is not, it is not because they guessed wrong about the nature of the universe - it is because one argument is correct and another is not.

Free speech is not axiomatic. Free speech is a right (and I agree it is a right!) because it has particular positive effects on society, through the benefits of open and unfiltered public discourse.

And the same reasoning helps us define exactly what "free speech" is. We make significant restrictions on free speech - classified information, copyright and trademark law, slander and tortious interference, electioneering laws, unauthorized practice of medicine or law, fraud, etc. - in the expectation that those restrictions serve to benefit society, and in the understanding that if we were to allow these forms of speech, they wouldn't really serve the goals which we see free speech, overall, as helping. If I were to say "I am a licensed doctor and I think you should take two pounds of Vitamin D a day," we understand that the benefit of me adding that statement to the public discourse is nil, and the harm is great, and so we don't recognize that as protected by free speech.

No, but he happened to be wrong for it.

The NSPA's goal was never to actually hold a march. They never did hold a march in Skokie, after that defense. Their goal was to harass Jewish communities through the process of applying for the march, which Goldberger, for all his good intention, assisted them with.

As the article notes, they sent letters to a whole bunch of suburbs asking for a permit to hold a march. They never followed up with the suburbs that ignored them, nor did they march in those suburbs either.

The whole thing was a bad-faith tactic which today we'd call trolling. They weren't fighting for their right to speak freely in Skokie, they were fighting for their right to use the legal process to harass the city of Skokie.

"Moon" is the name of the person who spoke the thing above that is being discussed in this thread.

Advising underage people through a wiki on how to make hormones at home is neither sexual assault nor grooming as the term is conventionally understood. How could it be? You can't get in contact with an anonymous reader of information that has been published to the public. You have no idea what they do with that information. So I am not really understanding what its relevance in this thread is.

(If anything, it's an example of free speech. You might not be a fan of it, which is totally fine, but information that advises people of any age on knowledge that people would prefer to be un-known is obviously at least as deserving of free speech protection - both in the legal sense of protection from government interference and in the moral sense that lovers of a free society should support it having a platform - as anything posted on Kiwifarms.)

Stars don't represent anything real. You don't star a project when you clone it, when you grab a packaged version from a package repository or the home page, when you use it as a transitive dependency, when you scale it out successfully to thousands of machines, when you pay for a support contract, when you contribute a pull request, etc. In turn, when you do star a project, it doesn't require the project to even work, let alone do things well, respond to feedback or contributions, etc.

And startups have long asked for people to star their projects for visibility.

I don't know at what point it hasn't been "gamed." Maybe there are now bots starring repos, but is that meaningfully different than masses of very real humans being excited by hype?

I very much agree with you that the lack of supply is a major problem, but the article is making a case here that what the algorithm is doing is tantamount to price-fixing / collusion. Even in markets where supply is much easier to come by than housing and does not have the entrenched political dysfunction restricting supply - such as RAM chips and canned tuna - price-fixing is a problem.

There's an analogy in the article to airplane seat pricing. The solution there was to tell the airlines they couldn't collude with each other, not to say "The real problem is the lack of flight supply."

Absolutely agree, but how do you do that in practice?

Do you self-host your services on some Linux distro? How many FAANG employees have upload access to that distro or maintain its infrastructure?

(Or maybe you audited everything yourself and you're 100% confident in your audit, somehow, and you've turned off automatic updates. How many FAANG employees are working on fuzzers to automatically find new exploitable security vulnerabilities and scale out those fuzzers on their employers' infrastructure?)

It protects the user's privacy against attackers other than Google.

To be fair, this is an entirely reasonable threat model for a lot of people. For instance, if you're a reporter in an authoritarian country, Google is almost certainly not colluding with the attackers who are literally trying to kill you, and using a Chromebook and Gmail is probably the best option out there. Your threat model is "Don't die," not "Don't be subject to surveillance capitalism."

But it's also something we should collectively be pushing back on. The motivating example for these products is "intelligent ambient systems," i.e., things like Nest hubs and doorbells that capture audio/video all the time. These products probably shouldn't exist at all, and to the extent they do, they should process data locally and discard it as soon as they can.

Not that I disagree with you about whether the average person realizes it, but it's not just a risk because Google has JavaScript trackers on your porn site. Google could just make a deal with the porn site to access their server logs and correlate data that way. The fact that you disclose information to the sites you visit means they may, in turn, disclose information to whomever else.

As a totally non-web example of this, as of 2017, "Google’s third-party partnerships ... capture approximately 70% of credit and debit card transactions in the United States." https://adwords.googleblog.com/2017/05/powering-ads-and-anal...

When you buy something with MasterCard, in person, with a magstripe or even an old-school carbon-copy imprinter, MasterCard can go give that data to Google.

I think the incognito warning could say "Websites you visit, and anyone those sites share data with" to draw attention to this, but I'm not sure if that's quite enough. I'm leaning towards the argument from this article that "incognito" itself is simply a poor name.

For Slack in particular, the deal is that new signins return a token that starts with "xoxc", not a token that starts with "xoxs", and that token requires corresponding cookies in order to be accepted. If you're grabbing a token out of the browser, you will also need to get cookies for slack.com and pass them in the client. Last I checked, you only strictly needed the cookie called "d", but you may as well grab all of them.

A bunch of folks who have been using Slack for a long time have saved their xoxs cookie from a couple of years ago and not invalidated their old sessions, and they'll tell you the various clients still work. For a new user who is getting an xoxc token, your client needs a way to pass cookies along with your token. Many of the terminal clients I've seen don't obviously give you a way to pass the cookie.

My company uses the enterprisiest Slack offering (Enterprise Grid, compliance archiving, proxy restrictions, the works) hooked up to Azure AD as the identity provider and previously to Okta via ADFS, and I have working programmatic auth to Slack (leveraging local Kerberos tickets from Windows AD signon). Give me some details on what your auth setup looks like and I can probably help you with it. (I can try to open-source my internal client if it helps, but it's specific in some ways to our setup so it might be easier to just talk you through it.)

One might hope, but they didn't. How do you tell in Java if stderr is a TTY, and if so, what its width is? How do you do an NSS passwd lookup (as in getpwnam("pjmlp") in C etc.)?

(To be fair, these could be defended, very slightly, on the grounds that Java is a cross-platform language, even though other cross-platform languages have better answers. But then I'd raise the point about Java corrupting RLIMIT_FILES for processes it starts....)

Well, kind of. Docker is a product, with official support for Linux containers on Mac (and Windows containers on Windows!). Docker for Mac comes with a Linux VM as a feature of the product; you don't need to install it yourself inside a VM (though that works, too).

It does sound like adding Rosetta binfmt_misc support would allow Docker for Mac to ship an ARM64 kernel/VM image instead of an amd64 one and benefit from some performance boost, but potentially at the risk of reliability/fidelity. The entire idea of Docker is that the kernel ABI is a (supposedly) stable interface, and even if your userspace changed around it, a Docker container would have its own userspace and wouldn't care. Running a different-architecture kernel and dynamically translating it necessarily means that there will be visible differences in the kernel ABI. Sure, you can translate those differences, but that gets you farther from the promise.

2016, and https://langui.sh/2015/07/24/osx-clang-include-lib-search-pa... (linked from the GitHub thread) seems to explain it better - if I understand right:

- Apple, in 2015, deprecated the version of OpenSSL they used to ship with the OS, which was the really old version 0.9.8. (The alternative is either Apple-specific crypto APIs or bringing your own OpenSSL.) The specific way they did that was to remove the development headers, but keep the runtime libraries around, so existing code would work but new code could not compile.

- For some reason, Apple's compiler searches /usr/local/include before /usr/include but their linker searches /usr/lib before /usr/local/lib.

- Homebrew's "link" operation puts libraries in /usr/local.

Therefore, if you were sufficiently unlucky, you could install a modern, up-to-date, secure OpenSSL from Homebrew in /usr/local via "brew link openssl," and have that used for the compile phase only, and end up actually using the deprecated, insecure OpenSSL in /usr, and you wouldn't notice anything had gone wrong.

"individuals from diverse backgrounds and groups historically underrepresented in the research community" according to https://science.osti.gov/grants/Applicant-and-Awardee-Resour... , so potentially any of those if you can make that argument, yes.

https://science.osti.gov/SW-DEI/DOE-Diversity-Equity-and-Inc... specifically includes "age, ... diversity of thought, technical expertise, and life experiences."

I'm not sure I see how that's connected to the article or the linked DOE policy - can you expand on what gets you that feeling? It seems to be saying the precise opposite of that, in my reading.

I'm not sure this is relevant to the article. It's saying that grant proposals must include plans to promote diversity, not that grant proposals must come from people of any particular race/gender/sexuality.

The words you're saying are correct in isolation, but in context of the thing you're replying to,

1) At issue here is not (just) the portion of the history in the changes under review, but the choice of where that history starts. That's what the commenters above mean by "diff based" and "branch based". If I start a Git branch on HEAD@{yesterday}, and HEAD@{today} renames a function that I'm using, then there is a semantic difference between approving solely my changes and approving my branch with information about its branch point. And in a workflow where only my changes are under review without further history, it's entirely possible for me to submit a set of changes that simply don't sensibly apply to a specific target branch, because the tooling did not reflect that my source branch is different.

Note that all of this true even if "my changes" takes the form of a series of patches, such as a [PATCH m/n] series posted to a mailing list using an LKML-style workflow!

2) All that said, I do not know of any tool that makes it particularly easy to manage both of these pieces of history in a review. All the Git-based review tools I've seen (GitHub, GitLab, Gitea, etc.) make it fairly easy to see where the remainder of history is, view the final state of a modified file with history (e.g., it's easy to see the blame view of a modified file), etc. But they don't default to showing you the commit-by-commit history; they show you the diff between the beginning and end for review. Meanwhile, the [PATCH m/n] workflow (e.g., git format-patch, including Sourcehut's tooling on top) is in fact much closer to the Phabricator one in spirit; while it does permit you to see the commit-by-commit history, it has no idea what the history before the first patch is, and it's difficult to even tell if a patch got merged!

So in a practical sense, there isn't really a tool that lets you work with full history. You have to make some form of compromise. In practice, I think the most common compromise is to constrain yourself to making one commit per code review; if the history is complex enough to really want commit-by-commit review, you're probably best off making multiple reviews anyway.

(You might object - what if the code doesn't build or work right between your first and second commits? But that's already a bad place to be, because ordinary git bisect will have false build failures if it lands between those two points. There is git bisect --first-parent, but first, your project had better be doing --no-ff merges to make this useful, and second, the effect of it is to ignore the detailed history, so if you're going to ask people to do that, why burden them with the detailed history in the first place?)

The other compromise here, weirdly enough, is Phabricator itself. Because Phabricator reviews diffs and not branches, you can submit two independent code reviews for two dependent commits, and Phabricator won't care. If you try to do this with any of the pull-request-style tools, the second code review will include both changes because they know history; Phabricator doesn't, and it will show just the second change if all you sent it is "arc diff HEAD^". And then you can "arc land" those on your own. (But you have to be careful about getting the order right, because, again, Phabricator doesn't know how to do that for you.)

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr... is basically trying to upstream grsec's good ideas in upstream-friendly ways.

(Oddly, grsec itself has expressed opposition to Rust in the kernel, I think on the grounds that their custom GCC plugins can't cross the language boundary. Now that there's work on supporting Rust in GCC itself, I'm not sure if that objection still applies.)

The blog post makes it clear that there's an intended single correct answer to this question, "No, a person who does this specific thing does not exist." It doesn't give room for "Yes, and I think they're right to do so, and here's why" - or even "No, but there's a person who ships their own stuff without review all the time."

I think you could ask it in an open-ended way (though maybe phrased more like "What's the most difficult part of getting code improvements shipped" or "How does your team tend to balance the merits of making big changes" or "What is good and bad about your code review process") and it'd be a fine question.

I asked two questions the last time I interviewed which are wholly unrelated to anything on this list, and they found me a place I was happy enough with that I haven't looked again in 5+ years.

To engineers - how do you feel about management / the practice of management at this company, especially compared to other places you've worked? I was looking for an answer that indicated that management wasn't just where they put engineers who wanted a promotion, and also that the company's processes realized that management was a skill you could be good or bad at just like engineering.

To managers - how is diversity on your team? The answer was universally some variant of "it could be better," but I got a lot of mileage from seeing whether it was a thing they were defensive about and whether they thought they actually could concretely make progress.

All the technical stuff follows from whether the company has reliably competent managers who believe both that they ought to make things better and that they are realistically able to. There are other specific questions you can ask to answer it; I just happened to use these two (and I certainly have no idea if they're the best, but they did work). Every bad technical answer can be fixed by people who want to fix it; at the same time, every good technical answer can go bad without people who care to keep things fixed.