Re: [dev] GSoC 2010

2010-03-04 Thread Szabolcs Nagy
let me summarise the ideas so far:

stali
ld wrapper
window system
bug and issue tracker
improve dmc (mail)
widget tool kit
dwm in go
text indexing
ssl cert validation for surf
text editor
improve st (terminal)
port scanner

if we need to focus the application in one area then these are not
very good i guess..



Re: [dev] GSoC 2010

2010-03-04 Thread Anselm R Garbe
On 4 March 2010 11:40, Szabolcs Nagy  wrote:
> let me summarise the ideas so far:
>
> stali
> ld wrapper
> window system
> bug and issue tracker
> improve dmc (mail)
> widget tool kit
> dwm in go
> text indexing
> ssl cert validation for surf
> text editor
> improve st (terminal)
> port scanner
>
> if we need to focus the application in one area then these are not
> very good i guess..

Uriel was proposing goblin in #cat-v, basically unix/plan9 userland
written in Go.

Cheers,
Anselm



Re: [dev] GSoC 2010

2010-03-04 Thread pancake

Szabolcs Nagy wrote:

let me summarise the ideas so far:

stali
ld wrapper
  

I didnt understood the concept at all. can somebody explain it better?

window system
  
a friend of me, who is a enlightenment developer is writing a new 
graphical system
to replace X windows, it is not suckless, but really minimal, well 
designed and much
more well done than the Xwindowing system (its not that hard to do it 
better :P) I

can talk to him so maybe we can push this project.

Its design supports multiple local/remote graphical devices, its 
everything done in
userland, even framebuffer drivers for two ARM boards and SDL for normal 
testing.


Actually is focusing on 2D, but will support XV and shaders for 
opengl-es at some point,
he doesnt wants to fill the stack will the current shit of X11 where 
there are several
layers to do the same shit. Another thing that could be implemented is a 
seamless X11
integration, so you can run X11 apps by grabbing the buffer of the 
window and rendering
it into the graphical server. So it will not be 'that hard' to move from 
Xorg to it.

bug and issue tracker
improve dmc (mail)
  

+1

widget tool kit
  
Anselm and me were discussing about the widget toolkit, the code name of 
the project
is "dwk" Dynamic Widget Kit. which is atm just a README with few random 
ideas.


We (arg and me) are currently quite busy, but we plan to start working 
on it before the
end of this month (at least me). If any of you want to have a look on 
the current status
of the project check the mercurial repo. Feel free to open a new thread 
and discuss

ideas, proposals, etc, for it.

 http://hg.youterm.com/dwk

dwm in go
  

i dont see the point a part that the fun of doing it.

text indexing
  

??

ssl cert validation for surf
  

+1

There are several other issues in surf

1) infinite loops in some situations (redirects with closed socket 
instead of keepalive)
2) segmentation faults when using AJAX using local files instead of 
remote ones

3) multiple empty queries when returning NULL headers by the server
4) downloads not working at all (i still have issues with them)
5) context menu doesnt allows to copy url of a picture
6) no automatic history support to log all visited urls with dmenu 
autocompletion

...

text editor
  

this depends on the widget toolkit and its a quite difficult task.

improve st (terminal)
  

+1

port scanner

  
the port scanner is already done, but needs some enhacements, like 
support for
scanning multiples IPs without having to use shell loops. i always 
wanted something

minimal for "nmap -sP 192.168.0.*"

if we need to focus the application in one area then these are not
very good i guess..

  





Re: [dev] GSoC 2010

2010-03-04 Thread Frederic DUBOIS
>> widget tool kit
>>
>
> Anselm and me were discussing about the widget toolkit, the code name of the
> project
> is "dwk" Dynamic Widget Kit. which is atm just a README with few random
> ideas.
>
>  http://hg.youterm.com/dwk

