sorted by: recent | see :
popular
Content Tagged thoughts
DRBD+ is going open source!
Today is an exciting day for us. We have announced that with the upcoming DRBD 8.3 release (currently scheduled for the end of this year), all those features that are currently commercially licensed in our DRBD+ add on will be merged into the GPL DRBD main source tree. That means that stacked device support, huge device support (larger than 4TB per device), and checksum-based resync are all coming to DRBD.
Is this something that we haven’t done before? No it’s not. We have, in the past, repeatedly merged DRBD+ features into DRBD. We have not, however, done so previously on this scale. That is new.
How will this affect our customers and users?
- First of all, if there ever was any relevant functionality gap between proprietary storage replication solutions and DRBD (there wasn’t — we had DRBD+ for that), not even a trace of any such gap will soon be left in DRBD as a fully open source, GPL-licensed solution.
- Secondly, for those would-be customers that previously had to back away from DRBD+ because it was not open source, and instead had to rely on open source drivers for proprietary hardware, that concern is now gone.
- And thirdly, it makes for much easier integration of DRBD into certified, fully open source high availability source software stacks, even for huge storage sizes. Whether that stack is maintained exclusively by us, by a partner, or by both jointly.
Has this been an easy decision? No, it took some contemplation. But we’re absolutely confident that it’s the right step in the right direction. So do watch our DRBD community web site for announcements regarding the 8.3 pre-release cycle and release.
Two days of great fun at work
You know, normally I use this blog for posting thoughts primarily focused on technical aspects of DRBD, Linux, HA solutions, or (normally) a combination of all three. This one is an exception.
Why I hate YUM
I really hate YUM, the crappy-ass apt wanna-be that all the non-Debian distros wet themselves over. Yes, it’s better than what they had before, which was NOTHING. But it is absolutely inexcusable that, when apt was already available, powerful and quick, that they wrote YUM. Not because I think everyone has to use my favorite toy, but because it’s a worse tool. It’s it’s slower, it’s stupid and it gives terrible feedback.
Let’s start with today’s beef. I tried to do this:
yum install libselinux-devel
on a just-installed Fedora 7. What I got was this:
Transaction Check Error:
file /usr/share/man/man8/matchpathcon.8.gz from install of libselinux-2.0.14-4.fc7
conflicts with file from package libselinux-2.0.13-1.fc7
file /usr/share/man/man8/selinux.8.gz from install of libselinux-2.0.14-4.fc7
conflicts with file from package libselinux-2.0.13-1.fc7
Tell anybody what the problem is? First of all, has anyone ever tried installing this package?
It turns out, what it’s trying to do is install the x86_64 and the i386 version of this package, and each one of those packages want to install those manpages. It seems fairly common to me that people might want to install this package on a 64-bit server. Why does it install the 32-bit lib? Why do the packages conflict? And why does the error message suck so bad?
Speaking of terrible error messages. Try this:
yum install kernel-dev
Wait, you might exclaim, being a RedHat person, this isn’t a Debian system, we name our packages -devel. Quite true, my bad. Except what does YUM tell me?
Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Nothing to do
Hm. Does that mean the package is already installed? Is it up to date? Or do we not even have a package named kernel-dev? Here’s another way to do the same thing:
mtaylor@qualinost:~$ sudo apt-get install kernel-dev Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package kernel-dev
Look at that! E for error, and then it shock tells me what the problem was.
The work has already been done! If you don’t want to use APT, that’s fine, you could at least look and see what it gets right and then improve on it! I mean, that’s the way this whole Free Software thing is supposed to work, isn’t it? Granted, maybe having to specify YUM repositories in chunks of XML is an improvement, and maybe I’m not seeing all the wonderful ways in which this is better than the crappy old APT from Debian.
But I don’t think so.
Captcha's
Captcha images are quite effective at halting comment spam. However, besides being inherently inaccessible, they're also quite annoying to regular users.
How to maintain a spam-free site, without annoying your users? That's the question.
One idea would be to make the captcha-generating code more intelligent. The NP_Captcha Nucleus plugin already does this in a limited way, by not generating challenges for registered site members. But that's only a start. There are a lot of possible tweaks.
How about never displaying the captcha challenge immediately? After the user hits the submit button, a set of rules (blacklist, heuristics, ...) could be used to identify a comment as "likely being spam". Only in such a case, the user would be presented with an actual captcha challenge:
Result: in most cases, a user can post comments without interference of any kind. Only when a message has spam-like characteristics, an extra step is required.
How about the visually impaired, I hear you ask? The captcha should be accompagnied by an alternative audio-challenge. The challenge for developers here is to make such an audio file as good in telling computers and humans apart as a visual captcha. One site where I saw an audio captcha in action was the Passport registration wizard.
By the way, the same technique could be applied without the captcha. If the post looks like spam, the user could be allowed to fine-tune it, rather than dropping the post immediately. This is something which has annoyed me in NP_Blacklist in the past: a valid comment was seen as spam, a redirect to the spamtrap page occurred, and hitting the back button returned to an empty comment form :(
Just a bunch of thoughts...
