>GNU ls: 5685 lines (4885 sloc) 167 KB

>OpenBSD ls: 619 lines (569 sloc) 15.3 KB



Everything in Linux is 10x as bloated.

GNU/Linux, excuse me.

>>92919022 (OP)

>Everything in Linux is 10x as bloated.

GNU/Linux is 10x more useful

>>92919022 (OP)

Well more code usually indicates better performance, or at least more functionality.

>>92919022 (OP)

You can write ls in 500 lines, but it won't be as useful or as performant in corner cases that are included in a program with 10x the loc.

I don't know what's the point of this thread.

security critical stuff like SSL library ought to show bsd's model, limiting features and size helps a lot

>>92919022 (OP)

>GNU ls: sorts files using Unicode collation algorithms

>OpenBSD: sorts files using bytes like in 60s

say what you want, but at least ls works on Linux:

$ ls

A  Á  Æ  B  D  Ð  E  É  F  G  H  I  Í  J  K  L  M  N  O  Ó  Ö  P  R  S  T  U  Ú  V  X  Y  Ý  Þ



can you say the same about *BSD?

>more code usually indicates better performance

>usually

Wew.

>no emoji allowed in the terminal? what?

It escapes the characters though. That's the proper thing to do, they fully intend to add more unicode forever you know.

>>92919022 (OP)

cuck license

anon i

Can it sort files by name or not? And what do emojis have to do with this?

>performant



Yes of course LOL. It's the default of course, like always.

You sure about that?

Works on my machine.



README                                   libcurses                                makefile

asm.libm                                 libdbm                                   man

cmd                                      libj                                     milligan

dk                                       libl                                     ncurses

games                                    libm                                     netfs

ipc                                      libmp                                    r70include.README

jerq                                     libnm                                    r70include.tar

lbin                                     libpicfile                               secombe

libF77                                   libplot                                  sellers

libI77                                   libsdb                                   srctotape

libc                                     libtermlib                               statement_regarding_Unix_3-7-17.pdf

libcbt                                   liby                                     sys

libcc                                    local                                    vol2



Try this set then >>92920038

I mean, it certainly should work, right? ls is such a simple tool even a 1st grade student could write it, right?

The sad state of bsdfags. You are no better than rust trannies - that PoS exo which is a rust replacement for ls has the same problem. The art of writing software that actually works has been long lost.

What a joke. Now realize that every GUI file manager is able to do that and *BSD can't

I just did it.

no you didn't

proofs here

Now do the same but instead of a single file with all the letters as its name, make each letter be its own file.

you realize I can see "" in your pic?

I'm tired of this game, I did that at the start with Æ. I'm not doing more. It's over for you.

>more code usually indicates better performance

not really. it just does when it comes to comparing GNU coreutils because they are good software

there

that's it, it's over

Sadly yes. While you'd instinctively think that "muh bloat" and shit will make caching the executable harder, its often very specific optimization that creates larger file size to reduce overhead. The classical example is loop unrolling. More instructions yet vastly improved performance.

Well obviously this isn't the case for electron shit anon.

i wish freeBSD wasnt the only bsd with any modern hardware support

really sucks
