lambda

HN does not use standard Markdown. It uses a very simple markup language possibly inspired by Markdown, but with much more limited functionality.

On HN, only two spaces are necessary for code:

  example

And it only supports asterisks for italics, two blank lines for paragraphs, and turning URLs into links; it doesn't support any of the rest of Markdown.

> they have root on your box

Or they have your discarded dead drive from your backup disk that you forgot to enable full disk encryption on. Or they rooted a machine that you were using "ssh -A" on to forward your agent, and have been able to temporarily hijack your SSH agent session. Or there's an information disclosure vulnerability in your web browser that allows them to read files from your hard drive, though without control of what files they can read, and by chance the attacker got lucky and one of the files was .ssh/id_rsa.

While the above description goes way further than I probably would, and yeah, 2FA would be more reasonable, there are good reasons to practice defense in depth, and try to design systems that have a chance of staying secure even if one of your assumptions fails like "private key is compromised".

As long as % formatting still works, it is in many ways more convenient that format. '"Foo: %s" % bar' is a lot shorter to write than '"Foo: {}".format(bar)'. And % formatting is still built into logger, so if you use logger heavily you will probably be used to it.

While the format() mini-language is nicer in a lot of ways, the convenience of % and its ubiquity mean that I generally use it more often. The main time when I reach for format() is when I need more detailed control of column widths and the like, which you can do with things like "{var:{width}}".format(var=var, width=width)

Lots of good stuff in here.

Python 3.5 may actually be what finally convinces me to move to Python 3 (that, and the end of Python 2.7 support coming up in a few years).

The new async stuff, finally fixing some of the problems with byte strings that made them not really an adequate replacement for Python 2.x strings, and os.scandir is a substantial performance improvement over os.listdir plus calls to stat (though os.scandir, at least, is also available in Python 2.7 via PyPI).

Hmm? Where does it say that?

> It's a matter of if you think about it for a bit it makes no sense, it's logically impossible.

Let's take a look at a dictionary definition of culture: "the way of life, especially the general customs and beliefs, of a particular group of people at a particular time" (http://dictionary.cambridge.org/dictionary/british/culture)

Now, note the "particular group of people" part. A person can be a member of more than one group. Some groups are sub-groups of others; some overlap with others.

For example, I am an American, and as such I have been brought up in American culture, with many of the traditions and ideals that that entails; Thanksgiving, the 4th of July, a strong belief in civil liberties, and a love of strawberry rhubarb pie.

American culture is also a subset of Western European culture, with influences from Catholic and Protestant branches of Christianity, so while I am not myself Christian, I celebrate Christmas and Easter and have many Christian influences on my values and life.

However, I am also a member of other cultures. My most recent ancestors to travel to the US were Scottish; and so Scottish culture is also part of my culture, but not most other people in the US. I wear kilts to weddings, and have an uncle and cousin who play bagpipes at weddings and funerals. That's a part of my culture, but that is not a part of overall American culture.

I'm also a software engineer and computer geek, and involved in free software, advocacy for civil liberties online, advocate for strong encryption and privacy, and the like. This is a particular subculture that tends to promote strong protections for individual privacy and liberty, while openness and transparency on behalf of institutions such as corporations and governments. This is not part of mainstream American culture, but it is part of my culture; and this particular subculture spans multiple countries as well, so in many of these ways, I have more cultural values in common with a Brazilian or German who is also involved in these communities than I do with the average American.

There are many other subcultures I could describe myself as a member of. And the same goes for anyone you ask. "Culture" is not one big, monolithic thing with clear boundaries. Because it is a set of customs and beliefs shared with a group, that set can be larger or smaller, and stronger or weaker, depending on how big of a group you choose.

> And if "multiculturalism" whatever that is, is so great, you'd think someone would have come up with support for that notion by now beyond "Ethnic food!"

