> Microsoft using copilot to license-launder the github corpus
Isn’t the game with licenses that you must specify what can and cannot be done with the code? It’s a big issue that no one prior to now had the foresight to forbid ML training on code without attribution. If the licenses going back 30 years had that stipulation then it would be easy to take down Copilot and ChatGPT. But the licenses simply don’t cover the use case of training a neural net, so it’s probably going to slip through the cracks just like SaaS slipped through the cracks of the GPL by not distributing code, hence the need for AGPL. So I’m sure we’ll see these kinds of clauses added to licenses going forward, but they can’t be applied retroactively.
The irony in all this is that from the start, open source licensing has been a game of wits where software creators try to cleverly use copyright as a lever of control. Well, they weren’t clever enough. They missed ML training and didn’t forbid it. As a result they’ve basically lost the whole game.
> Isn’t the game with licenses that you must specify what can and cannot be done with the code?
No, not at all. Microsoft's argument is that training an LLM on code is fair use, and thus doesn't trigger copyright-based licensing at all. That's why they include unlicensed code in Copilot, which under a training-triggers-copyright theory they have no right to at all.
Ads are unwanted. If you serve ads, you are doing something unwanted to your visitors. So they block the ads, and you get the unwanted effect of not making money. The pain point is not that your ads are being blocked — it’s that you don’t have a way to make money that doesn’t start with doing something unwanted.
It's the way ads are delivered that is unwanted. I would not care about a static inline banner ad at the top of a page. Slightly possible that I'm interested in it if it's relevant in the context of the page, easy to ignore if not.
The ads that pop up when I scroll, or ads between every paragraph (or more) or ads that are animated or use fancy CSS to overlay the main content or slide in from the side and float around -- those are what make me run an adblocker.
This is also what drives people into cults: not fitting into normal social environments, finding some esoteric community where suddenly there is a fit.
Nothing you said is truth. Those are just your own blind beliefs. How do you know the universe is meaningless? Maybe it’s a simulation being run for a purpose, and the beings running it care about the outcome. You’re just spouting YOUR truth, which is not truth at all.
> Maybe it’s a simulation being run for a purpose, and the beings running it care about the outcome.
This sounds an awful lot like a higher being who sits in judgement of their creation; and something that humanity seems to reach for very quickly. I was taught something similar as a child, but lost the belief when I was still quite young. I'd love to believe in a higher power or purpose because nihilism is quite a terrible experience. I often wonder if I'm just wired differently so in some way unable to believe things as others are or if a lifetime of chronic pain has revealed things to me that most people do not learn until they are older.
It’s hubris to think we can know anything about the reason for the existence of the universe. But just because we can’t know doesn’t mean there is no reason, that line of thinking is just hubris in the other direction.
I just want to make a comment about optimizing applications even though the article is about optimizing organizations:
The way to arrive at the optimal system is to continually optimize all individual components as the system develops. You have to walk the razor’s edge between “premature optimization is the root of all evil” and not optimizing anything until it’s too late and a bunch of bad design decisions have been baked in.
If you want to write the fastest program, profile its performance from the start and try different ways of doing things at each step of the process. There’s usually a way of doing things that maximizes simplicity and performance at the same time because maximum performance == doing as little work as possible to complete a task. Chances are that ‘littlest amount of work’ will be elegant.
Usually "optimisation" is something that happens once a slow part of the system has been identified. So you develop data and expose the problem with a profiler and fix a few things that seem to be holding it up and then find the next stage of bottlenecks. You keep doing this until you meet your performance goal or you can't improve it any further and determine a completely different approach is required.
Personally I prefer to recognise those components ahead of time and think about performance and do experiments to start from an architecture that has a better chance of succeeding in its performance goals from the outset. So I tend to agree with the article that its much more effective to optimise at the architecture than the individual components but its also much harder to do that once the thing is built and working already and the same is likely true for a lot of organisations as well. Once organisational culture has been set its hard to fix it.
Finding and fixing the one and only source of poor performance is a minority of optimizations. The more common case is a lot of suboptimal code creating poor performance.
Ehhh this isn’t quite the right takeaway, or at least it’s contrary to Deming’s approach.
The key insight from Deming’s work is that at any given moment there is only and exactly ONE thing that should be optimized. Once you optimize that, there will be a new SINGLE thing that is now slowing down the entire system, and must be optimized.
The goal of an engineer of a system (or manager of an org) is to develop a method to repeatedly identify and improve each new bottleneck as it appears, and to ignore other components even if they’re apparently not performing as well as they could.
That is what everyone currently and we know the results, that only takes you from horribly slow to very slow.
In order to have a chance to get anywhere close to fast you need each component to already be very fast, and then you can build a fast system on top of those. When you work with slow components you wont use the right architecture for the system, instead you start working around the slowness of each component and you end up with a very slow mess.
Example: A function call is slow, it calls a thousand different things so you speed this up by putting a cache in front, great! But now this cache slows down the system, instead you could have sped up the function calls execution time by optimizing/trimming down those thousand things it calls.
Adding that cache there made you get further away from a fast system than you were before, not closer. One cache is negligible, but imagine every function creating a new cache, that would be very slow and basically impossible to fix without rewriting the whole thing.
"Everyone knows this" yet you don't actually see organizations work like this almost ever in practice. Especially not software organizations. Instead you see big splashy initiatives to "overhaul performance" or whatever.
There is definitionally no more efficient way to improve the performance of a system than sequentially targeting each new bottleneck in its performance and nothing else.
Your example is just a case of picking a non-ideal method to improve a bottleneck. It's a lot easier to get this right when you're focusing on one important problem instead of generally "optimizing everything," which produces a clear incentive to take easy, immediately available, probably-not-ideal solutions all over the place.
> There is definitionally no more efficient way to improve the performance of a system than sequentially targeting each new bottleneck in its performance and nothing else.
You are making an extremely strong statement here, how do you define "bottleneck" for this to be true? Many slow systems doesn't have bottlenecks, they are just slow overall with no bottlenecks.
And this is the key insight that "everyone knows" and you apparently do not: every system has exactly one bottleneck at any given point in time. The bottleneck can move, alternate, or not be so significant relative to other near-bottlenecks that it's hard to spot, but there is exactly one.
Your perception that "there are no bottlenecks" is exactly the perception Deming set out to disprove.
Riddle me this: how can a system perform faster than its single slowest component?
It cannot. Ergo, there is a single bottleneck that sets the pace of the entire system.
> every system has exactly one bottleneck at any given point in time.
Consider this system that has 5 sequential steps with these durations:
Step 1: 10 seconds
Step 2: 5 hours
Step 3: 7 seconds
Step 4: 5 hours
Step 5: 18 seconds
It would seem that both step 2 and step 4 are both bottlenecks. Are you saying that in reality one of those 2 steps would not typically be the exact duration so one of them would be considered the actual bottleneck?
In this example, assuming sequential steps, if step 2 must be performed before step 4, then it is step 2 which is the bottleneck.
After step 2 has been optimized, step 4 becomes the new bottleneck—assuming that optimization of step 2 is satisfactory.
While both steps 2 and 4 contribute to a slow system, a bottleneck means something else entirely: it is the single most significant point of slow down for the rest of the process.
To put it another way, it’s hindering the overall execution. If both use the same amount of time, then whichever is closer to the front of the process is by definition hindering more of the process.
> every system has exactly one bottleneck at any given point in time
What, no they don't. Does a straight glass have a bottleneck? No, most bottles have it, but not straight glasses, hence not every system has a bottleneck.
The same applies to IT systems, there the topology is much more complex so often can have many bottlenecks, or sometimes fewer etc.
> Riddle me this: how can a system perform faster than its single slowest component?
A perfectly optimized component can't be a bottleneck but can still be the slowest component, trying to optimize that further will not speed up the system at all.
Here we see that you will miss a lot of optimization opportunities since you think the slowest component is the bottleneck, and not looking further.
I don't find the glass <> IT system analogy compelling (or even sensical) at all.
Describe to me how an IT system can produce results (e.g. tickets closed, if you wish) at a rate higher than the processing rate of the slowest component.
> A perfectly optimized component can't be a bottleneck but can still be the slowest component, trying to optimize that further will not speed up the system at all.
Correct -- but neither will optimizing anything else! That's the whole point!
> Describe to me how an IT system can produce results (e.g. tickets closed, if you wish) at a rate higher than the processing rate of the slowest component.
It can't, but the slowest component can be perfectly optimized and thus not be a bottleneck. You would fail to find a real bottleneck in this case, since you are just looking for the slowest one, hence I have proven that your statement above was false, there are cases where the optimal strategy is not to just look at the slowest component.
If you have some other definition for bottleneck we can continue, but this "the slowest component" is not a good definition.
No, what you've done is you've failed to find a way to improve the system's behavior further. If you have the slowest component and you can't make it faster, then congrats: you cannot make the system faster.
You cannot build cars faster than you can mine metal, nor faster than you can put stickers on the windows on their way out the factory. You are done optimizing.
That is only true for parallel executions, not serial ones. If a process requires executing many components serially (which happens a ton), then it isn't enough to just look at the slowest component.
Anyway, thanks, now we know that you only considered throughput in a factory like setting, there it is true. But your rule there isn't true for software systems in general, optimizing latency speeds and serial performance is extremely common in software.
Edit: Example:
Machine A takes 1 hour -> B 2 hours : System takes 3 hours.
Machine A takes 0.5 hour -> B 2 hours : System takes 2.5 hours, so faster even though we optimized the faster component.
The example I gave was a serial process. And in fact, every parallel process is just a group of serial processes. Factories are obviously linear but in reality every single process is linear through time, including the chaotic, complex ones you see in IT or software orgs. (Unless you have a time machine, in which case ignore me)
Fastest/slowest doesn't mean "takes the longest in clock time," it means "has the lowest throughput."
In your example, if B is only able to produce something every 2 hours, then no, speeding up A will not increase the throughput. You will see a larger backlog of jobs from A waiting for B to become available. Ultimately only 0.5 units per hour will be produced by this process.
If B is able to produce more than something every 2 hours, e.g. it can produce multiple things in parallel, then yes, speeding up A will increase throughput. But that is only because B wasn't the bottleneck to begin with! Your own failure to serialize that parallel process hid that fact from you.
Either of your systems (unless you have invisible parallelism in B) will produce 0.5 units per hour.
If you're saying to yourself, "well this is a process that runs only once per day, so there's no backlog anywhere in here," then congrats: you've just discovered that the true constraint sits upstream of A!
Speeding this up might be a nice quality of life improvement for the people involved, but it will not yield different outcomes for the system as a whole, because there's not enough work coming into A to consume the capacity of B anyway.
Your entire argument is about throughput in sequential pipelines or parallel systems. On systems not shared with other independent tasks.
Yes, in those simple cases there is one bottleneck at any given time.
But most tasks do not fit those conditions, and economically and technically are best optimized reflecting other objectives than just throughput.
Many times parallel or sequential pipelined groups of tasks have optional subtasks, so there will be as many bottlenecks as there are components that may run while others don’t.
Many tasks run intermittently, or for resource reasons, need to run as an uninterrupted sequence, with no opportunity to pipeline, and are optimized for latency. Which means any speed up of any subtask has value.
Many systems run multiple independent tasks to maximize return on resource costs, and so tasks are optimized to minimize active computational time. And any speed up of anything can improve that.
In all those cases, multiple modules can be usefully optimized at any given time.
And many factors can be relevant to making that choice. Such as relative benefit of optimization vs. time to achieve the optimization, cost of making the optimization, and project risk, all come into play.
In practical reality, there is a long tail of such factors. For instance, the skill and interest levels of available developers, relative to the module optimization options.
> There is definitionally no more efficient way to improve the performance of a system than sequentially targeting each new bottleneck in its performance and nothing else.
Doing so misses any state you can't hit via small iterations (you'll find a local minimum rather than global). It's easy to whack-a-mole every performance bug you can find and still miss that swapping to a columnar representation or using 32-bit keys instead of 64-bit is all you need to double performance for your program. Or that, in effect, the big ball of classes are executing something quadratic when linear solutions exist, but since that degredation isn't isolated to a small unit of code you can't identify it.
Doing so, even when you _can_ iterate to the global minimum, isn't guaranteed to be the most efficient path either. Imagine, e.g., speeding up foo (the slowest thing [0]), then speeding up bar (the next slowest thing), and finding in your refactor of bar that you no longer need foo. All the optimizations that went into foo were wasted.
In practice, I've had a lot of success using "lines of code deleted" as an initial north star. Rather than trying to optimize from the get-go, focus on changes which remove a bunch of code, or better yet make it easier to remove even more code in the near future. Once you've trimmed it down 5-10x [1], it's probably already faster and less buggy, but at that point the task of actually optimizing is much easier. I don't know that doing so is the most efficient solution per se, but whack-a-mole performance fixes I think are usually worse.
[0] If bar calls foo, then obviously bar is actually slower than foo (ignoring mutual recursion), but you have to pick a small enough unit to optimize; it's not very helpful to note that main() is your longest-running function call. In a real refactor you very well might have the foo->bar sequencing e.g. by seeing that the majority of bar's time is spent calling foo, thus concluding that foo is the "culprit" or otherwise has some low-hanging fruit.
[1] Almost all software I've seen has a tendency to accumulate cruft over time. That isn't a criticism of any individual's abilities, just an observation that the march toward new features tends to invalidate previous assumptions and degrade the project's code quality over time. Moreover, the act of running the previous version teaches things you didn't know when that previous version was written, allowing even the same author to make better informed decisions. If/when somebody decides performance is important, there's almost always an opportunity to delete a ton of code.
> Doing so misses any state you can't hit via small iterations (you'll find a local minimum rather than global).
When I worked in manufacturing, we distinguished between “continuous improvement,” which were these smaller improvements that will get you to a local minimum, and “radical transformation,” which will get you significant improvements and requires redesign of the entire system.
> Doing so misses any state you can't hit via small iterations
Nothing about this method of problem identification requires small or local improvements to fix issues. In fact it makes it much easier to justify larger scale changes because you can have confidence in the impact it'll have on your total output.
But removing the cache makes the system slower, it didn't optimize anything. So no, fixing this isn't possible with that approach, you need to take the holistic approach.
There's nothing about identifying and solving one problem at a time that prevents one from taking a holistic approach.
In fact the entire point is to interpret the behavior of the entire system in order to find the right singular intervention. To find the true globally optimal point of intervention, one must look at the entirety of the system.
If you are saying that your method includes all methods, then sure being open to consider all methods of making something faster will include the best way to do it. But I thought were were talking about useful advice here, to be useful you have to narrow it down a bit.
> The key insight from Deming’s work is that at any given moment there is only and exactly ONE thing that should be optimized. Once you optimize that, there will be a new SINGLE thing that is now slowing down the entire system, and must be optimized.
Are you sure this is what Deming thought?
A complex system has many different things that can be locally optimized independently, here's an example:
1-DC picking optimization
2-Store inventory placement to align with demand to both increase sales and decrease costs of liquidating old inventory
Both of these have very significant impact on costs or revenue or both, and are largely independent. The process of picking in the DC is independent of the specific selection and inventory levels of skus in the stores.
Why would you not do both at the same time to get the benefits as quickly as possible?
The infinite scrolling of the same images over and over again makes it harder to use. You can’t tell how many results you’ve actually received and what they are.
The value of ARM is that anyone with enough money can license Arm cores and incorporate them in their own products, which can be optimized for some custom applications.
The level of customization possible with an x86 CPU is much less. You must buy a complete computer board or module and incorporate it in your product.
While for custom applications it is easy to create a superior solution with Arm cores, for general-purpose computers it is hard to compete with the Intel and AMD CPUs. All the computers with Arm cores have worse performance per dollar than similar x86 computers. (For instance there was recently a thread on HN about a credit-card-sized computer with an Intel N100 CPU and with the same price or lower as a Raspberry Pi, but with a much higher performance.)
AMD does offer custom x86 - see the steam deck, surface laptops and Xbox and PS4 and 5. Given there aren't a ton of small fish making custom parts they are excellent at what they are made for.
AMD is pushing x86 to Apple ARM levels that keep power use low enough (best I've seen is 16 hour battery life on a device - I think MacBooks best this still) but performance per watt I haven't seen ARM really top charts. They are awesome and I want arm and risc-v to really shine in laptops but the only player on the PC side is Qualcomm who was told to destroy their only flagship by ARM.
These sorts of processors are available from Intel as well (if anything, more available, as you can buy low-end 5w processors with modern e-cores in them, eg. N95/N97). The commenter above is referring to these, and they are common in Mini-Pcs with 8-16GB of RAM and cost <200USD. These sorts of processors crush the ARM competition at the same level right now (ie. the pi).
In fact, AMD doesn't seem to have anything in the same segment currently, although they do exist in the higher tiers alongside Intel with their laptop processors.
There have been tons of proprietary CPU architectures with the same power efficiency as Arm. Only the x86 architecture is an outlier that requires an unusually complicated instruction decoder, which may degrade a little the energy efficiency.
Arm has eliminated most of the competing CPU architectures not by providing better power or energy efficiency, but by its business model of being licensable to anyone.
The ARM ISA was somewhat better than MIPS and SPARC, both of which have been handicapped by including some experimental features that have been later proved to be bad ideas. However there have been many other RISC ISAs more or less equivalent with ARM. Only the business model has extracted ARM from the crowd, not its technical advantages.
Arm "specifically went after low-power applications" only in comparison with x86 or in comparison with a few other architectures restricted to workstations and servers, like DEC Alpha or Intel Itanium.
Before 2000, there were at least a dozen CPU architectures that went for the same low-power applications as Arm. There were a lot of microcontroller or processor vendors and each one of them had at least one proprietary ISA, if not 2 or 3 or even more different proprietary ISAs.
More than 20 years ago, I have redesigned various kinds of communication equipment, in order to replace many other kinds of CPUs, for example Motorola MC683xx or ColdFire or IBM PowerPC CPUs, with Arm CPUs.
In none of those cases the Arm CPUs had a lower power consumption or any other technical advantage. In fact in all cases the Arm CPUs were technically inferior to the CPUs replaced by them, which has required the implementation of various hardware and software workarounds.
There was only one reason why the Arm CPUs had been selected to replace their predecessors with different architectures, and that was the lower price. Their lower price was in great part due to the fact that there already were many competing vendors of Arm CPUs, so if you did not like one of them it was easy to replace it with another vendor.
I get it that you don’t like Arm but that doesn’t change the fact that low power was and is central to their value proposition - and this latter fact doesn’t preclude other firms having low power offerings.
It's been said many time and the correlation between ISA and power efficiency have been debunked many time. ARM is power efficient because most ARM implementation are power efficient. Right now x86 AMD strix are about on par with qualcom x elites
Agreed. That power efficiency is still a central part of the Arm value proposition though. Others are competing with real designs on this with Arm in laptops but not in - for example - smartphones.
(simplifying) ARM provides verified, tested, standardized, reasonably well designed chips (logic circuits) that your company can purchase a license for and then send that chip design / logic circuit to be etched on a wafer, cut, encapsulated, and soldered to a printed circuit board.
Those ARM CPUs support a standard (but ARM-flavored) assembly programming language. (Formally: Instruction Set Architecture)
Designing your own chip previously was risky because you might have logic or hardware bugs in your chip that were very hard to debug, and then you hope that someone will bother to write assembly code that works on your chip. Since you probably designed your own assembly language that co-evolved with your chip, those assembly code developers are going to be sinking a lot of time into understanding your chips and assembly code quirks to wring performance out of them.
RISC-V standardizes a RISC-V flavored assembly code (ISA) and also provides some certification test packages to prove that "this particular chip design" can execute the RISC-V assembly language according to specifications.
In PCs, ARM CPUs perform just as good or better than AMD64 but have much better battery life. In the cloud, ARM CPUs are much cheaper (ca. 25% less) for the same or better performance.
Not quite. I think we need to split the value of ARM the instruction from specific implementation.
1 - In term of pure efficiency, nothing magical about ARM. Looking at AMD latest strix laptop platform they are about on par with qualcomm new arm laptop chips.
Apple M* CPU are still better. However, a lot of that efficiency is platform derived.
2 - The lower cost in the cloud is a function of the middle man being removed. Amazon is selling graviton cheaper simply because they don't have to pay the markup of AMD or Intel.
The main benefit is you get a rolling two years where no one else can use your code to compete with you. It’s a lot like a patent which gives you a window of time where you have an exclusive right to benefit from your creation.
Isn’t the game with licenses that you must specify what can and cannot be done with the code? It’s a big issue that no one prior to now had the foresight to forbid ML training on code without attribution. If the licenses going back 30 years had that stipulation then it would be easy to take down Copilot and ChatGPT. But the licenses simply don’t cover the use case of training a neural net, so it’s probably going to slip through the cracks just like SaaS slipped through the cracks of the GPL by not distributing code, hence the need for AGPL. So I’m sure we’ll see these kinds of clauses added to licenses going forward, but they can’t be applied retroactively.
The irony in all this is that from the start, open source licensing has been a game of wits where software creators try to cleverly use copyright as a lever of control. Well, they weren’t clever enough. They missed ML training and didn’t forbid it. As a result they’ve basically lost the whole game.