My 20-Year Experience of Software Development Methodologies - <AUTHOR> https://zwischenzugs.wordpress.com/2017/10/15/my-20-year-experience-of-software-development-methodologies/ <comment><USER2> There is an insider story about how these methodologies comes about. So there are few groups of people whose sole job is to do consulting on failed/late/over budget projects. Mind you, they _don 't_ write code but rather they observe how things are going and then prescribe process/management improvements (McKinsey style). Once in a while, these folks bump in to terrible projects and whatever they prescribed sometime works like a charm. In that case, they take that prescription on road and advertise the hell out in conferences, magazines, blog posts. Unlike regular developers, they have all the time in the world to do these activities. They write books and give interviews and by the media power of distributing information suddenly they pop out as process gods who knows how to fix any project. Eventually the new things starts to fad, people realize what works in project X didn't worked in Y, speaker engagements starts drying out and then these folks need new thing to repeat the cycle.

The obvious problem is that these folks prescribing the development process are not active developers. They are not even part of any real project over any long duration. They are in job of inventing and selling processes and handing out management advice as consultants. Whatever they prescribe, might have worked only in specific context and for specific symptoms, usually with huge dose of luck. Next time when you see new process fad, look up the history of originator of this process, what company he is part of, how much code has he written, how he makes money. You will know what I'm talking about.

<comment><USER3> This is not true for agile. The agile manifesto was in fact drafted by software developers. Also, agile doesn't prescribe any process at all, in fact, it does the opposite. Agile in essence is quite beautiful, unfortunately it gets twisted and turned upside down until it's just another methodology (which is exactly the opposite of its original meaning).

<comment><USER4> I actually like vanilla Scrum and think often you need a formalized methodology for the team to follow. I've worked with a lot of different teams and there are a few things I've noticed being pretty common among developers (or sometimes being guilty of myself).

1\. Not working on what you are supposed to be working on. Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. Something it is good and sometimes it just takes time or adds regressions you did not need at the time.

2\. Senior developers owning a piece of the code base. Often grabbing a huge chunk of work for themselves on it and then you don't hear from them for a while when they hack away. Sometimes they do good work and sometimes not and if they are sick or away and no one knows how their code works.

3\. Junior (or some senior) developers being stuck for a long while without asking for help.

4\. Ignoring the customer and building what you think should be built.

None of those are automatically fixed with Scrum and I know some here will just say "Yeah, we have a professional team that actually talks with each other and does code reviews" so they don't need it. And I get that but for a lot of those small teams building some CRUD application at a large enterprise the formalized communication ways are a god send in my experience.

<comment><USER5> I agree with you that a formalized methodology is required for you to start with agile, be it XP, Scrum, Kanban or whatever the flavor the team itself feels more comfortable doing.

What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto.

Like always, it's a strange whisper game...

<comment><USER6> Adjusting the process literally _is_ part of Scrum. At the retrospective, if something isn't working, you call it out and change it. That can be something as big as completely changing the methodology. I've never worked on a XP team but my understanding is formally there is no retrospective process - I would definitely want to put one in place if I did work with it.

Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.

<comment><USER7> Except at most companies that use Scrum, there are very rigid rules sent down from above regarding the implementation of Scrum. These rules apply to the whole company and can't be questioned or changed via retros.

<comment><USER8> This is definitely the case for me. I work at a reasonably large (~5-7000 total employees) company that had a top-down Agile Mandate imposed about a year ago. It's worked reasonably well, honestly, but there was a lot of chafing initially, and there's still some resistance. Problems with the process are occasionally solved by abandoning it entirely, with mixed results.

<comment><USER9> The thing to be careful of is that a lot of developers also don't like certain parts of agile, and those don't get used. They may have a preference to continue to use long cycle approaches (code reviews) where a shorter cycle approach is now necessary (pair programming). The end result is they pick and choose the bits they want and end up failing to ever do the process even once, not because its impossible but because it isn't their preference. They didn't do it out of knowledge, infact they failed to see the interplay in the processes working together and how the entire thing feeds together to produce the whole.

I think most teams drop agile practices before they have knowledge to show they aren't appropriate, they usually never get used at all. They adopt what they have to because they don't really want to do it at all because they consider a large chunk of it doesn't work.

Changing the process from a position of knowledge and experience on it is one thing, doing it without that knowledge is the more usual thing and its harmful.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Really liked this article.

I liken software methodologies to cooking recipes.

On one end of the scale you have a highly skilled and experienced chef, who can craft a great (requested) dish with a variety of ingredients and equipment. Knowing how to adapt and what to add and when. This works well, but requires a heavy cost (experience) and is, from the outside, difficult to follow and control.

On the other end of the scale you have fast food. A strict process and fixed ingredients that 'just works'. Those involved in cooking have very little knowledge of why, and are almost certainly not able to adapt. This works well for scenarios where you exactly know and control both the input and output.

A skilled chef can 'codify' their recipes, but this results in a specific description of what to do, and not why. Thus marginalising the adaptability.

In my experience, most software engineers are trying to attain the skilled chef role. While most _managers_ want the fast-food style predictability. With the 'process' being the battleground.

The best process is where you - a complete multi-disciplinary team - make as quick iterations as possible, learning as you go. But, always knowing where you are trying to get to (and why!) and constantly adjusting accordingly.

Good luck out there.

</comment><comment><USER11> Methodologies are a trap. The problem with any methodology is they tend to lead people to stop thinking about the context they are operating in.

"The methodology says X, we should do X, why oh why aren't we doing X?" is a familiar lament in the development world. I have been there and done that, to be sure.

It really isn't going to matter what the Methodology says, if something or someone in the context means it isn't being adhered to.

If the person ultimately paying for the project isn't convinced by the Methodology, or wants to deviate from it badly enough, guess what? The Methodology will be ignored.

You should always advocate for what the Right Thing To Do(tm) is, but you should ask yourself first: what is the most important criteria that determines what the Right Thing is?

 _Sometimes_ writing the quickest, hackiest, throwaway code can be the Right Thing. It can be a horrifying truth for a software developer. Sometimes doing the ballsy re-write is the Right Thing. Sometimes letting a project fail is the Right Thing.

Sometimes last weeks context and decisions no longer apply.

More critical to project (and personal) success than any Methodology is gaining a thorough understanding of the context in which you are working in, as quickly as you can. And then doing all the Right Things that will make you effective within those constraints.

