Let's look at a better popularity metric - what percent of which OS hit the servers of Wikipedia in October 2011.
Ubuntu was 0.41% of all Wikipedia traffic with roughly 16.9 million hits in October. Mint was 0.01% of Wikipedia traffic, with roughly half a million hits in October. Ubuntu traffic dwarfs Mint traffic by many multiples.
In terms of the popularity of Linux distros hitting Wikipedia: Android was #1. Ubuntu was #2. Fedora was #3, just barely surpassing SuSE which is #4. Debian was #5. Mandriva was #6. Then comes along Mint at #7. In fact, Mint is barely even beating Kubuntu. Hits to Wikipedia is not a perfect metric, but if anyone knows of a better one I'd like to hear it.
Things can change, and Mint may be gaining popularity, but we have to be realistic about things. I like a lot of things about Debian and Trisquel, but I'm also aware of the fact that for every Debian desktop hitting Wikipedia, there are 20 Ubuntu desktops hitting Wikipedia, including my own. That number goes to 1:30 for Mint to Ubuntu. So no, Mint will not be surpassing Ubuntu any time soon.
I have an app on the Android Market which is not that popular relative to others in its category, I submitted it to Amazon, and they wanted me to tweak it (mostly because of how Facebook's Android-style app is broken more than mine was, Facebook answers one of my Intents badly, a problem many people have had). This particular app has no ads yet, but I wonder who does ads with Kindle Fires. I don't see anything on Google-owned Admob. I don't have an Inmobi account yet, but don't see any mention of Kindle Fire on their web site. I wonder which vendor ad-supported Kindle apps will use.
I use a fairly up to date version of the latest Ubuntu, 11.10, as my desktop.
One thing I dislike is when they complicate things that used to be simple. It used to be if I wanted to switch to another workspace, I would move the mouse to the top of the screen and click which of the other workspaces I wanted. Simple.
Now to do that I have to move my mouse to the left side of the screen. Then a bar pops up on the left side of the screen, then I move to the workspace changer and click on it. It moves to workspace switcher mode. Then I move the mouse across the screen to the workspace I want and click. It complicates something that had been simple. In fact it's changed my behavior in a way I did not want it to - I used to run Firefox and Eclipse in separate workspaces, but as workspace switching is more of a hassle, I now have both open in one workspace.
Aside from things like that, Canonical decided it wanted to do things its own way and has been moving along with a Gnome fork. Which might be OK if it had enough resources. But it does not. for example, here is a bug that I encountered. Orange windows pop up all over your workspace while you're trying to work. It can be quite annoying, as the users comments suggest. It was reported over three weeks ago but a fix has not been released yet. Unity does not have a wide base of developers supporting it like Gnome or KDE do, almost all of the developers doing this type of work are working for Canonical.
I met someone months ago who liked using Google Voice Search on his smartphone. He said the best thing about it was that he didn't have to use the small screen keyboard on his phone. I wouldn't underestimate this as a motive for usage, if it's faster and easier to do it this way, people will use it. My tablet had come with it preinstalled, with a microphone button on the top left, but I never bothered with it until I met him, after I did I tried it out and it worked well. I myself don't use it regularly, if I'm showing the tablet to someone I might show them it can do that, but I haven't used it much otherwise.
I don't see this as an Android killer at all. Today you can download various Android apps, including Google Voice, that can perform tasks by voice activation and recognition. Even if Siri is superior to them, and maybe it is currently, they're good enough in the time being for most people.
I've been developing for the Android Market since May. There are some things to consider. One is some companies don't expect immediate success - lots of banks and such which may have been slow to get a website, have decided to get on smartphones and tablets now. The return for this might take years to come, but they have plenty of money. Why not do it now? They have the money and forecasts show they'll need it eventually, to stay competitive. Sometimes it is existing software. For Android, the Adobe PDF reader was really junky for the past few months. They just released an update, and now the app is much, much better. So they also are protecting their brand.
My capital costs, other than my labor time, are approaching $0.00. Well actually approaching $25.00 as that's what a lifetime Android Market account cost me. I have Admob ads in most of my apps, and average 5 cents a click. So after 500 clicks, I'm in the black. I can go on vacation for two weeks, and come back and see how much I have earned in the interim on Ad clicks. If I wanted to, I could sell apps, or do in-app sales and the like, and maybe I'll try that in the future.
This is something I enjoy doing. I do everything - I look over the entire market, I think up what to do, I write the code, I do the layout, I do the artwork (or get free for commercial ones from findicons.com, iconfinder.com etc.), I decide which user-requested features to implement and which to ignore. I decide whether to work on a new project or improve my existing projects. And then I get the money. Another thing is with work, in this young market, my check is increasing every month. Some of it is my improved products and some of it is people getting new Android devices for the first time.
Some of the things our community knows are relevant here I think. Release early, release often! Are there any Android apps which could load and search Microsoft Access databases on the phone, even if it had no network connection? There wasn't back in June. There still is not one as far as I know other than mine - Panacea Database. I didn't even have to do the Access-specific work, there was a LGPL license library out there I used called Jackcess. My first release took four days - all it did was load the database and iterate through the table rows. You couldn't even iterate backwards, and users said it then looked like junk on smaller phones. But in terms of competition, only one app came close, and for some things (free for an unlimited time, able to handle Access without needing to install a desktop app), it had no competition. Now, 1500 active users later, I have made a lot of improvements, many suggested by users. Which is another thing known by our community - listen to the users, and with a little bit of discrimination, let them have a large hand in determining the roadmap.
Panacea Database was really just an experiment to see if I could successfully port a popular open source Java library to Android. The experiment was an all-around success: I ported it, I sent patches back to the library which helped improve its Access 2010 usage (actually the lead developer took my patch and improved it even more), and lots of users are happy they can do what they want on their Android phones and tablets, and I'm making money on ads. And - I'm helping, in a very small way, an open source Linux platform be more useful. It's a small effort, but combined with a lot of other people like me, it has an effect. The users make out, the library makes out, Admob makes out, Google makes out, the manufacturers make out, the carriers make out, and I make out.
So the map seems pretty open to me. As the Cathedral and Bazaar says, whether its open source or not, scratch your own itch. Think what you'd like to see that is not on Android - or not on it in the way you want. Will people be able to find your app? There's 2 or 3 popular file managers, and those apps are easily findable by searching for file explorer or file manager or whatever. Will your app be as eas
I do Android development, and I had a look at the SDK and emulator when it was released last night. I created an emulator and was testing my applications out on it.
The first thing I noticed is that there are more help screens. I believe they disappear after first use, but they tell users how to navigate around the phone. Or tablet as it may be - that's probably the biggest thing about ICS, it integrates Gingerbread (smartphones) and Honeycomb (tablets) into one OS. I've been getting the hang of Android layout, and it is not so hard once you get used to it, you just stick with the things they recommend - density-independent pixels, scale-independent pixels, objects sized by width and/or height by fill-parent (fill layout container object is in) or wrap-object (make object only as large as it need be), objects or layout containers being assigned by weight. One trick I learned - I start design with the smallest device - WVGA - a small device with a low number of dots per inch. I do a portrait (device held with more height than width), and if I have time a landscape (device held with more width than height) view. Sometimes that is enough, and those two layouts work from the smallest to largest devices. Usually it requires a little tweaking, especially Activity classes that make use of buttons. You take the layouts you made and increase text size, increase the distance between objects and other objects, or objects and the edge of the screen. Some people rethink the design, they use Fragments so that where something that would be done on a small screen with ten screen changes with ten different Activity views, is now done with five screen changes with the same ten different Activity views - you just use Fragments to put two or so Activity views per screen. The ICS smartphone/tablet integration will help in that department, although you can do it to some extent already. In fact Fragments were introduced in Honeycomb (the old tablet Android version, before this ICS tablet/smartphone integration), so some of this is just bringing Honeycomb advances back to the smartphone. Another example of this is the Actionbar - over time the Android designers realized it would help UI consistency, ease of programming etc. if they put a bar on top that let people do things (open an email, go to the next page, whatever). So Actionbar was in Honeycomb, now it is in ICS as well. I should mention there is a compatibility package which allows apps to use many (but not all) of these new features on older phones like Gingerbread, Froyo, Eclair etc.
The next thing I noticed when looking at my apps in the ICS emulator is the new Roboto font. It is said to be able to be a good font for everything from a small, low density to a large screen with a high density. Some of my apps use the Android non-default fonts, and the ones I looked at looked most the same, although there may have been small tweaks I did not notice. And Android lets you use your own fonts.
One of my applications runs in the background, doing a database search while updating a progress bar - and while all of this is happening, an ad is often being loaded as well via the web. It seems to be stalling on something in the ICS emulator, I will do some debugging later to see where it is getting stuck. It may be one of those cases where I was doing something wrong but Android allowed it, and they increased the strictness of things. With ICS's use of Fragments, I can probably just load one ad Fragment when my app starts and put that on every screen anyhow.
Regarding source code, I'm sure it will be released. It will be a month or so before you can buy a Samsung Galaxy Nexus anyhow. The sooner the release the better for me, but Android's open nature beats Windows 8 Mango and iOS any day. I can sit at my Linux box, use open source tools to develop everything, and then just push it out to Android Market (or some other market - Android does not lock phones to their store like Apple does). It is beyond me why Apple punishes developers with an app sto
With the explosion of smartphones and tablets, HP announcing they're leaving the PC business and all the news being how Windows 8's perhaps main feature being tablet (and smartphone) ability, the mobile aspect of Windows 8 is what many people will be looking at.
I hear some Windows fans talk about how Windows 8 is going to come in and eventually dominate smartphones and tablets. However, Apple already has been in the smartphone space since mid-2007, and the tablet space since April 2010. Android has been around since October 2008 in the smartphone space, and Honeycomb came out in February of this year (and a few months earlier things like the early Samsung tabs were coming out). Developers have spent a lot of time learning these platforms and writing code for them. The App Stores and Android Markets are filling up with apps, which are being improved continually by updates based on user feedback. Over 550,000 Android smartphones are being turned on a day. Customers are familiar with the apps on their phone, and how to do various things on their phone or tablet.
What do we he hear from Microsoft? It's all just vaporware so far. Even if developers want to develop for an SDK with no device, there's no SDK out yet. Maybe it will be put out after this conference. Also - Microsoft has been saying a lot of it is HTML 5 and Javascript. I'm happy about that, but it doesn't really exploit all the code and experience for Visual Basic, Silverlight,.NET and so forth. I understand they backpedaled on this a little bit, although HTML 5 and Javascript will still be on it. They're kind of forced to do this - they can't force mobile developers to develop just for Microsoft, they have to hope that the popular iPhone/iPad/Android applications are easy to port to Windows 8 so they can get some applications that way. Microsoft's Windows 7 smartphone/tablet market share is very, very low, so due to the lack of any kind of monopoly strongarm, they're forced to open up a little bit.
The two things Microsoft has going for it is the existing Windows code base, and the ability for people to connect to their PCs, or PC formats (Word, Excel) or Microsoft servers at work (Exchange etc.). As people dump Microsoft PCs for iPads and Android tablets, this lock-in becomes less important. Also insofar as the Windows existing code base, both Apple and Android have had a lot of C++ OpenGL code which used to be primarily dedicated to Windows ported to Apple and Android mobile devices. Miguel de Icaza and company have even brought Mono to Android, so a lot of C# and.NET code can get on Android. As existing Windows code can often be used on Android, this lessens the advantage of Windows 8.
And then there's other things. Microsoft makes money selling Windows 8 to manufacturers like HTC and so forth. Google gives Android away for free, and makes money on the hook-ins it has for Google Maps and so forth. I guess with the Motorola purchase, Google will make some money actually selling the hardware as well. Microsoft has to sell an unwanted product to manufacturers, when a free, popular OS already exists, with a user base of millions, with an Android app market with hundreds of thousands of apps, and many developers working on creating new apps and improving existing ones.
I also wonder how hard it is to develop for Windows 8. For Android, I can download Eclipse on a Linux machine, and the Android SDK, make an Android emulator, develop code in Java (with a few calls to special Android SDK Java classes like Activity), pay Google a one-time lifetime $25 fee to put as many apps on Android Market as I want, and I'm all set. I can even release the app to a non-Market competitor site and save the $25. So the whole shebang costs $25 for life. What will Windows be like? Will I have to pay to get on their app store? Will I have to buy Visual Studio or something? If they don't make things real easy and cheap for developers, they're going to have problems. They might even have problems if they do make things real easy and cheap.
The article says that "The ultimate killer feature that Android and other tablets have failed to replicate is the care Apple took from the start to ensure enough iPhone applications were available that took full advantage of the iPad’s 9.7-inch screen. Today, over 90,000 of the 475,000 applications available online from Apple’s App Store fully exploit the much larger screen size. By contrast, only a paltry 300 or so of the nearly 300,000 apps for Android phones have been fully optimised for the Honeycomb version of the Android operating system developed for tablets—though many of the rest scale up with varying degrees of success."
If this is the "ultimate killer feature" that distinguishes iPads from Android tablets, you'd think there would be some basis for them saying that only 300 Android applications are optimized for Honeycomb. What is that basis? They do not say. An educated guess is that some months ago some unofficial lists of which applications are Honeycomb optimized were created, and at least one of those lists tallies only 300 or so applications. But this means nothing, it is just a random list made by some random person out there, which never claims that it lists all, or even a significant fraction of which applications are Honeycomb optimized. This is a rather paltry basis for what is supposed to be a killer feature.
I have an Android Honeycomb tablet - a Samsung 10.1 Galaxy Tab running Android 3.1 (Honeycomb). I also have two applications, the more popular one of which is optimized for Honeycomb. But that Honeycomb-optimized application of mine is on none of those lists of Honeycomb-optimized applications, it is one of the many applications which are not counted in that "300" number.
I have downloaded many applications for my Honeycomb tablet - so far 100% have been usable in Tablet format. Maybe 5% of the applications are badly optimized - they only use 1/5 or so of the screen space. Another 10% or so are fine, but could probably benefit with more tablet optimization - larger text size, bigger buttons.
The 300 Android to 90000 iPad comparison is ludicrous - my Honeycomb-optimized application is not counted in that 300, and I'm sure many hundreds, or thousands of other Honeycomb-optimized apps are not included. Google already has a lot of features which make tablet development easier, such as Fragments - which is part of the compatibility package, making it doable for even early versions of Android. Ice Cream Sandwich will come out later this year and further ease smartphone/tablet integration.
I should point out that Android is not just playing the following tail lights game. Google TV devices are built on Android as well. Smartphones was the first big market, and then tablets, but who knows what devices Android will target and try to replace in the future?
There is no fight for the Linux desktop. Ubuntu completely dominates the Linux desktop in terms of users. Look at how many Ubuntu's versus other desktop Linux's people hit one of the most popular web sites on the Internet with. Ubuntu has twelve times the number of desktop users that Suse has. Ubuntu has twelve times the desktop users Fedora has. Ubuntu has eighteen times the desktop users Debian has. So the dominant solutions for the average user have already been decided in al of the above - Evolution, LibreOffice, Unity.
As this is free software though, there are not winners or losers in the traditional sense. People happy with Thunderbird, Openoffice and KDE can continue using them. It's not like KDE is going away any time soon, even though Unity so dominates the Linux desktop. Unity is still very heavily dependent on the Gnome framework in terms of libraries and applications. Canonical does not have anywhere near the manpower to handle what the Gnome project handles. It's an ecosystem where everything benefits from everything else - Unity benefits from Gnome, KDE benefits from freedesktop.org work by Gnome developers. And vice versa - the fd.o library which handles PDF format is done mostly by KDE-centric developers - only Carlos Garcia Campos is more Gnome-based.
Compared to Windows or MacOS, a Linux desktop/workstation is a dream platform for developers, so it is never going away. The only question is will it break through to the wider public? As Linus says, Linux had done well on the low end with embedded and mobile, and does well on the high end with servers and "cloud" (whatever cloud means). It also is a popular desktop/workstation for IT people. Now, efforts like Ubuntu are trying to make headway into the standard user desktop area. Although they've been more focused on servers, Red Hat and Suse have done a lot of work in the desktop department as well, something which Canonical benefits from.
This is a statistic I watch. Mostly I am curious about Android usage, as well as other mobile usage, versus desktop usage. I'm also interested in desktop Linux usage.
Alexa shows Wikipedia to be the 7th most popular site on the web. Wikipedia is unique in that it is one of the few top sites not run for profit. Consequently, they allow open traffic analysis of their web traffic to some extent, which I have found very useful. Here is what operating systems hit Wikipedia web sites in June 2011. They have that data for May, April and so forth. I made a chart from the data a few months ago on my blog.
For June in Wikipedia, XP was 36-37% of traffic. Vista was about 13% of traffic. Windows 7 was 29-30% of traffic. Mac plus iPhone plus iPad was 12% of traffic. Android was 1.4% of traffic, and Ubuntu was 0.5% of traffic.
I would guess the majority of Android developers do not own a Honeycomb device. That would mean the emulator should be good. But on its default settings, the emulator is very, very slow. Google "honeycomb emulator" and the top results will mostly be about its slowness. Someone recommended I increase its memory, and that did help out a bit, it's still slow but at least usable.
One of my apps has less than 1% Honeycomb usage, so it is not big on my radar screen. I recently noticed another has over 7% - my app that lets people iterate and search Microsoft Access databases on an Android phone. It's the only reason I revisited the dog-slow emulator and tried the increased memory trick. I saw my app was displaying correctly with Android 3.0, and was displaying correctly on the larger tablet-sized screen. So the primary concern went away - everything worked. I then looked to see if I could improve things for the tablet, and I saw I could, but have not implemented it yet.
There are really two things here with Honeycomb and tablets. One is the OS version. The other is the screen size. With 2.3 and less you usually have smaller screens, Honeycomb often has larger screen sizes. My concerns tend more to be toward dealing with the larger screen sizes properly than implementing some of the neat whiz-bang 3.0 features.
So I think some assertions that are being made about Honeycomb are a bit off-base. If I saw my app displayed poorly on a tablet-sized Honeycomb device, I probably would have fixed it and sent an update out already. It may not be Honeycomb-optimized, but at least I made sure it is Honeycomb compatible. Also, even if I do make those changes that make use of the extra screen space on the typical larger Honeycomb tablet, I don't have an intention at this time of specially marking the app as Honeycomb-optimized. So it still wouldn't count in these surveys, even if I did optimize it for Honeycomb.
For my two existing apps, as well as others I am working on, most of what I think about with tablets is using all that screen space, which is not connected to Honeycomb (version 3 over version 2) per se. That is what most Android app developers will be thinking about more than whatever new features are in 3.1 over 2.3, in my opinion. Honestly, I am currently more engaged with limitations the Android OS has rather than cool new whiz-bang features. For example, there is a 16 bit (i.e. 65536) sized identifier for dex files which I have recently bumped up against. Which you wouldn't easily know about, since their error message for it is pretty vague once you bump into it. I'm more focused on banging my head against this wall right now than the new animation features in 3.0. But different people are focused on different things.
Chess engines have different components. Crafty and Fruit have their own licenses, which are not standard FLOSS. So ripping out the components Crafty does best with the components Fruit does best in violation of their copyright, and then closing it and having it proprietary - this is not rocket science, it's just disregard of licenses.
I develop applications for Android, so I am most familiar with that. Recently I was using someone's non-jailbroken iPad, and wanted to put an free SSH application on it. I didn't find much for the iPad, I found a little more for iPhone apps that worked on iPad. The best one I could get conked out every 500 characters or so, and you'd have to close the app, open it again, and reconnect unless you bought the app for $1.99.
I would write an ad-supported SSH app for iPhone/iPad myself if I didn't need a Mac, a $99 a year App Store account, a knowledge of Objective C, a knowledge of the iPhone API, the ultimate application approval of Apple, and all the other hurdles.
Compare this to the myriad number of free SSH apps for the Android.
I don't have a lot of iPhone/iPad experience, but for the one thing I needed, Apple was app-starved in an area where Android is not.
I see Battle of Wesnoth is included. I downloaded this game a number of years ago, when it was touted as one of the better free Linux games. I enjoyed it, mostly.
I also like a piece written by the original developer. He talks about how he had worked on various games which were unsuccessful, and what he learned subsequently and what he then did in preparation so that Battle of Wesnoth would be successful. I thought it was a pretty good short read of how he went from projects that fizzled out to a successful one with millions of downloads.
It is difficult to track users, but one indicator would be to look at the web logs of one of the most popular websites, Wikipedia. In March of 2011, 0.72% of web traffic to Wikipedia came from machines running Ubuntu. Wikipedia received roughly 30 million hits from machines running Ubuntu in March. In contrast, Wikipedia received about 3.4 billion hits from Windows machines in March, 325 million from Macs, 42 million from Androids and so on. Alexa says Wikipedia is the 8th most trafficked site in the world, and other Alexa-like sites put Wikipedia as a top site. It's one of the few (the only?) top sites to open its log analysis statistics like this.
You make an important point. Unity is a fork of Gnome. Most of the fork is not only in the user interface, but in the user visible part of the UI. Very little of the nuts and bolts underneath has been forked. So if you click around the UI as opposed to the code, it can seem the fork is bigger than it really is. Unity takes advantage of the modularity and flexibility of Gnome code. Yes, Gnome is not known for flexibility within the UI itself, but the ability to create a fork like Unity is a demonstration that the code base is written in a modular, flexible manner.
The way I look at this is Canonical/Ubuntu/Unity versus Gnome 3 and the companies and distributions which are issuing Gnome 3 desktops. The best methodology I can come up with to find marketplace penetration is web server logs for major websites. On that basis, Ubuntu currently has more than 13 desktops out there for every 1 of its closest competitor - Fedora. The SuSE's have less then Fedora, Debian less than he SuSE's and so forth.
The result of Canonical's shift is that the majority of non-mobile Linux desktop users were using Gnome 2, and will now be using Unity. They're still using Gnome nuts and bolts though. I am most familiar with the document displayer that both Gnome 3 and Unity use - evince, and the library it uses to render PDFs, poppler. Ubuntu has provided dozens of useful bug reports to these projects, as the large base of users has exposed bugs that people had just not encountered (or reported) before.
I have played with Natty (with Unity) and Gnome 3, and will probably wind up with my main OS on my multi-boot system being Natty running Unity, with a special user on Natty running Gnome 3 compiled from jhbuild (compiled off the latest git commits). A lot of changes on Unity I find less than thrilling such as close window moving to the left side of the window toolbar, and the rest of the window tool bars moving to the top of the screen. For both Unity and Gnome 3, I am unhappy that switching workspaces has gone from a mouse move and a click, to a whole rigmarole of mouse moves and clicks. There's a reason many of these things were the way they were for the last 20 years, or more. I have the command lines and shortcuts to fix some of these things - like shifting left back to right on Unity tool bars - but still.
On some level this becomes a discussion along the lines of, which is better, vi or emacs? Obviously people have different ideas on how often one should reboot. For me, it also depends on the shop - different policies are good for different types of shop.
Regarding "a situation where the systems are so critical that they cannot be restarted yet not important enough for any attempt at getting the startup scripts right" - as I said in my original post, it can be that Monday to Friday are to some extent critical, and Saturday is not.
With regards to test reboots being done - sometimes they can be, but sometimes a new application can be put on a machine which has been around for a year, with many other developers using the machine, many dependencies and so forth. Thus in some situations, people would have to wait until the weekend for the machine to reboot.
Anyhow, this is how it is in some places. People have different opinions about the wisdom of such policies, such as yourself. I've said about as much as there is to say on the topic, anything more and I would be repeating myself.
Yes, dozens. The original discussion is whether servers should be rebooted regularly (once a week/month or whatever) or should stay up as long as possible. If every other week a bad rc/init script is put in (and in my experience the average was higher), within 48 weeks you will have dozens of bad rc/init scripts. Thus "you have DOZENS of faulty changes to init scripts" as you put it. Correct. As I said before, some shops have one developer and a few machines in one room, some have tens of thousands of servers all over the word, and developers numbering in the high hundreds to low thousands - I have worked in both type of environments. Not only can this happen in a large environment, it does happen.
As far as "those that don't do it on important machines" that you talk of - naturally, this would tend to happen more on non-production, non-critical machines. I am aware that rc/init scripts, if they were ever installed in the first place, can be tested without rebooting. Developers do not always do this though. Dependencies (e.g. making sure your application starts after the database if it depends on the database and needs it running before the particular application is started) are a little more tricky to check but can be dealt with if some thought is put into it by the developer. Thought is not always put into it though.
You ask: "So what's that to get DOZENS then - over one hundred changed init scripts on one machine and a quarter of them with errors in them?" One machine? I am talking about thousands of machines, most of them with a number of (sometimes many) non-system rc/init scripts, touched by hundreds of developers, who are always changing their programs, many of the machines non-production, over the period of time discussed - as long as a machine can manage to stay up - which can be years. As I said in my original post, I am talking about large (financial or otherwise) companies, not small shops.
If you're a sysadmin, what's the largest number of machines you've ever had to support in a developer-heavy environment? If your answer was in the thousands, you would probably be less skeptical. This article says Facebook has 30k servers, Rackspace has 50k servers, Akamai has 60k servers, and Google has over 1000k servers. I can assure you that these companies regularly deal with server problems that the standard sysadmin with dozens of servers to look over is not used to - even a company with one quarter of Facebook's servers is going to have a different sort of quality to their systems setup than a company with 150 or so servers.
> One could be a mistake, but dozens means that a strawman is being constructed...
As I said before "it depends. If you have a small business, it might not be necessary to do reboot your servers...however...for a financial company"
There is no strawman. It depends on the business. I worked for a company where the number of servers being rebooted were in the thousands. Just for the UNIX servers, just in New York City, once a week we would find one if not several things that would not come up properly due to lack of init/rc scripts. I should modify my original statement slightly though - the problem with rc/init scripts were not solely due to their lack of existence. Sometimes the application-specific init/rc scripts were there - but they would be written wrong. Sometimes they would be written correctly, but would have a dependency on the database, but the application would start before the database would and fail. If machines were never rebooted and were all running for say three years, and then there was a sudden machine room crash, yes, no hyperbole, no strawman argument, there would be dozens of broken init/rc scripts to deal with, amidst all the other problems that might come up if a machine room crashed. This company chose to handle this by regularly rebooting the servers, so the fixes would be put in incrementally. There is another benefit to this - a developer who forgot or messed up on an init/rc script probably still has the application fresh in their mind. If you wait three years, the original developer may be gone, and how to fix it becomes more complex, especially amidst a machine room crashing.
How is one a mistake and dozens a strawman? It is simply a matter of scale, as I alluded to in my original post. Some shops have one developer and a few machines in one machine room, some shops have data centers internationally, with thousands or even tens of thousands of servers, and hundreds, or even thousands of developers. A rare problem in a small shop can come up often in a large shop, quantity transforming quality.
Obviously there has been acrimony between Ubuntu/Canonical and some of its upstreams such as Linux, Linux plumbing and Debian. There had also been rumblings regarding Gnome, but I had felt that was unfair to some degree. Yes, Canonical does not send much in the way of patches to Gnome and freedesktop.org, but Ubuntu has reached an audience of some of the not-the-usual-suspects Linux users, meaning non-developers. As many Ubuntu users are not developers, the percentage of users sending patches upstream ratio will be lower. While a patch is a high level of help to send upstream, there are lower forms of help to send upstream like bug reports. As there are
a lot of Ubuntu users out there pounding away on Ubuntu's Gnome GUI, I think this is helpful, an influx of non-traditional users has exposed many bugs in Gnome and fd.o which were unknown beforehand. Many have been fixed, and Gnome and fd.o all the better for it.
I do have some concerns over this Gnome/Unity fork. Not just how it will effect Gnome but whether Canonical and Ubuntu can handle a significant fork. I am fairly certain bugs like this are a product of the fork, and I wonder who is going to fix them. Canonical has trouble getting good bug reports for packages like cairo, poppler and evince upstream, never mind patching them. I can think of a number of examples, but is the aforementioned bug which was almost certainly probably caused by the fork going to be fixed before 11.04 is released? It is not the only bug caused by the fork either. Who is going to fix these? The fork is small now and these should be easy to fix, who is going to fix them as the fork gets bigger, and Gnome and Unity diverge even more? On the other hand, it's conceivable that Unity will be so awesome, that developers will flock to it, and Gnome shell will to some extent wither away. There are different perspectives, different problems and different possibilities for all of these things. I can tell you right now though that the Unity stuff is breaking stuff in Ubuntu's Gnome, and it is staying broken. Stuff that the Gnome developers will not be fixing either. We'll see what happens...
The real answer to this question is it depends. If you have a small business, it might not be necessary to do reboot your servers. Let us say however, you work for a financial company which trades from Monday to Friday, and demands high availability. Uptime on Saturday and Sunday does not matter much. Also, you are somewhat, but not always fully aware of what processes are running on the various systems. In a scenario like this, it makes sense to reboot machines. Sometimes you find equipment faults that you wouldn't have otherwise. You make sure that necessary processes are properly put into init/rc files. If you do not do this, and say your whole machine room experiences an outage one day, you might bring all the machines up and suddenly discover there are dozens of processes which were running which were never put into init/rc files properly. If you reboot once a week/month, at a scheduled time, this can be handled incrementally and without incident, having it happen all at once can be a nightmare.
The answer is it depends on the business. In my experience, it is not IT departments (and thus companies) which reboot machines once a week that have troubles, but companies which have certain machines that never are allowed to go down that have troubles.
Android aside, Ubuntu is far and away the most used Linux desktop. If you look at say, Wikipedia traffic analysis, Ubuntu has over twelve times the web users than the next closest competitor.
What does this mean? As GNOME was Ubuntu's desktop, it means a mass of new users for GNOME. I think this has been one of the main influences of Ubuntu. Linux has been on the server a long time, and people have been mucking with Apache on Linux and the like for a long time. But Ubuntu brought a lot of new users to the Linux desktop, and suddenly GNOME had a much wider user base than it did. This has exposed some bugs in GNOME and freedesktop.org applications, many of which have been patched. I have been mostly following the evince/poppler/cairo portion of this universe, and the influx of Ubuntu users has exposed bugs in all of these programs/libraries, many of which have been patched. Of course, Ubuntu has been moving somewhat away from Gnome to Unity, and it has already begun with Natty Narwhal.
Debian has come a long way from the days when they were struggling to get sarge released. They are back on track schedule-wise.
I am happy that they are going to split free and non-free packages in an easy way. If some Stallman-approved free software distro does a fork of Debian, it can now be a small fork, allowing for greater cooperation between Debian and the fork.
I was worried squeeze was going to be released without my bug fix being applied. But with a few days to spare, they managed to get it in there, excellent!
While I use Ubuntu a lot, one of the many nice things about Debian is how agnostic it is. If you want a bare bones system, install one. If you want a robust system, install a lot of packages. Use Gnome if you want, use KDE if you want, use Gnome with both GTK+ and QT libraries installed, or KDE with GTK+ and QT libraries installed. Or use good old FVWM.
This is my understanding of this as well. The Big Kernel Lock has not been completely removed from the kernel, however, it is now possible to choose a kernel configuration option that will compile a kernel without the BKL. This necessitates a BKL-disabled kernel not being able to use some of the modules which still depend on the BKL. However, none of the core modules depend on the BKL any more, and kernel developers are still working on removing the BKL from the handful of less important modules which depend on the BKL.
Slashdot Mirror
Let's look at a better popularity metric - what percent of which OS hit the servers of Wikipedia in October 2011.
Ubuntu was 0.41% of all Wikipedia traffic with roughly 16.9 million hits in October. Mint was 0.01% of Wikipedia traffic, with roughly half a million hits in October. Ubuntu traffic dwarfs Mint traffic by many multiples.
In terms of the popularity of Linux distros hitting Wikipedia: Android was #1. Ubuntu was #2. Fedora was #3, just barely surpassing SuSE which is #4. Debian was #5. Mandriva was #6. Then comes along Mint at #7. In fact, Mint is barely even beating Kubuntu. Hits to Wikipedia is not a perfect metric, but if anyone knows of a better one I'd like to hear it.
Things can change, and Mint may be gaining popularity, but we have to be realistic about things. I like a lot of things about Debian and Trisquel, but I'm also aware of the fact that for every Debian desktop hitting Wikipedia, there are 20 Ubuntu desktops hitting Wikipedia, including my own. That number goes to 1:30 for Mint to Ubuntu. So no, Mint will not be surpassing Ubuntu any time soon.
I have an app on the Android Market which is not that popular relative to others in its category, I submitted it to Amazon, and they wanted me to tweak it (mostly because of how Facebook's Android-style app is broken more than mine was, Facebook answers one of my Intents badly, a problem many people have had). This particular app has no ads yet, but I wonder who does ads with Kindle Fires. I don't see anything on Google-owned Admob. I don't have an Inmobi account yet, but don't see any mention of Kindle Fire on their web site. I wonder which vendor ad-supported Kindle apps will use.
I use a fairly up to date version of the latest Ubuntu, 11.10, as my desktop.
One thing I dislike is when they complicate things that used to be simple. It used to be if I wanted to switch to another workspace, I would move the mouse to the top of the screen and click which of the other workspaces I wanted. Simple.
Now to do that I have to move my mouse to the left side of the screen. Then a bar pops up on the left side of the screen, then I move to the workspace changer and click on it. It moves to workspace switcher mode. Then I move the mouse across the screen to the workspace I want and click. It complicates something that had been simple. In fact it's changed my behavior in a way I did not want it to - I used to run Firefox and Eclipse in separate workspaces, but as workspace switching is more of a hassle, I now have both open in one workspace.
Aside from things like that, Canonical decided it wanted to do things its own way and has been moving along with a Gnome fork. Which might be OK if it had enough resources. But it does not. for example, here is a bug that I encountered. Orange windows pop up all over your workspace while you're trying to work. It can be quite annoying, as the users comments suggest. It was reported over three weeks ago but a fix has not been released yet. Unity does not have a wide base of developers supporting it like Gnome or KDE do, almost all of the developers doing this type of work are working for Canonical.
I met someone months ago who liked using Google Voice Search on his smartphone. He said the best thing about it was that he didn't have to use the small screen keyboard on his phone. I wouldn't underestimate this as a motive for usage, if it's faster and easier to do it this way, people will use it. My tablet had come with it preinstalled, with a microphone button on the top left, but I never bothered with it until I met him, after I did I tried it out and it worked well. I myself don't use it regularly, if I'm showing the tablet to someone I might show them it can do that, but I haven't used it much otherwise.
I don't see this as an Android killer at all. Today you can download various Android apps, including Google Voice, that can perform tasks by voice activation and recognition. Even if Siri is superior to them, and maybe it is currently, they're good enough in the time being for most people.
I've been developing for the Android Market since May. There are some things to consider. One is some companies don't expect immediate success - lots of banks and such which may have been slow to get a website, have decided to get on smartphones and tablets now. The return for this might take years to come, but they have plenty of money. Why not do it now? They have the money and forecasts show they'll need it eventually, to stay competitive. Sometimes it is existing software. For Android, the Adobe PDF reader was really junky for the past few months. They just released an update, and now the app is much, much better. So they also are protecting their brand.
My capital costs, other than my labor time, are approaching $0.00. Well actually approaching $25.00 as that's what a lifetime Android Market account cost me. I have Admob ads in most of my apps, and average 5 cents a click. So after 500 clicks, I'm in the black. I can go on vacation for two weeks, and come back and see how much I have earned in the interim on Ad clicks. If I wanted to, I could sell apps, or do in-app sales and the like, and maybe I'll try that in the future.
This is something I enjoy doing. I do everything - I look over the entire market, I think up what to do, I write the code, I do the layout, I do the artwork (or get free for commercial ones from findicons.com, iconfinder.com etc.), I decide which user-requested features to implement and which to ignore. I decide whether to work on a new project or improve my existing projects. And then I get the money. Another thing is with work, in this young market, my check is increasing every month. Some of it is my improved products and some of it is people getting new Android devices for the first time.
Some of the things our community knows are relevant here I think. Release early, release often! Are there any Android apps which could load and search Microsoft Access databases on the phone, even if it had no network connection? There wasn't back in June. There still is not one as far as I know other than mine - Panacea Database. I didn't even have to do the Access-specific work, there was a LGPL license library out there I used called Jackcess. My first release took four days - all it did was load the database and iterate through the table rows. You couldn't even iterate backwards, and users said it then looked like junk on smaller phones. But in terms of competition, only one app came close, and for some things (free for an unlimited time, able to handle Access without needing to install a desktop app), it had no competition. Now, 1500 active users later, I have made a lot of improvements, many suggested by users. Which is another thing known by our community - listen to the users, and with a little bit of discrimination, let them have a large hand in determining the roadmap.
Panacea Database was really just an experiment to see if I could successfully port a popular open source Java library to Android. The experiment was an all-around success: I ported it, I sent patches back to the library which helped improve its Access 2010 usage (actually the lead developer took my patch and improved it even more), and lots of users are happy they can do what they want on their Android phones and tablets, and I'm making money on ads. And - I'm helping, in a very small way, an open source Linux platform be more useful. It's a small effort, but combined with a lot of other people like me, it has an effect. The users make out, the library makes out, Admob makes out, Google makes out, the manufacturers make out, the carriers make out, and I make out.
So the map seems pretty open to me. As the Cathedral and Bazaar says, whether its open source or not, scratch your own itch. Think what you'd like to see that is not on Android - or not on it in the way you want. Will people be able to find your app? There's 2 or 3 popular file managers, and those apps are easily findable by searching for file explorer or file manager or whatever. Will your app be as eas
I do Android development, and I had a look at the SDK and emulator when it was released last night. I created an emulator and was testing my applications out on it.
The first thing I noticed is that there are more help screens. I believe they disappear after first use, but they tell users how to navigate around the phone. Or tablet as it may be - that's probably the biggest thing about ICS, it integrates Gingerbread (smartphones) and Honeycomb (tablets) into one OS. I've been getting the hang of Android layout, and it is not so hard once you get used to it, you just stick with the things they recommend - density-independent pixels, scale-independent pixels, objects sized by width and/or height by fill-parent (fill layout container object is in) or wrap-object (make object only as large as it need be), objects or layout containers being assigned by weight. One trick I learned - I start design with the smallest device - WVGA - a small device with a low number of dots per inch. I do a portrait (device held with more height than width), and if I have time a landscape (device held with more width than height) view. Sometimes that is enough, and those two layouts work from the smallest to largest devices. Usually it requires a little tweaking, especially Activity classes that make use of buttons. You take the layouts you made and increase text size, increase the distance between objects and other objects, or objects and the edge of the screen. Some people rethink the design, they use Fragments so that where something that would be done on a small screen with ten screen changes with ten different Activity views, is now done with five screen changes with the same ten different Activity views - you just use Fragments to put two or so Activity views per screen. The ICS smartphone/tablet integration will help in that department, although you can do it to some extent already. In fact Fragments were introduced in Honeycomb (the old tablet Android version, before this ICS tablet/smartphone integration), so some of this is just bringing Honeycomb advances back to the smartphone. Another example of this is the Actionbar - over time the Android designers realized it would help UI consistency, ease of programming etc. if they put a bar on top that let people do things (open an email, go to the next page, whatever). So Actionbar was in Honeycomb, now it is in ICS as well. I should mention there is a compatibility package which allows apps to use many (but not all) of these new features on older phones like Gingerbread, Froyo, Eclair etc.
The next thing I noticed when looking at my apps in the ICS emulator is the new Roboto font. It is said to be able to be a good font for everything from a small, low density to a large screen with a high density. Some of my apps use the Android non-default fonts, and the ones I looked at looked most the same, although there may have been small tweaks I did not notice. And Android lets you use your own fonts.
One of my applications runs in the background, doing a database search while updating a progress bar - and while all of this is happening, an ad is often being loaded as well via the web. It seems to be stalling on something in the ICS emulator, I will do some debugging later to see where it is getting stuck. It may be one of those cases where I was doing something wrong but Android allowed it, and they increased the strictness of things. With ICS's use of Fragments, I can probably just load one ad Fragment when my app starts and put that on every screen anyhow.
Regarding source code, I'm sure it will be released. It will be a month or so before you can buy a Samsung Galaxy Nexus anyhow. The sooner the release the better for me, but Android's open nature beats Windows 8 Mango and iOS any day. I can sit at my Linux box, use open source tools to develop everything, and then just push it out to Android Market (or some other market - Android does not lock phones to their store like Apple does). It is beyond me why Apple punishes developers with an app sto
With the explosion of smartphones and tablets, HP announcing they're leaving the PC business and all the news being how Windows 8's perhaps main feature being tablet (and smartphone) ability, the mobile aspect of Windows 8 is what many people will be looking at.
I hear some Windows fans talk about how Windows 8 is going to come in and eventually dominate smartphones and tablets. However, Apple already has been in the smartphone space since mid-2007, and the tablet space since April 2010. Android has been around since October 2008 in the smartphone space, and Honeycomb came out in February of this year (and a few months earlier things like the early Samsung tabs were coming out). Developers have spent a lot of time learning these platforms and writing code for them. The App Stores and Android Markets are filling up with apps, which are being improved continually by updates based on user feedback. Over 550,000 Android smartphones are being turned on a day. Customers are familiar with the apps on their phone, and how to do various things on their phone or tablet.
What do we he hear from Microsoft? It's all just vaporware so far. Even if developers want to develop for an SDK with no device, there's no SDK out yet. Maybe it will be put out after this conference. Also - Microsoft has been saying a lot of it is HTML 5 and Javascript. I'm happy about that, but it doesn't really exploit all the code and experience for Visual Basic, Silverlight, .NET and so forth. I understand they backpedaled on this a little bit, although HTML 5 and Javascript will still be on it. They're kind of forced to do this - they can't force mobile developers to develop just for Microsoft, they have to hope that the popular iPhone/iPad/Android applications are easy to port to Windows 8 so they can get some applications that way. Microsoft's Windows 7 smartphone/tablet market share is very, very low, so due to the lack of any kind of monopoly strongarm, they're forced to open up a little bit.
The two things Microsoft has going for it is the existing Windows code base, and the ability for people to connect to their PCs, or PC formats (Word, Excel) or Microsoft servers at work (Exchange etc.). As people dump Microsoft PCs for iPads and Android tablets, this lock-in becomes less important. Also insofar as the Windows existing code base, both Apple and Android have had a lot of C++ OpenGL code which used to be primarily dedicated to Windows ported to Apple and Android mobile devices. Miguel de Icaza and company have even brought Mono to Android, so a lot of C# and .NET code can get on Android. As existing Windows code can often be used on Android, this lessens the advantage of Windows 8.
And then there's other things. Microsoft makes money selling Windows 8 to manufacturers like HTC and so forth. Google gives Android away for free, and makes money on the hook-ins it has for Google Maps and so forth. I guess with the Motorola purchase, Google will make some money actually selling the hardware as well. Microsoft has to sell an unwanted product to manufacturers, when a free, popular OS already exists, with a user base of millions, with an Android app market with hundreds of thousands of apps, and many developers working on creating new apps and improving existing ones.
I also wonder how hard it is to develop for Windows 8. For Android, I can download Eclipse on a Linux machine, and the Android SDK, make an Android emulator, develop code in Java (with a few calls to special Android SDK Java classes like Activity), pay Google a one-time lifetime $25 fee to put as many apps on Android Market as I want, and I'm all set. I can even release the app to a non-Market competitor site and save the $25. So the whole shebang costs $25 for life. What will Windows be like? Will I have to pay to get on their app store? Will I have to buy Visual Studio or something? If they don't make things real easy and cheap for developers, they're going to have problems. They might even have problems if they do make things real easy and cheap.
The article says that "The ultimate killer feature that Android and other tablets have failed to replicate is the care Apple took from the start to ensure enough iPhone applications were available that took full advantage of the iPad’s 9.7-inch screen. Today, over 90,000 of the 475,000 applications available online from Apple’s App Store fully exploit the much larger screen size. By contrast, only a paltry 300 or so of the nearly 300,000 apps for Android phones have been fully optimised for the Honeycomb version of the Android operating system developed for tablets—though many of the rest scale up with varying degrees of success."
If this is the "ultimate killer feature" that distinguishes iPads from Android tablets, you'd think there would be some basis for them saying that only 300 Android applications are optimized for Honeycomb. What is that basis? They do not say. An educated guess is that some months ago some unofficial lists of which applications are Honeycomb optimized were created, and at least one of those lists tallies only 300 or so applications. But this means nothing, it is just a random list made by some random person out there, which never claims that it lists all, or even a significant fraction of which applications are Honeycomb optimized. This is a rather paltry basis for what is supposed to be a killer feature.
I have an Android Honeycomb tablet - a Samsung 10.1 Galaxy Tab running Android 3.1 (Honeycomb). I also have two applications, the more popular one of which is optimized for Honeycomb. But that Honeycomb-optimized application of mine is on none of those lists of Honeycomb-optimized applications, it is one of the many applications which are not counted in that "300" number.
I have downloaded many applications for my Honeycomb tablet - so far 100% have been usable in Tablet format. Maybe 5% of the applications are badly optimized - they only use 1/5 or so of the screen space. Another 10% or so are fine, but could probably benefit with more tablet optimization - larger text size, bigger buttons.
The 300 Android to 90000 iPad comparison is ludicrous - my Honeycomb-optimized application is not counted in that 300, and I'm sure many hundreds, or thousands of other Honeycomb-optimized apps are not included. Google already has a lot of features which make tablet development easier, such as Fragments - which is part of the compatibility package, making it doable for even early versions of Android. Ice Cream Sandwich will come out later this year and further ease smartphone/tablet integration.
I should point out that Android is not just playing the following tail lights game. Google TV devices are built on Android as well. Smartphones was the first big market, and then tablets, but who knows what devices Android will target and try to replace in the future?
As this is free software though, there are not winners or losers in the traditional sense. People happy with Thunderbird, Openoffice and KDE can continue using them. It's not like KDE is going away any time soon, even though Unity so dominates the Linux desktop. Unity is still very heavily dependent on the Gnome framework in terms of libraries and applications. Canonical does not have anywhere near the manpower to handle what the Gnome project handles. It's an ecosystem where everything benefits from everything else - Unity benefits from Gnome, KDE benefits from freedesktop.org work by Gnome developers. And vice versa - the fd.o library which handles PDF format is done mostly by KDE-centric developers - only Carlos Garcia Campos is more Gnome-based.
Compared to Windows or MacOS, a Linux desktop/workstation is a dream platform for developers, so it is never going away. The only question is will it break through to the wider public? As Linus says, Linux had done well on the low end with embedded and mobile, and does well on the high end with servers and "cloud" (whatever cloud means). It also is a popular desktop/workstation for IT people. Now, efforts like Ubuntu are trying to make headway into the standard user desktop area. Although they've been more focused on servers, Red Hat and Suse have done a lot of work in the desktop department as well, something which Canonical benefits from.
Alexa shows Wikipedia to be the 7th most popular site on the web. Wikipedia is unique in that it is one of the few top sites not run for profit. Consequently, they allow open traffic analysis of their web traffic to some extent, which I have found very useful. Here is what operating systems hit Wikipedia web sites in June 2011. They have that data for May, April and so forth. I made a chart from the data a few months ago on my blog.
For June in Wikipedia, XP was 36-37% of traffic. Vista was about 13% of traffic. Windows 7 was 29-30% of traffic. Mac plus iPhone plus iPad was 12% of traffic. Android was 1.4% of traffic, and Ubuntu was 0.5% of traffic.
I would guess the majority of Android developers do not own a Honeycomb device. That would mean the emulator should be good. But on its default settings, the emulator is very, very slow. Google "honeycomb emulator" and the top results will mostly be about its slowness. Someone recommended I increase its memory, and that did help out a bit, it's still slow but at least usable.
One of my apps has less than 1% Honeycomb usage, so it is not big on my radar screen. I recently noticed another has over 7% - my app that lets people iterate and search Microsoft Access databases on an Android phone. It's the only reason I revisited the dog-slow emulator and tried the increased memory trick. I saw my app was displaying correctly with Android 3.0, and was displaying correctly on the larger tablet-sized screen. So the primary concern went away - everything worked. I then looked to see if I could improve things for the tablet, and I saw I could, but have not implemented it yet.
There are really two things here with Honeycomb and tablets. One is the OS version. The other is the screen size. With 2.3 and less you usually have smaller screens, Honeycomb often has larger screen sizes. My concerns tend more to be toward dealing with the larger screen sizes properly than implementing some of the neat whiz-bang 3.0 features.
So I think some assertions that are being made about Honeycomb are a bit off-base. If I saw my app displayed poorly on a tablet-sized Honeycomb device, I probably would have fixed it and sent an update out already. It may not be Honeycomb-optimized, but at least I made sure it is Honeycomb compatible. Also, even if I do make those changes that make use of the extra screen space on the typical larger Honeycomb tablet, I don't have an intention at this time of specially marking the app as Honeycomb-optimized. So it still wouldn't count in these surveys, even if I did optimize it for Honeycomb.
For my two existing apps, as well as others I am working on, most of what I think about with tablets is using all that screen space, which is not connected to Honeycomb (version 3 over version 2) per se. That is what most Android app developers will be thinking about more than whatever new features are in 3.1 over 2.3, in my opinion. Honestly, I am currently more engaged with limitations the Android OS has rather than cool new whiz-bang features. For example, there is a 16 bit (i.e. 65536) sized identifier for dex files which I have recently bumped up against. Which you wouldn't easily know about, since their error message for it is pretty vague once you bump into it. I'm more focused on banging my head against this wall right now than the new animation features in 3.0. But different people are focused on different things.
Chess engines have different components. Crafty and Fruit have their own licenses, which are not standard FLOSS. So ripping out the components Crafty does best with the components Fruit does best in violation of their copyright, and then closing it and having it proprietary - this is not rocket science, it's just disregard of licenses.
So why the hell are you suggesting that you need to buy a Mac and all the rest just to get an SSH app that works on the iPad?
There is a $1.99 SSH app for Apple, as I noted in my first paragraph. I said I'd need a Mac if I wanted to write an SSH app for iPad, not buy one.
I develop applications for Android, so I am most familiar with that. Recently I was using someone's non-jailbroken iPad, and wanted to put an free SSH application on it. I didn't find much for the iPad, I found a little more for iPhone apps that worked on iPad. The best one I could get conked out every 500 characters or so, and you'd have to close the app, open it again, and reconnect unless you bought the app for $1.99.
I would write an ad-supported SSH app for iPhone/iPad myself if I didn't need a Mac, a $99 a year App Store account, a knowledge of Objective C, a knowledge of the iPhone API, the ultimate application approval of Apple, and all the other hurdles.
Compare this to the myriad number of free SSH apps for the Android.
I don't have a lot of iPhone/iPad experience, but for the one thing I needed, Apple was app-starved in an area where Android is not.
I also like a piece written by the original developer. He talks about how he had worked on various games which were unsuccessful, and what he learned subsequently and what he then did in preparation so that Battle of Wesnoth would be successful. I thought it was a pretty good short read of how he went from projects that fizzled out to a successful one with millions of downloads.
It is difficult to track users, but one indicator would be to look at the web logs of one of the most popular websites, Wikipedia. In March of 2011, 0.72% of web traffic to Wikipedia came from machines running Ubuntu. Wikipedia received roughly 30 million hits from machines running Ubuntu in March. In contrast, Wikipedia received about 3.4 billion hits from Windows machines in March, 325 million from Macs, 42 million from Androids and so on. Alexa says Wikipedia is the 8th most trafficked site in the world, and other Alexa-like sites put Wikipedia as a top site. It's one of the few (the only?) top sites to open its log analysis statistics like this.
The way I look at this is Canonical/Ubuntu/Unity versus Gnome 3 and the companies and distributions which are issuing Gnome 3 desktops. The best methodology I can come up with to find marketplace penetration is web server logs for major websites. On that basis, Ubuntu currently has more than 13 desktops out there for every 1 of its closest competitor - Fedora. The SuSE's have less then Fedora, Debian less than he SuSE's and so forth.
The result of Canonical's shift is that the majority of non-mobile Linux desktop users were using Gnome 2, and will now be using Unity. They're still using Gnome nuts and bolts though. I am most familiar with the document displayer that both Gnome 3 and Unity use - evince, and the library it uses to render PDFs, poppler. Ubuntu has provided dozens of useful bug reports to these projects, as the large base of users has exposed bugs that people had just not encountered (or reported) before.
I have played with Natty (with Unity) and Gnome 3, and will probably wind up with my main OS on my multi-boot system being Natty running Unity, with a special user on Natty running Gnome 3 compiled from jhbuild (compiled off the latest git commits). A lot of changes on Unity I find less than thrilling such as close window moving to the left side of the window toolbar, and the rest of the window tool bars moving to the top of the screen. For both Unity and Gnome 3, I am unhappy that switching workspaces has gone from a mouse move and a click, to a whole rigmarole of mouse moves and clicks. There's a reason many of these things were the way they were for the last 20 years, or more. I have the command lines and shortcuts to fix some of these things - like shifting left back to right on Unity tool bars - but still.
Regarding "a situation where the systems are so critical that they cannot be restarted yet not important enough for any attempt at getting the startup scripts right" - as I said in my original post, it can be that Monday to Friday are to some extent critical, and Saturday is not.
With regards to test reboots being done - sometimes they can be, but sometimes a new application can be put on a machine which has been around for a year, with many other developers using the machine, many dependencies and so forth. Thus in some situations, people would have to wait until the weekend for the machine to reboot.
Anyhow, this is how it is in some places. People have different opinions about the wisdom of such policies, such as yourself. I've said about as much as there is to say on the topic, anything more and I would be repeating myself.
As far as "those that don't do it on important machines" that you talk of - naturally, this would tend to happen more on non-production, non-critical machines. I am aware that rc/init scripts, if they were ever installed in the first place, can be tested without rebooting. Developers do not always do this though. Dependencies (e.g. making sure your application starts after the database if it depends on the database and needs it running before the particular application is started) are a little more tricky to check but can be dealt with if some thought is put into it by the developer. Thought is not always put into it though.
You ask: "So what's that to get DOZENS then - over one hundred changed init scripts on one machine and a quarter of them with errors in them?" One machine? I am talking about thousands of machines, most of them with a number of (sometimes many) non-system rc/init scripts, touched by hundreds of developers, who are always changing their programs, many of the machines non-production, over the period of time discussed - as long as a machine can manage to stay up - which can be years. As I said in my original post, I am talking about large (financial or otherwise) companies, not small shops.
If you're a sysadmin, what's the largest number of machines you've ever had to support in a developer-heavy environment? If your answer was in the thousands, you would probably be less skeptical. This article says Facebook has 30k servers, Rackspace has 50k servers, Akamai has 60k servers, and Google has over 1000k servers. I can assure you that these companies regularly deal with server problems that the standard sysadmin with dozens of servers to look over is not used to - even a company with one quarter of Facebook's servers is going to have a different sort of quality to their systems setup than a company with 150 or so servers.
As I said before "it depends. If you have a small business, it might not be necessary to do reboot your servers...however...for a financial company"
There is no strawman. It depends on the business. I worked for a company where the number of servers being rebooted were in the thousands. Just for the UNIX servers, just in New York City, once a week we would find one if not several things that would not come up properly due to lack of init/rc scripts. I should modify my original statement slightly though - the problem with rc/init scripts were not solely due to their lack of existence. Sometimes the application-specific init/rc scripts were there - but they would be written wrong. Sometimes they would be written correctly, but would have a dependency on the database, but the application would start before the database would and fail. If machines were never rebooted and were all running for say three years, and then there was a sudden machine room crash, yes, no hyperbole, no strawman argument, there would be dozens of broken init/rc scripts to deal with, amidst all the other problems that might come up if a machine room crashed. This company chose to handle this by regularly rebooting the servers, so the fixes would be put in incrementally. There is another benefit to this - a developer who forgot or messed up on an init/rc script probably still has the application fresh in their mind. If you wait three years, the original developer may be gone, and how to fix it becomes more complex, especially amidst a machine room crashing.
How is one a mistake and dozens a strawman? It is simply a matter of scale, as I alluded to in my original post. Some shops have one developer and a few machines in one machine room, some shops have data centers internationally, with thousands or even tens of thousands of servers, and hundreds, or even thousands of developers. A rare problem in a small shop can come up often in a large shop, quantity transforming quality.
I do have some concerns over this Gnome/Unity fork. Not just how it will effect Gnome but whether Canonical and Ubuntu can handle a significant fork. I am fairly certain bugs like this are a product of the fork, and I wonder who is going to fix them. Canonical has trouble getting good bug reports for packages like cairo, poppler and evince upstream, never mind patching them. I can think of a number of examples, but is the aforementioned bug which was almost certainly probably caused by the fork going to be fixed before 11.04 is released? It is not the only bug caused by the fork either. Who is going to fix these? The fork is small now and these should be easy to fix, who is going to fix them as the fork gets bigger, and Gnome and Unity diverge even more? On the other hand, it's conceivable that Unity will be so awesome, that developers will flock to it, and Gnome shell will to some extent wither away. There are different perspectives, different problems and different possibilities for all of these things. I can tell you right now though that the Unity stuff is breaking stuff in Ubuntu's Gnome, and it is staying broken. Stuff that the Gnome developers will not be fixing either. We'll see what happens...
The answer is it depends on the business. In my experience, it is not IT departments (and thus companies) which reboot machines once a week that have troubles, but companies which have certain machines that never are allowed to go down that have troubles.
What does this mean? As GNOME was Ubuntu's desktop, it means a mass of new users for GNOME. I think this has been one of the main influences of Ubuntu. Linux has been on the server a long time, and people have been mucking with Apache on Linux and the like for a long time. But Ubuntu brought a lot of new users to the Linux desktop, and suddenly GNOME had a much wider user base than it did. This has exposed some bugs in GNOME and freedesktop.org applications, many of which have been patched. I have been mostly following the evince/poppler/cairo portion of this universe, and the influx of Ubuntu users has exposed bugs in all of these programs/libraries, many of which have been patched. Of course, Ubuntu has been moving somewhat away from Gnome to Unity, and it has already begun with Natty Narwhal.
I am happy that they are going to split free and non-free packages in an easy way. If some Stallman-approved free software distro does a fork of Debian, it can now be a small fork, allowing for greater cooperation between Debian and the fork.
I was worried squeeze was going to be released without my bug fix being applied. But with a few days to spare, they managed to get it in there, excellent!
While I use Ubuntu a lot, one of the many nice things about Debian is how agnostic it is. If you want a bare bones system, install one. If you want a robust system, install a lot of packages. Use Gnome if you want, use KDE if you want, use Gnome with both GTK+ and QT libraries installed, or KDE with GTK+ and QT libraries installed. Or use good old FVWM.
This is my understanding of this as well. The Big Kernel Lock has not been completely removed from the kernel, however, it is now possible to choose a kernel configuration option that will compile a kernel without the BKL. This necessitates a BKL-disabled kernel not being able to use some of the modules which still depend on the BKL. However, none of the core modules depend on the BKL any more, and kernel developers are still working on removing the BKL from the handful of less important modules which depend on the BKL.