[dev] suckless hackathon on IRC

[Anselm R Garbe]

Hi there,

all attendees should join #slcon4 @ irc.oftc.net

BR,
Anselm

Re: [dev] Some suckless hackathon 2017 preparation

[Anselm R Garbe]

Hi Michael,

On 1 September 2017 at 19:55, Michael Forney  wrote:
> I hope the wayland-related work at the hackathon won't just be
> duplicates of my efforts.

We will make sure to avoid duplicate efforts.

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 1 September 2017 at 17:05, Janne Heß  wrote:
> If you set the HSTS header for HTTPS connections, people will
> automtically redirected to HTTPS if they visited once.
> This would give an improved security because browsers would
> automatically redirect to HTTPS while you could still telnet/curl it
> without having to use HTTPS.

Already discussed, see above.

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 1 September 2017 at 10:33, Laslo Hunhold  wrote:
> Having given this a lot of thought over the last few days, I think
> going with the redirect is the proper approach.

The redirect is infantalizing the visitor. If I open a http:// URL I'm
aware of the implications.

Please end this discussion. There are more important things to do.

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 1 September 2017 at 10:15, ilf  wrote:
> No, I am serious. Users, who think HTTPS sucks, shouldn't use HTTP euther,
> because that sucks, too. The choice shouldn't be HTTPS or HTTP, but HTTPS or
> Gopher. But please let HTTP die.

Gopher is long dead, only some retro-enthusiasts are running gopher
servers these days. I'm not against setting up gopher as an option,
but not for the price to disable HTTP GET (which is all that we need
after switching to git: and ssh: for code access).

> In the current setup, users who type the domain suckless.org into their URL
> get HTTP cleartext. I think these users should get HTTPS.

Why? If I connect to suckless.org 80 with telnet and type GET /
HTTP/1.0 I want to see plain text.

> And what about old external links to the site, they are currently 100% HTTP,
> too. Without a redirect, HTTP will continue ti be used by many users
> although many would rathet use HTTPs - or don't care.

I explained this already. If I see a http link I expect an http link.
External links will migrate to HTTPS slowly.

-Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 31 August 2017 at 21:10, ilf  wrote:
> hiro:
>>
>> this is not about just whether something has TLS support, this is about
>> giving the user choices.
>
>
> If you can't speak TLS, then use gopher instead of HTTP. I hear HTTPS sucks,
> too.

Come on, isn't this a contradiction to your always redirect approach?
gopher is almost dead and doesn't provide any advantage over HTTP in
terms of MIM prevention.

I agree with hiro to let the user decide if he sticks to http or
https, but that we shouldn't mandate https.

This whole discussion is really a waste of time. Now, HTTPS is there
to satisfy some packagaer as an option to choose from. Kudos go to
Hiltjo for this. Whoever wants to stick with http, shall stick to it.

We don't want to break a running system.

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 31 August 2017 at 15:36, Hiltjo Posthuma <hil...@codemadness.org> wrote:
> On Thu, Aug 31, 2017 at 03:07:11PM +0200, Anselm R Garbe wrote:
>> well ;)), but I'm also a sceptic of HSTS.
>
> Can you explain why you are a sceptic of HSTS?

I'm sceptic of using HSTS on suckless.org. I think it is superfluous.

I really prefer that website visitors perform a *conscious* transition
to https urls of suckless.org (after learning about it in our news
feed that you wrote) rather than mandating the browser (which might
support HSTS) to perform some kind of a "magic" transition instead.
Actually the user might not notice at all if his browser supports
HSTS.

It's kind of an infantilization of the user.

Also I dislike the idea that browsers effectively share HSTS
information gathered in regular mode even in private (aka incognito)
mode (at least I read about this last time I looked into HSTS, which
is a while back).

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

On 31 August 2017 at 14:45, hiro <23h...@gmail.com> wrote:
> Now we have something much worse: letsencrypt and this completely
> insecure http redirection snake-oil.
>
> With letsencrypt you now have to put extra work (can't keep track of
> all the individual subdomains either, wildcards are suddenly a
> security risk?!), and nobody bothers to quanitfy the amount of gained
> security.

I don't really mind letsencrypt (actually I wouldn't mind to make a
deal with HonestAchmed or his cousin -- we can all trust them, because
the uncle of a friend is his step brother and knows the family very
well ;)), but I'm also a sceptic of HSTS.

Where do we really have a downgrade risk? In the content suckless
offers, this can be solved by using relative or non-protocol hrefs
everywhere. I wouldn't mind if existing external links are not
redirected, during time external references will adopt slowly.

BR,
Anselm

Re: [dev] Opinions on GNU stow

[Anselm R Garbe]

On 31 August 2017 at 09:33, hiro <23h...@gmail.com> wrote:
> The reason symlinks are still being used is that unions on linux are
> an even bigger, unstable piece of shit. The tinycorelinux people tried
> them out for their package system and had to give up and use the
> "hack" instead.

See my other mail, I wouldn't take it into the extreme, but just
define a couple of use-case specific "overlays".

Old school package managers would become part of contributing into an
overlay repo that consists of a full range of tools
sharing/contributing to a common use case.

BR,
Anselm

Re: [dev] suckless.org TLS / HTTPS support

[Anselm R Garbe]

Hi Hiltjo,

On 30 August 2017 at 23:06, Hiltjo Posthuma  wrote:
> suckless.org now supports TLS using LetsEncrypt. Cloning git repos over HTTPS
> works now. Some links on the page have been changed to allow both HTTP and
> HTTPS.
>
> HSTS is not fully working yet. This will be fixed.
>
> The IPv6  record was added and IPv6 is fully working now.
>
> suckless has many subdomains, these should hopefully all work via TLS. If you
> see a subdomain without a signed certificate please report it. If you find any
> broken links on the wiki pages, these can be fixed by anyone.

Excellent, thank you for your effort with the certificates.

BR,
Anselm

Re: [dev] Opinions on GNU stow

[Anselm R Garbe]

Hi there,

On 30 August 2017 at 01:39, fao_  wrote:
> Rather, I am asking your opinions on the general concept and
> how it has been implemented. Specifically, the idea of installing
> under a 'package' directory, and symlinking from there to the
> proper install location. But anything about the general behavior
> of it that you think especially sucky would help, also.

Generally speaking to base a packaging concept on symlinks is a very
bad idea. The GNU stow concept (regardless its actual implementation)
is duct taping symlink hacks.

Symlinks have always been a hack due to Unix' lack of a proper
namespaces approach. Plan 9 later fixed this by introducting a proper
namespaces approach[1] - but even today unices (incl. Linux) have
almost ignored the learnings of Plan 9 with some exceptions.

In a clean environment with a well defined directory structure (that
doesn't allow multiple ways of arranging files) it is a pretty easy
task to locate assets of a certain program. For instance in stali due
to static linkage there are no .so's hanging around in different
paths. Only important directories to look at are /bin and /etc
eventually.

In terms of a packaging manager, I'm a proponent of the idea I
introduced with stali as well. It does not require a package
"manager", but uses git for the rootfs overlay instead. If you want a
certain version of the system, you check out the required version from
/.git.

I'm certain that those ideas would scale up to a general purpose base
system, however if you want to deploy heavyweights like chrome or
openoffice etc. I would try to adopt union mounting overlays into some
/crap namespace of such "packaged" software, rather than using ugly
symlinks with stow.

[1] http://doc.cat-v.org/plan_9/4th_edition/papers/names

-Anselm

Re: [dev] less(1) replacement?

[Anselm R Garbe]

On 29 August 2017 at 12:10,   wrote:
> following conditions: In no way a core functionality of the user level
> application should be implemented in the "interpreted" language; In no way the
> SDK of the user application must force the availability of the "interpreted"
> language to be compiled or run; the user application should have designed a
> strong interface that would allow many "interpreted" languages (or C or asm or
> whatever) to be used and not only one: usually a simple C API or a simple
> "network protocol". I would write C.

A bit OT, but there is an exception:

http://jslinux.org/

*just kidding*

-Anselm

Re: [dev] dl.suckless.org file integrity github project

[Anselm R Garbe]

On 28 August 2017 at 19:25, hiro <23h...@gmail.com> wrote:
> wow, so much development going on in suckless these days.
> i congratulate everybody involved in the lack of any shitty code
> written. thanks. (and i am serious).

Go ahead. I'm serious as well.

-Anselm

Re: [dev] less(1) replacement?

[Anselm R Garbe]

On 27 August 2017 at 19:29, isabella parakiss  wrote:
> did you know that ksh93 supports

Nobody suggested that bourne level is equal to ksh93.

BR,
Anselm

Re: [dev] announcing edit-pipe

[Anselm R Garbe]

On 27 August 2017 at 20:16, Greg Reagle  wrote:
> On Sun, Aug 27, 2017, at 13:48, Thomas Levine wrote:
>> * mktemp is not portable; you could use something like the date and
>>   process identifier ($$) to create a portable temporary file.
>>   (I am actually still curious as to whether there is a reasonable
>>   portable approach that is less sloppy than this.)
>
> I'm not sure the best way to do that or if it's worth the extra
> complication.  It is unfortunate that POSIX doesn't have mktemp or a
> command to do the same thing.  However, mktemp seems to be very widely
> available.  It is in GNU coreutils (i.e. Gnu/Linux), OpenBSD, NetBSD,
> FreeBSD, Mac OS X, HP-UX, Tru64 Unix.

I would not bother about some exotic portability issues with mktemp.

-Anselm

Re: [dev] dl.suckless.org file integrity github project

[Anselm R Garbe]

On 27 August 2017 at 00:19, Mattias Andrée  wrote:
> The user's must be able to find the appropriate keys some way the first
> time, so suckless must at least have links to them. If suckless is
> compromised these can be replaced. PGP keys only ensure that future
> keys are not fraudulent as all new key should be signed by the old keys.
> SSL certificates ensures that the PGP keys are not tempered with by
> anyone outside suckless. Thus, hosting the keys one suckless.org, when
> it has HTTPS, is more secure that every ones private home pages outside
> suckless.org that do not have SSL certificates.

Perhaps I'm old-fashioned, but in the older days there used to be the
strategy to display your pgp fingerprint in mail signatures and lot's
of other places, to ensure that during time and a high degree of
footprint throughout the net, it would be a rather easy congnitive
task to base trust on that.

But I didn't notice this approach for a while and did stop it myself
back in 2008 or so...

BR,
Anselm

Re: [dev] dl.suckless.org file integrity github project

[Anselm R Garbe]

On 26 August 2017 at 21:08, Laslo Hunhold <d...@frign.de> wrote:
> On Fri, 25 Aug 2017 13:54:41 +0200
> Anselm R Garbe <garb...@gmail.com> wrote:
>> Either that, or perhaps we can reinstate the old fashion of
>> suckless.org/~user/ homedir.
>
> I gave it a bit more thought and realized that putting the keys all in
> one place defeats the purpose of PGP. If the server is compromised, an
> attacker would just have to additionally replace the keys in the
> homedirs besides replacing the signed release-tarballs with fraudulent
> ones that were signed with his "fraudulent" key.

There's nothing wrong to put public keys onto suckless.org, in
addition to a range of other places incl. official key servers.

It would be a very poor assumption to only base a trust model on
public keys found at the same place as some signatures.

BR,
Anselm

Re: [dev] less(1) replacement?

[Anselm R Garbe]

On 26 August 2017 at 23:59, isabella parakiss <izaber...@gmail.com> wrote:
> On 8/26/17, Anselm R Garbe <garb...@gmail.com> wrote:
>> On 26 August 2017 at 13:05, isabella parakiss <izaber...@gmail.com> wrote:
>>> i wrote a simple pager in ~100 lines
>>> https://github.com/izabera/bashutils/blob/master/pager
>>>
>>> inb4 it sucks because it's bash code
>>
>> Tbh, it looks hideous. Why on earth are you using bash?
>
> https://i.imgur.com/79U7mcO.png
> side by side screenshot against less
> your face looks hideous

That doesn't answer my question why you are using bash?

Regardless what you want to solve, bash is one of the worst options to
consider. There is no non-hideous kind of bash scripts once you start
using bashisms. If you'd stick to some kind of half decent bourne
shell level, then things might be excusable. But bash is out of any
discussion -- it's like suggesting to use Visual Basic for server
implementations.

BR,
Anselm

Re: [dev] less(1) replacement?

[Anselm R Garbe]

On 25 August 2017 at 21:37, fao_ <finnole...@inventati.org> wrote:
> On 2017-08-24 1:50 pm, Anselm R Garbe wrote:
>> 9base is not intended for interactive use, so no, p does not really
>> belong into 9base. 9base is intended to be a scripting environment.
>
> Excuse me if this is a stupid question, but: What's the difference?

In my terminology "interactive use" of 9base would assume that you'd
run rc as interactive shell in your terminal and use its userland from
command line directly. But the actual main use case of 9base is just
to be used in scripts. rc from 9base isn't particularly "convenient"
for interactive use, as long as you don't run it from inside acme,
9term or rio.

BR,
Anselm

Re: [dev] less(1) replacement?

[Anselm R Garbe]

On 26 August 2017 at 13:05, isabella parakiss  wrote:
> i wrote a simple pager in ~100 lines
> https://github.com/izabera/bashutils/blob/master/pager
>
> inb4 it sucks because it's bash code

Tbh, it looks hideous. Why on earth are you using bash?

-Anselm

Re: [dev] [9base] [musl] "Undefined reference to sigsetjmp"

[Anselm R Garbe]

On 25 August 2017 at 22:17, fao_  wrote:
> When compiling 9base with
>
>>  CC=musl-gcc
>>  PREFIX=""
>>  OBJTYPE=x86_64
>
>
> I get the error:
>
>>  ../lib9/lib9.a(notify.o): In function `signotify`:
>>  notify.c:(.text+0x9a): undefined reference to `sigsetjmp`
>>  collect2: error: ld returned 1 exit status
>
>
> Except:
> $ grep -Rni "sigsetjmp" /usr/lib/musl/
>>
>>  /usr/lib/musl/include/setjmp.h:22:int sigsetjmp (sigjmp_buf, int);
>>  ...
>
>
> On the offchance that `setjmp.h` was not included in `notify.c`, I
> added it manually. It still failed with the same error.

Nice spot, according to this[0] musl discourages legacy setjmp
behaviour. Hence I guess it will need a bit of fiddling in 9base to
make it p9setjmp-free.

I will check this during next week.

[0] http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc

BR,
Anselm

Re: [dev] dl.suckless.org file integrity github project

[Anselm R Garbe]

On 25 August 2017 at 12:56, Laslo Hunhold <d...@frign.de> wrote:
> On Fri, 25 Aug 2017 08:12:12 +0200
> Anselm R Garbe <garb...@gmail.com> wrote:
>> - (optional) repo owners/maintainers should sign their future git tags
>> for release creation by using their own private PGP key.
>
> the public PGP-keys could be put on the
> http://suckless.org/people/*-pages.

Either that, or perhaps we can reinstate the old fashion of
suckless.org/~user/ homedir.

BR,
Anselm

Re: [dev] dl.suckless.org file integrity github project

[Anselm R Garbe]

Hi there,

let me summarise what we will carry out during the upcoming hackathon
besides a load of other stuff:

- (mandatory) introduction of HTTPS besides http support
- (mandatory) sorting the maintainership/ownership of suckless repos
(incl. the right to commit/accept/deny patch contributions)
- (mandatory) on release creation making sure that sha256 hashsums are
present for tarball verification on dl.suckless.org
- (optional) repo owners/maintainers should sign their future git tags
for release creation by using their own private PGP key.

BR,
Anselm

Re: [dev] less(1) replacement?

[Anselm R Garbe]

On 24 August 2017 at 13:33, Greg Reagle <greg.rea...@umbc.edu> wrote:
> On Thu, Aug 24, 2017, at 05:01, Anselm R Garbe wrote:
>> On 24 August 2017 at 01:59, fao_ <finnole...@inventati.org> wrote:
>> > Is the suckless project packing a replacement to my favorite pager,
>> > less(1)? Or is the advice to just use something like screen or tmux. I
>> > don't really want to bother installing and learning those when `less` meets
>> > my needs perfectly.
>> >
>> > As far as I can tell, there isn't. But I could have missed something, given
>> > how many unrelated results `suckless "less"` pulls up :)
>>
>> https://github.com/9fans/plan9port/blob/master/src/cmd/p.c
>
> That p command does not seem to be in 9base.  Do the 9base developers
> think that it should be?

