Web developer will work for you for free - v-t http://hirefreecoder.heroku.com/

<comment><AUTHOR> Don't sell yourself short, Vladimir. If you're going to work for free, try contributing to an open source project you find interesting. If you're going to work for a for-profit company, you should be paid :)

<comment><USER2> This does seem to be a mantra on HN. I can't speak for anyone else, but where I live "junior developer" positions are looking for 3+ years experience, "Preferably" a masters degree in computer science, expert Linux, HTML and JavaScript, and so forth. While globally it is a hacker's job market, those of us who are not currently free to move to where the jobs are (I'm a single parent and don't want to uproot my kid again) sometimes have to try to get our foot in the door in this employer's market by begging for the chance to work even for free.

Not trying to be a Debbie Downer at all, by the way. I moved from the valley to the Midwest (I know, I know...) so I know that there are tons of jobs for people like me (and Vlad, probably). However in my opinion "Don't work for free for a for-profit company!" isn't advice everyone is in a position to follow. I wish I could.

(Disclaimer: I am a junior dev with Django/js experience in both personal and open-source projects, without a degree. So take my whining for what it's worth.)

<comment><USER3> This advice is contrary to my personal experience. I live in a part of the US with a similarly craptastic market for programmers. In a recent job search, with very little formal experience as a software developer, I was turning down offers and taking my pick of interesting positions. From what I could gather this was almost entirely due to a github page with lots of code and a portfolio of interesting projects.

However I originally did think the market looked like you describe until I realized this amazingly valuable insight: My resume was almost instantly rejected by any company where an HR person/recruiter got my application; Any company where an engineer was the first to read my resume I was eagerly contacted in less than a week. A related insight: I don't want to work for companies where engineers aren't doing the hiring.

I also had no interest in moving and found, much to my surprise, that there are a lot great telecommuting options out there these days.

edit: I just want to clarify the tone/message here a bit, I'm not saying "your doing it wrong" but that it's easy to be discourage by being rejected by companies that aren't worth your talent. There was definitely a point in my search where I felt completely doomed, but then I realized that I actually wasn't aiming high enough and was underselling myself.

<comment><USER4> "From what I could gather this was almost entirely due to a github page with lots of code and a portfolio of interesting projects."

I've been a hiring programmers for almost 10 years. It's so rare to get a resume with something like a link to a github page. You're pretty much guaranteed a phone screen with me if I see this. I know it's hard for people just starting out to understand this, but demand far exceeds the talent pool. You will always run into the managers that want to see "oracle blah blah blah" experience. When you get rejected by them because you couldn't answer how to solve some oracle specific problem in an interview you just ignore it, and keep applying.

<comment><USER5> _It's so rare to get a resume with something like a link to a github page. You're pretty much guaranteed a phone screen with me if I see this_

Yes, yes, a billion times yes!!!!!

Even if it's some tiny little project that went nowhere, the fact that you actually have some code that is yours and that you can discuss intelligently puts you well ahead of 99% of the people I see.

<comment><USER6> _you actually have some code that is yours_

That's the important thing. Sometimes the initial excitement of seeing that github account wanes when you realize 8 projects are forks of existing projects with one change, and the other two are a stock rails project with only three or four minor commits on top of that.

<comment><USER7> What about an application server that was abandoned after padrino became available. I built it on top of sinatra, it was to include authentication and authorisation as well as a few handlers.

I'd generalised it from another webapp I was buildingfor someone else (that didn't pay) summer last year.

<https://github.com/dublinclontarf/SchoolOut>

This is pretty much some of the only code I've made available in public. Should I put up the entire webapp that I built during the summer? It's not doing anything.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Makes sense on paper but its a bad move, trust me, I've been there ... people simply don't appreciate free labor the way they would if they paid something for it.

Smarter move is to say "Hey, I bill out at $80/hr but to work at your startup I'll only bill $20/hr for 2 months", then make sure to send an invoice every 2 weeks with the bill at $80/hr with a line item showing the discount ... that way they are reminded of how lucky they are to have you.

PS: All this is moot if you aren't actually awesome at coding.

<comment><USER9> This is exactly the advice I was going to give Vlad. Start at a low $10 and work your way up the ladder. If your first contractor is happy with your work (ie. he'll be extremely happy for how cheap you developed a 100 man-hour project for 1k instead of 10k) then he will gladly pay you more for the next gig, or at least refer you to some colleagues. Then charge $20, then $30, and in no time you will have built a rock solid reputation and in a year you will be able to charge whatever you want based on your skills.

Never do work for free, ever. That diminishes your value and moral, and as collateral damage the coding market suffers as more and more people start working for peanuts.

<comment><USER10> I couldn't have said it better

</comment></comment></comment><comment><USER9> Whomever hires Vlad, please pay the guy at least $10 an hour and gain some respect from the community not to be seen as a greedy bastard abuser. That, and all the life-karma you'll get.

Idea HN: Create a page for 'Hackers in need' where people can offer their services for $10/hr until they get out of the trouble zone. Lots of people can benefit from some quick and inexpensive coding while helping a fellow coder.

<comment><USER11> I like this "hackers in need idea". Though there needs to be a way to keep out the leechers/time wasters. A turing test of sorts or captcha for programmers?? Dunno...

<comment><USER12> You can require anyone trying to sign up to complete a reasonably difficult programming problem. It could either be sandboxed on the server, like Facebook's engineering puzzles, or require a short output like Project Euler. This would drive away people who can't do FizzBuzz and nontechnical people who want to hire someone to make Facebook for dogs or whatever.

</comment></comment></comment><comment><USER13> I'm always wary of free labor, mostly because I did some before so I know what it can feel like.

When you work for free, you never feel obligated to deliever or perform at your best because nobody is paying you, so if you get fed up you can just leave -- why put up with the bad environment? Sure it might be fun for a week or two, but people get bored, and it is usually monetary of personal incentives that keep us going. Working for free provides neither of these. It isn't my project, nor am I getting anything in exchange.

Now I'm not saying that he will be like this, but this flipside of mentality is definitely something to consider when you hire "free" labor.

</comment><comment><USER14> Are for-profit enterprises in the United States allowed to accept free labor? I know that nonprofit organizations can accept volunteer labor (and do so all the time), but I thought that business corporations and business partnerships that check the law (in the United States, at least) find out that they cannot accept free labor. What are the applicable laws involved here?

<comment><USER15> Unpaid internships are legal in the United States. I know of a few businesses that build these internships into their model as a way of keeping costs down.

The Department of Labor has a smell test for them: <http://www.dol.gov/whd/regs/compliance/whdfs71.htm>

<comment><USER16> "I know of a few businesses that build these internships into their model as a way of keeping costs down."

According to those regulations posted we see that a business can't legally have an unpaid intern to keep costs down. The pros for an unpaid intern would be; 'Intern gets experience,' and 'business has potential future employee.' Whereas the pros for a paid intern would be; 'Intern gets experience plus compensation,' and 'business gets profitable labor, and has potential future employee.'

<comment><USER15> You're absolutely right, but it's hard to enforce. I'm not saying it's right, but this kind of thing happens all the time in old media jobs and elsewhere. For example, if I brought you in as an intern and showed you how to write a story that's technically training, but your story may very well displace another reporter's story, too. Young workers live with it because they want to build portfolios and work experience.

</comment></comment></comment></comment><comment><USER17> There is really something wrong in the job market when I work two years to get a good hire for my small development company (at a good hourly rate, telecommuting, etc.) and people like Vladimir have to give away their services...

</comment><comment><USER18> Cut down 2 months to 2-3 weeks and your offer will pass for a reasonable probation period, albeit free to the hiring company. Alternatively, and this is more in line with what others are saying, - say "free 2-3 weeks of probation period and _then_ pay me for this time _if_ we continue working together."

I am just looking at this whole situation from employer's perspective, and the ability to test a developer for few weeks (and not needing to pay if he does not work out) is a really attractive proposition. On the other hand I would not consider dealing with a dev who's ready to work completely for free. Based on my past experience such devs are either seriously underqualified (and through that unreliable and require lots of mentoring and hand-holding) or they would gear down and slack if the project is not truly interesting for them. The money factor serves as a retainer and the conditional payment works as an incentive.

Think about it ;)

</comment><comment><USER19> I just hope that whoever hires him gives him something truly challenging and engaging to do. The biggest risk of working for free is that people think that since it doesn't cost anything anyway, it doesn't matter what he does (e.g. the internship curse).

</comment><comment><USER20> Vladimir, I'm not sure if what is your visa situation, but getting a work visa in the US is very hard and takes a lot of time and effort. I would start researching it right away and collecting your documents (degrees, awards, letters of reference, etc...). If you just want to come visit, you won't be able to work here with a tourist visa so start looking into it. Good luck.

<comment><USER21> Suppose Vladimir has an incorporated business in Russia, comes to the USA with his laptop and does some work for a USA startup from his laptop VPNned to his home base in Russia. The bills are sent from his Russian business address. After a while when his tourist visum expires, he flies back. Would this be viable?

<comment><USER20> First, I'm not an immigration lawyer so don't take my advice. However, I've been through a lot before I got my green-card and very familiar with the process. Coming here as a tourist and working (even for a Russian company) is illegal. even if you come here just for a tech conference without working, it's considered a business trip. bottom line, you have to declare you are here on a business trip cause they will check your laptop, go though your emails, find out you are performing some work for a US entity and deny your entrance and take away your visa. Definitely, not something I would recommend.

