Yeah, that's a core principal of branding - as soon as the customers are familiar with your logo, change it.
Someone tell Apple, IBM, and Coca-Cola.
101–110 of 118 posts
Yeah, that's a core principal of branding - as soon as the customers are familiar with your logo, change it.
Someone tell Apple, IBM, and Coca-Cola.
Earlier quoted context omitted.
> it would be really nice if I only had one 'update' button to push. No. If you are asking for updates and fixes, you are doing it wrong. It should be automated, because you shouldn't have to bother to remember pressing a button. I set up my mother with a Linux box and sure as hell I don't count on her pressing buttons without some prompting. > As it is, 5 different things want to update practically every day. If you…
"Most likely, you will end up with five different bugs scattered throughout your system with many different libraries that really should be just one." Actually, I prefer the five. When you have a shared library, and bugs are fixed, applications that use the library might well break. Shared libraries mean that either applications are at risk of completely failing to work, or that the library developers have to flag th…
So, yes, while you're right that shared libraries can sometimes cause the problems you describe, a good package manager will pretty much fix them. But what I love the most about Linux though is that if something bad like that happens (like the ABI of a shared library changing)... it's a minor inconvenience, but so what?
apt-get source $package
cd $package-$version
apt-get build-dep $package
dpkg-buildpackage
cd ..
dpkg -i *.deb
And bam, you just rebuild the program against the new shared library with the different ABI, and everything works. Obviously this isn't "user friendly", but then again I never had to do this before I started mixing packages from different OSes together. And isn't it so easy to do! You can just do that for any program in on your whole computer! "Hmmm, I wonder how this program works", and one command later you have its source code! Another command later and you've built all of that code, into a nice Debian package too. It's so wonderful to have such a powerful package manager.Earlier quoted context omitted.
"Most likely, you will end up with five different bugs scattered throughout your system with many different libraries that really should be just one." Actually, I prefer the five. When you have a shared library, and bugs are fixed, applications that use the library might well break. Shared libraries mean that either applications are at risk of completely failing to work, or that the library developers have to flag th…
With a proper package manager, applications won't break with the ugprade of a shared library, because their dependencies will be such that the new shared library will conflict with the application (or, what usually happens, a new build of the application against that shared library is uploaded to the repository at the same time as the library). Sometimes the packaging of a program has bugs in it though, so the situat…
Basically, as someone who switched back to Linux from Mac recently, Synaptic and the Software Center (and why there are two tools that show different-but-overlapping package sets is another WTF) are full of surprises and why-did-THAT-change?! moments.
Earlier quoted context omitted.
The OEM license is paid in full by the adware/crapware that comes installed over it. One more reason to uninstall Windows (besides Windows)
I don't see why they can't install crapware on Linux, cut out MS, and cut prices for customers while keeping a bigger cut for themselves.
Earlier quoted context omitted.
> It seems to me that the only good non-mirage reason for shared libraries was disk space usage. Shared libraries are shared in memory too. If you have 5 separate copies of libfoo and you start up applications using them, you'll have 5 copies of libfoo in memory too. And memory is much scarcer resource than disk space.
True, although code memory space consumption is not the issue it once was. The consumption of most of the big hogs (web browsers, word processors, etc) is data-related.
Earlier quoted context omitted.
It's pretty silly to have a serious dev machine without a package manager. What do you do when you migrate to a new machine? I like to copy a list of packages and then run an update/upgrade command. Linux wins by far. Copying a directory of self-contained apps is quick and easy as well... but if you need binaries for a newer arch, say x86-64, you'll have to download a new copy, whereas the package manager solution ha…
That's why I use macports on os X... While it's not provided directly by apple, you can't say that there isn't any package manager...
Copying app bundles around is easy enough though and they make things Just Work w/ fat binaries, so kudos to Apple for making that easy. Their Migration Assistant is slow, but still eases much of the pain of migration.
Earlier quoted context omitted.
True, although code memory space consumption is not the issue it once was. The consumption of most of the big hogs (web browsers, word processors, etc) is data-related.
Xulrunner takes 40 megs on a good day...
Earlier quoted context omitted.
That's a circular argument. OSX apps solve the dependency problem because they have no other way of dealing with it. They have copies of the dependencies inside the app bundle because they have to be self-contained bundles. But that's not solving the problem - if you have a defective library inside a bundle, upgrading the copy that lives inside the other bundle will have no effect on the first one. Programs are on th…
Remember DLL's on Windows? Having one new app upgrade a shared DLL was the source of so much pain in other apps. In a perfect world where interfaces are rock hard and apps code to them perfectly rather than how they actually work, shared libraries are a fine idea. In the real world of desktop software, though, independently tested, self contained packages are a much more robust solution. OS X's application installati…
Added disk usage was never the issue. Consistency of behaviour is. With shared components you know your machine will decode PNGs in exactly the same way across all the applications installed.
Earlier quoted context omitted.
With a proper package manager, applications won't break with the ugprade of a shared library, because their dependencies will be such that the new shared library will conflict with the application (or, what usually happens, a new build of the application against that shared library is uploaded to the repository at the same time as the library). Sometimes the packaging of a program has bugs in it though, so the situat…
It used to be really easy to junk a Debian system by installing random apps to try them and then uninstalling them. Even with more modern Debian-based systems like Ubuntu, installing and then uninstalling something (say, kubuntu-desktop, to pick an example that happened to me recently) does not leave your system in the same state it was before you started. Instead, you get (to a GUI user) bizarre random configuration…
Oh.. The 90's...
Seriously: I moved to Debian-based distros in 2002 and never experienced anything like what you describe. And mind you I ran testing with packages from sid directly for a couple years.
Earlier quoted context omitted.
Package management is really useful for servers, or other systems where there's a bunch of dependencies. Desktop apps hardly need it, and OSX apps in particular don't need it. The combination of the drag-to-applications-folder installing and checking for new updates to the app when you launch it solves the vast majority of this problem for the vast majority of users.
In addition to that, there's no restriction on having something like apt-get for packages that really don't make sense in the "drag-to-install" paradigm. Which is why I installed my own version of ruby, say, out of ports. I like OS X because, yes, there's a paradigm, but there's a rich underside that you can use as much as you like.