The Makefile I use with JavaScript projects - <AUTHOR> http://www.olioapps.com/blog/the-lost-art-of-the-makefile/ <comment><USER3> I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on using make with files with spaces in their names is simply "don't even try." In the 21st century, this is not an acceptable answer.

<comment><USER4> Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches.

I hate hearing people using 21st century or modern as reasons for inflating complexities. Without rein on complexity (whether it is hidden or not), the future is doomed, whatever you are building. While I am not saying we should avoid complexity at all cost, I am insisting that all complexity should be balanced with merits.

The merits of filenames with spaces is they read better in a GUI explorer. Whether that merit balances out all the complexity it brings is individual dependent. For me, that merit ranks very low and I avoid spaces in my filenames at all opportunities. For some, they need those filenames to be readable. And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Another solution would be to add an additional pre-step of copying/renaming/linking/aliasing. With the latter solution, the complexity is confined.

I guess for some, it only matters with "I do work" or "they do work" rather than the big picture. That is fine. However given the context of you are working with Makefiles, then you are a developer at some level, you are supposed to do some work.

<comment><USER5> > And there are solutions. One solution, from those who don't code, seems to > demand ("developers", paid or not) that every tool that deal with files > should handle this additional complexity, regardless of their context and > what they think.

Users expect computers to work in a non-surprising ways.

It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one more way that computers are scary and unpredictable.

Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years.

<comment><USER4> > Meanwhile over in Windows land, all tools have been expected to deal with > spaces in them for what is approaching 20 years.

That is an excellent example that deserves a second look from a different aspect.

... it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. They are scared of computers more than ever. They are very scared of it and having it heavily disguised as an appliance is mandatory.

<comment><USER5> > it has trained a crop of computer users that are afraid of command lines and > with an attitude of anything beneath the GUI interface is owned by and of > someone else's problem.

There is nothing beneath the Windows UI interface. The GUI is the primary subsystem of Windows, the command line is a separate subsystem. Windows has traditionally been built up around the Win32 API, which is GUI first.

It is of course possible to do things from the command line, and some advanced stuff may need the command line, but users should never need to drop out of the UI unless something has gone horribly wrong.

The Windows UI is incredibly powerful, with advanced diagnostic and logging capabilities, incredible performance monitoring tools, and system hooks everywhere that allow the entire UI to be modified and changed in almost any way imaginable.

The way Services work on Windows is not some (hotly debated) config files. It is through a UI. Management of hardware takes place through a UI. Pretty much everything short of running Ping has a UI around it.

I love the command line, if I am developing it is how I primarily work. And while doing so, younger devs look at me like I am crazy because they have customized the living daylights out of their UI tools (VS Code, Atom), to do amazing things that exceed what a command line can do, and of course those editors have a command line built in for when that is the best paradigm!

> and having it heavily disguised as an appliance is mandatory.

Something working so well that it becomes an appliance isn't a bad thing. It means the engineers who made it have put in so many fail safes and worked to make the code of high enough quality that it doesn't fall apart around itself all the time.

Heaven forbid I can upgrade my installed software and not have some random package break my entire system.

<comment><USER4> > There is nothing beneath the Windows UI interface.

To clarify, beneath the GUI interface is the actual code that implements that interface.

> Something working so well that it becomes an appliance isn't a bad thing.

Not at all. I don't attempt to call or think my phone as an computer. Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances. It is just that there are still a big camp of people who use a computer as computer. That causes some confusions in the communication between.

<comment><USER5> > Window's users, on the other hand, still call their PC computers. I guess > that is ok if computers are appliances.

It seems that 90% of computer use has moved into the web browser. Heck outside of writing code, almost everything I do is in a browser, and my code editor of choice happens to be built as fancy skinned web browser...

> To clarify, beneath the GUI interface is the actual code that implements > that interface.

I'd say that everything moving onto the web has once again made the code underneath it all accessible to the end user, if they so choose.

(Ignoring server side)

<comment><USER6> > It seems that 90% of computer use has moved into the web browser.

This is an extremely (web) developer-centric viewpoint IMHO.

Try telling 3D modellers/sculptors, games programmers, audio engineers that 90% of their computer use has moved into a browser. They will look at you with a blank face since they all require traditional "fat" desktop apps to get their work done at professional level.

And those are just the examples I can find off the top of my head, I'm sure I could think of more.

<comment><USER7> Do all of those computer users constitute more than 10% of computer users? I don't think there's even 5% of computer users there.

Talking about 3D modelling, game programming and producers like they're the majority is a technologist-centric view.

Most computer use is by people who think the web is the internet and use 'inbox' as a verb.

<comment><USER6> > Do all of those computer users constitute more than 10% of computer users? I > don't think there's even 5% of computer users there.

So as stated that was the list of the top of my head. I just pulled from my personal list of hobbies, things that I use a computer for other than programming or automation.

Within 50 feet of me at work there are a whole bunch of electrical engineers who spend 90% of their time in some fat app for designing, I dunno, telco electrical stuff.

In the fishbowl next to that, are 50 network operations staff who spend 90% of their day in "fat" network monitoring applications.

I'm just pointing out if you look far enough there are plenty of people using apps outside a web browser for their daily work and hobbies.

