Re: [dev] a terminal transformer, analogous to a unix filter

Rodrigo Martins wrote in : |It was thus said that the Great Greg Reagle once stated: |> I have coined the phrase terminal transformer for a class of programs |> like tmux, dvtm, tcvt, and splitvt. Perhaps there is already a phrase. |> A terminal transformer runs on top of a terminal emulator

Re: [dev] A secure wireless protocol

Hello Sagar, > Currently, all phones use WiFi, GSM, Bluetooth networks in practically > all applications. For WiFi and Bluetooth replacements, do you have any > alternate network in mind which caters to only local public and private > keys. Here in the US, wireless communications are tightly c

Re: [dev] A secure wireless protocol

Sergey Matveev wrote: >*** Josuah Demangeon [2023-10-15 16:43]: >>Not possible to do "tcpdump -i ipsec0" to see the packets going >>*over* the VPN as there is no network interface for it > >That depends on OS/configuration. There could be literally "ipsec" >interface in FreeBSD to see exactly the

Re: [dev] A secure wireless protocol

> (OpenBSD added the pflog interface for tcpdump purpose though) My bad, it is the enc(4) interface: https://man.openbsd.org/enc.4 # ifconfig enc0 enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active # tcpdump -i enc0 tcpdump:

Re: [dev] A secure wireless protocol

*** Josuah Demangeon [2023-10-15 16:43]: >Not possible to do "tcpdump -i ipsec0" to see the packets going >*over* the VPN as there is no network interface for it That depends on OS/configuration. There could be literally "ipsec" interface in FreeBSD to see exactly the packets flowing over that VPN

Re: [dev] A secure wireless protocol

Sergey Matveev wrote: > *** Sagar Acharya [2023-10-15 18:00]: > >How many devices can connect to IPSec VPN? > > Thousands easily. Depends on bandwidth and CPU speed mainly. You can also find that protocol in almost any 'hardware' router that claims to support a VPN: Mikrotik, StormShield, Forti

Re: [dev] A secure wireless protocol

*** Sagar Acharya [2023-10-15 18:00]: >How many devices can connect to IPSec VPN? Thousands easily. Depends on bandwidth and CPU speed mainly. >What is the private key or secret key for these networks? Various. Mostly either PSK (symmetric pre-shared key) or X.509-certificate-based keypair are u

Re: [dev] A secure wireless protocol

*** Sagar Acharya [2023-10-15 17:22]: >I don't need signing, just encryption. Are you aware that "just encryption" is practically useless, if it does not authenticate transmitted data somehow? By MAC, by AEAD, by signature, but with "just encryption" malefactor in many cases can alter your data wi

Re: [dev] A secure wireless protocol

*** Sagar Acharya [2023-10-15 16:33]: >How is libcrypto of libressl? Just a library with numerous algorithms. There are plenty of others. >It has no encryption. What about ed448 and aes? Generally no asymmetric encryption is used in modern protocols. Only signing and key exchange operations as a

Re: [dev] A secure wireless protocol

*** Sagar Acharya [2023-10-14 13:17]: >So, a network which before transmitting a packet, encrypts it with the >recipients' public key and broadcasts it with recipients id as header, say >like, Pay attention that using asymmetric cryptography is pretty CPU consuming task. Using it for each IP pac

Re: [dev] A secure wireless protocol

On Sat, Oct 14, 2023 at 01:17:04PM +0200, Sagar Acharya wrote: > Dear devs, > > Currently, all phones use WiFi, GSM, Bluetooth networks in practically all > applications. For WiFi and Bluetooth replacements, do you have any alternate > network in mind which caters to only local public and privat

[dev] A secure wireless protocol

Dear devs, Currently, all phones use WiFi, GSM, Bluetooth networks in practically all applications. For WiFi and Bluetooth replacements, do you have any alternate network in mind which caters to only local public and private keys. So, a network which before transmitting a packet, encrypts it wi

Re: [dev] a terminal transformer, analogous to a unix filter

