I was working for a marine biologist applying computer vision to the task of counting migrating river herring. The data set was lousy, with background movement, poor foreground/background separation, inconsistent lighting, and slow exposures that created blurry streaks. Moreover, the researchers had posted the frames to some citizen science platform and asked volunteers to tag each fish with a single point—sufficient for counting by hand, but basically useless for object detection.
In desperation I turned to Mechanical Turk to have the labels redone as bounding boxes, with some amount of agreement between labelers. Even then, results were so-so, with many workers making essentially random labels. I had to take another pass, flipping rapidly through thousands of frames with low confidence scores, which gave me nausea not unlike seasickness.
The judges do absolutely everything they can to keep these things moving or settle. They force people to mediation, they force people to reduce the claims to get rid of shitty claims, etc. Everything they can to get the vast majority of cases that shouldn't need a judge to resolve (which is most of them), out of court. This does slow things down.
To give you a sense of how good we are at that (surprisingly), only 1% of federal civil cases (IE this kind) actually reach trial. Only 0.7% reach a jury. It's not evenly distributed across claim types, but if we could push people to that state faster, you'd get some speedup. Not as much as you think. In federal district court, you will get pushed to mediation very very quickly in most cases.
They also have special programs to handle complex litigation, to handle multi-district litigation, etc. From a process standpoint, it's more efficient than i think people give it credit for.
Trials themselves are usually quick (a few weeks). But even that volume is immense.
In 2024, there were 347,991 new civil cases filed in federal district courts. Up 22% (ie crazytown) from the year before. In 2025, so far, it's back down again, but we'll see. A few years ago it was >500,000 new federal civil cases in a year.
There are 94 federal district courts in the US, and 677 federal district judges.
The average number of pending cases over the past 12 months, per judgeship, currently stands at 757.
Maybe they work slow?
Nope - they have, on average, terminated 866 cases each in the past year. So uh, terminated more than 16 cases a week.
Each.
The number of district court judges is set by congress. It has been set at 677 for a long time. For the volume of cases that there are these days, it's not enough if you want them to go to trial in less than a few years.
If we ignore the deliberate abuse of things like binding arbitration, etc, it really does exist (as mediation does) to try to get people to stop wasting court time on things that don't need court.
Because while sure, you could always say "get more judges", it's very hard to say 500,000 new federal civil cases a year is not crazy. This is just federal district courts, too. State courts get 13-20 million new civil cases a year.
While plenty of lawyers play games, it's honestly mostly the clients. Lawyers just get all the blame.
> "When you consider that classical engineers are responsible for the correctness of their work"
Woah hang on, I think this betrays a severe misunderstanding of what engineers do.
FWIW I was trained as a classical engineer (mechanical), but pretty much just write code these days. But I did have a past life as a not-SWE.
Most classical engineering fields deal with probabilistic system components all of the time. In fact I'd go as far as to say that inability to deal with probabilistic components is disqualifying from many engineering endeavors.
Process engineers for example have to account for human error rates. On a given production line with humans in a loop, the operators will sometimes screw up. Designing systems to detect these errors (which are highly probabilistic!), mitigate them, and reduce the occurrence rates of such errors is a huge part of the job.
Likewise even for regular mechanical engineers, there are probabilistic variances in manufacturing tolerances. Your specs are always given with confidence intervals (this metal sheet is 1mm thick +- 0.05mm) because of this. All of the designs you work on specifically account for this (hence safety margins!). The ways in which these probabilities combine and interact is a serious field of study.
Software engineering is unlike traditional engineering disciplines in that for most of its lifetime it's had the luxury of purely deterministic expectations. This is not true in nearly every other type of engineering.
If anything the advent of ML has introduced this element to software, and the ability to actually work with probabilistic outcomes is what separates those who are serious about this stuff vs. demoware hot air blowers.
I used to be in charge of technical measures for controlling crackpot submissions at arXiv because we were trying to get a very ornery physicist from not getting us in trouble sending nastygrams to HBCUs and such. The endorsement system was my work.
Two things we noticed were: (1) there weren’t really that many crackpot submissions but they were concentrated in certain areas that really would have been overrun with them. Crackpots don’t ever seem to find out that there is a big mystery in how cuprate semiconductors superconduct or what determines how proteins fold or even that there is such a thing as condensed-matter physics (e.g. most of it!) (2) Crackpots almost always work alone, contrasted to real physicists who work with other physicists which was the basis for the endorsement system. We’d ask a crackpot “who else is working on this?” And always get the answer “no one.”
From having done that work but also having an interest in the phenomenon, being too well read of a person to make it in academia, and personally meeting more than my share of lunatics, that it is really a psychiatric phenomenon really a subtype of paranoia
particularly involving grandiosity but sometimes litigiousness. It boggles my mind that Weinstein threatened a lawsuit over criticism of his ideas, something I’ve never heard of a real scientist doing —- I mean, scientific truth is outside the jurisdiction of the courts. I met
and did not get to put his motor on my bench but I did set up some equipment on my bench that showed that the equipment he was demoing his motor on could give inaccurate readings and he had this crazy story of sueing the patent office and using his right-wing connections with churches and the Reagan administration to bully NIST into testing his motor.
(Okay, to be fair, compilers tend to change the loop bounds so that the final comparison is a comparison against 0. This will reduce the register usage of the loop, but otherwise doesn't change the analysis). Taking into account micro-op fusion, there is at best two actual hardware ops in that assembly pattern, since the comparison and branch will be fused, and the increment(/decrement) is also a decent candidate for fusion. The branch can also be predicted with a high degree of fidelity--an advanced processor should be able to predict the branch with exactly 100% accuracy.
You still have the some basic pattern at the end of the loop, except that the INC (which might not have been previously fused) is no longer in the critical path, but now the critical path instead has a load in it. That load is a much slower instruction than a test-against-0 or a comparison: no load completes in one cycle, whereas both tests (bitwise and) and comparisons (subtraction) complete in one cycle. Splitting hairs by saying that the test-against-0 is going to be less expensive than a subtract-and-check-carry, so therefore null-terminated is faster ignores the fact that they execute in the same time and brushes the extra load, which is definitely slower, that exists in the null-terminated string.
It goes worse, though. When you have a pointer+length combo, the length of the array, and the legal dereferenceability, is now known to the compiler in symbolic form that is easy to compute. That makes it possible to do things like unroll loops, or vectorize loops, or rewrite loop bounds in better forms, etc. When it's null-terminated, the length comes from reading memory, and the amount of memory you can read is not known ahead of time. Unrolling the loop or other steps are no longer really possible since you don't know how many iterations the loop will take, and the extra loop exits you'd generate tend not to be tolerable in optimization.
This story has been reposted many times, and I think GJS's remarks (as recorded by Andy Wingo) are super-interesting as always, but this is really not a great account of "why MIT switched from Scheme to Python."
Source: I worked with GJS (I also know Alexey and have met Andy Wingo), and I took 6.001, my current research still has us referring to SICP on a regular basis, and in 2006 Kaijen Hsiao and I were the TAs for what was basically the first offering of the class that quasi-replaced it (6.01) taught by Leslie Kaelbling, Hal Abelson, and Jacob White.
I would defer to lots of people who know the story better than me, but here's my understanding of the history. When the MIT EECS intro curriculum was redesigned in the 1980s, there was a theory that an EECS education should start with four "deep dives" into the four "languages of engineering." There were four 15-unit courses, each about one of these "languages":
- 6.001: Structure and Interpretation of Computer Programs (the "procedural" language, led by Abelson and Sussman)
- 6.002: Circuits and Electronics ("structural" language)
- 6.003: Signals and Systems ("functional" language)
These were intellectually deep classes, although there was pain in them, and they weren't universally beloved. 6.001 wasn't really about Scheme; I think a lot of the point of using Scheme (as I understood it) is that the language is so minimalist and so beautiful that even this first intro course can be about fundamental concepts of computer science without getting distracted by the language. This intro sequence lasted until the mid-2000s, when enrollment in EECS ("Course 6") declined after the dot-com crash, and (as would be expected, and I think particularly worrisome) the enrollment drop was greater among demographic groups that EECS was eager to retain. My understanding circa 2005 is that there was a view that EECS had broadened in its applications, and that beginning the curriculum with four "deep dives" was offputting to students who might not be as sure that they wanted to pursue EECS and might not be aware of all the cool places they could go with that education (e.g. to robotics, graphics, biomedical applications, genomics, computer vision, NLP, systems, databases, visualization, networking, HCI, ...).
I wasn't in the room where these decisions were made, and I bet there were multiple motivations for these changes, but I understood that was part of the thinking. As a result, the EECS curriculum was redesigned circa 2005-7 to de-emphasize the four 15-unit "deep dives" and replace them with two 12-unit survey courses, each one a survey of a bunch of cool places that EECS could go. The "6.01" course (led by Kaelbling, Abelson, and White) was about robots, control, sensing, statistics, probabilistic inference, etc., and students did projects where the robot drove around a maze (starting from an unknown position) and sensed the walls with little sonar sensors and did Bayesian inference to figure out its structure and where it was. The "6.02" course was about communication, information, compression, networking, etc., and eventually the students were supposed to each get a software radio and build a Wi-Fi-like system (the software radios proved difficult and, much later, I helped make this an acoustic modem project).
The goal of these classes (as I understood) was to expose students to a broad range of all the cool stuff that EECS could do and to let them get there sooner (e.g. two classes instead of four) -- keep in mind this was in the wake of the dot-com crash when a lot of people were telling students that if they majored in computer science, they were going to end up programming for an insurance company at a cubicle farm before their job was inevitably outsourced to a low-cost-of-living country.
6.01 used Python, but in a very different way than 6.001 "used" Scheme -- my recollection is that the programming work in 6.01 (at least circa 2006) was minimal and was only to, e.g., implement short programs that drove the robot and averaged readings from its sonar sensors and made steering decisions or inferred the robot location. It was nothing like the big programming projects in 6.001 (the OOP virtual world, the metacircular evaluator, etc.).
So I don't think it really captures it to say that MIT "switched from Scheme to Python" -- I think the MIT EECS intro sequence switched from four deep-dive classes to two survey ones, and while the first "deep dive" course (6.001) had included a lot of programming, the first of the new survey courses only had students write pretty small programs (e.g. "drive the robot and maintain equal distance between the two walls") where the simplest thing was to use a scripting language where the small amount of necessary information can be taught by example. But it's not like the students learned Python in that class.
My (less present) understanding is that >a decade after this 2006-era curricular change, the department has largely deprecated the idea of an EECS core curriculum, and MIT CS undergrads now go through something closer to a conventional CS0/CS1 sequence, similar to other CS departments around the country (https://www.eecs.mit.edu/changes-to-6-100a-b-l/). But all of that is long after the change that Sussman and Wingo are talking about here.
Whenever you have a proposal like this that essentially laments that we don't have the nice shiny thing, it's quite useful to take a few step backs and ask "well, why don't we have it," and try to consider some of the problems with it. This paper is no exception--advocating for a return to a Smalltalk/LISP machine approach as opposed to Unix; why don't we have those things?
The facile answer is the "no true Scotsman"--we've never really had a true, whole-system approach to this, only approximations, and if only we had that true, whole-system approach, everyone would fall in love with it. I'm not persuaded. We were forced to use a Smalltalk environment for one of our classes, and the reaction was pretty universally negative. Not because it was a lamentably incomplete instantiation of a wonderful thing, but because if you screwed up--as anybody is wont to do--you would just absolutely and sometimes irreversibly hose the entire system. Imagine trying to poke at an error stack trace resulting in the only editor you could use to fix it breaking with the only means of recovery going back (outside of the all-encompassing environment, mind you) to an older version.
So I think that's the real reason these systems never took off: "everything works together" too often becomes "everything breaks together." Hotpatching code sounds nice, but it now means you get to deal with stuff like "oops, the global cache has both the old and new version stuffed in it and something else is hosed as a result." Replacing "sqrt" with "mysqrt" everywhere also implies the ability to replace "open" with "vfsopen" everywhere... only to accidentally map it to a VFS that has no files and now you can't open any files on your system from any application.
>Biology researchers aren't reverse engineering the binary outputs of qPCR machines
While this is beside your point, outputs from qPCR machines are often reasonably interpretable. I've seen one model that's XML, and one that's JSON, both as files in an overall data file that's just a ZIP, and I have seen intermediate files that are just plain text. In both cases, these are processed on the machine from raw images, which are a standard TIFFs, though they are usually not stored.
I am similarly left confused about the motivation of this project, however. If I recall correctly, commercial offerings of cryptographic signatures for qPCR machines already exist, running on the machines. Also, while they immediately dismiss the idea of modifying the machine, or even using different software, those are both important considerations. Many modern qPCR machines have computers running full operating systems in them (the QuantStudio machines run Android, for example, and have their core control running internally in Python); these can extremely insecure. All the work they have done would do nothing to protect against a modified machine, and contrary to what they suggest, I have found that modifying machines, and writing interface software as an alternative to the manufacturer's, can be quite easy. qPCR machines are not actually very complicated instruments, especially from a firmware perspective. In putting tamper-evident seals on the machines they perhaps don't realize how open lab equipment can be: I've seen almost intentional unauthenticated privileged remote code execution, for example.
And, as you note: it's very unclear what type of behavior this is even trying to defend against. Research malpractice is both rare, and can take place at very many points in the process. This seems like it is defending against a particularly unlikely point. I think fraud would more likely take place either in setup, or in data processing.
And finally: this locks down machines to be only usable in very specific ways. That is reasonable in diagnostic and clinical settings. But research is often not about doing the exact same thing that has already been done. It often involves new uses for equipment, and new experimental methods. Most of my use of qPCR machines, for examplee, would be impossible in their setup, as I'm using them in ways the manufacturer's software doesn't support, and the data coming out has nothing to do with qPCR, and so can't be processed in a normal way. At some level, research equipment cannot be heavily constrained, as that is contrary to the very point of research.
(For context: I maintain an open source package to control QuantStudio machines, primarily intended for using them for non-qPCR purposes.)
This came out at the end of my career as a serious professional cook and I have mixed experience with it. It's kind of an escoffier guide culinaire type deal for the 2000s. It documents & standardizes, or at least presents emerging conventions for, a huge range of techniques that were in use in certain kinds of restaurants in the preceding two decades.
In terms of food like that you sit down and eat with other people, it was narrowly focused and dated almost immediately. But some of the techniques and "moves" became genuinely mainstream and it's fairly reliable as a reference to them. And some of the others didn't, but could have and are useful, and unless you were cooking at one of a couple dozen restaurants from 2002-2008 you're unlikely to find another detailed guide to how to do them.
That said, for a lot of the detailed technical stuff, they generally chose to authoritatively select one specific approach to a technique, eliding details that can definitely be a big deal at this level of precision. Sometimes the "recipe" is really more of a demo, silently depending on details like a neutral pH, making it prone to failure if modified but too basic to be usable in its presented state.
Also some of the techniques simply don't work as written. Specifically the ones that are presented as novel simplifications for complex molecular gastronomy operations are really hit or miss. I suspect these are just really bad cases of the previous point, where there is a hidden variable they didn't document, that didn't come up in testing. But there is a replication crisis in cookbooks too, this is not out of the norm though it is frustrating.
It also raises the annoying question that's been in my head for 15 years now: wtf does myhrvold think "modernist" means?
Back in 2010 when we were building Amazon Route 53, we had a really big problem to solve. DDOS attacks. DNS is critical, and it uses UDP, which is a protocol that allows attackers to spoof their source IP address. We knew that DNS services are a common target for attacks from botnets; and our research at the time showed that our established competitors used large and expensive "packet scrubbers" to handle this.
We budgeted out what we think it would cost to handle our scale and the price tag came to tens of millions of dollars. You might think that would be no problem for a big company like Amazon, but our total infrastructure budget for Route 53 was something like tens of thousands of dollars. At the edge, we were re-using CloudFront servers that had failed hard drives for our name servers; since we wouldn't need much storage, and our API servers were pretty modest. We had a team of about ~6 people. That's what "scrappy" looks like at AWS; spend nothing, minimize downside risk, get things done quickly. There was no way I was going to ask for tens of millions of dollars for packet scrubbers. Besides, they would take too long to arrive, and would make us too reliant on a vendor.
Early on we had decided to run Route 53 name servers on its own dedicated IP range to give some measure of isolation. We could use dedicated network links to make sure that Amazon's other infrastructure wouldn't be impacted. But that wouldn't help Route 53's customers from sharing fate with each other. We didn't have a real plan beyond "When it happens, get really good filtering using our existing network and system tools".
Early that summer, I was reading one of Knuth's recent fascicles for 4A and was swimming in combinatorial algorithms. One night it just "clicked" that by creating many virtual name servers, we could easily assign every customer to a unique combination of four of those virtual name servers. We could even control the amount of overlap; some quick math showed that we about two thousand name servers, we could guarantee that no two customer would share more than two name servers. That number is important because our experiments showed that domains resolve just fine even when two name servers are unreachable, but beyond that it starts to be a problem.
The recursive search algorithm to assign the IPs was inspired directly by the algorithms in 4A; it gives customer domains two more independent dimensions of isolation. They also get 4 name servers from 4 independent "stripes", which correspond to the different TLDs we use for the name server names (co.uk, com, net, org). This guarantees that if one of those TLDs has an issue (like a DNSSEC mistake), only one of the name servers is impacted. They also come from 4 independent "braids", which can be used to ensure that no two name servers share certain network paths or physical hardware. I just wouldn't have known how to do any of this without reading 4A. And I even have a background in combinatorials; from statistics and cryptography.
I've never been more excited by a solution; this approach gave us provable network IP level isolation between customer domains while costing basically nothing in real infrastructure. It's math. It wasn't completely free; we had to use 2,000 anycast IP addresses, and it turns out that we also had to register 512 domains for them because of how many TLDs require name servers to be registered and to have glue records; so that was a fun process working with our registrar. But we got it done.
I named the approach "Shuffle Sharding", and it's more discovery than invention. Many multi-tenant systems that use some kind of random placement get a kind of shuffle sharding, and network filtering techniques like Stochastic Fair Blue use time-seeded hashing to similar effect. But I've never seen anything quite the same, or with the level of control that we could apply; I could even extend it to a kind of recursive nested shuffle shading that isolates at even more levels. For example if you want to isolate not just a caller, but a caller's callers when they are in some kind of "on behalf of" call pattern.
Years later, I made a personal pilgrimage of gratitude to see a Knuth Christmas lecture in person, and sat in the front row. I still read every scrap of material that Knuth puts out (including the Organ pieces!) because I never know what it might inspire. All of this to say ... I do think his volumes are surprisingly practical for programmers; they broaden your mind as well as deepen your understanding. What more could you want.
I happen to have some first-hand knowledge around the subject! In 2014 someone did a talk[0] on disabling the camera on some older Macbooks. It was fairly trivial, basically just reflashing the firmware that controlled the LED. I worked on the security team at Apple at the time and in response to this I attempted to do the same for more modern Macbooks. I won't go into the results but the decision was made to re-architect how the LED is turned on. I was the security architect for the feature.
A custom PMIC for what's known as the forehead board was designed that has a voltage source that is ALWAYS on as long as the camera sensor has power at all. It also incorporates a hard (as in, tie-cells) lower limit for PWM duty cycle for the camera LED so you can't PWM an LED down to make it hard to see. (PWM is required because LED brightness is somewhat variable between runs, so they're calibrated to always have uniform brightness.)
On top of this the PMIC has a counter that enforces a minimum on-time for the LED voltage regulator. I believe it was configured to force the LED to stay on for 3 seconds.
This PMIC is powered from the system rail, and no system rail means no power to the main SoC/processor so it's impossible to cut the 3 seconds short by yoinking the power to the entire forehead board.
tl;dr On Macbooks made after 2014, no firmware is involved whatsoever to enforce that the LED comes on when frames could be captured, and no firmware is involved in enforcing the LED stay on for 3 seconds after a single frame is captured.
Great to see so many reactions to my interview, thanks!
I see that many people are confused by the interview's title, and also by my take that math talent isn't primarily a matter of genes. It may sound like naive egalitarianism, but it's not. It's a statement about the nature of math as a cognitive activity.
For the sake of clarity, let me repost my reply to someone who had objected that my take was "clickbait".
This person's comment began with a nice metaphor:
'I cannot agree. It's just "feel-good thinking." "Everybody can do everything." Well, that's simply not true. I'm fairly sure you (yes, you in particular) can't run the 100m in less than 10s, no matter how hard you trained. And the biological underpinning of our capabilities doesn't magically stop at the brain-blood barrier. We all do have different brains.'
Here was my reply (copy-pasted from my post buried somewhere deep in the discussion):
I'm the author of what you've just described as clickbait.
Interestingly, the 100m metaphor is extensively discussed in my book, where I explain why it should rather lead to the exact opposite of your conclusion.
The situation with math isn't that there's a bunch of people who run under 10s. It's more like the best people run in 1 nanosecond, while the majority of the population never gets to the finish line.
Highly-heritable polygenic traits like height follow a Gaussian distribution because this is what you get through linear expression of many random variations. There is no genetic pathway to Pareto-like distribution like what we see in math — they're always obtained through iterated stochastic draws where one capitalizes on past successes (Yule process).
When I claim everyone is capable of doing math, I'm not making a naive egalitarian claim.
As a pure mathematician who's been exposed to insane levels of math "genius" , I'm acutely aware of the breadth of the math talent gap. As explained in the interview, I don't think "normal people" can catch up with people like Grothendieck or Thurston, who started in early childhood. But I do think that the extreme talent of these "geniuses" is a testimonial to the gigantic margin of progression that lies in each of us.
In other words: you'll never run in a nanosecond, but you can become 1000x better at math than you thought was your limit.
There are actual techniques that career mathematicians know about. These techniques are hard to teach because they’re hard to communicate: it's all about adopting the right mental attitude, performing the right "unseen actions" in your head.
I know this sounds like clickbait, but it's not. My book is a serious attempt to document the secret "oral tradition" of top mathematicians, what they all know and discuss behind closed doors.
Feel free to dismiss my ideas with a shrug, but just be aware that they are fairly consensual among elite mathematicians.
A good number of Abel prize winners & Fields medallists have read my book and found it important and accurate. It's been blurbed by Steve Strogatz and Terry Tao.
In other words: the people who run the mathematical 100m in under a second don't think it's because of their genes. They may have a hard time putting words to it, but they all have a very clear memory of how they got there.
TSMC and other ASML customers build the designs that let those fancy printers create transistors and then logic gates, as well as a basic library of arrangements for those logic gates (PDK). They also provide all of the raw materials and processes and physics that go into said printers.
Apple and other design customers then compile RTL using that PDK to produce a design that can be manufactured using the fab’s process steps.
The printers are A hard part but far from The hard part. If you have an ASML machine it is useless to you unless you have also figured out how to build a 3D transistor in layers. Good luck!
"which is 3 orders of magnitude faster than a single frame in a video game."
You're right on the money. I worked in HFT for half a decade.
Back in the late 2000s you were on the cutting edge if you were writing really good C++ and had overclocked some CPUs to hell and back and then shoved them in a rack in a datacenter in new jersey. "To hell and back" means "they only crash every hour or two" (because while they're up, they're faster than your competition).
Around the mid 2010's it had moved entirely to FPGAs. Do something smart in software, then give the FPGA something dumb to wait for (e.g. use software to produce a model and wait for some kind of alpha to develop, then tell the FPGA "ok wait for X > Y and fire the order" was basically the name of the game. And it was often better to be faster than it was to be smarter, so really you just kept the FPGA as simple and fast as possible.
At that point, your hard realtime constraints for the language doing the smart stuff really dissolve. Compared to an FPGA getting an order out the door in some fraction of a mic, a CPU doing anything is slow. So you might as well use python, yknow?
People also play all kinds of different speed games. There's latency races around NJ and chicago where microseconds matter around price movements and C++ isn't really part of the picture in a competitive way anymore, but that's not to say someone isn't ekeing out a niche where they're doing something vaguely smarter faster than opponents. But these things, at scale, tend to be questions of - either your alpha is very short-lived (microseconds, and if it isn't organically microseconds, it will be competed until it is), or it is fundamentally longer-lived (seconds to minutes?) and you might as well use python and develop 100x faster.
The silly thing is, the really good trades that focus on short-term alphas (ms's and less) are generally obviously good trades and so you don't have to be super smart to realize it's a really fucking good trade, you had better be fast and go get it. So there's also this kind of built-in bias for being fast because if a trade is so marginally good that you needed a crazy smart and slow model to tell it apart from a bad trade, it's probably still a relatively crummy trade and all your smarts let you do is pick up a few extra pennies for your trouble.
I'll close by saying don't take my words as representative of the industry - the trades my firm specialized in was literally a dying breed and my understanding is that most of the big crazy-crazy-fast-microwave-network people have moved to doing order execution anyway, because most of the money in the crazy-crazy-fast game dried up as more firms switched to either DIYing the order execution or paying a former-HFT to do it for them.
>This isn't how Supreme Court cases usually work. Most of the time, as in this case, they clarify some things and send it back to the lower courts.
I'm actually a member of the Supreme Court bar, and have been involved in a number of supreme court cases, so i'm fairly aware of how Supreme Court cases work :)
They did what I said:
"Whenever the President and Vice President discuss their official responsibilities, they engage in official conduct. Presiding over the January 6 certification proceeding at which Members of Congress count the electoral votes is a constitutional and statutory duty of the Vice
President. Art. II, §1, cl. 3; Amdt. 12; 3 U. S. C. §15. The indictment’s allegations that Trump attempted to pressure the Vice President to take particular acts in connection with his role at the certification proceeding thus involve official conduct, and Trump is at least presumptively immune from prosecution for such conduct"
The other big challenge is from a SAR (structure-activity relationship) point of view, it's completely benign looking from just about any way you look at it. It's two peptides, and a methanol (which yes, gets converted to formaldehyde, but so does fruit pectin). There's nothing zany about its structure, it's not particularly lipophilic, no receptor bindings of note, no spicy reactive groups, no alkylators, no intercalators, no redox sites. If it doesn't look like a duck, doesn't quack, doesn't waddle, doesn't fly, doesn't hang out in ponds, and hasn't shown ducklike activity over 50 years, what are the odds it's secretly a duck?
This reminds me of some playing around I did with x86 instruction decoding. I've sort of come to a conclusion that both the assembly and the manual are lying to you a little bit about the actual instruction formats.
The basic form of an x86 instruction is as follows:
* The presence or absence of each of 5 "legacy" prefixes (0x66, 0x67, 0xf0, 0xf2, 0xf3). Supposedly, 0xf0, 0xf2, and 0xf3 can't coexist (they're all group 1), but if you look carefully at a few instructions, it turns out that there are some instructions which require you to specify two of them at the same time.
* The group 2 prefixes end up being a segment register specifier, although they got overloaded as branch hits for the branch instructions.
* If you use a REX prefix, it adds an extra bit to the opcode (REX.w). If you use a VEX prefix, it adds two extra bits (REX.w and VEX.l). EVEX adds five extra bits (REX.w, VEX.l + EVEX.l, EVEX.b, EVEX.z). Otherwise, everything they add is extra register bits, although some instructions may have differences if they use a "modern" prefix versus not.
* Opcode map. For VEX and EVEX, you specify this via a few bits in the prefix, but otherwise, you use 0x0f, 0x0f 0x38, or 0x0f 0x3a to specify.
* 1-byte opcode.
Combine all of these together, and you almost have every unique instruction. That's roughly ~21 bits of opcode encoding (fewer due to holes and impossible encodings), and this will tell you what the instruction expects as its opcode form: whether it has a ModR/M byte and how many subsequent immediate bytes it expects. The ModR/M byte specifies a register and either a register or a memory location. It actually doesn't take that long to iterate through every single x86 instruction!
However, there's one last trick x86 plays: sometimes, the register of the ModR/M byte is used to select between different instructions, particularly when you have an instruction that only takes memory instructions. So the instruction 0x0f 0x01 with r0 is a SGDT instruction, whereas the instruction 0x0f 0x01 with r3 is a LIDT instruction instead.
> The cerebellum has a repeated, almost crystal-like neural structure:
As a software engineer who did neurosurgery residency, my intuition/guess is that the cerebellum is kind of like the FPGA of the brain.
The cerebrum is great for doing very complicated novel tasks, but it takes time and energy. The cerebellum on the other hand is specialized in being able to encode common tasks so it can do them with quickly and efficiently. A lot of our motor learning is in fact wiring the cerebellum correctly.
This can actually lead to an interesting amnesia, where a person can learn a skill (cerebellum) but not remember learning the skill (cerebrum). So you could end up with a person who would think that he had never seen a basketball hoop or basketball before but could be doing layups, dunks, and 3 pointers with ease.
Lawyer here. Hard disagree. The software is sold for the purpose of reducing competition, and gives advice on how to best achieve that. Everyone colluding is buying and using the software with a goal of not competing with each other.
That is just about a textbook case.
You can remove the software. Imagine you all pay someone to write a number on a piece of paper that gets posted on a light pole once a month. You don't get a say what the number is, but you all agree to set prices at that number 80% of the time.
This is illegal. Even if you remove the 80% and say "we recommend you use this number 80% of the time to maximize your non competition", it would be illegal
This is not a close case. Fixing the price this way is illegal.
Agreeing not to compete at all is illegal.
It does not matter if you get someone else to set the price. At the point you all agree not to compete, you've clearly violated the act.
As for whether it's per-se illegal, per-se illegal went out the window on basically all illegal acts under the sherman act over the past few decades, except a few remaining forms of price-fixing.
But you would still win the cases under the rule of reason anyway, and it would not be close there either.
People seem really hung up on whether they agreed with each other explicitly.
They don't have to. Conspiracy suffices. Tacit agreement is not illegal, but it has to be truly tacit. This is not. As I said elsewhere: it is illegal for them to conspire to not compete matter what the form of the conspiracy.
However if they just aren't competing, you can't order them to compete.
This is a clear case of the former - they are conspiring towards a common non competition goal. They knew what would happen if they conspired this way.
It's like trying to avoid a conspiracy to commit murder charge by saying you never explicitly agreed to hire a particular hitman, you instead just followed the directions some software gave you when it said "in order to maximize the possibility of your husband being dead, we recommend depositing at least five million at the following address". Good luck with your claim that you didn't agree to anything with anyone - you were just maximizing some probabilities.
Hell, i bet when they do discovery the company has not been as careful as they think, and there are chats/emails about how successfully they've been able to destroy competition or raise prices or whatever.
Because there always is.
Libc is really a conflation of at least three different notional libraries. The first library is what its name suggests it is, a standard library for C. Another part of the library is in providing the userspace portion of system services--things like handling static initializers, dynamic loading, or the userspace side of things like creating new threads (not to mention, the actual raw functions you call to get the kernel to do something). The final part of the library is a collection of userspace services which are language agnostic, you might choose different implementations, but you'll always assume are somehow present--libm and malloc are the goto examples here.
As for why the userspace system service library is part of libc instead of being a separate libsyscall or libkernel, that probably is due to Unix being a C operating system--written at a time when most operating systems also came with their own system language. It's definitely not the case for all OS's that the C runtime library is the same as the libsyscall/libkernel--most notably, on Windows, the former is MSVCRT*.dll and the latter is kernel32.dll (or ntdll.dll if you're looking very specifically at syscalls themselves, but ntdll.dll is largely an unstable interface).
The article shows the connection but it doesn't present an intuition of the why, which I think is by far more interesting, and it's key to understanding Fourier analysis.
You can take a vector and shift all its elements to the right by 1 (rotating the last entry to the first position), let's call this operator S.
Since the rows of a circulant matrix C are all rotations, if you apply the shift S, then multiply by C, and then shift back, you get the same result as if you just multiplied by C. In equations, S^-1 C S = C.
This is another way of saying that circulant matrices are shift-invariant. If you have a vector of zeros and just a few values in the middle, the matrix doesn't care where those non-zeros are, the result is the same but shifted accordingly; intuitively, the matrix operates in the frequency domain, not in the spatial domain. This is the same idea behind convolutional neural networks: translation-invariance means that we can ignore the position of an object in an image, and thus share the parameters across all positions, reducing the parameter complexity from quadratic to linear.
Now one of the first things you learn in linear algebra is that if two matrixes commute, they share the eigenspaces. We know that SC = CS from the equation above, so if we want to find the eigenvectors of any C, we can just find the eigenvectors of S.
But if we write S in matrix form, it is just ones under the diagonal, and a one on the top right. That's the companion matrix [1] of x^n - 1! So the eigenvalues are the nth roots of unity, and that shows the connection.
These intuitions translate (haha) quite naturally to function spaces, where shift-invariant operators are diagonalized by Fourier series (for periodic functions) and Fourier transform (for non-periodic functions with finite energy).
EDIT: I just remembered we don't even need to inconvenience the companion matrix. If ω is a n-th root of unit, and you have a vector which is [1, ω, ..., ω^{n-1}] and you multiply it by ω, you get [ω, ..., ω^{n-1}, 1] (because ωω^{n-1} = 1), which is exactly the original vector shifted by 1, so it is an eigenvector of S.
In the early 90's, Apple had big plans for end-user programming. Larry Tesler, the head of Apple's Advanced Technology Group, gathered people from ATG and elsewhere at Apple who were working on aspects of end-user programming for a project code-named Family Farm. The idea was that most of the pieces that were needed for end-user programming were already working or close, and that with a few months of work they could integrate them and finish the job.
The project sputtered when (1) it became clear that it was going to take more than a few months, and (2) Tesler was largely absent after he turned his attention to trying to save the Newton project.
AppleScript was spun out of the Family Farm project, and William Cook's paper [1][pdf] includes some of the history, including its relationship to Family Farm and HyperTalk, HyperCard's scripting language.
AppleScript shifted the focus from creating something that end users without previous programming experience could easily use to application integration. I was a writer who worked on both Family Farm and AppleScript, and I was both surprised and hugely disappointed when AppleScript was declared finished when it was obviously not suitable for ordinary users. I assumed at the time that there had been no usability testing of AppleScript with ordinary users, but Cook's paper claims there was. All this was even more disappointing in light of the fact that so much more could have been learned from the success of HyperCard and HyperTalk, and that the HyperCard developer and champion Kevin Calhoun was just around the corner.
The Wikipedia article on HyperCard [2] gives the history of the product, including the pettiness of Steve Jobs in cancelling it.
That comment is not the reason for the function’s existence, but the details of how the function interacts with GC.
The reason for the function’s existence is that it allows typed arrays to dynamically switch between a fast/compact representation for the case that the JSVM owns the data, and a slightly slower and slightly less compact version for when the JSVM allows native code to share ownership of the data.
This function, slowDownAndWasteMemory, switches to the less efficient version that allows aliasing with native code.
Of course the name is sarcastic. The actual effect of having this is that JSC can handle both the owned case and the aliased case, and get a small will if you’re in the owned case while being able to switch to the aliased case at any time. Since there’s no way to support the aliased case without some slightly higher memory/time usage, we are sort of literally slowing down and wasting memory when we go aliased.
Source: I’m pretty sure I wrote most of this code.
LLC's are state inventions, and thus vary quite a bit, but one standard feature is that you can't be liable for more than you put in. Thus they are shielded from any excess liability beyond their investment. This is true of c-corps today for sure.
However, on top of that, they usually have almost no formalities or regulations, making piercing the corporate veil incredibly difficult.
C-corps have limited liability (now), but piercing is much easier for bad acts, and they have lots of regulation and formality (historically) that helped prevent bad acts in the first place.
The LLC changed a lot here - you could form businesses basically structured any way you want, with almost no regulations, and still not be liable. Outside of constructing an LLC to do totally illegal things (like rob banks or something), you and your shareholders are pretty much never liable.
That is definitely not true of C-corps, and was even less true historically :)
For limited liability in general:
General forms of limited liability are about 100-150 years old, depending on country.
IE before 1850, it was pretty rare. I believe new york has an earlier statute, but it was uncommon.
LLC's are not corporations, either, under most state law, they are special forms of companies.
The alternative mind you, was sometimes double liability for shareholders, who both lost their investments, and had to pay for excess loss.
I'm actually okay with that - it's a good way to ensure better diligence and less risk.
It's true that LLC's enabled innovation that would have been slower, but at a tremendous cost - enabling almost any risk to be taken for free is to me, a lot worse than slower innovation. It also lead to totally perverse things (toxic dumping, etc) and shareholders didn't worry or care because at most they lost some of their investment, and most of the time, could easily pull it out before the shares dropped, and move on to investing in the next horrible thing. In the old world, they would have been responsible for the entire cost, even if they pulled out.
Limited liability is a bad idea as long as people can do horrible things to each other and the world faster than you can (or should) make them strictly illegal.
People can always think of horribly destructive ways to make money, and ensuring not just personal, but shareholder liability for them, is one of the only ways to keep things in check.
These things would happen a lot less if the ROI was not as high, and in particular, if downside risk was not minimal.
Your friendly billionaire is going to invest a lot less in arms dealers if the downside risk is not just their 1 million investment, but their entire fortune.
Being technically better is usually not a good enough reason to be incompatible.
I'm not sure why people don't get this, but it is almost always true.
Starting from scratch, just because you can theoretically design a better system, is one of the worst thing to do to users. Theoretically better also rarely wins in the marketplace anyway.
If you want a slightly lighter position:
Software needs to be built to be migrated from and to, as a base level requirement. Those communities that do this tend end up with happy users who don't spend lots of toil trying to keep up. This is true regardless of whether the new thing is compatible with the old - if it doesn't take any energy or time, and just works, people care less what you change.
Yes, it is hard. yes, there are choices you make sometimes that burn you down the road. That is 100% guaranteed to happen. So make software that enable change to occur.
The overall the amount of developer toil and waste created en masse by people who think they are making something "better", usually with no before/after data (or at best, small useless metrics sampled from a very small group), almost always vastly dwarfs all improvement that occurs as a result.
If you want to spend time helping developers/users, then understand where they spend their time, not where you spend your time.
I coined the term "Xenoserver" back in 1999, for a paper in IEEE HotOS proposing an architecture for allowing systems in core networks to safely accept and execute code from untrusted users (for a fee, of course!): https://www.cl.cam.ac.uk/research/srg/netos/papers/1999-hoto...
I was inspired by the word "xenos" (meaning both stranger and guest, or in combination a stranger who you invited into your home) rather than the word "xenia" for the general concept of hospitality extended to such a stranger [EDIT: since I wasn't familiar with the word "xenia"].
The Xenoserver project at Cambridge University developed this idea, and eventually focused around the hypervisor, which took on the name Xen.
There are many many games that embody small parts of economic theory, but few that bother with a "full" simulation. I'd suspect it's a little too fragile to guarantee a fun gameplay (as in, many logical economic outcomes might not be thrilling to simulate). Here's some notables off the top of my head though:
- Food Chain Magnate - interesting recent game that explores some aspects of pricing, marketing, and management structure. A lot is abstracted away, but it does a great job of creating strategic depth off of a few basic tenets.
- Container - cutthroat pricing and resource delivery game about shipping/manufacturing companies. Players must sell to each other and cooperate somewhat to keep the economy viable. One of the harder simulations I've seen; the market definitely can crash or stall in this game, which some people complain about but I find very interesting.
- Stockpile - very basic game about information in the stock market, but handles the ideas quite elegantly.
- Power Grid - one of the best-known and highest-rated of realistic auction games, also features a resource market. To me, Power Grid is most notable as an economic game on a meta level: it's spawned many different maps and expansions and each one plays differently, usually only based on small tweaks to the power plants available or the arrangement of the network or 1 or 2 rules twists.
- "18XX games" - this is an entire genre of "train games" that are generally about building rail lines in the early days or railroad expansion, but often include additional "hard" economic aspects, like the ownership and valuation of stock in the companies (some of them even grant most of the traditional player agency to the companies themselves, and then control is inherited by the majority shareholder, so depending on stock, 1 player could control multiple companies and another could control none). I'm just starting to play these games so I can't give much more detail yet but they are definitely worth looking into.
- Acquire - a downright classic game about mergers and acquisitions between hotel / real estate companies.
- Modern Art - another classic about emergent value in the art industry; very simple design begats complex play.
There's also a whole slate of more generic eurogames that breach into interesting economic areas, Brass, Panamax, Arkwright, and Kanban are some jumping off points there. Even less economic-themed games breach many cool concepts; certainly whenever I play my favorite game, Keyflower, I'm thinking about how to value actions over goods and how the global value of the different currencies (meeple colors) is fluctuating and how much game-end wealth delta an early denial to my opponent is worth to me...
It's really not possible to dispute that the Supreme Court just tells police what magic words they need to include in their reports to make unconstitutional searches constitutional.
In Terry v Ohio [0], a plainclothes policeman saw three guys casing a store, saw the outlines of concealed items that he believed to be guns, he stopped and searched them on that basis, and two of the three guys had weapons. The Court ruled that the evidence was admissible and the officer's "reasonable suspicion" made the search lawful, as the officer's safety may be endangered if they're questioning individuals with weapons. Without a reasonable suspicion that an individual has a concealed weapon, though, the frisk is an unconstitutional 4A violation.
In this NY Civil Liberties Union study of stop and frisk data [1], going through NYPD stop and frisk data, from 2003 to 2013, 2585945 frisks were performed but weapons were only found in ~2% (!!!) of frisks. If your suspicions are wrong 98% of the time, it's pretty hard to describe the suspicion as "reasonable", but the SC declared that asserting reasonable suspicion is all it takes to make those unconstitutional searches constitutional.
I'm not anti police, I'm a homicide researcher in Chicago and I have immense respect for a number of the officers and detectives I've worked with. But I can't look at these facts and then pretend they don't exist.
I'm not going to bother with the conspiratorial bits beyond to say that Machines as the Measure of Men is a book you might find interesting to engage with. The precolumbian Americas are a fundamentally alien continent that evolved separately from Eurasia. Europeans, explorers and scholars alike, had fundamental misunderstandings of how differently societies can evolve and judged them by how similar they were to European societies. Not surprisingly, entirely alien societies evolved a bit differently and get misjudged harshly on that mistaken basis.
However, to engage with your position in good faith, it's worth going through the sorts of things Indigenous American societies were incredibly advanced at. Let's talk list some fun facts about American urbanism:
* Teotihuacan during its heyday was one of the largest cities on earth.
* Some modern cities like Tucson have continuous urban habitation stretching back to before the founding of Rome.
* Tenochtitlan was equal to or larger in size than any city of Western Europe at the time of contact. Other cities like Cusco were merely "extremely large" by European standards.
* The Valley of Mexico at contact was one of the most densely populated and urbanized regions on earth, far exceeding anything in Europe at the time.
* One of the largest residential structures at approximately the size of the modern Kremlin is Pueblo Bonito in modern New Mexico. By room numbers (though not sheer area), later Rio Grande pueblos would rival Versailles.
* Parts of modern Chandler and Mesa, AZ, as well as most of Southwestern Colorado have approximately the same population density today as in precolumbian times.
As an archaeologist I don't think any of these are particularly meaningful metrics (or that comparative work is all that useful), they're just fun. I could probably go longer with other areas and facts, but it gets boring quickly. More meaningful would be discussions of agricultural intensity or resource efficiency or systemic resilience. American societies were phenomenally competitive on these sorts of metrics. They constructed the largest irrigation networks in the world, achieved per-acre calorie densities that wouldn't be seen again until fertilizer and intensive automation were invented in the 1950s, and practiced agriculture in some of the most arid locations on the planet, where Eurasians never succeeded.
In desperation I turned to Mechanical Turk to have the labels redone as bounding boxes, with some amount of agreement between labelers. Even then, results were so-so, with many workers making essentially random labels. I had to take another pass, flipping rapidly through thousands of frames with low confidence scores, which gave me nausea not unlike seasickness.