Ask HN: Why are there some many *.js frameworks/api's coming out - <AUTHOR>

Its seems like, these days, everybody and their mother is writing a .js library or framework. Whats is causing this sudden phenomenon. Why do people want to use javascript the server or middlewhere or wherever ? what changed ? Would like to get the community's perspective. <comment><USER2> 1\. node.js happened

2\. lots of devs already know the javascript API very well.. a lot of times these same devs write server backends. why not share code between client and server?

3\. (maybe just me) it turns out writing in a language as dynamic and flexible as javascript is pretty fun

<comment><AUTHOR> 1\. I guess why did node.js happen. Was the developer just trying to showcase his skills and did it for fun, and then went viral. And now everybody else is just doing that. To me then *.js are nothing more than a fad. 2\. Reasonable. 3\. Php is fun, has more support (atleast when it comes to doing more 'servery' stuff.

<comment><USER3> I'm not an expert on Node.js but my understanding is that Ryan Dahl wasn't happy with the performance that PHP and Apache provide. PHP is very feature complete but the way Apache handles web requests means that a web server has a relatively low max capacity. Apache handles requests by forking the process which is both slow and resource intensive.

The way Ryan explained it is that moving past that performance barrier is a solved by a single threaded application that can respond to event based input output. He liked Javascript because it is such a minimal language which already supports that paradigm and has advanced tools and community.

That's the main point that I recall from one of the talks of his that I watched. There are some tertiary reasons as well which make Javascript a good choice.

</comment></comment></comment><comment><USER4> I think the biggest single thing to happen was significantly faster JavaScript processing. The speed boost has made things that were previously not worth doing possible. With out the V8 engine node.js was not a realistic proposition.

<comment><AUTHOR> Agree. V8 is one part of the equation. However, in my opinion re-inventing the wheel for fun can be argued both ways.

</comment></comment><comment><USER5> JavaScript is fun and easier if you don't have to share code or data with other people. there are no contracts, no interfaces, no classes to slow you down, and most of the software world has a 'screw the other guy' mentality anyway. All you have to do is remember what your own data looks like for a short time. Most code will not be shared with outsiders and most people want to impede their coworkers rather than do extra work to make things easier. so the mentality is "why not use JavaScript for everything."

<comment><AUTHOR> I never understood the 'fun' part when people refer to programming languages since its so subjective. Apart from that I agree with your comment, in that the field of software engineering is so young and as a result one has to deal with a lot of noise, because everybody is trying to contribute which is a good thing, but it also creates chaos.

<comment><USER2> When I call a language fun, I generally mean:

1\. It delights me by doing what I want.

2\. It makes normally complex programming tasks easy (try metaprogramming in php).

3\. It is simpler than I originally imagined.

1 & 2 generally means... it's a "hackable" language (ruby is another good example). 3 is icing.</comment></comment></comment>


Magic Numbers of Amazon Web Services: 386209384616 - <AUTHOR> https://medium.com/@vitoc/magic-numbers-of-amazon-web-services-386209384616-5482b13ca8e0#.79801l6uj <comment><USER2> Dog-fooding has been described as "The Golden Rule of Platforms"[1] and was apparently part of Jeff Bezos's mandate:

" _His Big Mandate went something along these lines:... There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team 's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network._"

1\. [https://plus.google.com/+RipRowan/posts/eVeouesvaVX](https://plus.google.com/+RipRowan/posts/eVeouesvaVX)

</comment><comment><USER3> > It's nice to see that AWS' supporting services are ran pretty much the same > way as how outside companies will run their workload within AWS.

Reminds me that Heroku does (or at least did) run their slug compiler Vulcan _as a Heroku app_ —when you push your app to Heroku, you're simply relying on another Heroku dyno to do the work of building yours. They don't need to do anything special to those dynos, or give them any special privileges; they're already isolated enough to serve as build-task runners, and their only output is to push something from their filesystem to S3, which they can do completely obliviously to Heroku's architecture.

I believe the recently-rebuilt Heroku dashboard might _also_ be a Heroku app, but I'm not as sure on that one.

</comment><comment><USER4> This is pretty well-known. For a similar example, you have to magic-number the Elastic Load Balancing service IDs[1] in order to dump logs to an S3 bucket.

[1] - [http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable- access-logs.html#attach-bucket-policy)

</comment><comment><USER5> It scared me initially that knowing this would open up a can of worms but conclusion came to dog fooding and not exploit.

Thanks I never gave it and these ids too much thought until this post.</comment>


Ask HN: Got into YC. Where do we live? - <AUTHOR>

Just heard back that we've been accepted to the Summer 2013 class. I have a few days to find a house while we're out here. Any tips on where to live? <comment><USER2> What are you looking for? Pretty much anywhere between the presidio neighborhood in sf all the way down the peninsula to say Cupertino/Sunnyvale will be good, depending on what you want.

BART stops running about 12:30 AM and caltrain stops around 9, so unless you plan to work normal hours, plan on needing a car or a bike to get to and from the office. Commuting in a car is not fun, because traffic can be pretty bad.

</comment><comment><USER3> Recommend trying to find something short term in SF. Apart from the fact that all the major startups (Twitter, Obvious Corp, Pinterest, Airbnb, Square, etc) are based in SF, it's only a 35-40 min drive to Mountain View and most importantly, you'll be able to connect more easily with YC alum mostly living in SF. Check Craigslist SF Bay for short term, furnished housing.

<comment><AUTHOR> Ah interesting take. Did you go through YC?

<comment><USER4> This probably what we'll be doing.

<comment><USER3> Even Zuck prefers to live in SF (he has a house in Palo Alto 'only' because of office proximity). Ron Conway lives in SF. Marissa Mayer (except when she has to be at Yahoo), Drew Houston, Jack Dorsey, David Sacks, etc - all live in SF. Everyone commutes via shuttle/train to Mountain View or Menlo/PA.

</comment></comment></comment></comment><comment><USER5> As bad as mountain view is, you'll want to be there for at least the time during YC.

IIRC, YC will send you leads on places to live shortly after interviews.

<comment><AUTHOR> Yeah we want to go close to the YC offices if possible. Do you know if most people do houses or apartments?

<comment><USER3> Some homes have short term sublet rentals. (airbnb, homeaway). For short term apts in Mountain view, try here: <http://bit.ly/ZSpLCS>

</comment></comment></comment><comment><USER6> I may have a furnished spare bedroom available, just off of Castro Street about a mile from YC. Feel free to ping me.

</comment><comment><USER7> Strongly suggest mountain view. Avalon, etc. are fine.

</comment><comment><USER8> South Bay for sure, during YC. MV, Palo Alto, Los Altos, Menlo Park etc. You can move to SF after YC.

Anywhere close to YC with easy access to the 280 is best.</comment>


EC2 Instances with Nvidia T4 Tensor Core GPUs - <AUTHOR> https://aws.amazon.com/blogs/aws/now-available-ec2-instances-g4-with-nvidia-t4-tensor-core-gpus/ <comment><USER2> Nearly a year behind Google

[https://cloudblog.withgoogle.com/products/compute/google- clo...](https://cloudblog.withgoogle.com/products/compute/google-cloud-first- to-offer-nvidia-tesla-t4-gpus/amp/)</comment>


Show HN: The past decade trends based on HN - <AUTHOR> https://nvbn.github.io/hn-past-decade/ <comment><USER2> What stands out is a substantial decline in submissions about Google.</comment>


Web applications don't follow Moore's law (Google developer) - <AUTHOR> http://www.colijn.ca/~caffeine/?m=200709#19

<comment><USER2> "But Joel's assertion that Google doesn't understand the big problems and isn't working on general solutions to those problems is patently false, as is his suggestion that all work on optimizing AJAX apps will be wasted in 6 months."

Peter didn't read the same essay I did, he's fixated on some trivial statement, or he's deliberately setting up a straw man version of Joel's argument. Joel's point, as I took it, is that people too committed to rolling their own everything out of misplaced focus on performance _now_ are going to miss out on the performance and interoperability improvements that will be coming in the future.

Here's an example from Mac software history that Joel may be ignorant of: WriteNow, a word processor, was well known for being blazingly fast. It was the only application in its class written in hand-tuned 68K assembly. Everyone bowed before the WriteNow team's accomplishments...until the PowerPC Macs came along and made their codebase obsolete. Oops!

I'm not sure there's anything that people wanting to build non-trivial apps _now_ can do about Joel's vision of the future, except understand that it very well may be coming.

<comment><USER3> peter was making the point that moore's law won't, for example, make my round- trip latency from sf to boston much less than 90ms, so optimizing to reduce round-trip times (and to a lesser extent, bandwidth) will _always_ be necessary to design snappy interfaces on the web.

<comment><USER4> Just to be clear: he didn't say "always." He said, "any time soon."

</comment></comment></comment><comment><USER5> The amount of multimedia on the internet will expand to fill the pipes just enough to slow down everyone else's mission critical data. Better find a way to optimize round trips or you're toast.</comment>


Pagedip is coming 5.15.15 - <AUTHOR> https://pagedip.com

<comment><USER2> If this is yours could you add a short block saying what it is ?</comment>


Apple rocks with iTunes 9, iTunes Store improvements - <AUTHOR> http://arstechnica.com/apple/news/2009/09/apple-rocks-and-rolls-with-new-ipods-itunes-lps.ars

<comment><USER2> Anyone else feel their lineup is extremely.. non-Apple-y now?

It used to make a lot of sense - to me anyway - how they arranged their iPods from cheap(ish)/only basic features to the luxury-versions with more features.

I.e., shuffle -> play music; nano -> all of shuffle's features + view album covers, song texts, song titles to the music, calendar; iTouch -> all of nano's features + the whole smartphone without phone thing

But now, ever since the introduction of the iPhone 3G, this doesn't hold true any more. The iTouch is supposed to have all the features of the nano plus more - but now it doesn't have a camera?

The only reason to give the nano a camera and not the iTouch would be to distinguish it from the iPhone and market it as a gaming device. But then it doesn't make sense how the basic model of the iTouch has a slower processor and GPU than the iPhone.

I don't know, but from these oddities in the lineup I'd almost go as far and predict more changes to come very shortly. Either push the iTouch more in the gaming niche and make the nano the new multimedia device (as opposed to just audio in the first two generations of it), or push the iTouch more into the all-in-one direction - which would mean there ought to be a new iPhone as well in order to keep the two apart.

Not sure if I'm making sense here, but right now the nano, iTouch, iPhone lineup is quite counter-intuitive and almost non-transparent (yes, choice is not always a good thing).

<comment><USER3> _The iTouch is supposed to have all the features of the nano plus more_

Says who?

<comment><USER4> says apple's usual product lineup aesthetic.

one of the problems apple had about the time jobs came back was a confusing product line. nobody had the discipline to say "no," so there were a bunch of nearly identical competing products. novices had trouble picking one.

this current situation isn't nearly as bad as that one was, but it's definitely headed in that direction.

</comment></comment></comment><comment><USER5> Well, rocks. In a weird kind of way. The new things are all nice but iTunes has become this huge pile of features, thrown together with no sense of direction.

Case in point: Genius Mixes and iTunes DJ. They both do the same. DJ gives you more options (like a history of played songs, better display options, voting, etc.) while Mixes can pick out similar songs (which DJ doesn't do). Both have the purpose to play a never ending stream of music. Why the heck do they keep them separate? That doesn't make any sense at all. Combine the two.

Kick out the old and consolidate. That would be a bold goal for iTunes X.

</comment><comment><USER6> For those who are wondering (it's the first thing I checked): It's still not 64 bits.

<comment><USER7> As someone mentioned elsewhere (Gruber I think), it uses the older Carbon API which is being left in the 32-bit world. They'll have to upgrade it to Cocoa to make it a 64-bit app, but Cocoa isn't ported to Windows... So they have limited options:

* Port Cocoa to Windows and port iTunes to Cococa

* (Gruber's prediction) Port iTunes to be entirely based on Webkit (though I don't know how well that would work as I've never looked into Webkit performance/issues on Windows)

* Port Mac iTunes to Cocoa maintain Windows iTunes in Carbon

* Drop Windows iTunes (not going to happen)

* Port iTunes to iPhone/iPod Touch and drop it on OS X (yea right)

* Port Carbon to 64-bit -- even though it has been stated that they won't in a push to force developers onto Cocoa.

None of those are particularly attractive decisions. Going back on their word and porting Carbon to 64-bit or porting iTunes to be entirely a Webkit view seem to be the only options with the least friction, IMO.

I think that porting Cocoa to Windows would probably be a larger undertaking than it would be worth it, though they may have some portions of Cocoa ported already (IIRC, Safari is Cocoa, but they maybe have only ported what they needed to make Safari work).

<comment><USER8> "Port Cocoa to Windows and port iTunes to Cococa"

OpenStep was already ported Windows NT at one time ( <http://en.wikipedia.org/wiki/File:OPENSTEP_on_Windows_NT.jpg> ). They already port other libraries to Windows to support iTunes and Safari. I think this option makes the most sense moving forward if they want to continue building cross-platform applications.

<comment><USER7> Arguably iTunes is on Windows to support Windows users of iPhones/iPods (to expand their 'device market' beyond just the Mac ecosystem). Safari.... not really sure why Safari is there other than to try and support Windows developers of iPhone-targeted web-apps (before there was an official iPhone API). But that conclusion is questionable seeing how there are no Windows development tools for iPhone apps now that there _is_ an official API.

> _They already port other libraries to Windows to support iTunes and Safari._

iTunes doesn't use Cocoa/ObjC. It uses the Carbon/C (C++ too?) that was a way to transition between OS/9 and OSX back in the day (You could download the Carbon libraries for OS/9 and a Carbon app would run in OS/9 with them). Safari is Cocoa/ObjC so far as I know, but it's just a wrapper around Webkit for the most part. They could have ported the Windows version of Safari to Carbon, or just ported the parts of the Cocoa libraries that Safari needs (rather than the whole thing).

So.... it looks something like this:

      Port X% of Cocoa to Win32 + Port iTunes to Cocoa

Depending on that percentage _and_ the amount of time it would take to port iTunes itself to Cocoa would determine how costly it is (time & money). I realize that you're also saying that porting however much of Cocoa over to Win32(+ Win64?) would help them develop more cross-platform apps, but I don't see this being part of their strategy.

Unless you prescribe to the John C. Dvorák line of thinking that Apple is going to go cross-platform, make a way to seamlessly develope Windows/MacOS applications, and then eventually dump MacOS for Windows on Apple machines, I don't think that Apple will leave the galleon that they have for themselves (their product/developer ecosystem). They just use cross-platform apps as a means to an ends... extending gang planks to passing ships and beckoning their passengers to cross over to the Apple side (or at least buy their consumer- devices and get hooked onto those).

<comment><USER8> From what I've looked into, Safari on Windows isn't using Cocoa. The latest Safari even looks much more like a Windows application than previous versions. So maybe I'm wrong about this point. However, I still think they're going to have to port iTunes to Cocoa simply because they've essentially deprecated Carbon. For the Windows version of iTunes, maybe they'll just have an completely separate version that isn't a port.

<comment><USER7> I know that when Safari for Windows first came out people were looking into some of the DLLs that were installed along with it, which were ports of things -- IIRC CF libraries at the very least -- from OSX. They may have depreciated those in newer versions due to poor compatibility with Windows.

</comment></comment></comment></comment></comment></comment><comment><USER9> I don't like the new, white UI. It clashes horribly with the rest of the (dark, grey) UI feels rather tasteless. Screenshot: <http://twitpic.com/h48v1>

The old UI was far, far classier.

<comment><USER10> Isn't it a shame you can't theme it at all?

<comment><USER11> No. The only themes I ever install are the ones that make it look like a native app, as it should.

</comment></comment></comment><comment><USER12> I installed iTunes 9.0 and it seems to have a very web2.0 interface. I kind of like it. They have also increased the top 100 to top 200 lists in the appstore, which is wonderful. Now, they need to improve the rating, review system and voila.

<comment><USER13> Yep, overall some nice improvements but I was hoping they would have carried the Top Earners across to categories too.

<comment><USER12> totally agree. And it should be relatively easy to add. I think they are going to have it with 9.1 or something within a month.

</comment></comment></comment><comment><USER14> I was hoping to hear more about improvements in the technology that regularly offers to delete all the music on my iPhone or iPod. For instance, the Genius feature could save time by deleting only the tracks I am likely to enjoy. With pocket-sized tera- and petabyte storage on the horizon it's the sort of forward-thinking innovation that distinguishes Apple from the lesser players in the field.

</comment><comment><USER15> They took away the category view in the iTunes Store for all older iTunes. A lot of app developers are going to be very upset about this.

<comment><USER16> They hid the categories beside the App Store disclosure triangle at the top of the screen.

</comment></comment><comment><USER17> Nano-phone?

<comment><USER18> It would be extremely unlikely for a new iPhone to be released at an Apple Music Event.</comment></comment>


A List Apart: Get started with Git - <AUTHOR> http://www.alistapart.com/articles/get-started-with-git/

<comment><USER2> The best part of Git? More and more people are using version control and a lot of them aren't even developers. Just like Rails, the community and the social effect (aka GitHub) have made this possible.

<comment><USER3> How well does git handle non-text files like .psd and .ai files?

<comment><USER4> I have a git repo that seems to do fine handling binary files of 1-200 megabytes that regularly update.

The downside is that the repo grows by that much every time I update the file. The upside is that I get a version history if I need to back out to an older version!

<comment><USER5> Also, you can't diff or merge them.

<comment><USER6> Thats not gits fault. It would need to know how the programm that preduced the file does updates or some professor somewere has to figure it out on bitlevel.

<comment><USER7> With the push in the design community to create some sort of replacement for psd comps, I could see a new file type becoming accepted.

The problem is that web design inevitably ends up in pixels, and I will always have to move to that level to tweak, anathema to version control.

</comment></comment></comment></comment></comment></comment><comment><USER8> If you use textmate:

      git diff | mate -

<comment><USER9> What is the trailing slash for?

<comment><USER10> A lot of command-line programs that operate on files take '-' as placeholder for stdin or stdout. For example:

      wget -O - 'http://news.ycombinator.com' | less

The -O option is for specifying an output file, but the '-' says to dump the contents to stdout.

<comment><USER11> Funny; I always use the curl command for that kind of thing, since it automatically pipes to stdout -- but there's something fun you can do with that, too:

        curl http://example.com/foo.tar.gz | tar zxf -

Tar's input file is "-", which means stdin. This downloads and decompresses a tarball to the current directory, without creating a temporary file that I have to delete later.

</comment></comment></comment></comment><comment><USER12> Mercurial is another feature rich DVCS. Joel Spolsky has done an excellent job of providing a similar beginner-friendly introduction at <http://hginit.com>. It's short, easy to understand, and pretty funny in places.

</comment><comment><USER13> I'm really tired of Git standing in for "DVCS" - there are so many better options. Bazaar, Mecurial, Monotone, Fossil - check those out. The only win I see in git is the adoption rate. Which doesn't seem like a real win, just populist shackling.

<comment><USER14> Would you mind explaining why Git is inferior?

<comment><USER13> A big problem with git is that the commits-and-branching model is poorly thought through. It's very easy to find yourself on no branch at all, for instance, or for a developer to believe they've committed work to a shared branch when in fact it's a private one (and therefore leave the rest of the team hanging.)

It's merging workflow is awful - I'm fine with correcting the odd whitespace- as-conflict, but I find the fact that git presents me with >>>>> eyebiting </comment></comment></comment><comment> conflict markers <<<<<< even when I'm using a merge tool difficult to excuse.

Most of all, more than once, git has completely eaten work, which hasn't happened to me with a VCS since the days of CVS and corrupted repos.

Frankly, I see two kinds of arguments in support of git: arguments that derive from the fact that it's a DVCS, and therefore apply to other (IMO better) tools, or "community acceptance" (a la github, Rails) which I find frustrating and circular. Oh, and it's somewhat faster for infrequent operations.

<comment><USER15> > A big problem with git is that the commits-and-branching model is poorly > thought through

Really? I think that is one of its strongest points. being able to switch branches by just going 'git checkout <branch>' and immediately having the entire file structure switched out to what's 'contained' in the new branch was a big win for me.

Git also alerts you when you've made changes and are switching branches, so you can commit or stash your changes to the branch you were on and not mix it up with the new branch, unless thats what you really want to do.

> It's very easy to find yourself on no branch at all

Interesting. In what situation would that happen? I always thought you had to be on some sort of branch (master) at least to use git.

> It's merging workflow is awful - I'm fine with correcting the odd > whitespace-as-conflict, but I find the fact that git presents me with >>>>> > eyebiting </comment></comment><comment> conflict markers <<<<<< even when I'm using a merge tool > difficult to excuse.

Sounds like we're complaing about a cosmetic issue.

> Frankly, I see two kinds of arguments in support of git:

How about the fact that its branching model is pretty awesome and it gives you the tools to do exactly what you want with your version control (rebase, amending commit histories etc)?

<comment><USER13> "Really? I think that is one of its strongest points. being able to switch branches by just going 'git checkout <branch>' and immediately having the entire file structure switched out to what's 'contained' in the new branch was a big win for me. Git also alerts you when you've made changes and are switching branches, so you can commit or stash your changes to the branch you were on and not mix it up with the new branch, unless thats what you really want to do."

Cheap branching is a fantastic feature - that all the open DVCS tools have.

Git focuses on the ability of developers to edit their revision history and provide lovely linear histories (hence the existence of stash, rebase, et al). Git as a tool and as a community encourages one to do so - but the result can be that your local repo and my local repo can no longer be synchronized. Furthermore, it's easy to create a commit of inconsistent code - since you can commit file changes in separate commits.

Ultimately git simplifies the work of project maintainers at the expense of day-to-day development, which isn't surprising given it's source, but I think it's a bad trade.

<comment><USER16> _the result can be that your local repo and my local repo can no longer be synchronized_

Nope. All rebase operations create a brand new branch and merely repoint a ref at it. The original pre-rebase branch is still untouched, and "git reset HEAD@{0}" (see: git-reflog) will reverse the effects of any rebase (and of course, you can undo the undo). Rebase does not affect synchronization in any way except that two users may have very different commit histories that they both call "master". Git handles the synchronization fine, however, so this is a social issue rather than a technical issue. I regularly work on large projects with many committers that rebase, and I have never had any difficulty. Hell, git pull even defaults to "git pull --rebase" now, so you probably won't even see any merge commits when you pull from someone's rebased branch now.

 _Ultimately git simplifies the work of project maintainers at the expense of day-to-day development_

I disagree again. Git makes both day-to-day work easy, and it makes maintaining the project easy. When you are in hacking mode, you just commit with a short message whenever you feel like it. Commit freely, branch freely, merge freely, undo freely. When you are done and you want to cleanup your work to share, you can quickly split commits, combine commits, reorder commits, add better commit messages, and so on. Then, you can push to a public repository, ask someone to pull your branch, or just email patches around. If you mess it up somewhere, everything is undoable. Git even has tools to make merge conflicts easy to handle; if it sees a conflict you've manually repaired before, it can automatically try that repair without bothering you again.

Anyway, it's clear that some people take issue with people "rewriting history" and that they will never use git. But I take issue with having to maintain projects that have an incomprehensible (but "historically accurate" in the sense that I know exactly what the state was when some random person on the Internet typed "commit") history, and so I use git. It is the most efficient use of my time and mental energy, and is why its become so popular.

</comment></comment></comment><comment><USER17> I'm glad to see the increase in GIT tutorials, about a year or two ago there wasn't anything out there except confusing circles that you spin in for people who already know GIT.

Perhaps a blog like the daily VIM might be a great idea for any keen hackers out there.

<comment><USER18> I started git earlier than a year ago. You can just read the documentation that comes with git. It's understandable (at least if you are a hacker).

<comment><USER17> Sorry I didn't precisely mean understandable. I mean that's now how your average user wants to learn the system. If I can't figure it out in 3 minutes I go "screw this, it's complicated" and go away back to "File-> save as-> TheEntireProject-Backup2-version8-March11-2009.code" again.

But maybe I shouldn't be concerned with programmers like that.

<comment><USER18> You were right that git wasn't approachable for normal people.</comment></comment></comment></comment>


Ask HN: How can you completely switch to terminal/console - <AUTHOR> In the modern era we are we much as focused on GUIs but back in the day everything was done using terminals/console. In the modern era how can we completely switch to terminal and perform our day to day tasks on terminal <comment><USER2> For easy start (human friendly) there is Regolith Linux.

[https://regolith-linux.org/](https://regolith-linux.org/)

Once you learn the basics you can switch fully to tmux,vim etc.etc.

The productivity boost is huge.

<comment><AUTHOR> Thanks for sharing I'll definitely check this out Honestly I'm trying to get rid of GUI and starting to lean more towards terminal

</comment></comment><comment><USER3> You can have the best of both worlds, you don't need to go without either a GUI or a CLI.

On my desktop(s), I have both GUI and CLI applications, both ready for immediate use. Ferinstance, I have a GUI browser as well as several CLI xterms.

In fact, I probably do much more minute-to-minute work using the xterm CLIs, but that browser is always available for reference work (and entertainment!).

A bunch of xterms: [https://imgur.com/kqVROsg](https://imgur.com/kqVROsg)</comment>


For the love of POSIX: A more useful way to not segfault from null pointers - <AUTHOR> http://blog.directededge.com/2010/03/31/for-the-love-of-posix-a-more-useful-way-to-not-segfault-from-null-pointers/ <comment><USER2> I think the author is missing the point of the ksplice article ( <http://news.ycombinator.com/item?id=1231961> ), which is that you can exploit NULL pointer de-references in the kernel to gain privilege escalation.

<comment><AUTHOR> That's not actually the point of that article; it's the point of their next one. The linked article basically said nothing about security exploits other than "they happen and we'll talk about them next time". It's a pretty general introduction to virtual memory and a way in user space to avoid crashing dereferencing a null pointer. That said, the post is as much a response to the title on HN as anything:

 _Dereferencing a NULL pointer always segfaults, right? Not if you're clever..._

Now, I don't actually know enough about the exploits they're talking about to know if handling the signal would avoid them or if the null pointer dereference has to actually be in kernel space and they were just starting with examples from user space, which was my assumption on the first pass of reading the article.

<comment><USER3> Sorry, but the point of the article is clearly not "Here's a useful way to avoid having null pointer dereferences crash your program." They start out talking about kernel vulnerabilities in general and the null pointer dereferences specifically.

<comment><AUTHOR> Can you paste some part where they actually talk about the vulnerability? I assume that the title quoted above was the original title of the post since that's what's used on HN and Reddit.

<comment><USER3> The first two paragraphs clearly talk about it in the context of a security vulnerability. They don't explain how to exploit the vulnerability, but one versed in systems programming should either realize what it is, or be able to easily find it through Google or the pages they referenced in those paragraphs.

If you Google "linux kernel null pointer exploit" you will find many examples.

<comment><AUTHOR> So you think most people found the post interesting because of the thing that they're actually going to talk about next time rather than the actual content?

I believe that it's been widely read because of the novelty of avoiding crashes when dereferencing null pointers; in fact, for anyone who could have jumped to the conclusions about how the exploit would work, they could have reduced it to one line: "You can map address 0x0 with mmap and then segfaults on deferencing null don't happen." All of the rest of the article is only useful to people _who don't_ know systems programming.

At any rate, I'm not sure that our fundamental disagreement is that wide; clearly the article is laying down a building block for a later piece on the security exploit and it was written to serve that purpose. This seems to be your point. My point is the actual content can stand alone and, in fact does, and is not about security.

<comment><USER4> _So you think most people found the post interesting because of the thing that they're actually going to talk about next time rather than the actual content?_

Actually, yes. I posted a comment on the previous article saying so. The information in the current article is rather trite. The intricacies of kernel privilege escalation is a different story.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> The problem here is that you've caught all SEGV's, not just the ones from NULL pointers. That's much more dangerous than trying to be clever about NULL.

You can play games with sigaction and siginfo_t to get around this, but that's hairier than just mmap'ing.

<comment><USER6> Why is catching all the SEGV's more dangerous? What specifically can happen?

<comment><USER5> Some SEGVs will be from dereferencing NULL, which is a fairly innocuous error (you asked for something from an API and the API said "no"), but many others will be from derefencing wild pointers.

</comment></comment></comment><comment><USER7> This is an interesting post, but I have a few points. First, there are certain kinds of error conditions where it's better to crash (producing a core dump) and restart rather than "swallow" the condition (even if it's logged). Java attempted to differentiate in this realm by introducing checked exceptions (where you could explicitly say this is an error condition where you can and should recover from, this is an error condition that you might not be able to recover from), but it hasn't had the intended effect (exceptions are simply seen as boiler plate and are wrapped in a try { } catch (Exception e) { logger.error(e); } block; checked exceptions are seen as a mistake).

Null pointers are typically be exactly _such_ errors: e.g., you failed to allocate memory and malloc returned NULL, you didn't do proper validation on input or you assumed a key exists in a hash table when it doesn't. Either assumption that pointer is not NULL is an invariant (in which case it's better _to crash_ and leave a core dump), or it's not (in which case the application should do a check for a null pointer).

It's also _not_ advised to do complex processing inside signal handlers: the idea is to perform a single atomic operation in a signal handler (e.g., change an integer from 0 to 1), and let the application examine that operation's side effects. For example, there could be a "should_quit" integer which when 1 would mean the event loop should terminate and the signal handler would just set that integer to 1.

</comment><comment><USER8> From the article being ranted about: " _Next time, we'll look at how a process can not only map NULL in its own address space, but can also create mappings in the kernel's address space. And, I'll show you how this lets an attacker use a NULL dereference in the kernel to take over the entire machine. Stay tuned!_ "

So it's not really about handling NULL ptr derefs, but exploiting them.

</comment><comment><USER9> So, catching SIGSEGV is still a segfault! It is not fatal, so in that sense sure you aren't segfaulting, but the error still occurs, the signal is still generated, and you still don't actually dereference NULL. In the other article there is no error, SIGSEGV is not generated, and therefore there is no segfault at all. They are fundamentally different.

<comment><USER10> Hiding the error does not mean that the error did not occur or that it is not a problem.. It was about to occur and there is still a fundamental problem in your logic leading up to the would-have-been segfault that was swept under the rug.

I would much rather know where my code tried to access a null memory space and what/why/how a null pointer was passed than to have it "fake" that it didn't ever happen! A signal handler for a SIGSEGV/SIGBUS is a great place to add a syslog() so you can find the error in your logic and correct it.

<comment><USER11> > Hiding the error does not mean that the error did not occur or that it is > not a problem.. It was about to occur and there is still a fundamental > problem in your logic leading up to the would-have-been segfault that was > swept under the rug.

It's an error only if you didn't want to dereference address 0. If you know it's safe and useful to do so on the system for which you're developing, why shouldn't you be able to do it?

As the KSplice article shows, on Linux (under specific setup which is not the default), you can actually have something mapped there. I'd be hard pressed to invent a convincable scenario in which you would _want_ to do it, but that doesn't mean there is none.

</comment></comment></comment><comment><USER12> As I mention on his blog post, both of these tactics are inherently evil and can result in security vulnerabilities, since the attacker now can keep trying memory addresses until he succeeds, which defeats ASLR for one.

It will also turn an easy-to-debug SIGSEGV into a horrible-to-debug memory corruption; check out <http://support.microsoft.com/kb/976038> for an example. This bug made debugging large applications on x64 a _real_ pain.

</comment><comment><USER13> I don't think the ksplice article was really about a way to "not segfault" from dereferencing a null pointer, but this ended up being a nice, short exposition on handling signals anyway.

<comment><USER14> Agreed, the code was a clear example of how to handle signals. I could understand it even though I haven't even dealt with signals before.

</comment></comment><comment><USER15> Where's the POSIX? This is bad example code.

</comment><comment><USER16> WTF,

You _should_ get an error condition from dereferencing a null. When you're debugging your code, that error condition should be nice and verbose. Once you're shipping, that error condition should be very short and simple and should almost never occur. Trust me, your customers will not help you debug your code.

Test Driven Development and Design By Contract AND traditional software engineering all agree - FAIL EARLY AND OFTEN in your test suite to avoid later bugs. It is WRONG to let errors float around in your program logic, WRONG.

I went from C++ to Rails and back to C++. Is Rails reasoning trying to seep into C++? HELL NO!, The C-parts of C++ are serious and won't stand for this shit.</comment>


Intel's new boss wants to teach the chipmaker new tricks - <AUTHOR> https://www.economist.com/business/2019/05/11/intels-new-boss-wants-to-teach-the-chipmaker-new-tricks <comment><USER2> > firms from Microsoft to Facebook to Tesla have begun designing custom chips > specialised for the sorts of number-crunching their businesses need.

>That is unlikely to harm Intel directly, since such accelerator chips are complements to its server chips, not replacements.

This is just straight down the line wrong. In the data centre there is just 'compute' it doesn't matter if it's a GPU or CPU doing the compute. What does matter is that if you're doing all your compute on a GPU or ASIC then the CPU you're buying can be a lightweight chip just to do a little control & synchronization. Intel doesn't make huge money on those chips. It's the massive 512core 100GHz monsters where it's making the most cash. So these custom solutions absolutely present a threat to Intel's server revenue.

As well as that Tesla are going for ASIC in their car. Automotive was a key growth area for Intel which is one of the reason s it bought Altera and MobilEye. If they miss automotive (which they will given most big movers are on Nvidia platforms with ASICs coming after, and Intel is failing in their fab business).

>he hopes to continue Mr Krzanich's strategy of expanding the firm's reach.

Intel cannot execute on this until Intel's culture changes. The problem they have is they're trying to cost cut in legacy businesses whilst investing for growth in new businesses. Firstly this pisses off the legacy businesses like you wouldn't believe. Secondly, legacy business spends it's entire time dressing up in make-up and a new dress and screaming "Look at me! I'm a growth area!". And finally, the actual growth areas are hamstrung by inappropriate cost-saving, 1-size fits all management and spending 99% of their time trying to persuade the rest of the business they really are a growth area.

Intel is just not set up to win new markets.

<comment><USER3> This is a classic The Innovators Dilemma scenario, as described in the book back in the '90's. If the people running Intel read the book and understand the problem they'll know what to do. Otherwise the opening will be there for someone (Nvidia) to take the ball, run with it and own the industry.

Being aware of history is important. Very few things in business are new once you distill things down to their essence.

</comment></comment><comment><USER4> Overall Intel's future looks bleak. Finance guy at the helm usually means milking existing markets and a slow decline. The bright spot IMO is Mobileye. I think that there is a good chance that they will end up the dark horse AV leader.

</comment><comment><USER5> I'm bearish on Intel. The culture is conservative and unwilling to compete with FANG on pay for employees.

<comment><USER6> It's funny you mention that since Intel was involved in antitrust lawsuits along with Apple and Google for conspiring to wage fix.

[https://en.m.wikipedia.org/wiki/High- Tech_Employee_Antitrust...](https://en.m.wikipedia.org/wiki/High- Tech_Employee_Antitrust_Litigation#Civil_class_action)

</comment></comment><comment><USER7> I don't see much new tricks here: he moves Intel as a business into the safe harbour of "enterprise" products a specialty server hardware that nobody, but easily upsellable corporate clients will buy.

<comment><USER8> Easily upsellable corp clients have lots of money. Intel is a sitting duck to disruption of all types.

</comment></comment><comment><AUTHOR> paywall workaround - [https://outline.com/3aH5Su](https://outline.com/3aH5Su)

</comment><comment><USER9> Not a good start when you count 4 incorrect statements in the first few paragraphs of the article.

<comment><USER10> What are those statements?

<comment><USER9> Generally lazy writing or attempting to jazz up the piece without enough expertise to know when you've changed the meaning.

"Intel dominates the market for chips that power desktop PCs." It has a bit over 85% market share, in a two-player market. Furthermore, because they didn't say CPU like they should have, they're technically inaccurate. Intel network PHYs don't "dominant" consumer boards, last I checked.

"demand for server chips is growing, propelled by the profusion of internet- connected gizmos, from smartphones to cars." Really? IoT is the catalyst?

"missed the arrival of the smartphone" Unfair and reductive. Intel didn't "miss" the smartphone: it saw it coming, didn't have a product that fit, looked at the margins, and didn't think it was worth investing. That probably wasn't a bad move in hindsight.

"GPUs, specialised chips designed for video-game graphics" That tortures the definition of a different microarchitecture.

"And its manufacturing technology, which used to advance with such metronomic regularity that Intel called its business plan "tick-tock""

This was it for me. Intel _literally_ moved to the tick-tock cadency _because_ Moore's Law was slowing down. Before, it was just an unending stream of process shrinks. Tick-tock accepted that there was now time for an entire microarchitecture update between process shrinks.

"The firm's latest generation of products, built on its "ten nanometre" manufacturing process" Also, since when do we air quote measurements?

<comment><USER11> Intel did try to get into phones, they just failed. I have one of the Asus ZenFones with an Intel processor running x86 Android.

<comment><USER9> They tried, but the power-optimized Atoms were still a hedged bet. They threw some spaghetti at the wall to see if it would stick, while keeping the core suitable for other markets if it didn't.

</comment></comment></comment></comment></comment><comment><USER12> I don't see any experienced programmer making an investment in an Apple language(unless they are being paid).

If you are old enough, you have been jerked around by Apple enough to know better.

Expecting $500$+ dev packages in the next 10 years from Apple.

<comment><USER13> What has this got to do with Apple?</comment></comment>


What They Don't Tell You About Public Speaking - philipp-spiess http://zachholman.com/posts/what-they-dont-tell-you-about-public-speaking/ <comment><USER2> "There's one mistake I consistently see made by speakers both novice and experienced: they're not excited about their talk."

I'm a nervous presenter. The way I used to combat this was with a poker face. No smiles, no laughing, no gestures, monotone voice... I'd do anything not to clue them in to my nervousness.

This is a flawed approach for me. People are very forgiving of humanizing nerves and foibles. People aren't so forgiving of boring, monotone talks.

What I try to do now, with some success, is to embrace (not suppress) the nervous energy. To 'feel' the same way I do before a challenging ski slope. I'm in my 30s and I don't get adrenaline spikes very often like I did in my 20s (like say, when flirting with someone new that I really like). So I'm teaching myself to seek out places to present, so I can get and enjoy that intense energy spike.

Adrenaline is the best, cheapest, healthiest, and most legal drug available to you; don't shy away from it. And give some of that energy back to your audience.

<comment><USER3> This is a bit off topic, but according to wikipedia; "Adverse reactions to adrenaline include palpitations, tachycardia, arrhythmia, anxiety, headache, tremor, hypertension, and acute pulmonary edema."

I've always thought that a true straight-edge person wouldn't deliberately trigger adrenaline releases. The fact that your body produces it given a particular stimulus doesn't seem to really be relevant to the "goodness" of the substance. If your body produced cocaine when you get in a mosh pit is that different than just taking cocaine?

<comment><USER4> Adrenaline doesn't have any long-term health risks, unlike cocaine. If cocaine was safe in the long run, and I found that I didn't get negative side-effects and it helped me do <x>, I'm not sure what the downside would be in me using cocaine.

When I used to be a singer I personally found adrenaline would only come with more important performances (bigger concerts, live radio), never with smaller concerts on recording sessions - I never experienced any downsides, and it helped me do better. If I could have found a way to get an adrenaline rush all the time, I definitely would have grabbed it with both hands.

edit: Given the topic of this actual thread, an interesting side-note is that despite never having problems with music, I'm pretty terrible at public speaking.

</comment></comment></comment><comment><USER5> Great post, especially the concept 'Talks should always be reactionary rather than anticipatory'.

A public speaking ancedote for all those that are nervous at public speaking or currently aren't that good at it.

My father excels at public speaking. He has done many conferences, TV interviews, company all-hands meetings, regular presentations, etc. He is natural, comfortable, excited, etc. Most imporantly, he can really read a room and react to people and tune his presentation on the fly to what interests the crowd.

But it was not always so. When he was in his 20s, he was absolutely terrible at speaking in front of a room. At one point early in his career he was giving a presentation and his boss turned to the HR guy that had hired him and said 'is it too late to undo this one', purposely, loud enough for him to hear.

Over the course of 5 or 6 years he dramatically improved at public speaking.

Public speaking is a learned skill. You can practice it. Do not leave making the presentation to the last minute, finish it a week before hand and practice 40 times. Comfort comes from being prepared. Walk the room beforehand. Check all of your gear and have backups of everything just in case. Be prepared to use no slides so it won't be a completely new experience. Have fewer slides, it makes you feel more naked but the audience won't notice if you get things out of order a bit.

Toastmasters helps. If you are younger, join a debate or model congress club. It's like shooting a foul shot, you just need more reps.

<comment> why-el It will be awesome if your dad had a book on what happened in those 5 to 6 years.

Of course I am in no position to provide as useful an advice, since I am still a student and the toughest audience I presented against are themselves students. However, I find the preparing by replaying the presentation to yourself a little daunting. I used to do that and there always seems to be something that goes wrong, especially that I am supposed to have memorized the presentation. I don't really trust my memory that much, so what I started doing is knowing the topic very well, have some general enough guidelines, and just talk to the audience. It's classic improvising and it worked for me up to now.

<comment><USER5> I wouldn't say you want to memorize the presentation.

In fact I think the more you write out for yourself, write on your slides, or try to memorize, the more difficult the presentation becomes.

The practice is more about stumbling a bunch of times. I hate when I repeat the same word or phrase within a few sentences of each other. If I notice that I say the same thing twice on one slide, maybe I'll stand there for a second and think of a new way. The next time I practice through I might use a 3rd way, but at least I'm not repeating.

I only really memorize maybe the first two sentences I'm going to stay just to get the ball rolling smoothly, and maybe a final sentence so my exit is clean.

<comment><USER6> I'd go so far as to say you absolutely don't want to memorize your speech, unless you're at the level of Important Remarks for Important People like the State of the Union.

Instead, you want to memorize all the key features, jokes, and wry remarks.

You can write out your speech, if it helps. But read it. Out loud. To a wall. About ten or fifteen times. Read it, without looking at the paper (except when you forget what goes next), and without trying to duplicate it verbatim. You'll learn what phrasings come naturally to your tongue rather than your hand, and it'll flow a lot better when you give the speech itself.

<comment><USER7> To extend your point on key features: I think of it as memorizing the overall structure of your talk. You may have a dozen or so topics you want to hit in your presentation, and that is what you end of memorizing - not on purpose, but because if you're well prepared, you can't help but _not_ memorize it.

If you know that you want to hit points A, B, C, ..., in your talk, and you know your material cold, then you don't have to memorize how you want to connect A and B, B and C, etc. That is what you re-create on the spot. The practice is important because sometimes you _can't_ connect two points on-the- fly. Practicing your talk at least once will reveal those places, and you can either: figure out what the connecting bits are, or decide you don't want to cover that.

In addition to the jokes and wry remarks, I find that I also tend to replay the same body language in talks that I did in practice.

<comment><USER8> I've given more than a few public talks, and I ran for Lieutenant Governor of NC a few years ago, and did some campaign speeches as part of that... what I have found is that they key is to be _able_ to improvise your entire talk if need be. That is, if you know the points you want to make, and a rough order you want to make them in, you can construct the talk as you go if need be. Then you never have to worry about "forgetting your lines" or whatever. If you can develop this ability to give a speech totally unscripted, you can then choose whether or not you want to use notes or whatever to help you stick more precisely to the plan... but in the worst case, you're never totally screwed with no ability to proceed.

FWIW, when I ran for office, I never memorized a single speech, nor did I use notes. I mentally rehearsed the key points and structure on the way to the venue, and then improvised. Take the fact that I didn't get elected however you want, vis-a-vis the effectiveness of my approach. :-)

</comment></comment></comment></comment></comment></comment><comment><USER9> It's tougher to be a solid public speaker than it looks. I've given talks to big rooms, gyms and moderately sized conference rooms. I rarely get nervous but occasionally it hits us all. I do have some notes on watching great speakers in person and learning from my own mistakes.

1\. Do NOT ask for a 'show of hands' from the audience. Even some practiced speakers do this. They think that it engages the audience, but it is a crutch, an attempt to turn the focus away from the speaker onto the audience. It's always clumsy and delays the audience from hearing the content. Some speakers claim that they want to know more about the audience before they proceed. We all know that's not true. Are you really going to completely modify your speech, dropping that five minutes of solid material just because not enough hands were raised when you asked about it? Of course not.

2\. Note cards are not 'bad'. I had to learn this one the hard way. If you are professional orator, you will eventually get to the point where you can pontificate the same speech verbatim without a single note. But for the rest of us, a note card of bullet-point topics can keep us on track. Just don't have a ream of pages and stare down at them, reading monotonously without looking up.

3\. Everyone hits that middle 'death valley' at some point. It's the point of a talk where you are very aware of your own voice, and you aren't getting any perceived feedback from the audience. This is the hard slog where you have to know that while time has slowed to a crawl for you, it hasn't changed for the audience. Remember how you feel when the situation is reversed - how often have you ever seen a speaker so bad that you actually noticed it and remembered it? Not often, if ever. Boring speakers are forgotten - <AUTHOR> speakers are ignored - great speakers MIGHT be remembered. So just keep going, and the worst that could happen is that you are boring, which no one will remember anyway.

<comment><USER10> > _Do NOT ask for a 'show of hands' from the audience._

I completely disagree. If you ask people to raise their hands 10 times on inane questions, then of course it's useless. But correctly used, it:

1) Wakes people up and gets everyone in the room focused

2) Gets people aware of the rest of the audience, and "on the same page"

3) Ideally provides a natural segue into how the point of the lecture directly connects to _you_

I taught English for years, which was basically public speaking every single day, and getting my students to tie an aspect of the theme/question of the day into their lives, and respond, in the first couple minutes was always _key_ in terms of getting them all on the same page and relating to the material in the rest of the class. It would only occasionally be a show of hands, there are hundreds of other techniques as well (shouting words, asking the nearest person a question, writing a word on a piece of paper, etc.), but these are all _fantastic_ public-speaking techniques. Of course, you need to have the personality to pull them all off, so the audience trusts you and wants to go along, but you can develop that.

Indeed, I think it's a real shame most public speakers don't interact _more_ with the audience through these kinds of things. They boost attention levels and retention levels so much more.

<comment><USER7> While I defended the practice below, I consider teaching to be a special case of public speaking. I have "presentation mode" and "lecture mode." There is a lot of overlap, but they're not exactly the same. In presentation mode, I will not stop everything and wait for someone to answer a question. When I'm presenting, I don't expect people to understand everything that I'm saying to the point that they can apply this new knowledge. I would _like_ that, sure, but I think it's presumptuous to assume they would like it as well. Presentations are also often made to peers, and I don't like quizzing my peers in such a way.

In lecture mode, that's the entire purpose of my presentation, so I do it. I have no problem quizzing students in such a way - because if they can't answer the question, then I should change the focus of the lecture to make sure that everyone can before I move on.

Note that I am differentiating between quizzing and polling. I'll poll in both lecture and presentation mode.

</comment></comment></comment><comment><USER11> My breakthrough in being comfortable with public speaking came from a quote:

 _"...though it cannot hope to be useful or informative on all matters, it does make the reassuring claim that where it is inaccurate, it is at least _definitively_ inaccurate."_ \- Douglas Adams

If I am to make a mistake while presenting, then by gum I'm going to make that mistake with the most confidence and gusto I can muster. I will own up to being wrong, I will turn that into a "teaching moment" for the audience, I will plow forward confident in the spirit of Kipling's "If" knowing that while I may have screwed up I did so in a good-faith effort at taking the lead and making things happen for an audience that chose to follow. If I am wrong, then I shall be _definitively_ wrong!

That's pretty good for an awkward introvert.

<comment><USER12> Not only can you get away with mistakes by moving past them with gusto, but your entire speech can be a mistake if you pull it off with confidence.

The Dr. Fox effect:

> _Forty years ago, a singularly interesting lecture was held at the > University of Southern California School of Medicine. The subject was > "Mathematical Game Theory as Applied to Physician Education." The speaker > was Dr. Myron L. Fox from Albert Einstein College of Medicine, a pupil of > von Neumann and an authority on the application of mathematics to human > behavior._

> _The attendees were psychiatrists and psychologists (MDs and PhDs) who were > gathered for a training conference. They listened to the lecturer with great > interest, asked many questions and were satisfied with speaker's replies._

> _They gave him flying grades in the satisfaction questionnaire. Nobody > suspected anything wrong. In reality the speaker was an actor and knew > nothing on the subject of his lecture._

[http://www.significancemagazine.org/details/webexclusive/123...](http://www.significancemagazine.org/details/webexclusive/1237447/PhDs- couldnt-tell-an-actor-from-a-renowned-scientist.html) [http://www.er.uqam.ca/nobel/r30034/PSY4180/Pages/Naftulin.ht...](http://www.er.uqam.ca/nobel/r30034/PSY4180/Pages/Naftulin.html)

<comment><USER13> That was the secret of Ronald Reagan's political success.

</comment></comment></comment><comment><USER14> I like this a lot. I'll add a few of my own points too (though I think Zach's are great):

1\. Practice, practice, practice. Now, I'm a hypocrite for saying this because I do tons of speaking engagements with little or no practice (which is a combination of hubris and the fact that I'm often pegged to do stuff at the last minute). Still, if you aren't comfortable speaking off the cuff or in front of a crowd, practice makes perfect.

Something I've often done is to do screen recordings like Zach says -- but instead of doing them of the talk live, I do them before the presentation. The advantage here is that I can practice what I want to say, listen back to my cadence and then adjust and readjust if necessary. By the third or fourth time, I'm usually golden and I have a great master copy that I can try to mimic live on stage.

2\. The better you get. -- This is true of almost anything, but it's especially true of speaking in public. You'll become more comfortable and natural on stage (or on camera) and have a much better sense of how to steer a talk, how to keep your energy up and how to come across as assured.

3\. Record yourself in advance. For beginning public speakers, it's important that you record what you sound like so that you can adjust your speed (slow down or speed up) and cadence. It can be odd to hear yourself speak at first, but once you get used to it, you can adjust what you look and sound like. This is especially important if you are doing any media appearances.

4\. Watch Yourself After -- If your speech or conference is being recorded (or if you are recording yourself) -- watch it back after. Again, it can be disconcerting but it's a great time to learn how you can improve next time. It's also a great way to see how you progress over time. If I look at my first CNN appearance in April of 2011 and my most recent appearance, it's like night and day. That helps me when I get up to present at an event, keynote a conference or do another media appearance.

<comment><USER15> Recording yourself is extremely important. Although it may be awkward to look at yourself stumble through a speech, you will get good understanding of how you are presenting yourself. I'd even go as far as trying different clothing and see how each changes the image your reflecting. As I use to co-host a radio show, I found that listening to yourself live is the best way to ensure a high quality show. It makes sure you don't speak too slow,fast, if there's an echo etc.

</comment></comment><comment><USER16> Legendary senior partner at a law-firm sandwich seminar: "The most important thing about public speaking is to say it with _confidence_!"

Young associate (me), raising hand: "But what if you really _aren't_ confident?"

Senior partner, fiercely: _"FAKE it!"_

<comment><USER17> Totally off-topic but: I wish you'd comment more often here.

<comment><USER16> I'm flattered! (Ditto to Thomas.)

I do lurk here a lot.

</comment></comment></comment><comment><USER18> "Talks should always be reactionary rather than anticipatory: they're going to come off as more natural, more interesting, and above all, more valuable."

I agree with the sentiment here. My presentations are all about science and bioinformatics, and I find they go best when I have a story to tell. The audience loves to hear stories, especially when they can experience the aha! moment themselves before I get to the end of the story. It's a much better story if the project is almost complete rather than mostly unfinished.

As a minor aside, being a grumpy old guy, I would suggest that rather than "reactionary" (which means something altogether different than what I understood Zach to be saying), the proper term might be "retrospective" and paired with "prospective". I misused "reactionary" myself in younger days and still cringe when I think about it. Strange word indeed.

</comment><comment><USER19> For those that do much public speaking there's an interesting article on rhetoric here [http://www.european-rhetoric.com/rhetoric-101/modes- persuasi...](http://www.european-rhetoric.com/rhetoric-101/modes-persuasion- aristotle/)

In a nutshell For communicating a message Pathos(emotive "Be Excited") is more important then logos(the words). Ethos(Ethics, character) is more important then Pathos.

Of the modes of persuasion furnished by the spoken word there are three kinds. The first kind depends on the personal character of the speaker; the second on putting the audience into a certain frame of mind; the third on the proof, or apparent proof, provided by the words of the speech itself. Persuasion is achieved by the speaker's personal character when the speech is so spoken as to make us think him credible. -Aristotle 1356a 2,3

</comment><comment><USER20> "Talks should always be reactionary rather than anticipatory: they're going to come off as more natural, more interesting, and above all, more valuable."

I think that's not true at all. There is room for both. I would say do not mix them. Talks can either share what's been done or share what can be from a visionary perspective.

<comment><USER21> Admittedly I slipped an "always" in there when I shouldn't have; I agree that anticipatory talks can be great, too.

Let's put it this way, though: for a beginning or first-time speaker, I'll maintain that talks should be reactionary. There are more than enough other things to worry about going into your first talk that it's really comforting to talk about your past experiences than try to prepare a new project or a "what-if" for an arbitrary conference date. That's more the target market I meant with that (admittedly broad) statement.

<comment><USER22> I would recommend you seriously consider re-wording the "reactionary rather than anticipatory" sentence on your blog. (The number of confused/questioning comments here on HN about the use of those terms suggests I'm not the only one. :) )

The sentence in your post above explains your intention much more clearly:

"There are more than enough other things to worry about going into your first talk that it's really comforting to talk about your past experiences than try to prepare a new project or a 'what-if' for an arbitrary conference date."

As I understand it, what you're wanting to convey is that it's better to choose a topic where you can talk about "what I've done" rather than "what I hope to do". The "reactionary"/"anticipatory" terms don't clearly convey that intention and seem to me to be incorrect terms to use.

(I don't have a specific suggestion for replacement terms--"retrospective" is one option but has a slightly negative connotation.)

Aside from that, thanks for sharing your experiences. :)

</comment></comment></comment><comment><USER23> Great post. I used to often speak publicly. Last week I gave my first talk in years, to a large crowd. I was nervous because of how long has passed since I've last done it, but then I remembered my old habit. Before my talks I used to spend time with the conference goers in the hall, just chatting with them about whatever comes up. This seems to play a trick on the mind, making me feel like I'm speaking to friends rather than a faceless crowd. It worked last week as well. I highly recommend trying it out.

<comment><USER24> I love it, I have no problems presenting to people I know - however vaguely - but a room full of strangers fills me with cold dread.

</comment></comment><comment><USER25> I would give serious consideration to taking an Improv Comedy class. If you can't, I'd like to share the concept of "Yes, and--"

Invariably something will go wrong during one of your presentations.

A slide will look funny. There will be a weird noise from outside. An audience member will say something strange.

The idea behind "Yes,and-ing" in improv is basically you treat every single thing as if it were planned and part of what you were doing, rather than negating it or ignoring it, which is dishonest and creates a disconnect.

I've given three presentations in my life (all this year) and each time something went wrong I ran with it and the audience responded very positively. My slide about "Internal Leaks" was missing the first two letters. Second time public speaking. Crap.

Instead of negating ("Oh this was supposed to say Internal"), I Yes-And'ed.

"Up next, a very important problem, Ternal Leaks." And I then verbally chopped off the first two letters of the next slides (verbally), my name, my company name, and closed with "Anks, I hope you enjoyed it."

(Yes, it's a little corny, but it breaks the wall between audience and speaker. I find, in life, if you make someone really laugh, even if it's just once, everything else works out.)

</comment><comment><USER26> Be excited about what you're presenting is key. You have to engage people through your excitement and by cuing off what they react to.

Many times I find myself including the audience feedback into the presentation in terms of spending time on certain points that get the most reaction.

The author is dead on about the questions, though they don't have to be after the presentation is over.

</comment><comment><USER27> I had a laptop hard lock in the middle of a talk once. That was fun. For the record, I handled it by immediately swapping out my laptop for the session runner's (can't risk it happening 2x during the talk), my slides were online and I just re-downloaded them and tried to go forward losing as little time as possible.

</comment><comment><USER28> An obvious thing that took me a little too many talks to figure out, is to say "Thanks" when you're done. The audience wants to applaude, but the speaker has to initiate it. It always gets weird if the speaker goes to Q&A without it. Do we clap now? Later?

</comment><comment><USER29> This blog has a ton underlying something I think of each time I go into a large presentation - be a rock star!

I realize that's oversimplifying it a bit, but if you think about presenting there are many items that do coincide: know your material in and out, think about your audience, bring the enthusiasm...etc. I realize not every presentation is going to be rock star material, but if nothing else it makes me strive to elevate what I am discussing and has given me something more to strive for whenever delivering material to a larger audience.

<comment><USER30> ... and if you feel you're losing people's attention, biting the head off a live bat is a way to get it right back! Try that next time people are nodding off while you drone on about cloud architecture.

</comment></comment><comment><USER7> A presentation is a performance. When you are on stage, you are _on stage_.

</comment><comment><USER31> "Most conferences are a crap shoot when it comes to video. Half the time they won't record your talk, and the other half of the time it may take months before your talk is published.

Something I've been doing recently is making a screen recording of my talks using QuickTime on my Mac."

This is really true, and really good advice. Organizers have a lot on their hands leading up to a conference, and, after, getting recordings posted languishes until they manage to recover enough of their personal lives to start ramping up for the next.

I've had several instances where I've given a talk, been very happy with the response, and then realized that I had no way to share it with a wider audience except trundling off to the next conference. Next time, I'm making my peace with a screen recording app.

</comment><comment><USER32> I've always been bad at speaking (all my experiences were in school, so far... Not really "public"). But my one really good presentation happened in college. I'd stayed up pretty late the night before finishing the thing along with a handout we were required to give to the class (also my notes), which I was going to print off in the library before class.

Went to bed and next thing I knew my alarm was buzzing and class had just started. I had time to throw on pants, jog to class and immediately start talking about the French horn; no notes or props. I didn't have time to be nervous or worry, and was just genuinely engaged in the topic and it went great.

</comment><comment><USER33> I find that engaging the audience into a back-and-forth has been very successful for me, and I get more positive feedback on the talks afterwards, too.

</comment><comment><USER34> Exceptional advance. Thanks.

I would add that one should not try to get excited about a topic that does not excite you. Authenticity is important. Rather, give talks about topics that you are excited about.

</comment><comment><USER35> The title is a little misleading: they do tell you all these things and more if you don't rely on blog posts that will unavoidably focus on a couple of things and go for a good book.

</comment><comment><USER36> Yesterday's episode of "Back to Work" went over public speaking and confidence as well -- it's definitely worth a listen:

<http://5by5.tv/b2w/72>

<comment><USER37> It may have been worth a listen for you, but I think YMMV applies very strongly to podcasts.

<comment><USER36> in general, I'd agree, but if you're interested in the subject matter of the article here, the podcast does cover some good tid bits about public speaking.

I guess I should have mentioned that the real meat of this show doesn't usually kick in until about 30% of the way through (which I could understand might annoy some people)...

</comment></comment></comment><comment><USER38> best public speaking advice that has made me a 10x better presenter: "a presentation is about the audience, not about you."

</comment><comment><USER39> Steven Wright's stage presence should be a github repo.

</comment><comment><USER40> mm Nothing at all about the art of rhetoric and how to do public speaking well though you could try watching

[http://www.gresham.ac.uk/lectures-and-events/the-art-of- rhet...](http://www.gresham.ac.uk/lectures-and-events/the-art-of-rhetoric)</comment>


Using technology to address gender bias in film - <AUTHOR> https://www.google.com/about/main/gender-equality-films/ <comment><USER2> The graph often shown about the gender breakdown of Computer Science vs. other studies is misleading - the reality is that the percentega was unusually high in the 80s, and now it's converging to the gender ratio of engineering.

[http://www.randalolson.com/2014/06/14/percentage-of- bachelor...](http://www.randalolson.com/2014/06/14/percentage-of-bachelors- degrees-conferred-to-women-by-major-1970-2012/)

In fact, as another article by the same author shows, this concern is probably overblown, if not outright irrelevant - women are _heavily_ overrepresented in _many_ college degrees, but noone cares. Sexism?

[http://www.randalolson.com/2014/06/15/the-double-edged- sword...](http://www.randalolson.com/2014/06/15/the-double-edged-sword-of- gender-equality/)</comment>


Game Of Life in one line of APL, step by step - <AUTHOR> https://www.youtube.com/watch?v=a9xAKttWgP4

<comment><USER2> An old friend ...

Most submissions have little or no comments - I've marked those that have more than just one or two ...

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

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

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

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

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

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

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

[https://news.ycombinator.com/item?id=2547655](https://news.ycombinator.com/item?id=2547655) : 22 comments

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

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

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

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

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

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

[https://news.ycombinator.com/item?id=451923](https://news.ycombinator.com/item?id=451923) : 31 comments

[https://news.ycombinator.com/item?id=204042](https://news.ycombinator.com/item?id=204042) : A few comments</comment>


Ask YC: Alternatives to 3rd Party Processing? - <AUTHOR>

My startup is kind of stalled at the moment, while I try and work out a solution to the 3rd party payments problem.
My business provides (or will provide) a payment solution in a niche market, mostly the domestic service industry, cutting costs for the vendor and providing better service and more convenience for the customer, whereas Paypal lets their users request payment against an email address, I let my users raise the invoice against a street address.
However banks see this kind of thing as "3rd party payments", taking money to give to someone else, and won't touch it with a barge pole. Paypal have a similar sucking air through the teeth reaction, they're all scared of fraud.
I'm looking for solutions, and I have two in mind at the moment, one would work, but might negate the need for the business in the not too long term, the other might not even work in getting the banks to grant me a merchant account.
So, the first option is to use Paypal, and require the vendor to have a Paypal account, and have the customer make payments direct to the vendor, I know there are several billing applications around that let people raise invoices, but they require the vendor to have their own method of collecting payments, whereas I want to provide that for my customers as well.
The problem, as the various bank reps have explained to me, is that the people making payments are not buying anything from me, and that raises issues with fraud. So I was wondering if having the customers purchase "tokens" from me, and spending them on the services from various vendors. I'm not sure if this will be enough for the banks though.
Are there any other alternatives to being a 3rd party processing application? Any that I've missed? <comment><USER2> Hi Stubbs, I might have a solution to this, but would prefer to discuss over email... if you don't mind contacting me, <http://mikal.org/contact/>

</comment><comment><USER3> The tokens sound like a good option. There are plenty of cases where similar systems are used. The token could just as easily be a custom-valued gift card or the like.

</comment><comment><USER4> Stubbs -- ever figure out a good solution?</comment>


Shell Scripts Matter - <AUTHOR> https://dev.to/thiht/shell-scripts-matter <comment><USER2> Now that I know there's a unit testing framework for shell scripts I wonder how I never thought to look for one. Huh.

And this from someone who unit tests his editor configuration!</comment>


Homebrew 1.5.0 - <AUTHOR> https://brew.sh/2018/01/19/homebrew-1.5.0/ <comment><USER2> I'm always so confused by the nomenclature in homebrew. Even beyond all the beer terminology, I'm still not sure what the difference between update and upgrade is. The docs simply defines upgrade in terms of itself: "Upgrade everything with: brew upgrade". Does "everything" include homebrew itself (which is what homebrew update is supposed to do) ? If so are the commands redundant? It just seems like an example of a great tool overall that has all these unnecessary complications.

<comment><USER3> > I'm always so confused by the nomenclature in homebrew. Even beyond all the > beer terminology

It is even worse if you aren't a native english speaker. English beer brewing terminology is not part of most language curricula! I enjoy a bit of whimsy as much as the next person, but some precision terminology would suit the toolset better.

It also incenses my French colleague who insists that wine technology is superior to beer technology.

<comment><USER4> Ugh, yes. Agree.

Taps? Casks? Kegs? None of these terms map well to anything. It's like if git used a car analogy and called repos "wheels", commits "blinkers", and branches "exhaust pipes".

Maybe it makes sense to people who brew beer, but I doubt it. It's just cutesy for cutesy's sake, and too many projects do this.

<comment><USER5> As someone who used to brew beer, and probably drank too much, I can definitively say it doesn't map well period.

I posit the reuse of nouns from apt would have greatly reduced confusion.

</comment></comment></comment></comment><comment><USER6> The brew postgresql-upgrade-database command is a fantastic idea. It's not a huge deal to upgrade by hand, but enough of a hassle that I tend to fall behind.

<comment> house9-2 I have gone back and forth between using a homebrew postgres and postgres.app over the years - a few months back I returned to postgres.app and am really liking it, the best part is you can switch between multiple versions of postgres fairly easily (click a button update a symlink).

Everytime I need to install an older version of postgres with homebrew it is a no go.

\- [https://postgresapp.com/](https://postgresapp.com/)

</comment></comment><comment><USER7> Has anyone tried to use nix package manager and nix-darwin ([https://github.com/LnL7/nix-darwin](https://github.com/LnL7/nix-darwin)) instead of brew?

I am curious if there is any upside to using it over the hard work brew team is doing.

<comment><USER8> I try it every few months because I _really_ want it to work locally. Nix itself works pretty well, and most of the packages work well, but there's just enough brokenness in important utilities to keep me going back to brew for now.

It's certainly possible to mix them, and use nix for most things with brew as a crutch until nix packages get better, but I already have the App Store, stack, cargo, pip, gem, and npm trying to manage packages on my system, and I really don't want to add a brew replacement until it can be a complete replacement.

<comment><USER9> We have a stable channel for darwin now ([https://nixos.org/channels/nixpkgs-17.09-darwin](https://nixos.org/channels/nixpkgs-17.09-darwin)) if you don't want the very latest versions of packages.

<comment><USER8> Thanks, I'll check that out this weekend.

</comment></comment></comment></comment><comment><USER10> Great work as always, maintening a full packaging system is no easy task, but can you even inverse a binary tree bro'?

<comment><AUTHOR> Worth noting that was the creator of Homebrew rather than the post author/a current maintainer (I say this as I don't want to take any credit for creating something I didn't).

</comment></comment><comment><USER11> > We will maintain python2, python3 and python@3 aliases.

Is the python3 alias likely to be present indefinitely?

I work with beginners a lot, so I look for a simple installation with as few steps as possible. I like that someone who hasn't set up their mac for development can run 'brew install python3', and then use the python3 command to work with the latest version. They don't have to modify their PATH to get started, and as long as they use python3 to run programs and configure a text editor, they don't have to think much about the difference between their Python 3 installation and the system Python.

I understand that 'brew install python' will now install Python 3, which is great. But that does mean you have to modify your PATH to have the python command use the homebrew-installed Python 3 interpreter, right?

Is it reasonable to continue to recommend that beginners use the 'brew install python3' command?

<comment><AUTHOR> > Is it reasonable to continue to recommend that beginners use the 'brew > install python3' command?

Yes. I cannot promise it'll be around forever (as I can't promise anything forever) but it remains reasonable to recommend that to beginners.

<comment><USER11> Thanks, that's really helpful. And thank you as well for providing something that's helpful to professionals and beginners alike!

</comment></comment></comment><comment><USER12> Homebrew is great, only thing that bugs me is auto update executed before each command, kind of slows down user experience.

upd: to disable auto update

        export HOMEBREW_NO_AUTO_UPDATE=1

<comment><AUTHOR> Thanks! Consider setting HOMEBREW_AUTO_UPDATE_SECS to a high number instead. For example I set

      export HOMEBREW_AUTO_UPDATE_SECS=3600

In case you're wondering the reason we have auto-update on by default is because before we did literally ~50% of our issues were solved with a `brew update`.

<comment><USER13> My biggest frustration with the auto-update is how long it takes. I wouldn't mind the auto-update in the slightest if it took 5s instead of 30s. It's ironic (and a testament to your work on bottling) that the longest phase of installing a formula, even one with many deps, is waiting for `brew update` to complete.

I'm curious if you have plans to make `brew update` faster. Is it really just `git pull` that's that slow?

Apologies for griping. Homebrew has made my life much, much better—thanks for all your hard work!

<comment><AUTHOR> We've tried and got `brew update` pretty much as fast as we can (at least for the no-op case). I literally added a new GitHub API to make this faster: [https://developer.github.com/changes/2016-02-24-commit- refer...](https://developer.github.com/changes/2016-02-24-commit-reference- sha-api/)

Would definitely welcome any help making this faster, though!

> Apologies for griping. Homebrew has made my life much, much better—thanks > for all your hard work!

I wanted to particularly highlight this part of your comment: stuff like this is really kind, not common and really helps with my motivation to work on Homebrew. Thank you too!

<comment><USER14> > I wanted to particularly highlight this part of your comment: stuff like > this is really kind, not common and really helps with my motivation to work > on Homebrew. Thank you too!

I'd love to chime in while we're at it. Thanks Mike, for your awesome work on Homebrew. My life is significantly better because of it. I remember back in the 2000s how I would literally spend hours at times figuring how to fix compilation errors, Googling for undocumented CFLAGS, etc. Homebrew is such a pleasure to work with, and it feels like it just keeps getting better. I have no idea how, but it does.

Less time spent tinkering with build flags means I get my work done faster, which means less time working and more time with my family. You rock.

UPDATE: Just set up a $10/month contribution to you folks on Patreon. Here's the link for anyone else who's interested in contributing: [https://www.patreon.com/homebrew](https://www.patreon.com/homebrew)

</comment></comment></comment></comment></comment><comment><USER15> "On 1st March 2018 the python formula will be upgraded to Python 3.x and a python@2 formula will be added for installing Python 2.7"

As someone who really likes Python 3, this makes me really happy

</comment><comment><USER16> I love my MBPro. With Homebrew, I love it 10X more. Thank you so much for all your hard work on this.

</comment><comment><USER17> > brew postgresql-upgrade-database

Oh man. That is frigging awesome. This is going to save so many people so much time. Where's the tip jar?

<comment><USER18> > Where's the tip jar?

here: [https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e9...](https://github.com/Homebrew/brew/pull/3568/files#diff-04c6e90faac2675aa89e2176d2eec7d8R63)

<comment><USER17> Thanks!

</comment></comment></comment><comment><USER19> As a PHP developer, merging the PHP repository into core will be disastrous for me. I have 27 packages installed for PHP 5.5 - 7.2, and the versioned extensions will evaporate. So much of my tooling is built around homebrew and the `homebrew/php` tap, that my entire toolchain for development will change.

The last time, Apache was switched from installing/running at the system level to user-based. That broke almost everything on my system for a day while I tried to fix it. Worse, there wasn't a warning prompt before the package upgraded.

I don't have time for things to break down every 6-12 months.

<comment><AUTHOR> Any formula that gets removed you can continue to maintain in your own tap (third-party GitHub repository, [https://docs.brew.sh/How-to-Create-and- Maintain-a-Tap.html](https://docs.brew.sh/How-to-Create-and-Maintain-a- Tap.html)). [https://github.com/Homebrew/homebrew- php/issues/4721](https://github.com/Homebrew/homebrew-php/issues/4721) explains what needs to be done. If you want to avoid your workflow being disrupted: chip in and help; we're giving you plenty of warning.

<comment><USER19> I understand that. However, if I had time to contribute to homebrew, I would have by now. I definitely do not have the time to maintain a tap and keep its packages up to date.

I'm glad y'all gave enough warning, but that doesn't make me any less frustrated by the decision.

<comment><AUTHOR> Sure, I understand your frustration. Similarly I hope you can see that it's frustrating for us when we make it very easy for people to help themselves and they don't try to do so because they are too busy. You have a job, we have jobs and most of Homebrew's work happens outside people's jobs.

</comment></comment></comment></comment><comment><USER20> If I could make one request, it would be that Python formulas get a "python-" prefix, PHP formulas get a "php-" prefix, and so on.

There are still some things I don't love about Homebrew but there is quite a lot that I do love. Thank you for continuing to build great software and maintain a high standard for packaging. The binary "bottles" are especially appreciated.

<comment><AUTHOR> We're unlikely to do that because end-users shouldn't care what language a tool is written in in order to install it.

<comment><USER20> I'm not talking about CLI tools. I'm talking about Python _libraries_ , like Pandas and Numpy.

<comment><USER21> Homebrew really shouldn't ship libraries in the first place, for that we have our own language's package management (and for cases where we have difficult to install binary dependencies, we have our own language's mechanism for dealing with them).

<comment><USER22> Language package managers are for developers. End users should use their platform's package manager to install whatever libraries their application needs. E.g. Apt knows what version of numpy easypaint works with, while pip simply gives you the most recent.

</comment></comment></comment></comment></comment><comment><USER23> It's slightly unclear to me what will happen for the php formula's, we have several people working very happily with it, easy to switch between major versions and include extensions.

> By 31st March 2018 we will deprecate and archive the Homebrew/php tap. > Unfortunately we have been unable to maintain an acceptable, consistent user > or contributor experience and CI workload through non-core formula taps in > the Homebrew organisation so we are continuing to migrate widely used > formulae into Homebrew/core and encourage more niche formulae and options to > be supported outside the Homebrew organisation.

<comment><AUTHOR> [https://github.com/Homebrew/homebrew- php/issues/4721](https://github.com/Homebrew/homebrew-php/issues/4721) provides more detail. If you want to avoid your workflow being disrupted: chip in and help; we're giving you plenty of warning.

</comment></comment><comment><USER24> Thanks for all the hard work.

</comment><comment><USER25> Congratulations to the authors and contributors of Homebrew. Ironically enough, it is one of the most sane Unix package managers, IMO.

</comment><comment><USER26> One thing that I don't know if it's possible with homebrew is installing previous versions of packages. For instance, _brew install python3_ installs python 3.6. How can I install python3.5?

<comment><AUTHOR> We support multiple versions with `email@example.com` packages but we don't support it for many packages or many versions. It's easy to create an maintain these yourself, though: [https://docs.brew.sh/How-to-Create-and-Maintain-a- Tap.html](https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap.html)

</comment></comment><comment><USER27> I know it's been deprecated, but can I still `brew linkapps` in 1.5.0?

<comment><AUTHOR> Yes.</comment></comment>