Care to expand on why this isn't usable?
Another classic example of the unix haters fag blaming common developer kludges on Unix. People lazily tacking on unfitting features instead of either making it fit or designing a new, better tool is an old problem predating Unix and even computing: kludges and niggerrigging have existed since the dawn of mankind and will continue until our extinction.
Much of modern plumbing is unnecessary, overengineered waste disposal which wastes valuable fertilizers. A mix of composting toilets, proper waste treatment plants, and smaller communities surrounded by farmland would be much more efficient in the long term.
Maximalism
Adam Collins
Andrew Cruz
Macfags get the fuck out of this board with your $1000 overheating craptops that don't have a cooling system that actually cools the components but instead just channels air into a separate section that somehow is supposed to cool the computer.
If your computer reaches 80c when playing banished you should throw it in the fucking garbage.
but you can't because you paid $1000 fucking dollary doos for it
Dylan Lopez
And what I said was that you just redefined what the thread is about in order to talk about Unix again. It's getting tiresome, really. Instead of further talking about the big design up front approach, you just rant about Unix.
That may or may not be, but the reason for you getting sidetracked is that you are unable to leave Unix out of the equation, no matter what the discussion is about.
Chromium and Electron are good examples of "unix" software? Have you read what I wrote about static linking? You disregard whatever is being said and just talk about again.
conductor we have a problem, conductor we have a problem
Levi Reyes
Because it doesn't work. Pipes need multiple processes and context switches to do what the same program on a good OS would do with a plain function call or memory access. It's not only slower, it requires programs to be split up in unnatural ways and needs all this extra code to serialize and copy data and read it back. Programmers have to do more work just to make things slower and less reliable. You can probably imagine how bad it would suck if every .o file had to be a separate executable in a separate process. That's why UNIX copied 20 year old (at the time) assembly technology. Combining multiple .o files into one program is done by the UNIX linker, which is based on the shitty "ar" tape archive format.
They are not common developer kludges, they are found only in UNIX. They might be common today, but that's only because of the spread of C and UNIX. It was the equivalent to Pajeet software, some cheap outsourced crap companies could license without having to hire good programmers. AT&T was able to get away with it because they didn't make the hardware. Blaming the PDP-11 or VAX hardware for UNIX software bugs didn't matter to AT&T.
For examples of big design up front, look at the design of Ada and Multics.
adahome.com
multicians.org
"Systemd, dbus, pulseaudio" are Linux software, and Linux is a clone of UNIX. "Of course written entirely in Javascript" is more UNIX bullshit because JavaScript is a UNIX language based on C and Java. You're giving examples of UNIX (technically "UNIX-like") bloatware, so how can I avoid blaming UNIX? The only non-UNIX software are that bulk file renamer and that ham radio program.
They're good examples of how the UNIX way doesn't scale to modern software, and yes, Chromium and Electron themselves are literally UNIX software. Chromium is based on WebKit from KDE. Electron combines Chromium with node.js, based on the Chromium V8 JavaScript engine.
Compare that to how it would be done on a normal GUI system like Lisp machines, Xerox Alto, pre-OS X Macs, and even Windows. There was software with embedded Internet Explorer since Windows 98, basically doing the same thing as Electron. Users never needed multiple copies of Internet Explorer bundled with each program. The UNIX way has been like this ever since each C program that used printf needed to bundle its own copy.
Suckless programs are small despite the redundancy because they don't do 90% of what users want. Compare them to real software that had real memory constraints like the old Macs, Lisp machines, and Xerox Alto. That was not 10% software, but they had far smaller programs and memory requirements than this suckless garbage.
Subject: why Unix sucksSome Andrew weenie, writing of Unix buffer-length bugs, says:> The big ones are grep(1) and sort(1). Their "silent> truncation" have introduced the most heinous of subtle bugs> in shell script database programs. Bugs that don't show up> until the system has been working perfectly for a long time,> and when they do show up, their only clue might be that some> inverted index doesn't have as many matches as were expected.Unix encourages, by egregious example, the mostirresponsible programming style imaginable. No errorchecking. No error messages. No conscience. If a studenthere turned in code like that, I'd flunk his ass.Unix software comes as close to real software as TeenageMutant Ninja Turtles comes to the classic Three Musketeers:a childish, vulgar, totally unsatisfying imitation.
Xavier Kelly
Yep, you're delusional. Kludges have existed outside computing for millennia yet according to you compsci was somehow immune to this common human trend before those dastardly weenies and AT&T (which was bad unlike the other wise corporations and universities) discovered the kludge and magically convinced everyone else to do it too.
If we play the "based on" game, all this leads back to Multics.
JavaScript is a Multics language.
Chromium and Electron can trace their roots back to Multics.
Systemd, dbus, and pulseaudio are all Multics software too.
Nevermind that many of these took great influence from Microsoft Windows (itself based off OpenVMS) and how all these examples of bloat are from software and OSes deviating from their source's design philosophy. According to you, anything bad in software comes from Unix and its philosophy so you refuse to consider how other operating systems and impure design could also have a negative impact.
t. someone who's never used it
That is a compiler issue. Older compilers often optimized more for memory use than speed and running Suckless.org software through them would probably produce even smaller binaries, especially the non-X11 programs.
As for static linking, it isn't nearly as redundant as people think because statically linking a library or program doesn't include the entire thing, only the components the program actually uses. Shit like Electron is a bad example because it bundles an entire browser with your program whether you need its functionality or not (you never do), not to mention how the most commonly libc, glibc, intentionally nerfs static linking anyways. glibc ensures static linking is rarely used outside niche musl distros.
Static linking is not ideal compared to Multics' dynamic linking. It is, however, superior to Unix's godawful take on dynamic linking for everything except proprietary software.