Food is a pretty fundamental part of any culture. As something that is necessary for sustaining life, it's something that everyone does. In almost every culture I've seen, meals are a large part of fostering community, of strengthening social bonds. You have meals with family, with friends, with coworkers. "Breaking bread" is a term rich with culture connotations of mutual trust, peace, welcoming, because sharing food with someone is so important; and the same holds in many other cultures, one of the most generous and welcoming things you can do is invite someone to your table and share your food with them.

So don't be so quick to dismiss "ethnic food" as an important part of multiculturalism. Food is in many ways the heart of of a culture, and exploring the food culture of another people can be a strong way to share something with them.

However, multiculturalism can extend far beyond that as well.

The musical heritage of America is quite strongly multicultural. Ragtime, blues, jazz, R&B, and hip-hop all have their roots in black culture in the US, but have had enormous influences in white culture as well. Of course a large amount of American musical traditions comes from Western European classical and pop traditions as well, and then there are a variety of folk traditions, such as Celtic, that have been integrated into the mainstream through bluegrass and country music.

But there's a lot more than just that. A large number of cultures have made substantial impact on film in America. Many of our "Western" genre is actually a product of Italy; but that in turn influence Akira Kurosawa in Japan, with Samurai westerns such as Yojimbo. His work has also influenced Western work, where The Magnificent Seven is a western remake of Kurosawa's Seven Samurai, and his The Hidden Fortress is one of the major influences on Star Wars.

Let's see, getting back to day to day life, Jewish culture has also had a fairly large impact; from Yiddish, we get words like "schmuck", "chutzpa" and "klutz". We also get bagels (oops, back to food again),

On the musical front again, some of the best American music like Gershwin's Rhapsody in Blue had roots in Western classical tradition, jazz, and klezmer, traditional Ashkenazi folk music.

I could go on, but man, detailing all of the positive effects of multiculturalism on American society could fill up hundreds of volumes of books, not just a single comment on HN.

> A murder seems to be ipso facto a hate crime.

That is not what is meant by the term "hate crime." Simply redefining a term that has a particular meaning to mean something else does not really add to the discussion.

I'll quote from Wikipedia:

> In both crime and law, hate crime (also known as bias-motivated crime) is a usually violent, prejudice motivated crime that occurs when a perpetrator targets a victim because of his or her perceived membership in a certain social group. Examples of such groups include but are not limited to: ethnicity, gender identity, disability, language, nationality, physical appearance, religion, or sexual orientation.

A "hate crime" is not simply any violent crime. It is a crime in which the attacker was motivated by their perception of the victim's membership of some other group.

There are several things that can motivate a criminal to commit a crime. Poverty, greed, hatred of a particular group, hatred of a particular person, sheer anti-social tendencies, and I'm sure many other motivating factors. Only one of these falls under the term "hate crime" as it is commonly defined; those crimes in which hatred of a particular group of people is a primary motivator.

If you look at the statistics I cited in a previous comment, while it is true that black on white murder happens more often than white on black, white on white murder far surpasses either (and likewise, black on black). No amount of arguing about the black on white vs. white on black levels of crime will make these intraracial crimes go away, and the levels of intraracial crime is a very strong signal that racial animus is not actually the motivation for the majority of crime that occurs.

The reason it is important to look at the motivation behind a crime, and not just the statistics about whether a crime happened, is that the motivations can help tell you the best way to reduce that type of crime in the future.

Hate crimes, in the sense of any crime committed on behalf of membership in some group, can be particularly dangerous because they can lead to either prolonged violence between those two groups, or ethnic cleansing or genocide. These types of crimes, when allowed to escalate, have escalated into some of the greatest atrocities of a last couple of centuries. Breaking the chain of hate-motivated violence by discouraging the use of rhetoric of hate, by changing laws that institutionalize disparities between these groups, and by applying harsher penalties to those crimes committed for these reasons, are some ways to deal with these types of crimes.