This means there is no Single Truth for software development. No easy answers. But there are a wide variety of principles you can draw from and apply and _discard_ as needed.

Or as Bruce Lee put it: Be like water.

<comment><USER12> What's worked best for me is basically 'agile' but without a lot of what I consider to be the bullshit. Project manager and/or team lead prioritize new cards as they come in, and developers just keep working on them. No sprints, just keep pulling work out of the backlog as needed. Stand ups and most meetings can be replaced with quick updates via Slack, otherwise they can be organized as needed (they usually aren't). We had agreed that estimation was mostly a pointless waste of time, so we stopped doing it.

<comment><USER3> This could work, but it relies on highly competent autonomous team members who trust eachother. Often not the case.

<comment><USER12> It _should_ be the case though. Competent, autonomous, and trustworthy is a pretty low bar.

</comment></comment></comment></comment><comment><USER13> I've worked in a variety of environments, and the most important thing in my experience is simply to ensure that your team is creating a working, tested, and "shippable" update every ~2 weeks. It amazes me how many teams fail to do this, despite calling themselves "agile" and "customer driven".

Use whatever methodology, technology, and processes you need to accomplish that singular task. Orient your entire organisation around doing that. Your customers don't care how you do it. They just want frequent updates and progress. And if you're not giving them useful updates (you'll know, they'll tell you) then the problem isn't methodology, it's probably your ideas. No methodology will fix that.

<comment><USER14> This only works in certain kinds of projects. I often work on projects where you need to spend months figuring out some technologies and see what works best. For a while we tried to deliver "shippable" updates every 3 weeks but this just created a lot of work creating artificial prototypes without any real benefit so we gave up.

If you work on some web site where the tech is well understood then shipping something every 2 weeks probably works.

<comment><USER15> > figuring out some technologies

That is research, not software development.

For software development you know your tools and how to use them, and only what the resulting product should be is slightly unknown.

<comment><USER14> I call myself a developer but I often work on stuff where at the start we don't know whether it will be desktop, web, mobile or whatever. We don't know which database will be best so we try a few. I guess it's research but it feeds straight into development which is done by the same people within the same project.

<comment><USER16> >" _We don 't know which database will be best so we try a few._"

There is but a handful of valid choices for a relational database, and all of them pretty much able to handle every single thing you can throw at it.

Or are you just trying out "flavors" of database? In which case you're wasting the client or employer's time/money, in all honesty.

<comment><USER14> I work in medical devices. We can store data directly on the device, on some other device, the cloud or our data center. All have their advantages and disadvantages regarding security, maintainability, battery consumption and a lot of others. There is no clear answer up front so you have to try a few approaches and see how they go.

</comment></comment></comment></comment></comment></comment><comment><USER17> Nice post! I worked in a few big and small companies, and from I can see software companies with more then ~40-50 devs don't scale well (I only talk about about single-ish product software companies here). The reason for this is in my opinion is absence of financial liability of devs: if you're a dev in a company with 500 other devs - most likely you have zero financial liability to produce great code, on other hand you have all time in the world to create job security code around you. Also if there is 500 devs on one project, most likely one will see a lot of infrastructure just to get this devs busy with something. This could be seen in companies were one department creates "the framework", and others departments create "features" based on this framework. In this case there is no "market" of frameworks - you basically stuck with it, and "the framework" has zero market competition. Compare it to normal market of middleware - if your framework is bad, I'll just go to your competitor. Free market is much healthier situation in my opinion (could be a strawman argument though). I am not wise enough to say that creating internal competition inside one company is always good thing, though financial contracts make a healthier political discussions.

<comment><USER18> I don't believe job security code really works. If they're in a place where they're not paying any attention to you committing awful code why would they care when developers tell them that only you can work on your code?

<comment><USER19> The job security comes when you write great code but awful designs and architectures. The resulting objections are more abstract and harder for project managers to really understand. Or they'll understand the objections but not know how to weight their severity.

<comment><USER18> They'll just ignore them and do what they please, is where I'm going with this.

<comment><USER17> Yes, but it's not as obvious as it sounds. For example let's say we have dev A and dev B and we give them same task. Dev A solves the task in such way that we don't need to come back to the solution at all, it "just works". While dev B solves it in such way that now we need 1+ devs maintaining a solution full time. Any solution that needs to be maintained full time is a form of job security. Sometimes it is needed (like placing a small team on devops), sometimes it is not (like in-house full time development of dashboard frameworks).

</comment></comment></comment></comment></comment><comment><USER20> I'm surprised that Don Reinertsen's book The Principles of Product Development Flow doesn't come up in these discussions. Rich Hickey mentioned it once after a conference years ago and that's the only time I've heard it mentioned. I've since found a few blog posts responding to conference talks (of which there are several on YouTube from around 2015), but not many. I think people simply don't know about it. I wrote it down at the time and finally digested it over the past several months. It's an incredible book that I think would resonate with many of the commenters here.

I think of Reinertsen's approach as industrial agile, in the most honorable sense of industrial. There is theory and some math. There is heavy emphasis on project economics as a means of making complex trade-offs and a basis for training, deputizing, and expecting employees at all levels of an organization to make better decisions on the fly as part of doing their jobs. Lessons are drawn from many fields, such as network communications, queueing theory, and the Marines. Contrasts are drawn with manufacturing to explain exactly why some of the techniques we adopt do not apply in product development but where many techniques from kanban systems do apply.

The book is organized around hundreds of principles given as tools, to be considered and applied as needed to your specific situation. Annoyingly, he refuses to get into implementation. At first I thought he was saving pages, but the more I think about I realize the seeming omission was necessary genius. Digging into even one example implementation would result in the death of the message and framework as people copied that and get dogmatic about a methodology all over again.

The whole presentation is beautifully constructed and _tight_. It puts a perspective and language on things in a way that makes me hopeful and interested in project management, similar to how Rich Hickey's talks raise my understanding, vocabulary, and aspirations for software engineering.

I would welcome anyone involved in prioritizing commercial software projects to read and discuss this book (and document their implementations).

</comment><comment><USER21> My 30 years of Software Development Methodology:

* The user is more important than any of this. * The programmer is nothing. * The computer is doing all the work.

Thus: use what makes all the above, True.

<comment><USER22> What does "the programmer is nothing" mean?

<comment><USER23> And "the computer does all the work"?

<comment><USER24> I'm guessing: The machine does what the user (client and org) expects effectively in a way that they easily understand.

