2008 Google Summer of Code Highlights

andrewmin writes "SoC 2008 has begun, and with 175 organizations and 1125 students it looks better than ever before. Here's a quick run-down of a few programs that, if they are finished, will definitely be making their way onto your machine."

E17?

Cross-platform is now officially the hottest thing for desktop environments. First, KDE announced that KDE 4 was being ported to Windows and OS X. Now, the lesser known Enlightenment project is doing the same thing. Student Dzmitry Mazouka is now porting the Ewl and Etk libraries to the Win32 platform.

How about finishing Enlightenment 0.17? I've been waiting for almost 8 years now...

Re:E17?

Then get to it, damnit.

Re:E17?

The difference is that you are going to pay somebody to do those things. Enlightenment is done as a hobby, and it still manages to come up with some pretty cool stuff that works its way into somebody's code or maybe even a finished DE someday. However, complaining that unpaid hobbyists should abandon what they enjoy doing to in favor of pursuing your priorities is like asking the guy how lives next door who builds hotrods for fun to come and fix your toyota. If you want them to finish E17 that bad, either pay them to do it or do it yourself.

Oh, and before I get that troll who says that this is the problem with open source, I would like to point out that the "hobby" development is not typical of open source software; most people who work on OSS get paid to do it (for example, by redhat, novell, mysql, sun, ibm, trolltech [now owned by nokia] etc.)

Re:E17?

Patience.

It is this very attachment and craving that keeps you from attaining it.

Re:

I've been using the CVS for three years now and have encountered instability extremely rarely. I don't know if raster will ever actually make an official release, but e17 is the best window manager I've ever used even if it is still in a development limbo.

7 slots for DragonFlyBSD

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008 [dragonflybsd.org]

DragonFly Projects

Enhance dma

        * Max Lindner, mentored by Matthias Schmidt
        * See EnhanceDmaGSoC for more information

Port DragonFly to the AMD64 architecture

        * Jordan Gordeev, mentored by Thomas E. Spanjaard
        * See AMD64GSoC for more information.

RFC3542 support

        * Dashu Huang, mentored by Hasso Tepper
        * The standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s, it has also been implemented on DragonFly BSD with support for IPv6 applications. Today, to fit new demands, the API standard that support IPv6 applications has experience some changes from RFC2292 to RFC3542. However, the DragonFly BSD operating system now only support RFC2292, and it don't support RFC3542 advanced sockets API, to make it catch up the change, we need to make it support RFC3542. To make DragonFly BSD support RFC3542. My work will research the codes of current IPv6 stack in DragonFly BSD and understand how it works. At the same time, I should understand some related RFC, and how other BSD's such as FreeBSD, openBSD, merged RFC3542. Through this way, I can figure out which part of the old IPv6 stack should be improved. Finally,I will update the old IPv6 stack to make it support RFC3542.

Extend Multi-Processing (MP) support

        * Robert Luciani, mentored by Simon Schubert
        * Back in 2003 when DragonFly was born, the first subsystem to be implemented was the LWKT. The reduction in complexity achieved by using message passing (as opposed to a shared memory environment using locks) was undeniable. What was also "unlocked" though, was the potential for near linear performance scaling on multiple CPU systems. Unfortunately many kernel systems, such as the network stack, need to be modified to take advantage of this potential, since they are still encumbered by a legacy "Big Giant Lock". In this project I will remove the MP lock in important areas of the kernel that have a direct affect on the performance of popular programs such as PostgreSQL.

Proportional share userland scheduling algorithm

        * Mayur Narayan Bhosle, mentored by Jeffrey Hsu
        * Proportional share algorithms like lottery scheduling, Stride scheduling algorithm guarantee proportional share of resources like (CPU) to a processes as per their requirement stated specified during the start. The traditional schedulers achieve fairness or resource allocation by adjusting priority, but the effect is observed over a long term. But instead in case of proportional share schedulers we observe the fairness of allocation over a bounded period of time when we adjust the requirement of resources dynamically.