9base is not intended for interactive use, so no, p does not really
belong into 9base. 9base is intended to be a scripting environment.

BR,
Anselm

Re: [dev] less(1) replacement?

[Anselm R Garbe]

On 24 August 2017 at 01:59, fao_  wrote:
> Is the suckless project packing a replacement to my favorite pager,
> less(1)? Or is the advice to just use something like screen or tmux. I
> don't really want to bother installing and learning those when `less` meets
> my needs perfectly.
>
> As far as I can tell, there isn't. But I could have missed something, given
> how many unrelated results `suckless "less"` pulls up :)

https://github.com/9fans/plan9port/blob/master/src/cmd/p.c

BR,
Anselm

Re: [dev] dl.suckless.org file integrity github project

[Anselm R Garbe]

On 24 August 2017 at 00:45, hiro <23h...@gmail.com> wrote:
> Any responsible suckless person should not download Aaron's software.
> I cannot guarantee it's not ransomware!
> But I also made a github and my checksums and signatures are certified
> by the German cybersecurity department of the TüV. My githab is called
> honestachmet. Please add me to your linkedin.

Actually the plan is to use HonestAchmed as our trusted CA for the
upcoming TLS introduction on suckless.org ;)

BR,
Anselm

Re: [dev] Moving scc

[Anselm R Garbe]

Hi Roberto,

On 9 August 2017 at 21:12, Roberto E. Vargas  wrote:
> A lot of different things happened since that moment, some of
> them in my life, and some of them in the suckless community.
> Due to these changes, I don't feel scc as a suckless project
> anymore, and as project founder, main contributor (I think
> I wrote about 95% of the code) and maintainer, I have taken
> the decision of moving scc away from suckless.

No objection.

I know that suckless.org was able to provide your project some kind of
infrastructure, however in terms of visibility and traction you didn't
display scc very prominently on suckless.org yet, hence I guess most
of suckless software users didn't really notice that scc existed at
all. So moving it to some other umbrella organisation is no problem
for us, also because it is defacto your sole project.

> After this mail, the new official community where scc is going
> to be developed is bitreich [1], and you can find the new
> repository in [2].

We will move scc to oldgit.suckless.org in its current state present
at suckless org and mentioned its new URL.

> [1] gopher://bitreich.org
> [2] gopher://bitreich.org/1/scm/scc/log.gph

Btw. bare in mind, that putting scc behind gopher won't increase its
visibility or traction by any means imho, rather the opposite. I
understand the motivation by adopting gopher, but nevertheless I
highly encourage you guys (incl. 20h) to also(!) provide your content
via http(s). You are locking yourselve up in some parallel universe,
if most people will end up using gopher web frontends to browse your
content ;)

It feels a bit odd and highly sectarian, if one _only_ relies on gopher.

Best regards,
Anselm

Re: [dev][dwm]size of dwm root window and framebuffer

[Anselm R Garbe]

Hi Kajetan,

On 8 August 2017 at 12:49, Kajetan Jasztal  wrote:
> my laptop's screen broke lately and I've got about 168px column
> on left unusable, this xrandr command seems to work, ie it crops
> screen to working area
>
> xrandr --fb 1432x900 --output eDP1 --auto --transform 1,0,-168,0,1,0,0,0,1
>
> but dwm renders on full width of screen (1600x900), so root and
> other windows sticks outside of screen even though xserver don't
> allow mouse pointer to escape past right edge of screen.
>
> shouldn't dwm be rendered to size of framebuffer or am I using
> xrandr the wrong way?

Interesting observation. It's quite likely that dwm always assumes
sx=0 sy=0, which could be the reason, but I can only check on Thu.

BR,
Anselm
>

Re: [dev] [dwm] Opening some URLs in a web browser crashes dwm

[Anselm R Garbe]

Hi Milan,

On 6 August 2017 at 16:38, Milán Csaba Kecskés  wrote:
> I've experienced the bug mentioned in the title. No matter which
> browsper - tried with Chromium 60, Firefox 54, Midori, Epiphany,
> QupZilla, even Dillo, but all of the browsers crash dwm when opening
> these links in them (disabling javascript does not help):
>
> https://www.reddit.com/r/firstworldanarchists/comments/6rvdn9/nice_grain/
> https://twitter.com/hurlarious/status/889213344749559808/photo/1

I cannot reproduce your crash, opening those url's in my setup
(suckbuntu) works fine. I'm using current head and tried to match your
browser versions without any real problem.

Only difference to vanilla config.h is my font configuration:

static const char *fonts[]  = { "Inconsolata:size=16" };
static const char dmenufont[]   = "Inconsolata:size=16";

Can you please provide the exact git hash and the font configuration
of config.h as well?

> I use Arch Linux. Only dwm is affected, the links open with no problem
> under i3. I've tried with the dwm package from the Arch repo (which
> was built using the unmodified config.h I guess), cloning the git repo
> and compiling myself with the vanilla config, but nothing changes: the
> result is a crash when opening these links.

Well, does the i3 font setup matches your config.h font setting of
dwm? Or are they different?

Thanks,
Anselm

Re: [dev] [9base] sbrk vs malloc

[Anselm R Garbe]

Hi Rendov,

On 5 August 2017 at 04:28, Rendov Norra  wrote:
> I've compiled 9base against musl, and dd spits errors about memory at
> me if I try to invoke it. I looked at the source and determined sbrk
> wasn't doing what it was supposed to. I don't know if this is to do
> with my version of musl, or just musl in general, but I replaced sbrk
> with malloc and it seems to work fine after recompilation.
>
> Is there any reason sbrk shouldn't be changed?

No, I have removed the remaining sbrk() uses.

Thanks,
Anselm

Re: [dev] [sic] password for nick

[Anselm R Garbe]

On 2 August 2017 at 15:28, Malte Kiefer  wrote:
> Ok I fix it.
> It was a Server Error.
> Then I try freenode it works.
> But when I want to enter my Password here:
>
> /msg NickServ identify PASSWORD

RTFM (sic.1), sic uses :m as shorthand for the IRC PRIVMSG command.

Laslo did point already out what you need to enter into the sic prompt

  :m chanserv identify 

BR,
Anselm

Re: [dev] [st, dmenu] Crash when attempting to display characters with missing glyphs

[Anselm R Garbe]

Hi,

On 28 July 2017 at 07:44, B. Wilson  wrote:
> I use mutt and happened to receive an email that caused st to crash. It 
> turned out that the email contained a unicode emoji character for which I 
> didn't have a suitable font.
>
> The character in question was U+1F917. I was able to reproduce the crash in 
> st by cat-ing a file containing the single bad character. Pasting it from the 
> X clipboard also reliably causes the crash.
>
> This is the error that is produced:
>
> X Error of failed request:  BadLength (poly request too large or internal 
> Xlib length error)
> Major opcode of failed request:  139 (RENDER)
> Minor opcode of failed request:  20 (RenderAddGlyphs)
> Serial number of failed request:  1442
> Current serial number in output stream:  1454
>
> I'm guessing that somewhere a 'missing glyph' error isn't getting checked, 
> but I wasn't able to find the relevant code from a quick perusal.
>
> Anyway, the same issue seems to exist in dmenu. As a sanity check, I checked 
> against the following:
>
> 1) different X terminal, i.e. xterm,
> 2) different character with missing glyph, i.e. U+1F642, and
> 3) installing a font with the appropriate glyphs, i.e. Symbola.
>
> As far as I can tell, the crash reliably occurs in st when attempting to 
> display a character that has no associated glyph. As a workaround, I was able 
> to install the Symbola font which
> apparently contains several unicode emoji.

1. Did you use st and/or dmenu from git?
2. Are you able to provide a stacktrace from the coredump?

Thanks,
Anselm

Re: [dev] [ANN] samurai: ninja-compatible build tool

[Anselm R Garbe]

On 26 July 2017 at 18:32, Michael Forney <mfor...@mforney.org> wrote:
> On 7/26/17, Anselm R Garbe <garb...@gmail.com> wrote:
>> Out of curiosity, what is the point of a build system like ninja, if
>> the codebase requires to be complex?
>
[..]
> In oasis I'm using ninja like you're use stali.mk in stali. The
> advantage is that dependencies are tracked throughout all packages
> (not only within a package and between packages), so I can edit a file
> in some library (libcurl for instance), and git, mupdf, and netsurf
> all get rebuilt automatically. The disadvantage of course is it's not
> a standard UNIX tool.

Many thanks for sharing this clarification and comparison.

>> Isn't the issue to be tackled the
>> codebase complexity then?
>
> Yes ideally projects like llvm and chromium would instead focus on
> codebase complexity. But the argument that ninja is bad because bad
> projects use it does not make sense to me.

I didn't suggest that implication. It seems that ninja offers some
advantages for a price, that I cannot estimate yet.

Best regards,
Anselm

Re: [dev] lightweight build system

[Anselm R Garbe]

On 26 July 2017 at 03:28, ochern  wrote:
> That's right. No new build system is suggested.
>
> Let me suggest a small poll:
> 1 What build systems do you consider as most suckless?

Plain mkfiles + rc or plain Makefile's + sh and sbase-compliant command usage.

> 2 Generating Makefile from a shell script: it sucks, it's acceptable
> or it's rather suckless?

