/tech/ - Technology★

>>>/g/ o and don't return.

Oof. Microsoft really slammed those braindamaged weenies. Some highlights:

>Fork is no longer simple. Fork’s semantics have infected the design of each new API that creates process state. The POSIX specification now lists 25 special cases in how the parent’s state is copied to the child.

>Fork doesn’t compose. Because fork duplicates an entire address space, it is a poor fit for OS abstractions implemented in user-mode. Buffered IO is a classic example: a user must explicitly flush IO prior to fork, lest output be duplicated.

>Fork isn’t thread-safe. Unix processes today support threads, but a child created by fork has only a single thread(a copy of the calling thread). Unless the parent serialises fork with respect to its other threads, the child address space may end up as an inconsistent snapshot of the parent. A simple but common case is one thread doing memory allocation and holding a heap lock, while another thread forks. Any attempt to allocate memory in the child (and thus acquire the same lock) will immediately deadlock waiting for an unlock operation that will never happen.

>Fork is insecure. By default, a forked child inherits everything from its parent, and the programmer is responsible for explicitly removing state that the child does not need by: closing file descriptors (or marking them as close-on-exec), scrubbing secrets from memory, isolating namespaces using unshare(), etc.

>Fork is slow. In the decades since Thompson first implemented fork, memory size and relative access cost have grown continuously. Even by 1979 (when the third BSD Unix introduced vfork()) fork was seen as a performance problem, and only copy-on-write techniques kept its performance acceptable. [...] Fork is now such a performance liability that C libraries carefully avoid its use in posix_spawn(), and Solaris implements spawn as a native system call.

>Fork doesn’t scale. In Linux, the memory management operations needed to setup fork’s copy-on-write mappings are known to hurt scalability, but the true problem lies deeper: as Clements et al. observed, the mere specification of the fork API introduces a bottleneck, because(unlike spawn) it fails to commute with other operations on the process.

>Fork encourages memory overcommit. The implementer of fork faces a difficult choice when accounting for memory used by copy-on-write page mappings. Each such page represents a potential allocation---if any copy of the page is modified, a new page of physical memory will be needed to resolve the page fault. A conservative implementation therefore fails the fork call unless there is sufficient backing store to satisfy all potential copy-on-write faults. [...] An alternative approach, and the default on Linux, is to overcommitvirtual memory: operations that establish virtual address mappings, which includes fork’s copy-on-write clone of an address space, succeed immediately regardless of whether sufficient backing store exists. A subsequent pagefault (e.g. a write to a forked page) can fail to allocate required memory, invoking the heuristic-based “out-of-memory killer”to terminate processes and free up memory.

>Summary: Fork today is a convenient API for a single-threaded process with a small memory footprint and simple memory layout that requires fine-grained control over the execution environment of its children but does not need to be strongly isolated from them. In other words, a shell. It’s no surprise that the Unix shell was the first program to fork, nor that defenders of fork point to shells as the prime example of its elegance. However, most modern programs are not shells. Is it still a good idea to optimise the OS API for the shell’s convenience?

>>1050833

sage negated :^)

>>1050833

Angry to see a post about tech and not about da joos?

Embrace, extend, extinguish

>>1050839

Go back home to your goyfriend.

>>1050847

Come the fuck on, it's just about replacing a shitty low level hack made before multithreading was ubiquitous.

>>1050839

>Angry to see a post about tech and not about da joos?

No. It's because this is the typical ni/g/ger tier "hurr durr use Windo$3 goyz" shilling thread that your kind keep making since you arrived, and started shitting up the catalog.

"Microsoft BTFO UNIX weenies" <--- seriously? You think this is /tech/ ? You're too newfag to know what /tech/ is, and confusing it with >>>/g/ hence why I gave you a link to >>>/g/ o and not return.

>>1050851

>this is the typical ni/g/ger tier "hurr durr use Windo$3 goyz" shilling thread

Weak damage control. This thread is not about Windows, it's about the retardation that is UNIX.

>You're too newfag to know what /tech/ is,

Sorry kiddo, but I have been on /tech/ almost as long as it exists. I know what /tech/ is. It is a shithole full of LARPers and you are one of those LARPers (probably fresh from /g/ too).

>>1050837

Those are the disadvantages. Let's list the advantages:

>When Unix was rewritten for the PDP-11 (with memory translation hardware permitting multiple processes to re-main resident), copying the process’s entire memory only to immediately discard it in exec was already, arguably, in-efficient.