Something like GraphApp? (http://www.enchantia.com/software/graphapp/)



Re: [dev] GSoC 2010

2010-03-04 Thread Mate Nagy
On Thu, Mar 04, 2010 at 01:14:37PM +0100, Frederic DUBOIS wrote:

> Something like GraphApp? (http://www.enchantia.com/software/graphapp/)
looks nice until you realize it doesn't support fonts (and they even
ideologized it for themselves in the FAQ)

Mate



[dev] Re: Simple port scanner again (was: GSoC 2010)

2010-03-04 Thread anonymous
On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
> 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.

I have already posted a thread about port scanner in this list. Here is
the code: http://bitbucket.org/noname/netscan/

It can scan with TCP connect, raw TCP sockets and raw UDP sockets. There
is no delay/timeout calculation, default delay is 1 second (like ping),
obviously too high for most uses so it can be changed. Probably I should
write some README and improve man pages.

It's biggest problem is pthreads. main() starts scanning thread and
outputs all scanned hosts until there is no hosts left. Then it waits
for second thread and exits. pthreads is bad, but I don't know what is
better.




Re: [dev] GSoC 2010

2010-03-04 Thread pancake

Mate Nagy wrote:

On Thu, Mar 04, 2010 at 01:14:37PM +0100, Frederic DUBOIS wrote:

  

Something like GraphApp? (http://www.enchantia.com/software/graphapp/)


looks nice until you realize it doesn't support fonts (and they even
ideologized it for themselves in the FAQ)

Mate

  

why do you need TTF? font rendering is a really complex stuff, in dwk
we were only planning to support monospaced fonts, calculate sizes
with changing size of fonts is really complex and cpu-intensive task and
i dont think it matters to the user.

i dont want comic sans in my "desktop"

--pancake



Re: [dev] GSoC 2010

2010-03-04 Thread Frederic DUBOIS
2010/3/4 Mate Nagy :
> On Thu, Mar 04, 2010 at 01:14:37PM +0100, Frederic DUBOIS wrote:
>
>> Something like GraphApp? (http://www.enchantia.com/software/graphapp/)
> looks nice until you realize it doesn't support fonts (and they even
> ideologized it for themselves in the FAQ)
>

It does. It is even easier and more convenient to use the system fonts
than the portable fonts.



Re: [dev] GSoC 2010

2010-03-04 Thread Anselm R Garbe
On 4 March 2010 12:14, Frederic DUBOIS  wrote:
>>> widget tool kit
>>>
>>
>> Anselm and me were discussing about the widget toolkit, the code name of the
>> project
>> is "dwk" Dynamic Widget Kit. which is atm just a README with few random
>> ideas.
>>
>>  http://hg.youterm.com/dwk
>
> Something like GraphApp? (http://www.enchantia.com/software/graphapp/)

Hmm, something simpler than that ;)

Cheers,
Anselm



Re: [dev] GSoC 2010

2010-03-04 Thread Connor Lane Smith
On 4 March 2010 11:40, Szabolcs Nagy  wrote:
> if we need to focus the application in one area then these are not
> very good i guess..

A lot of them have a theme, though. Gnome's GSoC theme is basically
their desktop environment, which is fairly broad itself. If Suckless
focus on a development environment (similar, but not so crufty),
suggested projects include;

OS: stali
WS: dws
WM: godwm
Toolkit: dwk
Web: surf ssl certs
Mail: dmc
Editor: samterm?
Term: st
Search?

There may be others (bugs and goblins?), but that's quite a cohesive
collection really. The only issue Google could bring up is that
Suckless is fairly small, and that it may be too broad for its size.
I'm not sure that can be avoided though.

On Thu, Mar 4, 2010 at 12:07 PM, pancake  wrote:
> > text editor
> this depends on the widget toolkit and its a quite difficult task.

This is true, unless it uses curses.

cls



Re: [dev] Re: Simple port scanner again (was: GSoC 2010)

2010-03-04 Thread Anselm R Garbe
On 4 March 2010 12:33, anonymous  wrote:
> On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
>> 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.
>
> I have already posted a thread about port scanner in this list. Here is
> the code: http://bitbucket.org/noname/netscan/
>
> It can scan with TCP connect, raw TCP sockets and raw UDP sockets. There
> is no delay/timeout calculation, default delay is 1 second (like ping),
> obviously too high for most uses so it can be changed. Probably I should
> write some README and improve man pages.
>
> It's biggest problem is pthreads. main() starts scanning thread and
> outputs all scanned hosts until there is no hosts left. Then it waits
> for second thread and exits. pthreads is bad, but I don't know what is
> better.

What about fork()? Nowadays hardware is so powerful ;) fork() results
in nicer code ;)

Cheers,
Anselm



Re: [dev] GSoC 2010

2010-03-04 Thread Mate Nagy
On Thu, Mar 04, 2010 at 01:44:04PM +0100, pancake wrote:

> why do you need TTF? font rendering is a really complex stuff, in dwk
yes
> we were only planning to support monospaced fonts, calculate sizes
yes
> with changing size of fonts is really complex and cpu-intensive task and
yes
> i dont think it matters to the user.
no, sorry

