[dev] a

[willy]

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 pipe:

The file has been created using GNU/tar, dynamically compiled against glibc.
As a reference, here is a test with the static bzip2 and GNU/tar:


If using the bzip2 binary provided with my distro (v1.0.6), everything
works as expected:

$ /usr/bin/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
pm/pm.c
pm/config.mk

As I said earlier, The error occurs only with a pipe in-between, so
uncompressing the file completely before extracting it works flawlessly:

$ musl/bzip2 -d < pm.tbz > pm.tar
$ musl/tar -tf pm.tar
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
pm/pm.c
pm/config.mk

I added some debug messages to `chktar()` in order to identify what is
going wrong (see patch attached), and the error changes (apparently)
randomly.

Sometime, extracting simply stop without an error:

$ musl/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README

Sometimes the magic string is wrong (header is read within a previous
entry):

$ musl/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
pm/pm.c
chktar: invalid magic "ootfs, datadir, *argv);
if (action == ACTION_UPDATE)
r += update(rootfs, datadir, *argv);
if (action == ACTION_DELETE)
r += delete(rootfs, datadir, *argv);
argv++;
}
break;
case ACTION_INSPECT:
if (inspect(datadir, n) != 0)
retu"
musl/tar: malformed tar archive

And sometimes the magic string is ok, but the checksum fails:

$ musl/bzip2 -d < pm.tbz | musl/tar -t
pm/
pm/IDEAS
pm/LICENSE
pm/README
pm/arg.h
pm/makefile
pm/pack.5
pm/pm.1
chktar: bad checksum
musl/tar: malformed tar archive

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 error occurs on the last entry,
but depending on the archives, it can occur on the second entry or in
the middle, there's no rule.

I hope my example are clear to define what the issue is. Would anyone
have an idea?

-- 
willy
diff --git a/tar.c b/tar.c
index 71719b0..49ecfae 100644
--- a/tar.c
+++ b/tar.c
@@ -351,8 +351,10 @@ skipblk(ssize_t l)
char b[BLKSIZ];
 
for (; l > 0; l -= BLKSIZ)
-   if (!eread(tarfd, b, BLKSIZ))
+   if (!eread(tarfd, b, BLKSIZ)) {
+   fprintf(stderr, "skipblk: failed to read %d bytes\n", 
BLKSIZ);
break;
+   }
 }
 
 static int
@@ -402,16 +404,42 @@ sanitize(struct header *h)
 }
 
 static void