In my nearly 25 career in IT I have never heard people use 'inbox' as a verb (as in 'inbox me?'). Sure some people must say it sometimes, but I think this is overstated and another example of programmer cliche or hyperbole.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I think the reason make is both so controversial and also long-lived is that despite how everyone thinks of it, it isn't really a build tool. It actually doesn't know anything at all about how to build C, C++, or any other kind of code. (I know this is obvious to those of us that know make, but I often get the impression that a lot of people think of make as gradle or maven for C, which it really isn't.) It's really a workflow automation tool, and the UX for that is actually pretty close to what you would want. You can pretty trivially just copy tiresome sequences of shell commands that you started out typing manually into a Makefile and automate your workflow really easily without thinking too much. Of course that's what shell scripts are for too, but make has an understanding of file based dependencies that lets you much more naturally express the automated steps in a way that's a lot more efficient to run. A lot of more modern build tools mix up the workflow element with the build element (and in some cases with packaging and distribution as well), and so they are "better than make", but only for a specific language and a specific workflow.

<comment><USER9> > It's really a workflow automation tool,

That's true.

> and the UX for that is actually pretty close to what you would want.

That is so not true. Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. That's often true for builds (which is why make works reasonably well for builds), but often not true for other kinds of workflows.

But regardless of that, a tool that makes a semantic distinction between tabs and spaces is NEVER the UX you want unless you're a masochist.

<comment><USER10> > but often not true for other kinds of workflows.

Examples? I mean, there are some broken tools (EDA toolchains are famous for this) that generate multiple files with a single program run, which make can handle only with subtlety and care.

But actual tasks that make manages are things that are "expensive" and require checkpointing of state in some sense (if the build was cheap, no one would bother with build tooling). And the filesystem, with its monotonic date stamping of modifications, is the way we checkpoint state in almost all cases.

That's an argument that only makes sense when you state it in the abstract as you did. When it comes down to naming a real world tool or problem that has requirements that can't be solved with files, it's a much harder sell (and one __not __treated by most "make replacements", FWIW).

<comment><USER9> > Examples?

Anything where the relevant state lives in a database, or is part of a config file, or is an event that doesn't leave a file behind (like sending a notification).

<comment><USER10> Like, for example?

To be serious, those are sort of contrived. "Sending a notification" isn't something you want to be managing as state at all. What you probably mean is that you want to send that notification once, on an "official" build. And that requires storing the fact that the notification was sent and a timestamp somewhere (like, heh, a file).

And as for building into a database... that just seems weird to me. I'd be very curious to hear about systems that have successfully done this. As just a general design point, storing clearly derived data (it's build output from "source" files!) in a database is generally considered bad form. It also introduces the idea of an outside dependency on a build, which is also bad form (the "source" code isn't enough anymore, you need a deployed system out there somewhere also).

<comment><USER11> I need to send an email every time a log file updates, just the tail, simple make file:

      send: foo.log
              tail foo.log | email

      watch make send

Crap, it keeps sending it. Ok, so you work out some scheme involving temporary files which act as guards against duplicate processing. Or you write a script which conditionally sends the email by storing the hash of the previous transmission and comparing it against the hash of the new one.

That last option actually makes sense and can work well and solves a lot of problems, but you've left Make's features to pull this off. For a full workflow system you'll end up needing something more than files and timestamps to control actions, though Make can work very well to prototype it or if you only care about those timestamps.

</comment></comment></comment></comment></comment></comment><comment></comment><comment>====

Another issue with Make is that it's not smart enough to know that intermediate files may change without those changes being important. Consider that I change the comments in foo.c or reformat for some reason. This generates a new foo.o because the foo.c timestamp is updated. Now it wants to rebuild everything that uses foo.o because foo.o is newer than those targets. Problem, foo.o didn't actually change and a check of its hash would reveal that. Make doesn't know about this. So you end up making a trivial change to a source file and could spend the afternoon rebuilding the whole system because your build system doesn't understand that nothing in the binaries are actually changing.

<comment><USER10> How would you fix that with your preferred make replacement? None of that has anything to do with make, you're trying to solve a stateful problem ("did I send this or not?") without using any state. That just doesn't work. It's not a make thing at all.

<comment><USER11> Lisper was replying to the OP who suggested using Make for general workflows. Make falls apart when your workflow doesn't naturally involve file modification tasks.

With regard to my last comment (the problem with small changes in a file resulting in full-system recompilation), see Tup. It maintains a database of what's happened. So when foo.c is altered it will regenerate foo.o. But if foo.o is not changed, you can set it up to not do anything else. The database is updated to reflect that the current foo.c maps to the current foo.o, and no tasks depending on foo.o will be executed. Tup also handles the case of multiple outputs from a task. There are probably others that do this, it's the one I found that worked well for my (filesystem-based) workflows.

With regard to general workflows (that involve non-filesystem activities), you have to have a workflow system that registers when events happened and other traits to determine whether or not to reexecute all or part of the workflow.

<comment><USER12> I mean you're just describing make but with hashes instead of file modification times. It's probably the most common criticism of make that its database is the filesystem. If file modification times aren't meaningful to your workflow then of course make won't meet your needs. But saying the solution is 'make with a different back-end' seems a little silly, not because it's not useful, but because they're not really that different.

GNU make handles multiple outputs alright but I will admit they if you want something portable it's pretty hairy.

</comment></comment></comment></comment><comment><USER13> Thank you. It's nice to know that I'm not alone in this dark, dark world.

It's so depressing when people use arguments like "it's old", "it uses tabs", and "it's hard to learn". As described by one Peter Miller, "Make is an expert system". If a tool is the most powerful, standard, and expressive among its peers, its age or the fact that it uses tabs should be inconsequential.

If anything, the fact that it's decades old and used in every major software project is a testament to its effectiveness, not a drawback.

And if "learning Make" is a barrier, that to me is a sign that someone cares more about complaining than about their project. The same way people learn Git when it's clear that it's the best tool, people learn Make. It really isn't that hard. Even the basics are enough to reap huge benefits immediately.

<comment><USER14> The tools are not the same on every platform. That's reason enough for me to not use it with my JavaScript projects.

The bigger reason though is that it's not very idiomatic for JavaScript projects to use Make. It sounds like the only reason that some people go out of their way to use it is because they actually don't want to learn something.

<comment><USER13> > "The tools are not the same on every platform."

Any common examples?

> "It's not very idiomatic for JavaScript projects to use Make."

While I agree that popularity is a factor in picking a tool, it shouldn't be a deciding factor. Going by popularity is precisely how we end up with a new Build System of the Year(TM) every few years. The fact that we've gone through 4 fairly prominent tools (Gulp, Grunt, Broccoli, Webpack), all of which contending to "fix" the previous, and none of which have proper DAG or incremental builds (which Make has had for decades) is damning evidence.

In other words, I think Make could be (and I wish it was) idiomatic for JS.

<comment><USER14> This comment points out the kind of problems that can occur just on Unix systems - [https://news.ycombinator.com/item?id=16485637](https://news.ycombinator.com/item?id=16485637)

And then there's Windows...

Anyway, the fact that things change quickly in JS-land is more of a testament to how popular it is than anything else IMO. If C were used in the same environments as JS, I'm sure that you'd see just as much churn.

<comment><USER15> C is used in a lot of platforms.

Js only in the browser (thankfully mostly converged) and in node.

<comment><USER14> JavaScript is in the server, browser, mobile apps, desktop apps and embedded devices.

Basically, it's used everywhere that C is used and then some.

<comment><USER13> > "Basically, it's used everywhere that C is used and then some."

It's the other way around. Every JavaScript program is run by a C/C++ program.

<comment><USER16> But if you consider browsers to be a "platform", which I think they are in fairness, then the GP comment could still apply. Whether the browser is written in C is pretty irrelevant to whether it can host it.

<comment><USER13> I conjecture that an upper-level "platform" that's on top of a lower-level "platform", for some definition of "platform", will be less varied and fragmented than the lower-level one.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Make's interface is horrible. Significant tabs. Syntax which relies on bizarre punctuation... If only whoever authored Make 40 years ago had had the design acumen of a Ken Thompson or a Dennis Ritchie!

We're stuck with Make because of network effects. I wish that it could just become "lost" forever and a different dependency-based-programming build tool could replace it... but that's just wishful thinking. The pace of our progress is doomed to be held back by the legacy of those poor design decisions for a long time to come.

<comment><USER18> Make is such a horrifically awful thing to work with that I just end up using a regular scripting language for building. Why learn another language with all its eccentricities and footguns when I already know several others?

<comment><USER19> This is why I like redo; it handles all of the dependency stuff for you, but your build scripts are written in pure sh

<comment><USER20> always been curious about redo. which variant do you use, and what do you use it for?

<comment><USER19> I use apenwar's because I installed it a long time ago and haven't needed anything more; it does look like it may be abandoned though.

I use it for anything where I need job scheduling around creating output files; even my DVD ripping is managed with redo calling into ffmpeg.

</comment></comment></comment></comment></comment><comment><USER21> After going through a few build systems for Javascript, I realized they were all reinventing the wheel in one way or the other, and pulled out venerable Make from the closet. It turned out to be way more expressive and easy to read.

One target to build (prod), another to run with fsevents doing auto-rebuild when a file is saved (instant gratification during dev), then a few targets for cleaup & housekeeping. All said, the file is 1/4 the size of any other JS- based build systems.

<comment><USER22> The reason I don't like doing this is portability. Since the steps within the makefile are going to be run through a shell, it is going to behave differently on different systems.

If your makefile fixes up a file using sed and your system has gnu sed, your makefile may fail on a system with BSD sed (e.g., a mac). If you rely on bash- isms, your makefile may not work on a debian system where it will be run with dash instead of bash. And so on.

<comment><USER23> I say, you JS guys doth protest a bit too much.

If you look in your package.json, you'll surely see a dozen or so "scripts" lines that run through the same shell that make does and have all the problems you just mentioned.

I'd also like to point out that Linux and almost certainly your production environment (because it's most likely *ix) will be case sensitive. Your macOS or Windows file system? Not so much. Point is, you're already up to your neck in portability issues. My macOS coworkers often forget this detail.

<comment><USER22> If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases. That is totally different than writing a line of script that only you have ever run and assuming that because it works on your laptop, it will run everywhere.

<comment><USER23> > That is totally different than writing a line of script that only you have > ever run and assuming that because it works on your laptop, it will run > everywhere.

huh?? No it's not. That's the whole discussion we are having now. I even specifically mentioned my macOS coworkers who develop on their Mac and are oblivious to case-sensitivity issues. Because "it worked for me."

> If an external package has scripts in it, those scripts have very likely > been run by somebody on a mac and somebody on linux and worked in both > cases.

Oh, I'd love for that to be true. But also not what I was referring to. Most large projects have a "scripts" section and those are no different than Makefile commands. If you're paranoid about your own Makefiles then you're going to need to be paranoid about your own package.json.

</comment></comment></comment></comment></comment><comment><USER24> The author forgot some great features of make:

* Parallel execution of build rules comes for free in a lot of implementations. This is really noticeable when you do heavy asset pre-processing.

* Cleanly written build rules are re-usable across projects as long as those projects have the same structure (directory layout).

* Cleanly written build rules provide incremental compilation/assembly for free: You express intermediate steps as targets and those are "cached". I put the "cached" in quotes here, because you essentially define a target file which is regenerated when it's dependencies are updated. Additional benefit: Inspection of intermediate results is easy - they are sitting there as files right in your build's output tree.

<comment><AUTHOR> Thank you for these points! I think that parallel execution is especially appealing. I edited the article to mention that.

</comment></comment><comment><USER25> Yes! I recently used Make on some JS projects and my coworkers looked at me like I was insane. Even if you don't know advanced Make-fu it's a really good way to run all of your build steps in the right order without some crazy JSON config format.

</comment><comment><USER26> The only build systems that I'm aware of that are monadic are redo, SCons and Shake-inspired build systems (including Shake itself, Jenga in OCaml, and several Haskell alternatives).

One realistic example (from the original Shake paper), is building a .tar file from the list of files contained in a file. Using Shake we can write the Action:

        contents <- readFileLines "list.txt"
        need contents
        cmd "tar -cf" [out] contents

There are at least two aspects I'm aware of that increase the power of Make:

\- Using `$(shell cat list.txt)` I can splice the contents of list.txt into the Makefile, reading the contents of list.txt before the dependencies are parsed.

\- Using `-include file.d` I can include additional rules that are themselves produced by the build system.

It seems every "applicative" build system contains some mechanism for extending its power. I believe some are strictly less powerful than monadic systems, while others may turn out to be an encoding of monadic rules. However, I think that an explicitly monadic definition provides a clearer foundation.

[http://neilmitchell.blogspot.com/2014/07/applicative-vs- mona...](http://neilmitchell.blogspot.com/2014/07/applicative-vs-monadic- build-systems.html)

</comment><comment><USER27> I use Automake and Autoconf (which generates the Makefile) for GNU ease.js:

[https://git.savannah.gnu.org/cgit/easejs.git/tree/Makefile.a...](https://git.savannah.gnu.org/cgit/easejs.git/tree/Makefile.am) [https://git.savannah.gnu.org/cgit/easejs.git/tree/configure....](https://git.savannah.gnu.org/cgit/easejs.git/tree/configure.ac)

The nice thing with using Automake is that it gives all the standard build targets with little additional effort (for example, `make dist` for producing the distribution tarball, and `make distcheck` for verifying that it's good).

I use a much simpler one for a project at work:

[https://gitlab.com/lovullo/liza/blob/master/Makefile.am](https://gitlab.com/lovullo/liza/blob/master/Makefile.am) [https://gitlab.com/lovullo/liza/blob/master/configure.ac](https://gitlab.com/lovullo/liza/blob/master/configure.ac)

</comment><comment><USER28> The concepts behind make are quite good, but the interface it provides is not decidedly not. It reminds me of Git in that respect. I'd think replacing the opaque symbols used everywhere with more descriptive words would be helpful. I don't suppose anyone knows if modern Make versions support alternatives to $@, $%, $?, etc. that can be read rather than memorized?

<comment><USER29> You _could_ do something like this:

       make -f- << sed 's/MAKE_TARGET/\$@/' Makefile.descriptive

But for the sake of compatibility I wouldn't.

<comment><USER30> No need for ugly sed error-prone trickery.

Use on the Makefile:

        MAKE_TARGET := /some/path

And invoke

        $ make MAKE_TARGET=/other/path

<comment><USER31> His point was that all of $@, $%, $? have more descriptive names as well, you don't need to use these single character macros.

Also you probably meant ?= instead of := as the command you gave would still use /some/path instead of /other/path if you use :=.

</comment></comment></comment></comment><comment><USER32> I have used make for years and am very familiar with it. My two major complaints are:

1\. The assumptions that it makes. Everything in and out are files (phony files notwithstanding). It is hard and painful if you want outputs to rely on and rebuild from configuration in the makefile itself. It's not impossible to implement, but it's difficult to _precisely_ implement it: often times I've seen systems that just rebuild everything after configuration changes.

2\. The mix of declarative and imperative styles, while useful for quickly throwing a build together, gets difficult to deal with as things scale up. The make language itself is pretty restricted, too (without using $(eval)).

I know that recent versions support guile extensions and even C(/C++?) extensions, but at that point it's not giving you all that much. I have often wished the make functionality was exposed in some "libmake" for me to extend.

For this reason (and others), I've recently refactored a huge build system to use shake[1] instead. Now builds are precise and correct, and properly depend on configuration and build environment.

[1]: [https://shakebuild.com/](https://shakebuild.com/)

<comment><USER33> That is not portable make, rather GNU Make.

<comment><USER32> Very true, thanks for clarifying. FWIW most of my stuff is portable make...

</comment></comment></comment><comment><USER34> > The target name `all` is special: When you run make with no target specified > it will evaluate the `all` target by default.

This doesn't appear to be true, at least on GNU Make 3.81 (MacOS). Rather, the _first_ target listed is the one that gets built on `make` with no arguments.

</comment><comment><USER35> I'm baffled at the amount of debate in this thread. Make is good for tasks that can be expressed as a directed acyclic graph of steps, where the steps' inputs and outputs are files, and steps can be expressed in a few lines of shell script. It works pretty well for such tasks in my opinion. Yes, it will look contorted for tasks that don't fit this model.

</comment><comment><USER36> I use Makefiles extensively for Docker, all sorts of individual projects (it's much easier to "make serve" than remember the specific invocation for getting a dev server up when you use multiple programming languages) and, of late, for Azure infrastructure deployments:

\- [https://github.com/rcarmo/azure-docker-swarm- cluster/blob/ma...](https://github.com/rcarmo/azure-docker-swarm- cluster/blob/master/Makefile)

\- [https://github.com/rcarmo/azure-acme- foundation/blob/master/...](https://github.com/rcarmo/azure-acme- foundation/blob/master/Makefile)

<comment><USER37> i (and people at work) do the same thing! i find it really easy to work with docker/k8s/helm/compose with Makefiles.

one tip -- remember to use .PHONY on your targets -- [https://www.gnu.org/software/make/manual/html_node/Phony- Tar...](https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html)

</comment></comment><comment><USER38> I started my career with C++ development and never used a direct makefile in any of my projects. When I write C/C++, I use CMake. My current job has me programming in Go where people seem to love makefiles, but I consistently find bugs in the implementation (usually has too many phony targets, etc.), Why don't people use makefile generators outside of the C/C++ community?

<comment><USER39> I don't use CMake for embedded systems because the syntax and options are even more obtuse for what I need to do with it. When I get down to it, every make- based build system I've ever used boils down to using the macro language to generate all the targets, and then building your output board image by dependencies. But it's the details of how to do this that vary widely depending on your application for the board.

CMake does a great job of compiling executable code and linking it using your compiler of choice, but where it falls flat is in giving me a convenient mechanism for fitting that executable into the system image.

<comment><USER40> It sounds like you are looking for something like Yocto/OE, which you can bake pretty much any build script into, cross compile and deploy.

What exactly are you looking for with regards to deployment, and what tool do use, instead of CMake, to give you that ability?

<comment><USER39> Can Yocto or CMake build QNX systems or bare-metal binaries with TI's compiler? The tool I'm looking for is Make because Make gives me a ton of flexibility to build whatever freaky combination of binaries might go into whatever product I'm working on, and then combine those binaries into a system image.

The point I'm trying to make is that every build system except Make solves a really specific class of build problem(building applications, or building Linux systems using GCC) and then pretentiously claims to support everything that matters. What you're actually getting is a small sliver of what you might need in my world.

This article is another example of how Make can do something really unexpected by providing really simple features and letting you decide what matters to you. I've yet to see another build system that is as generally useful.

<comment><USER38> It seems like CMake supports both of these out of the box:

[https://github.com/Kitware/CMake/blob/master/Modules/Platfor...](https://github.com/Kitware/CMake/blob/master/Modules/Platform/QNX.cmake) [https://github.com/Kitware/CMake/blob/master/Modules/Compile...](https://github.com/Kitware/CMake/blob/master/Modules/Compiler/TI-C.cmake)

</comment></comment></comment></comment></comment><comment><USER41> We use make for standardizing the way docker containers are built, pushed, tested, and run (debug and production modes). I even prefer it to docker- compose at this point, because it is more programmable.

<comment><USER42> If you're able, I'd be very interested in seeing some examples.

<comment><USER43> Not the OP, doing a bit less that it sounds like the OP is doing, but we built out a relatively handy make-based build system for building a set of images in correct dependency order.

Another member of the team subsequently taught make about the reverse dependencies so that you can split jobs across Travis nodes by the top-ish level image they depend on.

My favorite addition was the ability to generate a dependency graph using graphviz straight from the Dockerfiles.

N.B. Project is now moribund, the team was disbanded. May not build at all. Don't know if any of the forks are active.

<comment><USER41> That's pretty interesting about Travis. Make is great because you can do as much or as little with it as you want, but it generally always improves organization.

</comment></comment></comment></comment><comment><USER44> I've had a lot of fun recently writing a Makefile for a Go and Lambda app:

[https://github.com/nzoschke/gofaas/blob/master/Makefile](https://github.com/nzoschke/gofaas/blob/master/Makefile)

It started very verbose, one target for every Go program, until I figured out target patterns.

I'm also enjoying the -j flag to do things in parallel.

Now it's 3 lines of Make to build 10 go programs in parallel in seconds.

Parallel is also enough job control to run the development server and to watchexec rebuilding all go programs on code change.

<comment><USER45> Looks good, I think you need to add PHONY targets

</comment></comment><comment><USER46> One thing I've found useful about gulp and webpack is the fact that it's multiplatform.

What is the best approach to make sure your Makefile will work as expected on every platform, meaning, windows included?

For example: Can we write file paths using forward-slashes, or is it still an issue? I imagine running it via git bash (bash provided by the git installer on windows).

<comment><USER47> CMake! No, I'm kidding, don't really use CMake...

<comment><USER47> Downvote?! Looks like we have a CMake fan...

</comment></comment></comment><comment><USER48> Why is it that each time a JS dev discovers something most other fields have been using for decades, it has to be "The Lost Art", "Superpower" ([https://medium.com/@wesharehoodies/typescript-javascript- wit...](https://medium.com/@wesharehoodies/typescript-javascript-with-super- powers-a333b0fcabc9)) or something similarly tacky?

There's no Lost Art, no superpowers. It's just the JS scene _finally_ slowly getting up to speed.

<comment><USER49> Why is it that some commenters can't understand that all of humanity isn't at the exact same level of knowledge on everything?

People learn things every day, acting like it's "slow" or you are better than them is a very toxic elitist point of view that is better off not said. You think your way of doing things is better, then you should encourage others to do it that way, don't put them down when they just start using it! I'm glad the ALGOL programmers of the 60's and 70's didn't spend their time laughing and putting down that new-fangled C language when it inevitably made some of the same mistakes.

And besides, very rarely is something in life a complete upgrade. Make is nice, but it has some very real pain-points (as evidenced by the handful of utilities that are makefile-generators, because getting make to do certain things or work on all platforms is so difficult). Gulp is great too, but it also has some very big issues in some areas. There is no universal "right" answer to any of this, and assuming that everyone that's not doing it your way just doesn't know any better isn't just naive, it's also wrong.

<comment><USER48> > People learn things every day, acting like it's "slow" or you are better > than them is a very toxic elitist point of view that is better off not said.

You must've misunderstood me. I don't have any problem at all with people discovering things late. I am often a slow learner myself. What irritates me is when people make spectacular "discoveries" with tacky headlines. If the article were written in a bit more casual and technical tone, I'd be happy, much more so than with this "let me re-introduce you this amazing but forgotten lore you don't know about" nonsense...

> And besides, very rarely is something in life a complete upgrade. Make is > nice, but it has some very real pain-points

I agree, but that's all the more reason to not make such "discoveries" ...

</comment></comment></comment><comment><USER50> A long time ago, in a developer's paradise called the 1970's there was an automated build tool called "make".

It had this and only this syntax:

If a line begins at character 0, that is a list of files whose timestamps should be checked, if any are 'old', then execute the series of command lines beneath, identifying them as starting with a tab character.

That was it, the entire syntax of "make", and it was complete. Then some smart people fucked it up and we have that piece of shit we call "make" now.

<comment><USER51> I did not use Make at this time (I wasn't alive!), but it seems that you'd have to declare dependencies too. How did you determine if it was "old"?

<comment><USER52> "If a line begins at character 0, that is a list of files whose timestamps should be checked"

The list of files would be the declared dependencies.

<comment><USER51> Ah I see.

</comment></comment></comment></comment><comment><USER53> Working somewhere that really embraced Makefiles is actually very nice. If you keep your dependencies simple, the Makefiles to build stuff are pretty simple too, and it works for all the languages you might write software in. You can use it to deploy to servers too.

</comment><comment><USER54> Anyone here uses makefiles for anything other than compilation and build? One can use it to add some level of concurrency to shell scripts.

<comment><USER55> I use it for almost everything. Take ETL type tasks. It's almost impossible to remember where I downloaded certain data files six months after initially creating a project. I put that into the Makefile. Everything I do on the command line, I put into a Makefile. That way, 6 months later when I need to download new data, do some transformation on that data and load it into the database, 'make' re-traces my steps from 6 months ago. Broadly, my ETL makefiles look like this:

all: data.loaded data2.loaded

data.csv: wget 'some url'

%.sql: %.csv sed/awk/custom-python-script $< > $@

%.loaded: %.sql psql < $< && touch $@

</comment></comment><comment><USER56> For me, the problem with all make replacements is that they don't just solve makefile's issues in knowledge-compatible way, but reinvent their own cryptic syntax and structure from scratch. Minor issues that you know about (and know how to avoid) are never worth fixing in this way, since most people don't have time to learn infinite variations of superior tool #1 that has its own flaws. They are fine with #2 that works for them.

When someone says "there are numerous alternatives", I just look out the window and smile.

Almost all issues mentioned itt can be solved in barely-compatible, but easily transition-able way. If this tool exists, its name is welcome.

</comment><comment><USER57> I have used Makefiles for a lot of little things over the years. One of the latest things I have found it useful for is automating deployment of websites via Jenkins jobs.

It is a lot easier and more manageable if your Jenkins job is set up to just run a series of generic Make commands for a project, where any specific steps for a particular project are defined in the Makefile.

This way I do not need to know or care about how any particular project or site is built when configuring the job to deploy it. The Makefile takes care of all that.

</comment><comment><USER58> There's actually a much better general purpose build tool: [https://bazel.build/](https://bazel.build/) I consider it Make 2.0.

</comment><comment><USER59> The thing I like about Makefiles is the declarative structure you get by defining the targets. It really can serve as a form of documentation about your different stages of development.

</comment><comment><USER60> However expressive or standard on other platforms, Make is not the correct tool for building web projects. Putting aside fundamental technical differences between Make and say, Webpack (of which there are many) there needs only one argument: Make is not idiomatic on web projects. Most web developers are not going to be productive authoring or maintaining a Make build process. If this guy wrote a Make build process while working for me, I'd ask him to rewrite it using Webpack.

</comment><comment><USER61> CMake is so nice compared to vanilla makefiles. I wonder if it can be used this way with Javascript.

<comment><USER62> Make may seem crude these days but has manageable complexity, I've never run across a build issue I could not debug. Its model is so simple, I can have it fully in my mind and be confident this is how it works. Moreover, this model simplicity allows me to build reliable systems on top of it.

CMake is a nightmare of implied complexity. I've run into multiple situations (usually but not always involving cross-compilation) where it was simply incomprehensible. No amount of time invested would let me figure out why CMake blew up. There is no way I can build something a little out of the ordinary on top of CMake and be confident that it's solid. It's just too complicated.

This sort of balancing, upfront ease of use vs hidden complexity comes up often and I have been burned enough in the past that experience dictates to pretty much always go for model simplicity and pay the upfront costs. I don't see this often however. A lot of the time people will go for what feels or looks right, superficially, without bothering to look beneath the surface or think about model complexity costs. It's an attitude that has led to many disasters in this space.

<comment><USER61> Fair enough but it could be that CMake isn't the right tool across the board. It works well for the projects I've used it for. Maybe one day I'll come across a case that makes me hate CMake though who knows ;)

</comment></comment></comment><comment><USER63> I actually usually have a general-use Makefile that I work from as a starting point [1]. It takes all c files from a src/ folder and builds their objects to build/ and then links them all in one go. No need for me to specify the files. It also works recursively.

[1]: [https://pastebin.com/b1tr9th3](https://pastebin.com/b1tr9th3)

</comment><comment><USER64> I searched and didn't find a single soul using Makefile to orchestrate a set of build steps. I have been doing that for a long time: `make test`, `make build_docker`, `make push_docker`, `make deploy`. Now suddenly everyone shows up in one place here. Long live HN.

<comment><USER13> Apache Cordova's site and docs, although currently using Gulp, have a Makefile that mirrors the Gulpfile, and which nobody uses. :(

</comment></comment><comment><USER65> Make has dated syntax and conventions. When developers use emojis in command line, support for the spaces and other quirks look worse than a decade ago. Despite all of its expressive power and speed, Make is not going to attract many frontend developers.

If the concepts behind Make are repackaged in a more hipster way, the resulting tool may get far more appeal. Shake [https://shakebuild.com](https://shakebuild.com) is a build system library that can naturally express even the dependencies that require Makefiles go meta and generate new Makefiles. It can be a robust backend for any build system DSL.

<comment><USER66> I like functional programming languages and Haskell is something that interests me.

But you can't be serious when you say that make is out-of-touch with the average frontend developer, and then link to this:

[https://shakebuild.com/manual](https://shakebuild.com/manual)

<comment><USER65> I suggested making new build system that has the power of Make or Shake and is still oriented toward frontend development.

You are right that Shake and most general purpose build tools are out-of-touch with frontend. Even for people who are comfortable with these tools, they are not necessarily better than Webpack for the typical frontend tasks. Shake place in this hypothetical tool will be at its backend - like LLVM is the backend of many compilers.

</comment></comment></comment><comment><USER67> I learned a lot from this, and whether or not one should be doing this, I simplified:

[https://github.com/shmup/react- makefile/blob/master/Makefile](https://github.com/shmup/react- makefile/blob/master/Makefile)

I opted out of checking for modification dates on node_modules and yarn.lock, because that seems like exactly what Yarn itself is for. I let it manage itself.

I also let Webpack do the heavy lifting.

So in short: I don't really need the Makefile at all and could just add the clean and dev-server commands to a script block in package.json

I still like it though

</comment><comment><USER68> I find NPM script parameter as the most reasonable build tool. You can write any kind of shell commands or invoke shell or other scripts in javascript script into it without learning the strange syntax of Make.

</comment><comment><USER69> make is scary because people use autogenerated Makefiles.

After you've tried to naïvely read a Makefile for a medium-sized C project you'll never want to write a Makefile yourself.

That said, there's no tool that works so simply and so beautifully as make when you have a lot of build steps that generate lots of intermediate files with complex dependency links between them. That situation may happen everywhere, even if you're generating a bunch of PDFs or rendering HTML templates or making images from .dot files or whatever. Use make.

Or is there an alternative tool for these situations also?

</comment><comment><USER70> I believe $< is only the first dependency and $^ is all of them

<comment><USER71> With such an easy-to-remember intuitive syntax how could you forget?

<comment><USER13> We remember it the same way we remember System.out.printLn(), undefined == null, and other trivia in other languages.

</comment></comment></comment><comment><USER72> As a non-programer the only experience I have with makefiles are unpleasant ones of running ./configure then ./make only to go down an endless rabbit hole of missing dependencies. I am very grateful that yum/apt-get, etc. have come such a long way, they grab all your dependencies, you don't have to wait long periods of time for the code to compile.

I am sure Make still has it's uses, but I am sure glad package managers of have made makefiles irrelevant to me.

<comment> yoz-y This is not really a fair comparison though. Makefiles and package managers are orthogonal and the latter has not really replaced the former. Makefiles are like a recipe, package managers are food delivery. Somebody has still to cook the food.

<comment><USER73> > This is not really a fair comparison though.

I'd argue it's entirely fair with other examples (e.g. compare and contrast to, say, Rust's cargo build.) You can write a Makefile which fetches and builds your dependencies. Makefiles might be like a recipe - but these days we're building recipes for building entire OS images, including grabbing the dependencies in the first place. A single software project by comparison is trivial.

The problem is Makefiles are a jack of all trades, and master of none. You have to write or copy a distressing number of rules yourself, per project, per _subproject_ , and know the underlying build chain in relative depth to do even some rather basic things. I'd argue makefile authors not automating their dependency fetching is a symptom of this.

As a programmer, I avoid them, because I'll end up stuck maintaining them and end up lowering the build system's bus factor. With perhaps the exception of a couple of simple rules that forward to a "proper" build system, because I've written enough of them in the past that "make" still feels like the right default action that should generally work. But if it all possible, never for the meat of the build system.

<comment> yoz-y Of course. But I would not compare cargo build or CMake to package managers because again, they are developer tools and unless you are a developer you should not need them.

I definitely think that we can do better than Makefiles, but again they have the benefit to be extremely versatile so they can be bent to many uses. (personally I do not use them, I use CMake and generate ninja files)

</comment></comment></comment></comment><comment><USER74> Make is awesome. I often did things with it earlier however now if I want to do something with NodeJS I generally use npm scripts tag. And sometime it gets tedious to do so then I use nps [0]. If I need something big then I go with Webpack or Parcel.

[0]: [https://github.com/kentcdodds/nps](https://github.com/kentcdodds/nps)

</comment><comment><USER75> A tiny improvement that could be added - instead of locating Babel by adding your project's `node_modules/.bin` to your path or directly linking to it, you can always write:

`npx babel`

This will use any installed version of babel in your node_modules, or, if not installed, will temporarily install it for the duration of the command.

<comment><USER76> > or, if not installed, will temporarily install it for the duration of the > command.

Wait... doesn't that make typosquatting even more of a danger? People get used to typing "npx <command>", they mistype the command once in a while, an attacker uploads packages named after the most likely typos, and done - <USER2> attacker wins.

I question the wisdom of that shortcut.

</comment></comment><comment><USER77> A lot of good arguments about using and not using make. Count me in the not using make camp. IMO it's just simply overkill. JS work nowadays is so modular if we were talking about configuring a monolith service at build time... sure yeah. Meanwhile I just wanna make this div purple.

<comment><USER78> I presume you're running simple small js files. This post is about larger projects that need to transpile newer js code down to browser compatible code, combine multiple files into 2 or 3 http requests, and pack every possible byte out of the js resources we end up sending to clients.

<comment><USER77> Yup I'm a JS Dev and I use webpack (3). I get the entire thing. However I think this is still all so complicated for no sake but for a small benefit. I'm currently looking for a tool to find out how much is seen/used vs how much is delivered.

</comment></comment></comment><comment><USER79> I went through a Makefile phase but ultimately setting on Jakefile[1] for more approachable syntax and type-checkability via TypeScript.

[1] [https://github.com/jakejs/jake](https://github.com/jakejs/jake)

</comment><comment><USER80> Make works great for JavaScript but it seems very few people do so.

[https://github.com/webpack/webpack- cli/issues/152](https://github.com/webpack/webpack-cli/issues/152)

</comment><comment><USER81> Wish this article was about just make rather than JavaScript and using it in tandem

<comment><AUTHOR> Noted! I wanted to provide concrete examples, and I did not want the post to become too long. So I focused on one kind of project.

</comment></comment><comment><USER82> I like this a lot. We preach the mantra of reuse all the time, but we practice it so rarely - writing everything from the ground up every few years rather than trying to fit the existing tools to the new(er) processes.

</comment><comment><USER83> If you need to write in C or C++, use CMake. Otherwise, use whatever _modern_ build tool your language provides. It's 2018, and Make should have died in the 70s,

<comment><USER84> A lot of "modern" build tools lack necessary features.

</comment></comment><comment><USER85> The problem with make is that people build makefiles such that it is later referred to as a Lost Art.

<comment><USER13> People do this with all build systems. The difference is that Grunt/Gulp/Broccoli files are a Lost Art in 3 years, and Makefiles have been around for decades.

</comment></comment><comment><USER86> I'm not a web dev, but this article has uncovered yet another thing in the js ecosystem that just seems crazy to me.

This makefile snippet:

        lib/index.js: src/index.js
            mkdir -p $(dir $@)
            babel $< --out-file $@ --source-maps

The source and the output are both called index.js? Why, God, WHY???

<comment><USER87> Because `require` and `import` look at your package's `main`, which (if it's a directory) implies `dirname/index.js`. Building to an `index.js` entry file is, then, the most standard name that allows `require 'modulename'` to work.

The capitalized rending-of-garments is silly. This is transpiling; file names should remain the same from input to output.

</comment></comment><comment><USER88> I find the editorialized title a little bit harsh on author's intentions...

</comment><comment><USER89> Used make for building javascript bundles back in 2013. Worked incredibly well.

</comment><comment><USER90> Tangential, but I cringe everytime I see the word "transpiler". A compiler is a compiler is a compiler.

Previous discussion on this: [https://news.ycombinator.com/item?id=15154994](https://news.ycombinator.com/item?id=15154994)

<comment><USER91> Meh:

Compiler: collects sources from various places, assembles the result into machine code.

Transpiler: collects sources from various places, converts the source to another language.

Personally I cringe at the newspeak you seem to imply we should all be applying to our lives. These words mean things - quite different things, it turns out. There's a difference between human-readable source code language, and machine-executable binary code. These tools function in different ways entirely; your optimization to the language is not only un-warranted, but leads to a desultory effect: programmers get stupider when they don't know what their tools are actually doing.

<comment><USER92> > newspeak you seem to imply we should all be applying to our lives.

[http://foldoc.org/transpiler](http://foldoc.org/transpiler)

^ no match.

 _transpiler_ is the newspeak.

<comment><USER92> The original C++ is probably the most famous 'transpiler'

[https://en.wikipedia.org/wiki/Cfront](https://en.wikipedia.org/wiki/Cfront)

[http://www.softwarepreservation.org/projects/c_plus_plus/cfr...](http://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_e/src/master.pdf)

ohey, noone calls it a 'transpiler'.

I'm not so angry about the word transpiler; perhaps it might improve things.. but to imply that using compiler as a common term for all things here is a regression/neologism is patently wrong - transpiler is the newcomer.

<comment><USER85> But we called it lots of other things.

</comment></comment></comment></comment></comment><comment><USER93>
        lib/%: src/%
    	mkdir -p $(dir $@)
    	babel $< --out-file $@ --source-maps

Just look at all those magic things. The percent signs! $<! $@!

Well, I know they are not magic ;). But why would I want them when I can actually use normal names like "deps"/"entries" and "target"?

It gets substantially worse as we go down the rabbit whole. Where webpack can easily walk the entire dependency tree by itself, we have to invoke

       src_files := $(shell find src/ -name '*.js')

Where we can use same webpack to seamlessly output the resulting file into an output directory, we need to do the (very unintuitive) pattern substitution:

       transpiled_files := $(patsubst src/%,lib/%,$(src_files))

or even

       flow_files := $(patsubst %.js,%.js.flow,$(transpiled_files))

And when we want to watch for changes? Well, we need an external program anyway.

       $ yarn global add watch
       $ watch make src/

The art of Makefiles is often lost for good reasons: because Makefile don't really cut it anymore.

<comment><USER13> "Doesn't cut it anymore" isn't the same as "has a different way of doing it". Make has many other (necessary) features that Webpack doesn't.</comment></comment>


Show HN: Monthly Rentable Gitlab/Jenkins CI Runners - <AUTHOR> https://runnerrental.club <comment><USER2> Cool to see this. By the way at GitLab we're planning to charge per minute for runners [https://gitlab.com/gitlab-org/gitlab- ee/issues/3314](https://gitlab.com/gitlab-org/gitlab-ee/issues/3314)

<comment><AUTHOR> Thanks very much for the heads up! Awesome to see that Gitlab is solving this pain point.

I doubt there's any point to trying to run this service since per-minute charging is so much more efficient from a cost perspective and is where I was going to head to as well...

I guess I'll keep this around and see what the per-minute prices are and see if there's any space there.

</comment></comment><comment><USER3> I don't think any service can beat Hetzner's €3 server with 1vCPU 2GB 20TB specs.

<comment><AUTHOR> You'd be right, except Hetzner's €3 server's vCPU is actually _not dedicated_. Check out their pricing page, and look at "default" vs "dedicated vCPU"[0] (they start at ~€9/vCPU).

Hetzner is an excellent service by all means (I thoroughly use and enjoy it), but I'm not sure exactly what the performance of a 1vCPU "default" plan is -- honestly it's probably enough, but noisy neighbors might be a thing.

[0]: [https://www.hetzner.com/cloud](https://www.hetzner.com/cloud)</comment></comment>


Ask HN: Seeking a Cofounder - <AUTHOR> Overview:
I'm looking for a co-founder -- preferably someone with a technical background who can build and understand complex web systems, to build a SaaS startup (with equal ownership). I'm interested in the reviews space, restaurant industry, data science, education -- anything that has a clear benefit to society. I have thoughts of my own but am open to other ideas.
About me:
2 degrees from a top-10 school. Startups (full-stack software engineer, operations), NASA, VC, interdisciplinary AI/medical research; equally receptive to any programming language/stack as long as it's tried and proven. I can commit full-time or part-time to the business. I'm extremely driven but have an overall positive / friendly temperament. Would prefer a co-founder with a similar demeanor who believes that good karma matters.
Expectations:
Looking for someone who is similarly driven and persistent -- someone who won't get flustered/mad or flake when the inevitable obstacles come rolling in. I don't realistically expect an exceptional relationship to blossom overnight, but at the same time don't want to spend too much time philosophizing before getting something out into the world. A US-based co-founder would make things a little easier, but I'm happy to collaborate with those outside of the US and have done so in the past.
Why / Next steps:
I'm posting here since most people in my direct network are not very entrepreneurial, and I know there are others like me who would benefit immensely from collaboration outside of their direct networks. Email firstname.lastname@example.com if you're interested in chatting and I'll be happy to give some more details :) <comment><USER3> That looks interesting.

Seeking a tech-cofounder too to build a SaaS around the restaurant industry, machine learning and reviews.

I have the idea, mockups and validation done - need to build and ship - <USER2> I'm open to collaborate on the existing concept. I'm pretty self critical and highly collaborative.

About me, 34yo, well-connected, 15 years experience, exGoogle / Microsoft and some other large corps as well as Series A startups, investor relationship and VC fundraising experience. My last gig was as a Chief Revenue Officer (acting CEO) for the fastest growing F&B tech startup in my region. We acquired 5000 restaurants in a year or so.

Partnered with UberEats, Deliveroo, Zomato, WhatsApp and a bunch of other F&B tech leaders (as well as smaller players). I'm pretty well connected in my region and have zero issue to build a relationship to virtually anyone, if business needs.

Studied at Harvard / Columbia / MIT (not for the bachelor though, that was back in Italy). But realistically, I'm self taught in any aspect.

I'm fluent in digital, business, sales and marketing. A bit of a tech geek but I can't code. Whatever else digital, I'm able to ace it.

As I understand, you are a full stack? Are you looking at a cofounder CTO position?

Also where are you located? I'm in Europe.

Let me know if this sounds interesting. Happy to talk.

</comment><comment><USER4> I'm also in a similar boat. Full stack but my ideas are usually big requiring a team not a single Dev. Curious if you and op might want to team up. 3 devs as co-founders could accomplish a lot. I used to do Marketing 10 years ago and seo so can do some of that if needed to gain traction after we build the app.

My dream app is an airtable clone with a lot more column types like markdown with a nice editor so you could easily use it as a tool for a blog backend, also would be nice to have row and column level permissions and roles. So I could view and edit my info as an employee but not see others unless I was in hr for example. Also better linking and searching and combining of data from multiple bases into one mega base, and some sort of dashboard creator for stats and stuff.

</comment><comment><USER5> Just to ask: Do you have a business / project in mind already? It seems like you're a full stack developer already, so what parts would you need help with?

</comment><comment><USER6> I built this and am looking for someone I can work with to monetize it. [https://github.com/etewiah/property_web_builder](https://github.com/etewiah/property_web_builder)</comment>


Is it safe to sleep in the same room with a car battery? - <AUTHOR> https://electronics.stackexchange.com/questions/314855/is-it-safe-to-sleep-in-the-same-room-with-a-car-battery <comment><USER2> If there was even a slight possibility it wasn't safe many boats and motor- homes wouldn't be configured in a way that makes the batteries accessible from the cabin because doing so would open them up to lawsuits because that's the world we live in.

The comments on the question are surprisingly rational and level headed.</comment>


Chrome bookmark sync tool - <AUTHOR> https://chrome.google.com/webstore/detail/new-tab-bookmark-speed-di/pdcohkhhjbifkmpakaiopnllnddofbbn <comment><USER2> As someone who publishes my own Chrome extension with a similarly sized active user base, I am impressed by the number of reviews this has on the Chrome Web Store. There are 126 starred reviews and 40 text reviews while the extension has an active install base under 4k users. That equates to roughly 3% of users for star reviews and 1% for text reviews. That is much higher than anything else I have seen. The author must have hit on a niche that is more engaged than usual. That is a good sign for future monetization options if that is part of the plan.

</comment><comment><USER3> What cool new technology that hasn't already been solved by a million others. =P

Xmarks and Last Pass go really well together, been using them for years.

[http://xmarks.com/](http://xmarks.com/)

[https://lastpass.com/](https://lastpass.com/)

<comment><USER4> Having something "solved" does not mean there is no space left for different approaches or sheer competition.

And seeing people putting effort into something and delivering software is at least one indicator that the original problem is not solved in the eyes of some...

<comment><USER5> Indeed, despite the fact that Chrome/Chromium has built in bookmark and password sync, there's plenty of room for competition. Maybe some people don't like the fact that you have to have a Google account for the built in syncing, maybe others just don't feel they get what they want out of existing solutions.

I certainly look forward to trying this out.

</comment></comment></comment><comment><USER6> Is there a self-hosted version?</comment>


Apple Hacked - <AUTHOR> http://devimages.apple.com/maintenance

<comment><USER2> The wording seems awkward.

e.g. "In the spirit of transparency, we want to inform you of the issue. "

and "[long start of issue]...however, we have not been able to rule out the possibility that some developers' names, mailing addresses, and/or email addresses may have been accessed. "

</comment><comment><USER3> I wonder what this does for their strong reputation for security. Are they now big enough to attract attention? (Or too big to not attract attention?)

</comment><comment><USER4> This is probably the first time Apple gets hacked.

<comment><USER5> Not really. Here's at least one other case, from this year: [http://abcnews.go.com/Technology/apple-hacked-similar- attack...](http://abcnews.go.com/Technology/apple-hacked-similar-attack- facebook-data-breached/story?id=18539110)</comment></comment>


Turn Wordpress into an Image-Slinging Warhorse in Three Steps - <AUTHOR> http://www.factore.ca/on-the-floor/64-turn-wordpress-into-an-image-slinging-warhorse-in-three-steps

<comment><USER3> I advocate for declaring post thumbnails in your theme. It's much cleaner and you don't have to rely on a separate plugin.

<comment><AUTHOR> I agree, it's much cleaner to use the built-in features of Wordpress.

That said, this post is more of a gloss than an in-depth examination - <USER2> combination of plugin, template code, etc. can be used for considerably more complex purposes.</comment></comment>


IOS Text Editor Roundup - <AUTHOR> http://brettterpstra.com/ios-text-editors/

<comment><USER2> Says code editor roundup, but doesn't list code features like highlighting, auto-complete, or SFTP/GIT/SVN file access.

<comment><USER3> Pretty sure it says iOS Text Editor roundup. Syntax highlighting is in there, other code-specific features are listed under additional features because there's really only two "code" editors in the mix.</comment></comment>


WhoseTube?  - <AUTHOR> http://www.nytimes.com/2010/02/20/opinion/20kulash.html

<comment><USER2> _If record companies can't adapt to this new world, they will die out; and without advances, so will the futures of many talented bands._

I think there is a bit of a double-standard here. While digital music technology is _disabling_ the ability for record companies to make money using their current model, it is _enabling_ musicians to do more of what the record companies used to provide.

A talented musician today can record, edit and mix an album using computers and software that can be obtained for free or less(1). They can then distribute and promote a single world-wide and make the album available in both electronic and physical formats with small or no up-front cost and no ongoing risk (excess inventory, etc.). As this article points out, videos can be made for small amounts of money and distributed world-wide (as long as you haven't already sold your right to do so) to promote the band and the album as well.

There certainly are things that are still hard to do without a record company behind you but a significant amount of the risk these companies used to incur (namely studio time, marketing and distribution) are now all within the reach of anyone with talent and ambition.

Essentially musicians (and to an extent, novelists and filmmakers) are enjoying the position that software developers have enjoyed for decades. That is to say, it is not easy, or common, to see "rock stars" emerge from this process but with the reduced overhead it allows, it is possible to "make art your day-job" with a much smaller fan/customer base than it would be if you had to foot the bill for an entire studio and all of the other musicians that come with it.

So I believe, that to imply that the demise of record companies (as we know them) will be anything but a net gain for good music, is a dubious assumption.

(1)Many companies now pay to have computers capable of these tasks disposed of so you may even get paid to acquire the hardware, and there have been open- source applications capable of multitrack digital recording for years.

<comment><USER3> I completely disagree, the total number of amazing indie games, for example, can be written on the back of a matchbox.

The total number of paid for by publishers games numbers in the hundreds each year.

The number of amazing movies paid for by studios? Compared to the two or three indie films I can even think of in my entire lifetime.

It is delusional to believe that one person can have the skills to create great music, market that music, perform PR for the band and manage themselves. Those kind of people are so few and far between that if you want to bet the future of music on them that then we're in for a rough period musically speaking.

Don't get me wrong, I have great respect for these types of artists (Amanda Palmer is one that immediately springs to mind whose music I love).

But if it makes you feel better about the impending financing disaster approaching music by telling yourself that anyone can become a jack-of-all- trades you're just plain wrong.

<comment><USER4> >> " then we're in for a rough period musically speaking."

Come now. Recorded music is a very very recent invention. There was absolutely fantastic music before, there'll be absolutely fantastic music after.

I don't think it's useful to compare music to movies or games. The effort and range of skills required is completely different.

Also as I say, music has been around since forever. Movies and games are a more modern invention.

<comment><USER3> _Recorded music is a very very recent invention._

And that recorded music has meant a massive decline in paid live bands. So you can't get paid for gigging. So how are you going to get your 10,000 hours in like the beatles? You don't get resident bands in bars and pubs anymore.

 _I don't think it's useful to compare music to movies or games. The effort and range of skills required is completely different._

Aha, you think it's EASY don't you! Oh yes, anyone can be Nirvana if they grow their hair long huh?

It's not, grow up. The pure fact there are so many people who wanted to be a rock star and never were is a testament to the difficulty.

Also in the past movies = plays, games = Chess, backgammon, cards, etc. Plays cost money, chess boards cost money. And a poor person would never have had a chance to listen to Bach 300 years ago. All forms of entertainment have been around forever, the format changes with the times, but amazingly people always got paid.

So what is your point exactly?

<comment><USER4> Before recorded music, people just played music for fun, or were mainly employed by very rich people to play music.

If we go back to that, I don't think music as such will suffer. People create music mainly because it's fun, not because they want to be rich.

You certainly do get live bands in good pubs. Find a better pub.

And yes, I think creating music is far far easier than creating a movie or a modern game, where you have to organize music, lighting, casting, voices, graphics, gameplay, camerwork etc etc

<comment><USER2> Having done all three, I disagree that any one is categorically more or less difficult than the other.

</comment></comment></comment></comment></comment></comment><comment><USER5> This was something I actually hadn't seen before in this debate:

 _companies are cutting back spending on all but their biggest stars, and not signing nearly as many new acts._

I can sort of see how the big labels could stumble along their old path using heavy-handed techniques and lobbying for stronger copyright laws keep themselves in power as long as they actually supplied a constant stream of new music.

But not investing in their own future - that makes their demise a certainty.

<comment><USER6> Not exactly. There are new stars born every minute, so even if a couple of the big labels decide to sit out for a year or two they can easily get back in the game later. They can watch which mistakes the competitors make, think of new and better ways to adapt to the shifting music market, and so on.

It's better to make no investment in the future than to make investments you know to be bad.

</comment></comment><comment><USER7> This touches on something that I have been wondering for a while: why embed videos? On the Web, we don't embed text or images (if someone "embeds" one of your Web pages, many people would call that plagiarism or spam) but we embed videos. A video _has_ to be embeddable to be seen as having value. Why? How did we get to this place?

<comment><USER8> There are definite UX "costs" to following a Youtube link rather than watching an embedded video: it breaks the reading flow, it distances you from the context that the embedding site often provides, it opens a separate tab or window that you'll need to manage, you need to wait for the Youtube page to load, etc. These might seem like minor things but watching videos is often an impulse act, so _any_ operational or psychological obstacle to the user acting on that impulse makes it less likely that they'll follow through. And the opposite is true too; an embedded video is more visually interesting (think of the still frame) than a generic link, making it more likely that you'll bother to actually watch the video.

There's also a cost to the embedding site -- embedded videos keep the viewer's attention local, whereas linked videos send them offsite, possibly never to return. Many sites will just pick something different to embed rather than risk losing the viewer to the endless morass of distracting content on Youtube.</comment></comment>


A Penny for Your Books - <AUTHOR> http://www.nytimes.com/2015/10/25/magazine/a-penny-for-your-books.html <comment><USER2> The penny booksellers always fascinated me. The reporting in this piece has some interesting data: Thriftbooks sells 12 million books a year, for something like $2 per book (on the $0.01 cost + $3.99 shipping). I imagine Amazon could have some serious leverage if it wanted to.

And yet, 300,000 new books were published in 2013. Wow! Doesn't that seem like a lot? Is that maybe the source of the industry? Supply is overwhelmingly high. I know this model is the same for Hollywood and VCs, but wow. I can't imagine if 300,000 movies were released on DVD every year.

<comment><USER3> > And yet, 300,000 new books were published in 2013. Wow! Doesn't that seem > like a lot?

Isn't it amazing? And about that rate has been sustained for decades, as well. Can you imagine hundreds of thousands of books being published every year for decades? Who's writing them? How is this economicly sustainable? (If it's not, do we _really_ need to incentivize publication with ever longer copyright?) This is why when Google Books tried to estimate how many books had ever been published, they got a lower bound of 129 million and no real idea how much off they might be.

And it's not just books, either. There's maybe 100,000 albums being released every year, which means in our lifetime we'll hit 1 billion+. The number of feature films keeps going up (4000 a year not terribly long ago). The TV industry is feeling shellshocked by just how many programs are in production now. And all these numbers seem like they must be undercounts because who is really able to track how many new songs get uploaded to Youtube every day by professionals, amateurs, and all sorts of indescribable people? And in the rest of the world like China?

<comment><USER4> > 100,000 albums being released every year, which means in our lifetime we'll > hit 1 billion+

Even assuming a lifetime is 100 years, that would be only 10 million albums. There would have to be 10 million albums released per year to get to a billion in a lifetime.

I think a lot of albums don't take much effort to produce, EPs from garage bands and bedroom turntablists probably require less effort than even a trashy novel. Of course a decent number of those 300,000 new books are very low- effort affairs as well.

<comment><USER3> > There would have to be 10 million albums released per year to get to a > billion in a lifetime.

Sorry, I left out that part of Kelly's estimate of 1b songs is that album rates will also continue to increase at the historical rate. It seems improbable to me that we could really hit 1.1b songs by 2060 (it's such a mindboggling number), but on the other hand, the world keeps getting wealthier, making music keeps getting cheaper, and the appetite and dreams of people for making music seems to know no limits...

</comment></comment></comment></comment><comment><USER5> I'd like to see more focus on the fact that Amazon is straight-up lying about shipping-and-handling costs, which is how these guys are able to list books as selling for $0.01+$3.99 S&H when it's more like $2+$2 S&H. I had thought it was "just" the sellers being dishonest, but apparently it's an Amazon mandate:

> _A "penny book" is something of a misnomer. Used books sold on Amazon > typically carry a $3.99 shipping fee. But that isn't a reflection of the > actual cost of shipping them — it's a function of the company's rules, which > mandate a consistent shipping cost for every category of the product in the > Marketplace. Amazon takes a standard cut of every book sold — $1.35 — which > leaves each of the penny sellers of "A Visit From the Goon Squad" with a > whopping $2.65 to cover the cost of the item, shipping and handling, labor, > rent on warehouses and all the other costs that come up along the way._

At least they've gotten better about showing the full price with shipping in the comparison page, but that only mitigates the issue.

<comment><USER6> Amazon mandates that they charge exactly $3.99 for S+H, because previously when everyone set their own charges for S+H, it was difficult for the consumer to compare prices from different vendors, and the vendors were incentivized to inflate S+H so that their books would look cheaper than they were.

Of course it would be more logical for Amazon to mandate S+H of $0 so that what you see is what you pay, but I think the current system is a reasonable compromise.

<comment><USER5> > _the vendors were incentivized to inflate S+H so that their books would look > cheaper than they were._

And they're still doing that, only now they're not merely incentivized to do so, but required.

</comment></comment></comment><comment><USER7> I bought a lot of used books from Amazon when shipping used to cost $1.99 or $2.99, but now that it's $3.99, there's less of a differential between the cost of a new book (or Kindle book) and the cost of a used book (that may have problems like missing pages, which happened to me twice -- very frustrating to be hours into a book and find out that several pages were torn out for some reason). So now I rarely buy used.

Though I guess enough people are buying them to make it worthwhile to sell them.

<comment><USER8> Go to abebooks.com. Often the same sellers sell the exact same books there but with 2.50 shipping instead of 3.99. I almost never shop at amazon anymore for the simple reason that their used book base shipping rate is too high. But that's me; I'm addicted to used books.

<comment><USER2> I'm right there with you. I find the psychological race-to-the-bottom fascinating: a book at $4 is not nearly worth it when it could cost $2.50.

</comment></comment></comment><comment><USER9> I've recently begun to look into building a small home library without spending an arm and a leg on the price of new books. My immediate inclination was to hop onto Amazon and find as many used titles at $1 or less as I could. Only after filling my cart did I discover my $24 worth of books would cost $80 to ship.

I was disappointed but continued searching for a better solution. I'm in the process of writing an article about this search but I can reveal that so far Half.com has been the most affordable at $1.89 shipping for most books. It seems that shipping cost per book is unavoidable but I'm glad these gigantic sorting operations like Thriftbooks are around to repurpose stuff that'd otherwise be decomposing in a landfill.

With regards to pricing the actual books, I wonder what kind of info is out there when it comes to the same book costing $1 or $.01, which is more likely to sell. For non-trade paperbacks I'd say my upper limit per book is $5, but I feel just as ready to buy a good book for $1 as I would for $.01 (and in some cases having the price so low gives me a second thought that I might want to avoid purchasing said book because it might be in awful condition compared to one at $1). I wouldn't mind if these sellers ended up with 75 cents of my money rather than 7 cents per book.

<comment><USER8> check out abebooks.com. They have the best search engine for books when it comes to facts about the specific book, such as: is it a first edition? If its a hard cover, does it come with a dust jacket, and if so what condition are both in? Cheers

</comment></comment><comment><USER10> Previous discussion: [https://news.ycombinator.com/item?id=10461019](https://news.ycombinator.com/item?id=10461019)

</comment><comment><USER11> The local libraries around here get rid of books at $.25 to $2.00 each. I pick up a lot of sci fi that way.</comment>


California AB5 Signed into Law - <AUTHOR> https://www.bloomberg.com/news/articles/2019-09-18/california-governor-signs-labor-law-setting-up-bitter-gig-economy-fight <comment><USER2> If drivers are signed into both Uber and Lyft waiting for a ride, does that mean they are acting as employees of two companies at once?

<comment><USER3> I've been predicting that we won't be able to work for two or more companies simultaneously. A company is not going to pay you for time you are spending at the other company if we are talking about paying a dollar per hour wage. I also feel we will not be able to just log on anywhere and start working like we do now. I like to work in different cities in the SF Bay Area. If Lyft and Uber are able to direct where we wait for rides because we are employees, I predict the system will be more efficient and quite a few less drivers will be needed.</comment></comment>


Ask HN: How do we know Uber's surge pricing is automatic? - <AUTHOR> I was talking to a few engineer friends and they seem certain Uber's surge is algorithmically decided yet I've never seen any indication that is other than a few third party articles about it. <comment><USER2> umm how else would it be done? you think Travis himself fiddles with it?</comment>


Plato was right: statistical average of earth is a cube - <AUTHOR> https://phys.org/news/2020-07-plato-earth-average-cubes.html <comment><AUTHOR> From the Timaeus "To earth, then, let us assign the cubical form ; for earth is the most immoveable of the four and the most plastic of all bodies, and that which has the most stable bases must of necessity be of such a nature. Now, of the triangles which we assumed at first, that which has two equal sides is by nature more firmly based than that which has unequal sides ; and of the compound figures which are formed out of either, the plane equilateral quadrangle has necessarily, a more stable basis than the equilateral triangle, both in the whole and in the parts. Wherefore, in assigning this figure to earth, we adhere to probability"</comment>


How to 'Tune' a City - <AUTHOR> http://www.citylab.com/housing/2016/09/how-to-tune-a-city/501776/ <comment><USER2> I am fond of this book! I've been working hard to improve the process of renting properties in the USA and wholeheartedly support the idea that we have to modernize and simplify our city life. Shifting from a linear system to a circular one sounds great. Let's take the best feature of every city, like San Francisco's recycling system and Hong Kong's subway system, and integrate these best practices in creating the City of the Future!</comment>


Sea ice area returns to 1979 level - <AUTHOR> http://www.boingboing.net/2009/01/07/sea-ice-area-returns.html <comment><USER2> I'm so used to seeing bad news, I was trying to figure this one out. "So, this is a big step backwards for us, then, right? Oh, wait."</comment>


Modern math solves Ramanujan's 'vision' - may clarify black holes - <AUTHOR> http://www.futurity.org/science-technology/modern-math-solves-ramanujan%E2%80%99s-%E2%80%98vision%E2%80%99/

<comment><USER2> I love articles like this. Ramanujan was a very interesting man and perhaps had some of the deepest mathematical insights of anyone who existed. People are still trying to figure out what the things he wrote down meant. If you want to know more about his life, there's a great book called "The Man who Knew Infinity" ([http://www.amazon.com/The-Man-Who-Knew- Infinity/dp/067175061...](http://www.amazon.com/The-Man-Who-Knew- Infinity/dp/0671750615/ref=sr_1_1?ie=UTF8&qid=1355776982&sr=8-1&keywords=the+man+who+knew+infinity))

<comment><USER3> I find this very interesting since, while I am positive it has a mundane naturalistic explanation (like: the guy was really smart and had exceptional intuition), revealing the answers to questions that perhaps cannot yet even be formally asked is how I think I would go about proving that I was either from the future or another world.

Somehow get sent back in time a couple dozen thousand years? Carve a bunch of primes into the side of a cave somewhere, maybe throw in the Pythagorean theorem and a suspicious number of digits of Pi too. Messages that perhaps mean little to the contemporaries of the message.

Kind of fun to think about I think.

<comment><USER4> It gets even more interesting when you think about what 'intuition' really is, and what it means to 'know' something. Words, words m'lord.

If you're willing to leave the standpoint of a 'reality' which is based in the interactions between 'subject' and 'object' then things get really interesting and you begin to question what such an apparently great man meant when he said that what was revealed to him was done so by divinity.

To do so, of course, would mean you would have to understand the metaphysics of Indian thought and culture, which may be (rather basically) summarised to hold that the objective is merely a reflection of the absolute Subjective, i.e. divinity.

This is especially important because it is from this cultural standpoint that these visions were realised. I could go on if anyone is interested.

<comment><USER5> please do. i'd contribute more in response to encourage you, but anything i have to say on the topic is something i've drawn from my own processes and probably not worth discussing until i've at least done Wikipedia on it. and it's not really a topic i've heard discussed before, even in the context of "genius". though that is the context in which i've pieced them together. disclaimer IANAG

<comment><USER4> I think use of that acronym itself constitutes geekiness ;)

A bit of background: I've spent the last three years of my life studying Indian metaphysics in India at a traditional academy known as an 'ashram'. The environment was somewhat similar to the original Greek academies, I can imagine, but that is speculation. I also have interests in tech, programming and philosophy. Please note that I am not trying to 'prove anything' either correct or incorrect -- indeed, this would not be the forum to do so. Rather, an opportunity to be of service to another individual and present two different views of this experience of the world and thus life itself.

For the western mind, indeed, for my mind -- it is ingrained to a point of 'truth' that there is a single objective world around us which presents itself to various individuals via the senses. It literally took me 1.5 years of serious mental deconstruction, analysis and questioning before I was able to entertain the thought that my body, brain and indeed the world around me were a _product_ of the mind, and did not produce the mind itself. Consider that. It's your whole system of thinking about the world turned upside down.

In building a metaphysical system for the world and individual, the Indians defined an individual as a 'body-mind-intellect' (BMI) experiencing 'perceptions-emotions-thoughts' (PET). The former they termed the 'relative subject' and the latter the 'relative object'. It is easy to see that these cover EVERY aspect of human experience.

I am taking a shortcut and would be happy to clarify further, but there is a facet of the spiritual path in India known as bhakti yoga (the science of union with the Divine through emotion) which targets the mind in its emotional capacity. It is not uncommon, then, to use an IDOL (which is NOT the same as the goal itself) to represent the goal of absolute subjectivity which one is striving for and cannot be perceived, felt or conceived via the BMI and their PET.

This representation, symbol, takes the form of a goddess/god whose strange and crazy figures and ornamentation are intended to initially (1) evoke questions in the seeker as t to their presence and (2) inspire more devotion once their significance is intellectually understood.

Coming back to the genius mathematician. If one traces one's own moments of lucidity or inspiration, one would find that they come at times when the mind is relatively calm, composed and engaged in a subject. The extrapolation of this is the state of bhakti yoga (complete absorption in the ideas represented by the deity), and most adherents thereto ascribe the 'doing' of their thoughts, words and deeds to the deity Itself, to efface their egos and move closer to their ideal of transcending the world itself.

Now look at that simple statement: "These ideas were revealed to me by my God" [paraphrase]. The simplistic notion that an apparition appeared before him or in his mind to provide him with these incredible insights does not hold to a scientifically-inclined mind. But the notion that he had trained his mind so highly that he was able to become absorbed single-thoughtfully upon a subject to the extent that he was able to perceive subtle nuances therein, indeed subtle nuances that would seem 'magical' to a non-trained observer is not unthinkable. That he then ascribed his discoveries to a deity is something that happens daily in Indian life and as previously covered is intended as an effacement and ultimate transcendence of the ego and the world it projects.

I can highly recommend A Parthasarathy's Vedanta Treatise if you are interested further.

</comment></comment></comment></comment></comment><comment><USER6> This paragraph makes no sense to me:

 _They found that while the outputs of a mock modular form shoot off into enormous numbers, the corresponding ordinary modular form expands at close to the same rate. So when you add up the two outputs or, in some cases, subtract them from one another, the result is a relatively small number, such as four, in the simplest case._

<comment><USER7> You have two functions both of which grow to infinity, one of which is much better understood than the other. It turns out that if you subtract the two functions, they balance out perfectly so you end up with something converging to 4 instead of going to infinity.

<comment><USER8> When you subtract any two functions that are exponential, the answer is 4?

<comment><USER9> Not quite. Take two exponentially growing functions, say e^x and e^2x over the interval [0,infinity). as x-> infinity both grow without bound. So does the difference of e^(2x)-e^x because the former is just so much larger than the second. They both approach infinity, but at different rates! If the difference between two functions (in the limit) converges, that means that the two functions diverge at the same rate (i.e. both with the end behavior of e^(ax) for some constant a) This is all a little hand wavy though but I hope that clears things up.

</comment></comment></comment></comment><comment><USER10> I wish the article had talked more about what it had to do with black holes. Can anyone here explain that to me?

<comment><USER11> Here's a link to a paper on this: <http://arxiv.org/abs/1208.4074>. Explaining it is _well_ beyond my capacity, though.

<comment><USER12> For a layman the abstract sounds like a computer-generated hoax.

<comment><USER7> You could say that about any field that one is unfamiliar with. Heck, the most basic art concepts could seem like so to a blind man. Mathematicians have worked for ages on simplifying the concepts so every term is there because it helps a trained mathematician understand what is going on.

</comment></comment></comment></comment><comment><USER13> I hope we have handful of Ramanujan's DNA stashed somewhere so, once we accept (and achieve) human cloning, we can clone thousands Ramanujans in hopes of some of them developing such beautifully abnormal brain.

<comment><USER14> I think it would be poetic justice if in a triumph of naturalism we actually cloned him and got only boring copies because the real Ramanujan actually got his insights supernaturally, like he claimed...

<comment><USER13> There might be additional factors like mitochondrial DNA or some epigenetic factors or some accident during development of his brain. Getting 1000 boring Ramanujan clones would prove that the our skill is lacking not that we couldn't replicate a goddess.</comment></comment></comment>


Dreams Change Under Authoritarianism - <AUTHOR> https://www.newyorker.com/books/second-read/how-dreams-change-under-authoritarianism <comment><USER2> "Despite ongoing interest from publishers, no one has been able to find Beradt's heir, who holds the rights.)"

Wait, what? I thought "intellectual property" was the key to getting consumers products that they want.</comment>


Joel Spolsky talks about how to bootstrap your business with no cash - <AUTHOR> http://www.clubenetwork.com/index.php?option=com_seyret&task=videodirectlink&id=69

<comment><USER2> I actually thought that the most interesting comments were at the end of the interview.

"What the VCs created by not investing in entrepreneurs during the .COM winter, was they created a breed of super entrepreneur... That breed of entrepreneur didn't need money, they figured out how to make a business without a lot of money, and now they don't need the VC's any more and the VC's are freaking out."

He also mentioned that companies that take VC money are actually at a competitive disadvantage over those that do take money. The VCs force the startup to take a big exit, so the VC can make their 10x return on their investment in 5-7 years. But, if a company doesn't take money, they can be bought for a lot cheaper, and are a more likely target for acquisition. A VC backed company is going to be 10x more expensive than a non-VC backed company.

<comment><USER3> Thanks.

I hate clicking on a post only to find a video. I don't always have Flash available and even when I have flash I don't always have sound. It helps when someone summarizes the main point in a comment.

<comment> daniel-cussen I totally agree. I usually read the comments first for a summary. If they are very, very positive, I might look at the link.

</comment></comment></comment><comment><USER4> You can get the MP3 from here:

[http://www.venturevoice.com/2005/11/vv_show_20_joel_spolsky_...](http://www.venturevoice.com/2005/11/vv_show_20_joel_spolsky_of_fog.html)

One of my pet hates is using video, especially online non downloadable video, when it adds absolutely nothing. Video lectures with slides I can understand - but a static one frame face of Joel?

</comment><comment><USER5> This was a terrific interview; I listened to the whole thing. Thanks for posting it. Joel has such a lively manner: I wonder if there are other recordings of him?

</comment><comment><USER6> Digg this podcast!

[http://digg.com/programming/Joel_Spolsky_on_How_to_Bootstrap...](http://digg.com/programming/Joel_Spolsky_on_How_to_Bootstrap_a_Business_With_No_Cash)

</comment><comment><USER7> Second DaniFong. Great interview, listened to the end.

</comment><comment><USER8> Definitely worth listening to all the way to the end (it gets much better at the end).

</comment><comment><USER9> Does anyone happen to have a transcript of this?

</comment><comment><USER10> gotta love Venture Voice</comment>