Re: [dev] dwm: bug in fullscreen mode (SDL?)

[Matthew Carter]

You could always run fullscreen apps/games on a separate X display
using:

xinit $(which gameName) -- :8

-Matt

On Mon, Jan 23, 2012 at 02:14:40PM -0800, mikshaw wrote:
> 
> 
> - Original Message -
> > From: Roman Z. <
> > Sent: Tuesday, January 10, 2012 5:54 PM
> > Subject: Re: [dev] dwm: bug in fullscreen mode (SDL?)
> > 
> > Games work when the screen resolution of the game is the same as the
> > resolution in dwm.  If the resolution is different, all I get is a black
> > screen with the DWM statusbar at the top.  Keyboard input is still
> > passed to the game though.
> > 
> > Running "wmname LG3D" doesn't change anything about this for me.
> > 
> > Roman
> >
> 
> I've seen this happen frequently in the few games I play, and my solution has 
> been to open the game in windowed mode and switch to fullscreen inside the 
> game.  It seems to be reliable.
> 
> 

-- 
Matthew Carter
jeh...@gmail.com

Re: [dev] dwm: bug in fullscreen mode (SDL?)

[mikshaw]

- Original Message -
> From: Roman Z. <
> Sent: Tuesday, January 10, 2012 5:54 PM
> Subject: Re: [dev] dwm: bug in fullscreen mode (SDL?)
> 
> Games work when the screen resolution of the game is the same as the
> resolution in dwm.  If the resolution is different, all I get is a black
> screen with the DWM statusbar at the top.  Keyboard input is still
> passed to the game though.
> 
> Running "wmname LG3D" doesn't change anything about this for me.
> 
> Roman
>

I've seen this happen frequently in the few games I play, and my solution has 
been to open the game in windowed mode and switch to fullscreen inside the 
game.  It seems to be reliable.

Re: [dev] sbase ls patch

[Connor Lane Smith]

Hey,

On 22 December 2011 22:35, anonymous  wrote:
> Tiny cleanup patch.  Now more memory is allocated than necessary.

Thanks for the patch, I've applied it to tip. Sorry for the delay, I
didn't notice this thread. ;)

cls

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[Aurélien Aptel]

On Mon, Jan 23, 2012 at 10:59 AM, Nick  wrote:
> More generally, though, I agree, SSL is a good example of a
> security technology which is well worth the additional
> complexity.

It's funny because OpenSSL -- probably the most used implementation of
SSL -- is unreadable: http://corte.si//posts/code/reading-code.html

Re: [dev] [st] Drawing optimizations

[Aurélien Aptel]

On Sun, Jan 22, 2012 at 7:22 PM, Peter John Hartman
 wrote:
> Hi,
>
> Unfortunately, the tmux-split-pane problem still persists.  The
> tmux-split-pane problem is this: if one pane in tmux is spitting
> out a bunch of text (e.g. a sudo cat /var/log/messages or most
> compilations) you can't really switch panes or do much of anything
> at all.

I remember this and I can confirm this problem. I'm using [1] which is
pretty hardcore.

I don't where this lag comes from. Strangely enough, it's working
correctly on the xft branch...

1: $ dd if=/dev/urandom | od

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Anselm R Garbe]

Hi Michael,

On 23 January 2012 15:49, Michael Stummvoll  wrote:
> On 23.01.2012 15:40, Connor Lane Smith wrote:
>> On 23 January 2012 14:38, Nick  wrote:
>>> No no no, much simpler that debian holds that 1 line
>>> Makefile patch, and any other distributions who want to
>>> change it from setuid. Such things are very distro-specific,
>>> and besides, changing a config.mk setting in a debian patch
>>> is EXACTLY as much work as the current Makefile patch you
>>> proposed (which is fine.)
>> I agree with this. I think we should pull the C patch upstream and let
>> Debian handle the distro-specific Makefile themselves.
> yeah, you are right, that would be the best way. Thanks to all.

I would be willing to apply the slock.c patch, if you can supply diff
-u or hg diff output accordingly.

Thanks,
Anselm

[dev] [st] new xft branch (FreeType font rendering)

[Aurélien Aptel]

Hi all,

Due to popular demand and being fed up with x11 core fonts, I've made
a new branch "xft". X11 core fonts are still used in the default
branch and this new branch is just an experiment. It might be merged
back in default depending on how things go.

As of now, the code is still a bit messy but it should work.

