Jim’s blog

March 24, 2005

五百万啊五百万,一百遍啊一百遍

【8:59 pm By Jim】

今天還挺順利的,頭是個東北人,聽完我老老實實的評價後居然非常高興,我原以爲他會K我的,結果發現他是愛上我了:)

明天約了PM談項目,以前是個政府部門的人,據說很牛X。可我沒高興多久就發現這個項目異常的大而且很急,單一模塊數據庫的量初步估計是500萬條,並發未知。我沒有這麽牛X的經驗,就算有,這規模的一個項目也不可能只由一兩個人來完成,而且我也相信沒有集群支持的話這是不可想像的,而集群要攷慮的就更多了,於是這項目和一個企業級ERP的難度就不相上下了,MD,明天可怎麽談?

Struts+Spring+Hibernate輕量級的J2EE架構,。?我沒一個熟:(

上帝保佑~

March 23, 2005

家家有XX,人人有外遇

【11:59 pm By Jim】

收到Mail了,明天要去中銀interview,祝自己好運。我還真是的,放著Lexmark不去卻偏要自己幹,何必呢?想來想去大概是不喜歡在一群女人堆裏幹活的緣故吧,尤其是一群會在上班時間38的女人,盡管她們都很漂亮。

事多,煩躁。

今天把Arch研究了好一會,確實是個很不錯的系統。下了ISO准備在Vmware裏安裝看看怎樣,結果很快樂的發現,我那可愛的刻錄機連刻壞了兩張盤,顯然已經掛掉了,我!@$%*&。最後用Deamon Tools掛上ISO安裝好了,感覺還不錯,不過網絡的設定要再研究一下,和GentooDebian都不太一樣,除此之外,系統很清爽效能也挺高的,不會比Gentoo差多少,Pacman比apt爽太多了,也不比emerge差。週末安排一下,實戰Arch:)

中午吃飯的時候表姐38來一個差點讓我下巴掉下來的消息,我小叔叔有外遇了!叔叔在這邊工作,老婆在郴州守著兩個兒子過日子,我一直覺得叔叔是個好男人,現在。。。

有必要複習一下帥哥Jim的名言:     女人無所謂忠誠,忠誠是因爲所受的誘惑不夠;     男人無所謂專一,專一是因爲背叛的籌碼太低。

看來外遇和感冒沒什麽兩樣,都是會流行和傳染的。

最近巨喜歡五月天,聽下武裝以後,亂~

祝自己明天好。

Arch In Depth

【5:42 pm By Jim】

There are a lot of cliches about how the only thing that remains constant is change. That statement definitely applies to the Linux industry. Last year and the beginning of this has brought us a lot of changes. There are new technologies and distributions to pick from.

Ubuntu was a relatively unknown name a few months ago but now is generating a lot of buzz. Personally, I have tried Ubuntu and don’t see anything technically special with it. The way Ubuntu is marketed (free CDs and an interesting release cycle) is what is making it so successful. But this article isn’t about Ubuntu but a very different distribution called Arch. Could Arch dethrone Ubuntu as the new kid on the block? Does it have what it takes? Read on and find out.

First of all, let me go ahead and say I’m not approaching Arch with a completely clean slate. I’ve heard things about Arch Linux before. I’ve heard that it resembles Slackware in the way it was lean and meant for "advanced users". I’ve heard about its package manager called Pacman which is supposed to be all the rage. I’ve heard it’s optimized for i686 by default which can arguably improve performance. I’ve heard it’s Gentoo without "all that compiling". So when Arch 0.7 got out a few days ago I simply had to try it out.

Installation

The Arch ISO comes in two flavors. There is a 560 MB full version and a smaller base version. Both can be downloaded normally or via Bittorrent. For the uninitiated, Bittorrent is a peer to peer protocol for downloading files. I hope to see more and more distributions use Bittorrent for downloading ISOs since it cuts down on expensive mirrors. Anyway, after my download was done I burned the ISO, put the CD in the drive, and rebooted.

http://www.linuxtimes.net/article-images/archlinux/install1.JPG

Before I began the install, I glanced over the installation guide at http://www.archlinux.org/docs/en/guide/install/arch-install-guide.html Arch’s installation CD doubles as a rescue disk in case you may have a unbootable Arch installation in the future. The install CD boot up and dumps you into a command prompt. You have to invoke the installer using /arch/setup a la Slackware or Yoper.

