The amount of engineering rigor that has gone into sqlite over the years boggles the mind. It's a project that has been held up as a sterling example of successful software development many times, rightfully so. I especially like this part of their license, from the top of sqlite3.h
"The author disclaims copyright to this source code. In place of
a legal notice, here is a blessing:
May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give."
It was originally designed to run on guided missile destroyers in the US Navy. Not sure if it was ever used for that, but it explains the scrupulous attention to testing.
If you are building a guided missle or the destroyer it launches from, you are doing so because you believe it to be good and not evil to have a strong military defense. And the best defense is a good offense or something like that, I don't really follow sports.
It wouldn't be in contrast to anything. Destroying a guided missile is probably an act of self defence, hence likely to be considered good by the author.
It's a blessing, not an obligation or a demand or a condition of use.
Unlike the JSON license clause "The Software shall be used for Good, not Evil", the SQLite blessing doesn't put any restriction on your "freedom to run the program, for any purpose (freedom 0)" or on any of the other freedoms listed by the FSF.
It's no different from putting this in a library:
# This work is dedicated to the public domain.
# I hope you enjoy using it!
No one could argue that if you didn't enjoy using the library (maybe the API is a confusing mess) you would somehow be in violation of the license.
p.s. I upvoted your comment because I think you raised an interesting point!
The quote explicitly "disclaims copyright" and includes the blessing "in place of a legal notice". It would be truly absurd even for a lawyer to believe that the blessing constitutes a copyright license anyway.
I wouldn't call this license free either. In many jurisdictions there is no concept of "public domain", in some you cannot even disclaim copyright at all. In those cases the work would be under copyright still, and in absence of a license permitting you to copy and change and distribute it, you can't (theoretically. no one's going to sue you).
This is kind of saddening to see, but it is a crime that virtually every programmer has committed at one point or another in their careers. Let's be honest - in some cases it can be quite fun to do. The underlying problem is the ego, and the corresponding lack of objectivity that results.
From reading someone else's code - even glancing at it in some cases - one can infer a great many things. For example, if the indentation on some code is totally borked, most programmers will immediately be extremely doubtful about whether that code contains any interesting or useful ideas (though of course this is not always the case, counterexample being intentionally obfuscated code). In some cases, they will simply refuse to continue attempting to understand the code and dismiss it as useless. A similar thing can happen at the semantic level when the programmer detects a mismatch between the language/framework being used and the problem space; this dissonance is likely what is irking all of the people who are so childishly ridiculing your replace utility.
Sometimes when you're looking over someone else's code you spot some perceived inconsistencies/flaws/bugs. The crucially important part is what you do next. If you choose the route of publicly shaming them to stroke your own ego, then you have not only hurt yourself by appearing childish, insecure and unsociable, but you have also hurt their feelings. It's important to remain objective in these situations, and take the self out of the equation. If you HAVE to indulge yourself by tearing the code apart in a humorous manner then at least keep it between with your friends!
As I alluded before, I would guess that the reason people where poking fun at it was probably because there exist a lot of other utilities which have the same functionality and are readily available on most any system. Personally, I thought your code was interesting, and I thank you for choosing to make it public :).
Having done corporate grade mobile work, there's no question of which platform is easier to develop for. On Android, not only do you have to simultaneously target in some cases four or five different API levels, you also have to hit several combinations of screen dimensions and resolutions. The documentation for Android is also lacking in comparison to the iOS docs. The android SDK, though comprehensive and generally very high quality, suffers from the same complexity problems arising from issues related to fragmentation.
Remember though, most of the developers who are doing work that actually matters on mobile aren't doing it because they want do, they're doing it because a corporate strategist thought it would be profitable use of their time.
I haven't found this to be the case at all. With the compat libs you can pretty easily target 2.3 and 4.x. And the dynamic layout issues are more than offset by the much greater flexibility of Android's layout managers.
An iOS app I'm working on right now has been a nightmare in comparison because we had to port our layouts to the i5 form factor but can't require iOS 6 just to get autologous. Apple really blew that transition.
Still: how many currently deployed devices running iOS are you going to be QAing that application on? Two, maybe Three? How many versions of iOS are you going to be seeing on those devices? One or two most likely, iPhone users tend to upgrade with their software with much more conformity and faster. Compare that to Androids upwards of fifteen (and growing) widespread devices, and a heinous amount of API levels in the wild. That's one of the more objective factors which make Android easier.
Also, you can say that the API level differences don't matter because they are hidden by compatibility libraries like The Support Package, but the truth is that those are just the newer APIs re-implemented against the old interfaces. You pay for that extra abstraction with wasted cycles and bloat, and it's an ugly solution. Even still, those libraries aren't perfect: there have been subtle bugs or incompatibilities introduced by their use which are notoriously hard to find. Finally, even if the newer APIs are present on the device, The Support Library will still be used (last I checked, though I think they are working on this).
Less objectively, it's a matter of preference. Some people just prefer objective C to a JVM compilable language.
The emulator is atrociously slow and every manufacturer seems to have different implementations of UI controls meaning it is expensive and time consuming to test.
Run one of the x86 images and the emulator is plenty fast. It takes a while to start up but after that the speed difference compared to the iOS emulator is negligible.
Although that's true in principle it's a little idealized: HTML5 development on mobile is still a little half baked and impractical. You only have to look at Facebook's massive abandonment (at least temporarily) of that platform in favor of the native API.
The whole point of the article is that while there are more paying customers in the iOS world NOW, it's unlikely that the situation will continue to be true given the current trends.
<secure@microsoft.com>: host
microsoft-com.mail.protection.outlook.com[207.46.100.11] said: 550 5.7.1
Service unavailable; Client host [66.175.217.21] blocked using Blocklist 1;
To request removal from this list please forward this message to
delist@messaging.microsoft.com (in reply to RCPT TO command)
Did you use the makefile to build it? I'm thinking that those specific compile and link flags are key to the triggering condition.
I've gotten it to crash at least three or four times on several windows 7 boxes of wildly differing configurations. No confirmed trials on a windows eight box, the bug may have been fixed there.
I also ran it on Windows 7 (64-bit). Nothing happens, although the prompt was displayed. It wasn't on Windows 8. The program doesn't do anything special. Either you're running some other version of the program, or your report is incorrect.
I think I was able to reproduce it myself. Yesterday I ran your program on one particular laptop, tried to get it to crash but it didn't. Then today when it woke up from sleep, it suddenly bluescreened. I think you may onto something here...
I haven't exactly pinpointed the cause of the problem, I just noted that that call was the last point in my code to get executed before the system was hosed.
Also, the code is complete: check the tarball listed at the end of the page.
agreed. I was surprised at the number of responses to the contrary. this 'idea' is nothing new, nothing innovative, and has been proven to be a terrible approach by history time and time again.
well why doesn't he explain how we safely present a system API to arbitrary code?
the whole point of the browser is to provide a method for cross platform ui, abstracting the display of an application from the underlying OS. if you were to want to support more than one operating system you'd have to recompile your binaries against all the system APIs that you wanted to support, sysV, winnt, darwin, etc...
and if you were to present an abstraction which would transparently handle the system API difference then you're looking at a JVM, which has been painfully demonstrated to be extremely hard to prevent escalations for, time and time again.
"The author disclaims copyright to this source code. In place of a legal notice, here is a blessing: May you do good and not evil. May you find forgiveness for yourself and forgive others. May you share freely, never taking more than you give."