>Fork was simple. As well as being easy to implement, fork simplified the Unix API. Most obviously, fork needs no arguments, because it provides a simple default for all the state of a new process: inherit it from the parent.

>Fork eased concurrency. In the days before threads or asynchronous IO, fork without exec provided an effective form of concurrency. In the days before shared libraries,it enabled a simple form of code reuse. A program could initialise, parse its configuration files, and then fork multiple copies of itself that ran either different functions from the same binary or processed different inputs.

So the _only_ "advantage" that fork has is that it is "simple". Simple as in "UNIX simple", not "actually simple" btw.

>>1050839

Get in the >>>/oven/ Winkike

t. /pol/

>>1050855

>it's about the retardation that is UNIX

>UNIX = retarded

>It is a shithole full of LARPers

>and you are one of those LARPers

No. We are definitely not the same.

>>1050855

> This thread is about the retardation that is UNIX.

$ cat your_opinion > /dev/null

>>1050833

>>1050848

>>1050851

>>1050858

(You) didn't even read the post. Not everything microsoft does is bad. They seem to have a point, if you can't see that, you're just stupid.

I'm not defending Microsoft nor Windows here, I have Richard Stallman and free software in my heart.

>>1050855

>Sorry kiddo, but I have been on /tech/ almost as long as it exists. I know what /tech/ is. It is a shithole full of LARPers and you are one of those LARPers (probably fresh from /g/ too).

Unfortunately this. The first time I came here there was RMS on the sticky and it seemd to be a great place, but then there were only

>CoCks

>Jews

>nigga

>windows

Nothing about real tech. Did something happen, or I just was lucky enough to come here, when there were no so maly LARPers?

>>1050860

>LARPing

>>1050861

>cat

UNIX braindamage

>/dev/null

UNIX braindamage

>>1050860

Lol what a Unix weenie.

You belive in Unix without any doubt, like it was your religion. The truth is Unix isn't perfect. There are cool things about it, like for example minimalistic programs working together, but things like /bin/, /usr/bin, /usr/local/bin, or that everything is a file are retarded - especially the first one. Nothing is perfect, if you can't stand constructive criticism, it means you don't even know why do you love Unix so much.

Not retarded people use criticism to improve themselves and their work.

Example:

https://www.gnu.org/software/hurd/hurd/critique.html

>>1050864

>The truth is Unix isn't perfect

No shit. If this was the argument then fair play, but that is not the OPs claim. OP was postulating facile arguments of "Unix BTFO" and directly implying "Unix = retardation", which is objectively nonsense.

>>1050867

>Unix = retardation

>objectively nonsense

This is stage 3 braindamage. Most likely terminal.

>>1050833

He's right you know.

A lot of old unix was just hacks, this is why it's important to fix issues like this.

That being said, it just werks

>>1050863

>>1050864

What i don't understand about all this is why this aggressive and vitriol filled based posting? The paper seems fine but we come to a conclusion that yes, design of software was tied to the design of hardware and its limitations. And while the hardware changed, software opted out to be backwards compatible with many of its flaws/design decisions. So what do we do about it? Shitpost at each other? Are you or is anyone else gonna rewrite the GNU tools or the Linux kernel?

This is a tough problem and it requires discussion and probably wouldn't be solved without some major work put in by the very same tech giants that opted to continue the backwards compatibility/hack to make it work trend. You put the example of HURD there as a project that takes criticism seriously but is anyone using that kernel? Might be viable as a hobby project but not actually usable. I'm not saying HURD is bad or anything. My point is with such an offputing OP and posting style nothing is achieved. The fact is that lot of people here aren't really technically adept to talk about such stuff myself included. People who know their shit probably would be dissuaded from posting when seeing threads like this or those in the catalog. Just endless shitposting about minute stuff and badly formed OPs that seem more like opinionated rants rather than a call to discussion. You wanted a discussion right? Or just to call someone an UNIX weenie or whatever.

>>1050872

This trend of perpetuating 'hacks' has been happening for centuries.

e.g. with Roman roads > railway gauges > modern highways

and it will continue into quantum computing in the future.

>>1050872

Ok you're right, but the guy that didn't even read the post started.

And it is sometimes funny to call someone, who blindly glorifies Unix a weenie. Sorry for that, my perversion.

