Why aren't you using git-flow? - <AUTHOR> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ <comment><USER2> Git flow is a great tool as a starter to teach people what a reasonable git workflow is. Once you understand got better, you may find it a bit constraining.

Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense.

EDIT: Please not I am not suggesting that you not do feature branching. That is an awesome and compelling feature of git. I just don't see the need for a second branch just for developing in general in. That's what master has traditionally been for.

And yes, you can branch and redo tags at any time. If you don't know this, you probably don't understand git's underlying model very well. Time to read up: <http://www.google.com/search?q=explanation+of+git+internals>

<comment> brown9-2 If you develop directly in master, then how can you go back and fix a severe bug in the version of the code that is in your production site without having to revert all the in-progress development changes or risk introducing them into the bugfix? I believe this is the intent of not working in master.

If you tag each release, does git allow you to checkout by that tag and then start making commits to it / make a new branch from it? I could be wrong but I thought tags in git were basically just read-only and informational - can you start work from them?

<comment><USER3> There's a psuedo-branch in master, which is "everything since the latest commit that has been pushed out". (This is my own terminology, so don't go Googling for it.) This is the branch that becomes "real" once pushed to the public, and that's when you can no longer rewrite the history without hurting things.

If you are disciplined, it's ok to build on master, but once you realize you need a branch (3 or 4 commits in), it's really easy to deal with. You branch from master, re-checkout master, and git reset --hard back to the public psuedobranch. And it is as if you had a branch all along.

I play the same game with git svn sometimes, except the psuedobranch is the "stuff that has not yet been committed to SVN" and it's a lot more clear where the cutoff is. I won't pretend this is perfect, but it does work.

(The problem I have with branching off for absolutely everything is that I find it easy to end up with too many branches to remember what's what. Granted, I'm the team lead and I may be more prone to that than a team member with more defined tasks.)

<comment><USER4> There's no need for any custom terminology: Your master branch isn't a pseudo- branch. It's just another branch that happens to live in your local repository and shares the same name as the remote repository's branch that it tracks.

</comment></comment></comment></comment><comment><USER5> You know you suffer from FOSS-culture-tunnelview when...

...you are "astounded" that some people never heard of some less-than-a-year- old add-on to a fashionable development tool.

<comment><USER6> And on a related note, You May Be Getting Old if you increasingly hear statements like, "I don't know how anybody ever did X without having Y!" and you have direct memories of having did X quite successfully for 10-20+ years without, as you may have guessed, having Y. Because Y didn't exist for most of that time!

</comment></comment><comment><USER7> I do the same thing without git-flow already. What will git-flow give me that I can't easily do or is awkward with using git directly?

<comment><USER8> If you are doing this style exactly without git flow, you don't gain a whole lot. It is great if you are working with a team then it forces everyone to work the same way and is very clear what you do in each situation. One of my favorite features of git-flow is housekeeping, for features when you close them it merges to develop and destroys the branch, when you do a hotfix it merges to master and develop and destroys the branch. When you release it creates a tag with whatever version you specify, and you can work on that until you are happy with the state of release, then when you push tags you will have a nice snapshot of your last deploy.

tl;dr: good for teams, and housekeeping

<comment><USER9> I haven't used it yet, but I have to agree that forcing a team through the same general process would be a very big win.

<comment><USER7> Would a single member of the team (the release manager) be doing it all though, and the rest of the team would only be pushing to the development branch? The release manager would maybe pull for hotfixes, but it would always be the release manager doing the work (or his proxy).

</comment></comment></comment></comment><comment><USER10> I typically don't like tools like this. They hide too much of what is going on.

<comment><USER11> While I understand your concern, a feature of gitflow IMO is that you can switch between git and gitflow as you wish. Personally, I like the constraints that gitflow creates because it simplifies the process of pushing out releases.

Since time is my number one constraint right now, I'm taking advantage of every tool that makes me more productive. Yes, you can certainly _implement_ the workflow with vanilla "git" but if you're going to follow the workflow model, why not use a tool that excels at that workflow? especially when said tool allows you to see what it's doing.

</comment></comment><comment><USER8> Our team uses this with great success. To take this a step further we name our features in conjunction with features in our project management tool. git flow feature start visitor_can_sign_in_812381 This gives us a nice mapping of feature branches to actual features. The one thing to be aware of with git flow is that the author is more on the merge side than on the rebase side. So closing features just involves merging on top of the develop branch. This hasn't raised many problems for our team though.

<comment><USER12> Regarding rebasing, the first commenter at the bottom of the linked article mentioned he prefers rebasing to merging, and referenced a blog post of his explaining why:

<http://darwinweb.net/articles/the-case-for-git-rebase>

Worth reposting here in case anyone missed.

</comment></comment><comment><USER13> Every time I visit your blog, I open up firebug and disable that background image. Scrolling is awfully slow. Please disable it, its annoying.

<comment><USER14> Scrolling is much faster in Firefox 4, especially on pages with a background image.

<comment><USER15> Chrome is also bearable.

</comment></comment></comment><comment><USER16> Has anyone used git-flow with an existing repo? It seems like existing branches could just be renamed from "myfeature" to "feature/myfeature", etc. but I wonder if others have been down this road and have run into issues.

<comment><USER16> I've done some playing around with a dummy "existing" repo and it seems to adapt well. Upon "git flow init" it identifies existing branches and proceeds with the questionnaire in the article above associating.

Here's a gist I created showing how an existing repo (although very basic) can be adapted to use git-flow - <http://gist.github.com/538326>

<comment><USER17> This gist is literally the most helpful thing I have ever read in under 5 minutes :D Especially with all mistakes included and averted. Thank you! :)

</comment></comment></comment><comment><USER18> I remember reading about this branching model and really liking the idea. The tools might actually motivate me to use it.

</comment><comment><USER19> One of the original intents of the git project was to create an "SCM toolkit" where other people would use git to build their own little interfaces on top of it.

Then everyone just used git. It's interesting to see this dream come to a small amount of fruition.

</comment><comment><USER20> Because most of us don't need a branching model this complex, and if we do doing the equivalent thing with "git checkout" is trivial compared to actually managing all those branches.

</comment><comment><USER21> This sounds like a great tool for developers who are starting out in git, but it is even better for those familiar to it because it makes our life easier.

</comment><comment><USER22> Our workflow goes through gerrit. It's simple and I really like it that way.

I don't know that this could be added to it and not make it entirely more complicated.

</comment><comment><USER23> If there's one thing I've learned in 15+ years of build/release/scm engineering, it's that there is no one-size-fits-all branching model or workflow. git-flow is a nice set of tools for one workflow/branching model, but it should not be confused with a silver bullet.

</comment><comment><USER24> This is interesting. Does anyone know if it introduces any other metadata or concepts that are annoying if one reverts back to plain git?

<comment><USER20> It just appears to be a fancy-pants way of creating branches for you. Plenty of projects (e.g. Git itself) use a similar development model without using git-flow.

</comment></comment><comment><USER25> Because I use mercurial. Every commit is a branch if you want it to be. Also, task branching model is a bit heavy for my tastes.

</comment><comment><USER26> We don't use git-flow because we don't have any problems managing our code.

<comment><USER27> I don't use any language other than Blub, because Blub works just great.

</comment></comment><comment><USER28> because I am still struggling to understand normal git</comment>


Ask HN: Sysadmin vs. engineering - <AUTHOR> To be a "sysadmin", does it require a degree? Also, is system admin more like being a technician (electrician), rather than say an engineer. What profession is more respected? Like say Dr. vs Nurse, the Dr wins. <comment><USER2> I don't think this is a fair comparison. First, neither a "sysadmin" or system/network engineer specifically require a degree, although a degree can be helpful in finding employment for either depending on where you want to work (Silicon Valley less requirement, government contractor probably going to be a requirement). And I wouldn't say either is more respected specifically, although you will often find that engineer is a career progression from sysadmin. However, I know many people that have made great careers and are highly respected in their field being sysadmins. I would say the engineer is like being the architect of the building, while the sysadmin is more hands-on builder and daily maintainer. It is more a preference of what you want to do with your career. If you like having a hands-on, maintenance, troubleshooter role then sysadmin is the way to go. If you like building, designing systems, planning, then the engineer position is the way to go.</comment>


Show HN: Neural network color recognition - <AUTHOR> https://github.com/mateogianolio/hopfield-color-filter

<comment><USER2> Interesting but how is a NN necessary instead of examining pixel values?

<comment><USER3> I would assume it's a practical (although not entirely useful) example of a hopfield network. If you look at the wikipedia page for it[1] there is little to no information on what you would use it for, seeing an example of practical usage is great for figuring out other practical applications for a hopfield network.

[1]:[http://en.wikipedia.org/wiki/Hopfield_network](http://en.wikipedia.org/wiki/Hopfield_network)

<comment><AUTHOR> You're right, it's just a practical application.

For those interested, I came across this chapter [1], which is great for learning about hopfield networks.

[1]: [http://www.cs.toronto.edu/~mackay/itprnn/ps/506.522.pdf](http://www.cs.toronto.edu/~mackay/itprnn/ps/506.522.pdf)

</comment></comment></comment><comment><USER4> Good stuff.

quick q: why do you call this a hopfield network? I see you have a fully connected 2 layer neural network (0 hidden layers): [https://github.com/mateogianolio/hopfield-color- recognition/...](https://github.com/mateogianolio/hopfield-color- recognition/blob/master/network.js#L5)

instead of a bunch of circularly connected perceptrons: [http://en.wikipedia.org/wiki/Hopfield_network#mediaviewer/Fi...](http://en.wikipedia.org/wiki/Hopfield_network#mediaviewer/File:Hopfield- net.png)

p.s. it looks like the library you're using has a built in Hopfield network `new Architect.Hopfield(10)` (at the bottom: [here]([https://www.npmjs.com/package/synaptic)](https://www.npmjs.com/package/synaptic\))), why didn't you use this?

<comment><AUTHOR> Thanks.

To answer your first question, I (perhaps naively) assumed that the synaptic library used correct naming for its network prototypes [1].

My implementation contains a few modifications to the one defined as 'Architect.Hopfield' [2], which is why I decided to put it in a separate file. It also helps a visitor to know how the network is defined without needing to browse the source of the synaptic library.

[1]: [https://github.com/cazala/synaptic/blob/master/README.md#hop...](https://github.com/cazala/synaptic/blob/master/README.md#hopfield)

[2]: [https://github.com/cazala/synaptic/blob/master/src/architect...](https://github.com/cazala/synaptic/blob/master/src/architect.js)

</comment></comment><comment><USER5> I don't get it. If you trained to recognize black and white, why did it find such a complex pattern where there were clearly none in the first example? Isn't it an example that it failed?

<comment><USER4> Interesting stuff, nice work!

The complex pattern is a result of the network doing the equivalent of fitting 3 gaussians (1 for each of RGB color channel) on the intensity of the pixel in that channel. I was curious, so I recorded a tiny demo of doing the equivalent piecewise in photoshop: [http://cl.ly/183Z3w1V1B0F](http://cl.ly/183Z3w1V1B0F)

Posterization in photoshop is a k-means technique, and each k-mean is a center of a gaussian, hence my motivation for the analogue video.

The triangles in the thresholded image make me think that the network is doing the equivalent of predicting a probability that a certain pixel is white/black per channel, and then these channels collude for the final decision, and thus we see triangles when the intersections of the 3 triangly spaced gaussians yield a value above some threshold.

Pic of the different channels: [http://cl.ly/image/1w371V3U0N02](http://cl.ly/image/1w371V3U0N02)

<comment><AUTHOR> Great analysis, I hope you don't mind my linking to this comment as an explanation of the fractal patterns in the readme?

</comment></comment></comment><comment><USER6> Is the purpose of this project to simulate color perception paradox ( blue or gold dress) ?

<comment><AUTHOR> Nope, but feel free to do whatever you want with it.</comment></comment>


Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts - <AUTHOR> https://lkml.org/lkml/2018/12/22/221 <comment><USER2> I've been extremely critical of Linus Torvalds in the past. I was glad to see him decide publicly to change his behavior, and I am glad to see him doing better here.

Personally, I think this level of disappointment/anger/trust issue would be best dealt with face-to-face or via a phone or Skype call, or at least an off- list email. However, given the unique situation of the Linux kernel, I think it was appropriate to send to the public list.

The only line I'd remove or finesse is "Yeah, this is complete garbage." Otherwise, I think this is a great example of how to convey anger without personally attacking anyone. Linus doesn't swear, he doesn't call Eric stupid or curse him out, but he still says what he means: The behavior was out of line, it has to stop, and, most importantly, it represents a breach of trust.

He's not saying Eric is a bad, stupid or worthless _person_ \- he is saying that in this instance, Eric's _behavior_ is bad. That's the key difference.

<comment><USER3> He's still saying that Eric's behavior is so far beyond acceptable that no defense can be offered, and _the entire rest of his work_ is worthless until he admits that. I think Eric probably had a reasonable explanation for this change, and the fact that Linux containers work so well is due far more to Eric than Linus, so in a healthy project it would be worth hearing out Eric and letting the more meritorious idea win by technical argument. But Linus's email closes that possibility.

<comment><USER4> At no point does he declare Eric's other work worthless or otherwise "permanently" anything.

He indicates that trust has been breached, temporarily, withdraws his willingness to accept patches due to the breach of trust, and specifies precisely how Eric can rebuild trust:

> until you have made it clear that you comprehend this very fundamental issue

<comment><USER3> The problem is that Linus has transformed a technical disagreement into the language of a breach of trust. There is _no_ argument that Eric can offer to demonstrate that he weighed the factors and determined breaking userspace was the right call (it's certainly a call commonly made in kernel development, even by Linus himself on occasion!). And Eric can't argue fully because he feels a duty to his users to continue the rest of his work, which is now being held hostage. (Should he refuse to concede the point, then permanence kicks in. It reminds me of certain teachers I had in high school who I still believe were wrong on the facts but the threatened social consequences for pushing the point weren't worth it.)

So fundamentally we have the same _practical problem_ as with personal attacks: that it's bypassing what should be a discussion on technical merit. Maybe Eric's feelings aren't hurt, but it's still not clear we're building the best kernel we could.

<comment><USER5> If you read the rest of the chain til the end, Linus acknowledges that occasionally userspace has to break. He mentions security issues and extremely old code that provides no other option but breaking it, but then suggests that this was not one of them.

> ( _) Yes, there are exceptions. We have had situations where some interface > was simply just a huge security issue or had some other fundamental issue. > And we 've had cases where the breakage was just so old that it was no > longer fixable. So even rule #1 can sometimes have things that hold it back. > But it is _very* rare. Certainly nothing like this.

</comment></comment></comment></comment></comment><comment><USER6> I think this email underscores something people miss when discussing Linus's communication style.

It is entirely possible, as we see here, to convey the criticality of something without crossing over into personal attacks.

<comment><USER7> Convey to us reasonable people, reading it at a distance as 3rd-parties?

Absolutely.

...

Convey to the intended recipient, with his inevitable personal/emotional/etc. attachments to the topic, in such a way that it takes the intended effect?

A pending question-of-fact, and one that can only be answered very indirectly and in the long run.

Heck, if the answer really is "no", then it's possible we may _never_ know! (until the NSA pwns us all, or at least pwns the subset of us who didn't kowtow to whoever the central socio-econo-political authority of that era will be)

<comment><USER6> I don't think it's actually a pending question whether avoiding personal attacks makes people more likely to listen to a message.

<comment><USER8> > I don't think it's actually a pending question whether avoiding personal > attacks makes people more likely to listen to a message.

That depends on the context. When you're talking about changing ingrained behaviors, emotional shock and awe can definitely be necessary and the shortest, most painless path to resolution.

the underlying incorrect assumption is that everyone will do the right thing, if only nicely and logically talked to. This is not true and obvious to anyone with experience managing large amounts of people, especially so when firing is not an easy option.

<comment><USER9> > _the underlying incorrect assumption is that everyone will do the right > thing, if only nicely and logically talked to. This is not true and obvious > to anyone with experience managing large amounts of people, especially so > when firing is not an easy option._

I've yet to see abusive management tactics work in the long term. It might work in the short term, but people with the means will take it as a signal to jump ship because no adult is going to accept abuse if they don't have to.

I've heard your exact sentiment echoed by people who aspire towards management, and it always comes across as a weird power trip fantasy.

<comment><USER8> > I've yet to see abusive management tactics work in the long term. It might > work in the short term, but people with the means will take it as a signal > to jump ship.

Like I said, depends on the context. Being mean has it's place, as does being nice. Those are the extremes and the Lions share in the middle is non- emotional transactionalism.

</comment></comment></comment></comment></comment></comment><comment><USER10> Damn, cold-bloodedly nice Linus is _terrifying_.

<comment><USER11> Indeed. I think this illustrates that being civil is not just about making people more comfortable, it's also more effective.

</comment></comment><comment><USER12> A bit offtopic, but it seems the issues the kernel is handling are getting even more esoteric

Iteractions between different permissions and conditions is getting ever more complex

But yeah, kernel shouldn't break userspace, and this should have been internalized already by the maintainers

<comment><USER13> Strengthening controls on a system while simultaneously not breaking any client is an incredibly difficult goal.

Unfortunately, unless there is a single, united team focussed on this single goal (kernel is not by design). Then some fingers will be burned, because of the complexity of getting it right.

Some contributors will struggle, and others will fail at it. Unfortunately, that's just stats.

<comment><USER14> The systemd and various "secure" linux teams keep adding poorly thought out access controls that no one understands, that have escoteric loopholes and break things in terrible ways.

I wish they'd just move back to the original unix permission scheme, plus jails.

BSD and solaris did much better jobs of this a decade ago. Hopefully one of those will eventually take over again.

<comment><USER15> Solaris and (some of) the BSDs have NFS-style ACLs, and do not have the original Unix permission scheme either.

</comment></comment></comment></comment><comment><USER16> Haha well at least he isn't cursing anymore

<comment><USER7> Only time will tell whether that change is for better or for worse.

(Unless your chosen metric-of-value relies on feelings instead of actual concrete results.)

<comment><USER17> I like the new tone. It is clear and conveys severity/urgency without the swearing and personal attacks.

Compare to: [https://lkml.org/lkml/2012/3/8/495](https://lkml.org/lkml/2012/3/8/495) That's the same guy, so clearly, the swearing didn't have much lasting effect :)

<comment><USER7> That's one person of many. And it's not a question of aesthetics of the message in the short term, but of the quality of the overall results in the long term and the effort needed to achieve them.

Hopefully this won't happen, but it's entirely possible that this change will result in Linus finding himself with a much greater number of broken, half- broken and/or subtly-broken PRs to review than ever before, increasing the chances of something like [https://lwn.net/Articles/57135/](https://lwn.net/Articles/57135/) succeeding.

And having a kernel backdoor ship worldwide is way worse than having a few recalcitrant kernel developers be exposed to - oh no! - coarse language. Results > the "fee fees".

<comment><USER18> Are you saying that Linus has been able to review fewer patches because his personality has driven people away, and by being nicer he'd be overwhelmed trying to review code?

<comment><USER7> I'm saying that the patches he has reviewed may have been given more attention-to-detail by submitters and lieutenants because of his personality, in which case by being nicer he would lend his time to be abused to a greater degree. Note that I said "more patches that are broken/semi-broken/subtly- broken", _not_ "more patches overall".

</comment></comment></comment></comment></comment></comment><comment><USER19> I'm not a kernel dev, I hardly know what the kernel is, but even I know this by now.. _if a change breaks something in user space, it 's always a kernel bug_.

<comment><USER3> The funny thing is that you've got that drilled into your head even though it's not true. Userspace breaks all the time, it's just that some of them matter to Linus and some don't, and he's never been clear about which is which.

Several months ago at work I found a vendor app that was calling listen(0), i.e., listen for up to 0 connections, and worked fine on older kernels because they rounded to a minimum of 8. Newer kernels stopped doing that. Nobody cared. Nobody got criticized, constructively or unconstructively. (By the time we noticed it was several kernel releases upstream so bringing it up would just be asking for _another_ change to userspace.)

Linus himself broke userspace once in the hope nobody would notice. Spoiler: they did. [https://lkml.org/lkml/2017/5/29/541](https://lkml.org/lkml/2017/5/29/541)

And that's not counting all the things that aren't part of the stable interface like procfs and sysfs nodes, device names, etc. There is a clear version of what Linus is trying to say. He's just never said it.

<comment><USER20> So your point is that if you don't report breakage it won't get fixed ?

</comment></comment></comment><comment><USER21> Heh, I know of one time the kernel did break backward-compatibility, intentionally even - [https://github.com/torvalds/linux/commit/6b99e3569ba17b9fd38...](https://github.com/torvalds/linux/commit/6b99e3569ba17b9fd38514d66591ae728b778e3b)

My fan controller used the sysfs paths mentioned in the commit message directly. So while the commit is probably correct that users of the lm-sensors library would not be affected, _my_ application was.

It was relatively easy to fix since I was the only user of the application, so I didn't care about being compatible with older kernels.

</comment><comment><USER22> I've got a good one, I found a Kernel Bug in the memory manager of all places by being a tryhard in mergerfs (and upstream fuse was broken as well)

[http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html](http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html)

</comment><comment><USER23> This attitude is what has allowed Linux containers to work as well as they do. You can put software built and tested on a very old kernel and it runs successfully on a modern one. Container operators do not have to deeply worry that every kernel update will break all their developer's applications.

<comment><USER24> This attitude is what allows _any_ operating system to be usable. Nobody would want to develop code under Windows (or buy that code) if they knew that it would break when the user moved from Windows 7 to Windows 10. In the IBM mainframe world, people can still run code written in the 1960s (without even recompiling it).

If Linus didn't fanatically enforce backward compatibility, nobody could rely on Linux for mission-critical systems.

<comment><USER23> There were BC breaks across Mac OS X's kernel. Windows does a good job keeping things backwards compatible as well.</comment></comment></comment>


Why Not Make? - <AUTHOR> https://hackernoon.com/why-not-make-db142ccb2081 <comment><USER2> I don't think Make is ideal, but:

1) It's simple, standard, everywhere, and everyone knows it

2) I haven't seen anything better. Most of the other systems are disastrously complex.

I certainly, never, in a million years would use an untested, untrusted, proprietary build system from a little startup which might go away tomorrow.

I do think there is room for Make 2.0. Not Make reinvented; just cleaned up, better for distributed builds, etc.

<comment><USER3> Make may be simple, but most real world uses of Make I've seen are NOT simple. The primary benefit of CMake is it imposes a modicum more consistency on the build system. I'll admit CMake still has this problem, though, due to how flexible it is.

</comment></comment><comment><USER4> I just had to deal with a large, handwritten Makefile when trying to package and cross compile something for buildroot.

Turns out it was easier to learn to use cmake and rewrite the relevant parts of the Makefile than fix everything in the Makefile that didn't work in a cross compilation scenario.

<comment><USER5> If I had a nickel for every time a developer said "it was just easier to rewrite..." I'd be a rich man. It always seems easier to start from a clean slate and do a rewrite than to try to understand someone else's code, but in the end you just wind up with a different set of hacks and complexities.

</comment></comment><comment><USER6> I feel like every single point against make in this article is considered a feature of make by many other people. But I guess more than why not, I'd like to hear more about what the alternatives are. I see this is an ad, and it implies but doesn't say explicitly whether this product fixes all these issues, or what it actually does at all. People have been trying to redo make for decades, and despite all its warts (and it does have warts) so far it seems like nobody has been able to supplant it.

No sandboxing? This complaint amounts to "it isn't pure". There are reasons to allow reading a file in a build rule that isn't a dependency. Allowing temp files in a multi-step rule without complicating or obfuscating the dependency graph is one of them. You can do anything you want in a build rule. How often is this flexibility actually a problem? If someone is reading from a file dependency without using make to depend on it, they already know they'll get the expected behavior; failure to rebuild when the dependency changes.

Unportable caches is asking make to solve a problem that make wasn't built to solve. And one could argue this isn't technically a build system problem at all. Wanting network caching for multiple hardware configurations is reasonable, but isn't what make is for.

No language abstraction is something I like about make. I use make for automating analytics and image resizing and all kinds of things that aren't C++ specific. Adding language abstractions would bloat and complicate make.

Timestamps are faster to compute than hashes. Occasionally this matters a lot.

<comment> loa-in-backup Sandboxing issue can be solved by extending cmake with a directive specifying which paths are accessible up front.

I might be willing to do a PR soon

<comment><USER6> Yes. This isn't quite what the author was talking about though. They used the term "sandboxing" to mean that dependency rules in the build system can act on things that they don't depend on. You're talking about a higher level sandboxed view of the file system.

The kind of sandboxing you're talking about can be mostly solved for any build system with some wrapper shell scripts, or an environment shell script. That's how most people are doing it.

At my work, there's a crazy sandboxing system for Linux written as a C program that actually creates an environment with a modified file system, and access to certain paths is strictly enforced... no process launched from inside this environment can access anything but the whitelisted paths, by any means. This is a very heavy hammer, and I suspect over the top and unnecessary. OTOH, this definitely prevents mistakes, and my company is large. I don't know the history here, but the existence of a system like this leads me to assume there must have been some large and real pains that lead to the development of a heavy-handed sandbox.

</comment></comment></comment><comment><USER7> While make, for me, fell out of day-to-day use once C/C++ projects waned, it's still a great and powerful tool. I really appreciate its consistency to a Unix philosophy where it provides the essential feature of target building through dependencies but leaves so much of the heaving lifting through good ole /bin/sh.

</comment><comment><USER8> Make is trash, but some in house tool made 2 weeks ago is guaranteed to be a worse choice. Just generate Makefiles with CMake like everyone else.

<comment><USER9> Some alternatives to consider: [https://buckbuild.com/](https://buckbuild.com/) [https://bazel.build/](https://bazel.build/) [https://please.build/](https://please.build/) These have been deployed for _years_ in major corporations.

<comment><USER10> > These have been deployed for years in major corporations.

CMake is 6th fastest language growing on github: [https://octoverse.github.com/projects.html](https://octoverse.github.com/projects.html)

Boost is switching to it, Qt may be switching to it for Qt 6, it's the most used in the jetbrains survey ([https://www.jetbrains.com/research/devecosystem-2018/cpp/](https://www.jetbrains.com/research/devecosystem-2018/cpp/))...

for the sake everything holy, this is _the_ chance for the C++ community to standardize on a build tool. Once this is done and settled, it will be much easier to improve CMake incrementally since there will mechanically be more people interested in improving it, and it will also be much easier to switch from CMake to next-gen-buildsystem-which-solves-all-cmake-problems in 10 years than the current fragmented situation.

</comment></comment></comment><comment><USER11> TFA makes a bunch of claims about the functionality of make being bad or dangerous but doesn't really provide any backing scenarios to demonstrate why. E.g. where timestamps can bite you, how you can miss compiler flag changes, etc.

Without this, it reads as FUD.

<comment><USER12> Not sure if you read the whole thing, but it seemed to me like it made pretty good points.

From the article: "In determining when to rebuild, Make uses the timestamps of build inputs rather than their hashes. This results in many unnecessary rebuilds when a file has been touched, but has not actually changed. If this happens deep in the dependency tree, then the rebuild will take a long time!"

That's kinda clear to me -- why would this read as FUD?

<comment><USER13> Make compares timestamp of object-file with source-file amiright? This is nice and cheap and stateless. Do modern build-systems maintain a separate tree of hashes? I haven't seen this in my day-to-day but I don't tend to work on the bleeding edge ... I'd have thought the cost of calculating hashes for trivial source-files would be maybe only an order of magnitude cheaper than compiling one? Over a large source-tree I'd expect these costs to mount - I think I'd prefer to take my chance with timestamps!

<comment><USER9> Modern build systems (Buck, Bazel, Pants, etc) will compute a tree of hashes and manage it for you. They will also do this in the background (e.g. using Watchman). This is how Google, Facebook, Uber, Amazon etc. build their code, so the approach scales well.

<comment><USER13> So what I guess is that this is for building at scale?

In my experience this kind of incremental build is a matter of developer convenience so that small changes can be made and checked quickly, but builds for test and release are always built clean.

I guess the codebases we're talking about here are at such a scale that the incremental approach is actually used for releases too?

It still seems to me as though this is something that s should be solved architecturally though with an appropriate composition of modules ...

<comment><USER14> It's for your day-to-day builds, so when you switch between build types while working you don't have to suffer a full rebuild.

<comment><USER13> by build-types you mean release to test vs. build for my own work? All my code gets released off a build server, and I'd consider it bad practice for a developer to be releasing their own code from their own workspace ...

<comment><USER14> Same build, sure, but you don't release it - you just run it on your own computer, as opposed to the development build you might ordinarily run, to make sure you didn't break anything.

<comment><USER13> I still can't help but feel this could be obviated by a more top-down approach, like decomposing into modules.

Even with a well-specified dependency tree there are areas where an incremental build can still bite you in the ass. Things like inlining and transitive dependencies ... I think you still need to build from scratch to be sure.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> What if the objections in the article were solved directly?

> Writing a Large, Correct Makefile is Really Hard > No Sandboxing

Would it be possible to track dependencies on a file level, simply declaring everything that gets read as a dependency? In the end, it is very likely that the generated artifact is different if any of the files touched to build it changes.

So, why not track open() syscalls made by make and its sub-processes? This obviously has some requirements towards the kernel to allow such tracking. It would also report helper files used by the toolchain and maybe even the code (executables and .so files) used by the toolchain, but one may argue that they are actually dependencies -- the artifact must be regenerated if the toolchain gets updated.

> Caches are Not Portable

It should be considered first if rebuilding on each node is really that bad. Next, caches are non-portable by nature if they use different formats, or if dependencies that were used to build the artifacts are actually different on the various nodes. So this sets limits on cache sharing in principle -- but this has nothing to do with make.

> No Language Abstractions are Provided

Not going to argue against that.

> Timestamps, Not Hashes

Is there anything fundamental to make that requires the use of timestamps? Otherwise this sounds more like "nobody has bothered yet to change make to use hashes".

</comment><comment><USER16> I've recently started to build my own static website generator (I know, I know, there are already millions of them). I really just wanted something simple that would allow me to generate a few haml pages together and deploy on my DO droplet.

I thought about Make because I remembered reading a nice article about how great it is for this kind of stuff. During my research, I also looked at Rake, which is Make in Ruby. Since I was doing my project in Ruby, I felt it would be nicer.

I really enjoyed using Rake, it's very nice and will definitely re-use it in the future. Martin Fowler has a great article[1] about Rake and how it compares to Make.

[1] [https://martinfowler.com/articles/rake.html](https://martinfowler.com/articles/rake.html)

</comment><comment><USER17> I haven't used make for years - but I miss the simplicity. It just does what it's supposed to do, in plain text.

<comment><USER18> GNU make has many obscure features. Don't know about other implementations.

</comment></comment><comment><USER19> Make is fine: [https://agottem.com/weld](https://agottem.com/weld)

Stop inventing build systems.

<comment><USER13> _" Makefiles are inherently evil"_ [0]

While I agree with this sentiment, it's hard to know whether it's more or less evil than munging imperative and declarative build instructions in an XML file ...

Has anyone ever just thought about just replacing the tabs with something else and leaving it at that?

My own experiences with Make show there's a bunch of other things that make it difficult to manage and maintain beyond a certain point.

[0] [https://ant.apache.org/manual/intro.html](https://ant.apache.org/manual/intro.html)</comment></comment>


Streets with Nooks and Crannies Are Beloved and Endangered - <AUTHOR> https://www.theamericanconservative.com/urbs/streets-with-nooks-and-crannies-are-beloved-and-endangered/ <comment><USER2> _" Why are nooks and crannies no longer produced? One reason is that their value is not understood, and in any case no longer taught as part of place- making."_

Many times they weren't deliberately produced, nor was their deliberate design taught: they were the result of accretion layers built up over time as new structures are built next to & on top of existing ones.

They're not dying out through lack of appreciation, they're dying out because most times it's just plain cheaper to tear down the existing structure and rebuild.

<comment><USER3> On addition some narrow alleyways are a bit dangerous —they are narrow and in the event of emergency they can find themselves blocked off (when fire escapes empty to them, as they usually do).

<comment><USER4> If a modern developer doesn't address liabilities first, they would quickly be out of business. Hence, design is restricted to the parameters of what one can successfully defend if sued.

Fire departments and fire codes are especially difficult to design around in tight spaces, as they can basically veto any construction that doesn't allow ample room for fire trucks to get around. The city also doesn't want to get sued for preventing the building from being built.

See the recent $800M MGM hotels settlement for the Las Vegas massacre. Expect more cameras, more searches, more cover your ass protocol. Not directly related to the article, but an example where one's first thought will be "how do I protect myself from being sued for any possibility in the future".

<comment><USER5> Just looked up the settlement: it seems crazy to me that the hotel could be held liable for the shooting. Is there really an expectation for the hotel to keep tabs on what its guests are doing?

Edit: I looked into it further: MGM was insured for 751M for the payout and I suppose they figured an additional 100M to get it out of their hair was worth it. The existence of a settlement doesn't create a precedent, but I worry about these incremental movements towards a society where there is some expectation of invasive tracking.

<comment><USER4> There is now. Prepare to have your bags checked, and hotel rooms inspected at least once, if not multiple times per day. It's a ludicrous settlement, and I'd love to see an explanation from the judge(s) that let the suit(s) proceed instead of throwing it out.

The whole situation in America at this point is you're liable for anything and everything that could be connected to you (and definitely if it's on your property), but it only matters if you have assets you can have taken from you. So better hope you're big enough to protect yourself as much as possible with a team of lawyers.

<comment><USER6> > There is now. Prepare to have your bags checked, and hotel rooms inspected > at least once, if not multiple times per day. It's a ludicrous settlement, > and I'd love to see an explanation from the judge(s) that let the suit(s) > proceed instead of throwing it out.

Because someone has to be held accountable for the tragedy, and since we can't hold politicians, or the gun manufacturers accountable for it, you find the next person in line.

<comment><USER7> > Because someone has to be held accountable for the tragedy, and since we > can't hold politicians, or the gun manufacturers accountable for it, you > find the next person in line.

What happened to holding the shooter responsible?

<comment><USER8> Gun owners in the USA aren't required to carry liability insurance, so going after shooters in civil cases isn't very productive.

<comment><USER7> True, but it isn't just to sue someone else just because they do have liability insurance.

<comment><USER8> There is no pointing in suing someone for hundreds of millions of dollars unless they have some chance of actually paying that much.

<comment><USER7> It's unjust to sue someone who is not at fault just because they have money.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> It's illegal to build things without enormous parking lots and roads around them in most instances now. [https://www.youtube.com/watch?v=0lvUByM- fZk](https://www.youtube.com/watch?v=0lvUByM-fZk) includes an illustration of how this even results in the destruction of nice, walkable places when old buildings are renovated in to apartments.

<comment><USER10> Quite a lot of developments in the UK - certainly in London - are proposing zero parking.

We had a (now shelved) plan near where I live to build 700 2 & 3 bed apartments in a new development with zero parking spaces in the design. This strikes me as blindly optimistic that of those 700 apartments (that will likely have between 2 or 3 people or more per apartment on average, so somewhere like 1500-2500 people) absolutely none of them will bring car with them... not even spaces for people who need a car for their disability!

I think their usual rationale of being "environmentally friendly" is really wake-washing/cover for wanting to fit in more apartments that sell for £650,000-1,000,000+ each, vs parking spaces which only sell for £25,000 each.

(incidentally is there a word for this willful ignoring of reality, where people basically just keep on repeating the same false/questionable statements as if they were genuine facts over and over regardless of any reasonable evidence to the contrary? E.g. this insistence that something is for environmental reasons when it is clear to _everyone_ that it is not, or the rhetoric politicians keep on wheeling out for e.g. Brexit. I guess "lying"is one word...)

<comment><USER9> " think their usual rationale of being "environmentally friendly" is really wake-washing/cover for wanting to fit in more apartments that sell for £650,000-1,000,000+ each, vs parking spaces which only sell for £25,000 each."

...and?

The fact that apartments cost more than homes means that the market values that area more highly for human habitation than for car habitation. Perhaps you simply can't afford to store your car there.

Also, what are you talking about? Lying? Please support your statement before leveling this accusation.

<comment><USER11> Sheesh, these "conversations". Just "eliminating" parking at new developments does not eliminate the _need_ for parking. People still have to get to work, school, the grocery store.

We had that happen near us 30 years ago by a developer who used a similar argument. A golf course was developed into 13,000 apartments with virtually no parking.

Overnight, the surrounding neighborhood's streets were changed. Once they had been calm quiet places with plenty of parking. Now they are loud, crowded with double-parked cars blocking the street, blocked driveways, yelling and fist- fights. They've tried many thing to "fix" the problem. But 30 years later, the problems only gotten worse. It still sucks. Of course the neighbors will oppose it - label it NIMBYism or whatever you like.

But, we do have a problem and it would be great to actually change the status- qo. So, here's a proposal:

*New buildings may be constructed without parking but _only_ if both of the following conditions are met:

1\. The occupants are not allowed to own or operate motorized transportation of any type. This is enforced by the local police and the fines are huge.

2\. 20% of the sales price of the new development is used to build mass transit.

<comment><USER12> I agree with the idea of impact fees being used to fund public transit but your first suggestion sounds very confrontational for a few reasons:

First, why are only the people who "got there first" allowed to use the public streets for storing privately owned items?

Second, why not require that people who do have parking are only allowed to own as many motorized vehicles as can fit in their parking and cannot use the public right of way to store their private possessions, with huge fines?

It seems like we need more carrot and less stick.

<comment><USER13> Tokyo manages this problem before it ever becomes a problem: you can't register your car to a Tokyo address unless you can prove you have a parking spot. It could be a spot in your front yard (in this case probably the entire yard) or a rented space in a parking garage. If you can't afford a parking spot at market rate, then you can't afford a car.

<comment><USER14> More than that, registration is actually a national requirement for full sized cars (kei's don't need a registered spot). And the country as a whole generally does not have street parking. Conjoined, means that illegal/congested streets from parking isn't an issue

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> "Building Living Neighborhoods" [https://www.livingneighborhoods.org/ht-0/bln- exp.htm](https://www.livingneighborhoods.org/ht-0/bln-exp.htm)

Christopher Alexander (of Pattern Language fame)

> Our goal is to help everyone make our neighborhoods places of belonging, > places of health and well-being, and places where people will want to live > and work. This has become possible through the use of Generative Codes, > Christopher Alexander's latest work in the effort to make possible > conception and construction of living, beautiful communities that have real > guts -- not the sugary sweetness of pseudo-traditional architecture.

> The tools offered are intended for the use of ordinary people, families, > communities, developers, planners, architects, designers and builders; > public officials, local representatives, and neighbors; business owners and > people who have commercial interests. The processes here are expressed in > the belief that the common-sense, plain truth about laying out a > neighborhood, or repairing one, is equally valid for all comers, amateurs > and professionals. They help people build or rebuild neighborhoods in ways > that contribute something to their lives. Many of the tools have their > origin in 30 years of work published in Alexander's The Nature of Order.

This is the site that made me believe that the "unit" of human society is the _neighborhood_.

('"Atom" is the smallest amount of a phenomenon that evinces all of its properties.' G. I. Gurdjieff)

<comment><USER16> Do you know where that Gurdjieff quote comes from? I've not heard it before.

<comment><USER15> IIRC "Beelzebub's Tales to His Grandson". It's not verbatim.

</comment></comment></comment><comment><USER17> I think it's about power.

If you have one guy calling all the shots, then he will necessarily have a very abstract and simplified view and use simple patterns like straight lines and rectangles. There just isn't time for complexity.

If everyone has their own little piece to design and evolve as they see fit, then they will take into account the local factors and nuances.

<comment><USER18> Agreed. re: power. But perhaps I'm seeing that power relationship differently. I'm feeling very strong parallels with economist Eleanor Ostrom's view on governing natural commonses [1].

Basically, she spent 4 decades disproving the "tragedy of the commons" in a whole set of defined cases, showing that a group of people DON'T selfishly destroy a commons when looking after it. She codified the requirements for a group of people properly governing a shared place/resource. Two of the 8 key requirements were 1) Local autonomy; 2) Appropriate relations with other tiers of rule-making authority (polycentric governance).

aka, powers must not be pulled too far from the place in which they are executed. to the extent that we need to seek efficiencies, system should offer through support from above to operate more efficiently (e.g., offer services and "kits" to self-manage). DO NOT CENTRALIZE OR CONSOLIDATE POWER.

Of course, the above recommendations can be discarded, but then collective governance fails, and keeping commonses alive and vibrant requires more and more central support systems to prevent its failure. Her rules are who you'd follow if you wanted decentralized and resilient governance structures and patterns.

[1]: [https://evonomics.com/tragedy-of-the-commons-elinor- ostrom/](https://evonomics.com/tragedy-of-the-commons-elinor-ostrom/)

<comment><USER19> Per your description "disproving" sounds wrong. Sounds like she proved its overall correctness but found ways to correct for it.

<comment><USER18> Ah good point. She found the structures in which commonses can thrive, the permutations of which past generations had stumbled through and "discovered" (which persisted through the practices surviving time). But then we forget them and invented other truisms that seem reductive and perhaps wrong :)

</comment></comment></comment></comment><comment><USER20> As often is the case, cars are the elephant in the room. In the alley? We have rebuilt our urban spaces for cars instead of people. Now we wonder at what we've lost but have trouble connecting it to the automobile because t's ubiquitous and most of us can't imagine it otherwise.

<comment><USER21> Yup. It's the main reason many European cities and Manhattan feel so engaging and alive in comparison to other US cities (just using my experiences).

In walking cities you interact with the city itself -- you can stop and look at things closely, walk into a small store you've never noticed before, run into a friend and chat, or pause and just people watch.

In car cities everything's far off and viewed through glass, your only interaction being which direction you point your car and how fast it moves. And becoming distracted by something interesting causes expensive and dangerous accidents. Plus, driving is inherently frustrating and exhausting, in my experience, especially when compared to walking which is at least a nice bit of exercise. You just want to be where you're going and WHY IS THERE ALL OF THIS TRAFFIC?

<comment><USER22> Manhattan? Manhattan seems like a grid made for cars. Not place full of "nooks an crannies". I'm not saying it's not nice but it doesn't seem to fit the article at all. Most European cities are a wonderful mess of winding roads. Manhattan is mostly a grid. They don't seem comparible.

<comment><USER23> Manhattan's grid was laid out in 1811, a hundred years before the automobile.

[https://en.wikipedia.org/wiki/Commissioners%27_Plan_of_1811](https://en.wikipedia.org/wiki/Commissioners%27_Plan_of_1811)

Lower Manhattan has plenty of nooks and crannies. My father had a secret street that he would park on when he needed to visit Battery Park City. It was a little-known street maybe one or two blocks long that was perfectly legal to park on but that hardly anyone knew about because it didn't go anywhere. I went with him a few times, and we were the only car to park there.

Plenty of nooks and crannies can be found, even in grids. There are always irregularities and sacred cows to be worked around.

Also, Chicago has a lot of nice nooks and crannies. Including an ordinance that requires that a cattle path be maintained through some of its downtown skyscrapers, and an old barn at the end of an alley.

[https://www.chicagoarchitecture.org/2009/04/08/the-loops- mos...](https://www.chicagoarchitecture.org/2009/04/08/the-loops-most- peculiar-building-2/)

</comment></comment></comment></comment><comment><USER24> They have been optimized away.

Grids, blocks, straight lines, clear boundaries, maintenance space, standardized signage, standardized safety and accessibility, standardized everything... these are all things which reduce TCO.

Non-standard, interesting, niche, characterful, bespoke, artisan, historic... these all carry hidden costs that manifest in property prices or taxes or inefficiency.

Everyone admires the aesthetics of the latter type of cities but not so many are willing to pay the price for them.

</comment><comment><USER25> Weird, the masthead photo is the street where I grew up. Now clogged with people lining up to Instagram, sadly.

Plus nobody lives there anymore, really - they are all the owners' vacation homes.

<comment><USER18> Interesting. Thanks! Seems to validate and speak to the point: that these places are scarce (and so overcrowded) and valuable (as wealth has moved in and captured it as showpiece with low utility).

</comment></comment><comment><USER26> There used to be a neighborhood in Boston called the "West End" which was actually pretty far east in the city, bumping against the North End, Beacon Hill, and the Longfellow Bridge which crosses the Charles River.

Most of the buildings were brick tenements built in the 1800s. One of its most famous native sons was Leonard Nemoy, who left the West End in his late teens to start his acting career.

The West End had narrow, winding streets, and the city government said this was a fire hazard because fire apparatus couldn't be driven down certain streets and alleys. That was true (I saw an old black and white picture of a fire truck that got stuck making a turn) but there was another motive in moving to have the tenements cleared and the area flattened: "Urban renewal." The city wanted other buildings built there, not to mention the elevated central artery. Over the strenuous objection of residents, almost everyone was cleared out and the buildings flattened from 1958 to 1960. The elevated highway, new hospital buildings, government buildings, and commercial structures went up in its place.

The history of the West End is covered by the West End Museum ([https://thewestendmuseum.org/](https://thewestendmuseum.org/))

Leonard Nimoy was never able to go back home; his parents relocated to West Roxbury. The central expressway was demolished in the 1990s and the highway put underground (part of the "The Big Dig", see [https://www.mass.gov/info- details/the-big-dig-project-backgr...](https://www.mass.gov/info-details/the- big-dig-project-background#the-problem-)).

</comment><comment><USER15> I was walking with my mom and her dog up Brotherhood Way in San Francisco and we tried to take a shortcut through the new development on Summit Way to get into Park Merced. (There is no shortcut, BTW. There are some abandoned could- have-been-stairs but, as I say, they are abandoned.)

Anyhow. The houses are each quite nice but the neighborhood itself is terribly soulless. It's like a locker room for people. The vibe was so creepy it was like a horror movie. You can check it out on street view: [https://goo.gl/maps/ZGANULkeqQjKF6Yy6](https://goo.gl/maps/ZGANULkeqQjKF6Yy6)

<comment><USER27> That's always super annoying. In my mother's old neighborhood there is a former train yard that was an empty field for decades. It was two or three blocks wide, about dozen blocks long, and split into thirds by a couple cross streets. When uppermost third was finally developed, instead of joining the existing street grid, they surrounded it in a fence and ran a silly meandering loop inside.

</comment></comment><comment><USER28> > Unbroken sheets of glass, prefabricated panels, poured concrete, steel > girders—these are the basic units of construction, and all resist the kind > of random puncturing and cobbling that subordinated the work of the > architect to the changing needs of the community.

Glass curtain walls are progress, civilization, and enlightenment. "Random puncturing" by contrast, is pernicious just from the sound of it. Romanticism.

<comment><USER29> Glass curtain walls are many things-- lightweight, easy to prefabricate, etc. You can make an excellent claim that they belong in the repertoire of any builder. But to claim they represent progress or civilization is just silly. The point of any architectural element is to serve the building, that building's purpose, and the people around it. For the same reason you wouldn't build a skyscraper out of masonry an outhouse with all glass curtain walls is an expensive failure, not a triumph of enlightenment.

</comment></comment><comment><USER30> Weird article. Doesn't really cite any trends or data about such nooks and crannies being at risk.

It features a photo of a newer glass building from Washington, D.C., likely downtown or in the "Golden Triangle" south of Dupont Circle. There are no nooks and crannies to be found in that part of town, never were. DC has the highest proportion, by 3x, of properties with Historic Preservation designation of any US city. Most of the city was built according to the L'Enfant plan which specified wide streets and strips of green space in front of buildings (they look and are maintained as front yards, but these "public parkings" are owned by DC and not private property, and must be maintained as green space).

</comment><comment><USER31> Agreed. My city's local "planning commission" has overstepped many old timers long planned future family-development agreements because big money has come in wanting to develop large scale housing communities. The communities once plotted as kid friendly cul-de-sac, have become thoroughfares for big business by touting "connectivity needs". It's a joke, especially when you see that the make up of the planning commission is 2/3 land developers and contractors.

<comment><USER32> Meanwhile, other purists decry cul-de-sacs as a suburban abomination that inhibit walkability.

<comment><USER33> There is a third way. Suburban single-family zones full of cul-de-sacs are designed to be metaphorically put under glass and never changed. Building massive towers, on the other hand, is very drastic and has the potential to destroy the character of a community.

I like the approach advocated by the Strong Towns movement: allow the next increment of development by right, everywhere. So a neighborhood of mostly single-family homes should allow accessory dwelling units (mother-in-law apartments) and conversion to duplexes by right. A neighborhood of duplexes should allow conversion to triplexes or quadplexes by right. A neighborhood of those should allow conversion to even denser development like townhomes, and multiplexes, etc. This allows a town or city to grow gradually and naturally.

The way they put it is, "No community should have to experience extreme change... but no community should be exempt from change". Wanting to build massive towers to address housing shortages is not ideal, but it's an understandable reaction, when it's illegal to address the shortage by having every neighborhood in the city "thicken up" a bit.

This is how the great cities we love all over the world became great -- through gradual, incremental change and intensification.

<comment><USER34> I like their idea for height restriction as well--allowing a story higher than those buildings around it.

<comment><USER35> Which puts the neighborhood under glass. If you are going to rebuild that means your payout needs to pay for the current value of the building, tear down fees, and new construction fees. If the neighborhood is in decline no problem - land is cheap and the buildings are not being maintained, but there is no demand to build anything there so nothing gets built. If the area is in demand land values are high, the people living there maintain their property (to ensure it keeps the value), and so the costs of building one more floor are always greater than the costs of keeping the building.

</comment></comment></comment></comment></comment><comment><USER36> LA used to have a lot of little cut throughs and stairways going up and down the hillier neighborhoods during the streetcar era. Some of them are still around of course, but they are pretty secret as their original use case (getting to the street car stop) has been gone for 60 years.

New builds don't really consider the pedestrian or the neighborhood, and are generally hostile to the cohesiveness of the area. They are massive and take up sometimes the whole city block (while only building 5 or so stories generally), and the only way to bypass them is to go all the way around them which can take 10 minutes sometimes (vs. like 2 if there was a cut through).

Due to the homeless, most apartments also gate their parking lots so you can't cut through there either. My current apartment is one of these places and walkability is severely limited because there are only two exits (despite the place taking up nearly a block). If the surrounding fencing was removed or at the very least I had an exit on every cardinal direction and not just to the east and south west, I'd be able to walk to the subway that is NNW of me 10 minutes faster(calculated by google maps).

</comment><comment><USER37> "Modernism is the problem!" harrumphed the American Conservative, forgetting as usual that X was also once very modern. ◔_◔

<comment><USER38> It's almost as if 'Modernism' refers to a specific (albeit vaguely defined) style, and not to the property of being new itself.

They're not ranting against semiconductors or antibiotics (both also relatively modern), are they?

<comment><USER37> Of course not, but these are _not_ relatively modern. They're now part of traditional fabric of society for current conservatives. I think it's more apt to look at how conservatives of the time felt about new and paradigm shifting advances.

They led the charges against the scientific revolution when it threatened to subvert authority & mechanisms of control, strongly opposing Copernicus, Bruno, Kepler, Galileo, and Newton. Opposition to Darwin continues to this day in some quarters. And antipathy towards modern advancements in reproductive health is still very strong.

In any case, if conservatives come at modernist styles of expression & ornamentation, they should bring receipts. Or their arguments will smack of the notorious cries of "moral degeneracy" for which conservative thought is justly infamous.

In this case, I feel like the author is found wanting and the article unworthy of HN. There are amazing, actionable critiques of dehumanizing trends in architecture and urban planning (Jane Jacobs, Christopher Alexander), but this is not one of them.

<comment><USER38> > Of course not, but these are _not_ relatively modern.

About as modern as the steel-and-glass/nookless style he criticizes, that gained prominence after the World Wars [1,2].

Ignoring the guilt-by-association/ad-hominem part of your post, what do you find so lacking in his critique? I'll grant that it's a long-winded way to say "it's ugly, sterile, and unpleasant to live in", but I'd say that's a valid (if subjective) complaint. What sort of critiques did Jane Jacobs and Christopher Alexander make? I'm very curious.

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

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

</comment></comment></comment></comment><comment><USER18> This remind me of this wonderful article on fractals: [https://aeon.co/ideas/feel-good-fractals-from-ocean-waves- to...](https://aeon.co/ideas/feel-good-fractals-from-ocean-waves-to-jackson- pollocks-art)

tl;dr - human instinct guides us to prefer aesthetics with a certain "fractal dimension" (measure of repeating patterns across scales, ranging from 1.0-2.0) that mirrors the dimensions found in nature: 1.3-1.5

This sort of symmetry is the signature of living and biodiverse places. We are hardcoded to prefer it, through deep history.

My read on this is that we're finding solace in manufactured landscapes that fall within this range, and nooks help create this balance of chaos and order. The places we build outside this range subtly increase our stress.

The place I've visited where this struck me most, was Juifen, the Taiwanese mountain town that inspired Spirited Away. Walking through the long market "tunnel" was like walking along a forest path -- you'd look up and there's be many layers of canopy and hanging vines and accreted layers of human intervention. It felt so organic and layers and mentally energizing. [https://www.tofugu.com/travel/jiufen-spirited- away/](https://www.tofugu.com/travel/jiufen-spirited-away/)

Disclaimer: failed biochemist and evolutionary geneticist.

</comment><comment><USER39> This reminds me again of why I am obsessed with A Pattern Language[0]. Building close together, setting maximum building height, quiet backs, etc. This may be a naive opinion but I think if development regulators in cities followed many of the patterns in A Pattern Language those cities would be much more enjoyable to spend time in.

[0][http://caper.ws/patterns/](http://caper.ws/patterns/)

</comment><comment><USER40> Yuri: There are a lot of alcoves in the Astridpark. You use this word, alcoves?

Ken: Alcoves, yes. Sometimes.

Yuri: There are not many people around in these alcoves at Christmas time. If I were to murder a man I would murder him here. Are you sure this is the right word, alcoves?

Ken: Alcoves, yes. It's kind of like nooks and crannies.

Yuri: Nooks and crannies, yes! Perhaps this would be more accurate. Nooks and crannies rather than alcoves. Yes.

</comment><comment><USER41> With the variety of systems in place that tend to reject this sort of "old world" architecture, I too find it sad.

That said, if anyone knows of an architecture school or architect that is investigating "modern" community housing that is people focused and not 'car' focused I would love to look at their work.

</comment><comment><USER42> I wonder if security might be a reason. Hidden areas are also areas where you can be mugged, attacked, etc. without witnesses. Maybe on some level people are intentionally designing things to avoid that.

</comment><comment><USER7> I really like the look of medieval villages. All the erratic roads, leaning houses, not a straight line anywhere. I sometimes wonder why a subdivision developer doesn't try to mimic that.

</comment><comment><USER43> This reminds me a lot of Shinjuku Golden Gai.

Also, of "Golden Guy", a Burning Man cluster of micro-camp groups that creates a Golden Gai type experience each year.

</comment><comment><USER44> Designing and building places people find nice to be in have gone out of style because building places that suck to be in the name of making them suck to do the "wrong" things is in fashion.

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

<comment><USER3> This isn't a one sided problem.

There are: owners, the public and law enforcement.

In SF there were (and are) laws against panhandling, being a nuisance, harassment, etc., yet owners and or business people had to pressure for additional laws (known as sit/lie laws) because police were not enforcing existing laws and some people were abusing and taking liberties. Yes there is an aspect of social failing in this, but local businesses and residents should not have to bear the brunt of this.</comment></comment>


Storm: Distributed and Fault-Tolerant Real-time Computation - <AUTHOR> http://www.infoq.com/presentations/Storm-Introduction

<comment><USER2> Storm really has come a long way since it's introduction almost a year and a half ago. Nathan Marz and the Backtype folks are really impressive people.

<comment><USER3> What has changed since the initial release?

</comment></comment><comment><USER4> I don't know what that page is doing, but memory usage and CPU went way up. Is Storm some thing that starts running in my browser when I open infoq.com, perchance?:-)</comment>


Lay-offs and Hiring Freeze due to Covid-19 - <AUTHOR> As most of you know the economic meltdown. This has resulted in numerous lay-offs across many organizations. While the companies irresponsibly fire people, the struggle doesn't end there.
There are numerous companies out there (quite large by headcount and global presence) who have been pulling out of interview process. This is very disheartening for candidates as they have no control over the situation.
Additionally there is no way to know when the hiring freeze will be lifted, and if you're candidature would still be valid.
In a time like this - I would like to put together a list of resources for people who are looking for job in software engineering due to being laid off.
Please comment and share your experiences -
- If your company is hiring - is remote interviews an option? what about on-boarding after the offer is rolled out? is the option open to remote candidates?
- If you have been laid off/fired
 - Do you know of firms who have gone on hiring freeze in the middle of process? How was this handled? Did the firm talk about next steps?
 - Do you know of firms who are open to hiring by conducting remote interviews? Have you been on-boarded remotely?
Please share your experiences, every little bit could help.
Stay indoor, stay safe. <comment><USER2> My company was expecting some money to come this year – like they always do every year – to keep operating. Except this year money kept getting delayed until it never came. They have literally fired all engineers so the company can keep alive and operate until they find ways to get government or other types of money/assistance.

Not like they did this on purpose, but it was related to this epidemy.

Very sad.

</comment><comment><USER3> Are companies really laying people off this early? It's still unclear what the exact economic impact on tech companies will be.

If they are stopping interviews, I bet it's just due to the social distancing requirements. Once they figure out remote interviews it will restart again.

<comment><USER4> [http://alugy.com/news/layoffs-in-the-us-running-at- almost-a-...](http://alugy.com/news/layoffs-in-the-us-running-at-almost-a- million-a-day/) (Layoffs in the US running at almost a million a day)

</comment></comment><comment><USER5> The company I work for is hiring in San Francisco, New York and Bengaluru. We're doing remote interviews and are setting up for remote onboarding. If interested, my email is in my profile.</comment>


A Technical and Cultural Assessment of the Mueller Report PDF - <AUTHOR> https://www.pdfa.org/a-technical-and-cultural-assessment-of-the-mueller-report-pdf/ <comment><USER2> I get why they did this.

Document formats have gotten so complicated that you have no idea whether the redaction software you use actually does its job or doesn't. Going analog then back gives you a very good guarantee that you can't get otherwise.

In order for there to be guaranteed no leaks, the redaction software has to be bug-free. Leaks can be anything, from how much free space there is between allocated regions to highly precise layout placement information that you can use to figure out censored words on a trial & error basis if you have a copy of the used software. So you can't really come up with a watertight formal definition of leak-freedom, which makes proving that your software removes all leaks impossible, at least in rich-text documents. The only way I see is to go full ascii or something.

<comment><USER3> I wonder how different it is to carry a USB stick from SCIF to SCIF compared to just moving paper.

I doubt that top secret counterintelligence information in the report can be retracted in normal office space. Installed software in a SCIF may be highly limited and out of date.

<comment><USER4> SCIFs generally have some sort of TS/SCI network connectivity, so the appropriate solution would to just use it. But every agency that has SCIFs wants their own network, because it would be disastrous if TLA #1 could see TLA #2's cafeteria menus. Congress, the White House, all seventeen IC agencies, and every customer agency have at least one; and people on one don't necessarily have the access they need to others (or the cafeteria menus would be visible, and we can't have that). Given sufficiently pathological connectivity, it can be easier to just have someone courier a DVD.

There's absolutely no legitimate reason for a computer in a SCIF to have outdated software. Data diodes exist, and there is no technical obstacle to setting up a mirror of whatever package repository you like. (Political obstacles may be non-trivial, because compliance is far more important than security, and too many members of upper management believe that classified networks are somehow magically secure.)

</comment></comment></comment><comment><USER5> The gold standard for redaction is to replace the redacted text with nonsense of similar length. Otherwise, you retain precise metrics for the redacted text. With guesses or context you can fill those in with high probability. In an extreme case, the redaction might be a name of let's say a member of Congress, so the candidates can be narrowed down to a tiny number. There's considerable work on this, notably the "Declassification Engine" [0]. I believe it would be possible to apply even better word models (such as GPT-2) to improve the results even more.

I'm interested in whether this document was redacted in such a military-secure way, or whether black bars were simply placed over the text. I've reached out to a couple of news organizations offering my consulting help, but didn't get a nibble.

[0]: [https://www.newyorker.com/tech/annals-of-technology/the- decl...](https://www.newyorker.com/tech/annals-of-technology/the- declassification-engine-reading-between-the-black-bars)

<comment><USER6> > With guesses or context you can fill those in with high probability. In an > extreme case, the redaction might be a name of let's say a member of > Congress

Something like this actually happened somewhere in the report. A name was at the end of a line, causing a part of it to break unto the next line. The few, black characters present on the second line lead readers to theorise that the name ends with "jr".

<comment><USER7> Maybe Mueller figured out who killed JR?

</comment></comment></comment><comment><USER8> What a beautifully geeky article.

I was wondering if they'd want to also print-then-scan the document out of a fear that redactions can be undone somehow? Stories in my memory about how older revisions of documents were still retained in the meta (or otherwise not immediately visible) data of documents (at the very least documents from Microsoft Office).

<comment><USER9> Yes, that's basically it. (Source: I've previously worked for the government.)

</comment></comment><comment><USER10> One of the major shortcomings of this simple redaction method, and not mentioned in the article, is actually from a security point of view.

This is less of an issue with Mueller report but was quite noticeable with Snowden leaks. If your redactions are of short words or group of words, you can sometimes make pretty good guesses as to what was redacted. There are all kind of methods you can employ, statistical etc., to aid with this.

A proper redaction tool could avoid this by varying the length of the redactions. PDFs even have layout hints now, so it's not that complicated technically.

The copy-and-scan security method can be replicated by a flattening pass, that does the same, without losing any of the accessibility benefits.

<comment><USER11> The problem with that approach is that varying the length of the redacted text would effectively alter the document and forever muddy the waters as to what the original text could be. This would likely result in endless speculation that what might be released at a later date is not, in fact, the original text. It also makes it much more difficult to assess whether or not fighting to get one or more parts of redacted text released is worthwhile. (i.e. what appears to be a name or phrase in one area might not be deemed important vs a page and a half in another or vice versa)

So let's say Congress takes this to court and gets an order requiring the A.G. to disclose the contents of one or more sections/types of redactions. There would likely be little confidence that any future unredacted text they receive was the original text rather than yet another modified version of it (i.e. maybe one or more words would be added/removed etc.) By disclosing the exact length of the text, as imperfect a solution as that is, it makes it likely that any future alterations can be more easily detected.

</comment></comment><comment><USER12> > In releasing the redacted PDF of the report to the public, Barr avoids > suspicion that the document had been edited (changed) in addition to > straightforward redactions. PDF serves the need to unambiguously assure the > press and the public that they are seeing Mueller's actual report.

This is such a shame. The PDF wasn't even signed.

Is an HTML file with a hash provided directly by Mueller/whoever is doing the redacting too much to ask?

> There's really no model for redaction of HTML-based web content.

Is replacing censored text with a fixed number of some character not good enough?

<comment><USER13> With either a PDF file or an HTML file, there's no way to prove that the document is a redacted version of the original, rather than an edited-and- redacted version of the original. I also don't see what using PDF adds here.

<comment><USER14> I think it's because many people think you can't edit PDFs, but they know you can edit text documents.

<comment><USER15> Even if you really can't edit PDFs, there's nothing preventing you from recreating the document and exporting that as a pdf. After all, it's all text.

</comment></comment></comment></comment><comment><USER16> A proper standard for redacted documents would be a format where the author provides a list of ((text, position), signature) entries and the redactor is free to remove elements of this list when redistributing it. (edit: to show the deletions, the author would have to provide a singed background shape as well where the text entries is cut out already)

</comment><comment><USER17> Printers add small invisible yellow dots to pages to make them traceable. Is this a viable way to find out where these pages were printed?

<comment><USER2> Most of them are probably lost due to the heavy compression applied... but extracting yellow dots from scanned documents is possible in theory. E.g. it was most likely the reason why Reality Winner got arrested so quickly after she gave NSA documents to the press: [https://en.wikipedia.org/wiki/Reality_Winner](https://en.wikipedia.org/wiki/Reality_Winner)

</comment></comment><comment><USER18> Seems AI could be used to reconstruct a portion of the redacted sections of the document. There are already viable human translations proposed in this thread. . .</comment>