Re: [dev] sbase installed first impressions
On Mon, 3 Oct 2016 17:23:50 -0400 stephen Turner wrote: Hey Stephen, > Background first. I'm running a simple kernel, busybox, make, pcc, > musl, binutils (patched for ash) environment. Its run from ram so i > can trash the environment as many times as i care to reboot. That > being said I decided to install suckless in place allowing it to > overwrite the busybox links just for kicks. So far just sbase was > installed. > > I had to tweak the config.mk (expected i assume?) > PREFIX=/ > MANPREFIX=/usr/local/share/man (keeping with suckless default here, > removed variable) > CC=pcc > LDFLAGS= (removed -s as it was not supported) yes, it is expected to change config.mk for your environments. in 99% of the cases you don't need to change the defaults though. > It compiled and installed faster than expected but then the code was > smaller than expected too, very impressive size! Immediately i decided > to check and see if it overwrote the busybox links and it did but i > also noticed there is no color or column views? Reviewing the Readme > shows that color isn't listed as one of the removed features just fyi > unless it has a short hand from --color that i didn't know. This is because color is not part of Posix, but a GNUism. For column views, use the cols(1) utility that is shipped with sbase. There is no reason to implement that in each single utility. Just invoke ls | cols as you already found out yourself. The Unix philosophy states that you should have one tool that does one thing and does it well; in this case this is cols(1) whose only job is to columnize output. ls(1) is complex enough already, so we really don't want to worry about columnizing output as well. > I have never had ls without color or column included (i'm spoiled) and > google isn't being overly helpful at the moment. I found the cols > command and ls | cols solved that so i can just create an alias, what > about getting color? Is there a suckless solution? The suckless solution is just not to use color at all. It takes a while to get used to, but it's really not necessary. It's like syntax highlighting. > I see a few items have the -i removed, I can't say i use the > interactive mode but i assume you removed it due to redundancy and so > i'm curious how you would normally do that the suckless way. There is no compelling reason for interactive mode. rm(1) for instance is a tool and you should just use it properly. Give it the proper arguments and be done with it; write a thin wrapper script if you really want an interactive mode, but there really is no reason to have it. It's a gimmick, but maybe you can give really compelling reasons to include it. > Otherwise i haven't used it much but seems to be just as expected, a > gnu comparable cli. I need to update my scripts and then i will start > using this instead of busybox. I'm glad you like it! If you find any bugs, please report them! Cheers FRIGN -- FRIGN
Re: [dev] slcon 2016 videos are online
On Tue, 27 Sep 2016 15:42:01 +0200 Silvan Jegen wrote: > As far as I know that is a way to show appreciation for talks at > universities (at least in Switzerland). Same in Germany. :) -- FRIGN
Re: [dev] name for ii-like chatting
On Tue, 27 Sep 2016 14:49:14 +0200 Martin Kühne wrote: > Why not carry the IRC back into the name and make it binoirc or even > birco? Or maybe just birc. :D -- FRIGN
Re: [dev] name for ii-like chatting
On Tue, 27 Sep 2016 14:09:30 +0200 Jan Klemkow wrote: Hey Jan, > I am programming on front-end and back-end tools for ii for several > years now. For the back-end I use UCSPI[0] (Unix Client Server > Program Interface). But there is no name for the front-end of tools > like ii[1], ratox[2], sj[3] or jj[4]. I used the term "ii-like" in > my talk at the slcon3, because ii was the first of its kind. But, I > am unhappy with this term and looking for a better word or phrase > which fits to this kind of interface. I personally do not like the name UCSPI, because it doesn't roll of your tongue and sounds like a proprietary Broadcom firmware interface. However, given it is a few years old and kind of established it is okay to stick with it. > Do you have any ideas of a name for the ii-like front-end interface? I have been thinking about the name ii for a moment and when you pronounce it you say "eye-eye", so we can think of a rhetorical figure to describe paired vision (called stereopsis or binocular vision). The nice word "bino" has already been taken by a 3d video player[0], however, "bioc" or "binoc" might be nice memorable names for the frontend interface (and easy to type). Cheers FRIGN [0]: http://bino3d.org/ -- FRIGN
[dev] slcon 2016 videos are online
Hello fellow hackers, the videos of this year's suckless conference in the webm format are online. You can view them on the conference page[0]. Cheers FRIGN [0]: http://suckless.org/conferences/2016 -- FRIGN
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016 17:56:24 +0200 Kamil Cholewiński wrote: Hey Kamil, > Thanks for the tip! I'll share this with our IT dept. are you being sarcastic? Of course you can't use it for corporation-size investments, but for personal stuff, it really works out. As an added bonus, I think that when I see something on Amazon I would much rather buy something I don't need with a CC or PayPal than going to the store and buying the gift cards, as on the way to and from the store I have time to re-think the upcoming purchase. Just like they're trying to take the ready cash from us to force us into quick buying decisions with our credit cards, Apple Pay and other NFC technologies, PayPal and possibly implanted microchips in the future, buying things on the web are designed the same way. Of course you can't pay with cash online, but it makes sense to think about alternatives that come as close as possible, namely giftcards. Cheers FRIGN -- FRIGN
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016 16:38:43 +0200 Kamil Cholewiński wrote: Hey Kamil, > You're more-or-less without a choice if you want to do online banking. > Also safety in numbers. 99% of the cases of people getting pwned are > because they open random links and don't look at their fucking address > bar. yes. > Yes, because a three digit code printed on the back of your CC, that > changes once in every 3-5 years, and that gets shared with three dozen > different vendors, is s mch beeetteeer. Exactly! > When I want to shop for stuff needed at $WORK, basically I can no > longer even look at Amazon, because we were getting CC frauds every > few months. 10 years of dealing with my bank's crappy JS and SMS > codes and I haven't been robbed off a single grosz. A good way to shop at Amazon is with gift cards. You can charge up your account to a certain baseline (e.g. 100 bucks) and then shop as you wish, with no trouble of cc frauds and all this crap. Amazon has no banking info on you but still it is really easy to manage. If you buy a bigger item, you just go to the store, get a few of the 100 buck gift cards, type the code in in no time (even faster than your cc card number) and it's all good. If you send an item back because you didn't like it, Amazon will automatically put the credit back on your gift card balance. Cheers FRIGN -- FRIGN
Re: [dev] several questions
On Tue, 20 Sep 2016 22:04:05 -0400 Greg Reagle wrote: Hey Greg, > Would you mind explaining specifically what you mean by "not > portable"? It is my understanding that it works on a lot of Unix-like > operating systems and that it is highly portable. the thing is that 99.9% of people on Linux or the *BSDs don't even have rc available. I don't think one should force users to install 9base just so they are able to run packaging scripts or other scripts of some sort. Of course, given there is only one implementation, it is highly portable per-se, given the interpretation is equal everywhere and 9base is quite easily portable. Cheers FRIGN -- FRIGN
Re: [dev] several questions
On Tue, 20 Sep 2016 16:32:18 -0400 stephen Turner wrote: Hey Stephen, > On your site i see you have tested compiling your system with PCC > and i also see a SCC in dev. What was the reason you chose to write > SCC? Is it due to PCC's reliance on lex, yacc and m4? The last PCC release (1.1.0) was in 2014. Of course, this does not mean much, but it does not receive any major attention as of late. Additionally, and I can't speak for Roberto here, the goals of scc go in a different direction. Stay tuned for Roberto's talk at slcon3. > Bash and Make, I'm looking for compatible replacements for these. As > i currently understand it bash at the least is expected to compile > the linux kernel. Is there any suitable projects that you may have > seen around the net or considered a bash rewrite? I see you recommend > mksh and dash but neither have bashisms that some projects seem to > expect. Just don't use bash, but the Posix shell. Use the "#!/bin/sh"shebang and test your scripts with shellcheck[0], which is also pretty reliable in detecting bashisms. Some people would recommend rc (by Plan9), but it's definitely not portable and most unixoid OSes offer it. For make: Some people recommend mk, I'd recommend just being aware of GNUisms for make and try to make it portable (it's not difficult). > I found libre linux where they clean out the "globs" and tiny linux > but i was wondering if there was a new linux kernel cleanup project > somewhere? I'm sure you mean "BLOBs", which are binary chunks of proprietary machine code. To be honest, I don't mind that running in my system, however, in the long run one should try to select hardware that is not requiring BLOBs in the first place (Broadcom is a sinner in this regard). All this "Libre" bullshit with projects to "clean up" the Linux kernel don't achieve anything beyond ideological satisfaction. Stop singing the false song of "Libre Software" and rather make smart decisions in life. If you end up configuring your Kernel yourself and remove everything you don't need in the first place (including all drivers with BLOBs), your compilate won't contain BLOBs as well. With best regards FRIGN [0]: https://www.shellcheck.net/ -- FRIGN
[stali] Purpose (was Re: [dev] Re: [stali] updating package source)
Hello fellow hackers, > concentrate on the essence here, this is all a waste of time. - hiro to be fair and meaning no offense to anybody, I think stali in general is a waste of time. It is too ambitious given the low manpower and the hypetrain, if I may call it so, is just pissing people off when they hear 1. how long ago this has been announced, still being vaporware to this day 2. how "many" people are working on it 3. how overambitious it is (rewriting makefiles for base, ...). When discussing this topic so openly I often have to hear that I was just being grumpy and not for the project. Of course I'd love to see a suckless Linux distribution which actually does things differently and is not just a rebranded Debian with slight modifications. However, I know first hand what a dump of work package maintainership is, and I know many people here do as well. The Morpheus package scripts were a good approach to the problem but the manpower involved in porting this stuff and making it work was huge, and it takes all your honesty to admit that we at suckless are just not enough people to pull this off. It may have worked 10-20 years ago when it wasn't all such a mess, but just look at how the situation is today. The only Linux package manager which really does dependencies right is portage, even when the dependency trees are huge. And it also makes it really easy and straightforward to create cross compilers, which is usually a huge mess. I see suckless's purpose in creating simple, high quality and useful user software. The reason why it works out and has worked out with so few people is because we keep our code simple and thus can bear maintainership even of multiple projects at once for one person. With package management, this is different. If you stick your hands in a pile of cow feces, your hands will get dirty, no matter what you do. Get real guys, there are enough projects with TODO items in our repos; we really need to stop doing things that are definitely above our heads. Not because they are too "difficult", but because they just eat up time, unless you spit out makefiles in 10 seconds each. Rewriting the build systems for other projects and maintaining them along the line is borderline insane. With best regards FRIGN -- FRIGN
Re: [dev] Djvu viewer
On Wed, 14 Sep 2016 03:48:33 +0300 ilab...@gmail.com wrote: > As for patents and stuff, it is true that DjVu is somewhat more free > and provides reference implementation that can both read and write > files. PDF is an industry standard and I will not ditch it for DjVu which only seems to be popular in very tight spaces. I know, PDF is hard to render and the renderers are bloated, but we have to live with it. We used to piss on people for sending us docx's instead of pdf's, now we need to change the format we're working on again? No thanks. -- FRIGN
Re: [dev] [sbase] [paste.c] misleading indentation?
On Tue, 6 Sep 2016 09:37:09 +0200 Kevin Michael Frick wrote: > GCC, probably. Which sucks, but if Hitler warns you not to step of a > cliff, you don't ignore his warning because he is Hitler. I can understand the point you are making about GCC, but what is wrong with Hitler? /s -- FRIGN
Re: [dev] lnano[http|smtp] ipv6
On Fri, 2 Sep 2016 06:36:54 +0200 Markus Wichmann wrote: Hey Markus, > Oh come on, it's all of five minutes' work to compile this software > against any libc you want. And all of an hour's work to replace all > the printf() calls with something reasonable and reduce binary size > way further than this custom libc thing, BTW. or instead I just use sane programs who don't deploy NiH-solutions. And it would be much more work than that. All the socket stuff is very far away from how Posix describes it. Cheers FRIGN -- FRIGN
Re: [dev] lnano[http|smtp] ipv6
On Thu, 1 Sep 2016 21:53:21 +0200 Sylvain BERTRAND wrote: Hey Sylvain, > Added IPv6 to lnanohttp and lnanosmtp: how do you expect anyone to use your software when you ship your own "libc" called "ulinux"? Why would I use this piece of software when it's unportable and only available for x86 and x86_64 linux? Cheers FRIGN -- FRIGN
Re: [dev] [sbase] about audit
On Thu, 1 Sep 2016 12:34:12 -0300 Marc Collin wrote: Hey Marc, > Yeah, I'm not complaining about the audits, I remember they found > many bugs! It was just a random thing that came to me - normally a > person that makes a mistake will overlook the mistake. But someone > from the outside should spot it more easily. > I don't even know if this is true, but I think it is based on self > experience. And I think the message was good, since now Ali H. Fardan > decided to go through the code too. > In the end everyone wins :) the fault was a bit at me because the audit-patches were so big and nobody would be arsed to check the mall. However, nobody stops you from subscribing to hackers@ and receiving all the commits. Open Source lives from many eyes checking changes. > Since we're talking about sbase already in kind of meta way, I'll post > a question here instead of a new email. > sbase is basically ready, right? The few missing tools are not yet > applied, but were sent to the ML by maandree some months ago (patch, > diff and others). Should we expect a release soon? I'm excited :) Oh well, this is a difficult topic. Sbase has received a lot of work and it works better in some respects than the GNU coreutils. Aside from sed, ed and grep the tools are well-audited and I am confident they can be used in everyday life. However, there are still some things to do, but it's really not something preventing a release. Up to this point, we have not gotten around for doing a release because there is always something that can get in the way. Most prominently, nobody wants to make a release only to get a bug report the next day for a critical problem in some tool. We tested the sbase tools extensively, but some bugs just show up after heavy usage or deployment. In some respects, sbase is almost too ambitious for the given manpower. An important point for instance is the UTF-8/Unicode stuff. I expanded libutf to support proper case conversions, but we are still lacking in detecting grapheme clusters and multi-codepoint case conversions. This all depends on my redevelopment of libutf that is currently in the works, but given some personal things I have not gotten around to it in the last few months and thus development kinda halted. Cheers FRIGN -- FRIGN
Re: [dev] [sbase] about audit
On Thu, 1 Sep 2016 11:46:36 -0300 Marc Collin wrote: Hey Marc, > The missing brackets on paste.c that I talked about on the last > message revealed something else to me. > > It was introduced in commit cdbc0d50356a0f7e0dd5755e3c46593a947cf029 > by FRIGN, 2015-01-29. > > Then it was marked as audited and correct in commit > 1bc002b44acdbfec8d374bfd0e5a858a142c0378 also by FRIGN, 2015-03-17. > > This makes me think that a file should not be audited by a person that > had many contributions to it. Because if the person missed something > at first, it's likely she will miss something again. Someone else that > thinks in different ways is more likely to find errors. > > So I think files should be audited by third-parties or at least by > more than 1 person before being marked as audited. This way there are > less chances of passing a files as audited when there are still > errors. > > Just to make it clear, I'm not criticizing FRIGN. This happens to > everyone. It's *much* harder to find your own bugs, but easier to find > other's bugs. That's what I think. yeah sorry for introducing this. Mistakes happen. Overall, the audits fixed many many bugs though, so it's pain that can be taken. Send a patch to fix it and everything is cool. :) Cheers FRIGN -- FRIGN
Re: [dev] Re: [dwm] Crash when setting window title to a single emoji
On Wed, 31 Aug 2016 15:29:25 +0200 Markus Unterwaditzer wrote: Hey Markus, > Here's another one that fails: > > PROMPT_COMMAND='echo -ne "\x1b]0;\xf0\x9f\xa4\x94\x07"' > > taken from: > > https://twitter.com/djm_/status/770938881206317056 > > I seriously do wonder if anybody can reproduce this. I can on two > machines, one of them didn't have this problem until I installed > bdf-unifont (either 9.0.02 or 0.0.01) your dotfiles repo shows me that your setup really is anything but transparent. Your .xinitrc is a mess and stages an environment before starting dwm. Try to set up a minimal working example in a clean environment, e.g. try running gentoo and write the .xinitrc yourself. Your lack of control over this environment will forever hinder us from finding the cause of this issue. Cheers FRIGN -- FRIGN
Re: [dev] [dwm] Crash when setting window title to a single emoji
On Mon, 29 Aug 2016 19:56:56 +0200 Markus Unterwaditzer wrote: Hey Markus, > I'm getting crashes with a particular emoji in the window title. > Enter the following in st/termite/xterm/urxvt (without tmux > inbetween): > [...] > This is my first attempt at debugging anything Xorg-related, not sure > what else could be important. I can not reproduce it here. Cheers FRIGN -- FRIGN
Re: [dev] Sane office alternative?
On Thu, 25 Aug 2016 14:47:37 +0100 Cág wrote: Hey, > Abiword sucks, in my opinion. I've tried it numerous times and many > times it crashed > without recover. It started when they switched to GTK+3. > > Luckily, I don't depend on formats and use LaTeX in my nvi. There is > sc/vc for > spreadsheets. well, I respect your experience, but just for the record, Abiword never crashed on me, and I've had my fair share of things I opened with it (ancient docs, overloaded picture galleries and so on), but maybe the stability for me comes from the fact that Gentoo allows me to only compile in things into Abiword I really need. There are a lot of things not compiled into my version, making it rather lightweight. :) Cheers FRIGN -- FRIGN
Re: [dev] Sane office alternative?
On Thu, 25 Aug 2016 14:23:28 +0200 Markus Teich wrote: Hey Markus, > respond with a plain text document without file name extension and > laugh at their silly faces when they don't know how to open it. joke aside, but most people have no choice but to interoperate with Office- and Open-Documents. You can't just respond with a trolling. I've been using Abiword and Gnumeric at work for over 5 years now, and I come in contact with doc's, xls's, docx's and xlsx's quite regularly. What needs to be noted here is that ppt and pptx has become uncommon, same with the other formats in the office suite. So it's sufficient to dump the bloated mess LibreOffice is and use Abiword and Gnumeric. At least from the latter I know it is also heavily used at CERN, which explains why it even has superior data analysis tools than Excel itself. Cheers FRIGN -- FRIGN
Re: [dev] Sane office alternative?
On Thu, 25 Aug 2016 12:51:32 +0200 Kevin Michael Frick wrote: Hey Kevin, > what do you use to communicate with the part of the world (a majority, > unfortunately) who uses suckish formats such as .doc(x), .od[tspg] or > whatever? If Office is bloated, LibreOffice ain't slim, and people > keep sending me word documents :/ I can recommend Abiword and Gnumeric whole-heartedly. They are _relatively_ slim and are great substitutes for Word and Excel respectively. Cheers FRIGN -- FRIGN
Re: [dev] Never Ending Systemd Chronicles
On Sun, 21 Aug 2016 12:18:45 +0200 Christoph Lohmann <2...@r-36.net> wrote: Hey Christoph, > »My users are stupid[¹], let's make them more stupid[²] and helpless > [³].« -- new slogan of systemd > > [¹] By assuming the users which really do some mount are not able to > do a fsck or handle it in the right order. > [²] Giving away the responsibility from the user to some software > logic and adding yet another undebuggable layer of dependency logic > will surely make things easier to understand and keep the leaning > curve low. [³] By adding the above mentioned new complexity users are > directly prohibited to learn about their system. This opens the > ground for a new generation of »Linux experts« who's only task is to > hide their incompetence. (As seen in many other technical markets, > the Microsoft software niche.) > > We have seen where the hidden customer complexity theorem of Windows > has led. yes, this is a very good point! Added to this is the question if this automatic logic really covers all cases you could also handle in a simple shell script. I have an encrypted raid and it's a 10 LOC shell script to call all the necessary dependencies in the openrc context. It is definitely questionable how easy this job is if I wanted to solve the same problem using systemd-mount. Cheers FRIGN -- FRIGN
Re: [dev] How about software for photography enthusiasts?
On Sat, 13 Aug 2016 16:04:32 +0300 Ciprian Dorin Craciun wrote: Hey Ciprian, > * Starting with the obvious `dcraw` ( > http://www.cybercom.net/~dcoffin/dcraw/ ), which although I'm sure > will fail all of the "suckless" criteria, is among the few (if not the > only?) open-source solution for extracting data from RAW images. if you really care about photography, you would acknowledge the fact that dcraw or ufraw have to be part of an image processing pipeline. Raw data makes sense for a lot of reasons. Being the "author" of the farbfeld image format I have to highlight here that all the tools on suckless.org assume the sRGB color space, which, to be fair, is not a big sin given X11 and the entire ecosystem does not encourage color management of this dimension. Cheers FRIGN -- FRIGN
Re: [dev] [st] Release planned?
On Thu, 11 Aug 2016 16:37:39 +0200 Joerg Jung wrote: Hey Joerg, > Seriously, you really want to start again the same stupid discussion > about releases and version numbers, which last time led to splitting > the mailing lists into dev and hackers? chill down, you should know by know that Christoph is trolling more than 50% of the time. > Let’s summarise what we have: > There are users who build from release sources and there is nothing > wrong with it. There are also packages available for most major > distributions build from the release tarballs, and users which use > these packages, again nothing wrong with it. > > If you do not want this, you may really want to remove all existing > tarballs and releases, from suckless.org to state clear that these > are not wanted and to avoid the above, but why did you provided them > in the first then? ... and even if you do not provide them any > longer, people will likely start rolling/providing and tagging own > releases. For various reasons there are people which expect and want > releases. I agree with you there, but this is a limitation of the package managers. For more complex projects, going bleeding edge is not the way to go for "normal" users, but can we even talk of normal users wrt suckless software? It's a matter of responsibility, but I understand the notion of even professional users to run a stable version at the end of the day, just to make sure. It also makes it simpler to apply patches to it, as soon as patches are released for a stable version (I'm on it). Cheers FRIGN -- FRIGN
Re: [dev] [st] Release planned?
On Thu, 11 Aug 2016 16:07:29 +0200 Paul Menzel wrote: Hey Paul, > Are there plans to get release 0.7(?) out, so that users, not > building from repository, but from release source archives, can > profit from them? just FIY, Christoph tagged a 0.7 release a few minutes ago[0]. Cheers FRIGN [0]:http://git.suckless.org/st/commit/?id=6e79e8357ed1987a7f7a52cc06249aadef478041 -- FRIGN
[stali] scope (was: Re: [dev] neatroff)
On Thu, 11 Aug 2016 11:03:13 +0200 Anselm R Garbe wrote: Hey Anselm, > I have no problem with OpenBSD per se, but I do think that its scope > is general (server) purpose and that the hardware support in the > embedded non-network space doesn't sound too great to me. linux kernel > + some dedicated userland is far more flexible imho. hardware support is not as good as we see with Linux, but consider how much money flows into Linux compared to OpenBSD and how many companies push changes into the Linux kernel. And things are improving and there are numerous laptops and desktops running very well with it. Given how dedicated the suckless fellows are anyway (the only possible userbase for stali tbh in the short term), I'm sure they'd even invest into a laptop or desktop with the special interest of it supporting OpenBSD. Another thing is: Look at the OpenBSD drivers, they are designed like space-ships. Compared to this, Linux kernel code often looks like a racing kart held together with duct tape. I'd rather use a system offering less hardware support but genuinely better security and stability than some clamped on solution. My thoughts are this: We could either go ahead and create yet another Linux distribution with, even if it was successful, yet another fragmented community. Package maintenance is not an easy task, and as we discussed at the last slcon, you intend to rewrite all the build systems for the different projects to make them suckless, which is ambitious but also too ambitious for a project with such little manpower. We need to save our energy for projects that matter. The OpenBSD ports system is solid and well-maintained; we have strong arguments on our side to justifiy why static linking is in many ways more secure, stable and lightweight than dynamic linking. OpenBSD has some old cruft of course, but with Linux we are just scratching the surface. The entire userland is a toxic environment. The OpenBSD developers are sane guys and have complete control over the userspace; they discuss with reason and are not frightened to cut big chunks out of the OS if they see fit. The static approach of course would not apply to all packages, but I wouldn't even be surprised if they accepted such changes for certain things. As an example: Just look how easy it is to setup Wifi on OpenBSD, or a RAID, and many other things. This is years ahead of Linux. I am sure suckless.org has a lot of street-cred in the OSS-scene. We could use this leverage to have a positive influence on a big distribution people actually use. In the long term, making OpenBSD better will benefit those who are scared of making the switch. We all know that OpenBSD is much further on the convergence line towards an ideal operating system for server and desktop applications than Linux and its messy userland. Cheers FRIGN -- FRIGN
Re: [dev] [sxiv] Discussion
On Tue, 9 Aug 2016 18:09:44 +0200 Bert Münnich wrote: Hey Bert, > I was asked for sxiv becoming an official suckless project. I had > nothing against that move. And I have nothing against reversing it. I think there was a misunderstanding on my part. Does main development happen on GitHub or at suckless.org? In the latter case, I would favor keeping it on suckless.org having given it more thought. Cheers FRIGN -- FRIGN
Re: [dev] neatroff
On Thu, 11 Aug 2016 09:44:45 +0200 Anselm R Garbe wrote: Hey Anselm, > The stali plan has changed for me a bit during the last year. A couple > of months ago I tried to get stali self-bootstrappable based on just > src/. I have now given up on this idea for various reasons: > [...] > Any help is welcome under the new premises above. I think it is kind > of a hygene factor to not aim for a self-bootstrappable environment. > The beauty is that target platform, not the src/. The src/ is hideous > in most parts anyways, if you consider what stali relies on. I've been wondering for a while what you think the problem is with OpenBSD. Wouldn't it make more sense to somehow start an initative in OpenBSD to promote static linking there? Cheers FRIGN -- FRIGN
Re: [dev] [sxiv] Discussion
On Wed, 10 Aug 2016 23:33:06 +0200 Christoph Lohmann <2...@r-36.net> wrote: Hey Christoph, > Everything should be GPLv3, you are right. let's not discuss this here. You know my position on the GPL, and I know yours. > Please don’t waste that much resources on viewing a big picture > directory. You are making it worse. Have you ever actually tried it? The farbfeld tools were pretty slow in version 1 but improved dramatically and now are pretty fast. > Yes, because it does more than handling image display. It knows a > thumb‐ nail mode to organize and easily select many images, which is > very useful for organizing big image directories. Now that is a good point which justifies code complexity. > Where’s there no simplicity in sxiv? There are multiple aspects, but for instance how giflib is woven into the code. The attempt to handle EXIF-data so gracefully is honorful, but for many formats, it's just a big mess. > Yes, it is the mirror. Sadly sxiv was first on the fascist github. > We can’t revert history. Maybe when github closes due to its unicorn > nature people will come back to sanity. The real question is: Where does main development happen? On GitHub or here on git.suckless.org? > You see the code and the comment. What else do you need? A description in the actual commit what the underlying problem was? Is it too much to ask? Cheers FRIGN -- FRIGN
Re: [dev] [sxiv] Discussion
On Tue, 9 Aug 2016 21:51:54 +0200 Silvan Jegen wrote: > I see. That use case may make it harder to use farbfeld unless you > want to change your whole image collection to this format. > Theoretically, you could just use farbfeld as the intermediate image > format to apply the changes to and then convert the changed image > back to the original format. You could definitely use bzipped farbfeld as a storage format, but this is not what it is meant for. In the end it simplifies the program so that it only has to deal with farbfeld data instead of dozens of image formats. The conversion can happen in-situ and is generally no problem, as any image viewer program has to do that anyway to get the raw "bits". The overhead of first writing those bits into a farbfeld stream is pretty minimal. Cheers FRIGN -- FRIGN
Re: [dev] [sxiv] Discussion
On Tue, 9 Aug 2016 21:19:14 +0200 Silvan Jegen wrote: Hey Silvan, > feh has this odd right-click menu though. It's also surprisingly large > (it also can set your background image...). > > [feh]$ wc -l `find . -name '*.c' -o -name '*.h'` > [...] > 17441 total haha yeah. Fun fact: feh now supports farbfeld :) Try it out! > If the conversion tools are already written (I wasn't sure this was > the case already) then all that's left to simplify sxiv would be to > make it speak only farbfeld and then to wrap it up in a shell script > (?) that converts all arguments to temporary farbfeld files and passes > them to sxiv. Yes exactly. That's how sent[0] does image handling and it works very well! Cheers FRIGN [0]: http://tools.suckless.org/sent/ -- FRIGN
Re: [dev] [sxiv] Discussion
On Tue, 9 Aug 2016 18:36:34 +0200 Silvan Jegen wrote: Hey Silvan, > Personally, I would opt for taking out the thumbnail view and maybe > try to get rid of the font handling (if possible; maybe just use a key > press to write the file name to stdout?) to reduce the dependencies > somewhat. then it would basically be feh. > Of course one could get rid of all the image format dependencies and > use only farbfeld, if one finds someone willing to write/debug > farbfeld converters for all image formats so that sxiv would only > have to speak farbfeld. farbfeld is damn stable and one can easily use the 2ff tool to convert from all possible image formats with the help of imagemagick. Look at sent on how it is handled there. Cheers FRIGN -- FRIGN
[dev] [sxiv] Discussion
Hello fellow hackers, don't take it personally, Bert, but I don't think your project sxiv[0] belongs to the suckless git-repository. Not only is it licensed with the GPLv2, which is despicable in itself, but the code doesn't even look suckless to me and there are good ways to go around the whole image-format-cancer-spread nowadays. Look at how sent does image handling; it's definitely best to push this task toward other tools, like farbfeld, for easy internal handling. C: 3663 (98.05%) sh: 43 (1.15%) awk: 30 (0.80%) Do we really need a project the size of dwm to display images? The name suckless stands for quality software, which foremost tries to accomplish elegance and simplicity. There are already too many git repositories in git.suckless.org, and added to this it seems the sxiv repo on git.suckless.org is just a github mirror, with all its implied beauty[1]. Do I really need to dig around github now to see what the commit fixed? What do you think? Cheers FRIGN [0]:http://git.suckless.org/sxiv/tree/ [1]:http://git.suckless.org/sxiv/commit/?id=53a72c7b657d9dc3347d9d68e0b9a00773efe732 -- FRIGN
Re: [dev] Never Ending Systemd Chronicles
On Fri, 05 Aug 2016 11:52:52 +0200 Kamil Cholewiński wrote: Hey Kamil, > I don't think we need more systemd hate - people are already in one > camp or another. We do need a single, solid, real world, battle-proven > solution, to propose as a viable alternative for distros to implement. it's not hate, it's valid criticism. > Systemd does solve two things: 1. it's now universally available > across all major distros, and 2. it has a stable set of basic > interfaces (unit files, commands). It's an euphemistic way to describe a monoculture. systemd eats into your system and forces itself onto you with all its interfaces. A few years ago, it didn't matter which init system you had, now it goes so far that you can't run certain GUI applications without having this cancerous leech in your system. > No, runit is not the answer, it's only a building block. Of course, runit is only a service manager. But runit+sinit+misc is a whole other story. Cheers FRIGN -- FRIGN
Re: [dev] Allow secure access to Web site suckless.org
On Wed, 3 Aug 2016 12:23:41 +0100 Dimitris Papastamos wrote: > I did set it up for the first few months but then was too lazy to > renew it. What about Hiltjo then? He set it up for codemadness.nl. -- FRIGN
Re: [dev] Allow secure access to Web site suckless.org
On Wed, 3 Aug 2016 13:10:06 +0200 hiro <23h...@gmail.com> wrote: > are you claiming Let's Encrypt is trustworthy?! However, to add to my previous point, I like the automated process for Let's Encrypt, and it adds more trust than just connecting over HTTP. The 100% ideal way would be to do onion stuff, but how many people are really using Tor to browse the web? Let alone to download tarballs and stuff. For the majority, an "inferior" solution which can be troublesome in some cases but still provides another layer of security is in my opinion favorable. Dimitris already set up Let's Encrypt on 2f30.org, maybe he can help set things up for suckless.org. :) Cheers FRIGN -- FRIGN
Re: [dev] Allow secure access to Web site suckless.org
On Wed, 3 Aug 2016 13:10:06 +0200 hiro <23h...@gmail.com> wrote: > are you claiming Let's Encrypt is trustworthy?! To clear this up, no, I am not. However, Let's Encrypt is not about certifying the server on the other end in the first place, but providing a way for easy encrypted traffic. In my opinion, the best would be just to allow self-signed certificates in browsers, but Let's Encrypt comes close enough. Cheers FRIGN -- FRIGN
Re: [dev] Allow secure access to Web site suckless.org
On Wed, 03 Aug 2016 12:18:52 +0200 Christoph Lohmann <2...@r-36.net> wrote: Hey Christoph, > HTTPS is not really secure. Do you really trust any CA? How many CA > peo‐ ple have you met in your life and really trust them? there's always Let's Encrypt, but I know what you mean. Masquerading still seems to be an issue. However, what I think what Paul means is general surveillance. Even if you use self-signed certificates on your server, which provide 0 guarantee that the server you are contacting really is the "right" one, it still means the traffic itself is encrypted, with all benefits of it. > If you would contribute, you would have SSH access. A onion > service might be a consideration, to add something similar to > »security« as an access method for suckless.org. Yes, an onion service would be really cool. Cheers FRIGN -- FRIGN
Re: [dev] JWM on website
On Tue, 2 Aug 2016 22:35:45 +0200 patrick295767 patrick295767 wrote: > /* > JWM v2.3.5 by Joe Wingbermuehle > compiled options: confirm icons nls xbm > */ > > My theme: > > > FreeSans-9:bold > 4 > 20 > > white > #70849d:#2e3a67 > black > 1.0 > > > #aa > #808488:#303438 > black > 0.5:0.9:0.1 > > Yuck! XML config? No thanks! -- FRIGN
Re: [dev] Wayland vs X11
On Tue, 2 Aug 2016 22:08:08 +0200 Silvan Jegen wrote: > As far as I can tell, the goal of the Wayland devs is to keep the > required protocols to a minimum and graduate prooven protocol > extensions to official Wayland ones. It sounds good on paper, but really turns out to be a horrible mess in reality. > So theoretically, as long as you implement the Wayland protocol (and > it's assumptions) correctly, any compatible Wayland-speaking client > should work just fine. Yes, the clients are not the problem. We are talking about the compositor here. > Since Wayland is only a protocol, as long as both the client and the > server follow it closely enough both the clients and the server will > be happy. What is crucial is that the protocol is minimal and strictly > defined however. I am still cautiously optimistic that this is and > will be the case... It's not only about client-server interaction, it's about how you for instance should capture input in a compositor. You could use libinput, or a gazillion other libs out there with different levels of device support. I can already see the bug reports because this and that joystick, touchpad, whatever does not work in a specific compositor. And even clients have to do their own font-antialiasing. Sounds like a lot of fun! Please stop repeating the propaganda spread on the web, Wayland is not DoA without reason, and there is also a reason why nobody uses it nowadays other than to play around with it. It's a horrible mess and the wayland devs expect us to boil the ocean without any clear benefits at hand. Cheers FRIGN -- FRIGN
Re: [dev] Wayland vs X11
On Tue, 2 Aug 2016 20:33:39 +0200 Silvan Jegen wrote: Hey Silvan, > One can argue that having a simple protocol *is* the suckless part of > Wayland (dont forget Xprint[0] :P). The Wayland protocol also does not > allow for communication between clients directly[1] but only through > the Wayland compositor. yeah, but omitting the rest is not suckless, it just turns everything into a big mess. You might say anything about X.org, but at least you can more or less rely on a set of features available to you, even if they are "default" XFree86 extensions. > I see two main issues that stem from switching to Wayland. > 1. With Wayland there will be no non-compositing desktop. I don't see this aspect too critically. See how Wayland performs vs. X in limited environments[0]. > 2. Since rendering is done client-side and there is no Xlib, it may be >harder to get pixel on your screen if you don't want to use one of > the big GUI libraries like Qt or GTK2/3/++/whatev. Yeah, very good point. Also, clients cannot rely on compositor features, because each compositor can do things differently. There really is no simple way to write software and making it deliberately hard almost makes you believe its a GTK/Qt conspiracy of some sort. > As a non-expert in this space I am not sure the Wayland future is > looking that bleak though. > Velox[2] does not look bloated to me and wayland-enabled st[3] is only > barely larger than the current X11 version's git tip (though the > wayland version depends on wld[4]). How can you compare the two? You need a third-party library (wld) to get shit done. Just wait down the line how much of a fucking mess we are going to have! Cheers FRIGN [0]: https://www.youtube.com/watch?v=Ux-WCpNvRFM -- FRIGN
Re: [dev] Wayland vs X11
On Tue, 2 Aug 2016 18:04:20 +0200 patrick295767 patrick295767 wrote: Hey Patrick, > Do you believe that Wayland will replace X11 one day?;) this is a tough question to answer. If we are headed on the current course, I think we will face even more difficult times in the future with worse monocultures than we have today (systemd, Gnome, ...). > Besides, don't you believe that Ubuntu may have time to time some > negative influence on Linux phylosophy? Is this a rhetorical question? > Quote: > Display server expert Daniel Stone explains what is really happening > with the future of graphical display protocols on Linux. So far as > most Linux users are concerned, Wayland is the project that is > eventually supposed to replace the X Window System (X). Here's the thing: Wayland really does not make a complete stack, it merely is a very thin protocol which allows the talk between clients and between client and compositor. Everything else (rendering, buffer management, input management, ...) that used to be handled by X.org in a reasonable manner is now pushed to each compositor. So if someone wants to write a wayland compositor, he has to keep all this shit in mind and prepare to do a lot of work. dwm would be a bloody behemoth, like any other wayland compositor out there. The only alternative is developing a plugin for weston, which is the reference wayland compositor. However, weston is a bloody filthy stuffed pig, definitely not something I would want to work with. Just criticism on wayland and the troubles of developing a compositor are nipped in the bud by trolls claiming you should write a plugin, which really misses the point for me. If I was one of the wayland developers' father, I would send in my son for a checkup if he suffers from anorexia or something, because wayland really is a bloody thin protocol and they really are scared to even offer the slightest ease for the API-users. The best thing to happen to wayland is an initiative to really standardize shit on top of it. I mean, Weston acts all advanced and stuff but doesn't even get color management right. If you want to improve this section of the Linux ecosystem, at least get things right that Apple has been doing perfectly for over a decade. Color management will become more and more important in the future, the more people will use Linux for graphic design and photography. I can't even imagine how much of a mess it will be if every single compositor has to think of ways for color management, handle joysticks, don't fuck things up and so on. It's a huge mess! Cheers FRIGN -- FRIGN
Re: [dev] Re: [st] [PATCH] Converted "font" string to "fonts" array
On Mon, 1 Aug 2016 17:13:14 +0200 Ton van den Heuvel wrote: > Fallback fonts can already be configured through Fontconfig, why does > st need separate functionality for this? Because Fontconfig is a load of crap! -- FRIGN
Re: [dev] Re: [st] [PATCH] Converted "font" string to "fonts" array
On Sun, 31 Jul 2016 19:08:34 -0700 Eric Pruitt wrote: Hey Eric, > I used tabs when editing st.c, but I just noticed I accidentally used > spaces when I changed config.def.h. It's only one line, and I don't > think it's worth creating another thread, but if aren't willing to > edit the patch to fix that, let me know. just update your patch and attach it to your response. Cheers FRIGN -- FRIGN
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
On Mon, 25 Jul 2016 14:40:43 -0700 Eric Pruitt wrote: > I see; I misread "curpos" as "cursor" when I glanced over it the first > time. However, it still looks wrong to me, so I tested it to verify > -- I believe the problem is that the characters aren't guaranteed to > have a width of 8 or even be constant for every character, so if you > type (or paste) something like "Blah blah Բարի գալուստ Վիքիպեդիա Blah > Blah", the cursor position and the number of asterisks is not properly > synchronized. Yeah I just stumpled upon this issue. hmm, difficult. Still, you need to find a simpler solution for your purpose, even though I don't think it'll ever get merged into mainline. Cheers FRIGN -- FRIGN
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
On Mon, 25 Jul 2016 14:22:16 -0700 Eric Pruitt wrote: Hey Eric, > Personally, I like having the asterisks reflect the actual number of > runes typed and think the cosmetics are worth the extra lines. Even if > you're typing Latin characters, I think only getting feedback every 8 > key presses kind of defeats the point of having asterisks at all. You > might as well just make the flag not show any text at all which is a > pretty common alternative for Unix password prompts anyway. my suggestion prints as many asterisks as there are runes. try it out! :D Cheers FRIGN -- FRIGN
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
On Mon, 25 Jul 2016 11:39:55 -0700 Eric Pruitt wrote: > The attached patch adds a "-g" flag to dmenu so it can be used for > password entry. Typed text is replaced with asterisks. I looked more closely at the patch and I've found potential to simplify it. Why not go with a static char asterisks[BUFSIZ]; and do a drw_font_getexts(drw->fonts, text, cursor, &curpos, NULL); memset(asterisks, '*', curpos / 8); asterisks[curpos / 8] = '\0'; drw_text(drw, x, 0, w, bh, lrpad / 2, asterisks, 0); or something along the lines. Cheers FRIGN -- FRIGN
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
On Mon, 25 Jul 2016 13:07:23 -0700 Eric Pruitt wrote: > Again, no one is saying passwords should be sent via the command line. > Look at the patch. It uses stdout just like vanialla dmenu. Ah I see, thanks for clearing up that part. Now, what do the other people think about it? Cheers FRIGN -- FRIGN
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
On Mon, 25 Jul 2016 12:53:04 -0700 Eric Pruitt wrote: > And to clear the terminology: With "command line", I mean inside the actual arg-array, like $ example "supersecretpassword" If you actually mean a program that gets the password piped like $ dmenu ... | example I really would like to see if "example" actually exists. Does it really make sense to do that and is it even safe? Cheers FRIGN -- FRIGN
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
On Mon, 25 Jul 2016 12:53:04 -0700 Eric Pruitt wrote: Hey Eric, > There's an example in the description: entering passwords. I don't > think any thing else needs to be said, but I will humor you: So you pass passwords on the command line? Again, an example is really overdue. > > For me, this doesn't make any bloody sense and gives a false sense > > of security. > > "For you?" Maybe you never use a computer in the presence of other > people, but I (like many people) do and occasionally need to respond > to password prompts. There need to be many prerequisites to offer a safe password prompt. I'm sure you've never used explicit_bzero before and have questionable model of security in your mind if you really propose this "solution". In the end, with this talk, you only humour yourself. And give a bloody answer to my question already. I want to see a real example, a real program that actually _exists_ which takes passwords on the command line, or an example where you use dmenu to enter passwords in some "dynamic" context not observable to me at the moment. Cheers FRIGN -- FRIGN
Re: [dev] New Suckless computer language?
On Fri, 22 Jul 2016 20:46:50 +0200 Daniel V wrote: Hey Daniel, > Is there any interest in a small new computer language? > > A few years back I found a new way to make computer languages. > > [...] Bla Bla Bla [...] > > Is there any need for a new language, or is C good enough? this is not the book club. If you want to talk your heart out, talk to your hairdresser or something. If you can't find a way to host a git repo, at least show us the syntax here. Give a simple example, like a hello world to "enlighten" us. Other than most pseudosciences (Gender studies, psychology, social sciences, ...), it is easy to spot someone who just talks but doesn't deliver in a real scientific context, to which I also count software development, especially language theory. Show some code or you'll have lost all the respect by many people here, including me, if there ever was one. Cheers FRIGN -- FRIGN
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
On Mon, 25 Jul 2016 11:39:55 -0700 Eric Pruitt wrote: Hey Eric, > The attached patch adds a "-g" flag to dmenu so it can be used for > password entry. Typed text is replaced with asterisks. Why would you need that? Can you give an example? For me, this doesn't make any bloody sense and gives a false sense of security. Cheers FRIGN -- FRIGN
Re: [dev] new pre-patched version of dwm available
On Fri, 22 Jul 2016 13:54:36 -0800 Britton Kerin wrote: Hey Britton, > dwm needs patches to be good but the patches area is a mess and I > couln't get along with devs about fixing it, so I thought a pre-rolled > version of dwm might be useful instead: you really raise a valid point, fortunately, as you may know, there are proceedings to clean up the wiki and the progress is already pretty good. It's a difficult matter because patches interfere. I know of no way to make multiple patches inclusive to each other, in many cases it is not possible. There are some things thought that I'd like to see in mainline, e.g. removing borders of the window when there's only one window in the current tag. Cheers FRIGN -- FRIGN
Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.
On Wed, 20 Jul 2016 13:37:01 +0200 Christoph Lohmann <2...@r-36.net> wrote: > Sorry for the late answer, I had to save the world. Care to elaborate? -- FRIGN
Re: [dev] [PATCH][dwm] new alpha patch for 56a31dc
On Mon, 18 Jul 2016 09:50:33 -0400 "Eon S. Jeon" wrote: > This is a new version of 'alpha' patch for dwm, which reflects > breaking changes made regarding color schemes. Alpha values for > foreground, background, and border now can be configured > independently in a very straight-forward way. The rest stays the same. Yeah, this looks very good! Any comments from the other fellow? Else I'll just pull it into the wiki asap. Thanks for your hard work Eon! Cheers FRIGN -- FRIGN
Re: [dev] [st] Division by zero
On Mon, 18 Jul 2016 14:45:44 +0200 Paul Menzel wrote: Hey Paul, > If I am not mistaken, this is really a corner case. The user has to > set `actionfps` to zero in `config.def.h`. > > ``` > config.def.h:static unsigned int actionfps = 30; > ``` > > Even setting it to zero and rebuilding the package, I was unable to > trigger the issue. why would you set actionfps to 0? Thing is, what users do in config.h is their responsibility. I could also leave a struct empty and then be "surprised" about the program breaking. What you configure in config.h is your responsibility, that's it. -- FRIGN
Re: [dev] [noice] with musl
On Mon, 18 Jul 2016 13:49:16 +0300 Cág wrote: Hey Cág, > If someone knows what goes wrong or workarounds, please tell. did you try recompiling with "-fPIC"? Cheers FRIGN -- FRIGN
Re: [dev] is the multimon still useful?
On Sun, 17 Jul 2016 14:05:41 -0800 Britton Kerin wrote: > It looks like multi monitor support has been merged into mainline > anyway and this patch hasn't been updated in a while. I don't use > multi monitor setup so don't know about this stuff. Is this patch > still potentially useful or should it go away? You can put it into historical as a whole, as it's too old. -- FRIGN
Re: [dev] [dwm] Avoid requesting MotionNotify events
On Sat, 16 Jul 2016 14:33:18 +0300 (MSK) Alexander Monakov wrote: Hey Alexander, > A while ago dwm started requesting MotionNotify events from the X > server (that wasn't always the case). This was added when > focus-follows-mouse was implemented for monitors (in addition to > windows) in 2011 by commit b5068e32e9. > > This causes lots of useless communication between the X server and > dwm every time the mouse pointer is moved, even when nothing could > possibly change as a result (e.g. if Xinerama is not compiled in, or > only one monitor is present). On my system, the resulting > syscalls-per-second count in dwm is about 490, if the mouse if moved > continuously. > > The following patch fixes the issue in the minimal way only when > Xinerama support is not enabled at all. I'd find it worthwhile to > fix this under Xinerama too. To outline a partial solution for > one-monitor-connected case, moving XSelectInput to updategeom will > allow to request MotionNotify events only when monitor count is 2 or > more. I don't have a patch for this yet, but I'll be happy to create > one if desired. > > For multiple-monitors case, it should be possible to avoid > MotionNotify events too, by creating InputOnly subwindows of the root > window corresponding to monitor boundaries, and using EnterNotify > events on those to trigger monitor focus changes. I'm not really > familiar with Xlib, so I haven't worked out the details here, but if > there's interest in this solution I can look into it. nice work soldier! Can you elaborate on how you measured the syscalls per second? I'd be really interested because this telemetry data could really help improve the suckless.org tools, especially those wrt to the Xlibs, which might run but can turn out to be quite ineffective (as you have shown here). I wondered about these CPU-spikes in dwm as well. Cheers FRIGN -- FRIGN
Re: [dev] my next steps on dwm patches, please object now
On Tue, 12 Jul 2016 17:42:37 -0800 Britton Kerin wrote: > If patches turn out to be unportable to HEAD without huge problems or work, the best approach is to try to contact the author and move the patches to historical/. Cheers FRIGN -- FRIGN
Re: [dev] my next steps on dwm patches, please object now
On Tue, 12 Jul 2016 17:42:37 -0800 Britton Kerin wrote: > Oh, and I almost forgot: Don't use git-format-patch for the git patches. Just pipe the output of git diff to a file. Maintaining those git-format-patches is too much work. Cheers FRIGN -- FRIGN
Re: [dev] my next steps on dwm patches, please object now
On Tue, 12 Jul 2016 17:42:37 -0800 Britton Kerin wrote: Hey Britton, > Below is a list of what I intend to do about the remaining (obvious) > defects in the dwm patches. > The last line of each paragraph is what I have in mind, please object > now so I don't waste my time, thx. I welcome that you take your time to discuss this here. There's nothing worse than losing motivation because you do things that are inherently not what is expected. It happened to me too. > checking dwm, attachabove, dwm-git-20120406-attachabove.diff > prog dwm patch attachabove diff dwm-git-20120406-attachabove.diff > doesn't match any allowed pattern > don't know what commit to try to patch > Strategy: do nothing because it's ancient > > [...] Okay, this probably is the wrong way to go. I will give you a quick guide on what would be the best approach in this context because I'm so glad you want to spend time on the wiki and fix this old mess. :) Alright, so ask yourself, for a patch to be useful, which conditions does it need to satisfy? To answer this question, reflect that users either run stable versions or on git, the bleeding edge. Thus, for a patch to be useful, it needs to be provided both for stable tags and for the latest git HEAD. I took my time and reworked two pages to fit the "consistent" style already seen in the st-section. Please always refer to the st-section for style matters, as it is the only consistent patch section on the website. The pages are http://dwm.suckless.org/patches/alpha http://dwm.suckless.org/patches/alwaysfullscreen Especially the author-sections are very inconsistent on the other pages and there are many spelling mistakes. We also do not want information on size or date of the patches written behind the link. But as you can see, the reworked patch pages do not offer patches for stable versions, which is a problem as especially many Arch users run dwm as stable and still want to apply patches to it. So how do we solve this? Let's first make out 3 categories of patches (1) patches only supplying stable versions -> work forward and create patches for each stable tag following and the git HEAD respectively If it's too much work, always resort to just creating a stable patch for the latest version and a git HEAD patch (2) patches only supplying git versions -> create a patch for the _last_ stable version of dwm and update the git patch to HEAD (3) patches only supplying non-identifiable patches -> just test out and try to create patches for the latest release and git HEAD. Okay, now, to give a few examples: A page satisfying (1) is [1]. What you would do there is first try to apply the patch to version 5.8.2, as I actually hit more than a few cases of mislabeled patches. Next, you "forward-port" the patch. This means, you go forward to tags 5.9, 6.0, 6.1 and create patches for each version. It might look a bit redundant, but you have to forward-port anyway, so there's no reason not to provide those patches. If you however stumble upon a very ancient patch, feel free to just port to the latest version 6.1. As a next step, you create a git patch with the agreed upon naming scheme: dwm-current_desktop-2016-07-30-shorthash.diff A page satisfying (2) is [2]. Here you have to check out how old the patch is and forward-port it. First go to tag 6.1, create a stable patch, then make it apply to git HEAD. A page satisfying (3) is [3]. Here as well, assess the situation and create patches for 6.1 and git HEAD. # Now, as a final word: I know this is a ton of work. We cannot fix the dwm patch section by just renaming patches to a new scheme. We have to do major cleanup and it will require a big amount of work. However, once done, we will be able to make sure that stability is guaranteed in the future by automating the patch generation (and urging the "maintainer" to fix patches if they break). PLEASE, work on a site-per-site-basis and make a commit for each single page. Don't be scared to flood wiki@ with commits. Each page should receive a style-cleanup as well, and both can be combined easily. I hope this helps. :) Cheers FRIGN [1]: http://dwm.suckless.org/patches/current_desktop [2]: http://dwm.suckless.org/patches/alpha [3]: http://dwm.suckless.org/patches/fancycoloredbarclickable -- FRIGN
Re: [dev] first batch of renames pushed, but the new name scheme is somewhat bad...
On Tue, 12 Jul 2016 16:19:40 -0800 Britton Kerin wrote: Hey Britton, > To me the availability of patches in the current format implies that > they are curated and cared for, and I don't trust automated systems > like this to work right. I'd rather just see a patch again an old > version. okay, maybe there's a misunderstanding. The automation only applies to the git-patches. For tagged versions, we just create a patch and be done with it. The situation definitely is a mess for dwm. > I liked having -git_ in there. (I see later you decided to omit). > Maybe all suckless users are git versed but I doubt it. > Seems like an example of expecting others to see the world like > you do. The patch names are already verbose, why not > make things explicit? I agree with you, but it has been decided like that and I made the mistake to agree to the non-git version here on the ml. Cheers FRIGN -- FRIGN
Re: [dev] first batch of renames pushed, but the new name scheme is somewhat bad...
On Fri, 8 Jul 2016 13:14:30 -0800 Britton Kerin wrote: Hey Britton, > we re-discussed this yesterday and came to the conclusion that the format without "-git-" is the better choice. I changed the guides in hackers.md accordingly and renamed all st git-patches, which followed the other naming scheme. Cheers FRIGN -- FRIGN
Re: [dev] first batch of renames pushed, but the new name scheme is somewhat bad...
On Fri, 8 Jul 2016 13:14:30 -0800 Britton Kerin wrote: Hey Britton, > This was the agreed format but in a way it's a change for the worse. > It splits the thing patched against (prog+version) into two parts and > puts the patch name in between. To see why this is bad consider > http://st.suckless.org/patches/scrollback which stacks some patches on > top of each other to get different behaviors. Obviously we want the > patches to be mostly flat but that use case is reasonable. > It would be better to be consistent st > > st-scrollback-git-20160620-528241a.diff > st-scrollback-mouse-git-20160620-528241a.diff > > was instead: > > st-git-20160620-528241a-scrollback.diff > st-git-20160620-528241a-scrollback-mouse.diff > > This way things appended to the base name always represent > modifications of what comes before. No, this is not better. It makes sense if you only look at a patchset alone, but it's a bloody mess if you have multiple patch files, like many people do! A filename always has to satisfy a hierarchy. The most important information is which project it applies to, in this case "st". So we can all agree that this is the first part of the patchname. The second part is which patch we are talking about. It definitely should be the patchname itself, in this case "scrollback" or "scrollback mouse". The third part is the version. You either have one tagged against a fixed version, like st-scrollback-3.1.diff or a git version, which requires more information st-scrollback-git-20160620-528241a.diff Given we are currently in the process of automating the "maintainership" of patches, we will think about simplifying the git naming scheme in the future and maybe only including the git shorthash as a handle. The reason behind this is that if we have a githook automatically updating the patches on each git commit to st, dwm and so on, the date will be meaningless. However, we have many people here who are scared of rapid change. Some people suggest omitting the "git" in the filename of the diff, however, this is not an ideal solution. If you have many patches of one kind, the sorting will be all wrong. The "2016..." in a alphanumerical sorting (e.g. filename) will always be between fixed tag versions 2.x and 1.x. This is not desired. We can use the "git" tag and always be sure that it will be last, as numbers are usually preceding over letters like 'g'. > There are still lots of renames that have to be made by hand, broken > patches to contend with, etc. but I thought I'd ask one more time if > we're sure we're happy with this naming scheme. Yeah, let's do this! :) Think about the users and don't worry too much. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Fri, 1 Jul 2016 21:05:09 -0700 Leo Gaspard wrote: Hey Leo, > Actually, I'd think if you give people push access to their patch branch > it may be easier for them than having to export a patch and update the > wiki: they already rebase the patches for themselves, they would just > have to git push and that would be done. but this never actually happens. I know of people who have even private collections of patches updated, but would never get the idea to push them to the wiki, as the entire structure is inconsistent across projects. To remove strain for admins, the best choice really is to automate the process, which I've already managed to do for st. On each new release-tag, a patch for this specific version is added to the wiki. Every other solution will fail, as it is both too much work for the wiki admins (as they already have enough to do) and won't encourage people to do it (one more "wall" to prevent contributions). > This idea of setup does not take into account the cost for maintenance > of a setup where selected people are allowed to push to selected > branches, as I have not (yet) inquired more into that. > > This idea does not take into account the keeping alive of old patches > either; which may be implemented by auto-generating a tag when a branch > is force-pushed, but requires even more setup from the suckless server > admins. A simpler solution would be to disable force-pushes, but this > would mean mergeing all the time and an unclean history for patches. > > This idea only takes into account the price for the patch-submitting > end-user. Yes, and that is the big issue here. In my opinion, only those people should have a say in this process who actually spend time on fixing the patches (like Matthias Schoth, Jochen Sprickerhof, Eric Pruitt, Ayrton, myself and others). They actually do real work instead of phantasizing here on this ML. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Fri, 1 Jul 2016 14:49:34 -0700 Ben Woolley wrote: Hey Ben, > Late reply to this, but I favor the git branch approach as you suggest. > It is already a dependency, so why not use it for its intended purpose? > > The great thing about a branch is that it is easy to use the version the > patch is for, and update as desired. The tools to manage the use cases > around a patch are already built into git. > > Remember, git was originally created to solve the problem of concurrently > managing many large patch sets from distributed sources. Isn't that the > problem here? it's always the same thing here. People propose things that are very complex solutions for simple problems, and they end up being accepted due to negligience. However, only a few people actually maintain the patches in the long run, which is a shame. The dwm patch section just needs an overhaul analogous to the st patch section had. End of story. It's already difficult enough getting people to maintain their patches now, let alone in some git environment. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Fri, 17 Jun 2016 10:01:43 -0800 Britton Kerin wrote: > the right format is --.diff for release patches. Now do some work and change it to that... Use the st patches as reference, they are correct and have been agreed upon. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Fri, 17 Jun 2016 09:14:30 +0200 Anselm R Garbe wrote: > The date should always be updated, whenever the patch is touched in some way. Agreed. @All: Check out http://st.suckless.org/patches/, I changed the patch name formatting as discussed here. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Thu, 16 Jun 2016 10:23:15 +0200 v4hn wrote: Hey v4hn, > No. It indicates that individuals make use of some patches and contribute > their changes to make a patch work with whatever git checkout they use. > > Threads such as this one only appear because people who are too lazy to > update patch files they find flying around somewhere on their own and > instead decide to waste everyones time by sending user-request-mails. > This is not launchpad. yeah, you nailed it. I spent considerable time updating the st-patches over the last couple of months, and only few joined me in the "fight", like Joshua Haase, David Phillips, Ivan Tham and Anders Larsson. In certain respects, the st patches could use another update. Even hunk-differences can break someday after more commits. Maybe I'll work on a way to automate the process somewhat. :) To everybody else: Stop painting pictures here on the ml and actually help improve the patches. In the end, only the one who does something gets to decide how it's done. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Thu, 16 Jun 2016 07:27:58 +0200 Anselm R Garbe wrote: Hey Anselm, > I would suggest to use: -- hash>-.patch st-externalpipe-ea87104-160423.patch Admittedly, I don't immediately see the date in there. Also, always think about how you can enforce this properly. Most people don't even know how to get a short hash. > Replacing the "git" portion with the short hash makes it much more > accurate to what git version the patch applies to. but it breaks sorting. > Also condensing the date to skip the century is a good idea in the > year 2016. Still 84 years to come without a century problem of patch > file names. This makes it harder to spot as a date. > I would even go that far to skip the date completely. It doesn't > really tell you much. If someone bothers of the age of a patch, then > you can always check git with the hash. We already had this discussion, Anselm, and we concluded back then that the date is a great heuristic. The git hash first forces you to have the repo at hand. When you go check the patches, the first thing you have to think about is: Is this patch still quite recent? The recency is always with respect to the project at hand, however, this decision can only be made by the user and depends on the nature of the commits. Additionally, if you have a list of patches st-externalpipe-ea87104.patch st-externalpipe-fbd023a.patch st-externalpipe-fe0239e.patch you don't see which one is the newest one. As a last point of thought: The shorthash gives no info at all. It could either be a broken patch against HEAD or not, however, pasting the hash in the name somehow claims more than it does, and gives less information to 99% of people. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Wed, 15 Jun 2016 09:07:03 -0800 Britton Kerin wrote: Hey Britton, > While I agree it's annoying to have the patches fail, I'm still happy > I was able to find dwmfifo, it's quite useful to me and the patches aren't > so rotten that they're hard to figure out. So maybe just fix the misleading > file names? Also might be nice if the dates in the names corresponded > to an actual date of a commit (I guess at the moment they correspond to > the nearest earlier commit but I haven't checked). we also had this discussion already. The point here is: using the date of the "update" is the best and easiest heuristic. you see with one look if a git-patch is relatively old or new. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Wed, 15 Jun 2016 19:21:58 +0800 Pickfire wrote: Hey Pickfire, > I suggest using the same syntax as in st which is well maintained, eg: > > st-scrollback.diff > st-git-20151217-scrollback.diff yeah my bad, this is the current established standard. The issue with that is, that in a directory structure, they are easy to point out. A sorted output would put st-scrollback-6.1.diff st-scollback-git-20151217.diff together. And to be honest, it confuses the heck out of me every time I make updates to the patches. > Talking stuff here won't change much, just change suckless.org/wiki.md > so that most of the people can see it. Yes, very good point. I'll look into it. Cheers FRIGN -- FRIGN
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Tue, 14 Jun 2016 17:28:53 -0800 Britton Kerin wrote: Hey Britton, > The -6.1- substring seems to imply that these patches are intended to > apply cleanly to version 6.1, but the date strings that are appended > suggest that maybe they aren't. And they don't (for these two at > least). > > How is this supposed to work? > > I could make a script to test the patches again the given version if > -6.1- or something is included. this is all too complex, as most people who submit patches here lack diligence: Patches with versions should apply to the released versions. Everything upstream should be called "git" and the date of patch release. It's the task of the patch maintainer/submitter to rebase his patches accordingly to each release, which is not difficult as dwm has very slow releases. Say, I submit a patch today to give dwm a HAL-9000 color scheme and call it dwm-hal-6.1.patch dwm-hal-git-2016-06-14.patch applying to both the 6.1 release version (always the latest release for patches) and the git HEAD respectively. Now, let's assume I go abroad to North Korea or something, and nobody gives a shit about the patch (Most of the dwm patches in the wiki are dead, I did the cleanup for st already, but dwm is still pending). Now, let's say we release 6.2 and 6.3 before I return. So, now, when I check back in in 2018, what I should do is create the following patches: dwm-hal-6.2.patch dwm-hal-6.3.patch dwm-hal-git-2018-05-13.patch And that's it! :D TL;DR There are 3 rules here that we should abide to: 1) If you update the patch against git HEAD, remove the old git-patch. There should always be one latest git patch. People who really need an older git patch can check the suckless-wiki git-logs. 2) If you publish a new patch, create 2 versions: for the latest release and for git HEAD (even if they're the same) 3) Maintaining a patch involves both creating new patches for future tags and updating the git-patch as often as necessary so it's easy enough to use. An exception is when a feature pulled into mainline makes the patch superfluous. A point of debate for me really is when it comes to those super- fluous patches. Should we remove them or provide them for older versions of dwm? In my opinion, there is no reason for this legacy stuff. The dwm-patch section is already cramped enough, a cleanup would be pretty helpful. What do you guys think? Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Fri, 10 Jun 2016 03:02:44 -0700 Louis Santillan wrote: Hey Louis, > As to justification, I'd say, that depends. Libc (and C in general) > has some well known, well documented bugs that exists simply to keep > old code compiling (many methods that start with str*, malloc/free > corner but frequent cases, etc). I'd say that's sucks. And that is > why we have seen the proliferation of languages in the last 30 years > (since ansi c acceptance). A condition of NIH and a far worse sin > than trying to fix the situation by utilizing a lower level api. can you give an example? Posix sometimes does some weird shit, but definitely not are bugs standardized. What I noticed though is that Posix likes to keep the use of "char" even though it means "byte". > Take Plan 9 or Go-lang. Is that NIH? Or is that someone > experimenting and/or seizing an opportunity to suck less? Woah, hold your horses there for a minute. You are comparing a hacky libc-wannabe-codechunk, hardcoded on top of Linux syscalls and arch-specific with one maintainer with Plan 9 oder Go? I would be the first to go forward and call for maybe a simpler approach to this whole (or)deal, however, I really don't see so much that would justify tipping over all existing code built on top of the libc and starting anew. Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Thu, 9 Jun 2016 23:06:54 -0700 Louis Santillan wrote: Hey Louis, > Good job for getting this working. I'm a believer that suckless > indirectly speaks to API design in addition to software design. There > are many parts of libc that suck, IMO. Years ago, when I found Felix > von Leitner's talk about software design [0], and dietlibc [1], and > libdjb [2], and libowfat [3], I became curious about exploring other > runtimes for C [4][5][6][7][8][9]. Keep applying your ulinux runtime. are you joking? This reeks of NiH. In many regards, Posix has issues and without doubt, they can hinder you. But does it really justify just handrolling your own, unportable, probably buggy libc? Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Thu, 9 Jun 2016 19:18:21 +0200 Markus Wichmann wrote: Hey Markus, > Dear Lord, it's been a while since I've seen such nice code make so > bafflingly bad design choices. Where to start? the suckless mailing list is not a place for religious cults. > 1. The whole ulinux thing smacks a bit of NIH syndrome to me. And of > course, it kisses portability goodbye, but then that wasn't your goal at > all. With only i386 and AMD64 supported, I wonder why this isn't in > assembler. Holy shit, I can't even put in words how much NiH it is. Compared to this, Ubuntu's "Mir" was a work of genius! > 2. You immediately block all signals on entry. That means: > - SIGINT, SIGQUIT, SIGTSTP, SIGTTOU, SIGTTIN: There is no way to > control the process from a terminal. You have to get another > terminal out to kill it. > - SIGSEGV, SIGILL, SIGBUS: Undefined behaviour if your code does > anything to warrant the sending of those signals. > - SIGCHLD: Zombies and no way of knowing about them. Why don't you > just ignore it? > - SIGXCPU, SIGXFSZ: No way to gracefully close on reaching ulimits. > And so on, and so forth. And for what? So you can handle signals using > signalfd. That would be good if you actually did that. However, that > only happens if the client never stalls out on you. Yeah, the SIGCHLD thing is definitely a point to consider. If you ignore it, the program will reap children automatically. > 4. Synchronous communication, no forking, no threading --> One client at > a time. So you're using epoll on the same two sockets all the time, > which means you might as well not have bothered. I prefer poll over threads/forks, but yeah, it really is crazy here. > Still, it could easily be salvaged: Drop all the setup code for the > server socket and make the code read from stdin and write to stdout. > Then this server can be run from inetd, or through any ucspi > implementation. That will also remove the glaring issue that the program > must be run as root and doesn't drop privileges even when it's done > doing privileged things. Very good point! Definitely a very good point. It would also simplify the code a lot. > 5. Exiting at the drop of a hat: Your only error handling is to exit, > unless it was an expected error (usually EINTR). That's the opposite of > PHP, I guess, but that doesn't make it better. This is okay for one-shot-tools, but definitely not for servers. > 6. You do know that if you used a C library, you'd have access to > strchr(), strcpy(), and the like, right? Because you seem to be having a > jolly good time rewriting those over and over again. Which is a big shame. He could've saved some LOCs using a bloody libc. > 7. What's with the S_IFMT constants? You're binding hard to the syscall > interface, you can use 0666, it's not getting any less portable now. > 8. You do know that C has more loop contructs than just the endless one, > right? Because I'm seeing a lot of endless loops that are basically > do-while loops, or counting loops... C has structured programming. Use > it! Please... > 9. Oh wait, I see that you have strcpy(), you just don't use it. > Alrighty then. > And that was just what I saw in lnanosmtp.c. And I didn't check the > protocol. It's just a big fucking mess there is no need for. Sylvain, sit down again, use a fucking libc so fucking BSD users and other arch users can fucking use your shit. Then we can talk. Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
On Thu, 09 Jun 2016 15:02:29 +0200 Kamil Cholewiński wrote: Hey Kamil, > So libc is overkill, but instead you ship an entire tangled hierarchy of > nonportable and arch-specific headers to talk directly to the kernel, > which will all probably break in a random point release. I couldn't agree more. > > Overkill, don't need that much. This is so full of bullshit. There's no reason e.g. not to make it compilable on the BSD's. The Linux syscall-interface is also prone to changes. You should really re-think this decision. If you talk about overkill, what is the big deal? You'll find a libc in any system really, and even for crazy embedded cases, you could just create a statically linked binary. Cheers FRIGN -- FRIGN
Re: [dev] [lnanosmtp]
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 Cheers FRIGN -- FRIGN
Re: [dev] pledge(2) patches
On Mon, 6 Jun 2016 13:36:14 +0200 Martin Kühne wrote: Hey Martin, > Having done my own research, no it can't. Also, the way it is designed > is a rather silly approach to security which is much more revealing > about today's idiotic way of writing software by including tens of > millions of SLOC of dependencies instead of doing the one thing for > the one job. pledge(1) is not a security-feature, but a hardening-feature. Keep that in mind. The secure design of software (i.e. separating into sub-components that do one thing and do it well) is still up the programmer. However, you bring up a good point. I mean, even we here at suckless are guilty of this. Why exactly do we need to have one dwm.c for dwm? One st.c for st? Especially in regard to st we could easily split the terminal emulation and rendering part. If we based the rendering on simple primitives, it would be relatively easy to port it to other platforms. What it all brings up is the issue of IPC. Can you people suggest your favourite approach to IPC? If not, maybe we could look into writing a very simple library (name-suggestion "sippy" :P) which builds on top of UDS and implements a very simple messaging protocol. > I personally find the idea of polluting our source code for this > appalling and suggest the wiki. We also had the idea yesterday on IRC to let the OpenBSD guys know and just help them apply the patch to the st port. Cheers FRIGN -- FRIGN
Re: [dev] pledge(2) patches
On Mon, 06 Jun 2016 10:02:05 +0200 Kamil Cholewiński wrote: Hey Kamil, > The "problem" with pledge, is you have to let the program initialise > completely, and only then drop the privileges. Otherwise it could've > been implemented as a flag on the executable file. You can also pledge multiple times. I don't know if we can separate st so much into an initialization- and idle-stage. > If you'd make this a generic hook, it might get tricky to inject the > right behavior at the right stage, plus the cognitive cost of extra > indirection / abstraction. I don't see this issue here tbh. Trivial pledges, like disallowing network access and stuff can always be done. > Pledge is extremely human-friendly, and about as simple as it can get. > In almost every case, calling it is two lines of code, with xpledge it's > one. Compare with SecComp. This is no discussion about SecComp vs. pledge. This is solely a question if we should add a very good security feature, which unfortunately is not portable (yet). > Agree, however I've also found this: > https://github.com/Duncaen/OpenDoas/blob/master/libopenbsd/pledge-seccomp.c > TLDR: pledge on Linux implemented in terms of SecComp. As far as I know, SecComp has some weird behaviour when you exec. Other than pledge, which "resets" the permissions, SecComp keeps the limitations. Because of that, the only way would be to somehow disable Seccomp before execing, risking a TOCTTOU-problem. Cheers FRIGN -- FRIGN
Re: [dev] pledge(2) patches
On Sun, 5 Jun 2016 13:11:15 -0700
Ben Woolley wrote:
Hey Ben,
> Regarding #2, the usage stats of openbsd should be joined with the
> usage stats of st. I don't know the answer, but I am guessing not
> insignificant, especially since an openbsd user was driven to do it
> already. And it might increase now that it has pledge support.
> Terminals accept arbitrary input, so pledge support could be a very
> desirable and well-suited feature.
this is a very good point I didn't think of beforehand. In this
regard, we might want to think about an option, however, why not
do it like this?
#ifndef __OpenBSD__
int pledge(const char *promises, const char *paths[]) { return 0; }
#endif
This way, we can call it easily in the code without troubles.
I admittedly am a huge supporter of pledge() and would be happy
to see it included in suckless tools. However, there always will
remain a bad aftertaste given it's an OS-dependent solution.
However, to be fair, I think OpenBSD is the best OS out there.
Cheers
FRIGN
--
FRIGN
Re: [dev] pledge(2) patches
On Fri, 03 Jun 2016 19:46:18 +0200
Christoph Lohmann <2...@r-36.net> wrote:
Hey Christoph,
> Adding sloc will never get you security.
This is right in many cases, but for pledge(1) it makes sense,
however, there are 2 reasons why I would oppose a mainline-
include as well:
1) starting with #ifdefs is a long road and can lead to hard
to read code ("ifdef-hell")
2) the usage-stats of OpenBSD don't justify the inclusion
unfortunately.
Cheers
FRIGN
--
FRIGN
Re: [dev] [dwm] Window not created on external monitor with LibreOffice Impress
On Tue, 31 May 2016 18:42:45 +0100 Chris Down wrote: Hey Chris, > This is with a heavily patched dwm 6.0[0] and LibreOffice 5.0.6.3. can you also reproduce this bug with vanilla dwm (git upstream!) and the latest stable version of LibreOffice (5.1.2.2)? Cheers FRIGN -- FRIGN
Re: [dev] Different versions of suckless libutf
On Tue, 31 May 2016 10:25:22 -0300 Marc Collin wrote: Hey Marc, > Looking at libutf, I realised there are many versions? > There's an outdated version on the suckless repo by cls[0]. > Thee's an up-to-date version on cls private github[1]. > There's a fork on sbase[2]. > Is there a reason for the fragmentation? Which is the prefered libutf version? as a quick note, the sbase libutf is probably the most feature-rich one. The version by cls suffers from multiple issues, even though it might be the most recent. I am currently working on a new libutf which is much simpler, much more secure (de/encoder) and actually gets the grapheme handling right. Stay tuned. Cheers FRIGN -- FRIGN
Re: [dev] pledge(2) patches
On Wed, 18 May 2016 18:50:15 +0200
Kamil Cholewiński wrote:
Hey Kamil,
> Included are pledge(2) diffs for dwm, dmenu, st and slock. I've been
> testing these for a week now (both stress-tests and normal usage), and I
> have no ill effects to report.
I would never welcome this, but I'm glad to make an exception for
pledge(). Use the define trick
#ifndef __OpenBSD__
int pledge(const char *promises, const char *paths[]) { return 0; }
#endif
though.
Cheers
FRIGN
--
FRIGN
Re: [dev] opportunities for dwm docs to suck even less
On Tue, 17 May 2016 16:12:31 -0800 Britton Kerin wrote: Hey Britton, > There are a couple problems: then fix them god damn it! Suckless is a group of people who take matters into their own hands. Clone the dwm/wiki repos, fix the wording and submit a patch. I'm positive you can make valuable contributions to this project, it's just you to make the decision. Cheers FRIGN -- FRIGN
Re: [dev] [sup] Bring the simple user privilege escalation tool back home?
On Tue, 17 May 2016 08:54:19 +0200 Anselm R Garbe wrote: > I can only imagine he meant sandy which I would suggest to be removed asap. Yes sorry, I meant sandy. -- FRIGN
Re: [dev] [slock] PAM support
On Mon, 16 May 2016 17:21:01 +0200 Jan Christoph Ebersbach wrote: Hey Jan, > I've added support for PAM authentication to slock. When you try it, > I'd very happy about feedback because I haven't really done any serious > work with PAM yet: > > http://tools.suckless.org/slock/patches/pam_auth I'm not a big fan of PAM, but it's fine as an external patch. The document was not found because the wiki hadn't been updated. I did it and now it's accessible. Cheers FRIGN -- FRIGN
Re: [dev] [dwm] [patch] config.o
On Sat, 14 May 2016 16:24:10 +0100 Connor Lane Smith wrote: > Attached is a dwm patch that pulls out all of the key and button > handlers, and all of the layouts, into a new file called config.c, > replacing config.h. The idea is that it makes it clearer what is dwm > proper and what is just a part of the default config. > > I've sat on this patch for about half a year, and I've still not made > my mind up as to whether it's a good idea or not. But I thought I > might as well post it on here anyway. Also opposed. The config.h-semantics are consistent across suckless tools, and thus, breaking it breaks consistency. Cheers FRIGN -- FRIGN
Re: [dev] Linux distros that don't suck too too much
On Thu, 12 May 2016 18:19:01 +0200 hiro <23h...@gmail.com> wrote: > What is suckless' response to this? Do we have enough manpower to > maintain a webkit-shim, an archaic terminal emulator, a window manager > AND an ssl library? cinap is trying to fix the latter problem on > 9front, but it turns out the whole underlying specs are shit, too. so > it hardly matters how high the quality of your code is. if you want a > secure system you should pull the plug altogether. LibreSSL is fine, no need to reinvent the wheel. While keeping software simple it is possible to maintain it with few people. -- FRIGN
Re: [dev] Re: Linux distros that don't suck too too much
On Thu, 12 May 2016 17:59:40 +0200 hiro <23h...@gmail.com> wrote: > you guys are arrogant but still sheep. you can create as much elitist > software as you want, you have no chance to be interoperable with > every real-world system that we need access to. > > as much as i hate the cheesy term (i find it ridiculous to hint > towards something so obvious, but you "noobs" manage to prove me > wrong), you also don't even get "suckless". it doesn't mean running > pure code exclusively like RMS does. > > we demand a certain amount of pragmatism, cause the way towards > perfection can by definition not be the goal. elegant workarounds, > practical alternatives, sane preselection of ressources, interfaces, > apis are needed. and the things we interface are not only dwm window > managers or shitty terminal emulators made to run ncurses > applications. suckless strives for perfection in an environment where most people are illiterate. We are like a book club in india, but just because we literate while the majority is illiterate it doesn't mean that we are doing something wrong. We may not be a big force, but at least we're heading in the right direction. -- FRIGN
Re: [dev] Linux distros that don't suck too too much
On Thu, 12 May 2016 02:33:41 +0200 hiro <23h...@gmail.com> wrote: Good morning hiro, > let's maintain a list of of requirements a distro should fulfill. > perhaps we can make a nice table afterwards and see which OS fits > these requirements out of the box. > i'll start with this. convince me otherwise. it's an interesting idea, though you'll run into contradictions. There is no definite "best" OS, it depends on what you want to do with it. > 1. package system: packages having few, sane dependencies (early > tinycorelinux was excellent in this regard) directly contradicts > 9. hip applications have to run out of the box: skype, chrome, gimp, > openoffice, mplayer, openssh, rsync, irssi, mutt, qmail, gparted, > ntfs-3g, sbase/9base, (some file manager? i have no idea about such), > what else? The thing is, that once you want to install these "hip" programs, you end up pulling in tons of dependencies. The stali approach is to say: Well, if we can't cut the suck out of the hip, we suck the hip out of the suck and run each application in sort of a "jail" (namespace, chroot, w/e). This allows uninstalling programs easily, but of course comes with some limitations (dynamic libraries and stuff). Statically linking bloated applications is also a waste, but maybe a way to go. > 4. no fucking complicated powersaving scripts (laptop tools, s2ram and > such shit) for old shitty CPUs that are inefficient anyway > (speedstep), it's the kernel's job to save power, simplicity over > cargo-culting. And as I've noticed, you can save a great deal of power not running bloated programs. A heuristic for this is the RAM usage (and of course idle CPU %). If you take up 50% of your RAM just browsing the web no wonder your battery is eaten up faster than chicken wings in Wing Bowl 2016. Protip: Decrease display brightness, it's the most important factor. > 6. no stupid sound system, OSS3 or alsa is enough (yay tinycorelinux) Even though nothing comes close to sndio. > install doesn't ask stupid fucking retarded questions like: You forgot to list the stupid fucking retarded questions. > 14. username, just use the default name (e.g. fucksudo, optionally > something more corporate) and let it get root via sudoers without > password (because sadly root is broken by stupid people trying to > nanny us about not running their shitty apps as root) (tinycore yay) > 15. password: don't ask me for a fucking password, just log me in to > something that has superuser privileges. IM SITTING IN FRONT ANYWAY. I > know how to run the passwd tool or set up my .ssh dir myself. > (tinycore yay) I'm not too sure about this point. On some distributions, you can literally brick your hardware by writing to some /sys variable as root. I don't feel comfortable running Chromium as root to be honest, it's like unprotected sex with a street hooker. > 18. text editors: ed, perhaps vi vi is fine. Cheers FRIGN -- FRIGN
Re: [dev] Linux distros that don't suck too too much
On Wed, 11 May 2016 11:56:41 +0100 Nick wrote: Hey Nick, > A few nights ago my too-expensive laptop met with too-cheap wine and now > it is a far-too-expensive brick. As it's therefore time for me to > install a new OS on a new laptop, I was wondering what people would > recommend. I've been using Debian Stable for years now, which while it > sucks does work well enough that I don't have to think about it very > much, so I can do more interesting things with my time. But particularly > after reading a few good articles about issues with debian [0] [1] I > find myself wondering if there's a better option out there. A rolling > release distribution would be fine with me, but only if it didn't break > often at all; I enjoyed using Gentoo years ago when I was a student, but > keeping it working took a lot of time that I do not want to dedicate to > keeping a working system these days. I'd like to try something like > morpheus [2], but I suspect that would take quite a lot of time and > energy to get going and maintain. first you have to assess if you really need Linux. If not, there's nothing better to recommend than OpenBSD. Unfortunately, due to my work, I depend on different Linux things that are not available on OpenBSD (wine, fuse, LUKS, ...) and which cannot be replaced efficiently. I'm running Gentoo atm and once you've got a running system even Gentoo is not too much of a chore (at least not more than Debian, which sucks ass). If you depend on Linux-stuff, I'd take a look at Gentoo again. For rolling releases, you can go with -CURRENT on OpenBSD. Cheers FRIGN -- FRIGN
Re: [dev] [dwm] altera quartus ii qsys gui not showing
On Tue, 10 May 2016 11:55:46 -0300 Vitor Bandeira wrote: Hey Vitor, > This is a very specific problem, but I couldn't find a solution on my own. > I use the Altera's Quartus II (v15.1) in my machine with Arch Linux x86_64 > (kernel 4.5.2.1). > All other tools of Quartus II work normally, but when I open the Qsys tool a > new window is open, but it stays blank. > I tried with other window managers (i3, awesome, xfwm4) and in all these the > GUI loads normally. > Is this a limitation of DWM or a bug? I have the same issue with Matlab, so I have to deploy the wmname-utility (it's an in-house tool, should be in your package manager). You can fool Java into displaying the GUI properly by passing the right window manager name to it. So for example, the window manager name LG3D is just fine, so before starting Qsys you run $ wmname LG3D in your shell and it should work. Cheers FRIGN -- FRIGN
Re: [dev] [sup] Bring the simple user privilege escalation tool back home?
On Sat, 7 May 2016 12:36:38 -0300 Marc Collin wrote: Hey Marc, > Wouldn't it make sense to give jaromil access to the suckless git > repository and let him work there? > What does everyone think? I don't know jaromil and it seems like he is not even subscribed to the mailing list. Having push-rights for the suckless.org-git-repositories is a privilege and won't be given up to strangers. Keep in mind that giving somebody push rights enables him to push to any repo on git.suckless.org. As the developer announced, he'll add bloat to his software, and I think the vis editor alone is enough bloat in the suckless repositories. Cheers FRIGN -- FRIGN
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Mon, 2 May 2016 17:57:15 +1000 Timothy Rice wrote: Hey Timothy, > I'd be more interested to hear about what actually makes C inherently > better than Go. I quite like C: it forces you to think about the machine a > little bit, and it disincentivises large complicated programs. But I > currently have no rebuttals against the Go argument other than ad hominems > about hipsters ;) It's not about C or Go being inherently better, it's about which language is the best tool for the job. Go always comes with a garbage collector, which I personally don't need because I can very well keep track of shit I allocate and don't like GC's in general. This lack of control is something that gives me headaches, but I understand that this is necessary to have the other security measures in place. Most "hipsters" leaning towards Rust are those people frustrated with learning C in the first few steps. They analize their failures at programming working software and blame it on C's freedom. This trend can also be seen with more experienced developers who stick to bad practices, and I know it's very easy to write horrible C programs, especially if you do it on a payroll. Benjamin Franklin said this: “Those who surrender freedom for security will not have, nor do they deserve, either one.” And this defines what it's all about. C is all about freedom, and any measure a higher level language applies is a cut in freedom while increasing "security". There's no way around it. It's like the people who promoted communism in the 50's in America as the kool-aid to solve all the problems of a liberal market. What they didn't say is that a communist system can only work when there are strict regulations, and from the day JFK was assassinated on, US-Americans paid for their security from "terrorism" by giving up more and more freedoms. Same applies to EU-Europeans who bow down for the centralist EU-laws cutting each of our own laws protecting privacy and freedom of expression. Everybody has the choice to either choose a language which gives you a big range of freedom of expression or use one that dictates how you express yourself in tight margins. Cheers FRIGN -- FRIGN
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Mon, 2 May 2016 11:12:08 +1000 Timothy Rice wrote: Hey Timothy, > 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? thank you for bringing that up! I'd jump into Go right away if it wasn't for the binary sizes. Go may have comparable speeds to C and makes a lot of things much simpler to do, but the binary sizes are just insane. They'll address this in the upcoming versions, but until then, I'll not look into it. Once the day comes and a hello world goes below 800K (400K, ...), I'll definitely look into it. Cheers FRIGN -- FRIGN
Re: [dev] "Note On Webkit Versions"
On Sat, 30 Apr 2016 18:54:39 +0200 Kamil Cholewiński wrote: Hey Kamil, > You don't need a proof, you only need a significant improvement upon C, > which Rust delivers. the big drawback of Rust in my opinion is lack of readability. There are too many things to do one thing and it suffers from the same issues many novelty languages suffer from. Repeating the mantra of "safety" is also not smart. Either you can shoot yourself in the foot with a language or not, and if you look at Rust and do anything low-level, you just have to work around the "safety" the language provides. It is very well possible to write safe code in C, but it takes consideration and requires the programmer to actually put thought into what he does. > In C, 100 in every 100 lines is "unsafe". > Rust has its own insanities though. C just cuts the bullshit and doesn't hide the fact how computers really work. A language can be "secure", but in the end, it will all boil down to what C shows us every day. I wouldn't like to see a Rust-flamethread emerging on this mailing list, as the Rust-supporters here are probably a loud minority. The suckless-ml is the wrong place to promote Rust and there is a lot of material on the web on why Rust cannot in any way be considered even barely a suckless language. 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. Cheers FRIGN -- FRIGN
Re: [dev] Hi, newb here.
On Mon, 18 Apr 2016 21:18:25 +0300 ab wrote: Hey ab, > What kind of advice could you guys give to a novice? I'd like to get > myself more familiar with Linux and C (because I have a copy of K&R). > I'm asking you guys because you seem to know what you're doing and > you're the only community I know which are committed to what you do. read K&R and read suckless code. :) Join in on IRC (#suckless on OFTC or #2f30 on freenode) and ask questions if you like. #suckless is a strict development channels, so newbie questions are honestly more welcome on #2f30. Cheers FRIGN -- FRIGN
