This is what Cudder tried to do with his anonutils back in... 2008? But as we know, Cudder is all talk and no action, so the end result was around a dozen half-assed, incomplete, bug-ridden utils. Learn from this, Cudder, you little prick.
The echo utility shall not recognize the "--" argument in the manner specified by Guideline 10 of XBD Utility Syntax Guidelines; "--" shall be recognized as a string operand.
Implementations shall not support any options.
Name:
Anonymous2015-04-03 8:36
Suckless? LOL, more like dickless, even the echo is wrong. And that's the easiest of them.
This is a "known issue". Basically, on return, the system flushes all buffers. in case flushing errors-out (the libc fails to write its internal buffers to the kernel device) it can't report an error and ignores it. GNU coreutils solve this by having an onexit-function doing the cleanup and reporting errors in case something fails. However, _exit is usually used across sbase which doesn't call onexit-functions and generally speaking, onexit-functions are a pain in the ass to take care of. Another idea was to have a efclose-function which closes stdin and stdout at the end and reports an error in case it fails. However, it's not simple to take care of that across sbase either. In the end, the conclusion was that this is a more or less non-priority issue. This has been kept it mind, same with echo, but not reflected on it as there were more important issues.
If you have any ideas, let it be known.
Name:
Anonymous2015-04-03 21:36
I copy-pasted >>17 from IRC. The developers said they won't use this BBS because they aren't hipsters and that people should send patches. They don't give a damn about anything but patches, even though >>7-san made them review echo(1). Who the hell criticizes people testing their software and reporting bugs? LOL I've never seen this before.
>>17 What's wrong with this? return fclose (stdout) == EOF; It seems to work nicely for the case of >/dev/full, fflush works fine too. Or they could just use write(2) like their friends at plan9, write does not use buffers. (or just disable buffering on stdout)
Name:
Anonymous2015-04-04 5:03
>>18 Why would they give a damn about this BBS... They don't get it, they're filthy casuals. >>3 I remember... fuckn spammin his AnonOS project everywhere
Name:
Anonymous2015-04-04 19:05
>>18 4chan/g/ ``trolling'' mozilla. Social Justice Warriors spamming mailing lists. There's a reason for it.
It's too bad the last update was 2014, they need more people to keep the packages current.
Name:
Anonymous2015-04-05 11:13
>>31 Alpine Linux is a complete system using musl libc. Why not work on it instead of coming up with another distribution? Just convince Alpine developers to migrate to sbase, sinit, etc. and be done with it. Can you imagine Morpheus getting libreoffice, firefox and all other big programs? I can't.
Name:
Anonymous2015-04-05 11:44
>>30 Wow, nice. Except it should've been implemented in Haskell, not Racket.
Name:
Anonymous2015-04-05 23:02
>>33 Wow, nice. Except these dubs should have been gotten by a more worthy poster.
/* because putting integers in pointers is undefined by the standard */
What? uintptr_t is very well defined.
Name:
Anonymous2015-04-14 19:29
>>38 uintptr_t is unsigned. It looks like the author wants a signed integer here and that is a significant difference.
Technically uintptr_t is also a POSIXism so if you actually care about non-Unix like systems it's best not to rely on it. Since this is a suckless project I assume that is not the case here, though.
Name:
Anonymous2015-04-14 19:59
SuckLess Unix Tools
Name:
Anonymous2015-04-15 16:16
>>39 How is it a POSIXism? It's standardized in C11 and was already in C99 if I remember correctly.
Name:
Anonymous2015-04-15 16:34
>>39 Why would anyone care about non-Unix platforms besides maybe Windows, which is never going to be truly portable without massive rewrites or compatibility layers anuway?
Name:
Anonymous2015-04-15 16:39
uintptr_t is unsigned. It looks like the author wants a signed integer here and that is a significant difference.
I don't know which commit you're referring to, but conversion from a signed integer of the same size to uintptr_t is well-defined by The Standard, see 6.3.1.3.
Name:
Anonymous2015-04-15 16:44
why would a pointer ever be "signed"?
a pointer difference I can understand but not this..
>>44 It's not the pointer that is signed, read DA STANDARD.
Name:
Anonymous2015-04-15 18:14
>>41 Unix programmers have been stashing pointers in longs and the like since (approximately) the beginning of time. POSIX provides cover for many historic practices like this one (use of void * to store function pointers is another example). C99 is too recent.
>>43 It may well be defined but the conversion is still destructive.
I will confess I forgot about intptr_t entirely. I believe this particular code could get away with using an intptr_t or if the the range of values to be stored will fit in an intptr_t.
Name:
Anonymous2015-04-15 18:44
>>19 I am guessing it is just laziness. According to >>17 sbase is relying on required implementation behavior of closing streams after exit, which is of course too late if you want to set the exit status should closing fail. This is painful if you have a lot of streams open but in the case of things like echo it is not so hard.
>>47 No, it's not laziness. We found out it's not mandated by POSIX that the fclose-function should return an error in case the flush fails (yes, you read that right). Glibc just behaves this way, and we only noticed that after testing with musl and discussing this with the musl-developers.
fshut() is the combination of literally a day's work of reading standards and applying best practices. A simple fclose() is not sufficient here.
Name:
Anonymous2015-04-18 21:36
>>50 I think the musl developers are being legalistic here. The description of fclose in C89 says it shall deliver buffered data to the host environment (just like fflush does) and return EOF if any errors occur. Not returning EOF for a write error just because it's not specifically called out like the fflush description does is bullshit, or at least very surprising.
Can you name any libc other than musl that behaves this way?
Name:
Anonymous2015-04-18 21:50
In fact, POSIX has exactly the same text in fflush and fclose in the RETURN VALUE section (except the "it shall set the error indicator for the stream" part simply because the stream will be closed). It also says "The fclose() function shall cause the stream pointed to by stream to be flushed and the associated file to be closed". It does not say anything about not returning EOF if an error has happened in the flushing part. And in fact, some of the ERRORS in the POSIX page are about flushing failing.
Name:
Anonymous2015-04-19 6:06
>>52 Yeah, looking at the POSIX.1-2013 version of the spec, if you look at the History section for fclose, you see that the errno values for the errors that could occur during fflush were added a couple of years before POSIX.1-2008 was ratified.
musl advertises itself as supporting POSIX.1-2008, but maybe the musl developers erroneously were looking at the older IEEE 1003.1-2001 spec when implementing some of those functions.
In the README0 it says tar is audited. Why so many changes and fixes, then? Audited should mean it's pretty close to perfect. Remove the audit flag and audit everything again, I propose. And keep doing that: multiple audits. What do you think?
I sent a patch for st. I'm using st every day now, it's sugoi!
>>73 Your idle jealousy is showing, Cudder. Your anoncoreutils were in vain, because you didn't have what it takes to see things through to completion. If only you were a man, instead of being a girl who has long lost her innocence.
Name:
Anonymous2015-04-22 2:37
>>74 Can you send a patch to make st work with the keypress ``Delete''? Onegai, it makes me nervous.
>>87 Tuning in again, because a colleague linked me here.
Please do not misunderstand the term "audit" in this context. It's not easily chosen, as we have security audits in relevant places, but the raw term "audit" is equivalent to a "revision", and that's exactly what I did in the code.
Over the years, we've improved our coding style and how to write good code, so the audits made sure these good styles were applied consistently across the base.
In no way does this claim the software is bug-free after an audit, only in a coding-state which we consider consistent.
It's easy to write bug-free software when it's trivial (e.g. echo, true, false, ...), but the more complex it gets, you can always hit new traps. Don't shit your pants when we fix a bug in tar(1), the recent changes were fixes for edge-cases (limited user-namespace) and are an actual convenience to support tars with vendor-extensions.
We find bugs here and there, but overall, we have a stable product and for instance pass the busybox-tests without problems (modulo XSI-extensions).
>>96 Thanks for the clarification. For your sanity, please don't take the autists and trolls here too seriously when they critique your software, they're just doing it because they're bored and need something to shitpost about. The more intelligent among us understood what was meant by ``audit.''
Thanks for the clarification. For your sanity, please don't take the autistsshrine maidens and trollsyokai here too seriously when they critique your software, they're just doing it because they're bored and need something to shitcutepost about. The more intelligentautistic among us understood what was meant by ``audit.''
Almost all of those are implemented elsewhere on their git repository. Why not just translate the 9base ones or improve the hbase or morpheus-base implementation?
>>3 This is what Anoncoreutils apparently turned into... even the http://git.2f30.org/sbase/about/ looks like the original STATUS file distributed with ACU.
>>12,13 Amusing that the ACU version has error checking, while the sucklessmore version doesn't despite looking very similar.
>>74 That's not me, but I'd rather start things that eventually get picked up by others so I don't have to care about them anymore and can start working on some new ideas. Besides, web browsers are far more interesting now...
for (; *argv; argc--, argv++) putword(stdout, *argv); if (!nflag) putchar('\n');
return fshut(stdout, "<stdout>"); }
Why don't you help with the missing tools? Are you really all talk and no action as people say? This is your chance to actually help a project that's going to be completed.
Name:
Anonymous2015-04-26 20:43
>>113 This. Come on bakas! Let's submit them patches.
>>121 Why the fuck should I, if it's possible to write a self-contained, POSIX-compliant implementation of echo without anything but the standard library? Note that the one in >>12 is completely public-domain, as is the rest of ACU, so they could've just copied its direct simplicity.
I have a feeling this is just going to turn into another GNUish project like gnulib/libiberty/all that other shit. You are in a maze of twisty little dependencies, all alike...
This is certainly not in the spirit of ACU. I've already contributed enough in the form of ACU, if you don't want to make use of it and reinvent your own bastardised version of POSIX, then best of luck, gentlemen.
>>125 It's good to have such a maze of dependencies. It makes it easier to get users to install more of your stuff, and much harder to separate one thing from another. Same reason why GCC internals were such a mess: it prevented proprietary developers from stealing it and making new front-end language parsers or back end generators without paying the GNU Tax (your freedom from 1000 lines of license comments in every file). Genius, really.
I prefer Windows' echo though. A simple echo off will silence all echos until you turn them back on. Convenient.
Name:
Anonymous2015-04-28 8:30
>>109 I find the preponderance of static globals rather disheartening.
>>126 >>127 The goal of ACU is a set of simple, self-contained standard utilities that anyone with a reasonably POSIX-compliant system could pick and choose, and compile without any further dependencies. Public-domain and anonymously contributed (I did say I started the project and wrote some of them, but you don't know which ones, and there are no names at all in the package), free for anyone to use however they want.
This suckmore is going in the opposite direction. Not public-domain, not standalone, not anonymous.
Name:
Anonymous2015-04-28 11:04
>>129 MIT/X (= ISC) is as close to public domain as possible. Additionally, there are many states who don't even ack the existence of public domain. Which dependencies are there apart from libc in suckless base? I read the code and found none. You are only anonymous because your face is ugly.
>>129 Since when is it bad to put common functions used by the many tools in their own .c files? That's what libutil and libutf are. They make sure there's no unnecessary duplication of functions over the many different tools. But you wouldn't know that, since your attempt with ACU was absolutely superficial and the scarce tools you implemented probably didn't have common functions. Get lost, kid. You are all talk and no action. You never finishes anything you start.
Name:
Anonymous2015-04-28 20:29
1. put the code into a separate library 2. statically link that library in each binary it's used
fucking LOL
suckless logic is almost the same as women logic (utterly retarded)
Name:
Anonymous2015-04-28 20:35
suckless hello world implementation: #include "util.h" int main() { print_hello(); } LOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOLOL
Name:
Anonymous2015-04-28 22:38
Wow, check out this putword implementation /* See LICENSE file for copyright and license details. */ #include <stdio.h>
#include "../util.h"
void putword(FILE *fp, const char *s) { static int first = 1;
>>132 If anything the amount of extra space you're taking up in the symbol table with an additional (imported) function call and the code of this >>135 absolutely trivially stupid function is far more than just integrating the bloody thing into the source. It is literally a compare with an existing variable and a conditional function call, which you can't do if you decide to pull it out separately so you have to make an extra fucking variable THAT IS ONLY EVER USED ONCE! Instead you have to go through the motions of passing parameters and register saving/restoring and all that stupid shit that compilers do when they call functions.
Why don't you refactor all the for loops out into their own function too? Or all the if statements? After all, they are "duplicated code". This is near that level of retardedness.
You've also not propagated errors correctly... so it is a FAIL!
...and your stupid function call bloat (5 bytes + import table + register save/return + ...) turns into a single 2-byte jump instruction if we use the power of goto:
If anything the amount of extra space you're taking up in the symbol table with an additional (imported) function call and the code of the putword function, for example, absolutely trivially stupid function is far more than just integrating the bloody thing into the source. It is literally a compare with an existing variable and a conditional function call, which you can't do if you decide to pull it out separately so you have to make an extra fucking variable THAT IS ONLY EVER USED ONCE! Instead you have to go through the motions of passing parameters and register saving/restoring and all that stupid shit that compilers do when they call functions.
It is one thing when your ACU project is slammed on some message board on the Interwebs, it's another when you start "criticizing" another project on false grounds. I'll give you a small hint: The symbol table does not matter too much in statically linked applications (and that's what's supposed to happen) and libutil is not dynamically linked into the binaries. If the compiler detects a function to be "trivial", it will inline it automatically. I can understand the motivation to do that manually to optimize the code, but premature optimizations are the first step towards broken and unmaintainable, chaotic code (look at ACU).
Why don't you refactor all the for loops out into their own function too? Or all the if statements? After all, they are "duplicated code". This is near that level of retardedness.
Check out GNU coreutils if you like that.
You've also not propagated errors correctly... so it is a FAIL!
The symbol table does not matter too much in statically linked applications (and that's what's supposed to happen)
Oh $deity... :facepalm:
So you do all that work of extracting the function to avoid "duplicate code"... just so the compiler can put it back the way it should've been written in the first place!? WTF.
I can understand the motivation to do that manually to
optimize the code It's about optimising for efficiency and readability. By extracting that function you have required the reader to know what that function does... when she finds out, it happens to be something inanely trivial... and you're doing it in one of the most trivial of utilities.
premature optimizations
You're making premature pessimisations instead.
broken and unmaintainable, chaotic code (look at ACU).
Using big words like "unmaintainable" and "chaotic" does not help your argument. The ACU echo does not require anyone with familiarity with the POSIX interface to read more than a single file to figure out what it does.
Where?
Figure it out yourself if you think you're so smart.
That's a handrolled dirname(3) implementation that nobody can read. I guess using the standard dirname is overkill here.
I particularly enjoy the step_6 label.
Name:
Anonymous2015-04-29 17:15
>>146 step_6: //i inits with length of argument 1(directory) = last letter of dirname //if (current letter of dirname is not NULL(superfluous) and is '/'(slash separator ) decrement i at end of loop for(i=strlen(argv[1])-1;argv[1][i]&&argv[1][i]=='/';i--) //set current letter to NULL(0) truncating the string argv[1][i]=0; if(argv[1][0])//if first letter isn't NULL printf("%s\n",argv[1]);//print dirname else single_slash: printf("/\n");
>>143 Your post was friendly, beginning with in an innocent Hey Cudder and ending with a cheers. But in between the key presses that emanated that text your blood was pumping. Your face was red. Your eyes were focused and your fingers moved with dedicated purpose. When you read cudder-sama's post, something within you broke. Something precious. Your investment in your project and your ego as a eipc coder was threatened. It clicked and you had to retaliate towards the psychological threat. Level it to the ground with a well prepared post. You composed it. You kept it professional. But between the lines, you delivered the attacks that your wounded spirit required. You put your attacker in its place. You recovered your presumed title. You proved your competence. And most importantly, you re-validated your investment in the project that lies so closely to your heart and your identity. And you did it all by typing out a paragraph in a text box.
Hi MarcCudder, You really don't have to be such a twat about all this. Just offer your suggestion without the unnecessary abrasiveness. What I got from your link is that someone negatively compared your work to sbase, and now you've got a bee in your bonnet over it. Are we really going to have to put up with this noise? Thanks, cls
>>151 I know you're trying to be trollish but here's a hint for everyone else who doesn't get it: loops and if/else are useful when they fit the flow of the code. goto is for all the situations when they don't.
>>166 Who are the left and right faces in the top left corner?
>>166 Hi, I got here from the mailing list post. That picture made it worth it.
Too much shitposting though. I'm not sticking around.
Name:
Anonymous2015-04-30 23:26
>>174 Are there anyone else from 2f30 here to actually discuss Cudder's points? Where's sin, cls, FRIGN and all others? This BBS is funny. They must join US here.
I remember suigin was implementing bc for sbase, did he finish it? Will he help with more utilities?
Name:
Anonymous2015-08-03 20:08
I don't give a shit about sui/g/in and bc
Name:
Anonymous2015-08-03 20:15
>>198 Suigin is actually one of the few people here to put out some cool programs. I had a great time playing with his sstoy and studying the source code. Not trying to diminish all the fun/ironic threads and off-topic, that's cool too. But suigin is one of the only people to provide technical stuff that's nice.
and you too >>121 and you too >>120 and you too >>119 and you too >>118 and you too >>117 and you too >>116 and you too >>115 and you too >>114 and you too >>113 and you too >>112 and you too >>111 and you too >>110 and you too >>109 and you too >>108 and you too >>107 and you too >>106 and you too >>105 and you too >>104 and you too >>103 and you too >>102 and you too >>101 and you too >>100 and you too >>99 and you too >>98 and you too >>97 and you too >>96 and you too >>95 and you too >>94 and you too >>93 and you too >>92 and you too >>91 and you too >>90 and you too >>89 and you too >>88 and you too >>87 and you too >>86 and you too >>85 and you too >>84 and you too >>83 and you too >>82 and you too >>81 and you too >>80 and you too >>79 and you too >>78 and you too >>77 and you too >>76 and you too >>75 and you too >>74 and you too >>73 and you too >>72 and you too >>71 and you too >>70 and you too >>69 and you too >>68 and you too >>67 and you too >>66 and you too >>65 and you too >>64 and you too >>63 and you too >>62 and you too >>61 and you too >>60 and you too >>59 and you too >>58 and you too >>57 and you too >>56 and you too >>55 and you too >>54 and you too >>53 and you too >>52 and you too >>51 and you too >>50 and you too >>49 and you too >>48 and you too >>47 and you too >>46 and you too >>45 and you too >>44 and you too >>43 and you too >>42 and you too >>41 and you too >>40 and you too >>39 and you too >>38 and you too >>37 and you too >>36 and you too >>35 and you too >>34 and you too >>33 and you too >>32 and you too >>31 and you too >>30 and you too >>29 and you too >>28 and you too >>27 and you too >>26 and you too >>25 and you too >>24 and you too >>23 and you too >>22 and you too >>21 and you too >>20 and you too >>19 and you too >>18 and you too >>17 and you too >>16 and you too >>15 and you too >>14 and you too >>13 and you too >>12 and you too >>11 and you too >>10 and you too >>9 and you too >>8 and you too >>7 and you too >>6 and you too >>5 and you too >>4 and you too >>3 and you too >>2 and you too >>1
Name:
Anonymous2015-08-03 23:37
>>200,201 Back to the imageboards with your sage down/b/oat, please.
funny how people waste their time rewriting old unix programs, still hanging onto scraps. and still reinventing libc for all of their apps
Name:
Anonymous2015-08-08 3:09
>>229 Apparently that's as good as these jokers are good for. They don't spend time writing substantial software like CAD or graphics drivers, they're only capable of rewriting cat and ls.
Name:
Anonymous2015-08-08 11:35
Unix tools are shit.
- Text streams are not good computational interfaces. - Multiple processes are clunky, slow, and shitty compared to interacting objects. - The shell is a piece of cunt, again with the fucking text wrangling. - Commandline parameters are yet more bullshit text processing for cunts, with the added bullshit of no standardization. - Same with config files.
Fuck "Unix tools" in their crusty ancient ass. There are fucking data types beyond the 8-bit character.
Let this shit die.
Name:
Anonymous2015-08-08 17:08
>>231 But Unix tools are what I used when I first learned how to program a computer. Therefore they are the best.
Name:
Anonymous2015-08-08 17:38
>>231,232 Most people grew up with Windows. They haven't gotten a chance to look at Unix objectively.
Name:
Anonymous2015-08-08 18:06
make an OS kernel which lets you write typed 'core utils' instead of a unix style os.
All I want is to write some stupid dc-scripts, but there's no dc-program?? As long as that's missing, suckless could as well be called dickless. Just another toy project.
>>241 According to their TODO, they are only going to implement bc (almost finished by suigin, but the guy seems to have disappeared? I miss him). Anyway, feel free to suggest dc as a program for sbase, maybe they accept it.
Name:
Anonymous2015-10-26 17:08
dubs
Name:
Anonymous2015-10-26 20:09
>>240 I've been too busy the last few months to work on it, unfortunately. Wageslave job. Not happy. Maybe I should quit.
>>254 It's far from complete, it's just the front end lexer and parser. Plus, they already know about it. Only once it's near completion would I consider notifying them about it again. I wouldn't want to waste their time otherwise.
>>260 Not everyone who opposes your retarded imageboard customs is a SJW. Go fuck a fat feminist if you like them so much.
Name:
suigin2015-12-24 21:43
>>259 What's next on my list is making myself a memorable dinner for tomorrow night, to keep at bay for a few moments the darkness, misery and pointlessness of the collapsing society just beyond the walls I call home.
After that, polish off hebimath. sstoy isn't a high priority.
At this point, I don't think I'd use hebimath directly for the bignum arithmetic in bc(1). It's really more deserving of a custom and minimalistic implementation. Hebimath is more of a lightweight, general purpose replacement for parts of GMP at this moment.
The beloved people at suckmore, thought that it is a good idea to define the (useless) functions strlcat and strlcpy, forgetting, however that identifiers starting with str* are reserved by POSIX.
Name:
Anonymous2016-01-13 3:34
>>267 Write to their mailing list so they can discuss this (and probably fix). As flawed as it may be, I still think sbase is the best implementation of the unix tools out there. Better help than make fun and let it rot. That's my opinion. Do you share it?
Name:
Anonymous2016-01-13 3:48
I still think sbase is the best implementation of the unix tools out there.
You're literally saying that sbase is a polished turd.
I think that's an insult to polished turds.
Name:
Anonymous2016-01-13 3:50
>>269 Everything else is much worse. Busybox, Toybox and all that don't even get utf-8 correct. sbase works flawlessly for me. And your issues are minimal, no? Why not bring them up on the mailing list and help sbase get even better?
Name:
Anonymous2016-01-13 3:53
>>270 sbase can't get better. It, by design & by philosophy, is shit. It is following the shittiest shit of Unix legacy.
It is not written for the benefit of hypothetical sbase users, it is for the ego and lunacy of the sbase programmers themselves. Fuck them, and fuck you.
Name:
Anonymous2016-01-13 4:00
>>271 It benefits me. For example, here are 2 cases on coreutils/busybox/toybox:
$ echo "öã" | tr -d "ö" � $ echo "1ö2ö3" | cut -d 'ö' -f 1 cut: the delimiter must be a single character
Both wrong! On sbase it works though.
Besides that there's also the fact that it is more efficient.
Are you convinced? There's a talk on the suckless website on their last conference where the developer explains why they created sbase.
Stop being such a bully!
Name:
Anonymous2016-01-13 4:22
>>272 This is why I use real programming languages, not this incompetent ignorant-of-each-other piping shit, to do text processing. The shell sucks and should be discarded for programming languages instead of this concatenated text mess with shit C-based half-baked parsers in every fucking program bumbling along a raw char*, and tons of heavyweight processes to do something a few functions can pull off if you care at all about footprint.
Plus, the only thing you can process is UTF-8. Half the text files out there online seem to use other 8-bit encodings, if not 16-bit which was popular for a while.
Name:
Anonymous2016-01-13 4:26
>>273 So you think all unix tools are useless? So your problem isn't with sbase only, but unix itself? Ok, that explains a lot. I guess we have a fundamental disagreement and shouldn't talk any further.
Name:
Anonymous2016-01-13 4:34
>>274 A lot of people here have worded it a lot better than me, but dealing with pipes of bytes which may or may not be arbitrarily-encoded text is not a useful, safe, or expressive abstraction. The process boundaries are useless, expensive, and stupid for so many of these cases. It's all shit.
So you actually enjoy living in 1960s computing tech?
The rest of the world realized that their real problems, real programming expressiveness, real scalability, and real security is not met by that old cruft. Even if their solutions haven't broken free from the shackles of the past, they've made strides.
Name:
Anonymous2016-01-13 5:18
>>268 No, if they are unable to make something as simple as this, they should not make software at all. Not to mention their elitist stance (see >>18), that the issue has already reported (see http://lists.suckless.org/dev/1504/26150.html) and that they have seen this thread.
That epitomizes what I've said about this: This is simply not useful, and far less useful than the alternatives. It's hard to abstract on top of their chosen primitives, so instead of actually making a powerful ecosystem to actually tackle problems*, they just disacknowledge it.
* = of course, everybody else has already tackled these problems
Name:
Anonymous2016-01-13 6:16
>>272 Link to the video? There's a lot of them on the site, and I can't be assed to skim them all.
Name:
Anonymous2016-01-13 11:44
"Premature optimization is the root of all evil." - Donald Trump Knuth
Suckless's root is premature optimization of code size.
Name:
hojad!OUKY5mcbp62016-01-13 13:10
Unfortunately, the tendency for complex, error-prone and slow software seems to be prevalent in the present-day software industry. We intend to prove the opposite with our software projects. promotes C
suckless is a NIH meme for people who value premature optimization over correctness
>>279 The second one, called ``suckless core - A suckless userspace foundation'' Talk about sbase starts at 11:09
Name:
Anonymous2016-01-13 14:14
>>283 Thanks. Though it really does reinforce /prog/'s view of the project.
Name:
Anonymous2016-01-13 14:54
>>284 Care to explain why? It convinced me that coreutils/busybox/toybox aren't good enough and why sbase is needed, especially when it comes to international users that have special characters in their mother-language, like ö ü é for example. Didn't you like the talk? Why not?
Only supporting UTF-8 means their 8-bit text files will not be readable. It also means you can't use grep on binary files anymore. The meaning of Unix streams is ambiguous between bytes and text, with binaries often flowing through pipes.
But in general, there's just this sense of "I don't understand why they made these features, so they're wrong", "My preference is like this, so I will present it as the one correct way", "I need a bignum library so I'm going to roll my own even though there are great, mature, focused libs out there for it already", etc. It all smells of hubris, and there's little good reason for it to be such an isolated NIH project.
>>290 You must be new here. Often people use the quote function to paraphrase, rather than to quote directly. I hope that this newfound knowledge will save you the trouble of going around asking everyone who they're quoting. I'm sure you'll fit in much better now that you understand the culture here a bit more. If there are any other things you don't understand about textboard culture, feel free to ask!
Name:
Anonymous2016-01-14 22:22
>>287 You shouldn't be using grep on binary files in the first place. The proper solution is to write a program to read the binary file and spit out a text file or otherwise modify the program that emits the binary file to emit an associated text file.
>>295 Be descriptive, not prescriptive! There's no cause for you to make value judgements about other people using the quote feature in a way different from how you're expecting. It doesn't hurt you and I'm sure you'll pick up quite quickly when people are using it as a direct quote and when they are (sometimes humorously) paraphrasing after you've been here a while.
>>297 People should form new syntax to note different things. Quotes are for quoting. Hashtags are for tagging. Maybe if you want to paraphrase, you can use the non-quote syntax <
>>64 ed, getconf, install, od and pathchk are implemented. The missing tools.
at awk bc diff patch stty
Name:
Anonymous2016-02-15 14:23
>>303 don't forget dc. UNIX without dc is just not that good.
Name:
Anonymous2016-02-15 14:37
I can't believe they are rolling their own ``lightweight'' (read: incomplete and untested) bignum lib instead of using libtommath, which is simple enough (considering what a bignum lib entails). Suckless just makes no sense sometimes.
They use webkit on their web-browser, but can't use libtommath for their dc/bc because it isn't ``lightweight'' enough? Get your shit together and stop the NIH syndrome.
>>313 You are angry at a man who admits that his design is not intended for perfection?
Name:
Anonymous2016-02-18 0:50
>>314 It has nothing to do with perfection. It has to do with usefulness, especially as he's releasing code under the hubris that his philosophy is better than the others. There's zero point to him writing shit like this, and less than zero point to him claiming that the way he does things is better.