+dumpheader(struct header *h)
+{
+   puts("");
+   printf("%s: %s\n", "name", h->name);
+   printf("%s: %s\n", "mode", h->mode);
+   printf("%s: %s\n", "uid",  h->uid);
+   printf("%s: %s\n", "gid",  h->gid);
+   printf("%s: %s\n", "size", h->size);
+   printf("%s: %s\n", "mtime",h->mtime);
+   printf("%s: %s\n", "chksum",   h->chksum);
+   printf("%s: %c\n", "type", h->type);
+   printf("%s: %s\n", "linkname", h->linkname);
+   printf("%s: %s\n", "magic",h->magic);
+   printf("%s: %s\n", "version",  h->version);
+   printf("%s: %s\n", "uname",h->uname);
+   printf("%s: %s\n", "gname",h->gname);
+   printf("%s: %s\n", "major",h->major);
+   printf("%s: %s\n", "minor",h->minor);
+   printf("%s: %s\n", "prefix",   h->prefix);
+}
+
+static void
 chktar(struct header *h)
 {
char tmp[8], *err;
char *p = (char *)h;
long s1, s2, i;
 
-   if (h->prefix[0] == '\0' && h->name[0] == '\0')
+   if (h->prefix[0] == '\0' && h->name[0] == '\0') {
+   fprintf(stderr, "chktar: empty prefix and name\n");
goto bad;
-   if (h->magic[0] && strncmp("ustar", h->magic, 5))
+   }
+   if (h->magic[0] && strncmp("ustar", h->magic, 5)) {
+   fprintf(stderr, "

Re: [dev] a

[Michael Forney]

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 error occurs on the last entry,
> but depending on the archives, it can occur on the second entry or in
> the middle, there's no rule.
>
> I hope my example are clear to define what the issue is. Would anyone
> have an idea?

It's a tar bug. See http://lists.suckless.org/dev/1612/30865.html.

Re: [dev] a

[Markus Wichmann]

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 files correctly. The error only occurs when the data flows through
> a pipe:
> 

If an error occurs only when a pipe is involved, then in principle only
two things could go wrong: bzip2 could be failing to handle short writes
correctly or tar could be failing to handle short reads correctly.

If it was the latter then I'd expect to see weird behavior regarding
blocks and the start thereof. Like, for instance:

>   chktar: invalid magic "ootfs, datadir, *argv);
>   if (action == ACTION_UPDATE)
>   r += update(rootfs, datadir, *argv);
>   if (action == ACTION_DELETE)
>   r += delete(rootfs, datadir, *argv);
>   argv++;
>   }
>   break;
>   case ACTION_INSPECT:
>   if (inspect(datadir, n) != 0)
>   retu"
>   musl/tar: malformed tar archive
> 

If it was the former, then I'd expect similar behavior, however not
exactly like this. If bzip was failing to notice that some decompressed
data isn't written, tar would be seeing start blocks too late, not
too early, as it does here.

So, looks like a tar bug.

Ciao,
Markus

[dev] a few questions

[Greg Minshall]

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 of
accidentally trying to push my changes back to the repository).  (as a
former sccs/rcs user, i'm still a bit git-naive, especially
w.r.t. branches.)

2.  why do at least the dwm and surf makefiles *not* list config.def.h
as a dependency for config.h (so that a change in the former causes the
latter to be re-built)?  as it seems to me the obvious thing to do, and
yet hasn't been done, i'm guessing there's some philosophy there.

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 "chord" Alt-j, to effect an action.  of
course, this functionality requires keymaps, etc.  is there any thought
of doing this for dwm?  or, is there some external program that would
somehow handle this for you?

cheers, Greg

[dev] A Suckless Filesystem

[Brandon LaRocque]

Which one do you use? Why do you use it? What does it have that the
others don't?

[dev] A shot at dwm

[Robert Latest]

Hey, swm's another great discovery! Configuration in source code --
I've always been embarrassed  that my own software works like that,
now I'm happy to see that there are people out there who actually have
the guts to do the same thing and sell it as a feature. I miss the
MOD-p menu function though. It's mentioned in the config.h file as
dmenu_run which doesn't exist here. When I replace dmenu_run with just
dmenu, nothing at all happens upon pressing MOD-p.
Greetings,
robert

[dev] A suckless issue tracker

[Mattias Andrée]

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
to bugseverywhere. Anyone with push access
to a project's repository will be given full
control over the issue tracker.

There will be a web client (that I will not
write because if there is something I hate
more than the web, it is web development.)
This client's back-end will not implement
everything that is needed to access the issue
tracking system. Rather it will run command
that anyone else can run in the terminal.


Mattias Andrée

PS.
Anyone interested in a proper replacement
for X, is more than welcome to help me at
.



pgpSYUeXzgyHx.pgp
Description: OpenPGP digital signature

[dev] a suckless hex editor

[Greg Reagle]

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" ] && { echo "$0 infile outfile"; exit 1; }
[ -z "$EDITOR" ] && { echo "\$EDITOR must be defined"; exit 1; }

infile="$1"
outfile="$2"
dump="xxd -g1"
dedump="xxd -r"

tmpfile=$(mktemp)
$dump "$infile" > "$tmpfile"
$EDITOR "$tmpfile"
$dedump $tmpfile > "$outfile"
rm "$tmpfile"

[dev] A replacement for at.

[Mattias Andrée]

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 to waste very little
memory when it is inactive — since it is almost always
inactive — fork–exec:s, libexec:s to do things when
something happens.

satd is an unprivileged daemon that is user-private, and
starts and exits automatically. The client programs (sat,
satq, satr, satrm) communicates with satd using a domain
socket. Unfortunately message queues (or bus:
https://github.com/maandree/bus) was a not a good option
because of unbounded message lengths.

satd is able to update online, and is able to recover its
job queue if its shuts down unexpectedly.

I have released sat under the terms of the MIT License,
in hope that it will be useful if you want to base your
at-implement of it.


Mattias Andrée



pgpws3etsMNKy.pgp
Description: OpenPGP digital signature

Re: [dev] a few questions

[Greg Reagle]

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, your expected workflow is first clone the
repository, then copy config.def.h to config.h, then modify config.h to
suit your preferences (or leave it alone if you like the defaults), then
compile.

Re: [dev] a few questions

[Inokentiy Babushkin]

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
> git to track, but integrate my changes (without the danger of
> accidentally trying to push my changes back to the repository).  (as a
> former sccs/rcs user, i'm still a bit git-naive, especially
> w.r.t. branches.)
Many people maintain their own configuration either in a single file, and
copy it somewhere safe, or just set up a branch where their local changes
are versioned. When an update gets pushed to master, they either rebase
[1] or merge master into their config branch. Since repositories are
subject to access control, and since pushing is a quite explicit
operation, no real harm can be done that way (unless you manage to break
your local repository's history in a way that renders you unable to
properly receive and merge updates).

Hope this helps,

Ino

[1]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Re: [dev] a few questions

[Greg Reagle]

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 "chord" Alt-j, to effect an action.  of
> course, this functionality requires keymaps, etc.  is there any thought
> of doing this for dwm?  or, is there some external program that would
> somehow handle this for you?

Yea tmux is cool.  So is dvtm, try that too.

I doubt that requiring an extra keystroke will be accepted by mainline
dwm, but it seems feasible to implement.  I expect such a change would
require a patch of dwm because i don't know how it could be done
external to dwm.  If you want to hire me to write that patch, let me
know.  See http://dwm.suckless.org/patches/keymodes for something that
might be similar to what you want.

[dev] A secure wireless protocol

[Sagar Acharya]

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 with the 
recipients' public key and broadcasts it with recipients id as header, say like,



A list of MAC addresses would be maintained on WiFi server end for each device. 
Are there already such network softwares made out there?

The aim is no dhcp and not a single device outside list can communicate.
Thanking you
Sagar Acharya
https://humaaraartha.in/selfdost/selfdost.html

RE: [dev] A Suckless Filesystem

[wolf]

>Which one do you use? Why do you use it? What does it have that the
>others don't?

ext2. I forget why. Probably because I didn't know anything when I
installed archlinux.

I've heard good things about JFS. I've looked at the different FS's but
I can't really
identify one as being obviously suckless.

/wolf

Re: [dev] A Suckless Filesystem

[Antoni Grzymala]

w...@tivy.com dixit (2011-02-05, 16:20):

> >Which one do you use? Why do you use it? What does it have that the
> >others don't?
> 
> ext2. I forget why. Probably because I didn't know anything when I
> installed archlinux.
> 
> I've heard good things about JFS. I've looked at the different FS's but
> I can't really
> identify one as being obviously suckless.

JFS is lovely for a number of reasons, the main being stability,
very decent all-round performance and extremely low CPU-usage.

The main downsides are no shrinking possibility (at least in the
non-AIX incarnations) and practically a single part-time developer.

So recently I've been pretty much mainstream with ext4 – not extremely
stable yet in my experience, but lacking some annoyances of ext3 (like
very io-intensive deletion of big files and sensible fsck times).

-- 
[a]

Re: [dev] A Suckless Filesystem

[Patrick Haller]

On Sat, Feb 05, 2011 at 05:06:20PM -0500, Brandon LaRocque wrote:
> Which one do you use? Why do you use it? What does it have that the
> others don't?

XFS because http://www.jukie.net/bart/blog/usb2-enclosure-benchmark

Lots of tradeoffs with FSs, how about tackle userland first?


Patrick

Re: [dev] A Suckless Filesystem

[Ethan Grammatikidis]

On Sat, 05 Feb 2011 17:06 -0500, "Brandon LaRocque"
 wrote:
> Which one do you use? Why do you use it? What does it have that the
> others don't?

For USB storage and bootloader partitions I've reverted to FAT, on the
one because I got fed up with keeping UIDs in sync across multiple
machines & on both for the obvious reasons of being readable from all
OSs I've even considered using.

My Linux machines use ext4 on the simple basis that it's likely to be
the best-maintained file system. That's about the extent to which I'm
willing to go for sucklessness under the skin of a lunix (or indeed
unix) box these days.

[dev] a suckless init system?

[Calvin Morrison]

Hey all,

Recently on the Arch mailing list there has been much discussion of
different init systems. I was just wondering which init system, y'all
approve of. SysV or OpenRC pretty suckless and unix-y to me.

What do you think?

Calvin

[dev] A window without focus

[Manolo Martínez]

Hello,

I have a cronjob that launches a window with notify-send "Low
Battery" when, well, the battery is low.

Is there a way to prevent this window from stealing focus?

Thanks
Manolo

-- 

Re: [dev] A shot at dwm

[Samuel Baldwin]

Try upgrading to the latest dmenu?

-- 
Samuel Baldwin - logik.li

Re: [dev] A shot at dwm

[Moritz Wilhelmy]

dmenu should bring dmenu_run with it which is a short sh-wrapper around dmenu
which feeds dmenu with $PATH.
dmenu_run works fine here and everywhere else I tried it.

On Fri, Oct 02, 2009 at 08:58:57PM +0200, Robert Latest wrote:
> Hey, swm's another great discovery! Configuration in source code --
> I've always been embarrassed  that my own software works like that,
> now I'm happy to see that there are people out there who actually have
> the guts to do the same thing and sell it as a feature. I miss the
> MOD-p menu function though. It's mentioned in the config.h file as
> dmenu_run which doesn't exist here. When I replace dmenu_run with just
> dmenu, nothing at all happens upon pressing MOD-p.
> Greetings,
> robert
> 

Re: [dev] A shot at dwm

[Robert Latest]

> Try upgrading to the latest dmenu?

Yup, that did it. The other one was the one that cam with Debian's wmii.
robert

[dev] a suckless computer algebra system

[A.J. Gardner]

I'm interested in math and CASs, but my opinions on available software
are ill-formed and mostly ignorant. Does anyone else here have an
interest in this topic, broadly speaking? If so, do you have any
preferences for one package over another? Have you found any math
software that seem to follow the worse-is-better design model?

How is gnuplot? gmp bignum library? Maxima? Sympy? Octave? Ever used
any of these?

I'm too much of a n00b (and I'm still trying to wrap my mind around
what it means for software to suck less) to actually tell if some code
does, in fact, suck less.

tl;dr: Anyone know of any suckless math software out there in the tubes?

Best,
A.J.

[dev] a suckless computer algebra system

[Alex Ghitza]

On Thu, Nov 19, 2009 at 07:51:31PM -0500, Kris Maglione wrote:
> Don't be silly. There's nothing like a "suckless" CAS, at least
> nothing remotely approaching the simplicity of suckless.org
> software. Computer algebra and calculus are complex and
> computationally intensive. They can't (and arguably shouldn't) be
> simplified beyond a point.
> 

I tend to agree with this.

> 
> Maxima is pretty much the gold standard among open source CASs. Sage
> is a bit more featureful in some areas, but it's a ridiculously
> huge, self-contained distro including an entire Python runtime, and
> it pretty much requires that you use the web interface to do
> anything useful. Sympy is the basis of Sage, and it works, but it's
> a bit slow and lacks a few features.
> 

Sage is indeed ridiculously huge and will probably get bigger as
libraries from other areas of mathematics get added.

However, it is simply not true that it "requires you to use the web
interface to do anything useful".  I have been using Sage extensively
for teaching and research for the past two years and I spend 95% of my
time in the command-line interface.  I only use the Sage notebook
(i.e. the web interface) when I need to use graphics in a class, or
during talks (most students, but also a lot of mathematicians seem to
get a blank stare when they look at the command line).