</comment></comment></comment><comment><USER22> I got a good job once by offering to trade 5 hours a week of work for desk space to (ostensibly) work on contracting. Within a couple weeks they were paying me full time. This is probably a better approach than offering half time for free.

</comment><comment><USER23> I could never accept such an offer. I hope that Vladimir will gets at least a minimum U.S. hourly rate for his efforts. Edit: A minimum US hourly wage is a very decent pay in Russia.

<comment><USER24> Quick google tells me its $7.25/hour, is that really the case? Sure is decent in most of Russia, depends on the city though.

<comment><USER23> It is indeed the case. You really can't live off it in the US though...

</comment></comment></comment><comment><USER25> _"I can perform task like making your html pass validation tests, writing js widgets, adding ascii art to your nginx conf, writing specs for your code or hopefully implementing new features at your beloved startup."_

I see what you did there. Testing to see if people are reading it all, are we? :D

</comment><comment><USER26> Hey Vladimir, what kind of salary range are you looking for when you get hired on full time? Or what hourly rate are you looking for if someone was to work with you for a little while and decide "hey, this guy is awesome, I need to start paying him enough that he'll stick around and keep helping us out"?

</comment><comment><USER27> Vladimir, you should find the open source projects that interest you and work on those, or build plugins for them. Why not volunteer for Rails or Sinatra? Or write Emacs plugins/extensions? Write about your experiences with these systems...blogging and contributing to open source will absolutely get you the contacts you are looking for, without having to resort to working in enterprise for free. While I would personally love the free help, I don't think any ethical entrepreneur here on HN would take free work, and we'd all encourage you to at least charge for what you're doing if it's going to be with a for-profit company.

</comment><comment><USER28> Work for full-price or free, never for cheap. Good luck!

</comment><comment><USER29> Just emailed you. Bootstrapped startup with 2.5m iOS installs, just now expanding to web, and in need of Ruby/Rails/Web Frontend devs :)

</comment><comment><USER30> Email coming. I've got a small project I need done, it's basically tweaks to an existing one. More than happy to pay, though.

</comment><comment><USER11> While I agree that you shouldn't sell yourself short, I think it is also interesting that somone is taking the first step in letting their potential employer validate a potential employee's potential (too much potential there).

Also, it lets the employee validate the quality of the work.

I think it;s okay if done for a couple weeks (short project/assignment). If the employer likes him, he/she can pay him for the work done - out of goodwill.

Everyone wins (only in a perfect world).

</comment><comment><USER31> Vladimir, I won't hire a developer to work for free. But if you can pay me 5$ (I donno what's the unit they talk here per hour, per day or even per week) I'll assign you work. And... you can have all the experience.

Your 1st assignment: As my office work is worse than yours like ftping files sending reports etc. you can create some apps for teaching me Ruby, Javascript etc. and then add my details too in you website.

</comment><comment><USER32> Ahhh, the old "Mark Zuckerberg" ruse!

No thanks, dude!

</comment><comment><USER33> Before I got hired on at my current job, I had planned to find a local charity and build a pro bono site for them. It (1) would give me experience and (2) would help out a charity I favored.

I didn't wind up having to do that, but I absolutely think it's not a bad idea.

Although of course you do leave yourself open to abuse if you don't have a good line in the sand visible to all.

</comment><comment><USER34> Do you have a portfolio or GitHub profile? You mention Backbone.js. Do you hang out on #documentcloud on freenode?

</comment><comment><USER35> Hiring someone for free is a two-way risk. If you are working on some prototype, will you reveal the general core idea to him? If you do, he might run away with it. If you don't, he will get bored and run away. I'm not saying that he may be bad but just trying to highlight the two-way issue.

</comment><comment><USER36> replying on hn since this may interest some other folks too.

If you are interested in building something of worth and like the idea of open social networks and producing opensource software, there's always small modules that need building to make buddycloud feature complete. Pick a part of the architecture that looks interesting to you ([http://m.buddycloud.com/tmp/proofs/buddycloud%20architecture...](http://m.buddycloud.com/tmp/proofs/buddycloud%20architecture.png)) and chat to the rest of the team in our chatroom. More dev details on <http://open.buddycloud.com>

We also have some cash coming in... not a huge amount but enough to provide some support if you turn out to be good.

</comment><comment><USER37> It's great that there are people here offering up opportunities to do this. There's a Rails one up there, and if you can put that on your resume, it's a plus.

</comment><comment><USER38> Vladimir, if you are interested in working on a startup in México as paid intern. Ping me.

</comment><comment><USER39> Just sent you an email Vladimir.

</comment><comment><USER40> Start your own project. Something you love. Come up with an idea. Execute it well.

And unless you're rich and don't need money, do not work for free.

</comment><comment><USER41> If he really works for free and just got 200 pts on HN, then his time costs too much of mine.

<comment><USER41> Woah, hey. I wasn't trolling at all. I was suggesting the guy will be WAY too busy for me to ask for anything.</comment></comment>


R in production systems - <AUTHOR> http://erehweb.wordpress.com/2011/02/02/r-in-production-systems/

