jsjenkins168

http://www.spamhaus.org/sbl/

What programs are used? I'm a bit skeptical when the author doesn't mention any specifics.

EDIT: Assortment of linux film production applications available, apparently: http://www.linuxmovies.org/software.html

My prediction (and hope) is it ushers an era where consumers expect to have the ability to install any application they want on their mobile device, without having to go through their carrier to do so. I think carriers will start to lose that power and Apple will drive the change.

The best solution is still to stay off deck in the sense of offering a WAP-based web application rather than something that is installed. But this obviously wont work for some type of applications (Loopt is one of them). Loopt is doing great though, I am excited about their success.

The only instances I've seen UML being useful is in very large software projects with many people involved. Having an abstract way to convey program structure can be useful there. But for anything less it will probably slow you down and restrict your freedom, IMO.

My only concern is that knowing certain important people from TC now read HN, there might be an influx of spam from people looking for attention. Especially now that everyone knows it is possible get TC coverage by posting here.

This would only be a bad thing though if the "hey look at me!" spam really got out of hand. Otherwise, I really like reading about peoples startup projects (as I'm sure Arrington and others do too), as long as the intent is genuine.

Raising money beyond bootstrapping is very difficult unless you are referred by a credible source, which is what YC is. Its about the referrals and connections and the associated attention that comes along with them, not so much the money. I'd give up 6% of my startup if I could personally connect with all of the important angels in SV and Boston, probably even if no money was involved.

But, like you say it all really comes down to the product. That I'll agree with.

Unfortunately, individual health insurance is expensive. So it will definitely increase your burn rate. Regardless, I dont advise skipping on health insurance. Even if you are not a particularly active person, you just never know what can happen. ~$100 a month is not worth risking your life over.

I also prefer Android approach, even if theoretical performance might be lower not being native.

Android devices with significantly less RAM handle it fine. When a Service is scheduled, it is only allowed to run while resources (battery, CPU, memory) are sufficient to keep the critical processes (currently visible UI, current application) running. The OS has permission to kill off background Services without warning as needed to preserve the user experience.

No, the reason with Apple is simply political.

Reading the whole post, it is clear that Arrington is referring the importance of recorded music in monetary terms, not artistic.

Incorporate in Deleware (that is standard practice for tech startups btw).

Your application could be: Python -> Jython -> JVM -> compiled iPhone native and Apple cant tell the difference (or could they?).

Also, since everything runs in the same sandbox, Apple would technically not be able to stop people using the JVM with their applications. The JVM itself is not its own application, its just used to translate java byte code to native iPhone code for your application. Again this raises potential issues on how Apple could police that.

Also, this will be pretty pointless if the JVM must also run in the same sandbox as other iPhone apps. Its just additional overhead and the libraries will ultimately be limited to the same resources native apps have.

The only benefit I can think of is if you already have a Java ME based app you would like to port to the iPhone quickly.

I am curious as to the real reason why Apple neglected to implement a Service capability. The iPhone is effectively not multi-task capable and that is a monumental shortfall. I can only guess that they had too much to implement and didnt want to take the time (at least yet) to implement the service scheduling properly. Or I give equally likely probability that they simply dont want 3rd created applications to rival what Apple can make. They seem pretty anal about maintaining tight control over their walled garden.

I agree the real reasons for not doing so are based on ulterior motives. Apple is greedy and doesnt want Adobe playing in their walled garden.

This is an important consideration I think many ignore. There can be variability in how ICs, power, and speaker cables sound which does not always correlate to how fancy or expensive they are.

GWT is a higher level of abstraction than most other frameworks, which some like and some do not. The top-most layer is actually not coupled to anything specific related to javascript, DOM, or HTML in general. DOM manipulation and javascript are treated much like in-line native assembly code in a traditional high-level language. You can develop an entire web application like GMail without ever seeing anything below this high level abstraction. This may make it sound weak or limited, but its actually very powerful b/c you can focus on building rich functionality rather than debugging erratic cross-browser quirks.

The data is highly weighted on certain languages, which is probably to be expected. I'm a bit surprised there are not more Arc, GWT, AIR, or Silverlight based projects going on yet though.