Slashdot Mirror
APT Speed For Incremental Updates Gets a Massive Performance Boost
jones_supa writes: Developer Julian Andres Klode has this week made some improvements to significantly increase the speed of incremental updates with Debian GNU/Linux's APT update system. His optimizations have yielded the apt-get program to suddenly yield 10x performance when compared to the old code. These improvements also make APT with PDiff now faster than the default, non-incremental behavior. Beyond the improvements that landed this week, Julian is still exploring other areas for improving APT update performance. More details via his blog post.
Mainly because that flap involved very few of the actual technical people and people got upset long after the decision was already made. It also seems to be the case that some trolls went off on a misinformation campaign complete with fake bug reports. Quite frankly, I was terrified of systemd from what I was reading here, but then I actually read up on the subject and realized most of what people have been saying about it is false.
Now that I've actually tried it, my desktops boot faster and I have had a much easier time customizing the boot sequence of some of the servers I maintain.
Of course. It's not just plain text appended to a set of files so you would have to use journalctl to access them. Nothing wrong with that. Now this gives you a number of benefits. Since journald actually knows about the data that it stores it can make intelligent decisions. Everyone who has ever had to clean up a filled up /var/log partition knows how broken logrotate is. What if the journal could actually know about this and rotate based on size? It also makes it possible to actually search for things without having to take different date and log formats into account, and actually know that it came from the correct program. I know, crazy.
Holy fuck, I just read the blog article and this is what it said:
How the fuck did that all happen to begin with?! Who the fuck wrote the code like that initially?! How fucking long has this been the case?!
I understand that bugs will happen. I really do. But this is like a total breakdown in process. Why the fuck weren't these problems detected sooner, like when the code was committed and reviewed? The code was reviewed, right?!
We aren't talking about some minor software project here. This is apt, for fuck's sake! This is one of the core pieces of Debian's (and Ubuntu's, and many other distros') basic infrastructure. This is the kind of shit that has to be done properly, yet it clearly wasn't in this case.
The Debian project needs to address how this shit even happened to begin with. This is fucking unbelievable. The entire Debian community deserves a full explanation as to how this debacle happened.
I thank God every day that I moved all of my servers from Debian to OpenBSD after the systemd decision. I know that the OpenBSD devs take code reviews and code quality extremely seriously, not just with the core OS itself, but even with software written by others. The OpenBSD project will even create and maintain their own custom forks of third party software if the original developers can't get their shit together!
What's wrong with binary logs?
Nothing, if they're well-designed and ACID compliant, which journald is not:
It's rare that I choose to defend systemd, but ACID compliance does not mean you never have to deal with a corrupt database. It is a software technique to make sure transactions complete in an atomic, consistent, isolated and durable way but it still presumes a "perfect" system and if a bit flip happens in memory or on disk outside the programming logic then ACID will fail. That is why you have ECC, RAID1/5/6 and ZFS, but even they fail and sometimes you have genuinely "impossible" results like you've added $2+$2 to the account and the result is $5 (bit flip from 0x0100 to 0x0101). If you're using plain text and UTF-8 this can happen there as well, there are combinations that are simply illegal to use. You expect the parser to ignore the "impossible" and carry on, apparently that's what journald is doing too.
Live today, because you never know what tomorrow brings
[I apologize to the masses for responding to yet another offtopic systemd propagandafest thread.]
But could I grab any old 32 or 64 bit ubuntu live install usb stick from the last 5 years to access an unbootable Debian system? (from there intstalling raid admin tools is a one line apt-get)
Or before I can view the logs do I need to prepare and maintain a custom rescue boot disc for every debian version, with the same 32/64 bitness, same lib6c and other .so library versions, and same exact version of systemd? (some of the workstations track Debian/testing)
All before I can set up some export pipes before I can run grep, sort, uniq, and sed to isolate the problem? Do I need to master a new SQL variant? (Honest question)
Or will my life be made more difficult under critical server-is-down this is costing us 10s of thousands of dollars a minute pressure conditions due to artificial barriers which didn't used to be there?
K.I.S.S.
~.~
I'm a peripheral visionary.