Re: [dev] [lnanosmtp]
Sorry, I was trying s-nail, and answered by mistake. Have a nice day!
Re: [dev] [lnanosmtp]
Connor Lane Smith wrote:
> On 11 June 2016 at 07:34, wrote:
> > Strings are not idenpotent. In C strings, any pointer inside
> > of the string is a new string. Splitting strings is only
> > writing a 0. Splitting strings in Pascal strings require to
> > allocate a new chunk of memory and copy all the characters.
>
> This is fixed with slices (like in Go) though, as those are not,
>
> struct string { size_t size; char ar[]; };
>
> but,
>
> struct string { size_t size; char *ptr; };
>
> > Fixed maximum size. Pascal strings used a byte for the size,
> > and it meant that you could not have strings bigger than 256.
> > Of course you can increment this size to whatever you want,
> > but then you waste a lot of space.
>
> Clearly the problem with the above is that there is a word of
> overhead, instead of only a byte. Although note that since you can use
> `struct string s` in place of `char *s`, the pointer itself adds no
> additional overhead.
>
> > In both strings you can mess everything if you access out of the limits,
> > so they have the same problem.
>
> A size field does make it much more efficient to perform a bounds
> check though, which makes it easier to be absolutely sure (albeit with
> a performance hit); e.g.
>
> bool inbounds(struct string *s, size_t n) {
> return n < s->size;
> }
>
> vs.
>
> bool inbounds(char *s, size_t n) {
> for (size_t i = 0; i <= n; i++)
> if (s[i] == '\0')
> return false;
> return true;
> }
>
> So, so long as you're willing to take the performance and space hit,
> slices probably are safer. But since everything I've said above is
> also true for arrays, and C arrays don't have explicit length either,
> not very much is really gained. Ultimately, if you want that kind of
> assurance of safety at the cost of performance, you'd probably be
> better off using a memory-safe language instead of C.
>
> Although one unfortunate side effect of C strings is that as soon as
> you have to deal with the possibility of null bytes, everything gets a
> bit awkward.
>
> cls
Re: [dev] [lnanosmtp]
On 11 June 2016 at 07:34, wrote:
> Strings are not idenpotent. In C strings, any pointer inside
> of the string is a new string. Splitting strings is only
> writing a 0. Splitting strings in Pascal strings require to
> allocate a new chunk of memory and copy all the characters.
This is fixed with slices (like in Go) though, as those are not,
struct string { size_t size; char ar[]; };
but,
struct string { size_t size; char *ptr; };
> Fixed maximum size. Pascal strings used a byte for the size,
> and it meant that you could not have strings bigger than 256.
> Of course you can increment this size to whatever you want,
> but then you waste a lot of space.
Clearly the problem with the above is that there is a word of
overhead, instead of only a byte. Although note that since you can use
`struct string s` in place of `char *s`, the pointer itself adds no
additional overhead.
> In both strings you can mess everything if you access out of the limits,
> so they have the same problem.
A size field does make it much more efficient to perform a bounds
check though, which makes it easier to be absolutely sure (albeit with
a performance hit); e.g.
bool inbounds(struct string *s, size_t n) {
return n < s->size;
}
vs.
bool inbounds(char *s, size_t n) {
for (size_t i = 0; i <= n; i++)
if (s[i] == '\0')
return false;
return true;
}
So, so long as you're willing to take the performance and space hit,
slices probably are safer. But since everything I've said above is
also true for arrays, and C arrays don't have explicit length either,
not very much is really gained. Ultimately, if you want that kind of
assurance of safety at the cost of performance, you'd probably be
better off using a memory-safe language instead of C.
Although one unfortunate side effect of C strings is that as soon as
you have to deal with the possibility of null bytes, everything gets a
bit awkward.
cls
Re: [dev] [lnanosmtp]
> I you pointed to a perfect example. While extremely it is extremely > convenient for some architectures to represent strings as a pointer to > char/bytes + an implicit terminator, Pascal strings (really, a > struct/object containing pointer + length) are imminently safer. As This is not true. Pascal strings are not safer. Pascal strings have an advantage over C strings, you don't need to run over the string to know the end of the string. BUT, Pascal strings have a lot of problems: - Fixed maximum size. Pascal strings used a byte for the size, and it meant that you could not have strings bigger than 256. Of course you can increment this size to whatever you want, but then you waste a lot of space. - Strings are not idenpotent. In C strings, any pointer inside of the string is a new string. Splitting strings is only writing a 0. Splitting strings in Pascal strings require to allocate a new chunk of memory and copy all the characters. In both strings you can mess everything if you access out of the limits, so they have the same problem. C strings are very good if you run over all the elements of the string and you want to do some operation over them, but Pasacal strings are good if you want to do random operations over the string, or operations at the end, for example concatenate. As you can see, some operations are eassier in C strings, and other are eassier in Pascal strings, and both are sfer equally if you don't mistake. If you mistake you have the same problems in them. Regards, PD: Pascal strings are not compossed of a size and a pointer, the first byte of the string is the size, the characters are stored after this byte. Thus, the space required for a C string and a Pascal string is the same.
Re: [dev] [lnanosmtp]
On Fri, Jun 10, 2016 at 3:20 AM, FRIGN wrote: > On Fri, 10 Jun 2016 03:02:44 -0700 > Louis Santillan wrote: > > Hey Louis, > >> As to justification, I'd say, that depends. Libc (and C in general) >> has some well known, well documented bugs that exists simply to keep >> old code compiling (many methods that start with str*, malloc/free >> corner but frequent cases, etc). I'd say that's sucks. And that is >> why we have seen the proliferation of languages in the last 30 years >> (since ansi c acceptance). A condition of NIH and a far worse sin >> than trying to fix the situation by utilizing a lower level api. > > can you give an example? Posix sometimes does some weird shit, but > definitely not are bugs standardized. > What I noticed though is that Posix likes to keep the use of "char" > even though it means "byte". I you pointed to a perfect example. While extremely it is extremely convenient for some architectures to represent strings as a pointer to char/bytes + an implicit terminator, Pascal strings (really, a struct/object containing pointer + length) are imminently safer. As is, strings in C are this ambiguous type that lie somewhere in between pointers, arrays, and structs/objects. Complicating this further is the modern need for internationalization (UTF8, UCS2, UTF16, WideChar?) which increases the ambiguity of the underlying data storage and how to interact with it. Making strings an object could fix that. >> Take Plan 9 or Go-lang. Is that NIH? Or is that someone >> experimenting and/or seizing an opportunity to suck less? > > Woah, hold your horses there for a minute. You are comparing a > hacky libc-wannabe-codechunk, hardcoded on top of Linux syscalls > and arch-specific with one maintainer with Plan 9 oder Go? > > I would be the first to go forward and call for maybe a simpler > approach to this whole (or)deal, however, I really don't see > so much that would justify tipping over all existing code built > on top of the libc and starting anew. Does success, or scale, or commercial support, or number of developers make an idea "the right way to do things(tm)" or well designed? If that's true, we all ought to change the subject to Java, JavaScript, and C#/.Net. Instead, I think things/ideas like suckless or Plan9 or Go or alternatives to libc need much work and usage to prove their worth. There are still people waiting on Lisp and Smalltalk.
Re: [dev] [lnanosmtp]
On Fri, Jun 10, 2016 at 3:19 AM, Kamil Cholewiński wrote: > On Fri, 10 Jun 2016, Louis Santillan wrote: >> As to justification, I'd say, that depends. Libc (and C in general) >> has some well known, well documented bugs that exists simply to keep >> old code compiling (many methods that start with str*, malloc/free >> corner but frequent cases, etc). I'd say that's sucks. And that is >> why we have seen the proliferation of languages in the last 30 years >> (since ansi c acceptance). A condition of NIH and a far worse sin >> than trying to fix the situation by utilizing a lower level api. >> >> Take Plan 9 or Go-lang. Is that NIH? Or is that someone >> experimenting and/or seizing an opportunity to suckless? > > Very good points. However I don't think such a low-level framework > belongs as a part of an smtpd. If libc sucks, write a better libc! But > make sure it's well-tested, portable, bug-free, usable, uses good and > sane interfaces, etc etc etc. Then measure adoption in applications > versus other libnih's. I agree Kamil. ulinux could live (and should stand) on its own.
Re: [dev] [lnanosmtp]
On Fri, 10 Jun 2016 03:02:44 -0700 Louis Santillan wrote: Hey Louis, > As to justification, I'd say, that depends. Libc (and C in general) > has some well known, well documented bugs that exists simply to keep > old code compiling (many methods that start with str*, malloc/free > corner but frequent cases, etc). I'd say that's sucks. And that is > why we have seen the proliferation of languages in the last 30 years > (since ansi c acceptance). A condition of NIH and a far worse sin > than trying to fix the situation by utilizing a lower level api. can you give an example? Posix sometimes does some weird shit, but definitely not are bugs standardized. What I noticed though is that Posix likes to keep the use of "char" even though it means "byte". > Take Plan 9 or Go-lang. Is that NIH? Or is that someone > experimenting and/or seizing an opportunity to suck less? Woah, hold your horses there for a minute. You are comparing a hacky libc-wannabe-codechunk, hardcoded on top of Linux syscalls and arch-specific with one maintainer with Plan 9 oder Go? I would be the first to go forward and call for maybe a simpler approach to this whole (or)deal, however, I really don't see so much that would justify tipping over all existing code built on top of the libc and starting anew. Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Fri, 10 Jun 2016, Louis Santillan wrote: > As to justification, I'd say, that depends. Libc (and C in general) > has some well known, well documented bugs that exists simply to keep > old code compiling (many methods that start with str*, malloc/free > corner but frequent cases, etc). I'd say that's sucks. And that is > why we have seen the proliferation of languages in the last 30 years > (since ansi c acceptance). A condition of NIH and a far worse sin > than trying to fix the situation by utilizing a lower level api. > > Take Plan 9 or Go-lang. Is that NIH? Or is that someone > experimenting and/or seizing an opportunity to suckless? Very good points. However I don't think such a low-level framework belongs as a part of an smtpd. If libc sucks, write a better libc! But make sure it's well-tested, portable, bug-free, usable, uses good and sane interfaces, etc etc etc. Then measure adoption in applications versus other libnih's.
Re: [dev] [lnanosmtp]
On Friday, June 10, 2016, FRIGN wrote: > > On Thu, 9 Jun 2016 23:06:54 -0700 > Louis Santillan wrote: > > Hey Louis, > > > Good job for getting this working. I'm a believer that suckless > > indirectly speaks to API design in addition to software design. There > > are many parts of libc that suck, IMO. Years ago, when I found Felix > > von Leitner's talk about software design [0], and dietlibc [1], and > > libdjb [2], and libowfat [3], I became curious about exploring other > > runtimes for C [4][5][6][7][8][9]. Keep applying your ulinux runtime. > > are you joking? This reeks of NiH. In many regards, Posix has issues > and without doubt, they can hinder you. But does it really justify > just handrolling your own, unportable, probably buggy libc? As to justification, I'd say, that depends. Libc (and C in general) has some well known, well documented bugs that exists simply to keep old code compiling (many methods that start with str*, malloc/free corner but frequent cases, etc). I'd say that's sucks. And that is why we have seen the proliferation of languages in the last 30 years (since ansi c acceptance). A condition of NIH and a far worse sin than trying to fix the situation by utilizing a lower level api. Take Plan 9 or Go-lang. Is that NIH? Or is that someone experimenting and/or seizing an opportunity to suckless?
Re: [dev] [lnanosmtp]
On Thu, 9 Jun 2016 23:06:54 -0700 Louis Santillan wrote: Hey Louis, > Good job for getting this working. I'm a believer that suckless > indirectly speaks to API design in addition to software design. There > are many parts of libc that suck, IMO. Years ago, when I found Felix > von Leitner's talk about software design [0], and dietlibc [1], and > libdjb [2], and libowfat [3], I became curious about exploring other > runtimes for C [4][5][6][7][8][9]. Keep applying your ulinux runtime. are you joking? This reeks of NiH. In many regards, Posix has issues and without doubt, they can hinder you. But does it really justify just handrolling your own, unportable, probably buggy libc? Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
[i have too much time][i have too much time][i have too much time][i have too much time][i have too much time][i have too much time][i have too much time] On 6/10/16, Louis Santillan wrote: > Sylvain, > > Good job for getting this working. I'm a believer that suckless > indirectly speaks to API design in addition to software design. There > are many parts of libc that suck, IMO. Years ago, when I found Felix > von Leitner's talk about software design [0], and dietlibc [1], and > libdjb [2], and libowfat [3], I became curious about exploring other > runtimes for C [4][5][6][7][8][9]. Keep applying your ulinux runtime. > > > [0] https://www.fefe.de/dietlibc/diet.pdf > [1] https://www.fefe.de/dietlibc/ > [2] https://www.fefe.de/djb/ > [3] https://www.fefe.de/libowfat/ > [4] https://github.com/lpsantil/rt0 > [5] https://github.com/lunixbochs/lib43 > [6] https://gist.github.com/lpsantil/99cddf60ad6c8ae8756f > [7] http://www.erik-n.net/studies/linux_boot_c/linux_boot_c.pdf > [8] https://blogs.oracle.com/ksplice/entry/hello_from_a_libc_free > [9] http://c0.typesafety.net/tutorial/Strings.html > > On Thu, Jun 9, 2016 at 6:09 PM, Sylvain BERTRAND > wrote: >> On Thu, Jun 09, 2016 at 07:18:21PM +0200, Markus Wichmann wrote: >>> 3. smtp_line_send() can't handle short writes, because the pointer that >>> is handed in as second argument to write() is never advanced... >> >> Fixed. >> >> Thx! >> >> -- >> Sylvain >> > >
Re: [dev] [lnanosmtp]
Sylvain, Good job for getting this working. I'm a believer that suckless indirectly speaks to API design in addition to software design. There are many parts of libc that suck, IMO. Years ago, when I found Felix von Leitner's talk about software design [0], and dietlibc [1], and libdjb [2], and libowfat [3], I became curious about exploring other runtimes for C [4][5][6][7][8][9]. Keep applying your ulinux runtime. [0] https://www.fefe.de/dietlibc/diet.pdf [1] https://www.fefe.de/dietlibc/ [2] https://www.fefe.de/djb/ [3] https://www.fefe.de/libowfat/ [4] https://github.com/lpsantil/rt0 [5] https://github.com/lunixbochs/lib43 [6] https://gist.github.com/lpsantil/99cddf60ad6c8ae8756f [7] http://www.erik-n.net/studies/linux_boot_c/linux_boot_c.pdf [8] https://blogs.oracle.com/ksplice/entry/hello_from_a_libc_free [9] http://c0.typesafety.net/tutorial/Strings.html On Thu, Jun 9, 2016 at 6:09 PM, Sylvain BERTRAND wrote: > On Thu, Jun 09, 2016 at 07:18:21PM +0200, Markus Wichmann wrote: >> 3. smtp_line_send() can't handle short writes, because the pointer that >> is handed in as second argument to write() is never advanced... > > Fixed. > > Thx! > > -- > Sylvain >
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 07:18:21PM +0200, Markus Wichmann wrote: > 3. smtp_line_send() can't handle short writes, because the pointer that > is handed in as second argument to write() is never advanced... Fixed. Thx! -- Sylvain
Re: [dev] [lnanosmtp]
On 06/09/2016 01:35 PM, FRIGN wrote: On Thu, 9 Jun 2016 19:18:21 +0200 Markus Wichmann wrote: Hey Markus, Dear Lord, it's been a while since I've seen such nice code make so bafflingly bad design choices. Where to start? the suckless mailing list is not a place for religious cults. 1. The whole ulinux thing smacks a bit of NIH syndrome to me. And of course, it kisses portability goodbye, but then that wasn't your goal at all. With only i386 and AMD64 supported, I wonder why this isn't in assembler. Holy shit, FRIGN, you hypocrite. The suckless mailing list is not a place for religious cults.
Re: [dev] [lnanosmtp]
On Thu, 9 Jun 2016 19:18:21 +0200 Markus Wichmann wrote: Hey Markus, > Dear Lord, it's been a while since I've seen such nice code make so > bafflingly bad design choices. Where to start? the suckless mailing list is not a place for religious cults. > 1. The whole ulinux thing smacks a bit of NIH syndrome to me. And of > course, it kisses portability goodbye, but then that wasn't your goal at > all. With only i386 and AMD64 supported, I wonder why this isn't in > assembler. Holy shit, I can't even put in words how much NiH it is. Compared to this, Ubuntu's "Mir" was a work of genius! > 2. You immediately block all signals on entry. That means: > - SIGINT, SIGQUIT, SIGTSTP, SIGTTOU, SIGTTIN: There is no way to > control the process from a terminal. You have to get another > terminal out to kill it. > - SIGSEGV, SIGILL, SIGBUS: Undefined behaviour if your code does > anything to warrant the sending of those signals. > - SIGCHLD: Zombies and no way of knowing about them. Why don't you > just ignore it? > - SIGXCPU, SIGXFSZ: No way to gracefully close on reaching ulimits. > And so on, and so forth. And for what? So you can handle signals using > signalfd. That would be good if you actually did that. However, that > only happens if the client never stalls out on you. Yeah, the SIGCHLD thing is definitely a point to consider. If you ignore it, the program will reap children automatically. > 4. Synchronous communication, no forking, no threading --> One client at > a time. So you're using epoll on the same two sockets all the time, > which means you might as well not have bothered. I prefer poll over threads/forks, but yeah, it really is crazy here. > Still, it could easily be salvaged: Drop all the setup code for the > server socket and make the code read from stdin and write to stdout. > Then this server can be run from inetd, or through any ucspi > implementation. That will also remove the glaring issue that the program > must be run as root and doesn't drop privileges even when it's done > doing privileged things. Very good point! Definitely a very good point. It would also simplify the code a lot. > 5. Exiting at the drop of a hat: Your only error handling is to exit, > unless it was an expected error (usually EINTR). That's the opposite of > PHP, I guess, but that doesn't make it better. This is okay for one-shot-tools, but definitely not for servers. > 6. You do know that if you used a C library, you'd have access to > strchr(), strcpy(), and the like, right? Because you seem to be having a > jolly good time rewriting those over and over again. Which is a big shame. He could've saved some LOCs using a bloody libc. > 7. What's with the S_IFMT constants? You're binding hard to the syscall > interface, you can use 0666, it's not getting any less portable now. > 8. You do know that C has more loop contructs than just the endless one, > right? Because I'm seeing a lot of endless loops that are basically > do-while loops, or counting loops... C has structured programming. Use > it! Please... > 9. Oh wait, I see that you have strcpy(), you just don't use it. > Alrighty then. > And that was just what I saw in lnanosmtp.c. And I didn't check the > protocol. It's just a big fucking mess there is no need for. Sylvain, sit down again, use a fucking libc so fucking BSD users and other arch users can fucking use your shit. Then we can talk. Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 10:50:56PM +1100, Sylvain BERTRAND wrote: > Hi, > > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > https://github.com/sylware/lnanosmtp > https://repo.or.cz/lnanosmtp.git > > cheers, > > -- > Sylvain > Dear Lord, it's been a while since I've seen such nice code make so bafflingly bad design choices. Where to start? 1. The whole ulinux thing smacks a bit of NIH syndrome to me. And of course, it kisses portability goodbye, but then that wasn't your goal at all. With only i386 and AMD64 supported, I wonder why this isn't in assembler. 2. You immediately block all signals on entry. That means: - SIGINT, SIGQUIT, SIGTSTP, SIGTTOU, SIGTTIN: There is no way to control the process from a terminal. You have to get another terminal out to kill it. - SIGSEGV, SIGILL, SIGBUS: Undefined behaviour if your code does anything to warrant the sending of those signals. - SIGCHLD: Zombies and no way of knowing about them. Why don't you just ignore it? - SIGXCPU, SIGXFSZ: No way to gracefully close on reaching ulimits. And so on, and so forth. And for what? So you can handle signals using signalfd. That would be good if you actually did that. However, that only happens if the client never stalls out on you. 3. smtp_line_send() can't handle short writes, because the pointer that is handed in as second argument to write() is never advanced, nor is the unwritten part memmove()d to the front, as ridiculous as that would be. 4. Synchronous communication, no forking, no threading --> One client at a time. So you're using epoll on the same two sockets all the time, which means you might as well not have bothered. Still, it could easily be salvaged: Drop all the setup code for the server socket and make the code read from stdin and write to stdout. Then this server can be run from inetd, or through any ucspi implementation. That will also remove the glaring issue that the program must be run as root and doesn't drop privileges even when it's done doing privileged things. 5. Exiting at the drop of a hat: Your only error handling is to exit, unless it was an expected error (usually EINTR). That's the opposite of PHP, I guess, but that doesn't make it better. 6. You do know that if you used a C library, you'd have access to strchr(), strcpy(), and the like, right? Because you seem to be having a jolly good time rewriting those over and over again. 7. What's with the S_IFMT constants? You're binding hard to the syscall interface, you can use 0666, it's not getting any less portable now. 8. You do know that C has more loop contructs than just the endless one, right? Because I'm seeing a lot of endless loops that are basically do-while loops, or counting loops... C has structured programming. Use it! Please... 9. Oh wait, I see that you have strcpy(), you just don't use it. Alrighty then. And that was just what I saw in lnanosmtp.c. And I didn't check the protocol. Ciao, Markus
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 03:41:22PM +0200, FRIGN wrote: > This is so full of bullshit. There's no reason e.g. not to make it > compilable on the BSD's. The Linux syscall-interface is also prone > to changes. If the Linux syscall interface changes in a non backwards-compat manner then it is consider a bug. This is unlike to what happens in the BSD world. Regardless though, not using libc for such a project is just stubborn and inflexible.
Re: [dev] [lnanosmtp]
On Thu, 09 Jun 2016 15:02:29 +0200 Kamil Cholewiński wrote: Hey Kamil, > So libc is overkill, but instead you ship an entire tangled hierarchy of > nonportable and arch-specific headers to talk directly to the kernel, > which will all probably break in a random point release. I couldn't agree more. > > Overkill, don't need that much. This is so full of bullshit. There's no reason e.g. not to make it compilable on the BSD's. The Linux syscall-interface is also prone to changes. You should really re-think this decision. If you talk about overkill, what is the big deal? You'll find a libc in any system really, and even for crazy embedded cases, you could just create a statically linked binary. Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: > On Thu, Jun 09, 2016 at 02:03:33PM +0200, Kamil Cholewiński wrote: >> On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: >> > Hi, >> > >> > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp >> > >> > https://github.com/sylware/lnanosmtp >> > https://repo.or.cz/lnanosmtp.git >> > >> > cheers, >> > >> > -- >> > Sylvain >> >> Ages old, stupid question. What's wrong with libc? > > Overkill, don't need that much. > > -- > Sylvain So libc is overkill, but instead you ship an entire tangled hierarchy of nonportable and arch-specific headers to talk directly to the kernel, which will all probably break in a random point release. To receive mail. Interesting.
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 02:04:07PM +0200, FRIGN wrote: > On Thu, 9 Jun 2016 22:50:56 +1100 > Sylvain BERTRAND wrote: > > Hey Sylvain, > > > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > > > https://github.com/sylware/lnanosmtp > > https://repo.or.cz/lnanosmtp.git > > I looked at the code and wondered: what the hell is ulinux? :P userland linux: kind of linux uapi headers and little bit more. -- Sylvain
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 02:03:33PM +0200, Kamil Cholewiński wrote: > On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: > > Hi, > > > > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > > > https://github.com/sylware/lnanosmtp > > https://repo.or.cz/lnanosmtp.git > > > > cheers, > > > > -- > > Sylvain > > Ages old, stupid question. What's wrong with libc? Overkill, don't need that much. -- Sylvain
Re: [dev] [lnanosmtp]
On Thu, 9 Jun 2016 22:50:56 +1100 Sylvain BERTRAND wrote: Hey Sylvain, > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > https://github.com/sylware/lnanosmtp > https://repo.or.cz/lnanosmtp.git I looked at the code and wondered: what the hell is ulinux? :P Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: > Hi, > > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > https://github.com/sylware/lnanosmtp > https://repo.or.cz/lnanosmtp.git > > cheers, > > -- > Sylvain Ages old, stupid question. What's wrong with libc?
