Hi there,
On Fri, Jun 21, 2024 at 8:21 AM Greg Reagle wrote:
> I have looked into numerous language: Rust, Pascal, Ada, V, Hare, Zig, D,
> and others I am probably forgetting. I have not become an expert in these
> languages but read tutorials. And I have written small programs (like cal)
>
Hi there,
On Thu, May 11, 2023 at 1:04 PM wrote:
> DISCLAIMER: a shittily-put rant which should be useful, hopefully. Sorry, my
> eyes hurt a lot already.. god fucking dammit :(
>
> You wanted a simple reply? You got a fucking storm lmao, enjoy.
Talk to your green supplier, that they should doub
On Tue, 23 Jun 2020 at 14:48, wrote:
> I am writing a wm for myself and I have a question about how dwm (and
> a lot of other WMs that copies dwm, such as katriawm and berry) hides
> clients.
>
> dwm manage() a client when it receives a MapRequest event and unmanage()
> it when it receives both a
Hi there,
On Sun, 5 Apr 2020 at 04:00, Laslo Hunhold wrote:
> On Sun, 5 Apr 2020 12:11:09 +0200
> Georg Lehner wrote:
> > A question: why is the scrollback-patch not included in `st` already
>
> exactly my point. I see no reason why there can't at least be a
> scrollback, which defaults to 0 in
On Wed, 25 Sep 2019 at 23:27, Laslo Hunhold wrote:
> quark drops all its permissions as soon as it has done all the things
> it needs to do. This also includes that you can't accidentally serve a
> root directory. To underline it further, quark _disallows_ itself to
> run as root while serving for
Hi Laslo,
On Tue, 24 Sep 2019 at 23:22, Laslo Hunhold wrote:
> On Tue, 24 Sep 2019 11:17:09 -0700
> Anselm Garbe wrote:
> > - Always run as current user, if root is used chroot() to current
> > directory.
>
> chroot() should never be optional. unveil() might bring th
Hi Laslo,
On Tue, 24 Sep 2019 at 02:02, Laslo Hunhold wrote:
> Quark is actually very lean and offers 99% of the features you would
> expect for a static server. I personally am a big fan of OpenBSD's
> httpd and will use it on the server I am currently setting up.
>
> I see quark's role more lik
On Mon, 23 Sep 2019 at 12:50, Richard Ulmer
wrote:
> I checked the performance of revision
> 22b5b3cfa6b28f8e0c6c35c04ad9b4cb609b5643 like this:
>
> echo 'foo bar' > index.html
> doas quark > /dev/null &
> ab -n 1 -c 20 'http://localhost:8083/'
>
> And I got 942 requests/second, so I'd say the
Hi Richard,
On Mon, 23 Sep 2019 at 11:34, wrote:
> I'm toying with quark and noticed it's comparatively poor performance in
> my use case. I used Apache bench to benchmark the web server. With this
> setup I got 980 requests/second:
Out of curiosity, can you do me a favour and check a very old r
Hi there,
On Mon, 6 May 2019 at 08:05, sZpak wrote:
> I prepare myself for doing programming classes/course for kids/teenagers
> in a local community center. And I need your advice.
I think you ask this question in the wrong forum. Suckless targets
expert users, not programming noobs. But anyway
Hi there,
On Thu, 28 Feb 2019 at 10:27, aleks wrote:
> The spawn method in dwm.c checks if the received argument is dmenucmd
> and if so it sets the variable dmenumon (which is defined in config.h)
> to the currectly selected monitor (at least thats what I think is
> happening).
>
> It seems to m
On Wed, 13 Feb 2019 at 08:59, Hiltjo Posthuma wrote:
> I wonder what people think if XIM support is removed from dmenu (but kept for
> st). Reverting XIM and the input focus change?
Absolutely ;) People who need it, could maintain a patch for it.
--Anselm
Hi there,
can you be a bit more elaborate how to run into this bug? How does it
occure in your setup?
Is config.h modified? What are the inputs (from stdin), what do you enter?
Thanks,
Anselm
On Thu, 7 Feb 2019 at 18:35, Jordan Timmerman wrote:
>
> First bug report -- also only an amateur at d
Hi there,
I'm glad to announce new dwm and dmenu releases:
* dwm-6.2: https://dl.suckless.org/dwm/dwm-6.2.tar.gz
* dmenu-4.9: https://dl.suckless.org/tools/dmenu-4.9.tar.gz
These releases are the last ones that contain Xft support, which will
be removed in the releases to follow. The Xft mess ha
On Thu, 31 Jan 2019 at 20:18, Zach van Rijn wrote:
> Then I guess my concern is that, this level of discretion is not
> or does not appear to be used consistently in discussions that
> occur on the mailing list. I don't know of the IRC channel or
> elsewhere, but insofar as to the historical recor
Hi Hiltjo,
On Thu, 31 Jan 2019 at 11:48, Hiltjo Posthuma wrote:
> I'd like to show an experiment I made for automatically testing patches on the
> wiki. Its purpose is it to have a quick overview of broken patches on the
> wiki.
> I hope this will also help the community and patch authors in fi
On Thu, 31 Jan 2019 at 19:48, wrote:
> The thing I really don't understand, is this mailing list attracting some
> random group of guys, at regular time intervals, almost totally missing the
> point of "suckless", and though, pretending to get it while bringing on the
There is no surprise. The wo
On Thu, 31 Jan 2019 at 17:59, Zach van Rijn wrote:
> On Thu, 2019-01-31 at 09:49 -0800, Anselm Garbe wrote:
> > > > Our philosophy is about keeping things simple, minimal and
> > > > ...
> >
> > This is still totally accurate for the software industry, even
On Thu, 31 Jan 2019 at 07:50, Zach van Rijn wrote:
> If I may cite a brief excerpt from this page:
>
> > Our philosophy is about keeping things simple, minimal and
> > usable. We believe this should become the mainstream
> > philosophy in the IT sector. Unfortunately, the tendency for
> > complex,
On Sun, 27 Jan 2019 at 01:33, Richard Wiedenhöft
wrote:
> I am very interested in why you dislike functional-programming paradigms. It's
> a lot of complexity for sure but IMHO it makes it easier to reason about
> certain complicated problems. There are cases where it's worth the extra
> (well-def
On Tue, 29 Jan 2019 at 12:35, Cág wrote:
> Anselm Garbe wrote:
> >> Implying C is such an obscure language that can never pay your bills.
> > No implication here. But demand for plain C developers is considerably
> > lower these days with the exception of the embedded/
Hi Ciprian,
On Sat, 26 Jan 2019 at 13:35, Ciprian Dorin Craciun
wrote:
> * I would skip C if it doesn't require too much OS-related
> interaction; in fact if I do need OS interaction, Rust is a better
> alternative than Go, due to Go's goroutine runtime which, as a
> previous poster noticed, doe
On Sat, 26 Jan 2019 at 06:27, Siraaj Khandkar wrote:
> On Jan 25, 2019, at 20:18, Anselm Garbe wrote:
> > C89 (or C99) clearly remains the preferred language for suckless
> > software. However, when forced into typical day job developments to
> > fund your well being, gol
On Sat, 26 Jan 2019 at 03:55, Cág wrote:
> Anselm Garbe wrote:
> > However, when forced into typical day job developments to
> > fund your well being, golang might actually be the sanest option on
> > the table -- in order to avoid worse options such as Rust, Java,
>
On Fri, 25 Jan 2019 at 09:54, Nick wrote:
> Anybody else enjoying Go? Or hating it? Have I become lazy and
> trendy in my middle age?
Nice try.
C89 (or C99) clearly remains the preferred language for suckless
software. However, when forced into typical day job developments to
fund your well bein
On Wed, 26 Dec 2018 at 03:56, Martin Tournoij wrote:
> Don't want to start a discussion about it, but I'm curious why // is
> disallowed? AFAIK all compilers accept // these days, and have for a
> long time?
Consistency, -- we only want one way of comments in code, as with
everything else.
Follo
Hi Stephen,
On Wed, 9 Jan 2019 at 01:14, Stephen Gregoratto wrote:
> I am interested in creating an OpenBSD port of 9base, as the current p9p
> port depends on ghostscript (which I don't need on a server). However,
> the current tagged version of 9base is now 8.5 years old, and there have
> been
Hi Markus,
On 10 March 2018 at 06:08, Markus Teich wrote:
> Should be fine, but the salt should not be secret (you need to sync it
> between devices where you want to use this system after all). The point is
> that you can give your encrypted database as it is stored on disk to anyone
> and they
On 11 January 2018 at 07:03, k.suz...@aist.go.jp wrote:
> Can I build stali with another libc? The old stali seems to be built by
> uClibc.
> https://chemnitzer.linux-tage.de/2010/vortraege/shortpaper/308_stali.pdf
> https://dl.suckless.org/stali/clt2010/stali.html
> Should I use old stali sourc
On 5 January 2018 at 04:32, k.suzaki wrote:
> I found the following comment in the
> musl-cross-make/patches/gcc-4.2.1/0001-musl.diff
> "musl does not support the legacy OABI mode."
Exactly.
Best,
Anselm
Hi Laslo,
On 19 October 2017 at 15:17, Laslo Hunhold wrote:
[..]
> Alright, we are now at g_malloc(), and as we can see in line 94 it's
> just malloc() with some GNOME-vomit around it.
>
> TL;DR: g_strdup() == strdup()
>
> Reading this code is a real pain. It's like diving into a fractal,
> where
Hi Matthew,
On 12 October 2017 at 16:21, Matthew Parnell wrote:
> I'm writing a header file that will contain constants required.
> Should I use:
>
> #define FOO 123.456
Depends on the kind of header file you are talking about. A CPP define
can be the right thing, if this header file is part
Hi Laslo,
On 8 October 2017 at 13:05, Laslo Hunhold wrote:
> On Sun, 8 Oct 2017 11:14:21 +0200
> Anselm Garbe wrote:
>> But granted, that the cleanest solution would be to base all suckless
>> tools on 9base/mk instead.
>
> mk is nice, but there is just not enough &
On 8 October 2017 at 10:43, Bert Münnich wrote:
> Yes, I am. Unfortunately for you, I have no such plans. I rather use a
> portable make than bother to write a portable Makefile. Also,
> out-of-source builds are much harder if only using POSIX make syntax.
>
> Maybe it's better to write a new mini
On 23 September 2017 at 01:51, wrote:
> This topic was discussed earlier: no, go is not worth it. It's really a bad
> compromise against simple and explicit C. Wrong again: simple and explicit C
> is
Not sure who came up with that conclusion. Granted, you can solve many
problems surprinsingly we
35 matches
Mail list logo