It sucks. There is no need to generate Makefiles. I prefer the
suckless approach of config.mk's for adjusting include/lib lookups on
excotic platforms, whilst using defaults that work on almost every
platform. I'm also a strong opponent of using pkg-config crap. I hate
it and I prefer to delete it whenever I see it.

Also in terms of code, it appears to be incompetency among several
developers that require platform specific defines on Linux/BSDs --
they are barely necessary. Windows etc. is out of scope for this
community.

Generating Makefiles obscures the simple cognitive task of adjusting a
correct path by some weird shell script logic that one needs to
understand as well. It is the whole argument against GNU autohell,
that generating build files is insane. You need to learn and
understand 2-3 languages (shell, m4, weird GNU make, log output) to
track down issues with it, whereas you only need to learn and
understand make in a decent world.

The same argument also applies to the discussion config.h vs config
file parser. Why should I learn a config file language, if I can
achieve the same with the programming language? I get the parser of C
already in the compiler and does not need to reinvent a language
parser for "options".

Also options suck. They are a sign of indecisiveness or weakness in
finding proper defaults or making firm UI decisions.
I want tools that work out of the box without bothering about
"configuration". We can waste a lot of time with "configuring" to
death.

All this is rather obvious to me.

BR,
Anselm

Re: [dev] Some suckless hackathon 2017 preparation

[Anselm R Garbe]

On 25 July 2017 at 11:59, Laslo Hunhold  wrote:
> On Mon, 24 Jul 2017 22:13:36 -0500
> Joshua Haase  wrote:
>> I do think a good issue tracker is needed and would be willing to
>> contribute on september 2-3 (although maybe in a different time zone:
>> [UTC-6]).
>>
>> As for useless bug reports, a good cure would be to give access only
>> to people who can make a pair of ssh keys and sign with gpg their bug
>> reports.
>
> I honestly agree with Hiltjo here. Issue trackers lead to the
> developers becoming code monkeys, being flooded with
> invalid/useless/insane bug reports.
[..]
> I would go as far to say that issue trackers are harmful, only exciting
> for those who don't work themselves, i.e. for those who like to
> delegate work. The parallel to how most companies are run nowadays,

IMHO this view is short sighted. The point of an _issue_ tracker (not
every issue is a bug) is not the possibility to flood the developer
with random bug reports, but to provide a simple infrastructure to
organize and priotize a TODO list for the development of a certain
project -- AND also to document the development, why some decision was
made at some point in time. The idea for a suckless issue tracker is
to make it mailing-list based, so that one can work with it with plain
mails. It thus also allows discussions and patches.

Of course issue trackers can become a management monitoring tool as
well, but that's not the primary use of it. The primary use is that
developers can organize and serialize the various inputs like ideas,
requests, bugs in a proper and transparent way to create a roadmap for
themselves. There are times, especially outside the maturity phase of
software, where the inflow of ideas and bugs will outnumber the
ability of a developer to tackle it down immediately. At that stage
having a suckless issue tracker would be really handy.

> where managers with their corporate newspeak make decisions on things
> they don't understand (see Scrum for instance), is striking. Requiring
> a minimal amount of technical understanding is not too much to ask.

All those corporate processes are not the result of introducing issue
tracker tools. I agree with your critic particularly about Scrum,
which is a hideous software development methodology. But in general
those corporate issues are not rooted by the introduction of a
suckless issue tracker, simply because there is no suckless issue
tracker yet. All issue trackers I came across are heavily
over-engineered or developed by people that are incompetent to use
email.

Best regards,
Anselm

Re: [dev] [ANN] samurai: ninja-compatible build tool

[Anselm R Garbe]

On 26 July 2017 at 09:05, Silvan Jegen  wrote:
> On Wed, Jul 26, 2017 at 8:57 AM, Michael Forney  wrote:
>> On 7/25/17, Silvan Jegen  wrote:
>>> On Wed, Jul 26, 2017 at 7:32 AM, Michael Forney 
 Even if you don't care for ninja, it does seem to be gaining
 popularity, and I've noticed several projects start switching from
 autotools to meson (which outputs ninja), so I thought it would be
 good to have a small C implementation. It was also a fun project.
>>>
>>> I have seen that some of the Wayland projects I care about are working
>>> on switching to meson but I did not know that it uses ninja under the
>>> hood.
>>>
>>> Since you seem to have plenty of experience with ninja, do you think
>>> it has any advantages over using a Makefile containing 20-50 lines of
>>> code?
>>
>> No, not at all. Definitely use a Makefile for that case.
>
> That's what I suspected. Not sure it's desirable to ever work on a
> codebase big enough to require a build system which uses ninja under
> the hood. If I find myself in such a position I will turn to samurai
> first.

Out of curiosity, what is the point of a build system like ninja, if
the codebase requires to be complex? Isn't the issue to be tackled the
codebase complexity then?

-Anselm

Re: [dev] Some suckless hackathon 2017 preparation

[Anselm R Garbe]

Hi there,

thanks for your suggestion to prepare the content we could work on
during slackathon 2017.

Let me chime in with some thoughts:

First of all -- for all of you who can't attend slackathon in person,
but still would like to support the outcome somehow, I encourage you
to adjust your schedule to spent some time online on Sep 2-3 during
the event, so with your support the output could even be bigger,

Second, one goal of the slackathon is also to streamline the project
landscape of suckless.org, which also means we should presumably
define 3-4 clusters that will be addressed during the event and
identify all areas that are well established and don't need much care
during the slackathon. In particular I would see the following
clusters:

i) improvements to suckless.org and our general project setup (switch
to quark, stagit, static swerc, git://, streamline all projects, drop
drop-candidates, etc)
ii) improvements to the system tool landscape with a focus on probably
the static-izing ld wrapper (stali, 9base, sbase, ubase)
iii) focus on totally new stuff like the issue tracking, Silvans
patchwork idea or mail archiver
iv) looking into wayland adoption or similar of our UI focused tools
as a rapid prototype

With this in mind I would mill through your list as follows:

On 23 July 2017 at 14:39, Silvan Jegen  wrote:

Out-of-scope ideas:

> * Suckless font rendering library
> * Improve sltar
> * Write cookie handler for surf
> * Gopher services
> * A sane backend for surf
> * A VGA/DVI/Displayport-to-TTY cable

In-scope ideas:

> * Write ld wrapper or replacement for static linking
> * Write a decent bug and issue tracking system
> * Write a decent mailing list Web archive system

Out-of-scope projects:

> * blind
> * dwm
> * st
> * surf
> * dmenu
> * farbfeld
> * ii
> * sent
> * slock
> * tabbed
> * lsw
> * sprop
> * sselp
> * swarp
> * wmname
> * xssstate
> * libzahl
> * svkbd
> * vis?
> * svc
> * morpheus init scripts
> * oasis? [0]

In-scope projects

> * 9base
> * nldev
> * sbase
> * sdhcp
> * sinit
> * smdev
> * stali
> * ubase
> * quark
> * swerc

Potential drop candidates:

> * sandy

Personally I tend towards the clusters i) (50%) and iv) (40%) to spend
time on, and perhaps providing some guidance on the ld-wrapper idea
(10%).

Best regards,
Anselm

Re: [dev] lightweight build system

[Anselm R Garbe]

Hi Alex,

On 23 July 2017 at 09:47, ochern  wrote:
> I'm new here and I want to ask if somebody is interested in discussing
> a development of lightweight build system based on simple Shell and
> Make. It would be great to hear the opinions from the community and
> may be there would rise a common welth and opportunity to develop
> suckless build system :)

Imho an almost suckless build system already exists: mk[0]+9base.

"Almost" derives from the fact, that 9base or p9p in conjunction with
the popular rc shell is kind of an alien citizen in a regular
Linux/BSD environment, and thus probably not the easiest choice for
gaining straight adoption. Nevertheless, if you dig deeper into all
the problems of GNU vs BSD vs Shitwaris etc. userlands, you will
notice that it becomes a hard task to find a suitable subset in
Makefiles + shell commands that will work almost painfree on most
platforms. sbase+ubase doesn't ease the solution, as they don't nicely
co-exist with GNU or BSD userlands.

In such situations, relying on mk+9base is an excellent choice, as the
limitations of mk, rc and its native userland are well understood --
and still mk+9base are a lot(!) smaller in code size than bash for
instance.

For stali development I considered switching to mk, but concluded it
isn't worth the effort as stali can only be built in a Linux
environment anyways.

To conclude, mk and our just-Makefile based build systems aren't
perfect, but they are extremely suckless in comparison to generated
GNUmakefiles and GNU authell.

Instead on focussing on yet another build system, I would rather
suggest to focus on a better mail archiver or to work on a nice
bugtracker, that fits well into the mlmmj world of things.

[0] http://doc.cat-v.org/bell_labs/mk/mk.pdf

Best regards,
Anselm

Re: [dev] [proposal] suckless-nettools

[Anselm R Garbe]

Hi Daniel,

On 6 July 2017 at 18:21, Daniel Hammond  wrote:
> https://github.com/rdhammond/suckless-nettools

I guess many people have created similar things, perhaps less generic
ones. Since suspend/resume works pretty well in Linux I didn't come
across the need to hack helper scripts, but just to put the wifi setup
into wpa_supplicant.conf and executing those commands from commandline
(incl. sdhcp).

But it might be useful for people who switch between many networks
frequently or who need to setup things every day.

Did you consider rc? I'm more and more inclined (again) to go back to
9 rc etc. after all.

BR,
Anselm

Re: [dev] [question] gobo linux filesystem hierarchy

[Anselm R Garbe]

On 5 July 2017 at 11:37, Kamil Cholewiński  wrote:
> Package managers, or self-contained apps, they solve all of these
> problems once and for everyone. 'make whatever' has to solve each corner
> case again and again. Or in other words, executable code makes for a
> very poor metadata format.

It depends how well a program maintains stable locations in a clean fs
layout during its lifetime and maintenance period -- and how well it
follows a proper installation paradigm like executables go to /bin,
runtime data goes to /var/spool/, config stuff to /etc,
manual pages to /man. Programs that don't, should end up in /suck
instead.

Also the base system should maintain a proper file list -- in stali
this is solved by using git.

BR,
Anselm

Re: [dev] [question] gobo linux filesystem hierarchy

[Anselm R Garbe]

Hi Kajetan,

On 4 July 2017 at 14:23, Kajetan Jasztal  wrote:
> What do you think can be the downsides of filesystem hierarchy of
> Gobo Linux[0]? STALI[1] was attempting to modify default hierarchy
> after all. I personaly think it's clear, evident (only problem I have
> is hiding symlinks in /) and elegant. It's in a way compatible with
> Unixes by symlinking. I guess it's not that good after all, but
> I can't see what can be the problem here.

The main difference between gobo and stali is, that gobo introduced a
rather complex solution to a non-issue, whereas the stali fs layout is
a simple solution to an actual issue.

The installation of program assets into common directories (shared
with other programs) is not an issue at all. Gobos solution is very
similar to the misguided approach found in macOS (and probably its
ancestor NeXT) with the Crap.app containers. After all, a total
non-issue in a world, where either proper package management or
Makefile uninstall targets would allow to remove the assets of a
particular program or package. Apart from this, the Gobo approach goes
into a pretty retarded direction with the introduction of
Index-directories for executables and libraries crowded by a softlink
mess.

In contrast a real issue with the Linux FHS is, that it offers far too
many options for common directories, by allowing /bin /sbin /usr/bin
/usr/sbin /usr/local/bin /opt/bin etc. to name just a few typical
ones. The FHS is totally over-engineered and hence a real issue.
Deciding which prefix to use for a program or looking up some config
file with so many options to pick from sucks. Hence stali solved this
mess by declaring a hand full of softlinks to force the established
FHS thinking into a very simplified layout, where you can easily
determine where executables are to be found or where runtime stuff
will be placed.

I hope this shed some light into the motives of stali's rather unusual
fs layout.

BR,
Anselm