In non-uriel style, yes, font rendering is horribly complicated and an
entirely fucked up discipline, but I don't think a "real" widget set can
skip out on it. Bitmap fonts are fine for programming (and I even use it
for web browsing when it's dark and I switch the theme to
white-on-black), but often sub-pixel tuned ttf is just more comfortable
to read.

Actually I wrote a similar widget set that I use in frtplot
(frtplot.port70.net), straight C and everything, and.. it only does
bitmap font rendering (no Unicode though). But I wouldn't want to use it
for software that isn't exclusively for programmers..

Mate



Re: [dev] GSoC 2010

2010-03-04 Thread Anselm R Garbe
On 4 March 2010 12:48, Connor Lane Smith  wrote:
> On 4 March 2010 11:40, Szabolcs Nagy  wrote:
>> if we need to focus the application in one area then these are not
>> very good i guess..
>
> A lot of them have a theme, though. Gnome's GSoC theme is basically
> their desktop environment, which is fairly broad itself. If Suckless
> focus on a development environment (similar, but not so crufty),
> suggested projects include;
>
> OS: stali
> WS: dws
> WM: godwm
> Toolkit: dwk
> Web: surf ssl certs
> Mail: dmc
> Editor: samterm?
> Term: st
> Search?
>
> There may be others (bugs and goblins?), but that's quite a cohesive
> collection really. The only issue Google could bring up is that
> Suckless is fairly small, and that it may be too broad for its size.
> I'm not sure that can be avoided though.

Apparently that was no reason last year according to them. Well and
they accepted smaller projects in the past...

Cheers,
Anselm



Re: [dev] GSoC 2010

2010-03-04 Thread Anselm R Garbe
On 4 March 2010 12:51, Mate Nagy  wrote:
> On Thu, Mar 04, 2010 at 01:44:04PM +0100, pancake wrote:
>
>> why do you need TTF? font rendering is a really complex stuff, in dwk
> yes
>> we were only planning to support monospaced fonts, calculate sizes
> yes
>> with changing size of fonts is really complex and cpu-intensive task and
> yes
>> i dont think it matters to the user.
> no, sorry
>
> In non-uriel style, yes, font rendering is horribly complicated and an
> entirely fucked up discipline, but I don't think a "real" widget set can
> skip out on it. Bitmap fonts are fine for programming (and I even use it
> for web browsing when it's dark and I switch the theme to
> white-on-black), but often sub-pixel tuned ttf is just more comfortable
> to read.
>
> Actually I wrote a similar widget set that I use in frtplot
> (frtplot.port70.net), straight C and everything, and.. it only does
> bitmap font rendering (no Unicode though). But I wouldn't want to use it
> for software that isn't exclusively for programmers..

Well one design decision for the API I'm in favor with is not to
provide any font-related functionality in the first version and leave
font rendering up to the implementation. If someone writes an app he
shouldn't bother about the fonts/colors etc, he should concentrate on
the functionality -- this also enforces a consistent look among all
programs that might use dwk.

Cheers,
Anselm



Re: [dev] Re: Simple port scanner again

2010-03-04 Thread anonymous
> What about fork()? Nowadays hardware is so powerful ;) fork() results
> in nicer code ;)

Creating thread is not as complex as passing host structures. For example,
libthread from Plan 9 has channels. With pthread I should use condition
variables and mutexes to implement queue.




Re: [dev] GSoC 2010

2010-03-04 Thread Mate Nagy
On Thu, Mar 04, 2010 at 12:57:31PM +, Anselm R Garbe wrote:
> Well one design decision for the API I'm in favor with is not to
> provide any font-related functionality in the first version and leave
> font rendering up to the implementation. If someone writes an app he
> shouldn't bother about the fonts/colors etc, he should concentrate on
> the functionality -- this also enforces a consistent look among all
> programs that might use dwk.
 I agree something like this would be fantastic for small suckless GUI
projects (if that wasn't an oxymoron... but I'm not certain about this
at all, either way)

Mate



Re: [dev] GSoC 2010

2010-03-04 Thread anonymous
On Thu, Mar 04, 2010 at 01:51:12PM +0100, Mate Nagy wrote:
> In non-uriel style, yes, font rendering is horribly complicated and an
> entirely fucked up discipline, but I don't think a "real" widget set can
> skip out on it. Bitmap fonts are fine for programming (and I even use it
> for web browsing when it's dark and I switch the theme to
> white-on-black), but often sub-pixel tuned ttf is just more comfortable
> to read.

I really think sub-pixel antialiasing is a good topic for harmful.cat-v.org.