> 
> Use Maxima, try Sage, but if you want suckless, prepare to be
> disappointed by the latter.

Again, I agree that Sage is nowhere near suckless.  And it still lacks
many features that people want, although it's still a fairly young
project insofar as CAS's go (5 years), so I'm certain that lots of new
features will be added.

In the end, it depends on what you want to do with your CAS.  If you
want something very precise, there is good specialised software around
(Pari was already mentioned for number theory, GAP is the way to go
for group theory, Macaulay2 for algebraic geometry, Singular for
commutative algebra, mpmath for special functions, R for statistics,
etc.)


Best,
Alex


-- 
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/

Re: [dev] A suckless issue tracker

[FRIGN]

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 spend so much time to get
around working on actual software that benefits
people?

Isn't it bad enough that we have these Arch-hipsters
on this ml who constantly discuss things without
providing patches? No offense, Mattias, but if you
present a project like this, please share why this
bugtracker solves a problem that all other bugtrackers
leave unsolved.

If it is yet another NiH-timewaster, I can hardly
find the motivation to take a closer look at it.

Cheers

FRIGN

-- 
FRIGN 

Re: [dev] A suckless issue tracker

[Mattias Andrée]

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 mentorship.
> 
> Yet another issue tracker ...
> 
> Why on earth do people spend so much time to get
> around working on actual software that benefits
> people?
> 
> Isn't it bad enough that we have these Arch-hipsters
> on this ml who constantly discuss things without
> providing patches? No offense, Mattias, but if you
> present a project like this, please share why this
> bugtracker solves a problem that all other bugtrackers
> leave unsolved.
> 
> If it is yet another NiH-timewaster, I can hardly
> find the motivation to take a closer look at it.
> 
> Cheers
> 
> FRIGN
> 

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
to the problem that I know if is bugseverywhere,
but I think it is poorly designed and last time
I used it, it was very buggy. I guess one could
build a solution around it but I think that would
be a half-assed solution.

The entry in 'project ideas' as not very
descriptive of what is needed, but I thought
that addressed later.


Mattias Andrée



pgpHdxKfveMeU.pgp
Description: OpenPGP digital signature

Re: [dev] A suckless issue tracker

[Connor Lane Smith]

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

[FRIGN]

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
> to the problem that I know if is bugseverywhere,
> but I think it is poorly designed and last time
> I used it, it was very buggy. I guess one could
> build a solution around it but I think that would
> be a half-assed solution.
> 
> The entry in 'project ideas' as not very
> descriptive of what is needed, but I thought
> that addressed later.

Please don't CC the mail to me directly, the ml
doesn't work like this here. ;)

@topic: The software list is hopelessly outdated
in many parts (I just removed a request to port
stuff to bionic libc, which was an obvious DoA a
few months ago).

Please again tell me what it does better than
bugseverywhere than only being less bug-ridden.

Cheers

FRIGN

-- 
FRIGN 

Re: [dev] A suckless issue tracker

[Connor Lane Smith]

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 protests,
this idea did get a fair amount of attention when it was brought up on
the mailing list a while back. The archived thread [1][2] may be of
interest to you.

[1]: http://lists.suckless.org/dev/1201/index.html#msg10574
[2]: http://lists.suckless.org/dev/1201/10574.html

Thanks,
cls

Re: [dev] A suckless issue tracker

[Mattias Andrée]

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 researching the
> > area. (But I assumed you had.) The best solution
> > to the problem that I know if is bugseverywhere,
> > but I think it is poorly designed and last time
> > I used it, it was very buggy. I guess one could
> > build a solution around it but I think that would
> > be a half-assed solution.
> > 
> > The entry in 'project ideas' as not very
> > descriptive of what is needed, but I thought
> > that addressed later.
> 
> Please don't CC the mail to me directly, the ml
> doesn't work like this here. ;)
> 
> @topic: The software list is hopelessly outdated
> in many parts (I just removed a request to port
> stuff to bionic libc, which was an obvious DoA a
> few months ago).
> 
> Please again tell me what it does better than
> bugseverywhere than only being less bug-ridden.

Here is a list of what I think should be implemented.


> 
> Cheers
> 
> FRIGN
> 



pgpWOmvHUTzwx.pgp
Description: OpenPGP digital signature

Re: [dev] A suckless issue tracker

[Louis Santillan]

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, svn, git.

[0] http://www.cvstrac.org/index.html/doc/trunk/www/index.html
[1] http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki



On Mon, Apr 6, 2015 at 3:54 PM, Mattias Andrée  wrote:
> 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 researching the
>> > area. (But I assumed you had.) The best solution
>> > to the problem that I know if is bugseverywhere,
>> > but I think it is poorly designed and last time
>> > I used it, it was very buggy. I guess one could
>> > build a solution around it but I think that would
>> > be a half-assed solution.
>> >
>> > The entry in 'project ideas' as not very
>> > descriptive of what is needed, but I thought
>> > that addressed later.
>>
>> Please don't CC the mail to me directly, the ml
>> doesn't work like this here. ;)
>>
>> @topic: The software list is hopelessly outdated
>> in many parts (I just removed a request to port
>> stuff to bionic libc, which was an obvious DoA a
>> few months ago).
>>
>> Please again tell me what it does better than
>> bugseverywhere than only being less bug-ridden.
>
> Here is a list of what I think should be implemented.
> 
>
>>
>> Cheers
>>
>> FRIGN
>>
>

Re: [dev] A suckless issue tracker

[Mattias Andrée]

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 lovely protocol. Every single
gopher page looks wonderful. And gopher site designers
do not spend months on creating a good interface, it
just comes automatically with the protocol.

> 
> 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, svn, git.

Haven't read about Fossil, but SQL in an issue tracker:
yuk! Plain text files should be used whenever possible,
and a issue tracker certainly do not require anything
more advanced.

One drawback with my design is that it is not SCM-agnostic,
so some commands need multiple versions: one per SCM.
But I will only do git versions.

> 
> [0]
> http://www.cvstrac.org/index.html/doc/trunk/www/index.html
> [1]
> http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
> 
> 
> 
> On Mon, Apr 6, 2015 at 3:54 PM, Mattias Andrée
>  wrote:
> > 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 researching the
> >> > area. (But I assumed you had.) The best solution
> >> > to the problem that I know if is bugseverywhere,
> >> > but I think it is poorly designed and last time
> >> > I used it, it was very buggy. I guess one could
> >> > build a solution around it but I think that would
> >> > be a half-assed solution.
> >> >
> >> > The entry in 'project ideas' as not very
> >> > descriptive of what is needed, but I thought
> >> > that addressed later.
> >>
> >> Please don't CC the mail to me directly, the ml
> >> doesn't work like this here. ;)
> >>
> >> @topic: The software list is hopelessly outdated
> >> in many parts (I just removed a request to port
> >> stuff to bionic libc, which was an obvious DoA a
> >> few months ago).
> >>
> >> Please again tell me what it does better than
> >> bugseverywhere than only being less bug-ridden.
> >
> > Here is a list of what I think should be implemented.
> > 
> >
> >>
> >> Cheers
> >>
> >> FRIGN
> >>
> >
> 



pgp_cxz2CIs7M.pgp
Description: OpenPGP digital signature

Re: [dev] A suckless issue tracker

[Greg Reagle]

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.   I've been chuckling at your message so much.  Thanks for
the mirth.

P.S. My first sentence is an attempt at humor.

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
  love email again

Re: [dev] a suckless hex editor

[Greg Reagle]

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 "$infile" > "$tmpfile"
$EDITOR "$tmpfile"
$dedump $tmpfile > "$outfile"
rm "$tmpfile"

Re: [dev] a suckless hex editor

[Alex Pilon]

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 vim, regardless of anybody's feeling's on this list *either* way.


signature.asc
Description: PGP signature

Re: [dev] a suckless hex editor

[Greg Reagle]

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 reverse dump?

