Re: [dev] JFS filesystem

[stephen Turner]

I am an amateur here and follow mostly to learn from you all, but I did like 
some of the ideas in btrfs. Being able to add ssd’s for “cache” with spinning 
disks for long term and the system manage moving the data between the two based 
on use, auto repairs during use, data checks and corrections, backups, etc. 
Granted these were features more for a server but maybe a file system could be 
developed where the standard is pc based features with a patch or add on pack 
for server level features?

I think you do something similar now for dwm? 

Sent from my iPhone

On Apr 21, 2019, at 8:40 AM, Daniel Cegiełka  wrote:

niedz., 21 kwi 2019 o 12:48 Igor Rubel  napisał(a):
> 
> Hello!
> 
> What do you think about union mounting and UnionFS in particular?

I really like this idea. This is the Plan 9's bind implementation. You
can mount many different sources in one directory. Imagine that your
login program also creates new namespaces for you. All programs are
clustered in one /bin, and all libs in one /lib... manuals in /man
etc.

But with or without unionfs, you still need a filesystem :) I would
like to have one scalable and light file system and it turns out to be
a challenge. In my opinion, JFS looks the most interesting (as a light
filesystem). It has some key gaps vs. ext4. On the other hand, it is
very consistent - there is only what should be and nothing more.

I wonder if I should not rewrite jfsutils (as it was done in sbase).
And that's why I'm asking here for feedback about what others think
about file systems and what their view is on JFS, as a universal file
system.

Thx,
Daniel

Re: [dev] Coding style: why /* */ and not //?

[stephen Turner]

The only issue I see with c99 code is that some of the compilers appear to be 
behind the times on c. Any reason why we wouldn’t want to use a newer c feature 
other than compatibility?

Thanks,
Stephen

On Jan 10, 2019, at 4:27 AM, David Demelier  wrote:

Le 27/12/2018 à 11:10, Silvan Jegen a écrit :
> The only downside of //-style comments that I can
> see is that they are only allowed since C99[0].

Yes, but C99 was released 20 years ago. Perhaps it's okay to use it nowadays :)

Regards,

-- 
David

Re: [dev] Make cleanup

[stephen Turner]

I do like the idea of the warning “this is not posix” or “this is a gnu’ism”.  
It would be cool to have a suggested changes as well to possibly encourage 
posix usage.

Do you know if there is a gnu make test to verify all features are included and 
working? I’m currently looking for a gmake test and flowchart, figured they 
would be very useful if they exist.

Thanks,
Stephen

Re: [dev] Make cleanup

[stephen Turner]

I was thinking of a cleaner gnu make. The code you guys have written while I am 
having a hard time reading it, has inspired me to attempt once more to learn C. 

I have always thought gnu was bloated but a significant improvement over 
windows. I got started when redhat was free (1999?) and about that time wanted 
to learn C but still a teen had no discipline for it. 

Now with systemdumb er systemd plus the core of Linux bloating from 75 meg to 
over 100 I find myself bailing ship on gnu. I’m also not happy with this legal 
foss mob organization either and would prefer to see open source stay as it 
was, in the hands of hackers and hobbyists. 

My day job is a Mac admin and I do love all the features in Mac but damn yet 
again talk about bloat! Still it’s far more stable at our office than pc. 

Anyways, I’m looking for a gnu replacement to aid in installing those bloated 
apps we don’t have an alternative for or decide to continue to use anyways. 
Also need it for the kernel. 

I would also like to see the Linux kernel get a sanity check but fat chance 
with that one!

Thanks,
Stephen

On Dec 30, 2018, at 12:30 PM, ra...@airmail.cc wrote:

