adds hipster icons to ls command

> adds hipster icons to ls command
> pulls in a full copy of GNU coretuils as a dependency
> 308 MB
> for fucking file icons
> in fucking ls
I deserved this.
Any good examples of lightweight, functional, aesthetic FOSS, Jow Forums? I need a palette cleanse.

Attached: freeasinfeels.jpg (800x600, 45K)

Other urls found in this thread:

git.suckless.org/sbase/file/ls.c.html
github.com/coreutils/coreutils/blob/master/src/ls.c
lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
softwareengineering.stackexchange.com/questions/103807/what-is-negative-code/103817
reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/?st=j3v3iw3c&sh=5651ea3c
reddit.com/r/programming/comments/6gxf02/how_is_gnus_yes_so_fast_xpost_runix/
news.ycombinator.com/item?id=14542938
github.com/search?&q=shell scripts
openbsd.org/innovations.html
openbsd.org/events.html
twitter.com/NSFWRedditVideo

Install OpenBSD

What the hell are you talking about?

>chaos undivided
>GNU/Linux

Is this the link we've been missing all along? Different distros are like different chaos gods

>Suckless sbase ls.c: 489L
>GNU coreutils ls.c: 5310L
>Both can list files in detail
git.suckless.org/sbase/file/ls.c.html
github.com/coreutils/coreutils/blob/master/src/ls.c

My terminal, st with some patchs applied, has ~500L less than GNU ls, has true color, and a nice and aesthetic colorscheme (gruvbox).
You literally can read the entire source of sbase in 2-3 days.
Do the same with the GNU counterparts, it would take a entire year.
So, switch to sbase, or better

>nothing is more important than how many LoC a program has

You are saying that, not me.
I'm just pointing two C programs that can do the same, and one has 489L and the other 5310L.

>You are saying that

>thing A has x lines
>thing B has y linux
>so, switch to y
you used line count alone as an argument to use one over the other, now while you didn't say "nothing is more important", like suggested, you certainly are saying that line count is important

>I'm just pointing two C programs that can do the same
Same core functionality =/= do the same
GNU counterparts usually offer additional options and fewer arbitrary limits (not to speak of any speed advantages).

> implying sloc has anything to do with anything

lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html

I am saying that it is relevant, not crucial, not a priority. Certainly, find a bug can be easier on a very small code base than a very large one. Also, it matters if it is necessary to refactor/rewrite big chunks of code

>my program is 10x bigger because it's optimized
Lmao

softwareengineering.stackexchange.com/questions/103807/what-is-negative-code/103817
I don't disagree entirely with you. But bloat exists, that is undeniable, and with the years as become a problem that affects all levels of development, from the kernel to the web.
There must be a certain limit, a certain tolerance on how much a piece/suite of software should grow to avoid turning it into an unmanageable mess.

That's generally how it works, yes. If your program is very short it's because you took shortcuts, there's 0% chance that it works fast.