What follows is a typical text based installed. One positive comment I have is right away you are given the option for an FTP or CD install at the beginning. In some distributions (such as Fedora) you have to issue special commands to perform an FTP install. It’s nice of the people at Arch to make FTP installation easy.

http://www.linuxtimes.net/article-images/archlinux/install4.JPG

The strange thing about the installer is you are presented with a list of installation tasks but you can apparently jump around and do them in any order you like. This is quite interesting behavior but frankly this may confuse some people. I stuck with the norm and performed the steps in sequential order: disk partitioning, package selection, bootloader configuration. A comment about package selection: Arch actually recommends you install only the base packages.

http://www.linuxtimes.net/article-images/archlinux/install7.JPG

In fact, the package selection screen only has base packages selected by default. I suppose I can understand the reason for this. Linux packages tend to get stale pretty quickly and it would be a wiser default to install the base and grab the latest packages off the web after installation (assuming you have a fast connection). I chose to install the base packages as recommended. I got a final chance to review my packages and then pick a kernel. The installer then went off and did its business and installed the packages and a kernel. I then moved on to bootloader configuration which was a pretty standard fare.

http://www.linuxtimes.net/article-images/archlinux/install11.JPG

A curious menu item in the installer is the "Configure System" entry. Selecting this first asks you what editor you want to use (I selected vi) and then presents you with a list of configuration files you want to look at. I have done countless Linux installs and I can’t remember a single one where you have that level of control. It definitely promotes Arch’s image as a no hand-holding distribution. I decided not to edit any of my config files and accept the defaults. However, to my surprise (or shock) all the configuration files were empty. I’m not sure if this is a bug or a feature but there were no default values in the config files. I guess this meant I had to configure all of them by hand. I checked the installation guide which wasn’t clear on this. It did have some excellent documentation of what I should put in these configuration files. So I manually went through rc.conf, menu.lst (grub.conf), and many others using the installation guide to help me. I could configure grub without any help but I had no clue what to put in some of the files. The whole process was a bit frustrating.

http://www.linuxtimes.net/article-images/archlinux/install13.JPG

I was brought back to the main installation menu from where I rebooted and awaited my new Arch installation. My hopes were dashed when I discovered Arch wouldn’t boot. So the only option I had was to re-do the installation. This time around when I came to the "Configure System" option all the configuration files weren’t empty! They had good sensible defaults in them which I could work with. I finished up the installation and rebooted again and to my relief Arch finally booted.

First Impressions

Arch booted in a fairly standard way. The startup seemed good but nothing too shocking. The first thing I realized after Arch booted was that the installation never asked me to set up any root password or user accounts. I was simply presented by a login prompt. I guessed that I could log in as root with no password. The Arch installation guide confirmed this. After logging in, I changed my password using the passwd command. As the manual suggested, I went ahead and added a normal user.

http://www.linuxtimes.net/article-images/archlinux/boot.JPG

So I was all set to use Arch — or so I thought. I casually assumed my ethernet cable modem internet connection was working but I was mistaken. I tried pinging a few sites but there was no response. I ran the ifconfig command. It turned out although I did have a eth0 device the IP address it was using was a private address (i.e.: 192.168.xxx.xxx). This indicated to me that automatic network configuration with DHCP was disabled. I looked through the manual for help. Apparently to enable DHCP you have to edit the /etc/rc.conf file manually. I had foolishly accepted the config file defaults during the installation. I went ahead and changed rc.conf. To apply the changes, I just rebooted and now the network worked!

After the network fiasco I decided to read through the Installation Guide to make sure I didn’t miss anything else. The "installation guide" doesn’t just cover installation but also post installation tasks such as package management. In my opinion, the guide is very well written and well designed. However, the scope of the guide seems a bit limited. For example, the guide does not cover how to install Xorg (which is usually the first thing I do after any installation).

Pacman

