> Quite a lot of changing the code is just useless busywork: re-wiring old functions, moving imports around, searching for locations that benefit from extracting a common piece of code.
If other people are dissatisfied with LLM output quality while it seems to work fine for you, you might want to consider that the quality of code you produce is closer to the quality of code the LLM produces than what those other people are producing.
What you posted there, for example, about most of changing code being busy work is a pretty big red flag for a codebase. One of those "large structure" things that you're supposed to be paying attention to is the architecture of the code. There's always the chance that some change you need to do goes against the grain of the solution you architected, and you need to make changes all across your codebase to fit it in, but in general the point of modularity and good architecture is that when you make a change you just have to make that one change, ideally just changing the logic of the one responsible function with only minor changes required anywhere else in the codebase. If you're consistently having to hunt throughout the code for related functions that you need to rewire that's a sign that your architecture does not fit with the direction your codebase is evolving, or alternatively that you don't have much of an architecture to begin with and your code is highly interconnected.
Actually one habit you mention at the end of that quote can worsen this issue: "searching for locations that benefit from extracting a common piece of code". Tautologically this is a good thing as you define it as only working on locations that will benefit, but given the frequent need for rewiring of functions I would hazard to guess that you've "deduplicated" code a bit overzealously. Just because two functions share some common code does not necessarily mean it is appropriate to pull that out into a function. Deduplicating is good if conceptually the code is a single thing that you would always want to keep in sync, as it means that when you need to make a change to it you don't have to hunt down all the places it's used. On the other hand, if you find yourself frequently needing to delve in to these functions to rework them because you need to make a change to how it's used by just one caller, your "deduplication" has added to your workload, and probably created some overcomplicated code in the function that is in reality handling multiple distinct needs.
I hope this doesn't come across as too condescending, and if I've just wasted your time explaining principles you already understand I apologize. I don't know you or the code you're working on so I can't exactly confidently judge your work solely on a few paragraphs. It's just that your mention of how your experience of coding has been different from what others have described, and specifically that, for you, writing has been the bottleneck rather than understanding, combined with the specific issues you describe facing, imply to me that you may not realize that the approach you are taking to producing code yourself may be significantly different from how other Software Engineers are producing code, and that may account for some of the differences you note in your personal experiences programming.
It's not exactly whizzing around at light speed in the way that you imagine if it's beneath an event horizon. The entire point of an event horizon is that everything beyond it physically cannot move outward. The horizon isn't some kind of physical barrier, it is just the farthest distance at which the black hole's gravity becomes inescapable, that doesn't stop applying just because you've moved past the horizon, and in fact it only becomes more true.
If you imagine any sphere beneath the event horizon which is centered on the singularity, that sphere is just as inescapable as the farthest such sphere which we call the event horizon.
Additionally, the event horizon is inescapable to everything. Even gravitation is transmitted at the speed of light, and cannot outrun the cascade of inwardly falling spacetime beneath the event horizon. So no possible change in the distribution of mass within a black hole could have any effect on the configuration of spacetime at the event horizon, or even on any spacetime further from the singularity than itself.
This betrays a very naive concept of "knowledge" and "understanding". It presupposes that there's some kind of platonic realm of logic and reason that an AGI just needs to tap in to. But ultimately, there can be no meaning, or reasoning, or logic, without context. Matching a pattern of shapes presupposes the concept of a shape, which presupposes a concept of spatial relationships, which presupposes a concept of 3 or even 2 dimensional space. These things only seem obvious and implicit to you because they permeate the environment that your mind spent hundreds of millions of years evolving to interpret, and then tens of years consuming and processing to understand.
The true test of an AGI is it's ability to assimilate disparate information into a coherent world-view, which is effectively what the pretraining is doing. And even then, it is likely that any intelligence capable of doing that will need to be "preloaded" with assumptions about the world it will occupy, structurally. Similar to the regions of the brain which are adept at understanding spatial relationships, or language, or interpreting our senses, etc.
I'm not sure if I missed something in the article, but it appears to me that the article does not take in to account the change in supply due to change in effective wage caused by decreased utilization. The supply of drivers available would be based on what money drivers actually take home, not just the nominal price, so any decrease in the money taken home would result in a decrease in supply, meaning the positive impact on drivers wages would be larger than that computed in the article.
At high enough energies the laws of physics are actually different. Two of the four fundamental forces in physics, the electromagnetic force and the weak interaction, are actually a single force which only appears to be two separate forces at "low" energies/temperatures, with low being the pretty much all temperatures in the universe after the Big Bang.
It is completely reasonable to test whether phenomenon that hold at low energies still hold at high energies, and that may be the only way you're going to find more fundamental physical laws. Especially when we know quantum theory is incomplete, since it is currently incompatible with general relativity.
There's a lot of discussion here in the comments on whether this can meaningfully be called a vulnerability if you can only "see the temperature of your server".
Setting aside that the vulnerability doesn't actually allow that, isn't this potentially a Spectre / Meltdown vulnerability? This is an unprotected endpoint that conditionally executes code taken from user input. If the branch predictor can be trained to speculatively execute arbitrary code from the input, information could be extracted via endpoint timing using a similar methodology to Spectre or Meltdown, right?
We don't have the rules that we want the neural network to learn, if we did we could just directly use those rules, and there would be no need for ML to solve the problem. In this case we want the ML to learn how to infer spatial information from two dimensional images, and the process that generates the data it trains on cannot do this at all. It can create two dimensional images from spatial information, which is a much simpler and effectively solved process.
There are cases when we want a machine learning model to do the same thing as the process which generate it's data, like in the case of model's learning to replicate physics simulations, but even then the entire point is for the machine learning model to accomplish the same or a similar result but in a more computationally efficient way.
I didn't mean to say the fact that the interval exists makes it uncertain, I meant to say the fact that it is a 67% spread makes it uncertain. They are saying that they have narrowed the effect down to within that spread with a 95% chance. That combined with sources of uncertainty not covered by that intervale (Listed in their limitations: missing data, variable adherence, patient-reported findings on home tests, no blinding, and of course inconclusive results) definitely make it sound pretty inconclusive.
There is also the limitation that there was "no assessment of whether masks could decrease disease transmission from mask wearers to others."
The article explicitly states "The findings, however, should not be used to conclude that a recommendation for everyone to wear masks in the community would not be effective in reducing SARS-CoV-2 infections, because the trial did not test the role of masks in source control of SARS-CoV-2 infection."
You act like this is the first time in the history of the planet a country has enacted measures to stop the spread of disease. It's not, we've done it before, and the world didn't collapse because people were inconvenienced temporarily.
Ok so you say that characterizing the results as incoonclusive results is dishonest, but in the article the limitations sections literally lists "Inconclusive results" as their first item.
On top of that they state:
"Although the difference observed was not statistically significant, the 95% CIs are compatible with a 46% reduction to a 23% increase in infection."
Which sounds like their saying they can say with 95% confidence that there is between a 46% reduction and a 21% increases, which sounds pretty damn inconclusive to me.
Where did your conclusion of "masks definitely don't work for SARS-2" come from? Just in your quote it stated that the control that cloth mask use was compared to was a population with a high proportion of mask wearing. The study does not compare cloth mask usage to no mask usage, and only says that it is possible that cloth masks are harmful.
Also if you would like some more up to date information, as well as a larger number of studied, which are specific to COVID, the CDC website has a lot of information here:
So, you linked a number of articles from early 2020, when there was not significant community spread of COVID and thus the primary strategy for dealing with it was isolating and quarantining individual cases, and most people in the country would probably not come in to contact with someone carrying COVID.
If you want to know what the WHO recommends, you need only look at their website:
"Make wearing a mask a normal part of being around other people. The appropriate use, storage and cleaning or disposal of masks are essential to make them as effective as possible."
Perhaps you could point us to what cdc website you are referring to? Because on cdc.gov wearing a multilayer cloth mask is recommended, and they cite a number of studies on the effectiveness of masks which all show significant reductions in transmissions in people and populations which where masks vs those who don't. See "Human Studies of Masking and SARS-CoV-2 Transmission" on this page:
This is a bit confusing, since a planet is defined as "a celestial body orbiting a star or stellar remnant that is massive enough to be rounded by its own gravity, is not massive enough to cause thermonuclear fusion, and has cleared its neighboring region of planetesimals.", the relevant part being "Orbiting a star or stellar remnant".
I wouldn't think it would be possible to have a freely floating planet.
If other people are dissatisfied with LLM output quality while it seems to work fine for you, you might want to consider that the quality of code you produce is closer to the quality of code the LLM produces than what those other people are producing.
What you posted there, for example, about most of changing code being busy work is a pretty big red flag for a codebase. One of those "large structure" things that you're supposed to be paying attention to is the architecture of the code. There's always the chance that some change you need to do goes against the grain of the solution you architected, and you need to make changes all across your codebase to fit it in, but in general the point of modularity and good architecture is that when you make a change you just have to make that one change, ideally just changing the logic of the one responsible function with only minor changes required anywhere else in the codebase. If you're consistently having to hunt throughout the code for related functions that you need to rewire that's a sign that your architecture does not fit with the direction your codebase is evolving, or alternatively that you don't have much of an architecture to begin with and your code is highly interconnected.
Actually one habit you mention at the end of that quote can worsen this issue: "searching for locations that benefit from extracting a common piece of code". Tautologically this is a good thing as you define it as only working on locations that will benefit, but given the frequent need for rewiring of functions I would hazard to guess that you've "deduplicated" code a bit overzealously. Just because two functions share some common code does not necessarily mean it is appropriate to pull that out into a function. Deduplicating is good if conceptually the code is a single thing that you would always want to keep in sync, as it means that when you need to make a change to it you don't have to hunt down all the places it's used. On the other hand, if you find yourself frequently needing to delve in to these functions to rework them because you need to make a change to how it's used by just one caller, your "deduplication" has added to your workload, and probably created some overcomplicated code in the function that is in reality handling multiple distinct needs.
I hope this doesn't come across as too condescending, and if I've just wasted your time explaining principles you already understand I apologize. I don't know you or the code you're working on so I can't exactly confidently judge your work solely on a few paragraphs. It's just that your mention of how your experience of coding has been different from what others have described, and specifically that, for you, writing has been the bottleneck rather than understanding, combined with the specific issues you describe facing, imply to me that you may not realize that the approach you are taking to producing code yourself may be significantly different from how other Software Engineers are producing code, and that may account for some of the differences you note in your personal experiences programming.