<comment><USER2> The Climate Reports (<http://www.whitemagicsoftware.com/software/climate>) has been running for 10 months, without a single failure. The Climate Reports uses R to calculate the trend line.

During development, I encountered a bug with one of the packages. I told the author and he not only fixed the bug within 24 hours but also offered to create a custom build for my CPU architecture.

I have only good things to say about R and its community. And I think R is sufficiently stable for production.

</comment><comment><USER3> R is a stable enough language to be used successfully in production systems. But I would definitely _not_ recommend building anything "big" in R-- I've tried and the entire process was not pleasant. R is a research environment for statisticians or statistically-minded practitioners in other fields-- and there has not been terribly much effort (from what I can tell) to change its status. I'd be happy to hear from others who've had similar (or different, perhaps positive) experiences.

It's actually my experiences trying to build production statistical processes in R that have motivated me to work on building out the statistics-related libraries for scientific Python. Hopefully within a couple of years we'll have something that's competitive with R in terms of ease-of-use and comprehensive statistical functionality out-of-the-box.

<comment><USER4> Do you think that Python libraries or a comprehensive development push will overcome barriers to entry for statistical process platforms? What if the greater adoption of these techniques is more limited by communities of users than the developers?

<comment><USER5> I have often wondered when something Python-ish will come along to compete with R. I like the power of R, and there is no better choice if you require an esoteric statistical estimator, but there are also a lot of downsides. It's difficult to debug, the interpreter seems flaky, and parts of the SPLUS syntax feels dated. Also, I know it claims to be object oriented, but I have never really understood the OO system in R. So much more time and effort is being poured into improving the Python runtime, that it seems silly not to try to build something on top of it.

I am starting a stats PhD in the fall and have about nine months to kill between now and then. I'm seriously considering devoting all that time to building something like this.

<comment><USER3> I'm actually working on a stats PhD (in the early stages) and I've made it my goal to build a lot of Python software as I go along. So if you have the inclination I'd recommend giving it a shot. When you consider the wealth of tools out there for both high level (NumPy-based) and lower-level computation (e.g. Cython, for speeding up algorithms), and software development (especially interactive debugging and testing), it's a fairly compelling proposition (for me, at least).

But long story short is that people _are_ working on making Python more amenable to applied statistics work. And the more people working toward that goal, the faster we'll get there.

So I would recommend: join numpy-discussion and scipy-user mailing lists, explore projects out there-- last few SciPy conferences are a decent place to start.

<comment><USER5> Yes, it's a tantalizing prospect because so much of the groundwork has already been laid. I have the sense that something is just needed to tie it all together into a nice, easy-to-use package with a consistent interface, easily- understood object model, etc.

My masters is in math, and I have watched Sage create a small revolution in the past couple years by doing exactly this.

Food for thought...

<comment><USER3> I agree-- and doing so could make some pretty serious waves across both academia and industry. You should join the discussion on the mailing lists: in particular pystatsmodels and the numpy/scipy lists. Any input would be much appreciated.

</comment></comment></comment></comment></comment></comment><comment><USER6> I believe this is one of the problems that Incanter was made for: really easy embedding in a larger software system. Of course, it's nowhere near as featureful or widely-used as R.

<http://incanter.org/>

</comment><comment><USER4> I have been reconsidering my workflow for a more data-centric approach. When I first looked around the search results for data-centric workflow, I was shocked that it was limited mostly to theoretical discussions and commentaries.

Why don't we have communities online focussed around using tools and platforms that allow informed discussion and decision making to solve entrepreneurial problems??

</comment><comment><USER7> ESRI (The geospatial software company) and SAS (the commercial alternative to R) both got caught up reacting to their existing user bases instead of proactively watching the analytics world. Both companies have (or at least until recently had as my knowledge is circa-2008) very desktop-centric product lines. Their customers used their products as if they were fancy versions of Excel -- a perfectly valid use case, but not one suited to production analytics. Both companies first forays into production systems involved clunky wrappers around desktop components. I'm sure they will eventually put out first-rate headless production components, but there's probably a nice window available in which start-ups may innovate.

</comment><comment><USER8> good article... I have just launched a site (<http://www.promepi.com>) which uses R to recommend news articles to users. My co-founder used a lot when getting his masters degree, but I was new to it. It has been great to quickly develop our algorithm.

Anyone have experience with Revolution Analytics? My cofounder looked at these guys as we try to scale the site... he definitely agrees with one of the comments that "big" datasets are good in R and hopefully our site gets to a big dataset, so we are looking at scaling options.

</comment><comment><USER9> The advice to go 64-bit and throw RAM at the problem brings back memories of my computational math class.</comment>


The "Disgusting Food Museum" in Malmo, Sweden - <AUTHOR> https://www.washingtonpost.com/news/voraciously/wp/2018/10/09/this-new-food-museum-expects-to-upset-your-stomach-and-then-make-you-think-about-why/ <comment><USER2> I find it very surprising that balut made him vomit, it pretty much tastes like a standard chicken/duck non-fertilized egg with a different texture. Not that I necessarily enjoyed it, but with salt, its not terrible. Hakarl is bad, but I barely think that counts, in the sense that I don't think it was EVER meant to taste pleasing. I find any foods containing extremely high levels of ammonia to be generally off putting, but maybe in the future that flavor profile will be like hops in beer today and hipsters will chase after it and put it in everything. /shrug.

Also from another angle, if the point of the museum is to remove the "otherization" aspect from food, why even call it the "disgusting food"? Obviously anyone who connotates the exhibit with the items inside will be going in with a specific bias.

My personal thoughts are that a majority of "disgusting" items are generally grouped into categories broadly being: fermented, processed (sausages/spam), organ meat, or "creatively made" (ortolan, casu marzu). Just call it a food museum and subdivide it by the above categories, and remove the dumb culture differentiation.

The very article that they reference with Anthony Bourdain has a part that criticizes the notion of overly closely tying a food to a specific nation/culture. If you want to get rid of these sorts of biases, don't even bother tying the item to an identity, just show it and make it "normal" seeming.

<comment><USER3> It tends to be Texture, rather than Taste that makes most peope hate some foods.

I disagree however with seeking to divorce the food with the culture. The amount of understanding between cultures by sharing food is huge. Food implies 100s of things about the person and the community that produced it. I agree that we shouln't over-emphasize the strageness of it, but many have borderline fetish for the new, unusual, exotic. That human nature will always bring styles and tastes together, while preserving a positive group identity. We are, for better or worse, wired for tribalism. I think embracing that nature and optimising for it seems better than pretending its not there.

</comment></comment><comment><USER4> After watching a few videos of people trying surströmming, I figured they might feature it in the museum, and sure enough.

It's interesting to me that foods like that, that have an incredibly pungent/aggressive smell or presence are just naturally enjoyed by others.

I guess my brain still wants to believe that when something is that "bad" that everyone else will experience the same thing, though that's clearly not true.

</comment><comment><USER5> I was in Slagthuset the other day, it's a surprisingly lovely building on the inside and well suited to a museum display. Not sure I'll be visiting this one though.

</comment><comment><USER6> I have to disagree on the rotten shark, it really isn't that bad. It's not (even close to) good or anything, but it's not absolutely horrid either. Tried here: [http://islenskibarinn.is/net/](http://islenskibarinn.is/net/)

</comment><comment><USER7> This guy created the museum of failure. I really hope he consulted Stephen Pile, who wrote _The Book of Heroic Failures_ (possibly the funniest book of all time).

</comment><comment><USER8> Here's a link[1] without paywall.

I'm from Malmö and I just learned about this thing through HN.

1\. [https://www.thelocal.se/20180926/disgusting-food-museum- to-o...](https://www.thelocal.se/20180926/disgusting-food-museum-to-open-in- malm)

</comment><comment><USER9> Even with the 'facebook redirect' trick.. the paywall prevents me from viewing this article. -_-</comment>


The Linux codebase has over 3k TODO comments, many from over a decade ago - <AUTHOR> https://todos.tickgit.com/browse?repo=https://github.com/torvalds/linux <comment><USER2> TODO is vital for my development process. Sure, maybe there's better programmers who don't use or need TODO, but for me, it's a critical method for the following reasons.

1\. It prevents my "flow" from being sidetracked by micro-optimizations that are probably too early to consider necessary anyway.

2\. It helps me to retain my short term memory on the code I am working on. If I branched out at each TODO to implement some improvement or method, my brain typically needs to context switch to focus on the fine details of the subject. By the time this is done, and I switch back, I have forgotten key aspects of what I was working on and it slows me down again (i.e. local names, structs, etc.)

3\. It allows me to re-approach something with a completely different mind set (given that I come back to it after a signicant amount of times). Half the time I realise that what I wrote was indeed "good enough" and no further time should be committed to it unless a reason exists to do so.

4\. It gives opportunity for other developers to see, think, comment and contribute on the subject. I find that typically if I TODO an area, it's good for a second set of eye balls to see it. There's far smarter people than me around, and there's a good chance one of them will find it and propose a better solution.

5\. On the rare "quiet" day, I can grep for TODO and just work through them.

Obviously these points are only valid if the TODO labels are being added in situations that will benefit from the above.

<comment><USER3> It's critical for me too, for exactly the reasons you listed.

RE point 2., it also applies to issue trackers and other "proper" way of encoding TODOs - if I tried to branch out to file a ticket in such situation, or even make a TODO entry in the Org Mode files that always accompany my projects, I'd very quickly lose the flow. Context switch is deadly here.

RE point 5., I try to work through them as I go. I consider this to be a part of cleanup after a main task - I go over all the TODOs in the area I worked in, and implement the simple ones, delete the stale ones, move the serious ones into issue tracker, and leave the rest for future reference.

All of this applies also to FIXME, HACK and NOTE comments - three other types I use. Out of these, NOTE are informative, "seriously please pay attention" comments.

I date them all. I have a Yasnippet for all the above, which expands "todo" into "TODO: $ -- My Name, 2019-12-30", $ being where the caret stops after expansion. Same for "fixme", "hack" and "note".

<comment><USER4> > I date them all. I have a Yasnippet for all the above, which expands "todo" > into "TODO: $ -- My Name, 2019-12-30", $ being where the caret stops after > expansion. Same for "fixme", "hack" and "note".

why is that necessary ? git blame gives it to you already

<comment><USER5> You can rewrite the git history when you squash commits for example.

One case I've heard is that some people no longer have their names on git commits they made to various Google open source projects because their commit went inside, where it was rebased, merged, integrated, squashed, and then what the public sees is a single git commit by a Google insider that is the result of thousands of individual commits.

<comment><USER6> I don't understand the need to rewrite history. This is a good example against that practice.

<comment><USER7> Because it becomes more compact. Most of the time git commits are things that don't make sense to have at a more macro level. Squashing into a single commit that represents a coherent improvement, particularly for large projects, is the best way to read its history.

<comment><USER8> I prefer a small branch with many individual commits (cleaned from fixups or not) and a merge with main branch which adds the whole feature. Then you can have two levels of reading.

<comment><USER9> Doesn't this still put all the commits on the main branch?

<comment><USER8> No you commit in feature branches then merge to main branch.

<comment><USER10> Do you then keep the branch around forever?

<comment><USER11> The branch history is preserved in the commit graph of the main branch, so you don't need to keep the feature branch.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Interesting! I got curious about where they come from, so I dug a little. Here is a non-exhaustive breakdown:

\- 23 from crypto code: [https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:1000+file:crypto/&patternType=regexp)

\- 2380 from driver code: [https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+file:%5Edrivers/&patternType=regexp)

\- 73 from ARM arch code: [https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+file:%5Earch/arm&patternType=regexp)

\- 43 from x86 arch code: [https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+file:%5Earch/x86&patternType=regexp)

\- 114 from other arch code: [https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+-file:%5Edrivers/+-file:crypto+-file:Documentation+-file:%5Earch/arm+-file:%5Earch/x86+file:%5Earch/&patternType=regexp)

\- 606 from block IO, FS, networking, and other sources: [https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+TODO.*%5C:+case:yes+count:10000+-file:%5Edrivers/+-file:crypto+-file:Documentation+-file:%5Earch/&patternType=regexp)

<comment><USER13> Without auditing, driver code makes sense to me. Guessing there is a lot of vendor churn and therefore a lot of caveats to keep track of ... right up until the point the driver is obsolete and put on life support, never be looked at again.

<comment><USER14> Or simply the features are never needed so they are never implemented. There's rarely a perfect match between the hardware capabilities and the OS interface, that's the cost of the abstraction. Sometimes there's no trivial way to expose the feature or it would require too much work for something that's not deemed necessary.

</comment></comment></comment><comment><USER15> The _kind_ of software being written materially influences the semantics and use cases for TODO. I think much of the disagreement in this comment thread is based on a tacit assumption that everyone works on the same kinds of code bases. A web app is not the Linux kernel, and the priorities and concerns in development when annotating code will differ.

For example, in much of the database code I work with, TODO is used for _optimization banking_. In performance critical applications, this is the practice of pervasively tagging (often with TODO) micro-optimization opportunities in the code. When a bug fix or new feature unavoidably creates a significant performance regression (I use 5%), you implement several of the "banked" optimizations documented as TODO in order to bring performance back to parity. For this reason, a TODO may linger in the code base indefinitely _and that is okay_. It is a searchable annotation for code work that may never need to be done.

You do not put these kinds of TODO items in an issue tracker because they are extremely local and contextual to the code they apply to. Filling the issue tracker with thousands of these kinds of issues which can't be understood without looking at the specific lines of code the comment was applied to has high overhead with negligible value. You _do_ open an issue in the tracker for performance regressions in a subsystem, or if you want to improve the performance by some metric, which directs a developer to start looking at the banked optimizations in the TODO comments inside the code.

Another rarely discussed use case for TODO is assumption verification around the internal behavior of external dependencies. Developers make assumptions about code dependencies (e.g. Linux syscalls or compiler code generation) based on trivially observable and testable behaviors. For code that needs to make strong assumptions about dependency behavior for robustness, it is frequently impractical at the time of writing code to verify that assumptions hold under all conditions or that they will remain true over time (see: Linux fsync() behavior). This becomes an issue that is never "resolveable" in a meaningful sense because it is a moving target and time-consuming to research for any particular case. The TODO is a reminder to re-verify behavior if anything has changed in the software environment or a new bug has shown up and usually notes what _has_ been verified in the past.

Feature and bug work belongs in an issue tracker but there are many "issues", particularly ones that are non-functional and require extremely local context or can never be properly resolved, that are often best served in direct code annotation.

<comment><USER16> > You do not put these kinds of TODO items in an issue tracker because they > are extremely local and contextual to the code they apply to. Filling the > issue tracker with thousands of these kinds of issues which can't be > understood without looking at the specific lines of code the comment was > applied to has high overhead with negligible value.

This is one thing that really irks me about most code review cultures I've worked in - they can never stand to see a "naked" TODO (one without a reference to a tracking bug). You're spot on about the result.

The instinct to put a TODO is a note to self that there is a future cleanup, optimization, or improvement. It's a flag to readers of the code that the original author was not quite satisfied with some dimension of a solution. It is _not_ a work ticket, especially in the timeframe that most issue trackers work on (< 1 year).

Maybe there needs to be alternate semantics for these "contextual TODOs", so that people do not immediately get the instinct to either put them in the queue or remove them.

<comment><USER17> Yes... My own codebase has 669 XXX's, 227 FIXME's and 1564 TODO's... For just 615,981 lines of code. And that's valuable information during development.

</comment></comment></comment><comment><USER18> I use TODO in my code all the time as shorthand for: "This code is functional, but if you are going to do another iteration you may want to consider the following improvement or optimization."

It's not at all meant to be to be like an item in a TODO list. Code would be a terrible place to keep that.

<comment><USER19> The lead programmer at my very first coding job taught me to put a string of at least three hash marks in a comment, to denote "this is a thing which is okay during development but absolutely must be changed/fixed before shipping this product".

The more essential the change/fix, the more hashes. Made it really easy to do a global search for them, and you could easily filter the results to only show the most important ones by searching for longer strings of hashes.

Twenty years later and I'm still doing that in my personal projects.

<comment><USER20> At my work we just file a bug and make sure it gets prioritized as a must- fix... The code might contain a bug number and remark too for redundancy, but the bug itself generally spells out the bits of code that need to be changed/removed/whatever.

Using code comments really seems like the wrong place to prioritize changes. Even on personal projects.

<comment><USER21> I agree in principal, though if the intent is to have the minimal amount of side-tracking while marking something as TODO for the future, I don't think you can get better than a comment.

A nice cli interface for creating tickets in GitHub/Jira/etc. would help with that. I wonder, would it be nice to have a pre-commit hook that scans for TODO comments, removes them, and drafts tickets? Then both flows would work well.

<comment><USER20> I suppose it depends on how far you trust your ability to keep everything in your head, and reload everything coming back, and follow through on notes to self. I make todos too, but I try to honor a self-agreement that they be short lived and ideally not make it very far beyond my machine.

I linked [https://github.com/dspinellis/git- issue](https://github.com/dspinellis/git-issue) in another comment but it gives a sense of the command line experience. I've also at times hacked up various scripts to create or modify items in github/jira/our internal POS, it can make things more likely to hit the tracker than to be met with a shrug. (It's so odd how sensitive programmers can be to even minor blocks in flow like a few seconds waiting for a webpage, or avoiding refactoring a method / class because in Java a new method might best belong to a new class which to do things 'proper' often entails a new file and then another new file for unit tests, adding them to version control, and all that takes like 30 seconds even with IDE support and is annoying.) I've at times thought about a small vim command that would call one of those scripts to create a new issue pre- templated with the file and location I was on, create, then insert the work item id, but never got around to it. As a pre-commit hook something to look for TODOs explicitly might be interesting, though I generally dislike hooks.

</comment></comment></comment></comment></comment><comment><USER22> In my opinion, any comment prefixed by TODO, XXX, or the like should not survive past the review stage. Either fix the problem immediately or accept that it's going to be wonky forever.

Edit:

Amending here to avoid replying to ten different threads individually.

1\. Long-term improvements should be managed by a ticket tracking system. The code is not the correct place to manage that.

2\. Most of the disagreements below seem to come down to nomenclature differences.

In my own work, the code is liberally sprinkled with "Note:"s. These are, as others have pointed out, useful for providing context of what is going on, why, how it is non-optimal, etc.

TODOs that I come across tend to be of the "You ain't gonna need it" variety. If you can get a pull through review as-is, then the thing wasn't actually a "TODO", and if it was, then it should be added as a ticket to the backlog.

XXXs tend to show up in the reviews I do as code that is explicitly meant to be fixed before the pull is merged.

So to summarize:

1\. "Note:"s in code are great.

2\. "XXX" shouldn't survive the review

3\. "TODO" should be handled by the ticketing backlog to better separate out "actually needed" from "theoretically nice, but not necessary in practice".

Further, things that are "TODO" today often make zero sense as "TODO" in a year when the code has grown and evolved more, but since someone put it in as a TODO, I find that they rarely ever get removed since "surely someone knows what that means" (but that person is usually either gone or no longer remembers).

<comment><USER23> I agree and don't understand people who downvote you as a punishment for expressing your opinion.

A TODO item is missing significant business information: date, priority, severity, risk, impact, applicability etc and leaves all those assessments on developer's shoulders who shouldn't have to deal with it at all.

As a matter of fact, every time a developer encounters a TODO around the change he did, it suddenly becomes a burden. He needs to answer "should I be doing this?", "what's the business impact of adopting this?" etc. Even a simple code change can mean business impact in large projects and has regression risks. What if the aforementioned developer isn't at the right caliber for the task, but they don't know it and take it on?

Due to the missing information, it's very hard to analyze TODO data and come up with reasonable engineering decisions too. TL;DR: It makes everyone's job harder.

I only find TODO's suitable for personal projects where you don't want to go back and forth between IDE and the issue tracker.

<comment><USER24> You have almost converted me from using TODO. I typically place a "Note:" when there's code that is hacky but not obviously so, to provide context. I also make sure to provide a link if some kind to a relevant issue tracker.

But a TODO is something different. It's for prototype code, where I don't even know if the feature is going to stick around long enough for the hack to warrant fixing. It says "don't worry about just deleting this whole thing outright and starting fresh." It's graffiti to intentionally make the code uglier, so it's not confused for being part of some larger design. It says, "hey, so, I didn't actually expect this code to survive, but since you're here reading this, it clearly did, you're probably working on something related to it, and you might want to know a few things upfront because it's not going to go the way you think it should go."

<comment><USER23> "Note:" comments are perfectly fine. On the other hand, I've seen at least three distinct definitions for TODO in this HN thread:

\- TODO should be a note about behavior.

\- TODO should prescribe a small fix.

and yours: TODO should mean "don't worry about deleting this".

These different interpretations and potential confusion they would create make even a stronger argument against TODOs.

<comment><USER24> I'm afraid "don't worry about deleting this" was poorly phrased...but your point still stands

</comment></comment></comment></comment></comment><comment><USER25> Chromium has 26,000: [https://cs.chromium.org/search/?q=%22//+Todo%22&sq=package:c...](https://cs.chromium.org/search/?q=%22//+Todo%22&sq=package:chromium&type=cs)

<comment><USER26> Which makes sense since TODOs tie in to buganizer at Google.

</comment></comment><comment><USER27> I use this pattern across my codebase for the "critical functionality missing" scenario:

      #if DEBUG
      #define TODO(msg)
      #else
      #define TODO(msg) #error msg
      #endif

Works like a charm. I've got another PRERELEASE() macro that lets you do an unofficial preview build, but would break an official stable release.

<comment><USER28> That doesn't sound like it would scale at all for any more than a couple of devs.

<comment><USER27> Neither do TODO comments. This is just for a short-term "don't forget this piece before calling the current job done".

For anything more long-term you want to use a proper task management system with priorities, deadlines, dependencies and so on.

</comment></comment></comment><comment><AUTHOR> Creator here - this was a total pet project and no idea it'd hit the front page. Upgrading the infra now to handle the load . Sorry for the error rate

</comment><comment><USER29> > The Linux codebase has over 3k TODO comments, many from over a decade ago

And that is ok.

<comment><USER30> Sure, for the individual. Does the project track them internally? How are they followed up on? How is work assigned and prioritized?

<comment><USER31> When the file is next edited by the next individual. They don't need to be tracked

<comment><USER30> Sure, and then you end up with linux.

<comment><USER32> > Sure, and then you end up with linux.

You mean the most successful software project in the history of mankind?

<comment><USER30> By some metrics, sure.

</comment></comment></comment></comment></comment></comment><comment><USER33> FWIW, having a TODO file is mandatory for anything in staging/, see Documentation/process/2.Process.rst.

[https://www.kernel.org/doc/html/latest/process/2.Process.htm...](https://www.kernel.org/doc/html/latest/process/2.Process.html#staging- trees)

Moreover TODOs are added for unmaintained drivers outside of staging/ in order to prepare for their relegation to staging, e.g. see commit a0d58937404f ("PCI: hotplug: Document TODOs").

[https://git.kernel.org/linus/a0d58937404f](https://git.kernel.org/linus/a0d58937404f)

</comment><comment><USER34> Only ~3,000? Not really that surprising, is it? I think a more interesting metric is how many TODOs have been resolved/removed in that time. I have no interest in figuring out how to figure that out though, so...

<comment><USER35> Couldn't you take an older kernel and do a comparison of the TODOs in the most recent, and get a count like that?

<comment><USER34> That would tell you how many of the TODOs from that specific older kernel have been fixed. But in the intervening releases you could have TODOs come and go. To find them all you would have to go through pretty much every kernel patch looking for something approximating the following regex (assuming you were looking at TODO comments and not +/\- TODO files):

^-(?!--).*TODO

This should show you all lines removed from source that contain TODO, which should get you in the ballpark.

</comment></comment></comment><comment><USER36> The codebase that has no TODOs has no vision of its future.

<comment><USER37> Your vision of the future should be in a bugtracker, not in code comments. TODOs give you a vision of what you would do if you had a few more hours. A bugtracker gives you a vision of what you would do if you had a few more years.

(Where do you put "TODO: Learn tool X and rework all of this to be completely different using that tool if it makes sense" or even "TODO: The program crashes at shutdown with a double-free, but I don't know which line of code had the extra call to free"?)

<comment><USER38> I have completely the opposite opinion! Any bug in the bug tracker hanging around "in a few years" should* be closed. Comments should* persist while the source code issue to which they refer remains remarkable.

*it's fun issuing such rulings.

<comment><USER37> Closed bugs are still easily searchable in just about any bugtracking system, whereas deleted code is much harder to dig up (you're less likely to even look for it, and if you do it's harder to find the relevant parts).

I agree that closing bugs you don't intend to act on soon is reasonable; I disagree that this makes it not worthwhile to have filed it.

FWIW I also agree that todos _specifically about certain lines of code_ , i.e. todos that will become irrelevant if the code is rewritten at all, should be in code. The limit of that is probably roughly "TODO return the right error subclass". Even "TODO pass more information into this function" is probably past that limit, since it affects at least two spots in the code.

</comment></comment></comment></comment><comment><USER39> I used to be pro-TODO, I find myself today firmly in the no-TODO camp.

I work daily on a large, mature code-base, littered with cryptic TODOs left by developers long-gone. They are generally as useful as street-signs in a ghost town.

TODO: clean this up

toDo: validate once ARF-211 is closed

todo remove

TODO factor

TODO: lol, hae to enable in production for some reason

TODO- will this scale? logarithmic?

If I dive into the commit logs, I can try and sus out why they were there, whether they can be removed or acted on. Generally other devs don't touch them out of superstition, they are probably there for a reason, someone else understands them, and they will eventually be useful.

Clearly, better team agreements, discipline, strict code reviews etc could have prevented this or made them more useful, but that ship had sailed before I arrived, and given the pace of maintenance and new feature development I am sure these TODOs will remain for quite some time...monuments to earlier days and priorities that are long gone.

<comment><USER40> Your anecdotes are familiar and I completely agree with some of your observations on the limitations of TODOs, but I don't see any reason to be anti-

As far as I can gather, you've described TODOs being _useless but harmless_

</comment></comment><comment><USER41> The more interesting statistic would be: how many TODOs have been _removed_ from the code, and were they implemented, or just obsolete/wrong?

</comment><comment><USER42> If you don't use an issue tracker, then to-dos is your issue tracker.

If you're using an issue tracker as well as to-dos in the code, then you've got two issue trackers.

If you're using an issue tracker that also reads to-dos in the code, then you've got one issue tracker.

Where I work we don't have an integration between the tracker and our code, so we disallow to-dos, but allow comments with references to issues. So in other words - one issue tracker.

I can't quite understand why people would want to have multiple places to list code issues.

<comment><USER43> In practice they work quite differently in a number of ways, depending on your workflows. I'll outline mine, but from this thread you can probably tell, it's not unique.

Jira/Github-like issue trackers can often become blackholes for certain kinda of work. Not all TODO's NEED to get done, they're often just reminders to revisit decisions with the full context of the code. The two most common cases that come to mind are deferred possible optimizations and deferred generalization.

In my workflow, it's more of a counterbalance against premature optimization, abstraction, and distraction. It also has the benefit of:

a) informing reviewers what wasn't done and why right in the diff. It can often spark good conversations of if it's worth scoping them in or maybe scheduling in (Jira!) soon.

b) Allowing people to revisit the above when the next engineer is changing things in the neighborhood.

In my experience, if and engineering side ask isn't addressed in a month or 2 it quickly turns into one ticket that sits in the backlog forever and maybe another that get's created when the "idea" get's floated again.

Naturally, your milage may vary.

</comment></comment><comment><USER44> A small rule that we set at $WORK, that I found quite helpful for comments: always require a Jira ticket ID if you add a TODO comment.

That way you always have `// TODO (PJ-1234): better to have some caching mechanism`, where `PJ-1234` is a ticket with "TechnicalDebt" tag, and more details/context.

That gives some transparency to the rest of the team (outside of people working on this specific code base), and avoid situations where nobody knows why a TODO comment exists.

</comment><comment><USER45> This is why I wrote [https://srcoftruth.com](https://srcoftruth.com) \- it will find your todos and open, track and eventually close a ticket for each distinct todo in your repo. Works on GitHub repos and issues (private and public). Currently building JIRA integration and generic web hooks. And it's free!

</comment><comment><USER46> I don't understand the hatred for TODO statements (and similar), even if you never come back to them, they're still useful to know the future intention of the original author.

<comment><USER47> I agree but I also think that value is pretty marginal.

</comment></comment><comment><USER48> When I see just a simple `TODO` in some OSS project it's often hard to understand either it's a broken edge case or some micro optimization or refactoring left for future. For my projects I adopted (it grew naturally) priority tags, e.g. `TODO!!! [(WTF)]` for critical [tricky/edge case] bugs, `TODO!` for important hot paths optimizations, `TODO (low)` for nice to have, `TODO?` or `TODO (review)` for rethinking design later.

Actual tags are not as important as ability to understand the priority at a glance without looking up a tag in some docs. And fixing all `TODO!*`s is high priority, ideally they should not be committed.

<comment><USER49> That's a great idea, I'm going to give it a go myself, thanks!

</comment></comment><comment><USER50> I'll litter my code with TODOs while developing, especially in a green project. However, our team has a practice that we find valuable: any TODO checked into the master branch must contain a link to a jira ticket. A TODO that can't be prioritized is likely to never get done. We like the forcing- feature of making the choice to handle it now, or working to get it prioritized.

</comment><comment><USER51> TODO, aka I have the best of intentions but I'm probably not doing this in the near future or ever, for that matter.

I'm guilty for quite a few

</comment><comment><USER52> A lot of people suggesting "TODOs should become tickets before accepting the code for merge". So... How do you do that? Manually, I assume?

A while ago I started on a tool to automate managing GitHub Issues, but the libraries and tools around issues were mostly crap, so I stopped. But I'd love to get a generic tool together to manage issues using single lines in a text file (such as code comments, or Markdown lists), such that editing a line in the file causes the tool to create, update, close, or delete issues. Infrastructure as Code, but for issues/tickets.

You could then script pre-commit or pre-merge hooks to create issues for TODOs on the fly, and later on have a job skim though code and delete TODO comments whose issues had been closed. Extend it to use Jira and you can use it at work, too.

</comment><comment><AUTHOR> For anyone interested, I wrote a piece last week taking a look at the 2k+ TODOs in the Kubernetes source code as well: [https://medium.com/@augmentable/looking-at- kubernetes-2k-tod...](https://medium.com/@augmentable/looking-at- kubernetes-2k-todo-comments-b2db42dc7fdb)

Most were from over a year ago.

I don't think TODOs are bad practice, and I've seen a diversity of opinions on them in the comments of various posts. I think they are notoriously forgotten, and major codebases like linux and k8s are no different.

Aggressively stale TODOs though are likely an indicator of an area of code that should probably be revisited or cleaned up.

</comment><comment><USER53> The 'many from over a decade ago' part shows one problem with TODO comments. Very often these TODOs are never done. Really, TODO comments should not exist. When you are writing some code is the point when you know most about it and is therefore also the best point to write code of optimal quality. Also, for some TODOs I encounter in the wild I cannot really shake the impression that the author is showing off by suggesting something that sounds smart but actually is impractical and should never been done.

</comment><comment><USER54> At a former work we had points for what got added, fixing TODOs was worth 2 points IIRC. We were a small team and people were all good - probably wouldn't work in every situation.

</comment><comment><USER55> Meta: What's up this the URL on this post? The URL is just to the root of Linus' kernel repo on github, the HN sitebit is 'tickgit.com', but from the comments I figured out the actual submission is supposed to be sourcegraph.com and that nobody else seems to have any issue getting there?

[https://i.imgur.com/QAYtrVB.png](https://i.imgur.com/QAYtrVB.png)

<comment><USER56> On my end the URL is [https://todos.tickgit.com/browse?repo=https://github.com/tor...](https://todos.tickgit.com/browse?repo=https://github.com/torvalds/linux)

Perhaps your problem is caused by some browser addon.

</comment></comment><comment><USER57> Out of curiosity, I grabbed a copy of the repository and did some basic searching.

        $ egrep -icr "\bTODO\b" * | tr ':' '\t' > ../todos
        $ cat ../todos | awk '{sum+=$2;} END{print sum}'
        6372
        $ grep "^Docum" ../todos |  | awk '{sum+=$2;} END{print sum}'
        1172

So roughly 18% are in Documentation. The biggest culprit is [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/features/debug/user- ret-profiler/arch-support.txt) , because user-ret-profiler appears to only support x86. All other architectures are in as TODOs

        $ cat ../todos | sort -n -k 2 | tail
        Documentation/features/debug/user-ret-profiler/arch-support.txt 24
        drivers/media/dvb-core/dvb_ringbuffer.c 26
        drivers/platform/chrome/cros_ec_spi.c   33
        drivers/media/dvb-frontends/drx39xyj/drxj.c     34
        drivers/media/pci/ttpci/av7110_av.c     34
        net/ieee802154/nl802154.c       35
        drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c     40
        drivers/android/binder.c        48
        drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c       51
        drivers/net/wireless/broadcom/b43/phy_n.c       54

The biggest single-file culprit for TODOs is in the broadcom b43 drivers, [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/broadcom/b43/phy_n.c). From what I can clean from phy_n.c, it looks like it's because the linux kernel can't handle revision 19. There's a lot like:

         if (dev->phy.rev >= 19) {
          /* TODO */
                } ...

or

        static void b43_nphy_tx_cal_radio_setup_rev19(struct b43_wldev *dev)
        {
         /* TODO */
        }

</comment><comment><USER58> I always write TODO statements with a number from 1 to 4, indicating the severity.

1 is immediate, meaning it needs to be fixed for the system to work.

2 is something that should be done before release.

3 is a near term wish list sort of thing, and

4 is a hopeful, probably never sort of thing

In addition, another place I deviate from the norm is when I comment out code, I write the reason why it's commented out.

These two things really help keep my code from becoming incomprehensible as time passes.

<comment><USER59> That sort of convention sounds fine for a solo project, but I think if you have more or changing developers then it would make things more confusing.

</comment></comment><comment><USER54> From my time as a consultant I started doing some TODOs with a view to when I would be off of the project, for example there was code in a place that I knew would be not necessary due to changes at a certain time in the future I would put in a TODO because there was a chance I wouldn't be there when that code needed to be removed or changed. Who knows if anyone ever heeded them though.

</comment><comment><USER60> The number of FIXMEs seems about half of that, from a quick glance.

FIXMEs : [https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torva...](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/torvalds/linux%24+FIXME.*%5C:+case:yes+count:1000&patternType=regexp)

</comment><comment><USER61> I've never seen "TODO" / "FIXME" sections ever being eventually done/fixed. Never.

</comment><comment><USER62> Most anything you do, in general, will fork off into many branches. Some being required dependencies and many others being tangential improvements or generalizations.

You can either note them in some way as they emerge, or ignore them and keep your code tidy of such notes.

</comment><comment><USER63> I'm curious to learn how this is with other large codebases, or operating systems at Apple and Microsoft. I imagine the amount of open bugs or todo's will be much larger, many also from decades ago with no chance of ever being touched.

</comment><comment><USER64> Link not working for me. I'm getting this:

Error: Network error: Origin [https://todos.tickgit.com](https://todos.tickgit.com) is not allowed by Access-Control-Allow-Origin.

</comment><comment><USER65> Hilarious! I remember working on early Unix OS implementations in the 80s. When I saw all the TODOs and NEEDSFIX and WHOKNOWSWHAT I was thinking "How do I make any mods to this?"

</comment><comment><USER66> Well hopefully TODO compilation will be in the next C++ standard.

</comment><comment><USER67> Isn't this a nice case against comments in code? Everything that your compiler can't parse is a waste of time. Where is #todo if you need it?

</comment><comment><USER68> Let's add one not to forget reducing their amount

</comment><comment><USER69> It could be a red flag or nothing depending on the development culture around the project and how they assign meaning to these comments.

</comment><comment><USER70> If you think that is horrible, let me tell you a story about the opposite approach:

There is very successful company, let's call them "LEG", that makes computer thingies. In order to improve customer confidence, "LEG" has adopted a very strict release policy: all instances of TODO, FIXME, BUG and ERROR are removed before a release.

If you have a variable called "error", automated tools will flag it and you will have to explain to your boss why you could not have used any other name.

<comment><USER71> Which makes sense. Why are you making a customer release with outstanding TODOs/FIXMEs/BUGs/Whatever in the code? Are there things left to do? Are you delivering something incomplete to the customer while saying it's bug free and feature complete?

You need to make a decision whether to actually fix what you intended to fix or to judge that it's not relevant anymore.

The script is letting you know that there are outstanding things in the code that might have been forgotten. If you are the owner of those TODOs and choose to just delete the comment in order not to have any extra work, then maybe someone in your company should review your presence there.

<comment><USER70> Let me clarify: they are not fixing the issues, just hiding them from customers.

Are these important issues that should have been fixed or just small good-to- have things? The answer is: yes

</comment></comment></comment><comment><USER72> I have in similar no. o TODO in a 3 yr old codebase. And also 100s of warnings: "Don't touch if it's working"

</comment><comment><USER73> 3k TODOs in a vital opensource project. Why? Lack of funding or lack of coders or Linus/Stallman(FSF/GNU, who has resigned but is he replaced?) is unable to be everywhere and he need a bigger team to support him? What is the "news" here? Is it a warning to avoid Linux's possible "Heartbleed" type issue?

</comment><comment><USER74> Might these present an opportunity for those wanting to contribute?

</comment><comment><USER75> I'm amazed it is that low.

There's always stuff that wants doing, but not just now. Except now doesn't come, and those todo notes, like most comments, get ignored forever, peoples' eyes skipping straight over them like they were never there.

</comment><comment><USER76> I guess all the FIXME and HACK have to be addressed first :)

</comment><comment><USER77> I think Students could use them as homework/assignment

</comment><comment><USER78> later means never :)

</comment><comment><USER79> todo's are often for future perf or better ways of doing the same thing. Would be nice if todo's were annotated with a category.

</comment><comment><USER80> How many in the Windows or Mac codebase?

<comment><USER81> I'd also like to know. It could be a nice addition to this paper, in case of an update:

[https://blogs.msdn.microsoft.com/iliast/2008/05/16/code- qual...](https://blogs.msdn.microsoft.com/iliast/2008/05/16/code-quality- windows-vs-linux-vs-freebsd-vs-solaris/)

</comment></comment><comment><USER82> Error: GraphQL error: connection error

<comment><AUTHOR> Sorry about that! Didn't realize this would hit the frontpage, infra should be upgraded!

</comment></comment><comment><USER70> TODO: do something about all those TODOs in our codebase.

This could make an excellent XKCD.

Edit: to turn this into a more useful comment, let me add that TODO is an important component of test-driven development. If you read Kent's original example with Fibonacci you will note that he splits the functionality into multiple small milestones.But unlikes traditional waterfall these appear organically as TODOs in the test and implementation code as things progress.</comment>


Google and Amazon are punishing their own customers in a bitter feud - <AUTHOR> https://www.theverge.com/2017/12/5/16738752/google-youtube-amazon-punishing-customers-feud <comment><USER2> > Amazon has just responded to Google's decision to remove YouTube from all > Fire TV products

I'm sorry - is amazon prime video available on my chromecast now and I've missed it?

These guys are bloody hypocrites.

(edit: meant to say 'prime video' on chromecast, previously it just said prime)

<comment><USER3> > I'm sorry - is amazon prime available on my chromecast now and I've missed > it?

It used to be (well, Amazon Prime itself not, but they were working on it, and the Netflix app on Kindles did support it), until Google started constantly changing the (proprietary) protocol to prevent anyone else from implementing it.

Currently, the only way to stream to Chromecast is with Google's proprietary library, which they only license under the Android OEM terms (meaning you have to ship ALL Google apps, set them as defaults, and can't run your own App Store).

This has also completely killed all open source projects that tried to support the Chromecast protocol.

<comment><USER4> >Currently, the only way to stream to Chromecast is with Google's proprietary library

At some point the cast extension became a part of the browser. It also stopped working with chromium around the same time. However, it started working again a while later. My chromium on ubuntu can use the cast button. I wonder if it's falling back to chrome's proprietary bits (as in flash, widevine etc.) or if it's actually in chromium. The cast button in the browser is not the same as native chromecast support, but it's something.

</comment></comment></comment><comment><USER5> I'd been debating which one to get, Amazon stick or Chromecast. This settles the debate. I'll download and watch, as before.

<comment><USER6> This is why I got a Roku device

<comment><USER7> I recently bought a Roku, since it was one of the few devices that had an app for Twitch.tv. Little did I know, Amazon recently bought Twitch and yanked their app from the Roku channel list. They are clearly trying to redirect people to their own streaming devices. Yet another content provider with a conflict of interest...

</comment></comment></comment><comment><USER8> Is this going to trouble Google's antitrust problems in Europe? "You better carry nest or we pull YouTube." Seems kind of similar to Microsoft's 90s era "You better only carry IE or we cut you off or charge you a lot more."

<comment><USER9> How? "You better install Amazon's app store, or no Amazon Prime Video". "You let us access YouTube on Fire devices, but we won't sell Chromecast & Google devices on Amazon.com" \- Coming from the monopoly in online retail, looks very much like an anti-trust case.

<comment><USER10> Prime video example does not fit, as Amazon does not have a monopoly neither on video, nor on App Store. It would only be illegal, if Amazon App Store would be a monopoly, and its installation would require additional installation of Prime Video app (hello, Google).

</comment></comment></comment><comment><USER8> I think these are different issues over different products.

Google should take the high road and keep YouTube available as broadly as possible. YouTube shouldn't care about Nest product availability.

This would be similar to CBS blocking Wal-Mart mentioned in shoes because they wouldn't sell Westibghouse TVs.

The reprisals aren't similar.

The scary bit is that it reenforces that Google doesn't view the internet as open. Could you imagine YouTube blocking the Opera Browser? They shouldn't try to bundle services unnaturally.

</comment><comment><USER11> In other words, Amazon is about to start selling thermotasts.

</comment><comment><USER12> This is the kind of thing that regulators need to crack down on ASAP. This balkanization of the Internet is terrible for consumers.

</comment><comment><USER13> this kind of shit is why i just download all of my media. music, tv shows, movies, they're all easy to download and then i can play the back on whatever device i please with no restrictions

</comment><comment><USER14> This kind of behavior is why I recently steered a friend to a Roku. With any of the streaming devices (Amazon, Google, Apple) you risk losing out due to dueling between the major tech companies.. The major players tend to leave Roku alone since it's a 3rd party service that doesn't compete with them.

So I'm throwing my bet towards Roku since it's the only device that can survive a pissing match between all the tech companies.

</comment><comment><USER15> Is this also why Amazon refuses to sell the Google Home?

<comment><USER16> Yes

</comment></comment><comment><USER17> I know this is probably more of a shared bad behavior situation, it really frustrates me as Google did more or less the same thing against Microsoft. Dunno, feels like if they could silo their services away from every other platform at this point without hurting themselves, they would.

</comment><comment><USER18> The YouTube block is surprising at all. Google did the same thing with Windows Phone.

</comment><comment><USER19> While this is framed as a feud, I don't think that's actually the case.

Nest products have had a lot of public criticism, and I suspect amazons internal numbers might show high return rates and high levels of user fraud.

It could also be that amazon wanted a higher margin on the devices than Google was happy to give.

<comment><USER20> Either of those would be understandable reasons for Amazon not stocking Nest products. Given that they have not publicly explained their decision it seems fair to assume their behaviour is as claimed in the article.

Children squabbling.</comment></comment>


"If he doesn't work out, you can take his salary out of my bonus" - <AUTHOR> http://alexpotato.com/blog/if-he-doesnt-work-out-you-can-take-his-salary-out-of-my-bonus/

<comment><USER2> Hiring freezes issues by the top management can be weird. A department will start hiring a person as contractor (different budget) or the person gets hired by their PR agency who conveniently raises their monthly invoice (different budget). I've also seen an intern salary getting paid by a vice president out of his salary. It is worse in publicly traded companies.

</comment><comment><USER3> Good close. I have seen the "have a strong network" pay off over and over again.</comment>


Simple, Upstream, and Decisive: A Heuristic for Medical Progress - <AUTHOR> https://www.sarah-constantin.org/blog/2018/1/14/simple-upstream-and-decisive-a-heuristic-for-medical-progress <comment><USER2> Molecular biologist professor at a med school here. This is what people are already doing. This reads as someone who doesn't know the field very well.

<comment><USER3> > This is what people are already doing.

Is that what _everyone_ is doing? In molecular biology? In medicine more broadly?

From the last paragraph:

> If some approaches to cancer research are much more likely to work than > others, but the scientific community systematically favors the unsuccessful > approaches, then the difficulty of curing cancer isn't just a lack of low- > hanging fruit, it's a strategic problem.

<comment><USER2> > the scientific community systematically favors the unsuccessful approaches

The scientific community doesn't systematically favor unsuccessful approaches. Again, if the author was in the field they would know that's not true.

</comment></comment></comment><comment><USER4> I complained yesterday that a lack of contrast in text makes it hard to read. This blog has to be the worst offender I've seen. It not only uses grey text on white, but it also uses opacity to render the top navigation nigh invisible.</comment>


Usercorn – a versatile kernel+system+userspace emulator - <AUTHOR> https://github.com/lunixbochs/usercorn <comment><USER2> One of the many practical neat things you can do when you're emulating all the software of a machine, is visually analyzing memory relatively easily: [https://www.youtube.com/watch?v=25nLk1Z8wd0](https://www.youtube.com/watch?v=25nLk1Z8wd0)

</comment><comment><USER3> Author here. Usercorn at a basic level is like qemu-user in that it can load a userspace binary like ELF, MachO, etc into a CPU emulator and provide a syscall emulator interface.

It's built as an API that allows instrumentation of the resulting binary. You can hook instructions, basic blocks, syscalls, memory access... You get information like stacktraces in a cross-platform manner. There are helpers to compute and display diffs of memory and registers throughout execution.

There are many differences from qemu-user:

\--

Usercorn attempts to emulate several OS/syscall ABIs all from one binary (Linux, BSD, XNU, CGC, more to come like Redox, maybe weird stuff like Windows and DOS). qemu-user just translates arguments to your host kernel so to run a Linux binary you need a Linux host. qemu-user also has a different binary for each arch, like qemu-i386 and qemu-arm. The primary usercorn binary can emulate every single supported OS/arch combination and aims automatically detect the correct arch/kernel when you run a program.

Usercorn is being built as a framework around the Unicorn Engine. It's not just a way to run a binary on the command line. It can be loaded as a library (`NewUsercorn("binary").Run(args, env)` will run an arbitrary supported app). It allows hooking many things and I've been building a lot of features around static trace/analysis. I'm extremely excited about some of the features and supporting tools I have planned.

This twitter thread shows examples of a tool called imgtrace I built with Usercorn. imgtrace can visualize memory writes done by a program. The Hilbert curve view of MD5 is nice, as it makes the memory containing the internal MD5 state as well as the iterators very obvious at a glance: [https://twitter.com/lunixbochs/status/717945725024280578](https://twitter.com/lunixbochs/status/717945725024280578)

The underlying code of imgtrace is also extremely simple (basically all of it is to create the image data), which shows off the power of Usercorn's simplicity: [https://github.com/lunixbochs/usercorn/tree/master/go/cmd/im...](https://github.com/lunixbochs/usercorn/tree/master/go/cmd/imgtrace)

Usercorn is much less mature than qemu-user. It supports around ~50/400 Posix syscalls and is missing many architecture-specific features. Some architectures still need work on memory segmentation and thread-local storage. I've split up functionality internally in a way that makes sense, but I'm still building the base functionality and haven't designed the public API at all yet (even though it's possible to use Usercorn from external code, that's just happenstance due to the functions/types I exposed while building it).

\----

Architecture support is tied to Unicorn. Usercorn supports x86_64 best, and has various levels of support for ARM, MIPS, sparc, and m68k.

It's still very much WIP, but can run many binaries at this point, even Linux binaries dynamically linked to glibc. Host support is best on OS X and Linux. Guest support is best on Linux.

<comment><USER4> Wow this is seriously cool. Took a while of going through it and the links to Unicorn to understand what it was (your top level comment wasn't up yet).

I think this snippet from your Examples section sums it up best:

        usercorn bins/x86.linux.elf
        usercorn bins/x86_64.linux.elf
        usercorn bins/x86.darwin.macho
        usercorn bins/x86_64.darwin.macho
        usercorn bins/x86.linux.cgc
        usercorn bins/mipsel.linux.elf

<comment><USER3> That only explains the qemu-user part. The ability to run binaries in Usercorn is just a means to an end - I want to build tools in the vein of `maybe` (VFS layer will make this easy, and so much safer), `imgtrace`, `strace`, and some stuff that's 1000x more ambitious than these.

Running binaries is just... I'm recreating the universe so I can change just a few things, like logging memory access or doing taint analysis.

This is similar to tools like DynamoRIO, DrMemory, PIN, valgrind, but it not only covers all of those spaces, I could probably spend a few hours listing interesting stuff outside those scopes I want to build on Usercorn (for example, you could ignore the CPU emulation part of of Usercorn and use just the kernel emulation interface to implement the Linuxulator or Windows10+Linux compat layer natively for an OS).

I'll probably write real docs sometime after a proper API, but both are lower priority than core features atm.

</comment></comment></comment><comment><USER5> Unicorn engine home: [http://www.unicorn-engine.org/](http://www.unicorn- engine.org/)

<comment><USER6> Is Unicorn a fork which will eventually grow into another Qemu or just a fork to remove stuff and make it into something else that doesn't have the same goals. I'm confused because the website on the one hand says it's less functionality but then also that it does more than qemu. So which is it? Or is it just that they provide bindings and an API which they tout as "more than qemu".

<comment><USER3> Unicorn is a massive patch on top of QEMU 2.2 [1] that approximately does the following:

\- Removes a couple of architectures (because they're not supported yet for hooks/register access).

\- Removes hardware support, as well as the qemu-system and qemu-user targets.

\- Modifies the JIT and all supporting APIs to not use globals. This allows you to compile JIT support for more than one guest architecture into the same binary, as well as run more than one instance of the JIT at once (so you can emulate two CPUs in parallel, even of different architectures).

\- Adds a hook infrastructure to call callback function(s) with metadata on many different events, including memory access, memory fault, interrupt, basic block entry, instruction execution (so like per instruction address). These calls are inserted into the JIT stream only when you add a hook, so they're reasonably efficient.

\- Adds register read/write APIs (this is actually a ton of code in the form of a switch/case table for each arch)

\- Exposes all of this using a simple C library / API:

        uc_open(arch, mode)
        uc_mem_map()
        uc_mem_write/read()
        uc_reg_write/read()
        uc_emu_start/stop()
        uc_hook_add/del()

[1] I'm currently porting it to QEMU 2.5 because I need _one new ARM NEON instruction_. This is probably overkill, but it's a good cause.

<comment><USER6> Thanks for the detailed explanation. Does that mean it's not a replacement for QEMU and not intended to be?

Regarding qemu-user and qemu-system, I've had bad luck with it all the time. In 2.5-rc2 I got qemu-system-x86_64 but when I build 2.5 with the same configure flags, I don't get qemu-system-x86_64 at all. You wouldn't happen to know how to work around that, would you? As I use it just for kvm functionality for vms, I configure it like this, but qemu-2.5 final's build system seems to be broken.

        --target-list=x86_64-linux-user
        --enable-pie
        --enable-seccomp
        --enable-curses

The last known version that was able to build qemu-system-x86_64 is 2.4.92.

Any idea?

<comment><USER3> 1) It really depends on the features of QEMU you use. Unicorn and friends could eventually support every feature of QEMU, but currently are nowhere near that. Usercorn should be able to replace qemu-user eventualy.

2) You should really go to the QEMU team for support on that.

<comment><USER6> 2) Seems like the configure (and/or build) script was broken at some point. Letting it build all targets does not omit the amd64 kvm executable.

1) But I don't really understand the end goal if you're always forking of the next qemu relese to patch stuff back in. Is there no interest in qemu upstream for those features? I've seen it for the first time 2.6-rc, so is qapi some kind of API you might adapt or is it too limited?

<comment><USER3> At this point Unicorn is a hard fork with a very specific goal. It accomplishes this goal much better than upstream QEMU. I believe combined TCG / no-globals should be upstreamed (I think I actually saw commits in 2.5 about supporting multiple architectures in one QEMU binary?), but I don't know if anyone working on Unicorn has talked to anyone upstream about this.

I believe Unicorn also contains QEMU bugfixes.

To me, in an ideal world, we might have something like this:

libqemu-cpu - Basically Unicorn. C library/API to easily create/hook/manipulate one or more CPUs.

libqemu-system - All hardware/peripheral support from QEMU. Attach any component(s) to a supported CPU at runtime.

libqemu-user - The current qemu-user, except as a library with syscall/whatever hooking support. There'd probably be a good amount of code generation here.</comment></comment></comment></comment></comment></comment></comment>


Show HN: Recruitly – A simplified recruitment process - <AUTHOR> http://recruitly.co/ <comment><AUTHOR> Greetings,

We are trying to simplify the recruitment process with this platform. Our system halves the number of interviews by a selection of the most appropriate candidate(s).

Kindly provide any feedback you may have. It will be greatly appreciated.

All the best, Recruitly Team</comment>


Ask HN: Learning CS theory from preprints - <AUTHOR> A standard CS undergraduate curriculum teaches core subjects like computer architecture and networking. With the bevy of freely available CS preprints on such topics on sites like arXiv.org would it be possible for a highly motivated individual to learn the theory just from preprints? I'm wondering the same for the field of math, economics, or any other technical field. I haven't read that many papers but my intuition is that the background section often attempts (sometimes effectively, othertimes not so much) provide the context and vocabulary needed to understand the core theoritical aspects of the paper.<p>As an example to flesh out my question, for say the topic computer architecture - can we stitch together enough preprints (given the corpus of whats available on arXiv - not sure if they have all the important CS papers) so that if they go through them they could learn everything theoritical that is learned in an undergraduate or graduate computer architecture course. <comment><USER2> No, not at all. Even a standard CS curriculum doesn't teach enough in the required classes to give enough context to fully understand the preprints in the two subfields you used as an example. An important part of academic research is understanding the topic of a paper within the context of other current and previous work. It's very challenging to start at the end and work backwards when you don't have a solid grounding in the fundamentals.

</comment><comment><USER3> The problem is that many preprints are hit of a very high quality.

You'd be better off obtaining basic literature from books and then grabbing research papers off scihub.

</comment><comment><USER4> As a general rule, no. A lot of the preprints assume a detailed (grad level) understanding of the problem and they explain just enough to frame the problem in order to introduce their solution. I wager someone going down this path would get frustrated quite quickly.

</comment><comment><USER5> I think text book and library is better option. [http://hunet- hr.com](http://hunet-hr.com)

</comment><comment> a-saleh If I were you, I would instead go to a local university and go through their library.

</comment><comment><USER6> A textbook is cheaper and collated.</comment>


Show HN: Another JS framework - Backbone with HTML5 states - <AUTHOR> http://vpj.svbtle.com/another-js-framework

<comment><USER2> This has the same name as a hygienic macro system from Mozilla. I skimmed the headline and thought this link might have something to do with it.

<comment><USER3> I thought the same thing. [http://sweetjs.org/](http://sweetjs.org/) for this interested in the Mozilla project.</comment></comment>


A new Operating System - <AUTHOR> https://github.com/TusharPardhe/ <comment><USER2> Yet another generic linux distro. Nothing interesting.</comment>


Watch Car Thieves Steal a Tesla Model S in Under 30 Seconds Using a Relay Device - <AUTHOR> https://www.thedrive.com/news/29517/watch-car-thieves-steal-a-tesla-model-s-in-under-30-seconds-using-a-relay-device <comment><USER2> Previously on Hacker News ...

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

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

Additionally:

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

[https://news.ycombinator.com/item?id=20772161](https://news.ycombinator.com/item?id=20772161)</comment>


Server hack prompts call for cPanel customers to take "immediate action" - <AUTHOR> http://arstechnica.com/security/2013/02/server-hack-prompts-call-for-cpanel-customers-to-take-immediate-action/ <comment><USER2> Some more details here too:

[http://blog.sucuri.net/2013/02/cpanel-inc-server- compromised...](http://blog.sucuri.net/2013/02/cpanel-inc-server- compromised.html)

thanks,

</comment><comment><USER3> The discovery of successful attacks is starting to have a serious drum-like cadence...</comment>


Host everything for free (almost) - <AUTHOR> http://engineering.talis.com/articles/host-everything-for-free-almost/

<comment><USER2> Since you are already on Heroku, NewRelic in combination might be a good idea. Their free tier can monitor DB loads, uptime, exceptions, response times, slow methods and what not.</comment>


Bloglines is shutting down. End of an era. - <AUTHOR> http://blog.ask.com/ <comment><USER2> I've been using RSS readers in some form for more than 10 years now, and used Bloglines intensively from 2003-2007. I ditched it when NetNewsWire went free with syncing and I realized I had Macs at both home and work. I ditched NNW for Google Reader 2 years ago when I switched back to Linux most of the time, since the web version was terrible.

I remember trying Google Reader periodically after it came out, and it was _awful_ compared to Bloglines. It took them years to just duplicate the basic functionality. It's much better now on most fronts now after a couple more years of iteration, though their feed management stuff still sucks.

</comment><comment><USER3> The feed reader is my primary window into the web. I used to use Bloglines until they got unbearably unreliable some 2 years ago. I host my own Tiny Tiny RSS (<http://tt-rss.org/redmine/>) since then and can highly recommend it.

</comment><comment><USER4> Like so many others I was an avid bloglines user for years. I didn't even _like_ Google Reader during it's early years. The user experience on bloglines just seemed to get worse and worse, and eventually I had to switch.

</comment><comment><USER5> I, for one, will be sorry to see it go. I thought their beta version (which has been in beta for years, natch) was quite nice.

Anyone have any ideas for replacements (other than Google Reader, which leaves me unimpressed?)

</comment><comment><USER6> I switched to Google Reader a couple of years back, and never regretted it.

I was a bit sad at the time, but they kept having uptime problems, and I wasn't willing to put up with it endlessly.

</comment><comment><USER7> I was an avid Bloglines user back in the early 2000s. I remember loving the product so much that I emailed them asking how I could pay for it. I got a reply saying they were still figuring out how to make money.

I wonder now if they ever did get around to charging for the service.

<comment><USER8> No, they didn't charge for the service, they only showed ads on the start page.

</comment></comment><comment><USER9> I still have my free "I <3 Bloglines" T-Shirt. Guess I can just use it as a grease rag now...

</comment><comment><USER10> Dare I say it? Good.

Bloglines has been a crappy product and user experience for years, and I honestly don't think that Google Reader is that much better (anymore -- used to be awesome).

I much disagree with the assertion that RSS is dead, or even that RSS aggregators are dead/dying; I just think that Bloglines (and others) have really crappy implementations of what a news reader ought to do. Frankly, I always though that treating RSS feeds as email was the wrong way to go.

<comment><USER11> What do you use?

<comment><USER12> I'm not sure about the OP, but I use Fever:

<http://feedafever.com/>

You have to host it yourself, but after using it for five minutes it proved to me that it is was more than worth the $30.

<comment><USER13> Thanks for this recommendation. As a Bloglines user for years who has tried and failed a few times to like Google Reader, Fever seems to be exactly what I am looking for. It took some time to get everything up and running on my server and configured, but is a solid application and agree it is more than worth a one time $30 fee.

Particularly interesting is its concept of Sparks (a.k.a. RSS feeds with a high volume of posts that you wouldn't subscribe to normally.) Fever uses them to help "feed the fire" and surface the most relevant/interesting content from the publications you do subscribe to.

Also works very well on the iphone. These are just first impressions but so far I'm pretty impressed.</comment></comment></comment></comment>