Arch’s guide simply pointed me to the Arch Wiki (http://wiki2.archlinux.org/) from where I had to navigate to a "Howto install Xorg" article. First of all, I decided I better refresh my package list. I did so by issuing "pacman -Sy" as root.

This procedure is similar to Gentoo’s "emerge sync" and APT’s apt-get update". To my surprise, the command finished very quickly. My experience with Gentoo is refreshing the package list takes at least a two or three minutes. Debian’s probably takes about a minute or so on my computer, but Arch’s speed was impressive. After the package tree was refreshed, I installed xorg with:

pacman -S xorg

which proceeded to resulted in a bunch of things being downloaded. The speed of the download mirror was really nice. I didn’t pick a mirror manually. I’m not sure if pacman automatically gets the closest mirror or not but it was a nice touch. Maybe I was just lucky. Xorg installed and I came back to the command prompt. One reason I wanted to install xorg was to see if pacman is intelligent enough to launch xorgconfig for me or did I have to do it manually. As I expected, I had to configure Xorg myself. The process of configuring Xorg is one that is frustrating. I remember all the steps because I’ve done it so many times. I didn’t have a preconfigured xorg.conf lying around as I should have. To test out Xorg, I needed to install Gnome which was really easy to do using pacman. Even though Gnome did install, pacman wasn’t smart enough to install gdm with it. Yes I know there is a way to log in without using a graphical login manager but I would guess that the majority of people out there want to log in graphically. I had to install gdm manually.

I must say so far I am really getting into pacman. It seems to take the best from Debian and Gentoo’s package managers. For example, one thing that really bothered me about Debian’s APT is Debconf. Debconf is a way to configure packages as you install them in Debian. For example, if you install xorg in Debian, it will first ask you a bunch of configuration questions about xorg (and its dependencies) before installing it. While this behavior is useful in certain situations it can be really annoying when you have to install a lot of packages. You can’t just run the install command, go get a coffee and expect them to be installed. Thankfully, you can turn of Debconf. You can even set the question priority for Debconf but it is turned on by default. A lot of Debian documents recommended configuring through Debconf so even if you turn it off it doesn’t quite go away completely. Gentoo has nothing equivalent of Debconf and from my experience with Pacman it seems it doesn’t either. This goes along with Arch’s "do it yourself" philosophy.

Pacman’s speed seems fairly impressive also. One good thing about Debian’s APT is it’s pretty fast but from using Arch for a few days it seems Pacman’s speed edges out APT’s by just a just a little bit. Maybe it’s psychological for me but I do feel a difference. Of course this is totally subjective and depends on your system. Comparing Pacman to Gentoo’s portage is comparing apple’s and oranges (or Apples and PCs for that matter!) because portage compiles everything by source. However, we can still compare portage’s speed to Arch’s while (say) searching for a package. Gentoo just recently introduced a new version of portage which was supposed to be faster but I really didn’t see a difference. Searching for a particular package still takes a ad longer than it should. That said, after portage is up and running it’s very good. Pacman seems to do the same except faster and you really can say it’s like Gentoo "without all that compiling".

I’d also like to make a small note on packages that are a bit controversial in nature. There are packages such as mplayer and certain codecs, java, and some sundry items that are not available in the default Debian repository (due to licensing issues). This is a huge deal because this affects every distribution based on Debian (Ubuntu, MEPIS and others). Fedora is also another distribution that has very poor multimedia support for legal reasons. There is no acknowledgement of this problem from Debian or Fedora. Just imagine a new user who just tries a popular Linux such as Fedora. He soon finds that he can’t play any MP3 files. Yes as it turns out, MP3 is a licensed technology and is not open source (though some people believe that).

The Fedora documentation makes no comment on this. It doesn’t tell the user why the codec is not included and how they can add it if they don’t care about licensing issues. See http://www.ubuntulinux.org/wiki/RestrictedFormats for more information. Yes, you can install "controversial packages" on systems such as Debian using a third-party repository but this is not an elegant solution. I do not like installing applications this way because it always left me with a "unclean" feeling both of using unofficial packages that may not interact with my system as well as official packages may. Doing this also makes me as though I’m doing something so wrong that I have to do it in an underhanded way.

The story about codecs becomes more interesting when certain distributions do include them by default. For example, MEPIS has always (I’m pretty sure) included support for Java and multimedia codecs and flash. This is actually a big part of its appeal. Gentoo has always had all those packages and more in their repository. And coming back on subject, so does Arch. I was happy to. I’m not a lawyer. I just want to play MP3s and/or videos. The point of these packages is pretty simple: one distribution has them and one doesn’t. I’ll make my life easier and install one that does. Thankfully Arch seems to have a lot of good, bleeding edge packages.

Arch’s packages are not completely expansive though. For example, I wanted to install the ever popular Bittorrent application Azureus but there was no package for it. Of course I could install the package by downloading it from the Azurues site. Azureus is a Java application so before I did grab the latest Java Runtime from the repository and it worked fine. I also do Java development using Netbeans. I wasn’t surprised that Pacman didn’t have Netbeans in the repository as not a lot of people use this package. However, to use Netbeans you need the Java SDK which I did find in Pacman.

Overall I would say Arch’s package management is heading in the right direction. Obviously the distribution is a newer one and it will take a bit of time for them to create some of the more esoteric packages. Gentoo’s repository probably has the most depth but I have a feeling Arch’s is heading the same way. Also it would be nice if they could expose development packages like Gentoo does. Gentoo uses a masking system. For those who’ve never tried it, masking is basically a way of installing development (possibly unstable) packages on your system. This added power is really useful when you’re willing to risk a little instability to try the latest and greatest thing. From what I see of pacman, there is no equivalent of masked packages. However, the packages that do exist in Pacman are new enough to make up for the absence of this feature.

The Desktop

My desktop environment of choice is Gnome 2.8. When I logged into Gnome, I realized that the people over at Arch hadn’t customized it in any way at all. Everything is very "default looking". The wallpaper, splash screen are all stock. This is what reminds me of Slackware because I believe it is one of Slackware’s policies to not customize their packages in any way because doing that may introduce new bugs into them that didn’t exist before. While I agree with this philosophy to a certain extent I also feel that this shouldn’t be a black and white thing.

http://www.linuxtimes.net/article-images/archlinux/gnome.JPG

Branding a distribution with a custom KDE or Gnome wallpaper sounds pretty harmless to me and should be done to set one distribution from another. I know both Debian and Gentoo customize their packages to a certain degree. For example Gentoo includes extra applets for Gnome (that are not included in the default set). One of my favorite applets, the Network Monitor, was absent from the applets list. I tried searching Pacman for it, but I couldn’t find it. So I go on IRC to see if someone to help me with this. Some kind Arch user ("timmy") pointed that the package for the applet was netstatus. The absence of netstatus is a little confusing to me because if you read http://www.gnome.org/start/2.8/notes/rnwhatsnew.html it clearly shows the netstatus applet being a part of gnome.

Oh well, at least Arch has it in pacman. I was just about to open up Gnome Terminal and get pacman to install netstatus but I look through all the menus and a terminal application! Wow…no distribution I’ve ever tried didn’t have a terminal application. I was confused about this and then looking through the menus, I came to the conclusion that other basic applications such as the Gnome Calculator were missing. Was something wrong or was it supposed to be that way. I spoke with a few friendly Arch users on IRC and they understood my confusion. They explained that I didn’t have some zombie, disabled version of Gnome but that the minimal number of Gnome packages installed by default was a result of Arch’s philosophy. Basically, you install the base and you add exactly what you need and nothing else. But the neat thing about Arch is for those people (like me) who want a full blown Gnome (even with all the extra stuff we don’t really use) we can install a "gnome-extra" package which will install all the goodies for Gnome (including netstatus). I found this approach quite appealing. The solution is elegant because this way the minimalists are happy and others are not left out in the cold.

After install gnome-extra and a couple of other things I was finally ready to get my computing environment exactly the way I want. I have Windows on another drive and I edited /etc/fstab to add mount points for them. From installing applications to adding printers, configuring a Linux distribution like Arch can take a while. My usual procedure is to get some tunes going while I’m getting Linux configured which is a ironic because to do that I have to set up my sound card. The Arch Wiki page is very useful in this regard. I had sound working in no time. I installed XMMS and off I went.

http://www.linuxtimes.net/article-images/archlinux/gnome2.JPG

For instant messaging, I installed gaim. For playing videos, I install the windows codecs and totem. As far as my printer is concerned (a HP Deskjet 932C), I check with the Arch Wiki again just to double check even though I know how to configure CUPS. As I began to get more into the Arch system, I really began to appreciate the simplicity of the whole thing. There are no weird config file locations, no weird commands or weird scripts. Everything is really standard and I think an advanced Linux user will definitely appreciate it. There is a sense of respect from the system to the user. In a sense the system is yielding to you. It doesn’t make decisions for you. It only helps to execute the ones you have. The more I used Arch, the more prevalent this became and I must give Arch developers high marks for being consistent. Configuring something like ALSA for my sound card was a good exposure to this philosophy and I was pleasantly surprised by it.

More Pacman

If you’ve kept awake this far, you’ll realize that Arch isn’t a "one size fits all" approach. There are no default applications to speak of (unless you consider the ls command an "application"). The minimal approach is not a new one of course. Slackware, Gentoo, and Debian are famous for using the minimal approach to Linux. What really sets Arch apart is pacman. There is no denying that Pacman is the heart of the Arch system. So I decided it would be fun to poke around Pacman and see how it really works. From the get-go, Arch users are introduced to the concept of building custom packages (in the Installation Guide) using the Arch Build System.

To get started, I followed the instructions from http://www.archlinux.org/docs/en/guide/install/arch-install-guide.html#abs But first I needed a package that I could build. While playing around with Pacman, I had noticed that the p7zip package was not to be found in the Pacman repository. 7zip is a new exciting compression technology while gives usually gives a higher compression ratios that some of the older formats such as zip and RAR. In fact, you may have noticed that the size of the installers for Firefox and Thunderbird has gone down (for Windows at least) because they are using 7zip compression. There is a Windows 7-zip unzipper you can find at www.7zip.org. Unfortunately, there was no Linux alternative for a while. That is until someone wrote p7zip (http://p7zip.sourceforge.net/). Since Arch didn’t have p7zip in its repository I decided to stop complaining about it and build the package myself. I also picked p7zip because it’s a very small program with virtually no dependencies and would be a good package to get my feet wet with Arch’s build system.

The first thing I did to get started with ABS was to run the "abs" command as root. This got a package tree from an Arch mirror. This process only took a few seconds. After this I had to edit a PKGBUILD file. Creating Arch packages is relatively simple. All you need is the PKGBUILD script. A utility called makepkg reads the PKGBUILD script file and generates an Arch package from that (which can be installed by pacman). The format of the PKGBUILD file is intuitive and simple. You can also define dependencies in your PKGBUILD script. It also has support for configuring a package after it has been installed and after it is uninstalled.

Overall, I found the format of PKGBUILD and makepkg quite elegant yet powerful. In a few minutes, I configured a PKGBUILD script for p7zip. The script was relatively simple since p7zip does not have any dependencies. I ran makepkg and then installed the generated package. And it worked! My first Arch package — fairly painless. Overall I think Arch Build System is well done and it encourages the community to build they own packages that they need.

Conclusion

It appears to me that invariably, almost every week or so, a new Debian-based distribution comes out. The reason for this is simple: APT. With Debian’s package manager and pre-existing packages, what new distribution developer could resist it as a base? Apparently, not many. One of my favorite sites, Distrowatch, claims that about a that there about 128 distributions based on Debian. Out of all total distributions, only 29 can be classified as "Independent". Arch Linux is one of them. By doing this, Arch has taken "the road not taken" and traveled on the unbeaten path. This in itself is commendable but independence for the sake of it is pointless.

By writing their own package manager and having their own packages (i686 optimized) Arch has really set itself apart. This combined with their KISS (Keep it Simple Silly) philosophy makes Arch a good distribution to consider. One thing to note is that Arch is still at 0.7, which means that all the bugs have not been ironed out from it. I got a few weird error with Gnome in Arch. I also ran into one or two minor problems with pacman. Overall, there is no big show stopping bugs that would prevent me from recommending Arch wholeheartedly to you. Also, from what I have seen of it, the Arch community seems very welcoming and sensible. I didn’t see many RTFM type replies to my queries. Perhaps this is only because of the newness of the distribution but currently the community is a good plus to Arch. The community feel is prevalent throughout Arch. For example, the install guide encourages you to build you own packages and share them with other Arch users ("Archers").

As I have mentioned before, Arch feels a bit like a modern version of Slackware. I wouldn’t be surprised if a few Slack users jumped ship to Arch. Arch also possibly threatens the user bases of Gentoo and Debian. This would be especially true if Arch decided to add the aforementioned features such as the ability to unmask unstable packages. Gentoo users who are a little tired of long compiles will probably seen Arch as a viable alternative minus the compiling. The packages are also optimized for speed and efficiency which will appeal to any Gentoo user. Arch has made a good first impression on me. All the developers need to do now is polish out the edges. In short, Arch has strong start to the long road to becoming a mainstream distribution.

Summary

Pros: Strong package management; Attention to simplicity and standards; Good documentation

Cons: Still needs some polish; Configuring everything by hand can be a pain; Installation can be confusing to some users

The Bottom Line: If you like Slackware but wish it had a good built in package manager, you’ll love Arch. If you like having ultimate control over your system and don’t mind configuring everything by editing text files, you’ll fall for Arch. If you want to learn the innards for Linux, Arch would seem like a good platform to do so. If you’re expecting sound coming out of your speakers at first boot and USB drives mounting automatically on the desktop then you’d best stick to something like MEPIS or Ubuntu.

Author: Tarun Agnani is a software developer who recently graduated from college. He uses Linux for both work at play and dabbles in all forms of computing entertainment including Linux (obviously), Macintosh, and yes even Windows.

以上摘自Linuxtimes.net,很好的文章,打算翻譯出來放上linuxsir,如果有空的話:)

