Git 1.8.0 - <AUTHOR> https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.0.txt

<comment><USER2> > "git branch --set-upstream" is deprecated and may be removed in a relatively > distant future. "git branch [-u|--set-upstream-to]" has been introduced with > a saner order of arguments.

It would be great if changes to the git CLI were thoroughly thought through instead of one-off fixes like this. This is the reason the interface is such a mess.

      git branch foo --track origin/foo

But if you forgot --track:

      git branch foo

then it's:

      git branch foo --set-upstream-to origin/foo

and don't you dare do

      git branch --set-upstream-to origin/foo

Upstream and track are the same - why two different words?

And now we have --set-upstream-to and --set-upstream, which will be fun for git newbies to distinguish.

<comment><USER3> Wait, what exactly happens in that last one that I shouldn't dare do?

<comment><USER2> I should have written:

      git branch --set-upstream origin/foo

This counter-intuitively creates a LOCAL (!) branch named origin/foo which tracks the current branch. I would expect this to set the upstream of the current branch, given that most commands operate on the current branch unless otherwise specified. Instead it does something completely unexpected and useless.

<comment><USER4> which invalidates part of your point, because --set-upstream is now _deprecated_.

<comment><USER2> It's deprecated in the next release not this one, and it will be around for years to come. People will google and find the old way documented and have to read up on the difference, adding to the cognitivie baggage of git.

Regardless, my point is the interface is horrible and this is just adding to the patchwork. Why not add --track semantics or unify these flags?

<comment><USER5> \--set-upstream is deprecated in this release.

<comment><USER6> Deprecated, but not removed yet. It "may be removed in a relatively distant future"

<comment><USER5> This is what deprecated means. You can't just remove an API that's existed for years and scripts may depend on without giving them time to adapt. This shows a warning when it's used so it's clear which scripts should be changed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7>
        You're over the rate limit. Serve this file from your own servers. Contact firstname.lastname@example.com if you have questions.

<comment><USER8> I'm surprised they don't exempt high profile public projects from limits like that. Git being hosted on Github is hugely beneficial to their image.

Any roadblocks should be eliminated for VIPs, especially if the consequence is just a few bucks more in bandwidth bills.

<comment><USER9> We actually don't care about rate limits with this type of raw request. The limits are in place because people (usually porn sites) hot link js/css/image assets which can lead quickly to an insane number of requests.

If file extensions could be used to determine whether a resource could be used like this, we'd only apply the rate limits to those. Browsers don't care about extensions or event content types though. They'll happily use whatever's at the other end of a URL for <link rel=stylesheet>, <script>, and <img> tags.

As for whitelisting, it's a path we just don't want to go down for raw requests. We do a lot of that for the API and it isn't cheap to maintain.

<comment><USER10> Browsers will ignore content-type in many cases (html5 embraced that quirk), but they do have to sniff the bytes to confirm their hunch. You could use `file` to detect images. Or use the content length, maybe by changing hit quotas into bandwidth quotas.