> On 2018-12-30 01:32, stephen Turner wrote:
> If one was going to rewrite a cleaner make what would be the
> recommended approach?
> I see in a slightly older 2012 release of the code entries for windows
> 32 and amiga. I’m questioning why!
> Would it be worth while to strip make of these items and then attempt
> to clean the code section by section? Diff a legacy and perhaps gnu
> exclusive version against a newer release, or perhaps another
> approach?
> In the past I have learned coding by jumping into an existing item and
> rewriting, not sure if this is a task I will take on but the thought
> has crossed my mind.
> I am not skilled enough to start from scratch and make is just too
> bloated as is to try and tackle for me, I’m thinking perhaps removing
> these legacy items and going from there?
> Thanks,
> Stephen

Dear Stephen,

Are you wanting to have a clean reimplementation of POSIX make or a new 
(simpler) build system to replace make itself? Having thought about it my 
opinions is that the second option is a better one.

If you agree consider joining forces with me on building makes 
<https://github.com/rain-1/makes> a replacement for make. I have some initial 
work here which supports incremental and parallel builds. I'd be interested to 
hear you opinions on it.

You'll notice that it is ~200 lines while make is 39643 lines, I think that 
this demonstrates some potential of the idea 
<https://softwarecrisis.miraheze.org/wiki/Linecount#build_system>.

- rain

[dev] Make cleanup

[stephen Turner]

If one was going to rewrite a cleaner make what would be the recommended 
approach?

I see in a slightly older 2012 release of the code entries for windows 32 and 
amiga. I’m questioning why!

Would it be worth while to strip make of these items and then attempt to clean 
the code section by section? Diff a legacy and perhaps gnu exclusive version 
against a newer release, or perhaps another approach?

In the past I have learned coding by jumping into an existing item and 
rewriting, not sure if this is a task I will take on but the thought has 
crossed my mind.

I am not skilled enough to start from scratch and make is just too bloated as 
is to try and tackle for me, I’m thinking perhaps removing these legacy items 
and going from there?

Thanks,
Stephen

Re: [dev] Yet another "sane alternatives" thread

[stephen Turner]

> On Dec 27, 2018, at 12:36 AM, Martin Tournoij  wrote:

> I am disappointed to see that clang compilation speeds are a lot slower
> than what they used to be. The disadvantage of tcc is that it does
> almost no optimisations, so even simple programs will run slower. My
> solution is to use tcc as the default, and gcc when installing stuff.
> 

After hearing you guys use tcc I went back on a hunt and found the live branch, 
it is fast! 

I see it’s more active than pcc on development which is good but optimizations 
would be great just to replace gcc on a more perm basis. How suckles is adding 
optimizations to tcc? Would that turn it into a mess like gcc or is it 
something that either hasn’t been a priority yet or isn’t within the scope of 
the project?

Thinking out loud here but most things can be scripted, perhaps even a makefile 
conversion to avoid make? A conversion would be even better for someone who 
maintains their own distro since packages could be converted in advance and not 
need to run the script at compile time.

Altho some packages are fairly complex, a conversion script likely wouldn’t be 
a simple task but I would imagine still simpler than a new make and an 
investment in moving away from it. 

~Stephen

Re: [dev] Yet another "sane alternatives" thread

[stephen Turner]

> On Dec 25, 2018, at 12:22 PM, Sean MacLennan  wrote:
> 
> On Tue, 25 Dec 2018 08:16:47 -0600
> Cág  wrote:
> 
>> I'm thinking of something you can compile the Linux kernel[0] with.
> 
> The Linux kernel only compiles with the GNU toolchain. There are
> efforts to get it compiling with clang but I believe they are not there
> yet.
> 
> The Linux kernel is portability because the GNU toolchain is portable.
> 

Bad terminology on my part when I said portable I mean small, light, runs off 
cdrom/usb/virtual machine and is always a clean environment (or aims to be).

I know Rob was using LFS build scripts to test his little project and it was 
mostly intended as a busybox replacement that I think they decided to push a 
bit further. 

Now my curiosity is going, guess I will head over and see what’s up.


> Cheers,
>   Sean
> 

Re: [dev] Yet another "sane alternatives" thread

[stephen Turner]