Command od of sbase is halfway there--it can dump (od -Ax -tx1).  If it 
were enhanced to reverse dump, we could use it.


On the other hand, it kind of sucks to reinvent the wheel.  Combining 
already existing tools sucks less, and xxd already exists.

Re: [dev] a suckless hex editor

[Louis Santillan]

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 on this list *either* way.
>
>
> Is there another tool that can do a reverse dump?
>
> Command od of sbase is halfway there--it can dump (od -Ax -tx1).  If it were
> enhanced to reverse dump, we could use it.
>
> On the other hand, it kind of sucks to reinvent the wheel.  Combining
> already existing tools sucks less, and xxd already exists.


tr, bc & awk?

Re: [dev] a suckless hex editor

[Greg Reagle]

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

[Matthew of Boswell]

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 the hex.
- no syntax checking, since the editor sees it as plain text
- can't edit very large files in-place; must parse/copy the entire file

>  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?

"xxd -r" doesn't do any syntax checking, according to the manpage. So,
overwriting the file would be like playing with fire. However, how
often do you hex edit a file without creating a backup first? Hex
editing is an error-prone operation regardless of the tool. If
outfile matches infile, consider moving/renaming the original file and
making it the backup. Might have to watch for permissions/"mount -ro"
errors, though.

-- 
Matt Boswell

Re: [dev] a suckless hex editor

[pancake]

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 for embedded (assuming no dependence on vim)
> 
> Cons:
> - can't edit the ascii values on the right; everything is parsed
> from the hex.
> - no syntax checking, since the editor sees it as plain text
> - can't edit very large files in-place; must parse/copy the entire file
> 
>> 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?
> 
> "xxd -r" doesn't do any syntax checking, according to the manpage. So,
> overwriting the file would be like playing with fire. However, how
> often do you hex edit a file without creating a backup first? Hex
> editing is an error-prone operation regardless of the tool. If
> outfile matches infile, consider moving/renaming the original file and
> making it the backup. Might have to watch for permissions/"mount -ro"
> errors, though.
> 
> -- 
> Matt Boswell
> 

Re: [dev] a suckless hex editor

[Greg Reagle]

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 1; }

tmpfile=$(mktemp) || exit 1
infile="$1"
outfile="$2"

od -Ax -tx1 "$infile" | head -n -1 > $tmpfile
$EDITOR "$tmpfile"
/bin/echo -ne $(tr -s ' ' < "$tmpfile" | cut -d' ' -f2-17 | awk '{for (i=1; 
i<=NF; i++) printf "\\x%s", $i}') > $outfile
rm "$tmpfile"

Re: [dev] a suckless hex editor

[Dimitris Papastamos]

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"; exit 1; }
> [ -z "$EDITOR" ] && { echo "\$EDITOR must be defined"; exit 1; }
> 
> tmpfile=$(mktemp) || exit 1
> infile="$1"
> outfile="$2"
> 
> od -Ax -tx1 "$infile" | head -n -1 > $tmpfile
> $EDITOR "$tmpfile"
> /bin/echo -ne $(tr -s ' ' < "$tmpfile" | cut -d' ' -f2-17 | awk '{for (i=1; 
> i<=NF; i++) printf "\\x%s", $i}') > $outfile
> rm "$tmpfile"

echo -e is evil, use printf(1)

Re: [dev] a suckless hex editor

[pancake]

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
>> hex dump.
> 
>> #!/bin/sh
>> [ -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"
>> 
>> od -Ax -tx1 "$infile" | head -n -1 > $tmpfile
>> $EDITOR "$tmpfile"
>> /bin/echo -ne $(tr -s ' ' < "$tmpfile" | cut -d' ' -f2-17 | awk '{for (i=1; 
>> i<=NF; i++) printf "\\x%s", $i}') > $outfile
>> rm "$tmpfile"
> 
> echo -e is evil, use printf(1)
> 

Re: [dev] a suckless hex editor

[pancake]

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 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 1; }
>> 
>> tmpfile=$(mktemp) || exit 1
>> infile="$1"
>> outfile="$2"
>> 
>> od -Ax -tx1 "$infile" | head -n -1 > $tmpfile
>> $EDITOR "$tmpfile"
>> /bin/echo -ne $(tr -s ' ' < "$tmpfile" | cut -d' ' -f2-17 | awk '{for (i=1; 
>> i<=NF; i++) printf "\\x%s", $i}') > $outfile
>> rm "$tmpfile"
> 
> echo -e is evil, use printf(1)
> 

Re: [dev] a suckless hex editor

[Connor Lane Smith]

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 should be used
instead.

Re: [dev] a suckless hex editor

[Nico Golde]

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 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, but it's 
not much more useful then dd or hd for that sake imho.
I think to the very minimum, a proper hex editor should have the capability to 
show both hex and ascii in parallel, work well with large files, provide 
useful searches, and provide support for templates. Everything else is just a 
toy.

Cheers,
Nico
-- 
Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0


pgpvT5_aBtkSX.pgp
Description: PGP signature

Re: [dev] a suckless hex editor

[Greg Reagle]

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

[Greg Reagle]

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-standard -- as are
> all echo flags, really -- and as Dimitris says printf should be used
> instead.

That's exactly right.  But I've moved from echo to printf as Dimitris advised.

Re: [dev] a suckless hex editor

[Greg Reagle]

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, but 
> it's 
> not much more useful then dd or hd for that sake imho.
> I think to the very minimum, a proper hex editor should have the capability 
> to 
> show both hex and ascii in parallel, work well with large files, provide 
> useful searches, and provide support for templates. Everything else is just a 
> toy.

I appreciate honest feedback.  I am well aware that this list is not known for
being warm and fuzzy, so don't worry about it.  I am also well aware that this
list has some very talented programmers on it.

I agree that it is a "poor man's" hex editor.  I am having fun with it, even if
it is a toy.  I don't have the desire to write a sophisticated hex editor
(besides they already exist).

I like that the small shell script can turn any editor into a hex editor.  BTW,
if od is replaced with hexdump -C or xxd or GNU od -tx1z, then the ascii will
be in the dump too.

Re: [dev] a suckless hex editor

[pancake]

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 don't get it.  Is this a Unixy geeky way of saying you don't like it?
> 

Re: [dev] a suckless hex editor

[Matthew of Boswell]

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 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?

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"'.

-- 
Matt Boswell

Re: [dev] a suckless hex editor

[Greg Reagle]

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

[Snobb]

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?
> >
> > […]
> >
> > #!/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 vim, regardless of anybody's feeling's on this list *either* way.

Re: [dev] A replacement for at.

[Kamil Cholewiński]

> satd is an unprivileged daemon that is user-private, and
> starts and exits automatically.

Why not use a service supervisor?

Re: [dev] A replacement for at.

[Mattias Andrée]

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 Cholewiński  wrote:

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




pgpCLZNIXTzCF.pgp
Description: OpenPGP digital signature

Re: [dev] A replacement for at.

[Mattias Andrée]

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
> > starts and exits automatically.  
> 
> Why not use a service supervisor?



pgpcihMsiY2cL.pgp
Description: OpenPGP digital signature

Re: [dev] A replacement for at.

[Kamil Cholewiński]

> 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 into daemons and
instead solve this problem in a portable and non-sucky way.

Re: [dev] A replacement for at.

[Mattias Andrée]

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 can have user-private services.  
> 
> Yes, please let's stop writing process management code
> into daemons and instead solve this problem in a portable
> and non-sucky way.

I'm not sure I understand that you are suggesting.



pgpV9OjpKiYm_.pgp
Description: OpenPGP digital signature

Re: [dev] A replacement for at.

[Greg Reagle]

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.

[Mattias Andrée]

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. There is still a possible, less important, race
condition, but this can be fixed if one thought it was
worth it.

> 
> > How could supervision be made mandatory without making
> > it tied into one solution.  
> 
> Simple: just don't fork, don't write PID files, don't do
> anything. You can turn /bin/cat into a daemon under
> supervisord, runit, svscan, systemd, nohup &, or any
> other of the million solutions, as long as you don't try
> to outsmart it.