Anticipatory disk I/O scheduler

        * Nirmal Thacker, mentored by Simon Schubert
        * This project aims at developing an Anticipatory Disk I/O scheduler for DragonFlyBSD. An Anticipatory Disk I/O scheduler will ensure that an anticipation heuristic will nullify all possible deceptive idleness between consecutive disk accesses and at the same time try to maintain an overall good throughput. In the DragonFly BSD operating system it must also take into consideration the MP- safety factors.

LiveCD with a DragonFly-specific X desktop

        * Louisa Luciani, mentored by Sascha Wildner
        * In this project I will integrate more functionality into the nrelease build system. The build will generate a persistent liveCD with Dragonfly specific features. It will be customized for recovery, demonstration and testing and include a good default installation.

Links

        * http://code.google.com/soc/2008/ [google.com]

Re:7 slots for DragonFlyBSD

I wrote up the SoC's projects which will probably end up in Gnome (and by extension, Ubuntu) about a month ago.
http://www.ibeentoubuntu.com/2008/04/where-do-we-go-from-here-now-that-gnome.html [ibeentoubuntu.com]

coral cache link

It seems slow, so have a mirror: http://www.freesoftwaremagazine.com.nyud.net/columns/2008_google_summer_code_21_projects_im_excited_about [nyud.net]

stop hating on mplayer

Since VLCs firefox plugin is incompatible with noscript, I've started using mplayer, and as its modular (unlike VLC) I can also throw almost anything at it (actually I can throw more at it as it handles realmedia too). As for interfaces well i personally think Kmplayer beats VLC hands down as a media player too.

I also dont understand the need for a frontend to aptitude, apt + front end is just as powerful, its only dependency resolution that hasn't been well implemented in other front ends.

definitely be making their way onto your machine

Nope. I see nothing there that will be on my machine in the foreseeable future.

Re:

Agreed, the only thing that sparked any interest from that list was GRUB2, which isn't really even on the list, just some crappy fancy nonsense theme thing for it...

Me and GRUB have never gotten along, but maybe me and GRUB2 will...

Aside from that, that li

Re:Get GRUB2 production ready first...