Crimes committed due to a hatred of a particular person, however, are fairly different. They are usually based on some aspect of those people's relationship; perhaps an abusive domestic relationship, a cheating spouse, or the like. Here, there isn't some group-based animus, but a dysfunctional personal relationship. Here, the better way to deal with the problems are to provide better outlets for change than violence; provide shelters for people to escape from abusive relationships, allow divorce, as it it preferable to violence or murder.

Crimes that are committed due to poverty, to people having as sense of hopelessness and no further opportunity but to turn to crime, are another kind of problem. Here providing better social services, better education, better access to affordable housing, and the like can all help take that pressure off that can push people over the edge.

In all of these cases, the actual perpetrators of actual crimes do need to be punished; there needs to be deterrence as well. However, on a societal level, there can be many things done to reduce the temptation and pressure to engage in criminal behavior. And even on the individual level, knowing someone's motivation for a crime can be important in rehabilitating them and reintroducing them back to society.

> they didn't immigrate and expect to receive special treatment because they were a member of group X.

No one is asking for "special treatment". They are asking not to get special treatment that consists of being killed by police officers.

And yes, too many white people are killed by police. The police in the US have both a tendency to shoot too many people, and have a tendency to target too many black people, which both add up to shooting disproportionately many black people.

And yeah, the problem is more complex than simple racism by police. There are problems of too many criminals being armed in the US (both black and white), meaning that the police are more prone to shoot in supposed self defense. There are problems of class and poverty, that lead people into violence. There are a lot of complex, interrelated factors that lead to this.

But all of that said, it is undeniable that there are a disproportionate number of law abiding or peaceful, unarmed black men who are killed by police in this country.

> The real race problem is that when it comes to interracial violence, and black on white vs white on black, the facts are black on white racial violence is off the charts compared to white on black racial violence. It's not even close.

Interracial violence is a pretty small fraction of all violence.

Most violence is intraracial. Source: http://www.bjs.gov/content/pub/pdf/htius.pdf (2010, reporting data up to 2005, see page 67); about 42% of homicides are black on black, about 45% are white on white, about 8.8% are black on white, about 3.2% are white on black. If you're white, I'd be a lot more worried about that 45% than the 8.8%.

You know what's likely to be the most likely way to avoid getting killed or shot? Not having family members who have ready access to firearms. You are a lot more likely to be shot by a family member in anger than you are by a stranger of another race.

> Apple serves its Users not Developers, most of whom appreciate there's only 1 icon they need to click on to access the Internet. Only developers think that having multiple browsers to choose from is a value-add - for most users it just adds unnecessary confusion and complexity.

And Apple's restriction has nothing to do with "only 1 icon"; you can ship competing browsers, and in fact Google ships a "Chrome" on iOS.

The restriction is on the rendering engine.

And note that this restriction does not "serve the users". Users who want a faster, or safer, or more compatible browser with some favorite site of theirs that is pushing the envelope on mobile apps via the web are not able to use a better browsers with a better rendering engine.

Look at how many people run Chrome and Firefox on Windows and OS X, when there is an existing browser available. They are not all "developers"; they are users looking for faster rendering, more compatibility with services that are pushing the envelope of web apps, a safer experience, and the like.

For anyone curious, this section is on SAT solving. It's section 7.2.2.2 of TAOCP, and is over 300 pages long. Pretty thorough for a section of backtrack, within a section on generating all possibilities, within a full chapter on combinatorial searching.

Hacker News does not support markdown. It supports just italics with asterisks, blank lines for paragraphs, code blocks by indenting with two spaces (while markdown uses 4), and auto-linking URLs. https://news.ycombinator.com/formatdoc

Hmm, I figure it's more the the optimizer depends on code not exhibiting undefined behavior, like in C. It's not really the case that it's lazily evaluated, just the the causality gets screwy when you try to observe things in an asynchronous system without any kind of coherent memory model.

> only to have a mode where it refuses to silently make 'optimizations' when it does identify UB.