> On Dec 25, 2018, at 9:16 AM, Cág  wrote:
> 
> Jan Bessai wrote:
>> Not sure if it has any advantages for you, but you might try bmake
>> https://apps.fedoraproject.org/packages/bmake
>> It is a port of the Netbsd make.
> 
> bmake has its own conditionals like .if,  .ifdef,  .else,  etc.,  i.e.
> it is itself incompatible with GNU make. I'm thinking of something
> you can compile the Linux kernel[0] with. Ever noticed how some
> developers include a Makefile and a GNUmakefile?*
> 
> pkgsrc is an example. You can't use GNU make with it, and it ships with
> bmake -- unless it's NetBSD, whose bmake is just make(1).
> 
> 
> * - instead of writing portable Makefiles
> 
> [0]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Makefile
> 
> --
> caóc
> 

Toybox?
I haven’t followed the project in a bit, I really should check in and see what 
they have finished but I know that project aimed to get most if not all of a 
build environment recreated in a portable form so if you haven’t seen it then I 
recommend it. 

If I may ask, why do you disapprove of make? I would like to see it redone but 
curious your reasons. 


> 

Re: [dev] Some core tools

[stephen Turner]

>From a user perspective it has been a treat. I had issues with the GNU
M4 compiling on a embedded musl and PCC system but this M4 compiled
quick and clean. The only potential downside i can think of is it may
not be well maintained. last i checked the website there were no new
releases from when we tweaked the make file. There is another project
called elftoolchain which replaces binutils but i haven't tested it
yet.

On Tue, Feb 7, 2017 at 5:22 PM, Mattias Andrée <maand...@kth.se> wrote:
> It looks pretty good, maybe we should recommend it as an
> external component.
>
> On Tue, 7 Feb 2017 09:43:42 -0500
> stephen Turner <stephen.n.tur...@gmail.com> wrote:
>
>> I think this was blocked by the mailing list, sorry if
>> its a duplicate. I wanted to mention that there is a m4
>> converted from a bsd rewrite of m4 into a more Linux
>> compatible version, he advised it had all the popularly
>> used features but may be missing a few of the lesser
>> used. I for one have used it for a while with pcc and
>> haven't seen issues related to m4. Perhaps this would be
>> a helpful starting point for you.
>>
>>  http://haddonthethird.net/m4/
>>
>> On Mon, Feb 6, 2017 at 9:31 AM, stephen Turner
>> <stephen.n.tur...@gmail.com> wrote:
>> > As far as m4 is concerned I happened to meet a guy who
>> > converted a bsd rewrite of m4 into a more Linux
>> > compatible version, he advised it had all the popularly
>> > used features but may be missing a few of the lesser
>> > used. I for one have used it for a while with pcc and
>> > haven't seen issues related to m4. Perhaps this would
>> > be a helpful starting point for you.
>> >
>> > http://haddonthethird.net/m4/
>> >
>> >
>> > On Friday, February 3, 2017,
>> > <sylvain.bertr...@gmail.com> wrote:
>> >>
>> >> On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias
>> >> Andrée wrote:
>> >> > I'm work on implementing make(1)
>> >>
>> >> In theory, linux kbuild should be a good reference for
>> >> the minimum set of makefile extensions to code. Well,
>> >> in theory, the guys paid full-time at the
>> >> linux fondation to work on kbuild, should have
>> >> constraint themselves to use the
>> >> bare minimum of makefile extensions, and be honest
>> >> about it (they aren't, be
>> >> carefull). suckless: better have a bit more roughness
>> >> in the makefile than depends on super duper makefile
>> >> extensions... which would make coding an alternative
>> >> to make something crazy or insane. It's like C, the
>> >> bare minimum of extensions would be those required to
>> >> compile a kernel like linux (a good part of C89 syntax
>> >> is already to much, hence
>> >> even more with C99), but the gcc inline assembly is
>> >> critical. The "right" answer would be to abstract away
>> >> what's really needed (minimal) from a C toolchain for
>> >> a reasonable linux build (even clang/llvm people
>> >> failed).
>> >>
>> >> --
>> >> Sylvain
>> >>
>> >
>>
>