Having already pipes (this thing >>> |

Attached: longcat.png (1126x10000, 1.45M)

Less talk and show me your benchmarks.

You mean there must be some marketable size restraint for linux as a product???
But.. that's like dividing by 0.

True, but there must be a middle ground between modern web level bloat and absolute minimalism. Convenience and additional functionality aren't inherently bad. Nor is the wish to minimize bloat.

Why would I care about LoC? I care about 2 things: performance and memory usage. If bugs appear, the maintainers will fix them. If there are no maintainers, someone from the open source community will stand up for it and study the codebase.
What a bleak future where we create and use dumbed down, naively programmed software out of pure laziness. GNU applets regularly outperform plan9 and bsd btw.

Pipes don't optimize your program's performance or handle edge cases.

Pipes? are you insane? By the time I write down what I want to happen and double check my arguments are correctly lined up, the slowest, most bloated app would have finished.

> But.. that's like dividing by 0.
Like blindly trust on a 50M sloc atack surface that came out in recent news whit some serious vulnerabilities that some famous developer refuse to fix for so many years.

...

So gather some lads and fix it. If every competent open source user sat down to audit every weekend, this would be solved. Fucking freeloaders.
Just a quick small example. reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/?st=j3v3iw3c&sh=5651ea3c

Maybe computers aren't for you grandma.
Oh God! Too much complexity! I demand everything chewed by others so I don't have to use my jaw anymore buh huh!

You're the one stuck in the past. If you hate automation, you're a shit programmer and your philosophy on computers is outdated.

>Oh God! Too much complexity!
I thought stringing together simple tools with pipes is supposed to prevent unnecessary complexity?

>caring about 300MB
god shut the fuck up about suckshit already. Gnu coreutils are the best coreutils implemented, maybe only losing to eshell utils. They are the best performing and have the most features, there is no reason to use it unless you just autistically hate gnu or run a machine with 200kb of storage. Lines of code IS NOT A MEASURE FOR SHIT. More lines can mean many things:
> more hardware usage optimization
> more features and functionality
> bad implementation of features in too many lines
> an attempt to make readable code with comments, good spacing and stuff that makes sense

Maintaining code is way more on the documentation and readability than in LOC. Sometimes the attempt at having less LOC lead to shitty unreadable code that nobody understands.
If you just wanna get few lines of code, you will autistically sacrifice functionality arbitrarily based on what you use, instead of trying to fill general use cases.
You miss on doing stuff like multicore usage and good management of performance.
Every suckshit software sucks. Only a few like dmenu are decent, and i still like rofi more.
i want all of you unixtards to commit retroactive self abortion and let that shit suckless philosophy die already.

Oh, look!, GNU yes isn't that special snowflake, so sad.
reddit.com/r/programming/comments/6gxf02/how_is_gnus_yes_so_fast_xpost_runix/
news.ycombinator.com/item?id=14542938

Attached: 1561377906687.jpg (720x1181, 438K)

> What is shell scripting?.

Not an argument. Current readily available alternatives lose to GNU, which is what you wanted verified. qed

for fucks sake i hate you. programming is about automating and abstracting low level shit so you stop caring about the basics and make greater things. You fucking roadkill fetus will never do anything good if you keep trying to reinvent the wheel instead of making a car.

Text streams are a universal interface, isn't too complex.

Fuck off I am not sitting around finishing someone else's program. Ship a working product or fuck off. Shell scripting is for edge cases.
>will never
Dude these guys fetishize other people's bare-bones code, and still can't produce 1/10th of it themselves.

there is no reason not to use it*

Why so offended?, where

sheer hatred for shit ideas.

>Ship a working product or fuck off.
GUIs are your thing.
Stay away from the command line, you can hurt yourself! Or worst, someone else...

I use GUIs and command lines but only with quality products - not something amateurs scribbled up. You want to be your computer's personal worker, go ahead.

Oh yes, reimplement what has already been implemented 1000 times. Focus on that, use your limited time on that.

> Implying that those "quality products" weren't written by amateurs

Evidently they know what they're doing because an app called "Program that does X" really does X.

The GNU project is mostly composed by highly educated academics, then there are voluntaries. The most active are paid too

You don't have to
github.com/search?&q=shell scripts

At last I truly see.
Windows is the Imperium, old, inefficient, yet gets the work done. LTBS is the Astartes.
Apple are the *ldar: faggots. Hackingtosh the dark*ldar: pointless and faggots.

All I'm saying is that marketing and scoping out the design of a thing as a product is how humans create new useful tools and disperse their usage into the population.
You don't even need cash to do this really.

You are praising the Unix philosophy!?? "Do one thing and do it well"?

> Programmers knows what they're doing
Never heard before.

Yep. If I want to see the contents of a folder, I use ls.
If I want a browser with addon support, tabs, hardware acceleration, huge options menu, and more, I use chromium or firefox, not surf.

Every existing OS have some group of highly educated academics behind, not only GNU.
openbsd.org/innovations.html
openbsd.org/events.html
I just put OpenBSD as an example, I'm not shilling about it.

I'm with you In that one, suckless browsers are a lost battle.
I'll still continuing using other suckless tools, because I'm used to, like you.

didn't say otherwise

well this thread is a total shitshow.

Keep in mind that size does not corelate with performance; if that extra code is context specific optimisations then that's good, if it's a bunch of unneeded features then that will slow down the program.

Core utils are probably the last things that you'd have any reason to poke around the source for, so readability doesn't really matter, but performance matters a lot since most of your applications rely on them.
If GNU coreutils really are faster than good for them, but I know they also add a lot of useless bloat which really go against the UNIX philosophy

> go against the UNIX philosophy
and that's a great thing