why you should not trim your system install

I happen to think it's *mostly* pointless to trim the install of a system's packages. When I install a system, be it a desktop, server, development machine, etc I install all available packages for that distro. A lot of people disagree with me. They usually say:

• "All those packages take up space!"
  
  Go buy a hard drive made this decade. And while you're at it, stop partitioning your kicks with 2GB /usr partitions and 500MB /tmp partitions. If your disk is full it's full; there's no benefit in letting it fill up sooner than later. Your filesystem should have been created with at least a 1% reserve for root only, which will allow you to log in and fix the issue (unless you are running filesystem-writing apps as root; you're not, right?) not to mention the system monitors you use to tell you before the disk fills up.
  
  
• "But it's a security risk!"
  
  Do you really think your system is more secure because it lacks some binary files? While you're spending time trimming your package list, you're forgetting the basics of system security like firewalling, disabling services, checking the filesystem for overly-permissive files/directories, setuids, etc. Just because you didn't install that setuid kppp doesn't mean there isn't a hole somewhere else on your system. Do a proper audit of your system once everything is installed. This will eliminate typical system attacks and you'll be secure enough to handle exploits in userland apps.
  
  
• "It takes extra time to update all those packages!"
  
  Is your network that slow? Even if you upgraded all of KDE or Gnome it shouldn't take but a couple minutes to download the updated packages. Of course you were a good admin and you have a kickstart repository on the LAN of each machine (or accessible a hop or two away) so the bandwidth should be immaterial.
  
  
• "Yum/apt will take care of the extra packages if you need to install something later."
  
  Oh boy! Let's talk YUM, shall we? First of all it's one of the shittiest pieces of vendor-approved package managing/updating software ever. Read the source if you dare (and if you can). The only thing that's more retarded than its code is how retarded it is to have to troubleshoot YUM when it doesn't do what you want to do. Let's go down the checklist:
  
  
  1. Run `yum clean all`
  2. Check that the package's --requires exist in packages in the repo
  3. Check that the 'meta' arch of the package matches the arch of the machine
  4. Make sure there isn't a duplicate package with a different arch in the repo
  5. Make sure there isn't a package with a similar name but higher epoch in the repo
  6. Make sure the name is the same
  7. Make sure the version is higher and has the same exact format as any other package with the same name
  8. Make sure the metadata in the repo is up to date, and re-gen it just to be sure
  9. Do a `yum clean all` again
  10. Sacrifice a goat to the Yum maintaners
  11. Rename your first born to 'Yellowdog'
  12. Etc
  
  
  Usually someone pushing a bad package or a dependency of a package that used to work will be what breaks Yum. It'll go unnoticed until you really really need that package and its dependencies installed. Then you'll spend hours (and sometimes days) trying to get it installed and fix whatever was broken with rpm/Yum. Whereas if you had installed everything right after your kick, the package would just be there, ready for use. You should only use something newer than what came with your kick if you really really need it.
  
  Of course experience teaches us the folly of trusting any update to an rpm. Whenever you push a new package you must test it on the host it'll be installed on. The package itself may not install correctly via Yum (though using just RPM would probably work), or there could be some other problem with the contents of the package that you'd only know by running the programs contained in the package on the target host. Because we do this, we don't need Yum to browbeat us every time the RPM (or something else) isn't 100% to its liking. If you just install packages en-masse and test them you can skip the whole process of troubleshooting Yum and skip right to troubleshooting the package itself on the host it's intended for, which we'd be doing anyway with Yum.
  

For a VPS or some other disk-and-bandwidth-limited host it's obvious that trimming packages will save you on both of your limited resources. But on a normal network with multiple hosts and plenty of storage I wouldn't spend a lot of time time tweaking my kickstart packages list.

hype of the century

There's never going to be an end to the ridiculous hyperbole surrounding new, expensive, fashionable technology. It never matters if the thing they're hyping is actually good. I think this report sums up exactly the kind of situation I see all the time from the masses of ignorant media fiends.

However, there does seem to be a kind of peak that is hard to reach again. I'd like to tell you all about the biggest peak to date: the iPhone. Seems you can't talk about the iPhone in a negative context without someone bringing up the point that no matter what, I have to agree, the iPhone "changed the world". WELL THEN. Let's just take a look at this entrancing device and see if this assertion may be true?

First of all, I don't see any marketing blitzes in Rwanda or Haiti or the North Pole for this shiny hunk of metal and silicon. In fact, when it was first released the device was only accessible by those with a considerable amount of money and a specific geographic location and mobile service provider (AT&T). Over the years they've released the iPhone officially in other territories and it's possible to purchase one unlocked for other carriers. <edit> You can also now buy the iPhone locked for dozens of carriers around the world. But the device is not universal to all carriers and nations. </edit> This kind of access does not change the world. Maybe they meant to say it "changed the PART OF THE world WHERE I LIVE AND MY ACCESS TO MOBILE CONTENT ON ONE CARRIER". That may be true enough, but that's not what they actually say.

