Re: [dev] [ANNOUNCE] slock-1.4
On 2016-11-20 00:47, Markus Teich wrote: - add proper priviledge dropping yeah, "priviledge" dropping is nice :)
Re: [dev] [spt] 0.4 release
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
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
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
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
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
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?
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?
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?
On 2016-10-17 19:19, a...@alexpilon.ca wrote: On Mon, Oct 17, 2016 at 07:03:59PM +0300, Ali H. Fardan wrote: /bin - for binaries that come with the system So they never get maintained with a package manager? Sounds like a really weird way of doing things. If you bootstrap with a tarball, the distinction becomes meaningless once you've updated packages with a package manager. Throw away your Linux-ish idea of "everything is a package", and take a look at BSD systems, they provide tarballs for updating your system, which are maintain by the mainstream distribution, and are not under the risk of breaking because of a silly package manager mistake. 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. /usr/local/bin - is for binaries installed by the user without using the package manager So /local/bin now? Yes, if you got rid of /usr */sbin - is nonsense Details? Do you mean because it should be root:root 700, but everybody has it in their $PATH anyway? Or do you mean because permissions on the binaries themselves is good enough? Or because protections on the resources accessed by the binaries is good enough? Or because you just don't like splitting things into four? because of the last reason, splitting binaries to /sbin adds complexity, which is unnecessary
Re: [dev] app locations?
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
On 2016-10-13 15:42, Alexander Keller wrote: That's in the config, the user should be responsible for it. True, it is in the config. It's also the default. If the alternative is too much, perhaps changing strictssl = FALSE \* Refuse untrusted SSL connections *\ to strictssl = FALSE \* Validate SSL certificates from server *\ would help better inform what it does. My initial understanding when I used surf was that this would simply deny me the option of bypassing SSL errors. Not silently ignore them. I agree, it's confusing, send a patch to hackers@, they might apply it.
Re: [dev] [surf] badssl.com
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
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
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
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
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
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?
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
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
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
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
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