How We Killed Privacy - <AUTHOR> http://www.foreignpolicy.com/articles/2013/08/23/how_we_killed_privacy_nsa_surveillance

<comment><USER2> "How we killed privacy: in 4 Easy Steps", the registration guide for creating an account.

I honestly thought that was the article, until I saw the "click here for the actually article" button.

<comment><USER3> How wonderfully ironic.

</comment></comment><comment><USER4> The title of this piece is "How _We_ Killed Privacy -- in Four Easy Steps". Honestly this just makes me angry. I did not ask for this, I did not have part in any of these steps:

1\. _Decades-old Privacy Laws_ : All of the laws and cases cited were passed or occurred before I was born. Starting a few years after I reached a voting age I have been involved: showing up for elections, writing my representatives about these laws and laws like them, communicated that how they voted on these laws would directly affect how I vote in the next election. What effect has that had? Tell me what else I realistically can do within the current framework to change these obsolete laws. Tell me how I can influence the judgements of a secret court like the FISA court, or have any effect as a private citizen on the modern interpretation of decades-old cases like Smith vs. Maryland.

2\. _Our Evolving Use of Technology_ : in general, yes, people have been very quick to jump on Facebook, Twitter, etc. and share all the details of their private life. Again though, people like me who are in the industry (and the type to read HN) have warned people over and over and over again that anything they put on the internet is basically in the public record. Every misuse of volunteered information that this article is hemming and hawing about was foretold by someone like me and by me in conversation with people I know. For goodness sake, the AOL Search Query leak happened 7 years ago and even then it was old news that the aggregate data that people give to search engines and social media could be used to unmask and identify them. We were hoping news of that leak would be a wake-up call to the public about an issue we had been raising for _years_. So again, tell me what more I could have done.

3\. _Our Consent to Being Tracked Online_ : My thoughts on this "point" mirror those of the previous one. I have done everything I can to influence people I know to be more careful with how they allow themselves to be tracked. We collectively have written blog posts, articles, comments, and tried to create technical solutions around this issue, but we are ignored. What else can we do?

4\. _Our Response to Terrorism_ : Haha, yeah. I sure had a big role in this. /sarcasm When 9/11 first happened, people like me were urging caution domestically. We wrote letters to representatives, blog posts, talked to people, etc. warning them against losing our freedom in pursuit of security. When the illegal wiretapping was exposed under Bush we protested. We warned that this was just the tip of the iceberg, as we clearly see now. When the TSA started pushing out the body scanners, we protested, the public protested, but the agency continued on with impunity. I have argued against the Department of Homeland Security since its inception. Against the ever-expanding scope of the NSA, the TSA, the executive branch in general through it's ever-growing list of agencies. What good has all that done me?

Don't you _dare_ say that I had anything to do with the erosion of our privacy. I have fought it every step of the way. At this point I am re- evaluating how much our family needs to be online at all. I will readily admit that we face none of the physical brutality and oppression that were present in Nazi Germany or Soviet Russia, but the information machinery is already past that point in America. My heart hopes that it is not too late to correct, but fears that we are just waiting for the physical to catch up with the digital. My family stays in America for the same reason people stay anywhere: this is our home. I love my country, but I feel helpless to fix it. The people do not have power in the United States.</comment>


Boris: A tiny but robust REPL for PHP - <AUTHOR> https://github.com/d11wtq/boris <comment><USER2> That looks good, although one may wonder at the long term support prospects (the author says "I'm in the process of transitioning away from PHP to Ruby.").

For your delectation, other PHP repls include :

\- The basic built-in repl "php -a"

\- Facebooks phpsh : <http://phpsh.org/>

\- PHP Shell : <http://jan.kneschke.de/projects/php-shell>

\- php-repl : <https://github.com/tailrecursion/wigwam>

If you want something more customised to your needs, investigate the plethora of readln and posix functions in PHP and dive right in!

<comment><USER3> That is a fair concern to have, though I will be working on and maintaining Boris for the foreseeable future (already have a bunch of features planned, to make it more extensible).

As with Swift Mailer, which I maintained for many years, if the time comes for somebody else to take the project over, Boris will live on under a new maintainer. That's very unlikely in the next couple of years though. Plenty of activity via pull requests now.

</comment></comment><comment><USER4> To those who, like me, thought _PHP already has this_ :

> PHP's interactive mode does not print the result of evaluating expressions > and more importantly, it exits if you type something that produces a fatal > error, such as invoking a function/method that does not exist, or an > uncaught exception. Boris is designed to be robust, like other REPLs, so you > can experiment with things that you know may error, without losing > everything.

<comment><USER5> I was wondering the exact same thing. Sounds cool.

Anybody knows of a debugger equivalent to ipdb (python) / pry (ruby) for php to allow live debugging stuff on the server?

<comment><USER6> You can live-debug with xdebug. Have been using it with vim and it worked.

