Yahoo Pipes - <AUTHOR> https://en.wikipedia.org/wiki/Yahoo!_Pipes <comment><USER2> A couple of fun behind the scenes stories which I think at this point are past the statute of limitations.

Source: I was the Service Engineer on pipes for around a year or so.

1) When you went to the pipes landing page, there were a few demo pipes to show people what was possible. One of them combined search results from say ebay/craiglist/amazon to show prices for things.

One day I was looking through the source of these, and noticed there were affiliate ids in the ebay/amazon links. They all belonged to some early team member who had long since left.

I showed a couple people on the team, we all guessed at how much they were making from this, said good on em and went about our day. I still wonder how much they ended up making from it.

2) It was my first on-call, and all of a sudden the west coast pipes cluster just went bananas. After ~5 minutes, east coast started to go nuts and the west coast subsided.

Someone, despite numerous defensive measures, had found a way to create a pipe-bomb that would recursively call multiple versions of itself. Once the west coast load balancer failed over, one of these requests would hit the east coast and the 'virus' would jump over there. This flipped flopped back and forth until I figured out how to blacklist pipe ids (and eventually got a code fix).

<comment><USER3> Heh... just chiming in to say the affiliate person wasn't me :-)

<comment><USER4> I wish it was me. That's genius.

</comment></comment></comment><comment><USER5> As a fresh Yahoo! Developer Network employee I was the person who blabbed about the top-secret _callback parameter the weekend Pipes launched, which caused the service to be taken offline for capacity upgrade.

I had an interesting series of voicemails, ranging from "dude, WTF?" to "okay, we need to talk to you right away" to "we're pretty sure you're fired" but ending with "hey, Tim O'Reilly picked it up and ALL IS FORGIVEN THANK YOU!!!"

