neandrake

I was introduced to QBasic by a friend in the mid/late 90's and spent a great deal of time on a community called NeoZones. The site allowed people to showcase their work, tutorials for learning, forums for talking with everyone else -- there was always something to dig into and such fun. I've never experienced a developer/programming community like that since. I hope there are still communities like that out there and would love to find some to be part of again.

I work with DICOM pretty regularly and it's cool to see new implementations of parsers popping up. I've recently been toying with an implementation in rust with a goal of eventually compiling to web assembly. I've not learned golang but exploring this implementation is a fun experience since having recently been digging into the dicom standard.

Manager: Bob get to work on the quick fix that will mitigate some of the attacks based on the published exploit to go out within a day, Alice get to work on the correct fix to address the underlying issue to go out in a few weeks when it's fully tested and ready.

I've been able to avoid git repos for the most part, or the few times I've had to interact with them I've kept it a bare minimum of contribution to avoid any complex workflow. It's not the best idea especially since the industry still largely uses git, however I haven't had the appropriate occasion to learn git while also learning the project and commit the git process to memory. I've heard you can use hg on git repos but I haven't investigated using that yet. By far I think the things that confuse me most are I believe two points you brought up in your post -- local vs. public changesets, and working in a detached head state (working on a feature branch and then rebasing onto primary branch for landing). I think on top of that I get overly confused when github is thrown into the mix as again I've not sat down to learn the process since it comes up only sporadically.