Re: Suckless monitoring [was Re: [dev] git://git.suckless.org not accepting connections]

[Anselm R Garbe]

Hi Kamil,

On 4 July 2017 at 14:32, Kamil Cholewiński <harry6...@gmail.com> wrote:
> On Tue, 04 Jul 2017, Anselm R Garbe <garb...@gmail.com> wrote:
>> I've used my own for almost a decade: http://monitor.garbe.us/
>> It checkes the services every 20 minutes and sends me a mail if some
>> service goes offline.
>
> Care to share the code?

Nothing fancy, though:

http://git.suckless.org/monitor/tree/monitor.rc

-Anselm

Re: Suckless monitoring [was Re: [dev] git://git.suckless.org not accepting connections]

[Anselm R Garbe]

Hi,

On 4 July 2017 at 11:31, Kamil Cholewiński <harry6...@gmail.com> wrote:
> On Tue, 04 Jul 2017, Anselm R Garbe <garb...@gmail.com> wrote:
>> On 4 July 2017 at 00:36, Anselm R Garbe <garb...@gmail.com> wrote:
>>> On 4 July 2017 at 00:06, Michael Forney <mfor...@mforney.org> wrote:
>>>> I noticed that git.suckless.org is no longer accepting connections
>>>> with the git protocol. HTTP still works though.
>>>>
>>>> Just pointing that out in case it wasn't a deliberate change.
>>>
>>> Nice spot, wasn't deliberate and is caused by the server relocation.
>>> I'll look into this.
>>
>> Should be fixed now.
>>
>> BR,
>> Anselm
>
> What would be the least-sucking monitoring+alerting solution for
> infrastructure? Nagios, Icinga, Sensu, all of these suck horribly.
>

I've used my own for almost a decade: http://monitor.garbe.us/
It checkes the services every 20 minutes and sends me a mail if some
service goes offline.

BR,
Anselm

Re: [dev] git://git.suckless.org not accepting connections

[Anselm R Garbe]

On 4 July 2017 at 00:36, Anselm R Garbe <garb...@gmail.com> wrote:
> On 4 July 2017 at 00:06, Michael Forney <mfor...@mforney.org> wrote:
>> I noticed that git.suckless.org is no longer accepting connections
>> with the git protocol. HTTP still works though.
>>
>> Just pointing that out in case it wasn't a deliberate change.
>
> Nice spot, wasn't deliberate and is caused by the server relocation.
> I'll look into this.

Should be fixed now.

BR,
Anselm

Re: [dev] git://git.suckless.org not accepting connections

[Anselm R Garbe]

Hi Michael,

On 4 July 2017 at 00:06, Michael Forney  wrote:
> I noticed that git.suckless.org is no longer accepting connections
> with the git protocol. HTTP still works though.
>
> Just pointing that out in case it wasn't a deliberate change.

Nice spot, wasn't deliberate and is caused by the server relocation.
I'll look into this.

BR,
Anselm

[dev] Re: [slcon4] hackathon

[Anselm R Garbe]

Hi fellow hackers,

friendly reminder that we are approaching the deadline for slcon4
hackathon registration.

Anyone who hasn't registered yet should be quick to do so until

 ***15 June 2017***

Thanks,
Anselm

On 13 May 2017 at 21:38, Anselm R Garbe <garb...@gmail.com> wrote:
> Dear fellow hackers,
>
> We are glad to announce the slcon4 hackathon[0] event on 2-3 Sep 2017
> in Würzburg, Germany.
>
> In contrast to previous years we won't conduct regular talk sessions
> this year and hence are not(!) calling for talk proposals.
>
> Instead we want to be able to spend as much time as possible on
> hacking during the event.
> The nature of the event will be more like a hacker camp than a tech
> conference this year.
>
> In order to arrange for a suitable location we kindly ask all of you,
> who firmly want to attend, to send us a mail to
>
>   cha...@suckless.org
>
> until ***15 June 2017***.
>
> Please also let us know your preference if you want to share the
> accommodation with the other attendees (we expect this option will be
> cheaper than last year) or if you prefer to arrange for bed and
> breakfast on your own. We will communicate the final location around
> mid of July.
>
> We also recommend to arrange your travel already, if you plan to
> attend. The arrival should be scheduled for Sep 1st and the departure
> for 3rd or 4th Sep.
> The closest international airports are Frankfurt/Main, Germany or
> Nuremberg, Germany. Würzburg is a 90 minute train trip from Frankfurt
> airport.
>
> **Members of the suckless.org e.V. are invited to attend our annual
> Mitgliederversammlung (general assembly) on 1st Sep 2017 night in
> Würzburg (exact location will be communicated around early August, we
> intend to meet in some Hinterzimmer of a nice Bavarian Wirtshaus).
>
> [0] http://suckless.org/conferences/2017
>
> Best regards,
> Anselm

Re: [dev] [dwm] My patch

[Anselm R Garbe]

Hi Kristaps,

On 3 June 2017 at 18:49, Kristaps Civkulis  wrote:
> Recently I sent a patch http://lists.suckless.org/hackers/1706/15108.html
> and didn't get any response. Is there something wrong with my patch or
> patch/email format?

Others have pointed this out already -- barely anyone can be bothered
about accepting it for mainline.
Feel free to push it to the patches section.

BR,
Anselm

Re: [dev] [dwm] twin-head displays as single tags / workspaces

[Anselm R Garbe]

Hi Kuba,

On 19 May 2017 at 17:31, Kuba  wrote:
> Would it be possible to have to have a setup with 2 monitors where
> both are managed as a single tag?
> That would create "dual head workspaces" - I work on many projects at
> the same time and each project needs many windows - perfect for dual
> head setup. Currently to switch between projects I need to adjust tags
> on each of the monitors. If what I propose would be possible then a
> tag switch would be switching both monitors.

Do both of your screens have the same size/resolution? If yes, the the
simplest method would be building dwm without XINERAMA support and
treating the dual head setup as "single head". Perhaps with patching
updatebars() to only adjust the barwidth to sw/2, so that it doesn't
stretch with a gap in the middle.

> In fact something like "linking tags" would be sufficient - you switch
> a tag on any screen and that switches to a "friendly tag" (or tag with
> the same name) on the other screen.

If you keep multihead setup, you could amend view() in a way to
iterate over all monitors instead of selmon -- literally applying the
view() command to all monitors. Something like:

 void
 view(const Arg *arg)
 {
+   Monitor *m;
+
if ((arg->ui & TAGMASK) == selmon->tagset[selmon->seltags])
return;
-   selmon->seltags ^= 1; /* toggle sel tagset */
-   if (arg->ui & TAGMASK)
-   selmon->tagset[selmon->seltags] = arg->ui & TAGMASK;
-   focus(NULL);
-   arrange(selmon);
+   for(m = mons; m; m = m->next) {
+   m->seltags ^= 1; /* toggle sel tagset */
+   if (arg->ui & TAGMASK)
+   m->tagset[m->seltags] = arg->ui & TAGMASK;
+   if(m == selmon)
+   focus(NULL);
+   arrange(m);
+   }
 }

Though, I would recommend the singleheaded approach. Personally I've
been sticking to single head for the past 4 years and quite happy with
it. I don't really see the point in multihead setups anymore -- if you
need a large screen, you know where to get it. The only reason I
need/use multihead support is when giving presentations.

BR,
Anselm

[dev] [slcon4] hackathon

[Anselm R Garbe]

Dear fellow hackers,

We are glad to announce the slcon4 hackathon[0] event on 2-3 Sep 2017
in Würzburg, Germany.

In contrast to previous years we won't conduct regular talk sessions
this year and hence are not(!) calling for talk proposals.

Instead we want to be able to spend as much time as possible on
hacking during the event.
The nature of the event will be more like a hacker camp than a tech
conference this year.

In order to arrange for a suitable location we kindly ask all of you,
who firmly want to attend, to send us a mail to

  cha...@suckless.org

until ***15 June 2017***.

Please also let us know your preference if you want to share the
accommodation with the other attendees (we expect this option will be
cheaper than last year) or if you prefer to arrange for bed and
breakfast on your own. We will communicate the final location around
mid of July.

We also recommend to arrange your travel already, if you plan to
attend. The arrival should be scheduled for Sep 1st and the departure
for 3rd or 4th Sep.
The closest international airports are Frankfurt/Main, Germany or
Nuremberg, Germany. Würzburg is a 90 minute train trip from Frankfurt
airport.

**Members of the suckless.org e.V. are invited to attend our annual
Mitgliederversammlung (general assembly) on 1st Sep 2017 night in
Würzburg (exact location will be communicated around early August, we
intend to meet in some Hinterzimmer of a nice Bavarian Wirtshaus).

[0] http://suckless.org/conferences/2017

Best regards,
Anselm

Re: [dev] Is git daemon at git.suckless.org down?

[Anselm R Garbe]

Hi Silvan,

On 25 April 2017 at 19:08, Silvan Jegen  wrote:
> The git daemon at git.suckless.org seems to be down for me.
>
> st$ git pull
> fatal: unable to connect to git.suckless.org:
> git.suckless.org[0: 78.47.162.114]: errno=Connection refused

This happened from time to time and things should be solved now.

Cheers,
Anselm

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

[Anselm R Garbe]

On 27 March 2017 at 23:52, Alexander Krotov <ilab...@gmail.com> wrote:
> On Mon, Mar 27, 2017 at 10:00:43PM +0200, Anselm R Garbe wrote:
>> nevertheless I do think that all this still doesn't justify a
>> scrollback buffer built into st itself. Instead of mandating the use
>> of tmux et al, I would rather put a helper tool into the st repo, that
>> works as a basic shell wrapper process (no detaching). It would
>> implement the scrollback buffer only and allow to define its size in a
>> more flexible way (possibly via a command line argument) and also the
>> control sequences / key combos to actually scroll around. The tool
>> name could be stsb or something similar.
>>
>> What do you think about this compromise?
>
> As Laslo Hunhold suggests down the thread, this solution is likely to be
> more complex.
>
> To implement it properly, you have to implement a whole VT inside
> of stsb, because it has to pass mouse events down and keep track
> of character attributes.  ncurses programs will output all kinds
> of "move cursor here" and "change color" control sequences, but you
> can't just pass them again to st when you need to scroll around.  You

I wouldn't implement a whole VT inside it, just filter all curses crap
out and only cache filtered regular unformatted stream output for
scrolling. There is no point to scroll back in curses mode anyways.

> In the end, you will have a stripped down dvtm, with vt but without
> multiplexing.

I would raise the bar and claim, it should be doable in less than 300 lines.

> After that, I can proceed with implementation of scrollback based
> on ring buffer.  If it makes code simpler (by removing line shuffling,
> allocation and deallocation in tresize), it may be integrated into
> st.  If not, it will be just another patch.

I'm not totally against putting scrollback into st, for the same
reason as putting a status bar into dwm. It could turn out to be the
simpler solution after all. But I'm not convinced yet. One has to try
very hard, before making compromises ;)

-Anselm

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

[Anselm R Garbe]

Hi there,

On 27 March 2017 at 12:11, Laslo Hunhold  wrote:
> On Sun, 26 Mar 2017 20:06:57 +
> Cág  wrote:
>> I am genuinely interested why.
> in my opinion, it's an unnecessary component given I use terminals
> within dwm 99% of the time. I don't need a terminal multiplexer when
> dwm multiplexes my terminals for me. I know it's "nice to have" to be
> able to attach to tmux sessions, even over ssh and such. But to be
> honest, for my use case (!), I just don't need it. For the rare case I
> need more than one terminal open, even over ssh, I just open another
> terminal and fire up ssh a second time in the latter case.
[..]
> If we discuss scrollback support in st, we should look at it from
> another perspective. In the end, st is a window which can be resized,
> and also the font size can be changed. By the mere definition of that,
> one should expect the program to behave "isomorphically" under these
> conditions. Every operation of this nature should be reversible.
> To be honest, currently it's close to stressful to use st without any
> terminal multiplexer, because you constantly have to watch out _not_ to
> resize the master when a certain terminal with important information is
> present. I am sure everyone knows what I'm talking about, and this is

nevertheless I do think that all this still doesn't justify a
scrollback buffer built into st itself. Instead of mandating the use
of tmux et al, I would rather put a helper tool into the st repo, that
works as a basic shell wrapper process (no detaching). It would
implement the scrollback buffer only and allow to define its size in a
more flexible way (possibly via a command line argument) and also the
control sequences / key combos to actually scroll around. The tool
name could be stsb or something similar.

What do you think about this compromise?

-Anselm

Re: [dev] Can't push to sta.li wiki

[Anselm R Garbe]

Hi Alex,

please try again.

Thanks,
Anselm

On 26 February 2017 at 16:02, Alexander Krotov  wrote:
> Got connection refused over git protocol:
>
> $ git clone git://git.sta.li/sites
> Cloning into 'sites'...
> fatal: unable to connect to git.sta.li:
> git.sta.li[0: 136.243.92.79]: errno=Connection refused
>
> Can't push over http:
>
> $ git push
> Counting objects: 4, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (4/4), 420 bytes | 0 bytes/s, done.
> Total 4 (delta 2), reused 0 (delta 0)
> remote: error: insufficient permission for adding an object to repository 
> database objects
> remote: fatal: failed to write object
> error: unpack failed: unpack-objects abnormal exit
> To http://git.sta.li/sites
>  ! [remote rejected] master -> master (unpacker error)
> error: failed to push some refs to 'http://git.sta.li/sites'
>
> Patch that I tried to push is attached.

Re: [dev] Collecting sins of Apple

[Anselm R Garbe]

On 26 October 2016 at 02:05,  <a...@alexpilon.ca> wrote:
> On Tue, Oct 25, 2016 at 12:53:36PM +0200, Anselm R Garbe wrote:
>> To bring it to one sentence, Apple is about providing their stuff as
>> incompatible as possible with all non-Apple stuff. […] proceeds with
>> the keyboard layout,
>
> Unh, other than swapping Mod1 and Mod4, they've usually been the most
> consistent layout and non-minuscule keys unlike just about every other
> laptop manufacturer out there selling *consumer* grade keyboards. And is
> there even really any agreement on what a laptop keyboard layout should
> be?

Apple has swapped a couple of more things in the default qwerty
layout, already long ago in its pre-hipster supply age. And is has
kept its totally non-standard decisions all the way long until today.
But also its key combinations (shortcuts) for certain things are
totally absurd from a traditional control key viewpoint.

> They've just not been consistent in key switch quality.

I wasn't talking about the mediocre keyboard quality of Apple laptops,
which is far inferior when compared to the old IBM Thinkpad keyboard
quality and has never reached any competitive level on this. I agree
though, that there is not much difference among keyboards nowadays and
they all kind of suck. Probably the Lenovo TPs have still a slight
edge on this. But I switched to Dell a couple of years ago, since
Lenovo put me completely off with his hideous clickpad introduction
(which they have reverted in more recent models, but I don't care
atm).

>> goes on with accessory cable adapters and doesn't end with their
>> software stack consisting of propietary Apple-only protocols
>
> Thunderbolt in practice: implemented in software rather than firmware,
> no hotplug for a long time if at all ever. Which other consumers even
> see it?

It totally sucks. It's a nightmare.
I have experienced complete system freezes when unplugging displays
with quite recent (2014) MacBooks and current OSX versions.

***

I am experiencing Apple users suffering the Stockholm syndrome,
unwilling to "notice" the obvious problems or talking them away.

I kind of have to conclude, that Apple marketing must do some serious
brain wash to its potential customers, otherwise I cannot explain the
idiots waiting like lemmings in artificially created queues in front
of Apple stores when Apple starts to sell a little evolved "new"
product. But perhaps those are all paid and part of the marketing
strategy. The strategy isn't any new. All teenagers all over the world
already know the effect from night club operators. Outside its a
buzzing queue, inside no party ;)

