Re: [dev] containers opinion

2016-09-23 Thread Anselm R Garbe 
On 23 September 2016 at 19:19, stephen Turner
 wrote:
> whats the suckless view of containers and why? what about a

Containers are an indicator of conceptual decay. Application developer
code has now become infrastructure and is due to the juniority far
away from any half-standardized protocols. In times with agile
software development, architects lost track of the _overall_ system
architecture. System daemons seem not to be enough anymore or too hard
for junior application developer people to base some services on. Also
it is hard to write a daemon in J2EE Java or nodejs...

Since application programmers started developing (system)
infrastructure you now need to put their dependency hell into some
manageable "containers" to keep your base server infrastructure
somehow manageable.

But the introduction of containers will not lead to a better
architecture, it is just the opener for uncaring developers to do
system programming in nodejs etc.

Remember what the introduction of all programming paradigms into C++ led to.

-Anselm

Re: [dev] containers opinion

2016-09-23 Thread hiro 
> Docker daemon is a single, statically
> linked binary.

that's irrelevant. you still need the right version of loonix with
namespaces support, etc.
containers are not independent of the operating system.

Re: [dev] containers opinion

2016-09-23 Thread Kamil Cholewiński 
On Fri, 23 Sep 2016, stephen Turner  wrote:
> 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?

Containers DO NOT add any security. Unsharing resources does. If you are
serious about security, proper privilege separation is the way to go.
But it requires thought and careful design, something chronically
missing in that whole the "move fast, break things" crowd.

Stability - no. Unstable and shitty code is going to stay unstable and
shitty, no matter how many layers you wrap it in. A Good operating
system will shield one application from misbehaviors of another,
**by default**.

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

Yes, this is where containers shine. The developer writes a Dockerfile,
builds and tests the image on his laptop, does it work? :shipit:

Then the sysop guy just clicks around on the GCP admin panel to spin up
a Kubernetes cluster, points it at the image, and viola, fuken deployed.

For me, as a sysop, the image/container workflow finally makes the pain
of deploying the unstable and shitty code to production bearable,
because it confines the unimaginably imaginative developers' inventions
into a conceptually simple and uniform package. Finally I only have to
deal with one kind of crap, as opposed to 20 different kinds of crap.

I welcome containers with ovations and fanfares.

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

Last time I checked, sta.li was shifting focus to the embedded space.
Maybe I'm too old for this job, but I just... don't run my production
workloads on a bag of potatoes.

Also... Face it. The reason why we have containers, is because most
applications are a stinking pile of crap, and we needed a way to confine
them into something manageable. If the people that wrote all of that
shitty code cared about being suckless, they'd have to harakiri.

Now once you have a container, it doesn't matter at all, which host OS
is it running under. On AWS, your cluster runs Amazon Linux, some sort
of bastardised CentOS knockoff. On GCP, your clusters run on Debian
Wheezy. (Yes, I WTF'd and LOL'd, but hey, if it works, it ain't broke.)
Is there any difference? No, the Docker daemon is a single, statically
linked binary.

<3,K.

Re: [dev] containers opinion

2016-09-23 Thread Ben Woolley 

> On Sep 23, 2016, at 12:18 PM, hiro <23h...@gmail.com> wrote:
> 
> containers are there to emulate static linking or the common portable
> windows programs in the form of a single .exe
> 
> there is no security benefit of running more people's software on your 
> computer.
> 

I am reminded of the fact that the main proponent of categorical imperatives 
never ventured far from his home.

Re: [dev] containers opinion

2016-09-23 Thread Daniel Abrecht 
I am new here. I am using devuan + libvirt + lxc containers. I think in
terms of security, it's less secure than a VM, since it shares the
kernel & resources with the host system. But I think it's easier to
backup & update containers. I like that I can just copy a container to
another computer, and only need to set it up once. Also, if I update one
container, it can't break the other containers. Also, each of my
Container contains devuan and has its own network interfaces, it's like
having many different and complete servers with own IPs, hostnames,
etc., but without many expensive computers or crazy amounts of ram for
VMs. However, I always have a physical second fallback & backup systems
if the first one fails, because a single computer is still a single
point of failure.

Since I use containers as if they where normal computers, I don't see
why I need to be able to control the services from the host system, I
just ssh to the container if I need to restart a service. I think if I
just want to isolate a single service, I would just use a simple chroot.
I don't think an container is much more secure than a chroot.

Am 23.09.2016 um 17:19 schrieb 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] containers opinion

