A PSU cable tester is valuable for this. They're much cheaper than a replacement PSU, and you can plug in cables wherever they fit on a PSU, and test whether the output is correct for the CPU/PCI/motherboard/SATA connector you want to plug it into. The PSU and cable might be a black box, but the output is always testable.
The motherboard cables do all kinds of different scary crossovers so never separate them, though you'll probably never have an "extra" motherboard cable in the first place.
None of the other cables bridge pins on the PSU side, they "just" scramble the pins they're attached to at the other end.
Sure, that's plausible... a facebook exec so dumb that they're using their personal ISP connection to run a VPN for others, and even dumber that they don't notice or don't care about a massive amount of torrent traffic through that VPN.
It's not really a VPN for piracy purposes unless it's a commercial, no-log VPN. Since when a VPN is used to move the point at which traffic enters the internet, the owner of the VPN exit will be held to account.
They can try to claim they were running a "private" VPN and gave random people (from reddit and discord) internet access through it. They can try to claim they don't keep logs. Meanwhile, for a facebook VP with suspected activity tied to facebook corporate, the rightsholder will subpoena every digital device in the person's home, depose all their family and close friends, subpoena their facebook email...
Julia might just be the closest thing at the moment to Matlab without being a Matlab clone. I think you're overestimating the learning curve. It has a REPL, with tab completion and ?<funcname> for high-quality help (without resorting to a browser or llm).
...on a 4x 3090 rig. The game ran 299 moves, giving katago 100 minutes if it exhausted time on each move (which must be the optimal strategy under that time control). Shin used about 205 minutes, over twice as much time and of course had leeway to spend more time on difficult moves.
Is 20 seconds on that hardware really overkill and well into the diminishing-returns curve, as a top-level comment suggested, or is it plausible katago could have played better if given 40 seconds per move?
As another question, does it not operate similarly to the top chess engines? The way the neural network systems work is by using the probabilistic matching paired with a Monte Carlo simulation. So you can get to extreme depth very rapidly. Obviously the breadth is going to be limited, but if the neural network side is well tuned (so high probability hits are indeed generally the most challenging moves), then that's not such a problem.
And you can run a huuuuuuuge number of sims in 16 seconds.
I believe the basic idea is similar, but there's an enormous difference in the space of possible moves between chess and Go. Go has a larger board and moves are less restricted. There was a major breakthrough in Go playing programs a decade or two ago when good Monte Carlo methods were developed for it. But still I think the ability to simulate many moves is less powerful in Go.
I've not looked at the specific game in question, but in general, doubling the thinking time leads to a very notable strength improvement regardless of the base level of play. The increase becomes slightly smaller at higher levels but does not really diminish, and it currently looks like the ceiling is still a bit away.
If it is "only" 4x3090 at 16s, you will definitely get a drastic playing strength boost from doubling the thinking time. This is still clearly within the interval of a linear relationship between thinking time and playing strength, i.e. elo ~ log time. The relationship, to my knowledge, becomes less clear only starting at about 10-20x the number of playouts.
Considering the original AlphaGo ran on a full Google TPU rack, and here KataGo seems to run on a $10k computer, and won with 2 stones handicap, this is showing just how much advance there was in computer go
If you want to argue that there's excessive enthusiasm about anubis, which is neither a permanent solution nor a solution against all bots run for all purposes (some bot authors are cleverer than others, and you don't have to block everything, just enough to reduce resource use to tolerable levels)... fine.
However, the refrain from naysayers isn't that there's too much enthusiasm. It's that anubis doesn't make sense as a theoretical barrier against bots. Who cares as long as it works empirically, even briefly? Are you suggesting people let their sites continue to be degraded or unusable until they find a better solution, even though PoW challenges can improve the situation today?
Not everyone has the luxury of writing their own web app designed to handle massive bot traffic at minimal cost, gutting functionality to meet that requirement if necessary.
I noticed a couple of weeks ago that 1-2 orders of magnitude more bots were getting past anubis challenges. However, it would be incorrect to conclude that it's doing nothing and now worthless aside from heating up visitors' cpus. If I turn it off, I see >2x bots.
The next salvo in the war of attrition will probably be when anubis switches to wasm hashx, which the author suggested, in previous HN threads, is on the roadmap.
If bots quickly adapt (Claude vibe-coded JIT wasm-to-native-transpiler for hashx challenge algorithms?), that may be the end of anubis and efforts like it. If they don't, I expect more HN threads with people complaining that such compiler efforts are possible and therefore PoW-gated sites are doing it wrong... even if those sites stay usable.
If you just want to block the bottom of the barrel scrapers you don't need to do any proof of work. It's overkill and wastes user's times for such a purpose.
I'm not moralizing. The sites running Anubis are owned by people who like Anubis and are fully within their rights to run Anubis. I don't care how enthusiastic they are about it. It's their call.
The real world doesn't care about the soundness of your computer science. All that matters is whether it works.
It's like saying we should just completely give up on all NP-hard problems because we'll never discover a way to find the optimal solution in all cases. Meanwhile in the real world, people are more than happy with, say, a route planner which virtually all of the time gives them a solution which is within a rounding error of optimal. Nobody is going to care that it is technically bad science.
Same with Anubis: Sure, it's a dead end in an ongoing arms race. It won't last forever. But right now it works pretty well, so let's hope it lasts until someone can figure out a better approach.
I'm fine with you running Anubis. My point was that Tavis flagged the outcome this blog post is discussing a year ago. It was hotly disputed on HN at the time. That's all I'm saying.
You're arguing worst-case, and people running anubis are saying it dramatically helps in their experience, because they're not getting too many of the sorts of bots that people like you and Tavis (correctly) argue are theoretically possible. So the argument that it's "bad CS" falls flat.
A better, perhaps the best, argument is that a worse bot mix might appear tomorrow, so anubis should be used as a runway for a better solution, and not as a solution in itself. If only everyone with a website had the desire (or AI tokens) to implement their own better solution. In some cases even desire or a lot of tokens isn't enough. I mean, you think kernel.org folks haven't put some serious thought into it? And yet, as HN argues about it, there's kernel.org running anubis at difficulty 5.
I don't know what you mean by "the best argument". My entire argument is that it's bad CS. I'm not trying to convince people not to run Anubis. If anything, I'm trying to convince Anubis to use better computer science. That would make more people run it! But even that's just a faint subsidiary goal; the real goal, as someone who works in this field and has designed proof-of-work antiabuse systems before, is just to add clarity about what can and can't work and why.
I too would love anubis to use better CS, if available. Perhaps you have some ideas for @xena, instead of just letting anubis continue on the trajectory of iterating its PoW approach?
I had a fairly long conversation with Xe privately about this and didn't feel the need to repeat it here, especially since (as the search box will tell you) I've already talked about this before. But, do go on.
I looked at your comments and there's a bunch saying that Anubis is bad CS but none I could find saying what, exactly, you want Anubis to do instead. You sure are posting a lot about how it's bad, though.
It is interesting, this particular user seems extremely active in this thread. I'm not sure if they have a bone to pick with Anubis in particular or some other reason for disliking the software so much, but to me it does seem overzealous. Regardless of if it's "bad computer science" or what, Anubis works quite well and is easy to customise to target it to specific botnets, as I've done. And this is coming from someone trying to develop her own non-PoW anti-scraper system.
I get what you're saying, but I think that in the abstract "here's this thing you can do to cut the annoying traffic down to 1/3rd its previous level" (with the obvious issues to legitimate users of course) feels like a nice thing to have in this current moment!
If you were dealing with a DoS like this and had an option that cut the annoying traffic in half in a fairly deterministic way, that sounds like a decent thing to do operationally in the moment right?
Nobody who gives a shit about their software actually working obeys robots.txt. most robots.txt block everything except googlebot, which is an insane policy and you don't have to follow it.
Which isn't all that relevant a discussion here. Anthropic saying they did so in this case, means that they admit they were the scraper flooding the domain.
There are more than just the American top dogs (OAI, Anthropic, SpaceX, Facebook)... especially the Chinese government with all its infinite cash resources and next to zero ethical constraints.
I don't trust the US top dogs at all, but I think the fear of discovery alone would lead them to not use "residential proxy" services. Non-US/EU entities however... who cares?
Why would they directly use a proxy service? I'd just launder the data scraping through some third party company that I could slough off if it ever turned into a news story. Not that anything would happen to them if they directly used these services anyway.
If they were even slightly concerned that the scope went beyond what they were aware of with JSTOR, they would've either immediately contacted police or disconnected the laptop. The timeline in the report outlines that they discovered the laptop at 8am, and were in internal communications with their bosses and MIT's lawyers before someone finally contacted police at 9:45am.
They knew what was going on before they found the laptop. They had been briefed by someone at MIT who was in contact with JSTOR. I suspect that everyone on the networking staff (and possibly most of the university) knew of the JSTOR downloading situation after the second incident in October. JSTOR had blocked MIT for 3 days, and that must have caught people's attention.
Once they found the laptop, they involved police despite knowing to a virtual certainty that the problem with the laptop was that it was scraping JSTOR, again. They didn't know yet that it was Aaron, but they would've known it would turn out to be someone ideologically just like him.
There was nothing suspicious about it. It was simply jeopardizing MIT's contract with JSTOR. The use of a data closet like that was very bad manners.
The expectation is that MIT doesn't go to the police when someone plugs a computer into a switch in an effectively unlocked data closet.
The expectation is that such individual and laptop doing "unauthorized" scraping doesn't trigger a criminal investigation when the host university, and the target business, didn't implement any meaningful access controls or even rate limiting for any other person on campus.
The expectation is that after an investigation of scraping at 11 req/s (450,000 over 11 hours according to the report), a further 8,000 requests (before JSTOR blocked MIT's /8) two weeks later would not have the effect that "Half the servers in one data center failed, and JSTOR engineers feared that the entire service might go down worldwide." The expectation based on that claim by JSTOR is that JSTOR was incompetent or lying.
The expectation is that when MIT was able and willing to implement access control for JSTOR, and JSTOR declined because they want to develop a notice to MIT visitors who might be negatively affected by ending uncredentialed access, JSTOR would not then create a tempest in a teapot over the violator returning and continuing to download papers at a reduced speed that wasn't even detected for about a month. On Dec 26, when JSTOR again noticed the "abuse", they went to significant effort to route the violator's requests to a special server and serve them garbage instead of the real PDFs, all on short notice... yet they couldn't add the general notice to MIT visitors about the credentials requirement, on a much less urgent timescale; they had told MIT in October that they needed until after Dec 18th to add such a message. The expectation is that JSTOR's claims are self-serving lies.
The expectation is that such a request pattern would not trigger a report, by the MIT libraries director, to the MIT academic council, that a "cyberattack" had been launched from MIT's network.
The expectation is that you don't get arrested for felony B&E for entering a data closet that's effectively unlocked, connecting to a switch, and scraping a paper hosting site that offers free downloads from the entire institutional network.
The expectation is that you don't get charged with larceny for downloading, in any quantity, papers that are freely available to anyone on the MIT campus or probably most other campuses in the U.S.
The expectation is that sending web requests with a url parameter indicating T&C has been agreed to, and without saving cookies, might be a basis for a civil action, but is not "accessing a computer without authorization" under the CFAA.
The entire situation, at most, should've been a minor local crime and a lawsuit by JSTOR against Swartz. Yet the state charges were dropped (feds didn't want to share required discovery material), and JSTOR settled with Swartz before the feds even indicted.
MIT was caught in an awkward position of having the ability to block unauthenticated scraping to protect their contract with and access to JSTOR, but not doing so. So they proceeded to treat someone connecting to a switch in a data closet and doing what any MIT visitor could do, as a criminal offense.
I don't believe anyone at MIT was genuinely concerned that there was some broader criminal conspiracy when the issue was downloading of papers from JSTOR. Certainly not based on some random Chinese IP pinging or scanning Swartz's laptop. When the data closet laptop was discovered in January, MIT could have left a note telling the owner that JSTOR is very upset and it would be better for everyone if the scraping stopped. Why didn't they? They could even, reasonably, have taken the laptop and external drive and noted that the data closet was insecure and please contact network staff to claim it.
Modern references seem to align (for instance, Garner's): Bald-faced and bare-faced have slightly different connotation than bold-faced. Despite "bold-faced lie" being in somewhat common use, "bald-faced lie" is more common (over 2x according to google stats), and overwhelmingly agreed upon as the "literate" choice, unless an author intends to refer to the sort of lie that would headline an article.
[edited to more align with the essay's thesis, thanks to the reply for pointing out misalignment]
I don't think anyone complained about the hologram or red moon desert background because they disliked windows; they complained because they were hypersensitive to possible inappropriate/sexual connotations in imagery.
(Conversely, I very much doubt that the baby hologram or the red moon desert background swayed anyone to dislike Windows.)
People who hated Windows for being Windows would complain about it on technical grounds. It was terrible, and it crashed all the time. People who hated Windows because it was by Microsoft, would complain about Microsoft's bundling and monopoly tactics.
This does not seem to be related to the article. OP is about red moon and naked baby and clouds. It does not claim that anyone hated windows because of that.
Usually I wouldn't comment just to point out offtopic, but I think "instant bad thoughts every time windows is mentioned, no matter the context" is another psychological effect caused by Microsoft.
Is that statement by Iron Mountain's attorney believable, though?
If cage or server access was shared between Iron Mountain customers, how can Iron Mountain not have a record of what's in what cage or what's on what server?
If Iron Mountain customers like OSS were free to add or remove things without Iron Mountain's knowledge, then their (OSS's) access would've been limited to cages or servers dedicated to their (OSS's) own clients' data. Allowing an OSS ex-employee the same access they previously would've had should be a non-issue, from Iron Mountain's perspective.
What iron mountain does know is which drives are owned by oss. What they don't know is which drives owned by oss have the station's data on them. Hopefully nothing is comingled and drives are dedicated to a customer. Seemingly only oss knows and they went bankrupt so who knows what shape the records are in.
It's also possible IM serves a scaleable storage system that mingles data across customers. If you S3 they don't isolate clients per physical drive, they store blocks pretty randomly across millions of drives.
Plus the case above: OSS could have had another company storing sensitive medical records, and this hands over those drives to a PBS station.
reply