Would this not require that the user configures satd to
be started by the supervisor? I would not want this because
I would almost never it.

'satd -f' will cause it not to fork, or do other things
that a traditional daemon would do.

> 
> K.



pgpPM7MgHWm1x.pgp
Description: OpenPGP digital signature

Re: [dev] A replacement for at.

[Kamil Cholewiński]

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/

I'm aware of runit, in fact it's my init and my x11 login session.

What we don't have is a convention; my "make install" can't rely on
runsvdir running in /service, /etc/service, /var/service, /run/service,
or any other million places I've seen it deployed; also there is no
convention like $HOME/service, or /var/spool/runit/$USER/service or
whatever, for per-user services.

K.

Re: [dev] A replacement for at.

[Mattias Andrée]

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 without a lot of features that does
> not need to be there. sat is also written to waste very
> little memory when it is inactive — since it is almost
> always inactive — fork–exec:s, libexec:s to do things when
> something happens.
> 
> satd is an unprivileged daemon that is user-private, and
> starts and exits automatically. The client programs (sat,
> satq, satr, satrm) communicates with satd using a domain
> socket. Unfortunately message queues (or bus:
> https://github.com/maandree/bus) was a not a good option
> because of unbounded message lengths.
> 
> satd is able to update online, and is able to recover its
> job queue if its shuts down unexpectedly.
> 
> I have released sat under the terms of the MIT License,
> in hope that it will be useful if you want to base your
> at-implement of it.
> 
> 
> Mattias Andrée
> 

I am rewritting it so that it will only use signals
and flock for interprocess communication.



pgpW27noqPLiK.pgp
Description: OpenPGP digital signature

[dev] a new suckless scheme interpreter

[rain1]

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/

[dev] A simple POSIX build system

[Hadrien Lacour]

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 features to allow for some
complex operations. But after a while I noticed that GNU make was just (poorly)
trying to fuse POSIX make with sh, while not being as good as both.

So here's an almost (see Dependencies) POSIX compliant build system built on
POSIX sh and POSIX make. Here are some features it has:
* Proper install/uninstall without needing install(1) nor readlink(1) -f to
  normalize PREFIX.
* Simple runtime path rewriting for sh(1) scripts, allowing for inplace and
  installed use alike.
* A compiler flag detector.
* With the aforementioned detector, easy handling of LTO and PGO for both
  gcc and clang.
* Some more compilation variables like NATIVE and STATIC or flag presets in
  the form of CONFIG.
* Gperf and lex files handling (note: a `file.lex` or `file.gperf` is
  expected to produce a `file.c`, because SUFFIX rules don't allow for
  `file.lex.c`).
* No macro/environment mess like make, we only use the environment since
  it's a nice builtin associative array and one that is automatically
  passed to subprocesses.
* Since it's sh, it's as extensive as it should be, no need to bolt so much
  on make, and with a different syntax to boot.


If this can help other people rolling complicated makefiles, I guess it could
be nice. Criticism is welcome.


Regards,
Hadrien Lacour

[dev] A suckless X11 Widget Toolkit

[Lucas de Sena]

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).

Currently, the only implemented widget is the text input field (called
`CtrlTextField` internally).   There is a demonstration program in the
demos/ directory.   The demo program, called "prompt" is just a simple
dmenu-like input field that echoes what the user types into the stdout
when the user press Enter.  Unlike dmenu, control's input field widget
supports extended line editing features, like undo/redo (on Ctrl-Z and
Ctrl-Shift-Z), mouse-based cursor movement and emacs-like keybindings.

For the input field, I'm still using UTF-8 points as whole characters,
to move between input characters for example.  An ideal solution would
be to use something like libgrapheme.  I'll use it in the future.

You can run `make all` (or only `make`) to build the library, or `make
demos` to build the demonstration programs (there's only one for now).
Under the doc/ directory, there is an extensive manual page written in
mdoc(7).

One of the reasons I'm announcing this project here is that I think it
may be interesting for suckless users and developers, as some suckless
programs are X11 programs that implements basic widget functionalities
from scratch (this is the case of dmenu, which implements text editing
features in plain Xlib).

The other reason is to ask for help, by invinting people to join me in
this project.  A widget set is only a set of widgets if there are more
than one widget to make it a set (otherwise it's not a widget set, but
a widget singleton).   Anyone willing to work on a X11 toolkit, please
mail me.  The project is currently hosted in GitHub, but if you're not
comfortable with Microsoft's GitHub(TM), I may host it somewhere else.

There's still much to do in order for control to be usable.  I need to
write a Shell widget to communicate with the WM (so clicking the close
button on the window manager also closes the application); I also need
to write manager/composite widgets and other primitive widgets, like a
label and a push button, which will be implemented as gadgets instead.

Although the project is in its (very) initial stage, what do you think
of it? Would you use (or program with) a GUI toolkit?  The only simple
and suckless-y widget set I know of is X11/Motif, but it is likely not
developed anymore...  It's kinda badly written, with an ugly codebase.

Thanks,
Lucas "seninha" de Sena (https://seninha.org)

[1]: https://github.com/phillbush/control
[2]: https://www.x.org/releases/current/doc/libXt/intrinsics.html

Re: [dev] A secure wireless protocol

[Hiltjo Posthuma]

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 private keys.
> 
> 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,
> 
> 
> 
> A list of MAC addresses would be maintained on WiFi server end for each 
> device. Are there already such network softwares made out there?
> 
> The aim is no dhcp and not a single device outside list can communicate.
> Thanking you
> Sagar Acharya
> https://humaaraartha.in/selfdost/selfdost.html
> 

There are different levels of networking layers implementing secure tunnels in
different layers (IPSec, TLS, HTTPS, Wireguard, Encrypted XMLs over HTTPS). You
could even use public/private encrypted messages on sticky notes or by
carrier-pigeon.

Maybe I'm getting too old and conservative, but I'd use the standards (RFC)
that are there. Bluetooth kinda sucks though.

-- 
Kind regards,
Hiltjo

Re: [dev] A secure wireless protocol

[Sergey Matveev]

*** 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 packet (or TCP segment, UDP datagram,
whatever) is pretty harsh.

Moreover if you use modern ECC-based algorithm like curve25519 (that is
magnitudes faster than RSA for example, and has pretty compact public
keys), then take into account that it can not "encrypt" data, but only
to exchange/derive the shared key between the sender and recipient, so
you will have to send ephemeral public key with each packet, that will
also take at least 32 bytes of the payload more. Like "crypto_box" of
NaCl does: https://nacl.cr.yp.to/box.html

So if you want usable efficiency, in general you have to do some kind of
the handshake, to share the common cryptographic state and then use
efficient symmetric cryptography further, like nearly all transport
protocols do.

Maybe something like Yggdrasil would be interesting to you:
https://yggdrasil-network.github.io/
Each peer has its own public/private keypair and corresponding IPv6
address (from 200::/7 space) is derived from the public key. So you can
directly communicate with the peer knowing that address in advance.
Yggdrasil implementations can discover each other other the multicast IP
network (Ethernet/WiFi) without any additional configuration,
transparently building the meshed interconnected overlay network.
Basically no configuration required (IPv6 link-local addresses should be
always present on network interfaces, link-scope multicast packets will
find Yggdrasil capable nodes nearby) and you can transparently
communicate with each node by its 200::/7 IPv6 address.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A

Re: [dev] A secure wireless protocol

[Sergey Matveev]

*** 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 rule.

>Where can I find a comparison of all or maximum number of encryption algos and 
>their speeds?

For example LibreSSL/OpenSSL has "openssl list" command and "speed".
https://bench.cr.yp.to/
*25519 as a rule the fastest among well-studied asymmetric algorithms
https://cr.yp.to/ecdh.html
Anyway, why do you want to know that information? Are you going to
implement your own cryptographic protocol? If no, then you should
look/choose existing implementations/solutions and benchmark/compare
them, because even slow-as-hell RSA can be a tiny part of overall
computations and the speed of just DH/sign operation can be negligible
and play no role.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A

Re: [dev] A secure wireless protocol

[Sergey Matveev]

*** 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
without you noticing it at all.

>I said, what I want to do. Within wireless space, I want to trasmit a packet 
>with a fixed header and encrypted data packet.

Fire up any kind of VPN. IPsec, WireGuard, whatever. They can
transparently secure you IP traffic. IPsec (ESPv3) will literally has
its own ESP-header that will carry encrypted+authenticated plaintext IP
packet.

>I saw, ec cryptography is just signing, will not work.

No it is not only for signing. At least it is also for key agreement.

If you do not trust WiFi/Bluetooth/public-Ethernet security/encryption
(that is completely sane and understandable), then just start VPN over
that insecure channel. IPsec (ESP with AEAD ciphers (ChaCha20-Poly1305
or hardware accelerated AES-GCM) + IKEv2 with *25519 key agreement
algorithm) or WireGuard are the fastest in nearly all cases. If you do
not want to set any kind of IP addresses manually (or by SLAAC/DHCP*),
then (at least) WireGuard can work over IPv6 link-local addresses
without any problems (I do it).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A

Re: [dev] A secure wireless protocol

[Sergey Matveev]

*** 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 used for authenticaion.
(Symmetric) Encryption key of course is derived every time
the IKEv2 session is started with the peer.

>Where does it lie?

Where you wish for. Depends on implementation. IPsec itself, its
transport part (ESP protocol) generally live inside the kernel itself.
IKEv2 daemon (like strongSwan for example) lives in userspace.

>Is it secure?

Depends on configuration parameters, implementation. IKEv2/ESPv3
protocols in general are secure, yes.

>In the former case, client will return an md5 sum of earlier packet data to 
>confirm it received.

1) Neither IPsec, nor WireGuard, nor OpenVPN confirm that packet is
received. They just transparently make a secure tunnel for *IP* packets.
There is just no need in that kind of confirmation. Why? Internet
Protocol is "fire and forget" by design: it just sends IP packet and
forgets about it, job is done. If you want guaranteed delivery, then it
is the business of transport protocols above, like TCP.
IPsec/WireGuard/any-VPN secures IP-level.

2) MD5 in 2023? I hope no, it is not used. Well, actually MD5 is not
used as a hash function in IPsec (ESP), but as a part of HMAC-MD5, that
is actually still considered safe. But why one need to use that ancient
stuff? Modern protocols (WireGuard, Noise, TLS 1.3) use only
AEAD-algorithms, where "MAC" is some kind of integrated with the
encryption algorithm and they are always used together. IPsec supports
AEAD-ciphers in modern OSes a long time ago.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A

