A fork() in the road - <AUTHOR> https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/ <comment><USER2> I read the paper, and they make a lot of good points about fork's warts.

But I really wanted some explanation of why Windows process startup seems to be so heavyweight. Why does anything that spawns lots of little independent processes take so bloody long on Windows?

I'm not saying "lots of processes on Windows is slow, lots of processes on Linux is fast, Windows uses CreateProcess, Linux uses fork, CreateProcess is an alternative to fork/exec, therefore fork/exec is better than any alternative." I can imagine all kinds of reasons for the observed behavior, few of which would prove that fork is a good model. But I still want to know what's going on.

<comment><AUTHOR> I'm a bit rusty on this but from memory the overhead is by and large specific to the Win32 environment. Creating a "raw" process is cheap and fast (as you'd reasonably expect), but there's a lot of additional initialisation that needs to occur for a "fully-fledged" Win32 process before it can start executing.

Beyond the raw Process and Thread kernel objects, which are represented by EPROCESS + KPROCESS and ETHREAD + KTHREAD structures in kernel address space, a Win32 process also needs to have:

\- A PEB (Process Environment Block) structure in its user address space

\- An associated CSR_PROCESS structure maintained by Csrss (Win32 subsystem user-mode)

\- An associated W32PROCESS structure for Win32k (Win32 subsystem kernel-mode)

I'm pretty sure these days the W32PROCESS structure only gets created on- demand with the first creation of a GDI or USER object, so presumably CLI apps don't have to pay that price. But either way, those latter three structures are non-trivial. They are complicated structures and I assume involve a context switch (or several) at least for the Csrss component. At least some steps in the process also involve manipulating global data structures which block other process creation/destruction (Csrss steps only?).

I expect all this Win32 specific stuff largely doesn't apply to e.g. the Linux subsystem, and so creating processes should be _much_ faster. The key takeaway is its all the Win32 stuff that contributes the bulk of the overhead, not the fundamental process or thread primitives themselves.

EDIT: If you want to learn more, Mark Russinovich's Windows Internals has a whole chapter on process creation which I'm sure explains all this.

<comment><USER3> > created on-demand with the first creation of a GDI or USER object, so > presumably CLI apps don't have to pay that price

This tickles my brain. I read some blog post bitching that because Windows DLL's are kinda heavy weight it's way easy end up paying that price without realizing it.