* the font can be set in config.h (XFT_FONT) or via the -f flag.
* the fonts usable on your system can be listed with $ fc-list : family
* the font format is - or :size=
* only works with mono-spaced fonts
* if a bad font name is given, a default one is used without any
err-ing (it's just how XftFontOpenName() works) so be careful.

Re: [dev] [st] font help

[Aurélien Aptel]

On Mon, Jan 23, 2012 at 10:50 AM, Eckehard Berns  wrote:
> From your screenshot I would guess that the font pattern you specified
> isn't strict enough. St uses the maximum width of all characters in all
> fonts in the font set to calculate how wide the characters are. That's
> why you have these gaps between the different batches of chars.
>
> I usually specify at least the first four sections, the pxlsize and
> maybe the avgWidth, e.g.
>
>  --misc-fixed-medium-r-*-*-14-*-*-*-*-70-*-*
>
> You might have to specify the sWdth and adstyl also (part 5 and 6):
>
>  -misc-fixed-medium-r-normal--14-*-*-*-*-70-*-*
>
> Always leave the last two parts unspecified so that the font system can
> load the fonts for different encodings.
>
> If you don't know the font patterns for your font you can use xfontsel
> to construct them.

I think this is correct.
Also, these font-patterns are called XLFD. Google it if you need more
information.

Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply

[Bjartur Thorlacius]

On Sun, 22 Jan 2012 20:08:03 -, hiro <23h...@googlemail.com> wrote:


People used to take their steering wheels with them so that nobody
drives their car away. So I think your approach should work. Perhaps
you could take away the whole keyboard. It's very easy on my thinkpad.
Only 7 screws away from perfect security.


From now on I shall keep a steering wheel and a keyboard in my backpack.

--
-,Bjartur

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[Bjartur Thorlacius]

On Mon, 23 Jan 2012 11:04:55 -, Nick  wrote:

On Mon, Jan 23, 2012 at 11:57:42AM +0100, hiro wrote:

Security is not a feature.

I thought you were restricting yourself to Sundays.

Yes, on Sundays ;)

--
-,Bjartur

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[Bjartur Thorlacius]

On Mon, 23 Jan 2012 09:59:21 -, Nick  wrote:

They may well be examples of things that stunnel can work
fine with. Wrapper programs can be very handy alternatives
to building in alternative network functionality (e.g.
torify), though they tend to play less well with static
binaries.

You can't both statically link to a specific BSD Sockets implementation,  
and dynamically choose an implementation. Thus suckless software would use  
stdio when possible and pipe to UCSPI, optionally through whatever  
compression, encryption (e.g. tcpcrypt) or authentication (e.g. OpenPGP)  
you desire.



More generally, though, I agree, SSL is a good example of a
security technology which is well worth the additional
complexity.


Doubled. At least where encryption is needed.

--
-,Bjartur

Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply

[Roman Z.]

On Mon, Jan 23, 2012 at 12:38:04PM +0100, Roman Z. wrote:
> > dmenu_run & sleep 1; slock
> 
> The screen goes black for a moment, but then slock disappears (without
> dying) and you can use the computer again.

In general, you need to
1. run a key-grabbing program, like dmenu or most games in fullscreen mode
2. run slock without using the keyboard, i.e. over ssh or a button or whatever
and slock will fail to lock the screen.

This stuff sure got me worried, and I will definitely take my laptop
with me to the toilet from now on.

Roman

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Michael Stummvoll]

On 23.01.2012 15:40, Connor Lane Smith wrote:
> Hey,
>
> On 23 January 2012 14:38, Nick  wrote:
>> No no no, much simpler that debian holds that 1 line
>> Makefile patch, and any other distributions who want to
>> change it from setuid. Such things are very distro-specific,
>> and besides, changing a config.mk setting in a debian patch
>> is EXACTLY as much work as the current Makefile patch you
>> proposed (which is fine.)
> I agree with this. I think we should pull the C patch upstream and let
> Debian handle the distro-specific Makefile themselves.
>
> Thanks,
> cls
>
yeah, you are right, that would be the best way. Thanks to all.

Kind Regards,
Michael

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Connor Lane Smith]

Hey,

On 23 January 2012 14:38, Nick  wrote:
> No no no, much simpler that debian holds that 1 line
> Makefile patch, and any other distributions who want to
> change it from setuid. Such things are very distro-specific,
> and besides, changing a config.mk setting in a debian patch
> is EXACTLY as much work as the current Makefile patch you
> proposed (which is fine.)

I agree with this. I think we should pull the C patch upstream and let
Debian handle the distro-specific Makefile themselves.

Thanks,
cls

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Nick]

On Mon, Jan 23, 2012 at 03:35:02PM +0100, Michael Stummvoll wrote:
> than, may we could make the shadow-group configurable in the config.mk or 
> Makefile?

No no no, much simpler that debian holds that 1 line
Makefile patch, and any other distributions who want to
change it from setuid. Such things are very distro-specific,
and besides, changing a config.mk setting in a debian patch
is EXACTLY as much work as the current Makefile patch you
proposed (which is fine.)

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Michael Stummvoll]

than, may we could make the shadow-group configurable in the config.mk or 
Makefile?

Kind Regards,
Michael

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Kurt H Maier]

On Mon, Jan 23, 2012 at 03:20:44PM +0100, Michael Stummvoll wrote:
> I don't think, that checking if the tool has access to the password instead 
> of assuming this by its effective user is distribution specific.

It isn't.  Using setgid shadow is.

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Michael Stummvoll]

Hi,

I don't think, that checking if the tool has access to the password instead of 
assuming this by its effective user is distribution specific.

Kind Regards,
Michael

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Kurt H Maier]

On Mon, Jan 23, 2012 at 03:03:07PM +0100, Michael Stummvoll wrote:
> With the Makefile your object may is right. Maybe somebody finds a better 
> solution here than mine

The better solution is for distribution packagers to stop trying to push
distribution-specific garbage upstream.  If there's a "better" but more
platform-specific way to implement password checking, implement it in your
packaging.

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Michael Stummvoll]

On 23.01.2012 14:28, Kurt H Maier wrote:
> Not all distributions even have a shadow group. 
the patch in slock.c is indepedent of this group, it just checks if it can get 
the password-entry,
so it still runs on systems without shadow-group. It doesn't matter at all if 
you realize the access
with setuid root, setgid shadow or something else.

With the Makefile your object may is right. Maybe somebody finds a better 
solution here than mine

Kind Regards,
Michael

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Stephen Paul Weber]

Somebody claiming to be Kurt H Maier wrote:

On Mon, Jan 23, 2012 at 01:33:35PM +0100, Michael Stummvoll wrote:

so I patched slock to not demant root-rights, but just checks,
if the password-query commands are successfull.
I also patched the Makefile to do not setuid root but setgid shadow instead.

Not all distributions even have a shadow group.


I wouldn't take the Makefile patch, but checking if the tool has permission 
for what it wants to do, instead of checking if it ts root, seems 
preferrable to me.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

Re: [dev] [slock] patch for avoiding hardcoded root-check

[Kurt H Maier]

On Mon, Jan 23, 2012 at 01:33:35PM +0100, Michael Stummvoll wrote:
> I fresh adopted the maintaince for the suckless-tools package in debian.
> Its debian-policy to avoid setuid root binaries wherever this is possible,
> so I patched slock to not demant root-rights, but just checks,
> if the password-query commands are successfull.
> I also patched the Makefile to do not setuid root but setgid shadow instead.

Why do debian people always assume that everyone wants their shit?

Not all distributions even have a shadow group.  

Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply

[Kurt H Maier]

On Mon, Jan 23, 2012 at 12:38:04PM +0100, Roman Z. wrote:
> This is a security hole.  For example, my laptop executes slock when I
> close the lid.  If I close the lid while dmenu is running, slock will
> have no effect.

there's another security hole with slock:  if I run slock, then type my
password in, all someone has to do is hit enter and they have access to
my computer.  this is completely unacceptable, and I demand you code
around my bad habits.

[dev] [slock] patch for avoiding hardcoded root-check

[Michael Stummvoll]

Hi suckless folks,

I fresh adopted the maintaince for the suckless-tools package in debian.
Its debian-policy to avoid setuid root binaries wherever this is possible,
so I patched slock to not demant root-rights, but just checks,
if the password-query commands are successfull.
I also patched the Makefile to do not setuid root but setgid shadow instead.

I think, may the patch can go to upstream, so I send it here
Index: suckless-tools-39/slock/Makefile
===
--- suckless-tools-39.orig/slock/Makefile   2012-01-23 11:59:50.186494839 
+0100
+++ suckless-tools-39/slock/Makefile2012-01-23 11:59:54.258583809 +0100
@@ -41,7 +41,8 @@
@mkdir -p ${DESTDIR}${PREFIX}/bin
@cp -f slock ${DESTDIR}${PREFIX}/bin
@chmod 755 ${DESTDIR}${PREFIX}/bin/slock
-   @chmod u+s ${DESTDIR}${PREFIX}/bin/slock
+   @chgrp shadow ${DESTDIR}${PREFIX}/bin/slock
+   @chmod g+s ${DESTDIR}${PREFIX}/bin/slock
 
 uninstall:
@echo removing executable file from ${DESTDIR}${PREFIX}/bin
Index: suckless-tools-39/slock/slock.c
===
--- suckless-tools-39.orig/slock/slock.c2008-07-29 20:22:46.0 
+0200
+++ suckless-tools-39/slock/slock.c 2012-01-23 13:03:08.275556534 +0100
@@ -38,16 +38,17 @@
const char *rval;
struct passwd *pw;
 
-   if(geteuid() != 0)
-   die("slock: cannot retrieve password entry (make sure to suid 
slock)\n");
pw = getpwuid(getuid());
+   if(!pw)
+   die("slock: cannot retrieve password entry (may you need to 
suid or sgid slock?)\n");
endpwent();
rval =  pw->pw_passwd;
-
-#if HAVE_SHADOW_H
+#ifdef HAVE_SHADOW_H
{
struct spwd *sp;
sp = getspnam(getenv("USER"));
+   if(!sp)
+   die("slock: cannot retrieve shadow entry (may you need 
to suid or sgid slock?)\n");
endspent();
rval = sp->sp_pwdp;
}

Re: [dev] install dwm

[Roman Z.]

> Hi!
> 
> I already tired...I work in dwm on freebsd, but now I need from linux, 
> and cannot install from source dwm. My Os is Ubuntu x64 latest, I unpack 
> and 'make clean install', and nothing.
> My question, if you have or know a resource that have instruction to 
> install dwm on ubuntu I would be glad.
> 
> This is not working to me:
> 
> > sudo apt-get build-dep dwm
> > apt-get source dwm
> > sudo apt-get -b source dwm
> > sudo dpkg -i dwm*.deb
> 

Find out what packages dwm depends on.  Then append a "-dev" to all the
package names and install them.  (libx11 becomes libx11-dev, etc)

Roman

Re: [dev] install dwm

[Jakub Lach]

> Wow! It is not right answer, try again?

A reply nonetheless. 

Re: [dev] install dwm

[Nikolay G. Petrov]

23.01.2012 15:27, hiro пишет:

... --- .-. .-. -.-- --..-- /  .. /  -.-. .- -. .. - /  .--. .-
.-. ... . /  -.-- --- ..- .-. /  -- . ... ... .- --. . .-.-.-

Wow! It is not right answer, try again?

Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply

[Roman Z.]

> I don't think it's a good idea to add complexity to a suckless program
> for a _bug_ in X (that is kinda fixed already). Even xscreensaver
> doesn't want to fight X insecurities[1].

Let me throw this in:

> dmenu_run & sleep 1; slock

The screen goes black for a moment, but then slock disappears (without
dying) and you can use the computer again.

This is a security hole.  For example, my laptop executes slock when I
close the lid.  If I close the lid while dmenu is running, slock will
have no effect.

Re: [dev] install dwm

[Connor Lane Smith]

Hey,

On 23 January 2012 11:08, Nikolay G. Petrov  wrote:
> Thanks in advance for 'dwm' (very usefull), and not thanks for absent 
> instruction isntall to some famous OS ) .

We write software, we don't support distros, "famous" or otherwise.
Grab a tarball [1], and make install.

[1]: http://dl.suckless.org/dwm/dwm-6.0.tar.gz

cls

Re: [dev] install dwm

[hiro]

... --- .-. .-. -.-- --..-- /  .. /  -.-. .- -. .. - /  .--. .-
.-. ... . /  -.-- --- ..- .-. /  -- . ... ... .- --. . .-.-.-

On 23.01.2012, Nikolay G. Petrov  wrote:
> Hi!
>
> I already tired...I work in dwm on freebsd, but now I need from linux,
> and cannot install from source dwm. My Os is Ubuntu x64 latest, I unpack
> and 'make clean install', and nothing.
> My question, if you have or know a resource that have instruction to
> install dwm on ubuntu I would be glad.
>
> This is not working to me:
>
>> sudo apt-get build-dep dwm
>> apt-get source dwm
>> sudo apt-get -b source dwm
>> sudo dpkg -i dwm*.deb
>
>
>
> --
> Thanks in advance for 'dwm' (very usefull), and not thanks for absent
> instruction isntall to some famous OS ) .
>

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[hiro]