Re: [dev] A secure wireless protocol

[Josuah Demangeon]

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, Fortinet,
Cisco...

> >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 used for authenticaion.
> (Symmetric) Encryption key of course is derived every time
> the IKEv2 session is started with the peer.

In attachment, a small "x509" script that I place in my ~/bin to manage
certificate by wrapping some of the OpenSSL's tedious syntax. Not
prime quality, but could help to get started.

> >Where does it lie?
> 
> Where you wish for. Depends on implementation. IPsec itself, its
> transport part (ESP protocol) generally live inside the kernel itself.
> IKEv2 daemon (like strongSwan for example) lives in userspace.

I forgot about that, good point!

IPsec is a bit particular as it does not have any network interface
for the VPN itself, instead the kernel intercepts the packets going
out if they match the configured rule (from Priv1 to Priv2) then
encrypt/reroute them and directly send them (from Pub1 to Pub2).

Because it all happens in the kernel with no network interface,
troubleshooting is a bit particular.

Not possible to do "tcpdump -i ipsec0" to see the packets going
*over* the VPN as there is no network interface for it (OpenBSD
added the pflog interface for tcpdump purpose though).

So the various tools like tcpdump, firewall config syntax, etc.
have special handling and syntax for it. Keyword: "XFRM".

After some time working with it, it becomes more intuitive, but
on day 1 I was lost! :)

> >Is it secure?
> 
> Depends on configuration parameters, implementation. IKEv2/ESPv3
> protocols in general are secure, yes.

It is used by banks, phone systems, corporate VPNs...

For debugging, you can try "PSK" or "pre-shared key" authentication
which is just a password, to avoid to combine the difficulty of
X.509 and IPsec.

Josuah.


x509
Description: application/shellscript

Re: [dev] A secure wireless protocol

[Sergey Matveev]

*** 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.
https://man.freebsd.org/cgi/man.cgi?query=if_ipsec&sektion=4
Personally I just used to use gif-tunnels (IP-in-IP) and apply transport
mode ESP to them. Basically it has more-or-less (if we forget about ECN
at least) the same behaviour/efficiency as native tunnel mode (that also
encapsulates IP in IP and encrypts traffic between two tunnel endpoints)
but at least you have gif-interface you can conveniently tcpdump.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A

Re: [dev] A secure wireless protocol

[Josuah Demangeon]