<comment><USER4> It probably was this one: [https://randomascii.wordpress.com/2018/12/03/a-not- called-fu...](https://randomascii.wordpress.com/2018/12/03/a-not-called- function-can-cause-a-5x-slowdown/)

</comment></comment></comment></comment><comment><USER5> On macOS, fork() is a bit weird: [https://opensource.apple.com/source/Libc/Libc-997.90.3/sys/f...](https://opensource.apple.com/source/Libc/Libc-997.90.3/sys/fork.c.auto.html)

Many frameworks are backed by XPC services, where the parent process has a socket-like connection to a backend server. After forking, the child would have no valid connection to the server. The fork() function establishes a new connection in the child for libSystem, to allow Unix programs to port easily to macOS, but other services' connections are _not_ re-established. This makes fork on macOS (i) slow, and (ii) unsafe for code that touches virtually any of Apple's APIs.

<comment><USER6> fork() is generally unsafe for that reason, and OS X is only special in this regard in that it has more of these hidden C library handles that can blow up on the child-side of fork(). vfork()+exec()-or-_exit() is much safer.

</comment></comment><comment> dis-sys I agree with most parts of the paper.

Fork() is now basically the root of a looong list of special cases in so many aspects of programming. Things get even worse when you use a language with built-in runtime such as Golang for which multi-threaded programming the default behaviour. If fork() can't even handle multiple threads, what is the real point of having it when a 8 core 16 threads AMD processor is about $150 each.

<comment><USER7> > If fork() can't even handle multiple threads, what is the real point of > having it when a 8 core 16 threads AMD processor ...

These threads and those threads are not the same. The 16-threads SMT processor will happily chew on 16 different programs, processes or whatever the load at the moment is, e.g. if you use Python's multiprocessing you can create 16 processes and they'll be executed in parallel.

fork() can handle multiple threads but you have to be attentive when cleaning up etc. - quite often, code using fork() will get confused when you spawn threads, and code using threads will get confused when you fork()

</comment></comment><comment><USER8> Fork has really weird semantics, and a lot of fun gotchas around managing resources. Good riddance?

<comment><USER9> Not even just the semantics, the performance is awful. Even when the fork is virtual (as any modern fork is) and there's no memory copying because it's COW, all the kernel page tables still need to be copied and for a multi-GB process that's nontrivial. That's why any sane large service that needs to fork anything will early on start up a slave subprocess whose only job is to fork quickly when the master process needs it.

<comment><USER10> _> all the kernel page tables still need to be copied and for a multi-GB process that's nontrivial_

Only in the pathological case where the large process is backed solely by the 4kb pages. The hardware has long now supported large pages - on x86 since Pentium Pro, if memory serves - and huge pages. The popular OSes (Linux 2.6+ and Windows 2003+) also do support large and huge pages. A 2GB process can easily be three pages: r/x code, r/w stack, r/w data (2gb). Granted, it gets a bit more complex if mmapped I/O or JIT are used, but since both are mature technology now, it's fine to point fingers at any inefficiency and demand better. Another caveat would probably be shared libraries loading at separate address ranges, which, IMO, is another reason to ditch shared libraries for good.

Contrary to popular wisdom, OS research is still relevant.

<comment><USER11> You want to ditch shared libraries and mmap to map your big processes using GB pages to make fork fast again (despite it not being the main and only drawback)???

OS research might be relevant, and it's good that some people have wild idea, but honestly I doubt this one will go anywhere :P

<comment><USER10> Ah sorry, only want to ditch the shared libraries; added mmap is a later edition didn't realize it's unclear. Of course mmap is necessary.

<comment><USER11> About shared libraries, I know that there is this line of thought considering them "evil" (well at least sufficiently to want to get rid of them); but I'm quite unsure about what a modern system would look like without them (although this is less a problem at the application level on e.g. Android, the system level is still extremely important)

With Spectre, proper process bounds (well, address spaces) are more important than ever -- and oh well even without that I'd still have cited them as incredibly important, in the sense that I'd rather have more than fewer. Given that, code reuse involves shared libraries, for several good reasons; the obvious one being not wasting RAM, but then there is the update problem (how to patch programs when security holes are discovered, especially if multiple parties are involved), and on top of that there is the cache pollution problem, which is related to the code duplication problem, and which is quite insidious because it is probably simultaneously hard to benchmark and very real (ambient loss of perf, just not in very hot paths, but this will still have an impact on the general perf of a system, quite like Spectre mitigations are having a big impact)

Now we could like address space boundaries so much that we would want to just use even MORE processes in place of shared libraries, but this obviously does not work for all services (and Spectre is biting us again because context switches are not cheap), plus if you take it to the extreme this makes systems _extremely_ hard to design, and even bigger. This is part of the reasons we are using Linux instead of Hurd... (well Linux is too much in the opposite direction, but there are hopes that it will in the long term evolve toward a middle ground)

And anyway that does not fit the narrative at all of using more huge pages.

Now there are the usual radical ideas about how everything should be running on some kind of VM (sometimes even including the kernel), drastically reducing the amount of "native" code; but given the reality of our current systems that "everything" both relies on multiple VMs and I doubt it will tend to only one, nor should it (because of the monoculture this would induce). Plus the ambient perfs are _still_ lower than native code, and TBH I don't expect that to change ever.

So, why and how would you like to get rid of shared libraries?

<comment><USER12> We are using Linux instead of Hurd due to manpower.

Most high integrity real time OSes are microkernels.

Interesting that you mention Android, one of the key points of Project Treble is using separate processes for drivers with Android IPC to talk to the kernel (including hardware buffer handles).

<comment><USER11> Well in the end we are using any X rather than Y tech because of manpower, regardless of pretty much any other characteristics.

So let's put manpower kind of aside for the bulk of the dev (where thousands of man-years are needed for any big project) and look at what could actually be achieved with the very small amount of manpower _bootstrapping_ those projects. At this point you understand that the manpower thing is only a convenient narrative, while the reality is that even at the early time, Linux based systems worked _really better_ than Hurd based systems.

Because general purpose micro-kernels based systems are hard, and especially those with a design as ambitious as the Hurd. (When you start to want to strongly isolate FS from VM code, it even stops being just hard and starts to be really HARD.)

And this was even worse at the time for perf reasons (but perf reasons are still applicable even today, given the impact on mobile and datacenter workloads)

 _However_ , yes, I'm in favor of more isolation today, because for a shitload ton of drivers it literally won't make any difference whether or not you take 1us vs 50us if you need to execute once every few seconds. So it is retarded to the highest level to run in kernel space if you don't actually need it. Sadly, Linux is _way behind_ on that subject today.

That being said, and back to the original subject, a microkernel or at least a less monolithic one won't really get us in the less shared-libraries direction if it just re-implements the same perimeter of features of a monolithic ones, nor in the huge pages everywhere direction...

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> fork() is also used to daemonize and for privilege separation, two tasks where posix_spawn() cannot be used. I suppose daemonization can be seen as something of the past, but privilege separation is not. On Linux, privileges are attached to a thread, so it should be possible to spawn a new thread instead of a new process. However, a privileged thread sharing the same address space as an unprivileged one doesn't seem a good idea.

The paper also mention the use case of multiprocess servers which relies heavily on fork() but dismiss it as it could be implemented with threads. A crash in a worker would lead to the crash of the whole application. While a worker could just be restarted.

A proper use case of removing fork() from an actual program would help. For example, how nginx on Windows is implemented?

<comment><USER14> I can't answer for Nginx but normally on windows if you want "worker processes" you just start N of them and have them read work from a shared memory queue. That is, workers live longer than the tasks they perform. If one crashes, a new one is spawned. This does seem like a more sensible way of doing things than forking tbh. It isolates work in processes but doesn't pay for process creation per request.

<comment><USER15> "If one crashes, a new one is spawned."

I suppose that makes sense on an OS on which crashing is expected behaviour, though some people would want to know what bug caused the crash and whether that bug has security implications.

<comment><USER16> Crashing is an expected behaviour in Linux as well, you can enable coredumps or utilize an applications log if you want to know why.

<comment><USER15> The Linux kernel doesn't crash much, unless you have dodgy drivers or dodgy hardware. Whether your userland programs crash or not depends on what you're running. I don't expect to see sshd crashing, for example, though it's true that almost any program will exit suddenly if the system runs out of memory, which to an ordinary user looks like a crash, though it's a very different thing really.

<comment><USER17> If you weren't talking about userland crashes, then your crack about "an OS on which crashing is expected behavior" makes no sense.

<comment><USER15> The comment was not meant to be taken all that seriously, of course, but an OS is more than just the kernel, and I do tend to disapprove of brushing a crash under the carpet.

System runs out of memory, various processes get terminated, and the easiest way to get it back into a good state is a restart: not that worrying, but do you have a memory leak? Some process segfaults with 54584554454d4f53 in the PC: should be investigated, not glossed over.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I've been saying this for quite some time. Here's a gist I wrote about it: [https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c...](https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234)

</comment><comment><USER18> Can anybody elucidate about why fork() is still used in Chromium or Node.js? They are not old-grown traditional forking Unix servers (unlike Apache or the mentioned databases in the paper). I would expect them to implement some of the alternatives and having fork() only as a fallback in the code (i.e. after a cascade of #ifdefs) if no other API is available. Therefore, I wonder where the fork() bottlenecks really appear in everyday's life.

<comment><USER19> > why fork() is still used in Chromium

To support a multi-process web browser architecture that Chromium pioneered, you need to spawn processes. See [https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux_zygote.md)

<comment><USER17> That's not what the page says. It says the use of fork() saves 8MB and a few tens of milliseconds per process spawn.

</comment></comment></comment><comment><USER20> It points out that "1304 Ubuntu packages (7.2% of the total) calling fork, compared to only 41 uses of the more modern posix_spawn()".

In section 7 it suggests "We should therefore strongly discourage the use of fork in new code, and seek to remove it from existing apps."

Is anyone here going to help work on changing those 1304 packages?

I have already over-volunteered for thankless FOSS tasks like this, so I know it won't be me.

<comment><USER21> There are things that don't fit the posix_spawn limitations, especially with fd or capability manipulation.

<comment><USER20> Yes, certainly. The paper covers many of those limitations.

The goal is not "remove", but "seek to remove". The relevant definition of "seek" here is "to make an attempt" says [https://www.merriam- webster.com/dictionary/seek](https://www.merriam-webster.com/dictionary/seek) .

How many of those 1304 Ubuntu packages require fork()? Are there benefits to replacing (say) 1283 of them with posix_spawn()?

<comment><USER22> Yes, there are benefits to using posix_spawn: It's faster. See Figure 1.

<comment><USER20> How many of those packages would be improved with a faster spawn mechanism? Who is going to investigate each one? How will they convince upstream to change well-tested code?

</comment></comment></comment></comment></comment><comment><USER23> From the paper...

> 7\. GET THE FORK OUT OF MY OS!

Someone couldn't resist...

</comment><comment><USER24> If they're going to remove fork, then python's multiprocessing is going to be dead. Maybe then the community will be forced to get rid of GIL?

</comment><comment><USER25> When I learnt how fork() and select() worked, I just felt in love with Unix. The Win32 API was so ad-hoc and unnatural in direct comparison.

<comment><USER26> For me it was poll() due to it's simple and intuitive API. Also, it's much faster then select() when you have a large number of file descriptors being monitored.

<comment><USER25> For some reason the book (Beginning Linux Programming, Wrox Press, 1998 edition I think) explained select() first, so like the proverbial little duck that names 'mother' the first think it sees moving after hatch, select() caught my heart.

</comment></comment></comment><comment><USER27> And there I was thinking they would expose their fork() implementation.

Interested to see what this paper has to say.

</comment><comment><USER28> While fork() might be sub-optimal for launching different programs (fork() + exec() vs. posix_spawn()), it's absolutely essential in several types of common systems that don't use it to launch different programs.

Fork-requiring program class 1:

The biggest example where fork() is needed are webservers/long-running programs with significant unchanging memory overhead and/or startup time.

Many large applications written in a language or framework that prefers the single-process/single-thread model for executing requests (e.g. Python/gunicorn, Perl, a lot of Ruby, NodeJS with 'cluster' for multicore, etc.) are basically dependent on fork(). Such applications often have a huge amount of memory required at startup (due to loading libraries and initializing frameworks/constant state). Creating workers that can execute requests in parallel but _don't require any additional memory overhead_ (just what they consume per request) is essential for them. fork()ing _without_ exec()ing a new program facilitates this memory sharing; everything is copy- on-write, and most big webapps don't need to write most of the startup- initialized memory they have, though they may need to read it.

Additionally, starting up such programs can take a long time due to costly initialization (seconds or minutes in the worst cases); using fork() allows them to quickly replace failed or aged-out subprocesses without having to pay that overhead (which also typically pegs a CPU core) to change their parallelism. "Quickly" might not be quick enough if a program needs to continually launch new subprocesses, but for periodically forking (or just forking-at-startup) long-running servers with a big footprint, it's far better than re-initializing the whole runtime. For better or worse, we've come far enough from old-school process-per-request CGI that it is no longer feasible in most production deployments.

Anticipated rebuttals:

Q: Wouldn't it be nice if everyone wrote apps small enough that startup time was minimized and memory footprint was low?

A: Sure, but they won't.

Q: People should just write their big, long-running services in a framework that starts fast, has low memory requirements, and uses threads instead of fork()s.

A: See previous answer. Also see zzzcpan's response.

Q: Can you access some of those benefits with careful use of shared memory?

A: Yes, but it's _much_ harder to do than it is to use fork() in most cases (caveat Windows, but it's still hard).

Q: Do tools exist in single-proc/single-thread forking frameworks/languages which switch from forking to hybrid async/threaded paradigms (like gevent) instead?

A: Yes, but they're not nearly as mature, capable, or useful (especially when you need to utilize multiple cores).

Fork-requiring program class 2:

Programs which fork infrequently in order to parallelize uncommon tasks over shared memory. Redis does this to great effect; it doesn't exec(), it just forks off a child process which keeps the memory image at the time of fork from the parent, and writes most of that memory state to disk so that the parent can keep handling requests while the child snapshots.

Python's multiprocessing excels at these kinds of cases as well. If you're launching and destroying multiprocessing pools multiple times a second, then sure, you're holding it wrong, but many people get huge wins from using multiprocessing to do parallel operations on big data sets that were present in memory at the time multiprocessing fork()ed off processes. While this isn't cross-platform, it can be a really massive performance advantage: no need to serialize data and pass it to a multiprocessing child (this is what apply_async does under the covers) if the data is already accessible in memory when the child starts. Node's 'cluster' module will do this too, if you ask nicely. Many other languages and frameworks support similar patterns: the common thread is making fork()ing parallelism "easy enough" with the option of spending a little extra effort to make it _really really cheap_ to get pre- fork memory state into children for processing. Oh, and you basically don't have to worry about corrupting anyone else's in-memory state if you do this (not so with threads).

Anticipated Rebuttals:

Q: $language provides a really accessible way to use true threads that isn't nearly as tricky as e.g. multiprocessing or knowing all the gotchas (e.g. accidental file descriptor sharing between non-fork-safe libraries) of fork(); why not use that?

A: Many people still prefer languages with primarily-forking parallelism[1] constructs for reasons besides their fork-based concurrency capabilities-- nobody's claiming multiprocessing beats goroutines for API friendliness--so fork() remains useful in much more than a legacy capacity.

Q: Why not use $tool which does this via threads or why not bind $threaded_language to $scripting_language and use threads on the other side of the FFI boundary?

A: People won't switch. They won't switch because it's hard (don't tell me threaded Rust is as easy to pick up as multiprocessing--Rust has a lot of advantages in this space, but that ain't one of them) and because there's a positive benefit to staying within a given platform, even if some infrequent tasks (hopefully your Python doesn't invoke multiprocessing _too_ much) are a bit more cumbersome than usual. Also, "Friendly, easy-to-use concurrency with threads" is often a very false promise. There's a reason Antirez is resistant to threading.

\</comment><comment></comment><comment>--

TL;DR perhaps using fork() _and exec()_ for launching new programs needs to stop. But fork() itself is absolutely essential for common real-world use cases.

[1] References to parallelism via fork() above assume you have more than one core to schedule processes onto. Otherwise it's not that parallel.

EDITs: grammar. There will be several because essay. I won't change the substance.

<comment><USER6> There is one case where fork() is fantastic: as a way to dump a core of a running process while leaving the process running -- just fork() and abort()! But even this case should be handled by having something like gcore(1).

Another common use of fork() for things other than exec()ing is multi-process services where all will keep running te same program. Arranging to spawn or vfork-then-exec self and have the child realize it's a worker and not a (re)starter is more work because a bunch of state needs to be passed to the child somehow (via an internal interface), and that feels hackish... And also this case doesn't suffer much from fork()s badness: you fork() early and have little or no state in the parent that could have fork-unsafety issues. But it's worth switching this use-case to spawn or vfork-then-exec just so we have no use cases for fork() left.

<comment><USER29> These are both mentioned in the paper.

</comment></comment></comment><comment><USER30> fork() must go too??!!

</comment><comment><USER31> Interesting that Redis uses fork() for COW implementation.

<comment><USER32> It should be possible to achieve the same with mmap() and MAP_PRIVATE

</comment></comment><comment><USER33> [https://www.youtube.com/watch?v=p-mGXLgGqkY](https://www.youtube.com/watch?v=p-mGXLgGqkY)

</comment><comment><USER34> It's hard to take them seriously when they imply the mess that threads are is somehow acceptable and necessary, but nicer, less error prone and simpler fork isn't. Threads are a nasty hack and a liability for the modern programmer to use. And systems researchers really should acknowledge that their continued existence as first class OS primitives is holding back systems research much more, than fork. I guess they are looking to spread FUD and justify the mess that Windows got itself into, not doing actual research.

<comment><USER29> What's wrong with threads exactly?

<comment><USER35> Aliasable, mutable memory (ie race conditions) is evil, and threads perfuse the entire programming environment with it. This is a dirty implementation detail that operating system kernels have to deal with, and we should be burying it in the same hole as memory swapping and TCP retransmits, not making it a fundamental hazard every application developer has to worry about.

</comment></comment></comment><comment><USER36> I readily admit that I am unfamiliar with POSIX_spawn() and its benefits over fork().

However, may I point out that Microsoft SQL Server benchmarks have been posted that show Linux TCP-H outperforming Windows?

[https://www.dbbest.com/blog/running-sql-server-on- linux/](https://www.dbbest.com/blog/running-sql-server-on-linux/)

While I am sure that this is wise criticism, it might also be concluded that Windows itself contains no small amount of architectural decisions that limit performance.

</comment><comment><USER37> Fork is quite excellent, except in cases when the intent is to run a different program or when threads are involved (threads are basically an incompatible, competing model of concurrency).

The use of fork as a concurrency mechanism (creating a new thread of control that executes in a copy of the address space) is very good and useful.

In the POSIX shell language, the subshell syntax (command1; command2; ...) is easily implemented using fork. This is useful: all destructive manipulations in the subshell like assignments to variables or changing the current directory do not affect the parent.

Check out the fork-based Perl solution to the Amb task in Rosetta code: [https://rosettacode.org/wiki/Amb#Using_fork](https://rosettacode.org/wiki/Amb#Using_fork)

This essentially simulates continuations (in a way). (If the parent process does nothing but wait for the child to finish, fork can be used to perform speculative execution, similar to creating a continuation and immediately invoking it).

Microsoft "researchers" can stuff it and their company's flagship piece of shit OS.

<comment><USER38> The paper agrees with you that the fork models had a reason to exist and that is is perfect for shells.

They also point out that on modern hardware you often should want to write multithreaded multiprocess application.

Their main criticism of fork is that it does not compose at any level of the OS (as it cannot be implemented over a different primitive)

I understand that a lot of people here dislike Microsoft for good reason (not only historical), but drawbacks in fork() are well known and recognized, here they point out that it is also hard-to-impossible to implement as a compatibility layer if the kernel does not support fork.

Also:

> Microsoft "researchers" can stuff it and their company's flagship piece of > shit OS.

Do you have any reason to insult Microsoft researchers? They have plenty of citations in this paper of other researchers that appear to agree with them. This type of comments does not appear constructive to me

<comment><USER37> It's an idiotic argument. Only functions compose. Though fork is packaged as a function, it's really an operator with a big effect.

Booting a system doesn't compose; let's not have power-on reset and bootloaders.

Everything in this paper could have been cribbed from twenty year or older Usenet postings, mailing lists and other sources. Fork has been dissected _ad nausem_ ; anyone who is anyone in the Unix-like world knows this.

Oh, and threads have perpetually been the way to go on current hardware --- every damn year since 1988 and counting.

<comment><USER38> Also levels of abstraction compose.

> Booting a system doesn't compose;

Actually this is false, virtual machine and hypervisors allow to boot a system inside another system

<comment><USER37> Virtual machines can be forked processes, and contain operating systems with forked processes, some of which are virtual machiens ... fork composes!

<comment><USER38> as a function obviously, the point is that it does not compose easily with other abstractions. That is every other library and OS functionality needs to be fork-aware.

spawn do not have this requirement.

<comment><USER37> The concept of "fork aware" didn't exist until threads. You could argue it's a thread problem. Remember, every library and OS functionality aso needs to be "thread aware" when threads are introduced. The _pthread_atfork_ function can be thought about as "what do we do about thread and thread paraphernalia when we fork" rather than "what do we do about fork when we have threads".

Even the close-on-exec flag race condition is a result of threads. duplicating a file descriptor and setting its close-on-exec flag is a two step process during which a fork can happen, causing a child to inherit the descriptor without close-on-exec flag being yet set. But that can only happen if there are threads. (Or something crazy, like fork being called out of an async signal handler).

<comment><USER38> > You could argue it's a thread problem

But I explicitly want to not do it :) thread are obviously a good thing to have.

> every library and OS functionality aso needs to be "thread aware"

which is good, because differently from the case with fork thread aware libraries/OS help performance. Fork aware libraries/OS (in the case fork+exec) do not.

<comment><USER37> "Fork aware" is "thread aware". Hint: see the "pthread" substring in the identifier "pthread_atfork".

Note that this is necessary only because of the broken threading model that was retrofitted into Unix.

How it should work is that fork should clone the threads also. If a process with 17 threads forks, then the child has 17 threads. The thread IDs should be internal, so that all the pthread_t values in the parent space make sense in the child space and refer to the corresponding threads.

It's not fork's fault that the hacky thread design broke it. Fork is supposed to make a faithful replica of a process; of course if that principle is ignored in a major way (like, oops, where are the parent's threads?) then things are less than copacetic.

Threads also break the concept of a current working directory. If one thread makes a relative path access and another calls chdir, the result is a race condition.

Threads also break signals quite substantially; the integration of signal handling with threads is a mess.

Threads are not inherently a good thing to have; they are idiotic, in fact. Fork provides a disciplined form of threading that eliminates problems from the mutation of shared state, and provides fault isolation. It's much better to use forked processes instead of threads. Shared memory can be used for direct data structure access. With fork, you can create a shared anonymous mmap. This is then cloned into child processes as shared memory at the same virtual address.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER39> I havent read the entire thing yet, but reading from "replacing fork" to the end it reads too much like embrace extend extinguish.

<comment><USER40> It's suggesting posix_spawn, which is standardized and has nothing to do with Microsoft.

<comment><USER39> > Just as a programming course would not today begin with goto, we suggest > teaching either posix_spawn() or CreateProcess(), and then introducing fork > as a special case with its historic context (§2).

Or CreateProcess(), which has a lot to do with microsoft.

<comment><USER40> Yeah, if you're using Windows you aren't going to be able to use it. Or are you suggesting that Microsoft should implement posix_spawn?

<comment><USER41> Can't you use posix_spawn() with WSL and your favorite POSIX-compatible libc implementation?

<comment><USER17> Well that's a complicated question to answer.

You can use the posix_spawn function in glibc, which uses a vfork or clone syscall just like on Linux.

<comment><USER42> Also relevant, regarding the Linux native performance:

[https://mobile.twitter.com/RichFelker/status/602313979894038...](https://mobile.twitter.com/RichFelker/status/602313979894038528)

"Rich Felker, May 24, 2015: Some interesting preliminary timing of @musllibc 's _posix_spawn vs fork+exec shows it ~25x faster for large parent processes. (~360us vs 9ms)._ #glibc has a vfork-based posix_spawn but it's only usable for trivial cases; others use fork. @musllibc posix_spawn always uses CLONE_VM. This also means @musllibc posix_spawn will fill the fork gap on NOMMU systems cleanly/safely (unlike vfork) once we get NOMMU working."

Also evilotto's post here:

[https://news.ycombinator.com/item?id=19622477](https://news.ycombinator.com/item?id=19622477)

"a 100mb process generally takes >2ms to fork, while a 1mb or less process takes 70us"

<comment><USER17> Glibc got its main clone-based implementation in 2016, so it should be much more competitive now.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> Okay, this one has me laughing out loud. Of COURSE Microsoft doesn't like fork()... Windows pretty much can't do it. I'll admit, there have been a lot of times I wish there was a more streamlined way to spawn processes on Linux (particularly daemons) but when I don't have fork() I always end up missing it. I'd take this paper a lot more seriously if it came from someone with a less obvious bias.

<comment><USER44> As Linux developer and Windows hater, I agree with Microsoft. fork() is a hack.

Of course, all Windows APIs are terrible, but that doesn't make complaints about fork() any less legitimate. The concept of Establishing empty processes, instead of cloning yourself, is much more sane.

After all, the use of fork() is 99% of the time just to call execve(), and anything done in between is just to clean up the mess from fork(). Having a dedicated way to just create processes in a controlled fashion would have been better there. And, the other 1% is usually cases where pthread should have been used instead.

<comment><USER45> Cleaning up your own process between fork and exec is hard. Several programs resort to terrible hacks like force-closing everything except file IDs 0,1,2 in a loop. Or they look into their /proc directory to discover whichnfile IDs exist, which is only marginally better. But when your process is a house of cards built on third party libraries with their own minds, there are not a lot of other options.

<comment><USER46> Use O_CLOEXEC everywhere (even third party libs). It's really annoying, but necessary. Means you need to use accept4(), dup3(), popen with an additional "e" (of course all of that needs to be feature tested, during compilation/runtime).

<comment><USER45> The catch is that you may not be able to control 3rd party libraries enough to be be able to do all that. Thus all these annoying hacks. To me, the complexity of using fork() and the race conditions around pid reuse are the worst design problems of POSIX systems.

</comment></comment></comment></comment></comment><comment><USER47> "every other system has a feature except us, and we are not going to add it (because reasons) even if it's very widely used"

also:

> When a fork syscall is made on WSL, lxss.sys does some of the initial work > to prepare for copying the process. It then calls internal NT APIs to create > the process with the correct semantics and create a thread in the process > with an identical register context. Finally, it does some additional work to > complete copying the process and resumes the new process so it can begin > executing.

[https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl- system-c...](https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system- calls/)

<comment><USER14> They must have considered it many times (not least when making the partial posix support for NT) but felt that supporting it wouldn't help deprecating it either.

AFAIK it's only unix/Linux (posix) OSes that implement fork. Perhaps that's what you meant by "every other system", ie unix + clones/derivatives?

<comment><USER48> VAX/VMS implement "vfork()" which is an implementation of the most common use- cases of fork.

VAX and VMS are not POSIX or UNIX-like.

<comment><USER49> VAX is a hardware architecture. I'm not one to nitpick, but differentiating between VAX and VMS when VMS ran on the VAX is confusing.

</comment></comment></comment></comment><comment><USER50> We already have posix_spawn. I guess MS isn't aware of this.

Methinks MS need to focus on their own issues and leave the _nix world alone. While many people find their involvement in FOSS welcome, I do not and never have. They are still a for-profit company beholden to shareholders.

The purchase by MS of GitHub may, again, be welcomed by many, but I find it disastrous. I smell triple E here no matter what anyone says. This is why distros like Debian and Slackware are still so important. All _nix needs to do is start adopting MS ideas and then it's a matter of time before distros adopt disastrous code like systemd. MS does want to control everything around them like every other for-profit company. I cannot see this any other way. They are involved for their own good, for things like Azure and their own "cloud". MS needs to focus on their own garden and not that of *nix. I always have and always will prefer the "us and them" mentality when dealing with MS. Don't forget EEE. It's still a reality should you care to look hard enough.

<comment><USER51> Talk about uncharitable. MS Research produces world-class research. They don't just research Windows, they do research in all operating systems, programming languages and more.

<comment><USER50> It's not about being "uncharitable". It's about protecting _nix from being controlled by outside forces. MS does, indeed. have world-class research, but they are sticking their heads in the_ nix camp, which some of us don't like. We're not all in this together, despite what some will tell you.

Sadly, UNIX (umbrella term here) is not what it was a few years ago. I dearly miss Solaris, for example. Nothing touched it in it's day, not even AIX or HP- UX. I was a UNIX admin for 10 years. I've used them all. Nothing MS can produce will ever be better than pure UNIX. There is a reason it's still being made. FreeBSD can outperform anything MS has on offer. Hell, they borrowed networking code because they couldn't come up with better.

Not all of us see us all under the same tent. I surely don't and never will. It's us and them. To say otherwise would indicate we on all on a level playing field and we're all working together to a common good. We're not. Good research aside, I don't like their history, stewardship, or about anything else they do. Agenda...

<comment><USER51> Microsoft Research is not Microsoft. Microsoft Research employs some of the main Haskell developers, and you don't see Haskellers going all conspiracy theory. Research is research, and either the ideas they describe are good and should be adopted, or they're bad and should be ignored.

<comment><USER50> This may be true, but I don't want MS having ANY say on what goes into a Linux or FreeBSD OS. None. They have an agenda that doesn't fit in well with FOSS. May no mistake about it, driving everything so that it works with Azure/VS, whatever, is about staying relevant in a world that is largely leaving them behind. Short of having to write PS at work (required), I haven't run anything MS at home since 1998 and have no need to do so. EEE is alive and well. Ask why they want *nix compatibility so bad. To extend their hegemony into everything. There is nothing MS offers that I need. Nothing. I'm about to set up a shop for some people that is completely and utterly MS free. Cost will be only the HW. No software license costs. Freedom to do whatever. No stupid, arbitrary concurrent connection limits. FOSS all the way.

<comment><USER51> > This may be true, but I don't want MS having ANY say on what goes into a > Linux or FreeBSD OS. None. They have an agenda that doesn't fit in well with > FOSS.

False. MS is now one of the leading FOSS contributors. You're living in the past.

<comment><USER50> My living in the past is YOUR opinion. There are many millions of FOSS users who are highly opposed to MS having any influence whatsoever on FOSS. They have an agenda and it's never in the best interest of the FOSS crowd. Do you think they are doing what they do out of benevolence? It's done for MS software compatibility with FOSS, so users will choose Azure and their other cloud offerings. It's done purely to keep them in the game and relevant. No other reason. I heavily distrust MS, as over the years they have given many reasons not to trust them. Ever wonder why so many people abandoned GitHub after MS bought them?</comment></comment></comment></comment></comment></comment></comment>


Linux firewalls: what you need to know about iptables and firewalld - <AUTHOR> https://opensource.com/article/18/9/linux-iptables-firewalld <comment><USER2> The first thing I do on any server is mask firewalld and enable the legacy iptables service. Servers do not need firewalld and many other laptop features implemented under systemd.</comment>


47 Mind-Blowing Psychology-Proven Facts You Should Know About Yourself - <AUTHOR> http://www.businessinsider.com/100-things-you-should-know-about-people-2010-11

<comment> chao- A good mix of the well-known and less-known. I felt that half of them were "Mind blowing", and the rest ranged from "Apparent if you have ever thought about it" to "Obvious if you have ever thought about how advertising works", but informative overall.

A number of them I viscerally don't want to believe, but I know the science is there (e.g. multitasking).</comment>


Scott Pruitt's Strained Ties with Aides Set the Stage for His Fall - <AUTHOR> https://www.nytimes.com/2018/07/06/climate/scott-pruitt-epa-aides.html <comment><USER2> Regardless of what you think of what the regulatory role of the EPA should be, the scope of Pruitt's bilking of the american taxpayer is truly stunning. This is not run-of-the-mill influence peddling. From violating regulations to pay severances for public servants, to using taxpayer-funded positions to run errands and trying to get his wife a chick-fil-a franchise (lol), to just straight up fraud with his phone booth. The cost of this one persons little mini federal fiefdom is beyond words.

The worst part is that apparently the political divide has gotten so great that we can't even agree when a grifter goes this wild. This portends greater and greater abuses and wastes of our tax dollars.

</comment><comment><USER3> Today, Los Angeles hit all-time-record high temperatures. This is with 1C change from pre-industrial climate. We are headed for 3C and Scott Pruitt is dedicated to accelerating that change. We'll be lucky if the overnight temperatures in L.A. fall below 120, after we've hit 3C. If there was real justice in this life, Pruitt would have been flayed alive by an angry mob, not merely allowed to resign.

<comment><USER4> I dislike him as much as anyone, but was he really in office long enough to enact such devastating long-term change? It seems that many before him are as much to blame, if not more. Then there's donald, who will likely pick another shill to take pruitt's place.

<comment><USER3> I didn't say he personally did it all, I said he was dedicated to that purpose. And why? Just greed.</comment></comment></comment>


Show HN: GitMeet – Attract and Retain GitHub Project Contributors - <AUTHOR> https://www.gitmeet.net/ <comment><USER2> Who is the target market for this site? The repeated use of the term 'jobs' implies some sort of payment or longer term collaboration, but the interface seems to look like an idea in the vein of up-for-grabs issues within FLOSS projects.

<comment><AUTHOR> The target audience for GitMeet includes any developer who is working on an open source project and needs other contributors to fix bugs or work on subprojects within the repository. GitMeet provides popup tips to encourage users to contribute to projects they have joined and enables project creators to award "developer reputation" to developers who have provided helpful contributions to the project. Currently there are no payments involved with GitMeet, however, the main goal of the site is to encourage long term collaboration on a project.

<comment><USER2> So looking at the site, it seems like the main intended differentiators are the reputation system and the recommendation system (from users to projects). Both of these sorts of ideas require you to get a critical mass of users & projects.

Do you have any plans for getting an active userbase?

<comment><AUTHOR> Currently, I am trying to start small by providing ways to enable current users to alert others to their projects and jobs via built-in twitter notifications. Also, I plan to post actively on GitMeet's blog about topics surrounding use of the platform, opensource software in general, and how developers on GitMeet can best utilize the developer recommendation system. Do you think the plan mentioned is a sensible one? Also, are there any other methods of gaining an active user base that would be more effective?

<comment><USER2> I think the plan is sensible, but not that realistic in terms of being able to reach a critical mass. If I was in your position I would integrate much more closely with external services (github/twitter/etc) to hopefully make it feasible to have stuff like recommendations work effectively with a much smaller user base.

<comment><AUTHOR> Thank you for your feedback. As I add design/add additional features to GitMeet, how can I also be attracting users to reach critical mass? While the ideas that I originally outlined are certainly sensible, is there anything in particular that I am missing in my approach? Are there other ways of spreading the word about GitMeet? Thank you for your thoughts and time!</comment></comment></comment></comment></comment></comment>


Cosmography of the local universe highlights structures of local galaxies - <AUTHOR> http://irfu.cea.fr/cosmography

<comment><AUTHOR> There's also an accompanying paper with the technical details at <http://arxiv.org/pdf/1306.0091v1.pdf>.

</comment><comment><USER2> Awesome video, but somehow I don't think most of the audience here has the attention span to make it past the first few minutes.

<comment><AUTHOR> That may be the case, but it's still pretty incredible to put the universe (even a small corner of it) into perspective. It was really interesting to me to put some of the larger local structures like the Great Attractor and the Southern Wall into relative context.</comment></comment>


Fitness App PumpUp Thriving with 1.7M Members - <AUTHOR> http://velocity.uwaterloo.ca/2014/07/fitness-app-pumpup-thriving-with-1-7m-members/

<comment><USER2> How is this different than Weilos?

</comment><comment><USER3> Leveraging the current trend of channelling and fuelling narcissistic tendencies and jealousy on social networks/apps in order to motivate people to get in shape. Effective strategy.</comment>


My class: "Hands on Python 3.5" - <AUTHOR> Hello World, If you live near Santa Clara, I invite you to my class: "Hands on Python 3.5" which meets on 8 Saturdays for 4 hours starting Jan 7. The class will build software projects from popular packages available to Python 3.5.2. The venue is Santa Clara Adult Education room F4. The cost is $300. The class provides a certificate should you seek employer reimbursement. holler if questions: bikle101 at gmail Register: https://register.asapconnected.com/CourseDetail.aspx?CourseId=126730&ext=1 <comment><USER2> clickable >> [https://register.asapconnected.com/CourseDetail.aspx?CourseI...](https://register.asapconnected.com/CourseDetail.aspx?CourseId=126730&ext=1)</comment>


What do you do when you are offered 20% less? - <AUTHOR> I just got an offer about 20% less than I value my work. I have 1.5-year experience as a developer.
I like the field but I did not like their approach when they made their offer (over the phone, "how does this look to you?" etc.), which was a bit lower that what they had implied they would offer during the interviews.
What should I do? <comment><AUTHOR> Thank you very much for your suggestions. They are helpful.

By the way, they don't offer more benefits. When I asked them if they do, they replied with some crap on how they are a big company and some more bullshit which did not make much sense.

I will follow your advice, thank you.

</comment><comment><USER2> " That is a good start - for the probationary period, at the successful completion of which the salary will go to your phone offer amount" \- or something similar. You could also reply at 10% less for the probationary period.

</comment><comment><USER3> Counter offer that you would accept if they give the additional 20%. If they don't accept then you'll have to decide if you are willing to move forward or not.

</comment><comment><USER4> Assume raises suck and a general adversarial view of employees at the company.

You might also want to look at benefits. I assumed most companies had similar benefits.

</comment><comment><USER5> You can turn down the offer.</comment>


Idea: site to match hackers with short-term one-off gigs - <AUTHOR>

I alternate between being a lighting designer for a band and writing software for money. I get most of my work off of Craigslist's computer gigs section, but I'm finding it increasingly difficult, and I don't think it's just a matter of economic conditions.
Sites like Craigslist, Rentacoder and Elance are flooded with posts offering unreasonably low pay, as well as responses from offshore sweatshops that produce exceedingly bad code[0]. Posters have taken to hiding "put foo in the subject so I don't have to read spam" on Craigslist due to the overwhelming response to ANY ad. I think there might be room for something a little more exclusive.
My initial concept for this is that hackers would be screened for membership. It wouldn't be a high bar - a link to a HN account associated with a few sensible comments, a blog, a github account or similar would be enough to establish credibility. The site would also be policed a little more as far as postings go. One idea is to use a flagging system that can cause posts to be moved, and to have sections like "work for equity" and "work for pay".
[0] An example from an actual project I fixed after it was initially created by such a sweatshop can be seen here: http://paste.lisp.org/display/76132 <comment><USER2> _Sites like Craigslist, Rentacoder and Elance are flooded with posts offering unreasonably low pay, as well as responses from offshore sweatshops that produce exceedingly bad code_

Hiring a programmer on one of those sites is like hiring a lawyer (or accountant or interior decorator) out of the Yellow Pages. Sure, some people do it; but if you want someone good, you're much better off asking your friends and colleagues to recommend someone -- because the people you'll find in the Yellow Pages are predominantly those who don't get enough business from customer referrals to fill their hours.

<comment><USER3> I wish it was as easy as finding a lawyer. It's not hard getting a good reference from your divorce attorney for someone who does personal injury. I've reached six or seven programmers in my search for a web developer and none of them could put me in contact with someone can do what I need. Not to mention someone enthusiastic for a new start-up. Lawyers are always open for business.

<comment><AUTHOR> What is it you need? Maybe someone here knows somebody (or is that somebody).

</comment></comment></comment><comment><USER4> Although a potentially good idea, a lot of its dynamics remain pretty vague. What can differentiate this hypothetical site from a Rentacoder/Elance type site? A more rigorous vetting process before you're allowed to become a contractor?

<comment><AUTHOR> I want the site to be far more centered around attracting high-quality programmers and gigs. I suspect the differences would be more social than technical, though I certainly don't envision imposing the sort of process constraints Rentacoder does.

My idea is to be the Hacker News of freelancing sites, while the others are Digg and reddit. I have no idea if I can pull it off - right now, I'm just wondering if there's any interest.</comment></comment>


Police kill 95-year-old man with bean-bag rounds - <AUTHOR> http://rt.com/usa/police-man-killed-bean-bag-755/

<comment><USER2> Wow....</comment>


Ask YC: Are you working part-time on your startup/project/idea? - <AUTHOR>

I'm curious how much time you guys are devoting to your work? I have a FT job and I'm working on my own project that may become the basis for a startup or remain just something neat to showcase and develop my skills. Over the last four months I've managed around 2-3 days a week, which adds up to around 10-12hrs of coding a week. <comment><USER2> I did that for about 9 months before going full-time 6 months ago. I'd usually work on the startup for an hour before work and then 1-2 hours after dinner, so maybe 15-20 hours/week.

I've found that my coding time hasn't really increased much since going full- time, and yet I'm vastly more productive. The limiting factor in startups does not seem to be time: it's attention. Having that extra 8 hrs/day to think about the problem - and more importantly, _not_ having to shift gears and think about my employer's problems - makes all the difference in the world.

I've found it also changes the incentives around development and leads to better development practices. For example, I was much less likely to use frameworks or large libraries when doing this part-time, because I didn't have a solid block of time to thoroughly learn the library. If there was a major problem in the design, I'd be inclined to hack around it rather than tackle it head-on, because I didn't have the necessary brain-cycles to hold the whole problem in my head. I'd often cut the design down to what I knew how to do, rather than the product I'd want to use, because that was all I could handle in blocks of an hour.

I don't think it's really speed that suffers when you work part-time. Rather, it sets a ceiling on the difficulty level of the project you can do. So you're fighting over the same problems as all the other folks who're doing startups part-time, while many of the harder problem lie unsolved.

<comment><USER3> I completely agree with you. I recently left my career at one of the larger banks and the additional time has made all the difference. Now I get to spend time prototyping various ideas I never would have been able to otherwise with very small blocks of time. Best decision, ever.

</comment></comment><comment><USER4> I feel that THIS summer will be THE summer that I turn one of my projects into a startup, so in the past month, I've quit full time work and moved into a cheaper place to live.

I'm currently doing requirements gathering for my first project, and I've already done around 400 lines of coding. I wish I wasn't alone.

<comment><USER5> You are not alone. ;)

<comment><USER6> Guys, I think he is talking about a different kind of alone. Do not worry man, good things happen to those who wait.

<comment><USER4> Yeah, a different, more literal kind of alone.

I got burned last summer by bringing people on board too early. I'm the hacker-type.

The other people were the kind whose strengths too were different from mine. One was a high-powered client-interfacing guy, who has since taken a full time job as an IA, after the failure of his own Web 2.0 startup (all in under a year!). The other, and the troublemaker, was a high-powered marketing person who wanted to fasttrack the branding campaign before I even had a product or clients. We'd all worked together well in the context of a larger company, but we couldn't reconcile our directional aspirations for a startup.

So this year, I'm alone. In Northern Virginia's technology corridor. I would love a hackerly co-founder, or at least someone to bounce my ideas off of. All my friends from CS classes keep moving to the West coast to work for the Googles and Microsofts of the world. I have a feeling my YC application this year is going to be rejected simply because I'm a sole founder.

<comment><USER7> I'm also a sole founder. I don't feel _that_ disadvantaged because I have a mixed business/tech background, but in terms of applying to YC it's clear that being on your own is a major mark down.

It could be fairly interesting to see if a couple of technical people, working on different products, could act as one company. Both parties get the benefits of having someone to look over their shoulder (as they have a financial stake). You also get the sum of both sets of secondary skills and contacts. The downside would be a split in focus, but that should be no worse than the two working individually.

<comment><USER4> I'd love to have that.

Kind of a more-intensive, tech version of the Tuesday Night Music Club.

First rule: no bringing your girlfriend, even if she is Sheryl Crow.

</comment></comment></comment></comment></comment></comment><comment><USER8> I've found that I really enjoy my job, so my outside projects have started to shift from "this might make me money someday" to "this is really fun to code!" things.

It's weird how stability (and yes, coming from consulting and startuppery, this lion freely recognizes his gilded cage) and lack of where-is-my-next- paycheck-coming-from frees the mind to coding pure-fun stuff.

<comment><USER7> I like my regular f/t job as well, especially since I get moved within the company ever six to twelve months. It has given me a lot of freedom to do things that won't show a profit instantly like write and get some accounting qualifications.

However looking at what I really want to achieve I have decided that a startup is the way to go for me. Exit planned for September. Unfortunately it's not something I could run concurrently with a full time job, or else I might launch earlier to reduce risk :)

To answer the original question: Specs, use cases and UI mock-ups were 12 hours a week for 3 months. I wrote the first prototype this weekend (60 hours), so now I will be doing increments towards a stable production version, planned 12 hours per week.

</comment></comment><comment><USER9> Straight out of college when I was 23 I was working on a startup idea with a friend. we each had jobs, but they were very different. I was working as a mortgage broker (back then it was a good business) and my friend was working at a restaurant. I would get off work at 5 or so and my co-founder left work at 11-12.

So 4 nights a week we would meet at kinko's at 1am and work until about 4 am together. I would sleep for a few hours early morning and I'd also sleep for a few hours after I got home from work.

We weren't coding, just writing a business plan. We actually won an SBA business plan contest and got a little money to start the company. This was definitely the craziest hours that I've ever worked.

<comment><USER10> And how did your company do ? :)

</comment></comment><comment><USER11> The past few months I have been working my FT job, and also working on my start-up every spare moment I have (I would say 25 - 30 hours per week. Come June, I will be quitting the FT job and focusing exclusively on the startup.

I have been working FT for a large company for the past 5 years (past year remotely from home) and am really excited for moving to full time on my startup.

</comment><comment><USER12> Yes. I have been doing this for last 2 yrs and worked on 3 diff startups. First one is still operational, but I m not part of it, second one failed after 6 months of hard-work, and now I'm working on Third idea since last few months. There are mainly immigration issues bcoz of which I'm not able to go fulltime, so still continuing with part-time option.

During first idea, I was a bachelor, and used to invest more time on business development activities, product planning & management, networking events, mentoring sessions, reading books + blogging. I used to spend daily 3-4 hrs of evenings for this. My co-founders were doing coding. I did this for 1 year. Then bcoz of certain concerns, I left this project and started another.

During second idea, I got married, so working in the late evening was not justifiable. I used to work in early morning from 4am-7am, mostly coding and then in the evening, if necessary, meet some potential clients or advisors for business development activities. So daily I used to work for 4-5 hrs. Unfortunately, my other co-founders were married ones, and couldn't cope up with fulltime + mariage + part-time startup pace. So naturally, I was alone at the end, and after certain time, had to close the idea.

Now I again started with the third idea. Now I spend maximum time on learning technical stuff, and coding my application. Most of the times, I am the only one on this idea, I'm spending max time on developing product rather than building business, which I did lot in previous startups. I spend daily 2-3 hrs on weekday, and 5-6 hrs on one weekend.

In general, I try to put 15-20 hrs a week. Which i know are still very less for a startup :( I think having equally entrepreneurial and passionate co- founders, who are ready to slog hard in the part-time is very essential, which was the case in my first idea.

</comment><comment><USER13> I don't enjoy my current job at all. I work part time in a non-tech related job. the rest of my time is spent thinking about what projects to best devote my time to and experimenting.

</comment><comment><USER14> 2hrs/day * 2 ppl for 2 months == <http://unripped.com> (OpenID-based file storage and sharing)

The application works well and we hope to break free of part-time mode this summer. Opportunities for improving our product and exposure are limitless, so I guess that means the time we can/should spend on it is also limitless. ;p

fp's comment is right on: "The limiting factor in startups does not seem to be time: it's attention."

</comment><comment><USER15> i began working on <http://markkit.net> after hours. it took me about 9months to have first version online. then, beginning january 1st 2008, i negotiated with my boss to work part time (i had a good argument for negotiation : if he did not accept, i would go full time on markkit).

now i feel like i have the best possible situation.

</comment><comment><USER16> i have a fulltime job and freelance... i spend the time i have left after doing freelance at home to work on my "idea" - building something i need (and hopefully others would want it too...) and for the experience. basically it is like hitting two birds with one stone.

</comment><comment><USER17> When I was ramping up my last startup, I met my cofounder about 4 days a week after work and we worked until 9 or 10 at night.

I've found that when I go from "this is a cool project" mode to "going to turn this into a company" mode, the hours just start piling on.

</comment><comment><USER18> Quit Microsoft in January (<http://news.ycombinator.com/item?id=110792>) and I am loving working full-time on my own ventures.

I did build all products: (<http://www.phonemyphone.com>, <http://www.craigslistautoresponder.com>, and <http://www.emptyspaceads.com>) while working full-time at Microsoft, it seems really hard to succeed working part time on your startup.

</comment><comment><USER19> I average roughly the same. The last time I had a dayjob, I did about that amount of work each week, then stepped it up considerably in the couple weeks before a big release.

My problem is that, while working on my own stuff is fun, I'm often too pissed off about the dayjob when I get home each day and I tend to ruminate.

Sometimes I just end up not doing a hell of a lot. But other times I can salvage the rest of my day -- I'll take a quick shower and nap, then plan on spending 3-4 hours at my favorite cafe with a specific set of bugs or features to work on before leaving.

</comment><comment><USER20> I work some weeknights, plus large chunks of the weekends. I get maybe 10-20 hours a week on the project. I find this approach quite frustrating, though: you get totally in the zone and then it's time to go to bed because you have work the next day. Also, I find that I no longer have so much energy for volunteering or writing music or socialising. I knew that doing a start-up meant saying goodbye to your life, but I didn't realise that sacrifice would have to be made so early.

</comment><comment><USER21> About an hour a day, averaging weekends in with weekdays. I partly became so interested in Rails because I could actually accomplish things noticeably in that amount of time.

<comment><USER22> I agree completely with the rails aspect. I've only been using ror for about 3 months and as long as you think of what you want to do in a 'rails' way you get lots done.

In regards to the parent question , when I first start a side project I spend a fair amount of time on it afterwork. But it usually settles to 2-3 nights a week for a couple hours and 9-5 sat.

</comment></comment><comment><USER23> I started working on <http://muziboo.com> last year and then worked with my job for about 4 months. Quit my job and did it along with consulting for another 3 months and fulltime now. At one point, it gets very tough to switch your brains :)

Sometimes you can think of neat features/ideas only when you think for long enough and observe for long enough and atleast I need to be fulltime for that

</comment><comment><USER24> Hey, i've spend more than 4 hours per day, and 10 hrs more for weekend, so together added up to 40 hours a week. And i'm keeping this for months now.

</comment><comment><USER25> I've been thinking about this startup 2yrs and 1/2 ago now - started design & planning while i was student, then got a FT job, convinced a friend to join me in the meantime...

My teamate worked non-stop on it only 1yr ago, mainly coding the application - i was dedicating early mornings and late nights + weekends at it.

</comment><comment><USER26> I'm curious, for those who have gone fulltime on their startups, are you making any money at it, and if so how much?

</comment><comment><USER27> I did that for most of last year. But you can only do it for so long since all you do is work, then go home and work. Plus it just takes so much longer.

If it's an idea you truly believe in, it may be worth making that your full- time job. But it is a risk, you just have to decide if it's worth taking.

</comment><comment><USER28> Make sure you own your IP if you're working at a big company and part time on your startup.

<comment><USER29> How have people reconciled being able to work on your startup part time while at a large company full time? By reconcile, I mean in terms of legal contracts, etc. I'm pretty sure most people sign a non-compete clause in their employment contract.

<comment><USER28> The non-compete clause is for when you leave. IP rights are explicitly signed away in employee agreements.

The easiest way to reconcile is to quit and do the startup full time.

People shouldn't do things half-assed anyway. It's all about the focus.

</comment></comment></comment><comment><USER30> I'm a full time student so time comes and goes-- however, the Oxbridge term calendar (I go to Trinity College Dublin; the Oxbridge tag-alonger) gives us one hell of a summer holiday.

Hopefully something will come of this summer.

</comment><comment><USER31> Ive been working on my project <http://www.mee-mah.com> for the last few months for about an hour or two a day. However I did have the help of rent a coder!

</comment><comment><USER32> I work a couple of hours every few days, and try to get at least 8 in on the weekends. I've got a wife and kid and a FT job in a management capacity so it's tough, but I'm seeing progress.

</comment><comment><USER33> I'm doing the same thing, on pretty much the same time budget.</comment>


Program Logics for Certified Compilers [pdf] - <AUTHOR> https://www.cs.princeton.edu/~appel/papers/plcc.pdf <comment><AUTHOR> Link to announcement about making the book free to access on the authors web pages:

[https://sympa.inria.fr/sympa/arc/coq- club/2020-09/msg00016.h...](https://sympa.inria.fr/sympa/arc/coq- club/2020-09/msg00016.html)</comment>