Re: [dev] Screencasts?
Kai Hendry said: Videos should be easier to store (if they are self-contained), create and consume. Videos are harder to store (they are a lot larger then every other type of content), to create (video codecs are very bad at encoding text) and - the hardest part - to consume (you need to either memorize the whole process or enter infinite play - skip backwards - pause cycle to follow instructions). It only pays of for very UI-heavy software with tricky interaction and low discoverability of UI elements, but even then screenshots normally do better. Effectively the only good cases for screencasts I've seen to date are video games and Metro UI. Anyway, there is room for both mediums. Suckless software workflow is much easier to describe in plain text. If there is any room for screencasting, it definitely isn't here. -- Dmitrij D. Czarkoff
Re: [dev] Screencasts?
On Mon, Mar 10, 2014 at 6:33 AM, Christoph Lohmann 2...@r-36.net wrote: Stop spreading this screencast crap. Use some expressive language, maybe a screenshot and _text_ to describe what you are doing. This is easier to read, can be easier stored, searched / grepped, trans‐ lated, changed, extended and added to the suckless wiki. Agreed. Screencasts are not suckless.
Re: [dev] Screencasts?
On Sun 09 Mar 2014 at 12:54:11 PDT Caleb Malchik wrote: I switched to Linux/cli/dwm from OS X just a few years ago, and since the switch I feel the way I do certain basic things is embarrassingly inefficient. For example, if I find an article on the web I want to come back to, I will copy the URL from the address bar, open a terminal window with ctl-shift-enter, type 'vi doc/toread', then paste the URL at the top of the file. Yes it's still faster than what I would have done on OS X, but it feels clunky. I know enough to come up with my own fixes for a lot of these inefficiencies, but I wouldn't be confident that such fixes are sensible, and that there isn't a simpler and functionally better solution. And the amount of documentation I would have to read to be confident that my own solutions are sensible seems overwhelming. I'm not going to go down the screencast rathole. Instead, I'll simply point out that the steps you described are scriptable. Find out how to get the current url from your browser in a script. Also how to add a line to the beginning of a file (adding it to the end is easier.) If your browser doesn't support a custom hotkey you can use to invoke your script, create one at the system level. The latter choice will probably require you to find a way to identify and query the running instance of the browser. If your browser doesn't support any of this, or if it makes it too difficult, you might want to count that as a reason to drop it in favor of one that is more tractable. (Try surf, or uzbl!) That's probably the best way to evaluate software: does it allow you to quickly knock together solutions to accomplish custom tasks like this? The Unix philosophy is that the software which best supports this kind of ad hoc programming is software that is simple: designed to do one thing and do it well. But it's also software that is *composable*. If you seek out and use software that reflects this philosophy, you'll get the kind of efficiency you want almost automagically. But beware the siren song of ultimate efficiency! The Unix approach isn't about achieving perfection, it's about getting the job done. And that means good enough is usually good enough. Pay attention when things seem too slow or, in your words, feel too clunky. That's telling you there's a rough edge you need to smooth down. But once it's fixed and no longer bothering you, there's really no need to go on fussing over it. The idea that someone else might have found a more 'sensible' or more elegant solution should only concern you if what you've put together on your own still doesn't feel right.
Re: [dev] Screencasts?
On Mon 10 Mar 2014 at 09:29:16 PDT Charlie Kester wrote: Pay attention when things seem too slow or, in your words, feel too clunky. That's telling you there's a rough edge you need to smooth down. But once it's fixed and no longer bothering you, there's really no need to go on fussing over it. Unless, of course, you're a dedicated knob-polisher like the rest of us. ;)
Re: [dev] Screencasts?
Pay attention when things seem too slow or, in your words, feel too clunky. That's telling you there's a rough edge you need to smooth down. But once it's fixed and no longer bothering you, there's really no need to go on fussing over it. I'll echo that, but suggest that maybe what you are looking for in that particular scenario is bookmarks.
[dev] Shell vs C where is the border?
Hi, I was recetly wondering about the use cases of C and shell. I've seen that this topic appears several times mostly when discussing sbase. Some of you probably knows ffmpeg, software that allows to convert media files between various formats. Imagine now that we have several smaller tools that do one thing and do it well and to convert mkv wideo do webm we do: videostream movie.mkv | theoradec | v8enc video audiostream movie.mkv audio createwebmvideo video audio But having so many individual programs is more harder to use that just one (we need to run more commands), so reasonable would be to combine all this commands to one script which would do all this work automaticaly. So what solution would be better in your opinion? When we should use shell scripts and when write new C programs to achieve our goals? BR, Szymon
Re: [dev] Shell vs C where is the border?
On Mon, Mar 10, 2014 at 12:39 PM, Szymon Olewniczak szymon.olewnic...@rid.pl wrote: So what solution would be better in your opinion? When we should use shell scripts and when write new C programs to achieve our goals? When it makes sense.
Re: [dev] Shell vs C where is the border?
On Mon, 10 Mar 2014 20:39:08 +0100
Szymon Olewniczak szymon.olewnic...@rid.pl wrote:
But having so many individual programs is more harder to use that just
one (we need to run more commands), so reasonable would be to combine
all this commands to one script which would do all this work
automaticaly. So what solution would be better in your opinion? When
we should use shell scripts and when write new C programs to achieve
our goals?
My mail probably will be bounced, but anyway.
It (pipes or lack of them) can be abused either way. Example of way too
many command line flags (GNU ls):
$ ls --help | awk '/^ {2,6}-/{i++} END{print i}'
58
Yet you won't likely use more than a dozen options offered by ls ever
(and fewest on daily basis). Those rare cases, when you need something
specialized could be solved by sed/awk and other filters. Still they
somehow managed to squeeze all those flags there - someone really hates
pipes.
Counter example would be man(1) command (this is personal opinion).
Some implementation are doing something similar to that:
$ zcat some-manpage.1.gz | eqn | grap | pic | tbl | vgrind | refer \
| troff | more
This is running every time when you type man some-manpage. Filter
approach of *roff made sense, when it was used for creating documents
for printing (and it was often most CPU intensive command on the box
according to some accounts).
--
Paul Onyschuk
Re: [dev] Reasonable Makefiles
Quoth Nick: Basically because I'm replacing a autotools horrorshow with plain make, but am not sure what the nicest way of allowing compile- time feature disabling is. Can 'ifdef' be relied upon, and does it tend to produce unreadable and buggy makefiles in anyone's experience? Are there other options, beyond asking people to comment out certain lines in a config.mk, to e.g. disable some LDFLAGS? So I changed my goal slightly to just do basic build variable adjustments based on the system. I ended up creating a bourne script called config.uname, which sets a few sensible defaults for weird systems (like OSX solaris), and appends them to the config.mk, on first compilation. So that they can still be changed by editing config.mk if you want, and they're not hidden away in some 'ifeq' using included Makefile. So the Makefile has this: all: autoconfig $(BIN) autoconfig: sh config.uname config.mk touch $@ and config.uname is a shell script along these lines: #!/bin/sh os=`uname` case $os in Darwin ) echo 'Configuring for Darwin' 2 echo '# Extra configuration for Darwin (from config.uname)' echo 'EXTRA_CPPFLAGS = -I/opt/local/include' ;; esac It seems to me like a pretty reasonable and usable way of doing some basic autoconfiguration for different systems. Comments, anyone? Nick
Re: [dev] Reasonable Makefiles
So the Makefile has this: all: autoconfig $(BIN) autoconfig: sh config.uname config.mk touch $@ and config.uname is a shell script along these lines: #!/bin/sh os=`uname` case $os in Darwin ) echo 'Configuring for Darwin' 2 echo '# Extra configuration for Darwin (from config.uname)' echo 'EXTRA_CPPFLAGS = -I/opt/local/include' ;; esac It is similar to the configure of utmp, and usually it is the only thing you need. Regards, -- Roberto E. Vargas Caballero
