Re: [dev] piscou?

[Страхиња Радић]

Дана 24/05/04 12:48PM, Hiltjo Posthuma написа:
> Have you reported this issue to the author of piscou?

No. There is actually a number of issues with the program itself 
(for example: under the #ifdef DEBUG it calls both dunstify and 
notify-send - it loops over the list).

This is more about its presence on /rocks.

[dev] piscou?

[Страхиња Радић]

While browsing through the commits to /sites, I noticed a program 
piscou[1]. Just looking at its Makefile, it seems to include dubious 
code such as:

  clang: CC=clang
  clang: CFLAGS += -Weverything -Wno-unsafe-buffer-usage
  clang: clean release

and

  piscou: $(src) $(headers) Makefile
-ctags --kinds-C=+l *.h *.c
-vtags.sed tags > .tags.vim
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(src) $(ldlibs)

and doesn't even compile (tested on Artix Linux and OpenBSD). On 
OpenBSD, I get:

  $ make
  make: don't know how to make CFLAGS (prerequisite of: release)
  Stop in /home/strajder/src/piscou

About the program itself, I think that something like nopen[2] from the 
file manager noice[3] with its 103 LoC better represents the suckless 
principles than piscou.

About the license, piscou uses the GNU Affero license, whose purpose 
is[4]:

> The purpose of the GNU Affero GPL is to prevent a problem that 
> affects developers of free programs that are often used on servers.
[...]
> But suppose the program is mainly useful on servers. When D modifies 
> the program, he might very likely run it on his own server and never 
> release copies. Then you would never get a copy of the source code of 
> his version, so you would never have the chance to include his changes 
> in your version. You may not like that outcome.
>
> Using the GNU Affero GPL avoids that outcome. If D runs his version on 
> a server that everyone can use, you too can use it. 

in other words, it is intended for server software. piscou is supposed 
to be an interactive program, possibly running a GUI previewer?

P.S: From the synopsis, the percent-signs

  piscou %piscou-filename% [%piscou-extra0% %piscou-extra1% ...]

don't seem to be literal, so the syntax is confusing. Looks like it is 
taken from Microsoft's COMMAND.COM variable substitution?

I suggest removal.

[1]: 
https://git.suckless.org/sites/commit/a540477f182ef370a7e2aa6ef850889b6b92bbfa.html
[2]: https://git.codemadness.org/noice/file/nopen.c.html
[3]: https://git.codemadness.org/noice/log.html
[4]: https://www.gnu.org/licenses/why-affero-gpl.html

Re: [dev] [sbase] Defining scope of sbase and ubase

[Страхиња Радић]

On 24/03/09 05:28PM, Elie Le Vaillant wrote:
> Or is it out-of-scope for us to implement a full-blown shell? I really am
> not sure.

I think it would be interesting to have "official" suckless versions of all of 
the mentioned programs, which would at minimum implement their descriptions 
from POSIX while keeping suckless principles. In cases where POSIX is vague, 
there is nothing stopping the authors to implement their take on the acceptable 
behavior of those programs.

Re: [dev] [sbase] Defining scope of sbase and ubase

[Страхиња Радић]

On 24/03/09 12:59AM, Mattias Andrée wrote:
> I agree, a single repo (or alternatively making libutil it's own repo) is
> necessary if we want one binary, and I think we do.

Compiling all programs into one binary is currently an option, and IMHO it 
should remain an option. In my own toy distro[1] based on Musl-LFS and using 
sbase and ubase I compile all programs from {s,u}base separately.

The reasons why I consider that beneficial over a single executable include, 
but are not limited to:

- Easier to maintain: if an administrator decides a utility is unnecessary or 
  shouldn't be available, it comes down to rm-ing the file vs recompilation of 
  the entire *box.

- More robust: in case of disk corruption, all of the utilities are unavailable 
  vs only those affected.

- Fine-grained control: separate programs can be compiled using specific
  compilation options (eg. -g -O0) vs all of the programs sharing compilation 
  options.

etc.


> Even if submodules was possible, I do not think they are a good solution.

What makes the git submodules not possible?


> Using submodules is unpleasant and pointless since all could is under our
> control. I think submodules should only be used for code that you do not
> have control over but need the source code for. Either you have separate
> repos and have normal compile time dependencies (require that the libraries
> are installed) or you put everything in one place, one repo.

Everything in the quoted part seems personal preference. Git submodules offer a 
way to easily establish a hierarchy of git repositories while keeping them as 
separate "units".

So the libutil differs in sbase and ubase. Great, combine the two versions of 
libutil into a single, separate libutil repository, then have a directory 
hierarchy like this:

corebox
├──sbase (portable only)  \
├──ubase (nonportable) depend on libutil.so and/or libutil.a
├──xbase (non-POSIX)  /
└──libutil (option to produce .so and/or .a)



[1]: https://strahinja.srht.site/galeb

Re: [dev] [sbase] Defining scope of sbase and ubase

[Страхиња Радић]

On 24/03/08 06:40AM, Roberto E. Vargas Caballero wrote:
> I would like to move the discussion here and see what alternatives
> we have and how to proceed in this case.

IMHO, if the intention behind sbase was to provide a minimal portable POSIX 
utilities implementation, anything not fitting that definition should be moved 
out of sbase.

A separate project, perhaps called [insert_letter]base, could cover the 
utilities not in POSIX which are common in Unix-like systems.

The problem of having separate *box executables could be solved by creating an 
"umbrella" *box project, perhaps having sbase, ubase and [insert_letter]base as 
git submodules, and deciding what to build based on the contents of config.mk.

Re: [dev] [st] externalpipe on OpenBSD

[Страхиња Радић]

Hi, can anyone take a look at this and approve or comment if there is anything 
to add to or change about the patch?

https://lists.suckless.org/wiki/2402/4748.html

Re: [dev] [st] externalpipe on OpenBSD

[Страхиња Радић]

On 24/02/21 10:12AM, Страхиња Радић wrote:
> [...] (the program specified in openurlcmd doesn't get 
> executed).

I narrowed this down to adding "exec" to the second pledge:

+@@ -803,7 +809,7 @@ ttynew(const char *line, char *cmd, const char *out, char 
**args)
+   break;
+   default:
+ #ifdef __OpenBSD__
+-  if (pledge("stdio rpath tty proc", NULL) == -1)
++  if (pledge("stdio rpath tty proc exec", NULL) == -1)
+   die("pledge\n");
+ #endif

with the added "exec", the program in openurlcmd gets executed. What I don't 
know, however, is why is st not aborted if it is in violation of pledge, 
instead of silently failing. The changed pledge is in the parent, which 
continues execution.


> I also noticed that when I simply comment out the pledge, the program is 
> executed, but nothing is passed to openurlcmd.

Disregard this, it was due to having the debug version of script in openurlcmd 
still installed in the system.

* * *

Anyway, I have attached the proposed "0.8.5" diff with this message. Is it ok 
if I try to commit it to the wiki?
diff --git a/st.c b/st.c
index 034954d..98f2589 100644
--- a/st.c
+++ b/st.c
@@ -718,8 +718,14 @@ sigchld(int a)
 	if ((p = waitpid(pid, , WNOHANG)) < 0)
 		die("waiting for pid %hd failed: %s\n", pid, strerror(errno));
 
-	if (pid != p)
+	if (pid != p) {
+		if (p == 0 && wait() < 0)
+			die("wait: %s\n", strerror(errno));
+
+		/* reinstall sigchld handler */
+		signal(SIGCHLD, sigchld);
 		return;
+	}
 
 	if (WIFEXITED(stat) && WEXITSTATUS(stat))
 		die("child exited with status %d\n", WEXITSTATUS(stat));
@@ -803,7 +809,7 @@ ttynew(const char *line, char *cmd, const char *out, char **args)
 		break;
 	default:
 #ifdef __OpenBSD__
-		if (pledge("stdio rpath tty proc", NULL) == -1)
+		if (pledge("stdio rpath tty proc exec", NULL) == -1)
 			die("pledge\n");
 #endif
 		close(s);
@@ -1991,6 +1997,59 @@ strparse(void)
 	}
 }
 
+void
+externalpipe(const Arg *arg)
+{
+	int to[2];
+	char buf[UTF_SIZ];
+	void (*oldsigpipe)(int);
+	Glyph *bp, *end;
+	int lastpos, n, newline;
+
+	if (pipe(to) == -1)
+		return;
+
+	switch (fork()) {
+	case -1:
+		close(to[0]);
+		close(to[1]);
+		return;
+	case 0:
+		dup2(to[0], STDIN_FILENO);
+		close(to[0]);
+		close(to[1]);
+		execvp(((char **)arg->v)[0], (char **)arg->v);
+		fprintf(stderr, "st: execvp %s\n", ((char **)arg->v)[0]);
+		perror("failed");
+		exit(0);
+	}
+
+	close(to[0]);
+	/* ignore sigpipe for now, in case child exists early */
+	oldsigpipe = signal(SIGPIPE, SIG_IGN);
+	newline = 0;
+	for (n = 0; n < term.row; n++) {
+		bp = term.line[n];
+		lastpos = MIN(tlinelen(n) + 1, term.col) - 1;
+		if (lastpos < 0)
+			break;
+		end = [lastpos + 1];
+		for (; bp < end; ++bp)
+			if (xwrite(to[1], buf, utf8encode(bp->u, buf)) < 0)
+break;
+		if ((newline = term.line[n][lastpos].mode & ATTR_WRAP))
+			continue;
+		if (xwrite(to[1], "\n", 1) < 0)
+			break;
+		newline = 0;
+	}
+	if (newline)
+		(void)xwrite(to[1], "\n", 1);
+	close(to[1]);
+	/* restore */
+	signal(SIGPIPE, oldsigpipe);
+}
+
 void
 strdump(void)
 {
diff --git a/st.h b/st.h
index fd3b0d8..754cd08 100644
--- a/st.h
+++ b/st.h
@@ -81,6 +81,7 @@ void die(const char *, ...);
 void redraw(void);
 void draw(void);
 
+void externalpipe(const Arg *);
 void printscreen(const Arg *);
 void printsel(const Arg *);
 void sendbreak(const Arg *);
-- 
2.42.0

[dev] [st] externalpipe on OpenBSD

[Страхиња Радић]

Hello,

I recently installed OpenBSD for the first time and I noticed a few issues with 
externalpipe[1]. It seems this patch clashes with the parameters passed to 
pledge(2) in ttynew[2] (the program specified in openurlcmd doesn't get 
executed).

I also noticed that when I simply comment out the pledge, the program is 
executed, but nothing is passed to openurlcmd.

Since I am new to pledge, it will take some time for me to debug this, but I'm 
reporting this anyway in case there is someone more versed in the internals of 
OpenBSD who can take a look at this.


[1]: https://st.suckless.org/patches/externalpipe/
[2]: https://git.suckless.org/st/file/st.c.html#l799

Re: [dev] [st][patch] more work on the XEmbed embedder

[Страхиња Радић]

On 24/02/04 03:22PM, Robin Haberkorn wrote:
> Thirdly, I doubt that the maintainers would want to merge this into mainline.

The essence of the suckless philosophy goes hand in hand with the Unix 
philosophy - programs that do one thing well and cooperate with other programs. 
st is and should remain a terminal emulator, nothing more. There is already a 
program called "tabbed" to manage multiple programs into tabs. From the 
description, it seems that the functionality of your patch is different than 
tabbed in presentation - it uses overlapping windows instead of tabs, so it can 
be a separate program. However, its functionality does overlap with dwm. So 
perhaps a patch for dwm would be better? Even then, the main idea of dwm and 
other tiling window managers is that of the tilled (not overlapping) windows. 
So this would go against that idea.


> If you want to to try the patches in their current form, just build my version
> or cherry-pick the commits into your own st-patch-branch.
> Or does anybody insist I send them around in patch files?

That is how it usually works. Users submit patches, which are provided on

https://st.suckless.org/patches/

and (depending on context) might get merged into the upstream. This particular 
patch doesn't look like it should be in the upstream, but might be listed on 
the above URL. In any case, you should format it according to

https://suckless.org/hacking/


signature.asc
Description: PGP signature

Re: [dev] Presenting some more software

[Страхиња Радић]

On 24/01/15 09:58AM, Hiltjo Posthuma wrote:
> I would recommend doas and for Linux the fork opendoas.

Of course; there are several disadvantages to note about sup:

- it doesn't check credentials; it is like
permit nopass cmd1
permit nopass cmd2
permit nopass cmd3
  in doas; but having those in doas.conf is similar to using sup anyway

- the switch -l gives the list of supported commands "on a platter"

Still, I think that with a couple of tweaks it might be a replacement for doas?


signature.asc
Description: PGP signature

Re: [dev] Presenting some more software

[Страхиња Радић]

On 24/01/13 09:19PM, stefan1 wrote:
> https://github.com/stefan1/su
> https://github.com/stefan1/rootdo
> https://github.com/stefan1/rdoedit

I find sup[1] (~120-ish LoC) very useful, and in line with suckless philosophy.

[1]: https://oldgit.suckless.org/sup/


signature.asc
Description: PGP signature

Re: Re: [dev] what is a suckless way to add a few keyboard shortcuts to Firefox

[Страхиња Радић]

On 24/01/07 04:05PM, stefan1 wrote:
> However, I also have a question:
> Should I run noscript and ublock alongside umatrix in case something slips
> through the cracks in my umatrix configuration?

There's really no need to use any other ad blocker besides uMatrix. It is 
enough and better than other ad blockers.


> And how I set up umatrix to, for example, block third-party css by default?

Right click uMatrix button -> Options -> My rules. Syntax:

https://github.com/gorhill/uMatrix/wiki/Rules-syntax



signature.asc
Description: PGP signature

Re: [dev] what is a suckless way to add a few keyboard shortcuts to Firefox

[Страхиња Радић]

On 24/01/05 02:08PM, stefan1 wrote:
> Aside from ungoogled chromium, which browser would you say it's worth using?
> Preferably not chromium based and not tied to google/mozilla/ company>'s whims and shady interests.

That's the catch--The Web has grown too complicated over the years for someone 
to try and create an independent engine which would be capable of rendering it. 
And then the issue of maintenance would arise. Big Tech would very likely still 
want, and eventually probably succeed, to get a stranglehold on it, or diminish 
it in any way possible.

Currently, there are only a handful of "proper" engines, all controlled by 
Google/Mozilla/Apple/Microsoft. Aside from Apple's Webkit, which falls into 
this first category, and all the browsers using it, like surf, Badwolf, and a 
plethora of others, there are projects like:

- NetSurf, on life support for years now
- ELinks, lynx, w3m and other textual browsers, not actually usable for 
  most "modern Web"

I'm not a "fan" of Chromium nor Google. It just happens that **Ungoogled** 
Chromium **with uMatrix** at the moment is the least evil to handle the 
relatively necessary evil of current Web.

I was a Netscape user since 1996, and later a Firefox user, but like I said, 
today's Firefox is simply not the same piece of software that Netscape and 
first versions of Firefox were. Even for "normies", seemingly minor things like 
changes to the UI and removal of features and possibilities for customization 
are visible and a sign of not everything being quite as it should.




signature.asc
Description: PGP signature

Re: [dev] what is a suckless way to add a few keyboard shortcuts to Firefox

[Страхиња Радић]

On 24/01/05 04:14AM, stefan1 wrote:
> Maybe even remove my desktop all together at that point. :) 