<comment><USER7> Seconded. xdebug and the vim plugin "vdebug" ( <https://github.com/joonty/vdebug> ) work like a charm.

</comment></comment></comment></comment><comment><USER8> REPL's in PHP are quite hard due to the fatal error issue, among other things.

I wrote one (<https://github.com/apinstein/iphp>) a long time ago that got around a lot of these issues using temporary files, but his idea to use forking is really neat. I never got multi-line input working, either. I have been thinking about re-doing it with runkit, but now I'll have to play around with BORIS and see how it works.

</comment><comment><USER9> Very useful tool, partially useful is being able to start a Boris shell mid script:

$boris = new \Boris\Boris('myapp> ');

$boris->setLocal(array('appContext' => $appContext));

$boris->start();

so that you can poke about.

</comment><comment><USER10> Does it mean that now full PHP support could be added to Light Table?

</comment><comment><USER11> "There's no chance it can work on Windows, due to the dependency on POSIX features". Too bad.

<comment><USER12> PHP and Windows are often enough at odds that not having a nice REPL is probably going to be the least of your problems. The other poster is right, bring up a VM and be happy.

<comment><USER13> Huh? PHP and IIS work perfectly fine together. MS has worked really hard to make PHP a first-class language on their OS. PHP 5.3 and IIS 7.5+ are dead simple to get working. Azure features PHP support as one of their main features.

I've even got a client on an ancient Windows 2000 box running PHP. Took all of an hour to get running. Yes, not the most preferred stack, but they aren't at odds.

<comment><USER14> If you are using IIS/PHP how interchangeable is that with LAMP? In other words if I develop locally using IIS/Windows can I just drop the same code onto a LAMP server without breaking anything?

<comment><USER15> There are a few functions that are not available on Windows.

If you hard-code paths in the code that refer to Linux-specific things, it won't work in Windows.

That said, if it works on Windows, it will most likely work on Linux, but a VM should still be favored due to the probability of prod being Linux.

</comment></comment></comment></comment></comment><comment><USER16> Interesting. Even if most of PHP core devs are stuck in another era, the community manages to keep the boat afloat.

<comment><USER17> What is that other era like, exactly?

Edit: it was an honest question. You casually threw that statement about living in another era out there and get upvoted for it, while I'm being punished for asking you to elaborate on what you actually mean. Is that the PHP hate brigade at work or was there some kind of misunderstanding?

<comment><USER18> Very pleasant, actually, as long as you get used to people telling you that you're living in another era.

<comment><USER19> Perl programmers were in another era before you.

Perl - for original hipsters.

<comment><USER18> Perl - one of the few programming languages that PHP developers are allowed and encouraged to feel smugly superior over.

</comment></comment></comment></comment></comment><comment><USER20> Looks great now I can dump my 60 lines of tape, shoe strings and "I do not have time for this" and use a serious tool.

Thank you.

</comment><comment><USER21> I looked at it a while ago and it seemed abandoned.

Going to take a stab at using it in WP-CLI: <https://github.com/wp-cli/wp- cli/pull/437>

</comment><comment><USER22> Laravel 4 [1] has something called Tinker built in, that lets you interact with your application in a REPL environment.

[1] <http://four.laravel.com/>

<comment><USER23> I can't find anything named tinker in the latest laravel source. Where did you find it?

<comment><USER11> I can't find any documentation and haven't tested it yet but here's a class for a 'tinker' command in the Illuminate (Laravel) sources: [https://github.com/laravel/framework/blob/master/src/Illumin...](https://github.com/laravel/framework/blob/master/src/Illuminate/Foundation/Console/TinkerCommand.php)

'php artisan tinker' on the command line should bring it up.

</comment></comment></comment><comment><USER24> I wrote this shell script to evaluate php expressions directly inside vim(<https://github.com/zweifisch/pipe2eval>).

</comment><comment><USER25> I'm using phpsh as a REPL for PHP: <https://github.com/facebook/phpsh>

Are there any benefits in switching to BORIS for me?

</comment><comment><USER26> Brilliant! This seriously needs to be in PHP core.

</comment><comment><USER27> Looks useful! What does the name BORIS stand for? I see the creator is called Chris...

<comment><USER28> Maybe the author is a fan. The Wire - "Why always Boris..." <http://www.youtube.com/watch?v=JyHuG1ks04A>

</comment></comment><comment><USER29> cool, will be useful to sharpen my php skills.</comment>


MIT Researchers Pushing The Internet Up To 1000x Faster - <AUTHOR> http://hothardware.com/News/MIT-Researchers-Pushing-The-Internet-Up-To-1000x-Faster/ <comment><USER2> good news, but the post is too shallow.

this one has more meat: <http://web.mit.edu/newsoffice/2010/100x-internet-0628.html>

the promising technology is "Optical flow switching": <http://www.mit.edu/~medard/papersnew/WOBS%20Final.pdf></comment>


Serverless Computing: One Step Forward, Two Steps Back - <AUTHOR> https://arxiv.org/abs/1812.03651 <comment><USER3> On the same note, CloudFlare's approach to serverless computing by leveraging V8 sandboxing instead of traditional virtualization is fascinating: [https://blog.cloudflare.com/cloud-computing-without- containe...](https://blog.cloudflare.com/cloud-computing-without-containers/)

Considering challenges of interconnected cloud computing and common IR (of which the latter is mentioned in this paper) an interesting distinction arises: WASM, in comparison to containers, brings us a single language (JS), and through this, possibly a single "orchestrator" (V8 Isolates). Of course, this is more or less saying that the world would be a better place if everyone would be driving a Volkswagen. But this is like a second chance to iterate such idea and maybe do something about it. Isn't this a step towards the future of cloud computing?

<comment><USER4> Workers are network addressible which seems to directly respond to one of the complaints in the article. Beautifully, if you call one Worker from another they have a decent chance of running on not just the same server, but in the same process. When one Worker calls another its data doesn't even leave user- space, even if the two Workers are owned by different people. Imagine calling a third-party API and having your request never even need to leave the process to be handled.

<comment><USER5> If the request never has to leave the process, that means there isn't anything the third party API is doing that persists state or calls out to another backend. In that case, wouldn't it just be better to import this third party API directly as code and call it for significantly better reliability, performance, and reduced complexity?

<comment><USER4> There are advantages in being able to have a security barrier between your code and that of your customers, and that you can push releases etc without having to update every downstream consumer.

More importantly though, we're working on incorporating storage in a meaningful way.

<comment><USER6> If the third party code is running in the same process than the security is managed by V8 (or whatever runtime). Does such a thing exist in other managed languages? Does anyone know if C# or Java(for example) have the concept of untrusted libraries?

<comment><USER7> You could think of "untrusted library" as of a wrapper around an HTTP API. The code you don't run, but depend upon it's results.

</comment></comment></comment></comment></comment></comment><comment><USER8> Am I the only one that thinks severless is about creating a bunch of vendor locked-in technical debt?

<comment><USER9> You're not the only one.

Some time ago I worked with a bunch of people who staked their careers on moving everything to AWS and converting it to serverless architecture. Here is just one example of how fishy it was. They used Dynamo. During presentations to the outgroup, they constatly praised Dynamo as being flexible, scalable and fast. However, internally they _constantly_ struggled with various limitations of the database, from limitations of indexing to not being able to get certain types of metadata.

My point is, the architecture they were designing was heavily bent around Dynamo's strength and weaknesses. Considering how extreme and peculiar those strength and weaknesses are, switching to another database would require heavy re-engineering of the rest of their architecture, much more so than, say, switching between Oracle, MS SQL and Postgress.

<comment><USER10> Not sure I understand this. Why did they choose Dynamo? And what does serverless has to do with this?

This seems like a simple case of people choosing the wrong tool for the job, without really understanding its limitations or capabilities.

> say, switching between Oracle, MS SQL and Postgress.

That's because those are all relational DBs that use SQL. If they chose some other NoSQL DB they would likely have encountered similar "peculiar" strengths and weaknesses. And I'm still not sure what this has to do with serverless - they could've have easily implemented a serverless architecture with MySQL or Postgress on RDS instead of Dynamo. But they chose not to.

<comment><USER11> Aws might have fixed this by now with severless aurora, but as of earlier this year the issue was connection pools didn't work on lambda functions due to their ephemeral nature not being able to keep the tcp sockets open for more than a few minutes before the functions froze or were terminated.

<comment><USER12> We use pools in lambdas to Amazon Aurora and it works out fine. Only limit we hit was when the db server was configured way too small.

<comment><USER13> Are you running your Lambdas inside the VPC (and incurring huge cold-start latency), or are you running your database exposed to the public internet? I've avoided using Lambda for anything that requires relational database connectivity because those appear to be the two options, and neither is viable for me.

</comment></comment></comment></comment></comment></comment><comment><USER14> As others here have already noted, serverless is still not fundamentally any better than good old CGI, and despite recent advances in virtualisation it still follows the same stateless request-response paradigm.

For me the biggest shortcoming in serverless is that it is actually a poor fit for modern interactive web apps (and apps in general) with a constantly changing state.

Technologies such as HTTP/2, websocket and SSE are clearly pointing in the direction of long-running client-server interaction, yet current serverless solutions have (to the best of my knowledge) no answer for that.

I think the big challenge is in how to do serverless computing with long- running processes, in a way that solves isolation and scalability at the same time.

<comment><USER15> What's happening here that an Layer 7 Load Balancer, Multiple Serverless Functions, and a Websocket can't handle?

AWS released exactly that during the last re:Invent with the Websocket- integrated ALB being capable of triggering Lambda

<comment><USER16> You're basically locking yourself in with a particular vendor if you choose to use that tech (rather than a standard stack deployable anywhere with compute power).

<comment><USER17> Going beyond the vendor lock-in, one of the biggest initial draws of serverless - from speaking with friends - has been simplicity in situations where state isn't a concern. On the other hand, here we're discussing a bunch of hoop jumping to get stateful functionality that might more easily achieved by adding a library such as SignalR, or socket.io into your app.

Whilst this is probably a few screens to set up via the AWS, and can obviously be automated, you add complexity to development and delivery. Critically you also make it harder to diagnose and fix problems.

Like anything it's a trade-off: for some apps these issues won't matter so much, for others they will. For us, it would definitely be a problem.

<comment><USER18> Serverless is a tool with good use cases where your tradeoff-win will be great scalability. It's not that great for general use (yet) IMHO. You can create a "session" in redis pretty easily if you're willing to add another database as a requirement. That way you can share state. It's also very new so the ecosystem will keep maturing and enabling more use-cases.

</comment></comment></comment></comment></comment><comment><USER19> I loved the article [https://arxiv.org/pdf/1812.03651.pdf](https://arxiv.org/pdf/1812.03651.pdf)

It mentions two temporary bottlenecks:

1\. Functions can run only for 15 minutes and experience cold-starts.

2\. You can't use specialized hardware like GPUs.

It also mentions two fundamental bottlenecks:

1\. Serverless functions are run on isolated VMs, separate from data. In addition, serverless functions are short-lived and non-addressable, so their capacity to cache state internally to service repeated requests is limited. Hence FaaS routinely "ships data to code" rather than "shipping code to data."

2\. Because there is no network addressability of serverless functions, two functions can work together serverlessly only by passing data through slow and expensive storage. This stymies basic distributed computing. , With all communication transiting through storage, there is no real way for thousands (much less millions) of cores in the cloud to work together efficiently using current FaaS platforms other than via largely uncoordinated (embarrassing) parallelism.

Disclosure: We just shipped serverless in GitLab [https://about.gitlab.com/2018/12/11/introducing-gitlab- serve...](https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/)

<comment><USER20> As far as "bottlenecks".

Almost all applications have data separate from code. Most implementations don't run their applications on the same server as their databases.

Most app servers shouldn't be "caching state locally" anyway. Once you do that it makes scaling horizontally harder - you have to Implement sticky sessions.

And in all practicality, I would assume that most people are using EBS for their storage which is network attached storage.

Two lambda backed microservices work together just like any other microservices - via known urls and over https.

<comment><USER21> > Most app servers shouldn't be "caching state locally" anyway. Once you do > that it makes scaling horizontally harder - you have to Implement sticky > sessions.

Why not? In-memory caches are fast and fairly uncomplicated to write.

<comment><USER22> You always have to apply pressure to keep the system decoupled or you get a Ball of Mud. If you switch to micro services and serverless and then have a high fanout and caches everywhere just to make the numbers work, you haven't gotten rid of the Ball of Mud, you've just hidden it in plain sight.

Serverless and embarrassingly parallel problems look like pure functions punctuated by one or two state changes. To get that you should probably be passing all the data in, instead of communicating out of hand with a cache to keep your fanout from looking awful (again, hiding the problem).

<comment><USER23> But who is doing the "passing-in" then, and where does the data come from? This still sounds like hiding the problem...or more specifically, making it someone else's problem.

<comment><USER22> Who does the passing in in development mode? Where does the data come from?

You have this problem anyway, and it blocks you from launching new code. These out of band communication mechanisms always lead to problems with developer ergonomics and repeatability.

It's essentially a larger version of the problem of testing pure functions versus heavy usage of mocks. Passing the data in directly makes testing the callee very simple.

</comment></comment></comment></comment></comment></comment><comment><USER24> I'm not sure if i understand their view on fundamental limitations - <USER2> don't seem fundamental to me:

1\. It does not seem impossible to imagine a function that spawns code close to data, be it on a VM with a connected fast SSD drive already populated with data. Also, Lambda-at-edge and Cloudflare workers are already more like "shipping code to data.", or " the customer" in this case.

2\. Functions are load-balanced and potentially parallelisable to millions of invocations. The only missing piece is some kind of parallel-invoke call, to give each instance of a function a distinct piece of data to process, and an identifier to save the result under. The identifier could easily refer to a local disk location, in some future implementation.

Also, another point from the article: "FaaS discourages Open Source service innovation". seems wrong to me, as it may be said only about current super- early implementations, reason being, they are new.

In the long-run, I'd expect serverless to help open source, because of a simplicity of deployment. We will likely have projects working on an abstraction layer of compute and storage, hiding the underlying cloud or multi-cloud implementation. (Kubernetes is one candidate, it just needs ideas in the like of Virtual Kubelet to become more serverless).

<comment><USER5> >Cloudflare workers are already more like "shipping code to data.", or " the customer" in this case.

That's shipping code further from the data, unless you store all of your data on your customers' hardware.

<comment><USER24> The closest data would be in the datacenter closest to the customer, not on customer's hardware. But I mentioned it to illustrate that the code already is location-independent a little.

</comment></comment></comment><comment><USER25> Serverless applications suffer from a few under reported drawbacks:

\- Local development is complex. Does one provision a full cloud environment per developer? Emulate a cloud environment locally? These are solvable but it's a grind of special cases.

\- Limited customization. Eventually one needs to customize the language / libraries of the lambda. Again these are solvable with a grind of special cases.

\- Limited execution model. Not all compute tiers are the same. Some quickly assemble results from a database. Others run for a long time. Others build up a model in RAM before delivering results. Serverless optimizes for some but not all models.

Unlike serverless / lambda, all of the above can be addressed by containers.

\- Containers have orchestration solutions for local development and deployment

\- Containers are designed to support customization

\- Containers can be deployed to run in many different ways.

Not to be a booster, but in my experience containers are the scalable compute architecture.

<comment><USER26> > drawbacks:

> ... Serverless optimizes for some but not all models.

How is this a drawback? General purpose things are equally _bad_ at all things. If serverless is optimal for some models, those are the places you use serverless!

<comment><USER25> Please, share the use cases where serverless is the optimal choice.

Because I've tried it. For problems like thumbnail generation which is literally the canonical example [1]. And even in that case, found myself switching the workload back to containers to control the exact version of imagemagick to prevent a color gamut bug.

1\. [https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example...](https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html)

</comment></comment></comment><comment><USER27> A much needed paper which goes into the programming model in serverless rather than the operational model. Although, the first cases study is obviously bad for serverless (training a ML model) whereas the second case study does not indicate bad results (using trained ML model) as half a second latency is acceptable. As the paper itself quotes:

`One might argue that FaaS encourages a new, event-driven distributed programming model based on global state.`

Yes, exactly. It is not made for cluster computing or data-centric applications. It is made for making applications more modular, atomic and compositional with the upside of less ops and more scale and the downside of lower performance.

<comment><USER28> I think that the authors of the paper would say that, ideally, serverless would be ubiquitous, the obvious choice for the vast majority of use cases. A pipe dream? Perhaps. But that's the dream, and we'll never be able to make the dream a reality unless people write papers like this one that highlight the work that separates where we are from where we want to be.

</comment></comment><comment><USER29> Going through the article I think they made some mistakes in analysis and also miscategorized some features.

1) Limited Lifetimes, Stickiness: These is good and leads to good design when you scale beyond a single server. It prepares you for dealing with the reality that if you want to run a service 24/7 with no downtime you need to prepare for things like different versions being in production, failures, and stale caches.

2) I/O Bottlenecks: If you are parallelizing your workloads you will actually see more aggregate bandwidth than you could scale up quickly with normal server hardware. Sure a single Lambda might not have the full amount but you can run 1000 of them at once.

3) Communication through slow storage: This is not entirely true, you can call another Lambda directly but yes you can't access a particular instance. That is a good thing. Designing systems where you need to return to the same instance is an anti-pattern.

4) No Specialized Hardware: I don't expect this to be a limitation for long. There is no reason why you couldn't ask for specialized hardware in the definition of a Lambda and the scheduler take care of it. It will, in fact, be better than the status quo because parts of your application that don't need that specialized hardware won't need to pay for it. In a typical larger application you would probably end up running part of your heavy CPU load inefficiently on your GPU hardware because it would be convenient. Also, most of this might be unnecessary in many cases since you would likely take advantage of a service that was specifically designed to run specialized workloads. Only if you DIY would need this support. Lambda is especially good at coordinating such services.

5) Faas is a datashipping arch: Not even true today. Lambda lets you move the computation to the data like they are with CloudFront Lambda, S3 Batch and Snowball Edge Compute. It is in fact easier to execute the code near the data when encapsulated in this way.

