Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So libapt is a critical piece of your widely used tool, and you're just happy to sit back, bag on it and talk about the one un-maintianable patchset made. Typical. Ever wonder why apt isn't better in the first place?


If you spend any time looking into me, you will find that I actually care a lot about getting things upstreamed or at least reported in general. A few days ago I was doing a demo where I was laughing about how almost all node.js modules are one line of non-working code, using an example I had found earlier that day, and yes: I reported the issue. I have offered to do all the work to port some projects to fix things, and handed over patches. I am subscribed to a million project mailing lists and have weighed in on random things in random projects over the years.

The reality here is that I don't have the months required to really fix the one place here you could say I have "bagged on" APT, and it is not clear to me that the real problem (which is that the APT community is using C++ in weird or even simply "too many" ways) is fixable.

That said, I will also ask you a question: have you ever really cared how fast APT is? I notice it being slow on my server, but I know why it is slow and where it is slow... it is certainly much faster than Ruby bundler, for example. Is there any good reason at all for anyone but me to change all this code?

The OP complained about some performance issue applying diffs, but as I explained, the real issue with diff updates is that Debian isn't sending cumulative diffs: it doesn't really matter that that is slow either.

So I don't know what you really think I should be doing here. Do you want me to try to train the APT developers in some way? That won't work and is frankly kind of arrogant in a way that commenting from the sidelines isn't. The truly asshole "Web 2.0 GitHub generation" solution at this point would be to fork APT and "compete" with it, but I really really think people who push public forks of key projects are assholes: I am not going to do that.

But if we are going to talk about performance issues in this tool, I am going to try to provide some access to my background about what is going on and why: you essentially will never see me sit around and complain about APT in a context outside of this (and in fact you will generally find me defending APT against developers who are quick to judge something by quality of detail rather than quality of design: reddit makes it difficult to find old comments, but if you really cared you would find me constantly pointing out that APT can be improved rather than thrown out).


> Do you want me to try to train the APT developers in some way? That won't work

Try it out, we're always listening and around in #debian-apt on OFTC.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: