Re: [dev] [ANNOUNCE] slock-1.4

[Ali H. Fardan]

On 2016-11-20 00:47, Markus Teich wrote:

- add proper priviledge dropping


yeah, "priviledge" dropping is nice :)

Re: [dev] [spt] 0.4 release

[Ali H. Fardan]

On 2016-11-01 17:41, Pickfire wrote:

On Tue, Nov 01, 2016 at 02:41:02PM +0300, Ali H. Fardan wrote:

On 2016-10-31 20:30, Ivan Tham wrote:

spt - simple pomodoro timer
http://git.pickfire.tk/spt, https://github.com/pickfire/spt
http://git.pickfire.tk/spt/snapshot/spt-0.4.tar.gz


why have a usage() function when all it does is run die()?


For that I just want to keep the code looks cleaner. Thanks a lot for
your suggestion, please send in a patch so that your name is in the 
log.


By patch, I mean git send-email -1.


Nah, I'm good, change it if you want it, doesn't matter to me.

---
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [dev] [spt] 0.4 release

[Ali H. Fardan]

On 2016-10-31 20:30, Ivan Tham wrote:

spt - simple pomodoro timer
http://git.pickfire.tk/spt, https://github.com/pickfire/spt
http://git.pickfire.tk/spt/snapshot/spt-0.4.tar.gz


why have a usage() function when all it does is run die()?

---
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [dev] [ st ] - 'visudo' has strange effect

[Ali H. Fardan]

On 2016-10-30 21:49, Mohammed Zohaib Ali Khan wrote:

Other terminals like rxvt run it fine

After running in st I am able to exit using the :q, so it does open
however, does not render properly.