The Hurd was just an example. If someone is serious about their work, project, etc. they will accept criticism.

>>1050873

>>1050879

What's with all the saging?

sages negated

>>1050872

protip: GNU Hurd was never designed to be a kernel program. The Hurd is a multi-server platform.

>>1050879

Yeah some of the namecalling is expected here i agree. But i guess i just see more and more threads that just devolve into that rather than discussing the topic. Im glad you aren't purposefully starting shit. Its just the topic at hand seems really complex to me. What actual answer could one give to the current state of software and improvement of the same? Seems that most answers gravitate towards a clean slate approach which comes with many of its of difficulties, especially (in my opinion) drivers, which are their own tale of complexity/difficulty of integration.

>>1050882

Now this is interesting. From a shallow understanding and looking at their site "Our mission is to create a general-purpose kernel suitable for the GNU operating system, which is viable for everyday use, and gives users and programs as much control over their computing environment as possible". So would you know more about it?

>>1050882

>protip: GNU Hurd was never designed to be a kernel program. The Hurd is a multi-server platform.

<The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux).

And what's wrong with that? Not all kernels have to be monolithic.

>>1050851

>"hurr durr use Windo$3 goyz"

I'm not sure where you are getting the idea of using windows from.

>>1050851

The title is stupid, I agree on that, but the OP is still a much better contribution than half of the stuff in the catalog, and infinitely better than the rampant stormfaggotry.

>>1050858

>creating boards to make "witty" comments

Peak reddit.

>>1050894

> Not knowing that >>>/oven/ has existed since 8/pol/ exists

Peak reddit.

>>1050862

> Not getting chan culture

Newfags

>>1050910

>Summary: Fork today is a convenient API for a single-threaded process with a small memory footprint and simple memory layout that requires fine-grained control over the execution environment of its children but does not need to be strongly isolated from them. In other words, a shell. It’s no surprise that the Unix shell was the first program to fork, nor that defenders of fork point to shells as the prime example of its elegance. However, most modern programs are not shells. Is it still a good idea to optimise the OS API for the shell’s convenience?

man 2 clone

>Fork encourages memory overcommit.

HOLY SHIT FINALLY SOMEBODY NOTICES THIS FUCKERY.

Memory overcommitting is batshit insane (it makes it impossible to handle OOM conditions), so I disabled it on my box. Cue bulky programs like shitfox being unable to spawn subprocesses because of the fork idiocy. I thought I was the only sane person left on the planet.

>>1050898

> Not getting chan culture

>culture

You mean not being able to read the fucking post or shitposting?

>>1050930

based

>fork()

What is a thread?

Now fuck off, back to >>>/g/ !

>>1050939

?

>>1050839

No. I'm angry because this shit thread is about shitposting and NOT tech.

>>1050946

sage negated

>>1050821 (OP)

EMBRACE (Linux foundation)

EXTENDED (PowerShell on Linux)

I wonder what comes next

UNIX fork is another example of something that was known to be bad for almost 50 years but weenies still won't do anything about it, just like array decay, null-terminated strings, parsing hardcoded text error messages, having hundreds of copies of the same code on a computer, and the rest of that bullshit. In the 60s, it was common for multiple tasks to share one address space or share segments. What really sucks is that weenies ignore decades of good designs before and after UNIX just because they're not like UNIX.

>Ritchie also noted that a combined Unix fork-exec “would have been considerably more complicated,if only because exec as such did not exist; its function was already performed, using explicit IO, by the shell.”

That quote is so brain damaged that I can't even believe it. The only way this would make sense is if they were intentionally making something that sucks. That article about UNIX and C being a hoax comes to mind here.

>While it is hard to quantify the cost of implementing fork on existing systems, there is clear evidence that supporting fork limits changes in OS architecture, and restricts the ability of OSes to adapt with hardware evolution.Fork is incompatible with a single address space.Many modern contexts restrict execution to a single address space, including picoprocesses [42], unikernels [53], and en-claves [14]. Despite the fact that a much larger community of OS researchers work with and on Unix systems, researchers working with systems not based on fork have had a much easier time adapting them to these environments.

Not only this, but it's also incompatible with segmented memory. Fork holds back systems research, but it also holds back hardware.

Ever notice how most unices, the ones that don't use MMDF,
often send you half-complete messages? Ever wonder where all
those lost bits GO??

