Hacker News new | past | comments | ask | show | jobs | submit login

The truly surprising behavior to me is choosing to name the forked project nsm.

Fork the heck out of anything for any reason you like. Say critical things on mailing lists. Fight over who's right and who's a jerk. But actions which lead to less clarity -- like, say, polluting a claimed name in the process of making a fork -- doesn't look like good faith to me.




> The truly surprising behavior to me is choosing to name the forked project nsm.

I think the point was having the binary be of the same name, so it could work as a drop-in replacement that is compatible with existing software.


New's bogus insinuation that Non had ads or spyware makes me disinclined to buy this innocent justification.


IIRC (anyone else in LAD-proper correct me) the insinuation came from using some standard boilerplate in a release announcement for the fork. The fork's release tagline outlined what open source was and how it is beneficial to users. Specifically there was mention of the fork not having any spyware/ads in it.

I agree with the posted article that saying "X doesn't have Y" from the fork implies that it is a differentiating factor, but it doesn't strike me as an intentionally malicious act. More of just not being familiar how such release blurbs would be read when applied to a forked project.


This seems like a very reasonable comment and I had exactly the same thought, yet I found this comment dead and had to vouch for it. Can any of the downvoters explain why? Or was this somehow automatic?


Some new accounts are automatically dead on arrival or if they post too quickly, and have to be vouched. Nothing sinister about it.


Didn't mean to imply sinisterness. Was wondering if an automatic process like that existed, so thanks for the confirmation.


Wouldn’t a compatibility symlink or shell script have been enough?


Perhaps, though you'd end up with the same 'nsmd', 'nsm-proxy', and 'nsm-proxy-gui' commands with the same 'NSM_URL' environmental variable. Ideally there'd be more separation, but then you do lose the drop in compatibility. For a longer lived fork it would make sense (IMO) to use the proposed symlinks, though initially it was basically the same exact software as upstream + a few modest patches.


The front-end GUI /usr/bin/non-session-manager is replaced by a symlink to nsm-legacy-gui in a New Season Manager install. One doesn't really run the daemon directly anyway.


> I think the point was having the binary be of the same name, so it could work as a drop-in replacement that is compatible with existing software.

This is a long solved problem, you don’t use the same name. That’s very bad joojoo.


I'm not sure that's a good justification for naming something the same as an existing project. What if someone forked Nginx or PostgreSQL and did the same thing? Would that be acceptable behavior?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: