He's written a book on the subject and testified in front of the US Senate. The fact that he acted in a popular TV show more than twenty years ago isn't particularly relevant.
He has the most basic misunderstandings on the very foundations of crypto. He is not trying to understand. He is trying to make headlines to sell his movie.
Because it’s a company with no ethics beyond “might makes right,” owned by a person of dubious sanity who travels around the world to warn anyone who’ll listen about how the Antichrist is bad for their business.
Why would anyone in their right minds do business with a company like that?
To be fair the Antichrist, being a prophesied entity from several millennia ago, is probably not super up to date on twenty-first-century business best practices. They probably still use waterfall.
There is a fantastic book to be written about the Antichrist finally rising to lay waste to the world, only to be astounded by air travel, the internet, etc. A demonic horde of a thousand flaming knights riding through Rome is largely written off as a new burning man thing, etc.
The Antichrist is NOT a prophesied entity. There is no, "the Antichrist". Antichrist isn't even mentioned in the Book of Revelation.
Antichrist is only mentioned in the 1st and 2nd letters of John, where it refers to many antichrists (1 John 2:18), who are identifiable because they deny the Father and the Son (1 John 2:22), and that Jesus Christ has come in the flesh (2 John 1:7). The term simply means, 'against Christ', so anyone who is against Christ could be labelled such, even if they didn't match the description in 1st and 2nd John.
So antichrists existed when these letters of John were written and an innumerable number of them have existed over the past 2,000 years and exist even today. While antichrists would likely continue to exist while the events in Revelation occur, they are not described as having any role in the events described in Revelation.
The reason people link antichrist to the beast or false prophet in Revelation is not due to the writings in the New Testament stating that there is a link. It is more that any being who is against Christ, including those in Revelation, are likely to deny the Father and the Son and deny that Jesus came in the flesh, so, it isn't difficult to find numerous antichrists throughout the past 2,000 years that Christians could identify as being an antichrist and since, for each generation, their time was, to them, the end of time, because the future hadn't happened yet, it was easy for them to think of these antichrists as potentially being the beast or false prophet of the end times described in Revelation.
Over time, this traditional link between antichrist and the beast or false prophet became very strong, in spite of not being stated in scripture and more tradition has grown up around linking antichrist with the beast or false prophet, creating traditions upon traditions, upon traditions, not of which is substantiated by scripture or any other early writings from the Christian community.
It's pretty obvious this comment didn't come from a Canadian. Because if it was, you'd know that Palantir is elbow-deep in the Trump administration, the same one that has repeatedly threatened to annex Canada. That is not a threat to be taken lightly, and the Canadian public agrees, which is why the trump-opposing Liberal party is currently enjoying a parliamentary majority. A more relevant question would be "Why would anyone with Canada's interests in mind even consider Palantir in the first place?"
> Palantir is elbow-deep in the Trump administration, the same one that has repeatedly threatened to annex Canada. That is not a threat to be taken lightly, and the Canadian public agrees
Are they making any preparations for war, at all, that they weren't also doing in 2021?
Did the US make any preparations for war before abducting Maduro from Venezuela or before getting into a war with Iran that cost them freedom of passage in the Strait of Hormuz?
Right up until Russia invaded Ukraine, Russia maintained that, no, that troop buildup wasn't meant as an invasion force, and a good chunk of the world believed Russia because it was a moronic idea to invade Ukraine. Trump is far more moronic and power drunk than Putin, and would perhaps not even organize troops befre invading Canada, all because somebody in the inner circle goaded Trump into it.
You are being rude and condescending to a third party, when I think you meant to be rude and condescending to me.
You comment was ambiguous, using pronouns with multiple referents. I chose the referring that was the most charitable possible interpretation of your ambiguous comment. Your intended point is even more obviously wrong.
I'd say yes. Things like increased military spending (2% of gdp, largest since the end of the cold war), buying more non-US weapon systems (like Saab's GlobalEye, instead of US AWACS), exploring other alliances (with Europe and China), and lessoning dependencies on US companies (like Palantir).
Are you thinking that the Candian public doesn't care about Trump's annexation threats?
Assuming the answer is "no", that is sufficient to demonstrate that the Canadian public sees the threat as one to be taken lightly, and indeed one to which the most appropriate reaction is to ignore it.
Ah yes.. the threat to invade us... should be taken lightly. Right. We should fall in line, let them bully us, do nothing, keep sending our money there.
I'm sure that your dear leader would also take lightly any threat of invasion against the United States.
Imagine an agent dropping a directory with 1m images in it. just figuring out what happened and what got dropped, restoring it one by one, etc. - doable, but ergonomics are a bit lacking.
What is your evidence for this: "... because of structural problems that push them out, be that systemic misogyny in our educational systems ..." , "the toxicity present in the industry that pushes them out ... "?
They presumably didn’t write an entire literature survey in an HN comment because the CS pipeline problem has been written about so much in the past that it’s reasonable to assume basic familiarity:
I mean there's reams of women in tech or academia who talk about this shit. "I left my PhD program because I was constantly belittled and harassed by my advisor and labmates" "I left my position for a different company because I kept getting passed over for promotion after I had kids" "I switched majors from CS in college because most of my classmates were men who made me uncomfortable" "I was bullied in high school by boys because they thought I didn't get accepted into school based on merit". These are all stories I've heard and there are many of them. Go ask some women in your workplace and I'd bet money they've heard stories like this from other women they know or have experienced it themselves. I'm a man and I'm tired of hearing the contrarian denials regarding these problems from my peers in the industry. Maybe every woman I know in the industry experiencing sexism at some point in their education or career is too anecdotal for you I guess.
I'm sure there's studies in labor and education stats to show some quantitative evidence of this stuff but I'm not going to waste my time proving the obvious to you.
I don't think it's our responsibility to educate you about a phenomenon that has been discussed, analyzed, and written about extensively over the past couple decades. If you haven't seen evidence of this, then you've been living under a rock.
UV is super fast and great for environment management, however it's not at all well suited to a containerised environment, unless I'm missing something fundamental (unless you like using an env in your container that is).
uv works great in a container, you can tell it to skip creating a venv and use the system's version of Python (in this case, let's say Python 3.14 from the official Python image on the Docker Hub).
The biggest wins are speed and a dependable lock file. Dependencies get installed ~10x faster than with pip, at least on my machine.
> unless you like using an env in your container that is
A virtual environment, minimally, is a folder hierarchy and a pyvenv.cfg file with a few lines of plain text. (Generally they also contain a few dozen kilobytes of activation scripts that aren't really necessary here.) If you're willing to incur the overhead of using a container image in the first place, plus the ~35 megabyte compiled uv executable, what does a venv matter?
This is still a complete pain to work with. Virtualenv in general is a "worst of worlds" solution. It has a lot of the same problems as just globally pip installing packages, requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups. It's one of the reasons I would recommend against python for much of anything that needs to be "deployed" vs throw away scripts. UV seems to handle all of this much better.
I'm intrigued. I've been using virtualenv in numerous companies for about 8 years, traditionally wrapped in virtualenvwrappers, and now in uv.
UV doesn't change any of that for me - it just wraps virtualenv and pip downloads dependencies (much, much) more quickly - the conversion was immediate and required zero changes.
UV is a pip / virtualenv wrapper. And It's a phenomenal wrapper - absolutely changed everything about how I do development - but under the hood it's still just virtualenv + pip - nothing changed there.
Can you expand on the pain you've experienced?
Regarding "things that need to be deployed" - internally all our repos have standardized on direnv (and in some really advanced environments, nix + direnv, but direnv alone does the trick 90% of the time) - so you just "cd <somedir>", direnv executes your virtualenv and you are good to go. UV takes care of the pip work.
Has eliminated 100% use of virtualenvwrappers and direct-calls to pip. I'd love to hear a use case where that doesn't work for you - we haven't tripped across it recently.
Not quite; it reimplements the pip functionality (in a much smarter way). I'm pretty sure it reimplements the venv functionality, too, although I'm not entirely sure why (there's not a lot of room for improvement).
("venv" is short for "virtual environment", but "virtualenv" is specifically a heavyweight Python package for creating them with much more flexibility than the standard library option. Although the main thing making it "heavyweight" is that it vendors wheels for pip and Setuptools — possibly multiple of each.)
> It has a lot of the same problems as just globally pip installing packages
No, it doesn't. It specifically avoids the problem of environment pollution by letting you just make another environment. And it avoids the problem of interfering with the system by not getting added to sys.path by default, and not being in a place that system packages care about. PEP 668 was specifically created in cooperation between the Python team and Linux distro maintainers so that people would use the venvs instead of "globally pip installing packages".
> requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups.
Genuinely no idea what you're talking about and I've been specifically studying this stuff for years.
> It's one of the reasons I would recommend against python for much of anything that needs to be "deployed" vs throw away scripts. UV seems to handle all of this much better.
This is actually what I'm talking about .. Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application? That model makes it significantly harder to manage multiple applications/utilities on a machine, particularly if they have conflicting package versions etc. Being able to scope the dependencies to a specific code base without having to duplicate the rest of the python environment would be much better than a new virtualenv.
> Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application?
If you haven't before, I strongly encourage you to try creating a virtual environment and inspecting what it actually contains.
"A whole new Python environment" is literally just a folder hierarchy and a pyvenv.cfg file, and some symlinks so that the original runtime executable has an alternate path. (On Windows it uses some stub wrapper executables because symlinks are problematic and .exe files are privileged; see e.g. https://paul-moores-notes.readthedocs.io/en/latest/wrappers.... .) And entirely unnecessary activation scripts for convenience.
If you wanted to be able to put multiple versions of dependencies into an environment, and have individual applications see what they need and avoid conflicts, you'd still need folders to organize stuff and config data to explain which dependencies are for which applications.
And you still wouldn't be able to solve the diamond dependency problem because of fundamental issues in the language design (i.e modules are cached, singleton objects).
When you make a virtual environment you don't do anything remotely like "duplicating the rest of the Python environment". You can optionally configure it to "include" the base environment's packages by having them added to sys.path.
> Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application?
But… that’s what a virtualenv is. That’s the whole reason it exists. It lets you run 100 different programs, each with its own different and possibly conflicting dependencies. And yeah, those dependencies are completely isolated from each other.
I think his point is that you could have just had a situation where multiple versions of the same dependency could be installed globally rather than creating a new isolation each time.
I haven’t really had this issue. UV’s recommendation is to mount the uv.lock and install those manages package versions to the container’s global pip environment. We haven’t had much issue at my work, where we use this to auto-manage python developer’s execution environments at scale.
Nice tricks! I wasn't aware of the cache mounts, so I was building with UV_NO_CACHE=1. Cache mounts should also come handy when installing OS packages in multi-stage builds.
I still couldn't find the "global pip environment" part, unless by that you meant the "active pip environment", pointed by VIRTUAL_ENV during image building.
Mounting uv.lock doesn't actually work if you have intra-repository dependencies. UV can't deal with packages that lack metadata (because it's not mounted): https://github.com/astral-sh/uv/issues/15715
I am extremely skeptical about this sort of thing - I suspect that it's extremely challenging to reliably make assertions about the carbon cost of running a given website given that there are so many unaccountable-for variables; at best the very "edge" of any carbon usage is being guessed at.
Added to that the opportunities for charging the various parties for "certification" are simply too good to pass up it seems.
Yes, but one does not have to reliably make assertions to feed a meme.
People want to be good. The current agenda God says you are good if you sacrifice to the CO2 god. No need to make reliable assertions to feel good about it. Anyone who challenges the act of sacrifice is someone to burn. No challenge means no problems.
Anyone who wants to see both sides of the Co2 discussion is already sceptical at minimum. But it does not make you feel good. Therefore its rare. It feels good to sacrifice to the Co2 god. “Lemme sacrifice you fool.”
This project doesn't seem to care whether I'm sending data to someone else right near us-east-1 or whether I'm sending data to Australia. The energy costs will be very very different.
Not only is it measuring bytes blindly, it's counting rating your energy use as a % of bytes sent, versus total data-center consumption period. As though every byte is equally responsible for the total computing done. Absurdly wrongheaded model.
