[dev] HG and python
In war against bloat, python removal is on the todo list. Is there any chance to use something different than hg for source versioning and branching? -- code in C, protect your code with GNU (A)(L)GPL, keep your rights, use GNU/Linux
Re: [dev] HG and python
> There's always git, the core of which is written in C, but some > scripts are perl. perl support is disabled in my git build. But perl removal is somewhat trickier than python because of the GNU autotools. The real todo list for perl is GNU autotools removal or/and basic GNU makefile. I tried that on ncurses but it appeared to be a monstruous code generator, so GNU autotools removal needs a lot a work here: I thought to generate one version of the source, make a GNU makefile for it and trash the rest. I'm scared when I think about gcc and binutils. > And for the bloat: Git is sometimes percieved as somewhat more bloated > (>100 little tools instead of 1 like hg) - that depends on the point > of view. Still, git < hg+python. One other thing is to port X11 code to libxcb instead of libX11... but one thing at a time.
Re: [dev] HG and python
>>> There's always git, the core of which is written in C, but some >>> scripts are perl. >> >> perl support is disabled in my git build. But perl removal is >> somewhat trickier than python because of the GNU autotools. The >> real todo list for perl is >> GNU autotools removal or/and basic GNU makefile. I tried that on >> ncurses but it appeared to be a monstruous code generator, so GNU >> autotools removal needs a lot a work here: I thought to generate >> one version of the source, make a GNU makefile for it and trash the >> rest. I'm scared when I think about gcc and binutils. > > In heaven there is no GNU. Neither perl/python/ruby/lua/squirel/scheme/C++/java/C#. :) >>> And for the bloat: Git is sometimes percieved as somewhat more >>> bloated (>100 little tools instead of 1 like hg) - that depends on >>> the point of view. >> >> Still, git < hg+python. > > Please, we had this discussion already! Hu? Have not check the mailing list archive or forgot about this. Sorry.
Re: [dev] HG and python
>Lua is suckless, seriously. Just look at it. I know lua's code is suckless (unfortunately BSD-LIKE). But coding using lua is not. From there, lua won't reach heaven. -- use GNU/Linux, code in C only, protect your code with GNU (A)(L)GPL and keep your rights
Re: [dev] Announcing sinit - the suckless init
Hi, Just to let you know, I have a little initramfs project. The init process is hardcoded directly on the linux syscalls. In the near futur, I hope to add the support to mount the root filesystem by label and by uuid. cheers, -- Sylvain
Re: [dev] swc: A small Wayland compositor
Hi, just to let you know, I started a minimal wayland compositor: http://code.google.com/p/ulinux-wayland Again, it is hardcoded directly on linux syscall, except the display and input hotplug which uses libudev. It is stalled since I work on my refactoring of the linux southern islands radeon driver (hence, I kind of brainstorm a minimal alternative to the kludge which is the drm). This wayland compositor is targetted at this driver API. Regarding, it's dependency on libudev... can we "subscribe" to the kernel netlink events on the side of libudev without being stolen some by the latest? (I have not investigated the matter). regards, -- Sylvain
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 14, 2014 at 08:22:45PM +, Thorsten Glaser wrote: > Sylvain BERTRAND dixit: > > >Just to let you know, I have a little initramfs project. The > >init > >process is hardcoded directly on the linux syscalls. > > On Linux, syscall numbers, argument number, order and size, > etc. differ by architecture. Indeed, I have a *very* thin architecture abstraction in ulinux for that. I did only x86-64, but since it's very thin, I'm not that worried for new architecture addition. Usually, that bit is done by the libc. -- Sylvain
Re: [dev] C coded cross-platform youtube video viewer
Hi, Unfortunately, libquvi on gentoo expects a system installed lua (with additional modules). I don't want this high level script language as a system dependency. I would prefer lua being packaged internally into libquvi. Coze I would like to quit gentoo one day and have my own suckless-ish distro, then better do the work now. I don't want system wide installed perl/python/ruby/php/lua/guile/javascript... (holy m f*!), I would rather try to have applications package their high level script language and don't try to f*** it up our "system" throat. (and tell the script kiddies: "no, you FOO script language is not installed, and won't be. Then package your bloody f** kludge with your app") Anybody here does know if this is possible? -- Sylvain
Re: [dev] [GENERAL] License manifest
> So, given this context, is there any manifesto about this particular License > choice? E.G is there a reason to avoid GPL? Personnally, I have many reasons to avoid licenses which are not GNU GPL. I want optimal code to stay open. I mean at least to have a legal leverage. I want open code installed by default and not "improved closed version" of open code installed by default (cf apple model which is the dream of many industrials I met pushing for "closable" code licenses). But I'm ok in some **rare** cases to let a piece of open software being linked to closed source programs, then I would use the GNU *lesser* GPL (i.e. video games). If I want to preserve open code via network services, namely server side, I would use a GNU affero GPL (the most protective GNU GPL version). The GNU GPLv3 is complex because written by lawers in order to put some legal lights on some shades of the GNU GPLv2, and be a warning: "don't try to f*** that open source license" (and add a few other things which created a big disagreement between Linus and RMS, i.e. against tivo-ization). But the principles of the the license remain simple, they are just more well defined from a legal perspective (i.e. less f***able which seems to bother some people :) ). -- Sylvain
Re: [dev] C coded cross-platform youtube video viewer
You missed the points. I don't want "standard" distro integration to be a massive work. Now it's near unreasonable to integrate a proper desktop distro alone, and it's quite worse from a "SDK" point of view. It's good for the business of distro integration: coze a small team, or a sole coder cannot "compet" reasonnably. I'm being ironic, but I don't think I'm far from the truth. High level script languages are *many*. And forcibly used in many base components. Perl5 in autotools, apt/dpkg (have to re-check), ruby for grub2, python for portage, javascript for desktops (gnome) and I don't count all the "code generators" SDKs do have. Last time I tried to get rid of the autotools from the glib (not glibc), I ran into perl5 and python2 (and not 3!!) code generators. For libsnd, I discovered a crazy code generator written in GNU guile. Of course, each high level scripting language has to manage its module dependencies and so on, and it's of course of massive kludge... yes nearly *each* of them. People choosing to code using C with some libs, did choose it perfectly knowing that they will sacrifice some comfort compared to *insert your favorite high level scripting language* with *insert the chosen framework specific to that high level scripting language*... (the funniest is PHP with its tons of different www frameworks which do not work together but aim at the same thing). That works with crazy complex statically compiled languages like c++/java (which is probably the worst)/etc. Then, yes, I dont want all those things as system dependencies, coze I don't want to have to maintain integration on those very expensive pieces of software. The hard part, they will have to do it: to bundle in their SDK those thingies. It would solve only one part of the pb, coze I'm sure they would use build systems like cmake or the GNU autotools, then making the removal of those for some basic sh scripts or basic makefiles, a real nightmare (and I already put forward the issue of code generators). -- Sylvain
Re: [dev] C coded cross-platform youtube video viewer
> Yes; you could go change it to embed Lua. Sure. And all the used external lua modules too. Should have been a C toolbox, not lua scripts... What a pain! -- Sylvain
Re: [dev] C coded cross-platform youtube video viewer
> - not use GNOME As a matter of fact, I don't have gnome. But, having "any high level script" bindings in order to customize the gnome desktop is ok... till it's not mandatory for a reasonnably featured desktop. If I'm not wrong, gnome desktop APIs are based on gobject which can be interacted with *any* proper language. The main issue is when deploying a gnome extension with a language you don't have system installed. That's why gnome devs force javascript: to know that by default you will have javascript to write your extension. But with the new gnome software installation front-end, extensions may be installed with proper dependencies (they need to agree on package names to be the same across all distros though). Moreover, C coded extension would be compiled or script-compiled (see tinycc... :) ) One really bad thing, the javascript engine they use is switching to c++ (this is very bad). SpiderMonkey from mozilla. > - accept that people will build things with scripting languages and > that you will need them No. Never. Same for gcc from version 4.8. Their c++ can go to hell. And that I know for sure is going to be very hard to get rid of it. That's for sure is not suckless stuff. Open source software is being corrupted and dirtied to become a massive kludge in a way... well... see this video, it's self-explanatory: https://www.youtube.com/watch?v=uF3nV0r87v8 >> ruby for grub2 > > Haha, what? I checked... it seems ruby dep is gone. As far as I can remember, last time (more or less a year ago) I tried to install grub2, it ran a ruby program. Maybe some fishy distro integration script. (I have been using lilo for ages). -- Sylvain
Re: [dev] C coded cross-platform youtube video viewer
On Tue, Jun 03, 2014 at 09:05:23PM +0200, hiro wrote: > choose a stream, meaning of itags is on wikipedia article of youtube. > wget -q -O - 'http://www.youtube.com/watch?v=Ux1Za8Wmz_s'|sed > 's/"/\n/g; s/\\u0026/ /g; s/,/\n/g'|sed -n > '/url_encoded_fmt_stream_map/,/^$/p; /adaptive_fmts/,/^$/p' > > One very nice new thing i discovered by going the manual way without > the stupid quvi (which sadly randomly stopped working at some point > for me) was that they now at least they have pure audio files > together with that adaptive streaming bullshit, so I don't need ffmpeg > for my purposes any more. Try itag 171 or 140, e.g. > wget -q -O - 'http://www.youtube.com/watch?v=Ux1Za8Wmz_s'|sed > 's/"/\n/g; s/\\u0026/ /g; s/,/\n/g'|sed -n '/itag=171/s/^.*url=//p' > > Then you need to remove the percentencoding, I'm sure you guys might > be able to come up with a C tool for that. Hey! That's nice... I was blindly using movgrab for that. Never took the time to dive in youtube www API. -- Sylvain
Re: [dev] C coded lightweight Linux vector graphics editor
On Thu, Jun 05, 2014 at 05:25:25PM +0200, patrick295767 patrick295767 wrote: > Hi Friends, Hello Guys, > > Because you have always very fantastic/great ideas in this field, I > would like to ask if you would know a cool vector graphics editor. > > You probably know Inkscape, but I must say that I am not a fan of this > software. > Inkscape is a free and open source software vector graphics editor. > Its goal is to implement full support for the Scalable Vector Graphics > standard. The word Inkscape is a portmanteau of the words ink and > landscape. > > Would you have please valuable tipps...? It's a very good idea. Don't forget to keep the SDK as suckless as possible: no GNU autokludge/cmake/etc or python[23]/perl6/guile/etc code generators (basic C programs compiled for the host). Basic shell scripts for compilation (copy the ones from ffmpeg, they are very good), or, if the project is too long to compile for a debugging cycle (fix/compile/test/fix/compile/test), basic recursive makefiles (don't try to use *all* unix makefile tricks, better being verbose and simple than crazy insanely unreadable and small). You should code for tinycc to be sure we can get rid easily of gcc and clang. cheers, -- Sylvain
Re: [dev] Alpine Linux switched to musl libc
On Fri, Jun 06, 2014 at 10:50:24AM +0200, Silvan Jegen wrote: > Does anyone here have some experience with it? I have had it installed on my laptop for a while. But since I hardly use my laptop... What I can say: openrc is... not suckless: it's a kludge of scripts which try to manage all possible cases. I did remove openrc from my custom gentoo gnu/linux distro for this reason. I haven't updated alpine in while. I wonder if the glob and regexp engines, the date/time management and the brainfuckage which are the C locales are up to speed with the glibc. Coze, those things are from the nasty libc bits. I do prefere GNU Lesser GPL for libc legal protection. But if musl is really modular, working on those nasty pieces of the libc standard, and has a suckless sdk, I'm ready to drop my GNU Lesser GPL requirement to give it a try. -- Sylvain
Re: [dev] C coded lightweight Linux vector graphics editor
BTW, the choice of the gfx toolkit will be critical. Unfortunately, the C toolkits over there are turning very bad: GTK+ and the EFL do depend on harfbuzz for their font layout computation which is an *really* ugly c++ object-oriented brainfuckage (uglier that the glib SDK dependencies!). I did a C port of harfbuzz (drop-in replacement), but for basic text layout (roman style). Then to keep your GUI suckless, you should package a version of a toolkit to allow trashing harfbuzz, or avoid crazy SDK deps... This is unfortunately more work. -- Sylvain
Re: [dev] harfbuzz
On Thu, Jun 19, 2014 at 01:21:24PM -0400, Nick wrote: > Quoth Sylvain BERTRAND: > > Unfortunately, the C toolkits over there are turning very > > bad: > > GTK+ and the EFL do depend on harfbuzz for their font layout > > computation which is an *really* ugly c++ object-oriented > > brainfuckage (uglier that the glib SDK dependencies!). I did > > a C > > port of harfbuzz (drop-in replacement), but for basic text > > layout > > (roman style). Then to keep your GUI suckless, you should > > package > > a version of a toolkit to allow trashing harfbuzz, or avoid > > crazy > > SDK deps... This is unfortunately more work. > > You've complained about harfbuzz before. I haven't looked at > the > code, and believe you that it's bad, but good international > text > layout is important and tricky, so might it not be a better > idea to > clean up harfbuzz than just nuke it? ? I did not nuke it. The core issue with harfbuzz is c++ (c++ is certainly not suckless). Then it has to be be rewritten from scratch and follow its C API for drops-in replacement. I started to rewrite it, namely I unrolled the c++ code into plain C code. But I did it only for basic layout rendering. The API has a major race condition though (free before access), I did try to warn the GTK+/pango devs, that was just hitting my head against a wall. I currently uses my *c*harfbuzz with the GTK+ toolkit... (used by the netsurf www browser). The pb, is when the official dev feels threaten by an alternative implementation, usually, that dev will "enhance" its API to force dependent components (i.e. GTK+/EFL/gecko) to break compatibility with alternative implementations, and of course the devs of those "upper" components will never accept code to make their components working with alternative implementations. Harfbuzz dev has the time and mind peace as he's financially secure: he's a full-time employee at google and he's payed probably near 150k$ a year. The issue is similar with udev. Poettering did "absorb" the "official" udev project into his systemd giga-kludge (no lies here unfortunately). Components out there used the API version 0 of udev, now the API was "enhanced" to API version 1... don't expect forks to follow like dogs the API changes from Poettering on udev. And project like xorg will probably use API version 1 in the futur and give a really hard time to alternative implementation which stayed in API version 0, or went another road. Basically, project like xorg should get rid of libudev dep and be hardwired directly on linux (which has pretty stable userland interfaces... it's not perfect, but better direct linux than libudev API). Sort of "embrace" and "extend". I don't say some API changes are not required... but they could be more of a trick to kill alternative implementations than bringing *really* significant features. -- Sylvain
Re: [dev] harfbuzz
On Fri, Jun 20, 2014 at 02:40:50PM -0400, Bobby Powers wrote: > Hi Sylvain, > > Sylvain wrote: > > I started to rewrite it, namely I unrolled the c++ code into > > plain C code. But I did it only for basic layout rendering. The > > API has a major race condition though (free before access), I did > > try to warn the GTK+/pango devs, that was just hitting my head > > against a wall. > > This sounds interesting, but I couldn't find anything in the harfbuzz > mailing list archives about a race condition. Do you have links to > the email thread? That was on IRC. That said, you missed the "real" nasty point of harfbuzz, the race condition is not important compared to that one: ** It's written in c++ ** cheers, -- Sylvain
Re: [dev] suckless distro
On Mon, Jun 23, 2014 at 05:23:02PM +0200, FRIGN wrote: > [0]: http://sta.li/faq > [1]: http://dl.suckless.org/stali/clt2010/stali.html > [2]: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ BTW, regarding a static linux kernel for desktops: - was including as built-ins *all* desktop hardware driver modules available in the standard source tree kind of "benchmarked" like user space? That for a "live" stali gnu/linux based system. -- Sylvain
Re: [dev] suckless distro
On Tue, Jun 24, 2014 at 11:52:04AM +0100, Dimitris Papastamos wrote: > There's also smdev[0] if you are interested. > > [0] http://git.2f30.org/smdev Using a makefile is overkill. Should be a sh script. Makefiles should be used only when there are too many source files to recompile for a build increment. Not a fan of the licence, will still use my udev fork, but nice seeing alternatives. -- Sylvain
Re: [dev] suckless distro
On Tue, Jun 24, 2014 at 11:57:27AM +0100, Dimitris Papastamos wrote: > Nobody cares how you build the kernel. Ok, you are from those who does not care. Unfortunately, I'm from those who do care. Then I should not care about stali once I hit linux kernel issues. From now, I may have a look at stali only from a userland perspective, I thank you for the hint. Fine. Now, I exit the context of stali. I'm looking for feedback on "live" huge linux kernel, which are able to mount a rather "standard" root filesystem by itself with the kernel parameter like rootfs=UUID=38873-47398743 (the proper init process being selected with init=... kernel parameter). Probably not a 0-module linux but a linux with all disk drivers and the root filesystem modules, for instance: - ext4 related modules. - all usb controller drivers with USB mass-storage driver. - all disk controller drivers. This linux should be pretty "live", what do you all reckon? -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 02:13:15PM +0200, FRIGN wrote: > On Wed, 25 Jun 2014 14:05:20 +0200 > Sylvain BERTRAND wrote: > >> Using a makefile is overkill. Should be a sh script. > >> Makefiles should be used only when there are too many source >> files to recompile for a build increment. > > Are you serious? 100%. It's not suckless to use a makefile if recompiling all source files takes little time. The main purpose of makefiles is to cherry pick what to recompile on large projects in order to minimize build time. Pointless and technically expensive for small project SDKs, period. I started to remove makefiles from my SDKs. Because all are small (except the radeon GPU driver which is a linux module). I stole parts of the ffmpeg configure script for my needs. >> Not a fan of the licence, will still use my udev fork, but nice >> seeing alternatives. > > Anything is better than the bloody (L)GPL you are using. :) We disagree on the license. I think exactly the other way around. Nothing new here... -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 02:52:47PM +0200, Džen wrote: > On Wed, Jun 25, 2014 at 2:05 PM, Sylvain BERTRAND wrote: >> Using a makefile is overkill. Should be a sh script. > > Say what? See my answer to FRIGN. regards, -- Sylvain BERTRAND
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 02:34:32PM +0100, Dimitris Papastamos wrote: > On Wed, Jun 25, 2014 at 02:57:30PM +0200, Sylvain BERTRAND wrote: > > I stole parts of the ffmpeg configure script for my > > needs. > > Nothing to see here. ?
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 02:14:31PM +0100, Dimitris Papastamos wrote: > > On Wed, Jun 25, 2014 at 02:05:20PM +0200, Sylvain BERTRAND wrote: > > On Tue, Jun 24, 2014 at 11:52:04AM +0100, Dimitris Papastamos wrote: > > > There's also smdev[0] if you are interested. > > > > > > [0] http://git.2f30.org/smdev > > > > Using a makefile is overkill. Should be a sh script. > > Learn how to write portable makefiles. If you don't like > make use mk. You missed the point. read my answer to FRIGN. > FWIW smdev does not consist of a single source file. We also > build util.a. Few source files does not mean *one* source file. Do you understand that?
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 03:23:32PM +0200, FRIGN wrote: > On Wed, 25 Jun 2014 14:57:30 +0200 > Sylvain BERTRAND wrote: > >> 100%. It's not suckless to use a makefile if recompiling all >> source files takes little time. The main purpose of makefiles is >> to cherry pick what to recompile on large projects in order to >> minimize build time. Pointless and technically expensive for >> small project SDKs, period. > > The main purpose of makefiles is to make stuff, including building more > or less complex software-projects. > Even if a project of mine only has one source-file, I still write a > makefile to accomodate to common practice. > I won't stop you from writing shell-scripts, but I think it's really > stupid and a waste of time to do it. > If you don't know how to write portable makefiles, please don't start > ranting on this great system which has proven itself for decades. > >> I started to remove makefiles from my SDKs. Because all are small >> (except the radeon GPU driver which is a linux module). >> I stole parts of the ffmpeg configure script for my >> needs. > > Are there any reasons for it other than irrational ones? I did explain my reasons. If you and some others judge them "irrationnal" so be it. My SDKs will be "irrationnal" then :) This is where I draw the line for my SDKs: build time too annoying with a brutal and stupid sh script --> I'll go makefile to cherry pick what to compile/generate and speed up the build. >> We disagree on the license. I think exactly the other way around. >> Nothing new here... > > I used to be a GPL-fanatic like you, but then I took an arrow to the > knee. Licence choice is not a fanatic choice. I do prefer and favor GNU GPL protected software. I have reasons. I already explained them, and you probably read them as well. And for your information, I'm not bothered to work on some components which are not protected by a GNU GPL license, on a case by case basis evolving over time. You got shot to the knee? That hurts a lot. Coze those who are shot in the knee with one of the GNU GPL licenses are those who "forgot" to provide the source code of modified GNU GPL protected code to their users. Are you one of those? -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 03:25:58PM +0100, Dimitris Papastamos wrote: >On Wed, Jun 25, 2014 at 04:16:36PM +0200, Sylvain BERTRAND wrote: >> On Wed, Jun 25, 2014 at 02:14:31PM +0100, Dimitris Papastamos wrote: >>> >>> On Wed, Jun 25, 2014 at 02:05:20PM +0200, Sylvain BERTRAND wrote: >>>> On Tue, Jun 24, 2014 at 11:52:04AM +0100, Dimitris Papastamos wrote: >>>> > There's also smdev[0] if you are interested. >>>> > >>>> > [0] http://git.2f30.org/smdev >>>> >>>> Using a makefile is overkill. Should be a sh script. >>> >>> Learn how to write portable makefiles. If you don't like >>> make use mk. >> >> You missed the point. read my answer to FRIGN. > > I ignored the point. Indeed. > > > FWIW smdev does not consist of a single source file. We also > > > build util.a. > > > > Few source files does not mean *one* source file. Do you > > understand that? > > Regardless of the number of source files you arguments are > wrong. My arguments are perfectly sensible from the perspective of making SDKs suckless: the avoidance of technically expensive components in small SDKs. Please could you state with more that "you arguments are wrong", why they are wrong. I'm opened minded, I'm willing to read them. -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 04:34:59PM +0200, Sylvain BERTRAND wrote: >On Wed, Jun 25, 2014 at 03:23:32PM +0200, FRIGN wrote: >> On Wed, 25 Jun 2014 14:57:30 +0200 >> Sylvain BERTRAND wrote: >> >>> 100%. It's not suckless to use a makefile if recompiling all >>> source files takes little time. The main purpose of makefiles is >>> to cherry pick what to recompile on large projects in order to >>> minimize build time. Pointless and technically expensive for >>> small project SDKs, period. >> >> The main purpose of makefiles is to make stuff, including building more >> or less complex software-projects. This is where we disagree. You draw the line there: acceptance of the technical cost of make in your SDKs whatever the size. I guess, I draw the line somewhere else, damned! >> Even if a project of mine only has one source-file, I still write a >> makefile to accomodate to common practice. Install windows and visual studio then. Subscribe to msdn. That argument is invalid. Don't accept "common" practice blindly like a "fanatic" :). >> I won't stop you from writing shell-scripts, but I think it's really >> stupid and a waste of time to do it. Then, you'll think I'm stupid, and I'll think you are stupid. Welcome in the human world. >> If you don't know how to write portable makefiles, please don't start >> ranting on this great system which has proven itself for decades. You are making me say things I didn't. I'm not ranting about make. I'm talking about what I think is make misuse. Make is perfectly justified where a full build time is "too long". Oh! "writing portable makefile" did pop up. Could you explain me why it relates to this topic? -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 04:41:08PM +0200, koneu wrote: > Thanks. You prefixing the GPL with GNU each and every GNU time > made this so much GNU more entertaining to GNU read. I thank you too for your large contribution to the topic. Come on! If you disagree, give me arguments! -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 03:43:31PM +0100, Dimitris Papastamos wrote: > On Wed, Jun 25, 2014 at 04:34:59PM +0200, Sylvain BERTRAND wrote: >> This is where I draw the line for my SDKs: build time too >> annoying with a brutal and stupid sh script --> I'll go makefile >> to cherry pick what to compile/generate and speed up the build. > > https://github.com/sylware/charfbuzz/blob/master/make > > Yes this is suckless. Thank you. It took you more messages that I think before you got interested in my work and attack it, I expect those whose disagree with me to do the same than you. So, if you understand just a tiny bit of what I said: Yes it is suckless: because the SDK does not depend on makefiles, it makes the SDK less technically costly on the overall. BTW: could you show me some of you work? I wonder who I'm arguing with. -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 11:08:52AM -0400, Carlos Torres wrote: > FWIW the subject of the thread is straying away from "suckless distro" Sorry, I took some of my free time to feed the trolls... I'll stop very soon. All my apologies. regards, -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 04:41:03PM +0200, FRIGN wrote: > On Wed, 25 Jun 2014 16:34:59 +0200 > Sylvain BERTRAND wrote: > >> I did explain my reasons. If you and some others judge them >> "irrationnal" so be it. My SDKs will be "irrationnal" then :) >> >> This is where I draw the line for my SDKs: build time too >> annoying with a brutal and stupid sh script --> I'll go makefile >> to cherry pick what to compile/generate and speed up the build. > > Reading your makefiles I understand why you hate the concept. You can > write one in less than 20 LOC. Great! Finally! Thanks! The metric of LOC alone is not sufficient in many cases to define a suckless project. Of course this metric must not be overshadowed, but in no way is sufficient. Let me give a "extreme"/simplistic example to lead you to why: Coder A wrote a program using *insert your GIGABLOAT written in C here* which does function Z in 10 LOC. Coder B wrote a program using C which does function Z in 100 LOC. The suckless program is from coder B because the whole software stack of code is way more technically costly. What I mean: it's totally suckless to write more LOC if it reduces the technical cost of the overall software stack (SDKs included!). In the reality, each case is different, and people won't draw their line in the same place. The important thing is not to overshadow the global technical cost. -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 05:16:34PM +0200, FRIGN wrote: > On Wed, 25 Jun 2014 17:03:28 +0200 > Sylvain BERTRAND wrote: > >> This is where we disagree. You draw the line there: acceptance of >> the technical cost of make in your SDKs whatever the size. >> I guess, I draw the line somewhere else, damned! > > Says the guy who puts > > #This is a brutal makefile... but extremely easy to read as it is actually > #very basic makefile logic. > > on top of a 450 LOC makefile[0]. Dr. Frankenstein would be impressed! Oh! Why are you talking about the size of one of my makefile? Could you not understand that the topic is "the use of make in SDKs" not "how to actually write a makefile"? You disappoint me to think that the people here won't make the difference (I bet most detected your trick). Anyway, let's change of topic, since you want to do it. Let's be in the context of writting a makefile, namely in the context of SDK where full build time is annoying in the coding cycle, then we need makefiles to cherry pick what is to be re-built. (I don't believe it... I'm feeding that obvious troll/bot :) ) so... This is another point: it is way more suckless to write more but simpler code than writing less but very complex code. It is valid for makefiles too! (the obvious example is C/c++). In the context of a makefile, I prefer writing totally stupid makefiles, very easy to read, namely verbose, than one that will for sure make me pull the make documentation to understand what I did 6 months before :) Then if you look that makefile, it's a totally stupid one, ultra easy to read. No crazy targets/rules (damned! what is $& already! :) ) This is by design, you, LOC fanatic ;) >> Install windows and visual studio then. Subscribe to msdn. That >> argument is invalid. Don't accept "common" practice blindly like >> a "fanatic" :). > > I'm talking about common practice in the scope of suckless software > development, not in the sense of software development in general. > > If you really believed in GNU/Freedom(R), you would never even talk > about Microsoft. You've been unmasked! For your information, I genuily hate microsoft/oracle/apple/sap... from all my heart. I despize them. For me, they don't register higher than cokroaches. They generate sooo much hate! That said, that part was dealing with "common practice"... you dismissed that topic completely... pfff! unfair! You slave of some "common" practice! ;) >> Then, you'll think I'm stupid, and I'll think you are stupid. >> Welcome in the human world. > > With the difference that I'm not the only one here who thinks your > makefile-concept is stupid. This is not stupid. It's just putting reasonably the line somewhere else to be friendler to the suckless philosophy. -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 08:07:17AM -0700, Ryan O’Hara wrote: > On Wed, Jun 25, 2014 at 7:40 AM, Sylvain BERTRAND wrote: >> My arguments are perfectly sensible from the perspective of making >> SDKs suckless: the avoidance of technically expensive components >> in small SDKs. >> > > To look at things another way: simple projects don’t require particularly > complicated Makefiles. You can write one simple enough that running the second > line is equivalent to running make. If it needs to be extended in the future, > that’s easy enough; it’s portable; everyone can read it; everyone knows how > to override its configuration. Indeed, but those simple projects would not require complicated shell scripts too. Then better use a shell script instead a makefile. Why? Well for all the reasons I stated in off-topic part of this thread ;) -- Sylvain
[dev] arrow in the knee because of the GNU GPL???
On a previous thread off thread topic, we got this: On Wed, 25 Jun 2014 18:07:49 +0200 FRIGN wrote: ... > I used to be a GPL-fanatic like you, but then I took an arrow to > the knee. > > Cheers > > FRIGN Could you describe to us what *exactly* did happen to you? I'm eager to know *exactly* why you were disgusted by the GNU GPL license. It's *very* serious. Since it may change my mind about this license. regards, -- Sylvain
Re: [dev] arrow in the knee because of the GNU GPL???
On Wed, Jun 25, 2014 at 12:52:33PM -0400, Calvin Morrison wrote: > On 25 June 2014 12:49, Calvin Morrison wrote: >>> Could you describe to us what *exactly* did happen to you? >> >> see [0] >> >> [0] http://knowyourmeme.com/memes/i-took-an-arrow-in-the-knee > > But more seriously, GNU freedom is the same kind of 'freedom' that is > promised by communists. It's actually not very free. If you craft your > words enough, and trick people enough, then they will believe it is > free, while being coerced into helping the 'greater good' > > Free should mean anyone can take my code and do what they please with > it. Somewhat free is usually like, they can do whatever they want, but > leave my name on it. GNU Free is, sure you can use it, but you need to > contribute back any changes you make or else. I respect your opinion. We can start another thread on why GNU GPL/MIT/BSD with your arguments. Don't take personnaly, but I already answer countless times those arguments. Let's try to keep this thread on the topic (this time I started a specific thread!): I would like to know how *exactly* (the details), of how FRIGN was "hurt" by the GNU GPL licences. A real case. I'm extremly serious about it. Because it can change my mind on licences for good. -- Sylvain
Re: [dev] Re: arrow in the knee because of the GNU GPL???
On Wed, Jun 25, 2014 at 07:09:06PM +0200, FRIGN wrote: > On Wed, 25 Jun 2014 18:47:53 +0200 > Sylvain BERTRAND wrote: > >> Could you describe to us what *exactly* did happen to you? >> >> I'm eager to know *exactly* why you were disgusted by the GNU GPL >> license. >> >> It's *very* serious. >> >> Since it may change my mind about this license. > > Hey Sylvain, > > the GNU GPL is best describes as the prophecy of the beast and the > legend of Dovahkiin, the Last Dragonborn. > The appearance of the last Dragonborn was prophesied upon the GNU GPL, > a large edifice found within GNU Haven Temple. > It depicts several events that would preface the return of the Nordic > god of destruction, Richard Stallman. The prophecy itself is dire, but > scholars believed that its omens had been fulfilled and that a single > individual, gifted with the same incredible powers held by the dragons > themselves, may rise to fight against Richard Stallman and assure the > world’s survival. > Richard Stallman finally returned in 1995, however he was defeated in a > battle with the Last Dragonborn atop the Throat of the World, after > which he fled to Boston only to be hunted down by the Last Dragonborn > and finally slain. > > I hope I could shed some light on your question. Please, could you state exactly what did happen to you to make you hate the GNU GPL licenses? This is very important. As I said, it could change my mind on licenses. regards, -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 12:38:01PM -0500, M Farkas-Dyck wrote: > On 25/06/2014, Sylvain BERTRAND wrote: > > What I mean: it's totally suckless to write more LOC if it > > reduces the technical cost of the overall software stack (SDKs > > included!). > > > > In the reality, each case is different, and people won't draw > > their line in the same place. The important thing is not to > > overshadow the global technical cost. > > Now, I can't honestly claim to write for all the suckless community. > But I shall write for myself at least. > > Computers are meant to do tedious work for us. That includes us who > program them. The appropriate metric of code quality, ergo, is how > much easier it makes one's life. To this end, mental costs trump > technical costs by far. > > A reusable component with well-specified interfaces makes my life much > easier, for I need not reimplementate that functionality each time I > need it, and it works uniformly across all usage sites, which means > less to remember. Even if it takes more computer time, to a point I > care not, for computer time is cheap and my time is costly. > > Make is such a component. I needn't care how many files I need to > build; I just write a makefile and it does so. > > You clearly deem a shell an acceptable technical cost, tho itself not > a simple program. C compilers and OS kernels are yet other technical > costs. I use all these programs as they give me a uniform common > interface to launching and connecting programs, machine code > generation for various architectures, and the machine itself. > > Losses arise when components cause more grief than they're worth. Make > itself is easy to build and use. GNU autoshit ain't; its mental costs > due to nonuniform interfaces and other faults are too great. Hi, You write like I was not recommending the use of makefile in any context. You may have misunderstood me. It's expected when you look at the mess which is that part of this thread, then my guess is your are not ill intended. Actually, the context was specific. The context was small SDKs. Those you usually find in suckless-ish projects. Of course, I would use makefiles for SDKs where a full build is annoyingly "too long" for the coding cycle. Frign even brought the attention of the readers to one of my makefile trying to throw discredit on what I said using my makefile coding style (that very coding style I explained in the follow-up message). :) But for the GNU autosh*t... we all agree... this is one of the worst and kludgiest SDK systems out there... a definitive nono. regards, -- Sylvain
[dev] reboot, arrow in the knee because of the GNU GPL???
This is a reboot of the previous thread that was hi-jacked by a derived topic ;) Let's stay focused on the pertinent topic of the thread, without the damage of what we wrongly did on the thread related to the suckless distro, thank you for your understanding. - On a previous thread off thread topic, we got this: On Wed, 25 Jun 2014 18:07:49 +0200 FRIGN wrote: ... > I used to be a GPL-fanatic like you, but then I took an arrow to > the knee. > > Cheers > > FRIGN Could you describe to us what *exactly* did happen to you? I'm eager to know *exactly* why you were disgusted by the GNU GPL license. It's *very* serious. Since it may change my mind about this license. regards, -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 02:21:05PM -0400, Carlos Torres wrote: > On Wed, Jun 25, 2014 at 2:17 PM, Sylvain BERTRAND wrote: > > giberish... > > Sylvain > > > > why don't you start another thread about makefiles vs shell scripts Something is not fishy there, I have never sent this message wtf? Yes, I'll start another thread (even if there is no more to say). -- Sylvain
[dev] shell scripts vs makefiles for small SDKs
As rightfully requested. A dedicated thread. -- Sylvain
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 11:52:07PM +0530, Weldon Goree wrote: > On 06/25/2014 05:35 PM, Sylvain BERTRAND wrote: > > > > Using a makefile is overkill. Should be a sh script. > > > > Makefiles should be used only when there are too many source > > files to recompile for a build increment. > > Huh. Make strikes me as one of the more suckless tools out there. It > does exactly what it says it does, and nothing else. It doesn't "reach > inside" the tools you tell it to use (except for the fact that it more > or less intrinsically knows the workflow 99% of C compilation projects > use, but you can also make it forget that easily). It doesn't complain > if you use it for something outside of its intended scope -- I'm a > sysadmin, not a "real" programmer, and I've used make in just about > every aspect of sysadmining, one way or another. It even works as a > fairly usable rc / daemon control system (it could be init itself, for > that matter). But it does none of those things by bloating; it does them > by staying out of the way as much as possible. > > It does one thing well (running commands based on a supplied command > definition and dependency file), liberally reads a plaintext > human-readable file as input, places no artificial limitations on its > usability, and acts deterministically and predictably*. That's what > sucking less is, really. > > Now, a downside of being a good tool is that it gets misused a lot. You > could say the same thing of a good power drill. Make is the medium into > which GNU's autohell gets translated, but that's mostly because it's one > of the few systems both simple and powerful enough to survive that > monstrosity and still mostly function. > > But, back to your point, I don't know that a custom shellscript is "more > lightweight" in any important sense than a makefile. Make is on > basically any system with a compiler -- if you're using simple, portable > makefiles (and you should), then it's actually a more stable API to work > with than trying to work around all the various shells and their > versions that might be out there. Using a shellscript opens you up to > "oh, that doesn't work in bash < 4.1" and "wait, what if somebody has > /bin/sh linked to csh?" (to say nothing of "where do the semicolons go > in a bash for loop, again?"). To me, make should be used when you need a > specific set of commands run in a dependency relationship, particularly > one involving file mtimes. Many, many builds work that way, even simple > ones. > > If you'd prefer, look at make as a rather clever sed/awk script that > transforms a yaml file into a series of sh commands. > > * Having behavior tied to mtimes of files in the environment makes it > somewhat less than deterministic, in fairness. > > Weldon Could you repost on the thread I was rightfully requested to create for this topic. Thank you. -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Wed, Jun 25, 2014 at 02:30:48PM -0400, Calvin Morrison wrote: > stop repeating yourself. You don't need a new subject and a duplicate > post to garner a response. what a waste of space Please, keep this thread for frign to expose *explicitely* what went wrong with the GNU GPL licenses and discussions related the details and facts of what happens to him. BTW, We are still waiting... -- Sylvain
Re: [dev] arrow in the knee because of the GNU GPL???
On Wed, Jun 25, 2014 at 10:30:28PM +0200, Kurt Van Dijck wrote: > In my understanding, GPL enforces that derived work of your code > will still be free to its users. This covers 2 major aspects: > * One cannot repackage or modify GPL software and make it non-free > I think that is a guarantee that your code will _stay_ free, > even after modifications. > > * People that are not using the software, have absolutely no rights. > If I modify my linux kernel on my system, even Linus himself has > no rights to see. > Strictly speaking, only users of my computer that runs that kernel > can force me to give the sources. > > Am I wrong in this? Nope, you are right. Let me add some infos. You have other GNU GPL licences, for instance: - GNU *lesser* GPL: allows a "closed source" component to be linked to the component protected by the license. Perfect for middleware for instance. That's why most the libs are protected with a *lesser* version of the GNU GPL. - GNU *affero* GPL: this extends the GNU GPL to software components providing services over the network. For instance, the source code of a HTTP server protected with this licence would have to be provided to users. (this license is extremly rare, I have never seen it, except on some of my components ;) ). - *linux* GNU GPLv2. The linux GNU GPLv2 is a modified version of a plain GNU GPLv2: closed source userland programs are allowed till they are "normal". Basically, a device driver, even in userland is covered by the GNU GPLv2. Closed source device drivers are tolerated in the linux kernel (for various reasons), but in no way are legal. - GNU GPLv3: it's very hard to cheat it, because written by legalists. v2->v3 Highlights: Adds protection against those who open some code, but put "software patents" on that very code. Adds protection against those who open the code, but make it unmodifiable by users by a technical mean (tivo-ization, I may be wrong, but it one of the main things Linus T. does not like with v3). regards, -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Thu, Jun 26, 2014 at 02:59:09AM +0800, Chris Down wrote: > Sylvain, > > You've had positive contributions here before. Please have consideration > for the many subscribers who are here to participate in discussion > related to suckless.org and suckless philosophy, and have no interest in > meaningless mud slinging between two people. > > There is a good way to approach discussion, and a bad way; certainly > this thread falls in the latter category. Cool down, take some time out, > and then reapproach the problem with a more productive mindset that > isn't focussed on baying for public humiliation. :-) > > Thanks. I'm very disappointed: I was the guy who was attacked on his published work on internet (in a rather clumsy and harsh way). Nethertheless, when I'm about to get a very important piece of information, I'm only being silenced for good and I get more bashing? That piece of information: a real life issue with the GNU GPL license (which end up being a dirty lie?). It seems some "subscribers" may be malicious accounts to sabotage any attempt to get a constructive argument (directed against some specific people?). Do note that the "people" behind those accounts are worth quite less than those from microsoft/apple/sap/oracle/etc, even if they write open source software. Well... it's the price of a public mailing-list, I guess. cheers, -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Thu, Jun 26, 2014 at 09:07:26AM +0900, Philip Rushik wrote: > It's the internet, people say stuff, don't let it get to you. It did not get to me (I'm an internet children, I'm used to trolls). On those later threads, I stayed polite and analytical all the time except, of course, regarding closed source system software manufacturers. Could you pinpoint to me some parts I was insulting the participating "subscribers" or engaged in active public discredit (like making fun of published code)? > You did start 3 threads, that's not good ml etiquette. Probably > could have dealt with this off the mailing list, or not taken it > personally. There were lots of better options. Hey! I was asked to start a new thread. I know it's bad to "steal" the topic of a thread like that. Then I did it, and in an instant I was told to kill that thread ??? I started another thread regarding a real life GNU GPL license issue of one of suckless subscribers (the holy graal for me). The thread was immedialtly "stolen" and strayed away from its primary purpose. Then I rebooted the thread, and ask the people to be nice and respect the purpose of this thread. Code license is important for all suckless software and, finally, and we have somebody able to reveal to suckless people a real life issue with the GNU GPL. This is reasonnably valid to be dealed and discussed by the suckless community. Basically, out of the blue, I was instantly asked to stop all my threads. Quite weird actually. > You aren't getting anywhere by using terms like "dirty lie". > There are lots of arguments against the GPL. Just because you > don't agree doesn't justify calling people liars. Nobody has been able to pinpoint to me pertinent, real life, issues with the GNU GPL licenses that would make prefer MIT/BSD like licenses. The only thing I have got is, to summerize, "trust me, there are some". If you have some, I'll be pleased to read about them, because the issue from a subscriber seems top secret/classified (how convenient!) And hey! I cannot disagree on things I'm not told about yet! Come on :). I only can disagree on keeping it a secret, that's it. I was happy, in a technical argument about choice of SDK build system, a "subcriber" swore to me he had real troubles with the GNU GPL. Again, when I'm about to get that intell, abracadabra, It disappears, and people are frowing eyebrows hard! >> It seems some "subscribers" may be malicious accounts to >> sabotage any attempt to get a constructive argument (directed >> against some specific people?). > > You seriously believe this? I hope you don't. It's common on web public forums (trolls and super stealth kiddies using tor). Why not on a public mailing list. Here, they are a bit smarter than their web counter parts, that's all, but we are not a lot higher than the sea level (I wonder, could they be bots to win the turing price?) >> Do note that the "people" behind those accounts are worth >> quite less than those from microsoft/apple/sap/oracle/etc, >> even if they write open source software. > > Again, if you don't want to be attacked, trying to offend others will > get you nowhere and doesn't help your case at all. That, I just posted it. Apparently, the damage happened before. I wonder when... as I said, I'm open minded, I do accept constructive critisism. regards, -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Thu, Jun 26, 2014 at 11:11:38AM +0900, Philip Rushik wrote: > On Thu, Jun 26, 2014 at 10:24 AM, Sylvain BERTRAND wrote: > > It did not get to me (I'm an internet children, I'm used to > > trolls). > > On those later threads, I stayed polite and analytical all the > > time except, of course, regarding closed source system software > > manufacturers. Could you pinpoint to me some parts I was > > insulting the participating "subscribers" or engaged in active > > public discredit (like making fun of published code)? > > In most parts of the world "dirty lie" is not considered to be very > friendly. Just because you didn't specifically make fun of somebody's > code doesn't mean you were being civil and polite. You were very > aggressive, just take a look back at the things you have written. I did. It is order of magnitude less that the other guys. A drop in the middle of a public wipping. It's neglectable compared to the other guys. Please be fair: do provide the same treatement you are giving me to the other guys. > > Hey! I was asked to start a new thread. I know it's bad to "steal" the > > topic of a thread like that. Then I did it, and in an instant I > > was told to kill that thread ??? > > > I started another thread regarding a real life GNU GPL license > > issue of one of suckless subscribers (the holy graal for me). The > > thread was immedialtly "stolen" and strayed away from its primary > > purpose. > > > Then I rebooted the thread, and ask the people to be nice and > > respect the purpose of this thread. Code license is important for > > all suckless software and, finally, and we have somebody able to > > reveal to suckless people a real life issue with the GNU GPL. > > This is reasonnably valid to be dealed and discussed by the > > suckless community. > > You started an entire thread when you only wanted an answer from one > person. On a topic you have to know is going nowhere, its even been > discussed on the suckless mailing lists before. > > I agree that this thread needs to die very soon. It's good advice on > account of there is no beneficial communication happening here. I firmely disagree with you on this: the event of somebody hurt by the GNU GPL with real life facts is of highest importance for all open source coders. And communication would have been an enrichment for the suckless community. The thread will die because I think those facts do not exist. > > Nobody has been able to pinpoint to me pertinent, real life, > > issues with the GNU GPL licenses that would make prefer MIT/BSD > > like licenses. The only thing I have got is, to summerize, > > "trust me, there are some". > > If you have some, I'll be pleased to read about them, because the > > issue from a subscriber seems top secret/classified (how > > convenient!) > > And hey! I cannot disagree on things I'm not told about yet! Come > > on :). I only can disagree on keeping it a secret, that's it. > > > I was happy, in a technical argument about choice of SDK build > > system, a "subcriber" swore to me he had real troubles with the > > GNU GPL. Again, when I'm about to get that intell, abracadabra, It > > disappears, and people are frowing eyebrows hard! > > The main argument is idealogical in nature. Whether the added > restrictions in the GPL are hurtful or not has never been proven, nor > will it likely ever be. Real examples will be something like "Party A > GPLs his code, Party B could improve it, but doesn't because he > disagrees with GPL/wants to use a different license, therefore the > world is deprived of an improvement to Party A's software". I don't > use GPL because I believe all restriction inhibits progress, and I > have to do extra work to make sure I never derive anything from a > GPL'd source, so GPL hurts me. "Whether the added restrictions in the GPL are hurtful or not has never been proven, nor will it likely ever be..." Thank you. Then you were right, it would have ended in public humiliation. (I don't debuck the quite common pro-BSD/MIT license example you selected above, it's of course completely biased, I was asked off-list to let go (bash?) all licenses issues from the list, you can ask me the details off-list). > Do a search on Google, lot's of people complain about GPL and give > good reasons for it. and valid arguments have been stated here as > well. Its an argument as old as the GPL itself, even you refered to > the disagreement between Stallman and Torvalds over the GPLv3, so you > _must_ be aware of some of the argum
Re: [dev] suckless distro
On Wed, Jun 25, 2014 at 08:12:10PM -0600, Anthony J. Bentley wrote: > Sylvain BERTRAND writes: >> Using a makefile is overkill. Should be a sh script. >> >> Makefiles should be used only when there are too many source >> files to recompile for a build increment. > > For an opinion that matters, try Kernighan & Pike (The Unix Programming > Environment, pg. 241): > > It's a nuisance to have to type two commands to compile a new version of > [our example]. Although it's certainly easy to make a shell file that does > the job, there's a better way, one that will generalize nicely later on > when there is more than one source file in the program. ... > > make is most useful when the program being created is large enough to be > spread over several source files, but it's handy even for something as > small as [our example]. > > In other words, one advantage that make provides is a simple interface for > building any program, whether small or large. Said interface should not > come at the cost of complexity, but good makefiles are simple anyway (the > one in their example is two lines). Well, I disagree on that point with Kernighan & Pike (The Unix Programming Environment, pg. 241). And come on... :) regards, -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Wed, Jun 25, 2014 at 09:32:33PM -0600, Anthony J. Bentley wrote: > Sylvain BERTRAND writes: >> I firmely disagree with you on this: the event of somebody hurt >> by the GNU GPL with real life facts is of highest importance for >> all open source coders. And communication would have been >> an enrichment for the suckless community. >> The thread will die because I think those facts do not exist. > > You have already been provided with the classical case, which you immediately > dismissed as "biased", no reason given. Other real-world examples, like the > gratuitous incompatibility of different GPL versions as in LibreDWG or Samba, > have been brought up on this list in previous discussions. I heard about GNU GPL version wars, was only aware of the benign Linus T. one. Let me laught: Do you really think a GNU GPL version war can reasonnably compensate the defect of code closing from MIT/BSD-like licenses. I'm not weak/stupid enough to let go the advantages of the protection of the GNU GPL for that. Please! I know what's the most important: protection against code closing. (Hey! I'm not going to stop driving a car because there are accidents) How can I get my hands on the libreDWG and Samba cases? Google? Suckless mailing list archive? -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Wed, Jun 25, 2014 at 11:35:39PM -0600, Anthony J. Bentley wrote: > Sylvain BERTRAND writes: > > On Wed, Jun 25, 2014 at 09:32:33PM -0600, Anthony J. Bentley wrote: > > > Sylvain BERTRAND writes: > > >> I firmely disagree with you on this: the event of somebody hurt > > >> by the GNU GPL with real life facts is of highest importance for > > >> all open source coders. And communication would have been > > >> an enrichment for the suckless community. > > >> The thread will die because I think those facts do not exist. > > > > > > You have already been provided with the classical case, which you > > > immediate > > ly > > > dismissed as "biased", no reason given. Other real-world examples, like > > > the > > > gratuitous incompatibility of different GPL versions as in LibreDWG or > > > Samb > > a, > > > have been brought up on this list in previous discussions. > > > > I heard about GNU GPL version wars, was only aware of the benign > > Linus T. one. > > > > Let me laught: > > Do you really think a GNU GPL version war can reasonnably > > compensate the defect of code closing from MIT/BSD-like licenses. > > Yes. Then, this is a weakness. I don't belong to the people with that weakness. But I do understand than the GNU GPL bashers will use those cases to leverage that weakness in others about plain GNU GPL versioning. I can from now warn open source devs about it, to help them build resolve against those people (usually the same type of hypocrites I was talking about in my previous message) who *will* leverage this fear. I have to thank you because I don't how that matter has been eluding me for so long. You are the first person to reveal to me clear cut issues with plain GNU GPL versions (*lesser* versions are fine). Well, there is the Linus T. thingy with the GNU GPLv3 but it's totally benign. Basically in the end, my GNU GPLv3 only driver module for linux *is* illegal. I have to admit it now since I got *finally* clear cut infos on that matter, and not vague and mere suggestions, like people feared I get interested in the subjet and build a defense against it... which now is built. I'll have to re-license my driver module to using the the linux GNU GPLv2. I'm not a moron like AMD catalyst devs or NVIDIA devs who do quite worse. When provided with the right and accurate information that clearly shows me something I did wrong, I clean my mess... if that information reached me early enough. That said, I was asked off-list to shutdown all my threads. If you want to know who and why, please ask me off-list. regards, -- Sylvain
Re: [dev] suckless distro
On Thu, Jun 26, 2014 at 01:04:09PM +0200, FRIGN wrote: > On Thu, 26 Jun 2014 05:30:04 +0200 > Sylvain BERTRAND wrote: > > > Well, I disagree on that point with Kernighan & Pike (The Unix > > Programming Environment, pg. 241). > > Why do you disagree? > > And before you go open a new thread, don't do it! A response is > sufficient. > > I consider this book the UNIX bible and recommend it to anyone > interested in starting with a un*x-os. > Also, if you have no points on your matter, don't fear to accept that a > certain solution can be very handy and way more flexible than writing a > shell-script instead, especially when it just tries to "emulate" a > makefile's functionality (like in your case). I stated my reasons earlier. Writting books does not make you immune to make technical choices that could be disagreed by members of the community. (don't let me start on Stroustrup...) That's would be too easy... I was asked to kill all my threads, including all this one. I'll do it. If you want to know who and why, just ask me off-list. regards, -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Thu, Jun 26, 2014 at 05:57:13PM +0900, Philip Rushik wrote: > On Thu, Jun 26, 2014 at 1:29 PM, Sylvain BERTRAND wrote: > > I heard about GNU GPL version wars, was only aware of the benign > > Linus T. one. > > > > Let me laught: > > Do you really think a GNU GPL version war can reasonnably > > compensate the defect of code closing from MIT/BSD-like licenses. > > I'm not weak/stupid enough to let go the advantages of the > > protection of the GNU GPL for that. Please! > > > > I know what's the most important: protection against code closing. > > > > Can I point out real quick that I addressed this? "Code closing" is a > terrible argument as I pointed out, MIT/BSD protects from "code > closing", even a public domain release would protect from "code > closing". > > This is the same logic that led to DRM and the DCMA. "Code closing" is a shorcut. Basically GNU GPL does forbid open code to be copied for use in closed source components (you have a middle ground with the *lesser* versions of the GNU GPL). I was asked off-list to shut down all my threads. If you want to know who and why, don't hesitate to ask me off-list. regards, -- Sylvain
Re: [dev] reboot, arrow in the knee because of the GNU GPL???
On Thu, Jun 26, 2014 at 06:01:08PM -0300, Amadeus Folego wrote: > Hadrian, > > please do not tell that you represent everyone, you don't. Also what you > just said is like your opinion, man. Indeed. As I was asked off-list, please, keep this thread shut down. Thank you.
Re: [dev] surf rewrite for WebKit2GTK
On Sun, Oct 26, 2014 at 01:15:04PM -0500, F Hssn wrote: > On Sun, Oct 26, 2014 at 12:34 AM, Andrew Hills wrote: > > On 10/25/14 13:41, F Hssn wrote: > >> > >> Following suckless's minimal philosophy, I'd be interested to find out > >> ... ... > >> latest webkit. > > > > > > Do you really want to write your own Javascript engine? > > > > Well, I hadn't thought of that but now that you mentioned, I > downloaded v8 and spidermonkey sources, 0.5 vs 1.2 million (both > mostly C++). Then in v8 I noticed it has directories for architectures > like arm arm64 mips mips64 ia32. I removed those directories and left > only x87 and x64 and ended up with 333k, with 223k lines of C++ source > files. > > To answer your question, I guess it comes down to how much time I have > (as always) which is, not much. But I would definitely like some > "suckless cleanup" in this direction, just like in other directions. There is also the c++->C port in order to help remove the c++ compiler/ABI/runtime non-sense from "suckless systems". But the real issue with javascript seems to be the dynamic bindings with a www renderer which is huge and insanely complex. This is the feedback I got from one of the netsurf coder. Netsurf is a www renderer, C coded (may have one or two ugly perl5 code generators in their SDK). With javascript support (very partial), it uses the spidermonkey before the mentally ill people at mozilla decided to move it to c++. -- Sylvain
Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)
On Fri, Oct 31, 2014 at 03:31:44PM +0100, Christoph Lohmann wrote: > What's needed for the next steps: > * Someone who knows any of the popular web rendering engines very well > and can modify them without ending up in psychiatry. Game over. There are only 2.5 "popular" and "usuable" open source www engines, webkit, blink (webkit-ish) and gecko. Those are far beyond the limit of sanity as those are brain damaged c++ object-oriented massive kludge. On Fri, Oct 31, 2014 at 03:31:44PM +0100, Christoph Lohmann wrote: > * The rendering engine needs to be modified to be reused for the points below. As I said before, after a little chat with one of the main netsurf dev, the current complexity of the web is due to javascript/the dynamic dom. > Anyone steps up? I would rather define which www sites are "critical" and go push hard for a 0-javascript basic html www portal and/or a *simple* web API (not OAuth which requires the use of one of the previous www renderers). I'll go to trial if I'm ignored. regards, -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 10:28:51AM -0500, Bobby Powers wrote: > Hello, > > Hiltjo Posthuma wrote: > > - Don't use C++ style comments (//). > > I personally find C++ style comments more pleasant on the eyes for > single-line comments, and they are part of the C99 spec. > > Can someone explain why they think /* */ sucks less than // ? It > doesn't seem like it is for compatibility when st and dwm require C99 > anyway. An internet search did not turn up much, apologies if I've > missed an obvious link or previous discussion. I'm external to the project, but here is my guess: cosmestic part of coding guidelines for that project. On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). My 2c. -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: > On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: > > On a personnal level, I port some of my C99 projects back to C89, since it > > seems a C89 compiler is easier to write than a C99 compiler, and some part > > of > > my code could go in C89 only project (i.e. the linux kernel). > > the linux kernel is built with gnu99 iirc. Documentation/HOWTO: "The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them." Then I guess, it would help to have a C89/C90 base code to start with instead of C99. I wonder how much of the linux kernel tinycc is able to compile. -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 05:27:06PM +0100, FRIGN wrote:
> If you take a look at C, everything is block-oriented. The smallest
> linguistic entity is "...;", followed by "(...)" and "{...}". The
> traditional comments "/*...*/" are part of this axiomatic system.
> This approach is not line-oriented.
I have to agree on that.
--
Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 05:09:44PM +, Dimitris Papastamos wrote: > On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: > > On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: > > > On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: > > > > On a personnal level, I port some of my C99 projects back to C89, since > > > > it > > > > seems a C89 compiler is easier to write than a C99 compiler, and some > > > > part of > > > > my code could go in C89 only project (i.e. the linux kernel). > > > > > > the linux kernel is built with gnu99 iirc. > > > > Documentation/HOWTO: > > "The kernel is written using GNU C and the GNU toolchain. While it > > adheres to the ISO C89 standard, it uses a number of extensions that are > > not featured in the standard. The kernel is a freestanding C > > environment, with no reliance on the standard C library, so some > > portions of the C standard are not supported. Arbitrary long long > > divisions and floating point are not allowed. It can sometimes be > > difficult to understand the assumptions the kernel has on the toolchain > > and the extensions that it uses, and unfortunately there is no > > definitive reference for them. Please check the gcc info pages (`info > > gcc`) for some information on them." > > It uses a *lot* of extensions. If I remember correctly, a significant number > of gcc extensions were initially driven by the needs of linux kernel > programmers. > > A C89 only compiler would have no hope to build the kernel in any way > so I do not see how C89 is relevant here anymore. 1 - because it's easier to port to C89/C90 + gnu extensions from C89/C90 than C99 (moving variable declarations back at the beginning of each block is already a pain) 2 - this is related to what I'm doing to my code, it was informational in order to help you do your choice. regards, -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 06:15:36PM +, Dimitris Papastamos wrote: > On Thu, Nov 06, 2014 at 06:40:15PM +0100, Sylvain BERTRAND wrote: > > On Thu, Nov 06, 2014 at 05:09:44PM +, Dimitris Papastamos wrote: > > > On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: > > > > On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: > > > > > On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: > > > > > > On a personnal level, I port some of my C99 projects back to C89, > > > > > > since it > > > > > > seems a C89 compiler is easier to write than a C99 compiler, and > > > > > > some part of > > > > > > my code could go in C89 only project (i.e. the linux kernel). > > > > > > > > > > the linux kernel is built with gnu99 iirc. > > > > > > > > Documentation/HOWTO: > > > > "The kernel is written using GNU C and the GNU toolchain. While it > > > > adheres to the ISO C89 standard, it uses a number of extensions that are > > > > not featured in the standard. The kernel is a freestanding C > > > > environment, with no reliance on the standard C library, so some > > > > portions of the C standard are not supported. Arbitrary long long > > > > divisions and floating point are not allowed. It can sometimes be > > > > difficult to understand the assumptions the kernel has on the toolchain > > > > and the extensions that it uses, and unfortunately there is no > > > > definitive reference for them. Please check the gcc info pages (`info > > > > gcc`) for some information on them." > > > > > > It uses a *lot* of extensions. If I remember correctly, a significant > > > number > > > of gcc extensions were initially driven by the needs of linux kernel > > > programmers. > > > > > > A C89 only compiler would have no hope to build the kernel in any way > > > so I do not see how C89 is relevant here anymore. > > > > 1 - because it's easier to port to C89/C90 + gnu extensions from C89/C90 > > than > > C99 (moving variable declarations back at the beginning of each block is > > already a pain) > > There's many instances in the kernel code where variables are not > declared at the beginning of the function block. Linus T. does let closed source modules live (even so the GNU GPLv2 gives legal power to open the code, or block binary blob distribution, like what happens with mpeg video or 3D texture compression), moreover the linux kernel is massive... Then I would not be surprised to see code note following Documentation/HOWTO or Documentation/codingstyle. The thing is *I* want *my* code ready to be easier to get into linux and to follow Documentation/HOWTO and Documentation/codingstyle. My 2c and you do whatever with it. cheers, -- Sylvain BERTRAND
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 10:17:44PM +, Dimitris Papastamos wrote: > On Thu, Nov 06, 2014 at 10:47:28PM +0100, Sylvain BERTRAND wrote: > > The thing is *I* want *my* code ready to be easier to get into linux and to > > follow Documentation/HOWTO and Documentation/codingstyle. > > I will leave you bathe in your fantasies now. ok... this is a troll... my bad. kisses all over, -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 08:34:40PM -0500, random...@fastmail.us wrote: >None of this has been examined by a court. It's because Linus T. and many core kernel devs decided not to go to court against closed source modules. The linux GNU GPLv2 has only the syscall exception and does not contain the "lesser" exception that would allow binary blobs to live below the syscalls. The syscall exception has been in there since the beginning I presume. Adding the "lesser" exception would be license change. Thus, nvidia ass holes can keep distributing their binary blob for linux, since linux is actually a GNU 'lesser' GPLv2 kernel which in *not* a plain GNU GPVv2. It's a balance of power issue: if linux wants to become a sensible alternative on the desktop, it must have a nvidia driver because they have a huge market share. Then, it was decided to let go... regards, -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Fri, Nov 07, 2014 at 10:30:20AM +0100, Silvan Jegen wrote: > There is the http://llvm.linuxfoundation.org/index.php/Main_Page llvm/clang is worse than gcc as it's from the start a massive c++ kludge. At least with gcc until its version 4.7, you can bootstrap its compilation with a C "only" compiler. They should add http://tinycc.linuxfoundation.org/index.php/Main_Page, since tinycc has the decency to be coded in C. :P -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Fri, Nov 07, 2014 at 04:01:28PM +0100, Alexander Huemer wrote: > On Fri, Nov 07, 2014 at 03:35:52PM +0100, Sylvain BERTRAND wrote: > > On Fri, Nov 07, 2014 at 10:30:20AM +0100, Silvan Jegen wrote: > > > There is the http://llvm.linuxfoundation.org/index.php/Main_Page > > > > llvm/clang is worse than gcc as it's from the start a massive c++ kludge. At > > least with gcc until its version 4.7, you can bootstrap its compilation > > with a > > C "only" compiler. > > Indeed, that fact isn't nice about clang. That fact is a definitive nono. I would reconsidere if re-written in C. I'm stuck with gcc 4.7.x -- Sylvain
Re: [dev] GCC situation
GCC 4.7.x can be bootstraped with a basic C compiler/runtime. >From GCC 4.8, you must have c++98 compiler/runtime, which is of several order of magnitude more costly from a technical point of view. For me, that reason is enough to start looking at other compilers (written/bootstrapable in C) and/or stick with GCC 4.7.x. -- Sylvain
[dev] [libutp-c] ISO C90-ish ports of bittorrent c++ libutp
Hi, A new "suckless" lib for bittorrent clients: libutp-c (https://github.com/sylware/libutp-c) Master branch: This is the old C api, which is a drop-in replacement for transmission bittorrent client libutp. I'm trying to make this implementation distributed as an option with transmission bittorrent client package. I'm getting high resistance from the "dev in chief": http://trac.transmissionbt.com/ticket/6065 (I have been running a modified libtransmission with libutp-c without any pb) upstream branch: This is the new C api. Ported from c++ recently but untested. I'll sync it and debug it once transmission bittorrent client code is updated to deal with libutp new C api. regards, -- Sylvain
Re: [dev] [libutp-c] ISO C90-ish ports of bittorrent c++ libutp
On Sat, Feb 06, 2016 at 12:54:10AM +0100, v4hn wrote: > On Sat, Feb 06, 2016 at 10:14:59AM +1100, Sylvain BERTRAND wrote: > > I'm trying to make this implementation distributed as an option > > with transmission bittorrent client package. I'm getting high > > resistance from the "dev in chief": > > http://trac.transmissionbt.com/ticket/6065 > > He is not "resisting". He simply wants to know whether you will > *maintain* your C port. He doesn't want to add a new dep if it > is dead code from the start. You didn't answer to that yet. Read my last post on their report tracker: you'll see it's unconsistent and irrelevant since, basically, the "official" current transmission old API libutp *is* dead code anyway (no updates for 3 years). He's asking me to maintain dead code, if I want to be hypocrit I would say yes :) (maintaining in sync dead code is 0-work). There are 2 libutps: dead and old API libutp, the *current* transmission one... and the rarely updated (see github) new API libutp, which is *not* the current in transmission. The focus of the current exchange is the *current* then dead libutp in *current* transmission. -- Sylvain
Re: [dev] [libutp-c] ISO C90-ish ports of bittorrent c++ libutp
On Fri, Feb 05, 2016 at 09:38:56PM -0200, Marc Collin wrote: > Nice project and a great thing for everyone (the less C++ garbage in > the wild the better). > Too bad the devs are showing resistance. > On suckless "stuff that rocks" page they btpd[0]. > Maybe it's saner to play with that instead, even though it's been > abandoned since 2012? I personally never used btpd, but if suckless > say it's good, it probably is :) > Best wishes. > > [0] https://github.com/btpd/btpd Hey! It seems to be a nice client! Thx for the tip! -- Sylvain
Re: [dev] [libutp-c] ISO C90-ish ports of bittorrent c++ libutp
On Sat, Feb 06, 2016 at 06:39:49PM -0200, Alba Pompeo wrote: > rtorrent is 40,000+ lines of C++. > Besides btpd, I found a client called Unworkable. But it's also unmaintained. > https://github.com/niallo/Unworkable Asynchronous code can be lovely. Good to know. Need DHT and crypto. But still, probably some good code to salvage and re-use! -- Sylvain
Re: [dev] [libutp-c] ISO C90-ish ports of bittorrent c++ libutp
On Sun, Feb 07, 2016 at 12:45:46PM +, Quentin Carbonneaux wrote: > On Sun, Feb 07, 2016 at 11:34:09AM +1100, Sylvain BERTRAND wrote: > > On Sat, Feb 06, 2016 at 06:39:49PM -0200, Alba Pompeo wrote: > > > rtorrent is 40,000+ lines of C++. > > > Besides btpd, I found a client called Unworkable. But it's also > > > unmaintained. > > > https://github.com/niallo/Unworkable > > > > Asynchronous code can be lovely. Good to know. Need DHT and crypto. But > > still, probably > > some good code to salvage and re-use! > > Hi, I did not really check-out what you had done but I have some DHT code I'm > willing > to give. It probably needs adaptations and was not really tested. It is > pure C. I think there is a DHT implementation in dhbt. Publish it somewhere and give us the link, who knows... :) -- Sylvain
Re: [dev] [ANNOUNCE] dtext-0.1: Font rendering library
On Sat, Feb 13, 2016 at 08:03:13PM +0100, Leo Gaspard wrote: > https://git.ekleog.org/dtext/ Hi, What is the scope of dtext in perspective of harfbuzz? Do you plan to support unicode for a maximum of languages? (heard thai and indi are tough). harfbuzz is c++ pure and raw brain fu**age (sorry for those words, but only that comes to my mind when thinking about c++). In order to, at least, remove the c++ dependency, I coded a partial ISO C90-ish port of harfbuzz (charfbuzz on github) as a drop-in replacement. The thing is that you would need to work on GUI toolkits to add backends for your lib (GTK+, EFL). -- Sylvain
[dev] [lnanohttp] nanonimal http server for linux
Hi, For my personnal use, I needed a small http server. All "mini" http servers out there I had a look were, IMHO, bloaty (SDK included). lnanohttp is really small (including dependencies and SDK), straight on linux kernel syscalls with a thin layer. Tested only on x86 and with a gcc/binutils toolchain for the moment (planing to buy an armv8 raspberry board). Can be use easily as a base for a beefier http server. https://github.com/sylware/lnanohttp https://repo.or.cz/lnanohttp.git regards, -- Sylvain
Re: [dev] [lnanohttp] nanonimal http server for linux
On Wed, Apr 20, 2016 at 07:46:38AM +0200, Anselm R Garbe wrote: > On 20 April 2016 at 05:17, Sylvain BERTRAND > wrote: > > For my personnal use, I needed a small http server. All "mini" http servers > > out > > there I had a look were, IMHO, bloaty (SDK included). > > Did you also look at http://git.suckless.org/quark/tree/quark.c ? Nope. Missed that one. :( As a member of the suckless collective: shame on me. > quark is fork() based (and POSIX compliant in that sense) though, not > epoll_wait() based. So quark will perform accordingly, but it supports > a bit more HTTP features (incl. cgi execution), but its SLOC is > considerable equal to lnanohttpd. lnanohttp is enough for my personal use (static content). cgi is already too much. It's easy to add clone(fork/thread)/cgi/(and more). In ulinux/patterns there is code of a "network server" which does the cloning stuff, even "pre-cloning" (pre-fork/pre-thread spawning). Just need to adapt the code. But it's way beyond my needs. > > lnanohttp is really small (including dependencies and SDK), straight on > > linux kernel > > syscalls with a thin layer. Tested only on x86 and with a gcc/binutils > > toolchain for the moment (planing to buy an armv8 raspberry board). > > > > Can be use easily as a base for a beefier http server. > > Some quick remarks: it uses a lot of #define's (all over the place) > which I consider very weird. Also for type declarations it uses > #define's of types which seem to be very weird as well. (e.g. #define > sl ulinux_sl). The defines are used to manage namespaces. ulinux thin layer has its own namespace in order to be mixed with other namespages (libc/posix/etc). > Also is relying on -errno checks all over the place really secure? I > would rather check for -1 and compare with errno directly. Or is it a > linux pattern I wasn't aware of? quark pulls the posix libc. lnanohttp has 0 deps: this is straight linux syscalls programming, there are no libc syscall wrappers. Now, I need to find bugs... :) -- Sylvain
Re: [dev] [lnanohttp] nanonimal http server for linux
On Wed, Apr 20, 2016 at 09:39:43AM +0100, Dimitris Papastamos wrote: > On Wed, Apr 20, 2016 at 07:05:09PM +1100, Sylvain BERTRAND wrote: > > quark pulls the posix libc. lnanohttp has 0 deps: this is straight linux > > syscalls programming, there are no libc syscall wrappers. > > What's wrong with libc? Overkill, don't need it.
Re: [dev] [lnanohttp] nanonimal http server for linux
On Wed, Apr 20, 2016 at 03:09:20PM +0100, Dimitris Papastamos wrote: > On Thu, Apr 21, 2016 at 12:22:42AM +1100, Sylvain BERTRAND wrote: > > On Wed, Apr 20, 2016 at 09:39:43AM +0100, Dimitris Papastamos wrote: > > > On Wed, Apr 20, 2016 at 07:05:09PM +1100, Sylvain BERTRAND wrote: > > > > quark pulls the posix libc. lnanohttp has 0 deps: this is straight linux > > > > syscalls programming, there are no libc syscall wrappers. > > > > > > What's wrong with libc? > > > > Overkill, don't need it. > > > > You should have revived kHTTPd[0] instead. > > [0] http://www.fenrus.demon.nl/ Mine is user space. This one is kernel space.
Re: [dev] [lnanohttp] nanonimal http server for linux
On Wed, Apr 20, 2016 at 04:39:05PM +0100, Dimitris Papastamos wrote: > On Thu, Apr 21, 2016 at 01:18:12AM +1100, Sylvain BERTRAND wrote: > > On Wed, Apr 20, 2016 at 03:09:20PM +0100, Dimitris Papastamos wrote: > > > On Thu, Apr 21, 2016 at 12:22:42AM +1100, Sylvain BERTRAND wrote: > > > > On Wed, Apr 20, 2016 at 09:39:43AM +0100, Dimitris Papastamos wrote: > > > > > On Wed, Apr 20, 2016 at 07:05:09PM +1100, Sylvain BERTRAND wrote: > > > > > > quark pulls the posix libc. lnanohttp has 0 deps: this is straight > > > > > > linux > > > > > > syscalls programming, there are no libc syscall wrappers. > > > > > > > > > > What's wrong with libc? > > > > > > > > Overkill, don't need it. > > > > > > > > > > You should have revived kHTTPd[0] instead. > > > > > > [0] http://www.fenrus.demon.nl/ > > > > Mine is user space. This one is kernel space. > > You don't understand humour. Who's humour?
[dev] [lnanohttp] content-type support
Hi, Added easy http content-type support to please www browsers like w3m and netsurf. https://github.com/sylware/lnanohttp http://repo.or.cz/lnanohttp.git cheers, -- Sylvain
Re: [dev] "Note On Webkit Versions"
The main issue is java/ecma script on the "www DOM" (Document Object Model): Between noscript www browser code requirements and script-able www browser code requirements, there is an abyss in size and complexity. Additionnaly, the "modern" www tends to force the user to have a script-able www browser, even though many www sites could provide their services with a noscript www browser through a cleverly crafted main www portal or a dedicated noscript www portal on the side of the main (with all bells and whistles) www portal. ^ | That's where the real fight is For instance, youtube could provide a noscript www portal with and/or html elements. EZ and reasonable to implement even for inexperienced coders around the globe. But no. You _must_ have a script-able www browser to enjoy youtube (the terms of use even forbid users to employ anything else in order to watch/listen to a video/audio stream). I have to admit, html needs a little extension to / in order to support split video/audio streams. Basically, we would need a simple html-ed "DASH" manifest. But vp[98]/opus high/med/low qualities video/audio combined streams should be enough in most cases. (remainging cases would be handled with the standard "download then view" way). Another example: online banking. http, xhtml1.1 and css2.1 with basic forms are hell enough to provide banking services to www users. But no. You _must_ have a script-able www browser. And lately, it does apply to "verified by visa" and online payments... Sometimes, it does not work. For instance, soundcloud. Soundcloud needs a rich GUI to provide its services. But they could provide a simple http API to let people have their own GUI components. Many www sites have their www APIs, but need a redirection on a script-able www browser on the side for authentication... Ooops! You have only 2.5 modern open source engines which "can run the www": - webkit (massive and c++ is brain damaged) - blink (webkit google's fork, see above) - gecko (firefox, massive and c++ is brain damaged) BTW, I wonder if there is a http/mime way for a www browser to tell a http server: "noscript please". There is a team working on a C implemented www browser: netsurf. I got a little chat with one of its devs: "www DOM dynamicity through script is insane". cheers, -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Sat, Apr 30, 2016 at 12:47:36PM +0200, Kajetan Jasztal wrote: > how about servo[1]? aims for memory security and fast parallel rendering > > [1] https://servo.org/ At least servo can be compiled with a simple ISO C99 compiler and limited SDK... unlike gcc with its mandatory ISO c++98. -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Sat, Apr 30, 2016 at 08:53:35PM +0200, Anselm R Garbe wrote: > [0] http://www.netsurf-browser.org/ I was looking at netsurf to add the javascript/DOM bits required for online banking (my bank account and online payement). But it seems rather not that easy to get into it. I will give it another try later. -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Sat, Apr 30, 2016 at 04:09:28PM -0700, Menche wrote: > On Sun, 1 May 2016 10:04:37 +1100 > Sylvain BERTRAND wrote: > > > On Sat, Apr 30, 2016 at 12:47:36PM +0200, Kajetan Jasztal wrote: > > > how about servo[1]? aims for memory security and fast parallel rendering > > > > > > [1] https://servo.org/ > > > > At least servo can be compiled with a simple ISO C99 compiler and limited > > SDK... unlike gcc with its mandatory ISO c++98. > > > > It can? I thought rustc used LLVM, which is in C++. Last time I read some rust advocacy (maybe slashdot... ahem...), they were proud of having a simple SDK and being compilable with a simple ISO C99 compiler. Wrong? -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Sun, May 01, 2016 at 11:58:36AM +0200, Sanel Zukan wrote: > Kamil Cholewiński writes: > > Bad stuff: > > > > - C++, autohell, pthreads > > pthreads are bad? Really? c++ is _really_ bad, indeed. > dependencies (gtk, I look at you). https://github.com/sylware/misc/blob/master/gtk-utox/gtk-utox.sh cheers, -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Sun, May 01, 2016 at 05:20:08PM +0200, Sanel Zukan wrote: > Sylvain BERTRAND writes: > >> pthreads are bad? Really? > > > > c++ is _really_ bad, indeed. > > I think I mentioned pthreads, not c++ :) Anyway, c++ is still _really_ bad and light years away from suckless philosophy. Have a look at the EFL/enlightenment (without physics). -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Sat, Apr 30, 2016 at 10:24:31AM +1100, Sylvain BERTRAND wrote: > Additionnaly, the "modern" www tends to force the user to have a script-able > www browser, even though many www sites could provide their services with a > noscript www browser through a cleverly crafted main www portal or a dedicated > noscript www portal on the side of the main (with all bells and whistles) www > portal. > > ^ > | >That's where the real fight is > > For instance, youtube could provide a noscript www portal with and/or > html elements. EZ and reasonable to implement even for inexperienced > coders around the globe. But no. You _must_ have a script-able www browser to > enjoy youtube (the terms of use even forbid users to employ anything else in > order to watch/listen to a video/audio stream). I have to admit, html needs a > little extension to / in order to support split video/audio > streams. Basically, we would need a simple html-ed "DASH" manifest. But > vp[98]/opus high/med/low qualities video/audio combined streams should be > enough in most cases. (remainging cases would be handled with the standard > "download then view" way). Actually, I thought again on this html-ed "DASH" manifest. It would be useless. Just need a "DASH manifest" mime type in the or elements and let the media infrastructure handle it. Youtube has no more excuses. -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Mon, May 02, 2016 at 12:14:20AM +0200, FRIGN wrote: > C is definitely not suckless either, especially when it comes > to UB, but it's probably the language with least suck and > highest simplicity while giving the most power to the developer. +1 :) -- Sylvain
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Mon, May 02, 2016 at 11:12:08AM +1000, Timothy Rice wrote: > > C is definitely not suckless either, especially when it comes > > to UB, but it's probably the language with least suck and > > highest simplicity while giving the most power to the developer. > > Not too long ago I expressed support for C as a way to obtain very fast > programs; the context is I work around people who are interested in stat > mech, MCMC, simulations of complex systems, etc. > > A more experienced developer replied that in fact Go has comparable speed > to C but does not lead to the same memory management challenges, thus > should usually be preferred. It appears that most interest in C these days > is from people who need to work with Arduinos. > > So, while we're on the (off-)topic of comparing the suckiness of various > languages, what do people here think about Go? When you want to promote a new language: 1 - write a boostrap compiler (for kernel profile and other profiles) in the current "system language" (I guess C, but gcc is now at least c++98). 2 - write a usable kernel with your language (kernel profile). 3 - write a compiler for that new language using this new language (all profiles). The first components which should be written using this new language are the basic system components *and the kernel*. They all epic-ly fail at the kernel step. There is zero perfect languages. There are already tons of unperfect languages out there: C, D, haskell, python[23], ruby, perl, guile, java, c++, swift, javascript, ml family, php... each with tons of frameworks and variations. No syntactic sugar/comfort from those will account for the technical cost increase of the software stack, already screaming in pain because of their sheer number. Basically they are no significant points to diverge from C (max ISO C99). I'm actually thinking that nowadays, diverging from simple C, is hurting the software stack. It's by far the best compromise. -- Sylvain
Re: [dev] "Note On Webkit Versions"
On Sun, May 01, 2016 at 01:23:54PM +0200, Sanel Zukan wrote: > Mitt Green writes: > >> but find me portable and usable C UI toolkit > >> without tons of dependencies > > > > Tcl/Tk > > Hell yeah +1 Tk x11 widget toolkit needs Tcl scripting language... Not a lean set of C libs... :( -- Sylvain
[dev] C, gcc and armv8
Hi, Just to raise awareness on this issue: - gcc is now c++98 boot-strapable only. - The last C boostrapable gcc is gcc 4.7.x. - armv8 (64bits, raspberry 3) support is only in lastest gcc (i.e. _not_ in gcc 4.7.x) It means you cannot natively compile gcc on armv8 from a basic C compiler, for instance tcc, anymore. That loop is closed. More and more c++ applications out there now requires a c++14 compiler (mame, inkscape, soon gecko? webkit?), reasonnably only a recent gcc (_not_ gcc 4.7.x) can compile them properly. And wait for c++17... That loop is almost closed now. -- Sylvain
Re: [dev] C, gcc and armv8
On Mon, May 02, 2016 at 09:00:30AM +0200, Anselm R Garbe wrote: > Hi there, > > On 2 May 2016 at 07:25, Sylvain BERTRAND wrote: > > Just to raise awareness on this issue: > > > > - gcc is now c++98 boot-strapable only. > > Where do you have this information from? http://gcc.gnu.org/install/prerequisites.html and I did try with versions above 4.8. > At least to me it looks like that gcc-5.3.0 is still bootstrappable > without any g++ call as long as you are not targetting to build C++ > support. Weird. -- Sylvain
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Mon, May 02, 2016 at 03:47:06PM +0200, Leo Gaspard wrote: > On 05/02/2016 04:40 AM, Sylvain BERTRAND wrote: > > On Mon, May 02, 2016 at 11:12:08AM +1000, Timothy Rice wrote: > >>> [...] > > > > > > When you want to promote a new language: > > 1 - write a boostrap compiler (for kernel profile and other profiles) > > in the current "system language" (I guess C, but gcc is now at least c++98). > > 2 - write a usable kernel with your language (kernel profile). > > 3 - write a compiler for that new language using this new language (all > > profiles). > > > > The first components which should be written using this new language are > > the basic system components *and the kernel*. > > > > They all epic-ly fail at the kernel step. > > > > You mean redox is an epic fail? Or did I misunderstand this statement? No. You do shorcuts in order to troll. Hurd? -- Sylvain
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Mon, May 02, 2016 at 04:29:11PM -0700, Andrew Gwozdziewycz wrote: > Given this effort, and the fact that they've gotten pretty damn far > towards being usable, I'd say you can't *possibly* argue that "they > all *epic-ly* [sic] fail at the kernel step." (emphasis mine). Like Hurd. > Of course, you didn't mention rust in your initial list of "unperfect" > languages rust is better than go, or the other way around? Fight! (while I go code something in a subset of C). :) -- Sylvain
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Tue, May 03, 2016 at 10:16:31AM +0200, Leo Gaspard wrote: > The fact remains: rust has had approx. 1/26 times the time hurd, and > 1/25 times the time linux had to develop. Do you think it's fair to > already consider it's an epic fail? Ok, you won the troll. Wait and see. In the mean time I'll go back coding something using a subset of C syntax, C which is already too rich and complex. -- Sylvain
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Tue, May 03, 2016 at 07:35:46PM +0200, Markus Teich wrote: > Heyho, > > seeing the new subject I feel obligated to leave this link here: > https://www.destroyallsoftware.com/talks/wat Yeah, ruby is better than go, for sure in my experience. -- Sylvain
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Wed, May 04, 2016 at 09:19:06AM +1100, Sylvain BERTRAND wrote: > On Tue, May 03, 2016 at 07:35:46PM +0200, Markus Teich wrote: > > Heyho, > > > > seeing the new subject I feel obligated to leave this link here: > > https://www.destroyallsoftware.com/talks/wat > > Yeah, ruby is better than go, for sure in my experience. Oops! I made a mistake, I thing javascript is safer and better than ruby... (don't let me start on the incredible quality of php...). Wait! Were we talking about rust? I'm sorry for the python 3 guys or python 2 guys, I cannot remember which one is mandatory for rustc SDK. BTW, rustc SDK needs a little c++14 or c++17 compiler/runtime? Wow! I just realize that this massive mess makes me feel really safer now. The world is saved. Gladly going to shoot myself in the foot while coding something in a subset of C. I'll fix the holes in my foot over time. That is less painful than to deal with this mess. mmmh... maybe not, I'll suffer maybe a lot more when I'll compile a recent linux for armv8 with tinycc (raspberry model 3). -- Sylvain
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Tue, May 03, 2016 at 07:10:02PM -0400, Alex Pilon wrote: > > > seeing the new subject I feel obligated to leave this link here: > > > https://www.destroyallsoftware.com/talks/wat > > > > Yeah, ruby is better than go, for sure in my experience. > > Great. Yet another poorly specified or documented language. Just what we > need. That was sarcasm. I can keep going: are you sure it's not D or haskell which is poorly defined, probably go or python then. Heard objective-c (or objective-c++ I don't recall is magnificiently defined, that's why apple used id. Probably a kernel written in objective-c would have been safer. -- Sylvain
[dev] [lnanosmtp]
Hi, Introducing a new minimal and naive smtp server à la suckless: lnanosmtp https://github.com/sylware/lnanosmtp https://repo.or.cz/lnanosmtp.git cheers, -- Sylvain
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 02:03:33PM +0200, Kamil Cholewiński wrote: > On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: > > Hi, > > > > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > > > https://github.com/sylware/lnanosmtp > > https://repo.or.cz/lnanosmtp.git > > > > cheers, > > > > -- > > Sylvain > > Ages old, stupid question. What's wrong with libc? Overkill, don't need that much. -- Sylvain
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 02:04:07PM +0200, FRIGN wrote: > On Thu, 9 Jun 2016 22:50:56 +1100 > Sylvain BERTRAND wrote: > > Hey Sylvain, > > > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > > > https://github.com/sylware/lnanosmtp > > https://repo.or.cz/lnanosmtp.git > > I looked at the code and wondered: what the hell is ulinux? :P userland linux: kind of linux uapi headers and little bit more. -- Sylvain
Re: [dev] [lnanosmtp]
On Thu, Jun 09, 2016 at 07:18:21PM +0200, Markus Wichmann wrote: > 3. smtp_line_send() can't handle short writes, because the pointer that > is handed in as second argument to write() is never advanced... Fixed. Thx! -- Sylvain
Re: [dev] JIT & VM discussion
C JIT->have a look at tinycc from F. Bellard. llvm is c++ then, by definition is not suckless and a massive brain damaged kludged. cheers, -- Sylvain
