Re: [dev] convergence
On Jan 1, 2013 8:02 PM, "Daniel Bryan" wrote: > > On Wed, Jan 02, 2013 at 10:01:10AM +1100, Sam Watkins wrote: > > On Tue, Jan 01, 2013 at 02:13:14PM +1100, Daniel Bryan wrote: > > > Bash is my go-to for system scripting, but for something that will run > > > 100% of the time on my system for years it's not over-engineering to do > > > it efficiently. > > > > It would be nice to extend C with suitable function and macro libraries, > > and a little new syntax (can be done with a pre-processor) so that we could > > write compact code in C as in shell. Try setting up a shell pipeline in C, > > and you'll see what I mean. There's no reason it should be more > > difficult to do stuff in a compiled language, we barely ever use truely > > dynamic stuff like "eval" or varibles by name in the shell anyway. > > Combined with a good quick compiler or interpreter, we could get a real > > "C shell" into the bargain. > > > > tinycc for example is well fast enough to be used in an interactive REPL > > as if it were an interpreter; and that's without any attempt to optimize > > by pre-loading headers or whatever. > > > > Sam > > > > > > For sure. Equivalent code in higher-level compiled languages like D or > Go can be made fairly idiomatic for pipelines and stuff like that. > > Languages that are compiled "on the fly" like Clojure are far faster > than Python or Bash scripting, and in that specific case LISP can almost > reach the niceness of Bash. > > On the other hand, it's not the fact that C is compiled that makes it > more efficient than the interepreted bash - it's the fact that C is just > reading files and filling buffers, whereas Bash is doing a dozen > fork+execs. > > Seeing as people have already implemented all of POSIX in a single > binary (BusyBox), I sometimes wonder how much work it would be to build > an in-process C library that you could leverage in your C code which > essentially provided things like awk and grep as functions which take a > stdin file descriptor and arguments and return a stdout/stderr pair - > but which do everything in the address space of the caller. > > Imagine how much more idiomatic system scripting code would look - in > any language - if it was built on top of a library whose idioms are > those of the UNIX utilies. > Implementing an entire userland in a library could only lead to a lot more sucking.
Re: [dev] what's your opinion on Go
On 13 December 2011 08:03, Bjartur Thorlacius wrote: > > + D is the best of C and Python modulo compatibility and popularity. > Unlike lisp, most any programmer can read it. > > Last time I looked at D it was more like C++ plus even more crap^H^H^H^Hfeatures.
Re: [dev] Suckless Desktop Environment
On 7 November 2011 15:13, Sean Howard wrote: > > The idea would be to first have an identity, the »Suckless > > Desktop«, which needs a logo, some texts and then links to > > the various parts of suckless. This would be the entrypoint > > for new users, where they can decide, what to adopt to or > > just take everything. > > > > Logo is a marketing thing. Are we about marketing? > > How marketable could a logo for "suck less" be? ;)
Re: [dev] Anti-GPL hipsters
On 24 October 2011 14:00, mikshaw wrote: > > > Unrestricted freedom is impossible > And there's no such thing as restricted freedom. > > I just disagree with people who support those licenses while rabidly > claiming the GPL to be some kind of evil cancer. > > But the GPL is *designed* to be a cancer. It's intended to be viral, restrictive, and impossible to eradicate.
Re: [dev] ideas on suckless file manager
On 8 June 2011 09:32, Kurt H Maier wrote: > it is impossible to rename a file > O wow, I definitely missed the sarcasm here, was about to say > rename(2) ? I must be tired.
Re: [dev] TermKit
How hard would it be to have fd 3 or 4 be a mmap'able image of the window (like /dev/fb) && would this suck less? On 20 May 2011 09:27, Dieter Plaetinck wrote: > [...] > 6)non sucky rendering. I think applications should be able to have > pixel-precise control of what the output should be (other than maybe a > terminal-imposed resize factor, and also not _where_ it should be), to > i.e. render images in the terminal. > I think a fd to write something to like "here's an image, please > render it somewhere" is better than cls's suggestion of having apps > directly write to the terminal. I think the latter idea would get > messy quickly. It's as if X windows would draw themself to the screen > rather then having a window manager take care of it.
Re: [dev] [ANN] sabotage 2011-04-30, a musl+busybox based distribution
On May 4, 2011 9:01 AM, "Uriel" wrote: > > On Sun, May 1, 2011 at 12:29 AM, Christian Neukirchen > wrote: > > Hi, > > > > this is the third public release of sabotage, a distribution based on > > musl and busybox. Provided software is: > > This is a mildly interesting project that might have some potential. > > Please, replace gawk with a sane version of awk, like the one included > with 9base. > > Also, adding Go should be easy as it completely bypasses libc and > links statically by default. Not quite. A few commits ago the net package was changed to use libc in places and dynamically link unfortunately > For a web browser I would recommend NetSurf, not to be confused with > surf (which is a shameful disgrace for the suckless project). > > uriel > > > > > > 9base-6 autoconf-2.68 automake-1.11 binutils-2.21 bison-2.4.3 > > busybox-1.18.4 curl-7.21.4 diffutils-3.0 e2fsprogs-1.41.14 expat-2.0.1 > > file-5.05 flex-2.5.35 gawk-3.1.8 gcc-core-4.5.3 git-1.7.4 gmp-5.0.1 > > grep-2.7 less-436 libarchive-2.8.4 linux-2.6.38.2 lynx2.8.7 m4-1.4.16 > > make-3.82 mpc-0.9 mpfr-3.0.1 musl-2011-04-18 ncurses-5.9 openssh-5.8p1 > > openssl-1.0.0d patch-2.6.1 perl-5.12.3 pkg-config-0.25 psmisc-22.13 > > python-2.7.1 sed-4.2.1 syslinux-4.04 vim-7.3 xz-5.0.2 zlib-1.2.5 > > > > There also is an experimental xorg set with: > > > > bigreqsproto-1.1.1 compositeproto-0.4.2 damageproto-1.2.1 > > fixesproto-5.0 fontconfig-2.8.0 fontsproto-2.1.1 freetype-2.4.4 > > inputproto-2.0.1 kbproto-1.0.5 libICE-1.0.7 libSM-1.2.0 libX11-1.4.3 > > libXau-1.0.6 libXaw-1.0.9 libXdmcp-1.1.0 libXext-1.2.0 libXfixes-5.0 > > libXfont-1.4.3 libXft-2.2.0 libXi-1.4.2 libXmu-1.1.0 libXpm-3.5.9 > > libXrender-0.9.6 libXt-1.1.1 libfontenc-1.1.0 libpthread-stubs-0.3 > > libxcb-1.7 libxkbfile-1.0.7 pixman-0.21.6 randrproto-1.3.2 > > recordproto-1.14 renderproto-0.11.1 resourceproto-1.1.1 > > scrnsaverproto-1.2.1 st-0.1.1 twm-1.0.6 util-macros-1.13.0 > > videoproto-2.3.1 xauth-1.0.5 xcb-proto-1.6 xclock-1.0.5 > > xcmiscproto-1.2.1 xextproto-7.2.0 xineramaproto-1.2.1 xinit-1.3.0 > > xkbcomp-1.2.1 xkeyboard-config-1.4 xlogo-1.0.3 xorg-server-1.9.5 > > xproto-7.0.21 xterm-269 xtrans-1.2.6 > > > > Everything is statically linked. > > > > As of this release, sabotage supports both i386 and x86_64. > > > > You can bootstrap your own build from the scripts at > > > >https://github.com/chneukirchen/sabotage > > > > or use a ready-to-boot disk image either for netinstall or with sets > > included (put it on an USB stick, burning a CD will not work), to be > > found at: > > > >http://xmw.de/mirror/sabotage/i386/sabotage-2011-04-30/ > >http://xmw.de/mirror/sabotage/x86_64/sabotage-2011-04-30/ > > > > You also can netboot the install kernel directly (use pxelinux from > > somewhere). > > > > The default root password is "sabotage". > > > > Enjoy, > > -- > > 58c09ad48792240b3c07d11da62e99773ce205bf i386/sabotage-2011-04-30/sabotage-i386-full-2011-04-30.img.gz > > 24e2f96ffa8fac72a3ea5d38efe2579232be3be9 i386/sabotage-2011-04-30/sabotage-i386-netinstall-2011-04-30.img.gz > > 8d6c675cf511f90f2539331a92772fb31628c712 x86_64/sabotage-2011-04-30/sabotage-x86_64-full-2011-04-30.img.gz > > f042686295d20941929b308e0188577ec2d7a53e x86_64/sabotage-2011-04-30/sabotage-x86_64-netinstall-2011-04-30.img.gz > > > > Christian Neukirchenhttp://chneukirchen.org > > > > >
Re: [dev] sta.li progress
I'd never used jam before, it really is a hideous beast. I was only messing with it to figure out what exactly needs to happen to get bionic to compile so it could be translated into a working mkfile. And I've hit some degree of success. I've just gotten bionic to compile. Some things apparently didn't go right. I had to write my own _start(), and for some reason my hello.c produced a 220K executable. But I'll keep poking it. I'd volunteer but I'm really not very familiar with build systems at all. On 13 October 2010 08:37, Anselm R Garbe wrote: > Anyone volunteering to create an mkfile for bionic, this jam looks > like jam and should be avoided. > I volunteer to review it and to bring it in good shape. > > -Anselm > > On 13 October 2010 14:34, Jens Staal wrote: >> I have no idea what the jam stuff is but I found this after some googling too >> >> https://www.metasploit.com/redmine/projects/framework/repository/revisions/10202/entry/external/source/meterpreter/source/bionic/libc/Jamfile >> >> 2010/10/13 Corey Thomasson : >>> Excellent! I've been searching for something like this. I'll check it out. >>> >>> On 13 October 2010 08:29, Jens Staal wrote: >>>> Are those issues already solved by >>>> >>>> http://www.metasploit.com/redmine/attachments/433/get_bionic_working.diff >>>> >>>> ? >>>> >>>> 2010/10/13 Corey Thomasson : >>>>> On 12 October 2010 20:58, Wolf Tivy wrote: >>>>>>>I've managed to make it compile a good chunk of the object files, >>>>>>>but not malloc/free so its somewhat wasted. >>>>>> >>>>>> It'll talk eventually, keep up the pressure. >>>>>> >>>>>>> When I get a chance to go at it again I believe the android distribution >>>>>>>has some "clean" kernel headers included. I may try to move those to >>>>>>>wherever its looking now. >>>>>> >>>>>> Yes it does, in fact I think it shouldn't need any system headers at all, >>>>>> if you point it to the paths in OVERVIEW.TXT. Is there some >>>>>> "include_path" environment variable you can set, or do we have to hack >>>>>> the jamfile? Or we could do it your way and move them. Worst case is a >>>>>> new >>>>>> makefile. >>>>> >>>>> there's a variable in the Jamfile INCLUDES_x86, the included header >>>>> files dont seem to do the trick though. Running into syntax errors. >>>>> >>>>>> Surely someone else must have dealt with this. Metasploit has been >>>>>> mentioned >>>>>> a few times, but I couldn't find any thing more than the blog post >>>>>> (issue report, whatever) that jens linked. Anyone have a link to more >>>>>> info? >>>>>> >>>>>> About uClibc, it's LGPL, so isn't static linking a bit marginal? For >>>>>> GPL-compatible stuff it's ok, but 9base is incompatible, so it may >>>>>> actually >>>>>> need to be ported to bionic. Have I got this right? >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
Re: [dev] sta.li progress
Excellent! I've been searching for something like this. I'll check it out. On 13 October 2010 08:29, Jens Staal wrote: > Are those issues already solved by > > http://www.metasploit.com/redmine/attachments/433/get_bionic_working.diff > > ? > > 2010/10/13 Corey Thomasson : >> On 12 October 2010 20:58, Wolf Tivy wrote: >>>>I've managed to make it compile a good chunk of the object files, >>>>but not malloc/free so its somewhat wasted. >>> >>> It'll talk eventually, keep up the pressure. >>> >>>> When I get a chance to go at it again I believe the android distribution >>>>has some "clean" kernel headers included. I may try to move those to >>>>wherever its looking now. >>> >>> Yes it does, in fact I think it shouldn't need any system headers at all, >>> if you point it to the paths in OVERVIEW.TXT. Is there some >>> "include_path" environment variable you can set, or do we have to hack >>> the jamfile? Or we could do it your way and move them. Worst case is a new >>> makefile. >> >> there's a variable in the Jamfile INCLUDES_x86, the included header >> files dont seem to do the trick though. Running into syntax errors. >> >>> Surely someone else must have dealt with this. Metasploit has been mentioned >>> a few times, but I couldn't find any thing more than the blog post >>> (issue report, whatever) that jens linked. Anyone have a link to more info? >>> >>> About uClibc, it's LGPL, so isn't static linking a bit marginal? For >>> GPL-compatible stuff it's ok, but 9base is incompatible, so it may actually >>> need to be ported to bionic. Have I got this right? >>> >>> >> >> > >
Re: [dev] sta.li progress
On 12 October 2010 20:58, Wolf Tivy wrote: >>I've managed to make it compile a good chunk of the object files, >>but not malloc/free so its somewhat wasted. > > It'll talk eventually, keep up the pressure. > >> When I get a chance to go at it again I believe the android distribution >>has some "clean" kernel headers included. I may try to move those to >>wherever its looking now. > > Yes it does, in fact I think it shouldn't need any system headers at all, > if you point it to the paths in OVERVIEW.TXT. Is there some > "include_path" environment variable you can set, or do we have to hack > the jamfile? Or we could do it your way and move them. Worst case is a new > makefile. there's a variable in the Jamfile INCLUDES_x86, the included header files dont seem to do the trick though. Running into syntax errors. > Surely someone else must have dealt with this. Metasploit has been mentioned > a few times, but I couldn't find any thing more than the blog post > (issue report, whatever) that jens linked. Anyone have a link to more info? > > About uClibc, it's LGPL, so isn't static linking a bit marginal? For > GPL-compatible stuff it's ok, but 9base is incompatible, so it may actually > need to be ported to bionic. Have I got this right? > >
Re: [dev] sta.li progress
I had heard of jam but never had the slightest inclination to use it. I've managed to make it compile a good chunk of the object files, but not malloc/free so its somewhat wasted. I'm currently hitting a supposed syntax error in of my Linux header files. Perhaps it uses some extension and the jamfile predates it? When I get a chance to go at it again I believe the android distribution has some "clean" kernel headers included. I may try to move those to wherever its looking now. On Oct 12, 2010 5:37 PM, "Wolf Tivy" wrote: > It can be built alone with jam I _think_, I've been toying with > it but > it takes some work and... I've started playing with the jam route, but as you say, header trouble. At the end of libc/docs/OVERVIEW.TXT it says what the header search path has to be. I haven't figured out what to do with that though, maybe you can. Does anyone know Jam well? I'd never heard of it before this. I'm going to lay off the bionic angle for a while, anything more complex than gcc *.c stumps me. Build systems suck. Good luck!
Re: [dev] sta.li progress
It can be built alone with jam I _think_, I've been toying with it but it takes some work and I haven't gotten it all figured out (it seems to be making incorrect assumptions about where some header files are, and missing some files that i think get moved around by the whole build), and as far as I can tell you still have to download the whole source. On 12 October 2010 01:58, Wolf Tivy wrote: >> 2. Demonstrate stand-alone static binaries that have been linked >> against bionic/x86. > > This assumes we have bionic itself working. Has anyone actually built it > without building all of android? I got the source, but I can't make it build. > I've tried a few things, but I hate makefiles. Especially when they're called > Android.mk. > >
Re: [dev] "channel" construct for inter-thread communication in C programs
I was only referring to the channels, not the entire library. I pointed it out more as a potential jumpstart for implementing a select(), etc. I wasn't trying to say cchan was redundant. On 9 September 2010 08:29, Szabolcs Nagy wrote: > > that's not similar/same > > the entire point of the excersise is to do messaging when you need to > exploit modern multicore buzzword compliant architectures > > libtask does no such thing > libthread does i guess > > >
Re: [dev] "channel" construct for inter-thread communication in C programs
libtask [ http://swtch.com/libtask/ ] implements something similar/same; however, it's a coroutine lib and I'm pretty sure it will not work with multiple threads. However, it does have something like a select() for channels, see the Alt structure and associated methods, IIRC the implementation is fairly simple. On 9 September 2010 07:21, Mate Nagy wrote: > Hello all, > > I guess I can't get enough of the punishment I always get in these > threads. Announcing project: > > http://repo.hu/projects/cchan/ > > 'This is a small library that implements a "channel" construct for > inter-thread communication in C programs. ' > > This is a very small and simple lib that does one thing only. > It uses mutexes and conds for synchronization; it is interfaced to the > thread API using a very thin .h file with macros. It would be probably > quite easy to port it to use other thread APIs. Currently it supports > pthreads and SDL threads. > > Doesn't use C99 or gcc-specific features, hopefully. > > Future development: would be nice to implement a select() operation for > listening on multiple channels at once; would probably also be very > complicated. > > Regards, > Mate > > PS. I'm fully aware that Plan 9 has this functionality built in. Not > interested in "you should use plan9 and/or plan9 portability libs" mails > thanx > >