Re: [dev] Some core tools

[stephen Turner]

I think this was blocked by the mailing list, sorry if its a
duplicate. I wanted to mention that there is a m4 converted from a bsd
 rewrite of m4 into a more Linux compatible version, he advised it had all
 the popularly used features but may be missing a few of the lesser used. I
 for one have used it for a while with pcc and haven't seen issues related
 to m4. Perhaps this would be a helpful starting point for you.

 http://haddonthethird.net/m4/

On Mon, Feb 6, 2017 at 9:31 AM, stephen Turner
<stephen.n.tur...@gmail.com> wrote:
> As far as m4 is concerned I happened to meet a guy who converted a bsd
> rewrite of m4 into a more Linux compatible version, he advised it had all
> the popularly used features but may be missing a few of the lesser used. I
> for one have used it for a while with pcc and haven't seen issues related to
> m4. Perhaps this would be a helpful starting point for you.
>
> http://haddonthethird.net/m4/
>
>
> On Friday, February 3, 2017, <sylvain.bertr...@gmail.com> wrote:
>>
>> On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias Andrée wrote:
>> > I'm work on implementing make(1)
>>
>> In theory, linux kbuild should be a good reference for the minimum set of
>> makefile extensions to code. Well, in theory, the guys paid full-time at
>> the
>> linux fondation to work on kbuild, should have constraint themselves to
>> use the
>> bare minimum of makefile extensions, and be honest about it (they aren't,
>> be
>> carefull). suckless: better have a bit more roughness in the makefile than
>> depends on super duper makefile extensions... which would make coding an
>> alternative to make something crazy or insane.
>> It's like C, the bare minimum of extensions would be those required to
>> compile
>> a kernel like linux (a good part of C89 syntax is already to much,
>> hence
>> even more with C99), but the gcc inline assembly is critical. The "right"
>> answer would be to abstract away what's really needed (minimal) from a C
>> toolchain for a reasonable linux build (even clang/llvm people failed).
>>
>> --
>> Sylvain
>>
>

Re: [dev] Collecting sins of Apple

[stephen Turner]

while my mac experience is limited to only 1 year, i can say that
sticking to mavericks (10.9.5) and el capitan (10.11.6) have been
exceptionally stable. Some antivirus programs such as mcafee have been
known to corrupt files on the mac as was our issue previously but have
since switched to a dedicated mac AV and no further issues have
occurred. I think the point that could have been missed here is that
IBM is not only using mac, they are also using JAMF a SCCM management
suite for the mac. It is very powerful in its ability to automate
deployments, set up "zero config", and essentially eliminate for the
most part the typical setup and maintenance of windows systems. One
can still achieve better with Linux but in the commercial markets
Jamf+Mac is better than the windows solutions. As with any deployments
and software you never want to be on the bleeding edge either unless
you like death by a thousand cuts. we have only recently updated to
10.11.6 and will wait for Sierra (just released) until were confident
it too has matured.

With jamf its simple to deploy the latest software, set up one policy
to download the package, then later after it has been downloaded a
separate workflow to trigger the install. Jamf is able to update
systems not on the company network which in my experience i have not
seen from windows and SCCM but thats not to say it could not be set up
for them as well.

With a special program (name eludes me at the moment) the company macs
can be forced to call home from anywhere in the world and if wiped
they can be reimaged remotely! pretty nifty.

Apple has a lot of issues, but the Mac+JAMF combo is powerful enough
that i believe IBM really is saving $500 a person, if apple wasn't so
expensive it would easily grow its base rapidly. But again its not
perfect, just better than windows.