Arch Linux: Why It Rocks

【5:17 pm By Jim】

最近在對這兩個Distro攷查中:Arch/Kubuntu,有幾篇好的文章要記記,基本上是對Arch更感興趣一些,一個更接近Gentoo的distro~

2003 was the year with Gentoo written all over it in the Linux universe. Last year was Ubuntu’s & MEPIS’. I believe that Arch Linux’s year is the current one. Read more for a comparison of Arch to existing distributions, and why we think it rocks and where we think it still requires some work.

Intro

Arch Linux Arch is an i686-optimized Linux distributions based upon the ideas of CRUX and Slackware. It incorporates their stability, speed and most of all, their keep-it-simple philosophy. When Judd Vinet started Arch towards the end of 2001 he did it because he needed n operating system that resembled CRUX or Slackware but with a package manager that had the ability to track dependencies. So he sat down, used LFS to put together his distro and wrote ‘pacman’ from scratch, his minimalistic and yet very usable, package manager. Here is a quick look on how pacman works: pacman -Suy (update the whole system by syncing) pacman -S firefox (install Firefox from -Current) pacman -R firefox (remove Firefox from your system) pacman -A package-name.tar.gz (install a local package)

http://osnews.com/img/8761/arch.jpg

The distribution’s installation procedure is curses-based but it’s not too difficult to figure out (except the part that GRUB won’t get installed if another GRUB is already installed at the same place and it will instead spit an error message — that part always elluded me).