Certainly it's you who's trolling today.

[dev] install dwm

[Nikolay G. Petrov]

Hi!

I already tired...I work in dwm on freebsd, but now I need from linux, 
and cannot install from source dwm. My Os is Ubuntu x64 latest, I unpack 
and 'make clean install', and nothing.
My question, if you have or know a resource that have instruction to 
install dwm on ubuntu I would be glad.


This is not working to me:


sudo apt-get build-dep dwm
apt-get source dwm
sudo apt-get -b source dwm
sudo dpkg -i dwm*.deb




--
Thanks in advance for 'dwm' (very usefull), and not thanks for absent 
instruction isntall to some famous OS ) .

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[Nick]

On Mon, Jan 23, 2012 at 11:57:42AM +0100, hiro wrote:
> Security is not a feature.

I thought you were restricting yourself to Sundays.

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[hiro]

Security is not a feature.

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[dafusser]

2012/1/23 ilf :
>>
> I also really like sic and ii, but without extra code for SSL, I won't use
> it.
>

there is a ssl patch for ii: http://tools.suckless.org/ii/patches/ssl

i'd like one for sic too

Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[Nick]

On Mon, Jan 23, 2012 at 10:40:03AM +0100, ilf wrote:
> This got me tinking: Is there a place in the suckless philosophy for
> security? (However one wants to define that). Small code base can't
> mean "insecurity".
> 
> I for one, love suckless software, but I want "security" as a basic
> feature, too.

Small and well designed code also means auditable code,
which is a big boon for security.

Think for example about my simplyread browser addon[1]. Of
course browsers are wonderfully insecure, but addon programs
which are actually sensibly designed and readable can be
quickly checked to see they don't add to the problem. 
 
> I also really like sic and ii, but without extra code for SSL, I
> won't use it.

They may well be examples of things that stunnel can work
fine with. Wrapper programs can be very handy alternatives
to building in alternative network functionality (e.g.
torify), though they tend to play less well with static
binaries.

More generally, though, I agree, SSL is a good example of a
security technology which is well worth the additional
complexity.


Nick

1: http://njw.me.uk/software/simplyread

Re: [dev] [st] font help

[Eckehard Berns]

On Mon, Jan 23, 2012 at 04:21:20AM -0500, Christopher Lunsford wrote:
> I've also installed the terminfo for st, but the screen is still
> garbled. The default font in config.def.h works great however I cannot
> use anyother font.

>From your screenshot I would guess that the font pattern you specified
isn't strict enough. St uses the maximum width of all characters in all
fonts in the font set to calculate how wide the characters are. That's
why you have these gaps between the different batches of chars.

I usually specify at least the first four sections, the pxlsize and
maybe the avgWidth, e.g.

 --misc-fixed-medium-r-*-*-14-*-*-*-*-70-*-*

You might have to specify the sWdth and adstyl also (part 5 and 6):

 -misc-fixed-medium-r-normal--14-*-*-*-*-70-*-*

Always leave the last two parts unspecified so that the font system can
load the fonts for different encodings.

If you don't know the font patterns for your font you can use xfontsel
to construct them.

-- 
Eckehard Berns

Re: [dev] [st] font help

[Christopher Lunsford]

sorry, this appears to be something wrong with my own setup. Thank you.

[dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply

[ilf]

On 01-22 21:14, Eckehard Berns wrote:
I don't think it's a good idea to add complexity to a suckless program 
for a _bug_ in X (that is kinda fixed already).


This got me tinking: Is there a place in the suckless philosophy for 
security? (However one wants to define that). Small code base can't mean 
"insecurity".


I for one, love suckless software, but I want "security" as a basic 
feature, too.


I do want more complexity in slock to work around this (or another) 
keypad issue. And I want slock to stay on top no matter what other 
clients want.


I also really like sic and ii, but without extra code for SSL, I won't 
use it.


Has the general problem been discsussed before?

--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: Digital signature

Re: [dev] [st] font help

[Christopher Lunsford]

>> I had similar results until I compiled the st terminfo file by running:
I've also installed the terminfo for st, but the screen is still
garbled. The default font in config.def.h works great however I cannot
use anyother font.