Why mobile video sucks - <AUTHOR> http://blog.framebase.io/post/43655960048/why-mobile-video-sucks

<comment><USER2> IMHO, mobile video use is about to grow. This due to the amount of web apps coming out that focus on it. Ten years ago no one would even dream of a service like Instagram being a success. Who would want to take pictures with their cell phones and post them on a site? Turns out, millions of people. I think that video has that same potential. Just think about the possibilities:

\- You can record the moment your {girl : boy}friend says yes to your marriage proposal and post it online ASAP.

\- You can record that really funny joke your friend does and share it.

\- You can do product placements and all kinds of marketing with it and people will never be any wiser.

This argument that people don't want to appear on video is wrong. People crave the attention video gives them. A quick visit to youtube is evidence enough.

I do think that the time limit for each video has to be around 10-15 seconds and not 6 seconds like Vine does. Its a bit too short.

<comment><USER3> _> Ten years ago no one would even dream of a service like Instagram being a success. Who would want to take pictures with their cell phones and post them on a site?_

Are you kidding? People were taking pictures with camera phones like crazy soon after they were widespread. Digital cameras and camera phones changed society. The only reason why Instagram took so long to appear is because the likes of Verizon and AT&T suck at software and aren't nearly as motivated by what people want as they like to think.

<comment><USER2> You obviously don't get my point. Which is that we are about to reach the point where video is going to be used for short communication like images, tweets, and status updates. That has not been properly done before due to network speed, phone hardware, and software.

<comment><USER3> _> You obviously don't get my point._

No, I get that point. The "who could imagine" part about Instagram/digital snapshots is what I objected to. All it takes is to step outside of ourselves and look at larger trends. Easier said than done, I know, but the signs were all there for photos _from the time of feature-phone cameras_.

I'm not so sure the signs are there for video. Calls can be spur of the moment casual. So can sending a photo. Video calls are a little too much like a get together or a date.

When video calls get to the point of casualness where lots of people are drunk dialing so they can show an out of town buddy something stupid at a bar, then there will be something there.

</comment></comment></comment></comment><comment><USER4> I was on a (p)review team for a short-film festival for a number of years. I learned a lot about what makes a video appealing to me, roughly in order:

1) Sound! Bad sound can ruin a video even if everything else is perfect.

2) Editing is key, we rejected a lot of 10 minute films that could have been turned into great 2 or 3 minute pieces.

3) A good story trumps a series of pretty pictures

All of these are big problems for quickie mobile videos so I think tools for sound and editing could really help.

<comment><USER5> What's your take on stories told in photos -- eg this <http://backspac.es/r/V0bCokJWnt/how-it-happens>

That was also made on a mobile phone

<comment><USER4> I think that's a great format for small screens. I could also imagine it as a storyboard for a video, or for mixed sequences of still images, audio, text and videos.

</comment></comment></comment><comment><USER3> I think things like UStream combined with the likes of Google Glass is the future. Live stream voyuerism doesn't require editing. If drunk video calls could be made with the ease of drunk dialing or texting. We'll have passed the threshold.