That's not always possible. It's not that it makes the optimization when it identifies UB. It's that it makes an optimization that is valid to make if UB doesn't occur, but if UB were to occur then that optimization could cause all kinds of unexpected problems. But the compiler can't necessarily identify those cases.

Please read the "what every C programmer should know about undefined behavior" series of articles from LLVM; they describe the reason why they can't, in general, provide warnings or errors for these cases in which optimizations rely on lack of undefined behavior:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

The third article describes why the compiler can't, in general, warn about those cases in which it's relying on lack of UB, but you should read the first two as well.

Note that for some of those cases, clang and GCC have recently added undefined behavior sanitizers, invoked via "-fsanitize=undefined", which can help even more than the warnings they can add. However, what they do is add extra instrumentation to the executable, and then either log a warning or crash when you hit undefined behavior. The runtime aspect helps avoid the "getting this right would involve solving the halting problem" aspect of why they can't, in general, provide appropriate warnings, but it does mean that this is generally only appropriate in test builds, and that you will only find the undefined behavior that you can trigger during test, while there may be more hiding that only show up in obscure circumstances.

If you really don't want undefined behavior, it's best to use a language, like Rust, which does not have any undefined behavior (outside of "unsafe" blocks). The problem with any kind of warnings that are tacked on after the design of the language is that you are either going to get lots of false positives, lots of false negatives, or both. With a language that is designed not to allow undefined behavior, you know that if the code compiles, it doesn't invoke UB.

Did you read the article?

Their top two recommendations were invest in a startup, or give to the Gates foundation.

Wow.

I... don't even know what to say about that.

I have known many people to not drink beer. Some of them do so because they just don't like the taste. Some don't because they are former alcoholics. Some are alcohol intolerant; others have trouble with the carbonation. Some don't for their own personal moral or health reasons. Some don't for religious reasons.

I have never had one of those people "impose or restrict" my rights or "make me feel very uncomfortable" in the workplace or any other venue I shared with them.

This exact attitude, assuming that someone who doesn't drink beer will be a detriment in the workplace, is the kind of thing this article is refuting; that if you use enough of these "culture fit" markers, then you will simply wind up picking a team with very little real diversity, which could cause real problems in the long run.

I think that this is a good question, but poorly phrased; you assume in the phrasing that it's possible for the existence of one language to "kill" another.

I was somewhat disappointed when Apple shipped Swift; I feel like Rust has considerably more potential as a general purpose language, and it would be nice to have less dilution of effort in fairly similar space.

However, I don't think that the existence of Swift is an existential threat to Rust.

> Swift will be able to do everything Rust can do and is also positioned as a systems programming language

Swift is an interesting language, with some good ideas, and in many ways easier to use for application programming than Rust; but I still, on balance, think that Rust is more interesting and versatile.

Swift is not really a systems programming language. You can't write a kernel in Swift, nor target embedded platforms, nor write a library that could be called from other languages like Ruby or Python (at least, without bringing in the whole runtime as well). It's closer to the space of Go, a more systems-y application language.

Furthermore, open source Swift does not mean you will be able to use the whole ecosystem on other platforms. I highly doubt that Apple will port Cocoa/Cocoa Touch to other platforms; so Swift on other platforms will likely only be viable for back-end code.

Objective-C has been open source for years, and until the introduction of Swift was the dominant language of choice for writing code on one of the most popular smartphone platforms, but Apple canned cross-platform OpenStep when they bought NeXT, and Objective-C has never made serious inroads on other platforms (I know exactly one person who writes production, server-side code in Objective-C on Linux).

So, I could see Swift becoming popular for writing backends for iPhone applications, but I can't imagine that it will make serious inroads in other spaces, unless Apple makes a dramatic change in strategy and starts shipping their UI libraries on other platforms as well.

Moldbug did not simply "mention the existence of slavery."

He explicitly celebrated it. He talked about it being a natural order. He argued that "the innate character and intelligence of some is more suited to mastery than slavery."

