GSoC Hammer and compression performance numbers

Earlier this week, Daniel Flores posted the first-week report on his Google Summer of Code project, file compression in Hammer.  He mentioned that the LZ4 algorithm he is using seems to have the best performance with repeating text data, as in logfiles.  I asked for numbers, and he provided them.  The important data in the results is the total compression column.  It shows how many 64k blocks were able to be compressed, with that type of data.

Summer of Code, first week reports

All the Summer of Code students for DragonFly have posted their first week reports:

If any of these projects are interesting to you, or if you have any tips for these students on work they are doing, please provide feedback.

 

 

 

PRISM, privacy, and what you make yourself

If you’ve been reading the Digest for a while, you’ve seen me talk about the value of hosting or running your own services.  It’s not too much of a surprise in my case; if you are working on an open-source operating system, you want to run it.  It’s good to get the experience, and you can run programs the way you want, instead of picking from whatever vendors happen to sell you.

The PRISM disclosure, which I am going to assume everyone is familiar with at this point, is another facet.  Every time you use another company for your email, your entertainment, your software, and so on, their information on you can be accessed.    This isn’t a problem that can be fixed by going from one webmail provider to another.  You can shop around, but notice that the author in that link effectively throws his or her hands in the air and says, “there’s no way out” by the end of the article.  This is because corporations work as collecting agents for the government, even if they don’t plan to do so.

That sounds drastic, but there’s legal frameworks in every country for governments to require companies to give up data on any person, on request.  It happens.  I’ve seen it myself; I worked for Time Warner for several years, tracking down cable modem user information and handing it over as compelled by law.  I know the lawyers at TW Corporate didn’t like doing it, but they didn’t have a choice.  (I have some horrifying stories about what people would do to themselves and each other.)

Companies are increasingly working to create services to sell, not products to buy.  A service never stops being consumed, so it forms an ongoing revenue stream.  I’m not saying this is bad; I firmly believe that a financial incentive to be paid improves services.  However, as only a consumer, you can end up not owning what you use.  Other people have pointed this out, and I don’t want to sound like a frothing crazy person… but it is relevant, though not necessarily as catastrophic as some people pronounce.

What I’m working towards here is a reminder that you should run your own software, and running it on DragonFly is the best way.  (Or some other operating system, I guess.  If you have to.)  Instead of trying to figure out what the least-bad commercial option can be, run it yourself.  Good for privacy, good for learning.  I know that’s not an option for everyone; fighting with Sendmail (for instance) is not an activity that many people pick voluntarily.  But, if you’ve been thinking of setting up a replacement for Google Reader, or hosting your own mail, or own blog, etc… there’s never a better time than now.

(Follow all those links for some good information; consider it an early Lazy Reading post)

 

Rough network queues added

Sepherosa Ziehau has added a sort of queuing to altq, where TCP ACKs get higher priority.  You may have seen this in any number of pf configurations, where returning data is given its own queue to keep high-volume transfers from slowing themselves down because the acknowledgements can’t get back to the sender.  His commit has statistics on the performance improvement.  He also added a ‘netrate‘ tool for calculating results from using netperf.

Symbol versioning coming in, also buildworld

If you’re using DragonFly 3.5, your next update should be a full buildworld.  That’s because John Marino is adding the framework for symbol versioning.  This means that individual library (.so) files will internally keep track of newer and older symbols.  The current behavior is to name the files differently, which can cause problems if an expected, linked file is missing – even if the needed symbols are present.  The basic framework is being added now, and will be turned on all at once, to minimize the number of times that full buildworld is needed.

Old amd64 removed and extra upgrade step added

The ‘amd64’ specific parts of kernel architecture have been removed, since x86_64 covers all that.  As a side effect of other changes, John Marino warns that upgrading DragonFly from a version older than 3.4, to a version newer than 3.4, will require an intermediate step of going to 3.4 first.  e.g. If your machine is a DragonFly 3.0 system, you will need to upgrade to 3.4 before moving to, say, 3.6 once it is out.  This won’t matter for some months, since the next release is months off.