A Simple Makefile for Medium-Sized C/C++ Projects - <AUTHOR> https://spin.atomicobject.com/2016/08/26/makefile-c-projects/ <comment><USER3> I do like simple makefiles. I adopted a C++-project without having much C++-knowledge, and simplifying the build setup was a big step in making it mine.

Thinking that it might be nice, I tried this one instead of my own approach at a simple makefile ([https://github.com/onli/simdock/blob/master/Makefile](https://github.com/onli/simdock/blob/master/Makefile)) and I get this error:

> Makefile:16: __* missing separator. Stop.

Which raises kind of an important point: Simple means understanding what is happening. I have no idea why `$(CC) $(OBJS) -o $@ $(LDFLAGS)` does raise that error - and just like that it is not simple for me anymore.

 _Edit:_ Now with the tab-error out of the way, it of course does not find the dependencies. That might be caused by a strange project organization (like said, it is an adopted project) or maybe the makefile is just not complete – I'm not sure how far the auto-generation is supposed to go. Played a bit with it, but that just removes the simplicity. For now, I think that the pkg-config way is nice and explicit, and would recommend to take a look at the linked makefile if a simple one is searched. Though I still would be happy about optimizations for that file!

I of course just might miss the point. Well, after all that supports mine: Not that simple after all.

<comment><USER4> Your editor probably automatically converted tabs into spaces. And just like that, the Makefile stops working.

Which proves the point: Makefiles are at a point in life where they should be exclusively automatically generated.

The only exception are throwaway projects where you and only you use it.

<comment><USER5> I strongly disagree. The tab requirement for Make is very well known and less strange than custom Makefile generation. Simple Makefiles work extremely well in lots of projects.

<comment><USER4> Somebody listed a number of common build system requirements below, but of course there are usually many many more like custom compilers, cross- compilation, any number of things that your "simple makefile" can't work with.

By the time the Makefile has grown to support all these things it no longer has the properties that made it useful in the first place (parsimonious, understandable, small).

<comment><USER6> Supporting custom compilers and cross‐compilation is as simple as using ${CC} in the Makefile instead of gcc…

<comment><USER4> This is how we got into this mess in the first place. "Surely it can't be very difficult, let me just add this.."

<comment><USER6> Perhaps, but I suspect writing a portable Makefile is not as difficult as you think.

Speaking as a packager, I have to patch _many_ CMake build systems for portability issues. And don't even get me started on SCons. Autotools is better in that regard, but has many flaws of its own.

Here's an example of a portable Makefile I've contributed to a project which handles the common packaging issues (staging directories, cross‐compilation, parallel builds): [https://github.com/sinamas/gambatte/pull/6/commits/8d6fffc2b...](https://github.com/sinamas/gambatte/pull/6/commits/8d6fffc2b3614f3753aae30bf78e66626a88d428)

Compared to the original build system (two SConstructs): [https://github.com/sinamas/gambatte/blob/master/gambatte_sdl...](https://github.com/sinamas/gambatte/blob/master/gambatte_sdl/SConstruct) [https://github.com/sinamas/gambatte/blob/master/libgambatte/...](https://github.com/sinamas/gambatte/blob/master/libgambatte/SConstruct)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> It always annoys me that we don't have better solutions for building C and C++ projects by now. My own take on the generic drop-in makefile[1] has over 1000 stars on github, which says pretty loudly to me that this is a common pain point for many people. Alas I haven't had a brilliant idea for a solution (yet).

[1]: [https://github.com/mbcrawfo/GenericMakefile](https://github.com/mbcrawfo/GenericMakefile)

<comment><USER8> True. Other languages have it way easier because:

\- proper module system, none of this header file nonsense

\- no compiler flags to worry about

\- no preprocessor definitions to worry about

\- as a consequence of the above, no dependencies that require their own linker flags, include directories and preprocessor definitions to work

\- no need to support different compilers/platforms with different configurations (which work differently with libraries that require different linker flags and include directories and...)

<comment><USER9> Out of curiosity, how do other languages cope with:

a. Targeting different release types (debug vs release)

b. Changing behaviour of the compiler

c. Having different code paths between debug and release (#ifdef _DEBUG)

d. Having macros and helpful macro expansion

I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against?

I suppose you could implement everything in a header file if you wanted a simple "module" system (thinking of the header as a module), but this would establish a very simple system with no interdependencies or reusability.

<comment><USER10> > I do not understand the dislike of header files: how would you recommend > distributing DLLs and libs while exposing their functions to be developed > against?

Do you enjoy writing out all your function signatures twice? Haven't you ever wished the compiler could automatically build the header file for you?

</comment></comment></comment></comment><comment><USER11> Please don't brew your own build system. It likely won't handle at least one of the following situations:

* installing into a DESTDIR

* setting custom CFLAGS/LDFLAGS

* changing prefix, libdir, sysconfdir

* cross-compilation

* parallel builds

* conditional features

* missing requirements

and will make packaging your software in Linux distros much harder than it needs to be.

<comment><USER12> There's no point telling people not to do something if you don't give them an alternative that does do all those things.

(And no, "just use autotools" is not a viable answer.)

<comment><USER11> Autotools _does_ do all of those things. I'm not a particular fan of it either, but when I'm packaging software for a Linux distro then I'd rather see autotools or cmake being used instead of some crappy custom build system that will require patching to make it work.

There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used, so there's a rather large barrier to entry.

<comment><USER13> Auto tools is great. To compile all you do is

        ./configure
          make
          make install

It couldn't be simpler. Even though I am part of the GitHub generation, I don't see why so many of my peers hate it. I actually like it.

<comment><USER14> This only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).

<comment><USER15> Why would it only work with command line programs on the Mac? That's definitely not true, unless something changed _very_ recently.

Also, you don't need autotools itself to build a autotoolized program. The generated configure script is portable sh.

</comment></comment></comment></comment></comment></comment><comment><USER16> Just use cmake or scons. In 2016, you should not hand write a single makefile !

A simple cmake/sconcs build file will be as simple as the one shown (or even simpler !) and it will definitively will be easier to integrate external dependencies if you have to.

<comment><USER17> Would be nice if you could give an example, not just "use that".

<comment><USER3> Especially since scons and cmake are in no way easy to learn, imho.

<comment><USER8> Still hell of a lot simpler than hand-writing Makefiles though. For both small and large projects.

I mean, a "hello world" CMakeLists.txt can be literally just this:

        add_executable(hello hello.c)

And it's cross-platform, can generate Visual Studio/Xcode/... projects, etc.

<comment><USER3> I think we have to go deeper than that to really see an advantage of cmake. A corresponding makefile would be:

        all: hello

That's not really complicated either.

<comment><USER18> Exactly. When evaluating a language / build system / whatever, it is definitely not sufficient to look at Hello World. You have to evaluate the worst case and average case if you want to get an idea of what you're in for. Looking at the "best case" (simple one-file project) tells you almost nothing except how hard it is to get started.

<comment><USER19> When evaluating build systems, one of my major questions is: How much "magic" will I have to work-around in order to do something off the beaten path that the build system's developers never considered?

This is a good criteria for languages as well.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> This is a good start. Could be made a bit more minimal.

I'll throw my base Makefile into the fray [0].

It supports cross compilation, CFLAGS & LDFLAGS usage, dependency file generation, source file autodetection (add the file to right folder and it's automatically included in the build), library building (`make lib`), Continuous Integration (`make start_ci/stop_ci`), Continuous Testing (`make start_ct/stop_ct`), Continuous Deployment (`make start_cd/stop_cd`), Installation (`make install`), Uninstallation (`make uninstall`), parallel compilation (`make -j4`), there's some build machine detecting/autoconfiguration support, build artifact generation, and even some git shortcuts (`make gstat/make make gpush`).

All in about 190 lines of Makefile (including some comments, and lots of blank space lines). It does depend on GNU watch if you use any of the `start_ _/ stop__` targets. I'm about to add self-documentation to it as well.

For more minimal, comprehensible approaches, see the work of the suckless people [1][2][3].

[0] [https://github.com/lpsantil/NewProj](https://github.com/lpsantil/NewProj)

[1] [http://git.suckless.org/dwm/tree/Makefile](http://git.suckless.org/dwm/tree/Makefile)

[2] [http://git.suckless.org/sbase/tree/Makefile](http://git.suckless.org/sbase/tree/Makefile)

[3] [http://git.suckless.org/ii/tree/Makefile](http://git.suckless.org/ii/tree/Makefile)

<comment><USER21> > a bit more minimal

ie. smaller, which is ironically smaller than the quote

edit: compared to 'gcc $CFLAGS $LDFLAGs <...> *.c' it's all rather bloated

</comment></comment><comment><USER22> Neat! I've been putting off learning how to use those `-M` flags to automatically generate dependencies, but it looks like it's not that hard :)

What I also like to do is hide the actual compilation command with recipes like this, inspired by the Linux kernel

        %.o : %.c
            @echo "      CC $<"
            @$(CC) -o $@ -c $(CFLAGS) $<

I think it looks a lot tidier, it turns a ton of dense uninteresting command lines into a few dozen short lines.

<comment><USER23> In a past life, the mega-but-autogenerated Makefile I helped maintain would store the executed command and only echo it if the command failed. And we logged everything to file, so you got nice output but all the info was there if we needed it. Didn't take that long to work out how to do it, once we'd decided it would be a nice thing to have.

<comment><USER24> I like that. It lives the Unix philosophy to be silent unless an error occurs.

</comment></comment></comment><comment><USER25> This approach is flawed because it uses "find" to discover the source files which means that if you delete a source file, it won't cause a rebuild since it won't see any changed files.

<comment><USER26> It's probably possible to adapt it to do that by using find much like you use gcc -MM to get header deps, generating a make snippet that you then depend the executable output on. But then we're getting pretty nasty.

</comment></comment><comment><USER14> The problem with Makefiles is that they don't work on Windows with Visual Studio, and generally only have very limited support in IDEs like Xcode, QtCreator, etc... and once stuff like cross-compilation and feature selection comes in, they get really messy really fast. That's where meta-build-systems like cmake etc come in. They all have their faults (cmake has a terrible scripting language), but they solve real problems for non-trivial projects.

<comment><USER27> I agree that cross-platform is tricky and in the past I have used SCons with some success for that.

Although, at least for Xcode, I can build my entire Xcode project from a Makefile: you just have to use command-line tools like "xcodebuild", and if you want a clickable version you set up a build phase that runs "make". And, while Apple's ".xcconfig" files are not exactly "make" syntax, they support a subset that looks exactly the same so it is possible to have files with variable settings, etc. that can be referenced by both Xcode and any Makefile that needs to stay in sync. Environment variables are yet another option.

</comment></comment><comment><USER28> I'm going to take this opportunity to rant about sad state of C++ open source. I would _really_ _really_ like to write some C++ but I'm not a C++ guru; so I tried installing facebook/folly and facebook/fatal on my Mac OS. That just doesn't work. It wasn't written cross platform and it probably never will. So I spun up a ubuntu VM and tried there. fatal compiles, folly still doesn't... And so ends my brief foray into C++. At that point I started researching how can I bind the library I need to Rust so I can skip all this nonsense.

C++ is not a bad language and I would like to write a project hat uses it. But I'm just a user of the language. I don't have time and expertise to tackle those build issues and quite frankly installing any library is a major PITA.

<comment><USER29> C++, regardless of open/closed source is not in a sad state IMO. The problems you describe sound like they're from the perspective of someone who's worked with much higher level languages. C++ is as good (or as bad) as it's always been, it hasn't evolved to a bad state.

New language designers have the luxury of having been bit by C/C++'s misfeatures and wrinkles. They also have the luxury of high end computers which can solve lots of problems in reasonable computation time. This means that modern languages can afford to trade off more computation resources in favor of development simplicity.

> But I'm just a user of the language. I don't have time and expertise to > tackle those build issues and quite frankly installing any library is a > major PITA.

I have a hard time understanding what "just a user" of the language means. It sounds like you're confessing to being a novice. That's fine, but you should be prepared to have to do a lot of work before you become proficient in C/C++. Much more so than modern languages.

</comment></comment><comment><USER30> BSD make (bmake) and its .mk includes are really simple, it's basically make with batteries included. Many makefiles may be reduced to two lines while no new syntax is introduced:

      PROG=${.CURDIR:T}
      .include <prog.mk>

It indirectly extends original BSD make. There are some syntactic differences from GNU make, but no big depart.

See [http://www.crufty.net/help/sjg/bmake.htm](http://www.crufty.net/help/sjg/bmake.htm)

Here is a custom BSDmakefile for my website, a more extensive example where the mk libraries can't apply:

      # makefile -- Build the website.
      #
      # $Id: makefile,v 1.10 2016/08/15 12:55:49 igk Exp $
      #
      #

      M4=m4
      AWK=awk
      SED=sed
      TIDY=tidy5
      TARGS=-i -utf8

      include config.mk

      # Common templates for each output file.
      MACROES=html.m4 config.m4
      TMPL=${MACROES} meta.m4 header.html.m4 HERE footer.html.m4
      HTML+=${LISTS:S/$/.html/}
      ATOM=${LISTS:S/$/.atom.xml/}
      OUT=${HTML} ${HTML:S/html$/&.m4/} ${HTML:S/html$/&.dirty/} ${ATOM}

      .MAIN: ${HTML} ${ATOM}

      # Generate lists.
      .for L in ${LISTS}
      $L.txt: $L.list
      	${AWK} -f list.awk ${.ALLSRC} > ${.TARGET}

      $L.atom.xml: $L.list
      	${AWK} -f atom.awk ${.ALLSRC} \
      		| ${M4} ${MACROES} - \
      		| ${SED} '1,2d' > ${.TARGET}
      .endfor

      .ifndef NOTIDY

      .for P in ${HTML}
      $P : ${P}.dirty
      	${TIDY} ${TARGS} ${.ALLSRC} 2>/dev/null > ${.TARGET} || true
      .endfor

      .for P in ${HTML}
      $P.dirty : ${TMPL:S/HERE/$P.m4/}
      	$(M4) ${.ALLSRC} > ${.TARGET}
      .endfor

      .else

      .for P in ${HTML}
      $P : ${TMPL:S/HERE/$P.m4/}
      	$(M4) ${.ALLSRC} > ${.TARGET}
      .endfor

      .endif # NOTIDY

      .for P in ${HTML}
      ${P}.m4 : ${P:S/html$/txt/}
      	$(AWK) -f page.awk ${.ALLSRC} > ${.TARGET}
      .endfor

      clean:
      	rm -f ${OUT}

      .PHONY: uuid pub ssh anal
      uuid:
      	sh ./make-uuid.sh
      pub:
      	sh ./publish.sh
      ssh:
      	sh ./s.sh
      anal:
      	sh ./analytics.sh

</comment><comment><USER31> We must be using a different definition of simple. I've never seen a simple makefile.

<comment><USER29> Well, with implicit rules IMO you can get really simple but productive makefiles.

e.g. (not "medium-sized" project, but illustrates the simplicity) [https://gist.github.com/androm3da/9b5575fb288045775c178a4fb2...](https://gist.github.com/androm3da/9b5575fb288045775c178a4fb2483438)

here's a slightly more feature-rich example, still relatively simple IMO.

[https://gist.github.com/androm3da/9126ff51b5b47f69b99b1e3db8...](https://gist.github.com/androm3da/9126ff51b5b47f69b99b1e3db845d85b)

</comment></comment><comment><USER32> Nice to see people spreading good practices with Make.

Too many folks don't understand good use of Make and thus are doomed to re- invent it badly.

I've had to use too many build systems that are, basically, big and flat lists of variables you can set. And yes I'm pointing at everything from esoteric in house systems to mainstream ones. Make's system of overrides is something especially useful.

<comment><USER33> This. Make is highly underrated. It's old so it's probably clunky, has a weird syntax and dog slow. Well no. So many examples of people reinventing the wheel, it's just sad.

</comment></comment><comment><USER34> "But because Make works backward from the object files to the source, we need to compute all the object files we want from our source files".

No.... don't do this.

Make is intended to work the other way around... it finds the source from your targets.

Define your VPATH and let it find them.

This is what loads of people do and is why there are _so_ many Makefiles are packed full of macro-magic!

<comment><USER35> I do agree that VPATH is helpful, but you'd still need to put the Makefile into the build directory in that case, which is distasteful, as it's not a built file.

Also you can't really get around specifying the files or searching, unless you have one c file per executable.

</comment></comment><comment><USER36> I feel like the only person in the world that uses Boost Bjam (for a proprietary project). I feel like I should switch but every time I look into it and read comments it's not at all clear that Bjam was a bad decision - <USER2> if it feels like I was the only one to choose it :-) It's simple, seems pretty fast but it is very hard to integrate custom build steps.

</comment><comment><USER37> I'm a big fan of meson [0].

The one thing it doesn't have over this Makefile is automatic detection of source files - you need to manually specify them. I haven't found that to be prohibitive in practice.

0: [http://mesonbuild.com/](http://mesonbuild.com/)

</comment><comment><USER38> Jam is nice and simple [https://www.perforce.com/resources/documentation/jam](https://www.perforce.com/resources/documentation/jam)

</comment><comment><USER39> Translating that Makefile to Shake [http://shakebuild.com/](http://shakebuild.com/) would be a good Shake learning project...

</comment><comment><USER40> This is not simple. I haven't made my own Makefiles, because when I see them, they are complex and not easy to understand.

That's why I chose CMake for my projects. If this is simple, I chose the right build tool.

This build file of a large project is easier to understand than the "Simple Makefile"

[https://gitlab.kitware.com/vtk/vtk/blob/master/CMakeLists.tx...](https://gitlab.kitware.com/vtk/vtk/blob/master/CMakeLists.txt)

<comment><USER33> > they are complex and not easy to understand.

Makefiles are declarative, which is a bit strange at first. If you start with a simple one you pick it up really fast.

</comment></comment><comment><USER41> Can we kill raw makefiles already? Projects that don't handle out of source builds in a sane way are awful to integrate.</comment>


Worst Bar Chart of 2014? - <AUTHOR> http://blog.infoadvisors.com/index.php/2014/01/29/worst-bar-chart-of-2014we-may-already-have-a-winner/

<comment><USER2> This one will be hard to beat!

<comment><AUTHOR> Yup. It's a groaner for sure</comment></comment>


Ask HN: Self Taught and Already Employed Developer – Should I Go Back to School? - <AUTHOR> I'm in my late twenties, I have two degrees in philosophy, and I spent one year doing a PhD before dropping out (funding; poverty; depression; just wasn't good for me ). I always had an interest in programming and taught myself some basic python and javascript when I was a teenager, wrote all my papers in LaTeX, and used Linux as my OS since I was 16.
When I left academia I moved in with family with the aim of taking a 1 year masters conversion course in computer science. However, before I even applied I managed to get a job as a contractor at a well known consultancy. I happened to learn a particular javascript library that isn't too easy to learn and was in demand.
I have now been employed as a contractor with this firm for just over a year, and in that time I have learned a lot. I also absolutely love my new career and I am motivated to get better at it so I can keep doing it.
Most other developers are very surprised when I tell them my background and I keep getting pushed into senior-ish developer roles (maybe because of my age, and because I have a beard \_(ツ)_/¯). Despite only having a year of experience, I'm in some ways a much better programmer than some of my 'on paper' betters that have years of experience and CS degrees.
However, I also feel very stunted compared to my peers. I don't have a grasp of algorithms and my mathematics is patchy, my understanding of databases is poor, and my experienced with compiled languages is 100 line toy applications. I'm basically stuck in mostly front-end development building SPAs using React and using nodejs for some simple server side scripting.
I want to make this a career that can last and I want to get away from the front-end where I don't have a flair for design that seems to be expected from me. Despite now having a lot of experience, should I take a year out and take a course like this one to further my chances:
http://www.bristol.ac.uk/study/postgraduate/2017/eng/msc-computer-science/ <comment><USER2> My suggestion to any self taught programmer is that if you are not looking for a certificate/degree then just go through the course material, buy the text books mentioned in the course material then read, practice and learn :)

By the way here is something that you might enjoy [https://www.youtube.com/playlist?list=PLhQjrBD2T383Xfn0zECHr...](https://www.youtube.com/playlist?list=PLhQjrBD2T383Xfn0zECHrOTpfOSlptPAB)

</comment><comment><USER3> There are many and equally valid reasons for going to school. Vocational knowledge is among them. So is the pursuit of an academic credential for it's own sake...or for the sake of approval by one's social circle. Not to mention the pursuit of knowledge for the pursuit of knowledge.

My advice: γνῶθι σεαυτὸν</comment>


The Tyranny of Dating Choice - <AUTHOR> http://www.salon.com/life/coupling/index.html?story=/mwt/broadsheet/2010/04/14/tyranny_of_dating_choice

<comment><USER2> If you're with anyone you don't want to be with you're doing it wrong.</comment>


Myths about /dev/urandom (2014) - <AUTHOR> https://www.2uo.de/myths-about-urandom <comment><USER3> (disclaimer I sell a HW random number generator)

I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG).

One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-4.8 you could ask the kernel to periodically pull a little bit of real entropy from the input to refresh the urandom output (non-blocking) pool, by default that was once every 60 seconds, but in our case with lots of entropy available we'd set it to happen once a second - now post 4.8 it looks like urandom_min_reseed_secs is ignored and the input pool (where /dev/urandom gets its data from) is not regularly updated unless data is also pulled from /dev/random - which may make sense if entropy is rare, but is not so useful when back pressure from /dev/random is left to control the rate at which external entropy flows into the system - I suspect it's time to present a patch that makes urandom_min_reseed_secs work again

Nevertheless the conclusion "use /dev/urandom" is still valid

<comment><USER3> BTW - a tiny bit of python to keep /dev/urandom fed post 4.8 - useful if you have a hardware RNG (either an external one or the one in your CPU):

      #! /usr/bin/python
      #
      #       OneRNG /dev/urandom tickler
      #       (C) Copyright Paul Campbell Moonbase Otago 2018
      #       Released under a GPL 3.0 license
      #
      import time

      with open("/dev/random", 'rb') as r:
              while True:
                      with
      open("/proc/sys/kernel/random/entropy_avail", 'r') as e:
                              iv = e.read()
                              print(iv)
                              if iv > 1500:
                                      x= r.read(1000)
                              e.close()
                      time.sleep(1)

<comment><USER4> GPL 3.0 for a few obvious lines seems to be really an unfitting license.

Non-licensed English language version, containing the same information:

Once per second, read /proc/sys/kernel/random/entropy_avail and if the resulting number is more than 1500 perform a read of 1000 bytes from /dev/random.

<comment><USER5> (this is more of a tangential licensing PSA, since we're on the subject)

Not licensing something is, ironically, restrictive. If you want to release to public domain (or equivalent), you have to explicitly mention that. E.g. by licensing under CC0.

Otherwise, default copyright and "all rights reserved" applies.

[https://creativecommons.org/share-your-work/public- domain/cc...](https://creativecommons.org/share-your-work/public-domain/cc0/)

(But, IMO, nothing wrong with publicizing use of GPL 3! :) thanks either way to both)

<comment> semi-extrinsic I think GP is getting at something else. As the length/complexity of the code goes to zero, the copyright and "all rights reserved" vanishes; this is well established, or else we'd all have to license "Hello world" examples from Kernighan and Ritchie's book.

If someone writes the same one-sentence pseudocode as GP in a book or blogpost, nobody could reasonably claim that an implementation would fall under the copyright of that book. And I think you'd be very hard pressed to argue it's copyrightable just because someone typed it out into real code.

</comment></comment></comment></comment></comment><comment><USER6> This article naturally leads to a question that I didn't see addressed, perhaps you can answer it here:

If it's unnecessary to ever prefer /dev/random to urandom, then why does /dev/random's current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS's, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

<comment><USER7> Because Theodore Ts'o, a major Linux contributor and maintainer, created and maintains /dev/random and blocks attempts to make it nonblocking like every other cryptographically secure random source. It's a political problem, not a technical one.

See [https://news.ycombinator.com/item?id=6550256](https://news.ycombinator.com/item?id=6550256) for a much longer argument about it.

<comment><USER8> Why should it be made non-blocking? If you want a large string with little entropy just use /dev/urandom. The political/dogmatic argument is that is should be made non-blocking. The process of acquiring entropy in typical computers is _definitely_ blocking.

<comment><USER9> What does "acquiring entropy" mean here? There is no reason a properly seeded CSPRNG should ever need to block.

<comment><USER8> I don't think you understand how CSPRNGs work.

<comment><USER9> Do go on.

</comment></comment></comment></comment></comment></comment><comment><USER10> 2014: [https://news.ycombinator.com/item?id=7359992](https://news.ycombinator.com/item?id=7359992)

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

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

<comment><USER6> Nice! Thanks

</comment></comment><comment><USER11> This document is very informative for sure, but I don't really think it's dispositive for many of today's use cases for randomness. In fact, I think this document is pretty dangerous.

I referenced this document here in this stackexchange question, which I think has a good and lively discussion about the real stakes of /dev/urandom today:

[https://security.stackexchange.com/questions/186086/is- alway...](https://security.stackexchange.com/questions/186086/is-always-use- dev-urandom-still-good-advice-in-an-age-of-containers-and-isola)

<comment><USER9> I don't think you're going to find too many cryptography engineers recommending that you use /dev/random, or, for that matter, the blocking variant of getrandom(2).

This might be a live debate on message boards, or on the wrong stack overflow boards --- though Pornin's answer[1] on this question is one of the all-time good Stack Overflow answers --- but among practitioners, this is long settled.

[1]: [https://security.stackexchange.com/questions/3936/is-a- rand-...](https://security.stackexchange.com/questions/3936/is-a-rand-from- dev-urandom-secure-for-a-login-key/3939)

<comment><USER11> Well, perhaps you have a better answer to my question than forest's answer, to which I awarded the bounty. For my money, I think that's one of the finest and most balanced pieces of writing on this topic available on the internet today.

> I don't think you're going to find too many cryptography engineers > recommending that you use...the blocking variant of getrandom(2).

It depends on what you mean by "the blocking variant". To quote Cory Benfield:

> Can we please try to be clear about what kind of blocking we mean? > getrandom(flags=0) absolutely _can_ block: that's what the original issue > was all about. To ensure it _never_ blocks you need to call > getrandom(GRND_NONBLOCK): that's why the flag exists.

It may (or may not) surprise you to learn that PEP 524, which uses this (sometimes blocking) variant of getrandom, has been accepted.

Here's a discussion of the matter featuring several reputable, kickass security-minded python people discussing the matter and indeed endorsing the sometimes-blocking (flags=0) variant of getrandom:

[https://bugs.python.org/issue27266](https://bugs.python.org/issue27266)

For full transparency: I read your post on this topic before I posted my question and found that, as far as I was able to read, it added nothing new to the public discourse on this topic. It does not seem to overcome the very real and well-sourced concerns raised by forest in his answer to my question.

Anyway, I'm not sure what you mean by "the wrong stack overflow boards" \- can you tell me which are right and which are wrong?

The link which you've provided, which of course I had already read thoroughly, as I pointed out in my question, is not from Stack Overflow, but from Security StackExchange, just like my question.

I haven't yet marked an answer correct, so if you actually have something substantive to add that you think is better than forest's answer, it's possible that you can grab the check.

<comment><USER9> Regarding that Stack Exchange answer: avoiding the Linux KRNG in favor of alternate RNG's like OpenSSL's is literally the opposite of what cryptographic software security engineers will tell you. For the past decade and a half, virtually all notable cryptographic failures owing to bad randomness came from systems that weren't using the kernel RNG.

<comment><USER11> Yeah, as you can see, I pushed back on that.

But, as far as I can tell - and I do indeed write with this in mind - <USER2> movement to create applications for very fresh, naive installations such as containers or IoT devices, does indeed present a problem for purely-blocking random.

My sense is that you and others in the community encouraging blind trust of /dev/urandom need to adjust your language when consulting on this matter in the future.

Since I mostly write python, I'm happy that this has been worked out and that python now uses blocking random (via getrandom(flags=0)) in these very rare situations.

<comment><USER9> Once again: there is exactly one time in the lifecycle of an entire system when you want a blocking read from the Linux KRNG: when the system is first booting, to ensure it's seeded (FreeBSD is smarter about this and handles that automatically). Apart from that one time, every other read on your system should be from urandom.

No, this doesn't need to updated for IoT or "containers" (Linux containers share the KRNG).

<comment><USER11> > there is exactly one time in the lifecycle of an entire system when you want > a blocking read from the Linux KRNG

Right. I'm glad to hear you phrasing it this way.

And listen: I don't mean to be flamy here, and it's possible that my sense of these things is tainted by our many... colorful discussions here on HN, but the unradom orthodoxy, to which getrandom and python's os.urandom are in part a response, is something for which you are arguably a tiny bit responsible, having actually written "Use urandom. Use urandom. Use urandom. Use urandom. Use urandom. Use urandom" on your blog. That kind of punditry has no place in security engineering.

There is a need for a degree of sobriety with these sorts of security considerations. Sometimes edge cases move toward the mainstream, and that's exactly what has happened with this odd little phenomenon of programs being executed much, much earlier in the OS lifecycle in the case of containerization and IoT devices.

Yes, some containers are deployed in settings where the host KRNG can be and is used. But not all. And many IoT devices suffer from a sufficiently weak set of entropy sources as to need to block.

These are real concerns, as identified by the study I linked from the University of Michigan. The researchers there were able to replicate over 1% of the SSH keys that they found in the wild because the devices that created them had insufficient entropy at the time of the key generation.

All I'm saying is: don't treat these sorts of security issues as subject to orthodoxy. Clear thinking and solid engineering are the orders of the day.

<comment><USER9> The blog post you're referring to contains exactly the advice I just gave in the preceding comment.

I don't see a link to a Michigan study in this thread. If you post it again, I'll be happy to explain why it doesn't say that you should use /dev/random, or a userspace RNG.

<comment><USER11> Well, man, that's not the debate. As so often in these conversations, you're running away with the goalposts. If I may advise: these are exactly the antics that are costing you credibility with those of us out here in the field actually building cryptographic systems.

Good day.

<comment><USER9> I don't understand your objections, like, at all. Every "concession" you think you're extracting is right there, in a blog post I wrote 4 years ago. Those are the goalposts. They haven't moved since 2014.

Everything else you have to say just reads like word salad. I should be concerned about container RNGs, but not Linux containers, unless they're the Linux containers that don't share the KRNG? Or the IOT devices where blocking somehow solves the cold-start entropy problem, and at the same time can't be done in the init scripts? Even the Python issue thread you posted --- yes, I read it --- disagrees with you. I have no idea what you're talking about and, candidly, I don't know that you do either.

I've written (until now) perhaps 1 word on this thread for every 30 of yours, and I think my comments are straightforward and make obvious points. You respond to each of them with a wall of text. Can I suggest that maybe instead of a grand disagreement, you've instead just done a poor job communicating whatever your concern might be?

Regarding that last sentence of yours (er, the one before your "good day"): I am _extremely_ comfortable with who does and doesn't find me credible. Thanks anyways.

<comment><USER11> Well look, the problem is solved, at least for people using python. So there's really no need on my end to discuss it further.

As for community communication and understanding: I really don't think there's any good reason that we all have to lock horns all the time. I do think that you'll find more joy in these sorts of discussions if you can be less caustic and more deliberative. It's no more difficult to be nice than it is to be mean; give it a try. And if you get to the edge of your knowledge (and, it seems to me that you do, fairly frequently, which is great - you are obviously interested in a wide variety of societal topics just like I am), don't just keep marching. Stop and acknowledge your short-comings and recognize that there are others who might have had some original / compelling / correct thoughts on these matters also.

Again, this is no skin off my nose. My current project is python, and python has wisely decided to stop using urandom in favor of getrandom(flags=0), so this is a non-issue.

But won't it be nice if the next non-issue can be handled with greater ease and less toxicity?

<comment><USER12> _and less toxicity?_

Wait a minute, you have made nasty insinuation after nasty insinuation in just about every single comment you've written on this thread and then sprinkled them liberally with finely ground condescension. That's where the toxicity is coming from.

<comment><USER11> I'm sorry if I've been unkind. That wasn't my intention.

But insinuation? I think I've been very clear and explicit about my criticisms rather than insinuating anything. Is there something about which I can be more transparent that will increase the quality of this and similar discussions?

I also don't mean to condescend, and I can understand from my writings how my tone might be interpreted that way. But what is the right thing to do in these situations? Discussions on HN of security and the political ramifications are dominated by the volume and aggression of this person and s73v3r_ and others of similar style, and it is taking a toll - people who are quiter but more knowledgeable (and to be clear: I'm not saying I'm either of those things) are being shut out. Can't you see it?

It reminds me of far-right AM radio. I don't want to find myself just tuning out of HN entirely, so I'm trying to be a little more proactive.

On the other hand, I certainly don't want to respond to vitriol with vitriol, but I do want to try to find common ground so we can all learn from each other instead of bark about who's right and who's wrong on these minuscule, mundane points.

Again: Although I think I've been quite explicit rather than lean on insinuation, I apologize for portions of my tone. I'm not a mean person; I'm just trying something new in an effort to change the direction of these things.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > _I just claim that it 's bad to block when the entropy estimate is low._

As always when it comes to engineering, good and bad can only be defined when you are specific enough about what it is you're trying to accomplish.

Is it a single-user client system with an intelligent user who won't try to subvert security (maybe because you've defaulted to /dev/urandom but given them a choice to override and use /dev/random), and you're trying to do something of crucial importance like generate a long-lived crypto key? Then blocking might be fine or even the better way.

Is it a multi-user and/or server system where randomness is a scarce resource whose exhaustion could bring down the system like any other scarce resource (disk, network, RAM, CPU, etc.)? Then blocking is probably a terrible idea and could even open you up to denial of service attacks, thus causing you to achieve _less_ security.

<comment><USER9> First problem with this response: programmers have a terrible understanding of what "crucial importance" is. In fact, most things in cryptography that want random values _need_ unpredictable values. The old Linux man page creates the impression that you want "good" random for keys, and "mediocre" random for everything else, which is false.

Second problem is, there is no such thing as "good" and "poor" random. There are two states: unpredictable (seeded) and predictable (not yet seeded). Once you read seeded state, you're done; _blocking serves literally no purpose_.

<comment><USER13> > _programmers have a terrible understanding of what "crucial importance" is._

If you cannot understand requirements, you cannot produce satisfactory software.

Anyway, it was intentional that I gave an example where an educated end user is able to make the choice rather than a programmer having to guess.

> _The old Linux man page creates the impression that you want "good" random > for keys, and "mediocre" random for everything else, which is false._

It certainly is false, and it is a myth that many people believe, but it isn't what I was saying.

> _Once you read seeded state, you 're done; blocking serves literally no > purpose._

As the article explains under the last section ("Not everything is perfect"), /dev/urandom does not guarantee that you are reading seeded state.

Also, those numbers' unpredictability rests on the crypto being really good. Which I'm sure it is, but crypto weaknesses have been discovered in the past. It would be defensible to seek additional protection against that possibility for peace of mind if peace of mind is more important to you than running time and/or availability.

</comment></comment></comment><comment><USER6> Well written post, I enjoyed it, it makes sense.

The part tearing into the man page was especially excellent!

Following your point a little further.. the thought of updating the man pages with warnings like the following made me laugh:

"AES, SHA-3, RSA, Diffie-Hellman, Elliptic curves, and all those crypto packages you're using, OpenSSL, GnuTLS, Keyczar, your operating system's crypto API, are all theoretically vulnerable to a cryptographic attack. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, do not use them."

</comment><comment><USER14> This seems to just muddy the waters.

[https://sockpuppet.org/blog/2014/02/25/safely-generate- rando...](https://sockpuppet.org/blog/2014/02/25/safely-generate-random- numbers/) is shorter, more succinct, and to the point.

</comment><comment><USER15> On a VM that someone else runs (i.e. Google or AWS), is either /dev/random or /dev/urandom cryptographically secure?

If no, are there any "safe" choices? (other than an external source like an HSM or hardware random number generator)

<comment><USER16> Most vms / cloud providers can provide a virtualized source of entropy to be mixed into the pool (google "virtio-rng"). Good OSs (like linux with the right virtio modules) will use that to have a high amount of entropy very early into boot. If that's what you're asking, then the answer is "yes, clouds have good urandom available, usually earlier than on real machines".

If instead you're asking "but can the cloud compromise me?" then the answer is "you're wrecked".

If you do not trust the hardware your vm is running on (be it real or virtual hardware), then you have no hope.

Any source of random numbers you read from will read those numbers into memory. The hypervisor or sufficiently-malicious-hardware will then be able to read your memory and get the data, even if it came from an hsm.

The "safe" choice is to trust that your hardware/hypervisor is not stealing such data.

If you can't trust that, you may have to start fabricating your own processors and running your own data-centres.

Be sure to hire better physical security than AWS has or else it's all for naught when someone comes in and yanks your memory to read it.</comment></comment>


Carbon Copy Cloner 5 - <AUTHOR> https://bombich.com/features <comment><USER2> Thanks for posting this, it's one of my favorite utilities. It's rare to see this degree of polish on such a nerdy, low-level tool.

<comment><USER3> Well worth what it costs too! It's highly useful and does its job elegantly.</comment></comment>


James Siminoff: I would create a fully self contained incubator - <AUTHOR> http://jamessiminoff.com/post/64336227/y-combinator-is-dead

<comment><USER2> Investors haven't stopped investing. In fact the record series A valuation for a YC-funded company was set just a few weeks ago.

Even if investors did stop investing, it wouldn't kill us. At the last Demo Day, 4 of the companies presenting were already profitable. (All 4 have had offers of investment, incidentally.) At the next Demo Day the ratio of profitable companies will be even higher.

As for his alternative suggestion, among other problems, it wouldn't give startups any more runway. There's no reason to suppose that if we got into the real estate business, we could offer space to startups any cheaper than they can get it on the open market.

<comment><USER3> wow, record series A valuation? Did this company start working on their product near the beginning of their YC funding cycle or had they been working on it for a while? It appears to me that a higher percentage of YC companies are coming into the program with a developed product and traction than we had during the reddit, loopt, kiko days.

As an aside, I love the author Jamie Siminoff, I enjoy our product brainstorming sessions, and think his company Phonetag is awesome, but I think this article is a bit empty. I wonder if companies would be as hungry to succeed if they had guaranteed place to stay in a hotel that resembled a 24 hour lan party? Probably not.

<comment><USER4> Matt thanks for the comment and I agree the article is a bit empty, because in reality it was a quick post based on what I have been feeling lately, not so much an article...

I should probably write a follow up about how I would envision the "24 hour party". For example for sure you would not be gauranteed to stay, the ability to stay would be based on how the company and team are working. So in essence every week or 2 would be viewed as an additional round. However with this cost basis unlike others you could keep a company going a lot longer if you believed traction would come.

</comment></comment></comment><comment><USER5> This seems to wholly miss the point of YC, associating it with a sweatshop style mentality: live for work, etc. But, YC has many, many, companies, possibly a majority, that would not fit into a "Hotel de Startup" model.

It wouldn't have fit my company, for example. We have baggage...family, dog, lives outside of our company, etc. I kinda doubt several of the most successful YC companies would have signed on at all for such an intense sort of experience.

Beyond the basic expenses of buying a hotel in the valley (I think the cost is being underestimated, even in this economic climate), the expenses of operating it are going to be very high, even without staffing it as a hotel. It's obviously a mandatory expense, and everyone needs somewhere to live, but you're not going to save a huge amount of money over individuals placing themselves in their own apartment or house. And, more importantly you're going to self-select out of being able to fund any company that doesn't exactly fit the stereotype: Fresh out of college, no family, not from the area and thus not already settled somewhere in the valley, not needing to have a presence outside of the valley for business reasons, etc.

This is one of those things that sounds cool, but I think it takes the simple, and obviously successful, kernel of YC and adds a non-essential boondoggle that doesn't actually improve on the model.

I believe the solution to the "what happens after" shouldn't be "make sure the founders never have to think about after by infantilizing them and making sure they never have to think about necessities", but instead should be "make sure the founders are well-prepared for after". After is going to come eventually, if the company is to be a success.

</comment><comment><USER6> Argumentless linkbait. I want my thirty seconds back.

<comment><USER7> Agreed. I thought only diggers fell for big, empty headlines. Angel investing is more likely to survive in the IT segment than standard VC investment due to the small barriers to entry. I just said more than that entire blog post.

<comment><USER8> Headline has been revised from when the parent was posted, it used to talk about YC being "dead".

</comment></comment></comment><comment><USER9> I'll post here, what I posted there:

 _But the idea that you can put something out there on the cheap, get traction and become profitable is very much alive._

You can run a startup for two years for less than the cost of grad school. If anything, the YC model is more alive than ever. The labels should be worrying, not the talent.

<comment><USER10> Your comment has me attempting to map web companies to rock bands.

I got as far as:

Google = Beatles

Myspace = Monsters of Metal

37Signals = Led Zeppelin

#silly I know.

<comment><USER11> I've been reading PG's stuff since way before YCombinator existed, and that was my initial analysis of YCombinator.

First of all, my belief was that PG graduated from five different colleges around the world because he liked being around smart young people, and to continue to be in a college-like atmosphere of optimistic young people without going to school in the U.S. and Europe for yet another degree, he started YCombinator, where he convinces smart young people to come to him, which is a much more efficient way of being around smart young people.

Another way I've thought about it was that PG was like a manager of boy bands of 2-4 young people, who try to entertain fellow college men instead of young girls (and later on, the general population, once their "act"/app caught on). These bands couldn't always sing, but they used technology to help them get a marketable product out, similar to how startups make up for their inexperience by using frameworks and web services to make their product improve, so they could continue to release "new records" regularly.

Over time, I've found that both the number of startups YCombinator has launched and the addition of the jobs page to news.ycombinator has shown that PG is actually not like a manager of boy bands, because the companies hire their own people and PG does not micromanage every decision, from what I understand. Also, I've noticed that media articles now describe these companies as their own beings, without always mentioning that these companies are part of YCombinator, something that is different from when YCombinator first started.

</comment></comment></comment><comment><USER4> I am a little surprised that this got picked up, did not realize that my blog had the readership to even become link bait...

While the title might have been a little aggressive it was how I was feeling today. I have seen a lot of stuff recently which is what brought this post about.

Hope I did not piss off anyone at Ycombinator (or the companies that they funded) as this post (if you read it you will see) is much more about the VC market changing and in my mind hurting the scrappy entrepreneur's chances.

<comment><USER12> I thought this was an interesting post, you raised a point which I haven't seen anyone refute yet: wouldn't it be more cost-effective in the long-term to purchase a bankrupt hotel? I'm not the finance guru in the room, but I feel like it would be cheaper long-term.

I've done apartment hunting in the bay area, and it sucks. You have to look around, sign contracts, deposits, etc. It's a huge time and energy drainer.

I like your idea, I find it to be creative. Can someone please discuss the downsides to doing it this way? Let's put aside the whole "YC is dead" argument, that's obviously only going to degenerate this otherwise meaningful discussion.

<comment><USER13> "wouldn't it be more cost-effective in the long-term to purchase a bankrupt hotel?"

It would be the ultimate extension of the Google (and Microsoft before them) "keep them at work" model. Bed, board, work in one location. Every cost could be amortized over the number of people/companies you have living there. Incomparable face to face networking opportunities.

Certainly one of those brainstorming "this is way too crazy to work...or is it?" kind of ideas.

<comment><USER14> It works on college campuses, why not elsewhere? Dorms largely eliminate the apartment-hunting roadblock and provide very close contact with (theoretically) interesting people.

I lived off campus for the last two years of college, and it made the experience suck a lot more.

This is the reason why I gave my upvote, nothing about a linkbait title or talk about VCs.

</comment></comment></comment></comment><comment><USER15> Admittedly I am a bit sleepy right now, but am I somehow missing the part where he supports his argument in any way?

<comment><USER16> i think his point is that seeding and growing businesses that lead to external VC capital and acquisitions is dead/dying.

his alternative is to essentially do the same thing, but gear it not towards external funding/buying, but just a single company that grows, fosters and continually owns the companies it helps to start.

its sparse on the details, but i had/have similar thoughts and would love to start or participate in something similar.

<comment><USER17> Isn't this kind of a model Google is approaching?

<comment><USER16> yeah, i was thinking the same thing, but didn't edit to add it. i think the main difference is that google has a moneymaker product that helps to fund the other small ones, which wouldn't be the same as this concept. or, maybe it could be, with coworking space being the main business to keep it above water on the basic expenses.

</comment></comment></comment></comment><comment><USER18> I would call it The YMCA Combinator.

</comment><comment><USER19> Where is the new YScraper these days? (I thought the original one evicted YCers after a justin.tv incident.)

<comment><USER20> it only evicted Justin.tv. There are still a lot of startups (YC and non-YC) in the building.

<comment><USER19> Cool. Just curious, which non-YC startups are there? Is it just as social? We (Dabbleboard) are a non-YC shop that could benefit from moving there.

<comment><USER20> not sure if they want everyone to know, email me

</comment></comment></comment></comment><comment><USER21> I've kind of had my doubts about YC myself (not the YC model) -- I was thinking this might be an intelligent piece addressing YC itself and the role of that sort of funding in startups.

But the hotel idea is cool too.

</comment><comment><USER22> The real self-contained incubator:

Save up 30 or 40k. Quit your job. Take 6 months out to build your app.

</comment><comment><USER23> He doesn't sound very smart for someone who created such a company.

<comment><USER24> Not very different _then_ how it was before.

</comment></comment><comment><USER25> think before you blog

<comment><USER4> Everything I blog I am obviously willing to have put out in the open. I stand behind the post, the title I would probably slightly modify for the wide audience (this was intended for my normal readership of about 100 people) it seems to now be getting...

But if you read the post I think the point I am making is clear and the title does fit that as well.

<comment><USER26> The problem is your tense. You make a prediction that will affect investors like YC, yet declare the firm immediately dead.

I would recommend writing to the audience you want to have, and nurture your current readership into loyalty through respect. That means reasonable headlines and fleshed out arguments.

I must admit though, I've toyed with the idea of a "dev bunker". Really cheap housing + coworking + startup community = super cheap collaboration.

I think PG is right, that it wouldn't be cheaper than the open market. But the benefit is in the colocation, not just cost.

There are plenty of YC companies that don't fit the super scrappy model though. We at Tipjoy have a house, for example.

<comment><USER4> I love the name, "Dev Bunker".

I think it would be a lot cheaper. Getting contracts for office, housing, etc., is very expensive (both from a cash perspective and a business energy perspective).

<comment><USER26> Scrappy startups dont have offices. They work out of their apartments. I don't think you can do better than that market. Utilities, food, etc. might be cheaper, but that is very, very marginal.</comment></comment></comment></comment></comment>


Unix file security 2013 (z/OS) - <AUTHOR> http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=%2Fcom.ibm.cics.ts.doc%2Fdfht5%2Ftopics%2Fdfht5_hfs.html z/OS <comment><AUTHOR> I have always been impressed with the level of ibm's documentation. Aside from the likes of ubuntu, arch, and my personal favorite: OpenBSD.</comment>


Show HN: A new way of eating out – by dropping in - <AUTHOR> http://www.cozymeal.com/ <comment><USER4> It occurs to me that _x_ -sharing startups in the mold of Airbnb/Uber may be most likely to overcome their regulatory challenges not through litigation or lobbying, but simply due to more of them popping up and the increased likelihood that the average person knows someone who has benefitted ("my friend's daughter who paid her way through law school driving for Uber", "my cousin the line cook who was offered the opportunity of a pop-up run at an established restaurant after a few successful months on Cozymeal", etc.)

Also, I wonder if Cozymeal might find opportunities on the operations/materials side of this equation. I know that e.g. sourcing and selecting ingredients is frequently a very personal experience for chefs and restauranteurs, but I can't help but think there could be some upside to facilitating volume pricing of certain ingredients for members within a particular region, not unlike how members of hobbyist electronics groups will organize group buys of components. If ingredients are a bridge too far, they might apply the same logic to more practical items—flatware, napkins, menus, and so forth.

<comment><USER5> > It occurs to me that x-sharing startups in the mold of Airbnb/Uber may be > most likely to overcome their regulatory challenges not through litigation > or lobbying, but simply due to more of them popping up and the increased > likelihood that the average person knows someone who has benefitted

I think there's something sublime about that. It seems the technology drives culture in many ways and it happens when an innovation goes viral and benefits people faster than the law can react.

Some technologies don't get the chance to do that. People see harms before they can feel the benefits and start to turn public opinion and law against the innovation. Segway's and Google Glass are in that category, I think.

</comment></comment><comment><USER6> What about zoning restrictions? Food service licenses? In many places, if you prepare food for sale to be consumed onsite, you are treated like a restaurant - most home kitchens aren't going to pass local health department requirements.

<comment><USER7> Many great new ideas aren't legal. Use your own car like a taxi? Rent your spare bedroom to strangers? Sell electric cars direct, without a dealer? Share music, books and movies with your friends? Run a mesh network in your city to bypass the local monopoly? Trade cryptocurrency for national currency?

Just because it's illegal doesn't mean it's not a killer idea.

Congratulations, Cozymeal!

<comment><USER8> In the case of unsanitary food preparation, it very well could be a killer idea.

By the way, none of those other ideas are illegal (in the US). Taxi drivers can own their own cabs; some do but most do not due to the expense of acquiring/maintaining an adequate vehicle. It's always been okay to rent your "spare bedroom" to strangers--just as long as you occupy the remainder of the unit (though whether your lease or HOA agreement allows this is a separate issue). Sharing your physical copy of an artistic work has always been allowed. Private mesh networks have never been illegal. Cryptocurrencies are legal forms of exchange (or in this context, "consideration") between two consenting private parties, just like _any other form of property._

</comment></comment></comment><comment><USER9> Feature request: Sort by distance. I don't live in SF so it would be nice to see things close to me first.

Edit: Also Facebook only sign in is a deal-breaker. I never use services where it's required.

<comment><USER10> My guess is that Facebook (or some other nearly ubiquitous account) will always be a requirement for this site since it's all about inviting people into your home.

</comment></comment><comment><USER11> Thank you for your comments and interest in Cozymeal. I am the co-founder of Cozymeal, which we launched three months ago. What started as a side project attracted a lot of interest and I am now working full-time on it.

The quality of the food and the experience in general are very important to us. Every host has to go through a vetting process before he can join our site.

Our guests use Cozymeal for the great food but also the amazing experience they get in terms of meeting new people and enjoying delicious food in a nice ambience without the unpleasant noise and rush you often have in restaurants.

Recently, some of our hosts started offering cooking classes which are also very popular.

<comment><USER8> You need to visit this page: [http://www.sfdph.org/dph/eh/Food/Permits/default.asp](http://www.sfdph.org/dph/eh/Food/Permits/default.asp). Then you need to talk to a lawyer and have a serious discussion about your liability issues (and the liability issues for your "hosts") and come up with a plan for helping your hosts understand just what they're getting into when they use your site to run a "one table restaurant."

You've created a cute site, but now that you're running it as a business that interacts with the real world you need to step up to the plate and treat it like a real business. And that means dealing with the unsexy stuff like licensing (for yourself or your hosts).

In two weeks, if you haven't added something to your site about this, I'm going to personally call the SF Department of Public Health myself.

<comment><USER12> Fuck you.

Seriously - the world is not as black and white as you would want it to be... we do not need regulation of every single little aspect of our lives.

Have you fucking eaten at restaurants in SF? Try Sam Woo you asshole - <USER2> place was an SF legend; and it was one of the most disgusting places.

<comment><USER13> Wow. What a terrible way to respond. First, opening with "fuck you" and calling another commenter an asshole is uncivil and drags the site down. Second, the insults you chose to hurl at the commenter are empty and boring; they're written solely for your benefit and not for any reader, including the commenter you're replying to. And if you're upset about the commenter's threat to call the health inspector, howling insults at them is (a) unlikely to change their mind and (b) certainly going to make this thread more memorable, lessening the chance that they'd simply forget to make good on the threat.

<comment><USER12> Dude,

Threatening someone on HN with "if you fail to do X Ill call and report you by Y date" deserves my response.

I stand by that comment. Your comment is written solely to make your self look so much "better" than me, is it not.

Get off your high-horse Patrick.

<comment><USER13> I'm just not sure what you're trying to accomplish. I read both your comments and those of the commenter you're replying to, regularly. Confidently: he doesn't care what you think.

<comment><USER12> So, I am NOT supposed to be concerned with what he thinks of my comment - <USER3> I am supposed to be sensitive to your qualms with the term "fuck you"?

Patrick, either you are on the side of me being able to voice my opinion, or you are in favor of me censoring it due to your, or some poster's, concern for sentiment.

I am concluded that you're more in favor of me being censored when you can have your apologist worldview unoffended and you can continue to feel morally high.

Look, we have never agreed on HN, I feel you are an apologist and you may feel I'm an extremist; but let me tell you one thing I am not: one who censors the opinions of others - I am one who engages another in my beliefs.

Why don't you take a stress pill, sit down calmly and think things over...

<comment><USER13> My name isn't Patrick.

<comment><USER12> hahaha

You are correct! My apologies - I have no idea why I typed that so many times, Bill.

<comment><USER14> Bill here. I agree that the expletive you used here is not appropriate.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Site seems down, but assuming it is meals at home with people, I like the concept. I wouldn't want to drop in to a dinner with a family or something, but if you did themed dinners ("crypto hackers dinner?" "YC applicants dinner") it would be both more appealing AND legally a lot safer -- even a heavy handed government would be wary of censoring free association and speech with incidental food, rather than purely commercial food.

<comment><USER11> The site is back now.

<comment><USER16> its still down for me :(

<comment><USER11> Yes, the site went down again. We are working hard on bringing it up. Sorry for the inconvenience.

</comment></comment></comment></comment><comment><USER17> The photography of the meals is spot on, could seem like a small thing but glad that you took a leaf from Airbnb's book to make sure that the meals are presented in the best possible way.

<comment><USER18> I second that, the photography is amazing!

</comment></comment><comment><USER19> It would be incredibly unfortunate if this were found to be illegal. You take many of the same health risks when eating at a friend's house. The only difference is you don't pay your friend.

<comment><USER8> The exchange of payment is precisely what makes this endeavor subject to food safety/preparation laws and (in many jurisdictions) illegal. It changes a social event into a commercial transaction: you pay someone else to eat food they prepared.

This is not remotely the same thing as friends splitting up the cost to buy food, or reimbursing one friend for purchasing food for a social gathering. We don't regulate social gatherings between friends because they have other means to deal with issues that could arise, even, if necessary, the tort system.

There are different expectations when dealing with commercial food transactions--and some of the major expectations are that the food be safe and prepared safely.

<comment><USER18> Without judging if it's a good thing or a bad thing, some of these services (e.g. Lyft in some cities) use "suggested donations" instead of payment. It changes the legal & tax consequences.

<comment><USER8> No, it really doesn't, especially not for tax purposes.

The law (and especially tax law) looks at the _substance_ of the transaction, not its form. Calling a payment for commercial services a "donation" doesn't make it a donation. If it did, every business would ask for "donations" instead of payment. Indeed, as a matter of tax law, calling the Lyft fees "donations" actually makes it worse for the drivers--they can't offset the "donation" income with their Lyft-related expenses. (Lyft can't recharacterize the donations it receives on behalf of the drivers as fee compensation when it remits payment to the drivers because it takes the position that they're independent contractors and it is merely acting as a collection agent.)

</comment></comment></comment></comment><comment><USER20> This is a very cool concept and I love how it can work together with AirBnB. If there were a similar platform for long-distance travel then I think the sharing economy will help people explore the world in amazing new ways. Not that ride-share and similar services don't exist, but some means to travel international would be amazing. But I can't even imagine the legal problems such a service would face.

</comment><comment><USER21> Genuinely awesome concept. I hope you find a way to make it work within food/zoning regs because I think this is much more positive and communal than many other 'sharing economy' ideas.

It'd be great if you could figure out a way to provide social trust that wasn't through a FB login though.

</comment><comment><USER22> Thanks for showcasing vegan dishes.

<comment><USER23> Also a filter for vegan only dishes will be great.

</comment></comment><comment><USER12> I AM IN!!!!

This is amazing, and my wife and I cant wait to try it.

We need to book a sitter and plan a date night around this.

They site should include the option to "book and Uber to and from"

</comment><comment><USER24> Does the site offer hosts/guests any protection (a la AirBnB) in case something goes wrong?

<comment><USER11> Cozymeal has a lot of safety mechanisms to ensure a safe and good experience for both sides (vetting of ALL hosts, mandatory Facebook registration for hosts/guests, etc.). In addition to that, Cozymeal will soon offer an insurance to hosts/guests similar to that offered by AirBnB.

</comment></comment><comment><USER25> The site seems to be down for me. Can someone describe what's it all about?

<comment><USER18> You can view one page here:

[https://web.archive.org/web/20140101130924/http://cozymeal.c...](https://web.archive.org/web/20140101130924/http://cozymeal.com/)

Hopefully the site will be back up soon :)

<comment><AUTHOR> Site is back up.

</comment></comment></comment><comment><USER26> Nice looking site. But sites like this are only continuing to influence the many public health worries that we face today. There is no nutritional information on any of the meals on this site! Just another social site, looking at the wrong aspect of health.

<comment><USER27> Meals have been social for much longer than they've been nutritionally quantified. IOW, we've shared food and community for thousands of years just fine without a list of nutritional facts for the buffalo or potatos we've eaten. I'd say this site is bringing things back to their roots, not focusing in the wrong direction.

</comment></comment><comment><USER28> Is this legal?

<comment><USER8> It's completely legal...as long as anyone who uses CozyMeal to run a food service business goes through the process of registering as a food service business. This largely means inspections to assess the cleanliness of the food preparation, storage, and delivery areas, and a liquor license if alcohol will be served.

</comment></comment><comment><USER29> hacker news broke the cozymeal :/

<comment><AUTHOR> It's back.

</comment></comment><comment><USER30> pretty cool concept, i like it</comment>


Ask HN: Hiring managers, what do you look for in a developer resume? - <AUTHOR> This is a question for both hiring managers and others involved in the decision making process for hiring. I'm curious as to what matters for you when you are looking at candidates' resumes. What are common mistakes you see? What makes a resume stand out in a good way? What makes a resume stand out in a bad way? <comment><USER2> Common mistakes:

1\. Over-focusing on technologies, rather than skills. ([https://codewithoutrules.com/2018/01/18/worst- resume/](https://codewithoutrules.com/2018/01/18/worst-resume/))

2\. Leaving out organizational context, project context. _Why_ did you do that? Why should I care?

3\. Leaving out outcomes. Don't just tell me what you did, tell me how awesome the results were!

So like "I wrote some software for the X project at company Y." Leaving out what company Y does, what the X project is, the fact that you worked alone on a really tight deadline and ended saving the company massive amounts of money.

<comment><USER3> > Over-focusing on technologies, rather than skills

For me, technologies actually help me contextualize how much experience the person has. When a resume says "fast learner" or "team player", well, everyone else will claim that too and it becomes somewhat of an empty claim in my mind. With that said, a bullet list of common technologies does tend to come across as a junior level of experience

> Leaving out organizational context, project context. Why did you do that? > Why should I care?

This is a good point. I would phrase it as "What was the purpose of the work". IMHO, there are two types of good answers, the ones that highlight the business impact, and the ones that tie in to code quality.

> Leaving out outcomes

Overall I agree, but I think there are some types of answers that raise flags, e.g. when the acccomplishment seems like the person might be claiming credit for the whole team's effort. Heroic stories might also be a sign of team friction.

<comment><USER2> > For me, technologies actually help me contextualize how much experience the > person has. When a resume says "fast learner" or "team player", well, > everyone else will claim that too and it becomes somewhat of an empty claim > in my mind. With that said, a bullet list of common technologies does tend > to come across as a junior level of experience

A list of technologies is just as easy to fake. So ideally it's "Because of X, in context Y, I did Z using technologies A, B, C." Rather than "I know A, B, C.".

<comment><USER3> I use it as a dunning-kruger sort of test. You can get a reasonable idea of skill level and areas of strengths if, for example, a resume only mentions Javascript/MySQL vs also mentioning Java/Hibernate or RabbitMQ/Docker

I definitely don't take a technology laundry list at face value, especially if I see something like 2 yrs experience and a list containing Swift, React, MongoDB and [insert fad technology here]

</comment></comment></comment></comment><comment><AUTHOR> I'll answer my own question first, but I'm interested in others' opinions. Some things I have noticed as a hiring manager / decision maker:

* I see a lot of resumes for inexperienced developers that go two to three pages. I understand that this might be the norm in other countries where a CV is more common than a resume, but in the US, if you have less than five years of job experience, I expect your resume to be one page (personally, I prefer this even if you have 5-10 years experience, but I can excuse it at that point. More than ~10 years and I think that having two pages is completely acceptable and maybe even preferred).

* Typos and obvious grammatical errors are big pet peeves of mine. I don't think developers need to have outstanding spelling or grammatical skills. I do think that developers need to be detail oriented enough to catch obvious (and hopefully non-obvious) issues in their code. If you demonstrate that you didn't catch obvious issues on a very important (for your career) two page document, then how can I trust that you'll catch obvious issues in your code? As an aside, if English isn't your first language, I'll be a little bit more lax in this area, but I still expect that you'll at least have an English speaking friend look over your resume for obvious issues.

* I don't like funky formatting. It's surprising how many resumes I see with fancy formatting, presumably because the writers of those resumes want them to stick out. What sticks out to me is a well formatted and well organized, text only, black and white resume with good content.

* Take out things that are irrelevant to the job. This is especially true if your resume is over one page. For example, if you have a bachelor's degree in CS, I really don't care where you went to high school or that you were the captain of Model UN while you were there.

<comment><USER3> > Take out things that are irrelevant to the job

I would also say that these reflect poorly on the candidate:

\- listing hobbies \- personal website (good candidates don't need to pad their resumes with one) \- links of poor quality. It's a turn-off to see a link to github full of forks of learning material from code schools, or a twitter account that is talking about overwatch.</comment></comment>


Where to Learn HQL? - <AUTHOR> <comment><USER2> [https://www.waytoeasylearn.com/2016/06/hibernate-query- langu...](https://www.waytoeasylearn.com/2016/06/hibernate-query-language- hql.html)

maybe?

</comment><comment><USER3> If You find suggest me also.

<comment><AUTHOR> Surely</comment></comment>


Accumulating 'microplastic' threat to shores - <AUTHOR> http://www.bbc.co.uk/news/science-environment-16709045

<comment><AUTHOR> A few years ago I walked along an ocean beach and digging down into the 'sand' found that it was actually very small fragments & grains of plastic that had accumulated to a depth of at least six inches on this particular beach. Having read about the Great Pacific Garbage Patch, I found first-hand about the on- shore impact on this beach and the native flora and fauna along the coastline.

I've thought about possible solutions and start-up opportunities since to help tackle the problem, but the problem is so huge, wide-spread and cost intensive, that the solutions I've come up with so far pale into insignificance of any viable and, at a minimum, break-even options.

FYI, the academic article, for non-subscribers/academics, costs US$35.</comment>


Show HN: Replacing WordPress with GitHub Issues-like Blog Comments - <AUTHOR> https://dmitri.shuralyov.com/blog/23#comment-0 <comment><USER2> The original [https://news.ycombinator.com/item?id=14170041](https://news.ycombinator.com/item?id=14170041) was much more about how Disqus was awful, not much about how GitHub Issues comments are a great solution. They're not. There are much better solutions than GitHub Issues comments.

<comment><AUTHOR> That's true, Discus is pretty bad. That said, I really enjoy GitHub Issues- like comments. They're simple and get the job done just right.

<comment><USER2> But you need the commenter to have a GitHub account.

Yeah, that's not too bad anyway. Otherwise you would need them to have an account on your site, or on Disqus.

<comment><AUTHOR> Yep. My target audience has a GitHub account already, and I'd rather not force them to create yet another account on my personal site just to comment or leave a reaction.

It also works well as a quality filter. People with a GitHub account will be much more responsible with their words, compared to anaonymous posters or throwaway accounts, since they have a professional reputation to maintain.

<comment><USER3> And it rules out those pesky commenters that care about things like privacy and avoiding the centralization of open source development and shoveling everything into 'the cloud'.

<comment><USER4> Now that's a feature I'd get behind: the ability to select out people I'd rather not talk to.

The one you mention is a nice positive effect.

</comment></comment></comment></comment></comment></comment><comment><USER5> I made the same with Hacker News comments: [https://comments.network/](https://comments.network/)

Just add it and get automatic comments from HN right in your blog/page. However I'm discontinuing it soon after HN asked me to do so, but it shouldn't be too difficult for anyone motivated to do their own.

<comment><USER6> If HN asked you to discontinue it, shouldn't others avoid doing it also?

<comment><USER5> IANAL. IMHO That is up to each individual's decision. I actually asked them and they said they really don't want other people to embed comments on their website. BUT a case could be made about fair use, embedabble content and the fact that there is no effective terms and conditions on HN, just a FAQ (so I think they don't have the exclusive copyright of the comments). Plus the whole YCombinator ethos of asking for forgiveness instead of permission.

So I am discontinuing it just because HN is awesome and they asked nicely. But other people might consider things differently.

<comment><USER7> But I guess he meant morally, rather than technically.

<comment><USER5> And who am I to judge the morality of other people in different cultures? What is legal and moral in a country is totally dependent on the culture and many times it has little to do with legality.

</comment></comment></comment></comment></comment><comment><USER8> I'd be tempted to use Firebase as a backend instead: simple integration with the browser, built-in auth using facebook, google and others, and no need to create a github issue for each post.

<comment><USER9> That sounded logical, so I searched a bit, and there's several good resources. The two that stood out to me:

This article goes through making a very basic interface, and is easy to follow...ended with 31 lines of js. It isn't production ready, but was a good intro: [https://css-tricks.com/building-a-jekyll-site- part-3-of-3/](https://css-tricks.com/building-a-jekyll-site-part-3-of-3/)

Then, a more complete implementation. Hasn't been updated for a few years, but has markdown support, up/down voting, flagging, etc: [https://commented.github.io/](https://commented.github.io/)

</comment></comment><comment><USER10> It's great... the only drawback is that the solution is exclusive to GitHub users only.

<comment><AUTHOR> Thanks. That's the case now, but it doesn't have to be.

I could add Google, Facebook, my own accounts (username/password), or other ways for people to authenticate with.

I chose not to do that, and stick with GitHub auth only for now, because it covers my current needs. My target audience mostly has an account on GitHub. Also, when a website has many ways to login, it's hard to remember which you've used previously.

</comment></comment><comment><USER11> I'm still focused on delivering comments from a client side option, so that my site can be delivered using a static approach. Disqus is a bit bulky but does meet that requirement still.

</comment><comment><USER12> Smart idea - got me curious about what else I can do with the github api

<comment><USER13> Besides the login, this isn't using the GH API at all for what it's worth.

<comment><AUTHOR> This is true.

Package githubapi uses the GitHub API [1], but that package is not currently used on my site.

[1] [https://godoc.org/github.com/shurcooL/issues/githubapi](https://godoc.org/github.com/shurcooL/issues/githubapi)</comment></comment></comment>


Tier One: C++ Beginner's Guide - free before December 31, 2010 - <AUTHOR> http://msdn.microsoft.com/en-us/beginner/cc305129.aspx

<comment><USER2> Note: it is from Herbert Schildt. This name should ring a bell for many competent C or C++ programmers, as the technical quality and accuracy of his books are frequently disputed, and for many regarded as synonymous of bad quality.

<comment><USER3> some in depth points on that criticism.

<http://www.developerdotstar.com/community/node/781>

disclaimer, i haven't read the book. but if teaching cpp while he was really teaching C was his crime, than i will probably be on his side when i do read the book :)

<comment><USER4> That's considerably less in-depth than the criticism itself. The post you linked is mainly complaining about how mean some people were to Schildt and brushes aside the criticism on the basis that Schildt had good intentions. You'll notice that he tries to link the widespread criticism of Schildt's books (I mean, it's in the "learn C" newsgroup FAQ) with some anonymous trolls' death threats against blogger Kathy Sierra. It's basically the "LEAVE BRITNEY ALONE!" of the programming world.

I also think that post's phrasing has confused you. When he says "teaching C in practice," he doesn't mean teaching C-isms in a C++ book — he means C as it is (incorrectly) used in practice, such as teaching implementation-dependent assumptions and pretending that they're part of the standard, as well as simply wrong code that might appear to work right "in practice" in certain situations. For example, his "Annotated ANSI C Standard" stated that void main(void) was a valid main function and that padding only appears at the end of structs.

</comment></comment></comment><comment><USER5> So c-style arrays and strings (and the C string functions) are discussed in chapter 4, exceptions and templates are chapter 12 "advanced topics", and in the discussion of arrays you're encouraged to write your own array class if you need bounds checking.

I don't see mention of std::vector (which has .at() for bounds-checked access) or std::string , maybe I just missed it not reading very thoroughly.

I don't think I like this book, it seems to encourage some rather bad practices...

</comment><comment><USER6> Avoid this book and get Scott Meyer's _Effective C++: 55 Specific Ways to Improve Your Programs and Designs_ instead:

[http://www.amazon.com/Effective-Specific-Improve-Programs- De...](http://www.amazon.com/Effective-Specific-Improve-Programs- Designs/dp/0321334876/)</comment>


List of acquisitions by Google since 2001 - <AUTHOR> http://en.wikipedia.org/wiki/List_of_acquisitions_by_Google <comment><USER2> This is probably a very incomplete list. I've heard they've been buying several per month. Most are so small they don't have to disclose them.</comment>


Managing Memory in Javascript is Hard - <AUTHOR> http://polarmobile.com/blog/2013/5/managing-memory-in-javascript-is-hard

<comment><USER2> And to confuse things further, we'll provide examples in Coffeescript?

To be fair, they do link to some JS conversion thing, but I'd prefer to read the examples right in the article - "don't make me think" and all that.

<comment><USER3> Yeah, especially because Coffeescript can be very liberal with creating objects if you don't know exactly what you (and coffeescript) are doing.

edit: Disclaimer: I have written and am still occasionally writing canvas rendering stuff in coffeescript and after some meddling around with some annoying bits it has been quite pleasant. For example you should make sure that functions that don't need to return anything, return false or null or undefined. Otherwise coffeescript will return whatever your last statement evaluates to. This is especially bad if the last thing is a loop.

<comment><USER4> CoffeeScript doesn't actually create any objects you're not telling it to do so. It does return the value of the final expression, but you placed that expression there to be executed. Its value will be returned and that might cause it to remain reachable for some additional time, but the value was created by your expression, not by CoffeeScript's return semantics.

</comment></comment></comment><comment><USER5> I still have nightmares about memory management in JavaScript following an unfortunate project involving a very media-rich application running on Vizio TVs with "Yahoo Widgets for Connected TVs" (a non-HTML JavaScript app framework that derives from the old Konfabulator).

Not only do you have all the usual issues with JavaScript and memory, but the amount of RAM available is tiny and the garbage collector is run on a set timer and if you blow your memory budget between these timed calls to the garbage collector, the program soft crashes (you'd think an emergency gc would be scheduled if memory pressure were that high -- you'd be wrong!). Even if you were very careful to set unused objects to undefined or explicitly delete them, the memory those objects took still counted against you because of the timed gc system. Object pooling was absolutely required but even then you had to be very careful not to blow your memory budget.

The 'soft crash' would result in a situation where the app and overall runtime is still running but the state of the software is no longer reliable until you _reboot the TV_. And none of this stuff (the timed gc, etc) was documented at all, and there's little to no active community for "Yahoo Widgets" so you basically had to figure this all out on your own.

</comment><comment><USER6> Managing memory in ECMAscript is hard.

These are the same problems from Actionscript (I know the crowd here has no love for AS though).

</comment><comment><USER7> Most folks probably write JavaScript for the browser.

Not only should you consider using object pooling for JS objects (like the author describes), but you also want to think about DOM element pooling, especially when you are dealing with large lists.

<comment><USER8> DOM element reference cacheing (and pooling) can significantly improve the responsiveness of very busy browser UI code (particularly in loops that make many DOM queries and/or updates) and can make the code more readable too, but be careful as you can create memory leaks especially in "classic" IE. Such leaks only tend to last as long as until the user navigates away, but they can become significant for single-page applications.

<comment><USER9> In many cases they can exist until the iexplore browser process terminates.

</comment></comment></comment><comment><USER10> I would love to know if using emscripten will make memory usage more deterministic.

</comment><comment><USER11> why is Jay Kay from Jamiroquai teaching memory management?</comment>


Comments are back on my blog: Disqus is the best - <AUTHOR> http://bobbelderbos.com/2011/12/comments-back-on-blog-disqus/

<comment><USER2> "the best" compared to...?

<comment><AUTHOR> I mainly compare it to Facebook comments which disappointed me a bit</comment></comment>


Mark Zuckerberg Plans 200 Acre Zee-Town for Its 10,000 Employees - <AUTHOR> http://www.techtimes.com/articles/34642/20150223/mark-zuckerberg-plans-200-acre-zee-town-for-its-10-000-employees-with-help-of-architect-frank-gehry.htm

<comment><USER2> I was pretty excited to read some more information about this development which was first discussed back in 2013 [1], but I haven't really been able to find any new information because the original story is paywalled [2].

One annoying thing about all of the articles is that they all use old press images of Gehry and Zuckerberg looking at models of the new Facebook campus rather than the discussed apartment complex which is misleading for people unfamiliar with the campus' design.

EDIT: For those interested, here's 'West Campus' under construction. It will connect to the main campus via a converted drainage under the 84 parallel to Willow Road: [http://binged.it/1zDxmE0](http://binged.it/1zDxmE0)

[1]: [http://newsfeed.time.com/2013/10/04/facebook-building-its- ow...](http://newsfeed.time.com/2013/10/04/facebook-building-its-own- apartment-complex-so-employees-never-ever-have-to-leave-work/)

[2]: [http://www.thesundaytimes.co.uk/sto/news/world_news/Americas...](http://www.thesundaytimes.co.uk/sto/news/world_news/Americas/article1522281.ece)

</comment><comment><USER3> This sounds about the right level of crazy for Zuck, but he's got a pretty good track record for crazy.

This would be more crazy and less meaningful if there was worthwhile city planning happening on the peninsula, but check out traffic patterns, population density and public transit. Also look at where the FB campus is. That area needs any help it can get.

</comment><comment><USER4> Starting to sound like the book "The Circle" [http://www.amazon.com/The- Circle-Dave-Eggers/dp/0345807294](http://www.amazon.com/The-Circle-Dave- Eggers/dp/0345807294).</comment>