Re: [dev] [announce] ff2sixel: view farbfeld images in terminal
On Mon, Mar 20, 2017, at 10:00, robin wrote: > If only the same honesty could be applied throughout life without bad outcome. No matter how outrageous the contribution of another party, just don't be a dick about it. We're all human. We all think something completely idiotic is a good idea at least fifty or sixty times in our life. We're here to learn and share, so offer constructive feedback.
Re: [dev] Re: looking for a simple music player
> STDIN to add files to queue: `find ~/music | sad` > Usage: > sad [-sr] [-f socket] I should also probably just let you add files to the queue by passing them as arguments, duh. So: Usage: sad [-sr] [-f socket] [FILE]... I mostly wanted the former so you can use tools like grep, sort, vipe, etc...
Re: [dev] Re: looking for a simple music player
Thanks for the suggestion of sad! I've been using mpd with bindings I added to dwm along with a libnotify/dunst background shell script on `mpc idle player`. mpd has been total overkill for what I need. I just add my media library (Vorbis) and shuffle them. I've been playing a bit with sad and I found it doesn't fully obey it's protocol spec. That's fine though. I think I'll hack it into a simpler media player perfect for others who just want a dwm controlled music DJ. I think I'm going to make this my weekend project. I'll report back here when I've something worth sharing. If you have any suggestions, feel free to share them. What I envision: STDIN to add files to queue: `find ~/music | sad` Protocol: play, next, prev OK Artist Name - Song Name pause, kill OK or ERR Plain text error message Usage: sad [-sr] [-f socket] -s Shuffle the queue before playing -r Repeat entire queue (-s shuffles between repeats) -f sockDefine a command socket other than /tmp/sad-fifo config.h: Optional libnotify support Make each codec optional (no need for Mpeg123 if you don't need MP3s, etc...) Redefine /tmp/sad-fifo
[dev] Re: st: Use after free
On Mon, Jan 23, 2017, at 02:48, Martin Kühne wrote: > I had a dream last night... Now now. No need to hold contempt on the mailing lists. Suckless isn't some Linux list where we go off on people who want to help but didn't read the entire codebase, wiki, and archive before posting. However, moosotc, it's always best to have even a basic working patch when reporting problems to OSS projects. Doubly so on ones that focus on code first, users second. :) Thank you for the patch.
Re: [dev] Request for video player recommendation with a good playlist
The simplest way I can imagine is to link them into a directory temporarily and/or permanently with: mkdir playlist ln *some_glob_pattern* playlist Then use the vidir(1) program to edit the files to number them sequentially the way you want. Then you can either create a playlist and delete the directory using some basic command line tools or just keep the directory as a playlist.
Re: [dev] mailto: and customi URIs in surf?
This has become a C discussion, so I'll toss in here. If you have a background in Python (most people who have coded before seem to), I recently stumbled upon http://www.toves.org/books/cpy/. It's light but covers enough to give you directions to study the language further. I personally would _not_ suggest learning C like many people do with other languages. Most people these days tend to just dive in and code something in a new language, using Stack Overflow or other internet search results to find code snippets that do what they want. This almost unilaterally guarantees buggy, unstable code, with many unhanded edge cases, bad practices, and type casting gotchas. It's solid and well understood languages with countless documentation and support resources; this also means not all resources are created equal. You will really need to know what the code you write is doing (and what it is not doing). "The C Programming Language" is a solid first choice at roughly 300 pages of insight. I would also suggest getting a book on secure C coding best practices. "The CERT C Secure Coding Standard" is my choice but it is a pretty hefty tomb at nearly 750 pages of engineering specifications. For an insight into why C can really mess with you, one of my favourite competitions is the underhanded C competition (http://underhanded-c.org/). This is where people intentionally write code that looks like it does one thing, even to C experts, while in reality it does something completely different. TL;DR If you spend the time to study a few good C books (not blogs or forums) cover to cover and program based on the lessons learned with minimal internet forum support, you'll do just fine.
Re: [dev] [surf] badssl.com
Thanks Quentin! Sounds like its all under control. Just wanted to bring it up in case nobody knew.
Re: [dev] [surf] badssl.com
> surf is not _silently_ ignoring them. If the validation fails, `sslfailed` > will be true and in the window title you can see a `…:U` for untrusted > instead of `…:T` for trusted. You're right. It does provide that feedback. My apologies. :) I've just been doing a bunch of digging in the TLS code under `void loadstatuschange`. I was prompted because it listed my own domain as untrusted. It turns out, if the website is cached and you visit a page at https, the page will be marked untrusted. This is because `msg` will have no certificate attached. I don't know if this behaviour is intentional. You can test this with: https://developer.gnome.org/gio/stable/gio-TLS-Overview.html Load the page, then close surf and open the page again. The first time you visit it will be trusted, the second it will be untrusted. It will load regardless of your `strictssl` setting. If it is untrusted the first time, clear your cache in `~/.surf/cache/` then repeat the experiment you should see it.
Re: [dev] [surf] badssl.com
> 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.
[dev] [surf] badssl.com
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] Just discovered dwm
> what do you guys do for wget like functionality? opt for curl? I just use curl. If you really need something small, you could use netcat: nc example.com 80 GET / HTTP/1.1 Host: example.com User-Agent: netcat