--- Original Message --- On Sunday, January 22nd, 2023 at 09:19, Greg Reagle - list at speedpost.net wrote: > -- > On Sat, Jan 21, 2023, at 10:29 AM, Rodrigo Martins wrote: > > > This has great potential. It can simplify the terminal program while > > being

Re: [dev] a terminal transformer, analogous to a unix filter

On Sat, Jan 21, 2023, at 10:29 AM, Rodrigo Martins wrote: > This has great potential. It can simplify the terminal program while > being very unixy. > > Here are some ideas for filters/transformers: > > - Unicode input: like composition key in the linux terminal or Xorg. > - Lock: asks for passwor

Re: [dev] a terminal transformer, analogous to a unix filter

This has great potential. It can simplify the terminal program while being very unixy. Here are some ideas for filters/transformers: - Unicode input: like composition key in the linux terminal or Xorg. - Lock: asks for password when locked, behaves like cat otherwise. - Macro: allows recording a

Re: [dev] a terminal transformer, analogous to a unix filter

[other] Greg, sorry, this is maybe too philosophical. but, reading your thoughts, what strikes me is, from the 1980s/90s (by [another] Greg[or] Kiczales) a model of things (software modules, say, or programs, or computing systems), where each "thing" has two sorts of interfaces: a *using* interfa

Re: [dev] a terminal transformer, analogous to a unix filter

On Sat Jan 7, 2023 at 9:30 PM EST, Greg Reagle wrote: > I have coined the phrase terminal transformer for a class of programs > like tmux, dvtm, tcvt, and splitvt. Perhaps there is already a phrase. "multiplexer" seems to be the term commonly used: https://en.wikipedia.org/wiki/Terminal_multiple

[dev] a terminal transformer, analogous to a unix filter

I have coined the phrase terminal transformer for a class of programs like tmux, dvtm, tcvt, and splitvt. Perhaps there is already a phrase. A terminal transformer runs on top of a terminal emulator and acts as a terminal emulator itself, with an application like nano running on top of it. In oth

[dev] A suckless X11 Widget Toolkit

Hi, I just want to announce the last project I'm working on. It's called control[1]. It is a GUI widget set based on the X Toolkit Intrinsics framework[2]. I name it "control" after Plan 9's widget toolkit which is also called control (but there is only one or two programs using it in Plan 9)

Re: [dev] A simple POSIX build system

For many projects, you can use the "One Compilation Unit" way: one root source file for one end result (shared lib/module/exe/etc). The source tree is static and code selection happens with the C preprocessor. -- Sylvain

Re: [dev] A simple POSIX build system

Fool that I am, I forgot to link it. Here it is: https://git.sr.ht/~q3cpma/posix-build

[dev] A simple POSIX build system

Hello, I've made a POSIX sh/make build system in order to ditch GNU make. Its only dependency is mktemp(1), which is available almost everywhere and can be written in few lines of C with mkstemp(3) if not. Here's an excerpt from the README: For some time, I've been using GNU make with all its fea

Re: [dev] A simpler static file server than quark