</comment></comment></comment></comment><comment><USER25> The biggest skill when interacting with a "big serious man" type of client is to making him pay you for what you want him to pay you for.

In my circle, we have a lot of discussions on clients like that: "and I told him, for what freaking thing do you need that freaking neural network when a banal statistics does the job better?". Having such guy, "a Wharton grad with stellar track record at the big 4" agreeing on the former requires compromising his ego, self image, exploiting him wanting to not to look incompetent in eyes of his superiors.

In the end, all such guys are made to pay 6 or even 7 digit sums for a fancy UI over database querying tools and a stats package, and not a "big data, machine learning blah blah blah," or otherwise being given "the exact thing they wished for" that had no chance of even minimal functioning

<comment><USER26> But how will his company make it to 100M+ valuation if he can't claim it is being done with AI?

</comment></comment><comment><USER27> The fiction I like best right now is "continuous delivery": You release often, push to production several times per day, one working branch, always ready to deploy. Features being in development are behind flags. Regression tests help a lot, eg, when you make an update or fix a bug you make an automatic test that checks if the new thing works, or repeats the steps that caused the bug and makes sure it's no longer there.

</comment><comment><USER23> We use 'waterfall' (detailed, fleshed out specs in formal language) on the hardware, firmware & backend and 'agile' on the frontend (web/app). So far that served us well and it addresses the difference in developer skills _and_ needs as well. With the danger of generalizing; frontend people are different from backend people who are different from hardware people (in my experience), and this gives all what they enjoy working with.

<comment><USER28> Hardware (and firmware to a lesser degree) almost require waterfall. Moving fast and breaking things doesn't really work well when you have to throw away the physical product you broke as opposed to iterating it to a fixed state.

I can actually see the merit in waterfall for elements of the backend.. though how do you avoid pre-optimisation or even complete wastage building out APIs that end up never being needed?

</comment></comment><comment><AUTHOR> Author here: interested in any strong views on this - @ianmiell on twitter.

<comment><USER29> Me and my brother wrote our first commercial videogame in 1987 as a 16-17yo pair of self taught programmer/artist/designers. We just did what seemed like common sense.

\- We had periodic meetings with the client (publisher). we showed them progress and they suggested directions to move towards

\- We didn't stick religiously to the initial design, and adapted as we saw things work or not work to make the game fun

\- We stuck to the deadline and just cut what didn't make it

It felt quite agile to me.

<comment><USER24> That sounds like heaven. What was the game?

<comment><USER29> Erikbye is correct, Stardust for Topo Soft on the Sinclar Spectrum and Amstrad CPC 8-bit computers.

I attribute a lot of the merit to us being mentally organized, but mostly to our producer Javier Cano (RIP), who had that magic touch for ensuring that things around him just ran smooth, always with a smile and making it feel natural. My god he was amazing.

</comment></comment></comment></comment><comment><USER30> All these methodologies are there just to get things done. After many years involved in software development i have find out that it all comes down to leadership. Of course you need people with skills, but no good leader, no good product.

</comment><comment><USER31> I like the car analogy, and I had additions to it with software-components in mind:

engine-choices representing data storage: very big engines. for big ships. very small ones, for lawnmower. self-made ones, smoking.

gear-choices representing libraries: single gear gear from 1 to 1000. No neutral and no reverse.

chassis choices (language choice): rusty old ones, hard to work with, but lasts. new shiny ones, overpriced and falls apart.

locks = safety: one key fits all (all doors and all cars). different key for each lock, can be bypassed by opening window. keypad with password, written on the back-side of the car.

interior = user interface: millions of choices, all flashy and shiny, each part looks totally different. Unusable steering.

break (software stability): no breaks. when used causes blue-screen

outside (program output): all parts have different sizes. holes covered with duck-tape and rust covered with shiny paint.

Enjoy the ride!

</comment><comment><USER32> I really enjoyed reading this and I strongly agree there isn't an easy task at all. Depends on the business, people, existing processes, it's up to us to find what really works. I had some thoughts based on my recent experience and went into a mood to write something quite long on my LinkedIn [https://www.linkedin.com/pulse/waterfall-scrum-kanban- scumba...](https://www.linkedin.com/pulse/waterfall-scrum-kanban-scumban- whats-next-richard-shenghua-he) if anyone interested.

<comment><USER32> Sorry, had a typo in the previous link, please use this one [https://www.linkedin.com/pulse/waterfall-scrum-kanban- scrumb...](https://www.linkedin.com/pulse/waterfall-scrum-kanban-scrumban- whats-next-richard-shenghua-he/)

</comment></comment><comment><USER33> I've not found a methodology yet that can displace smart decisions.

Methodologies organize projects to help further smart decisions and avoid dumb ones, but smart decisions and skill still dictate the success or failure of projects.

In the end, the people are still more important than the methodology, but I've encountered a mentality a few times where people believed a good methodology will fix all.

I've seen companies keep changing methodologies looking for success with largely the same staff, and key decision makers, but yet the results are the same. Insanity, anyone?

</comment><comment><USER18> The style he describes as RAD is really enjoyable to work in. No constant scheduled meetings and unread documents; just use your common sense and write something.

</comment><comment><USER25> There are no need for formal methodologies. A person with no technical expertise should not be but on a position managing technical teams. That requirement divides the industry on "tech companies" and everybody else.

The example of a tech company with gigantic dev teams and very little number of MBA doctrinaires involved in development process is Intel.

Companies with external development clients that practice "we will agree on any methodology you want for right amount of money, but we would not let you anywhere close to our developers (who will be doing their own thing anyways)" are Tatas, Wipros, Luxofts and others. Their biggest asset is their skill at managing the client.

<comment><USER34> Ah and how would say produce a management system for a core part of a country's core data network (I was a team member developing a management system for the UK's SMDS network) with out a process? - In this case we used a hybrid waterfall /RAD system 12 weeks to develop the fist release

<comment><USER25> The very very few cases where anything called a methodology works is when you deal with a repeating tasks: making a customized versions of standard tools, or what people call copy&paste development. SAP does it very well. Charges people 7 digits for "customized solution" that in reality is not customized beyond 20 lines of code from what the company sells to every sixth or seventh client.

The goal there would be to not to dive too deep into the task that is already solved in a way that "works well enough," and for what the client is already ready to pay money for.

<comment><USER34> Not everyone always works on me to crud applications leaving aside SAP and other "miracle" tools :-)

