# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 36
# self = https://watcher.sour.is/conv/mna5wlq
Open Source Developer Intentionally Corrupts His Own Widely-Used Libraries
"Users of popular open-source libraries 'colors' and 'faker' were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking.." reports BleepingComputer.
"The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that ... ⌘ Read more
@prologic There appears to be a backstory: http://web.archive.org/web/20220105101202/https://twitter.com/marak/status/1320465599319990272 And then he probably got upset that is work is used so much, but nobody ever pays him?
Hard to tell if any of this is true. It just shows how broken the modern software world is. People are surprised that pulling tons of dependencies without *any* kind of review process breaks stuff? Really?
Maintainers matter. Distributions matter. This is what irks me *a lot* about Rust, Go (and Python, to some degree): They all promote their own package management solution, none of which have any kind of review/testing process like a distro has. This is bad. (With Python, distros can at least provide a package and you can use that. That doesn’t work with Rust (and probably not with Go), because they hate dynamic linking so much.)
I’m just glad I don’t have anything to do with the JS world.
@prologic There appears to be a backstory: http://web.archive.org/web/20220105101202/https://twitter.com/marak/status/1320465599319990272 And then he probably got upset that is work is used so much, but nobody ever pays him?
Hard to tell if any of this is true. It just shows how broken the modern software world is. People are surprised that pulling tons of dependencies without *any* kind of review process breaks stuff? Really?
Maintainers matter. Distributions matter. This is what irks me *a lot* about Rust, Go (and Python, to some degree): They all promote their own package management solution, none of which have any kind of review/testing process like a distro has. This is bad. (With Python, distros can at least provide a package and you can use that. That doesn’t work with Rust (and probably not with Go), because they hate dynamic linking so much.)
I’m just glad I don’t have anything to do with the JS world.
@prologic There appears to be a backstory: http://web.archive.org/web/20220105101202/https://twitter.com/marak/status/1320465599319990272 And then he probably got upset that is work is used so much, but nobody ever pays him?
Hard to tell if any of this is true. It just shows how broken the modern software world is. People are surprised that pulling tons of dependencies without *any* kind of review process breaks stuff? Really?
Maintainers matter. Distributions matter. This is what irks me *a lot* about Rust, Go (and Python, to some degree): They all promote their own package management solution, none of which have any kind of review/testing process like a distro has. This is bad. (With Python, distros can at least provide a package and you can use that. That doesn’t work with Rust (and probably not with Go), because they hate dynamic linking so much.)
I’m just glad I don’t have anything to do with the JS world.
@movq That’s actually not a bad thing though. Static linking has its advantages really and the belief that dynamic linking makes security patching easier is really quite rubbish.
You are right though it all comes down to how good your processes are (or not)
@movq That’s actually not a bad thing though. Static linking has its advantages really and the belief that dynamic linking makes security patching easier is really quite rubbish.
You are right though it all comes down to how good your processes are (or not)
@prologic My concern/point is to have a review and/or testing process by a maintainer of my distribution. And I want to have this process for *libraries* (or “dependencies”, in general), not just for programs.
Here’s an example:
I’m writing a Rust program that uses the “chrono” library: https://docs.rs/chrono/0.4.19/chrono/index.html In the source code of my program, I add this lib as a dependency. What happens then is that the Rust tooling downloads this library *directly from upstream*.
Another program that I’m writing is using Python. Again, I have a dependency and I state that in my source code. But here, this dependency can either be installed directly from upstream or *through a package of my distribution*. When I do the latter (install the distro package), I don’t get *some* upstream version, but I get a *maintained version* from my distro.
I think it’s pretty obvious that using a distro package is the more robust way. There simply is a second pair of eyes to catch mistakes.
When stuff comes from the distro, then the distro maintainer has already done a good deal of work (catch stupid stuff like in the article on slashdot; maybe hold back versions that are known to be broken; maybe apply local patches to make the thing work with this distribution; …). Devs/users can rely on that work and it makes their life easier. But when everyone installs everything directly from upstream, *everybody* has to do the distro maintainer’s work.
@prologic My concern/point is to have a review and/or testing process by a maintainer of my distribution. And I want to have this process for *libraries* (or “dependencies”, in general), not just for programs.
Here’s an example:
I’m writing a Rust program that uses the “chrono” library: https://docs.rs/chrono/0.4.19/chrono/index.html In the source code of my program, I add this lib as a dependency. What happens then is that the Rust tooling downloads this library *directly from upstream*.
Another program that I’m writing is using Python. Again, I have a dependency and I state that in my source code. But here, this dependency can either be installed directly from upstream or *through a package of my distribution*. When I do the latter (install the distro package), I don’t get *some* upstream version, but I get a *maintained version* from my distro.
I think it’s pretty obvious that using a distro package is the more robust way. There simply is a second pair of eyes to catch mistakes.
When stuff comes from the distro, then the distro maintainer has already done a good deal of work (catch stupid stuff like in the article on slashdot; maybe hold back versions that are known to be broken; maybe apply local patches to make the thing work with this distribution; …). Devs/users can rely on that work and it makes their life easier. But when everyone installs everything directly from upstream, *everybody* has to do the distro maintainer’s work.
@prologic My concern/point is to have a review and/or testing process by a maintainer of my distribution. And I want to have this process for *libraries* (or “dependencies”, in general), not just for programs.
Here’s an example:
I’m writing a Rust program that uses the “chrono” library: https://docs.rs/chrono/0.4.19/chrono/index.html In the source code of my program, I add this lib as a dependency. What happens then is that the Rust tooling downloads this library *directly from upstream*.
Another program that I’m writing is using Python. Again, I have a dependency and I state that in my source code. But here, this dependency can either be installed directly from upstream or *through a package of my distribution*. When I do the latter (install the distro package), I don’t get *some* upstream version, but I get a *maintained version* from my distro.
I think it’s pretty obvious that using a distro package is the more robust way. There simply is a second pair of eyes to catch mistakes.
When stuff comes from the distro, then the distro maintainer has already done a good deal of work (catch stupid stuff like in the article on slashdot; maybe hold back versions that are known to be broken; maybe apply local patches to make the thing work with this distribution; …). Devs/users can rely on that work and it makes their life easier. But when everyone installs everything directly from upstream, *everybody* has to do the distro maintainer’s work.
In general, I try to use as little dependencies as possible. I rather read a deps source to see how it’s implemented and then implement it myself. But this isn’t enough. Transitive dependencies make everything horrible. For example, that Rust program I mentioned has two direct dependencies, which pull in four transitive ones. So the amount of work, that I have to do to make sure that all those deps don’t screw up, increases rapidly. If that stuff came from my distro, I’d at least have another person to help me with that.
In general, I try to use as little dependencies as possible. I rather read a deps source to see how it’s implemented and then implement it myself. But this isn’t enough. Transitive dependencies make everything horrible. For example, that Rust program I mentioned has two direct dependencies, which pull in four transitive ones. So the amount of work, that I have to do to make sure that all those deps don’t screw up, increases rapidly. If that stuff came from my distro, I’d at least have another person to help me with that.
In general, I try to use as little dependencies as possible. I rather read a deps source to see how it’s implemented and then implement it myself. But this isn’t enough. Transitive dependencies make everything horrible. For example, that Rust program I mentioned has two direct dependencies, which pull in four transitive ones. So the amount of work, that I have to do to make sure that all those deps don’t screw up, increases rapidly. If that stuff came from my distro, I’d at least have another person to help me with that.
TBH, I’m not sure if all of this is “dynamic linking vs. static linking”. The distro *could* theoretically provide packages with something like .a files and then my program could be statically linked. But the reality is that Rust (and probably not Go, either?) just don’t work that way. (And even if it was *technically* possible: People don’t do it.)
TBH, I’m not sure if all of this is “dynamic linking vs. static linking”. The distro *could* theoretically provide packages with something like .a files and then my program could be statically linked. But the reality is that Rust (and probably not Go, either?) just don’t work that way. (And even if it was *technically* possible: People don’t do it.)
TBH, I’m not sure if all of this is “dynamic linking vs. static linking”. The distro *could* theoretically provide packages with something like .a files and then my program could be statically linked. But the reality is that Rust (and probably not Go, either?) just don’t work that way. (And even if it was *technically* possible: People don’t do it.)
@movq Your right, neither Rust nor Go work that way. They use (_or at least in Go's case, I'm not sure about Rust to be hoenst_) Git really as a way to fetch packages. The plus side of this is you get all the nice benefits of Git
@movq Your right, neither Rust nor Go work that way. They use (_or at least in Go's case, I'm not sure about Rust to be hoenst_) Git really as a way to fetch packages. The plus side of this is you get all the nice benefits of Git
politics is a really complicated topic, to not say dirty. Needed but dirty at the end, so we delegate that kind the people to manage the public life.
That oversimplification said, we are surrounded by power, violence, rights violations and such. Simple fixes for complicated problems don't work, and the last question is: What are we going to do as individuals and as a community?
@eaplmx We can start with us, treat each other with respect and decency. That's a good start 👌 Listen to one another, have empathy and compassion. 🤗 These are not difficult concepts 😂
@eaplmx We can start with us, treat each other with respect and decency. That's a good start 👌 Listen to one another, have empathy and compassion. 🤗 These are not difficult concepts 😂
@movq Yeah I get your points. I used to maintain hundreds of packages for the CRUX distro once upon a time, so I get it. Your points about having a "2nd pair of eyes" are somewhat valid, but I say that because I've been a maintainer myself, we don't often do the "right" things as a maintainer and we sometimes get sloppy/lazy....
@movq Yeah I get your points. I used to maintain hundreds of packages for the CRUX distro once upon a time, so I get it. Your points about having a "2nd pair of eyes" are somewhat valid, but I say that because I've been a maintainer myself, we don't often do the "right" things as a maintainer and we sometimes get sloppy/lazy....
@movq I _think_ overall there are two issues at play here we can agree on, whether or not it's "managed" by a distro (_I think that's kind of irrelevant here, I use/develop on macOS for example and use brew but I don't want my deps to come from Homebrew uggh yuck_) -- Anyway There are two issues I see:
- Supply Chain -- Being able to vet, validate and verify everything that goes into a piece of software or product/service
- Library hygiene -- Being prudent about libraries as a Library author and reducing or eliminating "transitive" dependencies.
@movq I _think_ overall there are two issues at play here we can agree on, whether or not it's "managed" by a distro (_I think that's kind of irrelevant here, I use/develop on macOS for example and use brew but I don't want my deps to come from Homebrew uggh yuck_) -- Anyway There are two issues I see:
- Supply Chain -- Being able to vet, validate and verify everything that goes into a piece of software or product/service
- Library hygiene -- Being prudent about libraries as a Library author and reducing or eliminating "transitive" dependencies.
@prologic I would say empathy and compassion are extremely important and really difficult to grasp and practice!
That being said, in this group/community/organization/oasis/bunch_of_people, I really appreciate having it!
@eaplmx Yeah I agree! 👌 One of my greatest hopes is that as Yarn.social continues to grow, that each Pod and it's Pod Owner/Operator (_we seem to be calling Poderator thanks to @ullarah_) will create and nature small communities. The "network" as such will basically be an interconnected network of Yarn pods + Twtxtv2 feeds.
@eaplmx Yeah I agree! 👌 One of my greatest hopes is that as Yarn.social continues to grow, that each Pod and it's Pod Owner/Operator (_we seem to be calling Poderator thanks to @ullarah_) will create and nature small communities. The "network" as such will basically be an interconnected network of Yarn pods + Twtxtv2 feeds.
@prologic Smoot Poderator 🎶
Poderator is brilliant! Reminds me of the Podcast and the concept of Pod itself, Ham radio and such.
@eaplmx My only _gripe_ with the term "Poderator" is it's too close to "Moderator" but oh well 😅
@eaplmx My only _gripe_ with the term "Poderator" is it's too close to "Moderator" but oh well 😅
@eaplmx LOL even worse 🤣 🤦♂️ So no 🤪
@eaplmx LOL even worse 🤣 🤦♂️ So no 🤪