Re: [dev] dmenu's lsx binary naming conflicts with lrzsz!
That's not a machine, it's a moka. 2011/11/28 Kurt H Maier : > On Mon, Nov 28, 2011 at 12:08 PM, Bjartur Thorlacius > wrote: >> Scripts have to be able to depend on command names; command line >> interfaces are interfaces too. In theory, bin directories should >> contain directories containing the actual commands. Yes, I would >> suggest namespaces if compatibility with existing shells and scripts >> such as lsx would not require symlink hell. > > I'm not sure what your point is. > >> bin/ >> apt/ >> install >> show >> depends >> search >> dmenu/ >> run >> lsx >> update_cache >> prompt > > My machine doesn't have enough ram to process this structure for find(1). > > > -- > # Kurt H Maier > >
Re: [dev] sbase TODO patch
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/yes/yes.c?rev=1.8.22.1&content-type=text/x-cvsweb-markup 2012/2/10 Džen > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/yes/yes.c?rev=1.8 > > -- > Džen > > On 09/02/12 11:55pm, Lukas Fleischer wrote: > > On Thu, Feb 09, 2012 at 10:52:57PM +, Connor Lane Smith wrote: > > > On 9 February 2012 22:44, Lukas Fleischer > wrote: > > > > Yeah. 'if (!argv[1]) argv[1] = "y";' and this gets a +1 from me :) > > > > > > It'd probably be more like, > > > > > > > const char *s = (argc < 2) ? "y" : argv[1]; > > > > while(puts(s) != EOF); > > > > Agreed :) > > > > > > > > cls > > > >
Re: [dev] sbase TODO patch
It's weird to read people who calls nightmare something they didn't understood.
Re: [dev] sbase TODO patch
2012/2/11 Bjartur Thorlacius > > Shouldn't there be an utility that does both? A flag to rm, perhaps? > +1
[dev] Moveresize patch page defaced
Hi, it would be nice if Jan Christoph Ebersbach would remove its garbage along with all unreachable URLs from the moveresize patch page to its own page, maybe maximize_vert_horz, which have nothing to do with moveresize. Also it would be great to move its moveresize implementation to a more appropriate page like GNUmoveresize. Thanks! Regards, Claudio M. Alessi
Re: [dev] Moveresize patch page defaced
Hi, 2012/2/21 Anselm R Garbe : > It's a wiki after all and it would be quicker to fix the sites yourself. I'm here to discuss about the change *before* make it, since most people may not agree with me. Also I will not waste my time fixing other people defacements; nor I should. > The 6.0 patches do look ok from my point of view. Adding 60 SLOC with no real benefits is not ok, from my point of view. But yes, I understand someone may like to moving X clients around between monitors just for funny. Regards, Claudio M. Alessi
Re: [dev] Moveresize patch page defaced
2012/2/22 Rob : > I don't agree, I like moving windows with the keyboard, and the > cross-monitor thing was bugging me That's most likely due to your wrong workflow, which includes moving X clients between monitors. I'm not complain about multi-head setup, I'm just telling you that moving windows between monitor without any kind of criteria is a flaw in your worflow. > That's why it's a patch and not in tip This mean people can put any kind of patch on suckless.org regardless if it comply with our phylosophy or not (and place it above that which comply instead). Ok, I just learned a new rule. > You've got to have some sense of humour when using dwm/this mailing list I'm working hard to achieve this goal. Thanks! Regards, Claudio M. Alessi
Re: [dev] Moveresize patch page defaced
Hi, 2012/2/22 Connor Lane Smith : > I think we can agree that the "maximize vertical/horizontal patch" > should be on a separate page, but what I don't understand is why > you're emailing this mailing list. Clearly either you should make the > change, or you should email Jan (whose email is available on the page > you're complaining about). I have the bad habit to ask the community first. Regards, Claudio M. Alessi
[dev] [OT] Setting up a dedicated server
Hi, I've been asked to investigate whether it's worth to setup a dedicated web server (including hardware) in order to host about 30 web sites, among which our one. Although I think I have the skills to configure the software, I'm not much sure about the hardware and other aspects. Since we have ~50K monthly users I wonder if there are real benefits by having an internal physical dedicated server against an housed one, also considering that we will only runs a web server to host applications driven by PHP and MySQL. So, I would like to know how much bandwidth we need to efficiently serve 50K monthly clients (which are less than 2K daily) and which hardware would fit our needs. Knowing that, assuming that we will take advantage in performance, I can check if it's convenient from a costs point of view. Any help or suggestions would be very appreciated. Thanks in advance. Regards, Claudio Alessi
Re: [dev] [OT] Setting up a dedicated server
I just trust some people here and I wanted an opinion. I know this is somewhat irritating. Sorry dear.
[dev] [dwm] Several xinitrc processes running on Ubuntu
Hi, I'm on Ubuntu 12.04 with the following session file: claudio@clabook:~$ cat /usr/share/xsessions/xinitrc.desktop [Desktop Entry] Name=xinitrc Exec=/home/claudio/.xinitrc That's what I get once I restart dwm several times (not sure if it can happen without restart at all): claudio@clabook:~$ pgrep -fl xinitrc 13958 /bin/sh /home/claudio/.xinitrc 14569 /bin/sh /home/claudio/.xinitrc 15448 /bin/sh /home/claudio/.xinitrc 18171 /bin/sh /home/claudio/.xinitrc 18696 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /home/claudio/.xinitrc 18699 /usr/bin/dbus-launch --exit-with-session /home/claudio/.xinitrc 18703 /bin/sh /home/claudio/.xinitrc So I have, among the other things, several processes which loops each 30s to update the bar. Concurrently. I can safely kill the first four process since the PID 18703 is the only one I need. But, how can prevent all this unused processes to be spawn? Thanks in advance for any help. While waiting for a reply I'll continue to Google about and RTFM. Regards, Claudio
Re: [dev] [dwm] Several xinitrc processes running on Ubuntu
2012/11/5 Raphael Proust > > How do you restart dwm? > meta-shift-q > How do you invoke it in your .xinitrc? > exec dwm > Basically, paste your .xinitrc (or a simplified version that still > exposes the behaviour you have) to get some help. (Your dwm/config.h > might be useful, depending on your setting.) > I may reproduce the problem with a vanilla config.h and an xinitrc file containing only the line "exec dwm". I hope not getting into one of Ubuntu many weird windows-like problems.
Re: [dev] [dwm] Several xinitrc processes running on Ubuntu
It seems the problem has been solved by changing the session file like this: [Desktop Entry] Name=Xsession Exec=/etc/X11/Xsession Then, since Xsession doesn't read the ~/.xinitrc but the ~/.xsession one, I had to link them: $ ln -s ~/.xinitrc ~/.xsession That's all. Thanks for the help! 2012/11/5 Raphael Proust > On Mon, Nov 5, 2012 at 9:05 AM, clamiax wrote: > > > > 2012/11/5 Raphael Proust > >> > >> How do you restart dwm? > > > > meta-shift-q > > > >> > >> How do you invoke it in your .xinitrc? > > > > exec dwm > > > >> > >> Basically, paste your .xinitrc (or a simplified version that still > >> exposes the behaviour you have) to get some help. (Your dwm/config.h > >> might be useful, depending on your setting.) > > > > I may reproduce the problem with a vanilla config.h and an xinitrc file > > containing only the line "exec dwm". > > > > I hope not getting into one of Ubuntu many weird windows-like problems. > > Either that or your dm is making something funky. I can observe the > same on this Ubuntu machine running lightdm and a similar .desktop and > .xinitrc. (Does not happen in Arch with sldm.) > > pstree(1) indicate that the old processes are abandoned by lightdm and > passed over to init. Not sure why. > > -- > __ > Raphaël Proust > >
Re: [dev] I'm back
2012/11/17 Anselm R Garbe
> 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.
Re: [dev] I'm back
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
> What's wrong with Arch?
>
>
> On Sat, Nov 17, 2012 at 1:11 PM, clamiax wrote:
>
>> 2012/11/17 Anselm R Garbe
>>
>>> 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.
>>
>
>
Re: [dev] I'm back
Why don't provide an external lib, like libdraw, which provide an interactive bar which read/write data from/to somewhere and share it between dwm, tabbed, dmenu, etc. etc.? 2012/11/25 Anselm R Garbe > On 25 November 2012 15:26, KarlOskar Rikås wrote: > > I would like the bar to stay, but I'll be fine to have the mouse support > > removed. > > As I said, the bar will stay (default), but there will be a compile > time option to not compile it in. > > Best regards, > Anselm > >
[dev] xinerama and dbe mutual exclusion
Hi, I started to use Xinerama at office. Just want to inform you, if you already don't know it, that Xinerama (panoramix) and the DBE extension are mutually excluded[0]. Thus, for those who use xinerama, st is unusable. [0] http://cgit.freedesktop.org/xorg/xserver/tree/dbe/dbe.c#n1433 Regards, Claudio
Re: [dev] xinerama and dbe mutual exclusion
Does your st is built after 2012-07-28? 2013/1/8 Carlos Torres > > Thus, for those who use xinerama, st is unusable. > > i run Xinerama (through Nvidia) and st just fine. maybe i don't have > double buffer. > >
Re: [dev] xinerama and dbe mutual exclusion
DbeExtensionInit() just returns when Xinerama is enabled. I told my xorg.conf to load dbe but while trying to run st, XdbeQueryExtension() returns false. What's the story? 2013/1/8 Carlos Torres > On Tue, Jan 8, 2013 at 11:02 AM, clamiax wrote: > > Does your st is built after 2012-07-28? > > > That seems quite a ways back, i'm on 73879c1... and was able to compile > and run. > I believe thats tip... > > --Carlos > >
Re: [dev] xinerama and dbe mutual exclusion
That's mine: http://sprunge.us/bEeM Not sure what to compare, though. For what is worth there's nothing about dbe in both. 2013/1/8 Carlos Torres > On Tue, Jan 8, 2013 at 11:16 AM, Carlos Torres > wrote: > > On Tue, Jan 8, 2013 at 11:14 AM, clamiax wrote: > >> DbeExtensionInit() just returns when Xinerama is enabled. I told my > >> xorg.conf to load dbe but while trying to run st, XdbeQueryExtension() > >> returns false. > >> > >> What's the story? > > > > right, i forgot to check whether i have dbe loaded and enabled. :p > my dpy info http://sprunge.us/CQLE > >
Re: [dev] xinerama and dbe mutual exclusion
I don't think it's bloat so much. It's all about switch two buffers. Look at this example: http://wiki.osdev.org/Double_Buffering#Example_in_C I'm a bit rusty about C coding and Xlib but if nobody implements it I'll try to play around a bit by myself. 2013/1/8 Christoph Lohmann <2...@r-36.net> > Greetings. > > On Tue, 08 Jan 2013 20:16:17 +0100 clamiax wrote: > > Hi, > > > > I started to use Xinerama at office. Just want to inform you, if you > > already don't know it, that Xinerama (panoramix) and the DBE extension > are > > mutually excluded[0]. Thus, for those who use xinerama, st is unusable. > > > > > > [0] http://cgit.freedesktop.org/xorg/xserver/tree/dbe/dbe.c#n1433 > > Is there any X11 expert here how double buffering should be done with > Xinerama then? > > St could do the copying manually, but that’s bloat, if it’s a simpler > API, which is available. > > > Sincerely, > > Christoph Lohmann > > >
Re: [dev] xinerama and dbe mutual exclusion
It works perfectly for me. Thanks! 2013/1/19 Christoph Lohmann <2...@r-36.net> > Greetings. > > On Sat, 19 Jan 2013 15:49:58 +0100 Mihail Zenkov > wrote: > > Still have same issue. If I understand right - first we draw to xw.buf > > and than copy it to xw.win. In this case should by XftDrawCreate(..., > > xw.buf, ...). > > You are right. I pushed that change. Thanks. Please report if your is‐ > sues persist. > > > Sincerely, > > Christoph Lohmann > > >
