Mac OS X 10.6.6 Introduces App Store
Orome1 writes "Apple today released Mac OS X 10.6.6 which increases the stability, compatibility, and security of your Mac. What's also very important in this release is the introduction of the long-awaited Mac App Store with more than 1,000 free and paid apps."
People were previously not able to buy enough Apple products online, in the Apple store, and Best Buy and Walmart. Finally a new way to consume more!
I went to battle M.C. Escher, but drew a blank.
That's not an analogous situation though. In the case of iOS, you can only install an application if it's available in the iOS App Store (ignoring jail breaking and such, of course). The only way around that would be to have a web application, which in many ways is a poor substitute for having a native app. But in the case of OS X, you can still install/build any application you'd like. It's not as though using Steam prevents you from buying Starcraft II from Blizzard. In fact, the Mac App Store model is explicitly meant for types of applications that don't have to make system changes or integrate with the OS, something entire classes of desktop applications need to be able to do. Unlike iOS, this isn't attempting to be the only avenue for application installation, it's simply meant to be convenient. (can use your Apple ID, download and update your apps through one central location, develop and distribute paid applications without having to have your own purchasing infrastructure, etc)
Don't like the Mac App Store, but like the repository concept? Install and use Bodega - http://www.appbodega.com./ They have no guidelines, and have said they're not going anywhere.
Or, you know, continue downloading and installing disk image and other installer files from the web like you've always done.
The Debian project does have some fairly strict guidelines: they're just not related to content, so much as they are licensing of content. It must be "free" and unencumbered. They also, I suspect, have some guidelines/rules related to functionality, packaging namespace, privacy functionality,
Honestly, aside from the guidelines which mainly pertain to for-pay programs and legal liability (crude content, violence, etc.) I didn't really see anything in the Apple dev guidelines that jumped out at me and said "bad!" It's mostly just "if you want to play ball with us, you have to play by our rules." Exclusionary? Sure, if the dev wants to do something different, sure.
FreeBSD doesn't do 'repositories', so to speak. They do ports, and then FreeBSD. They're conveniently independent (I suspect so that the FreeBSD project can claim superior security to everything else). Even then, ports don't really have 'guidelines'. "I maintain this port and I'll update it as I please, consequences be damned" seems to be the guiding message, though.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
What the fuck are you on about? The Mac App Store has the same requirements as the Snow Leopard release:
1) Mac system running Intel processor;
2) 1 GB of RAM;
3) 5 GB of disk space;
4) DVD Drive
That's it. The entirety of the "required specs" to run Snow Leopard. There is no Intel mac that's been released since 2006 that doesn't have at least those specs, unless you ripped hardware out of it, or put together a Hackintosh of your own, and did it badly, and cheaply.
Or are you complaining because *you decided* not to upgrade to Snow Leopard, and now can't upgrade to the latest Snow Leopard patch, which includes the App Store?
Really? Is that why I can move my home directory from one linux install to another and the programs will still run?
Please don't even argue this point. Linux is a bit behind the curve and the only people who would argue otherwise are people who don't use both OS's. Sure you can copy your home directory on Linux, or use the stored installer (if you are expert enough to know where they go) for an individual app (on some distros)... all provided you are running on the same architecture.
With OS X you can literally drag an application into a chat window to a friend, who is running a different version of your OS, running on a different chipset and that friend can double click the app and run it. It's a great deal more painless since all the apps are the installers and are self contained directories ending in .app. It's one of the things Apple got right and where no Linux distro has enough pull to push change, especially since it is not a big pain point for end users. Additionally, the OpenStep packages make running software off a network drive or flash drive or anywhere really, easier by allowing for multiple sets of preferences and multiple included binaries to get around the whole hack of symlinks or multiple copies for multiple architectures.
Linux is not ahead in every area, just as OS X and Windows are behind in other areas. Get over it.
If "developers will hand over 30 percent of the purchase price to Apple," what will consumer prices be?
Have you ever worked in the end user software development business? 30% going to distribution, credit card processing, and managing updates isn't bad. When you add in the amount of publicity it generates by being in THE searchable software database for end users, well, likely prices will drop as advertising will drive more sales, more price competition, and larger volumes.
My four year old Intel-Mac doesn't have the required specs.
It has. You are just too cheap to spend $29 on Snow Leopard.
The Debian project does have some fairly strict guidelines: they're just not related to content, so much as they are licensing of content. It must be "free" and unencumbered.
Wrong. They just have separate sections; main, contrib and non-free, all maintained by the Debian project. You can search for non-free packages as easily as with free packages: http://www.debian.org/distrib/packages#search_packages
Sure, they must be legality distributable binaries - or else Debian themselves couldn't put it in the mirror - but it's not required to be free software. Adobe Flash, the proprietary Oracle JDK, non-free firmware, there are plenty of non-free packages in Debian.
Dilbert RSS feed
The App store detected my copy of Aperture and considers it as being installed.
Jonathanjk.com
Here are the stats I see on our website (major financial institution):
The remaining 2.73% is crap data.
With the first link, the chain is forged.
Actually, Linux relies upon dependency resolution at install time. OS X uses self contained packages with a dynamic linking scheme. That's the difference I was bringing up and what enables OS X to have more easily portable applications and better ability to use remote software.
Again, no, you seem to misunderstand what linux does and does not do.
Both systems work in both of the ways you have described. See e.g. MATLAB for linux (no install time dependency resolution), or Fink/Macports which does install-time dependency resolution on OSX.
On OS X the executable(s) and resources are in the same directory along with the libraries that aren't standard on the OS.
That's exactly the same way that 3rd party self-contined rather than package-managed software works on Linux. And the standard Linux way is exactly the same way that third-party package-managed software works on OSX (e.g. Fink).
As for unable to share libraries, that's not true. They do share libraries dynamically linking to the most up to date within the stable line. You can literally install a singed package and your other apps will upgrade or fall back to their own copy as needed because multiple copies are stored (one per app that uses it).
Are you claiming that if two different .apps have the same .dylib buried in their directory somewhere, then when the two apps are running, only one copy of the .dylib will reside in RAM? If so, then [citation needed] because I've never heard of that happening before.
It doesn't work as well, especially for...
No, it works vastly better except for... ...apps installed not using the package manger (as a Linux user I'm sure you have to deal with these as well) and it falls down in the several, specific use cases I mentioned in my last post (and which you did not address).
Of course the package manager doesn't manage non-packages. Much like the .app method doesn't help executables that aren't .apps. For non managed packages the install process is usually a case or running the installer executable, which is I will grant more awkward than using a .app on OSX (though plenty of OSX programs also seem to require installing, too). But not much, given that the majority of installed software is done through the package management system.
For the managed packages everything works effortlessly, like magic.
OK, back to your other points. I've never had a problem with networked executables. Things seem to run over NFS just as well as locally. And multi-arch programs also seem to run just fine. I believe that matlab uses a wrapper script internally to invoke the correct binary. But frankly, I run it and it works.
You do know that basically no applications get stored in /sw/bin right? That's mostly for bad ports and legacy software. Even OpenOffice installs as a .app these days and it can be stored anywhere the user likes.
No, everything fink installs goes in /sw. It isn't just "legacy" things as fink has up to date versions of plenty of packages. I find that the term "legacy" in computing is generally used as a pejorative, to dismiss a piece of software without offering any coherent reasons.
SJW n. One who posts facts.
Why do we need to upgrade and reboot the operating system to run, just, a new application?
Love it or hate it, Apple will drag its userbase, kicking and screaming if necessary, forward. In the end it's for the good of both Apple and their customers. If you want to live in the past, install windows xp ;)
Apple supports their OS to, at most, one version back. Period. No exceptions, no extensions. But they also do their damndest to make the transitions as painless/smooth/transparent as possible. (classic,rosetta,etc) If you make it easy and orderly, and do it periodically, it's not a problem for the vast majority of users.
I work for the Department of Redundancy Department.