Older blog entries for yusufg (starting at number 6)

Lots of buzz about Apples new Safari browser. So far David Hyatt hasn't said that he can't work on Phoenix (would this be a conflict of interest for him). Whilst I would really love to work with Mac OSX, I think Apple hardware is quite expensive given that the economy is still in the doldrums

One thing which I found interesting is that the Safari team consists of a lot of ex-Eazel guys. It's strange to see so many ex-Gnomer's now using KDE code daily.

Boris Barsky has been mentioning at times that whilst Gecko rules today in terms of compliance, if work doesn't continue to fix some design issues, it may lag behind. Who knows, maybe at some point someone will comeup with pluggable rendering engines for browsers (switch between Gecko,KHTML)

Lurking on the GCC list, I have read a fair amount of posts from Apple which describes how they would like to speed up GCC (I think they have a 6x target). Hope they can send some patches over soon or maybe this might occur after the next keynote where Steve Jobs will announce "Turbo Apple GCC" :)

Got an email from mjcox describing the end of life policy for various redhat releases including the recently released Redhat 8.0 (Psyche). According to the policy, Redhat is going to end-of-life (in terms of errata support) all their releases within 12 months of their release. For now, all their current releases are being EOL'ed on Dec 31st 2003.

Whilst I understand the motivations behind this, I feel that 12 months is too less. Obviously, Redhat would like people to switch to Redhat Advanced Server and Redhat Advanced Workstation which are going to have longer EOL periods, however one of the reasons (cost) of switching from Windows to Linux goes away since RHAS is around $900/server.

The suprising thing is that barring Linuxtoday, none of the news site such as Slashdot, LWN have posted any news on this.

I guess I should file a bugzilla RFE for up2date so that it can do at up2date --distrib-upgrade. Reinstalling the entire machine every year is going to make a lot of sysadmins quite unhappy

Had a peek at the strstr implementation in glibc. Not sure what algorithm it uses though the author claims its the fastest (does it beat KMP,Boyer-Moore ?) Also, glibc has some assembly language versions of string functions which are supposedly used when you compile with -O1 upwards. I should try to get some zen with objdump to see if I can figure out if the assembly versions get used in x86 or not

Got a reasonable thread to my question on freebsd-net about FreeBSD behaviour when the listen queue is full. It seems that it sends an RST which Bill Fenner [IETF routing area director] and Wietse Venema of, Postfix fame seem to think its a very bad thing

Hope the freebsd hackers can get a definitive reply soon and make the appropiate changes to the listen(2) manpage

I asked Jeff Garzik what Linux does in this situation, I looked at the code but couldn't figure it out. BSD code seems easier to read (having the design/implemation of the 4.4 BSD book by your side helps). If anybody else knows about this, let me know via a diary entry

No reply from Jeff as yet, maybe he got caught up in the stupid BitKeeper flamewar on lkml. Daniel Phillips is a smart person, just don't understand why he had to suck up so much bandwith/time for this issue

Came across this page about WindowsXP DNS resolver and its own caching/security policies

It seems that Microsoft is admitting that out of the box, WindowsXP can be cached-poisoned :). Ohh, and in order to secure the box, you need to hack the registry which may require you to reinstall your OS. Hmm, and they say Unix is difficult to use and inflexible :)

Now, I am not sure if that is still the case if the resolver points to secure caches such as dnscache. If that is so, its a disaster waiting to happen

Had a look at the Skipjack kernel SRPM to see what patches were incorporated in Redhat's upcoming release. O(1) scheduler, rmap and low-latency seemed to be the most interesting. It would also be nice if there was documentation in the kernel src rpm which said what each patch did

Anyway, with this combo I don't think I'm going to be using stock kernel's for a while

Fired up red-carpet to see if the RPM update was available in the Redhat 7.2 channel, it still isn't even though the errata has been out since approximately a month.

I can manually download and update the package but there seems to be no information from Ximian whether doing so would cause bad juju for RedCarpet. I know RedCarpet won't touch kernel upgrades, what other packages won't it upgrade ?

US Patent number 6368227 rocks :)

Children, please break out your piggy banks