grimsniffer: (Default)
(For the beginning of the story, see my previous post).

So I continued hacking at the problem last night.
After some testing I discovered a few things:
1. K/Ubuntu Karmic operates without an xorg.conf file. You CAN create one and then it'll use it, but if one does not exist (as is the default) it doesn't load.
2. If I created an xorg.conf file with the automatic fglrx command: aticonfig --initial, X would hang after login - not even responding to ctrl-alt-del - forcing me to perform a physical shutdown.

So, to work we went!
I kind of want an xorg.conf file, because well... I have a graphics card and I want to use it. So I began tinkering with the file a little to see where the problem lied. I had an irritating feeling (discussed in the previous post) that the problem was indeed with the proprietary ATI fglrx driver. So I attempted to define my video device and screen section as the generic "vesa" driver.
No dice - X still hanged on login.
Just to make sure, I again deleted the xorg.conf file completely - and then I /could/ log in (crappy graphics and no sound, but I could).
So I decided to uninstall the fglrx driver and work with the open soruce Radeon driver (which doesn't fully support the Radeon card in my Studio XPS 1640, but it's still better than using the generic vesa X-windows driver).
I did an "apt-get --purge" to all the relevant packages (again, for obvious reasons I didn't copy the exact commands and outputs), installed the open source driver's relevant packages, did an X --configure and (for good measure) recreated the xorg.conf file to point to the proper driver.
X still hanged after login, with exactly the same behaviour.
Deleting the xorg.conf file here too allowed X to load.
Which got me thinking fglrx somehow stuck itself somewhere else (kernel module?) and kept overriding my configurations in xorg.conf. Some digging through the 'net found this page - which solved my problem (the more aggressive method mentioned there, purging both fglrx and the open source driver, and then reinstalling the open source driver).
During this process, seeing as I was messing the hell out of the system, I decided to give Xmonad (about which I've heard lots of good things) a shot. I did, and even though I had to configure and personalize quite the hell out of it to make it work properly - MAN it's a wonderful window manager! I would seriously recommend it to anyone not minding wading through very poorly documented Hasksell configuration files. Seriously, it's worth the effort (more on that perhaps in another post).

So, what did we learn from all of this?
1. The new version of ATI's proprietary graphics driver has SERIOUS issues with Kubuntu Karmic and Dell Studio XPS 1640 laptops. Maybe they'll issue a fix, for now I'm content working with the open source driver (especially since I'm using Xmonad and don't really need 3D window managing to improve my productivity).
2. ATI's proprietary graphics driver needs serious convincing to remove itself from your system.
3. Take more coffee breaks if you don't want to heavily damage your system because of lack of attention (I learned that quite a few times but somehow always repeat the practice).

And now - to do some fine tuning with Xmonad.
What's Hasksell even used for normally?


grimsniffer: (Default)
So... I decided to try this Windows7 thing everyone's been rambling about (I miss playing World of Warcraft every now and then (and cba to install it on linux and fix the installation every week when a new patch comes out), I admit my shame - seeing as I don't watch TV ever, I think I'm allowed this one vice... well, that and smoking... and being a vegetarian... and being psychologically unable to wear matching socks, and... (three hours later)... and my excessive use of parentheses... and never being able to finish a thought when writing... so yeah, vices galore, oh... and sometimes when I see a loose brick in the sidewalk, I... (trails off in uninteresting rambles...) ).

Anyway! (Do yourselves a favour and skip here after reading the first line or so of the above paragraph, seriously)

So, I have a Dell Studio XPS 16" laptop that has been running Kubuntu ever since I got it.
It has a HD of 320GB which I hardly use, seeing as all my important shite's on my server computer (which has 1.25TB of storage). So I decided to partition the thing, giving 100GB for a Win7 partition.

The process I was going to follow was:
1. Boot the computer with the GParted boot disc, shrink the ext3 partition, and create an NTFS one.
2. Boot back to Kubuntu to make sure it's still working.
3. Install Windoze7.
4. Restore Grub through the Kubuntu Live CD (Windows has a tendency of being rather greedy and erasing whatever's in the MBR, placing its own bootloader instead) and configure it to dual-boot Kubuntu and Windows.
5. Drink coffee.

So! I reached point number two when all hell broke loose.

I booted into Kubuntu and received the KDE login screen. I entered my username and password, received some flickering in the screen, and then came back to the KDE login screen.
I tried entering the wrong password just to check if it were an authentication thing and KDE indeed told me I had the wrong password. Meaning it only loops on a successful password.
So - I started debugging it.
Logged in through console (that was fine, accepted my password with no issue).
Tried to start KDE manually with "startx" and then received a bunch of xorg.conf errors about X being unable to recognize my ATI (fglrx) driver. (for obvious reasons I couldn't really copy-and-paste the errors here for posterity, my apologies).
So, one thing lead to another and I "aticonfig --initial"ed to rewrite the xorg.conf file. <======= <Remember this critical stage and look at the page title again>
This didn't work, I rebooted and received the exact same behaviour.
This is where I skipped to step 5 and went to stretch my legs a little.
When I came back, some more tinkering showed me that the reason KDE couldn't really find any drivers or anything is that I had (very wisely) left less than 1GB of space in the ext3 partition when doing the partition scheme with GParted. It didn't really have anything to work with - couldn't even use the swap partition.
So I deleted some stuff and rebooted. The login loop to KDE was still there. However, now through the console I was able to "startx". But (remember that driver reconfiguring thing...?) KDE couldn't find any graphic card through the driver.
So I thought to myself "Oh well, probably because I recreated the xorg.conf file for no reason whatsoever, deleting all the custom configurations I've had there to make my card work when first installing the computer. No matter, there's no way in hell I can remember them now, but "aticonfig --initial" automatically backups the old file, I'll just replace it with the new one. No harm done."
Except I soon discovered that "aticonfig --initial" couldn't backup the file, because that would require a properly working swap partition (or at least a minimal amount of HD space) which I did not have. So... no backup. Wonderful.
I spent the next few hours trying to reinstall fglrx. Then trying to remove it and install the Radeon open source driver... no dice. I honestly don't know what the hell is up with it.
Went to sleep rather frustrated. Will keep hacking at it tonight. We'll see what happens.

grimsniffer: (Default)
While drinking my morning coffee, I had this slap me in the face.
To sum up, because of a revenue deal between Canonical and Yahoo!, the default search engine in Firefox on the new K/Ubuntu Lucid Lynx will be Yahoo! instead of the traditional Google.
This, as mentioned in the email I linked to, is obviously easily changeable, but that's not really what makes me wrinkle my nose.

What DOES make me wrinkle my nose is the revenue deal itself.
I'm not a big fan of Yahoo!, to say the least. I've got quite a long internet memory, and I remember them randomly spying on emails during the September 11th extravaganza - I also remember Yahoo! buying egroups.com and basically deleting any group on it they didn't like... and yes, I remember the much more recent possible Microsoft deal. So, Yahoo! - you get no luck with MS so you go over to the other trench to see if there's some money to be made there instead?

Seriously. So far I've had no problem with Canonical being a commercial company, including closed source programs as default in their OS, and generally Macinotoshizing (yes, that's a word! :) ), my operating system. Mostly because all of those things were easily removed. This new development however (even though it can also be easily removed of course, as mentioned in the linked post - and kind-of obvious to anyone who's ever used a web browser) does kind of cross a line. I don't like Yahoo!, I don't like them being associated even in a remote manner with my OS... and the fact that I'm not paying a dime for my OS and thus not supporting Yahoo! in any way doesn't seem to make it any better.

So I'm seriously considering moving to greener pastures. Kubuntu's been fun so far though... What then? Back to my Slackware days? All the way back to my Debian days?... Maybe try Gentoo for once? Any ideas from my so-far-not-so-substantial reader-base? :)
grimsniffer: (Default)
I just found out (month late, I know) that the new linux kernel FINALLY includes 3D support for my graphics driver.
Maybe I'll soon get a chance to actually gauge the full performance of my laptop for the first time.
I can't be arsed to compile it on my own, because out of previous experience, a custom kernel tends to wreck havoc through Kubuntu update - and I can't be arsed to make maintaining my home PC a full time job. So I just prefer to let the Kubuntu update do its thing every few months (I know I've complained about this very updater in a previous post - I suppose laziness comes before forethought and practicality).
A little bit of reading showed that the new Kubuntu 10.04, codenamed Lucid Lynx (I seriously can't wait for when they rollback through the alphabet and reach the letter F...) will include this new Kernel. Well, just four more months to wait.

In other news - I finally tackled bug-2075 completely. It was one of those "I keep thinking I'm done, but then discover this weird scenario which forces me to rewrite everything". Like bug-2169, this one also required quite a bit of code-rewriting.
I haven't submitted a patch yet because I need to clean up the code (quite some rewriting was done, as I said)... Will get 'round to it tonight, I hope.
New stuff this does:
* Changing the email you get when you send a copy to yourself to "You sent [[username]] a message" (it used to be "[[your username]] sent [[your username]] a message").
* Changed the corresponding email body text to link to the profile, journal, etc. of the person you sent the message *to*.
* Changed the subject of the copy message itself in your DW mailbox to include a preceding "Copy of: " - just to make things more clear.
* Added limited support to sending a copy of a message you sent to multiple recipients... I wanted to add full support (stuff like you getting an email saying "You sent X, Y and Z a message on Dreamwidth", but because of the way compose.bml is written, it would have required considerable rewriting... and since it was just a "nice to have" extra thing and not mentioned in the bug requirements, I wrote that off as something to do at another time.

I've got another minor bug assigned to me. Hope to solve that rather quickly, and then will start working on the HTTPS browsing mode feature.
grimsniffer: (Default)
(Yes, apparently sometimes I'm going to include non-technical posts here. I'm going to label them as "off-topic").

In the past few months, there's been some tension between my government and the Turkish government. The tension started over a TV Series depicting Israeli soldiers and Mossad (secret service) agents as animals and child killers.

There's been mutual slander thrown between the two governments over this series, but on the whole things were kept on a low key.
For some obscure reason yesterday, even though this thing had been going on for a few months, the Israeli Deputy Foreign Minister decided to summon the Turkish Ambassador to Israel in order to lodge an official complaint about the show.

That's all well and good (if you happen to agree with forcing other countries to censor their citizen's media, which I don't, but that's another discussion), except that Mr. Ayalon decided to publicly humiliate the Turkish Ambassador by refusing to shake his hand in front of the cameras, removing the Turkish flag from the Ambassadorial meeting and forcing him to sit on a lower sofa.
Yes, that is what the elected representatives of my country see as diplomacy.

So after this idiotic charade, the Turkish government - for obvious reasons - demanded an apology from the Israeli government and from Mr. Ayalon himself. The Deputy Foreign Minister, while still standing steadfast behind what he had done, expressed regret about the way he had done it and about the humiliation of the Ambassador.

Turkey did not accept this non-apology, and threatened to pull its Ambassador and reconsider its relations with Israel if it doesn't receive an apology for his treatment by the Deputy Foreign Minister.

After much debate in the high levels of my government (reaching both the Prime Minister and the President), over a Deputy Minister uttering three words and acting like a Human Being for a change, an apology was issued and Turkey accepted it.

Now, what most irks me about this entire story (and believe you me, quite a few things irk me about this story) is that for some reason an apology in our society is deemed as something that humiliates the person apologizing. People seem to think that if you apologize for a mistake you made, then you reveal yourself to be a person capable of making mistakes - and thus reveal your weakness in a world where... no one... makes... mistakes... ever...? what?!

We are Human Beings. We make mistakes. All of us. Every day - multiple times. True - not all of them as colossal as the one Mr. Ayalon made by publicly humiliating a foreign official. But mistakes are made all the time.

If I hear a person apologize for a mistake he made, it doesn't make me think less of that person. On the contrary, it just makes me respect them all the more. I gain respect for them as people who are willing to accept their mistakes, accept the fact that said mistakes hurt someone else, and apologize for having done so.

In this case, the Deputy Foreign Minister actually admitted that the treatment of the Ambassador was wrong, and promised not do that in the future. But he refused to utter those oh-so-important three words: "I am sorry." Why? Who knows. I certainly don't understand it.

I regret that Mr. Ayalon only apologized because he was forced to do so, but I'm glad that he did at least that. It doesn't gain him much respect in my eyes, but it's better than nothing.

Great is the man who knows to admit his mistakes, and thus admit he is Human. If people learn that lesson, a lot of needless conflicts and blood-shed would be avoided. Apologies are after all, not a sign of weakness - they are a sign of greatness.
grimsniffer: (pic#377996)
Well, just a brief post in the "I hope someone finds this helpful" category.
I'm using Vi (or more accurately Vim) to edit code on DW. And in the past few weeks of doing so I've added some dw-specific tweaks to my .exrc file beyond the usual spam that's there. So here they are, in case anyone else wants to use them:


# To adhere to the programming guidelines, tab size and spaces as tabs.
set tabstop=4
set shiftwidth=4

# Just for convenience's sake. Not really DW specific but some DW Vi stuff depends on it.
syntax enable
set cindent
color delek

# Getting Vim to recognize bml files as perl files for purposes of syntax highlighting.
filetype on
au BufNewFile,BufRead *.bml set filetype=perl


grimsniffer: (Default)
Excerpt from a conversation I had at the workplace (exact details aren't provided for reasons of NDA):

System Architect: The frames are filtered into several different categories, each category having its own set of parameters which tell the device how to treat packets from that category. We then--
Me (Application Integration): Wait, what did you say they were filtered by?
SA: This parameter.
Me: But this parameter is one of the parameters in the category they are filtered TO...
SA: Yes.
Me: Well, if they're labeled by the initial filter as members of one category and then the category parameters label them a second time, we can have a situation where frames are labeled as members of a category which the very same category denies they are members of. We could also have a situation where frames are labeled as members of just one category, while three categories see them as members.
SA: I don't see a problem with that.
Me: ...
SA: Well, the user will simply have to be careful not to create such a situation.
Me: facedesks


In other news, I say this a lot (especially to myself), but I'm nearly done with bug-2169. It was somewhat challenging at several places, especially figuring Storable out (thanks [personal profile] afuna!), but if nothing unexpected happens - right now it's just doing some writing (I almost wrote "finger work" but then thought better of it :) ), and cleaning up the code. So we should have (better) draft support soon, yay!

Up next is the HTTPs browsing bug. Though I might want to take a short hiatus with some minor bugs, because this last one has taken quite some work all in all, and the HTTPs one likely won't take any less.
grimsniffer: (Default)
Just a very quick rant, might expand on it later if I have time:

Yes, it's true - you are always asked to confirm a system update.
Yes, it's true - you can browse all the packages that are being updated, changed and can easily find out what changes are going to be done exactly.
Yes, it's true - most of these updates have release notes alerting for specific issues that the updates might cause.

But for fuck's sake - when I update I usually have 30+ updates (especially in this past month or two since Kubuntu 9.10 came out), and I'm sorry, but I just cba to start going over each and every one of them to see how my custom changes might be affected.
And seeing as I come from the "if stuff asks to be updated, it's probably important and should be updated right away" mentality, I rather often find myself with essential little services simply not working.

So when KpackageKit updates paths in my custom Bind9 files (God knows why), I find myself spending almost an hour finding out exactly what happened and why I can't access my Apache server the day after. An hour I really wanted to spend actually fixing bugs. Bleh.

Might just have to stop automatically confirming updates and just leave them for a specific time during the week in which I actually go over everything they're doing, because this is the third time in the past month this has happened (you'd think I'd learn to narrow it down quicker by now, eh? Or at least learn that whenever this happens, I should drink a cup of coffee, smoke a cigarette, calm down and THEN start finding out why I can't test the code I've just written... angry/frustrated system-work is sloppy system work).
grimsniffer: (Default)
Well, bug-154 is currently fixed and waiting for a review and eventually a commit. My fix seems to pass all scenarios I can think of, but with me not yet knowing the Dreamwidth site very well, I won't be surprised if it has to be edited a little.
The bug involved the "Reply" and "Thread from Start" links not appearing in comments that are opened in new pages (having the ?replyto argument).

The core2.s2 file has a print_interaction_links() function that's in-charge of printing the interaction links to entry and reply comments (Those Link/Reply/Thread From Start etc.) comments you see under each post and entry you read.
This function had a conditional that would display the "Parent" and "Thread from Start" links only if their values were not null in the hashref passed to said function by ReplyPage.pm. So then it was just a matter of going to ReplyPage.pm, finding the hash and adding the relevant values. For some reason (which still escapes me) the hash-ref wouldn't accept variables declared earlier in ReplyPage.pm, even if they were in the same scope as it is. Meaning I couldn't use the various objects already declared creating the comment itself. So I basically had to declare these values in the hashref by creating a comment object out of the dtalkid I already had, and assigning its parent_url() return value to the value in the hashref (or the threadroot_url() return value, to the threadroot_url value in the hashref). This passed it all to print_interaction_links() in core2.s2 and voila! All works. Tested it in quite a few scenarios (comments of entries, comments of comments, entries as parents, heavily nested comments, different themes, etc.), and it seemed to work well. Let's see if someone manages to find something I've missed.

I was planning on publishing a proper walkthrough (and crosspost it to [site community profile] dw_dev_training), detailing my work process in solving this bug - but since this was my first bug working on Dreamwidth, the learning process was rather complicated. Took me about a week on-and-off to figure it out, and I'm not sure I can recreate all the phases I went through. I'll take a look at my notes in the coming days and see if I can glean the proper workflow (or at least the major parts of it).

Now starting work on bug-2208. Hopefully it won't take me as long.

Bug-154

Dec. 9th, 2009 08:09 am
grimsniffer: (Default)
Well, I'm currently working on bug-154. I plan on posting a full walkthrough when I'm done... but for now I'm still banging my head against it.
It seemed at first like a rather trivial thing, but after a few nights of work, and quite a few hours of sleep lost over it, I learned better.
Yesterday evening I managed to find where the ?replyto pages are generated, or at least I think I did. At the time of this writing I'm pretty convinced they're created through talkpost.bml, passing the 'replyto' argument to the $init variable (I'm not by my private server, so can't really be sure what this variable points at, but it should be easy enough to find out).

I think it's mostly taking me so long because looking for stuff in the DW code is a rather messy process with which I'm not yet fully familiar - and talkpost.bml specifically is a monstrosity beyond words. I'm told it's going to be overhauled, or better yet - completely replaced - soon.
Just before I went to sleep, I decided to do a CVS update - mostly to clean all the debugging crap I've been putting in the code through my attempts to try and figure stuff out. But the hour was late, and I wasn't thinking straight - so I ended up vanila-ing my server. Shouldn't be too hard to fix, but I definitely took that as a "time to go to bed" sign.
Lesson learned: don't do major codehack steps when you're not fully awake. Or well - who am I kidding, lesson-not-learned-for-the-hundredth-time.

I'll keep at it during the weekend, hopefully I'll make some progress.

After I get it done (and post the walkthrough), I plan on posting a tutorial here regarding my torrent downloading setup at home (rtorrent+GNU Screen+a perl Email fetching and parsing script).
For now though, after I got this out of my system - back to the stuff they pay me for: delving through IGMP and OMCI.

grimsniffer: (Default)
Recently at work, I've been delving into the IGMP protocol structure. And this as always, means reading its RFC - which in my case means going over three different RFCs (IGMPv2, IGMPv3 and IGMP Snooping). I never minded reading RFC documents, and very deeply investigating the various bits and pieces of a certain networking protocol. I actually find it rather interesting. But when you have to read a few tens of thousands of words for most of your waking hours, your mind usually begins to wander...

While pausing to clear my mind, I took a look at RFC 1, as I'm sure most curious networking people have done at one stage or another. It's entitled "Host Software" and is dated April 7th, 1969. It speaks of recommendations for IMPs (Interface Message Processors) which seemed to have been refrigerator-sized machines connecting the four sites of the ARPANET. Today they are known as routers, and well... we all know how big they are.

The first RFC was a result of several meetings and exchanges between four representatives of the four sites of the ARPANET. All of them graduate students who were constantly working out efficient ways to make these computers speak to each other, in a time where "computer networking" wasn't even a field. All of them reached the wise conclusion, that if they were going to make this thing work - they had to reach some agreements together regarding how they want this "protocol" to function. And so they released this document to all the relevant people as a very raw suggestion for a protocol, openly inviting additions and comments.

Reading about this "Host Software", I couldn't help but smile. These brave pioneers actually wrote a full networking protocol years before TCP\IP, the 7 layer OSI-model or any sort of guidelines as to how this could be done. And it's definitely apparent. This one protocol mixes both packet routing (or messages, as they called them), error checking, session management, bandwidth allowance, etc. etc. Things that any sane protocol designer today would split across at least three or four layers. And yet they made it work - and that document laid down the foundations of what we today call "The Internet".

By reading the first few RFC documents, you very clearly see the spirit of camaraderie and sharing reflected by them. These people cared about their work, they were passionate about it - and they were passionate about cooperating with one another in order to complete it. It's a spirit that I see nowadays in the Open Source community, but sadly enough - not in the recent RFCs. Networking has become a vital necessity in our modern world, and when the co-writers of RFC documents nowadays are high-ranking corporate-types from Cisco and the like - I can definitely understand why that spirit has died.

Corporate interests and capitalism (if I'd be allowed to wear my Marxist hat for just a short moment) have taken away sharing and friendship. They have taken away the passion from the world of computer networking. This can be very easily seen by reading the first fifty or so RFCs and then reading a recent one. It seems as if they come from vastly differing approaches, only clinging on to similar formats and typesets for tradition's sake.

Nowadays, networking devices and applications are developed with the RFCs and standards as rough guidelines. If there's a line in an RFC that's inconvenient or would take too long to develop, it's usually disregarded (even if it's marked "MUST"). The company developing the product deciding to only fix it if the need arises. The companies do not wish to be 100% compatible with the standard (or with the recommendations), they only wish to save time and thus - money. This field is no longer a passion, it's cold necessity and monetary interests.

And that's why, in my opinion - computer networking (and indeed, most other fields of public or enterprise computing - but more on that some other time) has dwindled so much in recent years.

It's true that computer networks are much larger today, and do considerably more than they did in the past. Exponentially more, in fact. But it's very clear that the addition of this new functionality is at the expense of making the old functionality actually work better. Network equipment is known to be unstable (not as much as server computers, obviously - but still unstable). It has to constantly be maintained, upgraded and patched. Networking is not the robust science that it used to be in those early days of IMPs and RFC 1 - it is at best a large collection of half-working devices of a million different kinds and sorts that somehow manage to work together... most of the time.

When minds come together and try to work something out because they're passionate about it, because they simply want to bring something to an artistic perfection - wonders come out. The foundations of the Internet are laid down.

When corporations artificially create such collaboration, we get three different versions of IGMP over less than ten years with severe issues of backward-compatibility built right into the protocol, and companies not even fully adhering to those protocols later.