Economic Left/Right: -2.25
Social Libertarian/Authoritarian: -5.03
Jorge, go jump off a cliff, you intellectual midget.
Thank you John Marrett for the DVD+Rs of Debian sid! I’m currently upgrading packages that haven’t been upgraded since May 2003.
July 21, 2004
Political compass co-ordinates
July 16, 2004
Congratulations Andrew
So Linux.Ars rides again, this time with Andrew’s Mono writeup as the primary attraction. And quite an attraction it’s been.
I never did manage to finish a traffic shaping writeup or do some de-controversialisation of the writeup (which has earned Andrew much flak). Oh well. Andrew will be writing a series of writeups on Mono in coming weeks; as long as he can keep it up, we shouldn’t see much of an issue regarding paucity of content, what with one or two interviews also in the works.
July 12, 2004
Coming together
Evidently things are finally going my way. (No, Lady Luck, I do not will thee to change that.)
Thank you, John Marrett, for getting DVD+Rs of the current sid packages ready to send me, I guess I’ll finally be able to upgrade the 1,027 outdated packages that haven’t been upgraded for ages (some since I was last on broadband, which would be in May 2003).
1027 upgraded, 139 newly installed, 26 to remove and 17 not upgraded. Need to get 652MB/652MB of archives.
We’re preparing a new issue of Linux.Ars which, if all goes well, will be ready by Tuesday. On the agenda this week: the Mono 1.0 release and an introduction to .NET Framework programming using Mono (thanks, Andrew); a writeup on traffic shaping and traffic control using the iproute2 tools and especially the Wonder Shaper; a writeup on ndiswrapper (thanks Adam Skutt); and a news item and /dev/random (thanks Stephan). Things seem to be coming along fairly well; we have about two more days before we have to submit it.
As far as that last post is concerned (about the mp3 aggregator we were considering writing), it seems I misjudged what was wanted — the original idea was to aggregate the streams people were listening to by having a fixed queue of songs from different streams (a sort of first-come-first-served scheduling) with newer ones discarded and a song queued only if there’s space in the queue, and having this stream multicast to every user. I thought it might be a good idea to alleviate the bandwidth pressure on the single-point aggregator by dynamically creating bandwidth-based propagation trees (so that each node’s bandwidth is optimally used in participating in the multicasting; an “elected master” does the aggregation based on its bandwidth; each user apart from the “master” passes its current mp3 along if given the go-ahead). However, in the end, the initiator (Kyle) realised that not everyone likes the J-Pop and anime soundtracks that appear in the streams certain #linux people listen to, so the project pretty much fizzled out. 
I still like my distributed aggregation idea, but for the fact that it might land me in legal trouble (broadcast rights and all that).
I bought myself a USB 2.0 5.25″ drive enclosure and a PCI HBA (to make my burner portable) as well as a UPS. The UPS is charging. Unfortunately, it has no monitoring capability(!), but rather seems to be a glorified invertor meant for PC use. It emits this annoying beep when its battery level is low, so for the moment I’ve turned it off as it charges.
Last Friday, the entire street was flooded with 30″ water. I had to wade 400 feet in dirty water halfway up my thighs to my place because the wimpy taxi driver who took me home was afraid his engine would be flooded with water and stall. Fortunately, it all drained away during the night. It’s still raining outside . . .
It’s getting warmer yet rainier here. Bangalore seems to have an odd climate. I hope I won’t have to endure it for very long.
I tested my blood sugar at three different times yesterday. It turned out to be in normal range. If I keep losing weight due to diet and (especially) exercise, there’s a chance I’ll be off the metformin pills at some point in the future. I’m already off the glimepiride (Amaryl) pills with no ill-effects.
Incidentally, it would seem that there’s a slim chance I might attend Penguicon 3.0 next year, as long as I’m able to keep my commitment and churn out quality Linux.Ars issues every other week.
I’ve been obtaining application materials for a Master’s program in computer science from various universities all around the world. I’m mostly targeting second-tier universities this time round, since Master’s programs are pretty selective and I didn’t do so well at the undergraduate level. I’ll take the IELTS, GRE (computer science subject test as well as the general tests) and whatever else universities require. The bigger issue will be recommendations — I have doubts whether my professors remember me. I have one or two good ones in mind, but I messed up classes more often than I did well. I wonder if there are any decent universities that don’t place much emphasis on recommendations. (Suggestions on computer science Master’s degree programmes taught in English that are well-reputed yet not extremely competitive and that don’t place a great emphasis on recommendations would be gladly accepted.)
One of my best friends ever, Paresh Gajria, got married the Saturday before last to a lady named Tamanna Bhatia. Congratulations, Paresh; have a great married life!
July 2, 2004
How . . . odd.
What’s this? Somebody’s Master’s thesis?
Oh, look what it references!
Hello, Mr Hodges. Nice to know someone outside Planet Linux.Ars bothers reading my blog. 
(Yes, Paresh, I’m aware you do now. Thanks for the support. )
Along with other #linux folks, I’m planning to write an MP3 stream aggregator, sort of how Planet works for blogs, only different. Here’s my proposal for how the thing should work. I opine that on startup, the “client” should try to join a pre-configured IRC server with a pre-configured nick for an IRC bot (available as part of the client; I’ll get to this bit later) in order to get a list of “peers” with whom streams can be shared and aggregated.
Only one client of this “group” activates its bot to connect to the server (but not join any channel); let’s call this client “group master”. This is determined by its advertised average link latency to its peers every time there’s an “election”. An election might occur whenever the number of peers has increased or decreased by a power of two from the last election, for instance.
Additionally, since even consumer broadband doesn’t have enough bandwidth to aggregate more than perhaps three or four medium-bitrate streams upstream, we’d have to divide up the group of peers into “cliques” that share streams among themselves and only among themselves; these cliques time out and new cliques are formed every so often. (This can be a sort of weighted FIFO mechanism based on a few things.)
Cliques are determined by looking at playback history. The user might be able to “skip” a song in the stream via the UI; this would amount to a derating. Also, the user might be able to set an explicit rating. Thirdly, the frequency at which a song is played without skipping could count towards an automatic rise in the rating (unless, of course, the rating has been set explicitly). This frequency/rating/source information could be stored in a table in e.g. a BerkeleyDB hash or a SQLite database.
Peers that rate each other highly could go in their own cliques, each serving the others streams of its own MP3s. This is done dynamically; if network congestion is detected, the number of streams served is cut down. Similarly, the user is able to close streams from other users if he needs more bandwidth. Finally, each client will pace other clients by refusing to consume the stream further if its buffer for that stream is full.
Finally, at timeout, the “peer ratings” (determined as a function of the average song rating, point-to-point throughput and how recently the peer was in a clique with this one) can be temporarily depressed if the users are being placed in the same clique too often. This could, like the 2.6 scheduler’s interactivity estimator, require careful tuning and could easily break the assumptions, so this policy would have to be thought out more carefully.
Also, a user might be able to “killfile” certain songs (identified by a {MD5 hash; file size} key) so that they are skipped. (This also means that the streams sent out to different peers may be different; since we aren’t using broadcast or multicast, we aren’t losing any bandwidth this way.) Also, of course, a user may be able to “killfile” other users’ streams, and perhaps also “killfile” other users from consume his stream.
So much is for policy. As far as mechanism is concerned, I have some reading to do on distributed systems. Synchronization and election are not the hard part. The hard part would be coordinating state and the decision-making. For instance, what graph-theoretic algorithm do we use to create maximally-sized cliques where the outgoing cost is maximized yet bounded by a maximum cost (link bandwidth? latency? some function of the two)? This is more of an operations research/constraint satisfaction problem, and I’ll have to break open my copy of CLRS to see if I can find an answer.
Transport would be over HTTP. I’m thinking of SOAP for the control plane and raw MPEG-1 Layer III frames for the data plane. The MP3 player would access a localhost web server (part of the app) to get the aggregated stream. The app would also have to be able to talk IRC in case it got elected Group Master, to act as a sort of directory service. (If it lost the election, it would disconnect and allow the new master to connect with the same name.)
As far as the actual language and libraries to use are concerned, I’m thinking of using C++. libgtkmm would provide the View and (of course) libsigc++ for the Controller. JNetLib can provide the low-level network access functionality for the IRC bot part as well as for transmitting MP3 data (it includes a mini web server and client functionality). gSOAP 2 can provide the SOAP serialization/deserialization facility and a mini-web server and client for the control-plane communications. Configuration can be stored using libxml2 if need be. Boost can provide various algorithms and patterns.
The whole thing can be based around a configurable policy engine that stores configurations in memory and a module loader that can load DLLs/.sos that carry different implementations of required functionality based on the policies configured. (It’d have been nice to have something like COM available that would make this convenient, but alas, we can’t guarantee we’ll have something like this available — Windows and OS X both come with COM implementations out-of-box but it’s a very rare Linux box that has a COM runtime.)
What do folks think about this model? Would you consider this doable? (No doubt there will be many folks denouncing C++ as the work of the devil and SOAP being the spawn of Satan himself. Perhaps my model of a distributed system is flawed and you have a better idea. If so, comment!
This weekend, I’ll see if I can find some time to write up some sort of design spec and class diagrams, pending public approval.
It would help if you folks could comment about potential Linux.Ars topics. I might have a little time to do a writeup or two.
That’s it. It’s quite late and I have to work this morning. I’m going to bed.