Cheers,
Anselm

Re: [dev] Collecting sins of Apple

[Anselm R Garbe]

On 25 October 2016 at 13:34, Laslo Hunhold  wrote:
> what are the really compelling reasons for a Mac user to make the
> switch to Linux/BSD? How can we convince people to make the switch?

The only reason for an experienced Mac user doing the switch is,
because he wants to gain more control over his hardware (and
software). I would consider this is a natural desire when reaching a
certain level of competence with IT technology.
Some people are lazy and cope with the environment they are used to.
Some are willing to progress the edge further and will then drop the
straightjacket. Some will never learn.

Cheers,
Anselm

Re: [dev] Collecting sins of Apple

[Anselm R Garbe]

On 23 October 2016 at 23:44, Laslo Hunhold  wrote:
> "People who are really serious about software should make their
>  own hardware."
>
> And this approach works: Macs are reliable and used to be very reliable
> machines, as already pointed out in this thread IBM found that out as
> well a while ago.

I kind of disagree here. I'm using both, PC laptops and MacBooks and
besides the aluminium case and the screen, MacBooks are in no way
superior or more reliable than the competition -- both in terms
hardware and software.

To bring it to one sentence, Apple is about providing their stuff as
incompatible as possible with all non-Apple stuff.

It starts with the power cable, proceeds with the keyboard layout,
goes on with accessory cable adapters and doesn't end with their
software stack consisting of propietary Apple-only protocols to gain
the "best experience" (a recent example is Apples new earpot -- the
best voice quality can only be got when using a recent iPhone).

I don't really like this. I don't support this monoculturalism.

-Anselm

Re: [dev] Collecting sins of Apple

[Anselm R Garbe]

Hi Luk,

On 21 October 2016 at 21:54, lukáš Hozda  wrote:
> I am not very familiar with the usage of mailing lists and unsure
> whether this is the right place to post this request, but just like
> the title says, I am collecting the sins of Apple. I will be having a
> speech/presentation on problems of Apple the next week at my school
> where I plan to talk about the wrongs against people and sane software
> Apple has on account.

Apple has transformed from a rather "alternative pre-hipster" supplier
into a so-called "premium" eco-system definer. If a customer buys
hardware products from Apple, he becomes pretty much locked into the
Apple eco-system.

I consider this "forcing in" of customers into the Apple-monoculture
as the worst aspect of Apple. In the past it was excusable, because
one needed a PC for serious work anyways and Apple hardware and
software was just some odd pre-hipster tool with limited
functionality. Nowadays it has turned into a seriously locked up
eco-system that appears to me worse than Microsofts PC dominance
during the 90s and early 2000s. People who use Apple products barely
escape from them, because they have invested a lot of money into the
associated eco-system in the form of app/itunes purchases and other
subscriptions.

Corporate eco-systems means no freedom of choice to the customer.

Speaking from FLOSS perspective, I don't think that Apple is worse or
better than all the other IT corps that do some FLOSS contributions.
Though, Apple's business model clearly is not based on open source, it
is rather based on closed hardware and source. But the same applies
for most other IT corps as well. In terms of software quality it
depends on what you look at that Apple has contributed. Most of it is
rather mediocre and hence I would consider that Apple's closed source
and hardware design assets aren't any better than average.

Best regards,
Anselm

Re: [dev] [stali] The stali way to wifi

[Anselm R Garbe]

On 21 October 2016 at 10:01, Kamil Cholewiński  wrote:
> On Thu, 20 Oct 2016, Laslo Hunhold  wrote:
>> as an off-idea: How are startup-times of stali? Given the power of
>> machines today, there should not be many things limiting a startup in
>> just a few seconds. Any data on that?
>
> Oh just try it. I was truly amazed.
> From bootloader to login prompt in like a second? Wow.

Yes, on the pi3 it takes about 2-3s, but on a regular x86 machine it
should take <2s.

I've been arguing against MS Windows' misdesign to reboot the system
on configuration changes. But from a stali perspective I kind of
prefer rebooting the system for the prize of avoiding a daemon or
runlevel management. It's simpler and it also makes you "configuring"
a system less.

"Configuring" is always an indicator of suckiness.

Cheers,
Anselm

Re: [dev] [stali] The stali way to wifi

[Anselm R Garbe]

On 19 October 2016 at 19:10, stephen Turner  wrote:
> So i briefly viewed the svc scripts, it appears that you have for the
> most part recreated daemon-tools in script form?

Are you talking about svc? Actually I did not create them and never
understood the need for them

My take is to keep everything in rc.init resp. rc.exit. I don't need
on demand services. If something should run as a daemon then it either
daemonized itself in the -d tradition or one uses some small helper
daemonizer. But still, I only need init and exit, no extra on demand
runlevel or whatever.

Actually I'm considering taking the stali approach a bit further than
just having a source-oriented target-compile. I'm considering to also
have a source-oriented configuration with a static target setup. In
other words, if one sees the need to "configure" stali, one does it in
its source, similar to the tradition of config.h instead. This
particularly applies for rc.init/exit.

Cheers,
Anselm

Re: [dev] [stali] Why lksh?

[Anselm R Garbe]

Hi Bruno,

On 9 October 2016 at 10:06, Bruno Vetter  wrote:
> i'm curious why you have chosen lksh as the stali shell. The manpage says:

Looks like a man page fault to me, probably lksh.1 is copied over
sh.1. The binary should be definitely mksh.

Cheers,
Anselm

Re: [dev] [stali] Need musl based toolchain on stali installation

[Anselm R Garbe]

On 7 October 2016 at 16:24, Bruno Vetter  wrote:
> yes, it's tedious and I understand that it's not crucial to have the 
> toolchain statically linked. Trying to do so also brings up a lot of 
> questions that I cannot answer easily. For example a statically linked linker 
> apparently does not support an lto plugin. I have no idea if that would be 
> acceptable for a toolchain.
>
> I might just go on with the existing toolchain as you describe. Thanks much 
> for your help.

You can give http://ellcc.org/ a shot, apparently most parts of it are
statically linked.

I got stali partially compiled with it, though I stopped at libressl
which had some linux header problems apparently with ellcc's includes
that I haven't resolved yet. But it didn't appear too hard to be
worked around.

Cheers,
Anselm

Re: [dev] [stali] Need musl based toolchain on stali installation

[Anselm R Garbe]

On 7 October 2016 at 12:27, Cág <c...@riseup.net> wrote:
> Anselm R Garbe wrote:
>
>> It is pretty easy. Use the toolchain as is and copy some glibc based
>> .so's for x86_64 to /crap/lib on the stali target as well.
>
> But it will not be statically linked then, as OP asked for.

Building a statically linked toolchain is a very tedious task. The
important aspect is that the target system is statically linked, I
wouldn't bother too much about the toolchain itself. I tried it myself
for a couple of months, but finally gave up. But my requirements were
harder, I wanted to get the toolchain built statically with custom
stali.mk's.

Best regards,
Anselm

Re: [dev] [stali] Need musl based toolchain on stali installation

[Anselm R Garbe]

Hi Bruno,

On 3 October 2016 at 20:30, Bruno Vetter  wrote:
>
> I would like to experiment with stali and install built-from-source 
> applications on top of the base installation. For this I need a musl based 
> toolchain not for cross-compiling, but as part of my stali system. Can 
> someone give me some hints on how to achieve this?

It is pretty easy. Use the toolchain as is and copy some glibc based
.so's for x86_64 to /crap/lib on the stali target as well.

You can check with ldd on the binaries of the stali toolchain what
.so's are required.

When everything is in place use:

LD_LIBRARY_PATH=/crap/lib 

BR,
Anselm

Re: [dev] containers opinion

[Anselm R Garbe]

On 23 September 2016 at 19:19, stephen Turner
 wrote:
> whats the suckless view of containers and why? what about a

Containers are an indicator of conceptual decay. Application developer
code has now become infrastructure and is due to the juniority far
away from any half-standardized protocols. In times with agile
software development, architects lost track of the _overall_ system
architecture. System daemons seem not to be enough anymore or too hard
for junior application developer people to base some services on. Also
it is hard to write a daemon in J2EE Java or nodejs...

Since application programmers started developing (system)
infrastructure you now need to put their dependency hell into some
manageable "containers" to keep your base server infrastructure
somehow manageable.

But the introduction of containers will not lead to a better
architecture, it is just the opener for uncaring developers to do
system programming in nodejs etc.

Remember what the introduction of all programming paradigms into C++ led to.

-Anselm

[dev] [slcon3] schedule update

[Anselm R Garbe]

Hi there,

please note the updated schedule[0], especially the dinner location[1]
for tonight.

http://suckless.org/conference
http://www.derwaldgeist.de

Best regards,
Anselm

Re: [dev] several questions

[Anselm R Garbe]

On 21 September 2016 at 16:45, Evan Gates  wrote:
> On Tue, Sep 20, 2016 at 11:02 PM, FRIGN  wrote:
>> Of course, given there is only one implementation, it is highly
>> portable per-se, given the interpretation is equal everywhere and 9base
>> is quite easily portable.
>
> Sadly there are two implementations. This rc[0] claims to be a
> reimplementation for unix systems, but contains incompatible changes.
> Here is the list of problems from the man page:

There are two, but only the original one can be considered. Byron's rc
was supposed to work in a regular unix environment with GNU userland.
But especially its environment handling is completely different to the
original rc, which allows exporting fn's.

-Anselm

Re: [dev] several questions

[Anselm R Garbe]

On 21 September 2016 at 04:04, Greg Reagle  wrote:
> On Tue, Sep 20, 2016, at 04:44 PM, FRIGN wrote:
>> Some people would recommend rc (by Plan9), but it's definitely not
>> portable
>
> Would you mind explaining specifically what you mean by "not portable"?
> It is my understanding that it works on a lot of Unix-like operating
> systems and that it is highly portable.

I was thinking exactly the same. Portability is not about being able
to compile 9base on Windows, it is that rc scripts behave in a 9base
environment exactly the same, regardless if FreeBSE, Linux, OSX or
whatever is underneath.

-Anselm

Re: [stali] Purpose (was Re: [dev] Re: [stali] updating package source)

[Anselm R Garbe]

Hi FRIGN,

On 15 September 2016 at 12:17, FRIGN  wrote:
>> concentrate on the essence here, this is all a waste of time.
> - hiro
>
> to be fair and meaning no offense to anybody, I think stali in
> general is a waste of time. It is too ambitious given the low manpower
> and the hypetrain, if I may call it so, is just pissing people off when
> they hear
> 1. how long ago this has been announced, still being vaporware
>to this day
> 2. how "many" people are working on it
> 3. how overambitious it is (rewriting makefiles for base, ...).

It all boils down to the scope that one wants to achieve with stali.
If you expect a suckless linux distro in the fashion of Debian or
Ubuntu, you know where to find it. stali surely aims to suck less as a
distro, hence its scope cannot be "general purpose".