On Sun, Jan 26, 2020 at 08:59:55AM +0100, Richard Ulmer wrote: > Hi Hiltjo, > > Hiltjo Posthuma wrote: > > > I have used quark for this, but found it annoying, that I have to > > > provide a host and port and run it as root (the noroot patch doesn't > > > always work either, because the use of fo

Re: [dev] A simpler static file server than quark

On Sun, 26 Jan 2020 08:59:55 +0100 "Richard Ulmer" wrote: Dear Richard, > This is exactly what the noroot patch does: Removing chroot(2), > setgid(2), setuid(2) and setgroups(2). I didn't make up the behaviour > I described. I'm unable to reproduce the error right now, but it > occurs occasional

Re: [dev] A simpler static file server than quark

Hi Hiltjo, Hiltjo Posthuma wrote: > > I have used quark for this, but found it annoying, that I have to > > provide a host and port and run it as root (the noroot patch doesn't > > always work either, because the use of fork(2) is restricted). It seems > > like others have similar complaints abou

Re: [dev] A simpler static file server than quark

On Sat, Jan 25, 2020 at 08:59:11PM +0100, Richard Ulmer wrote: > Hi, > sometimes it's handy to have an easy to use file server at hand, to > share a file with a friend, colleague or smartphone, provide a dummy > server when developing an API or quickly view a website that requires > AJAX locally [1

[dev] A simpler static file server than quark

Hi, sometimes it's handy to have an easy to use file server at hand, to share a file with a friend, colleague or smartphone, provide a dummy server when developing an API or quickly view a website that requires AJAX locally [1]. I have used quark for this, but found it annoying, that I have to pro

[dev] a new suckless scheme interpreter

Here is a pretty complete and working scheme interpreter in 1600 lines of C. It was used to bootstrap a full scheme compiler. To use it in applications would probably require some extra hacking but that's what keeps it from getting bloated https://github.com/rain-1/single_cream/

Re: [dev] a few questions

On Thu, Apr 13, 2017, at 12:58, Greg Minshall wrote: > 3. i recently lost my ability to run X on my laptop, so lived with tmux > (which i heard about here, and very much like -- thanks!). this > experience emphasized that often i'd rather have a two-key (say) > sequence, ^B-j, rather than the "c

Re: [dev] a few questions

Hi, I am no developer of any of the suckless projects, but I guess I can outline how people I know, including myself, handle the configuration issue. > 1. when people make changes to their, e.g., config.def.h, how do they > deal with that w.r.t. git (branches, etc.)? i'd like to be able to use

Re: [dev] a few questions

Config.h is the file actually used to build the program. It is intended to be "manually" controlled by the user/developer, meaning not managed by git and not generated by a recipe in a makefile. It is for personal preferences. It is a sort of substitute for a .rc file. As far as i understand, y

[dev] a few questions

hi, all. thanks again for dwm, surf, both of which i use a lot. i had a few newbie questions. 1. when people make changes to their, e.g., config.def.h, how do they deal with that w.r.t. git (branches, etc.)? i'd like to be able to use git to track, but integrate my changes (without the danger

Re: [dev] a

On Thu, Feb 02, 2017 at 07:20:34PM +0100, willy wrote: > Hello everyone, > > While playing with sbase and musl, I encountered a strange bug: tar > fails to extract bzip2 compressed archives when bzip2 is compiled > against musl (I only tested static linking). Note that bzip2 uncompresses > the fil

Re: [dev] a

On 2/2/17, willy wrote: > At this point, I'm not sure where to look at, or even if the bug > really lies in tar and not in bzip2. > I checked the size (both octal and converted) and the value is good. So > I'm not sure why the headers are not well read. > In the case of the archive above, the erro

[dev] a

Hello everyone, While playing with sbase and musl, I encountered a strange bug: tar fails to extract bzip2 compressed archives when bzip2 is compiled against musl (I only tested static linking). Note that bzip2 uncompresses the files correctly. The error only occurs when the data flows through a p

Re: [dev] a few questions about watch in ubase

On 04/25/2016 02:11 PM, k...@shike2.com wrote: Dimitris, if I send patches to remove these hard coded sequences by calls to tput the patches will be accepted? On my computer, tput comes with package "ncurses-bin". Is that an appropriate dependency for ubase?

Re: [dev] a few questions about watch in ubase

I've an almost complete tput (the program) to add to ubase which has a terminfo library at is core. I'm planning to send the patch in the next week if I've time. Soon we'll be able to stop hardcoding this sequences. Be patient :) On 25/04/16 15:11, k...@shike2.com wrote: clear(1) from ncurses

Re: [dev] a few questions about watch in ubase

> clear(1) from ncurses also clears the scrollback buffer if the terminal > supports it (see the manpage), that's not what you'd want here. As for > portability, tput clear does `^[[2J^[[H` for basically everything: Dimitris, if I send patches to remove these hard coded sequences by calls to tput

Re: [dev] a few questions about watch in ubase

> Is it appropriate to use ANSI escape codes in the program rather than > using something like tput or terminfo, or to just execute the "clear" > command? Are the escape codes portable? No, they are not. The problem here is that a lot of ppl in suckless think that doesn't matter to keep the com

Re: [dev] a few questions about watch in ubase

Thank you to Dimitris and Ryan for answering my questions--very informative. On 04/21/2016 02:04 PM, Greg Reagle wrote: Please excuse me if these questions are rudimentary. I am using Debian Stable. Why is watch linked with the crypt library? cc -s -o watch watch.o libutil.a -lcrypt It does

Re: [dev] a few questions about watch in ubase

On Thu, 21 Apr 2016 13:04:43 -0500 Greg Reagle wrote > Is it appropriate to use ANSI escape codes in the program rather than > using something like tput or terminfo, or to just execute the "clear" > command? Are the escape codes portable? clear(1) from ncurses also clears the

Re: [dev] a few questions about watch in ubase

On Thu, Apr 21, 2016 at 02:04:43PM -0400, Greg Reagle wrote: > Please excuse me if these questions are rudimentary. I am using Debian > Stable. > > Why is watch linked with the crypt library? > cc -s -o watch watch.o libutil.a -lcrypt > It does not seem to need it. watch does not use anything

[dev] a few questions about watch in ubase

Please excuse me if these questions are rudimentary. I am using Debian Stable. Why is watch linked with the crypt library? cc -s -o watch watch.o libutil.a -lcrypt It does not seem to need it. watch uses "\x1b[2J\x1b[H" to clear the screen, which are the two control codes Erase Screen and C

Re: [dev] A replacement for at.

On Fri, 1 Jan 2016 10:19:01 +0100 Mattias Andrée wrote: > Hi! > > I'm written an alternative to at, called sat (for simple > at): https://github.com/maandree/sat sat is incompatible > with at, but I have tried to make sure that a > compatibility-layer can be written. > > sat is basically at wit

Re: [dev] A replacement for at.

On Fri, 01 Jan 2016, Greg Reagle wrote: > On Fri, Jan 01, 2016 at 06:05:58PM +0100, Kamil Cholewiński wrote: >> Yes, please let's stop writing process management code into daemons and >> instead solve this problem in a portable and non-sucky way. > > It's called runit: http://smarden.org/runit/

Re: [dev] A replacement for at.

On Fri, 01 Jan 2016 19:05:50 +0100 Kamil Cholewiński wrote: > > sat will create a PID file in $XDG_RUNTIME_DIR. > > PID files are a flawed concept, race conditions and > everything. Well. But they are standard. satd does not use the PID file to determine whether it is running, it uses flock.

Re: [dev] A replacement for at.

On Fri, Jan 01, 2016 at 06:05:58PM +0100, Kamil Cholewiński wrote: > Yes, please let's stop writing process management code into daemons and > instead solve this problem in a portable and non-sucky way. It's called runit: http://smarden.org/runit/

Re: [dev] A replacement for at.

On Fri, 01 Jan 2016 18:05:58 +0100 Kamil Cholewiński wrote: > > Wouldn't you need a service supervisor with at's > > functionallity? > > No. Separation of concerns. > > > If you are paranoid about sat crashing > > When in doubt, assume the component will crash/fail. > > > as long as you c

Re: [dev] A replacement for at.

> Wouldn't you need a service supervisor with at's functionallity? No. Separation of concerns. > If you are paranoid about sat crashing When in doubt, assume the component will crash/fail. > as long as you can have user-private services. Yes, please let's stop writing process management code i

Re: [dev] A replacement for at.

If you are paranoid about sat crashing and not get your jobs executed, it is possible to start sat under service supervision, as long as you can have user-private services. On Fri, 01 Jan 2016 15:17:43 +0100 Kamil Cholewiński wrote: > > satd is an unprivileged daemon that is user-private, and >

Re: [dev] A replacement for at.

Wouldn't you need a service supervisor with at's functionallity? Are there any? If you want to do things really simply you can use sleep-until (https://github.com/maandree/sleep-until), but then you cannot as easily list jobs and run the before scheduled. On Fri, 01 Jan 2016 15:17:43 +0100 Kamil

Re: [dev] A replacement for at.

> satd is an unprivileged daemon that is user-private, and > starts and exits automatically. Why not use a service supervisor?

[dev] A replacement for at.

Hi! I'm written an alternative to at, called sat (for simple at): https://github.com/maandree/sat sat is incompatible with at, but I have tried to make sure that a compatibility-layer can be written. sat is basically at without a lot of features that does not need to be there. sat is also written

Re: [dev] a suckless hex editor

Agreed. Besides if xxd is installed, one can do something like this in vi/vim: :%!xxd make changes :%!xxd -r. Is a shell script really necessary? On 13/11/15 11:45am, Alex Pilon wrote: > On Fri, Nov 13, 2015 at 11:28:36AM -0500, Greg Reagle wrote: > > What do you think? > > > > […] > > > > #!/

Re: [dev] a suckless hex editor

On Sat, Nov 14, 2015 at 10:14:38AM -0500, Matthew of Boswell wrote: > He probably would have said "rm -rf" if he intended for you to delete > the project. At the end of your script, you have 'rm "$tmpfile"'. Got it. Thanks for explaining.

Re: [dev] a suckless hex editor

On Sat, 14 Nov 2015 08:48:33 +0100 pancake wrote: > No. Not just this. Rtfm... Rm -f is needed if you dont want a prompt to > remove that file in case of custpm umask or a race condition with another > script happens. > > On 14 Nov 2015, at 03:40, Greg Reagle wrote: > > > >> On Fri, Nov 1

Re: [dev] a suckless hex editor

No. Not just this. Rtfm... Rm -f is needed if you dont want a prompt to remove that file in case of custpm umask or a race condition with another script happens. > On 14 Nov 2015, at 03:40, Greg Reagle wrote: > >> On Fri, Nov 13, 2015 at 09:42:11PM +0100, pancake wrote: >> Use rm -f > > I

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 07:54:07PM +0100, Nico Golde wrote: > I'm sorry to be blunt, but this is not a suckless hex editor, but a poor mans > hex editor that's barely useful for any real work in my opinion. I mean it > may > work fine for changing a single byte here or there and look at dumps, bu

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 08:51:24PM +, Connor Lane Smith wrote: > On 13 November 2015 at 20:42, pancake wrote: > > Also, echo is a buildtin, so dont use absolute path for it > > My guess is the path was added because the builtin echo may not > support the -e flag. But that's because it's non-s

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 09:42:11PM +0100, pancake wrote: > Use rm -f I don't get it. Is this a Unixy geeky way of saying you don't like it?

Re: [dev] a suckless hex editor

Hi, * Greg Reagle [2015-11-13 18:33]: > What do you think? I was afraid to overwrite the infile so I make the user > specify an outfile. Maybe if I did better error checking it would be okay > to overwrite? I'm sorry to be blunt, but this is not a suckless hex editor, but a poor mans hex editor

Re: [dev] a suckless hex editor

On 13 November 2015 at 20:42, pancake wrote: > Also, echo is a buildtin, so dont use absolute path for it My guess is the path was added because the builtin echo may not support the -e flag. But that's because it's non-standard -- as are all echo flags, really -- and as Dimitris says printf shoul

Re: [dev] a suckless hex editor

Also, echo is a buildtin, so dont use absolute path for it > On 13 Nov 2015, at 20:54, Dimitris Papastamos wrote: > >> On Fri, Nov 13, 2015 at 02:52:17PM -0500, Greg Reagle wrote: >> Okay then. It no longer depends on xxd. It depends on od for the hex dump >> (works with both GNU od and sbas

Re: [dev] a suckless hex editor

Use rm -f > On 13 Nov 2015, at 20:54, Dimitris Papastamos wrote: > >> On Fri, Nov 13, 2015 at 02:52:17PM -0500, Greg Reagle wrote: >> Okay then. It no longer depends on xxd. It depends on od for the hex dump >> (works with both GNU od and sbase od) and echo, awk, tr, cut for the reverse >> h

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 02:52:17PM -0500, Greg Reagle wrote: > Okay then. It no longer depends on xxd. It depends on od for the hex dump > (works with both GNU od and sbase od) and echo, awk, tr, cut for the reverse > hex dump. > #!/bin/sh > [ -z "$1" -o -z "$2" ] && { echo "$0 infile outfile";

Re: [dev] a suckless hex editor

Okay then. It no longer depends on xxd. It depends on od for the hex dump (works with both GNU od and sbase od) and echo, awk, tr, cut for the reverse hex dump. #!/bin/sh [ -z "$1" -o -z "$2" ] && { echo "$0 infile outfile"; exit 1; } [ -z "$EDITOR" ] && { echo "\$EDITOR must be defined"; exit

Re: [dev] a suckless hex editor

Check ired. From the radare github repo > On 13 Nov 2015, at 19:50, Matthew of Boswell > wrote: > > On Fri, 13 Nov 2015 11:28:36 -0500 > Greg Reagle wrote: > >> What do you think? > > I personally wouldn't use it over hexer, but it's an interesting idea. > > Pros: > - very minimal; great

Re: [dev] a suckless hex editor

On Fri, 13 Nov 2015 11:28:36 -0500 Greg Reagle wrote: > What do you think? I personally wouldn't use it over hexer, but it's an interesting idea. Pros: - very minimal; great for embedded (assuming no dependence on vim) Cons: - can't edit the ascii values on the right; everything is parsed from

Re: [dev] a suckless hex editor

On 11/13/2015 12:17 PM, Louis Santillan wrote: tr, bc & awk? Very cool. I'll see what I can do.

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 8:55 AM, Greg Reagle wrote: > On 11/13/2015 11:45 AM, Alex Pilon wrote: >> >> xxd's provided by vim. As convenient as it is, should a "suckless hex >> editor" really depend on that? It should be the user's choice or not to >> install vim, regardless of anybody's feeling's o

Re: [dev] a suckless hex editor

On 11/13/2015 11:45 AM, Alex Pilon wrote: xxd's provided by vim. As convenient as it is, should a "suckless hex editor" really depend on that? It should be the user's choice or not to install vim, regardless of anybody's feeling's on this list *either* way. Is there another tool that can do a r

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 11:28:36AM -0500, Greg Reagle wrote: > What do you think? > > […] > > #!/bin/sh > > […] > dump="xxd -g1" > dedump="xxd -r" xxd's provided by vim. As convenient as it is, should a "suckless hex editor" really depend on that? It should be the user's choice or not to install v

Re: [dev] a suckless hex editor

Improved a little. Is it appropriate for inclusion in sbase? #!/bin/sh dump="xxd -g1" dedump="xxd -r" [ -z "$1" -o -z "$2" ] && { echo "$0 infile outfile"; exit 1; } [ -z "$EDITOR" ] && { echo "\$EDITOR must be defined"; exit 1; } tmpfile=$(mktemp) || exit 1 infile="$1" outfile="$2" $dump "$in

[dev] a suckless hex editor

What do you think? I was afraid to overwrite the infile so I make the user specify an outfile. Maybe if I did better error checking it would be okay to overwrite? The user can choose to overwrite by specifying the same file for both infile and outfile. #!/bin/sh [ -z "$1" -o -z "$2" ] &&

Re: [dev] A chance for a suckless web?

On Sun, 11 Oct 2015 16:22:41 +0200 Christoph Lohmann <2...@r-36.net> wrote: Hey Christoph, > What do you comrades think? the web is almost a lost place. Nowadays, more and more people rely on third-party themes for their websites, and 99% of those have been developed with presentation in mind, n

Re: [dev] A chance for a suckless web?

Heyho, Christoph Lohmann wrote: > I found the AMP project [0], which seems to be a standard to have easy > rendering of webpages on mobile devices. It only allows a subset of the HTML > tags but forces at least one Javascript script file to be run. If the content > could be displayed without t

Re: [dev] A chance for a suckless web?

2015-10-11 21:29 GMT+02:00, Nick : > Quoth hiro: >> I approve of Ben's comment. I read a lot of web articles on my >> e-reader these days. This way I waste less time in front of shitty web >> browsers (on immobile supercomputers) and have something consuming to >> do on the go. > > I recently got a

Re: [dev] A chance for a suckless web?

Right now I just use the "getpocket" service, which was preinstalled on both my kobo and firefox and also has a chrome extension. I assume that they have some clever algorithms for this. On a kindle I used the "send to kindle" extension which functions the same way. Before I realized what that po

Re: [dev] A chance for a suckless web?

Quoth hiro: > I approve of Ben's comment. I read a lot of web articles on my > e-reader these days. This way I waste less time in front of shitty web > browsers (on immobile supercomputers) and have something consuming to > do on the go. I recently got an e-reader and thought I should do something

Re: [dev] A chance for a suckless web?

I approve of Ben's comment. I read a lot of web articles on my e-reader these days. This way I waste less time in front of shitty web browsers (on immobile supercomputers) and have something consuming to do on the go. If I navigate through the shitty flash and .gif and CSS websites fast and efficie

Re: [dev] A chance for a suckless web?

Quoth tauto...@gmail.com: > I have considered making a reader mode in surf, and having a sort of > automatic mode for going into reader mode to make it more of a default. I did that, but not with an automatic reader mode thing. Haven't updated it for a while, but it should still just work most

Re: [dev] A chance for a suckless web?

From: Christoph Lohmann Sent: Sunday, October 11, 2015 7:30 AM To: dev@suckless.org Reply To: dev mail list Subject: [dev] A chance for a suckless web? Greetings comrades, I found the AMP project [0], which seems to be a standard to have easy rendering of webpages on mobile devices. It only allows

Re: [dev] A chance for a suckless web?

2015-10-11 16:22 GMT+02:00, Christoph Lohmann <2...@r-36.net>: > Greetings comrades, > > I found the AMP project [0], which seems to be a standard to have easy > rendering of webpages on mobile devices. It only allows a subset of the > HTML tags but forces at least one Javascript script file t

Re: [dev] A chance for a suckless web?

I read about AMP some time this week. Reading into it, I think prohibiting all input elements except for the button seems like a huge step towards interactivity, so that websites could use image maps as on-screen keyboards and, like, build huge microsoft access like applications, webshops and all.

[dev] A chance for a suckless web?

Greetings comrades, I found the AMP project [0], which seems to be a standard to have easy rendering of webpages on mobile devices. It only allows a subset of the HTML tags but forces at least one Javascript script file to be run. If the content could be displayed without the JS being mandato

Re: [dev] A suckless issue tracker

On Mon, Apr 6, 2015, at 04:38 PM, FRIGN wrote: > Isn't it bad enough that we have these Arch-hipsters > on this ml who constantly discuss things without > providing patches? Would you like to discuss that issue? By the way, I've never encountered the term "Arch-hipster" before--very very amusing.

Re: [dev] A suckless issue tracker

On Mon, 6 Apr 2015 17:35:11 -0700 Louis Santillan wrote: > Gopher server as a goal! I love it. Especially since > I've been reading up on the protocol recently. It's a lovely protocol! If only there was a way around the issue that gopher uses its own URL syntax. And even better than its lovel

Re: [dev] A suckless issue tracker

Gopher server as a goal! I love it. Especially since I've been reading up on the protocol recently. But seriously, when I need a light-weight, private Issue Tracker, I reach for cvstrac [0]. It supported SQLite for almost a decade before Richard Hipp replaced it with Fossil [1]. Supports cvs,

Re: [dev] A suckless issue tracker

On Mon, 6 Apr 2015 23:08:18 +0200 FRIGN wrote: > On Mon, 6 Apr 2015 22:58:49 +0200 > Mattias Andrée wrote: > > Hey Mattias, > > > Well it was on the list of software you needed, > > so I thought I could help out. (So no, it is not > > a NIH-timewaster.) > > > > I have not spent too much time

Re: [dev] A suckless issue tracker

Hi, On 6 April 2015 at 21:29, Mattias Andrée wrote: > I have just started on a simple issue tracker > [Write a decent bug and issue tracking system], > that I would like to make part of suckless.org > and develop under your mentorship. I'm afraid I can't help all that much, but despite FRIGN's p

Re: [dev] A suckless issue tracker

On Mon, 6 Apr 2015 22:58:49 +0200 Mattias Andrée wrote: Hey Mattias, > Well it was on the list of software you needed, > so I thought I could help out. (So no, it is not > a NIH-timewaster.) > > I have not spent too much time researching the > area. (But I assumed you had.) The best solution >

Re: [dev] A suckless issue tracker

On 6 April 2015 at 21:58, Mattias Andrée wrote: > The best solution to the problem that I know if is bugseverywhere, but > [...] last time I used it, it was very buggy. Well at least the name serves as a warning. :) cls

Re: [dev] A suckless issue tracker

On Mon, 6 Apr 2015 22:38:17 +0200 FRIGN wrote: > On Mon, 6 Apr 2015 22:29:21 +0200 > Mattias Andrée wrote: > > > I have just started on a simple issue tracker > > [Write a decent bug and issue tracking system], > > that I would like to make part of suckless.org > > and develop under your mentor

Re: [dev] A suckless issue tracker

On Mon, 6 Apr 2015 22:29:21 +0200 Mattias Andrée wrote: > I have just started on a simple issue tracker > [Write a decent bug and issue tracking system], > that I would like to make part of suckless.org > and develop under your mentorship. Yet another issue tracker ... Why on earth do people sp

[dev] A suckless issue tracker

Hi! I have just started on a simple issue tracker [Write a decent bug and issue tracking system], that I would like to make part of suckless.org and develop under your mentorship. You can find the progress so far at . My idea is to have an issue tracker similar t

Re: [dev] A simple but flexible alternative to cron

Greetings. On Sun, 08 Feb 2015 14:55:01 +0100 Eric Pruitt wrote: > I've wanted something with a bit more flexibility than standard Cron for > a while, and I finally came up with a simple solution that I like and > felt might be of interest to this community. You are just replacing the run‐cron

Re: [dev] A simple but flexible alternative to cron

On Sat, Feb 7, 2015 at 8:30 AM, Eric Pruitt wrote: > > Each of the scripts has two functions defined: "condition," which exits > [...] SCNR, but didn't you mean to write "crondition"? cheers! mar77i

[dev] A simple but flexible alternative to cron

I've wanted something with a bit more flexibility than standard Cron for a while, and I finally came up with a simple solution that I like and felt might be of interest to this community. The core of my scheduler is a Bash script, and the script searches for files in a "tasks" subfolder that has o

Re: [dev] A new FIFO based tox client

On Mon, Sep 29, 2014 at 11:21:53PM +0100, Nick wrote: > How does that sound? I'm tempted to hack something together, so > feedback would be very welcome. Please keep in mind that we have not yet written an external client on top of the FIFO interface. It is likely that some important bits are mi

Re: [dev] A new FIFO based tox client

On Mon, 29 Sep 2014 23:38:47 +0100 Dimitris Papastamos wrote: > dwm with the fifo patch[0] could work fine. I generally work in tmux > that's why hysteria is done like that. Also it is mostly running on > a remote machine where I don't have X. You can tunnel your traffic > but when your machin

  1   2   3   >