To the author - I'm in the opposite boat where I've used mercurial for nearly 10 years but any time I try to use git I get lost. Everything in your post rung out to me as why I rather enjoy and understand hg (with exception to absorb which I haven't yet tried).

I highly recommend checking out this blog which discusses adding a command which is a customized log. It's made getting a visible understanding of my working state & phases tremendously easy.

http://jordi.inversethought.com/blog/customising-mercurial-l...

Additionally if you're planning to use evolve, most of the instructions I've seen for using it indicate installing it via pip, however I've only run into issues with that (as well as coworkers and others). Instead I recommend cloning the evolve repository and pointing the extension location to it (seen in .hgrc gist below). Upgrading is as simple as going into the evolve repo and running `hg up`. I can't wait until it's shipped with mercurial. The evolve repo can be cloned from:

https://www.mercurial-scm.org/repo/evolve

This is from my .hgrc (for a mac) which customized the wip colors a bit more (and fixes a recent issue where one of the original revset commands used by the blog has been deprecated/removed).

https://gist.github.com/neandrake/e770ea7b3d6bf8299f6be2ca08...

If you've been keeping up with HN the past day or so there have been a bunch of great discussion around alternatives

[1] Kallithea https://news.ycombinator.com/item?id=17246386

[2] Phabricator https://news.ycombinator.com/item?id=17245649

[3] GitTorrent https://news.ycombinator.com/item?id=17234498

[4] GitHub Alternatives https://news.ycombinator.com/item?id=17241487

[5] Gitea https://news.ycombinator.com/item?id=17245246

[6] Pagure https://pagure.io/pagure

[7] ReviewBoard https://www.reviewboard.org/

[8] GitBucket https://gitbucket.github.io/

[9] Tuleap https://www.tuleap.org/

How do you mean? Custom statuses can be configured if you visit `/config/edit/maniphest.statuses/`. It's also pretty well documented how to customize statuses there.

See [1],

"Phabricator uses a lighthearted tone in documentation and some interfaces, and includes some features which primarily exist to add flavor or make things sillier.

We use this tone because we like building software like this, and the feedback we receive about it from users is overwhelmingly (and often effusively) positive."

[1] https://secure.phabricator.com/book/phabricator/article/tone...

A few years back I went through and evaluated multiple different tools primarily for their code review capabilities. I looked at quite a few including GitLab, Gogs, ReviewBoard, SmartBear, and Phabricator. We use Mercurial for source control and nearly considered migrating to Git because that's where the majority of tooling exists. We set up Phabricator and haven't looked back. Getting developers to use Phabricator/Arcanist was fairly organic -- learning to use a command line tool for creating the reviews was probably the most challenging but devs learned it because of the convenience of the code review.

It's very well-designed and has support for enterprise features like ldap, clustered servers, CI, etc. and there's no distinction between community/enterprise versions -- it's all open source. Other great features are task management, wiki, blogs, question/answer (a la StackOverflow), and of course memes/macros which add some lighthearted fun to code review. The engineering behind the product is top-notch which is evident from reviewing the tasks/discussions behind features [1], or even reviewing the source code. One killer feature for my company was Spaces, which allows setting up "walled gardens" -- we use it to allow external collaborators to create tasks, etc. without being able to see anything outside their own space.

Managing and maintaining Phabricator is pretty straightforward. It's a standard LAMP type of product (Linux, Apache, MySQL, PHP) which is easy for myself or IT to jump on and diagnose issues. It's the only tool I've seen which will also alert administrators to identified issues with configuration (when logged into web page). Additionally administrators of the tool do not have blatant all-access to projects, though that might be niche.

I'm glad it's getting more notice now, even if it's largely due to Microsoft acquiring GitHub. I don't know if Facebook uses Phabricator still but WikiMedia does and I belive the Mercurial development team is considering it [2]. Phabricator is a great product and worth trying out. Their community is located at [3] - they used to allow open access to their self-hosted Phabricator instance but it became too noisy as the user base grew so they've moved to discourse forums.

[1] https://secure.phabricator.com

[2] https://phab.mercurial-scm.org/

[3] https://discourse.phabricator-community.org/

You're absolutely right, though I assume using Apache/nginx with a reverse proxy is pretty standard for this type of scenario. Having a single static binary makes it convenient for developing, testing, and deploying.

Re: lambdas - if one-off code is being rewritten so many times maybe it's small enough that it doesn't warrant it's own function? I've never run into that issue and love to use lambdas where possible -- in fact the use of streams api has frequently been a source of simplifying existing boilerplate loop-type code. Any time lambda code seems to be repetitive and large enough to warrant refactoring that's usually what happens -> throw it into a method and call from the lambda (or just use method reference syntax if possible).

I've been reading Dreamland by Sam Quinones, which goes into detail and background of the past ~50 years or so about how we got into this situation. A large part of the WHY you're referring to I'll summarize as

1. Pain being identified as a vital sign and hospitals/institutions new-found focus on tracking and treating pain

2. Deceptive pharmaceutical marketing that painkillers are a be-all solution to pain and also non-addictive (Purdue/Sackler seem to be worst offenders here)

This lead to doctors prescribing opioid painkillers to many of middle-class americans who would likely have otherwise not come in contact with drug addiction. The book so far has been a really good read and also goes into detail around how heroin started spreading through the rust belt as well (feeding on the existing prescription addiction). I highly recommend it (about 65% through it right now).

With PuTTy you have to open a separate application and configure connection in a completely different manner. Compared to Linux/OSX which enables a "work in a terminal" model, where "ssh", "scp", etc. are commands that can be used from within an existing terminal. It feels like a completely separate tool from the terminal instead of integrated with the terminal. I think this is a similar argument that users of text-based-editors (vim, emacs) have over using GUI-based editors.

I quoted this elsewhere but this part makes it sound like they are intending to move over large parts of the implementation into rust in the long run, migrating away from python due to the size of the project becoming more difficult to maintain

> In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial's development velocity.

Using rust for a shared library implementation seems like it would mean a big improvement for mercurial's tooling in the long run. Right now the options are command line invocation or using the python library (effectively puts a requirement on implementation). Though I'm not sure the integrations I'm aware of[0] would benefit from a shared library.

[0] https://secure.phabricator.com/T9548

It looks like in their last sprint meeting (end of Sept[0][1]) there was a lot of planning and talk about moving parts of mercurial to rust. From the history of sprints[2] it sounds like facebook first started experimenting with some mercurial implementations in rust and may be one of the big contributors spearheading this (though I also see indygreg and durin42 around the phabricator projet giving mercurial advice). I'm a fan of both rust and mercurial so this is exciting news to hear.

[0] https://www.mercurial-scm.org/wiki/4.4sprint#Rust

[1] https://public.etherpad-mozilla.org/p/sprint-hg4.4-NOSPAMREM... (remove everything after-and-including the last hyphen, I left it in since it seems like they don't want a direct link that's easily scraped?)

[2] https://www.mercurial-scm.org/wiki/4.0sprint

There was also this point that was phrased as a comparison to python but I think works equally as well for choosing rust over c:

> In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial's development velocity.

It's possible this might be more documented on old warez/cracking/serial # generation tutorials if they're still around anywhere. This is only speculation but I imagine the process would be something like breaking a CD-key into multiple parts (a unit#, salt, hash of the unit#+salt)

1. Using unit# + some known/random salt, compute a hash

2. Mix-in the unit# + salt to the resulting hash in some deterministic fashion (prefix, suffix, or maybe inserting/replacing into a known/random location)

3. Convert the hash result into a CD-key format

Generate one for each unit produced, print on a label and attach to the distributed product. When installing, the process to verify the key would be

1. Extract the unit# from the entered CD-key (or if randomly inserted/replaced just do this for each possibly bytes assuming its the unit# + salt)

2. Using the unit# follow the same 3 steps above to get a CD-key

3. Compare the generated CD-key to the one entered for validity

Using hash is fast, produces an output with a very large output range (not easily guessed) and unlikely to have collisions, while also limiting the possibly valid keys to (roughly) however many bits necessary for a unit#. This method also allows for offline validation since the key to the hash is being shipped as part of the CD-key, and this was back in the days when a constant-connection to internet wasn't available or necessary for licensing.

The downside, which was the bane of most producers, is that a reverse-engineer who acquires a copy of the software can use a debugger or disassembler to extract out the first 3 steps above to create a keygen. Once the keygen was out though basically anyone could generate their own valid keys. In order to combat this software makers started requiring an additional step that after validating the key it contacts a central server to see if anyone else has used it or not...

> How did the authentication system work? How difficult was it to brute force? Does it simply involve a master key creating individual subkeys? Is it RSA?

Producing individual builds/images to burn onto CD's was unlikely as it would make the CD production process impractical -- a single build/image for burning CD's was likely used until they ran out of stock and/or wanted to ship updated versions of the software. Using RSA would otherwise be a great solution as the software producer could generate private keys for each sold license. Many newer software licensing schemes have this approach.

Edit: Related answer on StackOverflow: https://stackoverflow.com/questions/3002067/how-are-software...

Does anyone have insight as to why they recommend only using Chrome, including using Tor with Chrome and not the Tor browser (fork of Firefox)? Is this just to keep things consistent or are there privacy/security concerns over using Firefox?

Isn't is still fraud though? Submissions of opinions to a government agency under citizen's names without their consent or even knowledge -- it sounds illegal and not addressing this sorta thing now sets a crazy precedent.

Another one you can check out is Codebook - https://www.zetetic.net/codebook/

No Linux support though

If you want requirements you gotta write 'em yourself~

Adding more complexity to the example - what about offering a digest-format where a user opts in to only receiving one email a day.

I suspect that the primary developers may be unfamiliar with AD/LDAP.

https://github.com/wekan/wekan/issues/119

What makes Phabricator not suitable for "normal" projects?

Check out Phabricator - https://phacility.com/phabricator/

GitBucket's UI used to be a full rip of GitHub until they received a notice to change it [0]. They then switched over to using a UI built with AdminLTE [1]. I'm not sure if the current UI is still based on it though.

[0] http://gitbucket.github.io/gitbucket-news/gitbucket/2016/03/...

[1] http://gitbucket.github.io/gitbucket-news/gitbucket/2016/07/...

What are the long-term health insurance related issues if they find out you didn't follow the doctor's prescription?

Maybe it's nostalgia for pre-Web 2.0 designs but I love your website; it has character and feels personal compared to most pages I peruse.

I think the idea they were going for is that Google Health would be an EMR intended to be used by institutions except that the patient is in control of their record - enabling them to take their health record to any provider. The problem is that institutions have close to no reasons for investing into something like that.

I think Microsoft HealthVault was more of what you describe, where it's a portal intended to be used by patients.

Yea I saw that was recently updated. I'm excited to see tooling be updated for Mercurial. I was hoping the recent updates and re-release as open source of RhodeCode would spur some updates from the Kallithea project.