6) FaaS Stymies Dist Computing: Maybe they have applications that can afford to fail at any point and not recover but keeping your global state in a distributed data storage system is the right thing to do generally, not just with Lambda. Might not work for HPC but it generally doesn't need to be reliable in the same way applications do.

At least in section 3.2 they finally seem to understand that most of the limitations are a good thing and if you are building software that don't have them you are likely not building scalable, reliable software systems. Also, if they think that their section 4 is somehow non-obvious to AWS and others they really aren't paying attention.

</comment><comment><USER30> Having your functions be stateless is actually an asset and forces you to write your code in a way that doesn't make assumptions about the state of some cache, which makes it inherently more reliable.

Cold starts aren't much of a problem if you have non-interactive workloads, or can design UI's in such a way to let the user know the first interaction will be slow but the rest fast, and if your modality allows for such. These problems tend to go away with any moderate scale in any event.

The time limits I've found to be an asset as well, and forces me to think about how to structure my task into discrete and well known units of work. This makes development harder but leads to an overall more reliable system where any one invocation failure won't seriously jeopardize the larger task and can easily be recovered. You can't say the same for a process that's been running for hours and suddenly dies without committing its work.

That said, I'd love to have serverless GPU functions. I'd love to be able to somehow run shaders over superresolution images. That would be amazing for me working in the mapping world.

</comment><comment><USER31> If a marketing term means exactly the opposite of what you think it means (that's some hefty server they've got there), then you probably should look elsewhere anyway. Unless you enjoy dealing with a community and support team that speaks an inverted lingo, of course.

<comment><USER32> Only programs that talk to servers can be serverless.

In two years we'll discover the benefits of running serverless workloads on the client and there will be a new name for that.

</comment></comment><comment><USER33> Some questions:

1\. The authors are quoting exact performance metrics and limits, which is making the article more about "Amazon Lambda" rather than "Serverless Computing".

2\. The authors mentioned a "15-minute lifetime" problem. Although it could be concerning that cache may be invalided sooner than running the same code on other infrastructures, a use case like this could easily migrated by using container. Not to say this number could be adjustable - this is a limit that is set by AWS rather than some theological limit. Thus using this problem to attack the serverless computing idea would be unfair.

3\. The authors mentioned low IO problem. As public cloud is a shard infrastructure, it is only reasonable for end users to assume a baseline IO performance when using the platform - and this applies to any service that any public cloud provides, currently and in the future. It would be more beneficial if AWS could reveal the baseline performance in number, as this would assist developers with planning.

4\. The author attacked serverless computing about its "Communication Through Slow Storage". This is probably not avoidable and is common practise in modern developing and should not be used to attack the idea of serverless computing. AWS do provide u-12tb1.metal EC2 server that comes with 12TB of RAM for this use case, though.

5\. The author mentioned that currently serverless has "No Specialized Hardware". Again, this is a attack on AWS Lambda rather than serverless computing, and is a particular function that could be easily added. (I have a feeling that Cloud TPU could be used with Google Cloud Function, but it's a assumption.)

6\. The authors also attacked that "FaaS discourages Open Source service innovation." Supposedly one can only imagine that more software projects would be PORTED TO serverless, and there should be no real issue running them as standalone application. I lost track of what the authors are trying to argue.

</comment><comment><USER34> I actually agree with many of the suggestions in the paper, but of course am biased as these are my colleagues and we disagree on some of the interesting capabilities of modern serverless architectures (see [https://arxiv.org/abs/1810.09679](https://arxiv.org/abs/1810.09679) ) . But it comes across like this DeWitt/Stonebraker piece from back in the day, "MapReduce: a major step backwards" [https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_...](https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html)

</comment><comment><USER35> If I were a Machiavellian dominant player trying to keep my advantage in distributed systems, I'd invest into serverless propaganda to mislead everyone performance/cost-wise, keep my dominant position and get people doing real performant distributed systems for cheap due to market hunting slow/costly fad.

<comment><USER36> How does someone grow up to be Machiavellian ? Bad childhood ? Extreme circumstances forcing them to always default in to a ruthless uncaring attitude?

</comment></comment><comment><USER37> Does anyone know why lambda is taking off, compared to heroku style PaaS?

Heroku style still removes the burden of managing servers ("serverless"), but doesn't lock you in as much. You could easily move your own server process to a different provider.

Is it just because Amazon doesn't offer anything similar to heroku?

<comment><USER38> A number of reasons. For one, you pay per execution with Lambda (and other similar services like Azure Functions and Cloudflare Workers)...and the costs can be dramatically lower. Here's a great article by haveibeenpwned author explaining how they support 141 million requests a month at 2.6 cents per day: [https://www.troyhunt.com/serverless-to-the-max-doing-big- thi...](https://www.troyhunt.com/serverless-to-the-max-doing-big-things-for- small-dollars-with-cloudflare-workers-and-azure-functions/)

Besides cost, automatic scaling is something traditional PaaS does not offer.

</comment></comment><comment><USER39> I honestly don't understand why this hasn't been PHP's niche for years. It's exactly what the language has been doing for years. That's why PHP hosting is so cheap.

</comment><comment><USER40> I'm not sure I would call it two steps back.

I think it's quite obvious that every web application everywhere doesn't need a full OS install chugging along all day everyday waiting for things like mouse input or having its own patches for services that will never be used.

It's first gen tech. Really curious to see where it goes.

<comment><USER41> I mean, where do we think the functions are executing now? It's not like Ubuntu Server is running Xorg, or has libinput installed, nor have any of those things ever been operational or developmental considerations on any "non-serverless" app.

Or maybe you're in a super cutting edge functions deployment where you're actually deploying microkernels? Seems orthogonal to me, and doesn't seem to address the data locality, etc issues brought up in this article.

There are so many people in this thread saying stuff like "PaaS doesn't allow auto-scaling" and I just don't really know what's going on. It's baffling to me. I guess if all you know is an archaic build process and manual deployment, then it looks great. But I'm willing to bet most of these function platforms bottom out on containers-on-k8s-on-vms anyway.

I am increasingly, increasingly convinced that people don't really need or want "serverless". They want the final step in the build/development process that they thought they were going to get with Docker -- they want to write code and have it running somewhere. I really don't buy that Serverless/Lockin are the right or best way to that future.

<comment><USER40> >They want the final step in the build/development process that they thought they were going to get with Docker

This isn't my area, so I don't know - but why didn't people get that with Docker?

<comment><USER28> They didn't get the magic functionality they wanted because magic isn't real. Coming from a devops background with more of an emphasis on "ops" than "dev", my (admittedly biased) opinion is that a lot of developers believe three things simultaneously:

1) Ops people are bitter, power-tripping killjoys who couldn't make it as developers and do nothing but click buttons and think up ways to make the lives of developers difficult.

2) Ops/infra really isn't as difficult as ops people would have you believe, and some day very soon all the ops people will be replaced by code.

3) Someone else should write the code that's going to automate the ops people out of existence.

These developers are like highly specialized scientists who think that their PhDs make them experts on everything. They have no idea what happens to their code once they commit it and they don't care to learn, but they're pretty sure that it can't be all that complicated.

Ops will—like everything else—eventually be eaten by software, but the people who drive that transformation sure as fuck won't be JavaScript specialists who can't troubleshoot their inability to connect to the VPN. They'll either be systems/infra people who can code, or well-rounded coders who understand that infra is actually nontrivial (or a group comprised of both).

If it seems like I have a problem with devs, it's honestly only because a vocal minority of devs have a big problem with me.

</comment></comment></comment></comment><comment><USER42> I love how everyone always shat on PHP (the original serverless technology...convince me otherwise) and now everyone is scrambling to reinvent PHP.

<comment><USER43> Does PHP automatically scale infrastructure to meet demand? Can you bring up 1000 instances of your service for spikes in volume? And then scale back down when the spike is over? Without writing code?

Nobody is reinventing PHP.

<comment><USER44> Totally stateless PHP apps (retrieving and storing state at the top and bottom of each request) plus autoscaling based on CPU load starts to look pretty close to Lambdas + scheduled tasks to keep them "warm". This is how most LAMP apps are/were built, notably Wordpress.

The real pain point in any auto-scaling/cloud/serverless application is and will probably always be the stateful bits. I think the first cloud provider to really figure out this killer bit will be the ultimate winner of the cloud wars. It will probably look something like Amazon's "Aurora Serverless" but be even more frictionless.