Root window + st, with a terminal multiplexer is all that is needed. Desktop 
icons are just eye candy, and inefficient when moving a mouse to a specific 
place on the screen and double-clicking without moving the mouse is compared to 
much faster and accurate pressing a shortcut key spawning a dmenu_run, followed 
by typing a few distinctive characters and pressing Enter.


> Sadly, I still need to browse the web because there's a lot of useful 
> information out there on the web. Thankfully, noscript and ublock origin 
> filter 
> most of the bloat.
> 
>  There is librewolf which comes with privacy features by default.
> There is palemoon which is forked from old Firefox, and is both lightweight 
> and more privacy -focused than Firefox.
> 
> Chromium is far too bloated for me to seriously think of using it. It takes 
> more than twice as long as Firefox to compile and has extra dependencies and 
> is, well, chromium, maintained by Google.

About this, there is a (still kicking as of now) website offering a thorough 
analysis: DigDeeper, as well as some other websites.

- uBlock Origin vs uMatrix:
https://digdeeper.club/articles/addons.xhtml#adblockers

- NoScript vs uMatrix:
https://digdeeper.club/articles/addons.xhtml#noscript

- Librewolf telemetry:
https://sizeof.cat/post/web-browser-telemetry/#librewolf
  vs Ungoogled Chromium telemetry:
https://sizeof.cat/post/web-browser-telemetry/#ungoogled-chromium

- Palemoon:
https://digdeeper.club/articles/browsers.xhtml#palemoon

- Mozilla Inc has its own dedicated article:
https://digdeeper.club/articles/mozilla.xhtml


signature.asc
Description: PGP signature

Re: [dev] what is a suckless way to add a few keyboard shortcuts to Firefox

[Страхиња Радић]

> what is a suckless way to add a few keyboard shortcuts to Firefox

Edit its source code (unironically). Anyone who would laugh at this proposal 
doesn't actually understand or accept suckless philosophy.

* * *

BTW, Web sucks => any browser sucks. But besides that, Firefox is worse than
Google Chrome when it comes to privacy. Among the many examples of scummy 
mechanisms embedded into Firefox is its addon system: it now requires an 
account. Firefox is light years away (in a bad way) from its beginnings and 
Netscape.

Ungoogled Chromium is still the overall better solution as of now, but like I 
said, Web itself sucks.


signature.asc
Description: PGP signature

Re: [dev] [Bug][sbase] make install borked since commit ddde8021

[Страхиња Радић]

On 23/10/29 08:49PM, Markus Wichmann wrote:
> Am Sun, Oct 29, 2023 at 06:00:18PM +0100 schrieb Страхиња Радић:
> > mkdir returning EISDIR is definitely not a part of POSIX.[1]
> >
> > [1]: 
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html#tag_16_325_05
> 
> That's where you're wrong. Any function can fail for any reason unless
> POSIX specifically states "this function shall not fail with...". Only
> if the error conditions listed in the definition of the function apply,
> they have to return those error codes. Or as XSI chapter 2.3 puts it:
> 
> | Implementations may support additional errors not included in this list,
> | may generate errors included in this list under circumstances other than
> | those described here, or may contain extensions or limitations that
> | prevent some errors from occurring.

Ok, let me rephrase that:

mkdir returning EISDIR is definitely not prescribed by POSIX. The possibility 
of it being returned is not forbidden, but also not explicitly enumerated in
POSIX.


signature.asc
Description: PGP signature

Re: [dev] [Bug][sbase] make install borked since commit ddde8021

[Страхиња Радић]

On 23/10/29 07:59AM, Randy Palamar wrote:
> > Plus I didn't know mkdir could fail with EISDIR. My manpage is not
> > documenting that case.
> 
> It's probably legacy nonsense or from some obscure platform that I
> noticed when checking other implementations [0].

mkdir returning EISDIR is definitely not a part of POSIX.[1]

[1]: 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html#tag_16_325_05


signature.asc
Description: PGP signature

Re: [dev] [edit] Introducing edit, a simple text editor

[Страхиња Радић]

On 23/10/24 11:49AM, Kyryl Melekhin wrote:
> Besides, I want people to actually use my software and have some kind
> of visibility.
> 
> Nobody would know of suckless.org were it not be constantly posted and
> talked about
> on various social media(s).

This touches up one of the fundamental differences between suckless software 
and software that sucks: what drives the creation of software? Many mainstream 
software projects have fallen prey to the same disease that gripped show 
business and other creative fields: it is exclusively driven by publicity, 
catering to crowds and statistical analysis of target audiences, over 
everything else. This is something to take note of and avoid.

Programmers shouldn't be held hostage by the "opinion of the crowd" (a social
network defect). Programmers should be motivated only by the desire to create 
what is in their own opinion functional, quality software. Maybe it will be 
hidden in obscurity, so what? But it won't. If it is useful, those interested 
will find a way to discover it and use it.


signature.asc
Description: PGP signature

Re: [dev] [edit] Introducing edit, a simple text editor

[Страхиња Радић]

On 23/10/23 03:11PM, Kyryl Melekhin wrote:
> Since this is my creation I might be biased, but I still think that Nextvi is
> the best suckless editor.

That should be left for others to decide.


> Please give it a revisit, and help me get 100 stars on github!

Social networks should die. Github is one of them.[1]

Say no to Microsoft, Google, Amazon, Disney, Mozilla and other globalist 
"Big Tech" corporations.


[1]: https://sfconservancy.org/GiveUpGitHub/


signature.asc
Description: PGP signature

Re: [dev] libsecret implementation

[Страхиња Радић]

On 23/10/10 01:04PM, Страхиња Радић wrote:
> It all depends on the degree of your agency over the choice of software and 
> over the software itself. If it's a program you wrote, then consider 
> switching 
> away from D-Bus to interfacing with a simpler/better/more traditional 
> solution, 
> like pass or factotum[1]. If it's not, and you don't have a say in the 
> matter, 
> then there's obviously nothing you can do about it, no?
> [1]: https://9fans.github.io/plan9port/man/man4/factotum.html

That said, a simple web search (LMGTFY...) for "libsecret implementation" 
reveals one such implementation[1] among the first results. Whether it is 
"endorsed" by suckless movement is another matter. As a suckless _fan_, I'd say 
D-Bus is bloat in itself and should be avoided if possible, just like related 
bloatware such as systemd.

[1]: https://github.com/grawity/secretsd


signature.asc
Description: PGP signature

Re: [dev] libsecret implementation

[Страхиња Радић]

On 23/10/10 10:33AM, Marko Bauhardt wrote:
> Hi,
> i have to use a program at work which requires libsecret - Secret
> Service D-Bus client library.
> Right now I'm using the gnome keyring implementation.
> I would like to get rid of this implementation and use a more simpler
> one, in other words without gnome/kde deps.

It all depends on the degree of your agency over the choice of software and 
over the software itself. If it's a program you wrote, then consider switching 
away from D-Bus to interfacing with a simpler/better/more traditional solution, 
like pass or factotum[1]. If it's not, and you don't have a say in the matter, 
then there's obviously nothing you can do about it, no?


[1]: https://9fans.github.io/plan9port/man/man4/factotum.html


signature.asc
Description: PGP signature

Re: [dev] [edit] Introducing edit, a simple text editor

[Страхиња Радић]

On 23/09/28 09:02AM, David Demelier wrote:
> Not sure if that helps but I eventually stopped adding flags at all and
> use just the defaults everywhere. Otherwise I'd be glad to understand
> if there is a complete and strict conformance explanation on those
> combinations.

As Adam noted, the macros need to be defined before including the headers. More 
details can be found in feature_test_macros(7)[1] and libc documentation.


