[ / / / / / / / / / / / / / ] [ dir / fa / girltalk / gunt / lisperer / roze / tingles / v8 / xivlg ]

/tech/ - Technology

Winner of the 68rd Attention-Hungry Games
/d/ - Home of Headswap and Detachable Girl Threads

January 2019 - 8chan Transparency Report
Email
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Flag
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 3 per post.


File: 97e1ea6579621ed⋯.png (141 B, 225x150, 3:2, logo.png)

File: e1bcb8327e98f55⋯.jpg (76.04 KB, 766x772, 383:386, the_worst_javascript.jpg)

 No.969082

There is a big problem with a lot of free software nowadays, and that's bloat. There's a really good article put out by the suckless community on this issue (https://suckless.org/philosophy). This page does good at describing the practical problems of bloated software, but I want to talk about the ethical issues surrounding "bloatware".

Now, technically, all bloatware put under a free licence is free software. But that doesn't mean that you can edit it, at least not easily. Freedom 1 of the Four Essential Freedoms states that the user has the freedom to "study how the program works." How the hell can you study the program if it's all jumbled up? This produces the same problem that proprietary blobs do: a gateway from studying how the program works. It may be easier than machine program to read, but given enough lines, the program becomes virtually unreadable.

What are some examples of this?

> chromium, firefox, most GUI web browsers

> bloated window managers

> anything GNU touches

> the big elephant in the room that came from Red Hat

> the Linux kernel (there's no way one program needs 4.8 million lines)

Now, how can we solve this? Start by using simple software. Don't use urxvt, use st. Don't use i3, use dwm. Now that's not to shill the suckless community. But they're really the only ones pushing on this issue, even though they only come at it from a practical perspective. Start by rolling up your sleeves and learning how to patch these programs so they do the things you want them to do.

Another good idea is to build a LFS build using only simple programs. Rather than the GNU utilities, use some of the BSD utilities, or Plan 9. Ideally this should be available in a distro, but that probably won't happen for a while. If anyone wants to work on this with me over the long term, let me know in this thread.

Pic not related, but it is awful programming.

 No.969088

>>969082

>the Linux kernel (there's no way one program needs 4.8 million lines)

It does. You have to thank diversity (in hardware) for that.


 No.969096

Nothing screams "virgin" more than a tech autist masturbating over how sui generis he is for using minimal software. Let's not forget: the C programming language is an extremely unsafe, hacky language in which everything is a member pointer. It has no array bounds checking, you can return pointers to temporary stack memory, and the language is so bad that compilers for the language will remove integer overflow and underflow checks because those checks use undefined behavior, you can use variables which are uninitialized and thus contain junk memory.


 No.969097

>>969082

>There's a really good article put out by the suckless community

dohoho post discarded.


 No.969099

>>969096

>Let's not forget: the C programming language is an extremely unsafe, hacky language

Let's also not forget your post went through several hundred million lines of C to reach me and it went quite well, while webdevs like in the OP have trouble writing 100 lines of code without creating a disaster.


 No.969100

>>969082

>suckless

More like featureless. Gotta love recompiling all my shit just to slightly customize it.

>LFS

>Plan 9

So, you have no idea what you're talking about.

GNU software is bloated because when it was developed the quality wasn't the goal, the goal was to provide a free alternatives to proprietary tools. If instead of bitching and making more "alternatives" people would just contribute to GNU we wouldn't have such a problem.

And in case of Linux, you're looking at the problem from top. OpenBSD might be more minimal but it doesn't support nearly as much hardware as Linux does. Before "fixing" the software consider "fixing" the hardware first.


 No.969101

do not take >>>/tech/969096 's bait


 No.969102

>>969088

Then you just patch the kernel so it supports your hardware. Ideally companies should provide the patches themselves, but community patches are cool too.

>>969100

>Gotta love recompiling all my shit just to slightly customize it

Patching st takes absolutely no time at all. It's just as easy as making changes to your vimrc file. I don't know a lick of C, and yet I am able to run patch and make. Fuck right off.

>>969096

this gives me a smug anime face


 No.969103

>>969099

Argumentum ad populum. Ada has advanced support for type checking, you can create types with specific ranges (e.g. an integer with values from 0 to 12), you can write modules, exceptions (in other languages the system gives you an error code you can't just ignore or the software will crash), 'generics' which means you can write a data structure (like lists) which will work on different kinds of data, like integers, floating point numbers, and strings. So, by writing just one function for all data types instead of writing functions for all data types specifically, the language has run-time checking and so many other features.

The kicker of Ada is that it's a higher level language than C and about a million times safer. The GCC compiler framework generates the fastest code for C, but GCC also supports Ada and the code generated for Ada is nearly as fast as the code for C. It also supports every architecture/platform that is supported by GCC.

You'd think, why do programmers hate Ada? C programmers in the 80's would use so many bullshit excuses like that the compilers for the language were expensive, or the language is too complicated (it's much simpler than C in day to day usage). The real reason is because they're just too lazy to learn Ada.

The reason for 'bloat' is because C makes it difficult to write good, maintainable, secure code. To you morons everything that isn't C is "bondage-and-discipline". Imagine the horror of using 1950's programming language features and practices.

>and it went quite well, while webdevs like in the OP have trouble writing 100 lines of code without creating a disaster.

C/UNIX idiots have a hard time writing curl/wget (pure C) without a thousand vulnerabilities (which they have an attitude about, and refuse to fix).


 No.969104

>>969099

What sort of argument is that?

If his kernel had keep written in Ada, it would've been serveral hundred million lines of Ada. Or Rust. Or Erlang, or Elixir, or Lisp, or Java, or whatever. You're making an inane argument that C is better because it's more popular - that's not even an argument. Maybe it's worse, because it's so easy to learn even retards are using it.


 No.969119

>>969100

>instead of bitching and making more "alternatives" people would just contribute to Windows we wouldn't have such a problem


 No.969120

File: 67433818f4109e6⋯.jpg (148.26 KB, 640x479, 640:479, DgzSF_0XUAE3Zsb.jpg)

>>969082

>hurr durr your software has too many features so that makes it proprietary


 No.969121

Bloat is not a problem for free software. It's your own problem if you refuse to maintain your own free software that has the bloat trimmed away.


 No.969125

>>969121

The user can't predict when a project gets to such a state. All he can do is leave the project when it does happen, or try and improve it.


 No.969126

>>969121

>>969125

Also why should the users fix the program, rather than have the program not be bloated/broken in the first place?


 No.969128

>still not using openbsd

this will never ever get fixed on linux


 No.969129

suckless is a bunch of nazis, they literally did a tiki torch march only a month after the charlottesville murder


 No.969132

>>969096

array bound checking slows down the program defintly with high array orientated workloads. also it is not really needed unless you are a nigger monkey and cant design a way to put it in yourself for arrays in the program that will have the problem.


 No.969140

>>969129

If that's meant to be dissuasive, you're on the wrong board kiddo.


 No.969141

>>969082

Is there really that much that can be achieved from making software understandable, when for the past 40 years the hardware it's running on is a proprietary black box?


 No.969144

>>969082

>it's not free software unless the code is nice and pretty like the way I want it

I can't


 No.969145

>array bound checking

Who the fuck other than retards need this? Do your damn math before you write code.

<b-but I just wanna write code, not think!

And that's why software in general is so shit today, you outsource all that thinking to the runtime environment, so your software ends up bloated and inefficient because the runtime environment has to correct for how fucking retarded you are.


 No.969147

It's not an easy problem to solve, but avoiding Linux and GNU/Aids is a huge step in the right direction. Despite being maligned for its "cuck" licensing, BSDs are far more community driven than Linux, which is basically another arm of the military industrial complex at this point.


 No.969156

>>969132

>array bound checking slows down the program defintly with high array orientated workloads.

If you write your code reasonably well you can minimize this. Loops that iterate over a whole array don't have any more checks than a c program.


 No.969160

>>969156

>having to work around your programming language because of a useless feature made for people who cant do math

bounds checking fags are weak


 No.969163

>>969160

>I love remote code execution vulnerabilities caused by append 2 strings together

look faggot your computer can deal with a few extra MB of RAM usage and a few extra clock cycles for bounds checking. It's not 1987 any more.


 No.969164

>>969163

Exactly that's why modern software is so fast.


 No.969166

>>969163

do you happen to be indian


 No.969167

File: dfb3158079aac51⋯.jpg (32.03 KB, 600x450, 4:3, dfb3158079aac511dfb594ea08….jpg)

>>969166

Enjoy your buffer overflows larper.


 No.969170

>>969167

you know you can implement your own bounds checking when debugging and for certain applications where you could get an over flow. its really not that hard. you dont need a compiler to hold your hand.


 No.969171

>>969170

Yeah you can also implement your own exceptions, core data types, socket api. But we don't because that's fucking retarded.

Thank god you can just run ASan these days and catch most things.


 No.969176

>Calibre

Perhaps the epitome of open sores bloat. Ignoring its abundance of technical flaws, it's a good example of a nonfree interaction paradigm, because it hits that sweet spot where it's valuable enough that it changes the way people perceive the problem it solves and thus necessitates its use for many–but too blobby and ambiguous in structure for any real competing software to crop up. And it's borderline violating the GPL, because you can't fucking compile it unless you use his own homebrew of qt hacks.

>Hydrus

Intentionally obscure commentary, buggy, broad stack for no good reason, not packaged for pip, and distributed under the broken wtfpl license (e.g. might as well be copyright). Equally as brilliant as Calibre, horribly done. You can't blame him, though; he probably doesn't know better. Even a layman can see he's inexperienced, and he's part of that weird niche of Windows users who also write mostly free software. Hydrus is a technically-flawed piece of software, but it's really valiant in thought.


 No.969183

>>969082

Without a good up front definition, "bloat" is a buzzword.

It doesn't help when you use shit logic such as

>But that doesn't mean that you can edit it, at least not easily.

to devolve into "no true free software" retardation.

Also claiming no program ever needs 5M LoC is insanity.


 No.969188

File: 0b1f3d69438eb9b⋯.png (62.93 KB, 627x533, 627:533, lin-usage.png)

>>969082

>i3 is bloat because it has 16 KLOC

Maybe you're just shit at reading code?

>there's no way one program needs 4.8 million lines

Pic related is a breakdown of the linux source by disk usage. hint: drivers are hard, so is supporting ten different arches


 No.969209

>dwm

bspwm is better


 No.969219

>>969209

Every time someone says this they have no idea how to use dwm and use it like some retarded tiling wm.


 No.969222

>>969088

It's less about the diversity in hardware and more because we no longer directly program it.

Operating systems are bloated today primarily because of the driver model and hardware not being directly programmed.


 No.969226

>>969222

>and hardware not being directly programmed.

Yes because what we all need is for every program to manually implement the driver every fucking time. That will really save us headache i'm sure.


 No.969229

>>969209

>>969219

never used bspwm but why is it better than dwm, in your gay opinion? i3 is nice as well but nothing beats dwm in terms of functionality, speed and minimal mental overhead. yes it's a fuck to tweak and re-compile, but this has an added benefit that once you've got a config to your liking, you are less likely to fuck with it every 10 minutes like some bored housewife.


 No.969233

>>969226

>manually implement the driver every fucking time

You've read my words but I don't think you understand what I'm saying.

How about just reading from and writing to some memory? That's exactly how it was done before(look at almost any 1980's computer) and it worked quite well.

The AMD Radeon R9 290X saw a 50% performance increase when they removed part of the Radeon driver and used Mantle to interact directly with the GPU. You can get rid of the driver bloat and increase performance; there just has to be enough interest to stop wasting resources on fancy unnecessary abstractions.


 No.969247

>wants programs with no bloat

>writes them in C

lmao, unicucks strike again


 No.969250

>>969222

>Operating systems are bloated today primarily because of the driver model and hardware not being directly programmed.

No. Linux is bloated cuz don't have a proper interface and driver architecture so they just put the code for each driver in the same repo.


 No.969272

I'm not going to dumb down my code just because a brainlet doesn't understand it.

>>969145

Your argument is flawed. With bounds checking you still need to make sure you are within the bounds yourself, else your program will be terminated. If you think C is better by having a more dangerous side effect if you get it wrong then you are being silly. Thinking you elite by using at inferior tool makes to sense. It's like thinking that using a rock is better to nail nails because it is harder to do.

<This makes people not think as much

No, I'm able to think more about what actually matters that trivial things.


 No.969275

The suckless crowd is a bunch of sperglords. Yeah, thanks for dmenu, but everything else you make sucks LOL dick.

Oh, by the way, how's that Static Linux project going? :^)))))


 No.969285

>>969275

I will say, as a die-hard Emacs user, I love almost everything suckless does to death, especially surf. There are a lot of idiots out there who think adhering to "true Unix" tradition means a bunch of shitty ncurses interfaces, but suckless is one of the few groups that really understands the appeal of Unix tools, because they're not shitty ncurses interfaces, and they're not even shitty, interactive CLI interfaces; Unix tools are one-dimensional. They're singular in there application, with no superlatives or quality-of-life features, and a pleasant side-affect of that is that they're light and pipe-able. Emacs works best as a frontend for software like that. Surf is somewhat neutered, so it depends on dmenu to sort of carry things from point "A" to point "B", something that what otherwise be poorly-implemented by the browser itself, like issuing search search queries and searching for arbitrary text, but the funny thing is, Emacs does precisely that, except better. I can interact with Surf via Emacs in precisely the same way dmenu is used to interact with Surf, and that simply wouldn't be possible if it weren't for suckless' paradoxically humble elitism. Emacs loves simple applications, because it's easy to take something intentionally shallow and effectively create your own toolkit with Elisp. Whereas traditionally, you would rely on a normal window manager to handle all your surf sessions, you can handle all your surf sessions with a number of Emacs interaction paradigms, you can sort them by name, by window element, by buffer type and manipulate multiple buffers at once–all with fuzzy search, because Emacs is a window manager, too, with EXWM, and whereas modern DE's struggle to even talk to other components even within itself, consummate integration is a necessary prerequisite of Emacs.


 No.969286

>>969272

Only tards not knowing the price of a branch on most µarchs will promote bound checking. Now, bound checking for debug builds is sensible.


 No.969289

>>969219

>>969229

Because, unlike dwm, keybinding is left to a separate application, talking with an appropriate RPC client to bspwm itself, as it should be. Its config file isn't parsed, too, it's just a shell script, since everything (including configuration) is configured with the RPC client (bscpc).


 No.969290

>>969275

Come on, there's st too.

>>969289

Also, there's no builtin status bar. I should also add that it uses XCB, instead of Xlib.


 No.969306

>>969082

That problem is caused by C. Doing anything in C needs a lot of code. Code is duplicated many times and everyone has to reinvent wheels instead of doing it once and sharing the code. Better languages can do more with less code.

> the Linux kernel (there's no way one program needs 4.8 million lines)

It's over 16 million now.

>>969096

Those checks could be done in hardware at almost the same speed as not doing them. Lisp machines can check array bounds in parallel.

>>969099

>Let's also not forget your post went through several hundred million lines of C

That means C really sucks if it needs that much code to send and process a few hundred bytes of text. Lisp machines, Xerox computers, mainframes, and so on could do a lot more with a lot less code. Checking for overflows in assembly is one extra instruction or part of the same instruction if it traps. In C, it's complicated bullshit code that has to be repeated over and over again and can't be optimized for the hardware you're using. The PDP-11 had an overflow flag, so you can't blame hardware for this mistake.

>>969126

>Also why should the users fix the program, rather than have the program not be bloated/broken in the first place?

That's a "feature" of all UNIX software. AT&T's proprietary UNIX had the same problems and the same mentality of blaming the user for all of them.

>>969272

>Thinking you elite by using at inferior tool makes to sense. It's like thinking that using a rock is better to nail nails because it is harder to do.

A lot of people are puzzled by this, but it only makes sense to me if there was heavy shilling involved.

>Also, only in the land of software would anyone actually suggest that one should not use a better tool, technique, process, whatever to build your product, because most of your _competition_ is using the inferior tool, technique, process, whatever.

>Jon S Anthony (jsa @ alexandria.organon.com) 1997/06/05

My reply to a discussion on another list concerning shell
output redirection:

>> What's going on is that you're overflowing the *shell's*
>> output buffer. When you do <prog> > <file> you're asking
>> the shell to capture all the output from <prog> and when
>> it's done, stuff that into <file>. As you've noticed,
>> there's not much of a buffer there and when you've filled
>> it up it goes kablooie.

...producing no error message or useful diagnostic, of
course. Such wasteful civilities are obviously far beyond
the ``small is beautiful'' design philosophy of which Weenix
Unies are so fond. And you weren't actually expecting the
shell to be designed to buffer its output correctly without
segfaulting, were you? As a user, keeping system programs
from wetting their pants is, after all, YOUR responsibility.


 No.969308

>>969306

>points inevitable cost of bloated handholding

>h-hardware will solve it!

Like a clockwork.


 No.969313

File: 590c92e6696b1c5⋯.png (326.47 KB, 895x429, 895:429, FuckBSD.png)

>>969082

>Don't use urxvt, use st

St cannot be daemonized, making it considerably heavier than urxvt when used in a tiling window manager setup.

>Don't use i3, use dwm.

Don't use either. X11 is bloated. Use Sway.

>>969088

Pretty much this. People are like, "muh plan 9 tiny kernel", but they forget that Plan 9 has shit-tier hardware support, and if Plan 9 ever did get Linux's hardware support, it may or may not be 4.8 million lines, but it most certainly would be astronomically larger than it currently is, and would be far bigger than any suckless shill would allow.

>>969147

>BSDs are far more community driven than Linux, which is basically another arm of the military industrial complex at this point.

HAHAHAHAHA

pic related. BSDfags actually treat their commercial bullshit as a SELLING POINT

>>969233

>The AMD Radeon R9 290X saw a 50% performance increase when they removed part of the Radeon driver and used Mantle to interact directly with the GPU.

And it's still way slower than what NVIDIA puts out. If you were trying to make a point here, you failed

For real though, if you guys really want better and more /minimal/ software, you should look to microkernels.


 No.969330

>>969082

>inefficient login method but doesn't matter because only 1500 users

>pointless "true"==="true", perhaps to get around some retard nigger linting tool or something similar, or maybe there's some metashit happening here that I don't know about

>setting cookie "loggedin" to "yes" lets you into the site? or is that $.cookie also setting up a session or something?

>still sending actual strings to the database in 1990+28

>typing out "account" to name a variable that's only used on the 2 lines below

>has to type an extra = because the PL is shit

>if (x===true) else if (x===false)

what am I supposed to be concluding from this shitcode? it's completely typical and has been for 30 years. the audience of codinghorror would only notice the first 2 points and some of the other minor syntax issues

>Don't use urxvt, use st.

I've been using mrxvt recently, is that bloated? Going from several other dog shit terminal emulators, the last I used was xfce4-terminal, which has unberable input lag and a bug where random strings of text become invisible while browsing man pages, and now I use mrxvt because it's decently fast (i.e actually opens within the first year of me hitting the hotkey to open it). However I don't think it supports unicode which has become impractical for me regardless of how shit unicode is

>>969096

so give me a minimal memory-safe PL, like LISP (but not actually LISP lol)


 No.969331

>>969313

>St cannot be daemonized, making it considerably heavier than urxvt when used in a tiling window manager setup.

Not the op, but doesn't st being way smaller than urxvt make this void 99% of the time? In any case, there are few situations where you're worried about the mem usage of the terminal, as opposed to, say, the browser. startup time does matter tho


 No.969332

>>969286

only tards not knowing the cost of lack of memory-safety will promote writing the entire kernelspace+userspace in an unsafe language


 No.969338

>>969330

GNU Guile?


 No.969340

>>969330

Pascal. Not even joking.


 No.969348

>>969313

yeah except when the daemon crashes and you get fucked in the ass, st all the way my nigger


 No.969352

>>969313

>>And it's still way slower than what NVIDIA puts out. If you were trying to make a point here, you failed

>Can only think in terms of consumer performance metrics such as synthetic benchmarks and game framerates

>Sees a brand name and has to display brand name loyalty instead of understanding the actual point being made

Your reading comprehension has failed you.

If AMD can get increased performance by partially getting the driver out of the way and directly programming the hardware, then NVIDIA can as well. Why? Simply put, the current driver model is a cost-heavy software abstraction that limits the total performance you can get out of a piece of hardware. All GPU manufacturers will see a performance increase from directly programming the hardware.


 No.969356

File: 48675a7b42d5fb0⋯.gif (2.12 MB, 346x244, 173:122, 6756734gklhgfdk453.gif)

>all these nomath pajeets pushing bound checking


 No.969361

>>969356

bounds checking is for pajeet XDDD

>>>/g/


 No.969365

>>969361

Real white programmers launch another process in which they iterate over the array in a goto loop until it segfaults.


 No.969368

>>969365

Maybe spanish programmers. Northern europeans unroll all their loops, no matter how many iterations, guaranteeing speed and security.


 No.969370

>>969365

>he knows about goto

>he thinks he's white


 No.969372

>>969082

That's an interesting point, but the freedom to study the source code refers to the source code as it was used by the author. For example, if the author has his code split up neatly into various files, but then uses a tool to merge them all into one file with tens of thousands of lines of code, that would not qualify as source code. On the other hand, if the author is a turboauitst who can actually keep track of one file that several tens of thousands of lines long, then there is nothing to argue.

Bloat is not an issue of political or legal freedom, it's an issue of practical freedom. No normal person is going to audit the source code of an incomprehensive mess, let alone make changes to it, even if they are allowed to. At that point you might as well re-write it from scratch.


 No.969380

>>969129

Of all the pro-suckless shilling in this thread, this is probably the only one that provides a solid supporting argument.


 No.969384

>>969372

And if the author enjoys writing binaries by hand in a hex editor, then that counts as free software as well. Come to think of it, some of the microsoft tools are edited in hex editors...

>Bloat is not an issue of political or legal freedom, it's an issue of practical freedom

If you're not already an anarchist, then why even live? The only issues that matter are practical issues. It just so happens that governments are very good at making political and legal issues into practical issues (and getting better at it).


 No.969387

>>969176

>broken wtfpl license

kys licencecuck


 No.969390

>>969286

>the price of a branch on most µarchs

Effectively zero if well-predicted? Like, one that goes one way all the time?


 No.969391

>>969390

Branches are almost free only on very modern CISC uarchs. Also, speculative execution brought us some lovely problems, these last few months.


 No.969392

>>969391

Buckle up then, since it's not going anywhere.


 No.969393

>>969370

>he repeats the forced academy goto meme

Just don't overuse it, like longjmp.


 No.969395

>>969306

>Lisp machines can check array bounds in parallel.

And superscalar machines can do useful work in parallel. Why waste silicon and power on useless checks if you can invest it in doing actual calculations instead?


 No.969400

>>969384

> The only issues that matter are practical issues.

That's not how it works. I can hand you the cleanest code in the world, if I don't give you permission to modify and redistribute it, I could sue the shit out of you for distributing a modified version. This is why practical freedom is built upon legal freedom.


 No.969403

>>969103

>C/UNIX idiots have a hard time writing curl/wget (pure C) without a thousand vulnerabilities

Just think: If a rather "small" program like curl has a ton of vulnerabilities (https://curl.haxx.se/docs/security.html), how many other (networked) C applications have egregious vulnerabilities? Next time you pedos are shitting yourselves about Spectre/Meltdown/the IME just remember that most of the C code running on your machine is insecure. (Another point I have to make: why do you losers have a pathological desire to live in paranoia? Shoved into lockers one too many times?)


 No.969404

File: 1997e798baf8f27⋯.pdf (234.58 KB, 18619746.PDF)

>>969361

yes you are a pajeet


 No.969409

>>969395

They're useful checks since without them you would get RCE vulns. I agree that there are use cases for unsafe assembly code, but anything in the chain of how you access your online bank is not one of them.

>>969400

Literally not an argument. Practical freedom existed before "legal freedom" or "legal restrictions". Also I'm pretty sure in practice some small guy like you would be unable to enforce anything about your code other than maybe a harrasment lawsuit and earn yourself $5.

>>969404

C isn't a good language in the first place. I don't want C with bounds checking. Ironically everyone here is too scared to open this PDF file literally because of C (which in fact is more prone to RCE vulns than assembly language). Even if C was memory-safe it would still be prone to causing security issues. A much better starting point is something like ML or even LISP.


 No.969412

File: 50251216b4af349⋯.gif (62.26 KB, 500x372, 125:93, 50251216b4af34995c957e582b….gif)

>OP makes a thread about minimal software

>shitters show up to screech about muh C and how their favourite languages are so great for big programs

Like clockwork. At least >>969285 made a quality post.


 No.969420

>>969409

>like ML

Yes

>or even LISP

No


 No.969421

>>969400

> I could sue the shit out of you for distributing a modified version

> It just so happens that governments are very good at making political and legal issues into practical issues

What if I host it on behind tor? What if I'm some small fry torrent seeder not worth pursuing? What if I obfuscate the bins so you can't prove I copied from you? etc. Even though these aren't legal protections from copyright, they are practical protections, that various anons use every day. Doing something just because the government tells you to is the definition of cuckoldery.


 No.969430

Code artisanship and language wars are retarded. Waste of time when so much software is totally outdated and uninteresting.

Luckily academia is on top of things and is getting people to reconsider actual design instead of fagging around writing fib sequences in new innovative ways.


 No.969432

>>969421

Yeah respecting free software licenses is retarded. You should just ignore the GPL and do whatever the fuck you want with it.


 No.969433

>>969430

Academia is perennially masturbating over the new in vogue functional language (that essentially clones the functionality of an older functional language, while adding maybe ten unique features). At least they still use FORTRAN in places.


 No.969435

>>969313

>Pretty much this. People are like, "muh plan 9 tiny kernel", but they forget that Plan 9 has shit-tier hardware support, and if Plan 9 ever did get Linux's hardware support, it may or may not be 4.8 million lines, but it most certainly would be astronomically larger than it currently is, and would be far bigger than any suckless shill would allow.

This is why you have different versions of the kernel on a per-uarch basis. This isn't as complex as you would make it out to be, either. You'd just have a modular microkernel that gets compiled into certain configurations.


 No.969441

File: 4287f26971f5e33⋯.jpg (60.11 KB, 982x552, 491:276, unhackable-kernel-sel4.jpg)

>>969435

>You'd just have a microkernel

well at least we can agree on that one

https://sel4.systems/

https://genode.org/


 No.969443

>>969441

Daily reminder that despite all the math shit that went inte seL4 it's still vulnerable to spectre and meltdown without any mitigation.


 No.969457

>>969443

>they had a modelling problem

>CHECKMATE MATHFAGS XDDDDDDDDDDDDDDDD

>>969412

>someone doesn't suck the C

<why do I come to this board

<pajeet

<XDDDDD

like clockwork


 No.969458

>>969432

What faggot has seen that their car uses GPLed software, and called them up to ask for the source? It's just a mildly annoying burden on them, and confers no benefit to you. Stallman's been jacking off to the distinction between free and open source software for 20 years, but I still have yet to hear of a situation where this has conferred any benefit to end users. The practical difference is that it fucks over large corporations, which I am all for, but why should I bother respecting this distinction?


 No.969459

>>969457

>>they had a modelling problem

Yes indeed checkmate math fags.

>hurr durr its proven correct goy!


 No.969467

>>969459

fuck off nigger i'm not defending sel4 i'm defending formal proofs


 No.969468

>>969458

nobody looks at the code in their cars because it's hopeless. use feet or ride bike instead. why would you entrust your life to KLOCS-MLOCS of code made by an industry that never once had any oversight (aside from uConnect, which indeed proved ECU code to be a disaster). expect code worse than what you get in routers, smart TVs, and other "embedded" software


 No.969491

>>969467

Well then bud instead of claiming things are "proven correct" how about you say "proven to match a specification that is likely wrong".


 No.969534

>>969458

Your confusion is that you believe that users need to be computer experts with good programming skills. This is a false assumption, it is wrong to conflate freedom with technical aptitude. Users (who have freedom) who need technical help need to go ask a skilled helper to help them. The skilled helper will request the source code from the user and the user will request the source code from the distributor to give a copy to the skilled helper.

Open source exists to promote an open software development method. In this philosophy, freedom is not the purpose, the purpose is about producing the highest quality software through the open source method. The free software philosophy and open source philosophy is not the same ideal, do not conflate the two as you can have one without the other. It is also possible to have both philosophies working on the same project.


 No.969539

>>969458

See how the Linksys router firmware was forced to be shared. Or see how "open source" allows faggots like Sony to just take FreeBSD and make their locked down computer called a console or Apple to avoid working for their turd of an OS.


 No.969630

>>969491

fuck off nigger i'm not defending sel4 i'm defending formal proofs


 No.969661

>>969534

Open source software is free software, except it grants one additional freedom, to disribute the software without providing source. As an end user, you have no reason to prefer free software over open source software. As a company who plans on selling the result, you will prefer OSS. The goal of free software, I say, is to screw over these latter companies, a job it does admirally. The goal is not to get companies to hand out their software for free, as the GPL requires them*, because no company would be stupid enough to fall for that. They will either use the free software in some way that doesn't make the rest of their code "derivative", or make/license a proprietary version of the software, even at great expense.

*fite me stallfags

>>969539

>router firmware was forced to be shared

Oh yay, you have the source for the firmware of a shitty router. No doubt you've already patched it a ton, and shared it with all your friends.

>sony made an operating system for slightly cheaper

They weren't gonna release the source anyways, they would've picked some proprietary os instead if bsd wasn't around. That would've made the resulting product shittier and more expensive, so score 1 for open sores?


 No.969839

>>969661

You believe that the purpose of free software is to screw over companies; this is wrong. The purpose of free software is to promote freedom for the users. The GPL works by preventing people to redistribute the GPL software as proprietary software, the only people this disturbs are the people (companies or individuals) who distribute proprietary software. You are confused to think that people cannot earn a profit selling free software; earning a profit does not conflict with the ideals of free software. The idea that conflicts with free software is the distribution of proprietary software in any form whether a profit is made or a loss is made.


 No.969981

>pretending we can have non-bloated systems with the traditional unix / x paradigm

The lispfag is right, also we could have had Smalltalk too. Running those on the bare metal would be easy these days and the systems are so much smaller, more flexible, and easily understood / modified.


 No.970012

>>969981

It's all talk and no action. You guys have it good these days because you have access to affordable and super fast computing machines. Yet, people who complain about this spend none of their own time implementing such systems that will not take the amount of time it would take to write TempleOS. I suppose I could note the suckless team who do indeed walk the walk instead of only talking about should be done.


 No.970385

>>969839

>You are confused to think that people cannot earn a profit selling free software; earning a profit does not conflict with the ideals of free software

There is no "selling free software". You beg for donations, and some people will give them to you. In the old days, when software was distributed on tapes, you could sell the media. Nowadays, you can't hope to sell the download for more than a couple pennies, and even then github would undercut you.

>the only people this disturbs are the people (companies or individuals) who distribute proprietary software

Exactly. gpl screws over proprietary software distributors, mit doesn't. that is the one and only difference.


 No.970387

>>970385

i thought summer ended already


 No.970390

>>970387

>all these (you)s

I'm in heaven


 No.970440

>>970012

What's needed is a bare metal platform which doesn't constantly change. The rPi would be a good option, with a stable hardware configuration.

Intel's right out, there are a million peripherals to support and they revise everything all the time.


 No.970962

>>969661

>>969539

>"open source" allows faggots like Sony to just take FreeBSD and make their locked down computer called a console or Apple to avoid working for their turd of an OS

>Open source software is free software, except it grants one additional freedom

what terrible bait.


 No.971017

>>970385

Your business model of selling software is self-limiting if you believe the only way to sell software is to copy the common model of selling proprietary software. The way to make a profit selling free software is to sell something valuable that cannot be readily duplicated.


 No.976516

>>969120 (((Telemetry '"man'")))


 No.976525

>>971017

>The way to make a profit selling free software is to sell something valuable that cannot be readily duplicate

Like putting it behind a cloud only API. This is the present.


 No.977653

File: 4ee643eb769e529⋯.jpg (64.8 KB, 450x358, 225:179, Amazing_Nigger_Engineering.jpg)

>>969129

baste and redpilled


 No.977659

>>969176

Calibre's GUI is trash-tier, but their

ebook-convert
tool is indispensable. Only pandoc comes close.

https://manual.calibre-ebook.com/generated/en/ebook-convert.html

>hydrus

I actually talked with the developer of hydrus a while ago because I have my own personal filetagging software. We had an interesting technical conversation and swapped some ideas. Hydrus isn't software that I use, but I like the developer. He seems like a good lad.


 No.977666

>>969338

GNU Guile is fun.


 No.980352

>>977666

I'll second Guile. I like to mix it with C++.


 No.980376

Remimder that drivers bloating the kernel wouldn't be an issue with a microkernel. Tannenbaum was right about everything.


 No.980386

>>980376

Drivers bloating the kernel wouldn't be an issue with a better hardware.


 No.980405

>>980386

Daily reminder that microkernels don't remove bloat that just move an equal or greater amount of bloat to another part of the system.


 No.980414

>thread caterwauling about bloat #107928374

>100+ replies

Shows how out-of-touch the autists here are.


 No.980422

>>969441

>>969435

What's special about the plan9 kernel anyway? I thought 9P, mounts and userspace made it special, not the kernel itself.

It might be hard but surely we could use the genode framework to present linux drivers as 9P filesystems, enabling plan 9 to stay small while compartmentalizing the mandatory driver bloat that exists today.


 No.988959

>>980422

From what i've read on it, you can compile the kernel down to suite very special needs. For instance, you can have one plan 9 instance be for general file storage and another for archiving. The kernel will only get to a few megabytes if you do it like that.


 No.988968

>>988959

That's the same like every other kernel on Earth.


 No.989030

suckless is just a bunch of autistic fucks who have no idea of what they are talking about.


 No.989068

>>989030

t. Electron using faggot


 No.989326

>>969176

>and he's part of that weird niche of Windows users who also write mostly free software.

That "niche" is bigger than the entire UNIX userbase.


 No.989890

>>969096

>minimalism is bad

>C is unsafe

Homosexual detected. Opinion discarded.


 No.989891

>>969129

Tell me some good suckless applications.


 No.989892

Threadly reminder

sudo apt-get remove librust*


 No.989896

>>989892

>apt-get remove

get out of that rock


 No.989897

>>989896

I just wrote it for rpms. You can use yum, dnf, emerge remove whatever you want.


 No.989980

>>989897

>apt-get

>rpm

Are you okay?

>>989326

Nice wrong opinion.


 No.990007

>>989980

>opinion

>a statement of fact (whether true or not) is now an opinion

Kill yourself


 No.990096

>>989980

>>apt-get

>>rpm

>Are you okay?

shit, deb

I suck (not cock)


 No.990339

>>989891

Dmenu, ST and i believe DWM is great too but I haven't tried it yet


 No.990368

>>969103

Could you speak about the usefulness of Tcl?


 No.990703

File: 775a2563ae322bb⋯.jpg (Spoiler Image, 703.01 KB, 860x1214, 430:607, 02d5b730037688c7fad3e623fb….jpg)

There is little point in actually using a lot of minimal software, because they lack development resources making them not good enough or buggy. Contributing code, money, documentation, etc is more helpful. Using them because they meet simple personal needs is fine but don't be upset someone uses bloated monster when minimal alternative is not good enough.


 No.990727

>>990703

But it's good enough and a lot of times even better. The only area where I see the minimalist side lacking is browsers (mainly because retarded standards). Netsurf is here but its developpement is quite slow and it will probably never implement privacy features like umatrix that are almost necessary these days.


 No.990979

>>969129

wtf i love suckless now


 No.990983

>>969129

>charlottesville murder

fat girl rioting in the street and attacking cars got hit by a car.

the only thing murdered in c-ville was responsible civil order and justice.

civilization isn't going to collapse because of "too many nazis", but it'll collapse when things get to the point that the average person commits a 'crime', realizes that's the end for them and they have not even the faintest hope of getting a just outcome from the courts, and decides to go for a high score

lit.

>due to a bad weather, a troop movement was delayed

>the general gathered his advisors, and questioned one

>"you, what's the Emperor's punishment for an army unit that's late?"

>"the entire unit is put to death, my general"

>"... and what's the Emperor's punishment for rebellion?"

>>990339

dwm's amazing. suckless software is pretty good in general. if it doesn't do enough for you, it's still a great start/reference.


 No.990988

>>990983

>https://www.youtube.com/watch?v=gs5SyBldAcA

>EU 'human rights' court says that jailtime is cool for mocking Islamifag's 9-year-old bride

>because that "could reasonably upset Islamic communities"

>no matter that this decision itself "could reasonably upset civilized communities"

fucking dark ages, man.

you can easily study suckless code and see that it's not going to leak your identity somehow.

that might be very important for you soon.


 No.991013

File: 972450be93545de⋯.jpg (3.09 MB, 2126x2567, 2126:2567, cat.jpg)

>>990988

NetBSD and OpenBSD are small & clean enough for me, don't need to go full suckless. The biggest challenge right now is the hardware. I have ARM board (with A20, dual Cortex-A7) but that's only a start, just enough to jump off the broken-by-design modern CPU madness. Maybe next is one of those Z80 kit computers.


 No.991048

File: fb81dd5da286a07⋯.png (33.96 KB, 960x544, 30:17, ClipboardImage.png)

>>969082

Don't pretend I didn't notice that FEISAR "S" logo lad


 No.991052

>>969129

>tiki torch march

how does that have anything to do with anything. is tiki torch march some white supremacist thing?

>>990703

that's not how it works dickface. having less code doesn't make you have more bugs. a bunch of faggots from Mozilla completely missing the point and implementing random bullshit like new transition effects for marketers to use in their websites, adds LOTS of bugs

>>990727

>muh umatrix

shut the fuck up nigger

>>>/g/


 No.991790

>>969330

apiService will return the entire users table, unhashed passwords and all


 No.991841

>>991052

>>muh umatrix

>shut the fuck up nigger

Where's the argument? Oh, right, you don't have one and probably have a unique fingerprint with your meme browser or enable javascript in your OS/browser like every beast in human form.


 No.992029

>>991052

>having less code doesn't make you have more bugs

Having less developers does.

Having all devs doing it for free does.

Having inexperienced devs does.


 No.992130

>>992029

>having less developers makes code more buggy

nigger no

>having inexperienced developers makes buggy code

this is the only true thing you've said, and the only thing that matters


 No.993298

>>969096

Don't have to use C, you can use ziglang which is a safer approach without sacrificing performance and it's more minimal than C as it doesn't require any runtime library while the standalone binary is a few kb.

Ziglang is also as flexible as modern languages with compile-time code


 No.993303

>>993298

To be honest, zig looks nice but it's sad that it's llvm only (like all these new languages). I'd say it's the most probable C successor, for now.


 No.993319

>>993303

Well it looks nice, but its syntax is still ugly; not Perl or Rust tier, but still far from C or Python.


 No.993500

>>993319

>Zig

>Syntax looks worse than C

The fuck this nigga saying?


 No.993562

>>969082

>> the Linux kernel (there's no way one program needs 4.8 million lines)

it doesn't though. the kernel itself is only a couple hundred thousand lines, and the important parts are even less. The rest of the "kernel" is drivers and shit like that.


 No.994235

>>993562

is there any way to take out those lines?


 No.994594

>>991048

heh, nice


 No.994646

>>994235

yeh compile your own kernel, not only can you not compile blaot drivers, you can also not compile additional blaot filesystems


 No.994686

h


 No.994912

File: 7b5a5a10e33422d⋯.png (97.51 KB, 1301x744, 1301:744, Linux_x86_3.10.0-rc2_Kerne….png)

>>994235

There are also official TUI and GUI tools that allow easy configuration of the kernel. Attached is taken from menuconfig's wiki page.


 No.994928

>>969285

I really dig your style. What OS are you on? Tell me more about your workflow.


 No.995961

>>994928

>>969285

bump for this faggot


 No.996178


 No.996187

>>991841

no you bloated faggot. just set javascript.enabled to 0

>>992029

t. nodev muricunt

>implying companies aren't filled with inexperienced devs


 No.997300


 No.997324

>>996187

t. europoor with no tech industry


 No.998025

>>997300

BLUMPF


 No.998048

>>969285

Holy shit my dude. Can you actually embed surf into emacs using xembed? Because that sounds amazing. If that is actually the case it might even be enough for me to get off my ass and learn emacs. One of the projects I currently have on the go is adding xembed support into my personal fork of links. I had originally planned on using it with tabbed but having the graphical version running within emacs sounds fantastic.


 No.998105

> chromium, firefox, most GUI web browsers

Then you're a retard. If GNU and Moonchild can fork and maintain Firefox derivatives with only a handful of developers, then its not impossible or hard.

> bloated window managers

Window managers like i3 are very lightweight already. You win nothing by using a "less bloated" version of a WM, except lose yet more features.

> anything GNU touches

Most of GNU's "extra" lines are documentation to make it easier to maintain and understand. Hell, half of cat's code is commented lines.

<b-b-but cat has options that can be done with less and 25 pipes instead!

Nobody cares. It saves time.

> the big elephant in the room that came from Red Hat

systemd? systemd itself is quite small. It becomemes big once you add all the rest of modules though.

> the Linux kernel (there's no way one program needs 4.8 million lines)

Yes, it needs those lines because it's a monolithic kernel. Most lines are drivers.

You can recompile it to use only the lines you need, but you will lose the ability to update trhough your package manager, to plug and play new hardware and you will gain 2 seconds on boot, because Linux only loads the drivers it needs in memory anyway.

<anlher good idea is to build a LFS build using only simple programs. Rather than the GNU utilities, use some of the BSD utilities, or Plan 9.

Why use LFS then? Just use BSD or Plan9 from the beginning. Why use the GNU operating system if what you want is to get rid of GNU.

<suckless

Aren't those the same retards who recommend ed over nano because it's "less bloated"? How can anyone take that shit seriously?

Also,

<waste your time patching suckless shit so they can perform the same tasks other programs can do natively anyway

This isn't the 1980s. There is no practical advantage of using gimped programs with less features just because they have less LoC.

Storage and RAM is cheap as hell and a 4 MB program is nothing. Compiling times are so fast than 1000 LoC take just a couple of seconds more to compile than 50 LoC.

There is no benefit to suckless and their bullshit. GNU tools are light enough as it is.


 No.998272

>>998105

>muh furfucks forks

>bloat = features

>systemd is not gigantic

>GNU operating system

>omg it's $current_year

fuck me


 No.998275

>>998272

>not a single counterargument

Wew.

<fuck me

Sure. In your place or mine?


 No.998504

>>998105

>most of gnus extra lines are documentation

This is demonstrably false. Most of gnus extra lines are obfuscation designed to slightly increase speed or generality at the heavy expense of readability.

>half of cat is comments

This isn't an argument. A simple program like cat shouldn't require any comments at all to understand how it behaves. Knowing gnu the comments probably amount to "wtf?!" and "you are not expected to understand this".

><cat has options

This is news to me

>1000loc takes a couple of seconds to compile

Thank god this is only true for the most degenerate of c++ code. Still, this ignores that suckless software expects configuration to be done through recompilation of the whole software. This would be untenable for the "set it before bed, hope it compiles before you wake up" of modern browsers, but is unnoticable given the line counts of suckless software.


 No.998572

cat is for concatenating files. using it for anything else such as text processing or with only one argument (cat file | blah) is misuse and should be punished.

>acceptable uses

cat shit.txt (display a file)

cat a.txt b.txt c.txt (join files)

links -dump thing.html | cat hdr.txt - foot.txt > saved.txt

>unacceptable uses

cat shit.txt | fold -sw80 (use shell redirection instead)


 No.998582

>>998572

>cat shit.txt | fold -sw80 unacceptable

cat -n shit.txt | fold -sw80 acceptable


 No.998587

>>998572

>is misuse

LARPer detected. Doubt you even use OpenBSD. The UNIX spirit is using the right tool for the right job, or the wrong job if it works. Is `cat << EOF fuck you EOF` """misuse"""?


 No.998636

File: bc12729e66e9d83⋯.png (444.45 KB, 642x11780, 321:5890, cat.png)

>>998504

>This is demonstrably false

OK. Demonstrate it then.

>A simple program like cat shouldn't require any comments at all to understand how it behaves

It doesn't. But it's good practice to help others understand your code.

>Knowing gnu the comments probably amount to "wtf?!" and "you are not expected to understand this".

So you don't know GNU and you haven't seen Coreutil's source code. Why are you trying to discuss something you haven't seen?

>Thank god this is only true for the most degenerate of c++ code

Irrelevant. The point is that there is no point in obsessing over LoC.

>Still, this ignores that suckless software expects configuration to be done through recompilation of the whole software

This is terrible design that doesn't work for complex programs.


 No.998638

>>998636

>This is terrible design that doesn't work for complex programs.

Is this your only argument? That it doesn't work for big programs? Suckless uses this because they only do simple programs, and because you don't have to write and use a runtime parser, cc already does the job.

The other anon seems like a retarded larper, but you seem to cultivate an irrational hate of minimalism too.


 No.998650

>>998638

Nah dude. I don't hate minimalism. Just Suckless.


 No.998653

>>998504

Suckless doesn’t count dependencies for LoC.

Surf still uses WebKit.


 No.998669

>>998636

>demonstrate it then

I dont need to, because you did it for me. Read over that program you posted; cat as we know it has been renamed to "simplecat". With comments it takes up about 40 lines. To make a full gnu program, again with comments, would take about 100 lines. Instead we get a 700 line abomination.

Now look at a slightly more demanding program: factor. Here, gnu gives up on commenting every second line, so the majority of the 2600 lines before cgit gives up on numbering them comes from the tendency in gnu software to redo everything twice, in slightly different ways. Reading from the bottom, the first glaring example is their 100 line reimplementation if line buffering.

>this is a terrible design that doesn't work for complex programs

How droll to hear this from a gnufag. Notice the ifdefs scattered through your cat example. Guess what these are for. Hint: its not runtime configuration.

>>998653

The best criticisms of suckless are always of the form "they fail to live up to their own goals". If they managed to write their own browser, that would be glorious. Instead, they use webkit, which already implements the majority of a browser, so they only add a thin layer of configuration around it and call it a day. From a standpoint purely of configuration options, you are better off using firefox.


 No.998677

>>998669

>From a standpoint purely of configuration options

What an absolutely retarded metric


 No.998687

>>998677

The way of the ricer.


 No.998734

>>998677

That's the whole allure of suckless, or even free software in general, you can modify it to your purposes.


 No.998779

>>998669

You didn't show how cat, or any GNU software, is "obfuscated" or "propietary."


 No.1001334

>>969285

you little ratshit double nigger, you better reply to me >>994928

i put my thinkpad in the fridge just to compile surf and now you leave me


 No.1001370

>>1001334

???

Wont that make your cpu run slower?


 No.1001377

>>1001370

no it kept overheating and shutting down


 No.1001451

>>998779

Is that what this thread is about?

>2 months ago

god damn have you faggots been bumping this. My argument for that can be found here: >>969384

I was just countering the notion that gnu is only verbose because of comments.


 No.1001459

How much control google have over the android?


 No.1001482

>>991048

>branding experts are at it again

are you going to crash suckless with no survivors?


 No.1002044

>>969188

Do you have a breakdown of those drivers? I'd assume individual drivers are quite small.

>>969082

The entire LoC debate is a bit of a moot point anyway. your system only ever needs a subset of those 4.8 million lines of code. and the most common drivers probaly make up a tiny part of those 4.8mil while legacy hardware and hardware with slight differences in setup contribute more to the LOC Death. Its only dangerous or worrysome if someone found an exploit in those legacy drivers and could force computers to fallback or use those. And we're not even talking about the fact that there is a difference between LOC and machine language. every arch probaly has errata ( I'm looking at you, Intel ) and therefore every arch will have arch specific code to circumvent alot of issues. which means you'll have multiple versions of the same code all for targeting certain systems.

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf

This is just to show what kernel devs MIGHT have to avoid when targeting certain systems. AMD has them too, like how FMA instr exist but dont work. AMD disabled them so you can't break your system.


 No.1002238

>>969129

Looks like I ought to look into suckless further, then. I wouldn't have bothered if it were not for your post. Thanks, faggot.


 No.1002242

>>969082

I set up void on my old laptop to have a play and to be really fucking honest:

systemd is the single best thing that was ever developed for GNU/Linux.

>muh unix philosophy

>muh bloated init

fuck you, if you think runit is a great way to manage your daemons and multi-process services you're retarded, there's no way to ship default configs for it and when I get a new service I want running I have to dick around setting it up like a faggot.


 No.1002246

>>969443

>math shit

Daily reminder that you're a nigger that doesn't understand the purpose of formal verification. Formal verification proves only that the software is correct. It does not (and cannot) prevent the OS being exploitable due to dud hardware.


 No.1002278

>>998504

>at the heavy expense of readability

Readability is overrated. You program software for computers, not for people.


 No.1002281

>>990339

>>990983

dwm is garbage. Fullscreen applications in particular were giving me major headaches until I just switched to bspwm.

> Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist.

> This keeps its userbase small and elitist.

’nuff said about the goals of suckless.


 No.1002284

>>1002242

I_never_tried_openrc.tiff


 No.1002285

>>1002281

If you think `elitist` is a double-plus-ungood word, you dont belong in here. If you actually know what it means, retard.


 No.1002286

>>1002278

The binary is for computers and the program is for people, tardo.


 No.1002288

>>1002278

>Readability is overrated.

Your career is going places. I can tell.


 No.1002289

File: 74c0ecff901f54c⋯.webm (5.35 MB, 400x226, 200:113, nvidia.webm)

>>969082

>bloat

call it what it is: obfuscation by spam

the "it just werks"fags are going crazy in this thread worshiping their unoptimized code

Look into using an RTOS OP, no coc, no bullshit, just mathematically verified code.


 No.1002450

>>1002284

>just install another shitty init

I think the basic problem is that you're not getting that service management is just better when you can kill the process tree of a service through one interface and have it just werk.

I mean sure, politics, whatever, but have you tried ubuntu server 18.04? It's so fucking easy to set up you never want to go back to a dirty peasant OS.


 No.1002469

>>969285

hello surfnigger, me again. bumping this.

i read this post like every two days, I wanna get this good.


 No.1002475

>>1002450

>openrc is an init

Way to show your ignorance. Openrc uses sysvinit out of the box (there's openrc-init, too).


 No.1002583

>>1002475

ok, so what you're saying is I install yet more shit into my minimal bloat free os?


 No.1002691

>>1002288

Programming is the worst career. Sure, you (might) get paid well but the amount of hair-pulling bullshit you'll have to deal with is just not worth it. So yeah, not an argument.


 No.1002699

>>1002285

Making “elitism” your goal just results in a community of niggers that masturbate each other's dicks without achieving anything significant. See OpenBSD.


 No.1002916

File: 4b121ec38cfd133⋯.png (128.49 KB, 384x384, 1:1, stockfish.png)

Stockfish is one of the least suckless software out there.


 No.1002919

>>1002583

You reduce bloat by having one tool to do a specific well defined function. Each tool does something as minimal as possible and you compose these little tools together to form more sophisticated functionality.


 No.1002929

>>1002699

Then you don't know what elitism is. Hint: it's not a goal, but a mean.


 No.1002951

>>969082

We need a minimal firefox build.


 No.1002956

>>1002951

What we need is niggers like you killing themselves.


 No.1003793

>>1002951

It's not firefox,it's the modern web.


 No.1003794

>>1002956

you completely missed his point. that's why he said "making elitism your GOAL"


 No.1003833

>>1003794

But nobody does, even those saying that they do, that's my point. Elitism is just giving more power to the most able. Even if your goal is having elites around you, that's not elitism being the goal here.


 No.1004342

>>1002919

>Each tool does something as minimal as possible and you compose these little tools together to form more sophisticated functionality.

You mean like those single-function npm packages?

Having too specific tools can lead to bloat too.


 No.1004386

I'm loving dwm, to I tried st. Nice simple terminal, but I cannot make the delete key work. In vim I only get ^? and P] on terminal. Applied the patch but nothing. Seems to be something with the smkx or rmkx tput mode.

Does anyone have a solution? I think I'm gonna go back to urxvt, at least seems to work well and th daemon/clirnt is a plus


 No.1004434

>>1004342

If you're so lazy that you'd import a set of single function libraries rather than reimplementing them, you deserve all the bloat you get.


 No.1004438

>>1004386

should be able to add a line like this to your config.h, no?

         { XK_Delete,        XK_NO_MOD,      "\x7f",          0,    0,    0},


 No.1004576

>>1004434

>If you're

>you'd

>you deserve

What are developers?

What other people do affects the quality of the code available, especially as less trivial libs use those one-liners too.

Also, you concede that "as minimal as possible" is not good enough on its own.


 No.1010393

File: 111ce01d9e2c1be⋯.png (26.36 KB, 820x1172, 205:293, urielwasright.png)

>>969082

I agree with you so much OP. The world has changed. It's no more some plain evil Ballmer pushing for proprietary software. The problem is more subtle and complicated.

Stallman's big idea have already been heard. Github/Gitlab code hosting is an industry standard, Android is open source, all popular browsers are either open-source or have a open-source version. Same with text editors, Atom and VSCode are free as in freedom. GNU/Linux distros are becoming popular. We have won the war, heh?

But takes no genius to realize that something in this list is strange, uncanny even.

The very architecture of Android with virtual os for every app. Browsers hogging up all the ram. Apps that use full browser capabilities just for text editing. Linux ridden with systemd bullshit. And, of course, GNU software that was written just for the sake of being libre, further bringing politics in software development.

The code becomes so needlessly complex and bureaucratic that it is no more viable to change it without a team of code-monkeys. That just negates the purpose of Stallman's freedom.

That's why it's time for suckless initiative to flourish.

Be less GNU, more UNIX. Use suckless software.


 No.1010416

>>1002242

>systemd is the single best thing that was ever developed for GNU/Linux.

no, it isn't. otherwise i would have installed it let alone know what purpose it's intended to serve. just like all the other gnome shit, you can't even describe what it's supposed to do. your gayass gnome image viewer is 30KLOC, takes 20 seconds to load the first time after boot, has _second_ delays for panning/zooming. my image viewer does everything within the refresh interval (16.66ms max), is 1KLOC, and _still_ has less dependencies. i literally tried all the gnome image viewers and they're all shit. same with all the file browsers. same with all the gnome text editors. extrapolating a bit, if they can't even accomplish such basic tasks, it should be obvious that all of gnome is shit, and anything of that ilk such as systemd. luckily gentoo never came with the D by default.

systemd and gnome are created by that white nerdy skinny SJW guy in the corner of your high school and college. he constantly appeals to rules for the sake of looking smart (or something) ("you said the N word that's racist get out of my server", "you j-walked, that's a misdemeanor", "you indented your code wrong"). this is a cancerous culture and everything they make is trash. he thinks XML, Java, and HTML are good.


 No.1010418

>>1003793

it absolutely is firefox my nigger. but it's the modern web too


 No.1010579

>>1010393

protip: the free software movement has been a political and social movement since day 1. Stallman's idea of freedom is that users who have authority to practice four specific freedoms. The idea of complex code does not negate Stallman's ideal of freedom.


 No.1010604


 No.1010649

>>1010604

Somebody is implying that complex software is proprietary software. This is false. Complex software licensed under the GPL is free software by virtue of the freedoms granted to the users of the software.


 No.1010664

>>1010649

>Complex software licensed under the GPL is free software by virtue of the freedoms granted to the users of the software.

"The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this."

If it's sufficiently complex, you cannot understand how it works. At best you can understand a small chunk at a time, but in order to properly understand how those chunks interact with one-another, you'll need help from other people who understand those parts, who could easily not care about your problems, autistically argue that your goals are dumb, or have left the project without properly documenting their steaming pile of unintentionally obfuscated spaghetti shit.

Complex GPL'd software is effectively only gratis if its complexity hinders your ability to exercise Freedom 1.


 No.1010666

>>1010664

My little daughter can't understand C code yet so suckless.org projects are proprietary closed source garbage


 No.1010669


 No.1010675

>>1010666

>My little daughter can't understand C code

She doesn't need to, Beast. All she needs to understand is cooking, cleaning, servicing cock, and rearing small children. Anything else is wasted on females.

https://ebooks.adelaide.edu.au/s/schopenhauer/arthur/essays/chapter5.html


 No.1010676

>>1010675

>(((Schopenhauer)))


 No.1010680

>>1010664

People who study computer software system logic by exclusively by reading and remembering source code have only themselves to blame when they cannot deal with the complexity of the system. You promote understanding of specific details of the system by abstracting the system into a collection of various system models. An example of a model is a land topography map which shows an abstraction of the shape and features of the land without the need for a highly sophisticated 3D laser scan of the land. Likewise, computer software can also be modeled into a set of system models with each model that has a focus on one specific detail.

The creation of system models is how you document a system without direct guidance of the architect(s) that preceded the current reader of the system.


 No.1010686

>>1010676

Schopenhauer wasn't Jewish. He also opposed the Jewish worldview. But, please, by all means, continue to ((())) everything you disagree with, so we can all see what a moron you are.


 No.1010698

>>1010686

Please, never breed.


 No.1010706

>>1010698

>resorting to name calling

Sasuga nu-/pol/ (Reddit, at this point).


 No.1010733

>>1010649

>>1010579

OP here, you are full of shit.

Complicated GPL'd software is de facto non-free because the amount of work required to edit it is too damn high. It's similar to how in US politics, we can choose from which ever party we want, but we can't get anyone outside of two special parties into congress or the white house, at least not beyond one or two people in the house.

>inb4 burning sandals

Though you should still vote for a third party if you want that to change, but let's get back to software.

Cry all you want about how complicated software under the GPL is free, but try and add something to a project like systemd, firefox, vim, or the fucking Linux kernel itself that impacts it in some meaningful way. Hell, just try to understand how it works, and not just how it should work

I want to make another point about complex software, but note that I have been careful to use the term "complicated" software here, rather than "complex". Complex software ""is not"" complicated software. Or rather, it doesn't have to be. To quote from PEP 20:

>Simple is better than complex.

>Complex is better than complicated.

Sometimes you 'need' complex software, but you can mitigate that by careful organization of code and ""good documentation."" If you can't easily explain the structure of your program through at most 3 paragraphs of text, then your code is complicated.

A good example of complex software is GIMP. The basic structure of GIMP is two parts ­-- one for displaying images and one for manipulating images -- held together by some very thin glue. At least now you can begin to wrap your head around what it is that GIMP does, rather than understand it as "buttons that do stuff." Hell, I hate GNU Emacs and I still think you could use these points to argue that it is a good example of complex software that isn't complicated, with how everything is an ELISP function. Want to find out how it opens a window? Go find the ELISP function and find the binding of that ELISP function to a C function.

I plan on making a mail server soon. I don't know how to code it, but I already know the basic structure of it. It's going to have a Go program to listen to the network, and then I am just going to use some shell scripts to query the email files and format them properly. The code for this might be complex, although I hope not, but just from this one sentence, I bet some of you could contribute to this project if you so wanted to.

>>1010393

I feel honored to receive a Uriel on my post. Thank you.


 No.1010835

>>1010733

The reason why you're wrong is because you believe that it is impractical for a single person to modify the source code to complicated software. The reason why this is wrong is because there exists ways to improve the understanding of source code so that any single person can understand the entirety of the source code in detail or the software system as a whole. The name of the study that allows individuals and teams to study a system is called "systems modeling". Professionals use many kinds of models to conceptualize and construct systems thus allowing them to intimately understand what it means.


 No.1010927

>>1010835

>any single person can understand the entirety of the source code in detail

I sincerely doubt that you could do that in a lifetime.

https://dwheeler.com/sloc/redhat71-v1/redhat71sloc.html


 No.1010931

>>1010835

I recently submitted a patch to a popular software project. I wanted to add a new keybinding to modify the way search worked. In order to make this patch, I had to understand and modify two files: the file relating to keybindings, and the file relating to search. Overall time spent couldn't have been much longer than an hour. That is what the OP refers to as practicality. Requiring someone to be a professional, requiring they achieve a high level understanding of the software, requiring they look into the major files in order to get an idea of the software, all impede practicality.


 No.1010935

>>1010835

Oh, and we shouldn't complain about proprietary software because we all can just open it with a hex editor and expect great things. >>1010931 hits the nail on the head.


 No.1010964

>>1010935

Implying any of you faggots could open a normal text editor and do anything interesting with plain source.


 No.1010972

>>1010927

>june 30th 2001

>Thus, Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2

take fedora to be redhat's continuation and it's in version 29 now.

But the article is focused on another important part of this: all that code is code you didn't have to write yourself, and therefore money you didn't have to spend yourself. You don't want to understand every line, because understanding code is almost as hard as writing code. You want to understand as little of the code as possible to be able to make relevant changes


 No.1011291

>>1010972

>You want to understand as little of the code as possible to be able to make relevant changes

Simple & bloat-less programs make this really easy.


 No.1011386

>>1011291

Have you actually ever read a suckless program? They may be smaller than most, but they sure as fuck are not high quality.


 No.1011534

>>1011386

This is true, but the size alone makes them easier to modify then most projects. They included a popup blocker in surf at one point, which had a tendency to block some popups I needed. Removing it was easy, basically because they have few enough source lines that you can look through every single one checking if it blocks popups.


 No.1011550

>>1011386

>st

>not high quality

>smug_anime_girl.png


 No.1011815

>>1011550

It is higher quality than xterm I will give them that.


 No.1012770

File: 302221edd763713⋯.jpeg (20.99 KB, 400x599, 400:599, painChart.jpeg)

>>969082

I hate to tell you, but lots of suckless' code is absolute shit. Example from their 'sic' program, an IRC reader:


size_t
strlcpy(char *dst, const char *src, size_t siz)
{
char *d = dst;
const char *s = src;
size_t n = siz;
/* Copy as many bytes as will fit */
if (n != 0) {
while (--n != 0) {
if ((*d++ = *s++) == '\0')
break;
}
}
/* Not enough room in dst, add NUL and traverse rest of src */
if (n == 0) {
if (siz != 0)
*d = '\0'; /* NUL-terminate dst */
while (*s++)
;
}
return(s - src - 1); /* count does not include NUL */
}

Look at this shit, there's not only the normal break statements and odd names that you expect from bad code, THEY ARE LITERALLY DOING POINTER MATH ``INSIDE OF A CONDITIONAL STATEMENT IN A LOOP``. I knew /tech/ was mainly full of pajeets who've never read actual code before but ``christ``, this isn't good. I get that it's written in C and C lends itself to ugly code but this is ==Literal Garbage==


 No.1012772

File: 5d06e615970a3cc⋯.jpg (111.97 KB, 900x900, 1:1, Brother_Nathanael.jpg)

>>1012770

>so new you don't know how to format posts


 No.1012780

>>1012772

> Sees statement

> Skips statement to make fun of not knowing esoteric markup

Imagine your existance


 No.1012790

>>1012770

Maybe it's just faster?


 No.1012800

>>1012770

while (--n != 0) {

what terrible code! Everyone knows it's idiomatic to use the goes to operator:

while(n --> 0){

>>1012790

If they cared about speed, they would be copying words at a time. This a clear case of preferring elegance and beauty over performance - endemic to suckless code, unfortunately.


 No.1012812

>>1012800

There is absolutely nothing elegant about writing obtuse code.


 No.1012819

>>969443

>it's still vulnerable to spectre and meltdown without any mitigation

Wow, a assumption in microarchitecture that leads to a side channel timing attack, and surely a kernel must be held responsible.


 No.1012841

>>1012780

>not knowing esoteric markup

That's the funny part: no one would notice or care if he hadn't tried to litter his post with it and failed.


 No.1012883

>>1012770

>suckless' code is absolute shit

>posts openbsd code

>this code is bad because I am a PHPtard that has no fucking clue

Holy shit I wish I could believe you were trolling and not actually that stupid.


 No.1012900

If they wanted to avoid bloat they wouldn't use C and UNIX paradigms.


 No.1012991

>>969082

>suckless community doesnt even fucking sign their code

No thanks


 No.1017444

>>1012991

they don't? wtf? do they even try to justify this?


 No.1017494

>>1012900

They would use a garbage collected monstruosity or some special snowflake shit like Forth?


 No.1017624

>>1017444

Cryptography is bloat.


 No.1017635

>>1017624

privacy is bloat


 No.1017636

authentication is bloat

integrity is bloat


 No.1017766

>>991013

Fucking larper.

No, using an 4mhz 8 bit computer with 512kb of ram through a 1ghz 512mb proxy doesn't count as using an 8 bit computer on the Internet.


 No.1022233

OP again.

>>998105

>Why use LFS then? Just use BSD or Plan9 from the beginning. Why use the GNU operating system if what you want is to get rid of GNU.

I admit that I didn't hear about Plan 9 and was very hesitant to use BSD because of the compatibility issues it has with hardware. And yes, I know about NetBSD. I don't plan on using them because I'm not sure they use 100% free software. However, I have taken the time to install OpenBSD on an old rack server I have and will probably install 9front on my next laptop. As of right now, I just use Debian with the Plan 9 from User Space tools. Acme is my shit.

><b-b-but [GNU] cat has options that can be done with less and 25 pipes instead!

Have you ever heard of making scripts? They can do all the shit the extra options in cat can do, but with out the retardedness. Plus it's way more fun that way. >>998669 has also shown how retarded you and GNU are. Anyone who defends the quality of GNU projects, or lack thereof, is a laughing stock.


 No.1022265

>>1022233

have these changes in your workflow made you more productive? as in, are you accomplishing things at a faster thanks to these new tools?

gnu cat is longer program by lines of code, but it is both faster and has more options, and that lets me accomplish things quicker. If you don't use the options, the code is not executed. so upon execution, a gnu at and a bsd cat will look much more similar. I don't particuarly have a problem with this.


 No.1022271

anyway, GuixSD > all other OSes in terms of elegance AND productivity (ding ding ding!), and one day the hurd will be released and emacs xor guix will be written to be in the same language (hopefully common lisp tbh, as much as I enjoy scheme)

meanwhile I'd rather spend my time gittn fukn gud so maybe I can help move things along than being autistic about how many locs a program has and worrying about what the council of cat-v autist have decided is "harmful" (oh the irony)

LISP FAGS WILL WIN


 No.1022285

>>1022271

>(hopefully common lisp)

actually i officially change my mind, i never realized all the benefits of guile-emacs until now


 No.1022407

>>1022285

>guile

Enjoy your "bash the fash" retarded maintainer.


 No.1022436

>>1022265

>gnu cat is faster

I'm not sure this is true in general though. I was recently annoyed by how slow gnu sort was (4000 lines). I decided to reimplement it to see if I could do better. Half an hour later I had a faster version of sort. Of course it doesn't support a single option. But this demonstrates that the options do come at the cost of speed. The particular thing that was slow for me was sort -R (lesson learned: use shuf), so I decided to look at the source code to see what they were doing wrong. I discovered that random sort was implemented by:

- generating a random seed (random_md5_state)

- hashing every input line with the seed

- comparing the resulting hash

This means that random sorting takes 10 times longer than regular sorting, rather than ten times faster as it should be. This, I think, is a product of bloated software. Once you've committed thousands of lines of source code, it feels wasteful to ignore it all when you implement the next flag. This even though it would require a lot fewer lines, and be so much faster.

Here's my version of sort if you want to pick it apart: http://paste.debian.net/1062104/


 No.1022438

>>1022407

>not using retard commienigger software to build national socialist propaganda distribution platforms


 No.1022445

>>1022438

Now you see the light


 No.1022453

>>1022285

>Guile-based Emacs is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile. It does not attempt to remove Elisp, and instead aims to become the canonical GNU Emacs of the future by being fully backwards compatible. It’s best to call it “GuileEmacs” or “Guile/Emacs” or such to make it clear that it’s still GNU Emacs.

hmmm why not Rust?


 No.1022455

>>1022271

>anyway, GuixSD > all other OSes

Second paragraph:

https://www.gnu.org/software/guix/contribute/

>>1022438

>not using retard commienigger software to build national socialist propaganda distribution platforms

Guix does come with an SXML library that makes generating HTML really easy. Just food for though... and make sure you proudly display in the footer that the page was written in GNU Guile


 No.1022456

>>1022455

Day of the fork soon


 No.1022469

>>1022436

>This means that random sorting takes 10 times longer than regular sorting, rather than ten times faster as it should be.

Random sorting is unlikely to be much faster than regular sorting on average (as the bulk of sorting comparisons will be done within the first few chars), and it's plausible for it to be slower on very large collections due to being impossible to split into batches.


 No.1022483

>>1022469

If you do it the gnu sort way, this is all correct. My point was that a random sort shouldn't be implemented as an actual sort, because it's so slow. Just do a shuffle instead.


 No.1022496

>>1022407

would you cry if your free hammer was made by a commie?

>>1022436

you completely ignored my question about productivity though (the more important concern), and one benchmark doesn't say much about the broader scope of performance comparison. I doubt this one slower benchmark has any meaningful impact in the larger scope of day to day productivity.

>>1022455

>https://www.gnu.org/software/guix/contribute/

I have and continue to do so.


 No.1022505

>>1022455

Other schemes have an sxml.


 No.1022509

>>1022505

I know, I just think it would be funny if a site about gassing kikes were to proudly proclaim "powered by GNU Guile". I wonder what the meltdown of Wingo would look like. I'm sure it would go over his head that his faggotry is the sole reason that site even exists and has that note. Freedom zero is to run the program for any purpose, so there is nothing he could do about it.


 No.1022522

>>1022496

>would you cry if your free hammer was made by a commie?

Using a free hammer doesn't imply you condemn this bullshit. Contributing to Guix does.


 No.1022555

>>1022496

Very frequently people respond to concerns about the size of various GNU programs by saying that they need to be this way in order to be fast. Maybe you don't think this, but this is what I read into your comment. Once you eliminate concerns about speed, number of options or "productivity", and number of lines or "bloat", stop seeming like such heavily correlated things.


 No.1022576

>>1022271

>have to learn SCHEME

ok fag, NixOS doesn't seem to have a code of cuck :^)


 No.1022582

>>1022576

I get the concern about the CoC, but what's wrong with learning Scheme? If you want to write Nix packages you have to learn Nix's custom language, so if you have to learn a new language you might as well learn one that can be used for other tasks as well.


 No.1022583

>>1022582

(((i wonder why scheme hasn't taken off)))


 No.1022622

>>1022583

Not an argument.


 No.1022708

>>1022483

>Just do a shuffle instead.

You still need to have all the elements indexes to do that, keep in mind that a random sort needs to be random, it won't do if some elements are more likely to end up in certain positions.

The Gnu way is pointlessly slow, since you don't care about the content of whatever you're random sorting, but even in theory your random sort speed is limited by how fast you can produce entropy.


 No.1022720

>>1022708

Randomly pick an item from the list and pop it. Randomly pick another item and pop it. Repeat until you run out of items. It's not hard to show that under this scheme every element has equal likelihood of appearing at every position.

>your random sort speed is limited by the entropy you can produce

GNU sort is using md5. They don't care about true randomness or cryptographic security.


 No.1022748

>>969082

<Don't use urxvt, use st. Don't use i3, use dwm.

No, fuck off. They are both crippled, useless garbage that relies on external programs to make up for their lack of functionality.

Suddenly you now neet tmux, xsetroot,... all for basic tasks that have been taken away in the name of "minimalism".

dwm in particular is just workaround after workaround to replicate what other window managers already give you out of the box.

Pretty much any window manager is "minimal" enough already to run fine on most computers. i3 runs flawlessly on my old T42, and performance-wise, it's pretty much indistinguishable from dwm.

The only good program ever made by Suckless is dmenu. That's it.

Suckless? More like Suckass.


 No.1022753

>>1022748

>dwm lacks functionality

>muh i3

lmao


 No.1022756

>>1022753

Wow, what an argument.


 No.1022763

>>1022748

>i3 runs flawlessly on my old T42, and performance-wise, it's pretty much indistinguishable from dwm.

Niggers don't care about principles, as always.

The real answer is bspwm > dwm > i3.


 No.1022764

>>1022756

You had a nice big cry about how you set your desktop background using dwm. Let's not pretend there's anything to discuss here.


 No.1022765

>>1022764

You think being able to run xsetbg is an achievement and proof of superiority. You're right, there really is nothing to discuss here.


 No.1022766

>>1022763

>Niggers don't care about principles, as always.

I outright refuse the princples of featureless software, not sure what you're getting at.


 No.1022769

>>1022765

How do you set the wallpaper in i3?


 No.1022772

>>1022769

feh, from what I've seen


 No.1026797

Featureless strikes again: https://lists.suckless.org/dev/1902/33214.html

>These releases are the last ones that contain Xft support, which will be removed in the releases to follow.

>The Xft mess has to be retired in favour for plain old Xfonts.

Try to rationalize this.


 No.1026921

>>1026797

only matters if you have to make your font size giant, and you only do that if you're fucking blind


 No.1026925

>>1026921

Except some of us have displays that are more than 1080p anon


 No.1026939

I don't care as much about bloated software as I care about unfree hardware that doesn't let me run whatever the fuck I want on it, to be honest.


 No.1026951

>>969102

>Then you just patch the kernel so it supports your hardware. Ideally companies should provide the patches themselves, but community patches are cool too.

This is exactly what android has done for years and it is a massive shit show because of it.


 No.1026982

>>1026921

>let's assume that font size values will never grow due to increasing screen resolution, what could go wrong

I'm baffled by how short sighted freetards can be


 No.1026989

File: 193bc389adb93d4⋯.jpg (52.26 KB, 474x355, 474:355, terminus.jpg)

>>1026982

There are newer fonts than xfonts-base compatible with hidpi displays


 No.1026993

>>1026982

That isn't a free software issue. Gnome and KDE has no problem with HiDPI screens or fonts. Suckless's ideal of system design is far too spartan for the rest of the world.


 No.1026994

>>1026939

This. If I am supposed to own the machine, then I should be able to run all the bloated software I desire. At that stage, I will be able to change the bloated software into any other non-bloated software.


 No.1027009

File: 3596d334fa3af5d⋯.png (18.5 KB, 1249x1146, 1249:1146, latest.png)

I've downloaded the DOS fonts from int10h.org (because some of them are nice looking) and made 2x scaled versions both for pure virtual tty (.psf) and for X (.bdf) I also upscaled some other fonts like the Amiga Topaz font and such. (love old bitmap fonts) They have a good size on my 4k screen. It's not even hard, all the tools are a few searches away. Bitmap fonts render a lot faster in terminal emulation because they don't go through so many intermittent steps and also they line up perfectly, for example for box drawing in curses applications, which is almost impossible to pull off with all the trickery vector based fonts often do. This is really basic stuff. For you people constantly going on about muh unix philosophy and muh minimalism, a lot of you really don't know how to do the most basic things without somebody or something holding your hand.

I'm not even defending st here, because it's really way too bare and also kinda broken. Now to blow your mind some more, with some of the more advanced terminal emulators, you can change the font on the fly.


 No.1027017

>>1027004

>far too spartan for the rest of the world

How naive of you. You think the "world" really cares about resolutions beyond 1080p? Don't need that to go on Facebook or read your mails.

inb4 better font rendering, normalcattle is content with what Windows offer, why would they even care? The only thing a high resolution brings is bigger GPU requirements.


 No.1027035

>>1026993

>That isn't a free software issue.

Suckless is a current of free software, so it is.

>>1027009

> For you people constantly going on about muh unix philosophy and muh minimalism, a lot of you really don't know how to do the most basic things without somebody or something holding your hand.

Manually creating large fonts is not basic, not minimal, and honestly pretty stupid: the entire point of fonts is to handle that stuff on their side,resizing them manually is like using a library but then reimplementing all of its functions.


 No.1027838

>>1027035

>resizing them manually is like using a library but then reimplementing all of its functions

This so much. Ultra-minimalistfags don't realize that they are just making things harder on themselves for no real gain.


 No.1027873

>>969096

>no array bounds checking

>you can return pointers to temporary stack memory

>you can use variables which are uninitialized and thus contain junk memory

These all are language sugar that makes it bloated.


 No.1027874

What's a script? Upscaling a whole folder of fonts was basically a two liner (three, if you count compressing them afterwards) and I don't have to deal with shit like box drawing not working out in curses programs because the font rendering system shoved a few pixels around because of some subpixel rendering shit and now nothing lines up anymore and it's entirely unclear how to turn it off just for that font but not for the browser, for example. THAT shit is neither basic nor minimal. I instead know I'll get exactly what I put in. It doesn't get any more basic than that. They're doing the right thing regarding future maintainability and entirely avoiding the palettes of cans of worms that is X font rendering. Shit's broken. Like I said, I'm not even defending st, it's not a good terminal emulator IMHO, but cutting that shit out was the right idea. If you people weren't a bunch of larpers you'd just re-implement it in your fork instead of whining around on an image board, lol.


 No.1027901

>>1027873

You aren't making any sense, in which way is an initialization check at compile time "bloat"?

>>1027874

>What's a script?

A miserable little pile of bugs.

The point is not that upscaling fonts is hard, the point is that it's anything but minimal.


 No.1027993

>>1027874

>I did this work myself therefore the software that made me do it by being shit is actually good

lmao same mentality that keeps zsh and emacs in business.

If suckless stops displaying working fonts then rip I could give a fuck about maintaining a fork when there are plenty of other projects out there that are only slightly more bloated but work.


 No.1028014

>>1027993

>If suckless stops displaying working fonts then rip I could give a fuck about maintaining a fork when there are plenty of other projects out there that are only slightly more bloated but work.

Agree 100%. I'm a dwm+st user myself, but having to patch them to make them usable is a flaw, not a virtue. Despite this, they are actually excellent pieces of software once properly configured and patched from a purely functional point of view, and that's the main reason I use them.

However, dropping a widespread font rendering system, functionality that dwm *already has*, for no real reason, is insanity.

The problem with software "minimalism" is that, while being good in principle, it often becomes an excuse for making crippled, partially functioning programs that need to rely on others to offer a complete, productive computing experience. And no, this doesn't mean "following the Unix philosophy". It simply means that the tools are not self-sufficient, and can't even perform what is conceptually seen as the "one thing" they should do.

Take this guy: >>969285 for example. He seems to have an interesting, efficient workflow where he uses Emacs to control separate Suckless programs. This is possible because the underlying program used, Emacs, offers a fuckton of functionality that is able to compensate missing features from applications such as Surf. Most will agree, however, that Emacs is the antithesis of "minimalism".

So, while the individual Suckless programs aren't "bloat", the whole combination ends up being absolutely not minimal, and the whole, not the individual parts, is what ultimately counts.

Not to mention that striving to follow the "Unix philosophy" at all costs is not always the right thing to do. Emacs is a prime example of this. People who love Emacs do so exactly because it offers a large, comprehensive set of features, as opposed to other editors.


 No.1028025

>>1027993

>>1028014

Only faggots like you who haven't looked at xft and fontconfig (with its nice XML config files) can be content with this bullshit. Xfonts are perfect for terminal emulators, the only thing it lacks is a fallback mechanism.


 No.1028041

>>1028025

>Only faggots like you who haven't looked at xft and fontconfig (with its nice XML config files) can be content with this bullshit.

That's because you have "muh minimalism" so far up your ass that you can't conceive that most of its configuration is meant to be done automatically by programs.

>the only thing it lacks is a fallback mechanism.

You are saying this as if it were a trivial issue.

Besides, xft support adds very little complexity on the application's part. Font rendering itself (and fallback) is handled by fontconfig. Plus, Suckless has announced their intention to drop xft from dwm and dmenu, they have said nothing about st, which does support xft and will likely still continue in the future, as many people, even st users, do use xft fonts. We are not talking about terminals here.

Yes, Xfonts still work fine for terminal emulators, and I use them myself, but they aren't the only place where fonts are used, you know, and not a complete substitute.

The thing is, this is not a discussion about whether to implement something or not. Such functionality *already exists* in dwm and dmenu. Dropping it offers zero benefits and creates needless complications. fontconfig is already available on nearly every Unix-like operating system. It would be like dropping X support because X is a mess (it is, but it's too widespread to be ignored).

Merely stating that something is shit won't make it go away. You have to offer something that can replace it, doing the same things at least, but better. Yes, xft and fontconfig have issues, but xfonts can't completely replace what they offer. Meanwhile, Wayland is here, and Suckless fags still use X.


 No.1028104

>>1026797

just dont update then. those programs are already complete.


 No.1028106

>>1028104

This guy gets it, they aren't even internet facing so it's not like you need the newest security update. I've got a heavily customized dmenu and there's no point for me to ever update it as long as X11 won't change in some huge way, which it won't.


 No.1028134

>>1028106

>they aren't even internet facing

>curl wttr.in

As long as the computer is networked, any program should be treated as internet facing.

terry was right

Although I do wonder if these short programs even contain any exploits. People say that c is necessarily insecure, but they demonstrate it by showing some million line bloated mess with an exponential SLoC graph.


 No.1028205

>>1028104

>another shortsighted freetard


 No.1028210

>>1028041

>That's because you have "muh minimalism" so far up your ass that you can't conceive that most of its configuration is meant to be done automatically by programs.

It's not. If you want to specify fallback, you must make user fonts.conf. You can't mix fonts of different sizes together too, even if you can with some custom Xfonts fallback mechanism (mainly because CJK fonts can be too big compared to their latin counterparts).

>>the only thing it lacks is a fallback mechanism.

>You are saying this as if it were a trivial issue.

It is. Look at how lemonbar does it.

>Besides, xft support adds very little complexity on the application's part. Font rendering itself (and fallback) is handled by fontconfig.

You don't know what you're talking about, do you? It's freetype (and optionally harfbuzz) that does the rendering, not fontconfig.

>Plus, Suckless has announced their intention to drop xft from dwm and dmenu, they have said nothing about st, which does support xft and will likely still continue in the future, as many people, even st users, do use xft fonts. We are not talking about terminals here.

Will probably follow.

>The thing is, this is not a discussion about whether to implement something or not. Such functionality *already exists* in dwm and dmenu. Dropping it offers zero benefits and creates needless complications. fontconfig is already available on nearly every Unix-like operating system. It would be like dropping X support because X is a mess (it is, but it's too widespread to be ignored).

That's because you're not a programmer that you can say that. Both these programs have a problem where xft shits itself when encountering coloured emojis with compatible fonts. And fontconfig is systemd tier in its disgustingness.

>Merely stating that something is shit won't make it go away. You have to offer something that can replace it, doing the same things at least, but better. Yes, xft and fontconfig have issues, but xfonts can't completely replace what they offer.

So except the fallback, what's missing?

>Meanwhile, Wayland is here, and Suckless fags still use X.

How do you make a simple program for Wayland? Where is libxcb/Xlib? Oh, you just have to use a bloated tookit or at least OpenGL/Vulkan with freeglut and co. Don't forget about a WM needing to reimplement half of X to work ("just use wlroots") or Wayland depending on logind and fontconfig.

Just kill yourself, faggot.


 No.1028251

>>1028210

>Oh, you just have to use a bloated tookit or at least OpenGL/Vulkan with freeglut and co.

If your standard for bloated is "I have to use graphics API", that's your issue.


 No.1028254

>>1028251

It means you must have a GPU or something like llvmpipe.


 No.1028264

>>1028210

>It's not. If you want to specify fallback, you must make user fonts.conf. You can't mix fonts of different sizes together too, even if you can with some custom Xfonts fallback mechanism (mainly because CJK fonts can be too big compared to their latin counterparts).

Yes, that's why you conveniently missed the point of automatic configuration done by other programs instead of doing it by hand, and started sperging about muh fonts.conf

>It is. Look at how lemonbar does it.

It's an unnecessary reinvention of the wheel on the application's part. It's easy, but not trivial.

>Will probably follow.

Likely not. Xft fonts are too widespread in terminal emulators, and there hasn't been any mention of it.

>You don't know what you're talking about, do you? It's freetype (and optionally harfbuzz) that does the rendering, not fontconfig.

My mistake for mixing the two, but once again, you conveniently avoided the central point, which is that the application itself doesn't need to worry about font rendering. It doesn't add a significant amount of complexity from the application's part.

>That's because you're not a programmer that you can say that. Both these programs have a problem where xft shits itself when encountering coloured emojis with compatible fonts.

It hasn't been the case in years. Removing such a feature offers zero advantages.

>And fontconfig is systemd tier in its disgustingness.

Not even comparable and you know it.

>So except the fallback, what's missing?

No scalable fonts, no antialiasing, no subpixel rendering, you name it. I get why you see all this stuff as "systemd tier" when you can't possibly conceive that there is more to fonts than just bitmaps.

<How do you make a simple program for Wayland? Where is libxcb/Xlib?

Not sure if retarded or just stupid.

<Oh, you just have to use a bloated tookit or at least OpenGL/Vulkan with freeglut and co.

Do you even know how much of a huge, convulted mess X is in comparison? And yet no one complains.

This is why "bloat" is such a meaningless term: autists merely cherry pick what they think is bloated and what isn't according to their arbitrary definition.

Sway+Wayland is an order of magnitude less "bloated" than dwm+Xorg. And no, it doesn't "reimplement half of X".

I'm all for leaner, more lightweight software, but not to the point where it becomes crippled and featureless. Take your head out of your ass and make something useful instead of something "minimal" for minimalism's sake.


 No.1028280

>>1028254

That's a perfectly reasonable assumption for a graphical interface.


 No.1028293

>>1028264

>Yes, that's why you conveniently missed the point of automatic configuration done by other programs instead of doing it by hand, and started sperging about muh fonts.conf

The UNIX philosophy states that an editable text file > an XML mess that can only be manipulated by tools for good reasons. If you want Windows, just get it.

>No scalable fonts, no antialiasing, no subpixel rendering, you name it.

This is what freetype (or more accurately truetype fonts) gives, not fontconfig.

>Do you even know how much of a huge, convulted mess X is in comparison? And yet no one complains.

This is a bad meme. X is indeed a mess but the rendering part of X isn't that bad (just use/keep DRI3 with KMS and you're done).

>This is why "bloat" is such a meaningless term: autists merely cherry pick what they think is bloated and what isn't according to their arbitrary definition.

Relativism is the worst rot your brain can get. Fix yourself.

>Sway+Wayland is an order of magnitude less "bloated" than dwm+Xorg.

That's arguable. Sway is bloated in philosophy, though (even more than i3). It implements screen grabbing, a hotkey daemon and wallpaper manager in one software; bspwc is more promising.

>And no, it doesn't "reimplement half of X".

Just look at wlroots. it does exactly that: talk to the kernel itself via DRM to make a compositor.

>I'm all for leaner, more lightweight software, but not to the point where it becomes crippled and featureless.

What is "crippled" if we follow your relativism? It seems you think I'm against truetype fonts, which I'm not.

>Take your head out of your ass and make something useful instead of something "minimal" for minimalism's sake.

I already make useful stuff for myself. Like most of suckless/cat-v/9front community does.

Honestly, you just look like you need to RTFM a few more years before swinging your dick here.


 No.1028296

>>1028280

I guess you're right. It's just that we lack a simple software renderer (no, llvmpipe isn't simple). Didn't look at swrast yet.


 No.1028301

>>1028293

>Relativism is the worst rot your brain can get. Fix yourself.

>proceeds arguing using completely relativist rethoric

Damn.


 No.1028305

>>1028301

What? Anyway, Xorg is utter shit, but so is Wayland. It doesn't care about portability (only care about Linux, depens on e?logind), doesn't provide anything to implement a compositor (wlroots was made from scratch) and is made by companies to use in IoT bullshit without caring about desktop at all.


 No.1028317

>>1028293

>The UNIX philosophy states that an editable text file > an XML mess

Anon, XML is text. It's just formatted and grouped with particular rules.

XML can be edited by hand without too much trouble, and its rules make it easy for external tools to parse it in a useful way.

Plan text is shit for config because there's too many details that can go wrong (escape chars, comments, whitespace rules...) and because it's harder for tools to handle intelligently.

>>1028296

>It's just that we lack a simple software renderer

Software renderers haven't aged well compared to the hardware side, now if you build a simple one it will be horribly inefficient and to make it more efficient you can't keep it simple.


 No.1028318

>>1028305

This reads so much like someone whose delusions about muh minimalism have just been destroyed that it's not even funny.


 No.1028866

File: 519c9e9e0047b2b⋯.jpg (345.78 KB, 1440x1080, 4:3, 16e47c356098159b2825335286….jpg)

>2019

>bloat is so bad it actually pedals technology backwards

>obviously a CIAnigger operation to make niggercattle buy new hardware by the billions every year

>minimalism fags start trying to fix it

>beyond retarded individuals try to drag down the idea of minimalism by claiming "hur dur you're not minimalist until your software doesn't work"

>others pop in pretending that's what people are advocating for to shill about how "wow that's stupid, let's just keep bloating"

It's pretty obvious it's the CIA reacting.

Don't give them (You)s, you jumbo dumbos.

But at the very least the shills ITT are not this guy:

04:24:58 < fajbern>   |   bloat is meaningless
04:25:09 < fajbern> | when your system has ample memory and even more ample swap it means
| nothing if there's a bunch of stuff you rarely use idling in the
| background
04:28:09 < fajbern> | not using memory is the very definition of throwing it away
04:28:28 < fajbern> | if spending 500 more megabytes of system memory is what it costs to
| not need to open up the terminal to use an USB pen drive then that's
| a good tradeoff
04:28:40 < fajbern> | plus shit that's completely inactive will get paged away anyway, so
| it won't even use memory
04:29:02 < fajbern> | and yes it is just memory that's being wasted, because "bloat" in
| the context of DEs is generally a bunch of idle processes that
| aren't doing anything and are thus consuming no CPU and some minimal
| amount of memory


 No.1028868

>>1028866

>copypasting weechat breaks

>try to fix it

>saame shit

nice


 No.1028887

>>1028868

just disable the stupid | thing or use the text mode


 No.1028947

>>1028317

>XML can be edited by hand without too much trouble, and its rules make it easy for external tools to parse it in a useful way.

Useful for crackers.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libxml2

>heap-based buffer over-read

>heap-based buffer over-read

>stack-based buffer overflow

>buffer overflow

>denial of service (buffer over-read) or information disclosure

>Buffer overflow in libxml2 allows remote attackers to execute arbitrary code

>remote XML entity inclusion

>allows remote attackers to cause a denial of service

>An integer overflow...allowed a remote attacker to potentially exploit heap corruption via a crafted XML file

>allows remote attackers to cause a denial of service (memory consumption)

>parser.c in libxml2 before 2.9.5 does not prevent infinite recursion in parameter entities

>parser.c in libxml2 before 2.9.5 mishandles parameter-entity references because the NEXTL macro calls the xmlParserHandlePEReference function in the case of a '%' character in a DTD name

>Use after free in libxml2 before 2.9.5...allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page

>remote code execution vulnerability

That's

JUST

2017 and

JUST

the bugs that were discovered and got a CVE. Let me anticipate some of your counterarguments.

<t-that's just one xml library!!!!

It's libxml2, arguably the world's most mature and widely-used XML library, and even with it being such a mature project and with so many eyes on it (including Google's) it's still full of bugs because handling XML is fucked.

<i-it's because it's written in a memory-unsafe language (C)!

Show me an XML library written in a "memory-safe language" that has equal (or better) functionality and performance as libxml2. If you can't, then write one, since

>XML can be edited by hand without too much trouble, and its rules make it easy for external tools to parse it in a useful way

You'd make a killing. And you should be able to do it. Because you said it's easy.


 No.1028949

>>1028947

>You'd make a killing.

... really?

who would pay for it?


 No.1029017

>>1028947

Maliciously crafted XML can be used to troll with things similar to decompression bombs, but that only means you shouldn't process random data without validation, which is something to keep in mind no matter which formats you work with.

Also, this is completely irrelevant since we are talking about locally stored and locally modified config files, which can be crafted and parsed with only a very limited subset of XML to reduce the potential for error even more.


 No.1029458

>>969096

This, but unironically.

Writing software using a language that requires a lot of LOC to do anything, then complaining that said software ends up having too many LOC is pants on head retarded.

That's why xmonad >> dwm, for instance.


 No.1029495

>>1028866

Minimalism has nothing to do with efficiency or bloat. Suckless "minimalism" is "pedaling technology backwards" even worse than JavaScript but the difference is that they think that's a good thing. Most software is bloated because of duplication and doing things the wrong way, not because there are too many real features (as opposed to "compatibility" nonfeatures like null-terminated strings). Software made by good programmers is much smaller, is done right, and has more features, which is the opposite of minimalist.

The problem is that it can't be compatible with weenie bullshit like C and UNIX because those would dwarf the size of the original project. Adding a UNIX "compatibility layer" to a good OS turns it into a slower UNIX with a couple extra megabytes of Right Thing code that nobody uses because they just program for UNIX/POSIX instead. That's one of the two reasons microkernel OSes failed in the 90s, the other being that they were written in C, which sucks. There was this paper about a Modula-2 OS that was basically just a runtime instead of a kernel because a memory safe language doesn't need all that complex bullshit and they decided to "add C and UNIX" for "compatibility" reasons. It ended up being UNIX with a Modula-2 runtime.

>>1028947

>buffer over-read

>An integer overflow...allowed a remote attacker

Those problems were solved by languages and hardware since the early 60s, probably even before that. There is no excuse to be using a PDP-11 hack that shits on the last 60 years of computer science and is too broken to fix.

><i-it's because it's written in a memory-unsafe language (C)!

That's absolutely correct. Any language with integer overflow checks and bounds checks would have prevented these bugs. They wouldn't have these problems if it was written in Ada, Algol, BASIC, PL/I, or pretty much any other language.

Why am I retraining myself in Ada?  Because since 1979 I
have been trying to write reliable code in C. (Definition:
reliable code never gives wrong answers without an explicit
apology.) Trying and failing. I have been frustrated to
the screaming point by trying to write code that could
survive (some) run-time errors in other people's code linked
with it. I'd look wistfully at BSD's three-argument signal
handlers, which at least offered the possibility of provide
hardware specific recovery code in #ifdefs, but grit my
teeth and struggle on having to write code that would work
in System V as well.

There are times when I feel that clocks are running faster
but the calendar is running backwards. My first serious
programming was done in Burroughs B6700 Extended Algol. I
got used to the idea that if the hardware can't give you the
right answer, it complains, and your ON OVERFLOW statement
has a chance to do something else. That saved my bacon more
than once.

When I met C, it was obviously pathetic compared with the
_real_ languages I'd used, but heck, it ran on a 16-bit
machine, and it was better than 'as'. When the VAX came
out, I was very pleased: "the interrupt on integer overflow
bit is _just_ what I want". Then I was very disappointed:
"the wretched C system _has_ a signal for integer overflow
but makes sure it never happens even when it ought to".


 No.1029527

>>1029495

>how will I convince the hip young /tech/ crowd this "suckless" thing sucks?

>I know

>I'll say it's worse than javascript and useless unlike my REAL programs in REAL languages

>also stuttertyping

>fucking stuttertyping

>that'll convince 'em

Fuck off, boomer.


 No.1029532

>>1029495

I don't care whether these posts are pastas/trolling or not, I 100% agree with them.


 No.1029540

>>1029495

>pedaling technology backwards

Exactly. That's why I use futuretech like Algol.


 No.1029653

>>1029458

"too many LOC" is always in reference to how many LOC it should take, which a minimal implementation would consume. If C required particularly many extra lines (tip: it doesn't), then that would be accounted for in the minimal and bloated versions.


 No.1029752

>>1029653

<it's not too many loc as long as it's c

At this point, why not just code everything in assembly? The end result would be even more "minimal" and lightweight at the cost of more LOC, but that's ok, because that's as many LOC as assembly needs to do the same stuff right?

Nah, fuck that shit.

The central point highlighted in the OP is that software whose codebase is too large is de facto very hard, if not impossible, to study, edit and customize to your preferences, therefore effectively making it de facto nonfree. Using a language which requires a lot of lines to do basic stuff directly contradicts this goal.

"Minimalism" in terms of resources is desirable, but it comes second.

"Minimalism" in terms of functionality is never desirable, and it's only a compromise to reduce the codebase.

Too many people ITT instead started arguing in favor of functionally deficient software, whose only merit is using little resources (still, not much less than other, more "bloated" alternatives), missing the actual goal, which is a small codebase.


 No.1029761

>>1029752

yeah lemme just use this high level abstract language that is also very efficient and you can easily write things like text editors with it.


 No.1029762

>>1029752

>"Minimalism" in terms of resources is desirable, but it comes second.

Depends on how many resources are used.

A clean codebase is nice, but not worth 1 GB of RAM for a text editor.


 No.1029770

>>1029752

C i still an HLL, with functions and macros. If it takes more loc then it's doing more than the equivalent lua or python version. Either those versions are delegating more work to libraries (whose loc isn't counted) than the c version or the c version is being more efficient with resources.


 No.1030144

>>1029770

>If it takes more loc then it's doing more than the equivalent lua or python version.

Imagine literally, unironically believing this. We are doomed.


 No.1030152

>>1030144

The only fundamental difference is gc vs manual memory managment, which also implies greater efficiency. Everything else is library support or syntax sugar. Prove me wrong nigger.


 No.1030154

>>1030152

Stop posting on this board right now and lurk for ten more years.


 No.1030201


 No.1030245

>>1030152

You're a god damn retard.


 No.1030276

>>1030245

Not an argument


 No.1030280

>>1030152

>The only fundamental difference is gc vs manual memory managment

There's a lot more to it. Are the faster GC languages only faster from library support and syntactic sugar?


 No.1030286

>>1030152

Either this is a bad bait, or you know next to nothing about computer science if you really think syntax is the only thing where programming languages differ. Inform yourself.


 No.1030289

>>1030280

So called faster languages are those that let you write faster code. They also let you write slow code. Simple example: write a c program using a static array, and a c++ version that uses a vector. The c program will be about twice as fast. Now replace the static array in the c program with a growable array. It slows down by about a factor of two. Slower languages are slower because of using excesively generic data structures and algortihms. Guess what? C can use generic algorithms and data structures as well, see eg qsort(3). This will reduce line count to comparable levels, and of course make the program similarly slow (not quite though, interpretation has a cost).

>>1030286

LISP and ML and prolog and brainfuck are all very different languages, with large LOC implications. But the only major differences between most c descended languages like python or java are syntax and virtual machine.


 No.1030291

>>1029527

gthumb and eye of gnome are literally as slow as JS over Tor. delete yourself


 No.1030292

>>1029770

most assemblers have macros that are more powerful than CPP

just another reason why C is retarded


 No.1030293

>>1030292

They're less portable though


 No.1030299

>>1030289

>But the only major differences between most c descended languages like python or java are syntax and virtual machine.

No one specified "C-descended languages" until you did right now. And still, those still have important semantic differences that go beyond merely having syntax differences or GC.

>Slower languages are slower because of using excesively generic data structures and algortihms. Guess what? C can use generic algorithms and data structures as well, see eg qsort(3).

qsort in particular is a horrible example, as C++'s std::sort is faster, more "high-level" and more general, without using void *, proving how repeated dereferencing is suboptimal, thus defeating the whole point of using C for "performance".

Void pointers are not even comparable to actual generic programming using a strict type system such as Haskell or ML's, not to mention a lot more error-prone. Yet another reason why C should never be used for safety-critical applications.

No, for any non-trivial piece of software, C will lead to many more lines of code than almost every other language. And let's not appeal to "performance": C++ and Fortran can both mop the floor with C when used properly, and often need less LOC overall.

(Notice how I specifically said *performance*, not safety or other concerns. In that case, neither of those languages are appropriate, especially C++).

Just because some languages need a capable runtime to work correctly (Lisp, Python...) doesn't mean they must, in principle be interpreted (see Lisp machines). Interpreters at the end of the day are simply emulating better, more capable hardware, which can actually execute code written in those languages. Do not confuse a language with its implementation.


 No.1030324

>>1030299

>No one specified "C-descended languages" until you did right now

I specified "lua or python" ten posts ago. Lisp or perl would probably beat any of the three, but it obviously isn't because of how high level the langauge is. Instead it's because perl for one has insanely specialized operators, and lisp lets you write insanely specialized macros. But the whole point is to make it easier for a someone else to edit your code, and using insanely specalized structures makes it difficult to understand and therefore start editing.


 No.1030326

>>1030299

>Notice how I specifically said *performance*, not safety or other concerns. In that case, neither of those languages are appropriate, especially C++

What would be a relatively safer language than any of those? Would Ada, Spark or Forth be any better?


 No.1030328


 No.1030567

>>1030299

Some languages, like C, are exactly like C. Hope I haven't blown your mind.


 No.1030759

>>1030567

Your point being?




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / fa / girltalk / gunt / lisperer / roze / tingles / v8 / xivlg ]