Did it change the industry? Perhaps... The idea of a manufacturer/producer of a phone dictating the terms of how the phone operates and even taking a cut of the subscription profits was certainly a hybrid business model. But did it change the industry? Thus far, no other vendor has accomplished such a feat. With the release of the Nexus One from Google we see an unlocked phone provided on multiple carriers whose operating system is solely controlled by Google. This is probably the second time I know of that a carrier's dictatorial domination of a device has been stripped away. But the iPhone was released three years ago. It took 3 years to begin to change the industry? What took so long? You can't say Apple's original hybrid business model "changed the industry" because the industry remained the same - only one schmuck corporation (AT&T) went along with the idea of total vendor lock-in.

If anything, the iPhone has influenced the way the industry builds out its services. I'm willing to bet that the volume of data is starting to surpass that of the volume of voice traffic. Text messages already replace most short conversations, and one day perhaps the voice channels will all be replaced by a single digital link with VoIP connecting users to providers. There's no reason why in the future you couldn't pick a different long-distance carrier than your "mobile ILEC", similar to land-line phone call routing for the past however many decades. It's obvious AT&T can't keep up with the current flow of data, however, and other carriers must see the need to expand their capacity.

Nobody rational or educated would argue that the iPhone ushered in a new era of smart phones. Smart phones had all of the features of the iPhone and more for years. Granted, those phones were usually high-priced unlocked devices more for the early adopters with green falling out of their pockets. The iPhone itself wasn't exactly cheap, starting out at $399 (and $499 for the 16GB version) plus a 2-year contract. OUCH. (To contrast that, the extremely capable Nokia N95 was around $500 at release time in the same year - unlocked with no contract). The phone even lacked basic features like Bluetooth profiles for input devices (or virtually any other useful profile, including that for wireless stereo headsets). It couldn't send picture messages, it couldn't copy-and-paste... Other than the multitouch interface it wasn't revolutionary in terms of technical gadgetry. You could get more done with a brick-style phone on any carrier than you could with the iPhone.

The one thing you could say was a game-changer was the App Store. Apps for phones is nothing new. Ever since Java became the "operating system" for phones in the early 90's people have been making custom apps and selling them for big bucks world-wide. But there was never an easy way to just look for, pay for and install any given app. The App Store made them accessible to any user at all times. This then also brought more developers in, and with the fast processor and moderately-fast bandwidth many apps were brought about to bring new kinds of content to the device. There were a couple other "app store"-style websites around, but nothing that tied directly into a phone. Google's Android followed suit with their own app store years later, and Microsoft is just now starting to get into the game.

In the end, we now have an industry saturated with look-alike devices, many of which provide more features and functionality than the iPhone itself. But they will never surpass the iPhone in terms of sales or user base. And the reason comes directly from Apple's ubiquitous business model of total lock-in. Control the hardware + control the software = control of the users. At this point, any device that tries to come in and "shake up the game" will be nothing but a distraction for the uninformed random user who stumbles into a carrier's brick-and-mortar trying to be told what they should buy. Most Web 2.0-savvy users will be looking for a phone that supports the "apps" of a particular service or web site, and the only two options today seem to be iPhone or Android. Some people still make Blackberry apps, but that's probably going to become niche for apps which cater to business or corporate users and less for the general public. So an iPhone pretender will always be that, and never become as successful - until they have their own App Store that can compete.

If you're quite done drinking my Haterade, i'll admit that the iPhone is nice. At this point it's the cheapest possible smart phone that provides such a feature set, support from developers and an incomparable user base. But world-changing? Ask anyone today who doesn't have an iPhone if their world seems different since 2007. They'll probably tell you about how the economy is fucked and the banks are running our government, and thank god we have a new President (or holy jesus we're all fucked because of the new President). But if you ask them to list the top 10 things that have changed their world since then, the iPhone won't be among them. Because most people don't give a shit. Their mobile phone needs have been met. And other than general curiosity in high tech gadgetry, they won't have the need to buy into something else.

safe subversion backup with rsync

Let's say you have a subversion repository and you want to keep a backup on a remote host. Doing a "cp -R" is unsafe as is mentioned here, so your two safe methods of copying a subversion repo are 'svnadmin hotcopy' and 'svnadmin dump'. The former only makes a local copy, but the latter creates a single dumpfile on stdout, which is the most flexible method (though it does not grab repo configs).

The simple method to back up the repo from one host to another would be the following:

• ssh user@remote-host "svnadmin dump REPOSITORY" | svnadmin load REPOSITORY

That would create an identical copy of remote-host's repository on the local host. However, for big subversion repositories this could take a lot of time and bandwidth. Here is the form to use disk space to save time and bandwidth:

• ssh user@remote-host "svnadmin dump REPOSITORY > REPO.dump" && rsync -azP user@remote-host:REPO.dump REPO.dump && svnadmin load REPOSITORY < REPO.dump

This makes a dump on the remote host and rsync's the difference of the dump file to the local host. Note that the dump file is uncompressed and rather large, so if you have lots of spare cycles you can pipe the output of 'svnadmin dump' into 'lzma -c' and the opposite for 'svnadmin load'. (The rsync '-z' flag uses gzip compression, but lzma will save you much more space and thus possibly more time)

edit lol, i just realized compressing before rsync is probably pointless, other than reducing the size on local disk. also 'svnadmin hotcopy' is probably the exact same if not better than dumping to a local file vs piping from one host to another (and saves the config).