https://youtu.be/_qaKkHuHYE0 (CppCon) A senior software engineer at Google tried to optimize tcmalloc by replacing a mutex with lockless MPMC queue. After many bugs and tears, the result is not statistically significant in production systems.
KCP uses a brute force congestion control algorithm that is unfair and inefficient. It is also poorly specified, which is probably why it is less commonly used outside circumvention circles.
What really happened is that China hacked Google, and it pissed Google off when they finally discovered it, many months later. This wasn’t some small intrusion or data breach. It was a systemic, coordinated, widespread, very deep hack, which among other things, gave China all of Google’s source code. It was very similar in scope and ambition to the Solar Winds hack recently out of Russia. It forced Google to completely rethink their security, which at the time was an Igloo model (hard on the outside, soft on the inside, a Gary Larson reference I think), and they had to migrate to where internal access was also limited, which took years.
I’ll share with you, confidentially wink wink, that most companies way overvalue their source code. It’s actually their engineers who are their biggest asset, because the engineers can reproduce the source code if it’s lost (quite quickly at that), whereas the source code can’t do fuck-all on its own. Moreover, most source code bases are so ugly that you couldn’t give them away. But Google had what they now call “HIP” (High-value Intellectual Property) scattered through their source code, which are the tuning parameters and constants for various algorithms and AI models which are the true Secret Sauce to Google’s Search and Ads dominance.
Sure, it's common to have it working for a long time, because breaking changes and interactions between different systems occur very infrequently at the level of bootloader and firmware, but when it happens it can easily get into very difficult support situation. Logistically speaking, firmware is not a nice place to play around. It's not well coded, not well tested, and rarely "used" by an end user.
For one I wouldn't put great confidence in a script to manipulate UEFI boot entries, because it is not idempotent and there are precedents to brick the UEFI with unexpected sequence of interaction. Also Windows' reboot options and its annual upgrade tend to mess with the boot variables. I had to help repair colleagues' laptops that had Grub's boot entries erased by Windows upgrades.
I have used EFISTUB for 10 years but I wouldn't recommend it for the next install. The bootloader is the one arcane place that you don't want to be clever with and get reminded of its presence daily, because once it fails for some reason, it wastes much more time to find and read docs and diagnose than the time saved in boot speedup, because the knowledge to debug it is not something you would remember everyday. And this setup is even rarer than Grub, so any failure cases will not have help from cached knowledge and thus require much more research from first principle. Some backup options here would help in case, even if they impose some tax in boot speed. (If Grub takes a tax of 3 seconds per boot, and if a failure in EFISTUB takes 1 hour to resolve, it takes 1200 boots for EFISTUB to be worth the risk, which is 3 years if it's a laptop booting once per day, and much longer for a desktop.)
Once my desktop using the EFISTUB setup had a kernel that failed to boot, stuck at some filesystem error. Then I had to come up with a rescue plan at the spot, because there was no other way to boot into the desktop and there was no tutorial to help with this at the time.
The issues of EFISTUB:
- It doesn't interact with kernel updates nicely. I used a script in /etc/kernel/postinst.d to copy /vmlinuz to \EFI\debian\vmlinuz.efi. There is no rollback, and no multiple kernels.
- It doesn't work well with kernel parameters. The parameters are encoded in UEFI NVRAM. You have to create separate entries for different kernel parameters, or manipulate the NVRAM back and forth with efibootmgr, which is another gun that easily shoots the foot (you can easily mess up the bootorder variable).
- It doesn't play nicely with Windows and Secure Boot.
OK, maybe "Turing test" was a bad hint because too often its extension turns into a philosophical rabbit hole of defining intelligence.
I want to get back to your initial statement about uncovering and structures, which I think is still grounded in the empirical realm. I think a less ambitious new test could be about the "uncovering" between analog data and the structures. To be real uncovering, the structures must be symbolic, not just transformed analog representation, and the symbolic structures must be useful, e.g. provide radical reduction of computational complexity compared to equivalent computation with analog data.
The point is to test if the machine can make the right abstraction (real uncovering) and also connect the abstraction with the data, not just games with words.
The Heideggerian point is a start, but I don't think it's enough to just point out a failure like this. This allegation is something like "The answer is already encoded in the question" like of trick, similar to one played in Foucault's episteme, where science itself is always-already a social construction without which it is impossible to happen.
The trick is challenging on first sight but it won't go very far, because it just tells us what ML lacks but doesn't tell us what ML can have and how to go there. We need a new kind of Turing test that actually reflects the power of human intellect.
Human can't visualize a tesseract, but human can conceptualize the Idea of a tesseract in the symbolic space, by math, physics, or in other words, by Reason.
The Symbolic is a radically simplification of all the complexities impossible to be fully sensible. Even though the simplification is always particular, contingent, and full of ambiguity (human languages) and often inaccuracy (Newton's laws vs relativity), without the simplification, without Reason, ML systems are probably like animals, eventually succumbing to the full force of the complexity of reality.
Plenty of RL systems learn to play video games just fine without fine-tuned rewards, but I see this line of thought isn't actually what you're getting at.
I would assume serious ML people would not be overly ambitious and overstep their claims beyond empirical realms. You were saying ML "uncovers latent representational structure not present in the data", but I would guess the claim, if that is what you're going against, is merely that the latent structures exist, and no Truth is really "uncovered" by ML per se, in the Heideggerian sense.
I agree ML hasn't really produced an Understanding of the world. The carving along the joints is in other words a symbolic abstraction of the world that is a radical simplification, for which only Reason is capable of, and ML hasn't shown to be capable of Reason. As an aside, I also would not assume the ambiguity you refer to can be fully eliminated even by human intelligence, just see how languages are fully of ambiguity, or even quantum mechanics.
But again, when philosophical critiques are launched against ML, the usual story is ML advocates would retreat to the success of ML in the empirical realms. I'm reminded of the Norvig vs Chomsky debate by this.
These are all unified as different modes of message passing in probabilistic graphical models. Kalman filters are indeed structurally similar to an HMM without the backward message passing step if viewed as a PGM.
I find Yanis Varoufakis' account of the history leading up to the collapse of Bretton Woods very telling:
As the combined costs of the Vietnam War and the Great Society began to mount, the government was forced to generate mountains of US government debt. By the end of the 1960s, many governments began to worry that their own position, which was interlocked with the dollar in the context of the Bretton Woods system, was being undermined. By early 1971, liabilities in dollars exceeded $70 billion when the US government possessed only $12 billion of gold with which to back them up.
The increasing quantity of dollars was flooding world markets, giving rise to inflationary pressures in places like France and Britain. European governments were forced to increase the quantity of their own currencies in order to keep their exchange rate with the dollar constant, as stipulated by the Bretton Woods system. This is the basis for the European charge against the United States that, by pursuing the Vietnam War, it was exporting inflation to the rest of the world.
Beyond mere inflationary concerns, the Europeans and the Japanese feared that the build-up of dollars, against the backdrop of a constant US gold stock, might spark off a run on the dollar which might then force the United States to drop its standing commitment to swapping an ounce of gold for $35, in which case their stored dollars would devalue, eating into their national ‘savings’.
The flaw in the Global Plan was intimately connected to what Valery Giscard d’Estaing, President de Gaulle’s finance minister at the time, called the dollar’s exorbitant privilege: The United States’ unique privilege to print money at will without any global institutionalised constraints. De Gaulle and other European allies (plus various governments of oil producing countries whose oil exports were denominated in dollars) accused the Unites States of building its imperial reach on borrowed money that undermined their countries’ prospects. What they failed to add was that the whole point of the Global Plan was to revolve around a surplus generating United States. When America turned into a deficit nation, the Global Plan could not avoid going into a vicious tail spin.
On 29th November 1967, the British government devalued the pound sterling by 14%, well outside the Bretton Woods 1% limit, triggering a crisis and forcing the United States government to use up to 20% of its entire gold reserves to defend the $35 per ounce of gold peg. On 16th March 1968, representatives of the G7’s Central Banks met to hammer out a compromise. They came to a curious agreement which, on the one hand, retained the official peg of $35 an ounce while, on the other hand, left room for speculators to trade gold at market prices.
Can you comment on the tradeoffs between indirect TOF (phase) and direct TOF (time), what made Apple opt for direct TOF here, is it Microsoft's patents?
I stopped using it for locals after it increased my mental load. The maintenance cost of const for all local variables is huge during refactor like you're fighting it just to get things done. And in most cases where the type of a variable matters I do have to glance around like when I need to remove a variable or change its type or refactor its dependent variables so const doesn't really for those cases.
Folds are not complicated. They are just not familiar to the intended readers.
The changed version is idiomatic in image processing or similar areas that deal with pixels. Being idiomatic makes it familiar to read, and easy to change.
If you as a reader need const to make sure a local variable is not changed this is usually a symptom of this function being too long to see at a glance. And quite often as code changes I do need to make some local variable non-const, and it quickly becomes annoying to fiddle back and forth enforcing const-ness of every local variable.
The argument about optimization is almost certainly premature optimization. Most of the time how you write a loop doesn't matter. You only find out what matters via profiling and refactor accordingly.
Local consts are not particularly useful, especially for things like ints. Compilers know it's const, and a reader doesn't need to worry about it in a local scope.
width, height usually come in pairs, so putting them on the same line is usual.
nPixels and nBytes are not used more than once so they are not useful abstractions, and the pattern of `width * height * bytes_per_pixel` is so common that there is no ambiguity about what it does.
The idx lambda is probably a distracting abstraction which requires the reader to think of it in a different context than the immediate what pixel goes to where. Again, the pixel moving pattern in the right is so common it's familiar to most people working in similar areas, and in terms of error-prone both are not better than the other.
Is it correct to think of it as application code running as PID 1 in kernel space? Can I fork or create threads? Can I directly access kernel's internal APIs like a kernel module?