</comment><comment><USER6> I agree with all that, but I still shoot a lot of video--mostly of concerts. In fact, I just shot about 20 minutes of a Kate Nash concert last night in Boston with my iPhone. (She was great, by the way. She's gone punk!)

<comment><USER7> As a fellow concert goer, I generally hate that people do this. I think it's distracting to everyone. However, I'll admit I think someone should record the best moments. I think it's better to enjoy the music and show rather that spend the effort to try and properly catch it. Not only that, but even at events which have been professionally or at least well recorded, I rarely go back to watch the video later. How much video you shoot do you actually go back and watch?

<comment><USER6> What I find distracting is the 7 foot tall guy who always decides to stand right in front of me. People recording bits with their cell phones don't bother me. Generally, I don't hold the camera over my head, so that if your view is not blocked by the back of my head, it won't be blocked by my iPhone.

As to how often I go back and watch the clips, that would depend on how much I like the band. If I had been able to record Kate Bush perform in 1979, there was a time in my life when I'd probably watch it every day! I recorded two whole Marina & the Diamonds concerts and a bunch of clips, and I watch them from time to time. Also, 19,131 people on YouTube have watched one of the M&tD concerts my friend and I recorded. As for Kate Nash, I'll definitely watch the clips again, and I have some friends who will want to see them.

I also occasionally go back and watch these clips I took of Sade:

       http://www.youtube.com/watch?v=OqdS-4J1_KY

333 other people have watched it.

</comment></comment></comment><comment><USER8> I think he's looking at it from the wrong perspective - the winner of mobile video will be the short-form "moment capture" apps, not the long-form edited video.

It needs to be fast and easy.

</comment><comment><USER9> YouTube? UStream?

Video production isn't mainstream? Come on now.</comment>


Qualcomm preparing to give up its push to develop ARM processors for servers - <AUTHOR> https://www.bloomberg.com/news/articles/2018-05-07/qualcomm-is-said-to-plan-exit-from-server-chips-amid-cost-cuts <comment><AUTHOR> Perhaps Qualcomm is pulling out due to a revitalized AMD, who is promising massively paralell x86 processors at reasonable prices and generally abysmal preformance levels of ARM chips both per clock, and max clock speeds compared to x86?</comment>


Egypt Sentences Tourist to 8 Years Jail for Complaining about Vacation Online - <AUTHOR> https://www.eff.org/deeplinks/2018/07/lebanese-tourist-sentenced-eight-years-egyptian-prison-viral-video <comment><USER2> I traveled to Egypt during a short lull in the revolution (early 2011) and couldn't get over the state of tourism then - I can't imagine how desperate it's gotten nowadays.

From the moment we left our hotel room we were incessantly harassed by vendors hawking everything from taxis to fake artifacts. Sometimes there would be a dozen of them surrounding my family stopping us from moving.

I have a very thick skin having traveled widely, but it got to a point where we couldn't wait to get out of Egypt!

</comment><comment><USER3> That doesn't sound as a good idea for a country with lots of tourists like Egypt to start putting them in jail.

Not a good signal for others.

<comment><USER4> Definitely not worth it from the tourism angle

</comment></comment><comment><USER5> Good lesson in the value of being familiar with the local law when you visit places that don't protect basic rights you may take for granted.

<comment><USER6> I was going to say something like that, but it seemed too cruel.

<comment><USER5> I'm not saying she deserved it. Sorry if it sounded dismissive.

<comment><USER6> Sorry to sound critical of you. As I said, I almost posted it.

There is a lesson here about how essentially innocent people get caught up by draconian and unappealable corporate policies. In this case, about video licensing. And, seriously, there's a whole VPN industry focused on evading geo-restrictive content availability. But being naive, she didn't think enough like a criminal. And used a valuable Microsoft account.

And seriously, If she had thought it through, she could have used a different VPN, and a different persona with a throwaway Microsoft account. And her primary account would be fine now.

I do try to reach naive people like her. To explain the concept of compartmentalization, and the basics of using virtual machines (VMs) with VPNs and/or Tor. To create unassociated personas. Show them how to play safe.

But it's hard. I don't speak Turkish. And I can not move freely in meatspece as Mirimir.

</comment></comment></comment></comment><comment><AUTHOR> The article mentions that she was partially a victim of the social media algorithms that helped her post go viral. But even if the social media engagement algo's weren't so tuned for spreading outrage (since that is so successful at increasing engagement), I can't help but worry that governments like this may start preemptively searching for these types of content violations regardless of if the message becomes widespread.

<comment> matt-attack Surely the point of posting it was to spread the word. It going viral seems consistent with her original intent.

</comment></comment><comment><USER7> Lesson learned: Never ever go to Egypt.

<comment><USER8> That's logical and mature. Surely America or other states other than Egypt would never detain people for potentially libelous speech, no matter how bad the optics are.

\- A Person Visiting Egypt Routinely and Finds All of Our Nations an Embarrassment

<comment><USER9> For all practical purposes defamation is not a crime in the US[1]. Some states still have the laws on the books, but they are not enforced anymore.

The rest of the world however is still a mixed bag [2].

[1] [https://cpj.org/reports/2016/03/north- america.php](https://cpj.org/reports/2016/03/north-america.php) [2] [https://en.wikipedia.org/wiki/Defamation](https://en.wikipedia.org/wiki/Defamation)

</comment></comment></comment><comment><USER4> Scratches Egypt from the list

</comment><comment><USER10> Not sure what to say about this. Proud to be an American I guess. Free speech is a glorious thing.

<comment><AUTHOR> You may want to keep an eye on things like this then:

[https://www.usatoday.com/story/news/politics/2018/07/18/doct...](https://www.usatoday.com/story/news/politics/2018/07/18/doctors- hospitals-sue-patients-posting-negative-online-comments/763981002/)

Hopefully this nonsense gets stopped in the courts.

<comment><USER11> Different that it is a private person suing you vs the state throwing you in jail imo. Also having a family member who's been on the side of one of those sites where people can post anonymous reviews (BadBizReport I think) they are usually bunk. Promotes salacious allegations as restitution is hard to come by and expensive.

[https://gizmodo.com/when-a-stranger-decides-to-destroy- your-...](https://gizmodo.com/when-a-stranger-decides-to-destroy-your- life-1827546385)

Also the guy in the article definitely seemed to be harassing the doctor with those emails about people getting arrested.

</comment></comment></comment><comment><USER6> So would Lebanon have extradited her, if she had waited to post it?</comment>


Two Must-Have Tools for a More Readable Web - <AUTHOR> http://www.hanselman.com/blog/TwoMustHaveToolsForAMoreReadableWeb.aspx

<comment><USER2> Modern Web design seems to focus too much on pretty visual designs. I think that designers should pay more attention to structure, like the original Gopher menus.

One of the major reasons Apple's App Store has taken off is that most Web designs are pretty, but optimized for big screens. They're awkward to look it on small devices like the iPhone. Simple design degrades gracefully.</comment>


Things in SQL Server which don't work as expected - <AUTHOR> http://tech.pro/tutorial/1419/10-things-in-sql-server-which-don-t-work-as-expected

<comment><USER2> I've worked with SQL Server for 20 years now, and you'd be amazed at how often the issues listed here actually come up. My Damascus moment was using Postgres for the first time. I kept discovering that it "just did the right thing" in a way that SQL Server never seems to.

<comment><USER3> SQL server by default creates tablespaces with non ANSI SQL NULL behaviour. Exlicitly specifying ANSI SQL compatibility when creating tablespace makes it "to do the right thing"

Edit: was doing it many years ago so forgot the details (or they changed :), so just checked - it is "alter database" that can switch various "ansi_null" default settings into ON from default OFF

<comment><USER4> The default in upcoming versions of SQL Server will use the ANSI NULL behavior.

[http://msdn.microsoft.com/en- us/library/ms188048.aspx](http://msdn.microsoft.com/en- us/library/ms188048.aspx)

</comment></comment></comment><comment><USER5> > Oracle and PostgreSQL sort NULL values last by default. Also, those two > RDBMS support an extension to ORDER BY clause: each expression accepts > possible modifiers NULLS FIRST and NULLS LAST

The wording may make one think NULLS FIRST and NULLS LAST a is proprietary feature of Oracle and Postgres. It's actually an optional feature of the SQL standard (T611 "Elementary OLAP operations")

</comment><comment><USER6> If your expectations are learned in one RDBMS and you move to another, you will always find things that "don't work as expected."

This is why it's a bad idea to assume you can treat RDBMSs as interchangeable black boxes, unless you confine yourself to the most basic subset of standard SQL.

<comment><USER7> That would be a good defence if he were talking about leaving out optional parts.

He is giving examples of violating the standard.

<comment><USER8> So, just out of curiosity, which other RDBMS doesn't violate the standard?

<comment><USER7> I never said that.

<comment><USER8> I honestly think it's a very informative article, clearly SQL Server doesn't adhere to the standard (whichever one you choose) but I'm not aware of any RDBMS that does so I was curious as to whether there was one.

There's lots of amazing databases around, each has their own quirks and as the gp says it's generally difficult to drop in replacements due to those quirks. There's a few listed in the article for SQL Server I'm sure anyone could easily find where others deviate from the spec too. But anyway getting back to what you said:

> He is giving examples of violating the standard

That's absolutely true and it's something every other RDBMS does.

<comment><USER5> > That's absolutely true and it's something every other RDBMS does.

To various degrees, and there's violating the standard (by adding non-standard construct) and violating the standard (by failing to implement a feature entirely, or implementing it with different syntax or semantics).

[http://troels.arvin.dk/db/rdbms/](http://troels.arvin.dk/db/rdbms/) is generally my go-to page for that stuff as it lists standard solutions (with reference and mention of the features used being optional if applicable) and alternative db-specific solutions (exclusive or inclusive of the database accepting the standard solution). Sadly it is not really up to date, and obviously does not go through the whole standard.

</comment></comment></comment></comment></comment></comment><comment><USER9> Lots of good tidbits and examples in there - I really enjoyed reading that. There are several not-quite-inaccuracies-but-not-really-how-you-would-think moments in it but, overall, it's very well written. The pictures were annoying after a while haha.

Just to clarify, this isn't "specific to SQL Server" \- SQL Server was originally a straight-up "licensed by Microsoft" version of Sybase SQL Server and thus it's early code base (things that defined the Transact-SQL language) has almost all to do with Sybase and naught to do with Microsoft. Things like the plus sign as a string concatenator, the way numbers are handled when compared to strings - all of that was the way Sybase did it and, for whatever reason, Microsoft didn't change it (we're talking way back in the late 80s and early 90s). In fact, there's not a single thing in that article that has changed or been implemented by Microsoft - nearly every one of the nitpicks/topics referred to by OP refer to the original choices made by the Sybase engineers. You could say, "Yes, but Microsoft hasn't changed this despite having 20+ years with the source code + standards!" and that's a valid point.[0]

1) TRIM - This has been asked for and discussed ad nauseum in the SQL Server and Sybase community. It always circles around the idea of VARCHAR though - the variable character type automatically trims trailing blanks thus, years ago, developers said, "Ahhhh, screw it - no need for a TRIM() function! They just should use the LTRIM() function to get rid of the leading blanks." It's not correct IMO but that's always been the logic.

2) "This behavior violates the standard and is specific to SQL Server." \- I hate this statement. Which standard? What section? This is a case of it being easy to say something but, without backing it up with a citation, it implies that I trust the OP. I dont' know OP - maybe he's right but maybe he's interpreted "the standard" incorrectly, or is referring to an outdated standard, or is comparing SQL Server 2000's interpretation of a later-written standard. There's no way to know - it's just too ambiguous.

3) ORDER BY in subqueries - I laughed when I saw this:

SELECT * FROM (SELECT TOP 100 PERCENT* FROM mytable... ORDER BY id) q

 _In nested queries and inline (single-query) table valued functions, ORDER BY is not supported unless TOP is used with the SELECT._

Kinda, sorta - it depends on which version of SQL Server you are referring to. SQL 2012 - yes. SQL 2008 - yes. The "original" SQL Server would have done what OP talks about - sorting w/ TOP - but, at some point, MSFT changed it to give the behavior he talks about. I can't remember when - maybe SQL 2005 or, at worst, 2008 - but this is an example where using specific version names would be helpful.

[0] [http://en.wikipedia.org/wiki/Microsoft_SQL_Server#History](http://en.wikipedia.org/wiki/Microsoft_SQL_Server#History)

</comment><comment><USER10> This was mostly well done and really makes me want to take a closer look at Postgres. But a cheap shot came on the last one, "Readers and writers block each other". Both locking and snapshots are implemented in SQL Server, and you can pick your poison. Is Postgres or Oracle better? Is either method more efficiently or intelligently implemented in either of those systems than in SQL Server?

<comment><USER11> PostgreSQL is 100% pure MVCC, a little bit like the "SNAPSHOT" method described in the article: updates and deletes always create new copy of a row, and every row has a visibility associated with it: the oldest transaction and the newest transaction that can see that row (if the row hasn't been deleted by any currently active transactions, the 'newest transaction' ID is empty).

There are definitely some drawbacks to MVCC. For example, many people are surprised how long "select count(*) from X" takes to run, because it has to do a full table-scan to check which rows the current transaction can actually see. You need to periodically 'vaccuum' tables, which updates a cached list of which table rows are deleted, so they can be reused by future update (modern Postgres will auto-vacuum, but it's another set of knobs for the DBA to tweak). Plus, the storage overhead mentioned by the article (although that really depends on the amount of churn in your particular application, and regular vacuuming keeps it to a minimum).

<comment><USER12> In fact, the latest stable Postgres supports fast, index-only scans for count queries: [https://wiki.postgresql.org/wiki/Index- only_scans](https://wiki.postgresql.org/wiki/Index-only_scans).

</comment></comment></comment><comment><USER13> Ever since I got exposed to Haskell, I've been wondering why RBDMSes-- notionally the things which should have the strongest type-systems of all-- have the moral equivalent of nullable pointers, rather than an Option sum- type. There are many cases in the use of SQL queries where weird inconsistencies with NULL could be solved by just distinguishing between Nothing, Just Nothing, Just Just Nothing, etc.

<comment><USER14> The db designer can handle that, just add an fk to a table that defines the values required for a particular problem domain.

In other words, don't succumb to the laziness of using nulls.

<comment><USER13> > don't succumb to the laziness of

No, see, that's what I was questioning. Why is using NULLs _easier_ , such that it's the "lazy" thing you can "succumb" to? UI is fundamentally about _incentives_ \--making good things easy to do, and bad things hard--and an API, or a protocol, is a UI for programmers.

Sure, instead of a NULLable column, you can have a pair of columns, one with an ENUM type to represent the sum-typeclass's type-instance, and the other to represent a value of that type. But that sounds like you're working at the wrong level of abstraction, fundamentally.

You're using an RBDMS because it lets you speak in terms of tuples, relations, projections, and other Relational Algebra concepts, rather than in terms of keys, values, and indexes. I can see doing the pair-of-columns thing in a NoSQL store--but why did the designers of SQL let this implementation detail infect my RDBMS?

It's kind of funny, actually. I see developers treating their RDBMS as a dumb object store... but then implementing a "domain model" layer right beyond it, basically creating a "model server" accessible over an API, which enforces the _business domain_ constraints on the objects it sends and receives. In other words, they've Greenspunned an RDBMS of their own in all but name, with its own custom protocol and half-assed validation logic. I feel like a large reason for this is that current RDBMSes just aren't up to representing the types and constraints and relations that developers need to express, so they put up their noses and say "business logic doesn't belong in the database!" ...and proceed to build a database for their business logic to reside in.

It's times like this when I almost get an urge to develop my own RDBMS that actually keeps the Relational-Algebra abstraction clean. No concept of a "table" or a "view" or an "index"; just relations between projections of an infinite theoretical tuplespace, where tables are created to store data that can't be inferred from an existing view, and garbage-collected behind the scenes when their values are no longer referenced by any projection. Indexes created gradually when a tracing-JIT-like query planner notices repeated access patterns. Strong, structural, parametric type declarations on every piece of data. Constraints that actually allow you to express things like "a user-to-user 'friend' relationship must be symmetric", rather than just being a weak declarative dress over triggers. Etc.

Would anyone be interested in such a beast?

<comment><USER14> You don't need a pair of columns to replace a nullable column. I was addressing the second part of your comment not your questioning of allowing nulls.

Nulls have their place I believe, but they are grossly overused. For example, if you have a Person table, then something like a nullable DateDied is logical and acceptable over a sub-type solution. But something like HairColor should not be nullable to cater for bald people, it should non-nullable and reference a table that has a 'none' value.

On another note, I don't think you can eliminate the null concept because they are the implicit outcome of outer joins and therefore means of comparing and aggregating nulls needs to built in.

<comment><USER13> > if you have a Person table, then something like a nullable DateDied is > logical and acceptable over a sub-type solution.

But this is exactly _where_ NULLs are bad. "DateDied IS NULL" could mean many different things, semantically:

\- This person hasn't died

\- We don't know if this person has died (the information was not provided with the record when imported)

\- DateDied is not an applicable property for this subtype of Person (for example, if you have an ImmortalPerson subtype.)

There are probably even more, if I wasn't just going off the top of my head. When you do an outer join, you get _another_ level of NULLability--which would perfectly map to another layer of "Nothing | Just something"\--but without that, you get those NULLs mixed in with the other three types of NULLs above. And then you insert all those into a table, export it, and import it somewhere else... and nobody knows what any of the NULLs mean.

</comment></comment></comment></comment></comment><comment><USER15> This is why you want to use SQL databases quite conservatively. Nearly every product I've seen that heavily leverages SQL has been an unportable mess.

... then you hit the performance wall, and say, "Well, just /one/ of these little features won't hurt, right?" And a year later you're singing the blues.

Standards should be executable.

</comment><comment><USER16> An enlightening and thorough article. Note that it is also not possible to SUM() a bitcolumn. Why, I will never know.

<comment><USER14> Is someone who finds something enlightening qualified to say whether something is thorough?

</comment></comment><comment><USER17> Good article. Another one that I find counter intuitive is that the sum of an empty set returns null which goes against set theory (states it should return 0) but apparently this is by design

<comment><USER18> Why shouldn't the "sum" of an empty set return 'NULL'? I could understand why a 'count' of an empty set should be 0 (which it is in SQL Server).

<comment><USER19>
        sum(A) + sum(B) = sum(A ∪ B)
        sum(A) + sum({}) = sum(A ∪ {})
        sum(A) + sum({}) = sum(A)
        sum({}) = 0

<comment><USER20> (This assumes either A and B are multisets, or they are disjoint.)

<comment><USER21> Indeed, but in the context of minor changes in how things SQL should behave, we can assume that everything is a multiset.

</comment></comment></comment></comment></comment><comment><USER22> As one of the comments notes, ORDER BY in subqueries is sometimes used for implementing pagination. I only have a limited amount of experience with SQL Server, but you ought to be able to accomplish the same using window functions:

        SELECT blah FROM
            (SELECT blah , ROW_NUMBER OVER(ORDER BY blah) num from mytable) as subq
        WHERE num < 10

Of course, it's anyone's guess how efficiently SQL Server will optimise that :-).

<comment><USER5> That is correct: [http://troels.arvin.dk/db/rdbms/#select-limit- offset](http://troels.arvin.dk/db/rdbms/#select-limit-offset)

Although note that if you're one of the Cursed Few who still has to use SQL Server 2000, you don't have ROW_NUMBER.

<comment><USER22> That's a useful site, thanks!

</comment></comment></comment><comment><USER14> That was quite dull and for the large part spurious. Order by on an in clause, aggregating bits, multi column in clause, trim, ordering of nulls, using,.. All of these are of zero practical interest.

Also, all this talk of 'standards' is strange because there is no mention of what standard is being referred to.

<comment><USER23> Dull perhaps, but spurious? As someone who writes SQL in a couple of dialects, these are the sort of things that I need to keep in mind.</comment></comment>


Finding Family Ties to Indian Slavery in New Mexico - <AUTHOR> https://mobile.nytimes.com/2018/01/28/us/indian-slaves-genizaros.html <comment><USER2> My wife, who's from New Mexico, recently did one of those genetic heritage tests. It showed that she was, IIRC, 19% Native American and 21% Iberian peninsula. She doesn't seem to really consider herself as Native American as she considers herself Spanish, though, despite them being essentially statistically the same. It makes more sense in the context of there being a preference for Spanish heritage.

<comment><USER3> Sure, or look at Obama, who is exactly as black as he is white(or, perhaps, even more white, since his father was little more than a sperm donor and his mother/her parents raised him). But he is considered by all, including himself, to be black.

I find it interesting that in the US, mixed race people tend to become the least 'privileged' race, whereas in Mexico, at least in this one case this woman identifies with the more privileged group

<comment><USER4> Mixed race people in the US are considered less 'privileged' only to white people, who find any race of people less privileged (as a whole, not on a case-by-case basis). But to minorities, people who are half white are seen as more privileged, especially in the black community.

<comment><USER5> Mixed race people are often seen as _outsiders_ by either race; how they personally identify can vary a lot (and often it's not simply with one or the other.)

<comment><USER6> When you say "outsider", be sure that you don't mean the racist "tragic mulatto" viewpoint that mixed blood inherently (ie, from biological reasons) leads to tragedy and hurt.

Even when seen as 'outsiders', meaning, as part of a different ethnic group, it's still not uncommon under European colonial rule that mixed white/black people have more privilege than black people. That is, what you say is not at odds with what magic_beans said.

Spanish rule in the Americas had race-based caste system. This included New Mexico. Quoting [https://en.wikipedia.org/wiki/New_Spain](https://en.wikipedia.org/wiki/New_Spain) :

> Eventually a caste system was created to describe the various mixes and to > assign them a different social level. ... The upper echelons of government > were staffed by Spaniards born in Spain (peninsulares), the middle and lower > levels of government and other higher paying jobs were held by Criollos > (Criollos were Spaniards born in the Americas, or—as permitted by the casta > system—Spaniards with some Amerindian or even other ancestry.[139]) The best > lands were owned by Peninsulares and Criollos, with Native communities for > the most part relegated to marginal lands. Mestizos and Mulattos held > artisanal positions and unskilled laborers were either more mixed people, > such as Zambos, recently freed slaves or Natives who had left their > communities and settled in areas with large Hispanic populations.

Haiti inherited the French racial caste system. Quoting now from [https://en.wikipedia.org/wiki/Haiti](https://en.wikipedia.org/wiki/Haiti) :

> Haitian mulattoes became the nation's social elite and racially privileged. > Numerous leaders throughout Haiti's history have been mulattoes. Comprising > 5% of the nation's population, mulattoes have retained their preeminence, > evident in the political, economic, social and cultural hierarchy in Haiti.

In the South African apartheid system, "coloured" people (with mixed heritage) had higher status than "African" people (meaning black). While not explicit at [https://en.wikipedia.org/wiki/Apartheid](https://en.wikipedia.org/wiki/Apartheid) you can infer from "Blacks were provided with services greatly inferior to those of whites, and, to a lesser extent, to those of Indian and coloured people." that black people were less privileged than mixed race people.

<comment><USER5> > When you say "outsider", be sure that you don't mean the racist "tragic > mulatto" viewpoint that mixed blood inherently (ie, from biological reasons) > leads to tragedy and hurt.

No, I'm saying that, in practice a person if mixed White/Black background will often be seen and treated as something-distinct-from-White (and disfavored for that reason) by Whites and something-distinct-from-Black (and, again, disfavored for that reason) by Blacks.

> Even when seen as 'outsiders', meaning, as part of a different ethnic group, > it's still not uncommon under European colonial rule that mixed white/black > people have more privilege than black people.

Yes, in systems with _de jure_ racism, often mixed race categories are in an intermediate legal position between legally pure members of the dominant race and legally pure members of the disfavored race.

This actually is often part of _why_ even the disadvantaged race, treats mixed race individuals, like advantaged-race individuals, as disfavored outsiders culturally, even long after that kind of legal system is gone.

> That is, what you say is not at odds with what magic_beans said

It was a refinement, not a disagreement.

<comment><USER6> I wasn't suggesting that you were. It's a caution that the term "outsider" likely isn't the right word, because it's close to historical racist stereotypes, and from my admittedly poor understanding, might bring with it other connotations than what you mean.

As I understand your use of 'outsider', a person with a white background is an outsider to blacks, and will be disfavored for that reason by blacks, and a person with a black background will be an outsider to whites and disfavored for that reason.

In colonial countries the whites had the power, so even if what you say is true, it's a relatively small component to the power structure of the culture.

What usually happens is that mixed race people form their own group, historically identified with terms like "mulatto" or "brown" or "coloured". They are not outsiders to other members of that group, and as a group have a privilege level between those of whites and of blacks.

Your construction didn't seem to consider that a new racial group might form.

The "tragic mulatto" concept, as I understand it, is based on the premise that there are only whites or blacks, that whites and blacks will both disfavor mixed race people, and that mixed race people will not form their own racial group with in-group privileges.

This is why I believed a caution was in order.

<comment><USER5> > In colonial countries the whites had the power, so even if what you say is > true, it's a relatively small component to the power structure of the > culture.

I'm not making a commentary on the power structure of national level society, I'm making a commentary on the way mixed race people are often treated by various subcultures within that society.

> Your construction didn't seem to consider that a new racial group might > form.

I think you have mistaken the word "often" in my post for the phrase "without exception". Trust me, had I meant the latter, I would not have said the former.

<comment><USER6> I think my confusion lies in that magic_beans was talking about power structure, and specifically privilege. I continued on in that track not realizing that you had changed to an orthogonal topic.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> It seems like today everyone want to feel victimized somehow, sure a lot of terrible things happened in the past, and it's good to be aware of that so we won't let that kind of atrocities happen ever again.

I'm from Mexico and here a lot of people "hate" on Spaniards because "they conquered us" that exclamation sounds pretty absurd when it comes from a dude with lactose tolerance and a big beard (both gifts from Europe). Population from northern states will have around 70% European DNA and 30% Native American, Southern states usually go the other way around 30% European 70% Native American, some researchers would say not even Native Americans of today are 100% pure natives, Mexico experienced a mix of cultures and blood since the XVI century. And yes it involved war, slavery and a lot of other atrocities. But the truth is we're not either the conquerors nor the conquered ones or you could say we're both, we're the result of that mix of cultures, trying to feel victimized for something that provoked one of your ancestors to other of your ancestors doesn't make sense.

<comment><USER8> How does becoming more aware of the past mean everyone wants to be a victim?

Part of learning about the past also involves learning about how past issues have carried us to where we are today and how sometimes the issues of the past still emerge in unexpected ways.

The bigger issue is people wanting to continue being oblivious about how the past affects the present because it's uncomfortable.

<comment><USER9> No they see individuals blaming their poor choices on things which happened hundreds of years ago. If your parents didn't give two craps about your education and you did poorly in school, that is your parent's fault, who made a conscious choice. If you do the same to your children, it is your fault.

And to blame something which happened hundreds of years ago, is to ensure this problem never gets resolved, because making poor choices is easy when you don't suffer the blame.

<comment><USER8> What exactly are you referring to? If we're talking in the context of education, it's well-established that education in this country is not equal. The factors including race and class that led to this have their roots in historical factors, yet a solution must be found as the issues exist today.

What exactly happened hundreds of years ago that you're referring to?

</comment></comment></comment></comment><comment><USER10> It's sad that even a publication like NYTimes refers to Native Americans as Indians.

It was an acceptable mistake at the time of Columbus, now not so much..

<comment><USER11> I don't really find this usage offensive, so much as confusing.

Indians are people from India.

I read the headline and imagined an immigrant from India who is exploited by an employer or visa sponsor.

<comment><USER10> As an Indian, from India, I do find it offensive and am sure that a lot of Native Americans would also find it offensive as it takes away from them their American heritage and ancestry.</comment></comment></comment>


A Usable C++ Dialect That Is Safe Against Memory Corruption - <AUTHOR> http://ithare.com/a-usable-c-dialect-that-is-safe-against-memory-corruption/ <comment><USER3> This works, although the downside compared to Rust is that soft pointer validity is checked at runtime, meaning that a program that compiles can still randomly fail at runtime and that performance is worse due to the checks.

The key idea and massive difference from standard C++ is that object destruction is delayed until a "quiescient state" happens in what is a reframing of RCU [[https://en.wikipedia.org/wiki/Read-copy- update](https://en.wikipedia.org/wiki/Read-copy-update)], allowing to freely use raw pointers as long as none survive across a quiescient state.

[note however that this system allows to take pointers to stack variables, so they have to restrict raw pointers to function arguments only - it would be better to also introduce a "heap-only" pointer that can be freely returned/stored on the heap/etc. but can't be stored in types that live across a quiescient state, from which stack-or-heap raw pointers can be derived]

This also results in the downside that things like mutexes can only be safe if they are kept locked until a quiescient state happens, since that's the only lifetime that the system understands.

Likewise, you can't do this like prevent updating a collection while iterating unless you are fine with freezing the collection until a quiescient state happens.

In general, you are much better off using Rust (or an equivalently expressive language, if it existed), since that allows to statically check for correctness, not have to delay freeing memory, and allows to use lifetimes and linear types to secure mutex locking, collection iteration, and other things where lifetimes are essential.

<comment><USER4> I don't understand your comment about how rust pointers are safer than soft pointers. The article explains how to implement a wide variety of pointer semantics, all of which are memory safe (throw an exception on explicit use after free, use the type system to have the compiler statically check the pointers are live, use dynamic cast, etc). Looking online, I see that people implement all the same primitives in rust, with exactly the same safety caveats.

Also, the container and mutex tricks you mention sound interesting, but I don't see why they can't also be used in C++ (which has a turing complete type system / checker).

<comment><USER5> > use the type system to have the compiler statically check the pointers are > live

It doesn't explain how it would statically ensure that a moved-from unique_ptr (or equivalent) can not be used. In fact the only mentions of moves are that owning pointers can only be moved and soft pointers can be moved or copied, but C++'s move does not remove any access, it just moves the content leaving the moved-from object in a "valid but unspecified state".

Note that valid != safe. Dereferencing a moved-from unique_ptr is unsafe for instance.

Rust's affine types solve this issue, a moved-from type (Box included) simply can't be used, its scope ends when it's moved.

> Looking online, I see that people implement all the same primitives in rust, > with exactly the same safety caveats.

Rust's (safe) pointers and references don't throw exceptions on explicit use after free because such code doesn't compile at all, and its equivalent to dynamic_cast has to be very specifically opted in: [https://doc.rust- lang.org/1.19.0/std/any/trait.Any.html#meth...](https://doc.rust- lang.org/1.19.0/std/any/trait.Any.html#method.downcast_mut)

<comment><USER6> > Rust's (safe) pointers and references don't throw exceptions on explicit use

Which essentially goes at the cost of having Java-style semantic memory leaks (very generally, _any_ kind of keeping-an-object-as-long-as-at-least-one- reference-exists suffers from it) => we still have to pick our poison (personally, I _strongly_ prefer to avoid refcounting, and it does work like a charm in a few very serious million-LoC/billions-transactions projects, but I do agree that opinions may differ).

<comment><USER5> > Which essentially goes at the cost of having Java-style semantic memory > leaks (very generally, _any_ kind of keeping-an-object-as-long-as-at-least- > one-reference-exists suffers from it)

Rust references work the opposite way. References don't extend the lifetime of their source, and a reference outliving its referent is a _compile-time_ error.

> we still have to pick our poison (personally, I _strongly_ prefer to avoid > refcounting, and it does work like a charm in a few very serious million- > LoC/billions-transactions projects, but I do agree that opinions may > differ).

I have no idea what the hell you're talking about, but you seem to suffer from pretty significant misunderstandings.

<comment><USER6> I'm still speaking about reference-counted RC<T>, which inevitably suffers from memory leaks. And moreover - _any_ implementation which avoids throwing an exception, in quite a few use cases has no other choice than to resort to keeping the stuff until the last reference to it is killed, inevitably causing Java-style semantic memory leaks.

P.S. FWIW, Rust's references ~= OP's "naked pointers" (NOT 'soft pointers'), and SaferCPP's 'scoped pointers'. A useful tool, but is not sufficient in quite a few real-world use cases.

</comment></comment></comment></comment></comment></comment><comment><USER7> I have a question about this.

Articles like [http://blog.llvm.org/2011/05/what-every-c-programmer- should-...](http://blog.llvm.org/2011/05/what-every-c-programmer-should- know_14.html) have convinced me that even if C or C++ reads logically like it is safe, there is a possibility that the compiler can rewrite your code in an acceptable way according to the standards such that the checks that are clearly visible in your code disappear, opening up the very problems that you thought you were protected against.

Is there any possibility that after an aggressive compiler gets done with inlining and optimization that that could happen here in some way? Can it be proven that if the compiler works according to the standard that this won't happen..even if the programmer accidentally trips on undefined behavior?

<comment><USER8> As far as I'm aware, if you stay within the confines of smart pointers (and don't drop down to the raw pointer it owns) you will never encounter undefined behavior. You may have crashes if you try to double free something, but these are defined to crash rather than letting the compiler optimize out checks.

<comment><USER9> Wouldn't you have a problem with reference cycles in C++ smart pointers? Not sure if they do anything special to prevent this.

<comment><USER8> std::weak_ptr is there for resolving reference cycles.

<comment><USER10> Which means you have to design around it. You can definitely run into problems with cyclical shared_ptr dependencies

<comment><USER8> Well, you have to do this for every language that does reference counting.

<comment><USER11> Either that, or have a cycle collector in addition to the normal reference counting optimizations.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> This technique is mostly a garbage collector, as I see it. Postponing memory destruction until the stack is empty is a special case of deferred reference counting [1], where sweep can only happen with an empty stack. If the "soft pointers" are implemented with reference counting, that's also a type of GC.

On the other hand, the tagged pointer implementation strategy for "soft pointers" isn't really garbage collection, but it does have much of the same overhead. Pointer reads must check the tag ID and throw, which is like a read barrier [2]. Writes through a pointer must do the same, similar to a write barrier [3]. And that's not getting into the overhead of multithreading; I see no reasonable way to implement this scheme in a multithreaded world. I expect that a fast GC without read barriers will significantly outperform this scheme. As much as everyone complains about the speed of GC, garbage collection is hard to beat!

[1]: [http://www.memorymanagement.org/glossary/d.html#term- deferre...](http://www.memorymanagement.org/glossary/d.html#term-deferred- reference-counting)

[2]: [http://www.memorymanagement.org/glossary/r.html#term-read- ba...](http://www.memorymanagement.org/glossary/r.html#term-read-barrier)

[3]: [http://www.memorymanagement.org/glossary/w.html#term- write-b...](http://www.memorymanagement.org/glossary/w.html#term-write- barrier)

<comment><USER6> > Pointer reads must check the tag ID and throw, which is like a read barrier

Usually, "read barrier" is understood as a multithreaded stuff - and OP has nothing to do with MT. In other words, no "read fence" is necessary (simply because it lives in a perfect single-threaded world). And from this POV, it is extremely difficult to beat this schema with any popular-multithreaded-GC. As a side note, proposed schema DOES allow 'naked' pointers, so relatively- expensive (costing ~4CPU cycles, which is not much to start with) conversion from 'soft' into 'naked' has to be done only _very_ occasionally, and after the conversion, we're working with good old plain pointers, which just happen to be safe due to the way they're used.

</comment></comment><comment><USER13> If anyone is really interested in this sort of thing, I suggest you take a look at SaferCPlusPlus[1]. It is "A Usable C++ Dialect That Is Safe Against Memory Corruption" (including data races). And it already exists.

And I think it's better than this proposed dialect in that most of the (safety) restrictions are enforced without requiring extra tooling, and it's much less restrictive. Most existing C++ code can be converted directly. And the run-time overhead is kept to a minimum. Btw these advantages apply versus the Core Guidelines[2] as well.

[1] shameless plug: [https://github.com/duneroadrunner/SaferCPlusPlus](https://github.com/duneroadrunner/SaferCPlusPlus)

[2] [https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...](https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus- versus-the-core-guidelines-checkers)

<comment><USER6> I happen to like quite a few things from it, but... there is a Big Fat Hairy Difference(tm) between "safe" and merely "safer". Make it "guaranteed to be safe" (which will most likely require tooling) rather than merely "safer" \- and I will be the first one to promote it myself :-). Also - it would be gr8 to reduce the number of different concepts developer needs to remember about while programming. In OP (assuming that tooling does exist) it is quite simple: there are only 3 concepts, with 2 of them ('naked' and 'owning'=unique_ptr<>) being already very familiar; OTOH, current implementation of SaferCPlusPlus reminds me of ALGOL68 - where it was possible to specify _everything_, but choosing the right thing was so time-consuming that it never really flew.

<comment><USER14> SaferCPlusPlus has two big issues which prevent me from using it: confusing class naming and too many concepts.

I do like the ideas it builds on, and I will probably implement a simplified version for my needs...

<comment><USER13> Yes, documentation and class names are not SaferCPlusPlus' strong points at the moment. Perhaps the easy way to get started is just to use the elements in the "mse::mstd" namespace, like vector, array, string, string_view, etc. which are just safe, compatible implementations of their namesakes in the "std" namespace.

As for the pointers, there's a slightly out-of-date article[1] that tries to explain them with examples. But a simple option is to just replace all your raw pointers with "registered" pointers. It's not performance optimal, but it's safe and simple.

But yes, better introductory documentation and examples are needed. There is not yet a forum for those picking up SaferCPlusPlus, but for now you can post any questions or suggestions in the issues section[2].

[1] [https://www.codeproject.com/Articles/1093894/How-To- Safely-P...](https://www.codeproject.com/Articles/1093894/How-To-Safely-Pass- Parameters-By-Reference-in-Cplu)

[2] [https://github.com/duneroadrunner/SaferCPlusPlus/issues](https://github.com/duneroadrunner/SaferCPlusPlus/issues)

</comment></comment></comment></comment><comment><USER15> Even when you use RAII, const-by-default, shared pointers, type-rich APIs, and the like, you're still using C++. That means you're still tied to C's legacy defaults (of UB) and that also means you're still using C++ value categories. If your "safe" C++ subset uses references, it can't be guaranteed to be safe (since plenty of _valid_ code will lead to UB).

More info in the value category cheat sheet: [https://github.com/jeaye/value- category-cheatsheet/blob/mast...](https://github.com/jeaye/value-category- cheatsheet/blob/master/value-category-cheatsheet.pdf)

</comment><comment><USER16> TL;DR; use smart pointers, RAII semantic and STL containers/iterators. Though, I'd have a few criticism...

> Rules to ensure memory safety

These "rules" only protect you against object's lifetime issues, not overflow / underflows, and other kind of memory issues.

> 'owning' pointers are obtained only from operator new

no, you shall be using std::make_{unique,shared}(...) which will protect you against leaking memory if exceptions are raised.

> Calling a function passing the pointer as a parameter, is ok.

Correct, but you can still shoot yourself in the foot. Best is to pass a [const] reference to the function called.

> This only leaves us with functions such as strchr()

Don't use C API. The STL should provide you with enough API to use the proper C++ types, either std::string or std::string_view in C++17 if possible.

> and also prohibits C-style cast and static_cast with respect to pointers

IIRC, you can't static_cast<> a pointer, you'd have to reinterpret_cast<> it, which the document does mention.

> For arrays, we can always store the size of the array within our array > collection, and check the validity of our 'safe iterator' before > dereferencing/indexing

use std::array.

<comment><USER8> Mostly agree, but:

> Don't use C API. The STL should provide you with enough API to use the > proper C++ types, either std::string or std::string_view in C++17 if > possible.

Sometimes you're working with C API that gives you back a char * that they've already allocated. AFAIK there isn't a way to create an std::string out of that without a copy.

> you can't static_cast<> a pointer

You can static_cast a void * into other kinds of pointers.

> use std::array

Do you mean std::vector and at()?

<comment><USER17> > Do you mean std::vector and at()?

No, std::array was added in C++11: [http://en.cppreference.com/w/cpp/container/array](http://en.cppreference.com/w/cpp/container/array)

<comment><USER8> std::array has its size fixed at compile time, so there's no reason for you to do have to do bounds checking…

<comment><USER14> char buffer[100] also has a fixed size and is responsible for most buffer overflow bugs :)

array::at is just as mandatory as vector::at IMO.

</comment></comment></comment></comment></comment><comment><USER18> Dialects are of limited uses, because they are dialects... New dialects are arguably of even more limited uses, because better languages now exist where the desirable characteristics are enforced not by using a dialect, but by the core languages, and safety checking is not optional. (Also, I'm somewhat curious about why the proposed dialect tells about think "similar to unique_ptr, and so over: just use the real think -- at least it would be less a dialect and more of modern standard C++). Dialects enforced by wishful thinking or at beast ad-hoc tools maintained by a too small community will perish in front of well architectured languages maintained by a real community.

They have even been used to ship some important code in big project made of tons of legacy code -- so I'm not even sure an interop argument could be made.

<comment><USER4> One point of a dialect (aka "coding standards") is that you can evolve legacy code bases toward them with a series of simple refactorings instead of by rewriting from scratch.

For me this is the big advantage of C++: it is possible to backport virtually any language feature you want to it, thanks to the combination of modern template programming and low-level C-style bit twiddling.

</comment></comment><comment><USER19> Interesting article. I hope the author has a chance to take a look at the Pony language, which he's described the core of. Now all it needs is a capability system to statically ensure that the data in sent messages is safe without copying. (And to move those runtime checks into the type system.)

</comment><comment><USER20> This is pretty close to the "autorelease pool" concept in objective C - <USER2> idea which I copied in C++ for a product around 10yrs ago to good effect.

You wrap an auto release pool around every turn of the event loop, which is the deferred memory release mentioned in the article (I admit I only scanned it). Within the "react" part, this gives you much cleaner way to code even if your code involves raw pointers to objects, as long as they are allocated on the pool and aren't being transferred to another thread or caught in an RC loop - both of which we managed using custom smart pointers.

</comment><comment><USER21> I feel like stuff like this is why golang and rust were created.

(edit: Forgot about Rust, sorry!)

<comment><USER22> _I feel like stuff like this is why golang was created._

Or more properly, why Rust was created.

I've grudgingly used C++ on some projects because of other constraints such as the target platform. Due to the compiler version, we're stuck on C++11, which is... OK. But keeping straight what we can use, and what we can't, and which kinds of pointers we should be using when is a considerable burden.

Still working through "Effective Modern C++" while learning the ins and outs of it in general.

</comment></comment><comment><USER23> _" Now, we can extend our allocation model with a few additional guidelines, and as long as we're following these rules/ guidelines, our C++ programs WILL become perfectly safe against memory corruptions."_

What could possibly go wrong?

<comment><USER8> If you're not being facetious, then really, not much. You really can't go wrong with smart pointers unless you explicitly try to access the memory it handles rather than going through its normal interface (e.g., not using get()). Shared pointers are basically reference counted just like many other language handle memory management.

<comment><USER24> > > as long as we're following these rules/ guidelines

If that's an assumption, it's not worth much. A safe language is one that enforces the rules, not one that hopes the program authors self-enforce.

<comment><USER25> I don't think anyone claimed the _language_ was safe.

<comment><USER23> Title: "A Usable C++ Dialect That Is Safe Against Memory Corruption".

Any questions?

<comment><USER16> The author claims that the rules described, "extending" the standard C++, are enforcing memory corruption, and it is this author described subset that is still unsafe, not C++ in general. Think about english vs. americanized english, largely the same, but two distinct entities.

In C++, you are free to shoot yourself in the foot. In Rust, you have a Government inspector ensure that you always point the gun not just in a "safe" direction, but only toward a crosshair target at a designated gun range.

</comment></comment></comment></comment></comment></comment><comment><USER26> This is basically how I program C++. Except that I try to avoid the 'new' keyword too by std::make_unique and std::make_shared. This way there are literally zero 'new' and 'delete' or 'malloc' or 'free' calls in your program.

<comment><USER27> Likewise, I avoid -> if possible.

<comment><USER8> Like, the operator ->? Why, and what do you use instead?

<comment><USER24> You could use ".get()." instead of "->", but I don't see how that helps.

<comment><USER28> Correction: "( _foo). " or smart pointer (_foo.get())." instead of "foo->".

But I still don't see how that would help.

</comment></comment></comment></comment></comment><comment><USER29> There's a pretty good comment on this post from a shadow banned user named Kenji, which I'm reproducing below:

This is basically how I program C++. Except that I try to avoid the 'new' keyword too by std::make_unique and std::make_shared. This way there are literally zero 'new' and 'delete' or 'malloc' or 'free' calls in your program.

<comment><USER8> I just vouched for that comment, so it should show up now.

<comment><USER29> Oh cool, I didn't know you could do that.</comment></comment></comment>


Ask HN: How to build and distribute *real* products? - <AUTHOR>

Recently, I received a not-so-good programmable coffee maker. I decided to take it apart and fix it: I built what I think it's a better product and now I'm planning to redistribute it, so that other people can benefit from my improvements. However, I'm stuck because I'm afraid of being ripped off by the companies I'm going to talk to.
Does it make sense to patent the invention? I realized the patent process is particularly expensive and time consuming. Alternatively, I thought about speaking to small manufacturers, protect myself with a NDA and forget about the patent thing.
How do "normal people" protect their inventions? How do they build and distribute REAL products?
Thanks <comment><USER2> Here is what I suggest: take your prototype and imagine the mass produced version. Make a slick video that shows off the prototype, the imagined mass produced version, and a request for funding. Work the numbers and figure out how much money you need to patent your invention, get it mass produced, and shipped to it's target market. Head over to kickstarter, use your slick video and properly balanced rewards to create incentives for people to fund your project.

Your idea has all the elements that make it sound like it could be successful: coffee, programmable coffee maker, something made better than it was before.</comment>


No, the iPhone isn't boring - <AUTHOR> http://blog.derrickko.com/no-the-iphone-isnt-boring/

<comment><USER2> Yes, it is. Sorry, but it really, really is.

No NFC (and some crap about Square letting you use wifi): NFC is for far more than just mobile payments. The ability to instantly swap and share content between devices is spectacular. The fact that NFC isn't "popular enough" and therefore the #2 mobile OS won't support it should be a sign the device is "boring". And personally, if I could use NFC to touch my phone to a Square terminal like I can with Google Wallet, I'd be a happy camper.

There are bigger screens: Quoting some guy who hasn't figured out how to hold a phone with a larger screen comfortably (which everyone with a bigger screen has) is just protecting your ego. My thumb can reach my entire screen, one handed, on my Galaxy SIII. We all were told that the 3.5" screen was the "perfect size for the human hand", and now that Apple has a bigger screen, it's _also_ the perfect size? No, it's because iOS developers can't handle variable display sizes, so Apple has to do these things in baby steps.

iOS is stale: Yes, it really is stale. It looks like a juiced-up palm pilot. You can pretend all you want that "it's the most usable interface out there" - well, maybe because you've been trained to use it. There's nothing that could be better? Multi-tasking is as awesome as it could be? The Notification Center was perfect when they lifted it from Android, and couldn't be improved? Managing notification settings, app settings, having random apps that can't be removed or put into a folder - these things are ideal? (I have a much longer list of annoyances, but I'll spare you those). No, you're just trained. Best for you. Not best. There's a difference.

It's just longer: It's also lighter and thinner. So was the iPhone 4S too heavy and fat, or would you have preferred they filled that space with a bit more battery, so "you can make it through the day" isn't a selling point? They quote the same battery life as the previous generation phone, despite new chips and radios. So I can only assume at some point they went "Being the fourth-thinnest smartphone currently for sale...that's way more critical than 8 extra hours of web browsing and apps. Good work team." Is that the choice you would have made? Most users?

Congratulations, the iPhone is boring and you are happy with that. You've decided you'd rather have predictable than amazing. Don't tell the rest of us we're wrong for wanting more.

</comment><comment><USER3> The why am I bored of hearing about it?

</comment><comment><USER4> Maybe it is boring, but receiving app submission feedback _always_ brings on a sense of renewed wonder...</comment>