On Tue, Oct 25, 2016 at 8:00 AM, Anselm R Garbe  wrote:
> On 25 October 2016 at 13:34, Laslo Hunhold  wrote:
>> what are the really compelling reasons for a Mac user to make the
>> switch to Linux/BSD? How can we convince people to make the switch?
>
> The only reason for an experienced Mac user doing the switch is,
> because he wants to gain more control over his hardware (and
> software). I would consider this is a natural desire when reaching a
> certain level of competence with IT technology.
> Some people are lazy and cope with the environment they are used to.
> Some are willing to progress the edge further and will then drop the
> straightjacket. Some will never learn.
>
> Cheers,
> Anselm
>

Re: [dev] [stali] The stali way to wifi

[stephen Turner]

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 there a README somewhere that
lists the differences from daemon-tools?

I mentioned it before but its worth repeating, I am excited about the
work you guys do here and can't wait to have a new base system running
it! Thank you.

On Wed, Oct 19, 2016 at 7:20 AM, Anselm R Garbe  wrote:
> 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 included. WPA(2) is not supported by default.
> It's on the adoption list already.
>
> Cheers,
> Anselm
>

Re: [dev] app locations?

[stephen Turner]

I had no intention of starting a debate, just wanted a little
direction on where to place these few applications appropriate to
legacy linux/bsd. I understand its not the common view of the members
here, and I'm definitely not trying to say one way is more correct
than the other. Sta.Li has its place and I'm sure will find a solid
user base with users who agree with the file system hierarchy and
other good features. Its by personal preference alone that i choose to
stick with the legacy layout but admire the work that was done for
suckless and wish to incorporate it.

On Mon, Oct 17, 2016 at 12:29 PM, Kamil Cholewiński  wrote:
> On Mon, 17 Oct 2016, Dimitris Papastamos  wrote:
>> everything in /bin
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>

[dev] app locations?

[stephen Turner]

So i have determined the locations of most of sbase and ubase using
the linux FHS [0]. I have a few that needs categories for the legacy
style linux and was hoping someone would have a few pointers. I
offered my thoughts based on the FHS description of the directories,
correct me if I'm wrong. Thanks for any help or pointers.

/usr/sbin/
fallocate
lastlog
fsfreeze
vtallow
respawn
swaplabel
unshare

/usr/bin
truncate
sponge


[0] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

Re: [dev] sbase installed first impressions

[stephen Turner]

Thanks Alex. I have followed landley as well and he is pretty sharp
especially on history. He does make a valid point that we really don't
need the file system laid out the way it is, and i can see why people
would like to have it set up more simply like stali. I myself was
tempted with the simplicity but it just doesn't feel right to me.

One thought does occur to me, I have been quoted posix in this thread
for reasons why features are not included and yet this isn't posix.
That being said, i wouldn't mind trying to help add something such as
a script for example to provide an option for the traditional layout
for those who opt for it. The question would be the implementation
method. Perhaps taking a play from "make suckless-box-install" and
calling it "make traditional-install" or such. I will inevitably
script something out for myself if this isn't available so i don't see
any reason not to contribute unless its considered out of scope for
the project.

On Tue, Oct 4, 2016 at 5:48 PM, Alexander Keller  wrote:
> The stali filesystem is explained by:
> http://sta.li/filesystem
>
> If you want to know why Suckless chose to fix it:
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>

Re: [dev] sbase installed first impressions

[stephen Turner]

Thanks for all the great feedback!

I installed sbase and ubase but it doesn't appear that suckless
assigns them to the proper directories e.g. /bin /sbin, /usr/bin,
/usr/sbin however everything is placed into /usr/local/bin. I assume
there was a thought or reason? Perhaps leaving it open for choice? I
was reading this site on posix directory structure[0] and not all the
programs belong to any one directory but it doesn't get specific on
which programs belong where lending itself to more of a judgement call
i suppose. Would you consider this a good reference or is there better
reading material for this? Sorry if i ask some odd questions, It seems
the posix way is cleaner and proper than gnu and I'm trying to stick
to it.