Re: [dev] Re: Simple port scanner again (was: GSoC 2010)

2010-03-04 Thread Dmitry Maluka
On Thu, Mar 04, 2010 at 03:33:53PM +0300, anonymous wrote:
> On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
> > 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.
> 
> I have already posted a thread about port scanner in this list. Here is
> the code: http://bitbucket.org/noname/netscan/
> 
> It can scan with TCP connect, raw TCP sockets and raw UDP sockets. There
> is no delay/timeout calculation, default delay is 1 second (like ping),
> obviously too high for most uses so it can be changed. Probably I should
> write some README and improve man pages.
> 
> It's biggest problem is pthreads. main() starts scanning thread and
> outputs all scanned hosts until there is no hosts left. Then it waits
> for second thread and exits. pthreads is bad, but I don't know what is
> better.

Maybe I miss something, but why not just output results as far as hosts
are scanned? Output isn't that slow to use threads.



Re: [dev] GSoC 2010

2010-03-04 Thread hiro
Sub-pixel antialiasing - the vengeance of the color-blind ;)



Re: [dev] Re: Simple port scanner again (was: GSoC 2010)

2010-03-04 Thread anonymous
On Thu, Mar 04, 2010 at 08:14:17PM +0200, Dmitry Maluka wrote:
> Maybe I miss something, but why not just output results as far as hosts
> are scanned? Output isn't that slow to use threads.

The main idea was abstraction: scanning function just pass scanned host
to next stage instead of calling output function.

It may be good idea to use plan9port, I have just compiled portscan with
9c/9l and it works. What about using libthread instead of pthreads? It
depends on pthreads, right?




Re: [dev] Re: Simple port scanner again (was: GSoC 2010)

2010-03-04 Thread Dmitry Maluka
On Thu, Mar 04, 2010 at 11:00:05PM +0300, anonymous wrote:
> On Thu, Mar 04, 2010 at 08:14:17PM +0200, Dmitry Maluka wrote:
> > Maybe I miss something, but why not just output results as far as hosts
> > are scanned? Output isn't that slow to use threads.
> 
> The main idea was abstraction: scanning function just pass scanned host
> to next stage instead of calling output function.

What is the profit from this abstraction? You call remove_scanned()
which moves host from host queue to scanned queue; output() takes hosts
from scanned queue and calls hostprint() for them; and you do
synchronization. Why not just call hostprint() at the beginning?



Re: [dev] GSoC 2010

2010-03-04 Thread Josh Rickmar
On Thu, Mar 04, 2010 at 12:40:17PM +0100, Szabolcs Nagy wrote:
> let me summarise the ideas so far:
> 
> stali
> ld wrapper
> window system
> bug and issue tracker
> improve dmc (mail)
> widget tool kit
> dwm in go
> text indexing
> ssl cert validation for surf
> text editor
> improve st (terminal)
> port scanner
> 
> if we need to focus the application in one area then these are not
> very good i guess..
> 

What about a usable interface for facebook? IIRC, there was some talk
about this on this list a while back.



Re: [dev] GSoC 2010

2010-03-04 Thread Uriel
Here is an idea the Google folks might like: Port sta.li (and p9p?) to
use Android's libc. AFAIK there is no real linux distro that uses the
Android libc, and this would be a project that might be useful for
everyone.

uriel

On Wed, Mar 3, 2010 at 9:41 AM, Anselm R Garbe  wrote:
> 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

2010-03-04 Thread Uriel
On Thu, Mar 4, 2010 at 2:13 PM, anonymous  wrote:
> I really think sub-pixel antialiasing is a good topic for harmful.cat-v.org.

I don't know enough about this to form a remotely useful opinion, much
less rant about it. But contributions to harmful.cat-v.org are always
welcome...

uriel



Re: [dev] GSoC 2010

2010-03-04 Thread Uriel
I will note that one of the original goals for creating werc was to
help build a sane replacement for the kinds of things trac does,
including bug tracking. I would be happy to mentor any project that
works in that direction.

uriel

On Wed, Mar 3, 2010 at 9:53 AM, 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

2010-03-04 Thread Uriel
On Wed, Mar 3, 2010 at 5:38 PM, 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.

Yes! I love all this ideas!

> 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 completely agree. Suckless needs a cohesive goal, and creating the
components of a simple, clean and elegant development environment that
is true to the original Unix principles is a good such goal.

uriel

>
> --
> - yiyus || JGL . 4l77.com
>
>



Re: [dev] GSoC 2010