[https://web.archive.org/web/20070302201929/http://developer....](https://web.archive.org/web/20070302201929/http://developer.yahoo.net/blog/archives/2007/02/yahoo_pipes_sud.html)

<comment><USER6> What were the implications of knowing the _callback parameter?

<comment><USER7> You could invoke pipes from any webpage without worrying about cross-domain access.

If you look at some janky JS code[1] I had on my website at the time, you can see what you can do with it.

That would basically source

://pipes.yahoo.com/pipes/pipe.run?_id=7CTRtbtL3BGX_AHbjknRlg&_render=json&_callback=load_daily_show

as a static asset in my page, which would load the JS and call load_daily_show(<json>) as a result.

Now, _EVERYONE_ who hits my page is invoking the pipe as a backend API call, with no caching and unfortunately with the entire Y/T cookies intact.

[1] - [https://web.archive.org/web/20081007043923/http://t3.dotgnu....](https://web.archive.org/web/20081007043923/http://t3.dotgnu.info/code/j002ube/)

<comment><USER8> Yeah I remember using it as a CORS proxy, it allowed me to put together a full client side music app (tracks source was not very legal) but tags, similar tracks/artists etc were pulled from lastfm and allowed to quickly build a decent playlist.

</comment></comment></comment></comment><comment><USER9> I used Yahoo! Pipes in a somewhat greyhat way. I started pulling in data from Reddit's RSS feeds for certain subreddits and using that to create and post content for fairly spammy Twitter, Tumblr and Facebook pages. I'd parse the titles (for example, change things like "cake day" to "birthday") and adding hashtags at the end.

You could ensure only top content made it by setting a minimum karma limit. It was a way of producing content 24/7.

I only did a couple of trial pages to test out the concept -- I never made any money from it nor had any intention to monetize -- but I'm almost completely certain that it was a method used by dozens of blackhats to make autoblogs for the purposes of ad revenue. You could even fake a comment history or have a "unique" title by selecting the top comments from the Reddit posts. Once you have one recipe down, you can just copy it for other subreddits. And there was an endless amount of hyper-focused niche subreddits that you can instantly plug into.

Fun times.

<comment><USER10> People are still doing this, only now it's reddit -> instagram.

<comment><USER11> Not to mention Reddit -> Reddit I'm amazed at how successful some crosspost bots are.

</comment></comment></comment><comment><USER12> I was at the O'Reilly Emerging Tech conference session that functioned as (what I remember to have been) the Pipes launch party. Everyone involved with the project seemed young and full of optimism, and while they didn't know exactly how Pipes would make money, I remember being as impressed with the UI as I was the forward-thinking ideas that motivated the project. Keep in mind that in 2006, IE 6 was still omnipresent so the fact that they had a usable drag and drop interface running put it in rarified air along with other UX trailblazers like Flickr and DabbleDB.

To this day, I am still bewildered and not just a little angry about how Yahoo's entire M&A machine was really just a catch-and-kill trap for taking the most promising ideas out of the ecosystem and slowly resource starving them into irrelevance.

<comment><USER13> I remember that ETech. Back when Yahoo was doing a bunch of things that were cool and not profit-driven, like FireEagle.

In a lot of ways that tech was all ahead of its time. It's a shame the monetization schemes weren't similarly evolved. If it were, Yahoo may still be more relevant today.

<comment><USER12> I met one of the FireEagle devs there, at the same ETech event, and he was a really great person. We proceeded to bump into each other a few more times over the years, specifically at the Ajax Experience conferences. He really tried to convince me that Yahoo wasn't all that bad, although he eventually did have to move on.

As evidenced by the previous paragraph, I've forgotten his name which makes it exceptionally difficult to reconnect.

Consider this a HN "missed connections" attempt. ;)

<comment><USER5> Possibly Tom Coates?

<comment><USER12> Damn, that is a great guess that is so close it hurts: you've made me confident that I'm mis-remembering enough to think I'm actually talking about the FireEagle launch event. The Pipes demo was a different session, possibly a year or two earlier.

Either way, the person I am doing a laughably poor job of describing was at the FireEagle event but I definitely remember him being a peer/coworker of Tom's - he wasn't the center of attention that day.

Sigh.

<comment><USER5> Maybe check Tom's leaving-Yahoo post? There's a paragraph listing a bunch of the devs:

"So I want to personally thank Seth Fitzsimmons, Samantha Tripodi, Jeannie Yang, Chris Martin, Ben Ward, Kevin Ryan, Phil Pearson, Rabble, Arnab Nandi, Simon King, Mor Naaman, Ayman Shamma and everyone else who worked on Fire Eagle at any point in its life. I learned an enormous amount from all of you."

[http://plasticbag.org/archives/2010/05/my_last_day_at_yahoo](http://plasticbag.org/archives/2010/05/my_last_day_at_yahoo)

</comment></comment></comment></comment></comment></comment><comment><USER3> Thanks for posting and the nice comments. Glad to have built something that people found useful...

<comment><USER14> It feels like Zapier and IFTTT are the successors to Pipes, but I never quite got the same feeling from them (maybe I haven't checked Zapier in a while). But Pipes was ahead of its time and I'm still not sure of anything that really comes close to what I could do with pipes even back then. Thank you.

<comment><USER15> Integromat [0] somewhat approximates Pipes. Haven't heard as much about it as IFTTT and Zapier. I found it because they've got one of the few remaining active API integrations with RunKeeper, which since closed the door to new application registrations.

[0] [https://www.integromat.com/](https://www.integromat.com/)

</comment></comment></comment><comment><USER16> Yahoo pipes was really fun and great, and I was happy that someone besides Google was still innovating in an exciting way. I remember being very sad when Yahoo Pipes was finally unplugged. That day I realised that the web is not about users, not about building fun and useful things, not about building lego-like structures, it's just filter bubbles, echo chambers and troll farms.

</comment><comment><USER17> Oh boy do I remember yahoo pipes. I used it heavily for some time. I always suspected their servers were under massive load running all their jobs so sometimes things were slow.

Pipes made you think the future of the web was going to be technical and brilliant.

<comment><USER18> >Pipes made you think the future of the web was going to be technical and brilliant.

Oh well, that was at least half right.

</comment></comment><comment><USER19> I was a big user of Yahoo Pipes for preparing custom RSS feeds.

I have now found that [https://feedity.com/](https://feedity.com/) does a good enough job scraping pages to produce feeds. I then run that through [https://fivefilters.org/content-only/](https://fivefilters.org/content-only/) to fetch the full content of the page and read it in [https://www.inoreader.com/](https://www.inoreader.com/), my favorite Google Reader clone.

Some people are amazed that I am always on top of new content they produce.

<comment><USER20> Hey Dan, Feedity's founder here. Thank you for using our feeds service! Just so you know, besides HTML webpages you can also create feeds for dynamic webpages with client-scripts, as well as social media profiles.

</comment></comment><comment><USER21> Pipes was _awesome_. I built many personal services with it - (and even a few low traffic production services!)

Really tragic they killed it, that's when I knew the Mayer era of Yahoo would be nothing more than a hatchet job.

I wish they made it F/OSS as part of the shutdown. Nothing has filled the void.

<comment><USER22> As someone who just briefly used Pipes for a couple of things and don't remember the service fully: What unique features of Pipes do you remember that nothing else been able to replicate?

<comment><USER23> A drag-and-drop engine for building extract/transform/load machines that ran in the cloud at no cost?

You could make HTTP REST requests to pretty much anything and parse the result and do whatever you wanted with it.

You could use Yahoo pipes to glue APIs together.

If you were the creative sort, the possibilities were endless.

Can _you_ name another product currently on the market that can do that?

<comment><USER24> Node-RED?

<comment><USER23> Oh wow! You are right! This is very similar. Thanks

</comment></comment></comment></comment></comment><comment><USER25> Ah pipes. Thanks for the memories of a product that both came and went before it's time. And technologically an amazing frontend web app. There is an attempt to remake pipes [https://pipes.digital](https://pipes.digital)

<comment><USER25> I really wish the pipes.digital project was open source. It could have really gone somewhere. Without it being open source, it seems to have gone the way of yahoo pipes itself. : /

</comment></comment><comment><USER26> To scratch a similar itch today, I self-host (well, on Heroku) an instance of Huginn ([https://github.com/huginn/huginn](https://github.com/huginn/huginn)). It's a bit of a different model, but works nicely. It's also pretty straightforward to extend by adding your own agents (especially if you know ruby/rails, which it is written in).

</comment><comment><USER27> Pipes where awesome!

The product seemed to have influenced a few products (off the top of my head):

1\. IBM's Node Red [1]

2\. AWS IoT Things Graph [2]

I'm sure there are others?

[1] [https://nodered.org/](https://nodered.org/)

[2] [https://aws.amazon.com/iot-things- graph/?nc=sn&loc=3&dn=6](https://aws.amazon.com/iot-things- graph/?nc=sn&loc=3&dn=6)

<comment><USER28> Though not exactly the same thing, I like to think of these as spiritual successors:

[https://ifttt.com/](https://ifttt.com/)

[https://zapier.com/](https://zapier.com/)

<comment><USER29> I agree. When I first heard of it, IFTTT was basically Pipes done right for me.

In many ways Pipes was far too ahead of its time. The Web simply did not have as much computation and reason for integrating data between different web apps at the time.

</comment></comment></comment><comment><USER30> Surprised to see no mention of Apache NiFi, Quartz Composer, or Simulink:

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

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

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

I feel like every few years GUI based workflow tools make a revival, but then slowly die out. In the 1990s the selling point was that your "business logic" could be written by "the business" instead of those expensive programmers, and we all know how that panned out.

There is obviously something here, however, especially when you consider what people are doing with Simulink. But why do these tools remain niche? Is there some threshold of complexity past which these tools don't scale well, but source code does? Considering these tools are effectively representations of a program's call graph, could there be a future where I toggle between text and graphical versions of my program depending on what works best?

<comment><USER31> Simulink is hardly niche, it's running right now in hundreds of millions of car engine controllers. And it isn't a programs call graph; Simulink models usually don't have control flow at all. It's all about data flow.

</comment></comment><comment><USER32> Wow memories. My first startup, grazr.com created a feed processing system that could achieve similar (imho superior) results to pipes and worked in a different way ([https://mikepk.com/2007/03/grazrscript-v12-beta/](https://mikepk.com/2007/03/grazrscript-v12-beta/)). The idea was to use actual code (rather than graphical drag-drop) to write feed processing and transformation applications.

We used server side javascript (before Node, I like to think we were ahead of our time, our own fork of Spidermonkey with network and other server code!). We used OPML as a container format with <grazr:script> tags in them analogous to html <script> tags. The "pipes" in our system were much more like unix pipes, where the output of one script could be the input to another. In the running script you could access the feed with a customized "Feed Dom" with items and do manipulations.

With grazr's real-time freshness, feed normalization and database it worked amazingly well. We never were able to get people to understand it (it was super nerdy). I built some pretty amazing apps with it, unfortunately none of it exists anymore :).

Yahoo pipes seemed like the sign of the end for Grazr though. Since we had a widget and feed display tech. a _lot_ of people wired their pipes to grazr's widgets for display and publishing. We saw an initial "burst" on pipes announce and then saw the yahoo pipes usage drop pretty fast and never really recover. As a proxy, it looked like there wasn't enough "there" there to continue to pursue our programming environment.

I still miss it though, it was fun to work on.

</comment><comment><USER33> I remember not too many years ago (2011/12?) Yahoo was _the_ best source of free APIs for weather/stock/news information.

It was well documented, fully-featured, had a great web dashboard, and most importantly of all it was super stable.

Not sure if it shut down or if it just became irrelevant in the modern web. But many a engineering student plugged into it to make "hello world" weather apps.

<comment><USER34> They were shut down. I remember building many a widget that would pull information from Yahoo's simple and thorough APIs, and they were all sunset sometime between 2010 and 2015. Their stock API was unique in that it was one of the few with good data on almost any ticker.

Most stock tracking APIs require licenses to use, or have terrible latency. Similar with weather APIs now.

</comment></comment><comment><USER35> Pipes was great!

Microsoft has Flow [0] now, but not sure how it compares.

[0] [https://flow.microsoft.com/](https://flow.microsoft.com/)

</comment><comment><USER36> Mandatory fanboi mention: see also [https://luna-lang.org](https://luna- lang.org) for a product that may hopefully become a worthy successor (and is fully open-source!).

</comment><comment><USER37> And I also remember its competitor, Microsoft Popfly [1].

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

</comment><comment><USER38> I used Pipes for RSS processing as well. I set up a rather convoluted system that let me forward email to SMS for free.

It used a weird mix of free services, including Yahoo Pipes and IFTTT. It went from email to RSS to Google Calendar to SMS. It was nice while it lasted, but now Google Calendar doesn't send SMS notifications so it's no longer possible for free.

</comment><comment><USER39> I remember I used Pipes to create a new single RSS feed containing dozens of separate, rarely updated RSS feeds. For some reason I preferred seeing that one feed subscribed in my — wait for it — Google Reader, than a long list of feeds that rarely got updated. Well. I managed to survive even after Pipes disappeared.

<comment><USER40> I also remember using it to create RSS feeds for sites that lacked them.

</comment></comment><comment><AUTHOR> [https://news.ycombinator.com/item?id=9660682](https://news.ycombinator.com/item?id=9660682) (related discussion from the 2015 end-of-life announcement)

</comment><comment><USER41> I really liked pipes. I used it to combine the RSS feeds from lots of google code and GitHub repos into a single project feed so I could see all commits across my group in a single, chronological flow.

It let me ignore lots of Designers limitations and work around them.

Although it was possible to code it all directly in many languages it's an example of how making something more accessible is good, not just making it possible. Also free cloud running.

</comment><comment><USER42> Pipes was great. I miss it constantly. I used it largely to filter RSS feeds - for instance where I was only interested in posts by certain authors or posts from certain categories of a website.

It was very easy to build these sorts of filters with their visual ui.

</comment><comment><USER43> Pipes was such a good product and sorely missed. Is there anything equivalent to it today?

<comment><USER44> You can use modern scripting languages such as Python, Ruby and friends. They will never go out of fashion if you want to put together a pipeline (also known as workflow or script :-).

<comment><USER45> I really don't think Python qualifies as an _equivalent_ replacement for Pipes.

<comment><USER44> Of course not :-) Python, Ruby and friends can do so much more (and you can run your pipes on your own computer, for example, ...).

</comment></comment></comment></comment><comment><USER46> Yahoo Pipes, Friendfeed were all fun. The world was more open at that point of time.

</comment><comment><USER47> The comments here are validating. I thought I was going to be one of the few "old guys" who actually remembered/used pipes.

Glad to see there was so much love for one of my favorite things about the internet!

</comment><comment><USER48> i liked yahoo pipes so much that after decommissioned i wrote this article (in greek sorry) of how much i used and liked the product: [https://medium.com/andreas-personal- blog/%CF%80%CE%B1%CE%AF%...](https://medium.com/andreas-personal- blog/%CF%80%CE%B1%CE%AF%CE%B6%CE%BF%CE%BD%CF%84%CE%B1%CF%82-%CE%BC%CE%B5-%CF%84%CE%BF- yahoo-pipes-alternatives-47b0f1417f2f)

Huge pipes that might cause issueS? that could have be me :P

</comment><comment><USER49> I feel like it's similar to Airflow [https://airflow.apache.org/](https://airflow.apache.org/)

<comment><USER50> It is, but it provided a ton of web-centric APIs in an era where people published useful RSS feeds. Half the value was in publishing modules that spoke RSS in some form, and the other half was a number of online query systems that spoke HTTP and responded with RSS.

There were many technical problems with pipes and one major business problem. The technical problems as usual, were solvable:

\- branching. the system really didn't have a clean way to cause branching. if you wanted to only apply a regex on certain items, that would fail hard. I feel like some part of the anime fansub system I built must have been stressing the system because I'd occasionally find it disabled or key components removed from Pipes. (Deluge can consume RSS in the background, but often the fansub RSS feeds have duplicate items for different qualities, or are missing the enclosure field the system keys off of and other field normalization problems)

\- types. the system really operated on RSS as a medium of data exchange. Any operation that worked on whole RSS feeds was great. So the typical 'put a ton of blogs into a pipe and union them all into one big feed' hello world app worked great. As soon as you wanted to operate on a specific line of input items and do subprocessing, you were in a sort of hell. It wasn't clear which modules worked on which types, or why.

\- composition. a general engineering principle is to build things out of small parts. That's the fundamental reason pipes works, but you never had the ability to treat a pipe you built as a small part itself. You couldn't build pipes that accepted RSS in. The subpipe command they eventually added only allowed RSS out, without even any parameterization. Judging by the comments from support engineers here, the reason is mostly obvious: they couldn't prevent people from building pipes that called themselves indirectly.

But the business problem was most fundamental. The most useful APIs were often monetized via web ads. Yea, someone was collecting amazon referral revenue, but beyond that, no money was changing hands. That was a fundamental challenge to further adoption. Bloggers started publishing truncated or headline blog feeds, and what sort of evolved was a cat and mouse game with content creators: people invent new ways to generate RSS feeds for sites that don't have them while the sites fuzz their UI to prevent it.

</comment></comment><comment><USER51> I used pipes to build custom RSS feeds to feed into google reader. I miss this product and google reader so very badly.

</comment><comment><USER52> It was really a good product. I've used it to normalize XML from couple of sources to create a news aggregator

</comment><comment><USER53> Yahoo Pipes -> Google Reader is now Feedrinse -> Newsblur

<comment><USER54> Yeah, though given the history of both of the former I'm a bit wary of using a non-open source solution I can't host myself (Newsblur can be self hosted, but AFAIK Feedrinse can't).

</comment></comment><comment><USER55> pipes looked like the future ... but it was too early, I guess

</comment><comment><USER56> Alteryx is a 7B dollar company. Their Alteryx Designer product looks like this & does the some of the same things.</comment>


New OVH servers: $63 for Xeon, 48GB RAM, 200mbps, 4TB disk - <AUTHOR> http://www.soyoustart.com/us/offers.xml

<comment><USER2> I guess uptime on those servers isn't that important: "Network availability: 99.9%" \- [http://www.soyoustart.com/us/offers/sys-e32-1.xml#support](http://www.soyoustart.com/us/offers/sys-e32-1.xml#support)

<comment><USER3> Not endorsing these guys since I have no idea what their availability is in practice, but isn't 3 nines a fairly common SLA? I believe this is what I get at Linode and Digital Ocean.

</comment></comment><comment><USER4> Not to be pedantic, but the 2 X 2 TB usually means it's a RAID setup, so it's actually 2 TB, not 4. Or am I wrong?

<comment><USER5> You can still use a software RAID.

Last time I checked, software RAID was at least as secure (a lot more tests) and efficient as hardware RAID, except for some high-end controllers which with an integrated small battery and cache.</comment></comment>


Ask HN: What startup incubators/accelerator have research labs like YC Research? - <AUTHOR> Is this unique to YC? Are there any research institutes that are more integrated with their startup incubator/studio (or vice versa)? <comment><USER2> There is the AI2 Incubator, which is part of the Allen Institute for AI</comment>


Explore the ownership system in Rust - <AUTHOR> http://nercury.github.io/rust/guide/2015/01/19/ownership.html <comment><USER2> Am I crazy to say I prefer the ownership and copy/move system of C++11? It feels much easier to reason about but then again maybe that's just because I'm more familiar to it.

<comment><USER3> > It feels much easier to reason about but then again maybe that's just > because I'm more familiar to it.

I'm a professional C++ programmer for a decade and have started to look into Rust, and there's no way that C++ is easier to reason about.

There's no automatic copying of complex data in Rust, you can't move something away and later use it again, you can't invalidate interators and this list goes on and on.

At the beginning you have to get used to the borrow system of Rust, learn the idioms, but after that, it really seems to be in a lot of parts a better C++.

</comment></comment><comment><USER4> This was very clear and made sense to me, but it unfortunately doesn't cover lifetime annotations, which make sense to me 80% of the time and are completely mystifying the other 20%.

</comment><comment><USER5> If you've written some Rust, and you're more confused after reading that, it's not your fault.

Here's how to think about ownership in Rust. First, realize that Rust has basically the same memory model as C/C++. C/C++ has three big sources of memory trouble: "how big is it", "who owns it", and "who locks it". C/C++ provides little help in dealing with those issue. Rust locks down all those problem. Mostly through compile time checks.

Ownership in Rust starts out simple. There's single-ownership, and multiple- ownership with reference counting. The latter comes in two flavors, with and without concurrency locking. Reference counting works roughly the way you think it should.

In addition to ownership, there's "borrowing". This usually means creating a local reference to something. The local reference must have a scope that doesn't outlive the thing being borrowed. That makes borrowing safe. Borrowing is a compile-time thing with no run-time representation. Borrowed objects with reference counts don't need reference count updates on the borrowed reference, which speeds things up a lot. Borrowing in Rust is cheap and easy, and should be done frequently.

When a reference to something is passed into a function, the compiler needs to know if it's being borrowed, or whether ownership is being handed off to the function. The default is to borrow; for more complex situations, there's special lifetime syntax. A similar issue appears when a function returns a reference. Returning a reference is complicated - is it a new object, or a borrowed reference to an input object? Creating new objects in functions and returning them should be avoided if possible. It's a Rust idiom to create the object in the caller and pass it into a function to be modified.

Single ownership can be handed off to another owner. This, after some controversy, is the default action for the "=" operator. (Using "<-" for ownership transfer probably would have been better.) Such a handoff invalidates the variable that gave up ownership, and that variable can't be used again. For some types, though, you get a copy instead. For other types, you have to explicitly ask for a copy. This part of the language is kind of ugly.

Rust has the concept of "mutability". This is just the inverse of "const". Since immutability is the default, you write "mut" in a lot of places.

Programs in Rust need more design effort than in some other languages. You need to plan out who's going to own what, and who gets to change what. "Agile" types may find this troublesome. The payoff is that once the program has compiled, whole classes of errors have been eliminated.

<comment><USER6> Noisy, unreadable code, obsessed with ownership, may give rise to whole new classes of errors that otherwise won't be there. Good that someone experimented with building a language around ownership, but for me it all demonstrates that the idea is not viable. I tried to read 10 tutorials already, each leaving me more confused than ever before.

<comment><USER5> _I tried to read 10 tutorials already, each leaving me more confused than ever before._

I can understand that. The language has been changing so fast that most of the stuff on the Web is outdated or wrong. I just found a place in the official reference manual that's out of sync with the compiler, and sent in a note. (The lambda/closure syntax is still in a state of flux.)

Rust roughly follows C/C++/Java syntax, except that, like Go, it's a "name: type" language. Talking about ownership in code is new, as is the syntax for that. The ownership syntax is a bolt-on, and it shows. The lambda syntax is kind of weird; the designers went for conciseness over clarity. Some of this will take getting used to. The syntax is no worse than C++, and in some areas, better.

The syntax isn't the hard part, anyway. It's living within the ownership restrictions that's hard. It's hard because that's a design issue. There's a Rust port of Doom, and it has far too much unsafe code, because Doom's data structures were not designed with Rust in mind. It's not yet clear how big an issue this will be. The remark that 10% of Servo, the web page renderer, is unsafe code is a bad sign.

I don't have a personal opinion on this yet. I haven't written enough Rust code. I'm writing an RSS feed parser to get a sense of what it's like to deal with a complex tree in Rust. So far, it's going well, with no need for unsafe code.

If Rust can eliminate buffer overflows, dangling pointers, and memory leaks, that's enough to justify using it in place of C/C++.

<comment><USER7> Mentioning Go for `name: type` may not be inaccurate, but it is an odd choice (we're seeing more comparisons of Rust and Go than Rust and any language it is closely related to). I believe the origin for Rust's choice is actually the ML family. __EDIT __: I just checked more carefully and Go doesn 't even have the colon ([this blog post]([http://blog.golang.org/gos-declaration- syntax](http://blog.golang.org/gos-declaration-syntax)) used it in pseudocode).

<comment><USER5> Sorry. "name : type" comes from Pascal, and the Modula/Ada/Oberon family of languages continue it. Now that type expressions have become so complex, it's better to have a syntax where you know a type expression is expected. C/C++ struggle with this; they have to know which names are types just to parse. This is a pain for tools which try to parse C/C++ without reading all the include files. C originally had only built-in type names and "struct". "typedef" came later, and made the syntax context-dependent.

</comment></comment></comment></comment></comment><comment><USER8> I found the rust-lang guide (now the rust-lang book[1]) very useful when first learning rust. The style used to teach ownership in that guide is very similar to this, but helped clear out a few remaining doubts I've had.

Consider adding contribution to the book!

[1]: [http://doc.rust-lang.org/book/README.html](http://doc.rust- lang.org/book/README.html)

<comment><USER9> Thanks for the kind words. I certainly plan on expanding it.

</comment></comment><comment><USER10> I have zero experience in Rust, so maybe I shouldn't comment on an intermediate tutorial, but just some thoughts. I'm sure the answers to most of this are out there, this is more stream of consciousness...

"let i = 1", so let isn't picky about types, and types can be implied. In the 'fn foo(i: i64)' we see the "<name>: <type>" syntax, which I'm not an immediate fan of that, but no big deal.

We have value types, defined as a 'struct' with a 'Copy' flag. The "impl Copy for Info {}" syntax seems weird, and the "#[derive(Copy)]" only slightly better. Also, why does the struct have a hanging comma after the last (only) member?

Next we add some methods to the Bob struct. Seems like there are multiple ways, depending on the type of method? 'new' is just nested inside an 'impl Bob' but 'Drop' is more explicitly nested inside 'impl Drop for Bob' and then a lowercase 'drop' function. Huh.

Inside the 'new' function we see the first use of return values. And starting to catch on that Rust likes chatty syntax, e.g. the '->' before the return type. But yet, a very implicit structure to both initializing and returning the new 'Bob' object! I get the sinking feeling the 'name: name.to_string()' in the Bob initializer is important, and that '{ name: name }' would sadly not work... Not loving the underscore in method names.

I guess the 'drop' function is a first example of an instance method, identified by having '&self' or in this case '&mut self'. For a function that internally doesn't explicitly mutate bob, it's curious to see the &mut in that case. I'm going to guess 'drop' is a special case which always must be 'mut'.

The next step is "make bob value format-able when outputting to console" which sounds an awful lot like implementing to_string() but is accomplished through the 'Show::fmt' trait which is implemented using 'fmt::Show'. Is it really called the "Show::fmt" trait, and not the "fmt::Show" trait?

Here's where I like the syntax less and less: "fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result". Why must 'f' be 'mut' here? Why is the '&mut' before the type and not before the name? The one colon for name/value versus two colons for namespace is starting to hurt. Why a double colon instead of a dot? Also, I have to figure out what are all these ampersands are actually doing... they are notably absent from the 'black_hole' function.

Skipping ahead... owned values can be mutated, you just have to flag it with 'let mut'. Almost wish that was simply 'met' vs 'let', or even 'mlet'. Any owner can flag their value mutable, it doesn't have to start that way.

Then we get to "fn mutate(mut value: Bob) { ... }". Earlier we saw the 'fmt' function apply 'mut' before the type definition, here mut keyword is before the variable name. Is this the same, or something different happening? It seems weird there's not just one place to put the 'mut' flag.

BTW, can you really not just do 'bob.name = "mutant";' versus 'bob.name = String::from_str("mutant");'? Up until this point string handling seems reasonably sane.

Further down we start putting things on the heap instead of stack. In 'let bob = Box::new(Bob::new("A"));' \-- do you have to always 'Box::new' to get to the heap, or is there a way to define Bob as always living on the heap, i.e. 'class' vs 'struct'? ... I think I spoke too soon, because further down when it takes all of 'Rc::new(RefCell::new(Bob::new("A")))" to simply have a stack pointer to a mutable instance on the heap, I think I'm ready to bolt.

It's an impressive level of control over the semantics of how objects are created and destroyed without having to explicitly control every aspect of memory management, and there do seem to be a lot of follow-on benefits for going through all this trouble, but perhaps by 2.0 they will have made strides to improve the syntax to something a bit less obnoxious.

<comment><USER11> > Next we add some methods to the Bob struct.

`impl Bob` defines methods inherent to the type; `impl Drop for Bob` implements methods defined by the Drop trait. (Think Java interfaces.)

> I get the sinking feeling [...]

`{name: name}` works just fine.

> I'm going to guess 'drop' is a special case [...]

Since the signature for `drop` is defined elsewhere, by the `Drop` trait, we must use `&mut`, regardless of if we actually mutate `self`.

> Why must 'f' be 'mut' here?

This time the trait is `Show`, and the same reason as for `Drop` applies. Now, however, we're actually using the fact that it's `mut`: you can't write to an immutable formatter.

> Why is the '&mut' before the type and not before the name?

Because mutability and ownership is information carried by the type, not by the value.

> It seems weird there's not just one place to put the 'mut' flag.

You use `mut` to define whether a stack-allocated value can be mutated, and also to define whether a reference can be used to mutate its referent. Function parameters are stack-allocated, so you can put `mut` before them in the parameter list.

> Up until this point string handling seems reasonably sane.

`String` is a resizable string. `str` is not. It's a bit like Vec<T> vs. [T] - see [http://cosmic.mearie.org/2014/01/periodic-table-of-rust- type...](http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/) .

> I think I spoke too soon, because further down [...]

That incantation effectively disables Rust's compile-time ownership checking and replaces it with a runtime-checked structure. RefCell implements `&mut` semantics at runtime, and Rc allows multiple owners of the same data. There are often ways to avoid needing these constructs, and it's considered a code smell, so the incantation is long for a good reason. (If you really want a shorter version, you can use `unsafe {}` and raw pointers. Or C++.)

You can have a mutable heap-allocated value simply by using `Box::new` and marking the stack variable as `mut`: `let mut foo = Box::new(Bob::new("A"))` .

I agree that the syntax sometimes isn't quite there. There used to be a `box` keyword for heap allocations, but it's been feature-gated for the alpha.

<comment><USER12> > `{name: name}` works just fine.

It doesn't in this case. "name" field is String, "name" is &str.

<comment><USER11> That's true. I thought he was making a point about syntax.

</comment></comment></comment></comment><comment><USER13> Would these checks be possible to implement as some sort of diagnostic or sanitizer in clang?

<comment><USER12> Some of it, yes. As a matter of fact, Clang already includes one, which is deployed on a large scale at Google.

[http://clang.llvm.org/docs/ThreadSafetyAnalysis.html](http://clang.llvm.org/docs/ThreadSafetyAnalysis.html)

</comment></comment><comment><USER6> Some serious voodoo science is going on here, with a good chance to become a next fad. Programming is difficult as it is, but apparently not difficult enough for someone's taste.

<comment><USER14> This 'ownership' system is a pattern which is used _informally_ in C, C++, and other languages with manual garbage collection—the idea that you have a bit of your program responsible for allocating and freeing memory, and another bit which merely uses it. Rust takes this pattern and has the compiler enforce it.

I suppose in some ways it makes programming more difficult, but it's also going to make low-level programming _safer_ by virtue of the fact that certain invalid programs are no longer possible to express. Rust is one of very few languages which can offer that.

(Also, having used Rust a fair amount, I don't think it's actually that difficult once you're used to it. I can think of much more complicated programming features that have been present in popular languages for decades!)

<comment><USER15> For me, understanding Rust's type system has been far more complicated than understanding the ownership model. But that's likely because I have zero C, C++ or Haskell experience.

<comment><USER14> Has it been something about the type system in particular, or just keeping track of all the parts? I would not call it a simple language, but I think it's ultimately tractable, albeit with work.</comment></comment></comment></comment>


Dropbox for iPad: Drop dead useful or lost in translation? - <AUTHOR> http://ipadappsbuzz.com/2010/05/11/dropbox-for-ipad-drop-dead-useful-or-lost-in-translation/

<comment><USER2> I'm going to post this here because I can't find anywhere else to have a dialogue about the seemingly universal fondness for, and unqualified recommendation of, Dropbox. I'm someone who takes contracts seriously when I sign them, even when they're just meant to be boilerplate fluff, and I was really unhappy to read the following in Dropbox's ToS:

> You agree not to do any of the following while using the Site, Content, > Files or Services:

> o Post, publish or transmit any text, graphics, or material that: (i) is > false or misleading; (ii) is defamatory; (iii) invades another's privacy; > (iv) is obscene, pornographic, or offensive; (v) promotes bigotry, racism, > hatred or harm against any individual or group; (vi) infringes another's > rights, including any intellectual property rights; or (vii) violates, or > encourages any conduct that would violate, any applicable law or regulation > or would give rise to civil liability;

I sent a mail to Dropbox saying the following:

> I'm used to seeing such passages in the ToS for bulletin boards and other > public-facing chat forums, but it seems to be incredibly limiting to say > that I cannot post, to a dropbox that is meant for my use only, information > unless I know for a fact that it is true. (The ToS make no provision about > belief; I simply cannot transmit text that is false.) This restriction seems > already draconian enough; but requiring further that the true text be not > misleading seems well nigh impossible.

but never received a reply. I understand that it's easy, and natural, to say "Oh, they'll never enforce that"; but should one really be willing to enter into a contractual relationship based entirely on the understanding that the actual contract will be ignored?

</comment><comment><USER3> I never would've thought to use it as a PDF reader. Installing now :-)</comment>


Windows 10 now wants you to pay for Solitaire - <AUTHOR> http://www.cnbc.com/2015/07/30/windows-10-now-wants-you-to-pay-for-solitaire.html <comment><USER2> This is what drove me to GNU/Linux. Was OS X user, saw how Apple censors GPL software from App Store, and saw 8-year-old kid with iPod touch getting his allowance stolen by a solitaire iOS game that charged him real money to cheat when he got stuck (which you can do with real cards, obviously) _while_ advertising at him to eat at McDonald's. I decided I couldn't trust Apple anymore, and no way would I trust Microsoft.

This is so blatant. Like there's nobody who can reasonably make the argument "yeah, but how else can we fund the development of solitaire computer games?" It already existed. This freemium / ad-infused software trend is effectively extortion.

<comment><USER3> Yeah because software is free to maintain and develop.

You can be disappointed if they make you pay for what was previously free but saying it's extortion to make people pay for software isn't very considerate to all of us who make a living of writing software, isn't it?

<comment><USER4> I work in the games industry. A lot of the freemium models are absolutely extortion. Some of the worst ones explicitly target children and gambling addicts to maximize profits on vulnerable people or abuse the family's card details.

When done right, Freemium is a fantastic model which can not only generate more revenue to the company (both short and long term), but is also more enjoyable and a more fun experience for the user.

When done greedily, it's extortion and is by far the most disgusting sales model known to mankind.

The latter is most common.

<comment><USER5> >but is also more enjoyable and a more fun experience for the user.

It's hard not to be sarcastic about this topic, but I honestly want to know which game is more fun freemium than pay once?

<comment><USER6> Any multiplayer game when you cant buy anything that helps you win, yet receive constant free gameplay content built with moneys of those who want to buy cosmetics, i.e. league of legends, team fortress and the like.

<comment><USER7> Disclaimer: I was a dota player, which has some rivalries with LoL

The LoL model is controversial. You may not pay anything, but it will take you literally thousands of hours to get most champs and runes. Do you need all? Thats arguable. Can you get IP fast enough to buy champs as they come out? Most people cant, from what i understand.

Dota and tf2 fit in the freemium that cares for the users.

</comment></comment></comment></comment></comment></comment><comment><USER8> Ads inside an operating system (startmenu) and in applications that are included by default (Solitaire). I never saw that, not in Android, not in iOS, not in OSX. All telemetry, key and audio capturing and auto-cloud-upload, peer-to-peer-updates, forced updates, ...these new "features"/annoyances aren't well received. What's going on at Microsoft campus?

On iOS one can simply deactivate Siri and iCloud, that's it, two settings. On Android it's almost as simple (remove GoogleNow widget, use Samsung/HTC/Sony/etc. non cloud-only apps). Windows 10 requires 25 settings to be changed, and two can only be changed in the Enterprise edition, and to decide yourself which updates should be installed the very expensive Enterprise Long Term Servicing Branch edition is required. What's wrong with Microsoft? Who would trust such an operating system? Nadella seems to be the worst CEO of Microsoft to date; he receive advance praise unjustified for earlier work that still Ballmer decided. Microsoft should fix that.

<comment><USER9> Y'know, there's one place I have seen ads in the OS before: Ubuntu's "Amazon Shopping Lens" in Unity. That was ugly and tasteless, too, and I hope Microsoft gets a similar backlash.

</comment></comment><comment><USER10> To be fair to Microsoft, you used to have to pay for Solitaire to get your free copy of Windows, now they've unbundled it you can get Windows 10 for free without having to buy Solitaire.

<comment><USER11> Windows 10 isn't free, only the upgrade (from 7/8/8.1) is, and it's a limited time offer.

<comment><USER12> I think mattnewport was making a joke there, in case you missed it.

</comment></comment></comment><comment><USER13> I feel like these titles are pretty disingenuous, as far as I'm aware you get all the functionality of the old Solitaire game and more for free without being shown any ads at all, while the ads are only in a new game mode.

Not to say I wouldn't prefer there to be no ads at all, or that I don't find the price extortionate, but these articles seem a bit overblown.

</comment><comment><USER14> Microsoft's official statement on this:

> Microsoft Solitaire has been free to play for the past 25 years on Windows, > and continues to be free to play on Windows 10. Users can access and play > everything within the game for free, including new premium features like > Daily Challenges and Star Club. The Microsoft Solitaire Collection game > experience and Premium Upgrade features such as Double Coins for Daily > Challenges, and removal of advertisements, is identical to the Windows 8 > version that has been available for purchase for years

Source: [http://www.windowscentral.com/heres-what-microsoft-says- abou...](http://www.windowscentral.com/heres-what-microsoft-says-about- windows-10s-version-solitaire-and-its-free-play-model)

</comment><comment><USER15> The games have been moved to the Store since Windows 8.1 (or is it 8?). See: [http://windows.microsoft.com/en-au/windows-8/solitaire- mines...](http://windows.microsoft.com/en-au/windows-8/solitaire-minesweeper- hearts) & [http://www.howtogeek.com/122145/what-happened-to- solitaire-a...](http://www.howtogeek.com/122145/what-happened-to-solitaire- and-minesweeper-in-windows-8/)

Not sure when the ads and IAPs were added. I bought a new Windows 8.1 machine a month or so ago and the version in the Store already included the IAP prompt.

</comment><comment><USER16> I get the feeling it was a suggestion from an enterprise customer. The other thing: it isn't needed anymore to teach people how to use the mouse. It was amazing how that one game taught a lot of computer haters how the mouse worked. That damn card game was an addictive motivator. Not a bad lesson to learn if you have an interface concept that you want people to learn and practice.

</comment><comment><USER17> I have older family that are winows solitaire addicts. The windows 8 options were just bad: Huge fullscreen only, sounds, fancy menus you have to navigate first...

I copied sol.exe and cards.dll from their retired XP machine.

Works great, just a bit small now. (Aislerot solitare from Linux is a clone with scalable cards, I wish windows' solitare went that way.)

</comment><comment><USER18> I wish I could go back and check but didn't this happen with Windows 8.1? Seems weird to be outraged now as opposed to back then (unless I'm wrong of course).

<comment><USER19> Yes, in Windows 8 / 8.1 Solitaire (as well as other casual games published by Microsoft, such as Minesweeper, Sudoku, etc.) did include ads. They were shown in small boxes on the start screen, if you swipe to the right, and in the end game "you win" screen. In addition to those, I occasionally saw a full-screen ad when starting a session on the PC, but not on the tablet.

</comment></comment><comment><USER20> Jeez. Is Microsoft just stupid or what sometimes? You can't charge for something that's been free for decades.

</comment><comment><USER21> This is the nadir of the utterly rancid freemium model of software.

</comment><comment><USER22> Hasn't MSFT ever heard of a 'Loss Leader'?

</comment><comment><USER23> Are they going to start making you pay for MS Paint?

<comment><USER24> Paint and Wordpad are two of the "classic" utilities that stayed untouched in Windows 10 - even though Paint could benefit from some touchscreen- friendliness, for users with touch screens, that is. But Microsoft already has something called "Fresh Paint" in the Windows Store, with IAPs that can cost as much as $99.99 (according to the app description).

</comment></comment><comment><USER25> The outrage!

In reality, I think Microsoft is suggesting we compare Solitaire from different vendors, and go that route, instead of using what they provide. They are so thoughtful!

</comment><comment><USER26> How is this different than paying Spotify for the ads to go away? People don't seem to mind that.

<comment><USER27> Solitaire added ads to something that was previously free and ad free and added ads.

Spotify took something that previously cost money and made it free with ads.

There's also the fact that people can view Spotify as a ongoing service easily while people view MS solitaire as a component of a product. Normal people dislike when you turn their products into services needing ongoing payments</comment></comment>


Muscle strain from using the mouse - <AUTHOR> How common is it to strain your muscles especially on your right side from using the mouse all day? Do you ever injury not the shoulders but the muscles on your sides next to your ribs? Have it ever gotten bad enough that it hurts to breathe heavily?<p>I am having this issue and I am not sure if it is related to me using the mouse with my right arm stretched too far forward. If these sort of strains are common, does anyone have any advice to avoid it in the future? <comment><USER2> I stopped using the mouse for this reason. Here's how I did it: [http://www.developingandstuff.com/2015/01/no- mouse.html](http://www.developingandstuff.com/2015/01/no-mouse.html)

</comment><comment><USER3> [http://www.webmd.com/pain-management/carpal- tunnel/tc/carpal...](http://www.webmd.com/pain-management/carpal- tunnel/tc/carpal-tunnel-syndrome-topic-overview)

<comment><AUTHOR> But this seems to only affect my sides next to my ribs not my fingers or any part of my arm.

<comment><USER3> Maybe you should visit a doctor

</comment></comment></comment><comment><USER4> Trackball: [http://xahlee.info/kbd/trackball.html](http://xahlee.info/kbd/trackball.html)

<comment><USER5> Seconded, I switched to a Logitech M570 and absolutely love it. I was noticing problems in my wrist more than anything.</comment></comment>


Isostick - the optical drive in a usb stick - <AUTHOR> http://www.kickstarter.com/projects/elegantinvention/isostick-the-optical-drive-in-a-usb-stick

<comment><USER2> In case you're interested there is substantial discussion about this in a previous submission:

<http://news.ycombinator.com/item?id=2817151>

BTW: In case you think it's hypocritical of me to point this out when I have also submitted a duplicate item, all I'm trying to do here is help unify the discussion. My "duplicate" is intended to revisit a deep technical article from some time ago. I see that as different, and if you disagree, I'd be happy to have a discussion of the question.</comment>


Debian Packaging Tutorial – Feedback Welcome - <AUTHOR> https://blog.ssundarraj.me/debian-packaging-1b176d03ab0 <comment><USER3> Being a Debian maintainer, that is a very bad and low quality tutorial. You missed a lot of files in debian directory, even your example of control file is not good enough, you're using practices to build package which would reject your package from even entering Debian. Also lintian is a must be if you work with Debian (and it would really scream with your tutorial).

Better tutorials:

[https://wiki.debian.org/IntroDebianPackaging](https://wiki.debian.org/IntroDebianPackaging)

[https://wiki.debian.org/HowToPackageForDebian](https://wiki.debian.org/HowToPackageForDebian)

[https://people.debian.org/~osamu/maint- guide.html](https://people.debian.org/~osamu/maint-guide.html)

[https://wiki.debian.org/PackagingWithGit](https://wiki.debian.org/PackagingWithGit) (because we are all going to git the world).

<comment><USER4> As a Debian _user_ , it's a fine tutorial. Not every .deb is built for distribution with Debian itself. The only change I'd make is to clarify that what's being built here is a "for personal use only" package.

As to the debian.org guides, I've always found them obtuse precisely because they emphasise what you've got to do to get a package distributed, rather than the plain technical details of how they work.

<comment><USER3> Packaging tutorial shouldn't be technical details how deb package works but how you build one (if you want those details you can also find them in Debian documentation but in the end deb package is just an ar file with it's set of make file that satisfies the installation in specific distro - this is the simple explanation). And no, the tutorial is misleading because Debian packaging means doing it for Debian, while creating a deb package for your personal need is different. You also have Ubuntu packaging guides and so on.

<comment><USER4> But the guides aren't just how you build a package. They're how you package something for official distribution. The requirements for the former aren't _nearly_ as stringent as for the latter, and by obscuring the former behind the latter, Debian makes its packaging guides less useful.

<comment><USER3> Debian packaging guides are less useful because they concentrate on how to build package for _Debian_?

And nobody is hiding from you any tutorial - Debian is an open community and the wiki is open to everyone so you can search for what you need but I really don't see the point in your sentences (are you saying that we should favorite somehow quick and dirty hacks instead of our strict high-quality ways of building packages? Because if yes, then Debian wouldn't be what it is today...)

<comment><USER4> Yes, that's exactly correct. Debian's tutorials are less generally useful because, to serve the specific goal of keeping Debian's packages high quality, they obscure what you _can_ do behind what _Debian_ thinks you _should_.

<comment><USER3> First of all (repeating myself again): there is a lot of documentation out there (already mentioned multiple times in this thread) how you can build debs quickly. Also, Debian tutorials are _Debian_ tutorials and they should serve Debian primarily and not some third-party, but still you have all documentation on Debian wiki (and also manpages of specific packages) - <USER2> just need to do a bit of search.

Second: saying that Debian's tutorials are less useful because they have specific goal of high quality - makes me really sad. Debian is community and not corporation, so to see that community has higher standard then any corporation should be praised. Also Debian's packaging evolved over 20+ years by thousands of hackers (experts in their field) all over world in their unique collaboration. I am sure this should be taken as a pride that you can go on net an read such tutorials.

And really, if someone thinks he is technical but can't read few pages of _not_ so demanding tutorial, then problem is in them because in software world you evolve every day and need to read and code a lot to keep a pace. Only problem that you could say is that maybe isn't that fun to read (because Debian wikis are old school so the sentences stretch through entire screen while today's web is focused on centering all which makes it a bit easy to read and so on).

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> This is a tutorial for building quick one-off packages that won't ever be accepted by debian but that you can use with your own servers.

If you want to do that, you will be better off using Jordan Sissel's fpm tool: [https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm) It can take any project and quickly package it into a .deb, .rpm, .whatever package.

<comment><AUTHOR> Agreed, no doubt. Just a quick start guide for beginner packages.

</comment></comment><comment> robinson-wall > If you're using OS X you can install it from homebrew (brew install dpkg).

While you can build a package of something simple like this example (static html), as soon as you want to compile a binary you're going to need to be building on the same environment as you're targeting.

I'd suggest removing any mention of OSX from the guide, or making it clear of the limitations of trying to build debs on it.

<comment><AUTHOR> I've added the limitation of this! Thanks for the feedback. That didn't strike me at all.

</comment></comment><comment><USER6> If you use the standard debhelper toolchain instead, you get lots of stuff for free.

Want to ship a systemd service file? include "\--with systemd" in the dh invocation in debian/rules (and add dh-systemd as a build dependency), and you can drop your system files in debian/yourpackage.service. The helper will do all the work for you like copying the service file to the right location, doing the "daemon-reload" to make sure it is read after it's changed, reload it after package installation, stop if when the package is uninstalled, and so on.

Want to create an empty directory? add it to debian/dirs. Want to install additional files? add them to debian/install.

Want to create a debian package from an existing perl module? "dh-make-perl --cpan The::Package".

And the nice thing is that all of these mechanisms are composable, and it is easy to override steps you want to customize.

At first, I found the standard debhelper toolchain to be complex too, but it actually makes simple things easy, and hard things possible.

Shameless plug: Yesterday I've blogged about debian packaging a simplistic Perl web application: [http://perlgeek.de/blog-en/automating- deployments/2016-005-e...](http://perlgeek.de/blog-en/automating- deployments/2016-005-example-project.html) (not much Perl specific in there).</comment>