But the point of this is that it really hasn't got much to
do with MMDF, it has to do with unix itself. The problem,
see, is that the machine you mention, MC, is only a poor
little Microvax 3, with probably only 16Mb of memory. Which,
you would think, would be perfectly adequate to run a mailer
and a filesystem.  And it would have been, too, except that
the nice helpful people who brought you unix invented this
thing called the "fork", which they then proceeded to stick
- um, sorry, about to get a little carried away, there.

But anyway, see, by employing the great unix principle of
"composable functionality", they were able to determine that
even though 99.9997 percent of the time you create a new
process you are -going to use it to run a new program-, it
would be a Good Thing to separate the notion of creating a
new process from the notion of stuffing the new program you
wanted to run into its address space.

Now, if you were going to do that, you might at least think
that you could arrange some kludge to optimize the common
case.(1) But no, that would be -messy-, and unix is not
-messy-. So, kids, the way we run a program here is to use
is the "fork" system call, which takes a running program,
makes a new process, and -copies (and I mean -copies-, as in
moves bits around on the disk), the entire address space of
the old program into the new one-, followed, 99.9997 percent
of the time, by the "exec" system call, which takes the
newly copied bits and -instantaneously throws them all
away-.

And that's why MMDF is slow.

(1) And you bloody well could, too, if you were from
California.  Just forget about that for now, OK?

>>1051016

What exactly would the "extinguish" part even be in this context? Is Microsoft going to straight up replace the Linux kernel entirely with NT? How is that even going to work?

>>1050821 (OP)

Why should I care about a paper that is biased in its abstract? It's obviously not partial to the conclusion as whoever wrote it was already manipulating the data to fit the contrived view.

>this thread

>only reference to posix_spawn is in a quote

if you're forking just to exec, then use posix_spawn instead.

if you're forking for concurrency purposes, then use threads instead

if you're forking so that you can create amusing heisenbugs that people will spend months digging into, then fork from a multithreaded application and do some work with process-wide data structures before execing.

>Muh GNU Hurr

>Muh Mike Rowe Kernel

>Hurr durr!!!

>LMAO I wuv mike rowe kernelz

Fuck off

>>1051086

>implying windows is popular because people think it's technically superior

It's inertia and OEM pressure, what Microsoft Research (who like most research divisions have next to nothing to do with the corporation anyway) says about Unix is completely irrelevant to Windows' success.

>>1051112

I doubt these people are reading papers on OS research though.

>>1051033

based

>>1051037

Are you retarded? fork is absolutely horrible. The abstract is unbiased and based.

8chan is younger than reddit, as you should know even if you only blew in from shitfront yesterday, and the abortion known as 8/pol/ copies reddit memes such as creating boards/subreddits for the sole purpose of making "witty" comments.

That's why your oh so interesting oven comments are peak reddit, you're parroting a reddit circlejerk.

>>1051037

>how could anyone not like fork()??!?!?!?!?

>YOURE A BIASED BECAUSE YOU DONT LIKE IT!!!11

HAHAHAHA

Listen you fucking charlatan. I started programming assembly in 2006. When I came to UNIX and saw fork() it was one of the most retarded things I've ever seen (same with pretty much all of C). I already knew how static and runtime linking and everything works coming from a windows reverse engineering setting and it still was retarded. Similar to the braindamage of any UNIX desktop system allowing stuff like ptrace to violate whatever shitty security model they were pretending to have.

On that subject, UNIX larpers won't even be able to tell you whether a fucking _file access_ will work for a given set of permissions and users/owners/uid/euid/gid/etc. UNIX centers around files as some kind of "simple abstraction" and UNIX larpers don't even have an idea how they work even at a level this high.

>>1050837

>>Fork is no longer simple. Fork’s semantics have infected the design of each new API that creates process state.

this. retard UNIX Larpers here have never even read a single man page. Or they just read the first sentence in the man page and none of the semantics and wonder why their shit crashes. UNIX Larpers are literally 5 year olds with no attention spam or discipline.

>>1051115

Papers on "OS research" are literal shit. Anyone who says "systems programming" to try and sound smart is an idiot as well. Anyone who doesn't concede that the OS and PL should be merged is most likely retarded, and all this "OS research" is just a bunch of shitty C-ABI-based OS. These papers are literally on shit like "designing" a function to get the system time, where "designing" means making a bunch of shitty hacks around C ABI, future and backward portability, "oh noes we already have this function what do do we deprecare the old one!?!?!!11", etc.

