nupark2

Mine do differ. Anecdotal evidence, after all.

Mine was 5 characters, alpha and numeric, but no special characters. It was in there, prepended with 0's.

Whoops.

At the very least, it should have been longer.

> No, there YOU go doing it again. That comment was in a long thread of context, and you willfully ignored that. The comment was also non-actionable and was clearly political hyperbole.

Not really, no. SOPA actually exists, and you joked about hanging its supporters. The only context that would have made it remotely appropriate is neutral one, in which it was clear to any observers that encouraging the hanging of SOPA supporters (even 'jokingly') was not your position.

> It's little thing called "the first amendment". Perhaps you've heard of it? Read it closely. It makes no reference to "...unless there were lynchings in the last century".

Then let me rephrase: There's no room to joke about lynching elected representatives (or anyone) in civilized mature discourse.

There is also a long history of case law that restricts "fighting words", despite the first amendment.

My only take-away from your repeated reference to assassination/lynching is that you're someone who is likely to incite if not participate in violence, and beyond that, you personally decrease the overall quality of rational discourse in US politics.

You may not be enough of a nutcase to try to assassinate a politician -- I'm honestly not sure, given your remarks here, and your ownership of the tools to do so -- but your seeming need to joke about assassination contributes to a culture of political violence that may very well incite someone to do what you won't.

... and there you go doing it again.

There's not much room to joke about assassination and lynchings in a country that has a very recent history of assassinations and lynchings.

It's in bad taste, it can incite violence, and given your statements here, as well as those you've made elsewhere, I'm unsurprised that the law came down on you.

Can you name a single widely used modern processor architecture that uses odd word sizes?

Microcontrollers are fair game.

I can't think of one.

They are broadcasting it to all of their neighbors. In our apartment building, I see about 30 WiFi networks.

> 1) There is very little chance of them closing their doors in the near future as they raised a large series A and have great growth.

Until/unless they get purchased. As you said, it was a large series A.

> 2) Having personally talked with Tikhon on the subject and it's clear that they plan to make this a stable platform for the longhaul. I would not hesitate to build a project on top of Parse they are a great group and would not leave their users hanging.

If they're bought, it won't be their decision.

> 3) If you're still hesitant keep in mind you can still keep mission critical stuff on your own Servers/APIs and use Parse for Push Notifications/Location etc.. There is nothing locking you into what parts of the Parse SDK you use.

Push, etc, is the easy stuff.

> 4) You can always export your data.

It's the continued functioning of the code that I'm worried about, not the data.

I see Heroku, Beanstalk, et al as the future here. This code-less approach will hit a brick wall very quickly, at which point they'll be writing something not unlike Google AppEngine, which itself suffers from being proprietary.

There's a substantial difference between a service and an installed product.

PostgreSQL 9.3 is installed on your database server, the source is available, and it isn't going anywhere.

If Oracle discontinued their database platform tomorrow (unlikely!), your licensed copy will remain valid for a long time up until you swap it out for another closely compatible database.

If Parse closes their doors or exits tomorrow, that's it.

Compare to AWS: If Amazon discontinues EC2, other virtual hosting services exist. If they discontinue Beanstalk, then at least you were coding to a commmon servlet API. If they discontinue S3, there are some compatible competitors, but hopefully you wrote your data layer to be S3-agnostic.

I think non-standardized AWS services are more risky. More standardized fare -- EC2, Beanstalk, etc -- less risky. Basing your entire code base on pervasive use of Parse -- very risky.

Being a hacker has nothing to do with poor ethics. In fact, I'd say many of the best hackers I've had the privilege to work with have a strong sense of morals and ethics.

None of that is justification for theft.

The victimized party can choose to spin this any way they want, but it had no bearing on whether it actually did them harm or how they actually feel about it. That's not your decision to make, and 'shades of gray' is a lousy justification for theft of service.

That neither proves that unethical behavior was required for Apple's success, nor that said bond could only be created through unethical behavior. If you want a recrimination of that behavior, I'd be happy to give it. It was immature and wrong.

