Bethesda apparently broke its own Denuvo protection for Doom Eternal - <AUTHOR> https://arstechnica.com/gaming/2020/03/bethesda-apparently-broke-its-own-denuvo-protection-for-doom-eternal/ <comment><USER2> This is good news, Denuvo (the evolution of SecureROM DRM) was found to cause performance issues in games, inlcuding spiking the CPU and tons of excessive writes, which may reduce the lifespan on SDDs:

[https://www.extremetech.com/gaming/282924-denuvo-really- does...](https://www.extremetech.com/gaming/282924-denuvo-really-does-cripple- pc-gaming-performance)

<comment><USER3> Interestingly, Denuvo was the cause of one of the most annoying bugs I've ever had to look at. A crash bug which only appeared after applying their patch to the executable.

</comment></comment><comment><USER4> Anyone remember the Unreal Tournament 2003 (or was it 2004?) Demo, which had an exe that was compatible with original retail release as a DRM free copy.

Of course, Unreal Tournament was a mostly online multiplayer game, and relied on cdkeys as well.

I'm surprised with everything i've heard about release pressure and crunch time that this doesn't happen more often.

<comment><USER5> For the original unreal tournament (1999) you could download the demo and then apply the "nodelta" official update to get the full version of the game.

</comment></comment><comment><USER6> Anyone else remember the DOS days where you would start an application and it would tell you in a cryptic font "Pg351, P2, Ln3, Ch3 thru 10" and you would just have to know that meant you had to open the user manual to page 351 and type characters 3 through 10 from line 3 paragraph 2.

Then there were some creative ones like B-17 Flying Fortress which had a paper decoding tool where you slid the paper rings to match the symbols on the screen. This revealed another symbol through a hole in the paper that you selected on the computer from a list to "prove" you had a legitimate copy of the game.

<comment><USER7> Old XCOM-UFO Defense had this too. Also my first experience with a hex editor to remove tedious DRM by setting the expected words in the binary to 'xxxx'.

</comment></comment><comment><USER8> They didn't "break" anything, someone screwed up and left the unprotected executable accessible.

</comment><comment><USER9> I have really enjoyed GOG lately for the lack of DRM

</comment><comment><USER10> > That 67MB file can reportedly replace the 370MB, DRM-protected executable in > the main game folder with minimal effort and no practical effect on > playability.

What other things is that 370MB executable doing that it needs to be over 5½ times as large as the game itself? Sending every keystroke home? Searching the hard drive for crimethink? Running a Bitcoin miner?

<comment><USER11> Mostly just obfuscation, but obfuscation via injecting more code rather than just symbol mangling. It's designed to ram tamper checks & other validation all over the place, making it hard to identify & remove.

And if you're thinking "but surely all that injected overhead would slow the game down?" then yes that's absolutely correct, it does: [https://www.extremetech.com/gaming/282924-denuvo-really- does...](https://www.extremetech.com/gaming/282924-denuvo-really-does-cripple- pc-gaming-performance)

</comment></comment><comment><USER12> I don't understand the relationship between the two companies, id and Bethesda. I see that they're both owned by ZeniMax but nothing else. Is this just a temporary marriage of convenience?

<comment><USER13> There are two Bethesdas. Bethesda Game Studios is a developer and makes Oblivion and Skyrim and so forth. Bethesda Softworks is the publisher for the ZeniMax-owned development studios like BGS and id.

</comment></comment><comment><USER14> A similar thing happened with Rage 2. Soon after release, they removed the protection. Here's a hoping the same thing happens here.

</comment><comment><USER15> Someone is going to be fired over this.

</comment><comment><USER16> This is going to cost them tens of millions of loss in sales.

<comment><USER17> Not really. Doom has enough of a brand name that the average person probably isn't going to say, "Great, now that I know a DRM-free version exists, I will pirate it!"

More likely, someone like me would just say, "Sweet! Now if I buy the game, I can get at a version that won't slow down my performance with all of the obnoxious DRM crap running in the background!"

<comment><USER18> This is part of why I quit PC gaming and took the plunge to Linux. It seems like every PC game recently requires a social login with its own launcher and a dedicated DRM rootkit. And the privacy policies for all of this stuff are very "permissive." After a certain point you realize you aren't in control of your own computer.

At least with consoles you _know_ going in that the manufacturer has every executable on lockdown. But I couldn't stomach _not knowing_ if some poorly coded DRM or RGB control service was opening up my private files to remote code execution[1].

[1]: [https://twitter.com/gsuberland/status/1175570500292108289](https://twitter.com/gsuberland/status/1175570500292108289)

<comment><USER19> Please don't say PC when you mean Windows. Playing games on a Linux PC is still PC gaming.

(I play games on a Linux PC myself.)

<comment><USER20> It's gaming in the sense that racing in the Special Olympics is still racing. Sure, but for the purposes of the marketplace it may as well not exist unless you're talking about Linux+Android gaming.

<comment><USER19> There are other valid perspectives than the marketplace's.

<comment><USER20> Not if the market's is also the colloquial definition.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Who ever is in responsible on or for the team that made this mistake twice should be fired. Doing the same hugely expensive mistake twice in a row is ridiculous.

<comment><USER22> I would not say that this will necessarily be hugely expensive. People who would have waited for a crack would not have paid anyways. The only impact is them getting to play the game at the same time as everybody else.

</comment></comment><comment><USER23> > Denuvo says it still considers even a few days of effective DRM protection > to be valuable to its publisher customers

This is a pretty ridiculous position and should be embarrassing if you work at Denuvo. Would you buy anti-virus software or any other security product with that claim. (Police officer to homeowner) I see you bought a lock for your front door that only offered two days of protection ... it's been 3.5 so we're not going to investigate and your insurance probably won't cover it.

<comment><USER24> This is a poor example. Most locks - like most DRM - does not stop the most determined people from gaining access. It makes it slightly harder, more time consuming and/or more resource consuming to get access, with the hope that it will deter the most opportunistic attackers, and slow the more determined ones "enough" where "enough" is a function of the cost of the protection vs. the benefit of delaying access.

We accept that because we recognize that there is a cost/benefit tradeoff to be made to protection - it is relatively rare for a protection to need to be absolute to be worthwhile; in fact in a lot of settings protections that attempts to be "absolute" will be prohibitively expensive and/or complicated.

<comment><USER25> A lot of DRM isn't like locks because a crack can be applied by casual enthusiasts, not just experts. Keygens are not hard to use, whereas lockpicks require a bit of skill, time, and equipment that you can't just download.

(Some DRM does actually act more like a lock, such as console DRM that require hardware mods and would void the warranty)

<comment><USER20> Lockpick guns aren't hard to use either and can be employed by casual enthusiasts, the idea that lockpicking is hard is a myth that comes from outsiders observing the hobbyist communities and failing to realize that they aren't devoted to simply opening locks but rather the cultivation of skills to open locks in a particular manner.

</comment></comment></comment></comment><comment><USER26> How hard can it be to protect AAA games when can't be bought or played without an internet connection? (Can't be bought because you don't buy stuff on physical media any more, and can't be played because there is a huge patch every 3 days that you'll need if you expect to be able to finish it).

Just make the damn thing require an internet connection all the time. I don't care. If you are a good publisher then you promise to remove this restriction after 1 or 2 years and enable offline play.

<comment><USER27> > Just make the damn thing require an internet connection all the time. I > don't care.

Not everyone has perfectly reliable access to the internet.

<comment><USER26> Most people who can download a 50GB game tend to at least be able to have a connection that allows the game to phone home once a minute or so.

<comment><USER22> Maybe that person went to a place where they could get Internet, downloaded the game to a suitable storage medium and dragged it over from there into their steam folder at home.</comment></comment></comment></comment>


Ask HN: Unable to comment on one of my posts - <AUTHOR>

<Edit/Repost>
I had originally titled the question as "Ask HN: Bug or stupid HN policy?"
Previously, I had submitted http://news.ycombinator.com/item?id=1542329. However, the "discuss" link for that post didn't show me a comment-box and that prevented me from commenting on my own posting. I had incorrectly assumed the missing comment-box was either due to an HN bug or HN policy.
It turns out (thanks to RiderOfGiraffes) that the post (a New York Times article on "Israel Puts Off Crisis Over Conversion Law") had been killed (presumably because it was flagged as off-topic). That explains why the post had no comment-box.
If a post is killed, I wish there was an easier way for the poster to know about it :) <comment><USER2> Some investigation shows the item has been killed - I suspect that enough people thought it wasn't sufficiently on topic and flagged it.

<comment><AUTHOR> It is odd that [http://www.nytimes.com/2010/07/24/world/middleeast/24israel....](http://www.nytimes.com/2010/07/24/world/middleeast/24israel.html) would be killed, but thanks for looking into it.

<comment><USER2> Why is it odd? It's not about technology, it's not about entrepreneurs, it's not about startups, it's not about math, it's not about physics, or user interfaces, or philosophy, or any of the other topics I've seen discussed at length here.

I also think it's thoroughly misplaced.

<comment><AUTHOR> The current #2 post on HN is <http://www.economist.com/node/16636027?story_id=16636027> (Too many laws too many prisoners)

Is that Economist post about any of the things you listed ?

If you think that the Economist post was relevant,it is easy to argue that the New York Times post which opened with a paragraph that mentioned the "byzantine complexity of Israeli politics" and "A growing crisis between American Jews and the Israeli government over a proposed law " is also relevant.

PS: Using the "not about startups, not about .." argument for the NYT post about Israel , but not for the hugely popular Economist post about America illustrates your own bias, but it is interesting to see that a large number of people share that bias

<comment><USER2> I've only just really realised the accusation you make in your PS. Interesting that you think my distinction is because one is from the NYT and the other from the Economist, and it would be interesting to see you flesh out that accusation further and be a bit more specific.

It would be especially interesting given that I'm not American (North or South) and I don't live in the Americas.

FWIW I am _very_ interested in the issues raised in the NYT and I have been following the process elsewhere. I just don't think it's of interest to hackers as opposed to anyone else. I do believe the discussion of laws and prisoners has a hacker flavor, because there is a chance of hacking justice. There is no chance (that I can see) of hacking the politics of the Middle East.

And further, FWIW, I didn't flag your submission, I'm not a moderator, and I have no special standing on this forum. I just used common sense and observation to answer your question. I find it disappointing that you accuse me of bias in this way.

<comment><AUTHOR> Since you want to keep flogging a dead horse topic, I'll respond one last time.

I think it is absurd for you to say that the Economist article was "biased in interest towards hackers because people can argue about how to change the laws, or the meting out of punishments - hacking justice" and then turn around and say that the NYT article about Israeli law is of "not specifically biased towards hackers"

As for your claim that there is no chance of "hacking the politics of the Middle East", the NY article was focused on one specific law and it appears that "hacking" (to use the term you'd like for the Economist article) has already been effective on that specific law.

To me, you're applying different standards to the two articles about the two laws and that indicates a bias for one topic over the other. That is fine. It appears that you reject the notion of having any bias and that is also fine by me.

As for where you live or what passport you have, I really don't care about that either. So quit your defensive posturing and don't make an issue over your nationality.

<comment><USER2> Perhaps I've simply mis-understood you - I'd be pleased to discover that's the case. However, when you said:

      > Using the "not about startups, not about .." argument
      > for the NYT post about Israel, but not for the hugely
      > popular Economist post about America illustrates your
      > own bias

... it sounds a lot like you think I'm biased _because_ one article is about Israel and the other is about America. That reading makes it sound like you think I'm biased against Israel and in favor of America, and so it is you that has brought up the question of nationalities and allegiances. That accusation is unjust - hence my reply.

If this was not your intention then I'm pleased, although that does confuse me as to what bias you thought you saw.

As to the suitability of either article for HN - both should be of interest to any intelligent person who cares about the real world, and both are marginal as to being of relevance to "Hacker News." I personally have more chance of thinking about and understanding the justice system than I have of understanding the specifics of a particular religion, even though I am interested in and following that issue as best I can. My reading of each article leaves me thinking that the question of the law and prisoners is more open to hacking than the interaction between a specific religion and the politics of the state that is so tightly tied to them.

You may think that's absurd, and I respect that opinion while, obviously, disagreeing with it.

And I will say no more on the subject.</comment></comment></comment></comment></comment></comment></comment>


Why is Apple search so terrible on all their products? - c-slice The Spotlight search on Mac is horrible and constantly needs to be reindexed. Search on iOS is equally as terrible and frequently doesn't find apps installed on my phone if I search for them by name. And the iOS App Store search consistently is underwhelming. Why? <comment><AUTHOR> Spotlight is pretty awesome imo. I had problems on previous versions, but that was specific to a corrupt PDF. Stuff like spotlight comments enhances it further. I search something like 25k docs in various formats on my Mac in seconds.

Windows is far worse. They don't have a native PDF search facility (at least on Windows 7) and its sloooow.

iOS, I agree. It's gotten better, but the app search thing is bizarre -- especially since it works so well on Mac.

<comment><USER2> I haven't had any problems with spotlight on Mac, in fact I've come to rely on it at work. For searching PDFs of wiring drawings, I can put in a cable tag and it will come back with the documents it found it in. I open them in preview and the search is already filled in and it takes me right to the specific sheet. I guess your use case is different but I wouldn't trade it for any other searches methods I've tried.

Edit: Sorry meant to reply to root.

</comment></comment><comment><USER3> Not my experience at all.

I've never noticed my Spotlight indexing, except for when I've upgraded the OS. Items also come up very easily for me. I mostly use it to launch apps and it finds those for me with very few keystrokes. Maybe 1-2 gets me to the apps I use the most. For documents, it works well for me too, but not as good as the apps.

You can always try [https://www.alfredapp.com/](https://www.alfredapp.com/), but even in their blog they admit that with Yosemite kinda changed the game for them.

</comment><comment><USER4> I'll chime in with another "this is not my experience at all".

I use Spotlight religiously for the very reason that it's lightning fast for me. I've never had it index anything for me where it interrupted me even with multiple HDDs plugged into the Mac. Most of the time it only indexes after OS upgrades and I usually do those at night when it's not business critical. Same with iOS. I've never had issues.

Have you tried manually removing the index and then re-enabling it?

</comment><comment><USER5> They don't have server-side "DNA", unlike Google and Facebook. The executive management were not competent to hire competent server-side people, basically. They are getting there though...

<comment> c-slice Really? But you don't need server side DNA to do a simple file system search.

</comment></comment><comment><USER6> Instead of the Finder or the Dock, I use Spotlight heavily. I should probably move to Alfred, but I'm too cheap. I only notice it reindex after some upgrades and maybe once or twice a year otherwise.

I also use iOS search a lot and haven't run into the problems you describe. The iOS App Store? I'm on the same page as you. It's totally frustrating and doesn't work right.

<comment><USER7> I wouldn't move to alfred for it's file search capabilities, in side by side tests spotlight is much better. Alfred does have many other uses though.

<comment><USER8> Interesting, I would've recommended Alfred over Spotlight specifically for that purpose, if you're searching by filename. I just tried a test and Spotlight was initially unresponsive and then temporarily beach-balled while searching, whereas Alfred was instantaneous. (This is on El Capitan.)

</comment></comment></comment><comment><USER9> > Search on iOS is equally as terrible and frequently doesn't find apps > installed on my phone if I search for them by name.

I have never had this problem, not even once. I love the iOS spotlight search.

<comment><USER10> I have never been able to find anything useful with spotlight. I tried it in the past, but I ignore its existence now. I accept that my Mac doesn't have a search feature.

</comment></comment><comment><USER11> iOS apps are difficult to index because apps lack searchable metadata. Searching for "espn" or "fantasy" while looking for the "ESPN Fantasy Football" app will provide no results because the official name of the app is 'Football.' The app name (also disjoint from App Store name) is really the only out-of-the-box search indexable string

</comment><comment><USER12> What you have to understand is that Apple is a company that is really bad at almost everything, except for the one or two products that Jobs or Ive are focusing on. (OK maybe their supply chain too, that is said to be Cook's strength.) But they are so good at those one or two things (the iPhone, basically), that people are willing to overlook all the bad things.</comment>


Ask HN: What to do when a lazy programmer is ruining the teams motivation - <AUTHOR> Hi, So theres this programmer at work that hardly does any work at all. He spends most of his time surfing the net and watching videos. His attitude is affecting his teams motivation as they under pressure to deliver, and they end up doing most of the work while he surfs the net. The thing is. They extremely upset, but also feel like they cannot approach management and tell on him as they feel bad about that. Management hasn't noticed his lack of work cause he bullshits his way in stand up and about his task deadlines.<p>What would you recommend them do in order to either get him off the team or start pulling his socks? <comment><USER2> _What would you recommend them do in order to either get him off the team or start pulling his socks?_

Before doing either of those things, why not try to address _why_ he isn't working? Is he finding his tasks boring? Is he out of his depth? Is there a problem outside of work that's affecting his productivity that he needs help with?

It's preferable for _everyone_ if you can help a team member rather than being antagonistic or defensive when there's a problem.

<comment><AUTHOR> Valid points. He is a very capable programmer and the work is definitely not boring. His team mates think he threw his toys out the cot because he did not agree with using a particular technology going forward. So now instead of helping write the code, he chooses to do small tasks that he sits on for weeks and months. Really, this is also a failure on management. Managers should know how much work load he has and when he should realistically be able to finish it. But they haven't paid attention to that, so he gets to sit on these tasks for the longest time.

For example. He decided to build a date-picker from scratch for no apparent reason, when there are a trillion jquery, bootstrap date-pickers available. It took him 3 months just to do this, Now he has said he is gonna work on CSS clean up and re-styling all the validation errors, its been 3 weeks of him doing this.

He is the senior dev in his pod. So when theres demos, he's the one that talks and includes himself on features that they rolling out as a "team" effort when he hasn't written a single line of code on it.

</comment></comment><comment><USER3> It's not your job. It is management's. If it is not worth the risk of airing your concerns to management, then that just shows that it is not really the particular developer that is the problem. And the idea of "the team" taking matters into its own hands is just another sign of how dysfunctional the workplace is.

Either act properly, or don't act. There's no excuse for anything else. The internet cannot give you permission.

Good luck.</comment>


Ask HN: Do you or anybody you know need my programming video course - <AUTHOR> Hi Guys and Gals
I am working on a 2 to 3 hour video course, to teach basic coding principles for newbies. I plan to teach 4 languages and the promise is to teach it all in one day. The course is not about getting someone a coding job in one day but it is about getting someone from zero to three in a scale of one to ten in one day.
I'm targeting newbies who are having hard time getting through the basics and non technical people who want to know the basics of programming. I'm planning to price the course at $99.
I'm wondering if there is demand for what I am making. Please tell me if you need this or know some one who might need this. <comment><USER2> "the promise is to teach it all in one day".. really? Do you have any proof of "your way of teaching" could do that OR is this just a old fashioned promise? If just a promise then $99 is way too much considering enormous amount of free learning content available on internet.

<comment><AUTHOR> Hi I know it sounds crazy. But I see that as an oppurtunity.

I have a youtube channel where I teach HTML CSS and Git in my mother toungue, I have a lot of positive reviews for my simple to understand method of teaching.

That being said I'm charging $99 because I'll save you days or months of users time by making something difficult very easy and a task that can be completed in a day and I'm so confident I can assure the results, I will have a 100% no questions asked money back guarantee.

Although I still have to validate if my language will be good enough in voice, since english is my second language and I don't speak english that often

Link to my youtube channel

[https://www.youtube.com/user/sathishmanohar](https://www.youtube.com/user/sathishmanohar)

</comment></comment><comment><USER3> Why not continue to focus on Tamil and other languages where transitioning to the English based idioms of programming languages represents a significant hurdle?

<comment><AUTHOR> I wish I can concentrate on Tamil too. The thing is I need to make some kind of money to keep going so I had to go to the paying markets.

I think my product is going to be superior in some ways than existing products.</comment></comment>


Matestack: Rapidly create interactive UIs in Ruby - <AUTHOR> https://www.matestack.org/ <comment><USER2> Core contributor here: Happy we made it to HN, maybe a notch too early :)

Right now there's only two not very supporting comments here. Glad the authors have solutions that work for them, but Rest + SPA is overly complicated for most small/mid sized projects in our opion.

Everyone else: Feel free to join our Gitter if you like what you see!

<comment><USER3> Do I understand correctly in that you are generating Vue.js components from Ruby? If so, how is that less complicated and not like an SPA than simply rendering HTML with erb or slim?

<comment><USER2> Technical clarification: We don't "generate" Vue.js components. Matestack generates HTML that contains component tags. Those tags reference existing Vue.js components and hand over some configuration.

This enables us/you to define interactive UI behavior by just configuring predefined Vue.js components in pure Ruby.

If one needs custom UI behavior here and there, just add your own Vue.js components (write some lines of JavaScript) and then add and controll them like you do with the predefined dynamic (=Vue.js) core components. this approach is much easier than creating a standalone JS frontend app. You might end up writing 90-99% Ruby and just some lines of JS while getting an interactive, dynamic UI (or even a PWA if you add some meta information).

</comment></comment></comment><comment><USER4> I like this trend of moving back toward component based architecture. This has many similarities to Flutter, which for me has been a major breath of fresh air.

What still gets me: HTML/CSS/JS honestly just sucks for building complex apps. We have shoehorned tools that were meant for simple document display into doing our bidding, but at what cost? Hours and hours of developer agony. It doesn't need to be this hard. I like looking at one file written in one language to see both the look and behavior of an app. There has just been too much mental overhead. I like the way things are going and this framework is step forward.

<comment><USER5> I really wish Flutter wasn't tied to Dart. Dart feels like a yet-another language with nothing over e.g. Go. Go can compile to JS and WASM now.

<comment><USER6> Doesn't Dart have generics and a lot of other language features that Go chose to omit?

<comment><USER5> Trouble is its yet another language to learn.

Flutter should have just done the cross platform UI part and offered APIs in a number of languages.

</comment></comment></comment></comment><comment><USER7> > A modern View Layer for Rails built on Trailblazer and Vue.js

Nice, vue.js is super popular with the rails and laravel crowd. Trailblazer is also a great way to keep business logic out of the standard Rails MVC, and make testing trivial.

It also appears that it has similar features that Phoenix Live View does.

</comment><comment><USER8> I don't get it. It seems to be a haml-like syntax for writing HTML, with a jquery-like set of canned js interactions? This is how we wrote apps in 2008

</comment><comment><USER9> I understand there's already some ruby feature to avoid full page refresh? I'm a js Dev currently working with a ruby backend. Honestly for what we're doing we could have just made a plain old html page and that would have been best, with some partial reload sprinkled here and there. I'm not sure if there's a market for this, but it's nice to see that you try new things. Right now I feel the pain of having a large react codebase while most of the team prefers working in ruby. The risk with such project imo is to have insufficient abstractions and to end up debugging js code in the browser anyway. How about code splitting, hot reload, automatic assets compiling, etc .. that we've come to expect when developing front ends ?

<comment><USER2> Since we're not compiling Ruby into JS (I think Opal/Hyperstack does this) debugging can be done using the Vue Dev Tools in the browser, so you're not worse off there.

Most basic use cases (show/hide/rerender on event, deferred loading, onclick...) are part of the Matestack core and have good test coverage. For special use cases there's a guide on creating custom dynamic components, but yeah we could add some more info on debugging I guess. Not sure if my comment helped?

</comment></comment><comment><USER10> In their architecture diagram they're comparing their stack to one with distinct native UIs for each device type but they don't really explain how they're replicating that functionality. Unless there's some trick there should still be 3 UI blocks in the Ruby side of their diagram.

I won't go so far as to say this makes things worse but it seems like you're just moving things around. You can still have distinct client code on the Ruby side. If your goal is to simply move all this work out of JavaScript and into Ruby because you like Ruby, it seems fine.

You no longer have the explicit rest API to force a separation of UI and business logic but you can just enforce that with coding practices. You lose the ability to decouple UI dev entirely though.

</comment><comment><USER11> I don't really understand what are they fixing here. They point that current web development has shifted to "REST backend" and "SPA frontend", which (according to them) is not a good thing (why?). Their solution is to make you write (again) a "full" MVC-backend that also serves the UI (frontend), and additionally, extend it with another frontend layer (Vue).

IMHO that is not fixing the initial problem they are stating that exists, but making it worse, because now you have to write UI-related code in two languages (ruby and js) instead of the 1 that is currently needed (REST + SPA).

<comment><USER12> If I'm not wrong you're assuming that the REST backend is written in JavaScript. This is not always the case. I personally saw that happen only once. All the other times the backend was either Java, Ruby, Python, Elixir.

What's risky is that a few people will know this technology. Far more know React, Angular, Vue. On the other side the same person writing the backend can write the frontend, assuming knowledge of HTML and CSS. So one project, not two. Probably cheaper.

</comment></comment><comment><USER7> After watching the youtube video, I feel that this actually is VERY competitive with elixir's phoenix live view. It uses websockets too.

</comment><comment><USER13> Sweet. Are there any similar projects for Python, e.g. Django?

</comment><comment><USER14> Reminds me of the components talk at RailsConf [https://railsconf.com/program/sessions#session-810](https://railsconf.com/program/sessions#session-810)

</comment><comment><USER15> Reminds me of inertia.js!

</comment><comment><USER16> Interesting project... What's the biggest downside you can think of by adopting this approach? all projects have to have downsides as well as benefits... what's the trade-off here

</comment><comment><USER17> Are there similar projects for other languages?

</comment><comment><USER18> `my_frist_page`

</comment><comment><USER19> would be a funny name for a dating app in SV.

</comment><comment><USER20> Can we please stop writing html inside Javascript or Ruby in this case?

</comment><comment><USER21> An API backend + UI front-end consuming it is the perfect solution, it is the only sane thing I ever came across. Stop trying so hard to shoehorn old bullshit over it. It took us decades to settle on this, please leave it be and focus on more pressing issues. World hunger or something.

<comment><USER22> > An API backend + UI front-end consuming it is the perfect solution

I call shenanigans.

It is _perfect_ only if you hand-wave away the math and consequences.

You've doubled your surface area, number of apps, stacks, dependency issues, deployment targets, bugs, uptime dependencies, hiring language/framework requirements and attack vectors.

It is the right tool for _some_ jobs. I'd encourage you to stop assuming any of this is _done_. People thought that when XML and Soap were the thing.</comment></comment>


Best freelance tools of 2013 - <AUTHOR> http://2013freelancetools.com

<comment><USER2> Loads of awesome tips, tricks and advice. Best one was "stop freelancing".

</comment><comment><USER3> Hey, Ryan from Proper here. Thanks for sharing!</comment>


Version Control Before Git with CVS - <AUTHOR> https://twobithistory.org/2018/07/07/cvs.html <comment><USER2> CVS was awful, but it was so much better than RCS, which operated only on single files. There was a time in the late 90s when CVS + Bugzilla + Tinderbox was the state of the art of CI if your toolset was all open source. I used this combination at multiple workplaces 1998-2002. It worked and we shipped, but we didn't really understand how bad the tools were.

At Sun all stuff was in Teamware, except when it wasn't, because every group at Sun could do whatever they wanted to (we used SVN in the x86 ILOM team). Teamware was good but suffered by being a wrapper on top of SCCS.

SVN was a revelation after CVS. I resisted switching to git from SVN for a long time because the mental model for SVN is so much simpler: everything is in one central place, every change is marked with a monotonically increasing version number, remember a number and you can always reproduce the state of the project. Eventually I saw the huge benefit of the "git workflow" (local branches, pull requests) for collaboration. Branches in SVN are error prone and always risked painful conflict resolution, so we made them rarely.

Perforce, which is commercial, was like stepping into another dimension (you mean all this stuff just works? Out of the box?). There's another historical timeline where Perforce has an early open-source model (like Redhat) and is the dominant VCS.

I enjoyed that remembrance of 20 years working on free-software based projects, not a bad way to start Sunday. I hope it was worth your time!

<comment><USER3> I still don't like the Perforce model of workspaces or whatever they call it (clients?). That mapping between the server folders and your local ones. Extra complexity for no obvious benefit I could see.

<comment><USER4> For the right use case workspaces are awesome.

We used to do code + art in the same 1TB perforce repo back when I did gamedev. Art folder was ~600GB. Having a workspace to eliminate that as a developer was awesome.

Git still fails to even approach the usefulness that P4 brought to those types of shops. Between the auto-cache proxies, dealing with 1TB+ repos and workspaces there's a reason P4 still does pretty well.

<comment><USER3> I won't reply to all the comments saying mostly the same thing, but Git doesn't have this, true. SVN, another centralized system, does have it. Shallow checkouts plus folder checkouts and you can have any combo you want. Without adding another concept to take care of.

Much simpler conceptually, in my opinion.

</comment></comment></comment></comment><comment><USER5> This article makes in seem like ancient history, but there are still projects around that use CVS or very similar VCS like for example ClearCase. My software engineering career started after git got popular, but I had to work with ClearCase. I wouldn't wish it on anybody.

The inability to go back to old states of your project unless you happened to tag them makes finding the cause of bugs extremely hard. I don't know how it is in CVS, but in Clearcase you can tag only a subset of the files and what you check out from the server is determined by a complex configuration file ("the configuration specification"). This is an additional hurdle to reconstructing old states of your software because now you need to know the config-spec to do so. Even if you have the old config spec, it might contain fallback rules ("just take the latest version of the file") that effectively make it impossible to reproduce the old state. Unless you're extremely disciplined in your usage of the tool it's a real challenge to fix bugs for old releases. And don't get me started on trying to backport bugfixes into several old releases when branches are managed for each file separately.

This lack of a proper project wide history also makes it extremely challenging to migrate to a different tool without losing a lot of information.

<comment><USER6> Case in point: OpenBSD[1].

[1] [https://cvsweb.openbsd.org/cgi- bin/cvsweb/](https://cvsweb.openbsd.org/cgi-bin/cvsweb/)

<comment><USER7> And NetBSD: [http://cvsweb.netbsd.org/bsdweb.cgi/](http://cvsweb.netbsd.org/bsdweb.cgi/)

</comment></comment></comment><comment><USER8> This is a really fun article. I started with CVS, graduated to Subversion, and now to Git. It makes me really curious what the next paradigm shift will be!

The way I see it the evolution of these version control systems was driven by the precipitously falling price of disk space.

CVS only stored a tiny bit of metadata locally so almost every operation required contacting the server. That made using CVS very slow and branching expensive.

Subversion stored a whole separate copy of every file locally. This made the critical "show me just my local changes" operation an order of magnitude faster and made branching cheap, at the expense of doubling the disk usage.

Git stores the entire history of everything locally (compressed). This makes most operations an order of magnitude faster still, so much faster that some things that were completely impractical with the earlier systems is now routine, and branches are free.

What's coming next?

<comment><USER9> I hope pijul will gain traction soon: [https://pijul.org](https://pijul.org)

<comment><USER10> How's it scale w/ repo size? How about large binaries? Those are the biggest pain points I have with git.

<comment><USER9> It's possible to check out partially without hacking, so should be in a better place than git in that respect. Other than that I'm not sure if there is any support (similar to LFS). It's also very much in its infancy so performance is likely not a primary focus.

<comment><USER10> Hopefully not not a consideration, either, though. :-)

Definitely a very interesting project. Will have to play around with it a bit.

</comment></comment></comment></comment></comment><comment> jon-wood I guess I've become an old greybeard while I wasn't paying attention. When I started out in software development CVS, and later Subversion were the best we had.

The emergence of git and GitHub have transformed Open Source development, being able to just open a pull request or an issue and know you'll get notified when things happen is great - I've submitted patches for many things which I just wouldn't have bothered signing up to a mailing list to keep track of in the past.

Signed, Github user 362 (from back before you could just sign up)

<comment><USER11> It also tells you how quickly software employment has exploded, that so many (half? more?) developers have never used any version control (fundamental) tool other than one that's been common for only a decade.

As recently as the first dot-com boom, Git didn't even exist. Even Subversion was brand new, and it was mind-blowing how much easier it was to work with than CVS.

One aspect of history that this article glosses over is that Git is not the only or even the first third-generation version control tool created. The earliest buzz I remember around DVCS was for darcs and bazaar, neither of which I've heard mentioned since about 2009. Mercurial and Git were released around the same time as one another, and were in a vim-emacs sort of grudge match for a few years before Git became the clear winner.

Mercurial seems to still be in use in some odd corners of both the corporate and open source worlds - probably a legacy of people choosing it for projects during that period before Git "won". When I first tried it it felt a lot like Subversion made distributed. Nowadays it feels incredibly clumsy next to Git.

<comment><USER12> That's not true, in my experience.

Mercurial has exactly the same features - and maybe something more - than git, with a UX which is at least more consistent.

The main problem I see with mercurial is that its team stays too quiet: everything is so smooth that probably nobody feels the need of doing much fuzz about it.

The HN community has a high technical level, but during my career, out there in the world, I have seen a lot of different folks: people that constitute the bulk of the workforce often do not have a strong mastery of the tools they are required to use. Sometimes they just endure them. For these people, using an easier tool (and mercurial is a good candidate in my experience) could probably help them to really improve their skills and become more productive team members.

<comment><USER13> Back in the day, once I'd understood the value of decentralized revision control, I was convinced Mercurial would prevail, and that Git would become a footnote in history.

This is one moment in my past that was formative in helping me make good tech predictions. Namely, if I see a technology that I think is better, and I think it will win out over an inferior technology, I simply reverse my prediction and enjoy being correct.

Coming from Subversion, Mercurial made so much more sense than Git. I still think the CLI is more consistent. I keep hoping for a new shakeup in revision control systems, though I suspect such a change will be a long time coming.

<comment><USER14> Isn't a big part of Git overwhelmingly "winning" is Linus making it? The same sort of situation won't be true in many other cases.

<comment><USER15> No, I don't think so. I think git "winning" was due to github.

<comment><USER16> Specifically github made public repos free & private paid. Bitbucket did the opposite...

</comment></comment></comment></comment></comment></comment></comment><comment> cup-of-tea I think one has to work a little without a tool to truly understand why the tool has exists. Many new developers are forced to use git and they just don't understand why they have to go through this painful process.

I started without version control. I very quickly realised that it's very easy to break a project but forget how to undo your latest breaking changes. I discovered subversion and it was amazing. It was 2006 and I was the only person on my course to my knowledge who was using version control.

At around that time git came out and some people were trying it but many people said it was completely unnecessary for most projects. I then tried to use svn for a project with more than just myself as a developer and it was a disaster. We had giant commits once a day that cause conflicts every time. It was horrible. Git was truly amazing. I agree the cli isn't great (I use magit) but you have to have lived without it to understand why it's so important.

<comment><USER17> SVN is one of the sanest and most robust VCSes there is. If even that leads to disaster, then throwing git at the team will only make things worse. You need to educate them about proper VCS use instead.

We've recently transitioned to git at work and a couple of weeks later I'm already stuck in a week-long repository cleanup project on one of the central repositories because people just created a phenomenally huge mess in it. They were experienced and happy SVN users before, but somehow the boss forced the git hype train on us and has to pay the price now.

<comment><USER18> Having worked in both git and SVN shops, SVN is adequate as a server-side VCS. Most of the time you don't need branches on the server side. However, using only SVN client-side is absolute misery - no interactive rebasing, local commits, local branches, stashing, or committing specific lines from a file. You absolutely have to use something like git-svn or hg-svn to be productive.

The other (and this is a major one) downside of adopting SVN for your org is the dearth of decent tools for code review and collaboration. At a previous company we used Fisheye/Crucible which is seriously not fit for purpose. At another SVN shop I worked at, we emailed patches to each other (seriously). And the lack of quality tooling is down to SVN's declining popularity - there's no market.

<comment><USER17> The lack of good tooling for SVN is because git is so utterly inadequate at doing it's job. So this created a need for a ton of tools that pave over those flaws and now the resulting ecosystem is a money making machine.

<comment><USER18> You're saying git is so bad that an ecosystem sprung up to support it? But if it's so bad why would it have a large enough userbase to support that ecosystem? That logic seems backwards.

<comment><USER17> The initial users came because of an enormous hype fueled by "Linus made a VCS" and a weird quasi-religious belief in the community that it is better than anything else in that space. Crazy times back then, really.

</comment></comment></comment></comment></comment></comment><comment><USER19> > When people talk about Git being a "distributed" system, this is primarily > the difference they mean. In CVS, you can't make commits locally. A commit > is a submission of code to the central repository, so it's not something you > can do without a connection.

Not just commits - log, diff, status, almost everything I can remember needed to go off to the remote repository for information. Not only was this annoying when you didn't have connectivity, it was slow when you did.

I do occasionally miss the ability to version files individually though.

<comment><USER20> Subversion, for all its improvements, was the same way. I remember jumping through a lot of ssh proxytunnel hoops just to be able to check svn history when I was working at a remote customer site in 2006.

The first time I ran "git commit" and it finished almost immediately blew my mind.

<comment><USER21> On the other hand, Subversion will be quickly done before a git clone is finished.

<comment><USER22> If you clone more often than you commit, Subversion is the VCS for you :)

</comment></comment></comment></comment><comment><USER23> I wonder whether something like pijul ([https://pijul.org](https://pijul.org)) might represent the next step forwards; I am no expert in these things but the patch based approach it takes sounds interesting and potentially very intuitive to work with. I might have to actually give it a go one of these days!

<comment><USER24> I feel bad for thinking that it's a terrible name, since it's probably a fine name in some other language, and I don't want to be an entitled American English speaker expecting literally everything software related to be in English.

And yet, it's a great tool that I suspect that it will never get traction for precisely that reason. The abundance of options enables people to be shallow enough that a silly-sounding name knocks it out of consideration.

<comment><USER25> What's wrong with this name?

<comment><USER26> As an english speaker, I don't know how to pronounce it. Git, subversion, sourcesafe, they can all be easily pronounced.

</comment></comment></comment></comment><comment><USER27> What would version control look like after Git ?

Git famously was not built for monorepo [1]

I would like to see sub-tree checkouts, sub-tree history, storing giant asset files in repo ( without the git-lfs hack ), more consistent commands, some sort of API where compilers and build systems can integrate into revision control etc

[1] [https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be...](https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&t=2595)

<comment><USER28> WWgitND, or "What Would git Not Do.

</comment></comment><comment><USER29> "Opening the Source Repository with Anonymous CVS." Usenix 1999, by Charles D. Cranor (AT&T), Theo de Raadt (OpenBSD).

[https://www.openbsd.org/papers/anoncvs- paper.pdf](https://www.openbsd.org/papers/anoncvs-paper.pdf)

[https://www.openbsd.org/papers/anoncvs- slides.ps](https://www.openbsd.org/papers/anoncvs-slides.ps)

OpenBSDs involvement here is conveniently missing, arguably GitHub may not have ever existed.

Also of note, despite the paper being presented in 1999, AnonCVS was operating as early as 1995. Other projects were still putting tarballs on FTP, no read access to source history.

</comment><comment><USER30> Others having mentioned the terror that was Clear Case, but I just want to highlight one of its bad features: everything was stored in a relational DB. And consistency was not guaranteed, so at one point all the code was corrupted. After recovery from the backup, it was retired with vengence, and everything went back to RCS and CVS.

When I wanted everyone to switch to Git or Mercurial (~2007) the main questions were about branch merges (MUCH easier in git than CVS) and the reliability of the version storage.

Many have now moved back to a centralised model of control (github), even if they have many partial copies. The incredibly RDBMS (non-git) method of managing the meta-data of github systems is very disappointing, but not surprising. If github is 4th gen, then I'm hoping for 5th gen, where all SE meta data is also available as a replicated database, which you can spin up with a local httpd.

<comment><USER31> You mean like fossil [https://fossil-scm.org/](https://fossil-scm.org/) ?

<comment><USER30> While there are nice features in fossil (and sqlite is fantastic), but it is not git compatible. If the code and artifacts were kept in git underneath then exchanging code with other repos would be seamless. I don't understand why they rejected keeping tickets as files in a version control system (separate from the code), instead of blobs. It just seems unfriendly to manipulation by other tools. Philosophically, I like that git can be extended with small tools and modules instead of a monolithic executable.

</comment></comment></comment><comment><USER32> My first professional coding job used SourceSafe which was lock-based so you couldn't even do concurrent versioning. Everyone had to take turns with the files.

<comment><USER33> Perforce was like that when I used it. (> 2009)

Why people liked it or even tolerated it still puzzles me.

Edit: While I'm sure this was what I experienced it might be because of configuration by the organization I worked for, but I doubt it as I remember reading everything I could find about Perforce since I disliked it so much and wanted to find out why everyone seemed to like it.

<comment><USER34> Perforce has supported concurrent versioning since at least 2001 if not earlier. Individual files could be marked as requiring locks which is useful for binary files for which concurrent changes cannot be merged (one of the big reasons why Perforce is so popular in game development), but it's not either the default or only option. It sounds like your organization had severely misconfigured Perforce.

</comment></comment></comment><comment><USER35> I started my software engineer using CVS. I was using CVS as recently as 2014.

Why? Two reasons. I'd played with git but hadn't really understood the power of trivial branching (though I was one of those CVS power users who could branch, but tended to use my IDE to manage it). I remember thinking to myself, oh this is like CVS, because that is how I used it when I played with it.

The bigger reason is that I was managing a team of 2-4 developers that rarely worked on the same thing. We all worked in the same room. The codebase was relatively small (35k loc). I could see no good reason to make the change when CVS was "good enough". I was the same reason we used the same old crufty bug tracker--too many features to write to spend time upgrading infrastructure. Unless it was a 2x efficacy improvement; we did add automated testing and scripting around deploys because the benefits were obvious.

Now I love git and the power to branch and stage commits but I am still not sure it's needed for colocated teams of that size.

<comment><USER36> I'll second your suggestion that centralized version control systems have advantages for small projects. I use SVN for most of my personal projects, because no one else is contributing. (Only one branch. In fact, I have never branched in SVN.) The simplicity is a major benefit.

The main downside is how condescending some Git users can be to SVN users. When I mention I use SVN, I often hear nonsense like "Oh, you must not understand tree structures." Actually, I do, and I see that they have no benefit for certain things I'm working on.

The one thing I'd like is the ability to commit without an internet connection, which distributed systems can easily do. But this hasn't been enough of an issue to motivate a switch.

<comment><USER13> SVN also maintains one killer advantage over git to this day: Storing large binary files.

\- Data scientists and researchers who want to check in the original products of data collection, cleanup, etc.

\- Software with large artistic assests like audio, textures, and other visual art.

I think about the reproducible research movement and think to myself that SVN is strictly better for many such projects.

<comment><USER37> And Subversion, being centralized, allows you to opt-in to a "lock, change, commit" workflow, on a file-per-file basis, or on basis of file-type. Which is great for binary files, as pretty much any binary file such as Excel sheets or Photoshop documents or even PNG assets can't be easily merged, so Git's "work independently, then merge later" workflow can never work with those files.

</comment></comment></comment></comment><comment><USER38> I didn't have much contact with CVS, but I used SVN quite a bit. Things I remember from these days:

* There was no separation between commit and push. How weird.

* "svn log" or "svn blame" would take ages, because it had to tal to the server.

* Well-run larger projects had branching guides, because the built-in commands didn't track enough meta data to do merges safely later on

* SVN made it trivial to checkout only a subdirectory of a bigger repository (which I still sometimes miss in git), so people often tracked different projects in separate directories of one repository.

The only thing I remember about CVS was that to clone something from CVS, you had to know some root directory (this presumably was the webroot), and sourceforge.net didn't show available webroots -- so there were tons of technically "open source" repositories that you still couldn't clone, because the webroot wasn't documented.

<comment><USER39> With cvs, specify just "." and it will checkout all the modules in the CVS repository. That would include CVSROOT which was the module containing hooks. But, yes it was sometimes annoying that the module name wasn't clearly documented.

</comment></comment><comment><USER40> I enjoyed skipping the part of the article that explains how CVS worked, because I lived it. :)

CVS at the time felt like an amazing upgrade to RCS, just like Git feels like an amazing upgrade to CVS.

I wonder though, have we reached the end? If there anything beyond Git? When I used RCS, I would always lament "it would be nice if two of us could work on a file at the same time". When I was using CVS, I'd lament, "It would be nice if two of us could work on a group of files at the same time and merge our changes".

But using Git, my only lament is, "I wish this were easier for new developers" and "it would be great if there were a standard workflow". Problem one has been somewhat solved by GitHub/GitLab, and problem two has been solved by some pretty standard git-flow tools. Neither one really demands a new paradigm in VCS though.

<comment><USER41> > Have we reached the end? If there anything beyond Git?

The ability to split and merge repositories as easily as we can split and merge branches might open up some new use patterns.

The particular context I'm thinking of is scientific repositories. These tend to grow in size and scope in an unplanned manner. Pieces inevitably need to be split off for a collaboration, to be made public, or because someone is changing institutions and needs to take part of the project with them.

</comment></comment><comment><USER42> I remember importing all our RCS files into our first CVS repository, around 1991. It was back when CVS was primarily used for maintenance of SunOS. As a result, this is the first commit in the repo I spend most of my time in:

        commit 0d92e7f51fa3e1dd3d2257e9900e7ea0b37d96de
        Author: jkf <jkf>
        Date:   Mon Oct 21 07:53:43 1985 +0000

            Initial revision

RCS migrated to CVS which migrated to git.

</comment><comment><USER43> RCS was okay if you were a sysadmin, terrible for everyone else. CVS was okay, but still limited. SVN was more advanced, but buggy as hell. Git is more advanced and less buggy, but over-complicated and unintuitive.

Git was actually started in order to complete core functionality and let someone else make the front-end for the VCS. But somewhere along the line people just decided they didn't need a user friendly frontend, and now the core is what people use every day. 13 years later and it's still difficult to use. Unless someone comes up with a really slick universal frontend for it, it's probably time for a new VCS.

<comment><USER44> What about Mercurial?

<comment><USER43> Good question. I never gave it a fair shot, and it used to have some flaws, but maybe it's cleaned those up by now.

</comment></comment></comment><comment><USER45> A CVS lifesaver that you can put into your shell init file:

      export CVS_RSH=ssh

This defaults to rsh and figuring out that I had to set it like this took me a shameful amount of time (mostly because it produces such and unhelpful error message). I literally couldn't pull the OpenBSD src tree for months...

I'm one of the few people who deliberately learned and used CVS (for a while) in recent times. I did not have any public repositories at the time and needed VCS for my configuration and some documents (Org mode mostly), and the model where I could have a central repository on a local directory which I could easily back up was compelling. Then I figured out a filesystem layout where I could back up all my work easily and this became useless, thus I switched to Mercurial. Nowadays I'm considering going just git, because it's what everybody uses, and Magit is a compelling piece of software.

I use RCS regularly along with Mercurial and Git nowadays. RCS is good for e.g. when I have a tree where most of the content is pdf files (papers), images, and other binary data that does not really need to be version controlled, together with an Org mode files for notes. I also have a pool of Elisp files which contain the personal bits of my Emacs configuration, and I use RCS on them because their histories are not related to one another. It's no good for projects anymore because it is essentialy a tool used when people used a single computer to develop software to which they connected w/ terminals, so they were all users of the same machine and the code was always in a determined location.

One thing people tend to confuse with CVS or SVN is that they think it's a client/server model whereas it's actually a repo/checkout model. The repo is central and can totally reside in a local tree, and checkins from different checkouts go directly to that repo. This is akin to sharing one .git tree between all your checkouts of a single repository.

</comment><comment><USER46> > Did you passive-aggressively rewrite a coworker's poorly implemented > function out of cathartic necessity, never intending for him to know? Too > bad, he now thinks you're a dick.

When did it start to be like this? Making code better is a dick move now? Who rewrites stuff passive-aggressively? What does that even mean?

</comment><comment><USER47> Nice article but the conclusion doesn't really follow from how the article is build up.

> It illustrates well why understanding the history of software development > can be so beneficial—picking up and re-examining obsolete tools will teach > you volumes about the why behind the tools we use today.

As the article re-examines this obsolete version management tool, it becomes clear it's pretty easy and straightforward and can do a lot of things that git can to a certain degree. On top of that it's dead-easy to setup and use, in fact, its simplicity might be an indication that's it's not all that obsolete and might be exactly the right fit for new small personal projects.

<comment><USER48> Those are some really optimistic takeaways. I hope you'll try CVS and report back (especially a merge, or looking at project history including deleted files). I don't think any of these statements will stand up to scrutiny.

<comment><USER47> I am using CVS (and even RCS) and for small personal projects, it's perfect. Maybe there are problems with merges or project history in a larger context, but as things are, at the end of the day, I type the single command `cvs commit' and have a magic backup with revision history as a bonus. Sometimes that's all a project needs.

</comment></comment></comment><comment><USER49> I see a couple of other references so I know I'm not unique, but my first experience of version control was SCCS on SCO Xenix. Then RCS, CVS, SVN and Git. I never used Perforce or ClearCase. Knew some folks who used PVCS and StarTeam and Visual SourceSafe.

I played with Bazaar, Monotone, Mercurial and Darcs but not enough to really appreciate them.

As an aside, I met Larry McVoy at a Linux convention in 1999 and heard him speak about BitKeeper. Those were interesting times.

</comment><comment><USER50> My first job in the US ~2011 was in design team at monster.com.

One of the engineers had made a SVN repository for all our design specs and had cooked up a simple intranet page where the latest version of a design could always be shared by a permanent URL but also a history of all earlier versions.

That was my first experience with version control and I remember thinking it was magic. I never found out who made that, so if you're reading thanks for going the extra mile :)

</comment><comment><USER51> Though I had experience with cvs and subversion mostly through open source (mostly in sourceforge), I remember installing Trac around the time it first came out, and using that as equivalent to what would be done with GitHub today. Of course you had to have one install of it per project (or per 'organization', depending on your repository setup), and run it on a server somewhere.

Trac was great though, especially for the time: subversion server, source and changeset browser, tickets, wiki, roadmap. Aside from my own personal stuff, I switched several open source projects to it, and got a couple companies on to it. It quickly became to me an essential part of the dev stack, and was a great way to get the full dev stack* up and running relatively quickly.

* Other than continuous integration, but for me that came later. I worked on a lot of php stuff that could be deployed from source and never really saw the need then. Now I think it's essential and don't work without it.

</comment><comment><USER52> > If cvs commit is what you were used to, then I'm sure staging and pushing > changes would strike you as a pointless chore.

But using only `cvs commit` would be the equivalent of using a single script with git that adds every single thing in the relevant dirs and then blindly commits it.

In other words, the people coming from cvs and svn and complaining that git added a step for them were either doing an impeccable job of keeping their source dirs clean _at all times_ , or they were implicitly admitting that they weren't keeping track of what they were adding to their own repos.

I would guess there are old projects that fit the latter description. But I know from experience there are old projects that clearly fit the latter.

<comment><USER38> At least with svn it was best practice to run `svn diff` before committing, just like `git add -p` is considered a better practice than `git commit -a`.

SVN also allowed you to commit only specific files, so if your working directory wasn't clean, you could mostly still commit just the parts you wanted to commit.

</comment></comment><comment><USER53> This post does not do justice to just how awful CVS is.

OpenBSD still uses it, and it's the main reason I've only rarely contributed patches. CVS is just that crappy.

When I say it's awful I should admit that like FORTRAN it's not bad _for its time_. But 1986 was 32 years ago. It's not bad because it's old, but it's not 32 years of good either.

Commodore 64 was great for its time, but I'm not going to load my version control from a cassette player in 2018.

</comment><comment><USER54> My temporal progression went CVS -> SVN -> Mercurial -> Git. Every one of those was a major upgrade in functionality except the last. I never fought against Mercurial, and I rarely needed to Google "how do you do X with Mercurial" because it was so intuitive. But I spend about 30 minutes a day fighting with or googling git. Git is a horrible mess, but I like everybody else am forced to use it.

</comment><comment><USER55> My professional career started in 2008, but I didn't personally use Git/Github until maybe 2010 or so, but it still took until 2015 for me to be able to use Git/Github at work!

Version control system timeline for me has been

IBM ClearCase -> CVS -> Perforce -> SVN -> Git

The non linear path is from switching jobs/working on legacy projects, but yeah.

Git has it's problems, especially on usability, but it's much better than all the others in that list!

</comment><comment><USER56> While CVS may have originated with Grune, I think the CVS everybody is actually familiar with is the version Brian Berliner wrote and maintained for years.

</comment><comment><USER57> > So I invite you to come along with me on an exciting journey and spend the > next ten minutes of your life learning about a piece of software nobody has > used in the last decade.

I know of companies who only very recently moved from CVS, and I'd bet there are many that still use it too..

Assertions like this are always dangerous, because inevitably, someone somewhere is still using that tech you think is long dead ;)

</comment><comment><USER58> RCS was god. I loved RCS. Firstly, unlike SCCS it was head state so fast (SCCS recalced head from the history of change from base) Secondly, because it wasn't CVS all that branch and remote crappe was irrelevant.

I never learned CVS. My peers at work hate me because I think branches are something you prune off a rose bush in winter.

(I use git now)

</comment><comment><USER59> This is a really interesting perspective for people who haven't grown up with Git. I'd not grokked a distinction between three generations of VCS before and it's strange to me to hear git's bad UI described as something other people think.

</comment><comment><USER60> Used CVS with my team for years, say what you like, it was rock solid on branches.

I was appalled first time I had to pick apart a mess made by SVN on a branch.

I've made peace with git now, but struggled with the many different ways of getting things done in git.

</comment><comment><USER61> CVS served its purpose [https://en.wikipedia.org/wiki/Comparison_of_version_control_...](https://en.wikipedia.org/wiki/Comparison_of_version_control_software)

</comment><comment><USER62> i work at a big bank that still uses CVS for most of their software. They use SVN for "modern" projects, and only recently started dabbling in git. The place is a tech museum.

</comment><comment><USER63> YYMV. I once submitted a patch to OpenBSD without any prior knowledge of CVS and found it easier than my first contact with GitHub.

Pure git without GitHub may be a little easier than CVS.

<comment><USER17> Pure git isn't easier than CVS. Git just adds complexity over CVS (in parts just for the sake of being obtuse). CVS had its shortcomings, but complexity wasn't one of them.

</comment></comment><comment><USER64> > Do you enjoy spending 40 minutes repeatedly running git rebase -i until your > local commit history flows like the derivation of a mathematical proof?

Hells no.

<comment><USER10> I enjoy spending a couple minutes squashing, splitting, reordering and tweaking commit messages in GitUp to make my commit history look nice.

I do wonder if it's pointless though. Not clear time spent on stuff like that is really worth, vs how often you need to go back and check the history.

Maybe it's all just a exercise in OCD.

<comment><USER65> Work on a code base with 40 plus developers and 30-40 commits a day. Having a clean commit history is a must versus "test commit", "fixed that thing", "added" etc.

</comment></comment></comment><comment><USER66> In another timeline where git never existed: [https://SVNHub.com/](https://SVNHub.com/)

</comment><comment><USER67> I miss bazaar a bit it felt like a saner git and moving to it from SVN and CVS didn't require huge mindset changes

</comment><comment><USER68> I don't know why my company use perforce

<comment><USER69> Probably because Perforce scales to truly massive monolithic repos while git traditionally doesn't (the insanity going on at Microsoft notwithstanding.)

Personally I feel the best method is using lots of small repos, one for each service or library, that get stitched together by the build system. I know some large tech companies have created such systems and I have experience with one of them working very well (they migrated from perforce). But this is a big change from the monolithic repository model and institutional inertia is very real.

(Perforce will eventually start to hit a wall when you get to the point where money won't buy hardware big enough for Perforce to serve your repo fast, but that's a very long way off for most organizations and I believe there are some mitigations for it.)

<comment><USER18> > Personally I feel the best method is using lots of small repos, one for each > service or library, that get stitched together by the build system.

But then your teams have to manage dependencies - or your release team has to do it for them. It's very easy to run into diamond-dependency problems or runtime classpath issues.

<comment><USER69> Sure, but in practice it seems to work pretty well.

</comment></comment></comment></comment><comment><USER70> We still use CVS at work ... FML I need a new job!

<comment><USER71> Um, be glad your company uses _source control_.

</comment></comment><comment><USER72> >Did you passive-aggressively rewrite a coworker's poorly implemented function out of cathartic necessity, never intending for him to know? Too bad, he now thinks you're a dick.

Woof, I bet this guy's fun to have at standup.

<comment><USER9> I also don't understand - is he _so_ used to git now that he thinks the idea that working copy=staging area and commit=push are terrifying?

That's the _normal behavior_ of most version control systems. Only a couple of new distributed systems have separated staging and pushing.

Just forget about commits, there are only pushes.</comment></comment>


A supercompiler pass for Erlang - <AUTHOR> https://github.com/fenollp/erlscp <comment><USER2> Author of the repo here.

Just wanted to say that 99% of this is thanks to [1] and his 2013 Masters thesis.

There has been slight discussion to integrate a supercompiling pass (more involved than the ones that are in the compiler already) over at [2].

Hope to motivate enough people to see this happen, especially since we now have even cheaper constant literals [3]! Let's get on this.

[1] [https://github.com/weinholt](https://github.com/weinholt)

[2] [https://github.com/erlang/otp/pull/1080#issuecomment-3145985...](https://github.com/erlang/otp/pull/1080#issuecomment-314598581)

[3] [https://medium.com/@jlouis666/an-erlang- otp-20-0-optimizatio...](https://medium.com/@jlouis666/an-erlang- otp-20-0-optimization-efde8b20cba7)

<comment><USER3> Can you share any more information about the types of code patterns that can be superoptimized or how much speedup you see on benchmarks?

<comment><USER2> So if you look into [1] you'll find .hrl sources (actually .erl) and their .S counterpart in the subfolders. From these you will see that functions `a` and `b` look more and more like each other. Note that `b` is the literal version of `a`.

How much speedup? Potentially infinite, at the price of compile time. In real world cases though I don't have any data yet. I want to be able to compile a whole project first and that fails for one last reason, described in the README. But I have faith :)

The patterns that can be superoptimized are few for now. [2] describes how some of lists.erl functions work so that they can be supercompiled. The long- term idea is to have a local(/global if secured) cache of code so that inter- module calls can be optimized if the developer wants.

My real world case/motivation is supercompilation of code such as [3] (goal is to turn `a` into `b` at the assembly level). This pattern is extremely common in my employer's software [4] (which is probably the biggest open source Erlang project AFAIK).

A short example of a being super compiled into b:

        a() -> hd([get()]).
        b() -> get().

[1] [https://github.com/fenollp/erlscp/tree/master/test/asm_data](https://github.com/fenollp/erlscp/tree/master/test/asm_data)

[2] [https://github.com/fenollp/erlscp/blob/master/src/erlang_sup...](https://github.com/fenollp/erlscp/blob/master/src/erlang_supercompiler.erl#L29)

[3] [https://github.com/fenollp/erlscp/blob/master/test/asm_data/...](https://github.com/fenollp/erlscp/blob/master/test/asm_data/unfold3.hrl)

[4] [https://github.com/2600hz/kazoo](https://github.com/2600hz/kazoo)

<comment><USER4> From what I understand (on phone so no refs right now), "super compilation" is limited to a linear speedup. However, "distillation" can achieve super-linear speedup.

</comment></comment></comment></comment><comment><USER5> For those wondering what a supercompiler is, here is a simple introduction to it on c2 : [http://wiki.c2.com/?SuperCompiler](http://wiki.c2.com/?SuperCompiler).

To quote it :

A SuperCompiler is a dynamic optimizer that can transform the code of an object according to its actual usage.

This may be simple static optimizations, removing state that isn't used from an object; or it may be very complex e.g. partial evaluation of functions leading to code transformation.

<comment><USER6> How does a supercompiler differ to the optimisations that occur in a JIT compiler?

<comment><USER7> It's on a spectrum with it. JITs don't actually do much "optimization", because they need to be fast. It's subjective, but I'd say supercompiling is nearer to profile-guided whole-program optimization.

<comment><USER8> Huh.

It would be kind of cool to hook a profiling execution tracer into a JIT to find hot paths, resolve that to the nearest "usefully supercompilable" code block (it sounds like supercompilation works best when fed whole programs, I'm not sure how much bigger-picture comprehension [large-scale] JITs have of program scope in practice) and then supercompile that in a CPU-throttled background thread.

Thinking in the context of LLVM et al.

I'm aware that JS engines do a "fast" compile designed to just generate code _now_ within a few ms, and a fractionally slower compile that does do some optimizations and returns executable results within a few hundred ms.

This could be a third optimization stage that takes 1 second, or maybe even 2 or 3, but produces really really good results. If this doesn't already exist - I don't know, so I can't really assume either way - it almost sounds like low hanging fruit, and a super fun project too.

<comment><USER7> Completely agree! There is plenty of unexplored space and tradeoffs across the spectrum :)

</comment></comment></comment></comment></comment><comment><USER9> "Not that the Futamura projections can be used with erlscp yet, but, you know, just in case that day ever comes. A man can dream."

I feel like this is the lament of every compiler author.

<comment><USER10> When first read about partial evaluation, I misread Futamura as "Futurama". Maybe my brain was trying to tell me something...

<comment><USER11> Yes, and then I found this wiki page about the topic and I still am confused: [https://en.wikipedia.org/wiki/Partial_evaluation](https://en.wikipedia.org/wiki/Partial_evaluation)

Can anybody explain like I'm 5?

<comment><USER10> Not like you're five, but if you're interested: the standard introduction is still 'Partial Evaluation and Program generation', which is freely available [http://www.itu.dk/~sestoft/pebook/pebook.html](http://www.itu.dk/~sestoft/pebook/pebook.html)</comment></comment></comment></comment>


Microsoft PowerApps – Build Custom Business Apps Without Code - <AUTHOR> https://powerapps.microsoft.com <comment><AUTHOR> Are there other businesses providing something similar? We have several customers looking to solve their data distribution problems in a similar way.

<comment><USER2> Try Appgyver [https://www.appgyver.com/](https://www.appgyver.com/)</comment></comment>


The Internet is a public commons erected on private property - <AUTHOR> http://www.theatlantic.com/technology/print/2010/12/wikileaks-exposes-internets-dissent-tax-not-nerd-supremacy/68397/

<comment><USER2> I am annoyed by some people failing to see the difference in privacy for governments and people. People have an inherent need for privacy, while government has an inherent need for transparency, by virtue of their _public_ service.

Something completely unrelated, but that is a _very_ well designed (print) page.

<comment><AUTHOR> Let's be clear: we need governments to be transparent because of the power differential between governments and individuals.

Bruce Schneier said it well [1]:

"All aspects of government work best when the relative power between the governors and the governed remains as small as possible -- when liberty is high and control is low.

Forced openness in government reduces the relative power differential between the two, and is generally good. Forced openness in laypeople increases the relative power differential, and is generally bad."

[1] [http://www.schneier.com/blog/archives/2008/03/privacy_and_po...](http://www.schneier.com/blog/archives/2008/03/privacy_and_pow.html)

<comment><USER3> Your same argument can be applied to the power differential between modern corporations (often amoral agents) and individuals.

<comment><USER4> Corporations have nothing to do with morals. It is business, not personal.

The film's assessment is effected via the diagnostic criteria in the DSM-IV; Robert Hare, a University of British Columbia psychology professor and a consultant to the FBI, compares the profile of the contemporary profitable business corporation to that of a clinically-diagnosed psychopath. The documentary concentrates mostly upon North American corporations, especially those of the United States.

[https://secure.wikimedia.org/wikipedia/en/wiki/The_Corporati...](https://secure.wikimedia.org/wikipedia/en/wiki/The_Corporation)

<comment><USER5> I think that is the point webelos was making.

<http://en.wiktionary.org/wiki/amoral>

</comment></comment></comment></comment></comment><comment><USER6> There's a lot of really good stuff in here, but I think it's important to note that it's a private commons erected on public land that is then leased/rented back to the public. It's not actually a public commons.

(And that is the whole problem.)

<comment><USER7> "Private commons" is an oxymoron.

<comment><USER8> Not really.

If you go back and read Habermas, who coined the term "public sphere" (which was what was used in the article), the first public spheres were private salons, coffee houses, and cafes. The discourse of the public sphere was also carried out in the (privately owned) media of the time (newspapers and pamphlets).

[http://en.wikipedia.org/wiki/Public_sphere#J.C3.BCrgen_Haber...](http://en.wikipedia.org/wiki/Public_sphere#J.C3.BCrgen_Habermas:_bourgeois_public_sphere)

Another (less readable) book on the subject is _Badlands of Modernity_ , which discusses distinct spaces in which social orders are changed. The Palais- Royale in Paris, the private residence of Louis Philippe II d'Orléans, was one such site in which the ideals of the French Revolution were acted out before the revolution itself.

<http://books.google.com/books?id=B0D0EOJoyMsC>

[http://en.wikipedia.org/wiki/Palais- Royal#The_Palais_Under_t...](http://en.wikipedia.org/wiki/Palais- Royal#The_Palais_Under_the_Stewardship_of_Louis_Philippe_II)

Private spaces are just as capable of being inclusive, liberal, open commons as public spaces. Indeed, in times of oppressive government, it is private spaces that become the refuge of the remnants of openness. This is one reason why liberal theorists from the Enlightenment era regarded the ownership of private property as a right essential to the maintenance of liberty.

</comment></comment></comment><comment><USER9> I wish this article had been submitted under the original headline, as it much better describes the argument.

That said, I was surprised at the contents of the article. When the author described the "Internet Dissent Tax," I don't think he's describing anything new. Controversial materials have always been more costly and challenging to publish--witness _Lolita_ , which didn't find an American publisher for years.

Rather, the dissent tax I find more interesting is the one brought about by 4chan and company--where loosely organized groups of internet users show their general disagreement with the actions of a company by attacking their servers.

It seems like companies doing business on the internet who take some action that could be unpopular with some of the internet's "defenders" must now take into account the "tax" they will pay for that decision, by having to deal with the attacks that could arise. One has to think that Paypal and MasterCard will be taking this risk into consideration in the future.

That itself is an interesting new social dynamic that I don't think we've really seen before, since it goes well beyond boycotts or sit-ins by affecting thousands of "regular" users, not just the companies.

<comment><USER10> (seconding your claim that this is an interesting new social dynamic)

In the quasi-whimsical view of Anonymous as a legitimate internet-dwelling mentality, it's these definedly group actions act actually constitute the speech (a vector of communication) for that entity. Every textual or video message signed "Anonymous" is quickly interpreted as the speech of an individual or small group of collaborating authors, relatable on human terms. The attacks, despite their sit-in level overall effectiveness, are inherently aggregate, as opposed to that-13-year-old or that-15-year-old-and-his-botnet.

</comment></comment><comment><USER11> The Internet is a landscape... not a business.

Speech, association, politics, mutual assistance (charity), etc... are transactions between humans that pre-date the commercial transaction.

The first ICT was perhaps a bird call constructed out of a leaf made by a hunter to notify his mates of where the prey was…

And the first journalism was Ooga running into camp and announcing she'd just seen the first spring sprout on a favorite berry bush.

And if the message was false, misleading or dangerous… the onus certainly didn't fall upon the air through which the information was transmitted!

There was no gatekeeper, no intermediary…

ICT AND JOURNALISM were BOTH strictly peer-to-peer.

The same could be said for politics and charity within the hunter-gatherer world... peer-to-peer.

The commercial transaction (and the creation of money, trade tokens, etc) arose with the need for interaction within or between larger or multiple 'social organisms'... an important and needed development.

At its root, a civilization (or any social organism) is a product of individual and group decisions (ideas+actions) operating within the confines of the physical environment and natural law.

Money was developed originally as a technology for the allocation of excess social energy where complexity (and loss of various forms of proximity) required conventions beyond the less formalized methods of a hunter-gatherer group.

I believe this suggest some re-thinking about the nature of money and capital (and capital creation) but that's another story...

The point here is that the nature of this "social energy" in a scaled organism requires that the exchange of this energy NOT be bound by transaction costs or other complications (like carrier censorship) IN AREAS RELATED TO COMMONS- DEDICATED FUNCTIONS ESPECIALLY...

These particular areas of exchange actually pre-date the need for or existence of the commercial transaction and require special attention.

This problem (which extends also into the political participation sphere especially) is directly linked to neglected scaling issues in this new landscape... and the capabilities required for Commons-oriented transactions in that space... and why that requires a viable, simple and secure MICRO- transaction.

A needed institution for a pragmatic approach to solution:

The Commons-dedicated Account Network:

A self-supporting , Commons-owned neutral network of accounts for both political and charitable monetary contribution... which for fundamental reasons of scale must allow a viable micro-transaction* (think x-box points for action in the Commons).

(I note that journalism is often a for-profit enterprise and that this presents a complicating factor. I believe this is an addressable issue.)

Re-Igniting the Enlightenment: On Building Landscapes for Decision [http://culturalengineer.blogspot.com/2010/12/re-igniting- enl...](http://culturalengineer.blogspot.com/2010/12/re-igniting- enlightenment-on-building.html)

LinkedIn <http://www.linkedin.com/in/culturalengineer>

I also suggest that such a distributed account network should own and maintain its own cloud and bank(s)... giving it a certain independence and resilience.

*Re the potentials of the networked political microtransaction:

"A full 90 members of Congress who voted to bailout Wall Street in 2008 failed to support financial reform reining in the banks that drove our economy off a cliff. But when you examine campaign contribution data, it's really no surprise that these particular lawmakers voted to mortgage our economic future to Big Finance: This election cycle, they've raked in over $48.8 million from the financial establishment." ("Crony Capitalism: Wall Street's Favorite Politicians", Zach Carter, ourfuture.org)

I don't like the way money is controlling politics either. Sometimes you have to fight fire with fire...

$48.8 million? It's disgusting how these special interests can network their money!

$48.8 million is less than 35 cents per registered voter... It's just a matter of implementing the technologies to harvest other sides of the debate..

Most people NEVER give to a cause or campaign. It's a hassle and unless you're giving substantial bucks you feel pretty impotent anyway.

It doesn't need to be that way. Its just a matter of catalyzing the network.

From google's blog: Governments shouldn't have a monopoly on Internet governance [http://googleblog.blogspot.com/2010/12/governments- shouldnt-...](http://googleblog.blogspot.com/2010/12/governments-shouldnt- have-monopoly-on.html)

Just trying out ideas!

</comment><comment><USER12> The internet will be dominated, metered, measured, taxed, regulated and manipulated by big corporations, it is only a matter of time. The question becomes how will this be accomplished?

One way is for the Government to decide a certain body of information that is not allowed to be public knowledge, and when it becomes public, they will attempt to create an "internet information removal button". This obviously will fail, which will pave the way for creation of internet data police to protect and defend us from terrorists by cleansing the internet from sensitive information. The key to own the internet is to demand that it be protected, by government of course, by a data police force.

The final phase of internet takeover occurs by default, big corporations control the government, big corporations decide how the bytes that travel between computers are managed.

<comment><USER13> I wouldn't be so sure about that. The recent events prompt effort to further decentralize.

It's ironic. The more attempt to control, the more effort is made to decentralize.

<comment><USER14> I hope that's the case, but that isn't always the reaction of major players. Often, governmental attempts to control things will lead to at least some of the bigger businesses deciding it's in their interests to actively collude with the attempt.

<comment><USER13> If we need major players to act ethnically, then we are already doomed.

<comment><USER14> It's tricky to get around them, though (but I agree, not necessarily impossible). If you look at the parts of internet infrastructure _not_ controlled by a Fortune 500 company, they're quite small and scattered.</comment></comment></comment></comment></comment>


Pragmatic Programmers: The Passionate Programmer - A Must Read - <AUTHOR> http://www.pragprog.com/titles/cfcar2/the-passionate-programmer <comment><USER2> It strikes me as disingenuous that the first edition was called "My Job Went to India: 52 Ways To Save Your Job".

Being worried about losing your job doesn't seem to be related to being a passionate programmer (except probably negatively correlated, a lot of the time).

<comment><AUTHOR> Check out the Podcast at [http://podcasts.pragprog.com/2009-04/chad-fowler-on- the-pass...](http://podcasts.pragprog.com/2009-04/chad-fowler-on-the- passionate-programmer.mp3)

He talks about how this one is different and how it focuses on the positive of keeping your job rather than desperate ways of loosing it.

Regardless Chad Fowler is a fantastic author and has a great story and message to share with the programming community.

</comment></comment><comment><USER3> While passion will not necessarily be at odds with utility, it seems from the "About" section that this book is _all_ about utility: Deliberately choosing what skills to develop in order to be able to "market" and "sell" them more effectively.

Nothing wrong with that, but it has little or nothing to do with being a passionate programmer.

<comment><AUTHOR> Yes and no, but you need to have passion to care that much. I find it hard to believe how many really smart people, lack passion in what they do. It's merely a means to an end. Passionate people enjoy the journey as much as the destination.

</comment></comment><comment><USER4> Hackers are not interested in a career, they are interested in building cool stuff.

<comment><AUTHOR> I think building cool stuff, even on the side is a kind of career. It's just an unconventional one.</comment></comment>


How we increased our conversion rate by 11% in 10 minutes - <AUTHOR> https://www.easyproducttours.com/blog/how-we-increased-our-conversion-rate-by-11-in-10-minutes

<comment><USER2> I think your conversion went up because users were able to easily see a demo of the product.

I personally think that the tour (of your homepage) does is not much useful otherwise - it just goes through all the elements one by one, the graphic design of the tours interferes with the design of the page, and the large amount of text in the tours makes it hard to understand whats different with the information in the tours.

I would love to see you try a couple of things and let us know how the conversion rate changed (it will also help us know the best practices when using your service):

\- try the tours with a similar theme as the site (as is currently the case), but do more to separate them - perhaps by adding rounded corners, more shadows, or changing what are the main colors in the tour.

\- try reducing the text in the tours.

\- try putting in content in the tours that is different from the current site content - perhaps by grouping the features on the site and your tours introduce them as groups, or perhaps by focusing your tours on the benefits (as opposed to the features).

</comment><comment><USER3> I find it hard to follow the tour, as the popup designs mimic the design of the site (and micro-screenshots) so closely.

It's hard to tell where the barriers are, and what I should be looking at next

<comment><USER4> Agreed, you should have done the tour popups in a different colour to the site being toured.

Also when the tour is finished there's no "close" which would be naturally placed where the next button used to be. When I closed the tour and wanted to start again I [apparently] had to reload, a "start tour again" button would have been good; perhaps have a tour hotkey that works site-wide to get a tour of a particular page.

</comment></comment><comment><USER5> Do you have any idea how well this will for a website that's not selling product tours? Would be eager to know if it works somewhere else.

</comment><comment><USER6> But I think you could do better than 10% if the site was redesigned with the tour at the core. At the moment there feels like a lot going on.

The 'how' is nicely explained now, but the 'why' isnt so much. Meaning I think for me I'm not coming away with the feeling it's the tour isnt going to simplify anything on my app / site.

As you mentioned, people are lazy, so I want to be inspired to throw it into my app because what I've seen is so nicely done that I want it too.

<comment><AUTHOR> Thanks for your feedback. We will be redesigning our landing page in a few days, after we have gathered some more feedback.

</comment></comment><comment><USER7> If you go out of business, do my guided-tours go as well ?

Or perhaps you generate a tour that I can host myself ?

<comment><AUTHOR> Hopefully we will not go out of business anytime soon ;)

But to answer your question, we host the tours ourselves and provide you with a small script to insert into your page. And in the event of us going out of business, we will provide an 'offline tour player script' which you can host yourself. This is something we are already developing for some of our clients, who require it for sensitive internal apps, so we should be able to open it up for everybody if the need arises.

<comment><USER4> You say "we will provide" the self-host option but contrast that with "should be able to" in respect of using the solution that enables self-hosting.

I'm not in the market for this so I'll leave my conclusions aside.

</comment></comment></comment><comment><USER8> That 'Welcome' popup keeps coming back after refresh, it's a bit annoying, for me at least... I closed it and selected to 'never show again', however it comes back. All I want to do is to look around without any tours... Just my 2 cents.

<comment><AUTHOR> Oops, looks like we messed up and disabled user-tracking for that tour. We'll fix it soon. Sorry about that.

</comment></comment><comment><USER9> Seems like a super specific product, is there enough of a market for it? I do like it compared with the average website tour, but seems like they should create something more comprehensive somehow.

<comment><AUTHOR> It is a super specific product. We designed it to be simple and so one thing but to do it extremely well. In our opinion literally every webapp requires a guided tour. If not to explain the features on their landing page, then to guide users through the actual functionality of the app itself. So IMHO, there is a pretty large market for us. Over the next few weeks we will be writing about how our customers are using Easy Product Tours in their applications.

</comment></comment><comment><USER10> Answer: split test.</comment>