</comment></comment></comment><comment><USER45> Here's a web version if you're on a phone: [https://www.arxiv- vanity.com/papers/1812.03651/](https://www.arxiv- vanity.com/papers/1812.03651/)

</comment><comment><USER46> TL;DR

3 WHY SERVERLESS TODAY IS TOO LESS

(1) Limited Lifetimes. After 15 minutes, function invocations are shut down by the Lambda infrastructure. Lambda may keep the function's state cached in the hosting VM to support "warm start", but there is no way to ensure that subsequent invocations are run on the same VM. Hence functions must be written assuming that state will not be recoverable across invocations.

(2) I/O Bottlenecks. Lambdas connect to cloud services—notably, shared storage—across a network interface. In practice, this typically means moving data across nodes or racks. With FaaS, things appear even worse than the network topology would suggest. Recent studies show that a single Lambda function can achieve on average 538Mbps network bandwidth; numbers from Google and Azure were in the same ballpark [26]. This is an order of magnitude slower than a single modern SSD. Worse, AWS appears to attempt to pack Lambda functions from the same user together on a single VM, so the limited bandwidth is shared by multiple functions. The result is that as compute power scales up, per-function bandwidth shrinks proportionately. With 20 Lambda functions, average network bandwidth was 28.7Mbps—2.5 orders of magnitude slower than a single SSD [26].

(3) Communication Through Slow Storage. While Lambda functions can initiate outbound network connections, they themselves are not directly network- addressable [...] can only communicate through an autoscaling intermediary service; today, this means a storage system like S3 [...]

(4) No Specialized Hardware. FaaS offerings today only allow users to provision a timeslice of a CPU hyperthread and some amount of RAM [...] no API or mechanism to access specialized hardware. However, [...], hardware specialization will only accelerate in the coming years.

<comment><USER46> While each of the above points are mostly quite factual, I don't personally find any of them to be restricting. We run a mixture of stateless and stateful services and serverless is suitable for the stateless ones.

The original problems for network security being solved by running functions in a VPC and secure connections to databases and even connection pools makes pretty much everything work.

<comment><USER47> Running functions in a VPC cause them to have cold starts of ~5 seconds. Connection pools need to be centralized to be of any use, since lambdas scale automatically.

<comment><USER48> I found myself in the middle of migrating a startup's entire "something" ingestion pipeline to be entirely done on Lambdas. For our purposes of one data block per every 10-20 minutes, and then processing and ingesting that data, Lambdas work perfectly, and about 10x cheaper than using ECS or EC2.

</comment></comment></comment></comment><comment><USER49> I really wish that one of the big cloud providers was building out actors as a service. That would address a lot of the shortcomings of FaaS, whilst still having many of the important benefits.

</comment><comment><USER50> One way to get around vendor lock-in if you're worried about it, is to use a shim that translates the proprietary code to a basic http interface. So you just write your code as it it were a basic interface. There are tools like apex up, [https://github.com/apex/up](https://github.com/apex/up) which do this already, though at the moment only support aws, but could eventually be setup to push to any provider.

<comment><USER51> Another alternative is ZEIT Now 2.0 which is supposed to be cloud-agnostic serverless. It puts a few more layers of abstractions between the developer and the cloud providers.

[https://zeit.co/blog/now-2](https://zeit.co/blog/now-2)

<comment><USER52> People will argue that there is vendor locking with Now 2.0 - it has its own config file and way of doing this.

But i am running express and the config is tiny, just few lines. If you use some cloud db provider for db that you can host yourself (like postgres or mongo in my case). You can move to your infrastructure without any pain.

Mind you using Express is not the "ideal" way Zeit seems to push. It is exactly like with PHP - you are supposed to use simple files and leave routing to webserver. I think they forget that there is no PHP framework that uses this. All of them use the "Front controller" pattern and webserver basically routes everything to it. There must be reason for this.

</comment></comment></comment><comment><USER53> Came to conclusions really close to these when I investigated FaaS/Lambda a couple moths ago. Here's the blog post (faster read): [https://archbee.io/blog/why-serverless-is-not-there- yet/](https://archbee.io/blog/why-serverless-is-not-there-yet/)

<comment><USER54> We have found the same when working on our own projects. Within the last few months a friend and I have been working on our own FaaS: [https://3clouds.io/](https://3clouds.io/) We believe it solves about 90% of those issues - it's currently under heavy development and not ready to be used in production yet, but we think we are on to something here. Check it out, let us know what you think.

<comment><USER53> Interesting that you have the Docker option. I wish big cloud providers would be able to allow us to provide a Docker image to run as serverless. And not be as expensive as AWS Fargate..

</comment></comment></comment><comment><USER55> If you want to avoid vendor lock in, may I recommend open source FN Project - you can run anywhere as it's container native serverless platform. [https://fnproject.io](https://fnproject.io) (Full Disclosure : My company supports development of this project).

</comment><comment><USER56> If you can write a paper like this, however right or wrong, that's the standard for Berkeley Computer Science often cited as one of the best programs out there?

It's nothing bad per se it just seems closer to nice blog post than research.

<comment><USER57> It's basically an opinion piece - CIDR is an unusual conference and encourages this:

[http://cidrdb.org/cidr2019/](http://cidrdb.org/cidr2019/)

<comment><USER56> Maybe the perception has less to do with the paper or Berkeley that than a possible bias against Software Engineering research.

I've always perceived it, maybe unfairly, as one of the least rigorous topics in Computer Science, and more removed from more foundational insights that can have eventually have more important, broader impact or increase fundamental understanding that enables advances in other areas.

If any of the conjecture is true, it wouldn't be a criticism of any researcher in this area or their capabilities.

Maybe it's just a matter of maturity. How rigorous can I expect theory to be when th top software companies in the word still have trouble estiming delivery and complexity of software implementations?

We may just not know enough yet.

</comment></comment></comment><comment><USER58> One thing that stops me seriously thinking about serverless is : what would my application's test suite look like if the application made heavy use of AWS lambda?

<comment><USER20> It should look just like it does now:

Production:

Lambda handler -> business logic

Test

Test function -> business logic.

Testing a lambda function is no different than testing an controller in an MVC framework.

</comment></comment><comment><USER59> "Cloud" = back to dumb terminals & mainframes. Giant step back.

Edit: and pulling content from two dozen separate servers ... madness^2

<comment><USER28> Yeah, simpler to just serve all content from the file server sitting in your garage. After all, you tested your site from the laptop on your kitchen table, and everything loaded just fine.

</comment></comment><comment><USER60> Why does serverless remind me of PHP?

<comment><USER61> Maybe because a making a "lambda" is quite like putting some code in a .php file and uploading it to a LAMP server, except it's pay-as-you-go and it autoscales.

</comment></comment><comment><USER62> One size never fits all. The end.

<comment><USER28> Not exactly. The authors are part of the (large) camp that envisions serverless eventually becoming ubiquitous. In that sense, they hope that one size _will_ fit all, some day.

<comment><USER17> > In that sense, they hope that one size will fit all, some day.

Nothing new under the sun there. And, that being the case, they're likely to be disappointed.

</comment></comment></comment><comment><USER63> I built an Adtech platform on Lambda recently:

It's processing 9 billion events per week.

1\. We used Firehose which pushed the data to s3

2\. Go binary on Lambda transformed the data into Parquet format

3\. Used Athena to query this data

4\. Using Lambda to adjust the machine learing data based on the ariving data in batches.

5\. Using Lambda to query athene/bigquery for data dashboard queries. Again using Go binary for max performance.

All this made our platform 10x cheaper.

<comment><USER64> Yep, there are workloads that benefit from the FaaS model, but not all.

In my case, the cost / hassle of high-availability, scaling, no need for state, time-based triggers, and more, made Lambda an easy decision to make: and it's working quite well. A cron-triggered job every minute is still in the "free" tier, so even better!

</comment></comment><comment><USER65> Interesting article. It has often seemed to me that efforts such as Urbit (urbit.org) deserve our attention, precisely because they might _actually_ deliver on the 'serverless' premise to a far greater extent than current solutions.

<comment><USER66> Really? Isn't urbit based on a computation model multiple orders of magnitude less efficient than KVM?

</comment></comment><comment><USER67> Oh look a bunch of academics telling developers how to do their job, again.

</comment><comment><USER68> Translation for those not proficient in Academese: Serverless computing a novel paradigm enabled by a large cloud provider, does not matches our past research, thus we argue why it's not the right thing.

This is classic "if theory does not matches practice lets change the practice" approach, which is far too common in academic systems research.

I trust AWS with knowing what its customers truly want (in terms of performance and cost) and what it can provide,Since AWS has real financial stakes in its success.

A decade ago the same researchers would have mourned emergence of cloud computing as a wrong thing and instead asked for P2P computing since that's what they had spent the decade before doing research on.

<comment><USER69> I'm afraid your "translation" does a disservice to all the potential readers of the paper, to those who want to decide whether to use serverless computing at present and to the authors.

Quoting from the conclusion of the paper:

"Taken together, these challenges seem both interesting and surmountable. The FaaS platforms from cloud providers are not fully open source, but the systems issues delineated above can be explored in new systems by third parties using cloud features like container orchestration. The program analysis and scheduling issues are likely to open up significant opportunities for more formal research, especially for data-centric programs. Finally, language design issues remain a fascinating challenge, bridging program analysis power to programmer productivity and design tastes. In sum, we are optimistic that research can open the cloud's full potential to programmers. Whether we call the new results "serverless computing" or something else, the future is fluid."</comment></comment>


Arnold Schwarzenegger's Amazing Motivational Story - <AUTHOR> https://www.youtube.com/watch?v=wJPRj19OU-w

<comment><USER2> Mr. Schwarzenegger is a clever and laser focused guy, that´s for sure, but this story is a complete rationalization of past memories.

"Seven sins of memory" by Daniel L. Schacter is a great book to read if you are interested in this area of knowledge.</comment>


Facebook Is a Normal Sleazy Company Now - <AUTHOR> https://slate.com/technology/2018/11/facebook-is-a-normal-sleazy-company-now.html <comment><USER2> What happened before FB were forums and forums had the same problems that FB had but forums had humans that ran them and usually volunteer moderators that enforced rules over the content. Nothing on forums passed scrutiny. Forums had flamewars and other issues but in the end they ended up causing a lot fewer problems than FB. We need to go back to forums and ditch FB. The social network version of forums is massive, unwieldy and unenforceable. I mean even Reddit is better in terms of enforcing rules than FB is.

<comment><USER3> I agree the problems are mostly the same but Facebook also has an Eternal September problem of introducing gullible baby boomers to this stuff at a larger scale than we've ever seen before.

<comment><USER4> There are so many more problems with Facebook than with Forums. There will always be another Cambridge Analytica. Facebook will always be caught selling data in ways that people do not approve. The entire business model of Facebook is to sell information about the account holders.

</comment></comment></comment><comment><USER4> The headline matches the original article, but to be truly correct it should read, "Facebook Has Been a Sleazy Company since Day One."

</comment><comment><USER5> What's a real indicator for me is that this week two tech-job applicants they had deleted their FB - and dropped other social as well!

Have we crested peak-social?

<comment><USER6> Maybe I misunderstand what you're saying, but people looking for jobs often temporarily change their names or disable social media accounts when looking for professional jobs. Dozens of my good friends did this out of college and told employers they didn't use social media because they didn't want them seeing it.

</comment></comment><comment><USER7> What a new revelation :)</comment>


Banking Startups Adopt New Tools for Lending - <AUTHOR> http://www.nytimes.com/2015/01/19/technology/banking-start-ups-adopt-new-tools-for-lending.html?ref=business <comment><USER2> The media narrative of these startups is somewhat misleading. It sounds neat to suggest that you can approve loans based on an amalgamation of seemingly random data points, like proper capitalization, but the reality is that even most of the alternative online lenders are using credit scores.

From Affirm's website:

> Affirm does a credit check to verify your identity and provide you with a > financing offer when you sign up. This is a 'soft' credit check and will not > impact your credit score. If you choose to complete a purchase and finance > it with Affirm, we will do a single 'hard' credit check when your first > order is processed by the merchant. This may have a minor impact on your > credit score. For future purchases with Affirm we won't need to check your > credit again.

</comment><comment><USER3>
        "It is important to maintain the discipline of not trying to explain too much," said Max Levchin, chief executive of Affirm. Adding human assumptions, he noted, could introduce bias into the data analysis.

This might be true, but I've heard this mentality before, and I feel like it draws this incorrect picture of completely fair robots scanning the universe of variables. Ultimately it's a [probably-white-upper-middle-class] human who intuits which variables are worth further study.

[probably-white-upper-middle-class]: pick your favorite adjectives to describe startup machine learning engineers.

</comment><comment><USER4> Kind of weird to have an article about alternative lending and big data, and not mention Lending Club? The are the biggest player in the space by far and IPOed only last month...

<comment><USER5> Looks like the focus of the article is on alternative techniques to determine creditworthiness. Lending Club, as I understand, relies mostly on traditional credit scores, which does not make them particularly innovative for _this particular aspect_ of lending.

</comment></comment><comment><USER6> By being online/mobile, aren't these companies already cutting out large swaths of the people they ostensibly aim to assist?

Also, another ex-PayPal entrant: Vouch.</comment>


FAQ – Virtualization - <AUTHOR> http://www.openbsd.org/faq/faq16.html <comment><USER2> Just started using OpenBSD as my main desktop OS and virtualization was the one thing I was uncertain about (wanted to see if I can setup test machines so that I don't clutter my base system, and it looks like they've added Linux support), but excited to grok how it works. I'm super happy about how solid the system is so far.

<comment><USER3> It appears to be missing guest SMP support. How is that not a deal breaker?

<comment><USER4> It doesn't have video support either. I think the needed components are available and other features are presently ancillary.

<comment><USER3> Ancillary if you're just doing dev work but rules out use as a VM host for a lot of software.

</comment></comment></comment></comment><comment><USER5> anyone have experience using bhyve[0] on any BSD flavors?

I am thinking about building a large FreeNAS deployment and virtualizing with bhyve... a few people I asked on IRC recommended against it due to its 'green- ness'

[0] [http://bhyve.org/](http://bhyve.org/)

<comment><USER6> I'd say that bhyve on FreeNAS is pretty stable. It is not THAT green anymore, it has been there for a few years.

It is also not as slick or feature rich as say any VMware product, but it does what it has to do. It runs VMs and I've seen the VMs survive a few power outages as well.

As always YMMV

</comment></comment><comment><USER7> Moderators: We should probably link directly to the FAQ: [http://www.openbsd.org/faq/faq16.html](http://www.openbsd.org/faq/faq16.html), the undeadly link is nothing other than a 1-paragraph reference linking to the same.

<comment><AUTHOR> Thanks. I considered linking directly to the FAQ, but chose the undeadly link instead simply because it highlighted the fact that the FAQ is a new addition, though the infrastructure has been there for a while now.</comment></comment>


Negative Ships and Unlimited Money Postmortem - <AUTHOR> http://www.war-worlds.com/blog/2014/07/negative-ships-and-unlimited-money-postmortem

<comment><USER2> I'd rather have No-Ships and Unlimited Spice.</comment>


Beware the Siren Song of Comments - <AUTHOR> http://www.leastastonished.com/blog/2014/08/27/beware-the-siren-song-of-comments/ <comment><USER2> _" Comments decay. They aren't compiled, and they'll never get executed at runtime. If they become out of date or incorrect, no test is going to fail and no user is going to complain. Programmers work around them out of fear that "somebody might need this comment or it might provide some value in the future", pushing them along far after they're useful"_

The developers who say this are ticking time bombs of laziness on your team.

Comments only "decay" if you don't _read_ them, or if you don't take the 30 seconds to update them when you make a change. And if you're not doing that, then _you 're not doing your job_, because the previous developer left the comment for a reason, and your defeatist philosophy of "comments are useless" is implicitly overriding that developer's judgment. Respect your colleagues enough to at least read what they've written and update it when it's incorrect!

It's pretty disheartening to hear this from a "director of engineering", actually. I expect it from a new grad who has never worked on a team, or with code that has to live for more than a quarterly project, but I want a team leader to be doing _everything possible_ to improve communication amongst team members. That includes compelling them to write and maintain good comments.

<comment><USER3> > Comments only "decay" if you don't read them, or if you don't take the 30 > seconds to update them when you make a change

Comment decay is a rehash of "code that isn't written is never incorrect". Aka every change you make introduces an opportunity to make a mistake, including both writing and updating comments.

</comment></comment><comment><USER4> I've found quite the opposite. Most developers hate comments because they represent extra work. That work manifests itself in the creation and upkeep of the code. We've found that addressing comments as part of our code review process made a big difference in keeping things up to date.

Regarding the issue of expressiveness: I never find myself commenting about what is obvious in the code itself. Often I'm writing about some thinking behind why something was done a certain way OR identifying expectations of downstream systems that can't be expressed using code. Code enough in environments where you're interacting with multiple disparate systems and you'll find that some well placed comment providing the broader context for the code is extremely helpful to folks encountering the code the 1st time or to yourself a year later when you're incorporating a new feature and have forgotten about all the concerns wrapped up in the code.

With the todo issue- we require folks to include a JIRA issue number along with the todo. If something was left undone then it needs to be recognized where we manage our backlog and flagged as a technical debt to be addressed.

<comment><USER5> +1. Commenting code _or config files_ with an issue number and a date turns out to be a lifesaver. Your future self will thank his past self (instead of cursing him as usual).

(I am a sysadmin, not a dev, but pretty much everything Operations writes counts as code for these purposes.)

</comment></comment><comment><USER6> > The right place to document [performance] hacks is a commit message.

This advice strikes me as patently insane.

Serious performance hacks often involve subtle interactions among different parts of the code. When that happens, properly documenting them requires explaining what's going on in a line of code, for every line of code, right next to that line of code. Just sticking a wall of text somewhere else entirely and leaving it up to your successor to go find it and figure out how the explanation cross-references with the code is _not_ an adequate alternative.

<comment><USER7> Likely to be using a workflow that uses `git blame` or equivalent to understand the context of code. The problem that is intended to fix is that comments don't stay in sync with the code they're commenting about. The problem it introduces is discoverability. You have to search to see where this code came from in order to understand it. That isn't going to happen unless you're disciplined. And we're all undisciplined at some point or the other.

<comment><USER8> I only find blame-type tools useful for discovering either recent context, or context of rarely-touched code. They typically only _easily_ show you the most recent change to a line of code, though you can sometimes dig through older changes in a kind of per-line commit history. So older changes get more and more buried under an accretion of more recent ones. To find the commit message discussing a performance hack from 8 years ago, you'd have to wade through all the more recent commits that also touched those lines of code (refactoring, fixing unrelated bugs, fixing library bitrot, etc.). I'd rather that important context stay right there in the code, not get buried among hundreds or thousands of other commits.

</comment></comment></comment><comment><USER9> Comments which reveal the _intent_ of a block of code are very useful. They provide useful clues precisely when the code does not meet the expressed intent:

        /* Dear Maintainer,
         * I write the following in the sincere hope that
         * it sorts the variables a, b and c in ascending order.
         */

        if (a > b) swap(a, b);
        if (b > c) swap(b, c);

They are useful when the code is complicated and the intent is not obvious. Or when there can be multiple plausible intents based on what the requirements are. Sometimes code contains implementations of requirements that are not spelled out in any requirements document. A high level requirement can break down into lower-level ones in umpteen ways. Whatever isn't in the detailed design document is only in the comments and the code. A programmer's statement of intent can in fact be a requirement specification: the only such document for that piece of code.

</comment><comment><USER10> This approach works well in only one situation: when your code isn't doing anything substantial in terms of data processing.

For me, comments are best used at explaining _why this is happening_, not what is happening.

By far one of the best examples of code commenting I've seen is the explanation of the L2ARC (the level 2 adaptive cache) in ZFS: [http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/ut...](http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c#L4245) . Most of the ZFS codebase is extremely well documented due to its comments, and it helps a lot having the documentation _in the code_, to provide context (something that commit logs, by default, don't).

<comment><USER5> The hard part IME is keeping your audience in mind.

Your future self? Your coworker who might be hired next month? Your past self who would have wished to read said comment?

Who is the audience for the comment?

</comment></comment><comment><USER11> Am I the only one that doesn't find looking up commit messages as a followup to `git blame` as convenient as a code comment?

When I see something like,

      42   def wobble(self):
      43       # Make sure the vent core has been frog-blasted,
      44       # so that we know {rare bad things} won't happen
      45       frog_blast(self.vent_core)
      46       self.do_important_things()

I find that a much faster answer to "Do I really need to foo the bar?" than if I have to decode it:

      42   def wobble(self):
      43       frog_blast(self.vent_core)  # see commit msg
      44       self.do_important_things()

      git blame wobble.py
      git log abcd4242

      Author: Bob

        Ensure that vent core is properly blasted

        We rarely have frogs, but the vent core must be cleared.

Is this a matter of insufficient knowledge of my IDE? (I'd love to be able to easily show the last commit messages for specific lines in a tooltip or other popup.) Having to context-switch into commit-sleuth mode seems (to me) to be more disruptive than having the code comment.

<comment><USER11>
      Is this a matter of insufficient knowledge of my IDE?

After writing this, I realized that it a symptom of exactly that: I'm not fully savvy with PyCharm/IntelliJ, my Python IDE of choice. I'll run down the ways I know of to access blame history (in case others don't know it exists).

1) Git -> Annotate: This is almost exactly what I wanted!

This gives a `git blame`-like column next to each code line, and clicking an item will show a summary of the commit, including both the commit message and fields modified. I can right click one of the annotations and select "show diff", and can even see the modifications to any of the files in the commit if necessary.

Unfortunately, this depends on a commit message explaining why that change mattered, AND on it being the most recent changes to those lines. Moreover, it doesn't show the full history of changes for those lines, such as if Alice added the real change, and Bob just did some whitespace changes.

I can find such information (with effort) using `gitk` or other git log browsing tools. If the most recent change (shown with git-blame) doesn't have what I need, I basically need to look at all of the changes for this file, going back from that commit, and see if I can find the one with a message that explains why ${hackity-hack} is necessary.

2) Right click a file tab or in the editor, and select Git -> Show History

This is a faster way of browsing the commit messages, but doesn't give enough information for me to tell whether that change was the one that affected the lines I care about. If it showed the diff of what the commit changed in my file, it would be more informative. (This is what gitk shows, for example.)

As far as I can tell, neither of these options is as comprehensively informative as using `gitk myfile` and backtracking from the commit that `git- blame` (or PyCharm's Git->Annotate feature) lists as the most recent change to those lines.

If comments don't describe what Is Happening or What Should Happen, they should be changed. This is much harder than maintaining unit test coverage, but I think the information is still very valuable to have in code comments rather than solely in commit messages. (It is certainly valuable to have them in commit messages as well, of course, as that documents how you felt at the time.)

</comment></comment><comment><USER12> > Let's say you want to resurrect this reslug_all_tag_pages method. Just use: > $ git log -Sreslug_all_tag_pages

You "only" need to remember that the method is named reslug_all_tag_pages.

</comment><comment><USER13> With respect to TODOs and FIXMEs in the comments, I use them to mark places I know I will need to go back. Before calling a piece of code done, I grep for TODO and FIXME to make sure I haven't left anything unfinished.

<comment><USER11> I agree. I use TODO indicators as a code smell for things I forgot to add before making my pull requests, but I also see them as valuable reminders for future needs.

Sometimes there's a quick-but-less-generalized way of solving something, and you know there's a more elegant way of doing it, but for now you need to get something working/fixed and don't want to make sweeping changes.

Your immediate change might be to add a way for users to see that X is finished. A useful TODO message would be something which explains what you're doing

      # Tell users when their Solve-My-Foo is done
      # (Currently done in an ad-hoc way)
      # TODO: Add a notification infrastructure so that
      #    arbitrary components of the apps can present
      #    notifications of Important Things
      #    e.g.:
      #    - celery job is done
      #    - a thing you've subscribed to has changed
      #    - a report/download/etc is ready to be retrieved

Building such a system might be overkill right now, if this part of your system is the only one that uses it, but a TODO message helps me see (the next time I make changes to it, or try to extend it, or use it as a template for reimplementation elsewhere) that there's more than one place we need this feature, and so it might make sense to plan/do those more comprehensive changes.

</comment></comment><comment><USER14> It would have been helpful if the author explained how this has benefited him in concrete ways, rather than asserting that his way is best and leaving it at that.

<comment><USER15> Indeed. "I hate reading articles that make abstract arguments, so enough bloviating" Author then proceeded to do exactly that.

The single item I agreed with was the blocked out old code that will never be used again - source control handles that.

Otherwise, what a load of nonsense.

</comment></comment><comment><USER16> I agree that patently obvious comments are not necessary... and descriptive naming helps avoid patently obvious documentation... But I disagree with adding more code to replace what would be a single line of documentation. To me that's insanity.

My teams find more and more value from documentation as they are forced to return to code months/years later.

And commit logs as the place to document performance issues? Seems like an easy way to make sure that a "weird" bit of code gets removed, and breaking your app.

As with all things, ideologies and blanket statements suck. I think what was talked about in this article could've been much better communicated if it wasn't so polarizing.

I've found comments are only not added or updated when people feel rushed. Or a culture which doesn't put value in them... Which is a problem with one's organization not the act of writing comments.

P.s. This is an edit: isn't it rather peculiar someone tasked with annotating all text doesn't annotate their code? Irony?

</comment><comment><USER17> I really dislike his notion of using the commit logs as the correct place to explain your code. First, it means that any time I need to find out why something is being done in code I need to leave the code and switch from my IDE to my source control. Second, most tools like blame will only show the most recent change. Minor fixes and changes happen all the time. What are the odds that the explanation I want will come up instead of something like "Fixed a typo". Third, what about code from other branches and external code drops?I may be using code from somewhere else and not have access to the full history of changes, just stable versions. Fourth, what happens when you change source control? If all of the comments are in the Git commit logs that'll be a big problem if the company switches to Perforce.

Instead of just making meaningful commit logs part of the code review process why not make "reading the comments" part of the code review process?

</comment><comment><USER18> As someone who is currently debugging a codebase that was written 5+ years ago by persons long gone, please, comment wherever you think it would be appropriate, and then some more. There are only a few things more hellish than being able to read the code and know what it does, while not being able to understand why something was coded a certain way.

</comment><comment><USER19> 1st Point: use self documenting code instead of commenting | Ok fine

2nd Point: Explain performance hacks in commit description | might was well not explain them at all. This is a great place to hide the reason for the performance hack

3rd point: Don't use TODO / FIXME | I'm on the fence.

4th Point: Don't comment out old code use version control for old stuff | Ok

<comment><USER20> TODOs are presented in task lists, etc, by many IDEs. For me, they're included in my workflow, not forgotten.

</comment></comment><comment><USER21> Thanks Andrew.

I think you missed a key point, or maybe I overlooked it while scanning.

Because modern programming languages allow very long variable and method names, you should be able to construct a "grammar" in your code. That is, the code itself should be able to be read -- and when you read it, it tells you what it does.

So "if CustomerHasALargeAccount then WriteThemASalesLetter()" not only is a piece of code, it's also directly explaining what's going on. As long as you make sure your names are long and explicit enough, your comments and code become one. (Except for some oddball cases)

I like comments while I'm constructing my thoughts. Once I've coded it, I delete the comments. I can also see using comments as sort of a mnemonic for future work.

A lot of good points here. Keep up the blogging!

</comment><comment><USER22> Nice article, but one passage gave me the willies:

> If you're writing a public API for a library that's getting exported to the > world, or to a bunch of developers at your company, it may be easiest to > maintain the documentation for that API in code comments.

An important idea that I always try to keep in mind when coding is that the _me_ of a few months from now might as well be a different person. All those things I understand so well today, will be no more obvious to me next year than they will for some other person.

So I think that if I follow a methodology that makes a distinction between code for me and code for others, then I'm Doing It Wrong.

</comment><comment><USER23> I can't see why he thinks his second example is any more readable than his first. The commented version explains what will happen. The second version requires at least some knowledge of the context.

There are plenty of times when I have been given bits of other peoples code and told to make them work. All I have is an error message. Usually very little context about what the program is doing or why. In these cases, comments make a world of difference.

Even in my own code, looking back on it after 6 months. Sure, I can read the code and understand it, but it will take me 5 times longer than if there is a helpful comment near each step.

</comment><comment><USER24> I do agree about the clutter of auto-generated comments.

And to some extent some comments do decay. However, with experience, we learn to write comments with a minimal decay profile. As an example, avoid including constants in comments. Also, if you find yourself writing the same text over and over again, it's a sign you're being too redundant and can elevate that comment to a high level.</comment>


Is Prison Necessary? - <AUTHOR> https://www.nytimes.com/2019/04/17/magazine/prison-abolition-ruth-wilson-gilmore.html <comment><USER2> Dutch prisons are currently leasing space to Belgium because of low occupancy rates. This low occupancy is the result of various policies to cut costs. Prisons are not cheap so cutting sentences a bit and using alternative punishments for lighter offenses helps keep cost down. People still get caught doing stuff they are not supposed to. Locking them up is one of the punishments and it's used if needed. But it is used in moderation. Occasionally this is unpopular when high profile criminals end up back on the streets a bit sooner than people would like. Particularly when it involves e.g. sex offenders. But mostly this works out fine. This has not resulted in a massive crime wave and most people in prison are neither sex offenders nor psychopathic murderers.

The US is a great example of how prisons don't help prevent crime. It has the largest prison population per capita in the world and crime and murder rates to sustain that (i.e. notably much higher than other countries and also much more violent). Locking up people in the US apparently does not seem to lower crime rates. If anything, prisons actually help perpetuate this problem. The people who come out of them are likely to end up coming back. That's why it is important to keep young offenders out of prisons. Locking them up all but guarantees they come back for more. Locking them up for really minor offenses is simply counter productive and just locks them into a life of crime.

Part of the problem in the US is of course that prisons are big business. Big as in trading on Wall Street. E.g. CoreCivic is worth about 2.5B $: [https://finance.yahoo.com/quote/CXW/](https://finance.yahoo.com/quote/CXW/)

I used to regard movies from the eighties like Robocop as pure satire but you have to admit that this company, it's name, and it's sameless corporatism and hollow marketing makes it look like OCP quite a bit. Straight from their website: "CoreCivic's effective, high-quality reentry programs are at the center of our mission to reduce recidivism and help better the public good.". Yeah, right. Comes with a photo of a friendly smiling prisoner (black, naturally).

<comment><USER3> > Part of the problem in the US is of course that prisons are big business.

This is directly debunked in the article: "By now it has become almost conventional wisdom to think that private prisons are the 'real' problem with mass incarceration. But anyone seriously engaged with the subject knows that this is not the case. Even a cursory glance at numbers proves it: Ninety-two percent of people locked inside American prisons are held in publicly run, publicly funded facilities, and 99 percent of those in jail are in public jails."

<comment><USER2> We're still talking about well over a 120K individuals: [https://www.criminaljusticeprograms.com/articles/private- pri...](https://www.criminaljusticeprograms.com/articles/private-prisons-vs- public-prisons/)

For reference, I believe Germany has a prison population of about 75K (on a population of 80M).

Those publicly funded prisons provide plenty of cheap labor to corporations and they make use of contractors and suppliers. We're not talking about civil servants here. The bottom line is that there plenty of corporate interests in perpetuating the status quo.

This system indeed sucks up a lot of public funding as well. That's kind of the point: tax payers are funding this and corporations cream off the profits through contracting, prison labor, or indeed privately run prisons. Some of these are multi billion dollar companies even.

</comment></comment></comment><comment><USER4> A sad but true story:

I spent about 6 years in federal prison, and at my last prison location, I made a really good friend, Jeff. He could play guitar as good as Slash (he ran the prison music room), he was funny, and could run a D&D game like the best DM's out there. I knew him about 19 months before I release d to the halfway house. He was supposed to release about a year after me.

He had gone into the Army when he was 18. Because he could play the guitar, he got into a band unit, and they would march in parades and such. He molested his first victim for which he was caught while in the Army, and they gave him a hard 20 (20 years with no parole or probation). They also never ordered him into sex offender treatment. He spent most of his prison time in the military brig, but was eventually transferred into the Federal Prison system for being a troublemaker (brewing alcohol, getting drunk and fighting). That's how I met him.

I always wanted to be his friend after we got out of prison. I never expected him to re-offend, after knowing him pretty closely for a year and a half. When I asked my Supervision Officer if I could write to him while he was still in prison, I was ordered to not have any contact with any former prison acquaintances while on probation. I though, "Okay, I'll just wait until I finish my probation. No problem."

A few years after my release, I thought I would at least check up on him without contacting him. When I found out what he had done after he got out of prison, it was like I had been punched in the gut. I was in a state of numb disbelief for days.

Here are a couple of articles about Jeff:

[https://www.stltoday.com/news/local/crime-and- courts/police-...](https://www.stltoday.com/news/local/crime-and- courts/police-missing--year-old-girl-from-poplar-bluff- mo/article_7862c855-eb03-5833-b3fa-f5748dde0173.html)

[https://www.kfvs12.com/story/19996812/jeffrey-dean- shelton-f...](https://www.kfvs12.com/story/19996812/jeffrey-dean-shelton-faes- additional-kidnapping-charges/)

[https://www.courthousenews.com/child-molester- gets-120-years...](https://www.courthousenews.com/child-molester- gets-120-years/)

Prison is the best place for him.

<comment><USER5> If he would've been correctly re-integrated, this would've maybe never happened.

This proves it: all this prison time alone, without good programs in place, was just "vengeance" and it didn't work.

<comment><USER6> Homosexual conversion therapy does not work, but pedophilia conversion therapy magically works?

<comment><USER7> If we follow your analogy, that these 2 things are similar. Then we should also accept the premise that pedophiles are probably born that way.

Which would make identifying them, before they commit a crime, hugely beneficial. Treating it as a disease, might lower the stigma, and allow these people to self identify themselves.

<comment><USER8> There actually are programs like that. I've seen posters saying something like "Do you like children more than you like? Contact ..."

</comment></comment></comment></comment></comment><comment><USER9> The article largely mirrors how European countries deal with crime: low sentences and extensive re-integration programs.

The goal in Europe is integration and eliminating recidivism, whereas the goal in America is vengeance and isolation. You won't see any progress until that overarching goal changes.

<comment><USER10> IMO the biggest problem with American penal system is how crazy the punishments are for non-violent crimes. Get caught smoking crack a few times? You might be in prison for many years.

Another issue is how the government + private industry is allowed to punish you for life even though you've supposedly "done your time". Employers can and regularly do discriminate even for things that would have no affect on job performance. Oh also housing and loans. You're basically pushed to the fringes of society unless you manage to make it big with your own business.

Oh and if you commit a drug crime you're cut off from school financial aid for life. And if you have any felony the army probably won't even take you. Have fun trying to turn your life around when your own government slams the door.

I'm okay with long prison sentences for really nasty stuff like murder. Not such a big deal if an ex-con steals some shit again, pretty bad if he goes back to killing people.

</comment></comment><comment><USER11> The article doesn't propose any practical ways of reducing the number prisoners. Simply letting everyone out and hoping for the best doesn't seem to be a good plan.

One thing that could work for non-violent crimes, would be a bracelet that records all conversations and all movements of wearer, making recidivism very hard. Of course attempts to destroy the bracelet should be punished by real prison terms.

</comment><comment><USER12> Maybe it's just me but I couldn't find an actual argument. Unless it's that the murderer's life is just as valuable so it's bad to steal part of it from him by putting him in prison. I don't think anyone outside academia values the lives of murderers very much, is there another argument in there somewhere?

<comment><USER3> Because Gilmore isn't trying to make an argument about specific approaches. She's trying to change the narrative--the way to reduce violence in society is to address the root causes of violence, not react to it after the fact as if both violence and violent people are inevitable.

Does she actually believe that prison would never be necessary for anyone if we could enact the ideal set of societal changes? It's not clear to me that she actually believes that.[1] I'm particularly doubtful that she thinks we can just turn loose existing violent offenders. If you read between the lines what she seems to believe is that the abolition movement as she understands it is more a _process_ than a goal, and it's largely prospective. Note that she's quite critical of the motives of other reformists.

[1] In fact, I wouldn't be surprised if she thought both the question and the answer irrelevant. We see an elephant in the room and she's saying, "there is no elephant". That is, if you presuppose an elephant you're going to end up creating one.

<comment><USER13> > It's not clear to me that she actually believes that.

It's unfortunate that a long, in-depth, sympathetic article titled "Is Prison Necessary? Ruth Wilson Gilmore Might Change Your Mind" didn't make it clear to you whether Ruth Wilson Gilmore believes prison is necessary.

Personally I have taken prison abolitionists at their word, that they actually do want to abolish prisons. I have long been genuinely curious how they would handle serious crime in the complete absence of prisons. I expect this is the first thing most people would want to know about their program. It's surprising and disappointing that the article (and other articles I've read on this subject) fails to answer that question.

<comment><USER3> Does anybody believe that perfect equality (of wealth, of opportunity, of w'ever) is possible? Does that mean we as a society shouldn't bother establishing equality as goal?

In a large election a single vote doesn't matter. And yet if we permitted that fact to dissuade us from voting nobody would vote and democracy as we practice it would be impossible.

I haven't read Gilmore's writings, and I'm basing my interpretations off the article author's gloss--their selected quotations and elaborations--but applying the rule of lenity and in light of some of her very cogent points (that private prisons aren't a big problem, that the vast majority of prisoners are in fact violent offenders) it would seem that she's applying the same principles as Plato and MLK. Specifically, that society can only achieve and will only reap that which it orders itself around.

Whether irrepressibly violent people will always exist is beside the point. If we build a system directed toward the management of such people, then those are the people we're going to get, above and beyond whatever genetically predetermined base rate we might otherwise find in the population.

How does Gilmore translate her abolitionist position into specific policy prescriptions? I don't know. Maybe they're contentious; maybe I'd disagree with them altogether. But at least superficially I don't see abolitionism particularly inconsistent. I doubt you feel compelled to demand that a Get Out the Vote volunteer explain to you why voting matters, or demand that a "Why Voting Matters" article provide a concrete proof for why it matters. It's more intuitive that voting could only matter in so far as enough people have internalized the notion that it matters and act accordingly. Americans, I think, lack that intuition and suspension of disbelief when it comes to violence and crime. Some things are self-fulfilling prophecies--if we believe or don't believe, that's what we'll get. How societies manage to shift from one set of expectations to the polar opposite... that's still something of a mystery, but surely it involves being open to advocates like Gilmore.

<comment><USER12> I don't follow your argument, are you saying that if we just "reorient" our society away from violence by not using violence to punish criminals, they will stop committing crimes?

Yes I agree we should strive for a society were fewer crimes are committed, , but I don't see how that somehow implies that we should abolish prisons. We only imprison people who actually commit crimes.

Besides, prisons have many uses, apart from curing the criminal. The first is to stop blood feuds, if society does not punish crime then relatives of the victim will, and this leads to never ending spirals of violence. Crime victims generally are more concerned with justice than rehabilitation.

Another important reason is to keep criminals off the streets. No matter what happens once they get out, we can be sure that the streets are safe from them while they're in prison. And since most violent criminals are young men, if we put them away until their testosterone has calmed down about in their thirties, they should be much safer to have around.

Then there's of course the deterring effect of a potential prison sentence. I for one believe that if crime goes unpunished then we'd see more of it, not less.

I'm not saying that the american prison system isn't terrible, but that is no reason not to have prisons at all.

</comment></comment></comment></comment></comment><comment><USER14> Prisons might not help prevent crime but surely help prevent retaliations.

Victims that support keeping their offenders out of jail might exist but I'm not aware of such cases.

<comment><USER15> Here's a statement from someone robbed at gunpoint doing exactly that (arguing to keep the perpetrator out of prison): [https://twitter.com/stainerson/status/1125956097997774850](https://twitter.com/stainerson/status/1125956097997774850)</comment></comment>


Ask HN: As a founder how does your weekends look like? - <AUTHOR> <comment><USER2> Uhhhh, the usual, restless sleep, wake up at 7am, check email, check bank account balance, silent panic, cold sweats, yesterday's coffee, 2 days ago Pizza, a few dozen rejection emails from assorted VCs and angels, listen to cofounder latest complaints against team he hand picked and trained himself, checks site, checks google analytics, one transaction, a faint smile, a hope of a better future, an attack of naivete, and Monday is here again....

<comment><USER3> For something everyone is aiming at, sounds terrible. Do you at least _get the girl_ or something in the end?

</comment></comment><comment><USER4> What are these weekends of which you speak? :)

Just kidding, I'm in an 18 year old company so my weekends are pretty sweet. Driving tractors and stuff.

But when we started, and even now, it is rare that more than 6 hours go by and we haven't checked email. We are weird, we do pretty great support so people check emails on weekends to see if there is a big problem. If there isn't, off we go to some fun. If there is, rally the troops and get it fixed.

We're in the enterprise software space so it's sort of expected that we have some coverage on weekends.

All that said, if we do our job right, weekends are pretty boring. Which is why we peer review everything and regression test everything. Even with that some stuff slips through but not very often. We did a .0 release 6 weeks ago, found one bug, about to push a .0.1 release out the door. Boring. Which is how I like it.

<comment><USER5> My situation is similar. 18-year old company. At weekends I check email occasionally, but don't reply until Monday unless it's an urgent issue (which it generally isn't).

There generally should never any need to do any work on weekends unless it's an unusual situation. You're just reducing your overall productivity if you work too much. Having said that, sometimes I do work on problems over the weekend just for the fun of it.

<comment><AUTHOR> Emails are very tempting. I am on the same boat but, I have been working with a remote team and usually happen to work a lot during weekends because of timezone issues. Working with 5 year old company (remote), bootstraped and I recently moved to Bay Area. Was wondering how it goes with other founders here. Thanks for writing.

<comment><USER5> For me it is mostly support, so it tends to be questions like "how do I do this thing that is explained in the FAQ that I didn't read"?

If it was questions from colleagues then I might reply, although it would probably depend on the situation, and I certainly wouldn't want there to be an expectation that I would reply quickly to any and all emails. (I don't have any colleagues, so it's not an issue for me :)

</comment></comment></comment></comment><comment><USER6> I'm flying up to Silicon Valley tomorrow (from LA) to host a user group meeting. I don't do that every weekend; usually I try to balance work, family and church. But yeah, there's work. (5 year old bootstrapped company; doing it full-time for the last 4 months only. 1 employee, in training.)

</comment><comment><USER7> I use weekends to do experimental work ... trying out new frameworks, or different machine learning strategies, which I'm doing right now, 2am Saturday morning :)

Sometimes I take 1 or 2 hours off during the day to play some PS4 ... dont push myself too hard in the weekends

</comment><comment><USER8> I try to stop work by Friday evening and start up again Monday morning but lately I've been using Sunday nights to get an early start on the work week.

</comment><comment><USER9> Like a normal person's weekend.

<comment><USER10> How was it at your first startup? Different, I guess?

If so, do you think your "normal weekend" is mostly related to one of the following points, all of them, or something else entirely?

a) wealthy enough, not _needing_ to make it work to put food on the table

b) old enough to have priorities shifted

c) easier circumstances (like reputation, network of colleagues etc.)

<comment><USER9> Depending on how you count, I'm on my 5th or 6th startup, starting from 1996. Of the previous 4-5 (ie, not including Starfighter), all but one had good exits; three of them grossed me a pretty substantial amount of money.

Only one of those companies demanded my evenings and weekends; it did so because I was a cofounder and I let it do that. And it's the one that failed catastrophically.

2 startups back for me is Arbor Networks, which I joined in 2001, and which was acquired in 2010 for a very large amount of money (it had hundreds of employees at the time). I was hired to take over as lead dev from Dug Song on their flagship product, which at the time (a) had no major customers and (b) was locked in an intense dogfight with two other well-funded competitors with the same small set of customer prospects.

I worked one weekend. Arbor got a deal to monitor the South Korean Winter Olympics for DDoS attacks and the engineering team took shifts managing the deployment. A big deal was made over the fact that we were being asked to do that.

(I later switched from dev to product management, and my schedule got grueling; in particular, I had the worst travel burden of my career. But I asked for that.)

No. I don't think I have normal weekends because I'm wealthy enough to thumb my nose at the startup lifestyle. I thumb my nose at that lifestyle because it is moronic and doesn't work.

<comment><USER10> Thanks! I knew you had more than Matasano under your belt, but not how many.

I'm still doubtful if startups can generally work with "sensible hours". It's probably one of the big reasons why I never thought about joining one (besides that it's still unusual in Germany).

</comment></comment></comment></comment><comment><USER11> i like to get more online learning, because these days are busy days and you only have one time at a time. so yeah, learning while you can ! :p

</comment><comment><USER12> we meet a lot of users during the week (and also sometimes have other meetings) so weekends are a really great time to focus on the product and build slightly larger changes to test during the week. fewer distractions and emails on the weekend</comment>