fix: corrected links

src/dry.md

@@ -15,4 +15,4 @@ The same thing happens with using libraries to figure out ANSI codes, handle scr
 
 In my case, the bulk of my development work is putting different concepts (libraries) together into something I think is interesting and useful. A "new" pattern is hard and requires thought, composition is much easier and where the ideas really shine. I also think that most other coders are the same way, we put together blocks.
 
-The drawback of this that we build up a tree of dependencies. In some languages, it can get very deep where a "simple" library ends up composing hundreds of other dependencies---directly or indirectly. When a [language doesn't provide a good support](./counts/), the number of indirect dependencies increases exponentially. When we have different implementations of the same thing, like logging or REST calls, then we also increase our dependencies.
+The drawback of this that we build up a tree of dependencies. In some languages, it can get very deep where a "simple" library ends up composing hundreds of other dependencies---directly or indirectly. When a [language doesn't provide a good support](./counts.md), the number of indirect dependencies increases exponentially. When we have different implementations of the same thing, like logging or REST calls, then we also increase our dependencies.

src/index.md

@@ -2,6 +2,6 @@
 
 The open-source ecosystem is huge with thousands upon thousands of developers creating billions of projects across multiple languages. Most of the time, these packages are pushed up to a centralized sites for discovery and download with no human oversight.
 
-This is the crux of the problem. As an ecosystem acquires [more packages](./counts.md) managed by [self-serve](./self-serve/) systems, there is always a risk of [a malicious developer](https://psychopathyis.org/stats/) creating a package to benefit them in some manner. It might be stealing information, protesting [current events](https://www.theregister.com/2022/03/18/protestware_javascript_node_ipc/), [making money](https://securityintelligence.com/news/popular-javascript-library-for-node-js-infected-with-malware-to-empty-bitcoin-wallets/) or simply just to destroy. But those individual packages are difficult to detect, more so when other developers are mandated with keeping packages up to date or the package itself is nested as dependency of another one.
+This is the crux of the problem. As an ecosystem acquires [more packages](./counts.md) managed by [self-serve](./self-serve.md) systems, there is always a risk of [a malicious developer](https://psychopathyis.org/stats/) creating a package to benefit them in some manner. It might be stealing information, protesting [current events](https://www.theregister.com/2022/03/18/protestware_javascript_node_ipc/), [making money](https://securityintelligence.com/news/popular-javascript-library-for-node-js-infected-with-malware-to-empty-bitcoin-wallets/) or simply just to destroy. But those individual packages are difficult to detect, more so when other developers are mandated with keeping packages up to date or the package itself is nested as dependency of another one.
 
 What this [plot](//d.moonfire.us/garden/) is to list one possible approach to handling this problem, along with some suggestions and next steps, because complaining about a system without coming up with a system isn't very productive. Naturally, if this is productive, then it would be an attempt to create a [standard](https://www.explainxkcd.com/wiki/index.php/927:_Standards) but one that I think needs to be done sooner or later, by someone's method or another.

src/self-serve.md

@@ -1,6 +1,6 @@
 # Self-Serve
 
-Outside of a single developer or team, [DRY](./dry/) means that there needs to be a mechanism for discovering and using other's work to avoid repeating their work also. That is the basis of package ecosystems.
+Outside of a single developer or team, [DRY](./dry.md) means that there needs to be a mechanism for discovering and using other's work to avoid repeating their work also. That is the basis of package ecosystems.
 
 The ecosystem has three components:
 
@@ -14,7 +14,7 @@ That is our npmjs.org, nuget.org, and crates.io.
 
 Since these are the showcases for the package system, they start with the need to bootstrap themselves and reduce the effort in producing packages for a new ecosystem. This means we get a self-serve system where any developer can upload a package for others to discover and use.
 
-With continually development, [packages are built on packages](./count/) that are uploaded by hundreds of different developers. Trying to review or address every single one would be overwhelming for individuals to perform on their own and there is little profit for most companies to do it. So, these packages get uploaded with little limitation and are made available as soon as they are.
+With continually development, [packages are built on packages](./counts.md) that are uploaded by hundreds of different developers. Trying to review or address every single one would be overwhelming for individuals to perform on their own and there is little profit for most companies to do it. So, these packages get uploaded with little limitation and are made available as soon as they are.
 
 That is where our malicious packages come in. It doesn't take much to upload one malicious package and have it dropped into place. For an mature package, that one package may be the foundation for countless other projects that touch every part of the globe.