Unix hate thread

Murdered*

fork() exec() instead of a proper syscall to just launch a new program.
fork is so FUCKING slow and it's always been. Copy on write helped, but not nearly enough.
Also, having many small syscalls was bad design, since that leads to more context switches.

Would you rather have one big syscall that does fucking everything? How would that even work?

>Also, having many small syscalls was bad design
Yeah, better have syscall like INT_T WinSysCall( param, NULL, NULL, NULL, 5, NULL, NULL, NULL, NULL)

Everybody knows tehát you fuking mongol, now explain us, why are they saved directly to home instead of a subfolder.

*sbin

not using fsync() on config files
command line has merged input line with output area
cryptic names to turn short and easy to memorize
all sorts of string expansion bugs, regularly need to escape it three times
all sorts of weird quirks such as leap seconds in epoch time or all sorts of weird shit in locales
issues adopting 64 bit or more for time representation even though 128 bits TAI64NA exists
fork+threads+signals+nonblocking IO mess
fork in particular is a fucking trash of a design

>leaving config files under the home directory
dotfiles aren't a unix thing.
dotfiles were a bug that happened because they didn't want '.' in the output of ls, but Ken initially just checked if the first char of the filename was '.', so by accident ls didn't show any files starting with '.' and other people started abusing it.
also, note that none of the unix utilities like grep even require any configuration.

shell does

this.
move .*rc files into a unified config file and don't make them hidden

Like a registry?

what's that?

A database to shit into.

sure.

what is the flaw of using posix_spawn() instead?

I agree, UNIX is shit.
Sadly there is no sane extant alternative.

Haiku

You know you can change that if you use a distribution like Arch right?

>Haiku
All the flaws of UNIX with no benefits.

I won't recompile every possible shit which allows itself to write in my home. It shouldn't allowed from day-1. Linux is not shit, just disgusting.

>Not using Linux is not beneficial.

You are better off using Open BSD if that is your motivation.

reword this

Linux developers are disgusting.

docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

posix_spawn works pretty much the same way - and as a result, is like 200x faster than fork-exec.

files and folders

There is no posix_spawn syscall on linux, retard.

threads and processes

C, by extension C++

This. C is one of the worst things that came out of the entire industry.

so is lisp and emacs
and vi and vim
it's all ancient shit

it's like being proud of being in a carriage with a horses ass staring you in the face

>OLD IS BAD

Attached: okkid.jpg (431x450, 37K)

Lisp is a good thing and overlooking functional programming for several decades was another major mistake that the industry made. Instead we got piles of legacy C written by arrogant retards who thought they could micromanage memory and not fuck it up.

they're both shit!

Not really.
Wait, did you fail CS 101 or something?

This. A lot of software nowadays isn't retarded and does follow this standard, but not enough.

It took way, way, way too fucking long for posix_spawn to become adopted.

Support. Only fairly recent libc implementations have it.

The implementation in glibc is basically vfork-exec.

A+

*blocks your gigs of hd space*

Attached: GlDnb.png (1254x749, 280K)

you seriously think that's good design?

#include
#include
#include

void _tmain( int argc, TCHAR *argv[] )
{
STARTUPINFO si;
PROCESS_INFORMATION pi;

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );

if( argc != 2 )
{
printf("Usage: %s [cmdline]\n", argv[0]);
return;
}

// Start the child process.
if( !CreateProcess( NULL, // No module name (use command line)
argv[1], // Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
0, // No creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&si, // Pointer to STARTUPINFO structure
&pi ) // Pointer to PROCESS_INFORMATION structure
)
{
printf( "CreateProcess failed (%d).\n", GetLastError() );
return;
}

// Wait until child process exits.
WaitForSingleObject( pi.hProcess, INFINITE );

// Close process and thread handles.
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
}

xdg directory spec is undeniably sick

You mean like ioctl?

That's funny cuz I just looked in my .config folder, and there's no dotfiles in there. None. Not a single fucking one. And oh btw .config starts with a dot.

ioctl isn't POSIX, and only multiplexes many small syscalls. Not what he wants.