This is pure, racist drivel. This is an evil way of thinking. There is a reason that racism, genocide, slavery are so abhorred in the modern world; they are poisonous ideas that have caused some of the largest atrocities history has known.

He also explicitly argues for a dictatorship beholden only to landowners: http://unqualified-reservations.blogspot.co.uk/2009/07/seces.... He admits that his influences and design are similar to those of the Nazism and Stalinism.

He is a fascist, arguing for a violent dictatorship, and arguing that slavery is a natural order. These are not mere rhetorical devices; this is the core of his argument. His entire argument is steeped in violence.

It's supposed to read as a portmanteau of "ASCII" and "cinema", but yeah, I can see the misreading.

> So I guess, there's still a lot of work to be done.

And I think this is the most interesting part.

One of the most depressing things about all of the "this image recognition algorithm performs better than humans on this task" is the idea that we've pretty much solved the problem, and it's just a matter of some more optimization and tweaking to handle a few edge cases.

This kind of problem, where the dominant solution simply gets it so wrong, and the problem cases are uncommon enough that any statistical solution is generally going to treat them as noise, reveals that in fact that there is likely plenty of room for entirely new, novel ways of approaching the problem to handle these kinds of cases better.

It's actually more exciting that there's so much more to be done, than to say "well, it's basically a solved problem, we just need to do some tweaking and optimization."

The main places to look are https://internals.rust-lang.org/, https://github.com/rust-lang/rfcs, https://github.com/rust-lang/rust (for actual implementation), and the Rust IRC channels such as #rust-internals on irc.mozilla.org.

IRC is used for quick casual conversation. The internals forum is used for discussion, "pre-RFC", and the like. The rfcs repo is use for actually discussing formal RFCs, as well as wishlist language and library bugs. The rust repo is for the actual implementation of rustc and the standard library itself.

Unicode is not a clusterfuck. Overall, it is a very comprehensive, well thought out standard, that has improved the situation for interoperable internationalization dramatically over the hundreds of separate encodings that preceded it.

The clusterfuck is mostly in the essential complexity of the problem; the world's languages and writing systems are quite complex and varied, and all of the writing systems and punctuation conventions were designed for reading, hand-writing and hand-typesetting by people who understood the language in question, not automatic typesetting and processing by a general purpose computer.

The complexity of the problem was increased by the necessity of providing migration paths from legacy encodings to Unicode and back again; without such a guarantee, bootstrapping the world into using Unicode would have been a much more difficult proposition, but that constraint also means that many oddities of legacy encodings have had to be preserved in Unicode in order to be able to preserve that round-trip mapping.

Unicode, and sister projects like the Common Locale Data Repository, are doing an admirable job of navigating and standardizing this complex problem.

There are definitely aspects of the Unicode process where they have gotten it wrong; UCS-2/UTF-16 is one of them, in hindsight it is apparent that UTF-8 is superior in pretty much every way. Having a variable width encoding but which most of the world's text fits in a fixed width, and which has endianness issues that necessitate inclusion of an non-textual byte order marker to disambiguate, has caused a number of problems and incompatibilities. There may be a few other points of legitimate criticism, like some aspects of Han unification.

But on the whole, outside of a few problems like those, the "clusterfuck" is caused not by Unicode, but simply by the essential complexity of the problem involved. Language and text are simply difficult things to model in a computer.

I think there are a few things wrong with this argument. I'm unconvinced by the argument that this should actually be considered a modifier letter.

  Consider any English word with an apostrophe, e.g. 
  “don’t”. The word “don’t” is a single word. It is not the 
  word “don” juxtaposed against the word “t”. The 
  apostrophe is part of the word, which, in Unicode-speak, 
  means it’s a modifier letter, not a punctuation mark, 
  regardless of what colloquial English calls it.