2010-03-04 Thread Uriel
On Wed, Mar 3, 2010 at 7:30 PM, yy  wrote:
> 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.

As I said in #cat-v, I don't think it makes much sense, a great part
of the essence of werc is that it is just a bunch of shell pipelines,
and that makes customization and specialized one-off apps and other
hacks really beautiful, because you can often do it by just adding an
extra sed(1) or grep(1) call here or there.

What I would like is to see rc and the rest of the p9p commands ported
to Go, which is the goal of the Goblin project:
http://repo.cat-v.org/goblin/ Some people have already started to do
work on this (I'm a lazy asshole that has been distracted by other
things, but I hope to get to it).

Then werc could run directly on the Go toolset.

uriel

> --
> - yiyus || JGL . 4l77.com
>
>



Re: [dev] GSoC 2010

2010-03-04 Thread Uriel
On Wed, Mar 3, 2010 at 9:30 PM, Charlie Kester  wrote:
> 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".

No, it is called "killfile".

uriel



Re: [dev] GSoC 2010

2010-03-04 Thread Uriel
On Thu, Mar 4, 2010 at 12:40 PM, Szabolcs Nagy  wrote:
> let me summarise the ideas so far:
>
> stali
> ld wrapper
> window system
> bug and issue tracker
> improve dmc (mail)
> widget tool kit
> dwm in go
> text indexing
> ssl cert validation for surf
> text editor
> improve st (terminal)
> port scanner
>
> if we need to focus the application in one area then these are not
> very good i guess..

st and dmc are two projects that without doubt should be rewritten in Go.

Window system, widget toolkit, text editor, and text indexing seem too
general/unfocused/ambitious/limited. In my experience this kinds of
GSoC projects are a bad idea and tend to produce useless mush (if they
produce anything at all).

Port scanner seems way too unrelated and unconnected to most of what
suckless does (I'm not against it, but doesn't seem like a good idea
if Google already thinks suckless is too much of a random bag of
stuff).

SSL validation for surf is plain stupid, why the hell is a whole
project needed for that? Could just as well propose writing a
replacement for OpenSSL (and yes, OpenSSL *sucks*, but if you think
you can replace it you are an idiot).

uriel



Re: [dev] Re: Simple port scanner again (was: GSoC 2010)

2010-03-04 Thread Uriel
On Thu, Mar 4, 2010 at 1:49 PM, Anselm R Garbe  wrote:
> On 4 March 2010 12:33, anonymous  wrote:
>> On Wed, Mar 03, 2010 at 03:25:38PM -0600, eze.program...@gmail.com wrote:
>>> 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.
>>
>> I have already posted a thread about port scanner in this list. Here is
>> the code: http://bitbucket.org/noname/netscan/
>>
>> It can scan with TCP connect, raw TCP sockets and raw UDP sockets. There
>> is no delay/timeout calculation, default delay is 1 second (like ping),
>> obviously too high for most uses so it can be changed. Probably I should
>> write some README and improve man pages.
>>
>> It's biggest problem is pthreads. main() starts scanning thread and
>> outputs all scanned hosts until there is no hosts left. Then it waits
>> for second thread and exits. pthreads is bad, but I don't know what is
>> better.
>
> What about fork()? Nowadays hardware is so powerful ;) fork() results
> in nicer code ;)

Or rewrite in Go. In any case, using pthreads is plain *RETARDED*.

uriel



Re: [dev] GSoC 2010

2010-03-04 Thread Josh Rickmar
On Thu, Mar 04, 2010 at 11:19:01PM +0100, Uriel wrote:
> I will note that one of the original goals for creating werc was to
> help build a sane replacement for the kinds of things trac does,
> including bug tracking. I would be happy to mentor any project that
> works in that direction.
> 
> uriel

This seems like a project that I could do. I would like to do something
like Goblin, but Go doesn't yet run on my OS (OpenBSD).

Josh



Re: [dev] GSoC 2010

2010-03-04 Thread pancake

Gogcc should work. Else you have Linux emulation.

On Mar 5, 2010, at 12:36 AM, Josh Rickmar   
wrote:



On Thu, Mar 04, 2010 at 11:19:01PM +0100, Uriel wrote:

I will note that one of the original goals for creating werc was to
help build a sane replacement for the kinds of things trac does,
including bug tracking. I would be happy to mentor any project that
works in that direction.

uriel


This seems like a project that I could do. I would like to do  
something

like Goblin, but Go doesn't yet run on my OS (OpenBSD).

Josh