Re: [dev] Suckless e-comerce script proposal
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.
Re: [dev] ot: C Standard noreturn
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
[dev] [ST] scroll patch build failure
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"
[dev] [slcon3] schedule update
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
Re: [dev] [ST] scroll patch build failure [SOLVED]
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"
Re: [dev] [ST] scroll patch build failure
> 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
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
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
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
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"
[dev] containers opinion
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
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 >
Re: [dev] containers opinion
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
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
> 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
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
Only slightly relevant, but I found this on Alan Cox' feed today: https://ptpb.pw/R5ZJ.jpg cheers! mar77i
Re: [dev] containers opinion
> 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
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