The definition of a modifier letter is (http://www.unicode.org/versions/Unicode7.0.0/ch07.pdf#G15832):

  Modifier letters, in the sense used in the Unicode 
  Standard, are letters or symbols that are typically 
  written adjacent to other letters and which modify their 
  usage in some way. They are not formally combining marks 
  (gc=Mn or gc=Mc) and do not graphically combine with the 
  base letter that they modify. They are base characters in 
  their own right. The sense in which they modify other 
  letters is more a matter of their semantics in usage; they 
  often tend to function as if they were diacritics, in 
  dicating a change in pronunciation of a letter, or 
  otherwise distinguishing a letter’s use. Typically this 
  diacritic modification applies to the character preceding 
  the modifier letter, but modifier letters may sometimes 
  modify a following character. Occasionally a modifier 
  letter may simply stand alone representing its own sound.

Punctuation, on the other hand, is (http://www.unicode.org/faq/punctuation_symbols.html):

  Punctuation marks are standardized marks or signs used to 
  clarify the meaning and separate structural units of text.

Based on these definitions, the apostrophe seen in contractions and possessives is definitely punctuation, not a modifier letter. Modifier letters indicate some effect on sound or pronunciation, either modifying an adjacent letter or having a sound on their own. U+02BC (MODIFIER LETTER APOSTROPHE) is such an example, being used to indicate a glottal stop.

Apostrophes used in contractions and possessives, however, have no effect on pronunciation; instead, just as in the definition of punctuation, they are used to "clarify the meaning and separate structural units of text."

  But we shouldn’t be perpetuating this problem. When a 
  programmer is writing a regex that can match text in 
  Chinese, Arabic, or any other human language supported by 
  Unicode, they shouldn’t have to add an exception for 
  English.

Thinking that it's possible to do text processing in a language or writing system neutral way is a fallacy. Unicode simply provides an encoding that allows all of these writing systems in a single document, plus a number of algorithms that are designed to be fairly reasonable across the entire encoding, but which cannot be correct for all languages and writing systems without specific tailoring.

Many writing systems do not use spaces between words. Any form of word segmentation for these writing systems will necessarily be language specific, generally involving dictionaries. Using a regex like \w+ on Chinese or Thai text is fairly meaningless, as it will generally match an entire sentence at a time, rather than actually matching a single word.

  For godsake, apostrophes are not closing quotation marks!

No, they are not. However, they also aren't modifier letters. If you wanted to provide a distinction for the purposes mentioned here, you would probably need to add a new, distinct punctuation character "curly apostrophe" or something of the sort (since the ASCII range apostrophe can't be reused due to its overloaded meaning). However, even if you did that, you would still need to deal with all of the legacy documents which use ASCII apostrophe and closing quotation marks; you wouldn't actually be able to simplify the implementation by making the assumptions that a closing quotation mark was always actually closing a quotation.

Now having three different characters that looked identical (the modifier letter apostrophe, the closing quotation mark, and the punctuation apostrophe) would additionally add to confusion.

Even if you didn't introduce a new character, and instead used the modifier letter apostrophe as a punctuation apostrophe, you would still have all of the problems with legacy documents; it would take years for this change to make it's way through all of the various word processing programs and text editors, even after it had there would be existing documents using the old conventions, etc.

In short, text processing is hard, because text conventions were designed for human readers who know the language, not computers trying to process text in a language-independent way, and they were designed either through handwriting or manual typesetting, not keyboard entry. You are never going to achieve a perfect text processing model that can handle all of the world's languages simply by using particular global Unicode properties of characters and applying a simple algorithm or categorization on them. A lot of text processing will need to be contextual, language (and locale) specific, and involve dictionaries.

I don't think that switching from the punctuation closing quote character to the modifier letter apostrophe for the punctuation apostrophe is likely to help much; and the confusion caused by nearly 20 years of documents that follow the existing conventions and so having to support both conventions is likely to make the situation much worse, not better.

I'm pretty sure that's intentional. The point of the license is for releasing crappy code that is still necessary for the research in question and validating the findings.

He never says any of these problems are fundamentally insurmountable. Just that you need to take any meta-data with a large grain of salt. Which, well, is exactly what Google does. It uses certain metadata, but doesn't trust it absolutely.

Also, he mentions Google in this essay; this was written after the emergence of Google, when Google was trouncing all of these other services that tried to use metadata embedded in webpages or tried to classify all websites into some big hierarchy.

CSS/HTML are not meaningfully semantic; they encode presentational attributes of documents and applications. Syntax validation is not semantic; it's syntactic. DOM is not either; it's an API for manipulating HTML, generally used for presentational purposes. RDF is designed for semantics, but no one of interest uses it. HTTP is a transport protocol; it's a way to take an opaque URL plus some persistent state and get a blob of text or binary data back, along with just the barest of semantics about which requests are intended to make persistent changes server side. MathML is this weird semantic/presentational hybrid, of which I have only ever seen the presentational side used; I am aware of no real-world systems that produce or consume the semantic subset of MathML. PNG is an image encoding format.

So out of all of that, RDF and MathML are the only things that even attempt to define any kind of semantic encoding, and as far as I can tell they completely fail at that in the real world. For the vast majority of real world services, if you want to extract semantic data out of them you use JSON.

I have found NetworkManager to be no more difficult to use than setting up networking in Windows. For me, for simple cases, it tends to just work; for more complicated cases with multiple interfaces, it takes some fiddling but can be made to work as well; and pretty similar to the amount of fiddling on Windows. I've found OS X to require less fiddling for some of the simpler and moderately complex cases, but also have problems of its own when you get to some more complicated cases.

> I have to admit I'm surprised to find that anyone is still trying to make desktop Linux work for normal people, i.e. non-programmers who aren't free-software fanatics.

As far as day to day use goes, modern desktop Linux environments are just as usable by end users as Windows.

The main impediments to adoption tend to be:

1. Software that they need that only runs on Windows or OS X

2. Syncing to devices like iPods or iPhones

3. Lack of easily accessible support infrastructure for when things go wrong, major version upgrades, etc. You can generally take a Windows machine to Best Buy or some other local computer store, or a Mac to an Apple Store, and they can deal with it, but there's little accessible support for the complicated cases on Linux unless you have a friend or relative who's into Linux.

4. Lack of support by IT departments.

So if you have a situation like in the original story, where someone is willing to provide that support voluntarily, and you just need a home computer with internet access and no specialized software, a modern Linux desktop will do just fine.

> My guess is that GNOME 3 and Unity require roughly as much CPU power and RAM as Windows 7.

Lightweight desktops like LXDE and XFCE can run fine on older hardware, and are much lighter weight than Windows 7. If you read the article, you would see that it was running LXDE, not Gnome or Unity.

In most of these discussions, there is no one "true" answer. There are engineering tradeoffs. There are design decisions, about what will be most easy for people to work with, least likely for someone to screw up and break the whole system. There is inertia of existing systems, that would cost a lot of money to rewrite, and tradeoffs of what will be the lowest cost solution.

There is a simple explanation in the introduction:

  In short, the theorem states that no rank-order voting system can be 
  designed that always satisfies these three "fairness" criteria:

    1. If every voter prefers alternative X over alternative Y, then the 
      group prefers X over Y.
    2. If every voter's preference between X and Y remains unchanged, then 
      the group's preference between X and Y will also remain unchanged 
      (even if voters' preferences between other pairs like X and Z, Y and 
      Z, or Z and W change).
    3. There is no "dictator": no single voter possesses the power to 
      always determine the group's preference.

A "rank-order voting system" is one in which all voters order the possible choices, from most preferred to least preferred. The idea is that based on everyone's votes, and some set of rules on how to evaluate those votes, you can come up with a decision for the entire group that respects those preferences, in some way that is considered fair.

All of these requirements listed above seem like fairly simple requirements for a voting system to have; if there's unanimous agreement about the ordering of two of the choices, then the voting system should order them that way. If a voter changes preferences about one choice C (maybe changing between them being ranked above or below D, or above or below one of A or B), without changing their ordering between choices A and B, that shouldn't affect the outcome of the A/B ordering that the voting system gives you. And finally, there is not dictator; no single voter is able to always determine the group ordering unilaterally.

The first requirement seems pretty obvious; if everyone is unanimous that we should pick one option over another, then the group should pick that option.

The second is a little trickier; but it basically states that there shouldn't be able to be "spoiler"; someone whose ordering in people's preferences affects the ordering of to other choices. Think about, say, the 2000 election, with Bush and Gore and a couple of third party candidates; now, that used just single choices per voter rather than a ranking, but imagine it used a ranking. So let's say Bush and Gore are fairly close, but 51% of voters prefer Gore over Bush. Their preferences for other candidates should not affect the fact that Gore wins over Bush. If I rank candidates Nader > Gore > Bush, that should not change the Gore/Bush result compared to if I ranked the candidates Gore > Bush > Nader.

And the last is pretty trivially desirable; generally a democracy wants to democratically make a choice, in which everyone's vote has the same weight in affecting the final outcome.

The fact that these conditions are impossible to achieve together is fairly profound, and means that almost any voting system will have serious flaws under certain circumstances.

But you don't need constant time access to code points for that, you just need constant time access to code units, which UTF-8 can do just fine. That's why I had asked that question; every reason I have ever seen given for wanting constant time access by code point can either be done simply by indexing by code unit, or is misguided as it assumes that a single code point is an interesting unit of processing on its own.

A code point (http://unicode.org/glossary/#code_point) is a value in the range from 0x0 to 0x10FFFF. In a fixed-width type, you need at least 21 bits to represent that, which is why 32 bits is the most common form for representing any arbitrary code point; but if you don't mind the alignment issues, you could even pack it to 24 bits or even 21 bits if you don't mind a little bit twiddling to extract it.

A code unit (http://unicode.org/glossary/#code_unit) is the smallest unit of encoding in the encoding that you are using. In UTF-8, that's a single byte; in UTF-16, it's two bytes, in UTF-32, four bytes.

In order to be able to have constant time offsets, you only need to store a code unit index, not a code point index.

The thing is, individual code points are not really all that interesting from the perspective of text processing. Almost all meaningful processing of them could potentially involve multiple code points, splitting on arbitrary code point boundaries without regards to higher level semantics can cause all kinds of problems, etc. So a desire to have constant time indexing by code points is misguided.

All offsets can be stored by code unit (byte in UTF-8). That gives you all of the constant time access to given points of interest in a string that constant time indexing by code point would have given you.

Displaying characters on the screen, and giving the ability to select text, is indeed quite a difficult and complex question in the face of full support of the world's written languages.

Glyphs vary in width. There are combining characters. There are ligatures (and in some languages, ligatures are necessary for the text to be readable, not just stylistic). There is contextual reordering of characters. There's bi-directional text, which can switch direction mid-sentence when quoting some Roman text in Hebrew or vice versa. There's vertical text. There are a number of fonts, font weights, font styles, font sizes, font features like alternative characters, language dependent selection of glyphs, and so on, plus fallback if the user doesn't have the designated fonts or fonts that cover the given Unicode range installed. There's line breaking, which can't always operate on spaces because not all languages include spaces between words. There's justification of text, distributing the spacing between characters to make a block of text even on both sides.

All of this complexity exists regardless of the encoding that you use. Simply picking a fixed width encoding will not do anything about the vast majority of the complexity; and the fixed width encoding will cause problems of its own (size bloat of strings in memory), as well as leading people astray in thinking that maybe they can get away with making some of the same assumptions that apply to ASCII on a fixed-width terminal (and even there, assuming that 1 character equals 1 unit of width fails in the case of tabs), when in fact they can't and most text handling beyond simply appending strings together is best handled by dedicated libraries that have had hundreds of developer-years of effort put into solving all of these problems.