[dev] GSoC 2010
Hi there, GSoC 2010 has kicked of and is looking for mentoring organisations next week, hence it's time now to get organised. Who is willing to mentor this time? What project ideas do you have apart from http://suckless.org/project_ideas? Note, to be successful this time, we need to focus on a bunch of similar projects according to Google's feedback of last year. They basically argued that our proposals were too diverse. I'd say let's have a deadline until Saturday for these discussions and in order to have enough time to create a successful application on Monday. I also got the impression that early applications are checked more carefully by the Google guys as late applications (afaik our application was neither early or late last time) -- but this time I want to press the submit button as early as possible. Cheers, Anselm
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: > Hi there, > > GSoC 2010 has kicked of and is looking for mentoring organisations > next week, hence it's time now to get organised. > > Who is willing to mentor this time? > > What project ideas do you have apart from http://suckless.org/project_ideas? "Create stali stable release" ~dum8d0g
Re: [dev] GSoC 2010
On 3 March 2010 08:22, Martin Kopta wrote: > On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: >> Hi there, >> >> GSoC 2010 has kicked of and is looking for mentoring organisations >> next week, hence it's time now to get organised. >> >> Who is willing to mentor this time? >> >> What project ideas do you have apart from http://suckless.org/project_ideas? > > "Create stali stable release" Stali is definately a topic, forgot to mention this. The project idea a colleague of mine at work came up with is creating wether a completely new ld or ld wrapper at the least to collect all info when a shared lib/executable is linked and using this info to create a static library/executable instead, basically kind of a tee ld if you like, where one result invisible to the caller is a static lib instead of a dynamic one ;) This would enable building nearly everything statically without the need of extra makefiles. I don't consider this approach for the base system, since the value in it is all about decent make files, but this might be a cool project for all other stuff and would fit the GSoC scope quite well. Cheers, Anselm
Re: [dev] GSoC 2010
I would love to see a suckless windowing system. I know that it is a point on the project page. But that is something I see as a important thing for me. But I'm also not sure if that is something which can be done during the GSoC. I think the approch of Stali is intresting but since I'm a BSD guy it doesn't intrest me so much. On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: > Hi there, > > GSoC 2010 has kicked of and is looking for mentoring organisations > next week, hence it's time now to get organised. > > Who is willing to mentor this time? > > What project ideas do you have apart from http://suckless.org/project_ideas? > > Note, to be successful this time, we need to focus on a bunch of > similar projects according to Google's feedback of last year. They > basically argued that our proposals were too diverse. > > I'd say let's have a deadline until Saturday for these discussions and > in order to have enough time to create a successful application on > Monday. I also got the impression that early applications are checked > more carefully by the Google guys as late applications (afaik our > application was neither early or late last time) -- but this time I > want to press the submit button as early as possible. > > Cheers, > Anselm >
Re: [dev] GSoC 2010
Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
+1 Current bugtrackers sucks. The linker proposal, looks interesting, but i dont get the idea at all, i would do it if i get bored somewhile..but i can't trick google to say that i'm a student. Is your idea to create a static bin from a shared one? There's a program called 'staticify' or something like this that does it. Do somebody checked 'bug'? a simple todo/bugtracker for commandline? http://vicerveza.homeunix.net/~viric/soft/bug/ Another topic I would like to open is about 'suckless games'. Recently I have discovered 'jvgs' and 'ledboy' which bring me some fun and think about minimalistic games with fun inside, originality and clean code. The problem here for example..is that jvgs is c++ with stupid dependencies like lua or cmake, ledboy is just hardware, most of games are bloated, filled with silly graphics and big media stuff, but lacking any kind of simplicity and clean code on it. http://jvgs.sourceforge.net/ http://hackaday.com/2009/12/08/ledboy-super-pixel-brothers/ Sure, there are bsdgames, and few years ago I wrote 'pag' a platform arcade game in text mode..but the code I wrote 10 years ago sucks.. http://hg.youterm.com/pag About the distro I think it requires so many stuff on it, so at this moment I think is more important to push partial projects before working on stali. --pancake Anselm R Garbe wrote: Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
About the mail part of the bug tracker.. why not push 'dmc'? and fix the imap protocol, implement the SMTP part and write a frontend. This can sound like not so much work..but it does from the side that it is actually not usable application, and it needs some love. I think that a decent minimal mail solution is mandatory for most of us.. So.. is anyone going to work on it? :) --pancake Anselm R Garbe wrote: Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
On 3 March 2010 10:09, pancake wrote: > About the distro I think it requires so many stuff on it, so at this moment > I think is more important to push partial projects before working on stali. These are the current main drivers of stali (or my take on it): a) having a decent toolchain and build system for embedded development (which is lacking big time in most of such projects like maemo and friends), the real value are the mkfile's here that ignore the configure hell completely. b) to prove that static linking produces slimmer systems that run faster, use less memory and are more secure -- contrary to all those pseudo-arguments the dynamic linking fan boys came up with. Cheers, Anselm
Re: [dev] GSoC 2010
Hi folks, I found some interesting issue-/bug tracking system last week. Even its written in Python the idea is cool. Bugs Everywhere (http://bugseverywhere.org/) uses the underlying scm (aka git, hg, bzr) to store its data on. It has also a mail-frontend like the debian BTS (didnt tried it, just read it). Maybee its such a solution you want to have for suckless bugtracking. If it jet sucks less is another question. -Chris On Wed, Mar 03, 2010 at 08:53:50AM +, Anselm R Garbe wrote: > Another idea that I'd like to push this year is the creation of a > suckless issue tracking/bug tracking system. All existing systems suck > and it is still a burden for projects and small businesses to track > bugs or customer issues in less sucking ways. The existing > alternatives are all a big desgrace, can't speak of those commercial > ones, but I guess they ain't any better than the floss ones. > > Approaches like trac do too many things, and hence fail at doing issue > tracking right. A friend pointed me to the debian bug tracking system > (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of > like parts of it. > > I think it is a strong requirement for a decent issue tracker to have > a decent mail integration, people don't want to use hairy web > interfaces and developers or customer relation staff doesn't wants to > use them either -- RT for instance is good in the mail integration, > but it does too many things and has a bad web interface that really > sucks. > > Kind regards, > Anselm signature.asc Description: Digital signature
Re: [dev] GSoC 2010
I agree about the issue trackers + the mail integration. A small suggestion: none of the issue/bug tracking systems do collaboration very well either. What I mean by "collaboration" is the capacity to pass a single document back and forth with several "notes" appended to it. a giant "comments" list isn't very good (no inline comments) and forums are dumb. Peter -- sic dicit magister P. http://individual.utoronto.ca/peterjh/ On Wed, 3 Mar 2010, Anselm R Garbe wrote: Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
On 03/03/2010 02:46 PM, Peter John Hartman wrote: > I agree about the issue trackers + the mail integration. A small > suggestion: none of the issue/bug tracking systems do collaboration very > well either. What I mean by "collaboration" is the capacity to pass a > single document back and forth with several "notes" appended to it. a > giant You might think on a distributed bug-tracking system similar to a list of bug-reports inside a git system with the possibility to create new bugreports "on the fly" when the mail-server receives a specific mail (you somehow have to define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on). There should be a 'central' (though not required) bug-tracking server for all those coming with bugs on you project-website. there, the current bug list and state is a available and an interface to add new bugs. then you could place some sort of hooks into your bugtracker (bt) configuration: bt/.config/new -> send mail to mail-adress with new bug then you can manage bug-notification via mailing lists. For users that don't want to use the website, you could listen on mails in a specific form/with a specific header to pass it directly to bt parsing it. if the parsing fails, automagically send a mail back to the composer with annotation where it failed, if successfull, send back a success-mail. usage could be like (in a distributed way): $ cd bugs/projectname bugs/projectname $ bt pull # pulls all new bugreports from server 7 new bugreports bugs/projectname $ 51 unresolved bugs 123 pending bugs where 'pending' means that their state is in "needs check if the bugfix works or not, waiting for approval" or something like that. If you want to make comments to a file, make them and afterwards a bugs/projectname $ bt commit -m "some annotation" bugs/projectname $ bt send # send new file to whole mailinglist bugs/projectname $ bt send some.u...@host.tld # send your changeset just to a specific user would do the rest. something like that. Didn't think too carefully on it.
Re: [dev] GSoC 2010
Anselm, I saw where you had some base ideas for a widget toolkit. I think that'd be a great GSoC project. I also support the bug tracking software idea, but a non-retarded toolkit would make my day. -- # Kurt H Maier
Re: [dev] GSoC 2010
I'm still a student (PhD student, but that's fine for Google), so I will probably apply to participate as a student. Since Go was released I have been playing with it. Is there any interest in the Go port of dwm? This would probably include the improvement of the xgb go package (which I don't know if it is fine, since Google's projects like Go cannot take part in GSoC). Other part of the project could be writing a widget toolkit, at least for the status bar and, eventually, dmenu, but could include more widgets to be a full toolkit (as Kurt suggested), or use the Go draw pkg (which should be inproved too). I have some vague ideas about a layout interface which could be shared between dwm and the widget toolkit. I'm also interesting in porting dio to Go, if you think that would make a nice project or could be included with the dwm port. That said... I think what Google meant about lack of focus is that writing software that sucks less is what everybody is trying, but not a concrete objective. You could call dwm/dmenu/surf and the rest of suckless projects part of a "desktop environment" (I know, I also hate that name) or, even better, a "development environment" (the first one not including an editor!). IOW, I think a goal clearer than "suckless software" is needed. -- - yiyus || JGL . 4l77.com
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: > Since Go was released I have been playing with it. Is there any > interest in the Go port of dwm? What would be the benefits of porting dwm to a new language? From my point of view, dwm is already functional and mature, porting it over to Go doesn't sound very constructive. // pipe
Re: [dev] GSoC 2010
EDUCATIONAL PURPOSES ONLY. dwm in go takes not much sense from my point of view. It will make code slower, afaik C bindings are not as clean as writnig C directly and there's no interesting feature from Go to be used in dwm code. Anders Andersson wrote: On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: Since Go was released I have been playing with it. Is there any interest in the Go port of dwm? What would be the benefits of porting dwm to a new language? From my point of view, dwm is already functional and mature, porting it over to Go doesn't sound very constructive. // pipe
Re: [dev] GSoC 2010
We need a desktop text indexing system that sucks less.
Re: [dev] GSoC 2010
On 3 March 2010 16:38, yy wrote: > I'm still a student (PhD student, but that's fine for Google), so I > will probably apply to participate as a student. > > Since Go was released I have been playing with it. Is there any > interest in the Go port of dwm? This would probably include the > improvement of the xgb go package (which I don't know if it is fine, > since Google's projects like Go cannot take part in GSoC). Other part > of the project could be writing a widget toolkit, at least for the > status bar and, eventually, dmenu, but could include more widgets to > be a full toolkit (as Kurt suggested), or use the Go draw pkg (which > should be inproved too). I have some vague ideas about a layout > interface which could be shared between dwm and the widget toolkit. > I'm also interesting in porting dio to Go, if you think that would > make a nice project or could be included with the dwm port. > > That said... I think what Google meant about lack of focus is that > writing software that sucks less is what everybody is trying, but not > a concrete objective. You could call dwm/dmenu/surf and the rest of > suckless projects part of a "desktop environment" (I know, I also hate > that name) or, even better, a "development environment" (the first one > not including an editor!). IOW, I think a goal clearer than "suckless > software" is needed. I'd say Go sounds like an interesting lang for a decent MTA and issue tracker, perhaps even considering the idea to implement werc in Go ;) Cheers, Anselm
Re: [dev] GSoC 2010
Chris Palmer wrote: We need a desktop text indexing system that sucks less. desktop sucks by definition.
Re: [dev] GSoC 2010
On 03/03/2010 06:28 PM, Anders Andersson wrote: > What would be the benefits of porting dwm to a new language? From my > point of view, dwm is already functional and mature, porting it over > to Go doesn't sound very constructive. And porting it is a real pain, at the moment. For example, you don't have bindings to xlib. It is possible via cgo to create bindings, but it's not that straightforward to use them. If the decision is made to take xgb (the xcb port for Go), one will notice that xgb is a rather premature state. Some time ago I tried out small apps with xcb (to get familiar with it) in C, and one of them was to simply port dwm's most basic functionality to xcb. About 4 weeks ago I tried to port this to Go and xgb, which resulted in me changing the xgb part because somehow the xgb developers lost track and sense what xgb is. For example, instead of having an error handler facility, xgb prints out the error and even worse - in some cases you don't have the possibilty to get the error at all or even don't get a status that an error occured, the only thing that happens is that an error message is written to stdout... That said, when thinking about porting dwm to something like go and despite that I don't really like xcb, a stable/working/sane/suckless xgb would be a decent way to go as with Go's easy multithreading, the asynchronity would reach another level. nw
Re: [dev] GSoC 2010
pancake writes: > >We need a desktop text indexing system that sucks less. > > desktop sucks by definition. You are very helpful. How about "We need a text indexing system for personal data stored locally on small computers that sucks less."
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 12:55 PM, Chris Palmer wrote: > We need a desktop text indexing system that sucks less. grep -- # Kurt H Maier
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 01:11:00PM -0500, Kurt H Maier wrote: > On Wed, Mar 3, 2010 at 12:55 PM, Chris Palmer wrote: > > We need a desktop text indexing system that sucks less. > > grep ...is not an example of an indexing system. While such a system would be useful, I'm doubtful that a ``suckless'' one could be made. It inherently involves lots of parsers for different file type metadata, which either introduces lots of code or lots of dependencies.
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: > What project ideas do you have apart from http://suckless.org/project_ideas? SSH-model SSL certificate validation for surf.
Re: [dev] GSoC 2010
2010/3/3 Anders Andersson : > On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: >> Since Go was released I have been playing with it. Is there any >> interest in the Go port of dwm? > > What would be the benefits of porting dwm to a new language? From my > point of view, dwm is already functional and mature, porting it over > to Go doesn't sound very constructive. > > // pipe > > I agree there are no inmediate benefits, but there is an incomplete port in the repo (almost nothing) and I was asking if there was any interest in finishing it. Anselm said, when Go was released, that he was considering using Go for future suckless project. Although later he decided he would wait until the language was more mature (which I think was a right decission) I would consider porting dwm as a first (experimental, if you want) step in that direction, not a final goal. Anyway, if there is no interest in the idea, that is perfectly fine, and I won't arguee any more. There are many interesting projects. I just thought I'd let it drop. @pancake: I would use xgb, which implements the X protocol, not C bindings. In any way, I doubt you could notice the speed difference between a Go and a C version of dwm (at least, not running it in normal conditions; of course you could launch thousands of windows to see which one is faster, but that would be even more stupid than porting dwm to Go). @Anselm: I agree a MTA would be a good fit for Go. I would not apply for that one, but it could be included in the ideas list. A werc port would be interesting, I'd like to know uriel's opinion. -- - yiyus || JGL . 4l77.com
Re: [dev] GSoC 2010
Kurt H Maier writes: > > We need a desktop text indexing system that sucks less. > > grep First of all, I had never heard of this program. It is so great! Wow! Thanks for the suggestion! In 45 minutes when my query has completed, I'll buy you a beer. I assume you prefer Coors Lite? Second, the newly-discovered grep program is horrible bloatware. 78KB on my system (the stali version will be larger due to static linking), when a simple awk script would suffice for the same purpose? Man, the people writing this new bleeding-edge software sure have no conception of the beauty of simplicity that reigned in the old days.
Re: [dev] GSoC 2010
David Thiel writes: > > grep > > ...is not an example of an indexing system. That's a feature, not a bug. Hash tables are bloatware. If you can't do it with linear search, you shouldn't do it. Don't even get me started on red-black trees... > While such a system would be useful, I'm doubtful that a ``suckless'' one > could be made. It inherently involves lots of parsers for different file > type metadata, which either introduces lots of code or lots of > dependencies. Lots of small programs working together in a pipeline. Also, strings foo.mp3 | delete_junk_words | index ... would work for MP3s. These small programs need not be particularly complex. Obviously, the nastier PDFs will need some help and there's no avoiding that. But it would be worth it.
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 1:33 PM, Chris Palmer wrote: > Kurt H Maier writes: > >> > We need a desktop text indexing system that sucks less. >> >> grep > > First of all, I had never heard of this program. It is so great! Wow! Thanks > for the suggestion! In 45 minutes when my query has completed, I'll buy you > a beer. I assume you prefer Coors Lite? it's not my fault you're bad at organizing your data if you think you need a 'desktop text indexing system', chances are you are doing something wrong > Second, the newly-discovered grep program is horrible bloatware. 78KB on my > system (the stali version will be larger due to static linking), when a > simple awk script would suffice for the same purpose? Man, the people > writing this new bleeding-edge software sure have no conception of the > beauty of simplicity that reigned in the old days. if you could actually write simple awk scripts you wouldn't need a 'desktop text indexing system' -- # Kurt H Maier
Re: [dev] GSoC 2010
Anselm R Garbe writes: > Stali's grep is smaller than your bloated 78kb dynamic executable, see > attached. It's 63kb actually and runs on all x86 linux platforms. An awk script equivalent to grep is at least one order of magnitude smaller, and possibly two.
Re: [dev] GSoC 2010
Anselm R Garbe dixit (2010-03-03, 18:55): > On 3 March 2010 18:33, Chris Palmer wrote: > > Kurt H Maier writes: > > > >> > We need a desktop text indexing system that sucks less. > >> > >> grep > > > > First of all, I had never heard of this program. It is so great! Wow! Thanks > > for the suggestion! In 45 minutes when my query has completed, I'll buy you > > a beer. I assume you prefer Coors Lite? > > > > Second, the newly-discovered grep program is horrible bloatware. 78KB on my > > system (the stali version will be larger due to static linking), when a > > simple awk script would suffice for the same purpose? Man, the people > > writing this new bleeding-edge software sure have no conception of the > > beauty of simplicity that reigned in the old days. > > Stali's grep is smaller than your bloated 78kb dynamic executable, see > attached. It's 63kb actually and runs on all x86 linux platforms. Cool, seems like it's got secret netcat functionality built in: $ strings /tmp/grep | /tmp/grep -i network Machine is not on the network Name not unique on network Network is down Network is unreachable Network dropped connection on reset and valuable Xenix support: Not a XENIX named type file No XENIX semaphores available :) -- [a]
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 8:05 PM, Chris Palmer wrote: > Anselm R Garbe writes: > >> Stali's grep is smaller than your bloated 78kb dynamic executable, see >> attached. It's 63kb actually and runs on all x86 linux platforms. > > An awk script equivalent to grep is at least one order of magnitude smaller, > and possibly two. p...@airwaves:~$ size `which awk` textdata bss dec hex filename 3134831392 20584 335459 51e63 /usr/bin/awk
Re: [dev] GSoC 2010
Kurt H Maier writes: > it's not my fault you're bad at organizing your data Please tell us about your data organization scheme, such that you can find anything you have -- email, PDFs, Postscript, music, text files, HTML files, et c. -- in the same amount of time a Google, Google Desktop, Spotlight, or Windows Search query takes. If you have never used any of those systems, I'll tell you: the amount of time is about 1/10th of a second. > if you think you need a 'desktop text indexing system', chances are you > are doing something wrong Having too much data? So rm is your search system? > if you could actually write simple awk scripts you wouldn't need a > 'desktop text indexing system' I think you've had a few too many PCP-spiked Coors Lites.
Re: [dev] GSoC 2010
Anders Andersson writes: > p...@airwaves:~$ size `which awk` >textdata bss dec hex filename > 3134831392 20584 335459 51e63 /usr/bin/awk Small price to pay for something that can basically do the job of almost the entire Unix userland. Also, yours is bloated (but still not too large given what it can do). 11:11 ~ ; size $(which awk) textdata bss dec hex filename 11871228804640 126232 1ed18 /usr/bin/awk
Re: [dev] GSoC 2010
This is supposed to be a discussion on the Google Summer of Code, not a nerd fight about whether grep or awk is better, and how to manage files. Can you guys fork your discussion? On Wed, Mar 3, 2010 at 2:13 PM, Chris Palmer wrote: > Anders Andersson writes: > > > p...@airwaves:~$ size `which awk` > >textdata bss dec hex filename > > 3134831392 20584 335459 51e63 /usr/bin/awk > > Small price to pay for something that can basically do the job of almost > the > entire Unix userland. > > Also, yours is bloated (but still not too large given what it can do). > > 11:11 ~ ; size $(which awk) >textdata bss dec hex filename > 11871228804640 126232 1ed18 /usr/bin/awk > > >
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 2:10 PM, Chris Palmer wrote: > Please tell us about your data organization scheme, such that you can find > anything you have -- email, PDFs, Postscript, music, text files, HTML files, > et c. -- in the same amount of time a Google, Google Desktop, Spotlight, or > Windows Search query takes. If you have never used any of those systems, > I'll tell you: the amount of time is about 1/10th of a second. you've misstated the problem. I almost never need to find information without having any clue where it is. if I need something from a PDF, it's probably with all my other PDFs. if I need something from email, it's probably in a maildir. with this powerful indexing system, I don't have to grep my whole hard drive to find granny's phone number. if it came in an email, then I can cd to maildir and grep -r. if it for some reason is in a pdf, well, grep works on binary data too! like some kind of miracle, this 'remembering where you put shit' technology is available for free, and it's cross-platform!1 > Having too much data? So rm is your search system? see above re: advanced 'not being a moron' techniques > I think you've had a few too many PCP-spiked Coors Lites. please explain your obsession with coors lite thanks -- # Kurt H Maier
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 2:12 PM, Niki Yoshiuchi wrote: > This is supposed to be a discussion on the Google Summer of Code, not a nerd > fight about whether grep or awk is better, and how to manage files. Can you > guys fork your discussion? you're right, but clearly the only way to decide whether a 'desktop text indexing system' qualifies as a gsoc project is a months-long mailing list flamewar -- # Kurt H Maier
Re: [dev] GSoC 2010
On 3/3/10, Antoni Grzymala wrote: > $ strings /tmp/grep | /tmp/grep -i network > Machine is not on the network > Name not unique on network > Network is down > Network is unreachable > Network dropped connection on reset > > and valuable Xenix support: > > Not a XENIX named type file > No XENIX semaphores available > > :) i guess these come from linked libc functions.. funny nevertheless
Re: [dev] GSoC 2010
On Wed 03 Mar 2010 at 11:17:14 PST Kurt H Maier wrote: On Wed, Mar 3, 2010 at 2:12 PM, Niki Yoshiuchi wrote: This is supposed to be a discussion on the Google Summer of Code, not a nerd fight about whether grep or awk is better, and how to manage files. Can you guys fork your discussion? you're right, but clearly the only way to decide whether a 'desktop text indexing system' qualifies as a gsoc project is a months-long mailing list flamewar "A suckless way to avoid months-long mailing list flamewars" sounds like a good GSOC project. Oh wait, it's already been done. It's called "unsubscribe".
Re: [dev] GSoC 2010
I'd like to see dmc improved upon. In it's current state it can already send mail with smtp, but there are also aspects of it that could be polished a bit more, like being able to receive mail, pgp support, et cetera. More work on stali would be very nice, too. -- I am a man who does not exist for others. pgpJtql9E3Vz2.pgp Description: PGP signature
Re: [dev] GSoC 2010
Hey all, I'm a first year student, and I'd be interested in helping out for GSoC. I like the idea of centring the projects on a "development environment", which doesn't seem too broad. I'm personally interested in writing a Unix-native samterm of some kind (I love sam, but not the Plan 9 samterm), but another project could be good too. I really like the idea of a suckless toolkit, but doubt I'd be cut out for that. As an aside, where are the stali utils from? Not GNU, surely? Thanks, cls
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 09:47:08PM +, Connor Lane Smith wrote: > As an aside, where are the stali utils from? Not GNU, surely? It's using a OpenBSD userland if I recall.
Re: [dev] GSoC 2010
Hi, yet another student here, of the second year British variety. I'd be interested in getting involved along the lines of a development environment with something like a suckless text editor, with decent mouse interaction a la Acme. Could be better to leave the terminal and use X11. Personally, I need to learn my way around Plan 9 a bit more too, so I'd love to write something Unix-native that's similar to one of their tools. Rob
Re: [dev] GSoC 2010
I'm an interested student as well; I'm a senior in Providence, Rhode Island, USA, doing a master's next year. -POLM
Re: [dev] GSoC 2010
Should probably say that I'm also a student (studying Computer Engineering at the University of Michigan) that would be interested in doing something like this. I don't yet know what exact project I'd like to take, keep posting ideas.
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 07:01:48PM -0500, Josh Rickmar wrote: > Should probably say that I'm also a student (studying Computer > Engineering at the University of Michigan) that would be interested in > doing something like this. I don't yet know what exact project I'd like > to take, keep posting ideas. > Which U of M are you studying at? Another suggestion: more work on st. -- I am a man who does not exist for others. pgpznl6RRBILm.pgp Description: PGP signature
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 07:16:22PM -0500, Jacob Todd wrote: > On Wed, Mar 03, 2010 at 07:01:48PM -0500, Josh Rickmar wrote: > > Should probably say that I'm also a student (studying Computer > > Engineering at the University of Michigan) that would be interested in > > doing something like this. I don't yet know what exact project I'd like > > to take, keep posting ideas. > > > Which U of M are you studying at? > > Another suggestion: more work on st. The one in Ann Arbor.
Re: [dev] GSoC 2010
On Wed, 3 Mar 2010 16:27:34 -0500 Jacob Todd wrote: > I'd like to see dmc improved upon. In it's current state it can already send > mail with smtp, but there are also aspects of it that could be polished a bit > more, like being able to receive mail, pgp support, et cetera. well. in fact, the support for sending mails is done by msmtp, the current smtp implementation doesnt supports authentication and fails in many situations. It would be good to get a look on it. Maybe by relaying on a real smtp local server would be enought, or just by calling 'mail'. attachment management has been already implemented (attach, detach), in a unix way in 160LOC. by using stdin/stdout. there is some basic support to receive mail. for pop3 its ok, but in imap4 there are some issues. the most common usage atm is as a shell to query imap mail remotely. a better syncronization algorithm should be done to get faster syncs. as you see there are many fronts there :) pgp support would be interesting too. --pancake
Re: [dev] GSoC 2010
I think this is a good project idea, and it would prove more than useful also im looking forward to the simple port scanner, these project ideas have caugth my attention. On Wed, Mar 03, 2010 at 03:41:12PM +0100, Nicolai Waniek wrote: > On 03/03/2010 02:46 PM, Peter John Hartman wrote: > > I agree about the issue trackers + the mail integration. A small > > suggestion: none of the issue/bug tracking systems do collaboration very > > well either. What I mean by "collaboration" is the capacity to pass a > > single document back and forth with several "notes" appended to it. a > > giant > > You might think on a distributed bug-tracking system similar to a list of > bug-reports inside a git system with the possibility to create new bugreports > "on the fly" when the mail-server receives a specific mail (you somehow have > to > define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on). > There should be a 'central' (though not required) bug-tracking server for all > those coming with bugs on you project-website. there, the current bug list and > state is a available and an interface to add new bugs. then you could place > some sort of hooks into your bugtracker (bt) configuration: > bt/.config/new-> send mail to mail-adress with new bug > then you can manage bug-notification via mailing lists. For users that don't > want to use the website, you could listen on mails in a specific form/with a > specific header to pass it directly to bt parsing it. if the parsing fails, > automagically send a mail back to the composer with annotation where it > failed, > if successfull, send back a success-mail. > > usage could be like (in a distributed way): > $ cd bugs/projectname > bugs/projectname $ bt pull # pulls all new bugreports from server > 7 new bugreports > bugs/projectname $ >51 unresolved bugs > 123 pending bugs > > where 'pending' means that their state is in "needs check if the bugfix works > or not, waiting for approval" or something like that. > > If you want to make comments to a file, make them and afterwards a > bugs/projectname $ bt commit -m "some annotation" > bugs/projectname $ bt send # send new file to whole mailinglist > bugs/projectname $ bt send some.u...@host.tld # send your changeset just to a > specific user > > would do the rest. > > something like that. Didn't think too carefully on it. >