>>1051314

triple based

>>1051315

unbased and completely retarded

>>1051314

My point still stands. The paper is biased so whatever conclusion that it arrives at is erroneous. Keep squeezing. I am sure you will get blood from that stone eventually.

>>1051326

nobody sane thinks fork() is good. this is literally the way it works

>retard bro plays video games all day in highschool

>doesnt know what he wants to be when he grows up

>goes to college

>oooh computers imma do CS

>UNIX teacher in that one class explains 'systems programming' and fork()

>techbro now believes fork() is a standard thing because he had to talk about it in an exam

and for grassroots UNIX larpers:

>UNIX systems use fork()

>all hail fork()

>how dare you disagree with my cargo cult belief!?!?

literally noone ever would write programs this way. if you want to start another process, you would write start_process(programB)

and this is just on a surface analysis. as the LISP weeenie posted ITT, it's full of nuances: >>1050837

>>1051326

>My point still stands.

It was never standing, you utter retard. Read the pdf or GTFO of my thread.

>>1051329

>as the LISP weeenie posted

Wrong. I'm not the based UNIX hater. I'm the based based poster.

>>1050821 (OP)

its just that these modern things are much worse than the old thing. like much higher resource use and much more code to do the same thing that the old simple thing did.

>>1051340

they're both shit

>>1051340

>simple

It's not though. Read the pdf.

>Fork is no longer simple. Fork’s semantics have infected the design of each new API that creates process state. The POSIX specification now lists 25 special cases in how the parent’s state is copied to the child.

>>1051335

Dumb faggot. There is blatant bias. The paper is worthless with that bias. Eat shit.

>>1051356

>muh bias

LOOOOL

Triggered UNIX weenies are funny

>>1051360

Look at you. You aren't objective in your arguments. Everything is about your feels. That's why you are a faggot and a piece of shit. Now shut the fuck up.

>>1051361

>objective argument

Oh I'm sorry. I wasn't aware that we were having an objective argument.

But alright. I'll humor you. How about you start by substantiating your claim that this paper is biased?

>>1051370

I already did you stupid fucking faggot. Now fuck off.

>>1051371

Look at you. You aren't objective in your arguments. Everything is about your feels. That's why you are a faggot and a piece of shit. Now shut the fuck up.

>>1051047

>if you're forking for concurrency purposes, then use threads instead

>you can create amusing heisenbugs

Threads are the ones that spawn endless heisenbugs, due to the default of sharing everything. Forking only shares MAP_SHARED mmaps, so of course it has far fewer data races.

>>1051329

>if you want to start another process, you would write start_process(programB)

When do you set up programB? file descriptors, permissions, etc? It turns out that start_process already exists in the form of posix_spawn, which is why the authors think the transition will be easy. Unfortunately, nearly all syscalls need a start_process_mysyscall variant to emulate calling it between fork and exec, which turns a beautiful little API into a monstrosity, and negates every argument they make except for the one about scaling (someone explain that to me pl0x).

There's also a number of apis for doing this in special circumstances. eg popen, system. These use fork under the hood, because someone needs to do the dirty work.

>>1051086

>windows is a company

>>1051335

Based based based poster

>>1051373

You're a huge faggot.

When will we outgrow all this Unix/Linux retardation? Is there anything than can replace it in 3-5 years?

>>1051447

Never. UNIX-haters are a quickly aging and dying-off minority, which was small already. So not only are there very few people who have the skills to do a good operating system, even fewer really care about making a new one and not just another UNIX copy.

There's also the problem of legacy cruft. You could probably run a SVR4 program without major issues right now on a Linux machine, which is absolutely invaluable for business.

>>1051571

>You could probably run a SVR4 program without major issues right now on a Linux machine

I severely doubt that, old Unix shit is plagued with subtle portability problems.

Taking Unix advice from MS, just as bad as taking dating advice from women or clothing advice from blind men. lol

>>1051577

sage negated. Keep crying Unix weenie.

>>1050839

how is a microsoftpost not about the jews?

>>1051581

sage negated

>>1051571

>Never. UNIX-haters are a quickly aging and dying-off minority, which was small already. So not only are there very few people who have the skills to do a good operating system, even fewer really care about making a new one and not just another UNIX copy.

