Slashdot Mirror
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."
Adding a GUI to the upcoming GRUB 2 because its black and white terminal interface is scary? Doesn't GRUB already have a GUI? That pretty blue screen at bootup?
http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
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, demonstr
It seems slow, so have a mirror: http://www.freesoftwaremagazine.com.nyud.net/columns/2008_google_summer_code_21_projects_im_excited_about
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.
IranAir Flight 655 never forget!
Nope. I see nothing there that will be on my machine in the foreseeable future.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Coral Cache link: http://www.freesoftwaremagazine.com.nyud.net/columns/2008_google_summer_code_21_projects_im_excited_about
-FST (anonymous to prevent karma whoring)
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 and http://developer.pidgin.im/wiki/GSoC2008/ThemeImprovements . 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.
All your base are belong to Wii.
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 list is just a bunch of Gadgets/Widget/Nonsense... im not sure why the Editor/Poster just didnt do a write-up and link to http://code.google.com/soc/2008/ or something a little more diverse and interesting.
Until grub2 has a security module so that i can lock down what you can boot too, im happy with grub, even if grub2 looks nice.
Hell i have 1 second time-out & hidden menu so i never see it anyway, grub doesn't need any nice interface as it shouldn't need to be seen other than when you have a problem in which case a nice UI just adds another thing to go wrong.
IranAir Flight 655 never forget!
The Dojo toolkit is going to get some love this SoC -- these things might be making their way into your machine even without you knowing it... Markup Previews, 3D effects and Drag&Drop form editor are all among the SoC projects this year.
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 and my development blog here
I warmly welcome any input on my project!
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/
They're all listed. Show your support, get involved, help them succeed if you really care.
Cheers!
Sean
Personally, I would prefer it if somebody would get GRUB 2 "production ready" first, instead of making fancy GUI menus for it.
Maybe it's just me, but I'd really like the ability to boot from LVM and get proper EFI support (though not really an issue until EFI is in wide distribution for x86) without having to install an experimental package.
It's a bootloader, guys. Functional first, form later.
1. Why the hell has it taken this long to get a Voice Recognition front end implemented?
2. Who decided that tomboy notes is a worthy front end?!?! Who uses tomboy notes? Couldn't we have something that would allow us to use speech to text in a way which is useful?
These optimizations are nice, but leave out the most obvious and important improvement to the codecs that have yet to be made. Most processors sold nowadays are 2 or more cores. And smooth single-threaded processing of 1080p x264 is impossible on all but the absolute highest end processors. So the most important step is obvious multi-threading. There's a summer of code project for that too. I'm surprised the author of the article missed it.
They are not porting Plasma or the KDE UI to Windows/Mac, just the core libs to allow KDE programs to run in other operating systems. As KDE apps are QT based, they mostly use the native widgets, and full native look and feel is in the works for Mac.
For you this means Windows looks like Windows, and Mac looks like Mac. The running application may be written for KDE, but this doesn't matter anymore.
Signature v3.0, now with 42% less memory usage.
the grub gui, if its actually any good will eventually get installed on my desktop linux machines...
... another rss solution? ooxml for abiword? bragging rights for game I've never heard of? Theming support for Pidgin? VLC for Windows CE? I can gaurantee you that I'm not going to EVER go out of my way to install ANY of that crud.
The rest of the crud the article mentioned? Wow... what a completely uninspiring and underwhelming list.
Oooh
Not that I have a problem with people working on its... its their time. But none of this is remotely 'must have' software.
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.
Dr Superlove 300ml. I use my powers for awesome
KDE are way better than the UI in Windows and may be better than OS X ones aswell thought. I run OS X but could see myself use KDE. Especially with Amarok and Kopete.
I can't speak for Google on this, but I will say there is no bad about it. It is the job of the project to apply and coordinate all the happenings. I don't know if ReactOS even applied? If you are fond of ReactOS, I encourage you get involved, to contact the developers and to offer your time to apply for the SoC ... (I don't know if they did or not, just saying) ... Open Source really "works" when you actually get involved.
you can't have everything, where would you put it?
I guess it doesn't matter much what I consider a port, but when users are accustomed to features working across all their applications on an OS, when they don't, well they throw that application into the same bin as OpenOffice and often look for better more "native" solutions; regardless of whether or not the application was originated on another OS.
Recent versions of QT use the native widgets for Mac [1] without changes. There are always cases where an application taken from the Windows centric UI style (KDE, Win32) to OSX might need some extra code to make it look more OSXy, but QT at least tries to give you a leg up.Certainly they make an effort to make things closer to the experience with native applications, but they also try to reuse as much as possible, which often results in sort of a "least common denominator" effect. You end up with applications that can't use any features of any OS that are not also present in all the other OS's supported (or sometimes only features in one OS, making it like a port in this regard).
I think there is a middle ground between the high expectations I set, and the rather grim picture painted by yourself.I didn't think I was painting a grim picture. I was just trying to be realistic. For now QT is Linux first, and everything else second. The functionality it affords reflects this. Most of the developers are on Linux and primarily targeting it and many don't even know about the features of OS X and Vista that they aren't supporting, because they don't use those OS's enough to be familiar with said features.
They are a good step towards letting developers quickly target multiple platforms and keep an application up to date on all of them, but they are certainly not providing the same level of quality and functionality that truly native applications do. Perhaps in the future that will no longer be the case. In the mean time, well maybe I can recommend some apps to people who don't use Linux, but who might like apps that right now are Linux only.