I've been a long time Linux user and a relatively recent Mac user. One of the things I've recognized for a long time is the severe lack of a package manager for nearly any commercial OS (other than Linux).
And while I like a lot of what the Mac provides from a user perspective, I was a bit dismayed that they didn't have a package manager.
However, after using it for a while, I realized why. For the standard application distribution method they provide, it's largely unnecessary. They really do provide a mechanism that's simple and elegant and self-contained.
The only times I've found myself wishing I had a package manager for OSX is if I'm installing a lot of open-source software... particularly ones through macports and the like.
Or alternatively, I'd sometimes like to know what ancillary files a program installs (eg. extensions to other programs, perhaps user data files, etc.). However in many of those cases, these are things that Linux package manager don't answer either.
All-in-all I have to agree... program distribution the Mac way is far superior.
For anyone wanting to achieve the same thing in Linux, I believe the GnuStep project provides a similar application distribution format.
To re-iterate, though.. it may look like a strange and not very useful method if you're used to Linux. But if you use a Mac for a bit and install a few programs, it all starts to make sense.
Well, we'll have to just agree to have differing styles on that one.
For me, it's a little like if you were trying to go in for a job and focused entirely on why you were better than someone else. Sure it's an approach that might work (I suppose it works in politics). But it's a lot different than focusing on yourself and why you're good on your own. You might be fully qualified in both cases, but I think the latter is just coming from a better place.. and that's something that people (even customers) pick up on.
Exactly! Which is why as a business decision, Java really never made any sense for Sun. They were originally trying to use it as a way to defeat Microsoft... which again was a poor business decision. You don't make a product to outdo your competitor; you make a product that customers want to buy.
While we got a number of nice things out of it, OSS for Sun was merely a symptom of their problems.
It's one of those questions, I think, where there really isn't a clear answer. Just to play devil's advocate here. I like to look at what goes on in China in terms of products (software, tech, etc.).
(I may not be fully informed here, so someone feel free to correct me.. I'm just offering my observations). China may have some copyright laws, but the whole culture appears different there... where piracy is just another part of business.
So it seems like there, you have an increasing amount of innovation centered around how to pirate and distribute things. This makes sense, since creation of the original is difficult, time consuming, and expensive. But trying out new tactics to get people to buy your warez is relatively cheap.
So I actually wonder if they had a stronger copyright enforcement system, if they'd perhaps then be forced to be more creative in product creation.
So perhaps our current copyright system is flawed, but not having a copyright mechanism may be at least equally flawed. Perhaps there's a middle ground (or something entirely new?) that we need.
(Of course, China's issues could also be largely cultural. We in the US do seem to hold individuality and creativity in high regard.)
Around the time of DesqView, there was also this great little known program called (I think) Concurrent PC. Does anyone remember that?
It was the first real "virtual machine" I'd seen for the DOS environment. It only supported 2 VMs, but it was really awesome. It could run lots of stuff in parallel that DesqView couldn't.
Maybe we need another article on DOS multitaskers. =)
Actually, CGA did have a separate palette that had yellow instead of white. And I think cyan and magenta were more green and red in that mode as well. I personally never really liked that mode, and fortunately it didn't appear to be used all that often.
I agree, subversion is not terrible. However, after getting a laptop, I definitely see the advantages of a DVCS. git's not the friendliest of tools, but regardless of the reason, there's a lot of moment out there and supporting tools, so I prefer using git as my DVCS system.
In addition, with git, I also have gotten extremely comfortable with creating a new local branch for any separate task I want to do. This makes my commits much cleaner and virtually eliminates the problem I had with svn where I was working on a feature then got interrupted with a high priority bug.
The git-svn bridge also comes in extremely handy, and is a great way to get the benefits of both worlds.
I have to say though, that I think git not handling directories as real objects is a big step backwards. And Subversion's use of metadatas can also be pretty handy sometimes.
The biggest problem with Flash is it's not an open standard. So it's actually not in any internet user's long term interests to use flash.
Although you are correct, there just isn't any good alternative (HTML5 really isn't the right approach either, and as you say, doesn't even address many of the issues that people who use Flash need).
What I'm surprised about is how Google hasn't seen this and is actually using the whole "we support flash" campaign to compete with Apple.
So yes, I personally agree with Apple and think Flash should die. But, when you need to get something done that HTML just can't do, at least it's better than Java.
Well said! I think one of the foundational basics of math is teaching people logic and causal relationships. It seems like so many people don't understand simple if/then relationships.
I'd like to add, for all the "Apple is evil" people out there... Apple's one of the few companies that seems to go through quite a bit to make sure you're aware of *any* changes to their license agreements.
I'll get messages when I log into the online service saying I have to agree by a certain date to continue using the service. Or I'll get a notice when I install an app/update about the license (or change in license). iTunes does this every time they add a new service (like Genius or Ping).
Whether you like their added service or not is a separate issue. The fact is they do much more to ensure that I'm aware of the license changes than I've seen from any other company. And most of the time when I look at those licenses they're just assuring me that they're not taking personally identifiable information; the information they do take will only be used for said service; and they'll only take that information if I enable the new service.
The only other thing they could do to make it really useful is perhaps have a "plain english translation" of the changes.
I think this is situation actually exemplifies what the original post was talking about. You as the developer heard "date" and interpreted that as particular a "date-base formated date field." Whereas the user really wanted something a bit different.
Closing/that/ gap is the challenge.
FWIW OmniFocus does support various notations like today/tomorrow/1d/etc to make things easier to enter.
I'm not saying any of that is easy fool-proof. But I think the original article is trying to highlight exactly this sort of gap between developer and user.
While there is _some_ truth to Android not being as open as Google would lay claim to, it's certainly more open than iOS is, and when it comes t getting an app out, Android is the platform benchmark for letting anyone release an app.
The problem I have is exactly the fact that Google is trying to push Android as open. Yes Android itself is open. But Android-on-your-cell-phone is not necessarily open... it's up to the vendor to decide.
Regardless of what you think of Apple's openness (or lack of), they have always been upfront about it.
Agreed... OSX is certainly one of the best desktops I've seen (unix backend or not).
I'd like to add... one of the big benefits I saw to Linux was the package management interfaces (rpms or dpkg or whatever.. they're all better than any commercial unix I've seen).
While it was an adjustment for me to come to terms with Apple's.app model, I've grown to see a lot of great benefits to this model. In many cases it really obviates the need to have any sort of complex package management. The added benefit is that even on the command-line, you can see everything that an app uses/needs very easily.
I'll start by saying I'm a iPhone developer and haven't yet looked at Android development. But Ronin Developer's comments seem well balanced and consistent with what I've read.
I'd like to add that from an academic standpoint, I rather like Objective-C and the Cocoa API. It's approach to objects and object interaction is the best/cleanest I've seen. The documentation is quite nice. (I personally have always hit a wall of complexity for even moderately sized projects every time I used C++ or Java... but I don't seem to have that issue with Obj-C). If nothing else, I think this will help all programs in seeing (and using) a well developed API.
You can get around the $99/year developers fee if you start with desktop development or if you just program for the simulator. I did find iPhone development to be a nice start into the API, though, as it's a bit simpler (due to there being fewer options than the Desktop).
The practical difference between a single "unified updater" nagging about an update every other day, and a different "per-app" nagging about an update every other day, is not really significant. Either way, you end up getting nagged, it's just the nagging has a different skin each time.
Again... the problem with multiple updates is that you get nagged simultaneously or one right after the other.
Basically, the "no news is good news" principle is a cornerstone of UNIX tool implementation and, more importantly in the context of this discussion, describes the fundamental core of your argument.
No, that's the cornerstone of Unix command line tools. And is specifically NOT the core of any of my arguments. It's the cornerstone of the argument you think I'm arguing even though I've repeatedly said otherwise. I do highly suggest you read "The UNIX Philosophy" by Mike Gancarz.
But in real terms the difference between "double clicking"/"running rpm -ivh" and "clicking next a few more times" is not large.
For single program one-off situations, that may be the case. But again I don't think that was ever the argument.
Anyway, I've enjoyed debating with you, but I think this thread has lost it's focus.
Not really. The updater apps are already written, and getting notifications every other day for different apps is really no different whether it comes from an individual application or a central tool.
That's not true. With a single tool implementation like PackageKit, I get a single notification that there are many updates. In a "typical" windows setup, I'll get popups and notifications from all sorts of apps where I just have to keep clicking through them. Think of all the users out there that don't immediately update software when a notification comes in. Just recently, I got continuous notifications from Adobe Acrobat Reader on Windows nagging me about a new update. Then when I finally did install it, it kept reminding me I had to reboot. I really didn't want to at the time, I was busy with actual work and don't like rebooting often. The software, despite what they're saying still works. So I don't want the nag. And if you magnify that issue to all apps installed, it'd be just a horrible pop-up fest of "update me now" dialogs.
To pick one rather obvious point, when the typical end user runs some program and gets no response or feedback, they assume it hasn't done anything and/or failed. The UNIX Philosophy is pretty much the complete opposite.
Yes, there's some fundamental differences about what Unix command-line assumes about the user and what most people deem appropriate for "the desktop". But, you'll notice most of the tenets of the Unix Philosophy say nothing of the example you mention. The only one that comes close is the one about making every program a filter and that's down at #9.
The lessons in the book are still important to understand even in GUIs. The reason the author talks about "captive user interfaces" is because a GUI does not specifically "have" to be captive. And it's perfectly possible to write captive command line programs.
I'll give you a great example that's still a problem on Windows and I believe Linux. I think however, that Macs do this correctly.
If you move a whole bunch of files from one directory to another. As soon as there's any sort of issue (eg. a file is marked read-only or the file will overwrite an existing one), then the copy operation stops as it prompts the user. The concept of the "captive user interface" is still there. Well if I'm moving a large enough data set, that operation could take hours. I want to be able to leave it and come back and expect it to either (1) be done or (2)do as much as it can and have a checklist of things i should manually acknowledge. The typical "Yes, Yes All, No, No All" options are really dumb and not sufficient. (Ideally the UI should also allow me to treat this as an atomic operation, but that's another story).
As with Linux, it depends on the developer to package it properly.
You're ignoring my comments again. On Windows, a "setup.exe" is perfectly "proper". It's the defacto standard. On Fedora, sure it's "possible" but it's really not proper. It's not how most apps are installed.
If you want to batch/script unattended installs, it's expected you'll be doing it in a managed environment, and thus have the requisite knowledge (or be prepared to learn).
And that's exactly my point. It's something that's difficult to to do in Windows. And not difficult to do in Linux. I'm not talking about teaching someone who barely knows how to center text in MSOffice how to do system administration. I'm talking about how much effort it is for someone with reasonable administrative experience being able to figure out and implement.
With rpms, you learn a few options like "-e, -U" etc and you can get through. On Windows, what do I have to do? Install an Exchange server or something? And only if I'm lucky if the app I wanted had an appropriate MSI will I be able to do it? It's completely not the same level of work or effort.
By putting most of the content in searchable formats (probably XML), and probably by following some kind of standards.
Well that's part of the problem. Flash applications don't have any standard of the sort. HTML for better or worse is an open standard. And by making websites that conform you automatically get searchability. Flash apps on the other hand require the user then to make the choice to be open. And when presented with that option, honestly I think most users and businesses will not even consider it.
Or in other words, the onus isn't on Google to find a way to index their site, but on the site owners to make sure that whatever they do, they're still in Google.
What you say there is logical. But as we can see in even the online advertising case I don't think businesses and web developers will do what makes sense in those cases.
Businesses especially like to choose flash because of the glitz. Then they figure out how to do SEO on top of that. They don't really think in terms of "if my content is good, they will come."
Also if you look at the mobile market, search is rather terrible in the application space, even on Android. I mean just finding the right application is hard, let alone searching for content within the apps. I'm not saying Google can't do it. But they're not right now. And this is a huge growing market for content. (both as standalone apps and web-based apps). (there's a great article that talks about this issue; I can't find it at the moment, though).
How can a Flash app be design to allow for search? The guys at google are smart, I guess they'd figure something out. But it really does change things quite a bit. And makes it much easier to obscure information.
I don't think Google really needs to go out of its way to index content nowadays, as if you're not in Google then you don't exist for a lot of the web's users...
That's true today. But with the current "battle for flash" on the mobile front, that could really change things. If Flash did not have anyone opposing it, many developers would (and currently are) choosing Flash as their platform of choice.
With the mobile market as large as it is and continuing to grow, that's going to be a significant portion of the web. And that'll be a significant portion that will be mostly invisible to search. I don't think it's something Google should readily dismiss.... unless they already have some killer Flash search technology.
Sure, but where's the motivation ? The practical results will be little different from today, and chances are fair to good third party vendors won't use it anyway.
I already addressed the motivation... several times.
The "stable" part is what's missing from OSS systems, as updating one part nearly always leads to a cascade of dependency updates as well, because ABI stability in the OSS world is, at best, an afterthought.
Agreed. OSS does need better care in that area. Though to be fair, I think there's far more dependency in OSS apps than commercial apps.
The "interactive" part is typing 'yum install blah', or 'rpm -ivh blah'. That's the equivalent of running an MSI and hitting next a few times. Both are interactive tasks (ie: not automated, not transparent, not managed by a third party).
I don't think you understand what people mean by "required interactivity". If you have the time, I suggest read the "Unix Philosophy". The author describes the issue in point as "Captive User Interfaces". These are interfaces that _require_ the user to sit there and baby sit an application. Yes, certainly typing "yum install..." requires an action by the user. However, a simple "yum -y install..." will not _require_ further input from the user (unless of course there's some sort of failure). Contrarily, _every_ graphical installer I've ever used (Windows, Linux, Apple, etc.) always requires the user to sit through various choices and mixing in long operations with babysitting "click next to continue" type operations.
If an operation is going to take a while I want to make my choices up front, walk away and be able to come back and have it be done. That's the difference between interactivity and non-interactivity. Don't confuse this with action vs non-action.
The inherent problem with a graphical installer is that even if you reduce it to a single "OK" click in the beginning of the app, it doesn't solve the problem. The reason is when I have to do a batch operation, eg because I'm installing multiple apps, I want to just "set it up and go".
RPMs are inherently scriptable and I have this ability.
And, similarly, you can do batch and unattended installations on Windows.
Again... theoretically possible is one thing. Practical possibility is another. Can I take most of the software I'd want to install on Windows and do this? I know I certainly can for Linux.
Tools that I typically want on a Windows system would be Firefox, putty, 7-zip, Acrobat Reader. Perhaps the Gimp and OpenOffice. In a business setting MS Office of course. Can I get all those programs to install non-interactively on Windows? I've seen technotes for how to do this with MSOffice. But honestly it's way more work than it was worth to me. To me it wasn't both practical AND possible.
As with Linux apps, it's utterly dependent on the developer (or someone else) to package it properly. With that said, most MSIs should come with an "unattended install" option. Try running 'someinstaller.msi/?'.
Again, you've ignored my statement. Of course some developer could do something wrong. That always happens. But that's not what I'm talking about. I'm talking about the usual case of (theoretically) competent developers following the documentation and design of the tools available to them. With RPMs it actually is entirely wrong to have an interactive RPM. While someone may be able to figure it out, there's certainly nothing in the documentation that tells you how to do that. And unless I am mistaken, it is _NOT_ wrong to create an MSI that requires interactivity. I seem to recall seeing in Microsoft's documentation them describing just how you can do it. And making it entirely a developer choice.
I'm not making a value judgement on Microsoft's case for MSIs. But I am pointing out the inherent difference in the system and what that means to me when I have to manage Microsoft systems.
The practical difference here is small. Certainly (and clearly) not enough for software developers to funnel all their software distribution through Microsoft (assuming the legal system would even allow them to).
You're just being silly there. Of course that approach would never work. People wouldn't go for it and Microsoft wouldn't want to deal with the hassle. The approach is just what the OSS people did with yum for example. Provide a software updater that others can hook into.
Take Adobe's acrobat reader for example. All I had to do was install their.repo file and now I can get acrobat reader updates along with everything else in the system. Simpler for Adobe, cause they don't have to write an updater tool. And less hassle for the user cause I don't get a separate update notification for every single app I have installed.
There's nothing stopping Apple or Microsoft from implementing those. It's not/that/ difficult to do. A 3rd party could implement it of course but what's their motivation? It's not something that users would pay for and it's not something developers would necessarily pay for. It is something however that directly affects the "user experience" of the operating system. So it makes most sense for Apple and Microsoft to develop.
(re: DLL-hell)
Really?
As a common problem ? Absolutely.
But as I understand it Windows apps solved this problem by simply including dlls in their own app directories. Or did they find a different solution? As a user I don't particularly care as long as everything works. Macs do this and I actually find it a very comfortable solution to the problem. Don't want an app anymore, delete it. No "cruft" lying around (less than Windows anyway). And when I do install an app I don't have to think about what the heck it depends on.
But from a technology standpoint, I like the sharing that RPM makes possible. Though I do agree it's a bit of work to keep things in sync in the back-end. However, I must say I think the public Linux repos/distros have gotten things a lot cleaner in recent years.
Packaging system has nothing to do with non-interactive installation.
I think you need to complain to the poster I was replying to. He was the one using automated installation as an example of why a packaging system is good.
It may be unnecessary to have a packaging system with a non-interactive installation. But the important thing I think it does provide is a unified way of installing/upgrading/tracking across all software on the system (also non-interactively).
The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.
Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.
It's been a while since I've used Debian, but the last time I did, I found it to be one of the most horribly interactive installation systems ever. To be fair, it's quite possible I chose the wrong installation option.
Redhat/Fedora-based systems however have never been interactive or required interactivity at the RPM level.
Sure yum/can/ be interactive. But it's easy enough to tell it to just install what it needs to. Basically what I mean is that I can easily install/upgrade software in batch across a number of systems relatively easily on Redhat-based systems. This is entirely different from a graphical installer that absolutely and always requires me to sit in front of it and click "OK" to move the dialog forward.
I've read things that imply non-interactive installs is possible in Windows. But the from what I've gathered it takes quite a bit of effort to setup an environment that allows for that.On top of that MSIs/may/ allow for non-interactivity but they also may not. It's really up to whoever
Well Windows apps did for a while have the DLL hell issue. Not sure if they still do.
But more important I think is the unified package distribution system. packagekit for gnome for example... I only need to get one notice from it that I have software updates. Whereas go to any presentation running a Windows laptop and you'll inevitably see at least one software update, though sometimes several from different apps during the presentation.
What I'm questioning is not the application providers, but the OS vendors lack of inclusion of a common platform for these issues.
Even Apple has this problem when you have lots of 3rd party apps.
Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.
Don't forget rpm/deb and the entire package management and distribution infrastructure.
It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.
Even cygwin doesn't use it in it's distribution, though I understand they have their reasons. But then what reason does projects like macports have to not use real package management?
The open source version solves the technical problems Apple may have with Flash.
But actually I think they're right in wanting Flash dead. It's true that it's a closed propriety format, and it will lead to a closed web. Perhaps they're doing it for their own selfish reasons. But in this case, I think those reasons coincide with what people want in the long term.
I'm just surprised Google hasn't realized the danger that flash poses. It'll completely demolish their search capabilities.
Slashdot Mirror
I've been a long time Linux user and a relatively recent Mac user. One of the things I've recognized for a long time is the severe lack of a package manager for nearly any commercial OS (other than Linux).
And while I like a lot of what the Mac provides from a user perspective, I was a bit dismayed that they didn't have a package manager.
However, after using it for a while, I realized why. For the standard application distribution method they provide, it's largely unnecessary. They really do provide a mechanism that's simple and elegant and self-contained.
The only times I've found myself wishing I had a package manager for OSX is if I'm installing a lot of open-source software... particularly ones through macports and the like.
Or alternatively, I'd sometimes like to know what ancillary files a program installs (eg. extensions to other programs, perhaps user data files, etc.). However in many of those cases, these are things that Linux package manager don't answer either.
All-in-all I have to agree... program distribution the Mac way is far superior.
For anyone wanting to achieve the same thing in Linux, I believe the GnuStep project provides a similar application distribution format.
To re-iterate, though.. it may look like a strange and not very useful method if you're used to Linux. But if you use a Mac for a bit and install a few programs, it all starts to make sense.
Well, we'll have to just agree to have differing styles on that one.
For me, it's a little like if you were trying to go in for a job and focused entirely on why you were better than someone else. Sure it's an approach that might work (I suppose it works in politics). But it's a lot different than focusing on yourself and why you're good on your own. You might be fully qualified in both cases, but I think the latter is just coming from a better place.. and that's something that people (even customers) pick up on.
Exactly! Which is why as a business decision, Java really never made any sense for Sun. They were originally trying to use it as a way to defeat Microsoft... which again was a poor business decision. You don't make a product to outdo your competitor; you make a product that customers want to buy.
While we got a number of nice things out of it, OSS for Sun was merely a symptom of their problems.
It's one of those questions, I think, where there really isn't a clear answer. Just to play devil's advocate here. I like to look at what goes on in China in terms of products (software, tech, etc.).
(I may not be fully informed here, so someone feel free to correct me.. I'm just offering my observations). China may have some copyright laws, but the whole culture appears different there... where piracy is just another part of business.
So it seems like there, you have an increasing amount of innovation centered around how to pirate and distribute things. This makes sense, since creation of the original is difficult, time consuming, and expensive. But trying out new tactics to get people to buy your warez is relatively cheap.
So I actually wonder if they had a stronger copyright enforcement system, if they'd perhaps then be forced to be more creative in product creation.
So perhaps our current copyright system is flawed, but not having a copyright mechanism may be at least equally flawed. Perhaps there's a middle ground (or something entirely new?) that we need.
(Of course, China's issues could also be largely cultural. We in the US do seem to hold individuality and creativity in high regard.)
Around the time of DesqView, there was also this great little known program called (I think) Concurrent PC. Does anyone remember that?
It was the first real "virtual machine" I'd seen for the DOS environment. It only supported 2 VMs, but it was really awesome. It could run lots of stuff in parallel that DesqView couldn't.
Maybe we need another article on DOS multitaskers. =)
Actually, CGA did have a separate palette that had yellow instead of white. And I think cyan and magenta were more green and red in that mode as well. I personally never really liked that mode, and fortunately it didn't appear to be used all that often.
I agree, subversion is not terrible. However, after getting a laptop, I definitely see the advantages of a DVCS. git's not the friendliest of tools, but regardless of the reason, there's a lot of moment out there and supporting tools, so I prefer using git as my DVCS system.
In addition, with git, I also have gotten extremely comfortable with creating a new local branch for any separate task I want to do. This makes my commits much cleaner and virtually eliminates the problem I had with svn where I was working on a feature then got interrupted with a high priority bug.
The git-svn bridge also comes in extremely handy, and is a great way to get the benefits of both worlds.
I have to say though, that I think git not handling directories as real objects is a big step backwards. And Subversion's use of metadatas can also be pretty handy sometimes.
The biggest problem with Flash is it's not an open standard. So it's actually not in any internet user's long term interests to use flash.
Although you are correct, there just isn't any good alternative (HTML5 really isn't the right approach either, and as you say, doesn't even address many of the issues that people who use Flash need).
What I'm surprised about is how Google hasn't seen this and is actually using the whole "we support flash" campaign to compete with Apple.
So yes, I personally agree with Apple and think Flash should die. But, when you need to get something done that HTML just can't do, at least it's better than Java.
Well said! I think one of the foundational basics of math is teaching people logic and causal relationships. It seems like so many people don't understand simple if/then relationships.
I'd like to add, for all the "Apple is evil" people out there... Apple's one of the few companies that seems to go through quite a bit to make sure you're aware of *any* changes to their license agreements.
I'll get messages when I log into the online service saying I have to agree by a certain date to continue using the service. Or I'll get a notice when I install an app/update about the license (or change in license). iTunes does this every time they add a new service (like Genius or Ping).
Whether you like their added service or not is a separate issue. The fact is they do much more to ensure that I'm aware of the license changes than I've seen from any other company. And most of the time when I look at those licenses they're just assuring me that they're not taking personally identifiable information; the information they do take will only be used for said service; and they'll only take that information if I enable the new service.
The only other thing they could do to make it really useful is perhaps have a "plain english translation" of the changes.
I think this is situation actually exemplifies what the original post was talking about. You as the developer heard "date" and interpreted that as particular a "date-base formated date field." Whereas the user really wanted something a bit different.
Closing /that/ gap is the challenge.
FWIW OmniFocus does support various notations like today/tomorrow/1d/etc to make things easier to enter.
I'm not saying any of that is easy fool-proof. But I think the original article is trying to highlight exactly this sort of gap between developer and user.
While there is _some_ truth to Android not being as open as Google would lay claim to, it's certainly more open than iOS is, and when it comes t getting an app out, Android is the platform benchmark for letting anyone release an app.
The problem I have is exactly the fact that Google is trying to push Android as open. Yes Android itself is open. But Android-on-your-cell-phone is not necessarily open... it's up to the vendor to decide.
Regardless of what you think of Apple's openness (or lack of), they have always been upfront about it.
Agreed... OSX is certainly one of the best desktops I've seen (unix backend or not).
I'd like to add... one of the big benefits I saw to Linux was the package management interfaces (rpms or dpkg or whatever.. they're all better than any commercial unix I've seen).
While it was an adjustment for me to come to terms with Apple's .app model, I've grown to see a lot of great benefits to this model. In many cases it really obviates the need to have any sort of complex package management. The added benefit is that even on the command-line, you can see everything that an app uses/needs very easily.
I'll start by saying I'm a iPhone developer and haven't yet looked at Android development. But Ronin Developer's comments seem well balanced and consistent with what I've read.
I'd like to add that from an academic standpoint, I rather like Objective-C and the Cocoa API. It's approach to objects and object interaction is the best/cleanest I've seen. The documentation is quite nice. (I personally have always hit a wall of complexity for even moderately sized projects every time I used C++ or Java... but I don't seem to have that issue with Obj-C). If nothing else, I think this will help all programs in seeing (and using) a well developed API.
You can get around the $99/year developers fee if you start with desktop development or if you just program for the simulator. I did find iPhone development to be a nice start into the API, though, as it's a bit simpler (due to there being fewer options than the Desktop).
That would be awesome! Especially if we could cover the planet with that. It'll make future archeologists jobs much easier!
It's a good goal to not be killed in a Volvo. But what about those being killed by Volvos?
The practical difference between a single "unified updater" nagging about an update every other day, and a different "per-app" nagging about an update every other day, is not really significant. Either way, you end up getting nagged, it's just the nagging has a different skin each time.
Again... the problem with multiple updates is that you get nagged simultaneously or one right after the other.
Basically, the "no news is good news" principle is a cornerstone of UNIX tool implementation and, more importantly in the context of this discussion, describes the fundamental core of your argument.
No, that's the cornerstone of Unix command line tools. And is specifically NOT the core of any of my arguments. It's the cornerstone of the argument you think I'm arguing even though I've repeatedly said otherwise. I do highly suggest you read "The UNIX Philosophy" by Mike Gancarz.
But in real terms the difference between "double clicking"/"running rpm -ivh" and "clicking next a few more times" is not large.
For single program one-off situations, that may be the case. But again I don't think that was ever the argument.
Anyway, I've enjoyed debating with you, but I think this thread has lost it's focus.
Not really. The updater apps are already written, and getting notifications every other day for different apps is really no different whether it comes from an individual application or a central tool.
That's not true. With a single tool implementation like PackageKit, I get a single notification that there are many updates. In a "typical" windows setup, I'll get popups and notifications from all sorts of apps where I just have to keep clicking through them. Think of all the users out there that don't immediately update software when a notification comes in. Just recently, I got continuous notifications from Adobe Acrobat Reader on Windows nagging me about a new update. Then when I finally did install it, it kept reminding me I had to reboot. I really didn't want to at the time, I was busy with actual work and don't like rebooting often. The software, despite what they're saying still works. So I don't want the nag. And if you magnify that issue to all apps installed, it'd be just a horrible pop-up fest of "update me now" dialogs.
To pick one rather obvious point, when the typical end user runs some program and gets no response or feedback, they assume it hasn't done anything and/or failed. The UNIX Philosophy is pretty much the complete opposite.
Yes, there's some fundamental differences about what Unix command-line assumes about the user and what most people deem appropriate for "the desktop". But, you'll notice most of the tenets of the Unix Philosophy say nothing of the example you mention. The only one that comes close is the one about making every program a filter and that's down at #9.
The lessons in the book are still important to understand even in GUIs. The reason the author talks about "captive user interfaces" is because a GUI does not specifically "have" to be captive. And it's perfectly possible to write captive command line programs.
I'll give you a great example that's still a problem on Windows and I believe Linux. I think however, that Macs do this correctly.
If you move a whole bunch of files from one directory to another. As soon as there's any sort of issue (eg. a file is marked read-only or the file will overwrite an existing one), then the copy operation stops as it prompts the user. The concept of the "captive user interface" is still there. Well if I'm moving a large enough data set, that operation could take hours. I want to be able to leave it and come back and expect it to either (1) be done or (2)do as much as it can and have a checklist of things i should manually acknowledge. The typical "Yes, Yes All, No, No All" options are really dumb and not sufficient. (Ideally the UI should also allow me to treat this as an atomic operation, but that's another story).
As with Linux, it depends on the developer to package it properly.
You're ignoring my comments again. On Windows, a "setup.exe" is perfectly "proper". It's the defacto standard. On Fedora, sure it's "possible" but it's really not proper. It's not how most apps are installed.
If you want to batch/script unattended installs, it's expected you'll be doing it in a managed environment, and thus have the requisite knowledge (or be prepared to learn).
And that's exactly my point. It's something that's difficult to to do in Windows. And not difficult to do in Linux. I'm not talking about teaching someone who barely knows how to center text in MSOffice how to do system administration. I'm talking about how much effort it is for someone with reasonable administrative experience being able to figure out and implement.
With rpms, you learn a few options like "-e, -U" etc and you can get through. On Windows, what do I have to do? Install an Exchange server or something? And only if I'm lucky if the app I wanted had an appropriate MSI will I be able to do it? It's completely not the same level of work or effort.
Cl
By putting most of the content in searchable formats (probably XML), and probably by following some kind of standards.
Well that's part of the problem. Flash applications don't have any standard of the sort. HTML for better or worse is an open standard. And by making websites that conform you automatically get searchability. Flash apps on the other hand require the user then to make the choice to be open. And when presented with that option, honestly I think most users and businesses will not even consider it.
Or in other words, the onus isn't on Google to find a way to index their site, but on the site owners to make sure that whatever they do, they're still in Google.
What you say there is logical. But as we can see in even the online advertising case I don't think businesses and web developers will do what makes sense in those cases.
Businesses especially like to choose flash because of the glitz. Then they figure out how to do SEO on top of that. They don't really think in terms of "if my content is good, they will come."
Also if you look at the mobile market, search is rather terrible in the application space, even on Android. I mean just finding the right application is hard, let alone searching for content within the apps. I'm not saying Google can't do it. But they're not right now. And this is a huge growing market for content. (both as standalone apps and web-based apps). (there's a great article that talks about this issue; I can't find it at the moment, though).
Not if the Flash is well-designed
How can a Flash app be design to allow for search? The guys at google are smart, I guess they'd figure something out. But it really does change things quite a bit. And makes it much easier to obscure information.
I don't think Google really needs to go out of its way to index content nowadays, as if you're not in Google then you don't exist for a lot of the web's users...
That's true today. But with the current "battle for flash" on the mobile front, that could really change things. If Flash did not have anyone opposing it, many developers would (and currently are) choosing Flash as their platform of choice.
With the mobile market as large as it is and continuing to grow, that's going to be a significant portion of the web. And that'll be a significant portion that will be mostly invisible to search. I don't think it's something Google should readily dismiss.... unless they already have some killer Flash search technology.
Sure, but where's the motivation ? The practical results will be little different from today, and chances are fair to good third party vendors won't use it anyway.
I already addressed the motivation... several times.
The "stable" part is what's missing from OSS systems, as updating one part nearly always leads to a cascade of dependency updates as well, because ABI stability in the OSS world is, at best, an afterthought.
Agreed. OSS does need better care in that area. Though to be fair, I think there's far more dependency in OSS apps than commercial apps.
The "interactive" part is typing 'yum install blah', or 'rpm -ivh blah'. That's the equivalent of running an MSI and hitting next a few times. Both are interactive tasks (ie: not automated, not transparent, not managed by a third party).
I don't think you understand what people mean by "required interactivity". If you have the time, I suggest read the "Unix Philosophy". The author describes the issue in point as "Captive User Interfaces". These are interfaces that _require_ the user to sit there and baby sit an application. Yes, certainly typing "yum install..." requires an action by the user. However, a simple "yum -y install ..." will not _require_ further input from the user (unless of course there's some sort of failure). Contrarily, _every_ graphical installer I've ever used (Windows, Linux, Apple, etc.) always requires the user to sit through various choices and mixing in long operations with babysitting "click next to continue" type operations.
If an operation is going to take a while I want to make my choices up front, walk away and be able to come back and have it be done. That's the difference between interactivity and non-interactivity. Don't confuse this with action vs non-action.
The inherent problem with a graphical installer is that even if you reduce it to a single "OK" click in the beginning of the app, it doesn't solve the problem. The reason is when I have to do a batch operation, eg because I'm installing multiple apps, I want to just "set it up and go".
RPMs are inherently scriptable and I have this ability.
And, similarly, you can do batch and unattended installations on Windows.
Again... theoretically possible is one thing. Practical possibility is another. Can I take most of the software I'd want to install on Windows and do this? I know I certainly can for Linux.
Tools that I typically want on a Windows system would be Firefox, putty, 7-zip, Acrobat Reader. Perhaps the Gimp and OpenOffice. In a business setting MS Office of course. Can I get all those programs to install non-interactively on Windows? I've seen technotes for how to do this with MSOffice. But honestly it's way more work than it was worth to me. To me it wasn't both practical AND possible.
As with Linux apps, it's utterly dependent on the developer (or someone else) to package it properly. With that said, most MSIs should come with an "unattended install" option. Try running 'someinstaller.msi /?'.
Again, you've ignored my statement. Of course some developer could do something wrong. That always happens. But that's not what I'm talking about. I'm talking about the usual case of (theoretically) competent developers following the documentation and design of the tools available to them. With RPMs it actually is entirely wrong to have an interactive RPM. While someone may be able to figure it out, there's certainly nothing in the documentation that tells you how to do that. And unless I am mistaken, it is _NOT_ wrong to create an MSI that requires interactivity. I seem to recall seeing in Microsoft's documentation them describing just how you can do it. And making it entirely a developer choice.
I'm not making a value judgement on Microsoft's case for MSIs. But I am pointing out the inherent difference in the system and what that means to me when I have to manage Microsoft systems.
The practical difference here is small. Certainly (and clearly) not enough for software developers to funnel all their software distribution through Microsoft (assuming the legal system would even allow them to).
You're just being silly there. Of course that approach would never work. People wouldn't go for it and Microsoft wouldn't want to deal with the hassle. The approach is just what the OSS people did with yum for example. Provide a software updater that others can hook into.
Take Adobe's acrobat reader for example. All I had to do was install their .repo file and now I can get acrobat reader updates along with everything else in the system. Simpler for Adobe, cause they don't have to write an updater tool. And less hassle for the user cause I don't get a separate update notification for every single app I have installed.
There's nothing stopping Apple or Microsoft from implementing those. It's not /that/ difficult to do. A 3rd party could implement it of course but what's their motivation? It's not something that users would pay for and it's not something developers would necessarily pay for. It is something however that directly affects the "user experience" of the operating system. So it makes most sense for Apple and Microsoft to develop.
(re: DLL-hell)
Really?
As a common problem ? Absolutely.
But as I understand it Windows apps solved this problem by simply including dlls in their own app directories. Or did they find a different solution? As a user I don't particularly care as long as everything works. Macs do this and I actually find it a very comfortable solution to the problem. Don't want an app anymore, delete it. No "cruft" lying around (less than Windows anyway). And when I do install an app I don't have to think about what the heck it depends on.
But from a technology standpoint, I like the sharing that RPM makes possible. Though I do agree it's a bit of work to keep things in sync in the back-end. However, I must say I think the public Linux repos/distros have gotten things a lot cleaner in recent years.
Packaging system has nothing to do with non-interactive installation.
I think you need to complain to the poster I was replying to. He was the one using automated installation as an example of why a packaging system is good.
It may be unnecessary to have a packaging system with a non-interactive installation. But the important thing I think it does provide is a unified way of installing/upgrading/tracking across all software on the system (also non-interactively).
The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.
Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.
It's been a while since I've used Debian, but the last time I did, I found it to be one of the most horribly interactive installation systems ever. To be fair, it's quite possible I chose the wrong installation option.
Redhat/Fedora-based systems however have never been interactive or required interactivity at the RPM level.
Sure yum /can/ be interactive. But it's easy enough to tell it to just install what it needs to. Basically what I mean is that I can easily install/upgrade software in batch across a number of systems relatively easily on Redhat-based systems. This is entirely different from a graphical installer that absolutely and always requires me to sit in front of it and click "OK" to move the dialog forward.
I've read things that imply non-interactive installs is possible in Windows. But the from what I've gathered it takes quite a bit of effort to setup an environment that allows for that.On top of that MSIs /may/ allow for non-interactivity but they also may not. It's really up to whoever
Well Windows apps did for a while have the DLL hell issue. Not sure if they still do.
But more important I think is the unified package distribution system. packagekit for gnome for example... I only need to get one notice from it that I have software updates. Whereas go to any presentation running a Windows laptop and you'll inevitably see at least one software update, though sometimes several from different apps during the presentation.
What I'm questioning is not the application providers, but the OS vendors lack of inclusion of a common platform for these issues.
Even Apple has this problem when you have lots of 3rd party apps.
Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.
Don't forget rpm/deb and the entire package management and distribution infrastructure.
It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.
Even cygwin doesn't use it in it's distribution, though I understand they have their reasons. But then what reason does projects like macports have to not use real package management?
The open source version solves the technical problems Apple may have with Flash.
But actually I think they're right in wanting Flash dead. It's true that it's a closed propriety format, and it will lead to a closed web. Perhaps they're doing it for their own selfish reasons. But in this case, I think those reasons coincide with what people want in the long term.
I'm just surprised Google hasn't realized the danger that flash poses. It'll completely demolish their search capabilities.