musl libc documentation[2] states (search for "Feature Test Macros Supported by 
musl")
> If no feature test macros are defined, musl's headers operate in
> "default features" mode, exposing the equivalent of the `_BSD_SOURCE`
> option below. This corresponds fairly well to what most applications
> unaware of feature test macros expect, and also provides a number of
> more modern features.
> 
> Otherwise, if at least one of the below-listed feature test macros is
> defined, they are treated additively, starting from pure ISO C as a
> base. Unless otherwise specified, musl ignores the value of the macro
> and only checks whether it is defined.


Likewise, glibc documentation[3] on feature test macros states:
> Be aware that compiler options also affect included features:
> 
> * If you use a strict conformance option, features beyond those from the 
>   compiler’s language version will be disabled, though feature test macros 
>   may be used to enable them.
> * Features enabled by compiler options are not overridden by feature test 
>   macros.


It is worth noting that most suckless programs don't define feature test macros 
inside of the source code. Instead, they are usually specified in config.mk as 
command line arguments passed to the compiler (thus guaranteed to not suffer 
from header inclusion before defining feature test macros). This also gives a 
clue on how to use termbox2.h properly.


Also: https://suckless.org/coding_style/
> C Features
> 
> * Use C99 without extensions (ISO/IEC 9899:1999).
> * Use POSIX.1-2008:
>   - When using gcc define _POSIX_C_SOURCE 200809L.
>   - Alternatively define _XOPEN_SOURCE 700.


[1]: https://linux.die.net/man/7/feature_test_macros
[2]: https://musl.libc.org/doc/1.1.24/manual.html
[3]: 
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fDEFAULT_005fSOURCE



signature.asc
Description: PGP signature

Re: [dev] [edit] Introducing edit, a simple text editor

[Страхиња Радић]

On closer inspection, termbox2.h does include signal.h itself[1], and 
additionally defines _XOPEN_SOURCE[2] and _DEFAULT_SOURCE, so the inclusion of 
signal.h can't be escaped.

My testing has shown that when -std=c99 is specified, it is as if that switch 
explicitly undefines _DEFAULT_SOURCE/_XOPEN_SOURCE **defined inside the header 
file** (this is the weird part). If -D_DEFAULT_SOURCE is given as an argument, 
or without -std=c99, when gcc is called directly rather than through the 
wrapper, c99, there are no warnings:

$ c99 -E edit.c | grep fileno
if (fstat(fileno(fp), ) != 0) {
$ gcc -E edit.c | grep fileno
int fileno(FILE *);
int fileno_unlocked(FILE *);
if (fstat(fileno(fp), ) != 0) {
$ c99 -D_DEFAULT_SOURCE -E edit.c | grep fileno
int fileno(FILE *);
int fileno_unlocked(FILE *);
if (fstat(fileno(fp), ) != 0) {
$

I use Alpine Linux, thus musl libc. Searching the web yielded the answer[3] on 
Stack Overflow, though:

> If you want this to cleanly compile with -std=c99, you must consider the 
> inclusion of the _DEFAULT_SOURCE feature test macro

I'm not sure about why you wouldn't want POSIX compliance though (To compile on 
Plan9? But it has APE[4]).


[1]: 
https://github.com/arthur-jacquin/edit/blob/41cd580d80459d1f13ef923c812cf6a858b240f0/termbox2.h#L40
[2]: 
https://github.com/arthur-jacquin/edit/blob/41cd580d80459d1f13ef923c812cf6a858b240f0/termbox2.h#L29
[3]: https://stackoverflow.com/a/10435860
[4]: https://9p.io/wiki/plan9/Porting_alien_software_to_Plan_9/index.html


signature.asc
Description: PGP signature

Re: [dev] [edit] Introducing edit, a simple text editor

[Страхиња Радић]

On 23/09/27 03:50PM, Arthur Jacquin wrote:
> termbox2.h is not C99 compliant, yet the -std=c99 compilation flag is
> set in the default configuration. On the compilers I tried, it has not
> been a problem as the non-C99 parts were ignored, but I shouldn't have
> assumed it would always be this way. Sorry for the annoyance.

Which parts of termbox2.h are not C99 compliant? What compiler doesn't "ignore" 
the non-C99 compliant code when -std=c99 is passed?

I maintain my own simple editor called sled[1], which uses termbox2.h and 
passes `-std=c99` as a default flag. I have compiled it using GCC, Clang/LLVM, 
tinycc, on (GNU/)Linux and OpenBSD, and I have yet to encounter any errors.

I tried compiling your program using `CC=c99` (script wrapper to GCC) and 
passing `-std=c99`, and there are only some warnings about implicitly declared 
functions, nothing about `struct sigaction`. In any case, you can simply 
include the needed headers prior to including termbox2.h (my program uses 
signal.h to redraw after C-Z, so I include it anyway).

[1]: https://strahinja.srht.site/sled/


signature.asc
Description: PGP signature

Re: [dev] Suckless web crawlers

[Страхиња Радић]

On 23/09/26 02:13PM, Sagar Acharya wrote:
> Which web crawlers and indexing tools does suckless suggest?

One can answer this and similar questions about particular niches of software 
by carefully reading and understanding what suckless is about:

https://suckless.org/philosophy/
(emphasis mine)
> We are the home of _quality software_ [...] with a _focus on simplicity, 
> clarity 
> and frugality_. Our philosophy is about _keeping things simple, minimal and 
> usable_. We believe this should become the mainstream philosophy in the IT 
> sector.


***


Immediately noticeable about xapian is that it is written in C++, which by 
itself is an overengineered language, far from being simple and frugal, which 
too often leads to overengineered software written in it.

Merely going by SLoC, just the latest xapian-core sub-project currently has 
around 92k lines of C++ source code. To get things into perspective, the latest 
shell mksh has around 29k lines of C code, and bash has around 118k lines of C 
code.


signature.asc
Description: PGP signature

Re: [dev] getting rid of cmake builds

[Страхиња Радић]

On 23/09/22 04:27PM, Страхиња Радић wrote:
> ...according to sloccount[1]...

[1]: https://dwheeler.com/sloccount/



signature.asc
Description: PGP signature

Re: [dev] getting rid of cmake builds

[Страхиња Радић]

On 23/09/22 07:27PM, NRK wrote:
> And this is no longer the 50s, we have enough memory to build a couple
> thousand line of code without *requiring* splitting things into multiple
> intermediate object files to avoid going OOM (even with bloated
> compilers like gcc/clang with optimization enabled).

It's not about memory, it's more about how easy it is for a human to navigate 
the source code. Of course, cscope and ctags exist, and reducing the number of 
lines of code is desired, but it is not always possible to reduce a program 
below 1k lines of code, so it needs splitting into several units.

For example (according to sloccount[1]), my patched dwm fork has ~3.3k lines of 
C code across 5 .c files, my patched st fork has ~4.9k lines of C code across 2 
.c files, and slstatus has ~2k lines of C code. My own programs are close to 
those numbers: some have up to ~5k lines of code combined only in .c files.


signature.asc
Description: PGP signature

Re: [dev] getting rid of cmake builds

[Страхиња Радић]

On 23/09/22 03:09PM, NRK wrote:
> Some tend to argue that this "doesn't scale", but as I said, this is for
> small projects. And the chances of your small project turning into the
> next linux kernel [2] with 30M LoC is probably not high. So don't create
> new *actual problems* by trying to solve an imaginary one.

The moment there is a new compilation unit, or several of them (but still way 
below "30M LoC" -- say, utils.c, screen.c and utf8.c), this quickly becomes 
tedious to type for every unit and a program. And then one puts those commands 
in ./build.sh. And then it occurs that one needs to adapt to a different 
compiler, different flags, different PREFIX and so on and ./build.sh gradually 
becomes less elegant than, say, a mkfile.


signature.asc
Description: PGP signature

Re: [dev] getting rid of cmake builds

[Страхиња Радић]

On 23/09/22 09:50AM, Sagar Acharya wrote:
> A better way to build is to write a build.dash script

Some elaboration is needed.

In what way would this shell script be better than the make systems I listed? 
How does it decide when rebuilding is needed? Does it track dependencies and 
how?


signature.asc
Description: PGP signature

Re: [dev] getting rid of cmake builds

[Страхиња Радић]

On 23/09/21 09:42AM, LM wrote:
> I build a lot of common libraries and programs from source.  Many of
> them are switching to cmake.  I'm not a fan of cmake.  For one thing,
> it's so complicated to build from source code that I can't bootstrap
> the build of cmake itself.  I really would prefer to build as many of

I agree. Anyone who tries to build a LFS system (or a derivation of it) will 
inevitably come across the beast that is cmake. When creating build scripts for 
"roll my own" static musl distro, Galeb[1], I came to several conclusions:

* cmake is a bloated mess (understatement), takes ages to build
* It being written in C++ is part of the reason for the above
* cmake can't properly figure out static library dependencies, in some 
  cases they still need to be configured manually

When it comes to the choice of a build system, I know of a number of options 
which are way better than cmake (in no particular order):

- djb redo
- POSIX make
- Plan9 mk

On topic, I'm afraid I haven't come across any automated converters, and as 
others have stated, it probably isn't even possible. I think it would be easier 
to write build scripts for packages using cmake in a simpler build system from 
scratch.


[1]: https://strahinja.srht.site/galeb/


signature.asc
Description: PGP signature

Re: [dev] C variants, compilers and completeness

[Страхиња Радић]

On 23/08/18 02:18, David Demelier wrote:
> On Mon, 2023-07-24 at 17:38 +0200, Sagar Acharya wrote:
> > I see C compilers recommended by suckless are:
> > 
> > tinycc
> > simplecc
> > cproc
> > qbe
> > lacc
> 
> qbe isn't a compiler. however cproc is promising but I had various
> issues compiling some apps, can't use it as my daily for now.

I haven't checked recently, but the most noticeable missing feature of cproc, 
as well as some other compilers, were VLAs. When someone writes the support for 
VLAs, cproc & co. will become much more usable.

The simpler compilers generally work for smaller projects, but for many 
existing packages, for now there is no real alternative to GCC and Clang/LLVM.


signature.asc
Description: PGP signature

Re: [dev] sbm dmenu bookmarker

[Страхиња Радић]

On 23/07/31 08:15AM, Randy Palamar wrote:
> `grep -v -e '#' -e '^$' $BOOKMARKS | dmenu -i -l 20 | cut -f 1 -d ' '`
> 
> Then I pipe it to the clipboard or a plumber script depending
> on what I want to do with it (bound to a keybind in dwm).
> 
> To add bookmarks I either use a text editor or just echo:
> 
> `echo "https://nsa.gov file sharing, hosting provider" >> $BOOKMARKS`

Since bookmarks are related to the Web, I usually keep them inside of my 
bloated web browser for the bloated Web (the very term [in the digital 
sense] originates from Netscape IIRC). They can be copied to the clipboard from 
there and pasted into st. Anything else I just type out. ¯\_(ツ)_/¯


signature.asc
Description: PGP signature

Re: [dev] Problem with windows name

[Страхиња Радић]

I managed to fix root window title being shown incorrectly by skipping 
conversion only for root window. I attached a patch with this message. Feel 
free to review it, I will make any necessary corrections.
From c5b399e138f6873e2eb9a292d55c5382e654f074 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 10 Jul 2023 09:25:30 +0200
Subject: [PATCH] dwm.c: Always convert title to UTF-8, except for root window
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Window names containing only ISO 8859-1 were broken on the location of
non-ASCII ISO 8859-1 character, for example áâãéíóôúç, because they were
treated as UTF-8. When commenting out the if-branch testing for XA_STRING, root
window title, usually set by status programs such as slstatus to UTF-8 text,
was not shown correctly, so this patch adds an exception for root window
instead, skipping conversion in that case.

Reported by Dr. André Desgualdo Pereira.

Signed-off-by: Страхиња Радић 
---
 dwm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/dwm.c b/dwm.c
index f1d86b2..c896325 100644
--- a/dwm.c
+++ b/dwm.c
@@ -917,7 +917,10 @@ gettextprop(Window w, Atom atom, char *text, unsigned int size)
 	text[0] = '\0';
 	if (!XGetTextProperty(dpy, w, , atom) || !name.nitems)
 		return 0;
-	if (name.encoding == XA_STRING) {
+	/*if (name.encoding == XA_STRING) {
+		strncpy(text, (char *)name.value, size - 1);
+	} else */
+	if (w == DefaultRootWindow(dpy)) {
 		strncpy(text, (char *)name.value, size - 1);
 	} else if (XmbTextPropertyToTextList(dpy, , , ) >= Success && n > 0 && *list) {
 		strncpy(text, *list, size - 1);
-- 
2.38.5



signature.asc
Description: PGP signature

Re: [dev] Problem with windows name

[Страхиња Радић]

Adding to gettextprop in dwm.c:

// ...
if (!XGetTextProperty(dpy, w, , atom) || !name.nitems)
return 0;
FILE* log = fopen("/home/user/dwm.log", "at");
fprintf(log, "---\n");
fprintf(log, "atom = {%lu}\n", atom);
fprintf(log, "text = {%s}\n", text);
fprintf(log, "value= {%s}\n", name.value);
fprintf(log, "encoding = {%lu}\n", name.encoding);
fprintf(log, "format   = {%d}\n", name.format);
fprintf(log, "nitems   = {%lu}\n", name.nitems);
fclose(log);
if (name.encoding == XA_STRING) {
// ...

I got: 

---
atom = {39}
text = {}
value= {thistest.odt - LibreOffice Writer}
encoding = {31}
format   = {8}
nitems   = {34}
---
atom = {39}
text = {}
value= {thistestL.odt - LibreOffice Writer}
encoding = {385}
format   = {8}
nitems   = {38}

So COMPOUND_TEXT sets the encoding field of XTextProperty to 385, a value not 
listed in Xatom.h, while STRING sets it to 31 (XA_STRING). The code:

if (name.encoding == XA_STRING) {
strncpy(text, (char *)name.value, size - 1);
} else if (XmbTextPropertyToTextList(dpy, , , ) >= Success 
&& n > 0 && *list) {
strncpy(text, *list, size - 1);
XFreeStringList(list);
}

converts any string not having XA_STRING as encoding with 
XmbTextPropertyToTextList[1].

The issue is that ISO 8859-1-encoded text, marked as XA_STRING, is copied with 
strncpy, and treated as UTF-8 later on in drw_text in drw.c. It probably should 
be converted to UTF-8 from the current locale, even when encoding field is set 
to XA_STRING. However, when I commented out the first branch like this:

/*if (name.encoding == XA_STRING) {
strncpy(text, (char *)name.value, size - 1);
} else*/ if (XmbTextPropertyToTextList(dpy, , , ) >= Success
&& n > 0 && *list) {
strncpy(text, *list, size - 1);
XFreeStringList(list);
}

The document title in LibreOffice was shown correctly. *However*, the output 
from slstatus, containing UTF-8 while having the encoding field also set to 
XA_STRING, was *not* shown correctly, even though the description of 
XmbTextPropertyToTextList states that

> The input text strings must be given in the current locale encoding (for 
> XmbTextListToTextProperty and XwcTextListToTextProperty), or in UTF-8 
> encoding 
> (for Xutf8TextListToTextProperty).

and my LANG is set to sr_RS.UTF-8 (so my "current locale encoding" should be 
UTF-8).

So, this would be a workaround, but one with further potential issues.


[1]: https://linux.die.net/man/3/xmbtextpropertytotextlist

Re: [dev] Problem with windows name

[Страхиња Радић]

I debugged dwm, adding to drw.c:

static void
log_msg(const char* fmt, ...)
{
char buf[4096];
va_list args;
va_start(args, fmt);
vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
fprintf(logfile, "%s\n", buf);
}

and calls to utf8decodebyte:

static long
utf8decodebyte(const char c, size_t *i)
{
   for (*i = 0; *i < (UTF_SIZ + 1); ++(*i))
   if (((unsigned char)c & utfmask[*i]) == utfbyte[*i])
   {
   log_msg("*i = %lu, for '%c' returning '%c'",
   *i, c, (unsigned char)c & ~utfmask[*i]);
   return (unsigned char)c & ~utfmask[*i];
   }
   return 0;
}

and drw_text:
utf8str = text;
nextfont = NULL;
while (*text) {
   log_msg("*text == '0x%X' == '%c'",
   *text, *text);
   utf8charlen = utf8decode(text, , 
UTF_SIZ);
   for (curfont = drw->fonts; curfont; curfont = 
curfont->next) {
   charexists = charexists || 
XftCharExists(drw->dpy, curfont->xfont, utf8codepoint);

I got the following output from "thisátest.odt"

// á
*text == '0xFFE1' == ''
*i = 3, for '' returning '^A'
*i = 1, for 't' returning 't'
*text == '0x74' == 't'
*i = 1, for 't' returning 't'

and the following from "thisátestњ.odt":

// á
*text == '0xFFC3' == ''
*i = 2, for '' returning '^C'
*i = 0, for '' returning '!'
[...]
// њ
*text == '0xFFD1' == ''
*i = 2, for '' returning '^Q'
*i = 0, for '<9A>' returning '^Z'

From here, it seems that dwm is receiving correct UTF-8 representations of "á"
(0xC3 0xA1) and "њ" (0xD1 0x9A) for "thisátestњ.odt", but it receives
ISO 8859-1 representation of "á" (no wonder, given it is passed a STRING 
instead 
of UTF8_STRING or COMPOUND_TEXT), 0xE1, followed by the next ASCII character, 
0x74 ("t"), still interpreting the two as UTF-8 sequence, when those two bytes 
form an invalid UTF-8. That invalid UTF-8 is further passed to libfreetype or 
whatever, which just interrupts output at that point.


signature.asc
Description: PGP signature

Re: [dev] Problem with windows name

[Страхиња Радић]

On 23/07/09 08:43AM, Dr. André Desgualdo Pereira wrote:
> # xprop
> xprop shows the correct name, but it doesn't has the _NET_WM_NAME defined as 
> it used to have on Debian 11 and before (I guess it is because missing 
> library 
> tkinter for python2.7).
> Example: WM_NAME(STRING) = "André Desgualdo.odt - OpenOffice Writer"

I have made two files, one with á and ASCII characters and another with added 
њ. The results from xprop are:

WM_NAME(STRING) = "thisátest.odt - LibreOffice Writer"
^^
WM_NAME(COMPOUND_TEXT) = "thisátestњ.odt - LibreOffice Writer"
^

This implies that this is a X.Org issue. Strings having only ISO 8859-1 
characters are silently degraded to STRINGs when they should really be 
COMPOUND_TEXT.


signature.asc
Description: PGP signature

Re: [dev] Minimalist software. Should I care?

[Страхиња Радић]

On 23/07/04 07:06PM, Nikita Krasnov wrote:
> If I had used one of the bloated programs I probably could have found a
> solution in one of the menus after reading few Stack Overflow answers. But
> with Neovim I'd have to first find the program that would be suitable for
> what I try to achieve, then I'd have to read many lines or pages of
> documentation, after that I'd have to implement that thing and only then I'd
> be able to use the thing.

Neovim is bloat. But for both Neovim and vi/Vi IMproved, just go through the 
tutorial and learn basic keys and ideas behind using it. (BTW, addons are 
unnecessary, Vim is a fully functional text editor, and then some.) If that's 
too hard for you, then that's your reason, the "why (not)?". Just carry on 
using whatever else without regrets. But if you want to be a "cool kid", you 
should know that that's bought with self-determination and a strength of will 
to read, tinker and explore.

BTW, the rationale and core ideas behind the suckless movement are explained on
the website, go read it:

https://suckless.org/philosophy/



signature.asc
Description: PGP signature

Re: [dev] Minimalist software. Should I care?

[Страхиња Радић]

On 23/07/04 07:06PM, Nikita Krasnov wrote:
> What would be the point of using minimalist software if bloated and
> excessively complex programs completely satisfy all my needs?

Doing all that but with much less resources (in the broadest sense) wasted.


On 23/07/04 01:16PM, Dave Blanchard wrote:
> I tried ST for a time before realizing it was trash and just switched back to
> Xterm, the gold standard of functional X11 terminal emulators,

Troll.


> noticeably faster as well when ST is patched with the juvenile "scrollback 
> buffer support" implementation

I use tmux.

Scrollback patch is literally the last recommended solution to scrollback in st 
FAQ:

> ## How do I scroll back up?
>
> * Using a terminal multiplexer.
>* `st -e tmux` using C-b [
>* `st -e screen` using C-a ESC
> * Using the excellent tool of [scroll](https://git.suckless.org/scroll/).
> * Using the scrollback [patch](https://st.suckless.org/patches/scrollback/).



signature.asc
Description: PGP signature

Re: [dev] Am I doing this right?

[Страхиња Радић]

On 23/07/02 06:39PM, Sebastian LaVine wrote:
> On Sun Jul 2, 2023 at 6:28 PM EDT, Nikita Krasnov wrote:
> > While we're on it. Are there any good Android email clients 
> > that you can recommend? I've yet to find an app that allows 
> > you to send emails in plain text, let alone with line 
> > hard-wrapping :(
> 
> I use and can recommend .

Since K9-Mail announced[1] that it will be "integrated" into Mozilla 
Thunderbird on Android, I use FairEmail[2] instead. Both "apps" are a bloated 
mess, but at least FairEmail doesn't depend on privacy-intruding Mozilla[3].

BTW, I suggest avoiding Android in the first place, for multiple reasons.

I have compiled a list of programs I use and recommend on my website[4] (page 
is in Serbian, but you can Google translate it to somewhat acceptable level).


[1]: https://k9mail.app/2022/06/13/K-9-Mail-and-Thunderbird
[2]: https://email.faircode.eu/
[3]: https://digdeeper.club/articles/mozilla.xhtml
[4]: https://strahinja.org/tekstovi/softver/preporuke


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

[Страхиња Радић]

On 23/06/18 09:01, Страхиња Радић wrote:
> You can't license the whole of A as GPL, only your modifications.
[...]
> which explicitely forbids removing the copyright and permission notices on
> Expat-licensed code, or replacing them with, say, GPL notices.

On second thought, I think Markus may be right. It is GPL which would forbid 
non-compatible sublicensing (which is changing the license of derived works 
*completely*), not Expat. Under Expat, you can sublicense *your copy/fork* to 
any license, including the proprietary licenses. (This is one of the reasons 
why I think that GNU GPL is superior--it stays true to the original intent.)

Of course, the copyright holder(s), or original authors, can always choose to 
retain the original license on their software, or relicense their work in any 
way they choose (IMHO this wouldn't retroactively impact the forks made when 
the program's license allowed free-software-licensed forks).



signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

[Страхиња Радић]

On 23/06/20 08:41, Miles Rout wrote:
> It requires the notice is included (so people know that that code is 
> available elsewhere under that licence), not that the notice is included _as 
> your licence for the overall work_.

As someone else said, "words do matter". Copyright notice is not "just words", 
it is important and carries legal weight. Expat license requires that the 
copyright and permission notices are left intact in (and thus apply to) "all 
copies" or "substantial portions" of the software. In this, it is not entirely
"permissive".

It is implied that the software which is mentioned here is the original code as 
published by the original author. If someone makes additional code which 
complements that program but is otherwise newly introduced to the program, he 
can (sub)license (according to terms of Expat license) the additional code 
under a different license, provided it is compatible with Expat. GNU GPL is 
such a compatible license.[1]


> Works as wholes are licensed under 
> copyright licences, not parts of works.

False. Parts of works can be licensed under different licenses and combined 
into a single unit, provided the two licenses are compatible. See [1].

The same program can even be multi-licensed by the copyright holder (original 
author).[2]


> I don't think relicensing is particularly relevant: the question is whether 
> your work, i.e. the whole program you have published, which includes both 
> code you wrote and you did not write, is able to be licensed under the GPL. 
> That is about licence compatibility.

Let us recall the original message:

> I'm curious about licensing and was wondering why suckless tools are released 
> under MIT rather than an alternative like GPL. Is it just to make it 
> compatible 
> with more other software?

So yeah, the topic is about potential relicensing of suckless software under 
GNU GPL.

Still, as far as compatibility goes, the question is already answered multiple 
times here: Expat license is compatible with the GNU GPL.[3]


[1]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
[2]: https://www.gnu.org/licenses/gpl-faq.html#HeardOtherLicense
[3]: https://www.gnu.org/licenses/license-list.html#Expat


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

[Страхиња Радић]

On 23/06/18 04:58PM, Miles Rout wrote:
> As far as I understand, if you create a work (A) that is a fork of another 
> work (B), where B is MIT-licensed, nothing stops you from licensing A as GPL. 
> I 
> wouldn't call it "relicensing": you're licensing your own work, A, which 
> happens to be derived from B. You aren't licensing B, which is someone else's 
> work. You do need to credit B's copyright holders of course. 
> 
> Have I got something wrong here? I am no copyright lawyer, that is for sure, 
> so I cannot claim any expertise. Or did you mean something different?

You can't license the whole of A as GPL, only your modifications. Expat license 
requires that:

> The above copyright notice and this permission notice shall be included in all
> copies or substantial portions of the Software.

which explicitely forbids removing the copyright and permission notices on 
Expat-licensed code, or replacing them with, say, GPL notices.

Like I said, Expat license is GPL-compatible[1]. That means[2]:
> It means that the other license and the GNU GPL are compatible; you can 
> combine 
> code released under the other license with code released under the GNU GPL in 
> one larger program.
>
> All GNU GPL versions permit such combinations privately; they also permit 
> distribution of such combinations provided the combination is released under 
> the same GNU GPL version. The other license is compatible with the GPL if it 
> permits this too.
>
> GPLv3 is compatible with more licenses than GPLv2: it allows you to make 
> combinations with code that has specific kinds of additional requirements 
> that 
> are not in GPLv3 itself. Section 7 has more information about this, including 
> the list of additional requirements that are permitted.

However, it *doesn't* mean that I can just take someone's program A licensed 
under Expat and relicense the parts of my fork B (realistically, perhaps 95% of 
program A) under GPL. More precisely, that is not legally possible, as I stated 
before.


[1]: https://www.gnu.org/licenses/license-list.html#Expat
[2]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean


signature.asc
Description: PGP signature

Re: [dev] [quark] a monty-pythonesque journey with SYSTEMd

[Страхиња Радић]

On 23/05/29 11:37PM, Spenser Truex wrote:
> systemd

Just don't use it, it sucks. Use anything else for PID 1 and process 
supervision.

https://suckless.org/sucks/systemd/


signature.asc
Description: PGP signature

Re: [dev] running a shortlink provider

[Страхиња Радић]

On 23/05/25 07:19PM, Spenser Truex wrote:
> I don't support this database heavy database stuff. A key-value pair
> dataset would be enough. It's basically a perl one-liner. 

See (just a quick example): https://stackoverflow.com/a/43050919/184064

This is still not an ideal solution, but it illustrates some of issues which 
can arise. Having a website in PHP around 2001 has taught me that writing to a 
file in a HTTP environment filled with crawlers, bots, people holding F5 and 
slow clients, is vastly different than writing to a file on a single-user 
system.


> If you have a markup language for your database it's bloat.

I mentioned a database system, not a markup language.


> Why use a hammer when you can beat the nail with your hand?

Indeed, one just doesn't do the latter.



signature.asc
Description: PGP signature

Re: [dev] running a shortlink provider

[Страхиња Радић]

On 23/05/25 10:29AM, Anthony wrote:
> What do you mean by, "because of concurrency"?

At any given moment, several HTTP clients can request posting data at the same 
time. They can hang indefinitely in the middle of sending data. If the process 
involves writing to a file, this can lead to data corruption or data loss. Even 
with a file lock, other such requests can be delayed or even denied. That's why 
a more sophisticated approach, possibly with caching, transactions and other 
methods which are present in database systems, is needed.


signature.asc
Description: PGP signature

Re: [dev] running a shortlink provider

[Страхиња Радић]

On 23/05/25 07:02AM, Marcel Plch wrote:
> 2) Pick favorite Web stack
[...]
> I personally would go for Python/Django, I'm not sure how suckless that's
> considered (probably not at all)
[...]
> Web is in a sad state so

You answered your own question. Web is bloat, in particular HTML itself as 
something derived from SGML.

Suckless way to have a URL shortener public service would probably be to create 
a CGI script in rc/shell or a program in C.

Perhaps the most minimal solution for keeping data would be TSV files, but they 
are not suitable for storing data entered from the web because of concurrency, 
so a "real" database would be needed.



signature.asc
Description: PGP signature

Re: [dev] organizing programs

[Страхиња Радић]

On 23/05/12 02:11PM, LM wrote:
> I'd be curious to know what tools other people use on the list to
> handle organizational jobs such as time and task scheduling, todo
> lists, habit tracking, displaying/printing calendars, etc.  Any
> recommendations?  If you use more than one application, which programs
> work together or chain well?  Thanks.

http://codemadness.org/todo-application.html


signature.asc
Description: PGP signature

Re: [dev] Simpler WiFi alternatives

[Страхиња Радић]

On 23/05/11 04:03PM, fo...@dnmx.org wrote:


This list needs moderation ASAP, otherwise it risks turning into another 
Reddit (which, for those who might not know, is a veritable cesspool).


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

[Страхиња Радић]

On 23/05/06 09:55PM, Laslo Hunhold wrote:
> [0]:https://unixsheikh.com/articles/the-problems-with-the-gpl.html

Dear Laslo,

Thank you for reminding me of Unixsheikh's article on his view of GPL and other 
licenses. I read it a while ago, but the arguments presented in it leave me 
unconvinced. I don't think the two matters, of picking a license and ensuring 
that programs remain simple and to the point in the technical sense, are or 
have to be connected. I simply linked some of the articles on gnu.org which I 
think are relevant and complement the articles linked before my reply by 
presenting the views of the "other side", which are behind GPL-related 
licenses.

As I stated before, I don't see the practical point of this "debate" with 
regards to (most of) existing suckless software - the Expat ("MIT") license 
can't (_legally_; of course _realistically_ anything goes, even "software 
'piracy'" is a reality but illegal) be changed, even if it is "permissive". It 
is GPL-compatible, Expat-licensed works can be combined with GPL-licensed 
works. So what's the point in that case?

The only viable "debate" could be about what license to pick for future 
programs written from scratch, but that wasn't what OP asked.

Sincerely,
Strahinya


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

[Страхиња Радић]

On 23/05/05 08:07AM, Laslo Hunhold wrote:
> I try to take a balanced stance in the GPL vs. MIT discussion, given it
> usually derails into tribalist diatribes on both sides.

Essays have been written and are available online explaining everything about 
GPL and related licenses, so there's no need for anyone to reiterate what is 
already there (examples: [1], [2], [3], [4] and so on). Anyone interested can 
read them and form their own opinion. Personally, I believe that GNU GPLv3+ is 
superior and use it for programs I write from scratch. But that is pointless to 
bring up here, because the reality is that the programmers who made suckless 
software mostly picked Expat License (and are calling it "the MIT License"). It 
is irrelevant for non-GPL programs I fork or contribute to, because once the 
license is picked, software it applies to can't be relicensed.

Here we come to my main point: that this is a troll topic, promoting division 
and pushing the main suckless principles to the background. Consequently, I 
already wrote too much here.


[1]: https://www.gnu.org/licenses/license-list.html
[2]: https://www.gnu.org/philosophy/philosophy.html
[3]: https://www.gnu.org/licenses/why-not-lgpl.html
[4]: https://www.gnu.org/licenses/rms-why-gplv3.html


signature.asc
Description: PGP signature

Re: [dev] Using ii to connect to libera

[Страхиња Радић]

On 23/04/20 06:00, Sagar Acharya wrote:
> I expected it to be interactive out of the box. A chat client, I cannot 
> imagine anything except interactive abilities.

Consider this a learning opportunity then: it is better to read documentation 
and/or a website[1] of some program, than create assumptions which might not be 
based in reality.

From the website[1]:

> ii is a minimalist FIFO and filesystem-based IRC client.
[...]
> Join a channel as follows: $ echo "/j #wmii" > in and ii creates a new #wmii  
> (channel) directory with in and out files.

And so on...

[1]: https://tools.suckless.org/ii/


signature.asc
Description: PGP signature

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[Страхиња Радић]

On 23/04/08 07:24PM, p...@mailbox.org wrote:
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };

How about:

> > (Try changing your
> > dmenu_extended keybind to something else and see if that works or not).

1. What happens if you use:

static const char *dmenu_extend[] = { "dmenu_run", NULL };

2. What happens when you run from the terminal emulator:

2.a:
$ dmenu_extended_run

2.b:
$ which dmenu_extended_run

3. What happens if you add the path obtained from 2.b to the command

> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
 ^-- here, before 'd'?



signature.asc
Description: PGP signature

Re: [dev] [DEV][Quark] Big problem

[Страхиња Радић]

On 23/02/25 12:59PM, fo...@dnmx.org wrote:
> Tried -s 128 -t 8, doesn't seem to do jack shit..
> Got less than 10 connection logs from Quark and then another dropped one..
> Is there any other reason Quark would print-out 'dropped', other than
> connection pool at max?
> 
> I restarted the jail, so Quark's memory and stuff should have been reset.

Reread Laslo's message and look at the source code as he suggested in the 
mentioned message.


signature.asc
Description: PGP signature

Re: [dev] [st] Font problem

[Страхиња Радић]

On 23/02/10 03:19PM, Vincent Lefevre wrote:
> Actually that's more Cairo vs Xft. Pango may use either:

Right. In any case, the most likely place the OP should check is fontconfig 
configuration and fc-* programs for debugging (fc-match, fc-list and so on).


signature.asc
Description: PGP signature

Re: [dev] st: no need for scrollback patch or program by using -o option

[Страхиња Радић]

On 23/01/16 12:33, Страхиња Радић wrote:
> Most of what's to be said in "defense" of st and other suckless software is 
> already out there on suckless.org, including the sorry state of XTerm being 
> the 
> driving idea behind writing st, which the OP turned upside-down, so that's 
> one 
> more reason against responding, and enough to see it's trolling.

s/OP/person Markus responded to/


signature.asc
Description: PGP signature

Re: [dev] st: no need for scrollback patch or program by using -o option

[Страхиња Радић]

On 23/01/14 09:25, Markus Wichmann wrote:
> On Fri, Jan 13, 2023 at 07:53:41PM -0600, Dave Blanchard wrote:
> > I experimented with st for a week or so, before finally realizing that
> > it's poorly-written trash. It has no advantages over XTerm at all.
> >
> 
> So where's the patch?
> 
> Given that a terminal emulator is a necessary part of the Trusted
> Computing Base if the system has X11, I'd prefer it to be as simple as
> possible, so that it is not exploitable. st is simple enough to be able
> to roughly gauge whether it has memory bugs or not. XTerm is such
> overwritten tripe I cannot gauge that at all.
> 
> Ciao,
> Markus

Obvious trolling should receive no response. This kind of noise belongs to 
Reddit and similar communities, where it is commonplace.

Most of what's to be said in "defense" of st and other suckless software is 
already out there on suckless.org, including the sorry state of XTerm being the 
driving idea behind writing st, which the OP turned upside-down, so that's one 
more reason against responding, and enough to see it's trolling.


signature.asc
Description: PGP signature

Re: [dev] Commandline Email Advice Request

[Страхиња Радић]

On 22/11/25 09:43, Teodoro Santoni wrote:
> Gmail doesn't allow to use SMTP in a classic way (normal auth
> with/without encryption). You may need to ask your sysadmins for
> XOAUTH2 keys and try to pass that git send-email through an SMTP thing
> like msmtp.
> A faster solution would be to make the patches with git format-patch
> and then send a manually created email with the patches attached.

I use Google's "App password" to authenticate, with "Allow insecure login" 
setting in Gmail to use msmtp with it.


signature.asc
Description: PGP signature

[dev] Broken link in /faq/

[Страхиња Радић]

The first link in

https://suckless.org/faq/

http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system

seems to be broken. Just wanted to ask if it is ok for me to replace it with

https://web.archive.org/web/20181118080003/http://freshmeat.sourceforge.net/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system

Cheers,
Strahinya


signature.asc
Description: PGP signature

Re: [dev] tar filename handling

[Страхиња Радић]

On 22/08/01 09:30, Quentin Rameau wrote:
> Andrew has posted a patch (on hackers@ on may first) for this
> that nobody had time to review yet. :/
> I suggest you try it, that should fix your issue.

Ah, I'm not subscribed on that list (yet?). Anyway, I tested my patch on my use 
case and it behaves correctly so far, so I leave you guys to decide whether to 
review/include it or not.

In the meantime, I have posted another patch, which adds a -n option 
(equivalent of --no-recursion) for your consideration.


signature.asc
Description: PGP signature

[dev] tar -n (equivalent of --no-recursion)

[Страхиња Радић]

I have made another patch for tar, this is more "quality of life" oriented. It 
adds the option -n to tar, which is equivalent to GNU tar's --no-recursion. 
This comes in handy when tar is used together with find(1) to filter and 
hand-pick the list of files to be archived.

The patch is here:

https://git.sr.ht/~strahinja/sbase/tree/master/item/patches/0001-Add-n-equivalent-of-no-recursion.patch

and I have also attached it to this message for review.
From 3c58d0ce54200f001309da369a54cb58a4e7ddf7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 1 Aug 2022 09:21:08 +0200
Subject: [PATCH] Add -n (equivalent of --no-recursion)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Страхиња Радић 
---
 tar.1 |  5 +
 tar.c | 16 
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/tar.1 b/tar.1
index be2ebea..f7d27a0 100644
--- a/tar.1
+++ b/tar.1
@@ -15,6 +15,7 @@
 .Op Fl C Ar dir
 .Op Fl J | Fl Z | Fl a | Fl j | Fl z
 .Op Fl h
+.Op Fl n
 .Fl c Ar path ...
 .Op Fl f Ar file
 .Sh DESCRIPTION
@@ -36,6 +37,10 @@ as input | output archive instead of stdin | stdout.
 If '-', stdin | stdout is used.
 .It Fl m
 Do not preserve modification time.
+.It Fl n
+Do not recurse into directories. This flag is an extension to standard,
+equivalent to GNU tar's
+.Fl -no-recursion .
 .It Fl t
 List all files in the archive.
 .It Fl x
diff --git a/tar.c b/tar.c
index d3a9f3b..3f8daf9 100644
--- a/tar.c
+++ b/tar.c
@@ -63,7 +63,7 @@ static int tarfd;
 static ino_t tarinode;
 static dev_t tardev;
 
-static int mflag, vflag;
+static int mflag, nflag, vflag;
 static int filtermode;
 static const char *filtertool;
 
@@ -374,7 +374,7 @@ c(int dirfd, const char *name, struct stat *st, void *data, struct recursor *r)
 	if (vflag)
 		puts(r->path);
 
-	if (S_ISDIR(st->st_mode))
+	if (S_ISDIR(st->st_mode) && !nflag)
 		recurse(dirfd, name, NULL, r);
 }
 
@@ -507,7 +507,7 @@ usage(void)
 {
 	eprintf("usage: %s [-C dir] [-J | -Z | -a | -j | -z] -x [-m | -t] "
 	"[-f file] [file ...]\n"
-	"   %s [-C dir] [-J | -Z | -a | -j | -z] [-h] -c path ... "
+	"   %s [-C dir] [-J | -Z | -a | -j | -z] [-h] [-n] -c path ... "
 	"[-f file]\n", argv0, argv0);
 }
 
@@ -534,6 +534,9 @@ main(int argc, char *argv[])
 	case 'm':
 		mflag = 1;
 		break;
+	case 'n':
+		nflag = 1;
+		break;
 	case 'J':
 	case 'Z':
 	case 'a':
@@ -577,7 +580,12 @@ main(int argc, char *argv[])
 		if (chdir(dir) < 0)
 			eprintf("chdir %s:", dir);
 		for (; *argv; argc--, argv++)
-			recurse(AT_FDCWD, *argv, NULL, );
+		{
+			if (!nflag)
+recurse(AT_FDCWD, *argv, NULL, );
+			else
+archive(*argv);
+		}
 		break;
 	case 't':
 	case 'x':
-- 
2.37.1



signature.asc
Description: PGP signature

Re: [dev] tar filename handling

[Страхиња Радић]

I have made the necessary change, you can review my patch here:

https://git.sr.ht/~strahinja/sbase/tree/master/item/patches/0001-Split-path-into-prefix-name-on-c.patch

I also attached it to this message.
From d91f1b0315ca3a0d584f8ac7c2e8ef16cc7493c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 1 Aug 2022 09:12:03 +0200
Subject: [PATCH] Split path into prefix + name on -c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Страхиња Радић 
---
 tar.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tar.c b/tar.c
index d3a9f3b..4c35102 100644
--- a/tar.c
+++ b/tar.c
@@ -180,6 +180,7 @@ static int
 archive(const char *path)
 {
 	char b[BLKSIZ];
+	char *split;
 	struct group *gr;
 	struct header *h;
 	struct passwd *pw;
@@ -187,6 +188,7 @@ archive(const char *path)
 	size_t chksum, i;
 	ssize_t l, r;
 	int fd = -1;
+	int slen, plen;
 
 	if (lstat(path, ) < 0) {
 		weprintf("lstat %s:", path);
@@ -201,7 +203,19 @@ archive(const char *path)
 
 	h = (struct header *)b;
 	memset(b, 0, sizeof(b));
-	estrlcpy(h->name,path,sizeof(h->name));
+	if ((split = strrchr(path, '/')) > path)
+	{
+		plen = strlen(path);
+		slen = (int)(split - path);
+		if (snprintf(h->prefix, sizeof(h->prefix), "%.*s",
+			slen, path) >= sizeof(h->prefix))
+			eprintf("snprintf: input string too long\n");
+		if (snprintf(h->name, sizeof(h->name), "%.*s",
+			(int)(plen-slen-1), path+slen+1) >= sizeof(h->name))
+			eprintf("snprintf: input string too long\n");
+	}
+	else
+		estrlcpy(h->name, path,   sizeof(h->name));
 	putoctal(h->mode,(unsigned)st.st_mode & 0777, sizeof(h->mode));
 	putoctal(h->uid, (unsigned)st.st_uid, sizeof(h->uid));
 	putoctal(h->gid, (unsigned)st.st_gid, sizeof(h->gid));
-- 
2.37.1



signature.asc
Description: PGP signature

[dev] tar filename handling

[Страхиња Радић]

I was using suckless tar to create an archive of a Python package, and hit a 
limit. When checking out the code, I noticed that the name of the file is 100 
characters long, however there is also the prefix field which is 155 characters 
long, and the actual path should be combined from prefix (if present) + name.

https://git.suckless.org/sbase/file/tar.c.html#l36

The path that failed was

./sucks/lib/python3.9/site-packages/docutils/parsers/__pycache__/commonmark_wrapper.cpython-39.opt-1.pyc

which is 104 characters long. On further inspection, it seems that the prefix 
field is taken into account with -x and -t ("small dance..."):

https://git.suckless.org/sbase/file/tar.c.html#l460

but not with -c:

https://git.suckless.org/sbase/file/tar.c.html#l204

I just wanted to know if this is planned for a future update. If not, I'd like 
to try to implement long (>100) path splitting for -c.


signature.asc
Description: PGP signature

Re: [dev] Replace ranlib(1) calls?

[Страхиња Радић]

On 22/07/23 11:06, Tom Schwindl wrote:
> Again, you'd have to rely on a tool which isn't defined.
> If a system says it's POSIX compliant, we can assume that the `-s' option
> exists, but there is no standard which tells us whether ranlib(1) is available
> or not.

Standards are not the Holy Grail.

https://harmful.cat-v.org/standards/ 


signature.asc
Description: PGP signature

Re: [dev] suckless indentation with vim

[Страхиња Радић]

On 22/07/02 11:07, NRK wrote:
> If someone's using vim and follows this style, what plugin and/or
> setting do you use?

set tabstop=8
set softtabstop=0
set shiftwidth=0
set noexpandtab

Not being lazy to type text, and indenting each line manually.

Side note: vim is bloated compared to vi and vis.


signature.asc
Description: PGP signature

Re: [dev] [dwm] Xorg crashed if I ran Pale Moon in dwm

[Страхиња Радић]

On 22/06/22 01:04, p...@mailbox.org wrote:
> > the discussion https://forum.palemoon.org/viewtopic.php?f=3=28505

[   140.237] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported. 
Supported versions are: 1.10, 1.20, and 1.00 ES

^ This is most probably caused by mismatched/misconfigured video drivers and/or
misconfigured X.Org (try asking on the forums of your distro instead).

dwm is very simple and doesn't use fancy GL APIs, unlike bloated web browsers
like Palemoon, so this has nothing to do with it.


signature.asc
Description: PGP signature

Re: [dev][surf] Compatibility: "empty" wep pages

[Страхиња Радић]

On 22/04/29 09:48, Robert Winkler wrote:
> Hi, surf is up to now the best browser I found for weak machines such as the 
> Raspberry Pi 0W, with respect to compatibility and customisability (link
> hints, full keyboard control).
> 
> The support of Javascript pages is fair.
> 
> However, some Web Pages do not work at all.
> 
> Example: 
> just produces a white page.

This is how that page (containing Google Analytics and Google Tag Manager) 
looks in surf here:

https://i.imgur.com/lgKot4U.png

While Web itself sucks[1], and surf is a compromise between a suckless shell 
and an engine that sucks (Webkit) for a medium that sucks (HTML+CSS+JS), I find 
that it is unfortunately not satisfactory yet from a privacy-respecting 
standpoint, at least until it supports plugins such as uMatrix which block Ads 
and various other privacy-intruding technologies. Simple filtering of URLs 
just isn't enough.

Until such a moment, I'm using ungoogled-chromium[2] for everyday use.

[1]: https://suckless.org/sucks/web/
[2]: https://github.com/Eloston/ungoogled-chromium


signature.asc
Description: PGP signature

Re: [dev] [st] UTF-8 not working

[Страхиња Радић]

On 22/04/28 01:44, Robert Winkler wrote:
> 
> usually, I am using the fish 

https://www.youtube.com/watch?v=8AQobpqySAU


signature.asc
Description: PGP signature

Re: [dev] [st] UTF-8 not working

[Страхиња Радић]

On 22/04/28 06:48, Страхиња Радић wrote:
> May I ask what shell are you using inside st? The only problem I noticed so 
> far 
> with my script, which uses xdotool(1) to type characters, is when I am using 
> it 
> while st is specifically executing mksh as a shell. With bash, dash and zsh 
> emoji are inserted correctly. This is undoubtedly some misconfiguration of 
> mksh 
> on my part, which I have yet to figure out in detail.

After some investigation, I discovered the following paragraph in mksh FAQ[1]:

> The shell’s utf8-mode before mksh R60 supported only the BMP (Basic 
> Multilingual Plane) of UCS and mapped raw (extended ASCII) octets, i.e. these 
> which are not valid UTF-8 BMP codepoints) into the U+EF80‥U+EFFF range, which 
> is allocated at the CSUR for this purpose. (It otherwise lies in the PUA; 
> however, there is ambiguity if encountering those UTF-8-encoded, so it 
> changed 
> for R60.) The Arithmetic expressions and CAVEATS sections in mksh(1) contain 
> more details about encoding and mapping.
>
> As of R60, utf8-mode maps “raw octets” to U-1080‥U-10FF, which is 
> outside the UCS and therefore collision-free. There’s work underway to make 
> the 
> shell support the full 21-bit UCS range for R60.

Since I'm currently using mksh R59, that part of the mystery is solved as well.

**Definitive conclusion: st does not need GNOME, ibus or other bloat (aside 
from 
good old native X.Org bloat itself) to support UTF-8 input/output.**


[1]: http://www.mirbsd.org/mksh-faq.htm#posix-mode


signature.asc
Description: PGP signature

Re: [dev] [st] UTF-8 not working

[Страхиња Радић]

On 22/04/15 07:08, Robert Winkler wrote:
> Hi, according to the st Status, UTF-8 should be working. Much needed for
> multilingual typing with ú, ü, ß, µ, ¿ etc.
> However, I only get 00e9 if I type é; anything, I need to specify in
> config.h?
> Best, Robert

Liks I said, I only use:

- login through getty (no display manager like lightdm, sddm, gdm...)
- no desktop environment, pure X.Org
- dwm as a window manager
- X.Org's native XKB configured with:
setxkbmap -layout us,rs -option grp:alt_shift_toggle
  which is executed by dwm on startup

and I can input various characters in Cyrillic, as well as color emoji and
other symbols using my own script[1].

May I ask what shell are you using inside st? The only problem I noticed so far 
with my script, which uses xdotool(1) to type characters, is when I am using it 
while st is specifically executing mksh as a shell. With bash, dash and zsh 
emoji are inserted correctly. This is undoubtedly some misconfiguration of mksh 
on my part, which I have yet to figure out in detail.

However, when I type ordinary text, regardless if it is using Cyrillic 
characters, using Serbian keyboard, or those characters you listed in your 
original message, using Spanish keyboard, they are entered and displayed 
correctly, even in mksh. I have captured a screenshot[2] as a proof of concept. 

In the first line in the screenshot, I have typed a command to configure XKB:

setxkbmap -layout us,es -option grp:alt_shift_toggle

In the second line, I have typed characters after switching to Spanish layout 
by pressing left Alt+Shift.

In the third line, I have typed the characters I used to get characters in the 
previous line, after switching back to US layout.

The other screenshot[3] demonstrates pasting a text containing color emoji from 
a web page into Bash running under st. I do have libxft-bgra patch for Xft 
installed through an AUR package to show color emoji.


[1]: https://git.sr.ht/~strahinja/dwm/tree/master/item/pickchar
[2]: https://i.imgur.com/yWd2nPd.png
[3]: https://i.imgur.com/7yTYHUY.png
[4]: https://aur.archlinux.org/libxft-bgra.git


signature.asc
Description: PGP signature

Re: [dev] Regarding dwm and st logo being removed

[Страхиња Радић]

On 22/04/28 12:19, Laslo Hunhold wrote:
> What do the others think?

I also like them, I think they contribute to overall visual identity of 
suckless programs and suckless.org and should be reincorporated into the 
website.


signature.asc
Description: PGP signature

Re: [dev] Regarding dwm and st logo being removed

[Страхиња Радић]

On 22/04/28 09:29, Hiltjo Posthuma wrote:
> Recently dark mode CSS support was added to the site.
> 
> It was reported on IRC the logo's were not visible with them.

This can be remedied with CSS which applies white background to logos (perhaps 
with some padding:  to also give a bit of a border).

In my opinion, dark mode is unnecessary and favored by mainstream "webdevs".


signature.asc
Description: PGP signature

Re: [dev][st] Solution: UTF-8 needs IBus!

[Страхиња Радић]

On 22/04/26 03:59, Robert Winkler wrote:
> To make a long story short: The input of UTF-8 characters with st needs
> an IBus daemon 

No, it doesn't.


signature.asc
Description: PGP signature

Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM

[Страхиња Радић]

On 22/04/26 05:39, Hadrien Lacour wrote:
> 
> Compare the output of env in the two situations. Something I noticed in one of
> your mails: you have en_US.UTF-8 in your locale output while here, on Gentoo, 
> I
> have en_US.utf8.

https://wiki.gentoo.org/wiki/Localization/Guide
> The command above lists the suffix in lower case without any hyphens, 
> glibc understands both forms of the suffix, many other programs don't. The
> most common example of which is X. So it is best to always use UTF-8 in
> preference to utf8.


signature.asc
Description: PGP signature

Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM

[Страхиња Радић]

On 22/04/26 08:20, Robert Winkler wrote:
> Anyone has an idea, what could be the difference between Gnome and DWM
> with respect to the font encoding?

I'm using dwm in X.Org using no display manager (autostart X at login [1]) in 
Artix Linux and everything works correctly. Setting environment variables 
correctly greatly depends on your startup "stack", ie. if you are using display 
manager such as lightdm, sddm... or just logging in through getty (like myself) 
and autostarting X at login, and also on your login shell. You should study the 
documentation of every piece of that "stack" thoroughly to determine how 
exactly to set up your system.

Like I mentioned in my previous message, input also depends on how you set it 
up in X. I'm configuring XKB[2] through the use of setxkbmap(1) by dwm on 
startup (I use "cool autostart"[3] patch for dwm to do that, though I could 
have also chosen to do it in $HOME/.xinitrc - again, I don't use a DM).


[1]: https://wiki.archlinux.org/title/Xinit#Autostart_X_at_login
[2]: https://wiki.archlinux.org/title/X_keyboard_extension
[3]: https://dwm.suckless.org/patches/cool_autostart/


signature.asc
Description: PGP signature

Re: [dev] [st] UTF-8 not working

[Страхиња Радић]

On 22/04/24 02:53, Robert Winkler wrote:
> Hi, thanks for all the hints I got from the [st] [dev]!
> Anyway, I still cannot sort it out; hopefully the following information
> helps that someone can spot the problem:
> As I mentioned, the UTF-8 symbols work in other terminals such as
> lxterminal.

How have you set up your input method? Try using setxkbmap(1) to set X input 
method. Also make sure that st's terminfo entries are installed
(make && sudo make install from st repository) and you have

export TERM=st-256color


signature.asc
Description: PGP signature

Re: [dev] [st] UTF-8 not working

[Страхиња Радић]

On 22/04/19 07:09, Robert Winkler wrote:
> 
> Sorry, but I don't get it fixed. I rebuilt the locals with dpkg-reconfigure 
> locales, with the US UTF-8 as default.
> 
> On lxterminal, the characters é, ö etc. work. In st they don't.

With

export LC_ALL=en_US.UTF-8

properly configured fonts in fontconfig[1][2][3] and properly configured 
config.h, Unicode characters, and even emoji, work in st. See the documentation 
for fontconfig for information on how to properly configure fonts in X.Org.

st works here perfectly with Unicode characters and color emoji.


[1]: https://www.freedesktop.org/wiki/Software/fontconfig/
[2]: https://freedesktop.org/software/fontconfig/fontconfig-user.html
[3]: https://wiki.archlinux.org/title/Font_configuration


signature.asc
Description: PGP signature

Re: [dev] Some direction with my project

[Страхиња Радић]

On 22/04/15 02:20, Wolf wrote:> 
> Configure script provides lot more then detection though. I have yet to
> see a hand written make providing support for --program-prefix or
> --program-transform-name for example. For packaging software, these
> additional features are useful from time to time.

They are trivial to program in a handwritten makefile.

On topic, suckless programs usually make use of makefiles which are 
hand-customized, just like the program settings (config.h). For bonus points, 
use Plan9 mk.

For my own programs, I prefer djb redo[2], which uses simple shell scripts and 
is better than GNU make[3].

About the Changelog/NEWS, they originate before the time of git and are 
superseded by git log/git shortlog.


1: https://9p.io/sys/doc/mk.html
2: https://github.com/apenwarr/redo
3: https://redo.readthedocs.io/en/latest/#whats-so-special-about-redo


signature.asc
Description: PGP signature

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[Страхиња Радић]

On 22/02/17 01:08, NRK wrote:
> Assuming there isn't, one alternative could be just using env vars.

Why would an environment variable be preferable here to a command line
parameter?

Environment variables are clunky, messy, insecure, prone to errors, race
conditions and the whims of a particular setup. They should be avoided whenever
possible. The suckless way is to have configuration done in config.h instead.

In this specific example, having a separate dmenumon, which would have to be
updated, is needed because of C.  It is needed to pass ASCII character for the
monitor number, which thus has to be constructed by using the expression:

'0' + selmon->num

but we can't use this expression directly in place of dmenumon to initialize
dmenucmd, because it is not allowed to have non-constant initializer elements in
C. (Try it as an exercize - you'll get a compilation error.)

I guess the room for improvement would be to move the code to reassign dmenumon
to some other (more "optimal") place than spawn function, but I don't see the
realistic gain from doing that, or need, outside of some abstract purism.


signature.asc
Description: PGP signature

Re: [dev] Is there a text editor following the UNIX philosophy?

[Страхиња Радић]

On 22/02/11 11:47, Daniel Littlewood wrote:
> It seems to me like the obvious alternative workflow would be, rather
> than to have a single monolithic program for the general job of
> "editing text" (which is really lots of jobs pretending to be one),
> one might have a program for syntax highlighting, a program for
> completion, a facility for dispatching text to shell commands, and so
> on. On the more extreme end one could even imagine separating the jobs
> of navigating through a buffer (i.e. a pager) from the editing of
> text. Obviously that's not a complete idea by itself, or I wouldn't be
> asking for suggestions.

The question of "Unix philosophy" is more nuanced than that, it should be
applied in an sensible manner. It just isn't practical to bring the scope which
the "thing" that "programs do well" belongs to, down to such a fundamental level
as navigating through a buffer. Those buffers are better manipulated as internal
structures inside a single program, rather than some (textual) representation in
an input/output stream.

What should and can be avoided though, are for example plugins. A text editor
doesn't need plugins, it should be sufficient for its purpose. Customization
could be instead implemented through patches, as in other suckless programs.

A text editor should do "its thing" well, nothing more, nothing less. "Its
thing" should be editing of text files.


signature.asc
Description: PGP signature

Re: [dev] requirements of build systems

[Страхиња Радић]

On 22/02/05 03:23, Petros Pateros wrote:
> On Mon, Jan 31, 2022 at 06:38:01PM +0100, Страхиња Радић wrote:
> > apenwarr/redo is the implementation of djb redo I settled on for my 
> > programs. It
> > has the most features among the current implementations.
> 
> I'm glad to hear that. But it doesn't implement the less-features feature 
> (that comes
> along with the only-the-features-necessary-for-the-do-one-job-well-plan) that 
> I
> was looking for ;-).

I'm not talking about the unnecessary cruft here, just the most features within
the djb's redo specification.


signature.asc
Description: PGP signature

Re: [dev] requirements of build systems

[Страхиња Радић]

On 22/01/31 12:10, Petros Pateros wrote:
> What would you expect from a build system? Should it trust mtime?
> Is it responsible for verifing the file's contents for actual changes?
> More generally, what are the key features that make a build system useful?

apenwarr/redo is the implementation of djb redo I settled on for my programs. It
has the most features among the current implementations. For redistribution, it
has a shell script named "do", so even if users don't have full apenwarr/redo
installed on their system, they can execute

$ ./do -c

to build my programs, or

# ./do -c install

to install them.


signature.asc
Description: PGP signature

Re: [dev] [surf] segmentation fault

[Страхиња Радић]

On 22/01/13 11:52, m...@datameer.com wrote:
> Regarding the note on the website `Compile your own webkit or expect
> hell`...
> Is it better or more stable to compile webkit as well?

Why don't you just try it and find out?

If you are asking me about my personal experience, I always compile surf from
source. I maintain my own personal fork with my choice of patches and
customizations at [1]. I never had any problems yet on Artix with compiling and
using surf with Artix's precompiled webkit.

When using binary packages, you are at the mercy of however the maintainers of
your distro decided to compile it. When you compile software from source, you
have (more) control over how the software is compiled. If the binary version of
wekbit doesn't work, the only other thing you can try is compile it from source.
If that fails too, raise the issue with the maintainers of your distro.

[1]: https://git.sr.ht/~strahinja/surf


signature.asc
Description: PGP signature

Re: [dev] [surf] segmentation fault

[Страхиња Радић]

On 22/01/12 04:02, m...@datameer.com wrote:
> Does that mean I have to compile surf incl all dependencies with
> https://github.com/void-linux/void-packages?

Compiling from source is the intended way to use suckless software.

Suckless software is configured by editing config.h, rather than by using
configuration files.


signature.asc
Description: PGP signature

Re: [dev] [surf] XDG conformity

[Страхиња Радић]

On 21/12/16 09:39, Janek F wrote:
> After trying surf recently, I was appalled to see a ".surf" directory in my 
> home.
> Is XDG basedir compliance not natural in suckless software?

Suckless software follows the principles that predate X Desktop Group and its
specifications, as well as its own principles.

Before 2000, it was customary in GNU/Linux to have user-specific configuration
files in the user's home directory, starting with a dot. For example, vim's
configuration file is ~/.vimrc, joe's configuration file is ~/.joerc and so on.
Those files are commonly called "dotfiles", because they literally start with a
dot, and programs like ls omit listing them by default (they are "hidden").

In addition, suckless software has its own convention, which is to configure
software by changing a header file in its source code, usually located in the
file config.h in the source directory of a particular program.


signature.asc
Description: PGP signature

Re: [dev] [st] wide characters getting cropped

[Страхиња Радић]

On 21/11/10 08:55, NRK wrote:
> I wouldn't say it's "critical need". And if we judge from that pov then
> one could ask, "What's the critical need for a dynamic window manger or
> minimal softwares in general?".

Terminal emulator's job is to allow terminal input/output. Latency is simply not
relevant, unless it is noticeable by a human (for example, if a simple "cat
/some/file" for a multi-line text file has a delay anywhere from 500 ms to a
second or two between the output of individual lines, when not dependant on
factors such as reading from a network of a faulty hard disk; that would just be
annoying, but still usable). st doesn't have such issues, so anyone experiencing
them should look for the cause elsewhere (Xft/fontconfig?).

Also, the need for "minimal software" is not comparable to the "need" for "low
latency" in a terminal emulator. The former is a fundamental concept, while the
latter is superficial.

> XTerm has many (visible) problems. Maybe I've misconfiuged it, but I
> cannot get it to fallback to other fonts reliably, and thus some glyphs
> don't render. It also chokes badly when it tries to render some unicode
> glyphs for the first time.

If you refer to color emoji or Nerd Font symbols, they are poorly supported in
X, and I'd even say they are bloat by themselves. But it is to be expected of
XTerm to have problems. To quote https://st.suckless.org,
> xterm is bloated and unmaintainable. Here's an excerpt from the README:
> 
> Abandon All Hope, Ye Who Enter Here
> 
> This is undoubtedly the most ugly program in the distribution. It was one
> of the first "serious" programs ported, and still has a lot of historical
> baggage.  Ideally, there would be a general tty widget and then vt102 and
> tek4014 subwidgets so that they could be used in other programs. We are
> trying to clean things up as we go, but there is still a lot of work to
> do.
> 
> Needless to say things have not changed, it's still ugly. It has over 65K
> lines of code and emulates obscure and obsolete terminals you will never need.
> 
> The popular alternative, rxvt has only 32K lines of code. This is just too
> much for something as simple as a terminal emulator; it's yet another example
> of code complexity.
> 
> Terminal emulation doesn't need to be so complex.


signature.asc
Description: PGP signature

Re: [dev] [st] wide characters getting cropped

[Страхиња Радић]

On 21/11/09 02:00, Laslo Hunhold wrote:
> I'm always wondering: What do you suggest to improve the
> latency-situation? Can we even be "better" than the screen's framerate?

I'm wondering what's the use case for such critical need for low latency?
Playing DOOM (2016) in a terminal with aalib? That's not what terminal emulators
were meant for.


signature.asc
Description: PGP signature

Re: [dev] [st] wide characters getting cropped

[Страхиња Радић]

On 21/10/29 12:18, Dmytro Kolomoiets wrote:
> Страхиња Радић, do you have a cleaned up version of the patch
> which applies to latest st tree without rejecting hunks?

No, but it shouldn't be too hard to make given the PR. I have applied it to my
fork of st (https://git.sr.ht/~strahinja/st).


signature.asc
Description: PGP signature

Re: [dev] [st] wide characters getting cropped

[Страхиња Радић]

n 21/10/26 07:51, Ian Liu Rodrigues wrote:
> echo -e '\e[31m \e[0m c'
> echo -e '\e[31m  \e[0mc'
>
>
> Here is a screenshot of the script's output: https://qu.ax/3SBs.png

For me, this patch fixed the glyph truncation:

https://github.com/LukeSmithxyz/st/pull/224

Perhaps someone could add this to the official patches?


signature.asc
Description: PGP signature

Re: [dev] Whether a css selector applies to given html surf code

[Страхиња Радић]

On 21/10/26 08:32, Sagar Acharya wrote:
> People like what they feel. Majority of people out there aren't coders.
> Majority of coders just code to earn and would gladly just accept what their
> company pushes to them. These people just like convenience. As much as we'd
> like them to accept a bit of pain for minimalist and simple code, I don't
> think they'd go beyond a certain point.
[...]
> Somethings work different to the way we want them to work. And the sad reality
> is, majority people are never gonna accept simplicity as a trade off for
> convenience. I think keeping convenience the same while making things simple
> is the way forward. I love suckless but this is where I differ a bit.

I believe we already had a similar conversation back in August and April. Here's
my reply from August:

==

On 21/08/07 02:54, Sagar Acharya wrote:
> This is where I diverge from suckless, suckless goes for hardcore minimalistic
> software at cost of user experience. 

Wrong. I'd argue that the "user experience" in most programs that suck is worse
than the "user experience" using suckless programs. That's one of the reasons we
call them like that - "programs that suck" and "suckless programs".

I believe we already discussed this about four months back.


>Addicted to almost all software out
> there like WhatsApp, Facebook, and many more things, most are never gonna use
> stuff like dwm. And things like Windows would keep them there. I myself
> use dwm, hyperbola OS, but suggesting it to common people wouldn't be
> wise. They'll switch back to Windows, and this time maybe forever.

And?

This sense of urgency and worry about the size of the userbase seems to be tied
to "software development" inside (big tech) corporations. They add (or remove)
features to software guided by statistical analysis of the target audience with
the aim of supporting what is perceived to generate the most profit, not by the
program's purpose or any other reason. Suckless movement is not a corporation.
It is a gathering of programmers writing software for themselves and others who
value the principles of simplicity and quality in software.

If anyone wants to use other software, by all means they should. There's nothing
wrong with that, but on the other side, that shouldn't influence suckless
programs.


signature.asc
Description: PGP signature

Re: [dev] Whether a css selector applies to given html surf code

[Страхиња Радић]

On 21/10/26 05:22, Nick wrote:
> Quoth Страхиња Радић:
> > This is what a web page should be:
> > 
> > http://motherfuckingwebsite.com/
> 
> When I load that in tor browser with js disabled (my default setup 
> these days), I get a 20741 byte page with the title "Captcha" and no 
> content except an eternally rotating image.
> 
> The web is beyond saving.

Yeah, it seems it sadly includes Gogole Analytics JS at the end after all:

Re: [dev] Whether a css selector applies to given html surf code

[Страхиња Радић]

On 21/10/26 04:48, Sagar Acharya wrote:
> That's a bit more primitive. It can go a bit more vibrant wrt fonts, colors,
> break points for mobile, tablet which would still be minimal in my view. I'm
> approaching such simplicity from the other complex end which most people
> prefer, unfortunately.

These are the web pages of some of the giants of computing:

https://www-cs-faculty.stanford.edu/~knuth/
https://www.w3.org/People/Berners-Lee/
https://www.bell-labs.com/usr/dmr/www/
http://www.wall.org/~larry/
https://www.cs.helsinki.fi/u/torvalds/
https://stallman.org/

Notice anything they have in common?

Modern web is a perversion of what it once was - a simple environment to
represent hypertext. Years of cruft and overengineering have lead to a bloated
mess we have today. Things like Gemini

https://gemini.circumlunar.space/

have risen recently precisely to address this problem.

Suckless movement is not about conformism, about "going with the flow" of what
"most people prefer". On the contrary, it is about shaking up the core values of
mainstream computing.

Take dmenu as an example. Its most well known use is to launch programs from the
script dmenu_run. Its counterpart in the traditional GUI would be eye candy
icons or shortcut buttons on some panel. When first confronted with such
concept, "most people" will find it "primitive" and even outlandish. However, if
some thought is given to understanding why it is made that way, one inevitably
starts to see the genius of the concept and why it is much better than clicking
an icon or a button with a mouse.

Surf is a necessary evil to be able to access the modern web. For new websites
however, anyone who finds value in the suckless principles should actively work
on reverting the web to a sane state it was in some 20+ years ago.

I suggest starting by making websites one creates viewable and readable in:

- NetSurf
- links


signature.asc
Description: PGP signature

Re: [dev] Whether a css selector applies to given html surf code

[Страхиња Радић]

This is what a web page should be:

http://motherfuckingwebsite.com/

This is less minimal, more readable, but still not plagued by "frameworks" and
"web coding" (uggh!). This is as far as web should go, ideally:

http://bettermotherfuckingwebsite.com/

There is nothing to gain from "minifying" CSS, just lose on readability by a
human.


signature.asc
Description: PGP signature

Re: [dev] tcvt: very useful for seeing more at once

[Страхиња Радић]

On 21/10/15 07:03, Martin Tournoij wrote:
> Note that mandoc has a default of 78 if not set; GNU man (and maybe some
> others?) do indeed take up the full width by default, but mandoc won't take up
> more than 78.

I've mostly used GNU man, and from my briefly trying other versions of man I
didn't go into that much detail regarding whether they set MANWIDTH or not, so I
don't know.

In any case, navigating man pages using the default pager is easy enough.


signature.asc
Description: PGP signature

Re: [dev] tcvt: very useful for seeing more at once

[Страхиња Радић]

On 21/10/14 12:28, Greg Reagle wrote:
> Useful, but a lot of wasted screen space on my monitor:
> man dwm

If MANWIDTH is unset (default), man page will take all of the available width of
the terminal, unless:

- COLUMNS is also somehow unset (it is set by most sane shells by default), or
- ioctl(2) is somehow nonfunctional, or
- you are not using a tilling wm, or
- you are using a floating terminal, in which case switching it back to full
  screen should use up more of the screen space.

I have no idea what tcvt is or does. Since you haven't provided any details on
that program(?)/script(?), I can only guess.


signature.asc
Description: PGP signature

Re: [dev] st crash(child exited with status 1)

[Страхиња Радић]

On 21/09/28 01:24, Sergei wrote:
> 1. screen -dmS rtorrent_daemon rtorrent -n -o import=~/.rtorrent/rtorrent.rc
[...]
> 2. sudo -u user bash -c "st  -e screen -r rtorrent_daemon" or "st -e screen
> -r rtorrent_daemon

st -e screen -r rtorrent_daemon

Running this command, there are no issues here. Ensure that screen is
active in the background first by

ps aux | grep -i screen

before executing the second command.

P.S: Bloat - sudo, GNU Screen, Bash, Debian (a distribution of Systemd/Snap).


signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/16, 20:36, Kyryl Melekhin wrote:
>And remember, always follow unix philosophy - go for what works first, optimize
>it later.

This should read "programs should do one thing and do it well" (DOTADIW)[1],
with the added "and work together".  Exactly what Wayland's monolithic,
opinionated concept doesn't. If a compositor crashes, the whole session goes
down. Comparatively in X.Org, you lose window transparency, shadows and
animations and can continue your work as normal. Wayland is in many ways
reminiscent of systemd.

[1]: https://en.wikipedia.org/wiki/Unix_philosophy


On 21/09/17 06:33, Tobias Bengfort wrote:
>I think much of the hate for wayland is misdirected. 

Although I cannot speak for everyone, criticism of Wayland is driven by facts,
not emotions. "Hate" or "love" don't have anything to do with it.

> Don't get me wrong, the state of wayland is bad. But IMHO that is not entirely
> the wayland people's fault.

It doesn't matter who is responsible. If Wayland is not finished, its developers
shouldn't act like it is and force it on users and programmers. Ideally, common
courtesy would be to dedicate part of their efforts towards the "long term
support" (fixing bugs, actual "finishing") of X.Org without introducing new
features. For example, they could address the well-known Xft color emoji crash,
a real example affecting suckless software. Instead, they deliberately choose
otherwise, while presenting Wayland as the new standard, using strong language
to tell off and even openly insult, resorting to petty name-calling, people who
suggest this or who present evidence on why their decisions are wrong. They
didn't even merge independently developed libxft-bgra patch so far! (Yes, it
doesn't solve the entire problem yet, but that's what git is for.)

>it's open source and I cannot force anyone do work on X if they don't want to.

Neither should Wayland be presented as the "be all, end all" of GUI under
GNU/Linux, even moreso since it "isn't in a good state" (fully agree).  After
all those years, someone should begin to wonder if it's worth it at all. Maybe
the general direction should be reevaluated?

>We could absolutely have a full replacement for the X server based on wayland.
>The wayland people won't build it for us though. Neither will the gnome 
>people. 

To use an allegory: it is perfectly fine that they don't want to build our
bridges. But they shouldn't tear down the ones we have, no matter how worn out
or in need of repair they might be. The new ones have design flaws and aren't
even complete.

> You can decide for yourself whether you want to keep whining

Typical use of a strong language as a substitute for having real arguments.

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/08 01:36, Nick wrote:
> The fact that the Jitsi devs closed 
> the bug as "not much we can do on our side" doesn't mean "wayland 
> broke it and we can't fix it".

It's exactly the same thing.

> the screen recording / sharing stuff - it works differently on 
> Wayland (for not-bad reasons),
[...]
> good reasons (thinking of the "prevents GUI applications from 
> running as root" and "breaks windows rasing/activating themselves").

The issues listed show a pattern and the impact of breaking with a
long-standing, time-tested tradition just for the sake of doing something "new"
and "different". "New" doesn't automatically mean "good".

They also show the attitude of the developers responsible for Wayland. I don't
like it when the "developers" tell the users what is good for them, especially
when they are being opinionated and stubborn for no reason at all.  Let the
users decide how they are using the software. Let us be able to make mistakes! 

It is the same line of thought as when we compare C to a language like Rust. One
of the key reasons why C is better than Rust and similar overprotecting
opinionated languages, is because it gives user the freedom to do whatever he
wants, mistakes included. In this, C is closer to machine language, and thus
more powerful, more expressive, allowing finer control.

Similar thing to Wayland happened with systemd, the developers responsible for
it were acting unreasonably and immaturely when confronted with different
opinions. Whenever one lacks civility in communication and resorts to
swearwords, that shows faulty of his cause and a weakness of his conviction.

You haven't mentioned the other points, just some of the major ones being the
issue of non-GNOME desktop environments, for example KDE. I'm not using KDE, but
why just erase it in favor of GNOME monopoly? I'm using no desktop environment,
I'm using dwm, but many of its key features are not supported by Wayland. 

Again and finally, I don't want to have to change my software-using habits just
because some "developer's" decision. I want to choose what software I use and
how. Thankfully, there are free licenses, and no free software is ever truly
"dead". If Wayland becomes enforced like systemd, in time there will be a
solution comparable to runit/OpenRC/s6.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Страхиња Радић]

By the way, here's another article not on Github (but linked from that page):

https://tildearrow.org/?p=post=2=2021=antihs



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/08 12:28, Nick wrote:
> honest I found the arguments made there to be largely unconvincing, 

Any argument in particular and why?

> * I'm thinking in particular of the repeated "emojis broke my st" 
>   mails, caused by a bug in Xft that noone upstream seems to care much
>   about fixing, and the fact that surf is a really just a nice
>   interface atop the hulking edifice of webkit2/gtk+

This is the fault of X developers, who decided to dedicate their time entirely
to Wayland. In their eyes, Wayland is the continuation of X.Org.

It is clear by now that Wayland is influenced by big corporations, RedHat in
particular, which is also forcing things like GNOME, systemd and Rust in the
Linux kernel upon the users.

Wayland sucks. X.Org sucks too, but it is still much better than Wayland.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/08/31 02:28, Nick wrote:
> Hi all,
> 
> I'm thinking it would be fun to play around with Wayland, so was 
> looking at different compositors (which do window management plus 
> other stuff). Has anyone else on the list taken Wayland for a spin 
> and had any experience with them?
> 
> From a search around the 3 that look interesting to me, a dwm user 
> for many years, are:
> - velox - written by Michael Forney, described as "inspired by dwm 
>   and xmonad"
> - sway - i3 for Wayland, undoubtedly mature, undoubtedly more 
>   features than I'd prefer
> - dwl - "dwm for Wayland", looks nicely dwm-ish, though no built-in 
>   status bar so I guess I'd have to find some external software to 
>   provide that.
> 
> Any thoughts, experiences, recommendations?
> 
> Nick
> 

https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277



signature.asc
Description: PGP signature