Arch Linux does not have many distro-specific tools and it definetely has no GUI configuration tools. Some of the configuration (daemons, modules, ethernet etc) can be done by editing /etc/rc.conf which is implemented in a clean and graceful way. For more configuration, you will have to use /etc/rc.local or the utilities’ own configuration files, e.g. /etc/conf.d/pcmcia.conf, or udev’s configuration files, or /etc/conf.d/wireless etc. There is definetely a learning curve in there, but Arch is using default file settings and so you won’t have to learn distro-specific tricks (as it is very common for the Debian subsystem or the main RPM systems).

Comparison

So far Arch does not look very glamorous from my description above, but looking under the hood and at the details, there are strong reasons why it has some advantages over the big Linux players and why it has personally won me over the last few months: (disclaimer: the following comparison is based on my own personal experience with these systems over the course of 7 years of using Linux)

Fedora, Mandrake, SuSE: they require at least 192 MB RAM, they are much slower & much bigger, RPM package management is too modularized and easy to end up with broken or incompatible packages all of a sudden. Some of their scripts or settings are too distro-specific with a long legacy behind them and so sometimes they even break the defaults of some applications or create hard-to-reproduce bugs. On the upside, these distros have lots of GUI tools and mind-share, enough to make commercial binary packages to only test with them to ensure compatibility.