Many GRUB developers are working diligently toward a production ready version of GRUB 2. I am a new contributor to the GRUB project and the reason I chose this feature to implement is because it meshes with my areas of expertise and interest. Also, I feel that making GRUB 2 usable by everyone (let's face it, right now that means it has to be supported by Ubuntu) is a very important goal. In order for Ubuntu to adopt GRUB 2, it will have to not only be functionally complete, but they will want it to look nice too, as the rest of the OS will.

No argument that it will be great to have GRUB 2 production ready. I am looking forward to it, and I hope I can contribute to other features after I complete the graphical menu system.

Colin

Re:definitely be making their way onto your machin

A nice UI may be more important for a Live CD install/rescue disk, for instance, where there are many choices, and you want it to simple to use and self-explanatory for any user booting the disk. Also, GRUB 2 uses dynamically loadable modules for virtually everything, so you can just not load the future 'gfxmenu' module if you like. Then it will consume no memory and will not be a possible source of problems.

Server dying

Coral Cache link: http://www.freesoftwaremagazine.com.nyud.net/columns/2008_google_summer_code_21_projects_im_excited_about [nyud.net]

-FST (anonymous to prevent karma whoring)

Pidgin projects are cool

My personal favorites are the project to add Voice and Video to pidgin and the Pidgin theming project. http://developer.pidgin.im/wiki/GSoC2008/VoiceAndVideo [pidgin.im] and http://developer.pidgin.im/wiki/GSoC2008/ThemeImprovements [pidgin.im] . People always ask for these things and the developers don't have time to do things that they don't use, so they never get done. Hopefully these actually get done by the end of this summer.

Re:Pidgin projects are cool

From the pidgin FAQ: "Why are file transfers so slow? MSN file transfer support is limited to the proxied version of file transfer support in the protocol. This means that the files are sent to MSN's servers, then the server sends the data to the other user. We don't know if or when we will ever support any of the peer-to-peer file transfer methods available in the MSN protocol." What would it take to add direct connection transfer support to Pidgin so I can actually send someone a file on MSN? Currently it maxes out around 4KB/s which is useless. I always wondered why this is not a priority.

Re:Pidgin projects are cool

What would it take to add direct connection transfer support to Pidgin so I can actually send someone a file on MSN? Currently it maxes out around 4KB/s which is useless. I always wondered why this is not a priority.

I imagine support for all closed, legacy formats is a pretty low priority. Why prioritize reverse engineering and optimizing less used features of an intentionally obfuscated format championed by someone trying to prevent the type of interoperability that is Pidgin's goal? Isn't it better for them to optimize file transfer over XMMP or the video and voice capabilities? I mean, if you want to transfer files with other users, there are plenty of other protocols that do work and where the Pidgin team doesn't have to work so hard only to have it intentionally broken by Microsoft at a later date. It is an inefficient use of their resources compared to working on core features using open protocols where they don't have to put in all that extra effort to overcome MS's antics.

Re:

Honestly, I think not. I've seen their stuff, and it's not exactly impressive to readd some features that Pidgin used to have. I emailed the developers about just releasing their features as pidgin plugins but I got a reply that they didn't know how to.

from the aptitude-gtk guy

Hi, I'm the Aptitude-gtk applicant.
If you've used both Synaptic and Aptitude, you should have seen some differences :)
The dependency resolution is one point, but it's not only that. The whole navigation in Aptitude is just much more efficient. Ever used Synaptic in a mixed-distribution install ? Say you want to install another version of a package and it has some different dependencies. Good luck navigating them in Synaptic. It's really not designed with that in mind.
You can see the full application here [milliways.fr] and my development blog here [milliways.fr] .
I warmly welcome any input on my project!

at less than 2%

Kudos to the few mentioned that will get some extra attention from this, but it's worth noting that the coverage doesn't represent even 2% of the projects that will be going on. I'd even go so far to say as many of those listed aren't even some of the most impressive or realistic, just one person's sampling of a few they know about.

Captain obvious points out that highlighting even just one project for half of the participating orgs would be about 88 projects and would still represent less than 8%. There's also no guarantee that the student will be successful on their project. About one in five students failed last year, so nothing is guaranteed regardless.

My point? There is a LOT of cool stuff being worked on. Check the projects out for yourself at http://code.google.com/soc/2008/ [google.com]
They're all listed. Show your support, get involved, help them succeed if you really care.

Re:GRUB GUI?

Blue screen at bootup?

Must... resist... urge... to make... Windows BSOD.... joke... aaaaaaargh!

Re:GRUB GUI?

Editing menu.lst hardly qualifies as a GUI.

Re:GRUB GUI?

The "Legacy" version of GRUB (latest release is 0.97), currently used by most Linux distributions, has been patched by various distros to support background images in a graphical console mode. However, there is no support in GRUB 2, where all GRUB development is currently taking place. I am going to add a basic GUI to GRUB that will surpass the patches for GRUB 0.9x in portability and flexibility. Once the graphical menu support is added (my GSoC'08 project), adding mouse support will be relatively straightforward... ;-) From http://www.gnu.org/software/grub/grub-soc.html [gnu.org] under "Fancy menu interface":

This feature is really important for GRUB 2, because GRUB Legacy has been patched by third parties frequently, as the official version never support a graphical interface, but such an interface attracts more casual users. Support for a fancy menu - even better than an unofficial patch for GRUB Legacy - would attract more people to GRUB 2, thus this is critical in a long term to accelerate the development.

I plan to make the code portable to non-x86 architectures (though at first VESA VBE 2.0 on PC architecture will be the only supported video driver). More details at: http://gibibit.com/grub-gsoc/proposal.html [gibibit.com]

Re:GRUB GUI?

BTW, in case you didn't pick it up, I'm the student developing the GRUB GUI for GSoC'08... :-)

stop reading slashdot and get to writing code!

Re:Multithreading way more important.

Except that x264 is already the most efficient multithreaded encoder in the open source world. I don't see what you mean; there is no such thing as an x264 "video format"; its called H.264, and given that x264 is an encoder and not a decoder, it isn't exactly our job to do multithreading, given that we don't even have a decoder to implement such a thing in!