This is a simple 'black and white' ethical case. He didn't have approval for the services and resources he consumed, he knew it was wrong (he purposefully avoided security), and he could have resolved any "gray area" at any time by simply asking permission. QED.

There's quite a bit of debate and philosophy on moral relativism, too. Which is the rhetorical baseball bat you're trying to apply here.

I see AOL as doing their best to avoid a bigger snafu over a smaller, unattractive snafu. Opinions on the value of this PR will vary, but the fact is that there's no substance here.

Somebody abused their fairly standard SV corporate perks, they responded without bringing in the police.

At the end of the day, my subjective impression is that their startup interests brought in an immature, ethically-challenged entrepreneur who is stuck in the money-raising cycle, and accordingly AOL has been dragged into the press because of something stupid he did.

That isn't a particularly positive narrative, but I can see how people that are more comfortable with Eric's failure of ethics can see it as a cool story of "hustling" entrepreneurship.

That's an unsupported assertion.

What unethical behavior are you referring to, and how have you demonstrated that Apple's success not only stemmed from such behavior, but could have only occurred through unethical means?

> They've actually been profiled as a reasonable company that invests in the future.

The best thing they can do at this point is put a positive spin on it, but ...

> The positive spin this article gives them is worth every penny of resources spent.

Not your decision to make for AOL. AOL will spin this, but post-facto justification ("see, it's not that bad -- they made good on my theft!") does not an ethical decision make.

> AOL is going to get press out of this that am sure they will find worth the few months of squatting.

That's AOL's decision to make. Not yours, not his.

> Also, entrepreneurs break rules in order to get stuff done.

Unethical people engage in unethical behavior (which is sometimes "breaking rules") in order to get stuff done.

Plenty of entrepreneurs do business honestly, and I'd rather read about them. I don't need a news story to tell me that behaving unethically can provide gains at a cost to others.

I prefer to work with people that resolve ethical questions ethically, not based on who benefits (or loses).

This is an exceptionally long rationalization for unethical behavior that well demonstrates why I am so opposed to the focus on "hustle" (or as you put it, "moxie") in some segments of the business world.

If someone leveraged this kind of "moxie" in interpreting a gray area of a contract with our corporation, I'd hesitate to do business with them again -- they couldn't be trusted to ethically consider both sides of a moral/ethical/legal quandary and resolve those gray areas to our mutual benefit.

AOL out the funds they spent on his theft of service and resources, and they're out the time they spent having security figure out why someone was sleeping there. They've been embarrassed in the press, and they're that much less likely to trust people that are part of their entrepreneur programs in the future.

The security staff in question was probably reprimanded for their failure to detect the interloper -- he abused the trust he had gained by previously becoming a "known" face.

You do what you have to do, ethically, to succeed.

Just a guess, but the iOS keychain can be used to share information across applications with a common bundle prefix.

It's also a demonstration of an ethical failure. It was theft.

If you use unit tests and Interface Builder, that time should largely disappear.

Compared to most specifications, RFCs are incredibly clear. While quality varies, they're remarkably approachable documents.

Of all the things to dislike, I find your dislike of SHOULD/MUST/MAY to be incredibly bizarre. The definitions of the words are intuitive, they place the definitions at the top of the document, and they use the words to eliminate all ambiguity when reading the document.

If you don't like RFCs, I'd be very curious to know what specification documents you do like.

The direct mapping of the database that it provides isn't really direct, and the impedance mismatch makes a mess of what could be a simple, easy to understand in-memory application model.

No, you haven't. If your in-memory application model mirrors your database model, you're probably doing it wrong; either your application model is poor, or your database model is.

> Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM.

This is not true.

At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model. If your hand is not forced by the ORM, this is unlikely to be a direct mapping of the database.

This is no different than a network protocol, wherein the protocol is not a direct representation of application state, and the application does not attempt to model the network protocol using the same constructs that it uses to model its in-memory state.

Or, switch to PostgreSQL for new projects and stop throwing good money in after the bad.

The hardware in question very likely has computing power (and associated cost) not that far off from that of the Raspberry Pi.

You also have to factor in the cost of the machine used to drive these USB display drivers -- with 4 users on a $500 machine, you're still talking about $125/user.