Debian, Ubuntu: Much slower to boot, slower performance overall. apt-get & dpkg and all these related tools are not as brain-dead simple to use as pacman is (and Synaptic is not really as wonderful either). Some distro-specific patches can create problems sometimes. On the upside Debian has a gazillion packages to install and its -stable branch is far more stable than any Linux out there.

Gentoo: Gentoo feels like it’s in beta all the time. It is an ever-changing system that started out simple but has become pretty complex with time. Portage is very strong, but the big problem of Gentoo is that it needs hours to get it installed or get it configured or update the system. With Arch you can be up and running in the 1/50 of that time. Speed-wise they are comparable, with Gentoo having an edge if Gentoo-specific modifications are used. Gentoo supports eBuilds (similar to Arch’s makepkg/ABS philosophy) however usually the most common option available is compilation from source.

Slackware: I have made a much more detailed comparison a few months ago. Since then, the only negative thing that has happened is the apparent slowdown in Slackware’s development due to the health of its sole maintainer. Slackware and Arch Linux have more things in common than not and this is the main reason why many Slackware users have moved to Arch recently.

Now, make it even better

Despite what you might think though, Arch is not perfect and no matter what Archers might advocate to you in the forums or IRC, Arch is not for newbies. Semi-experienced users will be able to successfully fully configure their setup with a bit of pain, but less experienced ones will probably be presented with something that resembles a chaos in their minds. This is not to say that Arch is not a great distro, cause it is. But it does target a more experienced part of the overall userbase.