</comment></comment></comment></comment><comment><USER35> I work for one of those fancy startups. Everything is chaos all the time, you have all these extremely smart people in the small doing actually kinda dumb things in the large. This worked better when the company was small and is causing more and more problems as we grow. Anyway, the point being that there's lots of smart individuals and little process.

I mentioned this during a meeting with my team, and so a process was devised for the next project we embarked upon. The process was waterfall, except nobody referred to it that way (most of the people are like 25, and weren't working back when it was the norm). Everything old is new again.

It wasn't important anyway; we didn't follow the process.</comment>


Scientists concerned that coronavirus is adapting to humans - <AUTHOR> https://www.theguardian.com/society/2020/may/10/scientists-concerned-that-coronavirus-is-adapting-to-humans <comment><AUTHOR> _The spike protein is the main target of leading vaccines around the world, and if it changes too much those vaccines may no longer work._</comment>


Tell HN: The Creepiness Factor – Why I Won't Apply for Analytics Jobs - <AUTHOR>

I don't want to be tracked.  It is for that reason that I blackhole analytics servers in my hosts file:

   127.0.0.1 www.google-analytics.com
   127.0.0.1 www.hosted-pixel.com
 Now I am very public on the Internet.  What I object to is anyone at all being tracked.  If you visit a website that sells strawberry jam, why should the prioprietors of that site even be permitted to know you were, say, a gay Muslim male?
On Thursday I went to a job fair in Portland, however I did not approach all of the booths.  One that I did not was Rentrak, because it promised a product that identifies "how they vote".  Neither did I approach Webtrends because they "invented analytics". <comment><USER2> I hear you, but I also see _some_ value in the products. I'd put it this way: I'm a 29 year old male, do I really want to see an ad for women's bras, Dora the Explorer, or Viagra pills? No. _If_ I'm going to be subjected to advertising all day, I'd much rather it be targeted and somewhat relevant to me.

That being said, there are certain times when my privacy is of upmost concern, and I use Tor when applicable.

In general though, I feel like any privacy on the internet is (at this point) an illusion at best, so (though it may be a cynical point of view) I assume no _more_ harm is done by further breaches of privacy. Maybe I'm wrong at that point, but I assume privacy is a Boolean, and once it's set to false, it's false for good...these companies might as well gobble up the data too.

<comment><AUTHOR> I hear what you're saying, in that there are some media that I read for the ads.

I'm not exactly concerned about my personal privacy, rather that of human privacy in general. I'd have a hard time explaining Tor to my Mom for example, despite that she is quite diligent about shredding paper documents.

</comment></comment><comment><USER3> Here is few more lists you can use;

www.malwaredomainlist.com/hostslist/hosts.txt

[http://winhelp2002.mvps.org/hosts.txt](http://winhelp2002.mvps.org/hosts.txt)</comment>


The Power of Nice - <AUTHOR> http://stevekrenzel.com/the-power-of-nice

<comment><USER2> A slight spin on this concept: if you're in line watching someone get harassed by assholes, be extra nice when it's your turn. It's an opportunity. In Vegas at Black Hat a few years back, I watched 3 or 4 consecutive parties harass the person at the check-out counter. My turn, all I said was "wow, rough day huh?" I got upgraded to a suite.

<comment><USER3> Exactly. Airline workers especially are quick to acknowledge a kind word. Their jobs are hell at times, and when someone offers some kindness, it is often returned in forms of vouchers and bump-ups.

<comment><USER4> "Their jobs are hell at times"

Their jobs can be hell. The last time I flew, I got stuck in a airport both ways because of weather trouble. Unfortunately thousands of other people were stuck with me. The line to just talk to a flight attendant literally took about 11 hours to get through.

I was on a break at the time, so the experience wasn't horrible for me personally, but it must have been a nightmare for the flight attendants. They had staff not show up for work. So basically overworked staff had to politely deal with thousands of angry and tired passengers.

</comment></comment></comment><comment><USER5> The way people treat others they don't have an immediate incentive to be nice to speaks volumes about them. If somebody is rude or manipulative to waitstaff on a date, for example, you _know_ that's going to come out later in the relationship.

When somebody is acting nice for purely selfish reasons, it tends to be quite inconsistent.

<comment><USER6> One of the best pieces of advice my mother gave me was 'date the waiter' -- because when you're on a date, the girl you're with is going to pay attention to how you treat the staff, because that's how you'll treat her.

</comment></comment><comment><USER4> The idea that cursing customer service representives is helpful is really wrong.

In most cases they have done nothing to cause your problem. Sure, they might not be able to help. But if that is the case, just move on and try contacting someone else. Cursing them out will do nothing, and just guarantee that they probably won't do anything extra for you. You might as well be nice.</comment>


Show HN: Easy to use webpage backup for sharing/offline use - <AUTHOR> https://github.com/victorbjelkholm/ipfscrape <comment><USER2> Wonderful. However, I'd appreciate it being written in Python or a similar language so that it could be used cross-platform, on Windows for example. Useful tool none the less.

<comment><AUTHOR> Good point and totally fair. My initial idea was to write in in Go and compile cross-platform binaries but the time limitation made me go for the simple way. I'll probably re-write it in Go in the future.

Thanks for the feedback!</comment></comment>


Things to Know About the Biggest Chip Ever Built - <AUTHOR> https://spectrum.ieee.org/tech-talk/semiconductors/processors/4-things-to-know-about-the-biggest-chip-ever-built <comment><USER2> If it is efficient, it must produce an enormous heat. Constantly, over a long time (like hours and days). How do they cool it?</comment>


Pioneer: Finding the next Einstein - <AUTHOR> https://pioneer.app/leaderboard#global <comment><USER2> hey it looks like you're #1 on the leaderboard - what are you working on? Must be interesting.</comment>


Ask HN: What's a reliable non-Twitter news source for web development? - <AUTHOR> Besides HN, I've received most of my web dev news from following Addy Osmani on Twitter.
Addy is a really good source of web dev news as he posts (and retweets) a lot of relevant web dev content such as new JS features, new CSS properties, PWA, react, webpack, and more.
Since I plan to quit Twitter, due to reasons irrelevant to post here, I'm curious to see if there's a reliable blog (to RSS) which posts about latest web dev content. <comment><USER2> [https://gitconnected.com](https://gitconnected.com) is great for finding trending articles, participating in discussions, and meeting other developers.

<comment><USER3> I've been using gitconnected for a week or more, and I've been enjoying it. Check it out.

</comment></comment><comment><USER4> Ponyfoo ([https://ponyfoo.com/](https://ponyfoo.com/)) is my go-to. I subscribe to their mailing list and I feel I get consistent, high quality news, even if a few days old.

</comment><comment><USER5> [https://frontendfront.com](https://frontendfront.com) Is pretty good. As the name suggests, it's mostly front-end stuff. They have a weekly email they send out too.

</comment><comment><USER6> I've enjoyed JavaScript Weekly for a while now. [http://javascriptweekly.com/](http://javascriptweekly.com/)

<comment><USER7> We also do [https://frontendfoc.us/](https://frontendfoc.us/) which covers more of the browser technology side of things.

</comment></comment><comment><USER8> Smashing Magazine is pretty good:

[https://www.smashingmagazine.com/](https://www.smashingmagazine.com/)

As is CSS Tricks if you're after info on new CSS properties and what not:

[https://css-tricks.com/](https://css-tricks.com/)

</comment><comment><USER9> Twitter quit me, and I'm forever great full.

(But sorry, that doesn't answer the question.)

<comment><USER10> I can't tell if there's a play on words here that I'm missing or...

<comment><USER9> I got suspended from Twitter for an account that was using aggressive advertising, long story... But I no longer had a twitter account. It was a lot like when I quit smoking, after a day I was wow there is life after smoking and I feel better. That's the same feeling I have with twitter, facebook... etc. I was just encouraging you to quit twitter.

;)</comment></comment></comment>


Slack Security Incident - <AUTHOR> https://keybase.io/blog/slack-incident <comment><USER3> Let's ignore the rather awkward self promotion, and the fact that 2FA would have prevented this specific incident.

This is the important part, which everyone should think about:

> What would have been way worse — immeasurably worse — is if our team had > used Slack for anything other than what we did use it for, which was > discussing outages of our own product. Had my cofounder and I discussed our > company's cap table, or business partnerships, or compensation agreements, > or ongoing legal matters over Slack; or had our team traded API keys, or > security-sensitive matters; or had we controlled mission-critical > infrastructure via Slack-powered "bots"; we'd be sweating bullets to this > day that our important company secrets were out in the open, about to > resurface at the worst possible time.

I see Slack being used for everything at a lot of companies.

There are a lot of interesting things in the chat history everywhere: SSH/API keys, logins and passwords, sensitive internal documents, chatops bots that would let one take control of the infrastructure, and worst of all - <USER2> office affair gossip.

Combine this with often lax user management (forgetting to disable old accounts, inviting people to channels they shouldn't be in, ...).

Most companies overlook this and don't even have a policy for what's OK to post on Slack, and what isn't. Not even to dream of any kind of enforcement.

I'ts a big security problem, even without Slack getting compromised, and should be on the radar for CTOs.

<comment><USER4> Slack has some options to delete all messages over N days old. Unless there is a really good reason not to, turning on this feature generally sounds like a good idea. At least you can drastically limit the length of the archive available to any attacker.

<comment><USER5> That's a _terrible_ feature in an instant messenger client for work use? I cannot recall the precise details of my conversations with smart people who know things I do not. I can recall that I had the conversation and remind myself what I learned before.

<comment><USER6> Depends entirely on the conversation obviously, but perhaps important details should eventually be coalesced and moved to a more permanent document or project management system before the deletion deadline. It's a good discipline to have.

</comment></comment></comment></comment><comment><USER7> The author would have done well by refraining from using this as an opportunity to make a sales pitch for their startup, as it detracts from an otherwise important message.

Let me see if I have this right:

Slack had a major security breach in 2015. Apparently someone installed malicious code that could even read password inputs in plaintext. They waited 4 years, after growing large and going public, to inform affected users. And in the interim they blamed their users for any related security problems.

Do I have this correct? If so, how is anyone going to defend this situation? And how can anyone put any sensitive data on Slack, or tell their company to do so, and feel good about it now?

I expected some stupid apology note from the CEO on their website if this turns into a bigger issue, which is sort of an anti-pattern at this point...

<comment><USER8> Would shareholders have a case to make for fraud here? Slack clearly didn't want this information getting out pre-IPO, as a security disclosure in this case would certainly impact public confidence in the company.

<comment><USER9> Every tech IPO filing has a generic statement saying something like "our software may contain bugs, including bugs that we cannot fix blah blah blah." So unless Slack has made fraudulent statements about this specific breach, I doubt they've done anything illegal WRT securities fraud.

<comment><USER10> I'm sure shareholders will sue, because they try to turn everything into a violation of securities law. But securities law shouldn't be the only way to regulate companies imo

</comment></comment></comment></comment><comment><USER11> What makes this even more sad is the extreme difficulty you'll have if you attempt to remove your company data off of the Slack platform. (Disclaimer: I stopped using Slack 2 years ago)

Our company used Slack extensively for multiple years. A couple years ago, we decided to stop using Slack for official company communication. After switching to alternative communication tools, we tried to delete the data in our Slack account and found it to be nearly impossible.

I recall using 3rd party python scripts (opensource on Github) that took hours to run - the script used an API key to fetch and delete messages individually.

We also tried using Slack's Admin panel to delete messages. At the time, I believe it required clicking a checkbox next to every chat message we wanted to delete. Clearly not a realistic way to scrub an account.

The sad reality is that with many services like Slack, once a provider has your data, there's often no easy way to remove it. IMO, this is a major downfall of our reliance on modern SaaS services (companies have no incentive to prioritize features for deleting account data - the only users who would find those features useful are already churned customers).

<comment><USER12> I don't understand this. They say that if you delete your workspace, all messages are gone.

[https://get.slack.help/hc/en- us/articles/204067366-Delete-a-...](https://get.slack.help/hc/en- us/articles/204067366-Delete-a-workspace)

<comment><USER13> It says they're "irretrievable", which isn't necessarily the same thing. That _you_ can't get that data back doesn't mean it's no longer stored by Slack in a way that a sufficiently severe compromise of their infrastructure might reveal.

<comment><USER12> I doubt they keep customer data after you're not a customer anymore. Sure, they could be lying but we don't have information pointing to that, do we?

They are subject (or have subjected themselves) to various security standards: [https://slack.com/intl/en-ie/security](https://slack.com/intl/en-ie/security)

And their security whitepaper [0] mentions:

 _Customer data is removed immediately upon deletion by the end user or upon expiration of message retention as configured by the customer administrator_

It would be a stretch to say a message is deleted permanently but a _workspace_ is kept forever, for unknown reasons. Occam's razor and stuff.

0 - [https://a.slack- edge.com/78b2/marketing/downloads/security/S...](https://a.slack- edge.com/78b2/marketing/downloads/security/Security_White_Paper_2019.pdf)

</comment></comment></comment></comment><comment><USER14> Wow - for a sales pitch fantastic. Many of these security issues leave you little to actually do. This write up provides an alternative.

What's super bad here is slack misleading about the cause wasting all the users time.

Quick question, anyone use key base - can u give a quick review? Team currently use slack

<comment><USER15> I use Keybase. I like it, the thing to keep in mind though is 99.9% of the time the biggest threat vector to your company is going to be preventing your employees from sexually harassing each other, not preventing the Russians or whoever from reading your internal messages.

<comment><USER16> _99.9% of the time the biggest threat vector to your company is going to be preventing your employees from sexually harassing each other, not preventing the Russians or whoever from reading your internal messages._

Yes, but:

1\. We always have to combine the likelihood and incidence rate of threats with the magnitude of damage. I do not personally subscribe to this thinking, but some bloodless financial types will suggest that you can compensate harassment victims, but a major security incident could cost you the entire company.

2\. Insert animated gif of a little girl asking, "Why not both?" Companies can and _must_ address threats like sexual harassment AND exfiltration of sensitive data.

</comment></comment></comment><comment><USER17> The post says "If the attackers inject server code, 2FA or U2F or any Web- based security practice does little." Understandably if the attacker was actively scraping passwords with 2FAs and was using the credentials immediately, that would be an issue.

However, for the issue mentioned in the post, wouldn't 2FA have saved him? Supposedly, the compromised credential is from 2015.

<comment><USER18> U2F saves you, most of the other options potentially make it worse.

If the bad guys are dumb and just were there to passively steal passwords then almost anything works. But if the bad guys are paying attention and stealing authentication secrets then it breaks down like this:

Passwords: Stolen if used while bad guys could watch

TOTP/MOTP/ similar software one time codes: Seed gets stolen by bad guys, they can generate the same codes as you now.

SecurID/ similar key fob type one time codes: Seed gets stolen by bad guys, they can generate the same codes as you now.

SMS: Now bad guys know your phone number. In a targeted attack they will "jack" the number and cause even more havoc, but you might be safe against script kiddies

U2F (or WebAuthn): The server doesn't know any secrets. It knows a cookie (meaningless gibberish except to one FIDO device) and a public key (public). Stealing these is futile and cannot be used to impersonate the user.

TOTP and SecurID surprise people because they forget that although the credential transmitted is just a one-time code, the _server_ (which bad guys broke into here) needs to know the same seed as the user does to get the same codes.

</comment></comment><comment><USER15> Not only does Keybase not automatically update its client, there is no way to even figure out if your client is out of date and in need of security updates. Even if you look up the exact version of your installed client, which you can find, there is nothing on the website that says what the most recent version is. The only way to even get a hint is to look on GitHub, and even that isn't accurate; version 4.2.1 is the latest release, but when I download the mac app it's still version 4.2.0.

For whatever problems Slack has, at least I know if there is a new version that I need to install.

<comment><USER19> You know what's better than installing slack? Not installing it and using it in the browser.

If there's a website option for any tool, I recommend using that over native. It's usually more performant and is less of a security risk. And it's always up to date.

<comment><USER20> > It's usually more performant and is less of a security risk.

Source, particularly for the "less of a security risk"? (It might well be now, I'm not an expert, but a few years ago I'd have thought "no way").

<comment><USER19> Which do you think is more potentially damaging?

1) Using a website which has had its server code compromised (slack).

2) Installing and using an application which has had its code compromised (maybe also slack).

The installed application is going to have more access and potential to damage your system and to compromise your data. There's not really anything more to it. One's in a browser sandbox and limited by browser capability, the other can do literally anything it wants.

<comment><USER20> Makes sense, thanks. I think my mental threat model was different:

you're talking about dodgy (potentially compromised) software: better run in the browser sandbox (albeit imperfect) than natively.

I was thinking of sensitive software (eg secret chats) I want to protect from attack: better run natively than in the (imperfect) browser sandbox.

In the context of this discussion (Slack), your threat model probably makes more sense.

</comment></comment></comment></comment></comment><comment><USER21> >By contrast, Keybase currently runs all of its mission critical chat applications over Keybase itself.

Reminds me of the time Amazon learned that using S3 to host status indicators for S3 is a bad idea if S3 goes down.

</comment><comment><USER22> > Were our Dutch friends sifting through our messages for four years before > Slack notified us of a suspicious login?

The author might know this already but the hackers aren't Dutch. They simply bought a cheap NL server from LeaseWeb to mask their real IP.

<comment><USER23> > bought a cheap NL server

.. or exploited/hacked a random cheap server to use to proxy their requests and have access to high speed 100Mbit/1Gbit downloads/uploads of Slack data.

</comment></comment><comment><USER24> slack in 2015: "We have no indication that the hackers were able to decrypt stored passwords, as Slack uses a one-way encryption technique called hashing."

slack in 2019: "In 2015, (...) The attackers also inserted code that allowed them to capture plaintext passwords as they were entered by users at the time. "

This reflects poorly on them. Unless they discovered only now that the 2015 hack included capturing plaintext passwords.

</comment><comment><USER25> Scary, and certainly doesn't reflect well on Slack. But, do keep in mind that the author runs a company that does compete with Slack in some ways.

<comment><USER26> I don't think that's relevant.

Poor security practices are poor security practices despite conflicts of interests, and Slack's are certainly _extremely_ poor.

<comment><USER27> From the blog posts slack has released we know nothing about their security practices.

They have a lot of high quality security features and you can see they actually work because they alerted Max that his account was compromised.

Saying their security practices are extremely poor based on an incident they had in 2015 when their company was 1/20th the size it is today is ridiculous

</comment></comment></comment><comment><USER28> Encryption for a business chat app limits the potential users rather significantly, as I understand it. A number of sectors (like banking) have strict rules which require keeping a record of company communications. How does Keybase deal with this, or do they choose not to play in that market?

<comment><USER29> Well, the bank could still record from their end of the conversation, capturing the chat logs from the employee's terminal and shipping them somewhere.

</comment></comment><comment><USER30> That's a nice sales pitch! A little on the nose, but I think that's ok.

I think one issue keybase still had is it's minimal web presence that sounds to focus too little on what keybase can do for regular users. People need more explaining of the day to day benefits.

</comment><comment><USER31> I wonder if this affected companies like IBM... I know for a fact IBM uses slack to talk internally about client billing, meaning if IBM was compromised the attacker knows what most of IBM clients bought from IBM.

Same applies to a bunch of other companies...

</comment><comment><USER32> > Unlike Slack, it is free. And without ads.

How does Keybase make money?

<comment><USER33> It's supported by the foundation that maintains Stellar, a popular cryptocurrency

<comment><USER32> Thank goodness. I was worried it was something unsustainable.

</comment></comment></comment><comment><USER34> > Keybase messages are end-to-end encrypted, and only our users control their > decryption keys.

End-to-end encryption isn't just good for the users because the service can't access the messages and sell them, it's also good for the users as it provides good protection if the service gets hacked: message content can't leak unless the attackers can change client code.

</comment><comment><USER35> As people are discussing Keybase for teams and whatnot - could anyone comment on Keybase for individuals, families, etc?

My family are debating moving to Matrix (and away from iMessage). I had briefly debates Keybase due to some interesting features. Anyone have experience with Keybase for families and individuals?

<comment><USER36> Why move away from iMessage? It's end-to-end encrypted.

<comment><USER37> Either one of:

\- iOS only

or

\- an extremely-crypto/privacy-aware family who is concerned that although end-to-end encrypted, there is no out-of-band user-validated key exchange (e.g through a digit code or QR-Code) or prior validation (e.g per-key TOFU) of the other party's identity or update to their keys. Which means that theoretically Apple could insert a new key in the user's set (there is a key per user's device for perfect backward/forward secrecy†) anytime to MITM/intercept messages and you would not be able to monitor it††.

† This is obviously defeated by Messages in iCloud (which you can disable) but the iMessage protocol has this built in.

†† Of course if there was some feature like that, Apple could also make such a key hidden in some way because they also control the Messages app code.

</comment></comment></comment><comment><USER38> The second I read this, I immediately signed up to Keybase today and deleted my Slack account and switched to the Keybase chat system instead which I am setting up right now.

I am confident to say that this incident was the final nail in the coffin for me to abandon Slack. Choosing Keybase was a no brainer.

</comment><comment><USER39> From the slack post:

> In other words, if you're one of the approximately 99% who joined Slack > after March 2015 or changed your password since then, this announcement does > not apply to you.

Hackers compromising plaintext password would seem to apply to everyone using Slack, whether their account was compromised or not??

</comment><comment><USER40> I'm a little confused here. Isn't Keybase a slack replacement product? Why is the CEO of Keybase using Slack for any company communication instead of his own service? Am I missing something obvious here?

<comment><USER41> It's described in the article:

> what we did use it for, which was discussing outages of our own product

You can't use Keybase to communicate about why Keybase is down :)

</comment></comment><comment><USER42> Slack gates a lot of its exfiltration security features behind enterprise licensing. Expect to double your spend if you want to try to prevent sensitive data floating around in slack.

</comment><comment><USER43> Is there any indication why did this post drop from the front page?

</comment><comment><USER44> Does Keybase support chat message search yet? Otherwise claiming to support all important features of Slack is stretching the truth. I use search extensively at work.

<comment><USER45> Yes, it does

</comment></comment><comment><USER46> Yeah, this is basically marketing material.

</comment><comment><USER47> Does Keybase have any kind of revenue stream? I didn't see any mention of pricing on their website.

</comment><comment><USER48> this needs to go up on HN!

</comment><comment><USER49> So why was the Keybase CEO using Slack in the first place?

<comment><USER50> > We basically just use a #breaking channel in there in case we have Keybase > downtime.

The problem wasn't they were using Foo and Foo was compromised.

The problem was that he couldn't be 100% sure whether Foo was compromised or not (when asked, they claimed they weren't).

Now, if Foo is a "random-cheezburger-meme-generator" startup you just try out with a throw-away password, then you can probably assume that it's likely they have been hacked and they are lying to you.

That leaves one alternative scenario: _you_ have been hacked.

You'd expect that Slack (in 2019), while it's still possible they lie to you, has decent security practices and thus makes it less likely to be hacked and thus increasing the odds that you might indeed be hacked.

In a way, it acted as a honeypot. But one that you don't control so you can't be sure whether it caught a hacker or whether the bees are drunk.</comment></comment>


Cmus – A Small Terminal Music Player - <AUTHOR> https://cmus.github.io <comment><USER2> Oh wow, did not expect this here! I am the current maintainer (not the original author) of cmus, and can answer some questions, if they'll come up.

<comment><USER3> One thing I would love to see is a folder-based music view like you have artist/album views.

I don't tag my songs, I just organise them in folders about three levels deep. What I'd like to see is a folder tree of my music folder on the left and all the files in that folder, plus all subfolders recursively, on the right. The only player I remember getting this right was amarok (now clementine). I've never once in my life ever wanted my songs listed by album or artist. I have my file manager to organise my files and they're already organised. It's really silly to ask me to organise them again in a different way that doesn't really fit my organisational style.

<comment><USER4> Ditto - automatic organisation by metadata might be nice if metadata wasn't universally inconsistent and incomplete. I tried manually fixing my whole library and it was nice for a couple of weeks, but there's so much ongoing maintainence overhead that OS-level folders are the only thing I bother with any more :(

<comment><USER3> The metadata doesn't even reflect the way I think about music. And what do you do with movie OSTs, which are by ten different artists and some are songs from other albums? It's just madness.

<comment><USER5> I use beets for tagging, and it has no trouble with OSTs. It sets a different tag for Album artist and Track artist, and cmus uses the Album artist. Most soundtracks of the type you mention are under <Various Artists>.

I'm different from most people in that nearly all of my music collection is complete albums, so if that's not the case, then I could see how a file/folder layout would work better, and the artist/album view is more full-featured than the file-browser view.

[edit] Also as far as I can tell, there's no way to filter based off of path (only filename) which might also be a good way if you prefer directory based organization.

</comment></comment></comment></comment></comment><comment><USER6> It's kind of relevant here, but VLC can also run inside a terminal.

      vlc -I ncurses

<comment><USER7> Noticed it when installing it on openSUSE, but VLC wont install any codecs that get installed on Windows, not sure what the legal issue is with that but it might as well be a paperweight on my laptop as is. Maybe I'll give it a shot as a terminal music client. On another thought, does that mean VLC somehow displays video with ascii? hah

</comment></comment><comment><USER8> I used cmus for a while, but always wanted a user interface more similar to winamp, so I built namp [https://github.com/d99kris/namp](https://github.com/d99kris/namp)

<comment><USER9> Nice work there, that looks pretty good.

I do have one very minor suggestion though; you might want to change your README.md:

        > namp is a command line MP3 player for Linux

Technically it's a terminal player rather than command line.

<comment><USER8> Thanks for the feedback! Yes, I agree. Terminal, or console-based, player is a more correct description. Will update!

</comment></comment></comment><comment><USER10> Some time ago I did complete depart from Apple apps and services, while still using Mac. It was pain to extract all the images from Photos but music transition to cmus was smooth. I am mostly playing di.fm stations and cmus works well with subscription links. Sadly both cmus and mplayer on Mac rely on Carbon components so there is big console warning for using deprecated components and more importantly they can't be send to background. If somebody got them playing as background process please let me know.

<comment><USER2> About «backgrounding» — please see [https://github.com/cmus/cmus/wiki/detachable- cmus](https://github.com/cmus/cmus/wiki/detachable-cmus) .

Carbon components warning is because cmus currently uses libao for the sound output on OS X by default. If somebody will contribute a native OS X output plugin, it will be gone.

<comment><USER10> Thanks. I am most probably on exit route from anything Apple or Google so most likely next cmus will be playing on native Linux for me. Off topic but Apple increasingly makes it easier to make such decision.

</comment></comment></comment><comment><USER11> I've been using cmus for the past two months and absolutely love it! Its simplicity compared to many other ncurses-based applications is refreshing.

My only wish is that it was a bit more "vi-y". I'm sure someone has a way, though ;).

<comment><USER12> I use moc ( [http://moc.daper.net/](http://moc.daper.net/) ) but seeing the example command on the cmus homepage (:seek +1m) makes me want to test it.

<comment><USER13> I used cmus before I found moc on Crunchbang. The feel of moc was just right for me.

I wrote down how I use moc[1]. Hope someone might like it. Also I tried to make navigation feel like vim sometime back. The keymap[2] might have a few tips.

[1] [https://chanux.wordpress.com/2013/04/25/the-thinnest- music-i...](https://chanux.wordpress.com/2013/04/25/the-thinnest-music- interface/)

[2] [https://github.com/chanux/dotfiles/blob/master/moc/keymap](https://github.com/chanux/dotfiles/blob/master/moc/keymap)

<comment><USER14> Yeah, thanks for sharing. I am also a moc enthusiast. Your post inspired me to add key bindings for moc commands to my awesomewm's rc.lua.

Oh and since I have no use for the audioStop key I made it run a python script that displays the name of the current song via dbus.

</comment></comment></comment></comment><comment><USER15> My two cents: I used cmus before, but in the long term I still prefer mplayer.

I construct the playlists myself by using soft-links to the actual paths of the songs. Real files are placed in sensibly named directories.

It's a matter of taste of course. Still I really appreciate that people write this kind of software for the terminal!

<comment><USER16> Have you tried mpv?

</comment></comment><comment><USER17> cmus user here. Its the only music player on my machine, but I'm using it less and less every day (Google Play Music)

<comment><USER18> It looks like cmus can use streams. Have you tried GMusicProxy [http://gmusicproxy.net/](http://gmusicproxy.net/) ? I use it with mpd but it should work with cmus as well. It's nice not to be able to access google play music via a regular music player.

</comment></comment><comment><USER19> I've found this issue helpful in getting cmus working on OS X El Capitan: [https://github.com/cmus/cmus/issues/331](https://github.com/cmus/cmus/issues/331)

</comment><comment><USER20> I've used cmus a bit and really like it--the simplicity is great if you have a lot of albums. Graphical players always bog down, are slow to scroll, etc.

</comment><comment><USER21> Very nice, does it have a music visualiser ?

It would be sick if this could play videos via libcaca too..

<comment><USER22> For visualiser, you might like [https://github.com/karlstav/cava](https://github.com/karlstav/cava)

For libcaca, see mpv's or mplayer's "-vo caca" flag.

</comment></comment><comment><USER23> I also recommend mpd + ncmpcpp.

<comment><USER24> mpd + ncmpcpp is my favourite too. It's made my music so easy to access, while allowing me to organize it the way I like it - by directory.

</comment></comment><comment><USER25> cmus is great! Loads fast, low resource usage, and well, just works without any configuration unless you want custom settings and colors.

</comment><comment><USER26> cool. Unfortunately, I get all my music from spotify now. No more mp3s.

<comment><USER27> If you'd still like to use a terminal player you should check out mopidy: [https://www.mopidy.com](https://www.mopidy.com)

<comment><USER28> I'm curious... Is mopidy like mpd in that clients that connect are only able to edit the playlist? Or can they themselves play songs?

<comment><USER29> It's not just like mpd, it _is_ mpd + a HTTP server. Ergo you need to control it with a CLI or graphical mpd client or with a web client.

<comment><USER30> It is absolutely not MPD, it has a partial implementation of the MPD protocol.

</comment></comment></comment></comment></comment><comment><USER31> Any support for windows ?

<comment><USER20> It sounds like cygwin can compile and run it: [http://matthieukeller.com/2015/01/compiling-cmus-for- cygwin....](http://matthieukeller.com/2015/01/compiling-cmus-for-cygwin.html)

</comment></comment><comment><USER32> 10/10, fav music player

</comment><comment><USER33> God, I'm dyslexic....</comment>


Fix Your Timestep - Synchronizing game physics - <AUTHOR> http://gafferongames.com/game-physics/fix-your-timestep/

<comment><USER2> Nice explanation.

I wonder, though, how important it is to do the interpolation (see the last code sample). With the example value of dt = 0.01, failing to do the interpolation would mean that the displayed frame will be behind by an average of 1/200 sec. Would that really be noticeable?</comment>


How the Kernel Manages Your Memory (2009) - <AUTHOR> http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/

<comment><USER2> One of the best article series on the Linux kernel (and operating systems in general) I've ever read.</comment>