I do not want to get involved in one of the usual useless discussions about
how much something sucks. As for me, I have never been able to install
Archlinux without having to use a custom kernel, which is unacceptable for
a serious linux distro. The system is often unstable, the community is
rather idiotic, full of fanatic morons with dubious technical skills and
anyway Arch is probably the "minimalist" linux distribution with more bugs
ever. systemd, which of course sucks, is a blessing in comparison to
everything else. I think we could write a book about, but I'll stop here.
2012/11/17 Newton Smartt <newtonbsmartt_AT_gmail.com>
> What's wrong with Arch?
>
>
> On Sat, Nov 17, 2012 at 1:11 PM, clamiax <smoppy_AT_gmail.com> wrote:
>
>> 2012/11/17 Anselm R Garbe <garbeam_AT_gmail.com>
>>
>>> Hi there,
>>>
>> Hi.
>>
>>
>>> I'm back in the game ;)
>>>
>> Welcome back!
>>
>>
>>> (i) First I plan a new dwm release with the introduction of draw{.h,c}
>>> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
>>> the dwm implementation and to define a clean draw.h interface to be
>>> used instead. This should also be incorporated into dmenu and st.
>>
>> This sound like a logical step we had to do first or later. At least,
>> until we have something to draw.
>>
>>
>>> a) requiring an additional library dependency at build time (I'm not
>>> the biggest proponent for this idea)
>>>
>> If we aspire the perfection this shouldn't even be considered.
>>
>>
>>> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
>>> implementation is the master
>>
>> Maybe. Does this also mean that we could end up to have some piece of
>> code used in some program but unused in other, for the sake of sharing the
>> same implementation?
>>
>>
>>> (ii) Another aspect on the dwm roadmap is a reimplementation of the
>>> current multi-screen handling. It still contains some weird bugs in
>>> special setups with same screen sizes. Those don't seem to be easily
>>> fixable with the current updategeom() handling.
>>>
>> I don't need multi-screen handling at all. No, I'm not proposing to
>> remove it. It would be too nice...
>>
>>
>>> (iii) A third idea is an old idea that 20h brought into the discussion
>>> when investigating 2wm. The man page of 2wm mentions sbar, which was
>>> abandoned a couple of years ago. My question here is:
>>
>>
>>> -> is there anyone who uses the mouse functionality of the dwm bar
>>> right now? Could you live without it?
>>>
>> No. Yes.
>>
>>
>>> I barely use the mouse for the dwm bar and would be in favour for
>>> removing the bar altogether from dwm. Instead I would output the
>>> current dwm state to stdout which could be used by a different program
>>> like sbar for input. But I wouldn't add an interface to dwm to change
>>> the tags through X props or some other command interface (like stdin
>>> processing) to allow other programs to amend the dwm tags. Good old
>>> key commands would be enough for me.
>>>
>> Agreed. Though someone doesn't. I hate when people which don't think like
>> me comes with good arguments. I can safely ignore them, though. So, +1 to
>> remove the bar from dwm.
>>
>>
>>> I know that some of you are inclined to use dwm on tablets. But I'm
>>> not convinced that tablets or touch interfaces in general are a nice
>>> fit with the terminal world we live in.
>>>
>> I'm pretty sure that even those who use dwm on tablets are doing it by
>> thinking that it is not a good idea.
>>
>>
>>> dmenu needs some fixes. The removal of config.h is the wrong way it
>>> took. If someone stays with hg of dmenu or uses the releases, he has
>>> to do conflict management now with dmenu.c changes.
>>>
>> I don't use dmenu. No, I'm not proposing to abandon the project. It's so
>> geek.
>>
>>
>>> To me archlinux was a good distro until a couple of years ago.
>>>
>> To me, you are wrong. Archlinux has never been a good distro.
>>
>> Nowadays it seems to be very en vogue and thus has degraded quite
>>> significantly in terms of simplicity. I'm not aware of any distro that
>>> would come close to the radical goals of stali, thus this is the real
>>> effort suckless.org must work on. I believe that the Android core as
>>> a base system is the best platform to base sta.li on.
>>>
>> I agree to use Android core as base system but only if we schedule to
>> slowly remove it from sta.li, one piece at a time, until will not
>> remaing nothing at all.
>>
>
>
Received on Sun Nov 18 2012 - 09:56:44 CET
This archive was generated by hypermail 2.3.0
: Sun Nov 18 2012 - 10:00:07 CET