Pacman has a few performance problems as of late. The number of packages got bigger but pacman does not seem to scale equally well. Currently there is a forum discussion about possible solutions to the problem.

Another weak point is the creation of home-made packages. Archers will advocate that makepkg is dead easy, but it’s not as dead easy as Checkinstall (but still much easier than creating RPMs, of course). Makepkg still requires a bit of extra knowledge and some extra time. With Checkinstall you "./configure" and you "make" but at the end, instead of typing "make install", you type "checkinstall". Checkinstall will strip the binary, will create the package for you and will install it, all automatically. Makepkg is definetely not as convenient, at least for ex-Slackware users.

Having to deal with configuration files all over the place for many different applications can be an exercise to one’s patience, no matter the level of his/her experience. It would be great if Arch could create more global configuration files similar to /etc/rc.conf for other things too, e.g. wi-fi profiles, printer, scanners, bluetooth etc. Sure, GUI tools are not the focus of this distribution, but having some easy-to-use global settings files can make everyone’s life easier nevertheless.

Lastly, I would love to see all its very useful wiki articles re-published under the Gentoo colored format: the step-by-step nature of Gentoo’s docs do bring out a higher level a confidence in one’s real abilities. And its happy colors prompt the user to think "hey, it is easy, try it!" (yes, part of it is about psychology and the "feel good" placebo effect).

Conclusion

Arch is a great choice for more-than-newbies+ computer users. It’s still in 0.7 version, but it steps on a solid ground, it has great people behind it and an extra-helpful community. Arch’s big point is "simplicity". But unlike other ’simple’ distros it goes one step further: it dares. It dares to be innovative where it counts without fearing that it might break some of its simplicity over usefuleness. I find Arch to be the best of all worlds, given you are a bit proficient with computers. Highly recommended for either a workstation or a server.

Installation: 7.5/10 Hardware Support: 9/10 Ease of use: 6.5/10 Features: 7.5/10 Credibility: 9/10 (stability, bugs, security) Speed: 9/10 (UI responsiveness, latency, throughput)

Overall: 8/10

以上轉自osnews.com

March 22, 2005

綠豆綠豆

【11:25 pm By Jim】

忽然想喝綠豆糖水,於是洗完澡就煲了一大鍋,確切說應該是爸爸煲的,我手傷了沒能幫上什麽忙。半小時後一大煲的糖水就做好了,媽媽很BS的一瞅:“你們爺倆都是眼寬肚窄!”這個。。。好像也確實是多了一些。。。慢慢喝唄,反正今晚我還得搞定Chapter4~

今天硬盤實在不夠用了,心一橫把好多東東都delete了,當然包括N多蒐集了好久的頂級神秘西片了,kidding:)主要還是一些下了幾百年都沒時間欣賞的電影、音樂之類,爲了迎接KDE3.4的到來也沒辦法了。

KDE3.4EVA0.2都發佈了,所以我要重新轉回到linux下了,Windows在娛樂方面的確一流,但實在是幹不了什麽事,再說我也不玩遊戲;linux下則正好相反:)月底前我得搭好一個PHP的平台爲論壇做准備,事多煩雜,有沒搞技術的美女來幫幫我哦:)

今天硬盤清了大概有十來G的東東,這兩天要重裝WIN,然後在第二塊硬盤下裝Gentoo。其實我還沒決定好是不是要用回Gentoo,畢竟編譯太折騰人了,我的機器又比較吵,晚上編譯等於直接讓自己失眠,可別的發行版怎麽用著都不爽,很多東西都不是我能控制的,我覺得這樣無論對學習和實用來說都不好,看來我還是逃不開Gentoo的五指山的了。只是KDE3.4散裝的ebuild還沒有出來,得再等等,也正好給我時間整理硬盤和重裝win(沒辦法哎,多媒體和網上銀行還是得用WIN的)