Side note: The readme for ubase doesn't list pcc as a known good
compiler but it appears to have done the job.

[0] http://www.linux4beginners.info/linux-how-to/directory-structure-posix/

Re: [dev] sbase installed first impressions

[stephen Turner]

Thanks for the links i will check it out! Also i wasn't aware of the
-F function, playing with it now and that is a big help with working
around the whole color bit. Clearly the / is for directories. How are
the rest used? Surprisingly even google doesn't know. From what i
could see they didn't label links and such so not very helpful in that
respect but at least i wont try to vi a directory or cd to a file.

On Mon, Oct 3, 2016 at 7:43 PM, Evan Gates <evan.ga...@gmail.com> wrote:
> On Mon, Oct 3, 2016 at 4:34 PM, stephen Turner
> <stephen.n.tur...@gmail.com> wrote:
>> @Evan
>> I am not too fluent at advanced shell at the moment so help me out
>> with this one please, I checked the advanced scripting guide but want
>> to make sure i understand this.
>
> Please do not read that, it's full of practices that are outdated and
> in many cases it is plane wrong. Instead check out the bash guide[0]
> and the accompanying bash faq[1] and bash pitfalls[2]. Although the
> wiki is bash specific it also covers POSIX sh very well.
>
>> s() { ls -F "$@" | cols; }
>> s() implies that you have created an alias for ls as "s" and the () is
>> to listen for what follows for the flags "-h etc"?
>
> It's a function definition.
>
>> {} is to encapsulate the real commands,
>
> The body of a function is a compound command, meaning it's one of:
> a list in braces
> a list in parens
> a loop (for, while until)
> an if statement (with following elif, else)
> a case statement
>
> That said most often you'll see braces.
>
>> ls -F "$@" the "$@" is to pass along the flags from s()?
>
> "$@" expands to the positional parameters (arguments) and must be
> quoted otherwise you can run into further word splitting and glob
> expansion (this is true for all expansions/substitutions).
>
>> and for the ; at the end of cols, i assume this terminates in a way
>> that prevents it from grabbing further input?
>
> A terminator is needed before the closing brace, both newline and
> semicolon are accepted.
>
> [0] http://mywiki.wooledge.org/BashGuide
> [1] http://mywiki.wooledge.org/BashFAQ
> [2] http://mywiki.wooledge.org/BashPitfalls
>

[dev] sbase installed first impressions

[stephen Turner]

Background first. I'm running a simple kernel, busybox, make, pcc,
musl, binutils (patched for ash) environment. Its run from ram so i
can trash the environment as many times as i care to reboot. That
being said I decided to install suckless in place allowing it to
overwrite the busybox links just for kicks. So far just sbase was
installed.

I had to tweak the config.mk (expected i assume?)
PREFIX=/
MANPREFIX=/usr/local/share/man (keeping with suckless default here,
removed variable)
CC=pcc
LDFLAGS= (removed -s as it was not supported)

It compiled and installed faster than expected but then the code was
smaller than expected too, very impressive size! Immediately i decided
to check and see if it overwrote the busybox links and it did but i
also noticed there is no color or column views? Reviewing the Readme
shows that color isn't listed as one of the removed features just fyi
unless it has a short hand from --color that i didn't know.

I have never had ls without color or column included (i'm spoiled) and
google isn't being overly helpful at the moment. I found the cols
command and ls | cols solved that so i can just create an alias, what
about getting color? Is there a suckless solution?

I see a few items have the -i removed, I can't say i use the
interactive mode but i assume you removed it due to redundancy and so
i'm curious how you would normally do that the suckless way.

Otherwise i haven't used it much but seems to be just as expected, a
gnu comparable cli. I need to update my scripts and then i will start
using this instead of busybox.

Re: [dev] Just discovered dwm

[stephen Turner]

On Wed, Sep 28, 2016 at 4:34 PM, Hannes Blut <cxb...@gmail.com> wrote:
> On 22.09.16 at 03:42pm, stephen Turner wrote:
>>
>> I liked the old debian floppy net install, 75 mb base cli only image.
>> apt get your way to happiness. It didn't fit with the suckless as they
>> did a lot to their system but it wasn't ubuntu. These days you can't
>> even install a Cli for less than 100+ mb. i really don't understand
>> what they are feeding these programs.
>
>
> The ubuntu netboot image has an initrd around 75mb...
>

While that may be true my understanding is that its still very bloated
and overrated and now they have systemd. I tried a bsd, and arch
linux, both needed frequent file system repairs. Debian tends to be
fairly stable but i haven't been happy with them in a while and can't
quite put my finger on any particular reason. Ubuntu has worked in the
past for a quick unix fix but not a system i would want to keep around
for the long haul.

At this point i am looking at sbase, ubase, sinit, linux kernel and a
few other necessary oddities for a full command line like maybe
libressl for https support. looking at some forums for the minimal
xorg install with dwm maybe and giving st a shot for a term.

what do you guys do for wget like functionality? opt for curl? I was a
little surprised you didnt have a sget or the like.

[dev] containers opinion

[stephen Turner]

whats the suckless view of containers and why? what about a
containerized init helper where sinit calls the container program and
then runs daemons and the rest of the system from containers? Do you
feel containers offer additional security/stability?

Just thinking about "cloud" stuff again and daydreaming about servers.

I suppose with a system as small as suckless offers it might be a moot
point by the time you fire up several VM instances. VM's would add a
semi redundancy in the event of a single failure in that it wouldn't
take down the other services but then you have other issues if the
system fails anyways right?!

just random thoughts.

thanks,
stephen

Re: [dev] Just discovered dwm

[stephen Turner]

I liked the old debian floppy net install, 75 mb base cli only image.
apt get your way to happiness. It didn't fit with the suckless as they
did a lot to their system but it wasn't ubuntu. These days you can't
even install a Cli for less than 100+ mb. i really don't understand
what they are feeding these programs.

On Thu, Sep 22, 2016 at 3:31 PM, hiro <23h...@gmail.com> wrote:
> then it's no better than ubuntu. i can deselect stuff there, too.
>

[dev] slackware custom build

[stephen Turner]

This is a bit off topic and i wanted to avoid thread jacking another
conversation.

I see people here are using slackware, i was considering a script
package management system that allows for easy modifications for a
"micro distribution" the idea was to not host any of the actual source
but do everything through scripts. I see slackware does host the
source tar balls but they have a script inside that facilitates the
install?

Re: [dev] several questions

[stephen Turner]

On Wed, Sep 21, 2016 at 3:02 AM, Ivan Tham <pickf...@riseup.net> wrote:
> Hi, Stephen.
>
> On Tue, Sep 20, 2016 at 04:32:18PM -0400, stephen Turner wrote:
>>
>> Bash and Make, I'm looking for compatible replacements for these. As i
>> currently understand it bash at the least is expected to compile the linux
>> kernel. Is there any suitable projects that you may have seen around the
>> net or considered a bash rewrite? I see you recommend mksh and dash but
>> neither have bashisms that some projects seem to expect.
>
>
> For me, I think bach it very much bloated. I would definitely agree that
> mksh or dash is a lot better. Well about rc, I wouldn't recommend that
> since it's a total different syntax compared to POSIX shell, although
> posix shell definitely have some weaknesses, it's still more portable.

I wouldn't mind using dash or similar but the kernel dependency for
bash is holding me back from removing bash entirely. Its not just the
kernel I'm sure but thats one that comes to mind.

>
> And about make, I would recommend make, I didn't check the source code
> for both make and mk but I did some benchmark back then, make is still
> the fastest build system that I have tested and it have a clean but
> weird syntax. But just beware of autotools and autoconf.
>
>> I love the site and the list of tools you have found to "suck less"
>> looking
>> great!
>
>
> Nice, hope you could help us out starting with some of the project
> ideas. http://suckless.org/project_ideas

I don't know C but if i find anything worth contributing i certainly will.

>
> --
> Do what you like, like what you do.  -- Pickfire
>

Re: [dev] several questions

[stephen Turner]

On Tue, Sep 20, 2016 at 4:44 PM, FRIGN <d...@frign.de> wrote:
> On Tue, 20 Sep 2016 16:32:18 -0400
> stephen Turner <stephen.n.tur...@gmail.com> wrote:
>
> Hey Stephen,
>
>> On your site i see you have tested compiling your system with PCC
>> and i also see a SCC in dev. What was the reason you chose to write
>> SCC? Is it due to PCC's reliance on lex, yacc and m4?
>
> The last PCC release (1.1.0) was in 2014. Of course, this does not mean
> much, but it does not receive any major attention as of late.
> Additionally, and I can't speak for Roberto here, the goals of scc go
> in a different direction. Stay tuned for Roberto's talk at slcon3.

They are not cutting regular releases but the CVS is getting updates.
They also have it time stamp every day with a tarball release so its
kinda hard to track when they actually do work if your not on the
mailing list.

>
>> Bash and Make, I'm looking for compatible replacements for these. As
>> i currently understand it bash at the least is expected to compile
>> the linux kernel. Is there any suitable projects that you may have
>> seen around the net or considered a bash rewrite? I see you recommend
>> mksh and dash but neither have bashisms that some projects seem to
>> expect.
>
> Just don't use bash, but the Posix shell. Use the "#!/bin/sh"shebang
> and test your scripts with shellcheck[0], which is also pretty reliable
> in detecting bashisms.
> Some people would recommend rc (by Plan9), but it's definitely not
> portable and most unixoid OSes offer it.
> For make: Some people recommend mk, I'd recommend just being aware of
> GNUisms for make and try to make it portable (it's not difficult).

I try to keep my scripts pretty generic as i tend to use them on
multiple platforms, linux and os x mostly. i also specify sh :)

>
>> I found libre linux where they clean out the "globs" and tiny linux
>> but i was wondering if there was a new linux kernel cleanup project
>> somewhere?
>
> I'm sure you mean "BLOBs", which are binary chunks of proprietary
> machine code. To be honest, I don't mind that running in my system,
> however, in the long run one should try to select hardware that is not
> requiring BLOBs in the first place (Broadcom is a sinner in this
> regard). All this "Libre" bullshit with projects to "clean up" the
> Linux kernel don't achieve anything beyond ideological satisfaction.
> Stop singing the false song of "Libre Software" and rather make smart
> decisions in life.
> If you end up configuring your Kernel yourself and remove everything
> you don't need in the first place (including all drivers with BLOBs),
> your compilate won't contain BLOBs as well.

I haven't used libre linux yet. Seems like a bit of a hassle honestly
but i like the idea. For me the appeal is just having everything in
code like it should be and being open for audit or improvement.

>
> With best regards
>
> FRIGN
>
> [0]: https://www.shellcheck.net/
>
> --
> FRIGN <d...@frign.de>
>

[dev] several questions

[stephen Turner]

Hi, its my first post so i hope I'm not on the wrong group here or being
 rude.

 On your site i see you have tested compiling your system with PCC and i
 also see a SCC in dev. What was the reason you chose to write SCC? Is it
 due to PCC's reliance on lex, yacc and m4?

 Bash and Make, I'm looking for compatible replacements for these. As i
 currently understand it bash at the least is expected to compile the linux
 kernel. Is there any suitable projects that you may have seen around the
 net or considered a bash rewrite? I see you recommend mksh and dash but
 neither have bashisms that some projects seem to expect.

 I found libre linux where they clean out the "globs" and tiny linux but i
 was wondering if there was a new linux kernel cleanup project somewhere?

 I love the site and the list of tools you have found to "suck less" looking
 great!

 Thanks,
 Stephen