Re: [dev] [ANN] CGD - Ultra-minimalist HTTP and FastCGI wrapper for CGI programs.
On Thu, Sep 20, 2012 at 9:50 PM, Džen wrote: > What's the reason behind using nginx anyway? I guess it would be simpler to > write an own http web server with go's http lib. Or am I wrong? CGD can act as an HTTP server, but wont handle static files, it will pass all requests to a single CGI script. Why people use nginx? Well, same reason people use any web server: the alternatives also suck and you have to pick one. I have some plans for a full standalone web server (that can handle both static and dynamic content) in Go, the libraries are all already there, but there are some issues like how to best handle configuration. Uriel > > > On Wed, Sep 19, 2012 at 5:41 AM, Uriel wrote: >> >> CGD runs as a FastCGI wrapper (to be used with nginx or similar web >> server) or as a standalone HTTP server, handing over all requests to a >> given CGI script. >> >> http://repo.cat-v.org/cgd/ >> >> >> This is useful to run werc under nginx, or directly without a >> standalone web server. >> >> CGD is extremely simple, under 50 lines of Go code, much simpler than >> fcgiwrap, and has been tested in production by several members of >> #cat-v. >> >> >> Instructions on how to use CGD to host werc with nginx: >> >> http://werc.cat-v.org/docs/web-server-setup/nginx >> >> >> Feedback and patches welcome, as an experiment the CGD repo is hosted >> with github: >> >> https://github.com/uriel/cgd >> >> >> Enjoy >> >> Uriel >> >
Re: [dev] [ANN] CGD - Ultra-minimalist HTTP and FastCGI wrapper for CGI programs.
On Wed, Sep 19, 2012 at 5:06 PM, Andreas Krennmair wrote: > * Stephen Paul Weber [2012-09-19 17:00]: > >>> Still, forking is never the bottleneck >> >> >> Never? Isn't forking-as-bottleneck most of the reason alternatives to CGI >> exist? > > > One of the bottlenecks of CGI is that the popular "web scripting" languages > (i.e. PHP, Perl, Python, Ruby) make it horribly inefficient. Every request > doesn't only mean a fork, but also completely loading the application's > source code including all dependencies. I once measured this (because the > web hosting platform that I work on uses CGI + suexec to separate web > scripts of different users on the same host), and every single request to a > WordPress makes the PHP interpreter load more than 1 MB of PHP source. > MediaWiki is even worse: I measured about 4 MB. > > For lightweight web apps, consisting of only a single binary or a single > script that is loaded quickly, this obviously isn't a problem. Exactly. For werc, which does hundreds of forks per request (and that is written in interpreted languages: rc, awk, sed), I measured that when using the markdown.pl Perl script for formatting, starting up perl took considerably longer than all the forks and executions of rc/awk/sed code. The real problem is how much popular scripting languages like Php, Perl, Python, etc, suck. And I wont mention Ruby because Ruby performance a joke nobody could ever take seriously: http://harmful.cat-v.org/software/ruby/ All that said, fork performance for statically linked binaries is really good on Linux, other platforms and dynamically loaded binaries are more problematic, but nowher near as much as others make it. (This reminds me, most such scripting languages are dynamically linked and load tons of dynamic modules at run time, more stupid overhead) Uriel > Regards, > Andreas >
Re: [dev] [ANN] CGD - Ultra-minimalist HTTP and FastCGI wrapper for CGI programs.
On Wed, Sep 19, 2012 at 4:10 PM, Stephen Paul Weber wrote: > Somebody claiming to be Uriel wrote: >> >> CGD runs as a FastCGI wrapper (to be used with nginx or similar web >> server) or as a standalone HTTP server, handing over all requests to a >> given CGI script. > > > Is this just a wrapper for compatability (which seems odd, since most > servers also speak CGI), or does it do prefork stuff to improve performance? Sadly not all servers speak CGI this days, most notably nginx, and others often have broken CGI support. Also CGD can act as a extremely minimal HTTP server itself to directly host "stand-alone" CGI scripts without a 'real' web server. The server itself uses goroutines which are very efficient, so has no need to pre-fork, the called CGI script can't be 'preforked' because before you fork a CGI script you have to set the relevant environment variables for the request. Still, forking is never the bottleneck (werc itself performs hundreds of fork per request) and I wouldn't be surprised if CGD is not more efficient than the CGI-handling code in most web servers, but if your web server already supports CGI i wouldn't really bother. Hope this answers most (all?) your questions. Uriel
[dev] [ANN] CGD - Ultra-minimalist HTTP and FastCGI wrapper for CGI programs.
CGD runs as a FastCGI wrapper (to be used with nginx or similar web server) or as a standalone HTTP server, handing over all requests to a given CGI script. http://repo.cat-v.org/cgd/ This is useful to run werc under nginx, or directly without a standalone web server. CGD is extremely simple, under 50 lines of Go code, much simpler than fcgiwrap, and has been tested in production by several members of #cat-v. Instructions on how to use CGD to host werc with nginx: http://werc.cat-v.org/docs/web-server-setup/nginx Feedback and patches welcome, as an experiment the CGD repo is hosted with github: https://github.com/uriel/cgd Enjoy Uriel
Re: Regarding "make"-systems [Was: Re: [dev] Build system: redo]
On Mon, Aug 13, 2012 at 4:54 PM, Andrew Hills wrote: > On Sun, Aug 12, 2012 at 8:23 PM, Uriel wrote: >> This whole topic is so silly, just use a language that doesn't need >> any of this nonsense, like Go. > > Are you insinuating that Go is the best choice for all projects, For all projects, obviously not. But for most projects Go is by far the least bad choice. > regardless of requirements? Or just that C is never the right choice? C is still the right choice some times, but rarely it is a better choice than Go. And in such cases, make and mk have worked just fine for decades, so all this discussion about build systems mostly a waste of time. All that said, I do like redo, I just don't see that much use for it, and I'm not interested in using it unless it is implemented in a sane language like C, rc or Go. Uriel
Re: Regarding "make"-systems [Was: Re: [dev] Build system: redo]
On Fri, Aug 10, 2012 at 11:48 AM, Ciprian Dorin Craciun wrote: > (I've changed the subject of the thread because I want to move the > discussion in a more "general" direction not specific to one build > system.) > > > On Sun, Jul 15, 2012 at 7:53 PM, Anselm R Garbe wrote: >> The holy make replacement is already there: >> >> http://man.suckless.org/9base/mk > > > Starting from a minor side note about `mk` (at least the > `plan9port` version, but I doubt the one from `9base` doesn't suffer > the same problems): it doesn't cope nicely with large, especially > generated, make files (i.e. after a few hundred rules)... (But when > you want to use them as a "backend" for another generator (like for > example `CMake` ore any other "suckless" or "bloatfull" system), you > get in a heap of problems... See the thread below for a lengthy > discussion...) > http://thread.gmane.org/gmane.os.plan9.general/60495/focus=60518 If you have generated makefiles with hundreds of rules, or cmake, or auto*hell, you already lost. Please stop writing code, become a lawyer or a bureaucrat. This whole topic is so silly, just use a language that doesn't need any of this nonsense, like Go. Uriel
Re: Regarding "make"-systems [Was: Re: [dev] Build system: redo]
On Sun, Aug 12, 2012 at 1:17 AM, Connor Lane Smith wrote: > (A) This suggests that we need a macro system. cpp(1) would bring us > #define, #ifdefs, and #include for free. This is good, because it > means we don't need to invent our own whole scripting subsystem. This is great because it shows your program is a worthless piece of garbage and I can completely avoid it without even bothering to build it first. Uriel
Re: [dev] Re: Regarding "dogma" words
On Sat, Aug 11, 2012 at 5:17 PM, Anselm R Garbe wrote: > I will transform this list to a moderated one, if the spamming and > trolling persists at current levels. The whining about the trolling is worse than the trolling itself. The original poster had a good point: the suckless name SUCKS. Still, it is not worth changing it now (but I'm sure you will change it again some random day, because you always have to change random shit all the time, even when it doesn't improve anything).
Re: [dev] [PATCH] sbase: add cut
On Fri, Aug 3, 2012 at 11:15 PM, Nick wrote: > Quoth Connor Lane Smith: >> % head -n -10 Yea, because obviously what we needed is even more unportable GNU extensions. If this is your only justification for head, it is really sad. > Cool, I didn't know that syntax. Useful. Out of curiousity, is it > codified in any standard? >
Re: [dev] [PATCH] sbase: add chroot
On Wed, Aug 1, 2012 at 5:00 PM, pancake wrote:
> That is vulnerable on linux. Proper use is:
Anyone using chroot for security is a fool.
Uriel
>
> chdir (path); chroot(".");
>
>
>
> On Aug 1, 2012, at 16:50, Strake wrote:
>
>> diff -r 8cf300476909 chroot.8
>> --- /dev/nullThu Jan 01 00:00:00 1970 +
>> +++ b/chroot.8Wed Aug 01 04:46:43 2012 -0500
>> @@ -0,0 +1,25 @@
>> +.TH CHROOT 8
>> +.SH NAME
>> +chroot \- change root directory
>> +.SH SYNOPSIS
>> +.B chroot
>> +.I path
>> +[
>> +.I x
>> +[
>> +.I argument ...
>> +]
>> +]
>> +.SH OPERATION
>> +.B chroot
>> +changes the root directory to
>> +.I path
>> +and starts
>> +.I x
>> +with
>> +.I arguments
>> +, or
>> +.B $SHELL -i
>> +if no
>> +.I x
>> +given.
>> diff -r 8cf300476909 chroot.c
>> --- /dev/nullThu Jan 01 00:00:00 1970 +
>> +++ b/chroot.cWed Aug 01 04:46:43 2012 -0500
>> @@ -0,0 +1,22 @@
>> +#include
>> +#include
>> +#include
>> +#include "util.h"
>> +
>> +int main (int argc, char *argu[]) {
>> +if (argc < 2) {
>> +fputs ("No new root path given\n", stderr);
>> +exit (1);
>> +}
>> +if (chroot (argu[1])) eprintf ("chroot:");
>> +if (argc == 2) {
>> +char *x;
>> +x = getenv ("SHELL");
>> +if (!x) {
>> +fputs ("chroot: SHELL not set\n", stderr);
>> +return 1;
>> +}
>> +if (execl (x, x, "-i", (char *)0) < 0) eprintf ("chroot: %s:", x);
>> +}
>> +else if (execv (argu[2], argu + 2) < 0) eprintf ("chroot: %s:",
>> argu[2]);
>> +}
>>
>
Re: [dev] [PATCH] sbase: add cut
On Thu, Aug 2, 2012 at 4:34 PM, Kurt H Maier wrote: > On Thu, Aug 02, 2012 at 10:33:19AM -0400, Calvin Morrison wrote: >> >> I think cut is exactly the kind of job that awk (or sed) can be good >> for. It seems crazy not to use an existing tool that implements all >> the functionality, that can be nicely bundled in a a script. >> > > To be honest, I feel the same way about head(1) -- why bother > maintaining C when the tool is obviously a subset of another tool? head(1) is utterly and completely idiotic. sed 11q is superior in every possible way.
Re: [dev] [PATCH] sbase: add cut
On Wed, Aug 1, 2012 at 3:18 PM, Martin Kopta wrote:
> On 08/01/2012 03:09 PM, Kurt H Maier wrote:
>>
>> On Wed, Aug 01, 2012 at 08:58:00AM -0400, Niki Yoshiuchi wrote:
>>>
>>> Why would you use awk or Perl when you have the best programming language
>>> available: Ruby?
>>> On Aug 1, 2012 8:55 AM, "Martin Kopta" wrote:
>>>
>>>> On 08/01/2012 02:36 PM, Uriel wrote:
>>>>
>>>>> Use awk.
>>>>>
>>>>
>>>> Use Perl.
>>>>
>>>>
>>>>
>>
>> I hereby declare this mail thread a disaster area of top-posting and
>> language fanboyism and request immediate dispatch of the vans.
>>
>> Also, I'm really curious why people use cut when awk exists.
>
>
> $ du -b /usr/bin/cut /usr/bin/gawk /opt/plan9/bin/awk
> 38600 /usr/bin/cut
> 400212 /usr/bin/gawk
> 105700 /opt/plan9/bin/awk
You don't mention if they are statically or dynamically linked.
> Why would I use awk of which I don't remember syntax, when I could often do
> with trustworthy cut easily? Seriously, apart from '{print $1}' and doing
> sums and stuff, I don't know awk. I don't want to. It is weird intermezzo
> between simple cut/sed/.. and almighty perl. Never understood awk users.
Awk is so simple that there is simply no excuse for not knowing it
properly, if you use Unix you should know awk.
Also The Awk Programming Language is one of the best technical books
ever written, and everyone who uses Unix should have read it.
Uriel
Re: [dev] [PATCH] sbase: add cut
On Wed, Aug 1, 2012 at 4:04 PM, Ryan Mullen wrote: > > Exclusion of cut would make sbase not viable when existing scripts > need to be supported. Exclusion of bash would make sbase not viable when existing scripts need to be supported. What a lame argument. Uriel
Re: [dev] Build system: redo
On Sun, Jul 15, 2012 at 3:28 PM, Prakhar Goel wrote: > I propose adding redo to the list of software that rocks. It'll also > give you a nice incremental build system to use. I like the design, but unless you rewrite it in C or Go it is not worth taking seriously. Uriel > > Info here: http://apenwarr.ca/log/?m=201012#14 > Github page: https://github.com/apenwarr/redo > > Actually, pretty much all of DJBs software (daemontools, qmail, > djbdns, etc...) could probably be added to the list as well... > > I especially like his take on the FS hierarchy: > http://cr.yp.to/slashpackage.html > -- > > Warm Regards > Prakhar Goel > LinkedIn Profile: http://www.linkedin.com/in/newt0311 >
Re: [dev] New friends
I really don't care, luser space, or kernel space, as long as ALSA and Puke Audio die. Uriel On Wed, Aug 1, 2012 at 2:34 AM, Anthony J. Bentley wrote: > Christoph Lohmann writes: >> Greetings comrades, >> >> in our reckless effort to improve the software world a new friend might >> have appeared [0]. >> >> >> Sincerely, >> >> Christoph Lohmann >> >> [0] http://klang.eudyptula.org/ >> > > Funny, considering OpenBSD's sndio interface[1] goes the opposite route and > moves audio to userland. I'm curious how the two compare. > > -- > Anthony J. Bentley > > [1] http://www.openbsd.org/porting/audio-port.html >
Re: [dev] [PATCH] sbase: add cut
Use awk.
On Wed, Aug 1, 2012 at 6:07 AM, Strake wrote:
> Will now need libutf.
>
> diff -r 8cf300476909 Makefile
> --- a/Makefile Sat Jun 09 18:53:39 2012 +0100
> +++ b/Makefile Tue Jul 31 23:06:28 2012 -0500
> @@ -27,6 +27,7 @@
> cksum.c\
> cmp.c \
> cp.c \
> + cut.c \
> date.c \
> dirname.c \
> echo.c \
> diff -r 8cf300476909 config.mk
> --- a/config.mk Sat Jun 09 18:53:39 2012 +0100
> +++ b/config.mk Tue Jul 31 23:06:28 2012 -0500
> @@ -10,7 +10,7 @@
> LD = $(CC)
> CPPFLAGS = -D_POSIX_C_SOURCE=200112L
> CFLAGS = -g -ansi -Wall -pedantic $(CPPFLAGS)
> -LDFLAGS = -g
> +LDFLAGS = -g -lutf
>
> #CC = tcc
> #LD = $(CC)
> diff -r 8cf300476909 cut.1
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/cut.1 Tue Jul 31 23:06:28 2012 -0500
> @@ -0,0 +1,51 @@
> +.TH CUT 1
> +.SH NAME
> +cut \- select columns of file
> +.SH SYNOPSIS
> +.B cut -f
> +.I ranges
> +[
> +.B -d
> +.I delimiter
> +]
> +[
> +.I file ...
> +]
> +.br
> +.B cut -c
> +.I ranges
> +[
> +.I file ...
> +]
> +.br
> +.B cut -b
> +.I ranges
> +[
> +.I file ...
> +]
> +.br
> +.SH OPERATION
> +Cut reads from given files, or stdin if no files given, and for each
> line selects
> +.TP
> +.B columns,
> +with -f flag
> +.TP
> +.B characters,
> +with -c flag
> +.TP
> +.B bytes,
> +with -b flag
> +.LP
> +within given comma- or space-delimited ranges.
> +.LP
> +.br
> +Each range is either a single decimal number, or of this form:
> +.br
> +.I x
> +-
> +.I y
> +.br
> +where x and y are decimal numbers, or empty.
> +Empty x means first, and empty y means last column/character/byte on the
> line.
> +.LP
> +If -d option given, then the first character of its argument is the
> delimiter; otherwise it is tab.
> diff -r 8cf300476909 cut.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/cut.c Tue Jul 31 23:06:28 2012 -0500
> @@ -0,0 +1,192 @@
> +#include
> +#include
> +#include
> +#include "text.h"
> +
> +typedef struct {
> + int min, max;
> +} range;
> +
> +int inRange (range r, unsigned int n) {
> + if ((0 == r.max || n <= r.max) && n >= r.min) return 1;
> + else return 0;
> +}
> +
> +int fputrune (Rune r, FILE *f) {
> + char x[UTFmax];
> + int n;
> + n = runetochar (x, &r);
> + fwrite (x, 1, n, f);
> + return n;
> +}
> +
> +void cutLineF (Rune d, unsigned int s, range *rs, char *x) {
> + int ii, n;
> + if (!utfrune (x, d)) {
> + if (!s) fputs (x, stdout);
> + return;
> + }
> + /* kludge; be warned */
> + for (ii = 0; rs[ii].min; ii++) {
> + char *y;
> + y = x;
> + for (n = 1; y; n++) {
> + char *z;
> + char ch;
> + z = utfrune (y, d);
> + if (z) {
> + ch = *z;
> + *z = 0;
> + }
> + if (inRange (rs[ii], n)) {
> + fputs (y, stdout);
> + fputrune (d, stdout);
> + }
> + if (z) {
> + *z = ch;
> + z += runelen (d);
> + }
> + y = z;
> + }
> + }
> +}
> +
> +void cutLineC (range *rs, char *x) {
> + Rune _r;
> + int ii, n;
> + for (ii = 0; rs[ii].min; ii++) {
> + char *y;
> + y = x;
> + for (n = 1; *y; n++) {
> + int l = chartorune (&_r, y);
> + if (inRange (rs[ii], n)) fwrite (y, 1, l, stdout);
> + y += l;
> + }
> + }
> +}
> +
> +void cutLineB (range *rs, char *x) {
> + int ii, n;
> + for (ii = 0; rs[ii].min; ii++) {
> + for (n = rs[ii].min - 1; rs[ii].max ? n < rs[ii].max : x[n];
> n++) {
> + fputc (x[n], stdout);
> + }
> + }
> +}
> +
> +void go (int mode, Rune d, unsigned int s, range *rs) {
> + char *x;
> + size_t size = 0;
> + x = 0;
> +
> + while (afgets (&x, &size, stdin)) {
> + int ii;
> + /* must delete newline here, and redo later;
> + otherwise, unknown whether it was included in cut */
> + for (ii = 0; x[ii]; ii++) if (x[ii] == '\n') x[ii] = 0;
> + switch (mode) {
> + case 'f':
> + if (!utfrune (x, d)) {
> + if (!s) {
> + fputs (x, stdout);
> + fputc ('\n', stdout);
> + }
> + }
> + else {
> + cutLineF (d, s, rs, x);
> +
Re: [dev] Re: Cleanup of (hg.)suckless.org
On Mon, Jun 20, 2011 at 8:55 PM, garbeam wrote: > On 20 June 2011 07:48, Petr Sabata wrote: >> On Sat, Jun 18, 2011 at 10:33:02PM +0100, garbeam wrote: >>> On 3 June 2011 17:35, garbeam wrote: >>> > RELOCATE >>> > - last (google code) ?? >>> > - libixp (google code) ?? >>> > - r9p (google code) ?? >>> > - vp (google code) ?? >>> > - wmii (google code) ?? >>> > - wmiirc-rumai (google code) ?? >>> > - skvm (dunno, don't get it) ?? >>> >>> I would like to hear about the status. Are things started to relocate >>> those repos? >> >> And why do you want to move them, actually? > > I don't consider those repositories a good fit with the suckless > philosophy anymore and I intend to sharpen the scope of suckless.org. The suckless philosophy: a bunch of clueless nerds spending all day talking about how to configure their favorite retarded text editors, arguing over which linux distro is most lame, and other equally pointless stuff. Fuck yea! How the hell is stuff like surf supposed to be suckless anyway? What a big fucking joke. uriel
Re: [dev] Microsoft considers harmful...
John Carmack: "I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security." http://twitter.com/#!/ID_AA_Carmack/status/81732190949486592 HTML5 is great, it is the final nail in the coffin of XML, and that can only be a good thing, of course it will take decades to bury the god damned thing, but it is the beginning of the end. The web can't be saved, lets at least try to save the future by killing XML as soon as possible. And may ken bless JSON, which has been like a miracle, ironically born of some of the worst web technologies around. uriel On Fri, Jun 17, 2011 at 12:00 PM, hiro <23h...@googlemail.com> wrote: > > http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx > > They learned their lesson and I want a button for disabling HTML5 in my > browser. >
Re: [dev] Re: Cleanup of (hg.)suckless.org
On Mon, Jun 20, 2011 at 8:48 AM, Petr Sabata wrote: > On Sat, Jun 18, 2011 at 10:33:02PM +0100, garbeam wrote: > > I would like to hear about the status. Are things started to relocate > > those repos? > > And why do you want to move them, actually? Usual garbeam fetish for busywork. He is an excellent bureaucrat. uriel
Re: [dev] [ANN] sabotage 2011-04-30, a musl+busybox based distribution
On Fri, May 13, 2011 at 12:26 AM, hiro <23h...@googlemail.com> wrote: >> Dillo is not really designed to be ported to use other toolkits > > Well, that's one more point for dillo then... To be tied up to a C++ toolkit is not a plus. uriel
Re: [dev] [ANN] sabotage 2011-04-30, a musl+busybox based distribution
On Mon, May 9, 2011 at 8:14 PM, Yoshi Rokuko wrote: > + hiro ---+ >> >> About dillo again: last time I talked about fltk everyone here wanted >> to kill me and I had to change my phone number. Is this just because >> of C++ or are there other reasons I've overseen? >> > > i really like dillo because it is fast, but i would really like to > control it like surf ... > > so i would propose to use neither fltk nor gtk for a dillo gui. Dillo is not really designed to be ported to use other toolkits, it took them forever and a very considerable rewrite to switch from GTK to fltk. Netsurf on the other hand already has quite a few different frontends using various toolkits. uriel
Re: [dev] Tabbed unmaintained?
Fucking German fags, learn English, morons. uriel On Mon, May 9, 2011 at 9:15 PM, wrote: > evening' > > On Mon, May 09, 2011 at 09:04:07PM +0200, ilf wrote: >> On 05-06 22:46, u...@netbeisser.de wrote: >> >1 Oettinger is on the way. > >> Oettinger? SRSLY? > > zes, different brands at the Linux Tag 2011. > > > nash > >
Re: [dev] Suckless UML
So much retarded crap in this thread, it is hard to know where to start. Fortunately somebody already has done some writing on the topic: http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html UML makes CORBA and C++ look like sane, productive and useful technologies by comparison. Pure, unadulterated PHB bullshit without even the slightest pretense of anything else. IBM are geniuses for pulling off such a stunt, and that anyone is still using such stuff is just as stunning. uriel On Tue, May 10, 2011 at 4:36 PM, CHABOT Simon wrote: > Hi all, > Today, an UML lesson have been given in my university. We used the > software DIA to build our diagram. I've made some research on Internet for an > UML suckless software, but didn't success. > > Could you give me some suckless softwares name to work with UML ? > > I was thinking about a software where UML diagram is describe, and then > compiled (something like LaTeX, you see ?) > > Thank you… > -- > CHABOT Simon > Université de Technologie de Compiègne > GPG KeyID : B6DFD50C >
Re: [dev] Why dwm or wmii over xmonad, etc., or not?
On Wed, Apr 20, 2011 at 4:27 PM, Eitan Goldshtrom wrote: > Hi Everyone, > So I started using wmii a couple months ago. It was the first time I wasn't > using GNOME and it's default stuff and I did so because a friend recommended > wmii to me. So now I want to know what you all think. Why are dwm and wmii > better than other tiling WMs? Or not? And what are your opinions of dwm vs > wmii? If you are capable of independent thought, what about you actually try the different window managers and make up your own mind? Or do you always need somebody else to tell you what to do? You already quit GNOME, it is all downhill from there. uriel
Re: [dev] Why dwm or wmii over xmonad, etc., or not?
On Wed, Apr 20, 2011 at 4:27 PM, Eitan Goldshtrom wrote: > Hi Everyone, I suggest you start by not sending HTML email to mailing lists. Thank you uriel P.S.: Can we please get a filter that bounces all HTML-containing emails with a message instructing people to learn to use their email client?
Re: [dev] [dwm] devilspie doesn't work
On Fri, May 6, 2011 at 3:04 AM, Al Gest wrote: > On 5 May 2011 21:12, Kurt H Maier wrote: >> I'm not telling anyone what they're allowed to do. I'm telling them >> what they're doing is stupid shit, and that founding principle of >> suckless is basically sound. > > Who's likely to behave more intelligently, a person who experiments > and finds out what works and doesn't work for themselves and > understands from experience why things work or don't work, or a person > who religiously follows the preaching of some overcompensating > jackass? Why don't you do mankind a favour and go experiment with a chainsaw and your dick. uriel
Re: [dev] [dwm] devilspie doesn't work
On Fri, May 6, 2011 at 1:17 AM, wrote: >> People who want transparent terminals are incapable of learning anyway. > > I'm curious, how did you come to this conclusion? There is plenty of empirical evidence to back this up, just look at this lists archives. uriel
Re: [dev] [dwm] devilspie doesn't work
On Fri, May 6, 2011 at 4:48 AM, errno wrote: > I could of course make some really opinionated and abrasive statements > about people like you who choose to continue to use hardware terminal > emulators in lieu of, say, 9term - but that'd be uncool. I hate hardware-emulation-terminals as much as anyone else in this filthy planet, but there are *real* practical reasons to use them. There is no justification whatsoever for transparent terminals. uriel
Re: [dev] [dwm] devilspie doesn't work
On Fri, May 6, 2011 at 4:17 AM, Anders Andersson wrote: > I'd also like to compare that kind of retardness to people that have > lights *inside* their computer, complete with a window on the side of > the tower. Totally useless, wasting power, pollutes the vision by > shining coloured light where there should be none, and just being a > sign of bad taste. Heck, there are cooling fans with LEDs in them. They are not called *ricers* for nothing, they are the same people that think it is cool to run Gentoo (or Arch, or whatever) because of all the piles of text they don't understand that scroll by their terminal, and use transparent terminals so they can jerk off to their lame ass desktop wallpapers all day long. uriel
Re: [dev] [dwm] devilspie doesn't work
On Fri, May 6, 2011 at 6:11 AM, Al Gest wrote: >> I'm not interested in how you think I come across. Fortunately, >> idiots like you don't control my speech. > > And yet you are clearly perturbed by it. It is disturbing that there are human beings inept and retarded enough to think transparent terminals are somehow not a completely idiotic idea. Please forgive us for displaying a minimal amount of empathy of the human race. uriel
Re: [dev] [dwm] devilspie doesn't work
On Fri, May 6, 2011 at 4:20 AM, wrote: >> Transparent terminals unnecessarily increase computational power >> required to render simple text. They make a fundamental application >> harder for a computer to run. This makes the core program less >> portable by raising the hardware requirements. The only gain is >> (arguably) aesthetic. This, in short, is a completely braindead idea >> of no practical value, unless you tend to use a computer in the manner >> of someone who has been hit very hard in the head and has forgotten >> entirely what computers do and what terminals are > > So... Houses simply shelter us from weather. Automobiles simply transport > us from point A to point B. Should we only live is sod huts? Should we > only drive wooden go-carts? Of course, anything else is just a waste of > resources, and computers are merely text processors. Do you read books with semi-transparent pages? Or do you dip the book in acid before reading it? No, wait, you clearly *drink* the bucket of acid when you wake up in the morning. uriel
Re: [dev] [st] transparency - Was: [dwm] devilspie doesn't work
On Thu, May 5, 2011 at 10:27 PM, ilf wrote: > On 05-05 22:04, Aurélien Aptel wrote: >> >> Leon Winter made a patch to support transparency in st few months ago [1]. >> It should'nt be hard to adapt it to tip if you want it. 1: >> http://lists.suckless.org/dev/1009/6046.html > > Cool! > > Any chance of adding a patches/ menu to http://st.suckless.org/ similar to > http://dwm.suckless.org/patches/ and including this? Can we please add to the patch a feature that rm -rf /'s the disk of anyone who runs it? > To the haters: Do you think this sucks for usability or code size reasons? It is for purely *stupidity* reasons. > The patch only adds 4 LOC, so it can't be that. About the usability: well > that depends on the config. And while there may be truly horrible uses of > this around, I really like my setup: http://i.imgur.com/3UDbi.png Hey, some people are into coprophagia too, if that is what you like, more power to you. uriel
Re: [dev] [dwm] devilspie doesn't work
On Thu, May 5, 2011 at 10:04 PM, Al Gest wrote: > You know what's great? freedom of choice. You know what sucks? People > telling you what you're allowed to do with the software you use. Is > this suckmore or suckless? Yes, please exercise your freedom of choice and go fucking use Gnome. > While I have no love for transparency given that the majority of > transparency features in desktop environments are superfluous and > counteract functionality, I also respect and support the right to > freedom of choice. Being told how I should use the software I use is > the exact opposite of the reason I turn to solutions such as suckless > software. > > You may hate transparency, and that is your opinion and choice, but > berating other people for wanting to experiment isn't a constructive > pastime. If people aren't free to experiment for themselves, how will > they ever truly learn what works well and what doesn't? Pointing out to people that what they want is stupid is a very valuable and important task. The reason software, and the world in general, sucks so incredibly much is because people are too damned respectful and afraid of offending others by attacking their retarded ideas. An attack on your ideas is not an attack on you, it is actually giving you a chance to learn from your mistakes. We all have had totally retarded ideas, it is only thanks in part to people that went out of their way to point out how retarded many of my ideas were that I learned and now I know better. uriel > If people were obnoxiously stating that suckless software should have > fancy fluff feature X implemented in vanilla then I could somewhat > understand the vitriol, but I really don't see the point of foaming at > the mouth and making yourselves look like complete jackasses every > time the word transparency is merely mentioned. > > On 5 May 2011 19:26, Kurt H Maier wrote: >> On Thu, May 5, 2011 at 11:50 AM, Connor Lane Smith wrote: >>> This is the dumbest thing I've ever heard. The comparison makes total >>> sense, of course, because transparency clearly kills people. How >>> fucking fallacious. >> >> *Reality* kills people. Therefore it's clearly not a bell or whistle >> and should be supported natively. >> >>> If someone wants to patch their own software to do something they >>> consider beneficial, that's fine. There seem to be people on this >>> mailing list who basically want the world to remain as it was in the >>> 70s, progress be damned! You're ridiculous. >> >> You're begging the question of whether a transparent terminal is >> 'progress.' I submit that it isn't, and it's just stupid shit. >> >> >> >> -- >> # Kurt H Maier >> >> > >
Re: [dev] [dwm] devilspie doesn't work
On Thu, May 5, 2011 at 5:23 PM, Connor Lane Smith wrote: > Besides, there's no reason for transparency to be considered a bell or > whistle: alpha is just a fourth dimension alongside RGB. Reality has > transparency, did you notice? Reality also has cancer and depression, so should programs randomly kill themselves? uriel
Re: [dev] [dwm] devilspie doesn't work
On Wed, May 4, 2011 at 9:59 PM, Maciej Sobkowski wrote: > I want to add transparency to terminal windows using transset-df. Is > this possible to acomplish within config.h file? Try instead getting a fucking life. uriel
Re: [dev] Sup and dmc
On Wed, Apr 6, 2011 at 7:49 AM, SHRIZZA wrote: >> You know, we could all say we're using shitty MUAs because we see >> the rendered HTML rather than the plain-text component. ;) Even >> HTML-only mail can be converted to plain text. > > Solution: use mutt. Real solution: Exterminate all Apple users. uriel
Re: [dev] Re: [ANN] sabotage 2011-04-30, a musl+busybox based distribution
On Wed, May 4, 2011 at 5:22 PM, Christian Neukirchen wrote: > Uriel writes: > >> Please, replace gawk with a sane version of awk, like the one included >> with 9base. The awk in 9base is a hacked up version of bwk's one-true-awk that supports UTF-8. > gcc4 needs an awk more powerful than busybox awk, thats why it's there. > I'm not sure it works with 9base awk, but it's easy to test. > >> Also, adding Go should be easy as it completely bypasses libc and >> links statically by default. >> >> For a web browser I would recommend NetSurf, not to be confused with >> surf (which is a shameful disgrace for the suckless project). > > NetSurf needs GTK+ on X, which pulls in a shitload of deps I've not yet > gotten around porting. As has been mentioned in this thread, there is a framebuffer version of netsurf, and if somebody wrote a tk or libagar frontend to netsutf it would be wonderful. GTK is an abomination. uriel
Re: [dev] [ANN] sabotage 2011-04-30, a musl+busybox based distribution
On Wed, May 4, 2011 at 4:06 PM, Corey Thomasson wrote: > Not quite. A few commits ago the net package was changed to use libc in > places and dynamically link unfortunately Blame Apple that breaks any code that doesn't do networking via their luserspace crap. In any case, Go's own DNS resolver is still there, and for example on ARM by default it still bypasses the libc for everything. uriel
Re: [dev] [ANN] sabotage 2011-04-30, a musl+busybox based distribution
On Wed, May 4, 2011 at 3:30 PM, Kurt H Maier wrote: > Netsurf brings in libxml. A web browser brings an xml parser?!? No shit! uriel
Re: [dev] [ANN] sabotage 2011-04-30, a musl+busybox based distribution
On Sun, May 1, 2011 at 12:29 AM, Christian Neukirchen wrote: > Hi, > > this is the third public release of sabotage, a distribution based on > musl and busybox. Provided software is: This is a mildly interesting project that might have some potential. Please, replace gawk with a sane version of awk, like the one included with 9base. Also, adding Go should be easy as it completely bypasses libc and links statically by default. For a web browser I would recommend NetSurf, not to be confused with surf (which is a shameful disgrace for the suckless project). uriel > 9base-6 autoconf-2.68 automake-1.11 binutils-2.21 bison-2.4.3 > busybox-1.18.4 curl-7.21.4 diffutils-3.0 e2fsprogs-1.41.14 expat-2.0.1 > file-5.05 flex-2.5.35 gawk-3.1.8 gcc-core-4.5.3 git-1.7.4 gmp-5.0.1 > grep-2.7 less-436 libarchive-2.8.4 linux-2.6.38.2 lynx2.8.7 m4-1.4.16 > make-3.82 mpc-0.9 mpfr-3.0.1 musl-2011-04-18 ncurses-5.9 openssh-5.8p1 > openssl-1.0.0d patch-2.6.1 perl-5.12.3 pkg-config-0.25 psmisc-22.13 > python-2.7.1 sed-4.2.1 syslinux-4.04 vim-7.3 xz-5.0.2 zlib-1.2.5 > > There also is an experimental xorg set with: > > bigreqsproto-1.1.1 compositeproto-0.4.2 damageproto-1.2.1 > fixesproto-5.0 fontconfig-2.8.0 fontsproto-2.1.1 freetype-2.4.4 > inputproto-2.0.1 kbproto-1.0.5 libICE-1.0.7 libSM-1.2.0 libX11-1.4.3 > libXau-1.0.6 libXaw-1.0.9 libXdmcp-1.1.0 libXext-1.2.0 libXfixes-5.0 > libXfont-1.4.3 libXft-2.2.0 libXi-1.4.2 libXmu-1.1.0 libXpm-3.5.9 > libXrender-0.9.6 libXt-1.1.1 libfontenc-1.1.0 libpthread-stubs-0.3 > libxcb-1.7 libxkbfile-1.0.7 pixman-0.21.6 randrproto-1.3.2 > recordproto-1.14 renderproto-0.11.1 resourceproto-1.1.1 > scrnsaverproto-1.2.1 st-0.1.1 twm-1.0.6 util-macros-1.13.0 > videoproto-2.3.1 xauth-1.0.5 xcb-proto-1.6 xclock-1.0.5 > xcmiscproto-1.2.1 xextproto-7.2.0 xineramaproto-1.2.1 xinit-1.3.0 > xkbcomp-1.2.1 xkeyboard-config-1.4 xlogo-1.0.3 xorg-server-1.9.5 > xproto-7.0.21 xterm-269 xtrans-1.2.6 > > Everything is statically linked. > > As of this release, sabotage supports both i386 and x86_64. > > You can bootstrap your own build from the scripts at > > https://github.com/chneukirchen/sabotage > > or use a ready-to-boot disk image either for netinstall or with sets > included (put it on an USB stick, burning a CD will not work), to be > found at: > > http://xmw.de/mirror/sabotage/i386/sabotage-2011-04-30/ > http://xmw.de/mirror/sabotage/x86_64/sabotage-2011-04-30/ > > You also can netboot the install kernel directly (use pxelinux from > somewhere). > > The default root password is "sabotage". > > Enjoy, > -- > 58c09ad48792240b3c07d11da62e99773ce205bf > i386/sabotage-2011-04-30/sabotage-i386-full-2011-04-30.img.gz > 24e2f96ffa8fac72a3ea5d38efe2579232be3be9 > i386/sabotage-2011-04-30/sabotage-i386-netinstall-2011-04-30.img.gz > 8d6c675cf511f90f2539331a92772fb31628c712 > x86_64/sabotage-2011-04-30/sabotage-x86_64-full-2011-04-30.img.gz > f042686295d20941929b308e0188577ec2d7a53e > x86_64/sabotage-2011-04-30/sabotage-x86_64-netinstall-2011-04-30.img.gz > > Christian Neukirchen http://chneukirchen.org > >
[dev] Re: Version control for Sta.li
> I just found a version control system that I hadn't heard of and might work > well for Stali: Fossil. It's by the author of SQLite Sounds like more than reason enough to avoid it like the plague that SQLite is. > It also serves as its own web server (but can be used with CGI as well) that > provides repository browsing, issue tracking, and a wiki. The emacs of scms? This is well beyond scary. uriel On Sun, Mar 20, 2011 at 6:23 PM, Bill Burdick wrote: > Trying to get Anselm's attention -- do you know if he is still working on > Stali? > Bill Burdick > > -- Forwarded message -- > From: Bill Burdick > Date: Tue, Mar 15, 2011 at 5:31 PM > Subject: Version control for Sta.li > To: ans...@garbe.us > > > I'm a fan of Stali and I just found a version control system that I hadn't > heard of and might work well for Stali: Fossil. It's by the author of > SQLite -- a single 800K executable that provides both client and server. It > also serves as its own web server (but can be used with CGI as well) that > provides repository browsing, issue tracking, and a wiki. > Here's my listing from ldd: > linux-gate.so.1 => (0x0088) > libz.so.1 => /lib/libz.so.1 (0x0041f000) > libc.so.6 => /lib/libc.so.6 (0x004e4000) > /lib/ld-linux.so.2 (0x001aa000) > It seems fairly feature-compatible with Mercurial/Git (nothing like Git's > submodule support at this point, from what I can tell). Here's the > link: http://www.fossil-scm.org > > Bill Burdick >
Re: [dev] [9base] cheeky TODO patch
And col(1), which sadly is missing from p9p too, but should be trivial to port from Plan 9. uriel 2011/1/20 Stanley Lieber : > diff -r e39eeddcc295 TODO > --- a/TODO Thu Jan 06 09:50:05 2011 + > +++ b/TODO Wed Jan 19 23:02:02 2011 -0600 > @@ -1,1 +1,1 @@ > -add wc > +add htmlfmt > > -sl > >
Re: [dev] [slock] Linux-PAM support
On Tue, Nov 16, 2010 at 2:38 PM, Kurt H Maier wrote: > the slackware people peat on policykit unitl it worked without pam, > why are we moving the other direction Because I suspect 'suckless' should be renamed 'suckass'. The amount of totally retarded evil shit that gets proposed in this list is astounding. And Glenda bless Slackware and OpenBSD from standing against the idiotic insanity that is PAM. uriel > -- > # Kurt H Maier > >
Re: [dev] [slock] Linux-PAM support
On Tue, Nov 16, 2010 at 12:09 PM, pancake wrote: > On 11/16/10 11:46, Petr Sabata wrote: >> >> Hey, >> >> this patch should enable Linux-PAM support in slock. It's my first try >> with >> Linux-PAM whatsoever so there's a chance it won't work everywhere :) Maybe >> it could be useful to some... Pam must die. uriel
Re: [dev] Re: [st] multibyte patch
On Sat, Nov 13, 2010 at 10:53 PM, Damian Okrasa wrote: > I removed the wchar_t completely, added some UTF-8 parsing functions. Cool! > No support for combining, bidi, doublecolumn etc. I hope it stays that way, all those things are truly insane and do not belong on any terminal. uriel
Re: [dev] [st] multibyte patch
On Sun, Nov 7, 2010 at 10:50 PM, Moritz Wilhelmy wrote: > Whatever you want, wchar_t is not the solution. Amen. Added it to the cat-v fortunes file: http://fortunes.cat-v.org/cat-v/ uriel
Re: [dev] anyone played with mkinit?
On Tue, Nov 9, 2010 at 6:06 AM, Jens Staal wrote: > There is an rc version in the svn repository though. Out of principle I refuse to touch anything stored in a svn repository. And really, the whole problem space is wrong, if you need an 'init system' your system is already FUBAR. If your init system requires dependency tracking then you are way beyond FUBAR. uriel
Re: [dev] anyone played with mkinit?
On Sat, Nov 6, 2010 at 4:50 AM, Jens Staal wrote: > http://9fans.net/archive/2009/10/375 > > https://lug.rose-hulman.edu/svn/misc/trunk/mkinit/ > > apparently still with bashisms due to issues with rc (does not mention > which) but seems cool and perhaps something for sta.li? Any issues with rc are no excuse for bashisms, actually there is never any excuse for bashisms, /bin/sh should be more than enough. Also the use of svn is a bad omen. uriel
Re: [dev] surf script.js - incompatible with openjdk6?
On Fri, Oct 15, 2010 at 11:42 PM, Antoni Grzymala wrote: > Gregor Best dixit (2010-10-15, 22:35): > >> On Fri, Oct 15, 2010 at 03:15:03PM -0400, MItchell Church wrote: >> > I've still been unable to implement link hinting in surf. Numerous >> > searches of >> > dev archives and internet forums make me believe that it could be some >> > sort of >> > incompatibility non proprietary java packages. That doesn't sound >> > plausible to >> > me, but I can think of no other reason why it wouldn't work. I can't even >> > get >> > the script to throw any errors, it is just simply not calling script.js >> > when I >> > ctrl-f. >> >> WOW... >> >> I'm sure you're just trolling, but I'm going to feed you anyway... The >> 'Java' in 'JavaScript' has _nothing_ to do with Java as in bytecode >> language interpreted by the JVM. It's just marketing blah to ride on the >> ever so neat wave of success that is Java. > > With JavaScript being actually a much nicer language. The smell of a pile of stale donkey dung is a much nicer language than Java. But there are always worse things... there are always C++ and D. uriel > -- > [a] >
Re: [dev] Evils of glibc
On Thu, Oct 7, 2010 at 10:22 PM, pancake wrote: > Thats not new. 9base build isbroken in arch for about a while. Last glibc is > stupid You say it as if the previous glibc's were not stupid, they just somehow managed to make the latest glibc even *more* stupid than it was already, i'm sure they had to work really hard to accomplish such a feat. uriel
Re: [dev] surf ssl handshake
Slightly offtopic, but just occurred to me that "the SSL handshake" should be renamed "the SSL middle finger", specially in consideration of the scam that are CAs. uriel On Sun, Oct 3, 2010 at 9:15 PM, Martin Kopta wrote: > I use surf and about a week ago it begun to refuse to load https pages with > message > > SSL handshake failed: A record packet with illegal version was received. > > I guess it is not surfs fault but before I dig deeper, I would like to > know if somebody doesn't have the same problem. > > I recompiled openssl, webkit and surf but it didn't help. I am using Crux > here. > > Thanks for any hints. > > Martin > >
Re: [dev] mcwm
On Wed, Sep 15, 2010 at 10:15 PM, Jakub Lach wrote: > 15/09/2010 21:51 Uriel : > >> What issues? and why aren't they fixed? >> >> uriel > > Oh, I was expecting something more along > the lines of "SDL is abomination and pile > of putrid garbage anyway".. > > Basically I was thinking[1] that SDL assumes > wm is re-parenting, which means that both cwm > and dwm have problems when SDL using application > window is spawned e.g. black window, no > content. > > Why it works with mcwm, I don't know[2]. > > [1] http://hg.suckless.org/dwm/file/tip/BUGS > > [2] If I reckon correctly, earlier dwm (5.7.2) > + earlier SDL didn't have such problems, however > there is nothing in SDL's changelog which would > explain present behaviour. > > P.S. As in BUGS, I have bugged them on their > forum + sent email, no reply. Have you (or anyone else) filled a bug at: http://bugzilla.libsdl.org/ ? uriel
Re: [dev] mcwm
What issues? and why aren't they fixed? uriel On Wed, Sep 15, 2010 at 12:36 PM, Jakub Lach wrote: > 15/09/2010 11:51 Alexander Polakov : > >>Looks like he is reinventing OpenBSD's cwm. > > At least it's running SDL based apps* without > problems. Last time I checked cwm had the same > issues as dwm. > > *Oh well, ok I admit it's chocolate-doom in my > case.. > >
Re: [dev] [patch] st - alphatransparency
Is it April already? Gosh how fast the time flies! uriel On Tue, Sep 14, 2010 at 8:03 PM, Leon Winter wrote: > Hi, > > just a proof of concept, no error-handling for non 32bit colordepth, > requires composite manager like xcompmgr. I noticed this feature is not > very popular so if you dont like the idea you better not apply the > patch ;) > > Edit ALPHA macro to change level of transparency (0x00 is invisible, > 0xff is nontransparent). > > Note: This patch will add real transparency to the background of the > terminal while the foreground still remains with no transparency. > > Diff against tip/148. > > Regards, > Leon Winter
Re: [dev] libdraw development
On Sat, Sep 4, 2010 at 12:34 AM, Connor Lane Smith wrote: > One file per function means a binary will only link the objects it needs, which helps keep binary size down when statically linking The linker should be capable of including only the symbols that are actually used in the program. uriel
Re: [dev] libdraw development
On Fri, Sep 3, 2010 at 10:28 AM, Connor Lane Smith wrote: > It may just be me, but weren't we > trying to write simple software, not just use libraries that already > exist because OMG they're in Plan 9! So instead you use libraries that already exist because OMG they are in Lunix!! (xlib and Xft, so far...) Oh, wait, you are creating a new library that uses those libraries! So I guess that makes it all OK. Not. In any case, and whatever it is intended for and how it accomplishes it, to use the same as libdraw is plain RETARDED. uriel
Re: [dev] libdraw development
On Fri, Sep 3, 2010 at 9:08 AM, Connor Lane Smith wrote: > Things are better seen in black and white, as Uriel will no doubt agree. Its got nothing to do with black and white: retarded shit is retarded. Unless you are a postmodernist, in which case any turd goes. Using the name 'libdraw' is *bound* to cause confusion, but of course I understand that when you are busy reinventing square wheels, causing extra confusion is the least of your worries... dwm and win32-dwm are totally unrelated, have different users, and I have never seen them being used in the same context. libdraw on the other hand has a very similar purpose and audience as your triangular-wheel-with-chewing-gum-spokes. uriel
Re: [dev] [patch] dmenu - support for xft font rendering
On Wed, Sep 1, 2010 at 10:02 PM, pancake wrote: > Current font size support in swk is merely a hack, the plan is to use > libdraw, so it will eventually support it. Antialiased fonts are sometimes > better for reading. > > I personally use 10x20 font or the fixed one. But certainly..reading the web > with courier is not as nice as with verdana.. Typographic nazis tend to be > quite extremist in pro to a correct use of fonts, like killing comic sans and > so on.. I'm no font nazi, but anyone that uses comicsans should die, very slowly and painfully. > I certainly think that having such possibility will be good. I know that font > systems are a quite mad, and utf8 is far more complex than just plain ascii > or bitmapped fonts. In fact ttf is a virtual machine, and opentype supports > as weird things as many different capital letters or combinations of two > chars. This is great for typographic ppl, and they tend to defend this > position in benefit of ease of reading. I know nothing about all this crap, but why not just use FreeType to render the fonts into a bitmap, and ignore the whole retarded X-font-systems? Or you could just use the *real* libdraw, which handles bitmap fonts quite nicely (and if you want another font at another size, you can always generate it). But that would be too simple and make too much sense, and re-inventing square wheels is so much more fun! uriel > On 01/09/2010, at 21:18, Arian Kuschki wrote: > >> Excerpts from Ethan Grammatikidis's message of 2010-09-01 19:00:17 +0200: >>> Connor Lane Smith wrote: >>>> If someone were to write a simple clean xft patch for libdraw it could >>>> be useful, perhaps even integrated into mainline. >>> This may just be my limited perspective, or it may be my upset stomach >>> talking, but I'm very surprised to see xft seriously suggested in this >>> mailing list. Xft is (to me) synonymous with the transition of X.org >>> from something bad but usable into a black box nightmare best left to >>> distro tools to cope with. Maybe it wasn't so bad for other people, >>> maybe it got better. >> >> I can't comment on the code complexity, but I do wish there was support >> for proportional fonts and other typographical niceties in >> terminal/ncurses apps. Not directly related to Xft I guess, but longer >> texts (email/rss feeds...) in monospace look rather unpleasant. It would >> be awesome if swk could reconcile the simplicity and efficiency of >> suckless tools with some basic regard for typography. >> -- >> > >
Re: [dev] libdraw development
On Wed, Sep 1, 2010 at 1:32 PM, Szabolcs Nagy wrote: >[snip] > the name could have been chosen with more care, but sane names > are usually taken Except that in this case the name is both insane *and* already taken by a sane library. uriel
Re: [dev] libdraw development
WTF is this 'libdraw' thing? So are you guys not only duplicating existing functionality implemented by p9p, but you are also confusingly using the same names? libdraw should be: http://man.cat-v.org/p9p/3/draw and that is what should be used as a portable drawing backend, and if more functionality is needed, patches should be submitted to Russ. uriel On Mon, Aug 30, 2010 at 6:44 PM, pancake wrote: > Recently I've been writing the X11 backend of swk, the suckless widget kit. > > After some lines of code I noticed that i was redoing stuff already done by > other projects and also in libdraw.. So I started mixing raw X code with > libdraw.. > > Actually I'm hacking in 'st' in order to add clipboard and selection > support, and > certainly... the way to get/set strings in clipboard in X really sucks, and > I don't > want to repeat it.. > > So, the proposal here is to join efforts between st, swk, sselp, dwm and > others > to use and enhace libdraw in order to reduce repeated code in all the > suckless > projects. > > I also liked to know if the libdraw author is open to contributions (can I > commit > it directly?). > > I would like to have functions in libdraw to work with clipboard, create > window > (already done in dc_window in swk) and other stuff. > > The next step would probably think in making different backends to libdraw > instead of dupping it in swk. > > Any feedback for this proposal? :) > > --pancake > >
Re: [dev] Stripping html from email
On Tue, Aug 24, 2010 at 4:45 PM, Kurt H Maier wrote: > MIME sucks; there's no nice way to deal with it. Indeed. http://harmful.cat-v.org/software/mime uriel
Re: [dev] [vp] A media website video player/fetcher
Very cool and useful! Thanks! uriel On Sun, Aug 15, 2010 at 11:18 AM, Kris Maglione wrote: > This is a cleaned up version of some of the scripts I've been using for a > long time to play videos from sites like YouTube. I use a key binding in my > browser to copy the video URL and run this script, which automatically runs > a media player with the given video. It can also fetch streaming videos. I > have another script that I use along with it to fetch a series of videos > (the dreaded multi-part uploads of YouTube fame), which I'm not uploading at > the moment. > > For now, the only sites supported are YouTube and Revision3, but I'm > releasing in the hope that others will find it useful and add more. I have > some others, but they're not remotely release ready. I'm well aware that > there are other such programs around, but they all tend to weigh in at > several thousand lines, and the logic for the individual sites is burried > somewhere in the middle. With vp, to add a new site, you just add a new vp-* > file, put the URL pattern at the top, and write whatever logic you need. > > The basic requirements are 9base or plan9port, curl, and, at the moment, a > javascript engine (spidermonkey or kjs) for the youtube script, although > I'll probably replace it with an awk script in the near future. > > hg clone http://hg.suckless.org/vp > cd vp > mk install > > -- > Kris Maglione > > You're bound to be unhappy if you optimize everything. > --Donald Knuth > > >
Re: [dev] off topic - awk versions performance comparison
On Sun, Aug 15, 2010 at 1:53 AM, Kris Maglione wrote: > On Sat, Aug 14, 2010 at 10:38:32PM +0200, Uriel wrote: >> >> On Sat, Aug 14, 2010 at 12:07 PM, Kris Maglione >> wrote: >>> >>> nawk is one-true-awk from FreeBSD. I find the results strange, namely >>> because Plan 9's awk is also one-true-awk. It also produces reasonable >>> results with "^y" instead of "y", while gawk doesn't. I know that nawk >>> uses >>> a combination NFA/DFA, but I see that Plan 9's awk instead pre-process >>> the >>> expression and uses Plan 9's pure-NFA engine. My guess is that, because >>> they're greedy algorithms, they both traverse the entire string looking >>> for >>> a possibly longer match, but my understanding of Plan 9's altorithm was >>> otherwise. >> >> I think one of the very few differences between Plan 9's awk and bwk's >> awk is UTF-8 support, not sure why that would make a difference, but I >> thought they were mostly identical otherwise. > > That's mostly true, but awk is still actively developed, and has had a lot > of changes in the 11 years since it was last synced with Plan 9. It also > uses an entirely different regular expression engine. Interesting, I thought they had done a sync more recently *sigh* And did't know about the completely different regexp engine. I'm a bit surprised because in my experience I had found that if anything Plan 9 awk's seemed to err more on the side of leaving things the way they were upstream, for example system() uses ksh instead of rc. uriel > -- > Kris Maglione > > The easy confidence with which I know another man's religion is folly > teaches me to suspect that my own is also. > --Mark Twain > > >
Re: [dev] off topic - awk versions performance comparison
On Sat, Aug 14, 2010 at 12:07 PM, Kris Maglione wrote:
> On Wed, Aug 11, 2010 at 03:06:13PM -0400, Joseph Xu wrote:
>>
>> I was using GNU tr. The input files were single lines with 1 or
>> 100 y's, so I was doing 100 matches in each case (from the for loop) on
>> the same line. I guess I should have made that more explicit, sorry. I'm
>> interested in what results you're getting.
>
> Sorry, I get tetchy when I haven't had enough sleep:
>
> 0.00u 0.00s 0.00r nawk {for (i=1; i < 100; i++) { match($0, "y")} }
> big
> 0.01u 0.00s 0.02r nawk {for (i=1; i < 100; i++) { match($0, "y")} }
> bigger
> 0.08u 0.00s 0.08r gawk {for (i=1; i < 100; i++) { match($0, "y")} }
> big
> 7.80u 0.03s 8.08r gawk {for (i=1; i < 100; i++) { match($0, "y")} }
> bigger
> 0.04u 0.00s 0.05r /usr/local/plan9/bin/awk {for (i=1; i < 100; i++) {
> match($0, "y")} } big
> 5.00u 0.01s 5.20r /usr/local/plan9/bin/awk {for (i=1; i < 100; i++) {
> match($0, "y")} } bigger
>
> nawk is one-true-awk from FreeBSD. I find the results strange, namely
> because Plan 9's awk is also one-true-awk. It also produces reasonable
> results with "^y" instead of "y", while gawk doesn't. I know that nawk uses
> a combination NFA/DFA, but I see that Plan 9's awk instead pre-process the
> expression and uses Plan 9's pure-NFA engine. My guess is that, because
> they're greedy algorithms, they both traverse the entire string looking for
> a possibly longer match, but my understanding of Plan 9's altorithm was
> otherwise.
I think one of the very few differences between Plan 9's awk and bwk's
awk is UTF-8 support, not sure why that would make a difference, but I
thought they were mostly identical otherwise.
uriel
> Looking at gawk, it also uses a DFA algorithm, so I really can't
> explain the shortcoming, especially when the anchor is used, but I refuse to
> look deeper because gawk is written to GNU coding standards and I value my
> sanity.
>
> As for my previous result, I have a shell function defined that replaces awk
> with nawk, and it seems that I called awk rather than gawk explicitly.
>
> Oh, and looking at my sig, it's serenditipously by BWK...
>
> --
> Kris Maglione
>
> As we said in the preface to the first edition, C "wears well as one's
> experience with it grows." With a decade more experience, we still
> feel that way.
> --Brian Kernighan and Dennis Ritchie
>
>
>
Re: [dev] [patch] xmms like pattern matching for dmenu (update to hg tip)
This seems like a rather clumsy, non-standard and silly way to implement globbing. Implementing * and ? wildcards would be a much better idea. uriel On Sat, Aug 7, 2010 at 3:20 PM, StephenB wrote: > see: (this patch is against 352) > http://pastebin.com/raw.php?i=4sh7ZTuJ > I use this all the time for uzbl browser history and bookmarks. > regards, > StephenB
Re: [dev] [patch] add Control-G and Control-D to dmenu
On Mon, Aug 9, 2010 at 1:07 PM, Connor Lane Smith wrote: > Hey, > > On 8 August 2010 09:22, Uriel wrote: >> Both are emacsisms as far as I can tell, and of little use (specialy >> given ^C already aborts). > > ^D isn't an emacsism insofar as using it in bash when not at the end > of the line works the same way. That said, I'm aware bash is a > monster. However: Just because some other retarded piece of GNU/crap implements it doesn't make it any less an emacsism. > > On 8 August 2010 11:54, Uriel wrote: >> Indeed, ^D meaning anything other than EOF is an abomination. > > I'm not prepared to limit myself to relics for the sake of it. dmenu > has no files of which to reach the end, so EOF is simply meaningless. > If we restricted ^D to solely EOF then it would be a dead key. On the > other hand, dmenu has a cursor, which 1970 teletypes did not have, and > so requires keybinds for its control. If Bell Labs UNIX had had a > terminal cursor I'm sure they would have provided the keybinds > necessary to use it. I don't believe pragmatism is abominable. This is a totally retarded argument, Plan 9 terminals do have a cursor, and certainly don't implement every retarded stupid keybinding imaginable, specially not ones that conflict with one of the most generally accepted and used keybindings. Also ^D makes perfect sense in dmenu, it means *end of input*, it works when you type cat(1) in any *nix terminal, even totally retarded ones like xterm. To do anything else with ^D is not pragmatism, it is totally retarded GNU/idiocy. uriel > Thanks, > cls > >
Re: [dev] [patch] add Control-G and Control-D to dmenu
On Sun, Aug 8, 2010 at 10:39 AM, Kris Maglione wrote: > On Sun, Aug 08, 2010 at 10:22:05AM +0200, Uriel wrote: >> >> On Fri, Aug 6, 2010 at 3:18 PM, Connor Lane Smith wrote: >>> >>> Hey, >>> >>> On 06/08/2010, Daniel Clemente wrote: >>>> >>>> This adds C-d (delete next char) and C-g (abort) to dmenu. These keys >>>> are >>>> also used in programs like bash or Emacs. >>> >>> I've added C-d but not C-g, since it seems like an emacsism. >> >> Both are emacsisms as far as I can tell, and of little use (specialy >> given ^C already aborts). > > So do Escape and ^[. C-g, unfortunately, is also used by mutt, which doesn't > recognize at all. C-d means EOF. It's always meant EOF and I've never > known it to mean delete-char, although I'm aware that in emacs it does. Indeed, ^D meaning anything other than EOF is an abomination. > >> For the 'canonical' list of Unix keybindings see: http://unix-kb.cat-v.org > > Whose canon? My canon ;P uriel > -- > Kris Maglione > > If you think your management doesn't know what it's doing or that your > organisation turns out low-quality software crap that embarrasses you, > then leave. > --Edward Yourdon > > >
Re: [dev] [patch] add Control-G and Control-D to dmenu
On Fri, Aug 6, 2010 at 3:18 PM, Connor Lane Smith wrote: > Hey, > > On 06/08/2010, Daniel Clemente wrote: >> This adds C-d (delete next char) and C-g (abort) to dmenu. These keys are >> also used in programs like bash or Emacs. > > I've added C-d but not C-g, since it seems like an emacsism. Both are emacsisms as far as I can tell, and of little use (specialy given ^C already aborts). For the 'canonical' list of Unix keybindings see: http://unix-kb.cat-v.org uriel > Thanks, > cls > >
Re: [dev] curses samterm
On Tue, Aug 3, 2010 at 12:26 PM, Robert Ransom wrote: > On Tue, 3 Aug 2010 12:01:24 +0200 > Uriel wrote: > >> Anyone that considers for even one second to use nano should be taken >> out and shot on the spot. > > It's not so bad if you build it with the --disable-wrapping-as-root > configure option and only use it as root. > > > > In case you're wondering why I know *that*, nano is the least bad > editor on the standard Arch Linux install CD image (the others are joe > and traditional, breaks-if-you-push-a-cursor-key-in-insert-mode vi; > I'd be happy with ed, but they didn't provide it), What the fuck?!?!? Everyone involved in the development of lunix distributions that don't include ed as one of its most core programs should have their liver devoured by harpies and their testicles infested by maggots for the rest of eternity, Prometheus-style. uriel > and I just peeked at > the PKGBUILD to see if the Arch folks had needed to patch /etc/nanorc > to make it stop mangling long lines. Apparently not... > > Robert Ransom >
Re: [dev] curses samterm
On Tue, Aug 3, 2010 at 6:41 AM, Wolf Tivy wrote: > I find it useful to be able to edit files using my regular editor > after I break X, or if I don't feel like starting it up. > I like curses stuff even in X because it is nice to open up an editor > and have it tempoarily reuse the terminal window without spawning > another and thrashing my layout. Furthermore, as a bit of an > aesthetic concern, curses editors inherit the color configuration of > the terminal, which is convienient if you are into making things look > nice. > > It was suggested before that a curses interface would be a good > idea, so I am assuming that I am not the only person who would > appreciate it. > > I might be happy with the p9p samterm, but I can't figure out how > to get it standalone from the rest of p9p, or what kind of Sam has run on lunix since long before p9p existed. apt-get install sam should work, it is a somewhat old version of sam, but all the functionality should be there. > aesthetic variations are possible (font?, color?). These issues are > not that big on thier own, but combined with the whole X-dependant > thing, it just doesn't seem worth it. > > So that's my view on why a curses samterm is a good idea. > If noone is interested, I will survive with nano, but if people are > interested or if someone has started, I'm willing to throw some > time at it. Anyone that considers for even one second to use nano should be taken out and shot on the spot. uriel > - Original Message - > From: Joseph Xu > Date: Monday, August 2, 2010 5:30 pm > Subject: Re: [dev] curses samterm > To: dev@suckless.org > >> Under what circumstance would you not be able to run sam's gui >> and have >> to resort to a curses interface? sam already provides a way to >> connect >> the gui to a remote host via ssh to edit files over a slow >> connection. >> I've even done this with an old Windows port of sam running >> locally and >> a remote linux host with p9p sam. So the only reason is if you >> don't >> want to run X on your local computer, which seems ridiculous >> nowadays. >> Rob Pike wrote sam in part because he didn't like having to >> cursor >> around in vi. >> > >
Re: [dev] How about sta.li ? - libc tangent
On Sun, Aug 1, 2010 at 11:36 PM, yy wrote: > 2010/8/1 Ethan Grammatikidis : >> >> Along with support servers this could >> ultimately give a very complete Plan 9 experience without any of the >> performance issues of virtualisation or the other issues of 9vx. > > Do you know what would give a more complete Plan 9 experience? Plan 9. > > I can see the beauty of a GNU-free staticly linked system, it is > indeed an interesting project, but it woulld not be too useful for me. > The reason I use p9p/9vx on top of unix is because of all the shit I > cannot run on a native Plan 9 system, and all that shit (X and web > browsers included) is from my pov the real challenge of the project. > But why running Plan 9 tools on top of a crippled Unix? I'd really > like to know a real use-case where neither a native system neither > glibc are feasible solutions. Most werc setups are an example of real use cases where one wants to run Plan 9 user space tools on linux (due to hosting/hardware-support/performance/web-server issues) while one wants to avoid glibc mainly because it makes static linking really hard, and dynamic linking makes fork/exec SLOW. uriel > > That said, it would probably be easier to fix the issues with 9vx than > what you are proposing. Performance is not a real problem, and it can > be improved. Bugs can be fixed (let me know if you find any issues). > And if 9vx does not fullfill your expectations, just use the real > thing. > > -- > - yiyus || JGL . 4l77.com > >
Re: [dev] How about sta.li ? - libc tangent
On Sun, Aug 1, 2010 at 8:00 PM, Anselm R Garbe wrote: > On 1 August 2010 12:35, Ethan Grammatikidis wrote: >> On 1 Aug 2010, at 8:43, pancake wrote: >> >>> I want to say that in latest glibc (see archlinux) many 9base programs >>> cant be executed because of being static. >> >> I sent the other mail off & then I thought, are you talking about finding a >> sane libc for any linux, not just sta.li? I've been thinking about it >> lately, needing to avoid glibc, OS X's libc, and gcc for various reasons >> including the dynamic linking issue. There are C compilers with the Go >> distribution which will produce Linux and OS X executables, but no libc, and >> that started me thinking, specifically with the goal of getting a statically >> linked p9p on one machine and a completely glibc-free p9p/9base and inferno >> on another. >> >> Perhaps it's a mad thought, but what about building a p9p-alike on top of a >> modified, ported Plan 9 libc? I expect most of the system calls would pose >> no more trouble than in p9p. It's work to be done over again, borrowing >> methods from p9p, but some parts will actually be easier. For example, the >> Linux kernel's clone system call is far closer to plan 9's fork() than posix >> threads clone() interface is. > > I think one decision in p9p was to provide something considerable > portable, not just Linux-tight. This decision wasn't bad at all and > allows to run it on Darwin, many BSDs and some other Unices. The Go runtime, which produces statically linked binaries which do not use the system's libc, shows that one can build something that can be ported to other systems while completely bypassing the system's libc. uriel > Anyways I see the point in migrating to a more suitable libc base. > bionic seems nice and shouldn't be too limited, but it won't be as > portable as uclibc for instance, which is still my favorite and fairly > feature complete for what exists. > > Cheers, > Anselm > >
Re: [dev] How about sta.li ? - libc tangent
> Perhaps it's a mad thought, but what about building a p9p-alike on top of a > modified, ported Plan 9 libc? I expect most of the system calls would pose no > more trouble than in p9p. It's work to be done over again, borrowing methods > from p9p, but some parts will actually be easier. For example, the Linux > kernel's clone system call is far closer to plan 9's fork() than posix > threads clone() interface is. This is quite similar to what the Go runtime itself does: it bypasses libc on all systems and instead has a portability layer that calls the relevant syscalls for each supported platform. It makes portability harder, but this days when only linux and perhaps OS X and some BSD matter, this is not a big deal (even the current p9p way of doing things has not helped portability to systems like solaris, and Windows, while Go has already been ported to Windows). On the other hand the Go people have found that completely bypassing the libc can be a pain because one has to re-implement all the braindead functionality of things like the resolver (including parsing of /etc/hosts, and what if the system is configured to use ldap, or god knows what?). But not supporting such retarded setups might be also considered a feature... uriel uriel On Sun, Aug 1, 2010 at 1:35 PM, Ethan Grammatikidis wrote: > > On 1 Aug 2010, at 8:43, pancake wrote: > >> I want to say that in latest glibc (see archlinux) many 9base programs >> cant be executed because of being static. > > I sent the other mail off & then I thought, are you talking about finding a > sane libc for any linux, not just sta.li? I've been thinking about it > lately, needing to avoid glibc, OS X's libc, and gcc for various reasons > including the dynamic linking issue. There are C compilers with the Go > distribution which will produce Linux and OS X executables, but no libc, and > that started me thinking, specifically with the goal of getting a statically > linked p9p on one machine and a completely glibc-free p9p/9base and inferno > on another. > > Perhaps it's a mad thought, but what about building a p9p-alike on top of a > modified, ported Plan 9 libc? I expect most of the system calls would pose > no more trouble than in p9p. It's work to be done over again, borrowing > methods from p9p, but some parts will actually be easier. For example, the > Linux kernel's clone system call is far closer to plan 9's fork() than posix > threads clone() interface is. > > I figure it could go one of two ways. One way some functionality would be > disabled, giving a very p9p-like result. I called this 9libc. The other way, > a 9p multiplexer server could be made. Along with support servers this could > ultimately give a very complete Plan 9 experience without any of the > performance issues of virtualisation or the other issues of 9vx. I called > this Under9. Under9 is distinct from Glendix in that Glendix is > Linux-specific, which doesn't make me happy and appears make more work for > the maintainers. Under9 ought to work with any kernel the libc has been > ported to. Also, Under9 need not try to load Plan 9 format binaries if that > turns out to be inefficient. > > So I have more project names than code, here. I wasn't planning on bringing > up these ideas until I at least had a good idea of what would be involved in > porting the libc, but the topic kinda came up. > >
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Tue, Jul 27, 2010 at 1:29 AM, Kris Maglione wrote: > On Mon, Jul 26, 2010 at 11:09:22PM +0100, Anselm R Garbe wrote: >> >> I think the right thing to do would be to extend Rule and applyrules() >> with support for WM_WINDOW_ROLE. However I doubt that many client make >> actually use of WM_WINDOW_ROLE in a consistent way, which is why I >> believe there is no great benefit in doing so -- or in other words, >> yet another proof how hideous X has become ;) > > Has become? It was so from the start, and I'm really not certain it's > possible for it to have become worse. There are certain depts of depravity > in software that are impossible to surpass without resorting to Java. I think somehow X managed to surpass its own hideousness without resorting to Java thanks to things like the use of XML by fontconfig, and the auto*hell-ization of the whole X.org distribution. uriel > At any > rate, WM_WINDOW_ROLE isn't meant to be used consistently, it's meant for > session managers to allow clients to restore their individual windows. > Personally, though, I'd just allow matching rules against arbitrary > properties. > > -- > Kris Maglione > > I speak to everyone in the same way, whether he is the garbage man or > the president of the university. > --Albert Einstein > > >
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Mon, Jul 26, 2010 at 11:32 PM, David DEMELIER wrote: > Hello dear dwm users, > > Of coure we could use the `title' rules but it's different on each > locale you are using so it sucks as well. Yay! One more reason why locales are totally and terminally braindead! (As if we needed any more reasons...) uriel > I would like to write a patch but for the moment I don't find the good > function that handle WM_WINDOW_ROLE. > > With kind regards. > > -- > Demelier David > >
Re: [dev] plumb 1.0
On Thu, Jul 15, 2010 at 11:17 AM, Mate Nagy wrote: > On Thu, Jul 15, 2010 at 11:10:36AM +0200, Christoph Lohmann wrote: >> Hi, >> your »plumb« looks like the Plan 9 plumber[0] done wrong, >> whereas your »plumbnet« is a wrong done socat[1] or >> ncat[2]. Those tools do network right and allow further >> configuration, like encryption, wrappers, filters, etc., >> which your application will only find out on purpose, if >> anyone needs it. > > apparently you haven't read any of my mails or the man pages, because > what plumb does has little relation to the plan9 plumber - and it does > it on linux where these facilities are unavailable anyway. I just want to point out that the Plan 9 plumber works on Linux as part of Plan 9 from User Space: http://plan9.us uriel > > furthermore, plumbnet's functionality is not easily reproducible with > either socat or similar tools (this is why i wrote it in the first > place). > > Best regards, > Mate > >
Re: [dev] [wmii] Locale problem with "uptime" (loadavg in status bar) and a suggestion
On Wed, Jul 14, 2010 at 7:56 PM, nico wrote: > Hmm, actually I never had problems setting the locale. I always have LANG > and LC_MESSAGES set to en_US.UTF-8 so language is still english and the > other variables are set to de_DE.UTF-8 so information many apps do rely on > like paper size, currency, punctuation (the fail in my case), address format > and stuff like that is correct. So I'm just going to use a different uptime > parsing method or is anyone having a better idea? Again, stop trying to 'use' the PoSix locale system for anything, it is completely broken and totally antithetical to how Unix is designed to work. An option would be to use p9p's user space instead of the usual GNU crap. uriel > > Am 14.07.2010 17:44, schrieb Ethan Grammatikidis: >> >> On 14 Jul 2010, at 13:31, Uriel wrote: >> >>> If you set locales to retarded values (anything other than >>> C/UTF-8/en_US), shit will break. >>> >>> Stop this crap, locales are an abomination. >> >> *nods* The output of unix commands is just as much API as UI, so applying >> locale conversions to them is hairy at best. >> >>> >>> uriel >>> >>> On Wed, Jul 14, 2010 at 2:08 PM, nico wrote: >>>> >>>> Hello there, >>>> >>>> i changed my systems locales to de_DE.UTF-8 and now the command "uptime" >>>> is using "," instead of "." because of LC_NUMERIC now being set to >>>> German >>>> too. As a result of this the loadavg part of the default statusbar looks >>>> like "131 087 071" (no dots since commas are removed by sed). >>>> I have tried several things to make it work but I was not sucessful. >>>> LC_NUMERIC _must_ be exported to make it work correctly, since uptime is >>>> called from a subshell. Exporting LC_NUMERIC to an English locale is not >>>> an >>>> option. >>>> >>>> Now, I don't know how to make that status command respecting a different >>>> locale. >>>> Changing the sed command to something more complex would surely work but >>>> I >>>> am posting this here since this was no issue with wmii 3.6 yonks ago and >>>> maybe other people run into this too. Any suggestions how to handle >>>> this? >>>> >>>> Secondly, a small suggestion: >>>> I would like to have something like a small indication if there are any >>>> floating windows hidden "behind" the managed layer if the latter is >>>> toggled >>>> active (currently there is none and it's quite possible to forget about >>>> the >>>> floating windows ;) Maybe a "~" in the tags name like the "*" if a >>>> window >>>> is requesting attention. Don't know if this is possible but I hope you >>>> get >>>> what I mean. >>>> >>>> regards, >>>> nico >>>> >>>> >>> >> >> > > > -- > regards, > nico > > >
Re: [dev] plumb 1.0
While this seems like an interesting project, I would strongly urge you to change the name, "Plumb" is already used by a way too similar project and will just cause confusion: http://doc.cat-v.org/plan_9/4th_edition/papers/plumb uriel On Wed, Jul 14, 2010 at 6:00 PM, Mate Nagy wrote: > Hello all, > > here I am advertising my own personal project. (Technically it's a > complete rewrite, the old version was announced here once before.) > > Home page: http://repo.hu/projects/plumb/ > > Plumb is a program that runs multiple processes and lets you define > arbitrary pipes between them (it uses libevent to manage the data > transfer). > > The major new feature in the rewrite is that it has a fairly comfy > "control language" that it can also read from pipes in runtime; this > means that a program running under Plumb can start new processes, shut > down old ones, create or kill pipes. > > The simplest, most common application would be to start two processes > and connect them in a "69" configuration - STDIN to STDOUT of the other. > This is how you can use Animator (http://repo.hu/projects/animator/) > to write simple interactive apps. > > A slightly more complex application: I wrote an interactive, graphical > Gopher client in AWK. It uses Animator for the display, and spawns nc > for downloads as needed. Multiple downloads can be ongoing at the same > time. It manages all this from a simple AWK script that does nothing > else but read from STDIN and write to STDOUT. > > There's another tool that is part of the "Plumb package", called > plumbnet. It's a TCP server that listens on a port and accepts > multiple connections at once (again, using libevent). > It writes lines received from connections to STDOUT, and reads > lines to send on its STDIN. Connections are distinguished by > integer connection ID prefixes in either direction. > > You'd tipically use plumbnet by wiring it together with your program > using Plumb. It may be a good alternative to inetd, when you > want to accept multiple TCP connections but there is common state > (so you'd have to do some sort of IPC, or write a complete network > daemon from scratch). > > Plumb basically lets you use STDIN/STDOUT in new and flexible ways. > Most of this was possible to do before by hand (e.g. by using mkfifo), > but with Plumb, it should be much more comfortable. I don't know, > it might even serve to connect a controlling script with a window > manager, so the wm logic is moved outside the core wm :) > > The core use case is probably the "hack up something fast" "i really > like AWK" "i'm at a programming compo" scenario. > > Suggestions/complaints/bug reports/flame is very welcome as usual > (except regarding the license or VCS ;) > > Thanks for reading, > Mate > >
Re: [dev] [wmii] Locale problem with "uptime" (loadavg in status bar) and a suggestion
If you set locales to retarded values (anything other than C/UTF-8/en_US), shit will break. Stop this crap, locales are an abomination. uriel On Wed, Jul 14, 2010 at 2:08 PM, nico wrote: > Hello there, > > i changed my systems locales to de_DE.UTF-8 and now the command "uptime" > is using "," instead of "." because of LC_NUMERIC now being set to German > too. As a result of this the loadavg part of the default statusbar looks > like "131 087 071" (no dots since commas are removed by sed). > I have tried several things to make it work but I was not sucessful. > LC_NUMERIC _must_ be exported to make it work correctly, since uptime is > called from a subshell. Exporting LC_NUMERIC to an English locale is not an > option. > > Now, I don't know how to make that status command respecting a different > locale. > Changing the sed command to something more complex would surely work but I > am posting this here since this was no issue with wmii 3.6 yonks ago and > maybe other people run into this too. Any suggestions how to handle this? > > Secondly, a small suggestion: > I would like to have something like a small indication if there are any > floating windows hidden "behind" the managed layer if the latter is toggled > active (currently there is none and it's quite possible to forget about the > floating windows ;) Maybe a "~" in the tags name like the "*" if a window > is requesting attention. Don't know if this is possible but I hope you get > what I mean. > > regards, > nico > >
Re: [dev] merp is a loneliness mitigation device written in python and Tk
Copy-paste with the host doesn't work by default because apparently making people's lives miserable is the main task of Inferno. As Kris pointed out, this work fine in acme-sac, and all that really is required is a single command (mounting the host's clipboard) in your startup scripts. But don't expect this to be fixed in the next ten years, so just use acme-sac ;) uriel On Wed, Jul 14, 2010 at 4:33 AM, Ethan Grammatikidis wrote: > Sorry, clicked in the wrong place & sent a blank reply. > > On 14 Jul 2010, at 03:03, Uriel wrote: > >> Also if somebody doesn't like the Inferno GUI for ircfs, it should be >> trivial enough to write another one. >> >> Running ircfs on a server, and attaching to it from different clients >> should work fine. >> >> uriel >> >> On Wed, Jul 14, 2010 at 1:08 AM, hiro <23h...@googlemail.com> wrote: >>> >>> Ok, I thought you were talking about wm/ircfs which extraordinarily >>> uses classic plan9 chording commands >>> >>> >> > > If that's the case, it's not wm/ircfs I need to write a new GUI for. Maybe I > should look into writing one for wm/sh. I really hope it's as trivial as > Uriel says. > > There is still the issue of no copy/paste with the host.. heh, I can try to > see if I can do anything about that. > >
Re: [dev] merp is a loneliness mitigation device written in python and Tk
Also if somebody doesn't like the Inferno GUI for ircfs, it should be trivial enough to write another one. Running ircfs on a server, and attaching to it from different clients should work fine. uriel On Wed, Jul 14, 2010 at 1:08 AM, hiro <23h...@googlemail.com> wrote: > Ok, I thought you were talking about wm/ircfs which extraordinarily > uses classic plan9 chording commands > >
Re: [dev] merp is a loneliness mitigation device written in python and Tk
The ircfs site t is up now: http://www.ueber.net/code/r/ircfs ircfs is great, and its gui is great too, and mjl is a great hacker. And does the world really need yet another python irc client? And I'm not sure what makes merp particularly 'suckless' (whatever anything written in Python can be 'suckless' is very questionable). But I do praise the choice of Tk for the gui. uriel On Mon, Jul 12, 2010 at 4:24 PM, hiro <23h...@googlemail.com> wrote: > The old wmii community probably knows that one well enough, but for > all the others I'd like to promote ircfs from Mechiel Lukkien. It runs > on inferno and includes a 9p server and tk client. > Sadly his site is currently down, but here's a paper from him: > http://4e.iwp9.org/papers/ircfs.pdf > >
Re: [dev] Presentation slides software
On Tue, Jul 6, 2010 at 3:13 PM, Claudio M. Alessi wrote: > On Sun, Jul 04, 2010 at 02:13:38PM +0200, Uriel wrote: >> I honestly and deeply hope you fail completely. > Please, put this on quotes.cat-v.org. Nah, it is not quotes worthy, but I added it to: http://fortunes.cat-v.org/cat-v/ uriel > > Claudio M. Alessi > > >
Re: [dev] Presentation slides software
On Sun, Jul 4, 2010 at 11:58 AM, Catalin David wrote: > Hello all! > > I am actually a student that used to work on this stuff. In our > research group, we were mainly interested in transforming the arXiv ( > www.arxiv.org) to XHTML + MathML via LaTeXML ( > http://dlmf.nist.gov/LaTeXML/ ) What you are doing is a truly evil thing. A certainly interesting project, from the point of view of trying to understand how and why would any human being take up such an abominable task. I honestly and deeply hope you fail completely. uriel > so that it can be displayed on the web > (build system page: http://arxmliv.kwarc.info -- down now due to > maintenance). > > What you might be interested in is this paper that we wrote a while > back for a workshop (DML 09): > http://kwarc.info/kohlhase/submit/dml09.pdf that tackles exactly this > issue, transforming LaTeX to XHTML+MathML. > > Please let me know on what you think or if you have any more questions, > > Catalin > > On Sat, Jul 3, 2010 at 7:17 PM, Uriel wrote: >> On Tue, Jun 29, 2010 at 5:04 PM, Kris Maglione wrote: >>> On Tue, Jun 29, 2010 at 12:34:52PM +0200, Uriel wrote: >>>> >>>> I'm looking for a minimally sane way to generate presentation slides, >>>> ideally using something similar to markdown and capable of generating >>>> decent-looking html (and hopefully) pdf. >>>> >>>> I know about magicpoint, and I normally use the troff slides macros: >>>> http://repo.cat-v.org/troff-slider/ >>>> >>>> But the generated HTML is rather messy, and fixing htmlroff is too much >>>> work. >>> >>> Have you tried generating a PDF and using one of the PDF to HTML converters? >> >> Do you know of any PDF to HTML converter that is not crap? Because I >> have been looking for such a thing for years, and would love to have >> one, but I'm starting to suspect such a thing is impossible. >> >>> They tend to work fairly well with PDFs generated by programs like troff, >> >> Not in my experience, but again I'm really happy to hear suggestions >> for good PDF to HTML converters. >> >> uriel >> >>> though I don't expect it'd be nearly as clean as that generated by markdown. >>> I use TeX myself, which has some fairly good HTML generators these days. >>> >>> -- >>> Kris Maglione >>> >>> Two things are infinite: the universe and human stupidity; and I'm not >>> sure about the universe. >>> --Albert Einstein >>> >>> >>> >> >> > > > > -- > ** > Catalin David > B.Sc. Computer Science 2010 > Jacobs University Bremen > > Phone: +49-(0)1577-49-38-667 > > College Ring 4, #343 > Krupp College B-313 > Bremen, 28759 > Germany > ** > >
Re: [dev] Presentation slides software
On Tue, Jun 29, 2010 at 5:04 PM, Kris Maglione wrote: > On Tue, Jun 29, 2010 at 12:34:52PM +0200, Uriel wrote: >> >> I'm looking for a minimally sane way to generate presentation slides, >> ideally using something similar to markdown and capable of generating >> decent-looking html (and hopefully) pdf. >> >> I know about magicpoint, and I normally use the troff slides macros: >> http://repo.cat-v.org/troff-slider/ >> >> But the generated HTML is rather messy, and fixing htmlroff is too much >> work. > > Have you tried generating a PDF and using one of the PDF to HTML converters? Do you know of any PDF to HTML converter that is not crap? Because I have been looking for such a thing for years, and would love to have one, but I'm starting to suspect such a thing is impossible. > They tend to work fairly well with PDFs generated by programs like troff, Not in my experience, but again I'm really happy to hear suggestions for good PDF to HTML converters. uriel > though I don't expect it'd be nearly as clean as that generated by markdown. > I use TeX myself, which has some fairly good HTML generators these days. > > -- > Kris Maglione > > Two things are infinite: the universe and human stupidity; and I'm not > sure about the universe. > --Albert Einstein > > >
[dev] Presentation slides software
I'm looking for a minimally sane way to generate presentation slides, ideally using something similar to markdown and capable of generating decent-looking html (and hopefully) pdf. I know about magicpoint, and I normally use the troff slides macros: http://repo.cat-v.org/troff-slider/ But the generated HTML is rather messy, and fixing htmlroff is too much work. Suggestions welcome. Peace uriel
Re: [dev] ji - ii-like jabber client
On Thu, Jun 24, 2010 at 4:59 PM, Kurt H Maier wrote: > jj requires glib. if ji doesn't, I already like it better. People that write programs that depend on glib should be taken out and shot, probably followed by those that write XMPP clients (and servers, and anything else that interacts with XMPP). The only remotely sane way to deal with the abominable monster that is Jabber is to use bitlbee or some other IRC gateway. uriel
Re: [dev] picture
On Mon, Jun 21, 2010 at 8:34 PM, Christoph Lohmann <2...@r-36.net> wrote: > Hi list, > > Anselm R Garbe wrote: >> >> On 21 June 2010 17:27, Uriel wrote: >>> >>> On Mon, Jun 21, 2010 at 12:56 PM, anonymous wrote: >>>> >>>> On Sun, Jun 20, 2010 at 09:46:12PM +0200, ⚖ Alexander "Surma" Surma >>>> wrote: >>>>> >>>>> I was just about to ask, Creatives Common BY-SA? >>>> >>>> Already discussed on this list, but for software instead of art. >>>> Unlicense[1] for software, >>> >>> While in principle I like the idea of the 'unlicense', its legal value >>> is very questionable. For software and code sticking with the classic >>> BSD/MIT/ISC licenses is a much better idea. >>> >>> I personally 'dual-license' my code as ISC and then release it to the >>> public domain. >> >> I kind of liked the license 20h was using in the past: >> >> "Copy me if you can" > > it is not a license. I am pretending that everyone's considering > my work public domain. It is a post-license. Because of a lawyer, > who analyzed this[0], regarding Geomyidae, I changed all maybe > useful code to MIT/X. > MIT/X is the best balance between "Keep respect to me." and "Kim- > Jong Uriel", yes, build your physical package with it.". Hahaha, this made my day, added it to the cat-v fortunes file: http://fortunes.cat-v.org/cat-v/ uriel > Sincerely, > > Christoph > > [0] > http://blog.iusmentis.com/2008/09/29/geomyidae-publiek-domein-behalve-als-u-niet-netjes-handelt/ > > >
Re: [dev] picture
On Mon, Jun 21, 2010 at 12:56 PM, anonymous wrote: > On Sun, Jun 20, 2010 at 09:46:12PM +0200, ⚖ Alexander "Surma" Surma wrote: >> I was just about to ask, Creatives Common BY-SA? > > Already discussed on this list, but for software instead of art. > Unlicense[1] for software, While in principle I like the idea of the 'unlicense', its legal value is very questionable. For software and code sticking with the classic BSD/MIT/ISC licenses is a much better idea. I personally 'dual-license' my code as ISC and then release it to the public domain. uriel > CC0[2] for art if you want to place your > work into "public domain" and allow anyone do to anything with it. > > [1] http://unlicense.org/ > [2] http://creativecommons.org/publicdomain/zero/1.0/ > > >
Re: [dev] picture
On Sun, Jun 20, 2010 at 11:54 PM, Kris Maglione wrote: > Not that there's anything wrong with BY-SA or any other CC licenses. It's a > matter of personal preference (though I'm personally never fond of SA-type > clauses, especially when they take on a viral bent). It is not a matter of personal preference, it has many of the same problems as the GPL, with the added confusion and complication of much worse license-proliferation. That some CC licenses don't even allow 'commercial use' (as if this could be defined!) should be enough of a red flag to stay away from the whole lot. CC0 on the other hand is quite different and is very useful, and everyone should use it if they want to allow as many people as possible to use their work but don't want to spend a lifetime learning all the retarded legal braindamage spread all over the world. uriel
Re: [dev] picture
On Sun, Jun 20, 2010 at 11:16 PM, Ethan Grammatikidis wrote: > > On 20 Jun 2010, at 22:08, ⚖ Alexander Surma Surma wrote: > >> The problem with public domain is, that it's not really global (some >> country behave differently). > > I used this in rc-httpd: > > LICENSE > > None. rc-httpd is in the public domain, I give up all rights to it. > For countries without a concept of public domain, consider it entirely > without owner. > > If anyone sees any problems with it, I'd like to know. Are you a lawyer with expertise in the arcane rules of copyright in every country? No, then don't think you can pull a 'license' or 'disclaimer' out of your ass that will be worth anything. People already have done the homework, either use CC0 (or MIT/BSD/ISC license) or ignore the problem and just say 'public domain' and to hell with people living in countries with terminally braindead copyright laws. uriel
Re: [dev] picture
Public domain, or if you really love CC, use CC0, all their other licenses are crap. uriel 2010/6/20 ⚖ Alexander "Surma" Surma : > I was just about to ask, Creatives Common BY-SA? > > On Sun, Jun 20, 2010 at 9:20 PM, Daniel Baumann wrote: >> On 06/20/2010 05:26 PM, Martin Kopta wrote: >>>> May I post this to another list? I think it's great ;) >>> Yes, of course. I can send you vectors if you want to. >> >> please do so, bonus points for publishing it under a free license. >> >> Regards, >> Daniel >> >> -- >> Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist >> Email: daniel.baum...@panthera-systems.net >> Internet: http://people.panthera-systems.net/~daniel-baumann/ >> >> > > > > -- > Alexander "cussing-makes-my-arguments-even-more-valid" Surma > >
Re: [dev] [9base] rc can't find .
On Fri, Jun 11, 2010 at 12:43 PM, Jan Winkelmann wrote: > Looks like this is some weird GCC/glibc/binutils error (correct me if > I'm wrong). When in doubt, blaming GCC is a safe bet: http://harmful.cat-v.org/software/GCC But in this case it seems that the glibc monkeys have surpassed their GCC brothers in their skill at fucking shit up. *sigh* uriel
Re: [dev] Suckless operating system
On Tue, Jun 15, 2010 at 4:18 PM, Kris Maglione wrote: > On Tue, Jun 15, 2010 at 04:05:24PM +0200, Dieter Plaetinck wrote: >> >> What's wrong with arch hurd? > > The HURD part, obviously. s/H/T/ uriel
Re: [dev] Re: XDG directories
On Fri, Jun 11, 2010 at 4:09 PM, David Engster wrote: > The problem is that data is even more spread than it was before, and > often cannot be tracked anymore to the application which generated > it. So if you're worried about applications littering your $HOME with > dotfiles, you now have a littered .local/share and often do not even > know if you can delete that stuff. I completely agree. It seems that they have taken what used to be a minor annoyance, and converted it into an incomprehensible kafkian nightmare that will haunt us for decades to come. Even if you really hate our lusers, implementing this 'standard' is a punishment that not even they deserve. uriel
Re: [dev] [OT] glibc (was: [9base] rc can't find .)
On Fri, Jun 11, 2010 at 1:02 PM, Moritz Wilhelmy wrote: > Do we have feature-complete alternatives to GNU libc? > eglibc is not an option, since it's based solely on the point that Drepper is > an asshole. > From what I heard, uClibc is incomplete, as is klibc and dietlibc.. > What else do we have? Android libc? How many programs depend on glibc? One of my favorite things about Go is that it completely bypasses the system's libc, and its core libraries and runtime all make use of the system's syscalls directly. So, the answer to your question is: start writing all your code in Go ;) uriel P.S.: Other than that, no 'libc' is 'complete' as PoSix is an insane abomination, and the more complete a libc is, the more it sucks. The android libc is quite minimal and seems quite decent, uClibc is *huge* (hundreds of thousands of lines of code), dietlibc is smaller and cleaner, but more limited, I have not checked klibc, but given that Al Viro has been involved in that project, it is probably pretty good, but I think it is quite specialized (and probably not portable to non-lunix systems).
Re: [dev] [9base] rc can't find .
werc is not meant to be called from the command line (unless you setup some kind of fake cgi environment for it). I have no clue what the problem might be, but if it worked and now it doesn't, you must have changed something. What version of 9base are you using? Also, werc has its own mailing list: http://groups.google.com/group/werc9 uriel On Fri, Jun 11, 2010 at 12:52 AM, Jan Winkelmann wrote: > Hi, > > I was running a werc+lighty+9base setup happily for a couple of days. > Suddenly it started throwing 500-errors and lighty log said that rc died > with signal 6. I tried running the werc.rc manually, but he throws a > rather strange error: > > $ pwd > /srv/http/wiki/bin > $ rc -x werc.rc > . /opt/plan9/etc/rcmain werc.rc > flag p > finit > flag i > flag l > . werc.rc > werc.rc: rc: .: can't open: No such file or directory > > To me it looks like he can't find the . command as soon as he is inside > the werc.rc, however he still knows it in interactive shell: > > ; . > . > rc: Usage: . [-i] file [arg ...] > > I already tried removing the custom werc.rc and replacing it by the > original, but that didn't help either. > > I don't really know what to look for at this point, especially because I > don't really know a lot about plan9. So, any help would be appreciated. > > Thanks in advance, > Jan > > >
Re: [dev] Is Mercurial (hg) suckless?
On Thu, Jun 10, 2010 at 7:04 PM, Moritz Wilhelmy wrote: >> Tom Lord did a fairly good job diagnosing some of the psychological >> aspects that drove the svn insanity: >> >> http://harmful.cat-v.org/software/svn/diagnosing > > By the way, is anyone here using tla? I used to, but being involved in some > projects using git and hg (and svn for university, blergh, they always use > deprecated technology for the sake of being deprecated) and never found anyone > using arch in real development situations, which made me pretty much switch to > git/hg since that's what many people already know and arch is rather hard to > use compared to them. I used both tla and its sh/awk predecessor for a while until hg and git came out. Some of its concepts were quite interesting, and conceptually it was not too complex, but both implementations were severely flawed due to Tom's really bizarre idiosyncrasies (like the ridiculous file and dir naming convention, or the GNU-inspired coding style). Still, it was nice to see a serious piece of software built out of shell scripts, even if it was using the retarded GNU coreuitils. uriel
Re: [dev] Re: [ANN] wmii 3.9.1 released
On Thu, Jun 10, 2010 at 12:53 AM, Kris Maglione wrote: >> It wasn't long ago that WMII just used rc for its scripting needs. > > Because, as it so happens, I'm not a rabid idealogue. It is not about ideology, but about pragmatism and avoiding headaches and wasted time. uriel
Re: [dev] Is Mercurial (hg) suckless?
On Thu, Jun 10, 2010 at 8:49 AM, Anselm R Garbe wrote: > Not to mention svn, which is much worse than CVS in any respect. I > experienced the joy a while ago to compile a more recent svn from > scratch with all dependencies. It was no fun and contained many > surprises as its dependencies popped up. Amen, instead of wasting time arguing over hg vs. git, people should instead push to kill the abomination that is SVN. SVN has got to be one of the worst open source software projects in existence and should have died many years ago. More content for http://harmful.cat-v.org/software/svn/ is very welcome. > My verdict is: the svn developers seem to have created a big monster > in order to keep their Google employment, I'd rather drive a review > rather soon of those guys if I was in charge at Google. ;) Tom Lord did a fairly good job diagnosing some of the psychological aspects that drove the svn insanity: http://harmful.cat-v.org/software/svn/diagnosing uriel > Kind regards, > Anselm > >