> (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: listening on enc0, link-type ENC
#

Re: [dev] A secure wireless protocol

[Josuah Demangeon]

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 packets flowing over that VPN.
>https://man.freebsd.org/cgi/man.cgi?query=if_ipsec&sektion=4

That is convenient and intuitively named.

>Personally I just used to use gif-tunnels (IP-in-IP) and apply transport
>mode ESP to them. Basically it has more-or-less (if we forget about ECN
>at least) the same behaviour/efficiency as native tunnel mode (that also
>encapsulates IP in IP and encrypts traffic between two tunnel endpoints)
>but at least you have gif-interface you can conveniently tcpdump.

This is some interesting setup. Then it is not needed to change the IPsec
configuration files all of the time, and firewall and routing rules can
be edited normally.

Re: [dev] A secure wireless protocol

[Josh Lawrence]

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 controlled by the FCC.  I 
just began my studies to become a licensed amateur radio operator ("HAM"), and 
it's clear to me from my studies that anything that broadcasts unlicensed 
signals will be quickly located and shut down.  There may be bands that are not 
as tightly controlled, I'll need to defer to someone smarter than me.

All of this is US-specific, I have no clue about other countries' regulations.

-- 
Josh Lawrence
joshlawre...@fastmail.com

[dev] A tiny IRC connection tool

[Connor Lane Smith]

Hey all,

I've written a tiny (90 SLOC) tool for connecting to an IRC server and
streaming the connection over stdin/stdout, while responding to (and
filtering out) pings. I just wrote this so I could write simpler IRC
bots without having to worry about TCP, pings, or having to reconnect
every time I want to re-exec when I update the bot. The auto-ping also
works well for logging. I don't know, it might come in handy for
someone.

Thanks,
cls
/* (c) 2012, Connor Lane Smith  */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define MAX(x,y)  ((x) > (y) ? (x) : (y))

static void stream(int, int, int);
static int dial(const char *, const char *);
static void eprintf(const char *, ...);

int
main(int argc, char *argv[])
{
	const char *host, *port;
	fd_set rfds;
	int srv;

	if(argc != 2 && argc != 3)
		eprintf("usage: %s host [port]\n", argv[0]);

	host = argv[1];
	port = (argc == 3) ? argv[2] : "6667";
	srv = dial(host, port);

	for(;;) {
		FD_ZERO(&rfds);
		FD_SET(STDIN_FILENO, &rfds);
		FD_SET(srv, &rfds);

		if(select(MAX(STDIN_FILENO, srv) + 1, &rfds, NULL, NULL, NULL) == -1)
			break;
		if(FD_ISSET(srv, &rfds))
			stream(srv, STDOUT_FILENO, 1);
		if(FD_ISSET(STDIN_FILENO, &rfds))
			stream(STDIN_FILENO, srv, 0);
	}
	return EXIT_SUCCESS;
}

void
stream(int in, int out, int pings)
{
	char buf[BUFSIZ];
	int n = 0, t = 0;

	/* DIY line buffering */
	while(n < sizeof buf - 1 && (t = read(in, &buf[n], 1)) == 1)
		if(buf[n++] == '\n')
			break;
	if(t == -1)
		eprintf("read error:");
	/* check for ping commands */
	if(pings && n >= 5 && !strncmp(buf, "PING ", 5)) {
		buf[1] = 'O'; /* ping becomes pong */
		out = in;
	}
	if(write(out, buf, n) != n)
		eprintf("write error:");
}

int
dial(const char *host, const char *port)
{
	struct addrinfo hints, *res, *r;
	int fd;

	memset(&hints, 0, sizeof hints);
	hints.ai_family = AF_UNSPEC;
	hints.ai_socktype = SOCK_STREAM;
	if(getaddrinfo(host, port, &hints, &res) != 0)
		eprintf("cannot resolve hostname '%s':", host);

	for(r = res; r; r = r->ai_next) {
		if((fd = socket(r->ai_family, r->ai_socktype, r->ai_protocol)) == -1)
			continue;
		if(connect(fd, r->ai_addr, r->ai_addrlen) == 0)
			break;
		close(fd);
	}
	freeaddrinfo(res);
	if(!r)
		eprintf("cannot connect to host '%s'\n", host);
	return fd;
}

void
eprintf(const char *fmt, ...)
{
	va_list ap;

	va_start(ap, fmt);
	vfprintf(stderr, fmt, ap);
	va_end(ap);

	if(fmt[0] != '\0' && fmt[strlen(fmt)-1] == ':') {
		fputc(' ', stderr);
		perror(NULL);
	}
	exit(EXIT_FAILURE);
}

Re: [dev] a suckless init system?

[Hugues Moretto-Viry]

That's a really good question!
Maybe, I already know what suckless thinks about SystemD.

-- 
Envoyé d'Archlinux

Re: [dev] a suckless init system?

[Kurt H Maier]

On Tue, Aug 14, 2012 at 01:36:55PM -0400, Calvin Morrison wrote:
> Hey all,
> 
> Recently on the Arch mailing list there has been much discussion of
> different init systems. I was just wondering which init system, y'all
> approve of. SysV or OpenRC pretty suckless and unix-y to me.
> 
> What do you think?

Both are crap.  openrc in particular is some serious amateur-hour
garbage.  Crux's init has good bones, but lacks finishing.  More distros
should focus on using init to bring up the system and then leave
userspace daemons to daemontools or such.

Re: [dev] a suckless init system?

[Calvin Morrison]

On 14 August 2012 13:50, Kurt H Maier  wrote:
> On Tue, Aug 14, 2012 at 01:36:55PM -0400, Calvin Morrison wrote:
>> Hey all,
>>
>> Recently on the Arch mailing list there has been much discussion of
>> different init systems. I was just wondering which init system, y'all
>> approve of. SysV or OpenRC pretty suckless and unix-y to me.
>>
>> What do you think?
>
> Both are crap.  openrc in particular is some serious amateur-hour
> garbage.  Crux's init has good bones, but lacks finishing.  More distros
> should focus on using init to bring up the system and then leave
> userspace daemons to daemontools or such.
>

maybe I will work on a new init system :p

Re: [dev] a suckless init system?

[hiro]

first initiate sanity in your brain

Re: [dev] a suckless init system?

[Sam Watkins]

There are dependency based init systems, should use mk for it.

net: 1
inetd: net
2: getty inetd

mk 2   # go to runlevel 2
   # inetd crashes
mk 2   # bring it back to life

It would need some sort of procfs view with process names, where unlink
sends a term signal, and some extra features for mk, to remove
objects in various ways.  That could be done in a separate program.

mk -rm inetd   # stop inetd (and anything that depends on it)
mk -rmdeps 1   # go back to just runlevel 1

Ok, now I should install some sanity into my brain.

I wonder if people get kicked off the list for posting stuff like this?

Sam

Re: [dev] a suckless init system?

[pancake]

Using mk takes sense as long as init scripts are a dependency based system. 
Please go on. That looks fun

Looks like doing suckless software implies surviving to troll comments.

Your software will be suckless when trolls stop throwing rocks at it.

On Aug 15, 2012, at 6:02, Sam Watkins  wrote:

> There are dependency based init systems, should use mk for it.
> 
> net: 1
> inetd: net
> 2: getty inetd
> 
> mk 2   # go to runlevel 2
>   # inetd crashes
> mk 2   # bring it back to life
> 
> It would need some sort of procfs view with process names, where unlink
> sends a term signal, and some extra features for mk, to remove
> objects in various ways.  That could be done in a separate program.
> 
> mk -rm inetd   # stop inetd (and anything that depends on it)
> mk -rmdeps 1   # go back to just runlevel 1
> 
> Ok, now I should install some sanity into my brain.
> 
> I wonder if people get kicked off the list for posting stuff like this?
> 
> Sam
> 

Re: [dev] a suckless init system?

[Jens Staal]

torsdagen den 16 augusti 2012 06.59.45 skrev  pancake:
> Using mk takes sense as long as init scripts are a dependency based system.
> Please go on. That looks fun
> 
> Looks like doing suckless software implies surviving to troll comments.
> 
> Your software will be suckless when trolls stop throwing rocks at it.
> 
> On Aug 15, 2012, at 6:02, Sam Watkins  wrote:
> > There are dependency based init systems, should use mk for it.
> > 
> > net: 1
> > inetd: net
> > 2: getty inetd
> > 
> > mk 2   # go to runlevel 2
> > 
> >   # inetd crashes
> > 
> > mk 2   # bring it back to life
> > 
> > It would need some sort of procfs view with process names, where unlink
> > sends a term signal, and some extra features for mk, to remove
> > objects in various ways.  That could be done in a separate program.
> > 
> > mk -rm inetd   # stop inetd (and anything that depends on it)
> > mk -rmdeps 1   # go back to just runlevel 1
> > 
> > Ok, now I should install some sanity into my brain.
> > 
> > I wonder if people get kicked off the list for posting stuff like this?
> > 
> > Sam

There is a mk-based init system that was initially presented here:

http://9fans.net/archive/2009/10/375

perhaps a start?

Re: [dev] a suckless init system?

[David Tweed]

I'll just note that, regardless of code quality, etc, there's the
question of what the end-user usability goals for an init system
should be.

Is it just to bring up the system, or is it to bring up the system
fast enough to use in an "quickbooting" environment (<5s off an SSD)?
I'm very inclined towards the later, but that's partly because I use
net-tops in impromptu settings (and it seems like resume from
hibernate (due to suspend-to-ram for 8 hours eating too much battery)
is slower than a reboot from scratch).

On Thu, Aug 16, 2012 at 9:53 AM, Jens Staal  wrote:
> torsdagen den 16 augusti 2012 06.59.45 skrev  pancake:
>> Using mk takes sense as long as init scripts are a dependency based system.
>> Please go on. That looks fun
>>
>> Looks like doing suckless software implies surviving to troll comments.
>>
>> Your software will be suckless when trolls stop throwing rocks at it.
>>
>> On Aug 15, 2012, at 6:02, Sam Watkins  wrote:
>> > There are dependency based init systems, should use mk for it.
>> >
>> > net: 1
>> > inetd: net
>> > 2: getty inetd
>> >
>> > mk 2   # go to runlevel 2
>> >
>> >   # inetd crashes
>> >
>> > mk 2   # bring it back to life
>> >
>> > It would need some sort of procfs view with process names, where unlink
>> > sends a term signal, and some extra features for mk, to remove
>> > objects in various ways.  That could be done in a separate program.
>> >
>> > mk -rm inetd   # stop inetd (and anything that depends on it)
>> > mk -rmdeps 1   # go back to just runlevel 1
>> >
>> > Ok, now I should install some sanity into my brain.
>> >
>> > I wonder if people get kicked off the list for posting stuff like this?
>> >
>> > Sam
>
> There is a mk-based init system that was initially presented here:
>
> http://9fans.net/archive/2009/10/375
>
> perhaps a start?
>
>



-- 
cheers, dave tweed__
high-performance computing and machine vision expert: david.tw...@gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot

Re: [dev] a suckless init system?

[Kurt H Maier]

On Thu, Aug 16, 2012 at 12:00:03PM +0100, David Tweed wrote:
> I'll just note that, regardless of code quality, etc, there's the
> question of what the end-user usability goals for an init system
> should be.

No.  An "end user" should not even be aware init exists.  The people an
init system has to impress are systems administrators.

Re: [dev] a suckless init system?

[Robert Ransom]

On 8/14/12, Kurt H Maier  wrote:
> More distros
> should focus on using init to bring up the system and then leave
> userspace daemons to daemontools or such.

Does Plan 9 need a service supervision service (like daemontools on Unixoids)?

If it does need one, what should it look like?


Robert Ransom

Re: [dev] a suckless init system?

[David Tweed]

Well, yes-and-no. The end user (who in the case of many linux desktops
and laptops is also the sys admin) may not be aware of how things are
structured "under the hood", but they can perceive "laptop X spends a
lot of time doing stuff when I turn it on, while laptop Y is usable
almost instantly". The only reason I mentioned it (I otherwise try and
stay out of "religiously" tinted discussions was that there was
discussion about how to do it but no mention of what the important
"externally visible" (if you don't like "end-user") goals should be.

On Thu, Aug 16, 2012 at 2:32 PM, Kurt H Maier  wrote:
> On Thu, Aug 16, 2012 at 12:00:03PM +0100, David Tweed wrote:
>> I'll just note that, regardless of code quality, etc, there's the
>> question of what the end-user usability goals for an init system
>> should be.
>
> No.  An "end user" should not even be aware init exists.  The people an
> init system has to impress are systems administrators.
>



-- 
cheers, dave tweed__
high-performance computing and machine vision expert: david.tw...@gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot

Re: [dev] a suckless init system?

[Kurt H Maier]

On Thu, Aug 16, 2012 at 02:39:43PM +0100, David Tweed wrote:
> Well, yes-and-no. The end user (who in the case of many linux desktops
> and laptops is also the sys admin) may not be aware of how things are
> structured "under the hood", but they can perceive "laptop X spends a
> lot of time doing stuff when I turn it on, while laptop Y is usable
> almost instantly". The only reason I mentioned it (I otherwise try and
> stay out of "religiously" tinted discussions was that there was
> discussion about how to do it but no mention of what the important
> "externally visible" (if you don't like "end-user") goals should be.

For init systems, speed is a natural consequence of correct design.
Only an incompetent would have to explicitly list it as a design goal.

Re: [dev] a suckless init system?

[David Tweed]

On Thu, Aug 16, 2012 at 3:19 PM, Kurt H Maier  wrote:
> On Thu, Aug 16, 2012 at 02:39:43PM +0100, David Tweed wrote:
>> Well, yes-and-no. The end user (who in the case of many linux desktops
>> and laptops is also the sys admin) may not be aware of how things are
>> structured "under the hood", but they can perceive "laptop X spends a
>> lot of time doing stuff when I turn it on, while laptop Y is usable
>> almost instantly". The only reason I mentioned it (I otherwise try and
>> stay out of "religiously" tinted discussions was that there was
>> discussion about how to do it but no mention of what the important
>> "externally visible" (if you don't like "end-user") goals should be.
>
> For init systems, speed is a natural consequence of correct design.
> Only an incompetent would have to explicitly list it as a design goal.

Maybe I have no claim to real competence..., but I always tend to find
that if the software design goals aren't pretty concrete listing even
the "obvious" things then either (a) someone else will consider
something I find obvious to be a "why do you want that" or (b) someone
else's obvious is my "why on earth would you want that".

Anyway, here's a comment that I remembered reading the first time round

http://lwn.net/Articles/300955/

Note that the point isn't whether fast boot is an important enough
goal to impact in other trade-off's (I think it is, others may think
it's less important than simplicity), as much as that it's something
where it's better to come to an explicit design goal decision.

Re: [dev] a suckless init system?

[Jukka Ruohonen]

On Tue, Aug 14, 2012 at 01:50:53PM -0400, Kurt H Maier wrote:
> Both are crap.  openrc in particular is some serious amateur-hour

I love it when suckless talks about amateur hours.

Maybe it is time to rewrite cat again?

- Jukka

Re: [dev] a suckless init system?

[Kurt H Maier]

On Sat, Aug 18, 2012 at 12:11:47PM +0300, Jukka Ruohonen wrote:
> 
> I love it when suckless talks about amateur hours.
> 
> Maybe it is time to rewrite cat again?
> 

Are you saying there is no value to be gained in simple implementations,
are you saying that there are problems you wish fixed in sbase cat and
that you have a patch, or are you just being a whining loser because
I wasn't impressed with some awful init system?

Just trying to ascertain if you have ever sent an email worth reading.

Re: [dev] a suckless init system?

[Anselm R Garbe]

On 14 August 2012 19:36, Calvin Morrison  wrote:
> Recently on the Arch mailing list there has been much discussion of
> different init systems. I was just wondering which init system, y'all
> approve of. SysV or OpenRC pretty suckless and unix-y to me.
>
> What do you think?

init should just execute /etc/rc and leave it up to the script.

Cheers,
Anselm

Re: [dev] a suckless init system?

[pancake]

Executables in etc? :)

On Aug 30, 2012, at 20:26, Anselm R Garbe  wrote:

> On 14 August 2012 19:36, Calvin Morrison  wrote:
>> Recently on the Arch mailing list there has been much discussion of
>> different init systems. I was just wondering which init system, y'all
>> approve of. SysV or OpenRC pretty suckless and unix-y to me.
>> 
>> What do you think?
> 
> init should just execute /etc/rc and leave it up to the script.
> 
> Cheers,
> Anselm
> 

Re: [dev] a suckless init system?

[sl]

> Executables in etc? :)

Aside from the historical precedent, even OpenBSD runs scripts located in /etc.

-sl

Re: [dev] a suckless init system?

[Calvin Morrison]

On 30 August 2012 14:40,   wrote:
>> Executables in etc? :)
>
> Aside from the historical precedent, even OpenBSD runs scripts located in 
> /etc.
>
> -sl
>

I don't really care where my executables are as long as my paths are
setup correctly. Which they are.

Re: [dev] a suckless init system?

[Anselm R Garbe]

On 30 August 2012 20:37, pancake  wrote:
> Executables in etc? :)