2016-09-23 Thread hiro 
containers are there to emulate static linking or the common portable
windows programs in the form of a single .exe

there is no security benefit of running more people's software on your computer.

Re: [dev] containers opinion

2016-09-23 Thread Thomas Levine 
My personal view is that separate users are enough software separation
for everything that I have ever wanted to do. Dunno about the party line
though.

On Fri, Sep 23, 2016, at 05:19 PM, stephen Turner wrote:
> 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
>

[dev] containers opinion

2016-09-23 Thread 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] [ST] scroll patch build failure

2016-09-23 Thread Nick Warne 
On Fri, 23 Sep 2016 13:43:22 -0300
Draco Metallium(Rodrigo S. Cañibano)  wrote:

> My bad!

No way!

I just cloned st again, got the patch, applied, all builds now and
works OK.

Thanks,

Works a treat.

Nick

> I should have copy the line from the patch itself and not from my
> config.
> 
> On 23 September 2016 at 13:40, Nick Warne  wrote:
> > On Fri, 23 Sep 2016 17:36:21 +0100
> > Nick Warne  wrote:
> >  
> >> On Fri, 23 Sep 2016 13:32:14 -0300
> >> Draco Metallium(Rodrigo S. Cañibano)  wrote:
> >>  
> >> > > st.c:337:12: error: ‘histsize’ undeclared here (not in a
> >> > > function) Line hist[histsize]; /* history buffer */  
> >> >
> >> > In the scroll patch 'histsize' is added to config.def.h, and
> >> > therefore to config.h. Didn't that patch apply?
> >> >
> >> > Does your config.h have a line with "#define histsize 5000"?
> >> >  
> >>
> >> No, nor does:
> >>
> >> st-scrollback-20160727-308bfbf.diff
> >>
> >> I guess I don't suck ;)  
> >
> > Or maybe I do:
> >
> >  #define histsize 2000
> >
> > Ummm.  Let me start again.
> >
> > Nick
> > --
> > "Gosh that takes me back... or is it forward?  That's the trouble
> > with time travel, you never can tell."
> > -- Doctor Who "Androids of Tara"
> >  
> 



-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure

2016-09-23 Thread Rodrigo S. Cañibano 
My bad!

I should have copy the line from the patch itself and not from my config.

On 23 September 2016 at 13:40, Nick Warne  wrote:
> On Fri, 23 Sep 2016 17:36:21 +0100
> Nick Warne  wrote:
>
>> On Fri, 23 Sep 2016 13:32:14 -0300
>> Draco Metallium(Rodrigo S. Cañibano)  wrote:
>>
>> > > st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
>> > >   Line hist[histsize]; /* history buffer */
>> >
>> > In the scroll patch 'histsize' is added to config.def.h, and
>> > therefore to config.h. Didn't that patch apply?
>> >
>> > Does your config.h have a line with "#define histsize 5000"?
>> >
>>
>> No, nor does:
>>
>> st-scrollback-20160727-308bfbf.diff
>>
>> I guess I don't suck ;)
>
> Or maybe I do:
>
>  #define histsize 2000
>
> Ummm.  Let me start again.
>
> Nick
> --
> "Gosh that takes me back... or is it forward?  That's the trouble with
> time travel, you never can tell."
> -- Doctor Who "Androids of Tara"
>

Re: [dev] [ST] scroll patch build failure

2016-09-23 Thread Nick Warne 
On Fri, 23 Sep 2016 13:32:14 -0300
Draco Metallium(Rodrigo S. Cañibano)  wrote:

> > st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
> >   Line hist[histsize]; /* history buffer */  
> 
> In the scroll patch 'histsize' is added to config.def.h, and therefore
> to config.h. Didn't that patch apply?
> 
> Does your config.h have a line with "#define histsize 5000"?
> 

No, nor does:

st-scrollback-20160727-308bfbf.diff