我不怕輸

【1:16 pm By Jim】

走到一個路口 你放開我的手
綠燈還在等候 不向前不向後
我們從此分手

這情景太真實 記住時間地點日子
唯一的方式 就是表現懂事
今天變成歷史 將來寫個故事

我不怕輸 就算有點無助
寧願開始孤獨 也不要繼續糊塗
失戀過才會懂 分手原來輕鬆
太堅持才是束縛

我不怕輸 感情沒有勝負
愛到先甜後苦 至少有一點領悟
放手 寂寞也是一種自由
有多難過 最終會過 就已經足夠

這個分岔路口 我不想再停留
紅燈之前回頭 你對我揮揮手
我們還是朋友

做朋友的意義 你我各自不同道理
是男生自私 是女孩太幼稚
請原諒我不是 騙自己的騙子
我在回憶往事 己成為過去式
女孩們都是這樣懂事
難過最終會過就己足夠

###################

因爲裏面的一句歌詞,喜歡上了這首歌,很㊣點,還有Piano Version,也很棒,值得推薦~

《Thinking In Java》筆記 - Chapter (4)

【12:43 am By Jim】

一、構造函數(Constructor)
(1)有別於 common function 的命名規則,constructor 名稱必須與 class 名稱相同;
(2)constructor 沒有返回值(注意區別於 void);

二、函數重載(Method Overloading)
(1)通過 Arguments List 以至於 Arguments 不同的順序(一般不採用這麽 SB 的方法)區分;
(2)primitives 的重載
    1)所提供數據的類型小於引數的類型時,該數據的類型會獲得晉昇;
    2)與1)反之,若大於,compiler 會報錯;
(3)Return Value 不能作爲重載函數的區分基准;

三、Default Constructor
(1)當 class 不具備 Constructor 時,compiler 會自動合成一個 Default Constructor,如:

// new Bird() 就是 Compiler 在生成 nb 時強制合成的 Default Constructor
Bird nb = new Bird();

四、關鍵字 this
(1)this 代表當前對象,並自動生成 Object Reference;
(2)通過 this,在 Constructor 中調用 Constructor,如:
/**
** 1)通過 this 只能調用一個 Constructor;
** 2)調用動作必須置於最起始處;
** 3)Compiler 不允許在 Constructor 以外的函數內調用 Constructor。
**/
Flower(int petals) {
    System.out.println("Flower(int petals)");
}
Flower(String s, int petals) {
    this(petals);
}

(3)static 函數沒有 this(所以可不必經對象來調用);static 函數中無法調用 non-static 函數;

五、Cleanup
(1)Garbage Collection 不等於 Destruction;
(2)Object 有可能永遠都不被回收;
(3)Garbage Collection 只回收由 new 分配的內存;
(4)finalize() 主要用於“對象生成”之外方式分配的存儲空間;
(5)
    1)System.gc():強迫性的作用於所有對象;
    2)System.runFinalization():作用於未被終結的對象;
    3)引數 all:以上兩個。

六、成員初始化
(1)初始化的優先級高於 Constructor;
(2)static 的初始化只會被執行一次;
(3)static/non-static 的明確初始化:

//static 的初始化
static Cup c1;
static Cup c2;
static {
    c1 = new Cup(1);
    c2 = new Cup(2);
}
//non-static 的初始化
Bra b1;
Bra b2;
{
    c1 = new Bra(1);
    c2 = new Bra(2);
}

(4)Array 的初始化
    1)不允許直接定義 Array 的大小;
    2)Array 可相互賦值(Reference 的複制);
    3)Objects Array 是由 Object Reference 而非 Objects 自身組成的;
    4)Objects Array 初始化的兩種形式:

//Objects Array 初始化形式之一
Integer[] a = {
    new Integer(1),
    new Integer(2)
};
//Objects Array 初始化形式之二
Integer[] b = new Integer[] {
    new Integer(1),
    new Integer(2)
};

(5)Multidimensional Arrays

//多維數組初始化示例(int)
int[][] a = {
    { 1, 2, 3 },
    { 4, 5, 6 }
};
//多維數組初始化示例(Integer 對象)
Integer[][] b = {
    { new Integer(1), new Integer(2) },
    { new Integer(3), new Integer(4) }
};

« Previous PageNext Page »

This work is licensed under a Creative Commons License .
Get free blog up and running in minutes with Blogsome | Theme designs available here