Alright, could you please specify your OS, Window manager, compiler,
compiler version, CFLAGS used when compiling st, your config.h
(if there is anything special there), the st version you're using
(revision hash if it's from git), the value of $EDITOR and $VISUAL

---
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [dev] [ st ] - 'visudo' has strange effect

[Ali H. Fardan]

On 2016-10-30 21:02, Mohammed Zohaib Ali Khan wrote:

Hi

You can just run 'visudo' in st and check if it does the job. Easy
enough to check, isnt it?


It works well for me


For me it simply doesn't fill the terminal with the /etc/sudoers in
the editor instead it trying to fill after the current position of the
cursor as I move the cursor up or down and the screen scrolls in doing
so.


are you sure you're using the right editor? have you tried invoking
'visudo' on a different terminal emulator?

---
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [dev] [ st ] - 'visudo' has strange effect

[Ali H. Fardan]

On 2016-10-30 20:44, Mohammed Zohaib Ali Khan wrote:

Coming to the point, I am using 'st' teminal and when I used 'visudo'
command in it, it did not render properly. If you are unable to
replicate the effect, please let me know I can provide more details on
it.


Like we can assume your issue magically? please give details

---
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [dev] Collecting sins of Apple

[Ali H. Fardan]

One of the biggest failures they have, is they're unable to develop
their own OS/Software by themselves, see their source tree[0], it's
just GNU utils, BSD utils, and other stolen parts, not to mention
the bad design of their hardware and it's overprice.

On 2016-10-21 22:54, lukáš Hozda wrote:

Hello suckless folks,

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.

I share the passion for C and ingenious, simple, concise and fair
software and have been reading everything in dev and hackers mailing
lists for a few months, which inspired me to ask you, sane guys, who
seem to have a similar view on software and computers as I do, but
have much more experience and skill in the field, for some input as
well.

Do you know about some bad things Apple has done in their pursuit of
ever-increasing profits? Do you know about ways Apple is against free
and open-source software? Please let me know. Naturally, if you know
about some good deeds of Apple, I accept them as well.

In return I will include everyone who shares some information in the
sources and briefly mention the great suckless community as well.

Thanks in advance,
Lukáš

P.S: If this is indeed the wrong place to post this or it doesn't
belong here for one reason or another, I am sincerely sorry and in
that case, please ignore this post/mail.


[0]: https://opensource.apple.com/release/os-x-10116/

---
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [dev] app locations?

[Ali H. Fardan]

On 2016-10-17 19:44, a...@alexpilon.ca wrote:

Throw away your Linux-ish idea of "everything is a package",


What the heck is wrong with that?


Relax, okay, just relax.



And why argue against, if you mentioned it in the first place? I was
just pointing out an inconsistency in how it was presented, as if /bin
wasn't managed by the package manager. Geez.


if you're following the /usr/* hierarchy, then /bin is not meant to be
messed with consistently, package managers are not supposed to touch it.




and take a look at BSD systems, they provide tarballs for updating
your system,


Whole system tarballs? So we're doing stable releases or big lumbering
version changes? If so, great. I'm out of here.


No, look at OpenBSD's snapshots[0] which is basically, a rolling release
system.



which are maintain by the mainstream distribution, and are not under 
the

risk of breaking because of a silly package manager mistake.


That's not an argument. You can break things with the other methods. 
You

blaming the package manager, or are you confusing it with all the
libpng's ABI or libsfml's ABI changed and half my packages are on the
old version bullshit?


that's dynamic linking issue.




> Some of us currently use package managers that bootstrap the system
> though.

I have nothing against this, but I prefer the BSD way of doing it.


Can we just say "unpack a tarball?" [, chroot, configure]?


there is no need for the chroot...

Re: [dev] app locations?

[Ali H. Fardan]

On 2016-10-17 19:44, a...@alexpilon.ca wrote:

Throw away your Linux-ish idea of "everything is a package",


What the heck is wrong with that?


Relax, okay, just relax.



And why argue against, if you mentioned it in the first place? I was
just pointing out an inconsistency in how it was presented, as if /bin
wasn't managed by the package manager. Geez.


if you're following the /usr/* hierarchy, then /bin is not meant to be
messed with consistently, package managers are not supposed to touch it.




and take a look at BSD systems, they provide tarballs for updating
your system,


Whole system tarballs? So we're doing stable releases or big lumbering
version changes? If so, great. I'm out of here.


No, look at OpenBSD's snapshots[0] which is basically, a rolling release
system.



which are maintain by the mainstream distribution, and are not under 
the

risk of breaking because of a silly package manager mistake.


That's not an argument. You can break things with the other methods. 
You

blaming the package manager, or are you confusing it with all the
libpng's ABI or libsfml's ABI changed and half my packages are on the
old version bullshit?


that's dynamic linking issue.




> Some of us currently use package managers that bootstrap the system
> though.

I have nothing against this, but I prefer the BSD way of doing it.


Can we just say "unpack a tarball?" [, chroot, configure]?


there is no need for the chroot...

Re: [dev] app locations?

[Ali H. Fardan]

In my opinion:
/bin - for binaries that come with the system
/usr/bin - binaries installed the default package manager, which is at 
/bin
/usr/local/bin - is for binaries installed by the user without using the 
package manager

*/sbin - is nonsense

However, I still support adding everything to /bin

On 2016-10-17 18:56, Laslo Hunhold wrote:

On Mon, 17 Oct 2016 16:07:24 +0100
Dimitris Papastamos  wrote:

Hey,


everything in /bin


I agree Dimitris. Some people really do love about the benefits of
separating into /bin, /usr/bin, /usr/local/bin, /opt/bin and so on.
Let's stop this madness! There is no reason to support this ancient
concept of a separate /usr-partition. The age of tape-drives is over,
there is no need for it. And I must admit, it really makes things
complicated in a lot of respects.
I hear arguments that you put user-specific applications into /usr/bin
and general applications into /bin, however, what kind of joke is this
distinction anyway? In my opinion, we should also get rid of /sbin. We
are entering the age where we don't have "root" and "normal" users.
doas(1) gives us an impression that "normal" users can just as easily
execute sbin-binaries as long as they are allowed to in doas.conf.

Putting everything in /bin really would be a courageous, but also
logical and inspiring move. In the long term, we might even think about
defaulting to the / prefix in our makefiles rather than /usr. What do
you guys think about it?

Cheers

Laslo

Re: [dev] [surf] badssl.com

[Ali H. Fardan]

That's in the config, the user should be responsible for it.

Raiz

On 2016-10-13 00:02, Alexander Keller wrote:

I just took surf to badssl.com to test how the TLS implementation in
surf reacts. To test I took the default Arch Linux package for a ride.
It failed the test. This is because by default:
static Bool strictssl = FALSE;

Without this set to TRUE, the browser effectively does not look at the
certificate. I understand the reason for turning it off (the whole PKI,
X.509, HSTS, CSP, HPKP, and now freaking preload lists methodology 
sucks

and DANE can't come soon enough), but to me this doesn't feel like the
right way to hand invalid certificates by default (if the person 
chooses

to turn off certificate validation, power to them).

Would it not make more sense to allow the user to add the certificate's
identity to a file in ~/.surf/ much like OpenSSH does? You can show it
to them and ask if it is correct, then add it if they accept. This way
only that file and cafile need to be tested for certificate validity,
thus keeping the complexity arguably low. Setting this as the default
means users are not locked out of sites with (for example) self signed
certificates while also giving them a heads up on MITM attacks.

Re: [dev] name for ii-like chatting

[Ali H. Fardan]

I prefer to call it front-end

On 2016-09-27 15:09, Jan Klemkow wrote:

Hi,

I am programming on front-end and back-end tools for ii for several
years now.  For the back-end I use UCSPI[0] (Unix Client Server Program
Interface).  But there is no name for the front-end of tools like 
ii[1],

ratox[2], sj[3] or jj[4].  I used the term "ii-like" in my talk at the
slcon3, because ii was the first of its kind.  But, I am unhappy with
this term and looking for a better word or phrase which fits to this
kind of interface.

Do you have any ideas of a name for the ii-like front-end interface?

Thanks,
Jan

[0]: https://cr.yp.to/proto/ucspi.txt
[1]: http://tools.suckless.org/ii/
[2]: http://ratox.2f30.org/
[3]: http://github.com/younix/sj/
[4]: http://23.fi/jj/

Re: [dev] Re: I wrote a pager

[Ali H. Fardan]

On 2016-09-18 16:41, Joseph Graham wrote:

On Sun, Sep 18, 2016 at 03:34:38PM +0200, Christian Neukirchen wrote:


1 loc!

awk 'NR%22==0 { getline _ <"/dev/tty" } {print}'



You do your paging with 1 loc and yet you send email with something as
bloated as Emacs!


Actually, it isn't 1 LOC, awk is more than that ^^

Raiz

Re: [dev] Shell style guide

[Ali H. Fardan]

one more thing, multiline vs one-line statements:

if [ expr ... ]; then
...
fi

versus

if [ expr ... ]
then
...
fi

this applies to others as well:

while [ expr ... ]
do
...
done

I'd stick with the multiline style, what about you?

On 2016-09-06 21: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].

Shebang: Use #!/bin/sh and only use POSIX shell features. If you need
bash features use the proper shebang, either #!/path/to/bash or
#!/usr/bin/env bash

Extension: Do not give your script a .sh extension. An executable
script is defining a new command. Do you run ls.elf? Furthermore if
the script is later rewritten in a different language the extension is
now wrong. It is acceptable to have a script with a .sh extension in a
project as long as it is then stripped of the extension and made
executable during the build (just like a .c file would be). The
following rule already exists as a builtin inference rule in POSIX
make to do this:

.sh:
cp $< $@
chmod a+x $@

Quoting: Quote all expansions/substitutions. e.g. always use "$foo"
and never use $foo. There are an extremely small number of acceptable
reasons to break this rule, e.g. $CFLAGS (note that some parts of the
grammar do not require quotes for safe expansion such as assignment
and case $var in, we should discuss what to require in these cases)

Storing Commands: Do not store commands in strings. This is what
functions are for. Storing complex commands in strings and trying to
execute or eval them is fragile and needlessly complex.

Command Substitution: Always use "$()", never use backticks. This
makes for easier nesting and fewer surprises. Remember these should
always be quoted.

Variable Names: By convention all cap names are reserved for internal
shell variables and environment variables. If your variable is not
exported to the environment for use by a child process it should not
be all caps. Lower case variables also greatly increase readability.

Errexit: Do not use set -e. It is a legacy feature that is broken by
design and includes many corner cases and gotchas. Check the result of
each command that can fail and exit if necessary.

Checking exit status: Do not run a command and then check against $?.
This is pointless. Instead check the exit status directly withif
cmd; then or by using a boolean operator such ascmd && ...

Do not parse ls: ls is a tool to view files in a human readable
format. Most often when someone tries to use the output of ls they
really just wanted a glob anyway.

Test: Do not use parens or boolean operators inside test expressions.
They are deprecated and useless. Instead of [ "$a" = foo -a "$b" = bar
] use [ "$a" = foo ] && [ "$b" = bar ]

Echo and printf: Do not use echo if your input includes a variable or
backslash. There is no safe way to do so. Use printf and %s instead.

These cover the most common mistakes I see.

I would be happy to comb through suckless projects and submit patches
that at least fix broken/dangerous code and preferably style aspects
as well.

Please discuss,
emg

[0]http://mywiki.wooledge.org/BashGuide
[1]http://mywiki.wooledge.org/BashFAQ
[2]http://mywiki.wooledge.org/BashPitfalls

Re: [dev] [sbase] about audit

[Ali H. Fardan]

On 2016-09-01 18:34, Marc Collin wrote:

Since we're talking about sbase already in kind of meta way, I'll post
a question here instead of a new email.
sbase is basically ready, right? The few missing tools are not yet
applied, but were sent to the ML by maandree some months ago (patch,
diff and others). Should we expect a release soon? I'm excited :)


http://git.suckless.org/sbase/tree/TODO

Re: [dev] [sbase] about audit

[Ali H. Fardan]

On 2016-09-01 17:46, Marc Collin wrote:

Hey guys.

The missing brackets on paste.c that I talked about on the last
message revealed something else to me.

It was introduced in commit cdbc0d50356a0f7e0dd5755e3c46593a947cf029
by FRIGN, 2015-01-29.

Then it was marked as audited and correct in commit
1bc002b44acdbfec8d374bfd0e5a858a142c0378 also by FRIGN, 2015-03-17.

This makes me think that a file should not be audited by a person that
had many contributions to it. Because if the person missed something
at first, it's likely she will miss something again. Someone else that
thinks in different ways is more likely to find errors.

So I think files should be audited by third-parties or at least by
more than 1 person before being marked as audited. This way there are
less chances of passing a files as audited when there are still
errors.

Just to make it clear, I'm not criticizing FRIGN. This happens to
everyone. It's *much* harder to find your own bugs, but easier to find
other's bugs. That's what I think.

Best wishes.


You're right, I'll go though the code

Raiz

Re: [dev] suckless debugger?

[Ali H. Fardan]

u...@netbeisser.de wrote:
do you know of a suckless linux debugger? what is an alternative to 
ptrace?


I use throw a bunch of puts()s around the code to see when it crashes
(or misbehaves), and printf()s to print variables value while the 
program

is running, and getchar()s as a breakpoints. Hope that gives you a hint

Raiz

Re: [dev] [dwm] compile error

[Ali H. Fardan]

On 2016-08-21 19:35, Reimundo Heluani wrote:

On Aug 21, Ali H. Fardan wrote:

If you could translate the compiler error I'd appreciate it

Raiz


It's a "not such file or directory" error, it's not finding the
headers ft2build.h

R


Well, you answered it, ft2build.h header is missing, if you're on
debian, run:

# apt-get install libfreetype6-dev

otherwise, find the appropriate package for your distribution.

Raiz

Re: [dev] [dwm] compile error

[Ali H. Fardan]

If you could translate the compiler error I'd appreciate it

Raiz

On 2016-08-21 19: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$

Re: [dev] s - suckless shell

[Ali H. Fardan]

On 2016-08-13 03:28, hiro wrote:

there already is a suckless shell, called rc. stupid you.


A new shell will have it's own use cases and might be a
perfect fit for  certain projects, some cases might not
require shell  scripting  so  the interpreter  part  is
unneeded.

Raiz

Re: [dev] st lack of scrollback

[Ali H. Fardan]

On 2016-08-11 20:32, Britton Kerin wrote:

I realize it's a non-goal

I realize there are patches that sort of work (still jumps to bottom
on output unfortunately)

It should be a goal because it's generally desirable and the
alternative mentioned on the web page isn't.

I use st because it let me control fonts precisely on new high-res
monitor.  I couldn't easily tell how to hack gnome-terminal to do that
or I would still use it.

Britton


treat it the way you treat nonscrolling terminals, less(1)

Raiz