stali's scope is now targeting embedded or special purpose
setups/platforms. Maintaining this scope is doable and doesn't require
herds of people performing crap management. The current software in
src/ is already too much for my taste and I will strictly reconsider
certain stuff that is currently in. I already mentioned my plan to
introduce 9base, as I believe it is superior to posux rewrites for
several reasons ;)

I see stali as an interesting platform for IoT devices in the future.

I agree that developing a general purpose distro with stali's design
goals is and would be a very hard task and require a lot of effort.
Hence I also gave up on this idea some years ago. But for the special
scope it is doable and works. I use it on my pi's for a special
purpose.

> The only Linux package manager which really does dependencies right is
> portage, even when the dependency trees are huge. And it also makes it
> really easy and straightforward to create cross compilers, which is
> usually a huge mess.

One rule of thumb is, that if you consider "packages" or package
management, you have left the suckless arena already. It is for a
reason that stali has no package management, because it is a magnitude
of complexity that can be avoided if done right. src/ is my answer to
"package management".

> up time, unless you spit out makefiles in 10 seconds each. Rewriting
> the build systems for other projects and maintaining them along the
> line is borderline insane.

You might not believe this, but having the stali.mk's in src prior to
my last session where I updated the software components of src/ proved
to be less of a hassle than in the first place when I was forced to
use autohell to identify all object files and compiler flags required
for the project in question.

If I interpolate this, in the longer term the time spend in developing
your own build system aside the official autohell crap pays off. As
said, it cannot be done for everything. But if you are after a very
simple basic system with no crap aboard, stali is already quite close.
The vaporware times are gone now. Have a look at what has happened
this year. The effort involved wasn't a big deal.

Cheers,
Anselm

Re: [dev] Re: [stali] updating package source

[Anselm R Garbe]

Hi Evan,

On 15 September 2016 at 01:08, Evan Gates  wrote:
> On Wed, Sep 14, 2016 at 1:33 PM, Evan Gates  wrote:
> documentation, I realize I misunderstood submodules, and subtrees are
> a better fit.
>
> For example, using sbase:
>
> git remote add sbase git://git.suckless.org/sbase
> git subtree add -P bin/sbase --squash sbase master
>
> Now the entire sbase codebase has been checked out in bin/sbase (note
> the use of --squash so we don't get the entire commit history in the
> log). We can make changes, in this case probably just adding a
> stali.mk as no other changes need to be made to sbase. If there are
> upstream changes we can pull them in:

[..]

> It all comes down to: Is this a good use of the capabilities of git?
> Or does this suck because it goes beyond most people's knowledge of
> git? I think it's a good solution to the problem of pulling updates
> into stali.

It looks appealing at first glance, but when thinking further it also
brings several risks with it.
For instance, if you rely on some repo that is hosted elsewhere, it
could become unavailable at some point or the upstream changes might
break the stali build. If all repos would be under our control and
might also include some stali branch, then things could work.

But I'm kind of old school nowadays and would consider the whole git
subtree (same applies for submodules) feature as bloat and unnecessary
complexity. It should not be part of git itself (even if it is).

My updating strategy so far involved manual copying and worked well so
far. It also gave me the freedom to patch here and there some lines of
code if necessary for a stali target build. I believe this can only
work well for the real core stuff. You may have noticed that I already
removed the linux kernel sources and keep them in separate repos.

What I imagine goes into your direction, but with a different toolset.
Google invented the repo script for Android development many years
ago. I don't like the repo implementation and its reliance on a crappy
XML format, but I do like the idea of having a meta-repo management
tool. Hence my suggestion for stali's future source organisation is
something like repo, but a suckless version of it. I have the
following in mind:

Let's call the tool metasrc, it consists of a metafile that contains the format:

# comment
local/path/situation:git-url[#tag|ref|branch]
...

You would run:

; metasrc sync http://git.sta.li/meta-stali/{x86_64-0.1|pi-0.2|...}.metafile

to initially checkout stali for the given target.

Later on you could keep pulling by running:

; metasrc pull

anywhere.

In a metasrc controlled tree git targets the current individual repo
(in your path), metasrc would always target the whole tree. Everything
except sync is interpreted as argument for one or many git calls
(depending on your tree). It is similar to repo forall.

This has also the advantage, that in theory one could also deal with
other source control systems, if some repo is not available as git but
instead as hg or even just a tarball.

I can imagine to switch to something like this.

-Anselm

Re: [dev] Shell style guide

[Anselm R Garbe]

Hi there,

On 6 September 2016 at 20:35, Evan Gates  wrote:
> suckless.org projects have traditionally been small amounts of pure C.
> The code tends towards simplicity and correctness. I value this and
> have learned much over the past years from reading and contributing to
> various projects.
>
> The addition of stali means there will probably be a fair amount of
> shell scripting. In my experience the vast majority of shell scripts
> are complete crap. Worse than poor style are poor practices that
> create broken code. As such I propose that we add a shell scripting
> style guide to go along with the existing C style guide in hopes of
> keeping suckless.org's shell scripts as clean, simple, and correct as
> the C code.
>
> I think it should include the following, and probably some more. Many
> of these rules are covered in the only bash guide I've found that
> doesn't include bad practices. It also has a lot of information
> pertaining to POSIX sh. Please check out the guide[0], faq[1], and
> common pitfalls[2].

I appreciate your efforts of coming up with some sh styleguide. A side
note to that, I prefer calling test explicitely, instead of using the
weirdo [ ] symlinks in while/if statements.

Nevertheless, after an excursion to sh for several years, I'm kind of
favouring 9base/rc again, after all. For stali I now tend to adopt rc
as primary scripting language for the target system as well. For the
build host environment I would rather stick to sh+make instead of
rc+mk. We have to live with the fact that a build host environment is
poisoned with crap bloat to hell anyways. But for ideal target system,
we should stick to technologies that have been designed with clarity
and cleanliness in mind. rc is the perfect example for a decent shell
environment.

When I started 9base and Uriel started werc and other rc-based stuff,
we concluded that one cannot really write portable scripts with sh.
You have to rely on a defined userland. The Plan 9 derived userland
offers this definition. I agree that sbase goes into a similar
direction, but the danger remains when using sh, that some stuff will
end up in pretty mixed environments.

For serious stuff like werc, rc was the right choice, because it
relies on this definite userland environment and hence does not allow
for ambiguity.

I just wanted to mention this, as this is one of my very recent
decisions about stali's future.

BR,
Anselm

Re: [dev] [dwm] Crash when setting window title to a single emoji

[Anselm R Garbe]

On 30 August 2016 at 13:18, Markus Unterwaditzer
<mar...@unterwaditzer.net> wrote:
> On Tue, Aug 30, 2016 at 08:28:21AM +0200, Anselm R Garbe wrote:
>> [...]
>> I wonder if this is a crash at all. It rather looks like a fatal Xlib
>> error to me.
>
> I'm not sure how that doesn't qualify as crash. What is your definition of
> crash?

To me a crash is an illegal control flow of a program that is detected
and aborted by the governing system (libc, etc.).

In contrast an exit() caused by the Xlib error handler is kind of a
legal control flow to me, though from a user perspective similar.

BR,
Anselm

Re: [dev] [dwm] Crash when setting window title to a single emoji

[Anselm R Garbe]

On 29 August 2016 at 19:56, Markus Unterwaditzer
 wrote:
> I'm getting crashes with a particular emoji in the window title. Enter the
> following in st/termite/xterm/urxvt (without tmux inbetween):
>
> PROMPT_COMMAND='echo -ne "\x1b]0;\xe2\x9b\x93b\x07"'
>
> dwm's output:
>
> dwm: fatal error: request code=140, error code=16
> X Error of failed request:  BadLength (poly request too large or internal 
> Xlib length error)
>   Major opcode of failed request:  140 (RENDER)
>   Minor opcode of failed request:  20 (RenderAddGlyphs)
>   Serial number of failed request:  4319
>   Current serial number in output stream:  4331

I wonder if this is a crash at all. It rather looks like a fatal Xlib
error to me.

Do you get coredumps of dwm? If yes, please provide a stack trace.

BR,
Anselm

Re: [dev] Sane office alternative?

[Anselm R Garbe]

On 25 August 2016 at 12:51, Kevin Michael Frick  wrote:
> what do you use to communicate with the part of the world (a majority,
> unfortunately) who uses suckish formats such as .doc(x), .od[tspg] or
> whatever? If Office is bloated, LibreOffice ain't slim, and people
> keep sending me word documents :/

When possible I use a pen and paper or rely on direct communication
like a phone call.

For the digital age, plain text is still fine and the format for decent emails.

When forced into office crap, I tend to use Google docs.

BR,
Anselm

Re: [dev] Bug in toolchain (based on gcc4.9.2)

[Anselm R Garbe]

Hi there,

On 25 August 2016 at 16:39, Kuniyasu Suzaki  wrote:
> I confirmed that the current toolchain "x86_64-linux-musl-gcc (gcc4.9.2)" 
> cannot treat "--coverage" option.

Not sure what you mean by "current toolchain". The current toolchain
has been updated some days ago to 5.3.0 and is based on Rich Felkers
musl-cross-make project.

> They are caused by "libgcov.a" with single "_" symbols. I checked the symbol 
> table with "nm" command and found the followings.
>
> _gcov_indirect_call_profiler_v2
> _gcov_indirect_call_callee
> _gcov_time_profiler
>
> They must be double underscores "__".  Can you fix the problem?

Why should I fix it, if it is outdated already.

> P.S.
> I confirm the (next?) toolchain downloaded from the following site worked 
> well.
>   
> http://git.sta.li/toolchain/commit/?id=6582ce3c11aee57fc83e502d5595c28f949fe98d
>   
> http://git.sta.li/toolchain/snapshot/toolchain-6582ce3c11aee57fc83e502d5595c28f949fe98d.zip
> The toolchain is based on gcc5.3.0.

Exactly.

Best regards,
Anselm

[dev] [slcon3] preliminary schedule and registration deadline

[Anselm R Garbe]

Hi there,

I'm glad to announce the preliminary slcon3 schedule[0].

We have accepted all proposals.

Please also note to register your attendance now (even if you are not
a presenter but plan to attend) until: *2016-09-01* by sending me a
mail to ans...@garbe.us

All presenters don't need to register, I already know that you will
attend. All others that have not yet notified their attendance, let me
know soon. The conference fee will be around 45 EUR this year
(including the drinks and lunch packages).

[0] http://suckless.org/conference/

Best regards,
Anselm

Re: [dev] [dwm] compile error

[Anselm R Garbe]

Hi there,

On 21 August 2016 at 18:19, Orka Edison  wrote:
> [sudo] password for Orka:
> cleaning
> dwm build options:
> CFLAGS   = -std=c99 -pedantic -Wall -Wno-deprecated-declarations -Os
> -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -D_BSD_SOURCE
> -D_POSIX_C_SOURCE=2 -DVERSION="6.1" -DXINERAMA
> LDFLAGS  = -s -L/usr/X11R6/lib -lX11 -lXinerama -lfontconfig -lXft
> CC   = cc
> CC drw.c
> In file included from drw.c:6:0:
> /usr/include/X11/Xft/Xft.h:39:22: fatal error: ft2build.h: Aucun fichier ou
> dossier de ce type
>  #include 
>   ^
> compilation terminated.
> Makefile:18: recipe for target 'drw.o' failed
> make: *** [drw.o] Error 1
> Orka@Sony-Vaio:~/Documents/dwm-6.1$

This reminds me to re-instate the good old non-freetype drw.* implementation.

Xft sucks.

-Anselm

[dev] Re: [slcon3] Call for papers

[Anselm R Garbe]

Hi there,

friendly reminder of our CfP deadline for slcon3 [0] on **20 August 2016**.

If you want to present, you have 2 days to make a proposal!

[0] http://suckless.org/conference/

Please note, all proposals that we have received so far will be accepted.

Also note that you can arrange your room booking at the venue
announced in our wiki, if you like.

Thanks and best regards,
Anselm

On 20 July 2016 at 08:17, Anselm R Garbe <garb...@gmail.com> wrote:
> UPDATE slcon3
>
> Unfortunately we did not receive too many proposals yet, though I
> checked with a bunch of fellows that they intend to deliver their
> proposal slightly delayed.
>
> Hence we extend the submission deadline until: **20 Aug, 2016**
>
> ALSO: I would like to ask everyone who wants to attend, to reply
> directly to me, so that we can check how many people will definitely
> attend the conference[0].
>
> [0] http://suckless.org/conference/
>
> Best regards,
> Anselm
>
> On 3 June 2016 at 08:04, Anselm R Garbe <garb...@gmail.com> wrote:
>> Hi there,
>>
>> I'm glad to start our call for papers for slcon3[0] which will be held
>> near Frankfurt (Main), Germany from 23-25 September, 2016.
>>
>> We expect talk proposals between 30-60 minutes each covering either
>> technical or philosophical topics (rants are welcome as well).
>>
>> Each proposal should contain
>> - the name of the author
>> - an abstract written in English
>> - presumably a couple of reference links to related ideas or topics
>>
>> Please note, do only submit a proposal if you are pretty certain that
>> you can attend the conference on the given date.
>>
>> The call for paper submission deadline is: 20 July, 2016.
>>
>> Please submit your proposal to: con(at)suckless.org
>>
>> We don't expect a paper or slide set prior to the conference! Your
>> proposal should enable us to accept/deny your talk and to schedule an
>> adequate slot for it.
>>
>> If you cannot attend on a certain day, please add a note to your
>> proposal. We then are able to fine-tune the schedule.
>>
>> We will publish the final schedule and all conference details in early
>> August 2016.
>>
>> [0] http://suckless.org/conference
>>
>> Best regards,
>> Anselm

Re: [dev] [sxiv] Discussion

[Anselm R Garbe]

Hi there,

On 9 August 2016 at 10:17, FRIGN  wrote:
> don't take it personally, Bert, but I don't think your project sxiv[0]
> belongs to the suckless git-repository.
> Not only is it licensed with the GPLv2, which is despicable in itself,
> but the code doesn't even look suckless to me and there are good ways
> to go around the whole image-format-cancer-spread nowadays.
> Look at how sent does image handling; it's definitely best to push this
> task toward other tools, like farbfeld, for easy internal handling.
>
> C:   3663 (98.05%)
> sh:  43 (1.15%)
> awk: 30 (0.80%)
>
> Do we really need a project the size of dwm to display images?
>
> The name suckless stands for quality software, which foremost tries to
> accomplish elegance and simplicity. There are already too many git
> repositories in git.suckless.org, and added to this it seems the sxiv
> repo on git.suckless.org is just a github mirror, with all its implied
> beauty[1]. Do I really need to dig around github now to see what the
> commit fixed?
>
> What do you think?

Disclaimer: what I'm saying next is not related at all to sxiv -- to
me a very valid image and thumbnail viewing tool.

I think we should address our overall project portfolio and
responsibility situation at slcon3 end of Sep. I think the
suckless.org project has diverged in many directions and needs some
clear rules and leadership wrt. which project to host, which developer
felling decisions for a particular project and which project to
decline or remove.

Due to the fact that many contributors have done great work so far and
also that we have formed a legal entity for suckless.org we need a
board to agree and define such rules for the future and to also agree
on a project decision and governance board in the future.

In the past I felt confident to fell some decisions on my own. Now I
feel a bit uncomfortable doing this on my own sake. I do see the same
problem if someone else related with suckless.org makes such
proposals. If the overall entity representatives agree on the single
leadership model, that would be fine by me. But we have to discuss
this first at slcon3.

So let's stop such proposals for now, until we have made an agreement
with the other representatives.

BR,
Anselm

Re: [stali] scope (was: Re: [dev] neatroff)

[Anselm R Garbe]

On 11 August 2016 at 11:21, FRIGN  wrote:
[..]
> I am sure suckless.org has a lot of street-cred in the OSS-scene. We
> could use this leverage to have a positive influence on a big
> distribution people actually use. In the long term, making OpenBSD
> better will benefit those who are scared of making the switch. We all
> know that OpenBSD is much further on the convergence line towards an
> ideal operating system for server and desktop applications than Linux
> and its messy userland.

I don't think that having a very compact linux based stali src is more
complex to maintain than trying to change little things in OpenBSD.

The purpose of OpenBSD nowadays has barely changed than its purpose 10
years ago. It is primarily used at the border of networks I guess.

The purpose of stali could be a nice IoT platform, with a completely
different embedded scope.

The purpose of the next leet linux distro could be the work
environment for the senior hacker. It could also well be OpenBSD or
FreeBSD, I don't mind.

But I also don't think that monoculturalism in terms of distros or
OSes is a good thing. Every little effort has its pros and cons.
OpenBSD is quite a decent OS overall, but for most it might be rather
limiting in scope. Unfortunately I also see the BSDs on the dying
path.

You could also suggest 9front or another Plan 9 bastardisation. It
will work in a specific scope, but won't give you much flexibility
outside the beauty of its world.

With stali I'm pretty much compact-userland-only oriented and benefit
from the kernel stuff others do. In BSD/P9 lands one is more
beauty-system oriented, but a loser when forced to use some kind of
commercial or semi-commercial software.

If the suckless community favours an own distro approach, I would
definitely start on the Linux path as well. There is no big reason
trying to change the BSDs for the better hardware support. That race
was lost already 15 years ago.

But I can understand your enthusiam for the BSD world. I have been
there 15 years ago as well.

Cheers,
Anselm

Re: [dev] neatroff

[Anselm R Garbe]

On 11 August 2016 at 10:10, FRIGN <d...@frign.de> wrote:
> On Thu, 11 Aug 2016 09:44:45 +0200
> Anselm R Garbe <garb...@gmail.com> wrote:
>> The stali plan has changed for me a bit during the last year. A couple
>> of months ago I tried to get stali self-bootstrappable based on just
>> src/. I have now given up on this idea for various reasons:
>> [...]
>> Any help is welcome under the new premises above. I think it is kind
>> of a hygene factor to not aim for a self-bootstrappable environment.
>> The beauty is that target platform, not the src/. The src/ is hideous
>> in most parts anyways, if you consider what stali relies on.
>
> I've been wondering for a while what you think the problem is with
> OpenBSD. Wouldn't it make more sense to somehow start an initative in
> OpenBSD to promote static linking there?

I have no problem with OpenBSD per se, but I do think that its scope
is general (server) purpose and that the hardware support in the
embedded non-network space doesn't sound too great to me. linux kernel
+ some dedicated userland is far more flexible imho.

Cheers,
Anselm

Re: [dev] neatroff

[Anselm R Garbe]

On 10 August 2016 at 08:47, Eli Cohen  wrote:
> What's the plan for stali? I was under the impression it would be a
> "suckless distro" with dwm, surf, st... will X11 stuff be in a
> different repository?

The stali plan has changed for me a bit during the last year. A couple
of months ago I tried to get stali self-bootstrappable based on just
src/. I have now given up on this idea for various reasons:

- I don't think it is really the point of stali to become a general
purpose system anymore.
- I can't stand the hideousness of gcc and llvm which seem to be a
requirement to get it done
- I wasn't able to create a statically linked cross target gcc setup
that is easy to port among different hosts/targest (host=target works,
but it sucks).

If one wants a general purpose system, there are plenty to pick from.
Granted, there are 0 statically linked ones. And that's the point. A
statically linked system *should not* be general purpose, it ought to
be special purpose instead.

The special purpose I think stali now will become is this: it will be
a multi-target static distro (pick your root fs flavour as you like)
without aiming to be self-bootstrappable. The target will most likely
be fully compiler- and build-chain less. This makes the target system
execution-only oriented and more compact. My next goal is to target
the arm64 (pi3) platform now.

In terms of "package management" this has also the implication, that
one can thing of extra/ add-on overlays that keep src/ sane. And such
ending up in the particular rootfs flavour.  Whenever someone wants to
part a certain package to stali, just create a setup that relies on
the fact that $STALI_ROOT/src and $STALI_ROOT/toolchain- exists
and good is. We will need general purpose (Debian, Gentoo, Arch,
whatever) build environments though.

(I will present some ideas at slcon3 about actual projects I'm working
on right now in terms of observing my bee hives with pi zeros that
will become stali based.)

Some days ago I branched src's master into a x86_64 branch, this will
aim for a very basic suckless target system featuring an X +
dwm/dmenu/st on top of the base system, Potentially with the addition
of a webkitgtk + surf static build.

My current arm64 branch will aim for a X-less target of course with
only the absolutely necessary stuff. I will create some extra repos on
top of that for some observation tools using different pi gadgets,
such as temp+humidity sensors and a IR camera.

> I tried to do something similar on my lan when I first heard of stali,
> with a bunch of overlaid rsync repositories. I guess I'm mostly
> curious about how i can help :)

