Re: [dev] [surf] unveil
Please send your port/patch. Maybe I will try it. On Sat, May 4, 2019, at 12:04, Thuban wrote: > Hi, > Is there any OpenBSD user who have already unveiled surf? > > I'm trying to, but I keep having an error about "Can't open display". > -- > thuban > >
Re: [dev] Open Source DIY ethics
I find the article and the subsequent comments from Jan and Sylvain to be very accurate. They have led me to remark that "do-it-yourself" describes my software interests better than "open source" or "free software" does. I am mostly interested in software that works as I want it to. Consequently, I pretty much require that the software be freely licensed, that the source code be short, and that the software be developed by volunteers. The terms "free software" and "open source" describe only the first of these points; they may suggest DIY, as they originate from hacker groups, but they technically only describe particular legal mechanisms that happen to be useful in the context of DIY software. Furthermore, elegant software is often easy to reverse-engineer based on the documentation and interface, so the free licensing of the source code is not necessarily important. I imagine that "DIY" will lose meaning as companies market proprietary products (perhaps internet of things) as DIY, but, for the moment, I think "DIY" suggests that people are encouraged to learn, run, and modify the software to suit their own wishes.
Re: [dev] securiy guidance
Dashamir corrected some errors in my prior message. I have forwarded his corrections, as he is not on this mailing list. --- Forwarded Message Date:Tue, 06 Mar 2018 03:53:31 +0100 From:Dashamir Hoxha <dashoho...@gmail.com> To: Thomas Levine <_...@thomaslevine.com> cc: dev mail list <dev@suckless.org>, pet...@riseup.net Subject: Re: [dev] securiy guidance Maybe this is off-topic, but I have to make a few corrections. On Tue, Mar 6, 2018 at 12:57 AM, Thomas Levine <_...@thomaslevine.com> wrote: > > It still uses gpg, but it forces a particular simplified style of usage > that should be very easy for many people to learn: Only gpg symmetric > encryption is allowed, so you do not need to understand the concept of > asymmetric cryptography; a > It defaults to symmetric encryption, but you can use asymmetric encryption as well, and switch back and forth between them (but only one of them is allowed). The last three examples at the end of the man page show this. The commands are `pw set-passphrase` to switch to symmetric encryption or to change the existing passphrase, and `pw set-keys [key...]` to switch to asymmetric encryption or to change the keys of the people that are allowed to access it. > also, it includes in a shell that remembers the decryption password, so > you can have it remember your password > without relying on gpg-agent being properly installed, and you can > easily have it forget your password without understanding that gpg-agent > exists. > The password is remembered only when you use the shell and when you use the symmetric encryption (the default case). When you use asymmetric encryption the gpg-agent does its job the normal way (if installed properly) and no passphrase is remembered by the script. > This is technically still gpg, but the encryption software could > easily be replaced by something else, like encrypted zip files, the user > doesn't need to know that it is gpg. > In the case of using asymmetric encryption the user does need to know that this is gpg, otherwise may not be able to use it properly. For example if you encrypt it with three public keys, then only the people that have the corresponding private keys can decrypt it (for example suppose that there are 3 sysadmins that need to share the data between themselves, without having to exchange any passphrase between each-other). --- End of Forwarded Message
Re: [dev] securiy guidance
If you copy (vendor) an encryption/decryption algorithm into your source code, then you are relying on more than libc. So perhaps you could expand your dependencies to libraries with acceptable licensing or to libraries that are widely available. For example, OpenBSD 6.2 provides blowfish. Also, GnuPG libgcrypt is far more involved than you require, but it is still appropriately licensed. I can't help myself from adding to the distracting tangents. pw by Dashamir Hoxha has some of the features of present discussion. http://dashohoxha.fs.al/pw/man/ It is derived from password-store. It stores passwords in an encrypted tarball instead of inside the normal filesystem. Like pass-tomb, this has the effect that file hierarchy doesn't show up in the filesystem. It still uses gpg, but it forces a particular simplified style of usage that should be very easy for many people to learn: Only gpg symmetric encryption is allowed, so you do not need to understand the concept of asymmetric cryptography; also, it includes in a shell that remembers the decryption password, so you can have it remember your password without relying on gpg-agent being properly installed, and you can easily have it forget your password without understanding that gpg-agent exists. This is technically still gpg, but the encryption software could easily be replaced by something else, like encrypted zip files, the user doesn't need to know that it is gpg. Another alternative is to rely on filesystem encryption. For example, you could use tomb without password-store. I once used used normal, cleartext files in an encrypted vnd device (You could use tomb for that as well.) that I mounted and umounted. The point is that you wouldn't need gpg. You might write some utilities that mount and umount the device and ensure correct permissions.
Re: [dev] Writing subtitles for videos
WebVTT format is more complex than I would like and also not fully implemented on any browsers, as far as I can tell, so I use a small subset that is very simple. The following section is most of the parsing of my bespoke formats for timings and texts. It references lots of other functions in the library of interest that all do very little, so it might be very tedious to read. The parsing of these files is simple enough that I did not give it its own function; this passage is complex because it also handles build dependencies, user interface concerns, and concatenation of subtitles. https://thomaslevine.com/scm/langrompiloj/artifact?ln=72-102=a370f5205509f123 In summary of the above, I combine a timing file and a named-for-a-language text file, and I come up with a sequence of Subtitle objects, where a Subtitle contains a language, a list of times, and a list of strings. I implemented two different WebVTT formats that dump the Subtitle sequence. I wanted to use the webvtt_karaoke, but I couldn't find any browsers that supported the karaoke feature, so I am using webvtt_replace. https://thomaslevine.com/scm/langrompiloj/artifact?ln=6-31=42a903bd25efb0b0 Fortunately, the input format and data structure are simple enough that you can probably ignore everything I discuss above. In my prior email I referenced this timings file https://thomaslevine.com/scm/langrompiloj/artifact/49ddb891f1f0b6fd and these two text files. https://thomaslevine.com/scm/langrompiloj/artifact/f01066b80ae8fe3b https://thomaslevine.com/scm/langrompiloj/artifact/cf93e6b1b7967053 Using the files and the corresponding video as inputs, I arrive at the these WebVTT files as outputs. https://thomaslevine.com/!/langrompiloj/blaukraut/blaukraut_de.vtt https://thomaslevine.com/!/langrompiloj/blaukraut/blaukraut_en.vtt Markus Teich writes: > Heyho Thomas, > > I did not look up the format, so it might be trivial, but do you mind shari > ng > your tooling for the WebVTT translation as well? > > --Markus
Re: [dev] Writing subtitles for videos
I settled on the following mpv configuration. https://thomaslevine.com/scm/langrompiloj/artifact/6a086022d93af1a1 https://thomaslevine.com/scm/langrompiloj/artifact/161b62d352fec4f7 This produces a file like the one below, which I edit until the subtitles are acceptably timed. Each line marks the beginning of the next cue and the end of the previous cue. https://thomaslevine.com/scm/langrompiloj/artifact/49ddb891f1f0b6fd Texts for the subtitles are stored in other files, one file per language. These files have one line per cue, so they have one fewer line than the corresponding timings file. https://thomaslevine.com/scm/langrompiloj/artifact/f01066b80ae8fe3b https://thomaslevine.com/scm/langrompiloj/artifact/cf93e6b1b7967053 I then produce a WebVTT file for each combination of a timing file and language. Thank you for everyone's input Hadrien Lacour writes: > It may be possible to do this with mpv and lua scripts.
Re: [dev] Writing subtitles for videos
As Felix pointed out (and I had not previously realized), the subtitles depend mostly on the audio, and the video can largely be ignored. I thus think it has relatively little to do with blind. I had looked at mpv and came upon the annoyingly close but still unhelpful watch-later feature. I considered whether it was possible to implementing my proposal with just edits to input.conf and whether it was worth using libmpv, but had not considered lua scripts. A Lua script indeed looks promising. https://gist.github.com/Hakkin/5489e511bd6c8068a0fc09304c9c5a82 https://github.com/thebombzen/scripts/blob/master/src/markchapter.lua It still seems a bit messy, (Perhaps a scripting language could be avoided entirely if the mpv configuration were written in C.) but this will probably satisfy me for now.
[dev] Writing subtitles for videos
I want to write some subtitles for some videos. I found several subtitle editors through web searches, and their documentation doesn't make them look very good. What's more, I haven't managed to install any of them properly, which is both inconvenient and further indicative of suck. I think that most of what I want could be accomplished by having a video player that writes the current time somewhere (like a file) when I press a particular key. I would play the video until I get to the position where I want to start or stop a subtitle, then I would press the key, and then I would copy that time to the subtitles file. Another helpful feature would be to reload the subtitles file without changing the current time; this way I could review the subtitles more quickly. Do any video players already do this? Or, does anyone have other recommendations about the editing of subtitles?
[dev] Linking a directory tree of configuration files
Having trouble installing rcm on some computers, I came up with the following alternative a couple weeks ago. I have been pleased. https://thomaslevine.com/scm/lntree/ https://thomaslevine.com/scm/lntree/uv/lntree-0.1.tar.gz Here is an example of where I have used it to compose configurations. https://thomaslevine.com/scm/os/artifact?ln=17..25=fb261310832d4eb6 Does something else like this exist? I could do without some of the features; for example, it would be acceptable to have something like cp -R that differed only in that it made hard links instead of copies. Also, while I do like how this is working, I suspect that it could be resolved more cleanly by designing the filesystem better. Consider, for example, the following rules. * All configuration files are stored in only a couple places so that they are easy to find and commit to version control. * There are separate directories for private and public files so that they can easily be put in separate version control repositories. * Directories containing configuration files do not contain any garbage, such as caches, examples, nor big files. This way, you could put the configuration locations directly into version control, without creating so many links. I am not pleased with these rules, but they should give you an idea of what I am thinking.
Re: [dev] announcing edit-pipe
I suppose I could have just logged in to my HP-UX computer to confirm.
So now I do that. It indeed has an incompatible version of mktemp that
happens to be even worse than the option that I proposed; here is the
relevant section of the man page.
The name generated by mktemp is the concatenation of a directory name,
a slash (/), the value of the LOGNAME environment variable truncated
to {NAME_MAX} - 6 characters, and the process ID of the invoking
process.
But this is from version 11.11, so I suppose it would be acceptable
not to care about it.
Re: [dev] announcing edit-pipe
> > * mktemp is not portable; you could use something like the date and > > process identifier ($$) to create a portable temporary file. > > (I am actually still curious as to whether there is a reasonable > > portable approach that is less sloppy than this.) > > I'm not sure the best way to do that or if it's worth the extra > complication. It is unfortunate that POSIX doesn't have mktemp or a > command to do the same thing. However, mktemp seems to be very widely > available. It is in GNU coreutils (i.e. Gnu/Linux), OpenBSD, NetBSD, > FreeBSD, Mac OS X, HP-UX, Tru64 Unix. While mktemp is very widely available, I came across systems where it was not, and I came across others where it behaved incompatibly. I think HP-UX was one of the problematic operating systems. I may have made notes on this in the urchin issue tracker and commit history, but I don't remember. http://thomaslevine.com/scm/urchin > > * Quote "$edit" in case the editor has a space in its name. > > I deliberately do not quote $edit so that I can set EDITOR to nano -w. > Is that non-standard/wacky? Is there a convention for whether the the > value of EDITOR environment variable should be able to have options? Dunno about the convention. Please report if you come up with an answer, as I am curious. Here are some ideas of how to handle this. They're in decreasing order of my preference, but the first one is the only one that I think is good. * Quote the variable, set EDITOR equal to "nano-w", and implement "nano-w" as a program that calls "nano -w". * Handle EDITOR and VISUAL one way, and handle two alternative non-standard variables the other way. * Call "eval $EDITOR", so that it is at least possible to specify paths with spaces by quoting the path. * Add a flag that affects how spaces are handled. > > * You haven't handled editor errors. > > I'm not sure the best way to do that or if it's worth the extra > complication. I present one approach in the attachment. It is based on commit 08d2db088dad2f35ce91523eb35b6456dd189031. diff --git i/edit-pipe w/edit-pipe index 3ceff5f..b0b9351 100755 --- i/edit-pipe +++ w/edit-pipe @@ -24,5 +24,8 @@ fi cat > "$tf" $edit "$tf" < /dev/tty > /dev/tty +code=$? +test 0 -lt $code || test "-v" = "$1" || cat "$tf" rm "$tf" +exit $code
Re: [dev] announcing edit-pipe
I had not been aware of vipe; thank you for sending this! Removing the perl dependency is worthwhile, even if it does not reduce RAM usage. (And I don't know what affects the RAM usage in this case.) Regarding the portability of your version, * mktemp is not portable; you could use something like the date and process identifier ($$) to create a portable temporary file. (I am actually still curious as to whether there is a reasonable portable approach that is less sloppy than this.) * I don't have /usr/bin/editor; how about you fall back to $(/usr/bin/env which ed)? Even better, just use /usr/bin/env ed directly rather than assigning its path as a string. * Print errors to stderr (>&2). * Quote "$edit" in case the editor has a space in its name. * You haven't handled editor errors. * vipe still is better because it has a man page. Note that I didn't actually try running it nor comparing it to vipe; I'm mostly just read the file you linked, and I didn't even looked very much at vipe.
Re: [dev] st, spurious character in paste?
And even if that isn't the issue, I think find your process to be faster if you bind a key in vim to "xclip -o". On Wed, Aug 23, 2017, at 06:04, David Phillips wrote: > Sounds to me like you are accidentally rolling your scroll wheel. > > Thanks > David >
Re: [dev] Cataloging of contacts
I wound up with this. https://pypi.python.org/pypi/bguo Each contact is a single file, like this one, http://src.thomaslevine.com/bguo/artifact/f24d0f9bdbf3f76e and they must all be in the same directory, like this one. http://src.thomaslevine.com/bguo/dir?ci=tip=example/orig.bguo This is the main command that I personally use. bguo export directory-with-my-bguo-contacts mh > ~/.aliases It is implemented in Python because that's the only language I know well enough. The file format is close to RFC 2822 because there's a standard Python library for that. vCard and ppl have some interesting fields, like birthday. Maybe I'll add them if I find some place I want to export them to. Here is my original inquiry from 09 Nov 2016, in case people do not recall the thread. > I want to keep track of some information about people, and I have an > idea of what I want the user interface to be like. Perhaps is there > already something close to what I want? > > I want to record the following information about each contact. > > * Name > * Phone number > * Email address > * Postal address > > I want each contact to have its own file. I will put all of the > contacts' files in a directory tree. I can look up contacts by filename > or with a search. (grep will probably be fine.) The software would do > the following. > > * Check that I have formatted the contacts' files properly. > * Convert into formats for other programs (my email client, notably) > > If I don't get any other ideas, I will probably write something that > uses vCard as the format. vCard is nice because search engines (like > recoll) will likely recognize it. The main thing I'm wondering is > whether there is a nicer format that vCard. Belated happy solstice
[dev] Cataloging of contacts
I want to keep track of some information about people, and I have an idea of what I want the user interface to be like. Perhaps is there already something close to what I want? I want to record the following information about each contact. * Name * Phone number * Email address * Postal address I want each contact to have its own file. I will put all of the contacts' files in a directory tree. I can look up contacts by filename or with a search. (grep will probably be fine.) The software would do the following. * Check that I have formatted the contacts' files properly. * Convert into formats for other programs (my email client, notably) If I don't get any other ideas, I will probably write something that uses vCard as the format. vCard is nice because search engines (like recoll) will likely recognize it. The main thing I'm wondering is whether there is a nicer format that vCard.
[dev] [ii] Reconnect
I start ii and chat for a while. Then I lose my internet connection for a few hours. What is a good way to have ii automatically connect when I get my internet connection back? I guess I have determine whether ii has disconnected and whether I now have an internet connection. I don't know how to determine whether ii has disconnected. Thanks
[dev] Simple shell with completion
For my login shell, I want a sh-compatible shell with the ability to
specify complex completions. As far as I can tell, ksh only supports
completions by command and filename. I want to do things like this,
in tcsh.
complete {folder,refile,scan,show,next,prev} \
'C@+*@`folders -fast -recurse | sed -e s/^/+/`@'
In the context of certain MH commands, this completes words that start
with "+" with my email folders.
Is there a variant of ksh that allows this level of detail in the
configuration of completions?
If not, I think I want to write a thing that does tab completion and
forwards input and output to a ksh subprocess. Does something like this
exist already?
Or I guess I could try zsh or bash
Thanks
Tom
Re: [dev] containers opinion
My personal view is that separate users are enough software separation for everything that I have ever wanted to do. Dunno about the party line though. On Fri, Sep 23, 2016, at 05:19 PM, stephen Turner wrote: > whats the suckless view of containers and why? what about a > containerized init helper where sinit calls the container program and > then runs daemons and the rest of the system from containers? Do you > feel containers offer additional security/stability? > > Just thinking about "cloud" stuff again and daydreaming about servers. > > I suppose with a system as small as suckless offers it might be a moot > point by the time you fire up several VM instances. VM's would add a > semi redundancy in the event of a single failure in that it wouldn't > take down the other services but then you have other issues if the > system fails anyways right?! > > just random thoughts. > > thanks, > stephen >
Re: [dev] Shell style guide
#!/usr/bin/env bash is necessary if you are using bash. But don't use bash. Here are some useful references on sh. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/contents.html http://blackskyresearch.net/shelltables.txt http://blackskyresearch.net/try.sh.txt Adherence to standards and legibility can be problematic if you care about portability to sucky systems and shells. For example, `...` is more widely supported than $(...). But in the case of stali, I suggest that non-suck should take priority over portability. Many portability issues come about from slight differences in utilities on different operating systems. Here are some notes on utilities that I have had issues with. http://src.thomaslevine.com/urchin/info/023e8abd7758b6c1b92e5dcfbcf620a2e48b6989?txt=1=532-600
[dev] Testing suckless programs
Hi, I originally came across suckless about six years ago when I was looking at IRC clients and thus discovered ii. Since then I have periodically updated myself on suckless happenings and have always held the software in high regard. But I had never thought to contribute anything because I have pretty much never written C. I have been thinking about how I might contribute without learning a lot of C, and writing automated tests seems like a good thing. Many of the tools could be tested in sh instead, and this might even be preferable in some cases. And I probably can write decent tests in C without being particularly good at C because the test cases can be relatively straightforward. Also, the intended behaviors of suckless programs are usually obvious because they are so simple and well documented, so I think I understand them well enough to write appropriate tests. 1. Tell me if you would like to see tests for any particular project that you work on, and I might eventually write them. 2. Have you previously considered having someone who knows very little C write tests for suckless programs? Tom Postscript: I might also not write tests for any particular project. Because suckless programs are so simple in both implementation and interface, I suspect that maintaining a test suite would often provide little benefit compared to informal documentation that discusses the intended behavior of the program and mentions edge cases; I suspect that a program would need to meet at least one of the following criteria in order for automated testing to be very helpful. 1. The user interface is complex. 2. Supporting different environments is a large concern. 3. People have managed to break already-documented things by accident in patches. I even have my doubts that testing would be that helpful here, though, because of what I see in sbase. I consider sbase to have a relatively complex user interface, but it is quite developed and lacks automated tests; it has apparently done fine without automated tests.
