but i mean, they suck ass. slock for example had a bug where it would display the contents of your screen while locked. now without changing compile options it does this dumbass bullshit where it turns your screen red if someone types the wrong password
What went wrong?
You know, one of the major points of suckless is that it's simple enough to be understood and modified really fast. So take your fingers out of you asshole and do something instead of whining.
Not to sound like a commie scum, but capitalism is the reason.
A big company hiring 700 pajeets can make a much fancier program much faster than an even competent individual can. And when that's all done, they can fire those pajeets and keep selling their monopolized software forever while keeping a handful of devs to add stupid features so they can justify selling the software again every couple years.
Normies don't give a fuck and will buy into it anyway even if it's bloated and slow and has 60 layers of botnet and doesn't do anything more useful than the previous version did, as long as it beeps happily when clicked on and has whatever trendy visuals that the king kike told them to prefer, and is 0 IQ-tier retardproof.
Meanwhile real software is unprofitable and risky so it can't support any developers other than autists who do it for free, and autists aren't known for their ability to make things user friendly or pretty, not to mention many of those autists are even worse than the pajeets that were hired by that big company.
oh yeah i'm just gonna go deep in X11 API and fix their screen revealing bug. the point is that the software sucks, not that it's easy to fix. really anything to do with the terminal is also garbage for fundamental reasons (metacharacter injection, etc). we can't just modify some terminal programs to fix this.
this
First off, you don't see the crap, since everyone has quick to forgot the unsuccessful and unimpressive (unless it was exceptionally terrible). It's the same reason why a "best hits" of a decade of music will almost always sound better than the Top 40.
You are right about people making do with limited resources. Though I will have to argue that
ignores the fact that even well-optimized programs of the past would require almost all the memory/cpu of a system. It's not like early 3D renderers and image editors ran silky-smooth on a standard machine of the day, or that highly-optimized games like Star Fox or Kirby's Adventure didn't suffer FPS drop on the native consoles.
The several reasons for this behavior, off the top of my head:
•Necessity
On hardware with very immediate resource limits, limited (cheap) input/output expansion, and a basic OS which did not provide a convenient, failsafe framework, egregiously sloppy code would simply fail. If you did not perform proper hardware resource allocation in your code, from memory reclamation to a consistent and manageable runtime, your program would fail on its own in short order. There were still newbies in those days who would write sloppy code, but the bar for "acceptably sloppy" was significantly higher in order for the programs to even run.
•Simplicity
Because the hardware had these limited resources, on hardware which an engineer could digest with much greater ease than the hardware of today, the pathways and limits of optimization were more readily apparent. And by being less aware of faults, creative developers could more effectively utilize hardware in unorthodox ways to achieve certain results, such as you see in demoscene. In the modern world of APIs and developer libraries, byzantine kernel drivers, and advanced, opaque firmware on individual hardware, the amount of deviance permitted for such hacks is lowered, unless one works around those standards as well.
If highly-optimized software software is absolutely required to perform a certain profitable function, it will be made (if proprietary). It is just the case that this is increasingly an edge case, especially when computation and rendering have become distributed and cheap.
The FreeBSD and Linux kernels and their userlands have both received plenty of corporate developer contributions that improve hardware support, performance, and features, as those corporations are direct beneficiaries of those improvements. High-quality open codecs like, Opus and AV1, and the software used to deal with these codecs, like ffmpeg, are also developed by multimedia corporations without direct profit, so that they can facilitate and standardize future development. And corporations increasingly tend to release the source code for certain in-house tools online, to facilitate development and possibly adoption. All this is coming from someone who has an axe to grind against corporate influence.
It seems to me that when techies harp on about "real" software, they are more concerned with the philosophy and aesthetics of use (practical vs. entertainment, minimalist vs. embellished, etc.) , rather than the value produced for oneself, or society from using said software.
I'm not sure about you, but as a user, I'd rather have my programs crash on an unhandled error, rather than taking down my whole system and compromising it permanently. C simply doesn't provide me with that safety.
Sure, your C is perfect because you are not le epick pajeet meem and you are a perfect programmer, and you don't even need to debug or write tests because you write code without errors 100% of the time, but sadly, you are the only programmer in the world capable of doing this, and you are too much of a NEET to bother writing a secure operating system all by yourself, with all the necessary tools for day to day use, so we will have to rely on C software written by pajeets and other non-Indian pajeets, so we (including you) are fucked.
No, most certainly not, unless we are talking about really tight loops, which anyways should be as simple as possible. Checks are what have turned personal computers into machines that are pleasant to use rather than "hey, reboot it" simulators. You fucks really have a short attention span if you don't remember the frustrations of using a computer in the early late 90s and early 2000s, with constant random crashes. We have advanced a fucking lot, and it hasn't been thanks to people like you complaining about the size of your programs not being measured in bytes.
No, programs are bloated and slow because programs nowadays depend on a thousand libraries, libraries they don't actually need. Libraries we wouldn't really need if languages included a sane set of tools in their standard libraries, but it seems we are either C levels of autistic reinventing the wheel, or Java levels of bloat. But who cares: need a simple hashmap? Sure, just include Qt or Boost, who will in turn make sure they include the entirety of their libraries because everything depends on everything else, then make the user download the whole library anyway just in case.
At work we are forced to copypaste stuff because Agile development or whatever, rather than designing a general solution for each non-specific task. As a result, we end up with files with tens of thousands of LoC, just because at the moment was faster and cheaper to do it this way. We are also forced not to linebreak statements, so we end up with lines that take up a whole panoramic screen to display and still need a scrollbar to see it whole, so you can imagine how much of a pain in the ass this is to maintain. They also determined higher level constructs such high order functions or closures were either too bloated or too difficult to understand that we are pretty much forbidden from using them, so we end up with 100 lines long switches and globals up the ass. They also determined dictionaries were too complicated, so we end up making linear searches over the same array over and over inside loops. But hey, it is simple to read, everything is adapted to work for their usecase and their usecase alone, and we just use the same three or four types for everything so it must not be bloated, right? :^) We also use 0 external libraries because we have a strong NIH syndrome at the office, which I can say is the only good idea we ever had. I just wish we bothered expanding it so we could boost our productivity by generalizing all the stuff we have to write by hand every single day
Actually it does. C programmers prefer for things to crash. Its modern features that allow to wrap everything in try catch lazily and act as if you have an elegant solution.
So it turns out Terry Davis was only halfway right when he said that. They went wrong when it became possible to make them usable by and sell them to niggers. Now people have become accustomed to supercomputer levels of power and take everything for granted. Hardware should have never progressed past the 80's. The average person should only be able to afford something like a 1-meg Amiga 500 with second floppy drive, or a 386SX wth 2 MB RAM, 40 MB HD, and the most basic of VGA and Soundblaster cards. Throw in a modem (9600 baud) and a 24-pin dot matrix printer, and that's all the hardware you get for the rest of your life. You don't like that? Tough noogies.
No, it's not that at all. People here talk about segfaulting all the time when talking about C memory unsafety, but segfaults by themselves are actually benign. Crashes are only benign until someone decides to take advantage of them and not quite crash the program, in which case you are fucked.
insecure.org
Protip: most people who use C and think C is the best language ever because it's the only thing they have learned in college, and then end up working in systems programming (the only job for real programmers such as ourselves), don't tend to know about this