Any help is welcome under the new premises above. I think it is kind
of a hygene factor to not aim for a self-bootstrappable environment.
The beauty is that target platform, not the src/. The src/ is hideous
in most parts anyways, if you consider what stali relies on.

BR,
Anselm

Re: [dev] neatroff

[Anselm R Garbe]

On 10 August 2016 at 03:56, Eli Cohen  wrote:
> I'm trying to get neatroff compiled in a stali fashion. I've run into
> a slight impasse regarding licensing.  for typesetting, neatroff uses
> ghostscript fonts, which are gpl. (really my goal with all this is
> just to display man pages)

stali is only core/terminal mode oriented, why do you need fancy fonts?

Re: [dev] Never Ending Systemd Chronicles

[Anselm R Garbe]

On 5 August 2016 at 13:34, Hadrien LACOUR
 wrote:
> On Fri, Aug 05, 2016 at 08:26:42AM -0300, Marc Collin wrote:
>> I got introduced to s6-rc [0] lately.
>> Do you guys have any experience with it?
>>
>> [0] http://skarnet.org/software/s6-rc/

Looks nice.

Nevertheless for my refined stali scope sinit is the way to go. I
don't require supervision.

-Anselm

Re: [dev] Allow secure access to Web site suckless.org

[Anselm R Garbe]

Hi 20h,

On 3 August 2016 at 12:18, Christoph Lohmann <2...@r-36.net> wrote:
> On Wed, 03 Aug 2016 12:18:52 +0200 Paul Menzel  wrote:
>> I noticed, that it’s currently not possible to securely browse the Web
>> site [1].
>
> HTTPS is not really secure. Do you really trust any CA? How many CA peo‐
> ple have you met in your life and really trust them?

Do you trust your network adapter telling you the truth?

Nevertheless I doubt you don't use online banking and stuff like that,
hence you definitely trust some CA to some extent ;)

BR,
Anselm

Re: [dev] Allow secure access to Web site suckless.org

[Anselm R Garbe]

On 3 August 2016 at 11:36, Paul Menzel  wrote:
> I noticed, that it’s currently not possible to securely browse the Web site
> [1].
>
> Are there plans to allow access using HTTP over SSL?

This is on my TODO list for quite some time. Expect it to happen until
end of this year.

BR,
Anselm

[dev] Re: [slcon3] Call for papers

[Anselm R Garbe]

UPDATE slcon3

Unfortunately we did not receive too many proposals yet, though I
checked with a bunch of fellows that they intend to deliver their
proposal slightly delayed.

Hence we extend the submission deadline until: **20 Aug, 2016**

ALSO: I would like to ask everyone who wants to attend, to reply
directly to me, so that we can check how many people will definitely
attend the conference[0].

[0] http://suckless.org/conference/

Best regards,
Anselm

On 3 June 2016 at 08:04, Anselm R Garbe <garb...@gmail.com> wrote:
> Hi there,
>
> I'm glad to start our call for papers for slcon3[0] which will be held
> near Frankfurt (Main), Germany from 23-25 September, 2016.
>
> We expect talk proposals between 30-60 minutes each covering either
> technical or philosophical topics (rants are welcome as well).
>
> Each proposal should contain
> - the name of the author
> - an abstract written in English
> - presumably a couple of reference links to related ideas or topics
>
> Please note, do only submit a proposal if you are pretty certain that
> you can attend the conference on the given date.
>
> The call for paper submission deadline is: 20 July, 2016.
>
> Please submit your proposal to: con(at)suckless.org
>
> We don't expect a paper or slide set prior to the conference! Your
> proposal should enable us to accept/deny your talk and to schedule an
> adequate slot for it.
>
> If you cannot attend on a certain day, please add a note to your
> proposal. We then are able to fine-tune the schedule.
>
> We will publish the final schedule and all conference details in early
> August 2016.
>
> [0] http://suckless.org/conference
>
> Best regards,
> Anselm

Re: [dev] [dwm] [PATCH] Configure geometry before applying rules

[Anselm R Garbe]

On 23 June 2016 at 16:40, Eric Pruitt <eric.pru...@gmail.com> wrote:
> On Thu, Jun 23, 2016 at 10:14:54AM +0200, Anselm R Garbe wrote:
>> Sorry I missed to reply sooner. Please re-create the patch against git
>> HEAD so that it cleanly applies and I will apply it.
>> Alternatively I can apply it as a new commit which wouldn't take your name.
>>
>> Hence I suggest create a clean patch ;)
>
> That patch already applies cleanly:
>
> dwm$ head -n10 0001-Configure-geometry-before-applying-rules.patch
> From da2a02dd23befc0ff89d08c990a360c048f0adfd Mon Sep 17 00:00:00 2001
> From: Eric Pruitt <eric.pru...@gmail.com>
> Date: Wed, 25 May 2016 16:33:11 -0700
> Subject: [PATCH] Configure geometry before applying rules
>
> Configuring geometry before applying rules makes it possible to have
> more complex constraints in applyrules that depend on the initial window
> dimensions and location.
> ---
>  dwm.c | 13 +++--
> dwm$ git reset --hard 3465bed290abc62cb2e69a8096084ba6b8eb4956
> HEAD is now at 3465bed fix fullscreen clients not resized on X display
> resolution change
> dwm$ git apply 0001-Configure-geometry-before-applying-rules.patch
> dwm$
>
> Does your repo have changes you haven't pushed to the public repo?