.vimrc: symbolic link to .config/vim/init.vim
(idea stolen from neovim, shouldn't be neccesary in the first place, I agree)

One syscall that does everything would have to be like ioctl. Otherwise, how would it know which thing you wanted to do?

shitty documentation is POSIX compliant

One of the worst things is the filesystem hierarchy.
The entire reason it exists is because they literally ran out of disk space, every explanation of how it works (including man hier) is just a rationalization after the fact.
lists.busybox.net/pipermail/busybox/2010-December/074114.html

Attached: reading1.jpg (600x510, 480K)

waitpid
signals
EINTR
fork
Pretty much entire posix is accidental design, yet vfork was such a shitshow even posix retards deprecated it.

Whether you want to admit it or not, one if the main reasons Unix sucks is C, and the whole reason the shell and pipes exist in the first place.
It quickly became obvious that C is an exceptionally bad language for scripting and automation, so they needed a different language for that. But now, being separate, it could no longer directly share structured data with the rest of the code, so they had to output bare text to the rest of the system, and take text ad input, linking separate processes with "pipes".
They then went out and justified this by claiming text is a "universal interface" when every non-trivial usage consists of tearing output open with awk, sed and other shitty tools.
Apparently, serializing and de-serializing data, parsing it again at every process, is simpler and more "Unix philosophy-ish" than just reusing data and functions directly.
This highlights why the Unix philosophy is bad: by focusing so much on the individual parts, the whole suffers. They focus on making individual programs "do one thing and one thing well" while completely overlooking interaction and combination. And during actual usage, it's the whole that matters, nobody cares whether a single program does "one thing" at that point.

Attached: eggnic.jpg (977x841, 40K)

Why it can't specify working directory?

Yes. lrn2abstraction

All syscalls work that way: there's only one syscall in processor. They are just not standardized.

UNIX no longer exists in any meaningful sense

This.

unix sockets, abstracting devices as files, not searching for libraries in the same folder as the executable, commands with 500 different options that no ones gives a fuck about, being forced to use vi and grep

but most of all i hate the file hierarchy. windows file hierarchy is probably 2X better and even that sucks nigger dick

Attached: CJ.jpg (200x283, 21K)

Bro there are libraries in *nixes. There is code reuse. The Shell is user facing so it makes sense that text is the interface.
Processes are separate instances of unique programs, every variable they need access to can be piped during runtime, read from a file, inputted by a user, or accessed from the set of environment variables
gnu.org/software/libc/manual/html_node/Environment-Access.html

Attached: there-are-no-solutions-there-are-only-trade-offs-thomas-sowell-20076941.png (500x396, 82K)

The problem with keeping your programs simple is that it pushes the complexity on to your users, if you know how much reading it takes to use programs like sed and awk you'd realize this

Just use Perl

sed and awk are not simple, things like cut and unexpand are

Attached: 1557027157927.jpg (400x320, 28K)

You're missing the point, a better example would be suckless programs, instead of dealing with the complexity of parsing config files they opted to keep things simple by having their users recompile the programs instead, so now instead of simply manipulating text files you're required to keep a full blown C toolchain on your system, the complexity is on you as a user

this is basically saying that you think processes with separate address space is a bad idea

>leaving config files under the home directory
are you stupid? just move them to /etc if you have autism and don't like configfile at your $HOME

>you're required to keep a full blown C toolchain on your system, the complexity is on you as a user
Suckless programs are just super autistic about resource usage, I prefer GNU stuff over them and bsdutils due to ease of use. However the point of the Unix philosophy is to encourage a modular approach which the coreutils do just fine despite their bloat, LOC matters way less.

man pages

>abstracting devices as files
how is that bad? just write your drivers to be POSIX compliant, you mong

>he doesn't know about ~/.config.d/

Attached: wrong.jpg (250x250, 12K)

Does anyone do it better?

>abstracting devices as files,
yeah, i love rebooting windows just to install an update. i especially can't live without that feature when i just want to quickly reboot the computer (after installing some important software) but it insists on installing 97 updates i couldn't give a hoot about

many other good ideas in history have been happy accidents

>while completely overlooking interaction and combination
are you an idiot or just blind? the whole point of unix utilities is that they are composable

More like compostable.

>Just move your Settings, they totally wont recreate it after the first run.
You know, I do packaging for an os, where no dotfiles and folders allowed directly under Home. I KNOW well, how time consuming to explain to every fucking program to just not fucking doing this.
>Just pass the config folder location to the configure script
Nowhere used in the code, it is just messing with $HOME + “/.fuckingdisasterrc
But thanks for the idea.

Haiku

Ah, now that my jolly friend, is a jest that diddles my humor!

>Everything is a file
>Not using a registry and APIs to regulate how the system is modified so you don't get retards accidentally destroying the whole system

how about the third option
>don't be a retard
or the fourth option
>if you are a retard, just stay out

Those options don't exist for 99.9% of users.

>implying we want 99.9% of users

i don't know what either of your replies have to do with anything.

Attached: stupid.png (774x842, 45K)

Well then it's horses for courses because 99.9% don't use Linux or any other unix-likes, largely because they're known to get broken for seemingly no fucking reason.

Works on my machine™

do you even know what those tty's do? probably not because you're too busy sucking dick to educate yourself for ten seconds

i have a process manager why would i care nerd

because you might want do write a program that does something more than just stop/start processes, fag

i have an IDE why would i care, nerd? and besides that im pretty sure i could still make it simpler, just in case you decide to hound me for not using I3 and terminals for everything like a fag lol

This desu
Don't shit up my home dir

suckless shit is actively retarded
actively retarded

basically this

you end up with similar issues anyway and you're just moving your issues to a less visible place for an optimization that largely doesn't matter
also, I've never really had to munge anything with sed, ever

you sound like the biggest gay fag

the windows registry (well, registry systems in general) is famous for being a fragile piece of shit

the windows registry would be 100x better than flat text files in every way IF microsoft and other gay autistic developers didn't abuse and obliterate the hierarchy with bad naming, checksums and other pointless garbage nobody cares about.

>Haiku's filesystem layout is quite transparent, trying to always use non-cryptic names for files and folders, that don't leave the user guessing. Files and folders that are important for the system to function properly, are protected from accidental tempering by showing one of these alerts:
I already like what I'm reading.

I agree, however I think this is more implementation faults than conceptual faults.
The fact that it's listed in the filesystem seems fine to me, the fact that it acts like a file, is not.
I feel like you can have it listed in the filesystem, and still have a better API to control it, is possible. Almost like in 9P.