>THE YEAR WAS 2081, and everybody was finally equal. They weren't only equal before God and the law. They were equal every which way. Nobody was smarter than anybody else. Nobody was better looking than anybody else. Nobody was stronger or quicker than anybody else. All this equality was due to the 211th, 212th, and 213th Amendments to the Constitution, and to the unceasing vigilance of agents of the United States Handicapper General.

>Some things about living still weren't quite right, though. April for instance, still drove people crazy by not being springtime. And it was in that clammy month that the H-G men took George and Hazel Bergeron's fourteen-year-old son, Harrison, away.

>It was tragic, all right, but George and Hazel couldn't think about it very hard. Hazel had a perfectly average intelligence, which meant she couldn't think about anything except in short bursts. And George, while his intelligence was way above normal, had a little mental handicap radio in his ear. He was required by law to wear it at all times. It was tuned to a government transmitter. Every twenty seconds or so, the transmitter would send out some sharp noise to keep people like George from taking unfair advantage of their brains.

>>1051585

>>1051579

if you negate this sage ur mum is a whore

>>1051631

What is this supposed to mean

>>1051666 (checked)

sage negated

>>1051674

He's a pretentious boomer with unwarranted self importance.

>>1051674

He is a retard attempting to conflate the dying of a UNIX-Hater mindset with the classic short story about a society of people made handicapped to promote equality

bump XD

UNIX weenies BTFO indeed

>>1051577

>just as bad as taking dating advice from women

what's bad about this btw

>>1050821 (OP)

>Microsoft BTFO UNIX weenies

More like "We couldn't manage to implement proper fork() in Windows so now we're telling you why it shouldn't exist".

>>1058414

spotted the LARPer who has never used fork

>>1058440

spotted the larper who can't program

>>1058456

>no u

LARPing intensifies.jpg

>>1058440

>spotted the LARPer who has never used fork

Not my projects where fork is used (not even for exec()) and I have to know about it and about the overcommit:

uwsgi

redis

My projects where I use fork:

yeah, no, not linking them.

In general, copy-on-write is a useful optimization.

Sure, the system-development costs are there, and there's literally nothing that couldn't be done without it.

But where it doesn't exists, in-library hacks and kludges have to exist.

>>1058457

>yes u

What now?

It's weird that some people ITT think that the state of art hasn't changed since 1960s/1970s. UNIX isn't the state of art anymore (nor is Windows or MacOS for that matter)

>>1058556

It's a typical rotten Unix "optimization" that causes more problems than it solves. Copy on write has the choice strictly between being useless and making OOM errors categorically impossible to handle.

>>1058349

Do you think a deer is going to give you good advice on how to hunt it?

>the sheer amount of samefagging ITT

>>1058605

based

>>1058657

t. samefagging UNIX weenie

>>1058620

>implying women don't willingly throw themselves at chad

Imagine being this delusional

>>1051314

Reverse engineers continue to kick ass and take names.

There are people in this thread actually trying to argue with someone that mathematically proved fork() is absolute shit.

Try using an RTOS sometime unix fags.

>>1058620

other deers but not themselves? why not?

>>1059486

keep dreaming

Here's what the OP of this thread would have posted if he wasn't a dick drink faggot:

I know it's (((Microsoft))), but they make some good points.

Here's some highlights. Don't let LISPfag see this.

>The received wisdom suggests that Unix’s unusual combination of fork() and exec() for process creation was an inspired design. In this paper, we argue that fork was a clever hack for machines and programs of the 1970s that has long outlived its usefulness and is now a liability. We catalog the ways in which fork is a terrible abstraction for the modern programmer to use, describe how it compromises OS implementations, and propose alternatives.

>As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.

https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/

>>1059882

Fuck off, (((retard))). If you don't like my OP make your own next time.

>>1059883

I would have, but I have a life.

>>1059884

leave this place then

>>1059887

based

>>1059882

>the only way to make good OPs is to preemptively appease and apologize to unix weenies

>>1059911

based

bump

>>1062713

based

the amount of samefagging in this thread is too damn high

>>1059986

>>1059894

>>1062714

Just stop. We need you to stop posting. Please.

>>1062713

based

>>1062714

based

>>1062744

>triggered UNIX weenies

unbased

>>1062754

nope

unbased btw

>>1062755

ok underaged

>>1062759

>t. 12 year old

ok, unbased kiddo

>>1062761

based

>>1062761

>>1062767

>>1062755

Bass