No, I ought to use git am rather.
(git apply gave me weird errors).

Applied.

-Anselm

Re: [dev] [dwm] [PATCH] Configure geometry before applying rules

[Anselm R Garbe]

Hi Eric,

On 23 June 2016 at 08:09, Eric Pruitt <eric.pru...@gmail.com> wrote:
> On Fri, Jun 10, 2016 at 08:37:11AM -0700, Eric Pruitt wrote:
>> On Wed, Jun 08, 2016 at 10:00:16AM +0200, Anselm R Garbe wrote:
>> > If I share the same view tomorrow, I will apply your patch.
>>
>> Are you still planning on on applying this patch?
>
> I'm following up on this since it still hasn't been merged.

Sorry I missed to reply sooner. Please re-create the patch against git
HEAD so that it cleanly applies and I will apply it.
Alternatively I can apply it as a new commit which wouldn't take your name.

Hence I suggest create a clean patch ;)

BR,
Anselm

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Anselm R Garbe]

On 17 June 2016 at 09:12, Quentin Rameau  wrote:
>> ---.patch
>> Would make:
>> st-externalpipe-20160423-ea87104.patch

> Should the date remain the creation date while the hash is updated, or
> should the date be bumped up too?

The date should always be updated, whenever the patch is touched in some way.

-Anselm

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Anselm R Garbe]

On 15 June 2016 at 19:45, FRIGN  wrote:
> we also had this discussion already. The point here is: using the date of
> the "update" is the best and easiest heuristic. you see with one look
> if a git-patch is relatively old or new.

I would suggest to use: ---.patch

Replacing the "git" portion with the short hash makes it much more
accurate to what git version the patch applies to.
Also condensing the date to skip the century is a good idea in the
year 2016. Still 84 years to come without a century problem of patch
file names.

I would even go that far to skip the date completely. It doesn't
really tell you much. If someone bothers of the age of a patch, then
you can always check git with the hash.

-Anselm

Re: [dev] [dwm] [PATCH] Configure geometry before applying rules

[Anselm R Garbe]

Hi Eric,

On 26 May 2016 at 01:57, Eric Pruitt  wrote:
> Since dwm doesn't expose enough of the X11 properties to use Devil's
> Pie, I am using changes inside of applyrules to modify window locations
> and geometry. As part of my changes, I needed client geometry properties
> to be set before the applyrules function is called because I need to
> know where a window is initially located to determine if it needs to be
> modified. I don't see anything that indicates the geometry assignments
> **must** occur before calling applyrules, so I think it would be a good
> to move the geometry assignments permanently in the suckless repo; most
> people "configure" dwm by patching it, and this change would make it
> easier to add more complex constraints to applyrules. I've attached a
> patch with this change to my email.

I think this change can be applied. At some point I did some kludges
to decide if something is floating (or fullscreen) in applyrules, and
at that time it was important to have the geometry applied after
applyrules. I'm still thinking about it, but can't see anything
harmful right now.

If I share the same view tomorrow, I will apply your patch.

BR,
Anselm

Re: [dev] [slock] [PATCH] Ctrl-u now resets the input

[Anselm R Garbe]

Hi Troy,

I'm not sure if this feature is really required. Typing a wrong
password can be corrected on second attempt anyways.

What is the opinion of other users to this change?

BR,
Anselm

On 5 June 2016 at 23:22, Troy Sankey  wrote:
> Before this commit, only pressing Escape would reset the input.  This commit
> makes Ctrl-u do the same.  Rationale: it more closely mimics behavior of
> login(1)/getpass(3).

[dev] [slcon3] Call for papers

[Anselm R Garbe]

Hi there,

I'm glad to start our call for papers for slcon3[0] which will be held
near Frankfurt (Main), Germany from 23-25 September, 2016.

We expect talk proposals between 30-60 minutes each covering either
technical or philosophical topics (rants are welcome as well).

Each proposal should contain
- the name of the author
- an abstract written in English
- presumably a couple of reference links to related ideas or topics

Please note, do only submit a proposal if you are pretty certain that
you can attend the conference on the given date.

The call for paper submission deadline is: 20 July, 2016.

Please submit your proposal to: con(at)suckless.org

We don't expect a paper or slide set prior to the conference! Your
proposal should enable us to accept/deny your talk and to schedule an
adequate slot for it.

If you cannot attend on a certain day, please add a note to your
proposal. We then are able to fine-tune the schedule.

We will publish the final schedule and all conference details in early
August 2016.

[0] http://suckless.org/conference

Best regards,
Anselm

Re: [dev] [sup] Bring the simple user privilege escalation tool back home?

[Anselm R Garbe]

On 16 May 2016 at 23:22, Marc André Tanner  wrote:
> On Tue, May 10, 2016 at 01:27:40PM +0200, FRIGN wrote:
>> I think the vis editor alone is enough bloat in the suckless
>> repositories.
>
> I don't know what vis has to do with the original thread, nonetheless
> it would be interesting to know which aspects of vis you consider
> bloated?

I can only imagine he meant sandy which I would suggest to be removed asap.

BR,
Anselm

Re: [dev] [dwm] [patch] config.o

[Anselm R Garbe]

Hi Connor,

On 14 May 2016 at 17:24, Connor Lane Smith  wrote:
> Attached is a dwm patch that pulls out all of the key and button
> handlers, and all of the layouts, into a new file called config.c,
> replacing config.h. The idea is that it makes it clearer what is dwm
> proper and what is just a part of the default config.
>
> I've sat on this patch for about half a year, and I've still not made
> my mind up as to whether it's a good idea or not. But I thought I
> might as well post it on here anyway.

I don't like this approach for various reasons.

First of all the decision to reduce dwm into the code not containing
key, button, focus and layouting algorithms and inventing a new
"config.c" containing all this looks very arbitrary to me. One could
argue that the affected code portions you put into config.c have been
referenced in the vanilla config.h, but conceptually pure dwm makes no
sense without key, button, focus and layouting algorithms to me.

Second this approach breaks the config.h idea pretty much. It would
make "configuring" dwm a lot harder. The idea behind config.h is to
only define data structures that later on influence the algorithms in
one way or another. One doesn't need to understand the actual
algorithms in order to "configure" dwm, or getting distracted due to
lot's of code in a config.c file. After all, config.h is also pretty
much widespread among suckless programs, hence breaking it would make
it  conceptually harder to follow.
(Of course some patch contributors have taken this approach further
and inject some local functions into config.h. As long if those things
remain exceptions I see this as acceptable. However I would never
change vanilla dwm to contain functions in config.h files.)

Third and foremost all suckless code I contributed followed a very
basic rule and I still believe this is the right thing. It is the rule
that _all_ code of a certain program should belong into a _single_
file with main at the end. The only exception I do accept here is, if
one inherits code copies from library's (like util.{c,h}, drw.{c,h})
that is shared among other projects.
Why?
This rule enforces simplicity: there is no need to introduce too much
extern'al visibility of data structures and functions.
This rule enforces readability (even with very basic editors):
whenever you end up reading code at some function call, I hate it if I
then have to skip and seek for the right file containing the _actual_
implementation of that function. This basic rule makes it easier to
just skip around in a single file.
This rule enforces consistency: you avoid splitting up the code of a
program into arbitrary files that will always raise questions by other
readers/contributors (why did you put it here/there).
This rule lives well with source control: git can easily follow the
whole history of each line, no certain points in history where a file
was abandoned because of such proposals like yours. Each time when
browsing a git history such an event happened, means to the reader, he
has to make up his mind why this happened...
This rule keeps SLOC down: probably the most important aspect: the
size of a program.c file forces its authors to keep the SLOC down,
because it is a good mirror if one can still understand the code
altogether. Having dozens of .c files let's you easily end up in a
different situation after some years.

Best regards,
-Anselm

Re: [dev] Re: Linux distros that don't suck too too much

[Anselm R Garbe]

On 13 May 2016 at 01:31, Jason Young  wrote:
> suckless is about *simplicity*. Simplicity != easy to use. Simplicity
> means, basically, there's fewer parts to break, and there *being* fewer
> parts, it's easier to see *where* it breaks. Unfortunately, the more
> "easy to use" you make a piece of software, the bigger it gets and the
> more dependencies it accrues, and you're right back at suck software.

This is a delusion. "easy to use" does not imply complexity.

A rule of thumb for UI design is this: if a UI offers multiple ways to
achieve the same result, it sucks and becomes less "easy to use". It
confuses the user. And such an UI costs the extra price of additional
complexity.

Instead "easy to use" interfaces should just reflect the solution
underneath and will only be simple if the solution underneath is
simple.

Also note the quotes Louis replied, they explain it much more crisp.

-Anselm

Re: [dev] [sup] Bring the simple user privilege escalation tool back home?

[Anselm R Garbe]

Hi there,

On 10 May 2016 at 13:27, FRIGN  wrote:
> On Sat, 7 May 2016 12:36:38 -0300
> Marc Collin  wrote:
>> Wouldn't it make sense to give jaromil access to the suckless git
>> repository and let him work there?
>> What does everyone think?
>
> I don't know jaromil and it seems like he is not even subscribed
> to the mailing list.
> Having push-rights for the suckless.org-git-repositories is a
> privilege and won't be given up to strangers.
> Keep in mind that giving somebody push rights enables him to
> push to any repo on git.suckless.org.
> As the developer announced, he'll add bloat to his software,
> and I think the vis editor alone is enough bloat in the suckless
> repositories.

My initial thought on Marc's mail was yes, however after becoming
aware of Jaromil's plan to add all those features to sup in the
future, I also decided against giving him access to suckless.org.

The problem here is that his plan violates the suckless philosophy of
keeping things simple and developing tools that do only one thing
well. Loading kernel modules, sending signals, writing to arbitrary
paths to /sys etc. doesn't really fit with suckless.org.

Nevertheless I do appreciate that he seems to have fixed certain
issues in suckless.org's state of sup. Thus I would suggest to check
what he has changed so far to see if it's worth being applyed to
suckless.org's version of sup. Perhaps pancake is available for his
opinion as well.

I also discussed with Jaromil the option to rename sup into something
different to avoid future confusion.

My preferred suggestion is, to rename suckless.org's sup into ssu (for
simple or suckless su), to make it crisp what it is all about. He
could keep using sup instead, as sup doesn't really contains the
simple or suckless aspect in its name. But also the other option would
be possible that he renames his sup version into something else when
he adds the bloat.

Best regards,
Anselm

Re: [dev] C, gcc and armv8

[Anselm R Garbe]

Hi there,

On 2 May 2016 at 07:25, Sylvain BERTRAND  wrote:
> Just to raise awareness on this issue:
>
>   - gcc is now c++98 boot-strapable only.

Where do you have this information from?

At least to me it looks like that gcc-5.3.0 is still bootstrappable
without any g++ call as long as you are not targetting to build C++
support.

-Anselm

Re: [dev] "Note On Webkit Versions"

[Anselm R Garbe]

On 30 April 2016 at 12:47, Kajetan Jasztal  wrote:
> how about servo[1]? aims for memory security and fast parallel rendering
>
> [1] https://servo.org/

I'd rather suggest NetSurf[0]. The idea is a couple of years old, but
one could consider forking it and remove all clutter from it, to form
a kind of usable HTML4 compliant browser.

For HTML5 support you are doomed to stick to WebKit/blink.

[0] http://www.netsurf-browser.org/

-Anselm

Re: [dev] [lnanohttp] nanonimal http server for linux

[Anselm R Garbe]

On 20 April 2016 at 05:17, Sylvain BERTRAND  wrote:
> For my personnal use, I needed a small http server. All "mini" http servers 
> out
> there I had a look were, IMHO,  bloaty (SDK included).

Did you also look at http://git.suckless.org/quark/tree/quark.c ?

quark is fork() based (and POSIX compliant in that sense) though, not
epoll_wait() based. So quark will perform accordingly, but it supports
a bit more HTTP features (incl. cgi execution), but its SLOC is
considerable equal to lnanohttpd.

> lnanohttp is really small (including dependencies and SDK), straight on linux 
> kernel
> syscalls with a thin layer. Tested only on x86 and with a gcc/binutils
> toolchain for the moment (planing to buy an armv8 raspberry board).
>
> Can be use easily as a base for a beefier http server.

Some quick remarks: it uses a lot of #define's (all over the place)
which I consider very weird. Also for type declarations it uses
#define's of types which seem to be very weird as well. (e.g. #define
sl ulinux_sl).

Also is relying on -errno checks all over the place really secure? I
would rather check for -1 and compare with errno directly. Or is it a
linux pattern I wasn't aware of?

BR,
-Anselm