[https://code.google.com/p/browsersec/wiki/Part2#Content_hand...](https://code.google.com/p/browsersec/wiki/Part2#Content_handling_mechanisms) <http://mimesniff.spec.whatwg.org/>

</comment></comment></comment></comment><comment><USER11> [http://git.kernel.org/?p=git/git.git;a=blob_plain;f=Document...](http://git.kernel.org/?p=git/git.git;a=blob_plain;f=Documentation/RelNotes/1.8.0.txt;hb=8c7a786b6c8eae8eac91083cdc9a6e337bc133b0)

<comment><USER12> Thank you.

</comment></comment><comment><USER13> That's a good change. I've never had the need to "git push" an entire repo, and pushing the current branch is simply more natural to do.

</comment><comment><USER14> That's great, guys using Homebrew can get this version by writing these:

        brew update
        brew upgrade git

</comment><comment><USER15> I really wish a day when I am able to download the code with minimal footprint. (few previous versions).

<comment><USER16> That's a _shallow_ clone: git clone --depth N ...

</comment></comment><comment><USER17> Seems to be back up. I assume they waived the rate limit.

        curl --head https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.0.txt
        HTTP/1.1 200 OK
        Server: nginx
        Date: Mon, 22 Oct 2012 05:32:02 GMT
        Content-Type: text/plain; charset=utf-8
        Connection: keep-alive
        Status: 200 OK
        X-Runtime: 14
        X-RateLimit-Limit: 100
        Content-Length: 1
        X-Frame-Options: deny
        Cache-Control: no-cache
        X-RateLimit-Remaining: 100

<comment><USER18> X-RateLimit-Limit? Sounds redundant.

<comment><USER19> They're the same headers the Twitter API uses: <https://dev.twitter.com/docs/rate-limiting/1.1>

</comment></comment></comment><comment><USER20> Why in the Release Notes do they use the verb "learned" to describe adding a command line option to a feature?

      "git cherry-pick" learned the "--allow-empty-message" option

It's not like Git has obtained sentience and has started to teach itself new tricks, though that would be an interesting development.

I understand what they are trying to say I just thought the choice of verb and subject was odd, leaving out the developers as those acting on the code.

<comment><USER21> Writing it in the passive voice is slightly more awkward. E.g., "git cherry- pick" was enhanced with an "--allow-empty-message option".

Similarly, writing it in the active voice but attributing the verb properly ends up with meaningless words: "Developers taught cherry-pick to..." or "We taught cherry-pick to...". Every entry would begin that way; having the first words be the relevant subsection of git makes it easier to skim through the release notes.

</comment></comment><comment><USER22> Does someone have more info on this:

A credential helper for Win32 to allow access to the keychain of the logged-in user has been added.

<comment><USER23> You can find it in contrib: [https://github.com/gitster/git/tree/master/contrib/credentia...](https://github.com/gitster/git/tree/master/contrib/credential/wincred)

See man 7 gitcredentials on how to set it up.

</comment></comment><comment><USER24> > In the next major release (not _this_ one), we will change the behavior of > the "git push" command.

So wait, is that in this release or not? Why put this at the very most top part of the file without even mentioning what release it will actually be in?

<comment><USER25> No, it is not in THIS release. it is in the NEXT major release. 1.8.0 is the current major release. 1.9.0 (or 2.0.0, whatever) will have the change.

</comment></comment><comment><USER26> Anyone have a mirror? GitHub has stopped serving this as it's over their rate limit.

<comment><USER25> [https://github.com/git/git/blob/master/Documentation/RelNote...](https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.0.txt)

</comment></comment><comment><USER27> Can git work with subtrees yet?

</comment><comment><USER28> Is updating worth it?

</comment><comment><USER29> looking for saner nested submodule pulling , reading now

</comment><comment><USER30> btw, what is Github's rate limit?

<comment><USER31> I don't know, but it's not meant for hosting pages or page resources unless you use their "pages" feature, so they set it pretty low.

<comment><USER32> Didn't Github suffer a DoS attack in the past few days?

<comment><USER31> Yea, these notices under light load are nothing new though.

</comment></comment></comment></comment><comment> xyz-x Awesome, now when and where do I download it for Windows??? "Please checkout the source and build it yourself" - wtf.

<comment><USER33> Or wait for it to appear in the Cygwin release cycle. Or, msysgit. I think you're being overly dramatic.</comment></comment>


Bob Chassell, author of "Programming in Emacs Lisp", has passed away - <AUTHOR> http://www.fsf.org/blogs/community/goodbye-to-bob-chassellk <comment><USER2> 404</comment>


Get Your API Right - <AUTHOR> http://wonderfullyflawed.com/2009/07/02/get-your-api-right.html

<comment><USER2> I like everything the author mentions, with one addition: besides XML and JSON as media types, I like to provide xhtml with a microformat. This allows browsers to interact with most API functionality directly, which has development benefits you just won't realize until you try it.

The key is that your xhtml must be generated dynamically from an internal data structure, and your JSON and XML should be generated dynamically from the same data structure. This ensures consistency both within and across media types, and it simplifies development because you can stop worrying about the output format; you just need to worry about the internal data structure which represents your resources. The transformation into a client-usable representation occurs completely separately from all of your business logic.

</comment><comment><USER3> The author says never to put data in attributes, always put it in tags. He shows and ID tag inside and ASSET tag.

The ID should be an attribute, and all the other data should stay as tags. This is because the ID won't change and identifies the ASSET. Anything else could change and is just data.

</comment><comment><USER4> these are important

1\. use hyperlinks and link relations i.e. <link href="/people/bob" rel="friend" />

2\. don't bother with multiple media types (unless /absolutely/ necessary) . If appropriate try to use/extend an established type such as Atom/AtomPub

3\. make sure you set your cache control headers appropriately</comment>


Let's talk about usernames - <AUTHOR> https://www.b-list.org/weblog/2018/feb/11/usernames/ <comment><USER3> > So if you're enforcing unique email addresses, or using email addresses as a > user identifier, you need to be aware of this and you probably need to strip > all dot characters from the local-part, along with + and any text after it, > before doing your uniqueness check. Currently django-registration doesn't do > this, but I have plans to add it in the 3.x series.

Sorry what? That seems pretty unneccessary. A third party system to dictate how a third party system handles it local alias system for emails? I can't see any benefit to that.

Whether a mail server handles '+' in a standard way is not guaranteed, and surely it is up to the user how they use that feature if enabled.

<comment><USER4> If you don't do this your system may allow users to sign up for multiple accounts and double-dip on signup benefits, free trials and other "one per account" features. (Barring additional controls, of course).

<comment><USER5> Or they could just sign up at one of the numerous free email providers with a different username. Stripping the + suffixes is only providing one thing - pain for the users that want to use it.

<comment><USER6> It's way easier to write a script to generate thousands of variations on the same email address than to sign up for a thousand different accounts. I've actually been bitten by this bug before... or rather, my company was bitten by an affiliate who neglected to sanitize their emails this way and someone was able to create thousands of gift cards in our system.

Having said that, in development, it's super nice to be able to create addresses with +'s in them.

<comment><USER7> What you say is not untrue, but it's still bad advice to do it -- a security red herring. First of all, you don't know that 100% of mail servers ignore characters after the +, so you can't safely strip those characters or you might not end up with a usable email address. That goes double for stripping the dots/periods, which gmail ignores but many other mail servers do not.

On top of that, it's just as easy to set up a catchall email address -- an email box that accepts all mail for a domain, literally firstname.lastname@example.com. So a malicious actor could sidestep this security attempt with minimal effort, but it still inconveniences legitimate users despite being worthless from a security perspective.

<comment><USER6> True, true. As I mentioned below, in my case, it was even usernames, just entering you email for a free gift card. The attacker actually used dots with a gmail address.

<comment><USER8> There are soooo many ways to easily game the email side of it that you would be better off using other means of detecting uniqueness (rate limit per IP address, rate limit per hash of IP address and user-agent)

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> > So if you're enforcing unique email addresses, or using email addresses as a > user identifier, you need to be aware of this and you probably need to strip > all dot characters from the local-part, along with + and any text after it, > before doing your uniqueness check. Currently django-registration doesn't do > this, but I have plans to add it in the 3.x series.

Please don't "normalize" email addresses like this. Not all mail systems are Gmail, and many do treat "email@example.com" and "firstname.lastname@example.com" as different identities. And even if we are talking about Gmail - it's not your identity system's job to deduplicate different logical addresses for the same physical inbox.

<comment><USER10> To emphasize your point: don't touch email addresses. You can get away with doing equality checks on NFKC case folding, but don't assume that you can store a lowercased email address and have it work properly.

Lots of weird email systems exist. Don't assume that everybody works like gmail. And do test that things work right with uppercase letters in email addresses: I've been locked out of systems before because I use an uppercase letter in my email address and one half of the system was trying to match the lower cased version to the actual text.

<comment><USER11> Unfortunately, Gmail rules the world and has trained people to expect that they can be sloppy and inconsistent and enter their email address as 'johndoe' or 'john.doe' or 'JohnDoe' or 'John.Doe'... etc. and it just works, I don't understand why _your_ site is broken, because _my_ email works!

And when that happens, trying to patiently pull a "well, _technically_ " and explain to them about RFC this and the specs say that is a way to lose users.

(I actually have extremely strong feelings about email, email addresses and the whole associated mess of specs, but had to tone it down for this article since it was mostly about the various traps you can wander into from naïvely thinking that you can just read a spec or implement something obvious and get away with it)

<comment><USER12> > And when that happens, trying to patiently pull a "well, technically" and > explain to them about RFC this and the specs say that is a way to lose > users.

Not in my experience. Showing compassion and agreeing with them that what happened is terrible and you wish things were different but you didn't call these shots back in the days and if they want improvement you can both go together and complain to google, the service which is actually broken.

Most people just want to be listened to. If you can do that, you'll earn a loyal fan, even if you don't do exactly what they tell you to when agitated. Some will even appreciate learning more about the email systems after the fact. They may even get the feeling you went above and beyond by offering to help them with matters outside of your site.

<comment><USER11> _Most people just want to be listened to._

Many people, even after being listened to, and even after having things patiently explained to them, still continue to enter someone else's email address into forms which will send sensitive information to that email address, and complain that they never got their important email, or that some "hacker" has "hacked" "their" email, etc.

In a perfect world this would not happen. We don't live in a perfect world and are unlikely to live in a perfect world any time soon, so we should not be asking "how can we be pedantic and tell users it's their fault for not reading the RFCs", we should be asking "how can we protect users from their ignorance of the RFCs".

(when I wrote this article, I did not expect that this would be the single most controversial line in it from HN's perspective, but I guess by this point I should have anticipated it)

</comment></comment></comment></comment></comment><comment><USER13> > And while I could write this as one of those "falsehoods programmers believe > about X" articles, my personal preference is to actually explain why this is > trickier than people think, and offer some advice on how to deal with it, > rather than just provide mockery with no useful context.

Thank you, so much.

I just wanted to highlight that for anyone who looked at the comments to decide whether or not to read the article.

<comment><USER14> Yeah, this is a really good article. I really wish more auth systems made use of the tripartite identity pattern.

</comment></comment><comment><USER15> In my 20 years of experience validating email addresses, I've found one thing that works every time without fail:

Send email to it

That is literally the only way to validate an email address. There is no regular expression or algorithm that can validate and/or deduplicate an email address.

You must simply treat every email as unique until you send an email to it and that person proves otherwise.

That being said, this article brings up a lot of important things about confusables that everyone should definitely be aware of, especially if you're going to have public identities.

<comment><USER16> How does sending email to it prove it's not a duplicate? For example:

        firstname.lastname@example.com

        firstname.lastname@example.com

Both resolve to the same email at the users end.

<comment><USER17> well with gmail they are the same email. But with other mail applications, those could be two different email addresses. You are going to need to test all the different email services and find out which do this and which do not do this... which is no easy task

<comment><USER18> > which is no easy task

Which is impossible; a number of people run their own email or use a small friend-run email server, and you can't possible discern the delivery rules from the outside.

<comment><USER11> _number of people run their own_

Yes. A small number is a number.

If we could go back in time and force every single implementer to follow every relevant RFC to utter perfection (and make sure all the RFCs were perfectly unambiguous), I'd be more sympathetic.

But email is fucked. The sheer number of oddball things, hacks, workarounds, deviations and other bits of mess that implementers have engaged in over the years means the RFCs should be treated as at best a loose hopeful outline of how email might in theory work.

</comment></comment></comment></comment></comment><comment><USER19> > So if you're enforcing unique email addresses, or using email addresses as a > user identifier, you need to be aware of this and you probably need to strip > all dot characters from the local-part, along with + and any text after it, > before doing your uniqueness check. Currently django-registration doesn't do > this, but I have plans to add it in the 3.x series.

Isn't this a really dangerous game to play? Just because some major MTA's assign a class of addresses to each user doesn't make each member of that class not a unique identifier in general. Is it worth the headache to maintain a list of various email systems' policies rather than just treating them all as unique?

<comment><USER10> The email RFCs explicitly say thou shalt not interpret the localpart of an email address, unless thou art the MTA of the domain in question. Even case folding is forbidden. And the wisdom of people who work with email is... the RFCs have good advice here: don't assume anything about how the localpart is structured.

You can generally get away with treating the names as case-preserving (as distinct from case-insensitivity), and you are probably safe in rejecting quoted localparts. But beyond that, even forcibly lowercasing email addresses, is likely to cause problems.

<comment><USER11> Like it or not, the RFCs have lost. "How Gmail does it" is now how email works in the minds of a stupendous number of people. So if Google says 'johndoe' and 'john.doe' are the same, we're stuck with the reality that 'johndoe' and 'john.doe' are the same.

<comment><USER20> It's completely legitimate to use variations on an email address for different accounts on the same website.

Also, it's useful to make use of +foo or varied usages of dots to create a unique email address for each site: for one thing, it'll help if one site leaks your email address, then it'll let you trace the origin of the leak if that email address gets unwanted email.

Finally attempting to deduplicate email addresses before authentication is almost as bad as lowercasing the password before checking if it matches.

<comment><USER11> There's a line in the Zen of Python: "practicality beats purity". If I can avoid someone filing a bug or a support request by knowing that Gmail has trained people to believe a bunch of distinct (according to RFC) mailboxes actually aren't distinct, I'm going to avoid the support request. The -- by comparison -- minuscule set of users who A) actually understand the relevant specs and B) care enough to yell at me in an HN comment are going to lose that battle every time.

<comment><USER20> > Gmail has trained people to believe a bunch of distinct (according to RFC) > mailboxes actually aren't distinct

I'd be fairly surprised if your average user of gmail knew this: I know it and I use it in part because it lets me _distinguish_ different accounts on the same site. Second-guessing someone who's taking advantage of this feature is more likely to generate tech support requests than not.

<comment><USER21> Knowledge of the plus trick has gotten pretty widespread. Anecdotally, I know a lot of non-technical people that use a single +spam address to route to a spam folder.

Non-anecdotally, articles with large numbers of views/comments about the trick can be found with a quick Google search on non-techie sites like NYT/HuffPost/BusinessInsider/Buzzfeed/Pinterest/etc. Not that those are definitive, but I think knowledge of this is more widespread than you think.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> > _Many systems ask the username to fulfill all three of these roles, which is > probably wrong._

What system with any non-trivial level of use uses the text username as (1) the FK in the database, as opposed to the generated or auto-incremented ID in the db; (2) the login name; _and_ (3) the publicly-displayed displayed "name" of the user for others to see?

Plenty of forums etc use the login name for #2 and #3, and I'm not convinced by this article that that's the wrong way to do it. I haven't ever seen a _single_ professional product that uses the text username that a user logs in with as the actual DB-level foreign key. That's grade school level database design.

<comment><USER23> When logging in, how do you get that autoincremented ID column? Some more complex variant of "SELECT *.id WHERE username = $1". So functionally, yes the username is the root identifier that pulls the very first record that then allows other joins to occur. But you are right, the username column is not literally the key being joined on.

There is also the security issue that by having the login name also be the publicly displayed name lowers the bar for attempting to make a targeted attack on the site, as well as other sites where the attacker suspects the victim may be using the similar login name. This can particularly be true in cases of harassment across platforms, which while is not a computer science security issue, it is a personal psychological security issue.

<comment><USER24> > the username column is not literally the key being joined on

That's exactly the point though. If you join on the username than allowing emails/usernames or whatever that identifier is to be edited is very hard. How you identify the row to auth against is literally the point of a username.

</comment></comment></comment><comment><USER25> > Uniqueness is harder than you think

Discord has a very interesting solution to this. They have user names and user ids. User IDs are tied to emails and the user's name seems to just be a random text identity for displaying to users. I assume most of their backend code used a unique, sequential or random, integer ID to identify and talk about users while their frontend just makes the ID to a "user name". As long as you slap account creation behind a verification email and don't mind one user being able to sign up for multiple accounts you side step many of the larger problems that come from choosing user names because, in effect, you are choosing the "Real" username and you can make any guarantees that make writing all of your other software easy.

<comment><USER26> Blizzard also uses a style like this. While it's great for some use cases, it really sucks for others.

In Blizzard's implementation, I can't add a friend by just knowing their name, I need their id number as well, and the process for finding it isn't exactly front-and-center.

<comment><USER27> I remember when I've switched to bnet ID and my tag became username#1337. People sometimes ask me if I've bought the name or something like that.

<comment><USER28> I got Ambroos#2772 or #2727 (can't remember, it's been a while). Which is fun, because I have a thing with 27 as it's the birthday of all my grandparents (moms side) grandchildren.

</comment></comment></comment></comment><comment><USER29> This should be exhibit number one why you should always favor open source libraries rather than writing your own plumbing functionality, especially around authentication and authorization. The onus should be on the developer to explain why the open source library isn't a fit, rather than defaulting to 'roll your own'.

The edge cases discussed don't pop up that often unless you have lots of folks using your software or are really diligent about fuzzing and testing edge cases. If you roll your own, say, username system, you probably aren't going to fall into either of those two cases. Which means you're vulnerable.

<comment><USER30> but then again, open source does not mean its good software, obviously. there should be some way quickly check if a library meets security best-practices. like a some sort of "vetted software" reference

<comment><USER31> Also, using a 3rd party library for something as important as authentication because you don't know how it works doesn't sound much better nor secure.

Like storing sensitive data in the authn's session system because you don't understand encryption vs signing nor how to find out -- maybe it's time to just sit down and credentialize as a craftsman.

The authn/z systems I've used that were the biggest headaches in my life were kitchen sink frameworks trying to generalize over everyone's creature features, and they were often tied to a company/community culture of not- gonna-touch-it that only hurt users and security.

<comment><USER29> I think you should absolutely understand any third party systems/libraries you use, especially when it is as important as authentication. Using a third party component doesn't free you up to be lazy or to use it incorrectly.

My comment was stating that you should default to these types of libraries and only roll your own if you can't do what you need to, simply because they're more likely to handle edge cases that can have serious implications.

Do you do unicode normalization on your usernames? I freely admin that I don't, and wasn't aware it was needed until I read this post.

</comment></comment></comment></comment><comment><USER32> I agree with everything here except the email addresses example. Yes I do want to register email@example.com and email@example.com. Those are different accounts, please don't mess with that.

<comment><USER21> There may be very good reasons for a site operator to disallow this. I mentioned some of them elsewhere in these comments: [https://news.ycombinator.com/item?id=16358625](https://news.ycombinator.com/item?id=16358625)

</comment></comment><comment><USER33> Hey community, shameless plug: For the purpose mentioned in the article to disallow certain usernames, I created this GitHub Repo sometime back. Feel free to submit a pull request :)

[https://github.com/dsignr/disallowed- usernames](https://github.com/dsignr/disallowed-usernames)

<comment><USER3> Seems I should add some more to [https://github.com/flurdy/bad_usernames](https://github.com/flurdy/bad_usernames) :)

<comment><USER33> Nice! Maybe we should merge our efforts.

</comment></comment></comment><comment><USER34> > So if you're enforcing unique email addresses, or using email addresses as a > user identifier, you need to be aware of this and you probably need to strip > all dot characters from the local-part, along with + and any text after it, > before doing your uniqueness check.

Please don't do this, lots of people (including myself) use the '+' hack to separate accounts for different contexts (business/personal, different projects/clients, etc).

<comment><USER35> I think he wasn't proposing to remove the '+' part from the address stored, but splitting the address into smaller parts when doing the unicode verification and checking if there's isn't already a 'john.doe+xxx' when you register with 'john.doe+yyy'.

<comment><USER34> I realize that. What I'm trying to say is that I like to create 'firstname.lastname@example.com' and 'firstname.lastname@example.com' accounts with some services.

Checking for the existence of any 'firstname.lastname@example.com'-like accounts would mean I have to register an entirely separate email account or set up (another) email forwarder/alias.

</comment></comment></comment><comment><USER36> My Linkedin username: [https://www.linkedin.com/in/Αdmin/](https://www.linkedin.com/in/Αdmin/)

<comment><USER37> Brilliant! Does it cause you any problems?

<comment><USER36> I'm using this username for about 6 months now. No problems so far...

</comment></comment></comment><comment><USER38> If you're going to allow unicode usernames then you should casefold them rather than lowercasing them before normalizing as NFKC.

You should ideally also store a second copy of the username in the original casing and normalized as NFC for display purposes, as some users care a lot about seeing their username exactly as they entered it. (And in fact not allowing this may be seen as culturally insensitive in some cases, much like not supporting unicode.) The same applies to the user's first and last name, which you can store in NFC for display purposes and casefolded into NFKC for string comparison (e.g. search) purposes.

That said, most sites limit usernames to ASCII characters so that they can be (easily) used in URLs. In this case you don't need to casefold or normalize, just converting to lowercase is enough.

<comment><USER11> _If you 're going to allow unicode usernames then you should casefold them rather than lowercasing them before normalizing as NFKC._

I wanted to stay out of the Python 2 vs. 3 quagmire in this article, but it's worth knowing that in Python 3.3+, strings have a 'casefold()' method:

[https://docs.python.org/3/library/stdtypes.html#str.casefold](https://docs.python.org/3/library/stdtypes.html#str.casefold)

Unfortunately, since Python 2 still has around two years of upstream support before EOL, I can't universally recommend people just use 'casefold()', no matter how much I'd like to.

</comment></comment><comment><USER39> These "battle hardened" articles are fascinating. It is the output of years of experience and learning from real problems. It's building the best practices guides, and building the tools to scan for the edge cases. A great read!

</comment><comment><USER40> Worth mentioning Spotify's account hijacking problem when using unicode [https://labs.spotify.com/2013/06/18/creative- usernames/](https://labs.spotify.com/2013/06/18/creative-usernames/)

</comment><comment><USER41> When it comes to email address normalization, it sounds like we could do with a standardized way for a domain to express normalization policies.

Could be as simple as publishing a set of regular expression subsitution rules, specifying (for example):

* render to lower case (because this particular domain is case insensitive)

* drop periods (because this domain treats them like gmail does)

* drop '+' and any subsequent characters (because this domain treats them like gmail does)

* ASCII only (because mail software is old, and doesn't support unicode)

Etc.

Each domain could then publish their own rule, perhaps in a DNS txt record, and anyone needing to check if two email addresses alias to the same could run the correct checks.

<comment><USER42> Some users capitalize their email address, and they expect to see it capitalized.

I think a better solution would be to use a case insensitive collation on the database for the email column.

If the user changes the capitalization of their email, treat it like any other email change (validate the new email via email token)

</comment></comment><comment><USER43> My strategy is to think of a name so unique that no one else would think of using it. The one on my HN account I originally cooked up in Nov. 2014, and I never had to extend it with numbers to get it accepted on various forums (yes, most of them were fine with changing the nick). My biggest gripe is that since YT changed their username system in October of that year, my most popular channel is stuck on an old username despite being a few months older.

</comment><comment><USER44> Aside from the authors library, django-registration, what other similar libraries for Python and other languages have taken all or some of this into consideration?

Excellent read by the way. Many things I have never considered or even worried about before.

</comment><comment><USER45> > 3\. Public identity, suitable for displaying to other users

Many sites-- like HN-- may not even need that. If you have system and login identity you can just display "dingus" as the name of every single user and the system should still work the same.

<comment><USER46> I think without display names having discussions would be difficult, as people find some identifier useful to follow along. Even if it's a pseudonym, it's hard to build a sense of community without being able to distinguish those in your community. Or am I misreading you?

<comment><USER47> 4chan and other imageboards manage to have discussion fine without unique identifiers.

<comment><USER21> It's a different kind of discussion, though. There is value to each type of threading, but no one-size-fits-all approach--as evidenced by the fact that 4chan lets you opt out of anonymity.

</comment></comment></comment></comment><comment><USER48> I don't follow the initial premise.

>Well, it's easy until we start thinking about case. If you're registered as john_doe, what happens if I register as JOHN_DOE? It's a different username, but could I cause people to think I'm you? Could I get people to accept friend requests or share sensitive information with me because they don't realize case matters to a computer?

Just this month we fixed this issue by using a citext column in postgres. So yes, it is easy. Maybe I'm missing an edge case here?

[https://www.postgresql.org/docs/9.1/static/citext.html](https://www.postgresql.org/docs/9.1/static/citext.html)

<comment><USER49> It's easy if you thought about it before you have users; people didn't and then need to ensure that a fix doesn't break something.

<comment><USER50> Yeah. We switched to CITEXT for email addresses after 10k users, and had to go through quite a complex process to merge about 30 user accounts that had signed up duplicate accounts with email addresses varying only in case). It was a major PITA

</comment></comment></comment><comment><USER51> The entire concept of usernames that are unique and permanent is stupid and even "cruel". The reality is that a relatively small handful of privileged early adopters get good usernames that match their identities, and everyone else gets screwed. These identifiers then act like tatoos that you got a long time ago and are stuck with for the rest of your life: people end up reminded every day of a sport they can no longer play due to an injury ("hockeystar") or loves lost ("iheartjessie"), attached to a joke that is no longer funny or to a thought that they found adorable as a 13 year old (when you are legally asked to "choose a username": a modern era coming of age scenario) but which adults find inane, or to a nickname that means something different than you realized to some people and now can't change.

The reality is that there are almost ten billion people on this planet and they live for upwards of a century. You are simply deluding yourself if you think it is reasonable to build a system with unique, permanent usernames. Nothing in the real world works like that, including trademarks. And it just helps enforce the very problem that people try to trust usernames and then get tricked by people who sniped usernames that are tied to other peoples' well- known identities (leading to abused "verified" badge systems and legal challenges and expensive hostage scenarios... it just sucks).

And for what? To make it easier to hand-type a URL? Does anyone even do that? I am super technical and I barely even do that in 2018, as if nothing else there are too many websites in existence to remember all of their one-off URL schemes. Like almost everyone, I either use the site's built-in search feature or I do a search on Google to find people, and let a combination of page rank and personalized results guide me to the right destination. Some web browsers don't even show URLs anymore!

Here is a great example of where it is completely insane: Facebook. There is absolutely no good reason for that website to have usernames for regular users, and they frankly shouldn't have usernames for businesses either. It isn't even clear to me that the app--which most users are using, not the website--even has a way to show people's usernames, which means this is an identifier which somehow everyone knows must be chosen and must be unique and is nigh-unto permanent but which somehow is also simultaneously meaningless but is also a horrible point of contention? What?

I am lucky. I spent a bunch of time in 1994 to select a username, and despite being 13, I was mature enough to come up with something that wouldn't ever come to cause me complex problems. People ask me what it means, and it essentially doesn't mean anything: it has only a positive connotation to me when I hear it, it is entirely neutral, and it had no existing usage I could find. Yet, I also still got screwed, as I am semi-famous, and everyone knows me as this username. I have kids who look up to me enough to want to take my name as a show of support and I have to essentially be the big bad asshole about it because in a world of unique and permanent usernames, people then assume the kid is really me. On the other side, I have been asked to rename myself by moderators of various forums as they couldn't believe the real saurik got an account on their site, and it was "confusing" people.

And so in the end we all have to deal with the worst-case scenario anyway: unless you do nothing but sign up for random sites rumored to be interesting constantly (which I seriously tried to do), you eventually will succumb to needing a way to prove who you are on multiple sites and tie together those identifies. And for _most users_... as in _virtually all_ "normal users", that moment comes when they are using only _two_ websites, as their username was probably something like jay.freeman.178 as everything that was even remotely interesting to them was taken a decade earlier by literally a different generation of humans, so they let the website automatically generate one.

In a world where everyone is having to solve the worst-case problem anyway, every site should just have numbers as unique identifiers, at most have some kind of trust score for degrees of separation on the site (so you can get a feeling for "is this the saurik that I met?"), and everyone should be trained "names don't matter and if you see someone with that name it doesn't even slightly mean that they are the same person you met last week".

<comment><USER52> > every site should just have numbers as unique identifiers

Do you realize how impractical it is for users to remember these numbers for every site? Until we get to the stage where every non-English-speaking user _and their grandma_ finds a password manager convenient, this proposal won't even pass the laugh test.

<comment><USER53> That's why we need biometric hardware everywhere and use its data as a login, not as a password. Bio data is mapped onto a long UUID and user just sets whatever username he wants to be displayed. We even have means to smoothly transition from no hardware to 100% coverage - just allow manual UUID input for systems where biometric is unavailable - e.g. you have a pair of face/ID on the phone, fingerprint/ID on laptop and just ID on PC.

<comment><USER54> Serious question: what happens when you lose your finger? Or you have an accident and your face gets mangled? Or a ball hit your eye and you lose it?

You have to remember your UUID? Probably it would be more like a file than a string.

<comment><USER55> You keep your UUID as a backup. The fingerprint system on my phone still has an _option_ to log in with password, the fingerprint is just a convenient, faster alternative. It's the same here, you keep the UUID in a folder with other sensitive documents and when you lose your finger, you fish it out, log in with it, and register another finger.

</comment></comment></comment></comment></comment><comment><USER3> One of the reasons I made my own bad username lookup. [https://github.com/flurdy/bad_usernames](https://github.com/flurdy/bad_usernames) Its a simple json file of usernames to disallow.

It does not address many of the other things higlighted in this post but it is a start, at least for my services.

<comment><USER56> In the en version of your file I don't see any of the common c-level words: ceo, cfo etc...

</comment></comment><comment><USER57> > So if you're enforcing unique email addresses, or using email addresses as a > user identifier, you need to be aware of this and you probably need to strip > all dot characters from the local-part, along with + and any text after it, > before doing your uniqueness check. Currently django-registration doesn't do > this, but I have plans to add it in the 3.x series.

This is needlessly user-hostile. If users wish to use mailbox extensions to have multiple unique accounts, that's their right. They can always get multiple different email accounts, after all.

He doesn't mention the one thing he _ought_ to do, which is to strip email addresses of comments before checking them: (foo)email@example.com, jdoe(bar)@example.com, firstname.lastname@example.com, jdoe@(home)example.com & (a (nested (comment)))jdoe(more)@example.com(all done) are all the same email address.

</comment><comment><USER58> I'm surprised nobody has mentioned PRECIS - the framework for Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols[0].

It defines a (small) set of profiles to validate and compare various types of string, including "Username" (in both case folded and case prepared variants) and "Nickname".

Want to compare two usernames for equality? Run the two strings through the comparison steps for the UsernameCaseMapped[1] profile.

It won't solve all of your problems, but it's a good place to start.

[0] [https://tools.ietf.org/html/rfc8264](https://tools.ietf.org/html/rfc8264)

[1] [https://tools.ietf.org/html/rfc8265#section-3.3](https://tools.ietf.org/html/rfc8265#section-3.3)

</comment><comment><USER59> For PHP, see the Spoofchecker class for similar functionality to the Python class discussed in the article.

[http://php.net/manual/en/class.spoofchecker.php](http://php.net/manual/en/class.spoofchecker.php)

</comment><comment><USER60> > What we really want in terms of identifying users is some combination of:

> System-level identifier, suitable for use as a target of foreign keys in our > database

> Login identifier, suitable for use in performing a credential check

> Public identity, suitable for displaying to other users

Some sites want a fourth one:

Public Identity, suitable for other users to use to refer to each other.

Like on Twitter: "Discussed this with @bob and @jane yesterday, you'll find ..."

Now, you don't need a unique username to be able to meet this requirement - StackOverflow is an example of a site that handles this I think? But having a unique username is a common pattern that many sites use to solve this so it seems worth mentioning.

</comment><comment><USER61> With all the unicode problems I'm surprised so few languages include ICU which has _everything_ unicode-related. Things mentioned in the article:

\- Normalization: [http://userguide.icu- project.org/transforms/normalization](http://userguide.icu- project.org/transforms/normalization)

\- Confusables: [http://icu- project.org/apiref/icu4j/com/ibm/icu/text/SpoofCh...](http://icu- project.org/apiref/icu4j/com/ibm/icu/text/SpoofChecker.html)

(and there are so many more things)

</comment><comment><USER62> > Django's auth system doesn't enforce case-insensitive uniqueness of > usernames

Their routing (for URLs) is also not case-insensitve. The whole framework by default is case sensitive. Honestly, kind of annoying.

<comment><USER63> Honestly never really thought about it much. Wouldn't that lead to accidentally duplicate URLs in the eyes of things like PageRank?

<comment><USER64> No. That's why you embed a canonical url meta tag.

</comment></comment></comment><comment><USER65> It is certainly slower but what i always did even back around 1999-2000 when i first learned web programming, was to simply query the user db to see if any user exists with the requested username before even doing anything else. Also at some point i decided to also store a "broken down" version of the username with symbols removed, Os replaced with zeroes, etc and check against that.

Also i never allowed less than two letters and characters that weren't numbers, latin letters, a space and a few punctuation symbols.

</comment><comment><USER66> I'm currently working on an service and have put a lot of thought into about seven tenths of what is said in this article.

This is a very good read and one I have bookmarked to share with colleagues.

</comment><comment><USER67> For my website, normally I'd be in favor of allowing users to create multiple accounts with variations of email addresses (e.g. firstname.lastname@example.com, firstname.lastname@example.com, firstname.lastname@example.com). I sometimes create multiple accounts like that myself as well.

Coincidentally, today a spammer is creating hundreds of accounts with such variations of the same email (gmail) address -- something that should be stopped right away.

</comment><comment><USER68> > making usernames case-insensitive would be a massive backwards-compatibility > break and nobody's sure whether or how we could actually do it.

Couldn't you store an upcase version of the username that is unique for this? You would still keep both columns so you have the upcase version for uniqueness and the original column for display name. This would also be backward compatible.

<comment><USER68> An upgrade script can find collisions and report them before you upgrade. You'll be required to resolve those before enabling case insensitive user names.

</comment></comment><comment><USER69> > Well, it's easy until we start thinking about case. If you're registered as > john_doe, what happens if I register as JOHN_DOE?

For most applications you are better off with making everything NOT case sensitive.

That's why SunSed language is completely case insensitive -- from variable names, tags (functions) to all string comparations. Users should not worry about case!

<comment><USER70> Doesn't case insensitivity combine poorly with (fairly unrestricted use of) Unicode though?

</comment></comment><comment><USER71> I somehow lost my old HN account and had to register a new one not so long ago. After trying a multitude of user names I surrendered and just copied words from the browser menu bar. This is what I ended up with :)

I always wondered why we don't use emails as (unique) login names generally. I mean they can be shown with wildcards if that is the concern?!

<comment><USER72> I generally agree. But we've had customers who share an email address, whether businesses or personal, who want distinct accounts on our site.

</comment></comment><comment><USER73> Meanwhile I haven't found a good way to know my Skype user name (or id?). My account was migrated to Skype from Outlook I guess and it is something like "live:username" but people can't really find me with that. I take full blame if it turns out that I just don't know how to use Skype...

</comment><comment><USER74> Somewhat of a tangent:

I somehow created a Reddit account without an email address in order to comment on something about 8 years ago.

Eventually, I decided to comment on something else but forgot the password.

I was unable to reset the password without an email address.

So I never commented on Reddit again...I don't want a username that isn't styfle :)

</comment><comment><USER75> Creative usernames and Spotify account hijacking Posted on June 18, 2013 [https://labs.spotify.com/2013/06/18/creative- usernames/](https://labs.spotify.com/2013/06/18/creative-usernames/)

</comment><comment><USER76> I actually loved the concept of bare-number UINs used in ICQ back in the days when ICQ and AOL dominated the messengers market. Those were neutral, easy to share vocally, allowed mutable non-unique screen names and e-mails. That's a pity people don't use them any more.

</comment><comment><USER77> I like how many system have problems with surrogate-pairs and the shy hyphen \xad. I just the other week had a support issue where I had used the very special character of - (dash) in my email...

Also Atlassian Stride doesn't support sending the \xad character at all. It just fails...

\xad makes me \sad

</comment><comment><USER78> [https://en.wikipedia.org/wiki/Zooko%27s_triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle)

</comment><comment><USER79> I don't see what is wrong with treating a email as a username.

I wonder if Auth0 or Cognito resolve any of these issues.

</comment><comment><USER80> This is a great article, thanks.

</comment><comment><USER81> > No, really, uniqueness is harder than you think

No it's very simple. Restrict usernames to ascii. Do unicode where it makes sense.

<comment><USER82> Which is great for everyone using the Latin alphabet, but what about Cyrillic and other non western-world based languages?

<comment><USER65> They can also use ascii, you do not have to use your real name (in fact i'd recommend to _not_ use your real name - it is really concerning how people lost the will for Internet privacy they had in the 90s) as a username. And even if you really really want, for some reason, you can just romanize it.

<comment><USER83> In the 90s and before privacy wasn't really a big thing -- looking at a couple of threads from usenet in the 90s, the majority of people used their real name (or at least I assume their real name).

<comment><USER65> I do not think usenet and newsgroups are a good indicator, by the 90s - especially mid to late 90s - when the floodgates to commercial internet fully opened together with the fast rise of the web, people spent more time in forums, chatrooms, etc than usenet which had more of a 80s "small community" background (where people felt more comfortable using their real names - <USER2> likely they already knew each other IRL considering they were usually from the same or nearby University or organization). When it came to forums, chatrooms, etc everyone used nicknames and even people who used both forums and usenet often used nicknames on the usenet than the other way around. Personally i remember reading back in 2000 or so that it is considered a good practice to use your real name in newsgroups (showing the real name bias it had) so that people "take you seriously" and thinking that it was a bad idea (and not commenting anywhere because i felt very uncomfortable with using my real name online - sadly this eroded over time, although the last few years i am sometimes concerned about it, but i think it is too late now and anyone can find who i am with a single google search).

But regardless, even if people in the 90s weren't more privacy minded (which _really_ _REALLY_ goes against my experience with any community i either was aware of - and i use the net since 1993), this doesn't really change my opinion that people should not use their real names online and instead they should limit themselves to latin, letters and a few symbols that cannot be forged.

</comment></comment></comment></comment></comment><comment><USER84> Why have usernames at all?

Think about it ... people who have you in their addressbook already have nicknames for you.

People who you let see your first and last name can already see that.

About the rest of the people - why do they care?

Only because you want your REPUTATION to be communicated to others in English. Hey it's "someguy22"!!

Yeah that's a pretty limited thing. Could be useful but really, how often do we remember names of others? Only celebrities. And who actually cares about Aziz Ansari and his sex life? Or any of the other dudes who we never met? Or why is one dude "the" Bill Gates and the others with same name are not verified by Twitter? My point is, think about what is the sociological meaning behind usernames.

<comment><USER85> So, how should mail services handle emails accounts?

email@example.com ?

<comment><USER84> Email John

Otherwise how did you come across John's email? SPAM?

<comment><USER85> From his business card?

From him spelling it out to me when I asked him on transit?

I've got 100% of my contacts either by them spelling out their contact to me, or by them entering it into my contacts app, or by me telling them my email, and they sending an email to that.

For all these use cases, 193938939302002 is a useless identifier.

So how should I handle emails, when I want to allow people to register emails?

<comment><USER84> Have you ever considered that verbally spelling something out may be a sign of a problem? If you were taking someone's credit card number, would you have them go one digit at a time over the phone, then read it back to them and so on, or email it so you can copy and paste it? Or how about just have them autofill a form?

Same here. John gave you a card? Cool, maybe it can have a QR code you can scan. Or do you enjoy reading and typing long URLs and having to double check them?

How do you handle emails, you ask? Well, how do people enter their emails? They can visit your site and the emails get autofilled. They can bump phones or use bluetooth or any number of ways that don't require verbally spelling things out.

And anyway, if you haven't allowed someone to email you, why should they be able to spam you?

<comment><USER85> > Have you ever considered that verbally spelling something out may be a sign > of a problem? If you were taking someone's credit card number, would you > have them go one digit at a time over the phone, then read it back to them > and so on, or email it so you can copy and paste it? Or how about just have > them autofill a form?

I don't use CCs, but I (and my parents) have memorized the Kontonummer and Bankleitzahl (and, from that, you can concatenate the IBAN).

> Same here. John gave you a card? Cool, maybe it can have a QR code you can > scan. Or do you enjoy reading and typing long URLs and having to double > check them?

I visit wikipedia by typing [https://en.wikipedia.org/wiki/<topic>](https://en.wikipedia.org/wiki/<topic>).

If a URL is designed well (HN's aren't), this is very easy. Wiktionary and Wikipedia do it well, reddit's is also okay, e.g. [https://redd.it/7wwtqy](https://redd.it/7wwtqy) – most sites, in fact, work nicely like this.

> Cool, maybe it can have a QR code you can scan.

Most don't.

Maybe you remember the time, just a few years ago, when everyone knew their phone number and email, and their friends', by heart? Why force people to change that? Relying on autocomplete and autofill for everything is horrible, and creates massive network lock-in.

<comment><USER84> Why not remembee your friend's IP address by heart? Come on. No one is "forcing" people to forget their friends' numbers. They could have always entered it even now. They CHOSE to stop remembering new ones and just press the thing in their contacts.

Are you one of those people who remembers every password on every site, because you think a password manager will one day screw you?

<comment><USER85> > Why not remembee your friend's IP address by heart?

18.104.22.168 is my server, in case I need to SSH into it.

> Are you one of those people who remembers every password on every site, > because you think a password manager will one day screw you?

I remember two of them, the password to my password manager, and the password to the email that I'd need to reset the password to my password manager.

It's always nice to use automated tools such as a digital contacts app or a password manager. But you shouldn't rely on it.

During the @googlemail.com to @gmail.com switch for German gmail addresses, I told Google not to switch. A few years later, in '16, Google auto-switched me anyway, so I selected "undo". In that moment, Google (probably due to a sync bug) wiped all my stored passwords in Chrome, all my contacts, all my emails, and my entire Calendar. On all connected Android devices as well.

It took me ages to get back to have everything working again after that, because I relied on this technology. I've lost contacts to some friends that I'll never be able to get back, because I only had them in Google contacts, or in Gmail.

So I won't ever support any suggestion that would make me rely even more on these. I'm self-hosting everything now, I've got backups everywhere, and, just in case, I've got the most important info memorized.

<comment><USER84> But this is an example of a remote company controlling your identity. Stored passwords in Chrome shouldn't rely on some server. You should be using an app (preferably open source) that has your own biometrics and passwords as seeds from which to derive keys that can get the master key, which is stored encrypted with those keys on YOUR computers (and maybe some cloud backups). I think that is how Apple's keychain does it.

That's a totally different problem to remembering info of CONTACTS.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Mahalo.com screws all their writers - <AUTHOR> http://www.searchengineoptimisation.org/mahalo-com-screw-all-their-writers/

<comment><USER2> After a particularly frustrating day I reminded myself that at least I don't work at Mahalo.

</comment><comment><USER3> I'll pretend to be surprised here. _GASP_

</comment><comment><USER4> I think the fairest solution and surprisingly the one not used here would be to "Grandfather" the revenue sharing pages in ~ but not allow any more pages to be built on that model.

I am sure that it was thought of and discussed internally and then they went with the "I bet we can take it a little farther and never pay recurring feeds again.." which will save the company a lot of money per month..

</comment><comment><USER5> meanwhile, on twitter...

"@Skitzzo here is the truth... <http://jc.is/cyTdfu>

jason links back to his announcement on mahalo of the new system that now has 50+ comments. the truth is certainly in there.

"The terms of service of Mahalo always had people wondering if something like this could happen. I actually encouraged other people to join Mahalo and defended Mahalo on other writing sites like Absolute Write. I just hope those people will forgive me."

"The entire guide system is based on the premise of writers being so desperate that they'd be willing to sell their time for a few dollars an hour with no rev share to provide long-term quasi-passive income."

</comment><comment><USER6> This company is dooming it self a little more every day. Bravo to them! Time to make a competing product and fill the void they're about to leave.

<comment><USER7> Not necessary, there are already tons of other linkfarms and spammers that can "fill the void"

</comment></comment><comment><USER8> This is all 100% false.

We did change our model from revenue sharing to paying writers, but we did not steal any money or not pay anyone. Also, we publish under Creative Commons, so folks are welcome to do whatever they like with the content provide they shoot us a link back.

This is just false, and in fact probably libelous, stuff.

<comment><USER9> There is no reason to down vote this comment. I know the HN collective dislikes Jason, but there is nothing wrong with it.

</comment></comment><comment><USER10> a word..

HuffingtonPost TechCrunch Gawker Mahalo

what do these have in common?

They all change writers contracts whenever the business favor winds blow in a different direction..ie whether we like it or not Jason is using a standard industry practice.

<comment><AUTHOR> From what I understand, the difference is that JC specifically promised revenue sharing.

<comment><USER8> We did not promise revenue sharing forever. We said we were going to _try_ revenue sharing and we, of course, reserve the right to change our model.

We tried hard to make revenue sharing work, and it only worked for 5% of the audience. So, instead of pretending that freelance writers wanted something they told us they didn't, we pivoted and we're moving to a more About.com-like flatrate with a bonus system.

Now we have a line of folks out the door who want to work for us.

</comment></comment></comment><comment><USER11> I'd never even heard of Mahalo until now.

Why am I supposed to care...?

<comment><USER12> If you dont care, why read/comment?

</comment></comment><comment><USER13> Why do we get articles about how much Mahalo.com sucks every day here at Hacker News? Why don't we just ignore them? I'm serious, I don't care about Mahalo, I barely even know what it is. Why do people keep posting stories about it? Is it just some weird kind of reverse-psychology marketing or something?

<comment><USER14> I think for the most part Mahalo represents the growing problem with Google and aggravating anyone doing SEO work.

To many searches on Google turn up a first page full of optimized pages focusing on advertising rather than the content. Sites like Mahalo make it very difficult for the little guy to optimize and get value from Google. Kinda like trying to get anything on the Digg home page.</comment></comment>


Ask HN: Blog options and experiences? - <AUTHOR>

If you have a blog, what are you using as a platform?  Is it a good or bad fit? Why is it a good or bad fit for you personally or what do you like/dislike about it?  How often do you update?  What do you typically talk about? What prompts you to post to it? Of course, a link to the blog would be nice too.
Any thoughts or discussion on the general topic of blogging is welcome.
Thank you! <comment><USER2> Yeah, I think other forums might be better suited for talking about blogging in general. Here are previous discussions about blogging platforms on HN:

[http://www.google.com/search?q=blogging+platform+site:news.y...](http://www.google.com/search?q=blogging+platform+site:news.ycombinator.com)

For my two cents, I've been using Wordpress a lot, but I'm currently working on switching to custom blog software because of the continuous security problems with Wordpress.

<comment><AUTHOR> Thanks for the link. That might be plenty of information for me for now. I tried playing around with Wordpress and it just didn't click for me. I have done better with Textpattern but I am still wondering if there is something out there that is a better fit or if it is merely a matter of time stress right now.

</comment></comment><comment><USER3> I am now using posterous (even though I'm not blogging heavily). I can have a domain name working with it, multiple blogs from one account, I can set up a favicon, and more. I like their approach better than wordpress.com, and I'd rather focus on other tasks than set up my own wordpress install, adding plugins etc.

<comment><AUTHOR> Is posterous the one where you can email your blog posts? I was thinking about that. It has a lot of appeal. I email myself a lot of stuff, and often cannot find it again later. :-/

<comment><USER3> Yes, you can email to post, and you can also post from the web, and post links to other sites/posts via a bookmarklet javascript thingie.

</comment></comment></comment><comment><USER4> I wonder what no comments from last 7 hours mean, either people here are bored of blogging or answers to your questions are too obvious.

<comment><AUTHOR> I have a long history of completely sucking at starting conversations in online forums. Typically, conversations I try to start either get completely ignored or go down in flames in the worst possible way. Over the years, I have tried to work on this. I go down in flames less, so there has been progress. After I make the observation a few times that I suck at this, I start getting "pity vote" comments -- ie people reply just so there aren't zero comments. I think that may be worse than getting zero comments. I don't remark on my total suckitude to whine. It's just an objective fact. My last submission to HN generated zero comments and the one before that generated pity comments along the lines of "Gee, that's tough. Maybe you should look elsewhere for support". Of 4 submissions here so far, I've managed to successfully generate conversation/meaningful, useful replies one time. That's probably about par for the course for me.

New questions to add to my above list: How would you ask this question/introduce this topic such that it would get replies? What did I do wrong?

:-D

<comment><USER4> I hope its not your objective to generate comments. I am not an expert (under 200 karma) but will advice anyways :-

1) Ask something when you need help and its not something obvious. Googling on your question before posting might help. For example, "What is the search engine you guys use ?" is a bad question.

2) Show something when you have something worth showing. Many people here are creating something and they like seeing what others are creating. If you are proud of something you built, show us.

3) People usually tend to contribute to a discussion when the original author seemed to have done some research himself. Take the "Brag HN" thread for example, I wonder if the author hadn't posted some examples about what kind of "about you" he wants to hear, it would have generated so much discussion.

4) Lastly, follow your instincts and have fun.

<comment><AUTHOR> I wasn't really looking to generate comments when I replied to you. A) I'm very chatty and don't like to just ignore people who are speaking to me. (I've actually had to work on learning when to let it go and that some comments do not really need a reply.) B) I find something very humorous about my poor ability to start good conversations online. I'm infamous for being very talkative and for having a habit of generating big reactions completely unintentionally. Somehow, I haven't mastered the art of "bottling" it, so to speak.

Anyway, I am pleasantly surprised to see a couple of other comments. So it's all good. :-) (And would have been all good even if no one had replied. I figured I was doing it badly when I wrote it. I left it up to see where it would go anyway.)</comment></comment></comment></comment>


Emmanuel Macron presidency prompts French startup boom - <AUTHOR> https://www.independent.co.uk/news/business/news/emmanuel-macron-president-french-startup-boom-france-investment-bank-bpifrance-a7790981.html <comment><USER2> I can see those cuts in corporate tax being good to increase startup competition. Some of the other big remaining issues to see highly successful startups are salaries and lack of tech talent.

We could argue that startup salaries aren't the highest anyways, so if salary isn't too big of an issue if French startup can provide equity easily. It seems that when you exercise stock options in France, you don't need to pay tax on it until the options are actually sold[1][2], so that's a good thing for employee, no need to scratch your head with 83b elections and whatnot.

Regarding the lack of tech talent, there's still a lot to be done. France has incredible engineers, but those engineering schools are not focused enough on Computer Science, instead they excel in "old-school" engineering like Aerospace, Civil, Nuclear, ... . On the other hand, Free universities have Computer Science degrees, but they don't prepare the future graduates as much as the Engineering "Grandes Écoles" would in regard to core engineering knowledge. There are some attempts at schools focused more on Software Engineering, but I feel that they're more similar to longer bootcamps with a focus on projects, I think those who graduate such schools are trained to be good "monkey coders" (pardon the expression) but lack a growth-mindset.

[1] (in French) [https://www.impots.gouv.fr/portail/particulier/questions/jai...](https://www.impots.gouv.fr/portail/particulier/questions/jai- des-stock-options-comment-est-impose-le-gain-levee-doptions)

[2] (in French) [https://www.impots.gouv.fr/portail/particulier/lactionnariat...](https://www.impots.gouv.fr/portail/particulier/lactionnariat- salarie)

<comment><USER3> I agree with you on most parts.

However I come from a private "engineering" school focused on computer sciences (named Supinfo) and there's some others (Epitech / Epita ) that though they don't deliver a engineer diploma (as per the law-regulated definition of engineer) but rather a master diploma (but that you can name "engineer in computer science" or somekind of trick like that and the schools play on that to attract student), actually have to my opinion, provide a decent education.

I learned assembly, C, logical gates and how to build a 1 bits processor.

I then learned HTML, and SQL, and then PHP, and some basic of algorithm (though no data structure courses, I learned only years after being graduated what was a quick-sort/merge-sort)

But I also learned management (how to hold a meeting, how to manage conflict) and project management (Gantt-diagram, Agile and Scrum) and some basis of ITIL

And even more related to the entrepreneur-ship world I had lessons about copyrights law, labor laws, patent laws , as well as finance course (what is an asset active/passive, what is the difference between giving yourself a salary and giving you shares etc.)

However I have to admit 10 years ago, I wanted to be a monkey-coder and thought the management and finance lessons were bullshit for people who were not good enough to code and still needed a job.

So I have to say the school totally prepared me for the "startup world" (and with 30 campuses in France and ~5000 graduated student a year, quite some others were prepared, though they were maybe with the same mindset as me).

<comment><USER4> Imho , schools like those don't do enough "hard" science, like math, to prepare you for the future.

Have you done enough linear algebra to work on image processing, or with neural networks , and understand the various parameters to tweak the libraries ?

Done enough logic (the math branch) to understand the deep nature , or at least feel the taste of the type systems to come ( scala, haskell and now more and more swift kotlin and rust), or use formal program proofs toolings ?

Enough statistics, physics and algebra to get a hint of what's under the hood of Quantum computers, should they come one day ?

<comment><USER5> There are CS Engineering schools in France that have a large part of their teaching in "hard" science.

For example, in my school (ENSIIE). I've studied Operational Research, Graph Theory, Logic, Probability, Statistic, Formal Program Proof, and other subjects I don't remember (oups...).

No Quantum Computing in my school however.

But it might be present in better schools like ENSIMAG or Supelec.

The side effect is that these schools tend to be old school in their purely technical teachings. No learning of <fancy JS framework released a weak ago> or how to configure <enterprise stuff> or <fancy cloud provider>, only basic programming skills in C, Java or CPP, SQL, a little assembly, OCaml and some Unix administration skills. By themselves, these schools will not produce code monkeys.

</comment></comment></comment></comment><comment><USER6> A law passed in 2015 in France [0] that makes it mandatory, starting 1/1/2018, for any business (including "auto entrepreneur", what you have to register as to be a freelancer or such in France) to used "certified" software for accounting.

Is a tool like Excel, which the vast majority of small companies are currently using, certified? Of course not! You have to pay for special software like Ciel Devis (9 euros/month) or Ciel Compta (9 euros/month). The keen observer will notice that they're produced by the same company, whose former CEO had a stint at Intuit - another software company that is very good at manipulating legislation to push its own interests.

If you get audited and are not in conformity, you get a 7500 euro fine and 60 days to correct your situation.

But what if you are serving foreign clients, and use foreign software to produce invoices that fulfill local regulation? Or if you developed in house software to meet your very particular needs? Heh, sucks to be you, go give money to Ciel.

That being said, the law says that if you do your accounting without software, you don't fall under the regulation. So can you just do your accounting in Excel, copy it by hand, and show that when you get inspected? Who knows.

There are many, many cases like this of useless bureaucracy and regulation in France that make it a nightmare for anyone to start and run their own business. My friends who have been "auto entrepreneur" in the past have hated every minute of it, and most of them have moved to other countries. I'm French, likely to start a company in the next 5 years, and would never go back to France to do it.

The government doesn't really want to create an environment where small businesses can flourish - no one has the proper background to really get what factors contribute to that. What they want is to get the big bucks from venture capital flowing into the country so that they can boast about having a French Google or Airbnb or whatever, which is purely a vanity metric and not particularly constructive for the economy.

[0]: [http://www.codial.fr/wp-content/uploads/BOI-TVA- DECLA-30-10-...](http://www.codial.fr/wp-content/uploads/BOI-TVA- DECLA-30-10-30-20160803.pdf)

<comment><USER7> FYI they are planning to remove this requirement, so it should not be a bother much longer

<comment><USER8> I came here to say that.

Source: [http://bfmbusiness.bfmtv.com/france/bercy-renonce-au- logicie...](http://bfmbusiness.bfmtv.com/france/bercy-renonce-au-logiciel- obligatoire-pour-tous-les-auto-entrepreneurs-1187105.html)

</comment></comment></comment><comment><USER9> Paradoxically, while Trump has accomplished very little but make speeches, the damage his presidency has done to our image, and perception of how welcoming America is, will be felt for years.

It's bringing back memories of our dismal global perception around 2006-2008. (Although this wasn't for "America is unwelcoming" reasons)

<comment><USER10> It's going to be devastating over the long term.

Those of us even in Australia are wary now of travelling to the US because of (a) fear they maybe mistakenly detained, (b) having to turn over social media information and (c) visa problems at the arrival gate.

Places like Berlin, Amsterdam etc are looking far more interesting for startups because of the access to the European market and the sensible policies that seem to be enacted e.g. roaming.

<comment><USER11> Exactly. Countries definitely lose out because of these policies.

I intended to visit China in the near future -- but I've booked a trip to Taiwan instead, almost entirely because Taiwan doesn't require me to get a visa.

Likewise, I can't see myself ever living in the US as long as I have access to free movement in Europe.

<comment><USER12> >"I intended to visit China in the near future -- but I've booked a trip to Taiwan instead, almost entirely because Taiwan doesn't require me to get a visa."

You still get a visa to enter Taiwan. It's just a "visa on arrival" as opposed to needing to obtain a visa prior to travel. Visa policies are reciprocal between countries. China and the US both charge citizens from each other's countries to visit for tourist purposes and that must be paid prior to travel. Tourist visa policies and immigrations polices have very little if anything to do with each other.

I think you might be short changing yourself if your only reason for not visiting mainland China is solely because they require a visa. It's less than a hundred bucks, it's basically a tourist tax. You likely won't regret it.

<comment><USER11> >You still get a visa to enter Taiwan. It's just a "visa on arrival" as opposed to needing to obtain a visa prior to travel.

Sure -- 'doesn't require me to get a visa' as in I don't have to make a trip to an embassy or pay a fee.

I'm sure I'll visit China eventually, but for the sort of low-budget travelling I'm doing, an entry visa represents a not-insignificant amount of the total cost. It also makes things less flexible: as I understand, authorities must be notified of exact travel plans before you depart.

<comment><USER12> >" It also makes things less flexible: as I understand, authorities must be notified of exact travel plans before you depart."

This isn't true. You are free to travel wherever and whenever you want in China provided you have a visa. Tibet might require a special approval but nowhere else. The visa is also good for 10 years. Also if you are a Westerner, hotels and taxis are a really good value in China. Lastly there are much better flight options into Beijing than there are into Taipei and so would more than offset the cost of the visa.

</comment></comment></comment></comment></comment></comment><comment><USER13> As an American living and working in France, this sounds like a scenario where France would love to have the results and benefits of a startup boom, but they don't want to take the necessary steps to enable it. Having a bunch of free money or easy visas are actually not what will cause a boom. France is notorious for never-ending paperwork and administration, and it's true. It's like trying to swim in molasses. You can do it. No one is "stopping" you. But eventually you just get too tired and give up, and go to the cafe and enjoy life. But hey, yeah let's make France attractive to startups and catch some of those taxes and world attention. But we don't want to change anything about our culture or regulations, so we can give give out a bunch of money, right? That will get people to flock here, make billion euro companies, and we'll reap the benefits. That's what it seems like to me.

<comment><USER14> > France is notorious for never-ending paperwork and administration

Having visited the Paris startup scene recently, I got the feeling that the bureaucracy is much less taxing these days.

<comment><USER15> No it's the same except we embraced IT and it helped a lot.

</comment></comment></comment><comment><USER16> The endowment of that venture fund (Viva Technology) will be around 10 billion euros. It has just been announced so the news hasn't come out in English media yet.

Here is a reputable source in French: [https://www.lesechos.fr/tech- medias/hightech/030386245787-en...](https://www.lesechos.fr/tech- medias/hightech/030386245787-en-direct-viva-technology-2017-cest- parti-2094678.php)

</comment><comment><USER17> French governments like to create all these grants and loopholes, but it doesn't mask the complexity and the hostility of french bureaucracy toward entrepreneurs. Don't be fooled by these PR stunts. If Macron really wants to change things he needs to start telling the tax office to stop treating every business owner as a de-facto fraudster and criminal.

<comment><USER16> It's the same everywhere. Do you think the IRS is any better than the FISC? Tax administrations are out to get you, regardless of your country.

<comment><USER18> Both of you are right, it's about all western governments.

Still, we have in france a strong anti market thinking that is well reflected in how our government keeps piling laws and regulations. This news is indeed a PR stunt nothing more

</comment></comment></comment><comment><USER7> As a French, I hope this will also bring large "big5-like" compagnies to open engineering offices in my country as well. I'm always a bit disappointed to see them have offices in London or Dublin but not here where we have a lot of engineering talent as well.</comment>


Man Convicted Based on Erroneous Evidence Exonerated After 25 Years - <AUTHOR> http://www.innocenceproject.org/news-events-exonerations/north-carolina-man-convicted-based-on-erroneous-microscopic-hair-evidence-exonerated-after-wrongly-serving-25-years <comment><USER2> "[Out] of 268 cases where agents used microscopic hair analysis to link a defendant to a crime, the agents' testimony was scientifically invalid in 257 or 96% of the cases."

That seems impossibly, mind-bogglingly incompetent.

<comment><USER3> What I would be curious to know is how many of these 268 samples do not have a matching DNA. "Scientifically invalid" is a bit vague. Does that mean that the samples were not a match or does that mean that the method used didn't provide a sufficient degree of confidence of a match?

<comment><USER4> This isn't about DNA analysis, it is about staring through a microscope, comparing hairs. Quote:

 _" At trial, the prosecution relied on the testimony of the three informants as well as the testimony of Elinos Whitlock III, an employee of the Charlotte Mecklenburg Police Department Crime Lab who had been trained by the FBI in how to conduct microscopic hair analysis. He claimed that he could make a "strong identification" that a hair recovered the crime scene was Bridges's hair. He further stated that there was only a 1 in 1000 chance that two Caucasian people (Bridges is white) would have indistinguishable head hair."_

<comment><USER3> I know the analysis isn't about DNA, but DNA gives us a way to validate the analysis. When a defense lawyer uses words like scientifically invalid, it is designed to make it look like the analysis is just bullocks, but most likely it is something much more subtile, like a different confidence interval, or something like that.

</comment></comment></comment></comment><comment><USER5> The state of forensic "science" today is similar to the state of medicine in the 18th century. Bloodletting wasn't an effective treatment, and but it's not like doctors--much less ordinary people--of the time knew any better.

Obviously those participating in hiding evidence should be prosecuted, but it's hard to blame everyone else who is going along with what forensic "scientists" tell them. The legitimate scientific establishment has done little to nothing to expose this field as the domain of charlatans. How are lay people supposed to understand the difference?

<comment><USER6> >How are lay people supposed to understand the difference?

Well first off lay people not to stop placing government agents on a God like pedestal where by everything a "forensic scientist" from the state utters in court is assumed to be truthful and beyond questioning.

This is how we get terrible science and convictions, the public watches a episode of CSI or NCIS where you have infinite zoom and enhance, where you can do facial recognition on a person in a ATM video from 25 miles away, where 2 people can hack all encryption by typing on the same keyboard really fast....

They see this shit, so then when a person from the FBI gets on the stands, says a bunch of big words, and points to the scary man or women at the table saying they did it... the case is over....

<comment><USER7> I mostly agree with you. It is however a serious flaw of the jury system. Forensic science is NOT in the terrible state that the OP makes it out to be.

<comment><USER6> I think the OP is being kind....

I question even the validity of fingerprint matching one of the oldest "Forensic science" fields.

Almost nothing in "Forensic science" follows the actual scientific method. There is far far far far far too many assumptions, "intuitive leaps", and formation of a preconceived narrative round "science"

They make the evidence fit their story, vs allowing the evidence to tell a story.

</comment></comment></comment></comment><comment><USER8> And this goes to show that if you want a fair trial in any country (even relatively evolved western countries), you need to be rich enough to have a decent legal team. When you read some of the cases from the innocence project, the incompetence is mind boggling.

And don't get me started on countries like Japan with 99.7% conviction rate and antiquated laws regarding police arrest.

I think that until you have a significant sum of money that can be used to pay for a legal defense team, you are at risk of prison even if you're innocent (of course in most cases the risk is negligible but if you're part of a minority it might not be)...

<comment><USER6> The cases from the innocence project are bad, but they only see the cases in which the person pleaded innocent and was convicted by a jury...

Most cases end in a Plea, which innocent people with out proper legal representation, and many with proper legal representation take for a whole host of reason.

</comment></comment><comment><USER9> This is one of the big reasons why there shouldn't be a death penalty.

<comment><USER10> I'd think that it matters how many innocent people are executed vs how many lives are saved by deterring potential murderers, and my trouble is I don't know how to get those numbers.

Regarding just the second number - deterrence - here's a claim that the death penalty deters, saving between 3 and 18 lives per execution depending on the study you choose (quite the spread, BTW...):

[http://www.washingtonpost.com/wp- dyn/content/article/2007/06...](http://www.washingtonpost.com/wp- dyn/content/article/2007/06/11/AR2007061100406.html)

...But here's a claim that the death penalty doesn't deter (though they cite, not direct statistical evidence, but the opinion of criminologists and the fact that some places without a death penalty have lower murder rates than places with it; but maybe if I dug deeper I'd find something more direct):

[http://www.deathpenaltyinfo.org/facts-about-deterrence- and-d...](http://www.deathpenaltyinfo.org/facts-about-deterrence-and-death- penalty)

Perhaps someone who've looked into it more deeply can weigh in; all I'm saying is that it matters what the answer is.

(My own intuition would be that people aren't deterred by the death penalty very much, because they count on not getting caught, instead of multiplying the penalty by the probability or some such. But I could be wrong. Also I'm open to the opinion that you shouldn't do some things to people regardless of potential benefits to society, for instance I'm pretty sure torture would deter more than the death penalty because it's a very vivid picture a potential criminal would have in their mind, but it's great that nobody thinks we should go there. I just don't think that the capital punishment is "cruel and unusual" that way.)

<comment><USER11> I think the real reason that the death penalty is not effective as a deterrent is that the people that murder in general don't think things through. Very reactionary. Obviously there are plenty of cold blooded killers out there too but I doubt penalties have a ton of bearing on things. Most people just don't murder other people. I could be completely off base though and would love to see some evidence either way.

<comment><USER12> Also, I believe many people don't consider the punishment just the chance of being caught. If you are going to commit a planned murder then you are likely to plan on getting away with it. If it is spur of the moment then again you won't be thinking about being caught or about the punishment...

</comment></comment></comment></comment><comment><USER13> One gets the ridiculous situation where an innocent person in prison, keeps on maintaining that they are innocent and end up serving far longer sentences than guilty people, convicted of very similar crimes, that don't deny their guilt.

I am not sure if this applied in this case, but it may well have done.

</comment><comment><USER14> Can he sue for compensation? Or, better yet, for putting prosecutors into jail for that?

<comment><USER15> Probably yes on the first.

No on the second, for good reason. There wasn't anything in the article that indicated that the prosecutors did anything wrong. They took the evidence they were given by the police, by informants, and by the crime lab employee and presented it at trial. That the police did not give the prosecutors all the evidence the police had, and that a forensic technique that was widely accepted at the time by the FBI and the state turned out to not be accurate is beyond the scope of the prosecutor's role.

<comment><USER16> I don't know about this case, but about a month ago I heard another wrongfully-convicted person discussing his case, including the fact that in the agreement that freed him, he waived the option to sue. His stated reason was that his alternative was to stay in jail for the process to work its way through, and in jail, 'accidental' death was just too easy. Paranoid? Given his circumstances, l don't think so.

<comment><USER17> If a prosecutor knows someone is innocent and doesnt let them out immediately they should be disbarred.

<comment> nommm-nommm I am pretty sure prosecutors don't have the power to let people out of jail.

</comment></comment></comment></comment></comment><comment><USER18> The very fact that something like innocence project _needs to exist_ is depressing :(

</comment><comment><USER19> One of the best, most eye-opening books on this subject I've read is Just Mercy by Bryan Stevenson.

</comment><comment><USER20> Another reason why it's best just to close the blinds, turn on the computer, and lay low for the rest of your life, using video games and pornography to entertain and escape.

You'll be more likely to duck things like this if no one knows your name.

</comment><comment><USER21> Listen and believe</comment>


MagLev rocks and the planning of the next Ruby shootout - <AUTHOR> http://antoniocangiano.com/2008/05/31/maglev-rocks/ <comment><USER2> "A few people objected that it won't fly, because it's going to be a commercial product. I don't think that's the case. The Rails community adopts Macs, TextMate, and other commercial software without blinking"

The Ruby community should be more serious about FOSS, I never liked those TextMate demos, why not use emacs, netbeans or notepad++ !!! ... well here comes the day when someone is using the TextMate usage and demos to show how the Rubyiest are not serious about FOSS ...

I mean the Ruby community acuses Java of many faults, but now Java moved from closed sourced to being open sourced

Is the Ruby community willing to take Ruby in the opposite direction, are they willing to move backward!

<comment><AUTHOR> You raise a very interesting point. I think that in the Ruby and Rails communities there are plenty of FOSS enthusiasts. Vim, Emacs, RadRails and Netbeans are all very common options. On the operating system side of things, Linux is a very common choice as well, despite the fact that many love Mac OS X.

When I made that remark I was mostly thinking about free as in beer vs. commercial. I don't think that companies and developers who adopt Rails as their tool of choice, would have trouble reaching for their wallet, for a product that significantly enhances their development experience. My remark was a way of saying that the Rails community has a track record of being able to pay for quality, be it an operating system, an editor, or hosting, and therefore won't be adverse to a product that has a price tag.

That said, I think that the communities have a good relationship with the concept of free as in speech. Many believe in the idea and actively participate in open source projects. Every other Ruby implementation is open source, Rails is open source, and almost all the plugins, gems and libraries out there are free software.

Parts of MagLev will be open source too, and this will probably benefit other implementations as well, particularly the conceptually not too distant Rubinius. I think that in the Ruby/Rails community we appreciate FOSS, but we are also pragmatic and accept the fact that some companies may opt for a different business model. The two paradigms can coexist, offering users both FOSS and commercial closed source options.

In this specific case, many Rubyists have been "suffering" due to MRI's slowness, and if the choice comes down to choosing between having a very slow implementation that is free, and a closed source one that's 30 times faster, most companies will accept the closed source compromise, especially when it comes from a company with a reputation for rock solid and mission critical VMs and architecture. And I don't feel that they can be blamed for it.

<comment><USER3> I believe the effect of MagLev will be marginal. Gemstone/S is charging $7K/year and it's not the best license they've got. This isn't going to fly in 2008: I like those guys and I am sure they'll find enough banks and airlines to sell this expensive technology to, but it won't become a popular tool for most websites: you can't compare it to TextMate, it's not a $40 one-time- purchase toy, it's your platform - and by getting into a deal like that you bind yourself to Gemstone possibly forever.

Consider Oracle, it runs circles around MySql in every imaginable category, but hey - how many people are using it?

Closed source development tools in 2008 are archaic. This is why nearly all Borland products died off, this is why XCode and Visual Studio express are free, etc. They will make some money, but at expense of hiding their technology from 99% of programming population.

If you ask me, it looks a bit shitty: they leveraged open sourced work of others (Ruby parsers, Rubinius team's work, etc) only to close their own stuff and have a nice ride charging for it. Capitalism at work.

And besides, DHH is right: MRI is fast enough for most practical purposes and this is what I'll continue using.

<comment><AUTHOR> It's obvious that many of the existing Ruby implementations will continue to be adopted, each with their own strengths and weaknesses. It is also my understanding that they intend to adopt a business model in which they'd have a free version (that will suffice for most people's needs) as well, and they plan to make commercial versions affordable. But we don't know what they're going to charge yet, so it's really just speculation at this point.

They are going to release the Ruby parts as Open Source and it's not set in stone that they're going to keep the VM closed either. However, if they choose not to make it FOSS, it's very unlikely that MagLev will become the single most popular choice. That said, companies pay a lot of money in hardware and hosting fees, so if the speed claims were to be true, many companies would have no qualms about paying for a much faster implementation. It's not going to be everyone's cup of tea, but it's a choice, and choices are usually good.</comment></comment></comment></comment>