I guess I don't suck ;)

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure

2016-09-23 Thread Nick Warne 
On Fri, 23 Sep 2016 17:36:21 +0100
Nick Warne  wrote:

> On Fri, 23 Sep 2016 13:32:14 -0300
> Draco Metallium(Rodrigo S. Cañibano)  wrote:
> 
> > > st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
> > >   Line hist[histsize]; /* history buffer */
> > 
> > In the scroll patch 'histsize' is added to config.def.h, and
> > therefore to config.h. Didn't that patch apply?
> > 
> > Does your config.h have a line with "#define histsize 5000"?
> >   
> 
> No, nor does:
> 
> st-scrollback-20160727-308bfbf.diff
> 
> I guess I don't suck ;)

Or maybe I do:

 #define histsize 2000

Ummm.  Let me start again.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure

2016-09-23 Thread Rodrigo S. Cañibano 
> st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
>   Line hist[histsize]; /* history buffer */

In the scroll patch 'histsize' is added to config.def.h, and therefore
to config.h. Didn't that patch apply?

Does your config.h have a line with "#define histsize 5000"?

Re: [dev] [ST] scroll patch build failure [SOLVED]

2016-09-23 Thread Nick Warne 
On Fri, 23 Sep 2016 17:09:36 +0100
Nick Warne  wrote:

> I am not getting much luck here (do _I_ suck?) :(
> 
> dwm and st work great so far and I am well impressed and happy; but
> any patches I apply either fail:
> 
> http://lists.suckless.org/dev/1609/30448.html
> 
> (I have since tried git versions, and it fails to build - but more
> later, that is on the back-burner for a mo)
> 
> ...or get build errors:
> 
> apply the patch to st for scrollback.  Latest git
> and latest diff. Patches fine.
> 
> > make
> 
> st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
>   Line hist[histsize]; /* history buffer */
> 
> I have read through the code several times for about an hour, but
> can't work out what is going on?
> 
> Ideas?

Talking to myself and going mad, I sorted it.

GCC being pedantic:

#CFLAGS += -g -std=c99 -pedantic -Wall -Wvariadic-macros -Os ${INCS}
${CPPFLAGS} CFLAGS += -g -std=c99 -Wall -Wvariadic-macros -Os ${INCS}
${CPPFLAGS}

All built and works great!

Thanks,

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

[dev] [slcon3] schedule update

2016-09-23 Thread Anselm R Garbe 
Hi there,

please note the updated schedule[0], especially the dinner location[1]
for tonight.

http://suckless.org/conference
http://www.derwaldgeist.de

Best regards,
Anselm

[dev] [ST] scroll patch build failure

2016-09-23 Thread Nick Warne 
I am not getting much luck here (do _I_ suck?) :(

dwm and st work great so far and I am well impressed and happy; but any
patches I apply either fail:

http://lists.suckless.org/dev/1609/30448.html

(I have since tried git versions, and it fails to build - but more
later, that is on the back-burner for a mo)

...or get build errors:

apply the patch to st for scrollback.  Latest git
and latest diff. Patches fine.

> make

st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
  Line hist[histsize]; /* history buffer */

I have read through the code several times for about an hour, but can't
work out what is going on?

Ideas?

Thanks,

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] ot: C Standard noreturn

2016-09-23 Thread Mahdi Khanalizadeh 
Hi,

noreturn is part of the C11 header stdnoreturn.h. Either use _Noreturn or 
include that header beforehand.
See: http://en.cppreference.com/w/c/language/_Noreturn

Cheers

pgpIkErznIOL8.pgp
Description: PGP signature

Re: [dev] Suckless e-comerce script proposal

2016-09-23 Thread Joseph Graham 
On Fri, Sep 23, 2016 at 10:24:46AM +0800, Kai Hendry wrote:
> Yes, make the site static & host on S3/CloudFront. Generate from a DB
> of your stock/inventory. Go lang's html/template makes this painless.
> 
> Dynamic bits should be ReactJS chatting with Stripe APIs. I would go
> so far as use Stripe to store the customer object et al. You can get
> it back out easy enough if you need to make a move.
> 
> Have fun,
>

I hope this is a joke.