I don't mind breaking the rules and moving it to /bin/, but I need the
system running first to get a feel for it.

Re: [dev] A window without focus

[Sam Watkins]

Manolo Mart?nez wrote:
> I have a cronjob that launches a window with notify-send "Low
> Battery" when, well, the battery is low.
> 
> Is there a way to prevent this window from stealing focus?

Use a window manager that doesn't steal focus?
What window manager are you using?
Seems off topic, unless you're asking about a suckless window manager.

Re: [dev] A window without focus

[Hugues Moretto-Viry]

I'm pretty sure he's using dwm...

2012/10/26 Sam Watkins 

> Use a window manager that doesn't steal focus?
> What window manager are you using?
> Seems off topic, unless you're asking about a suckless window manager.
>
>

[dev] A small patch for sic.

[Mark Edgar]

diff --git a/util.c b/util.c
index 26953d0..8afa58f 100644
--- a/util.c
+++ b/util.c
@@ -49,7 +49,7 @@ strlcpy(char *to, const char *from, int l) {

 static char *
 eat(char *s, int (*p)(int), int r) {
-   while(s != '\0' && p(*s) == r)
+   while(*s != '\0' && p(*s) == r)
s++;
return s;
 }

Hope that's in order!  :)

 -Mark

[dev] A lightwieight and working typesetting system.

[QUINTIN Guillaume]

Hi,

Do you guys know a (working) typesetting system other than latex ?
And a good soft to make presentations ?

Thanks.