On 10/23/16, Bruno Vetter wrote:
>> I suggest just grabbing cert.pem from libressl.
>
> Thanks for the quick reply. Do you know if there is a designated default
> path for certs in stali?
It looks like the stali curl_config.h sets CURL_CA_BUNDLE to
/etc/ssl/certs/ca-certificates.crt[0]. I suspect
> If all I want to do is flip my laptop closed to go from the kitchen to
the bedroom…
then your laptop should realize you're doing nothing and keep the CPU
in idle state anyway. you shouldn't need to tell it specifically,
especially for such a short time. shouldn't be worth it.
sane laptops will
> I suggest just grabbing cert.pem from libressl.
Thanks for the quick reply. Do you know if there is a designated default path
for certs in stali?
>From what I see, stali's curl is not built with any certs default path or
>default bundle file. I don't know if it falls back to some libressl set
On Sun, Oct 23, 2016 at 8:47 AM, Bruno Vetter
wrote:
> what is the recommended way to obtain a decent bundle of CA certificates for
> stali? Like the ones I find in /etc/ssl/certs in my current distro.
I suggest just grabbing cert.pem from libressl.
> On 10/21/16 11:48, Anselm R Garbe wrote:
> > I've been arguing against MS Windows' misdesign to reboot the system
> > on configuration changes. But from a stali perspective I kind of
> > prefer rebooting the system for the prize of avoiding a daemon or
> > runlevel management. It's simpler and it
Dear Anselm, and suckless folks,
On 10/21/16 11:48, Anselm R Garbe wrote:
On 21 October 2016 at 10:01, Kamil Cholewiński wrote:
On Thu, 20 Oct 2016, Laslo Hunhold wrote:
as an off-idea: How are startup-times of stali? Given the power of
machines today, there should not be many things limiti
On 21 October 2016 at 10:01, Kamil Cholewiński wrote:
> On Thu, 20 Oct 2016, Laslo Hunhold wrote:
>> as an off-idea: How are startup-times of stali? Given the power of
>> machines today, there should not be many things limiting a startup in
>> just a few seconds. Any data on that?
>
> Oh just try
On Thu, 20 Oct 2016, Laslo Hunhold wrote:
> as an off-idea: How are startup-times of stali? Given the power of
> machines today, there should not be many things limiting a startup in
> just a few seconds. Any data on that?
Oh just try it. I was truly amazed.
>From bootloader to login prompt in li
On Thu, 20 Oct 2016 07:57:44 +0200
Anselm R Garbe wrote:
Hey Anselm,
> Are you talking about svc? Actually I did not create them and never
> understood the need for them
>
> My take is to keep everything in rc.init resp. rc.exit. I don't need
> on demand services. If something should run as a d
On 19 October 2016 at 19:10, stephen Turner wrote:
> So i briefly viewed the svc scripts, it appears that you have for the
> most part recreated daemon-tools in script form?
Are you talking about svc? Actually I did not create them and never
understood the need for them
My take is to keep everyt
So i briefly viewed the svc scripts, it appears that you have for the
most part recreated daemon-tools in script form?
Perhaps i over looked it but it also appears to have omitted a auto
restart of the service. I assume this is by design and a good choice i
would think for a number of reasons. Is
On 18 October 2016 at 19:31, Bruno Vetter wrote:
> thanks for all the support so far.
> How would one connect to wifi in stali? For me, installing libnl-tiny and
> wpa_supplicant works, but I'd be interested to hear if/how this is meant to
> be achieved in a stali way.
ip and sdhcp are already
i use udhcpc from busybox
On Tue, 18 Oct 2016, Cág wrote:
> stali has sdhcp.
Thanks for the suggestion, I may include it in my setup at some point.
dhclient? I thought that was, *relatively* speaking, looked down on?
stali has sdhcp.
On Tue, Oct 18, 2016 at 07:46:14PM +0200, Kamil Cholewiński wrote:
> not running stali (Debian here), but should work all the same.
> I simply put wpa_supplicant and dhclient under runit:
dhclient? I thought that was, *relatively* speaking, looked down on?
On Tue, 18 Oct 2016, Bruno Vetter wrote:
> Hi there,
>
> thanks for all the support so far.
> How would one connect to wifi in stali? For me, installing libnl-tiny and
> wpa_supplicant works, but I'd be interested to hear if/how this is meant to
> be achieved in a stali way.
>
> Bruno
Hi Bruno,
On Mon, Oct 17, 2016 at 6:53 PM, Evan Gates wrote:
> The plan for now is to use 9 base troff and a pager which has not yet
> been picked. Currently 9 base troff has been added to the src repo,
> but the mdoc macros still need to be included (the ones from heirloom
> troff worked). As such you shou
On Sat, Oct 15, 2016 at 5:57 AM, Bruno Vetter
wrote:
> Guten Tag,
>
> trying out stali I see that manpages are included, but how can I actually
> view them? Before I install anything I want to ensure to do it in the most
> suckless way.
>
> Thank you
> Bruno
The plan for now is to use 9 base tr
On Sun, Oct 9, 2016 at 7:47 PM, Anselm R Garbe wrote:
> Looks like a man page fault to me, probably lksh.1 is copied over
> sh.1. The binary should be definitely mksh.
Yep, binary is named sh in stali.mk and bin.mk checks for $(BIN).1 so
we get sh.1 which is for lksh instead of mksh.1. Simple sol
Hi Bruno,
On 9 October 2016 at 10:06, Bruno Vetter wrote:
> i'm curious why you have chosen lksh as the stali shell. The manpage says:
Looks like a man page fault to me, probably lksh.1 is copied over
sh.1. The binary should be definitely mksh.
Cheers,
Anselm
Bruno Vetter wrote:
I'm curious why you have chosen lksh as the stali shell.
Nobody has. If I'm not mistaken, /bin/sh is a symlink to /bin/mksh.
loksh[0]
is another shell that is mentioned on the site, but yet to be
distributed
with the rest of the source.
Cág
[0]: https://github.com/dimk
On 7 October 2016 at 16:24, Bruno Vetter wrote:
> yes, it's tedious and I understand that it's not crucial to have the
> toolchain statically linked. Trying to do so also brings up a lot of
> questions that I cannot answer easily. For example a statically linked linker
> apparently does not sup
On 7 October 2016 at 12:27, Cág wrote:
> Anselm R Garbe wrote:
>
>> It is pretty easy. Use the toolchain as is and copy some glibc based
>> .so's for x86_64 to /crap/lib on the stali target as well.
>
> But it will not be statically linked then, as OP asked for.
Building a statically linked toolc
Anselm R Garbe wrote:
It is pretty easy. Use the toolchain as is and copy some glibc based
.so's for x86_64 to /crap/lib on the stali target as well.
But it will not be statically linked then, as OP asked for.
Hi Bruno,
On 3 October 2016 at 20:30, Bruno Vetter wrote:
>
> I would like to experiment with stali and install built-from-source
> applications on top of the base installation. For this I need a musl based
> toolchain not for cross-compiling, but as part of my stali system. Can
> someone give
Bruno Vetter wrote:
building several applications like this on a host works fine. But how
do I get a statically-linked native toolchain for my target system?
The cloned toolchain from git is all dynamic.
You will need to build your own toolchain then. I actually don't
understand why you need a
Bruno Vetter wrote:
Can someone give me some hints on how to achieve this?
Hi,
All you have to do is (at least how I've once tried it):
1. Create a directory for your build.
2. cd to it.
3. clone toolchain and src from Git.
4. cd src
5. Clone the kernel
6. export STALISRC=/path/to/$builddir/s
Anselm R Garbe wrote:
Please update and let me know if it works now. I removed the
Makefile-dependency here. Only remaining place is sys and ncurses.
It installs now successfully.
On 18 April 2016 at 11:33, Mitt Green wrote:
> Anselm R Garbe wrote:
>
>> No, can you provide full logs of your last command, just want to see
>> how it looks and where it might fail.
>
>
> Here you are.
Thanks, now I understood what caused this for you.
Please update and let me know if it works
Anselm R Garbe wrote:
No, can you provide full logs of your last command, just want to see
how it looks and where it might fail.
Here you are.make[1]: Entering directory '/home/mitt/stalibuild/src/etc'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/mitt/stalibuild/src
Hi,
On 18 April 2016 at 11:11, Mitt Green wrote:
>> I can't reproduce your issue. I renamed src into src2 and performed a
>> clean build and make install, no such issue.
>
> I can't help but it ran into the same thing again.
> Let me describe my process then:
> 1) mkdir stalibuild in my home
> 2)
Anselm R Garbe wrote:
I can't reproduce your issue. I renamed src into src2 and performed a
clean build and make install, no such issue.
I can't help but it ran into the same thing again.
Let me describe my process then:
1) mkdir stalibuild in my home
2) cd stalibuild
3) cloning toolchain and
Anselm R Garbe wrote:
Also make sure you are at least using:
http://git.sta.li/src/commit/?id=acbd9df7cbdc6a949c962ca887fb5f8d799c3bfa
No, wait, I looked at mine, it has $(ROOT) too. Alright,
anyway, better be rebuilding the whole world.
Anselm R Garbe wrote:
[...]
Also make sure you are at least using:
http://git.sta.li/src/commit/?id=acbd9df7cbdc6a949c962ca887fb5f8d799c3bfa
Oh, that's the case. Strange, I pulled the entire tree
just yesterday. And also tried replacing
/home/anselm/src with $(ROOT) but it skipped the $(ROOT)
On 18 April 2016 at 09:49, Mitt Green wrote:
> Anselm R Garbe wrote:
>
>> So you are talking about src/bin/kbd/Makefile or NOT?
>
>
> Yes, this one.
>
>> Yes, but why do you run make install in src/bin/kbd? You should run
>> make -f stali.mk install
>
>
> Sorry, I read it wrong and ran "make -f st
Anselm R Garbe wrote:
So you are talking about src/bin/kbd/Makefile or NOT?
Yes, this one.
Yes, but why do you run make install in src/bin/kbd? You should run
make -f stali.mk install
Sorry, I read it wrong and ran "make -f stali.mk" in src/bin/kbd.
So, I ran "make -f stali.mk install" in
On 18 April 2016 at 09:32, Mitt Green wrote:
> Anselm R Garbe wrote:
>> Which Makefile are you talking about? src/bin/kbd/Makefile should not
>> be considered, only stali.mk.
> I'm talking about this Makefile, because...
So you are talking about src/bin/kbd/Makefile or NOT?
> No errors, which is
Anselm R Garbe wrote:
Hi there,
Hi,
Which Makefile are you talking about? src/bin/kbd/Makefile should not
be considered, only stali.mk.
I'm talking about this Makefile, because...
Can you provide the output of cd src/bin/kbd && make -f stali.mk
install please?
No errors, which is not s
Hi there,
On 17 April 2016 at 17:10, Mitt Green wrote:
> I'm trying to build stali, running "make install"
> goes fine except for kbd; it entres src/bin/kbd,
> then goes
> "CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
> /home/anselm/src/bin/kbd/config/missing --run aclocal-1.11 -I m4"
> and th
Marc Collin wrote:
Good idea?
for i in *; do sed -i 's/anselm/$USER/g' "$i"; done
I've tried replacing with "$(ROOT)/../" and
"$USER", with the first it simply skips $(ROOT)
and starts with /../, with the second one
it skips $U and starts with SER; e.g.:
ACLOCAL = ${SHELL} /home/$USER/src/bin
Double check for rm commands. :)
> On Apr 17, 2016, at 11:30 AM, Marc Collin wrote:
>
> Good idea?
> for i in *; do sed -i 's/anselm/$USER/g' "$i"; done
>
>
>> On Sun, Apr 17, 2016 at 2:12 PM, Mitt Green wrote:
>> I also found hardcode references to Anselm's
>> home folder in other Makefiles,
Good idea?
for i in *; do sed -i 's/anselm/$USER/g' "$i"; done
On Sun, Apr 17, 2016 at 2:12 PM, Mitt Green wrote:
> I also found hardcode references to Anselm's
> home folder in other Makefiles, apart from kbd:
> curl, parted, gzip, libarchive.
>
> There is yet no mksh in /bin (install
> destina
I also found hardcode references to Anselm's
home folder in other Makefiles, apart from kbd:
curl, parted, gzip, libarchive.
There is yet no mksh in /bin (install
destination).
Marc Collin wrote:
It seems to hardcode the user's home path to /home/anselm and the
problem can be you have anther username?
http://git.sta.li/src/tree/bin/kbd/Makefile#n146
I have another username (mitt, obviously :) )
and when I saw it, I though that this is from
one of stali.mk's but could
It seems to hardcode the user's home path to /home/anselm and the
problem can be you have anther username?
http://git.sta.li/src/tree/bin/kbd/Makefile#n146
I also find it weird that it reports ZSH and BASH as those software
are really awful and sucks a lot.
HTH.
On Sun, Apr 17, 2016 at 12:10 PM, M
On 5 October 2015 at 11:14, Dimitris Papastamos wrote:
> On Mon, Oct 05, 2015 at 11:02:13AM +0200, Roberto E. Vargas Caballero wrote:
>> >
>> > > - am I correct in thinking that we install manual pages, but currently
>> > > no 'man' program to read them?
>> >
>> > I'd propose using the OpenBSD ma
On Mon, Oct 05, 2015 at 11:02:13AM +0200, Roberto E. Vargas Caballero wrote:
> >
> > > - am I correct in thinking that we install manual pages, but currently no
> > > 'man' program to read them?
> >
> > I'd propose using the OpenBSD man tools.
> >
>
> I propose to use neatroff, that is a new i
>
> > - am I correct in thinking that we install manual pages, but currently no
> > 'man' program to read them?
>
> I'd propose using the OpenBSD man tools.
>
I propose to use neatroff, that is a new implementation from scratch of
the full troff toolchain. I know that the main use of troff tod
From: Dimitris Papastamos
> > This is a fun distribution - thanks for writing it, R.> It is not ready yet!
I know - but it is still fun...
On Sun, Oct 04, 2015 at 01:00:36PM -0300, Marc Collin wrote:
> On Thu, Sep 24, 2015 at 11:29 PM, Pickfire wrote:
> > Is there a package manager for suckless [...] ?
>
>
>
> Well maybe you could use apk[1]?
> Looks suckless to me.
There are no plans to have a package manager.
On Thu, Sep 24, 2015 at 11:29 PM, Pickfire wrote:
> Is there a package manager for suckless [...] ?
Well maybe you could use apk[1]?
Looks suckless to me.
[1] http://git.alpinelinux.org/cgit/apk-tools/tree/
On Fri, Oct 02, 2015 at 02:21:57PM +, Richard wrote:
> Actually, having set my expectations very low, I am finding that it works
> surprisingly well. Having played and poked around in the OS for a few hours
> this has lead to yet more questions:
>
> - do we install a pager? I've look in bin
On 10/02/2015 10:21 AM, Richard wrote:
- do we install a pager? I've look in bin for more/less/pg etc. Are
there any plans for a pager? I looked in the TODO documents for both
sbase and ubase but did not notice any.
I am also curious about the pager.
On Fri, Oct 02, 2015 at 04:29:09PM +0200, FRIGN wrote:
> On Fri, 2 Oct 2015 14:21:57 + (UTC)
> Richard wrote:
>
> Hey Richard,
>
> > - looking further ahead; has there been any thoughts towards a
> > staticallylinked/musl-based X11 server? Is it feasible to simply take
> > the xorg sources a
On Fri, 2 Oct 2015 14:21:57 + (UTC)
Richard wrote:
Hey Richard,
> - looking further ahead; has there been any thoughts towards a
> staticallylinked/musl-based X11 server? Is it feasible to simply take
> the xorg sources and compile those with static linking or does that
> not work (or would
- Original Message -
> From: Dimitris Papastamos
> As it stands, there is a lot of work to be done on stali. Do not
> expect it to just work. If you want to help, then send some patches
> to hackers@ for consideration.
Actually, having set my expectations very low, I am finding that i
On Fri, Sep 25, 2015 at 08:45:05AM +, Richard wrote:
> Ah, great thanks. So I was half right: if you follow the instructions on
>
> http://sta.li/installation
>
>
> git clone http://git.sta.li/rootfs-x86_64
>
> you will end up with no /etc directory. But the directory is still needed in
>
Hi Richard,
On 25 September 2015 at 10:45, Richard wrote:
> Ah, great thanks. So I was half right: if you follow the instructions on
>
> http://sta.li/installation
>
>
> git clone http://git.sta.li/rootfs-x86_64
>
> you will end up with no /etc directory. But the directory is still needed in
> t
-
From: FRIGN
To: dev@suckless.org
Cc: Richard
Sent: Friday, 25 September 2015, 9:25
Subject: Re: [dev] Stali RC
On Fri, 25 Sep 2015 08:14:34 + (UTC)
Richard wrote:
> So, at the risk of failing another sanity test, why does the /etc
> directory not show up on the git tree listing? Is
On Fri, 25 Sep 2015 08:14:34 + (UTC)
Richard wrote:
> So, at the risk of failing another sanity test, why does the /etc
> directory not show up on the git tree listing? Is that a git quirk?
> http://git.sta.li/rootfs-x86_64/tree/
Check out the src-repo[0], it includes another set of folders
Subject: Re: [dev] Stali RC
On Thu, 24 Sep 2015 18:32:53 + (UTC)
Richard wrote:
Hey Richard,
> ... I just wanted a quick sanity check:
I'm sorry to tell you, but you haven't passed the test.
> - Am I right in assuming that stali does not include a /etc directory (and
>
On 25 September 2015 at 09:10, Pickfire wrote:
> Can I use sta.li on ARM architecture such as Raspberry Pi?
ARMv8 (64bit) will be a future target for stali, there is no
rootfs-armv8 available yet. Also note, that according to my info Pi is
currently limited to armv7 (32 bit) -- which is currently
pickfire, you can clearly not read:
Target x86_64 support only (arm64 support might be added later)
On 9/25/15, Pickfire wrote:
> Can I use sta.li on ARM architecture such as Raspberry Pi?
>
> --
> _
> < Do what you like, like what you do. >
> --
Can I use sta.li on ARM architecture such as Raspberry Pi?
--
_
< Do what you like, like what you do. >
-
\ ^__^
\ (oo)\___
(__)\ )\/\
||w |
|| ||
On 25 September 2015 at 04:29, Pickfire wrote:
> Is there a package manager for suckless or do you need to install
> everything by source?
I explained on http://sta.li in the goals section
* "Upgrade/install using git, no package manager needed"
Of course this goal is not fully achieved yet, bu
suckless is about feeling the pain of the bad code and the broken make
system first hand to drive shitty code off the nerd market.
Is there a package manager for suckless or do you need to install
everything by source?
--
_
< Do what you like, like what you do. >
-
\ ^__^
\ (oo)\___
(__)\ )\/\
||w
or not, like me.
wrote:
>Richard wrote:
>
>Hey Richard,
Hello, Richard,
>
>> ... I just wanted a quick sanity check:
>
>I'm sorry to tell you, but you haven't passed the test.
>
First of all, welcome to suckless. You won't need sanity here. It has long been
forgotten, at the benefit of feedback straightforwardn
On Thu, 24 Sep 2015 18:32:53 + (UTC)
Richard wrote:
Hey Richard,
> ... I just wanted a quick sanity check:
I'm sorry to tell you, but you haven't passed the test.
> - Am I right in assuming that stali does not include a /etc directory (and
> therefore does not include prebuilt rc scripts)
Applied, thanks Evan!
On Wed, Oct 15, 2014 at 12:10:42PM +0100, Dimitris Papastamos wrote:
> On Wed, Oct 15, 2014 at 12:29:13AM -0500, M Farkas-Dyck wrote:
> > I'm not sure, but some in this community are hacking morpheus [1],
> > which is much alike.
> >
> > [1] http://morpheus.2f30.org/
>
> The project is currently
Hello,
On Thu, Oct 16, 2014 at 2:16 AM, Dimitris Papastamos wrote:
> I kind of like this particular implementation of test(1). Are there any
> obvious deficiencies compared to the sbase implementation?
I haven't found any but that doesn't mean they aren't there.
> I will have a look at it in m
On Wed, Oct 15, 2014 at 01:24:26PM -0700, Evan Gates wrote:
> After looking at the sbase TODO I threw together test(1). As far as I
> can tell it's POSIX compliant. I used the POSIX description[0] to
> write it. It exits 0 for true, 1 for false, and 2 for bad input. Let
> me know what's good and wh
On Wed, Oct 15, 2014 at 10:55:24AM -0700, Kartik Agaram wrote:
> I've cloned all the repositories enumerated in
> http://morpheus.2f30.org and I could build sbase and ubase. What order
> should I build the rest in, to get to mk?
You can grab mk from 9base or so.
On Wed, Oct 15, 2014 at 10:55:24AM -0700, Kartik Agaram wrote:
> I've cloned all the repositories enumerated in
> http://morpheus.2f30.org and I could build sbase and ubase. What order
> should I build the rest in, to get to mk?
Clone morpheus and follow the README. We have a ports tree with
a fe
After looking at the sbase TODO I threw together test(1). As far as I
can tell it's POSIX compliant. I used the POSIX description[0] to
write it. It exits 0 for true, 1 for false, and 2 for bad input. Let
me know what's good and what's bad. I'll work on addresing those
concerns and getting it into
Quoth Kartik Agaram:
> But I don't know how to run ls:
>
> $ ls
> usage: ls [-1adFilrtU] [FILE...]
I'd guess you're using a shell that has ls aliased to 'ls --color'
or similar.
> Your ls is aliased in your shell startup scripts.
> Unset it or execute the program directly.
Ack, you're right.
On Wed, 15 Oct 2014 10:53:50 -0700
Kartik Agaram wrote:
> Is this expected? (I can try to debug if not.)
This doesn't happen for me. In sbase/, running
./ls works as expected, listing the files in
the current directory line-per-line.
Cheers
FRIGN
--
FRIGN
On Wed, Oct 15, 2014 at 10:53:50AM -0700, Kartik Agaram wrote:
> I just got sbase cloned and built without trouble. Awesome!
>
> But I don't know how to run ls:
>
> $ ls
> usage: ls [-1adFilrtU] [FILE...]
> $ ls .
> usage: ls [-1adFilrtU] [FILE...]
> $ ls -d .
> usage: ls [-1adFilrtU] [FILE...]
>
I've cloned all the repositories enumerated in
http://morpheus.2f30.org and I could build sbase and ubase. What order
should I build the rest in, to get to mk?
I just got sbase cloned and built without trouble. Awesome!
But I don't know how to run ls:
$ ls
usage: ls [-1adFilrtU] [FILE...]
$ ls .
usage: ls [-1adFilrtU] [FILE...]
$ ls -d .
usage: ls [-1adFilrtU] [FILE...]
$ ls *
usage: ls [-1adFilrtU] [FILE...]
$ ls -l
usage: ls [-1adFilrtU] [FILE...]
$ l
On Wed, 15 Oct 2014 15:46:00 +0200
Markus Teich wrote:
> could you perhaps assemble a list of needed tools/options in s/u-base?
http://git.suckless.org/sbase/tree/TODO
http://git.suckless.org/ubase/tree/TODO
Cheers
FRIGN
--
FRIGN
Dimitris Papastamos wrote:
> The most limiting factor is the lack of tools and options in sbase and ubase.
Heyho,
could you perhaps assemble a list of needed tools/options in s/u-base?
--Markus
On Wed, Oct 15, 2014 at 12:29:13AM -0500, M Farkas-Dyck wrote:
> I'm not sure, but some in this community are hacking morpheus [1],
> which is much alike.
>
> [1] http://morpheus.2f30.org/
The project is currently losing traction because we lack the manpower
to implement what is required. This i
I'm not sure, but some in this community are hacking morpheus [1],
which is much alike.
[1] http://morpheus.2f30.org/
On Mon, Dec 30, 2013 at 11:39:21AM +0100, Martin Kopta wrote:
> So, any tips for article about Stali for (one of the) most read [8] Czech IT
> portal?
Since all current work on sta.li is in pieces and various places, I'd
expand a bit on what's on http://git.sta.li - you can for example show some
c
On Mon 30 Dec 2013 at 02:13:09 PST FRIGN wrote:
We want to create a system you can do anything with, which allows you
to work on integral components, fine-tune settings, remove shit you
don't need and set up stuff by yourself.
It should be intuitional for the experienced user, but also relativel
On Mon, 30 Dec 2013 11:39:21 +0100
Martin Kopta wrote:
Hey Martin,
it's been a pleasure to help you out with your talk and I'm glad to see
you could use my keypoints while preparing it!
> But since this is article and I have so much more space and since Stali
> advanced in the meantime, I guess
Am 8/30/13 12:24 PM, schrieb sin:
Just started to pull them in at
http://git.sta.li
Best regards,
Anselm
You might also be interested in svc[1]. It is
used by stali-init.
[1] http://git.r-36.net/svc/
Thanks,
sin
Very cool!
Writing service scripts will definitely be one of the main task
> Just started to pull them in at
>
> http://git.sta.li
>
> Best regards,
> Anselm
You might also be interested in svc[1]. It is
used by stali-init.
[1] http://git.r-36.net/svc/
Thanks,
sin
On 30 August 2013 07:12, FRIGN wrote:
> What do you think of the idea to have a separate ml for stali?
I don't like that idea. dev@ is the right discussion place for the
forseeable future.
We had similar discussions in the past. One ml is sufficient.
Best regards,
Anselm
Am 8/30/13 7:44 AM, schrieb Anselm R Garbe:
Just started to pull them in at
http://git.sta.li
Best regards,
Anselm
Great!
This is going to be an awesome project!
What do you think of the idea to have a separate ml for stali?
On 29 August 2013 21:28, FRIGN wrote:
> Unfinished, but a great start!
>
> How do you like the idea we compile a list of repositories and then think
> about merging them into one (e.g., git.sta.li)?
>
> Currently, we compiled two external repos, but I'm sure there are more:
>
> http://git.r-36.net
Am 8/29/13 10:06 PM, schrieb sin:
On Thu, Aug 29, 2013 at 10:05:30PM +0300, sin wrote:
On Thu, Aug 29, 2013 at 09:26:12PM +0300, FRIGN wrote:
Am 8/29/13 9:15 PM, schrieb Anselm R Garbe:
On 29 August 2013 16:37, FRIGN wrote:
Am 8/29/13 4:58 PM, schrieb Andrew Mikhnevich:
I'm intresting in s
On Thu, Aug 29, 2013 at 10:05:30PM +0300, sin wrote:
> On Thu, Aug 29, 2013 at 09:26:12PM +0300, FRIGN wrote:
> > Am 8/29/13 9:15 PM, schrieb Anselm R Garbe:
> > >On 29 August 2013 16:37, FRIGN wrote:
> > >>Am 8/29/13 4:58 PM, schrieb Andrew Mikhnevich:
> > >>
> > >>>I'm intresting in stali so.
>
On Thu, Aug 29, 2013 at 09:26:12PM +0300, FRIGN wrote:
> Am 8/29/13 9:15 PM, schrieb Anselm R Garbe:
> >On 29 August 2013 16:37, FRIGN wrote:
> >>Am 8/29/13 4:58 PM, schrieb Andrew Mikhnevich:
> >>
> >>>I'm intresting in stali so.
> >>>In the conference(http://suckless.org/conference) was the perf
Am 8/29/13 9:15 PM, schrieb Anselm R Garbe:
On 29 August 2013 16:37, FRIGN wrote:
Am 8/29/13 4:58 PM, schrieb Andrew Mikhnevich:
I'm intresting in stali so.
In the conference(http://suckless.org/conference) was the performance of
this.
Presentation here http://suckless.org/slcon13.pdf
But no
1 - 100 of 140 matches
Mail list logo
