More than half of my power comes from domestic hydro, wind, and landfill gas sources, with the rest most likely produced from nuclear and domestic sourced coal and natural gas.
I can only speak for the Galaxy Tab 2 7.0, but modern Android devices are faster in part because of software performance improvements. Android 4.1 and 4.2 both have performance improvements, and upgrading the Tab 2 from the 4.0 it came with to 4.1 or 4.2 makes the OS visibly faster. The Nexus 7 comes with Jelly Bean (can't recall if 4.1 or 4.2 out of the box), so everything is fast to begin with.
In this way, Android is similar to Mac OS X - initial releases were rather slow, and subsequent versions (10.1, 10.2, maybe 10.3) were faster simply because there was a lot of easy optimization work to be done.
As an iOS user I didn't really like Android until Jelly Bean.
5:5 pulldown is real (playing each frame from a 24 fps source five times on a 120 Hz display), and does not involve motion interpolation. Watching content played at constant frame raters looks better, but it's a luxury many will find unnecessary.
People aren't buying expensive TVs because they are 3D; they are buying high end TVs which mostly happen to have 3D.
Now if these 3D TVs had real 120 Hz input (for two frames of 1080p60 in 3D using shutter glasses) it might be a useful feature to use without the glasses on. But so far I think they all only support two frames of 1080p30 at most - standard HDMI doesn't have enough bandwidth, and newer spec hardware and cables are required.
With 48 fps movies, we may see more TVs using 240 Hz, but probably none with any high-bandwidth inputs, especially if 3D goes away.
I think ipv6 is available across much (maybe most or all) of the Comcast network, but will only be usable with compatible clients with ipv6 DHCP support (and specifically DHCP6-PD for routers.) Most consumer routers that are currently deployed don't support IPv6 and some older ones that do might not work properly with prefix delegation. They may only enable it for modems that they have certified for IPv6.
That must be why all these large organizations, from government agencies to paranoid corporations, are supporting iOS devices instead of or in addition to the more secure blackberry devices they already have.
The collision appears to be caused by negligence, and was not simply an accident.
The way I read the article, nothing suggests the collision was caused by negligence. I think the article would have been written differently if this was the case. An attentive driver might have resulted in a 25 mph collision instead of a 45 mph collision, or hitting a car in another lane to avoid hitting the motorcycle...
FTA, the charge was "distracted driving", not something closer in meaning to "crashing into a vehicle/motorcycle and causing injury" or even "failure to control vehicle". The fine & speaking tour seems more reasonable to me considering it was for the distracted driving charge. I've known people to get more tickets in no-injury collisions.
Reading the article, it looks like this happened in 2009, and no other charges or details were mentioned - so I'm guessing there is more to the story here. There are many possibilities, but my guess is that the situation would have resulted in something happening even if the truck driver was paying full attention to the road - could have been a near miss, could have been a lower speed collision...
Unreasonably accusing someone of dishonesty is a terrible way to start a reply.
I agree completely. But you still haven't explained how a RCS can determine the sequence of user actions performed within an application that led to a new state without being programmed to interact with the application, or the application being programmed to interact with the RCS.
The example in my previous comment demonstrated two different sequences of events that both lead to the same result given the same original state. How does the diff between two document versions get turned into Office-style tracked changes? In a typical application, this information is lost as soon as the undo buffer is cleared.
Here is another way of posing this question: If I open a file in a text editor, make a lot of changes, write it to disk with a new name, and quit, how can you reconstruct the undo buffer given only the original file and the new version of the file?
I've worked with systems built upon traditional RCS components that enabled every feature you've described to be applied to any document, regardless of source format, extremely easily. These were internal systems, but they do exist.
I'm not sure if I can believe you. Such a system would have commercial value, and you should be able to refer us to the vendor.
Such a system would also need to have some awareness of the source format to approach the level of detail of change tracking in Office. For example, for ODF and OOXML, the RCS has to know at least to unzip the file and apply diff to the contents inside... and then there would have to be tools to do something with these diffs. Assuming it can diff two documents, how does a RCS figure out the differences between these two short documents:
Today is Friday
today is the day Friday
These changes take less than a minute to make by a user, and without application-level support, a RCS will just have the state before the user opened the file and after they saved. But integrated change tracking will generate different sequences of events depending on how the user made the change. If they selected the entire line and pasted the new content:
delete "Today is Friday" at position 0
insert "today is the day Friday" at position 0
If they made each change individually, this will be reflected in the change history, and the changes will be logged in the order in which they were made, so this is only one of 24 possible sequences:
delete "t" at position 0
insert "t" at position 0
insert "the day " at position 9
apply italic formatting from position 17-19
A sophisticated RCS with differencing support that was aware of the file format could try to recreate a history like this (by assuming all changes were made from left to right), but can't actually determine the actual sequence and timing of the changes.
The difference seems trivial with a small sentence, but it is a lot more significant when editing a bigger paragraph.
In my view, a document should be treated as a token, and modifications to that token should be handled by external systems.
Involving an external central repository is a lot more complex than storing changes inside a document, which can be easily copied, sent via email, etc. And as described in my earlier comment, RCS doesn't provide anywhere near the level of change detail and metadata-dependent approve/deny/comment abilities as integrated change tracking.
Inline change tracking allows me to write a document, enable change tracking, save it, give the document to someone else, and have them change the document and save it. This file could be sent via email, saved to a system that provides simple history functionality (like Dropbox), or even commited to a traditional RCS. If changes were exclusively tracked by an external system, this process would be a lot more difficult.
Yes change tracking is most definitely better served by revision control systems... Many organisations have had the change tracking systems in programs like word come to bite them in the ass pretty badly as comments they thought had been removed were still visible...
Sometimes people want to easily communicate changes and comments with others. Accidental use of change tracking features is not a valid reason to prescribe the use of external RCS instead.
but this seems like something better handled by revision control systems anyhow.
Integrated change tracking is a form of revision control system, embedded into some document formats and applications. It serves a different purpose than a traditional revision control system, and is useful in combination with a traditional RCS or a document management system with its own file-level revision tracking and approval systems (such as SharePoint or Alfresco).
Change tracking systems log a sequence of actions that led to the new state, store time and user metadata inline with these changes, and allow out-of-band content (comments) . The current state of a document with change tracking is (approved content + not yet approved changes + comments). In a traditional RCS, the current state of the document is just the approved content, as there's no approve/deny mechanism for individual changed sections and no metadata at the section level. ("section" here is the unit the RCS uses when differencing files - usually lines in a RCS used to manage source code changes, but in document change tracking, this is often just the part that was changed - could be a single character, could be an entire page of content, could be the metadata for a sentence, etc.)
In my view, a document should be treated as a token, and modifications to that token should be handled by external systems.
Changes should be tracked as they are made by the user. A traditional RCS tracks the differences in an entire file between the last change and the next commit, so it can't... unless every single change results in a separate (local) commit, and saving results in those commits being pushed to a new branch. But doing this requires the application to have support for change tracking, just with the backend being a RCS instead of inline metadata in the file. And then the individual changes can only be obtained and displayed to the user by getting all of the commits in the branch and replaying them, starting with the original state in-memory. Using RCS in this way still doesn't solve the approve/reject feature of change tracking, it doesn't solve comments, and it makes showing individual changes a lot more difficult than just storing the changes with inline metadata.
Traditional RCS doesn't know how a change was made; the application does. Changing "this is GREAT" to "that is great" could be a single change (overwrite using paste from clipboard) or many changes in the order they were performed (change "this" to "that", change "GREAT" to "great", adding bold formatting to "great"). The application knows, and it can save this data.
Traditional RCS can be used to atomically track the file-level changes to a document, but it doesn't provide anywhere near the level of detail as change tracking. I don't use MS Office, but I believe it supports both embedded (in-file) change tracking and versioning at the document level (using SharePoint or something that can pretend to be close enough, which I think Alfresco might be able to do).
I guess its an "official support" type of deal, not as if anything in the tech has changed.
Performance of the virtualized machines was great, the management of the VMs, however, is why you want VMWare if you're serious.
"support" is probably in the form of first-class integration software and drivers, possibly for improved I/O performance, time synchronization, shutdown, disk shadow support, etc.
Other example: Apple introduced random playlists on iPods years ago. Now people noticed that some songs got played more than once before all others were played. Can't be random! There's a bug! Well, no. Still, Apple had to modify their software to make the choice actually LESS random (by have no song being played twice) to make it appear "really" random to the users.
I've never had an iPod with a random feature. However, it does have a shuffle feature, which implies that each song will be played once (assuming repeat is not enabled), and this is exactly what the feature does.
iTunes has a random Smart Playlist feature that can randomly select songs from a selected set of songs.
They should get on with the program and scrap the pile of shit they call Windows and build something around the UNIX kernel
You backpedaled quickly when I called you on something you must have known was wrong. There's nothing Microsoft could implement on a Unix kernel they couldn't implement on a Windows kernel.
You are dishonest, arrogant, and deluded.
Honestly, these things are completely unnecessary now, because desktop is not where it's at. Your comment and thinking is still stuck in the 90s desktop mentality (kind of like entire Microsoft).
Did you read the first half of my comment? I mentioned modern OS features used by all kinds of systems - whether it be a iOS device, desktop computer, web server, whatever - and described how these are not exclusive to Linux at all.
I'm talking about the Web 2.0 startup world, where Microsoft is literally dead (in the sense that no new Web startup is afraid of Microsoft or is worried Microsoft is going to destroy them).
Outside of Netscape and Opera, who has ever had this fear?
But you won't see Google or Facebook or any new Web startup deploying on their tools or OSes.
Of course not. But they do that because there are better and cheaper alternatives - not because Microsoft tools are fundamentally uncapable of running modern applications, and not because the unix way is the only way to run modern applications.
I'm 40 now, I learned my way around UNIX 25 years ago and kept at it.
I think your narrow focus on UNIX has blinded you.
There are some damn nice features that 7 has I wish my Mac would copy. Namely: snap to sides.
This feature is in BetterTouchTool, which I recommend if you use a Magic Mouse or a mutlitouch trackpad on a Mac (even without the snap to side feature).
They should get on with the program and scrap the pile of shit they call Windows and build something around the UNIX kernel and run legacy apps in VM like they virtualize XP now.
And what is so different about a modern Unixlike kernel compared to the Windows NT kernel?
Most device drivers run as part of the kernel
Processes on both kernels run in their own virtual protected memory space
Processes can have multiple native, independently-scheduled threads that share the same memory space
Both kernels are written in C
Both kernels support C as the primary development target
Processes interact with the kernel via system calls or native calls using C function call semantics
Processes belong to users and groups
File system handling (including security enforcement) occurs in the kernel using a common API, regardless of the underlying filesystem type (direct attached disk filesystem, network filesystem, fake filesystem like FUSE etc.)
Users and groups have rights to access certain resources and files, both via traditional ownership and more complex ACLs
Networking is handled by the kernel in a layered fashion, with the device driver at one end and, sockets API at the other, and others in between
File and network APIs use a file handle or descriptor to identify a resource and write/read to it
File operations can occur by reading/writing arrays of bytes or memory mapping files
File operations can also be performed on block or character devices
Multiple facilities exist for inter-process communication, including message passing, shared memory, domain sockets/named pipes, etc.
The major differences are in the kernel level APIs. The Windows API is a lot more verbose (
POSIX can be implemented on top of Windows (as in Services for UNIX or whatever they call it now, and as in Cygwin) because Windows NT isn't that different in functionality than Unix. All of the major kernel level operating system features are in both.
Meanwhile everyone else that matters in post Microsoft world uses open OSes, leveraging their investment is stable APIs, great free tools and go on about innovating with the only cost being hardware and (usually smarter) people.
The Windows API is one of the most stable for certain types of applications. The same Windows graphics APIs used to build basic applications are still supported a few decades later and still get new/additional features (without breaking backwards compatibility). Compare to the many toolkits for X over the years; the switch from Gtk+ 1 to Gtk+ 2; switches between the various versions of Qt...
Windows's device driver interfaces are also much more stable, and better yet, the old interfaces don't get removed when new interfaces are made (allowing old drivers to be used even when the APIs have been replaced). Compare to Linux, which considers unstable kernel APIs a good thing.
Microsoft should just keep pushing good stability features for their crappy OS. Every single OS release is an "oh we got this new x and that new y (both available in other decent OS for ages, except for the occasional innovation)" moment
The Windows 7 graphics stack is still more capable than anything in Linux when it comes to features like switching between GPUs and replacing GPU drivers without closing programs, logging out, or rebooting. This feature greatly reduces the impact of graphics driver crashes, as the graphics driver can be restarted without losing any work, and reduces power usage on laptops with discrete GPUs, as low-power integrated graphics can be used when high-power graphics are not needed.
The audio system is also more stable and more capable than Linux's.
Linux can't get video and audio working with the features and stability seen in Windows or Mac OS X in the mid 00s, let alone today.
That's what Windows should do -- add powerusers to their marketshare (I mean real powerusers).
Of course we all know that No true power user would use Windows right now, right?
Fedora and Debian both provide a core repository and non-core repositories. I'm not familiar with Ubuntu.
The Debian and Fedora repositories are huge.
OpenBSD does the same, and my memory is that freeBSD does, as well. The difference is primarily one of scale. openBSD, for instance intentionally keeps the core repository much smaller than most other distributions, and not just because the team is (intentionally) small.
The base OpenBSD and FreeBSD distributions (without ports) are designed to be an operating system to themselves (usually with all of the source for this core checked into the same repository), similar to what passed for a commercial UNIX system two decades ago. They both happen to provide "ports" systems on top of this. Linux distributions are generally build scripts/SPEC files/whatever used to patch, compile, and package source from upstream in a certain way, and most distributions (RHEL/SLE excluded) seem to have no problem adding lots and lots of packages.
The problem with the Mac, and it's a real problem, is that there is no official repository. Well, wasn't.
Now there is, but it's neither free nor open, as near as I can tell from the outside. (I'm not interested in being on the inside right now, so I'm judging it by the reports.)
The App Store works quite well for end-user facing applications, most of which are written specifically for Mac OS X.
But the app store still doesn't solve the underlying problem of dependency.
The dependency for programs in the App Store is Mac OS X. Generally, the core libraries in Mac OS X are rich enough that applications written for OS X don't need dependencies.
Apple really let us down when they dropped the ball on this one. They have enough money, they could be supporting all three unofficial distros, so that you aren't as restricted by which package manager you've loaded a package by. And they could be encouraging, with financial encouragement, those guys to learn interoperability.
Apple does support one: MacPorts, which is hosted by Apple at MacOSforge. The packages in these distributions are almost all for developer/UNIX power user use, and serve a completely different purpose than the Mac App Store.
Slashdot Mirror
More than half of my power comes from domestic hydro, wind, and landfill gas sources, with the rest most likely produced from nuclear and domestic sourced coal and natural gas.
I can only speak for the Galaxy Tab 2 7.0, but modern Android devices are faster in part because of software performance improvements. Android 4.1 and 4.2 both have performance improvements, and upgrading the Tab 2 from the 4.0 it came with to 4.1 or 4.2 makes the OS visibly faster. The Nexus 7 comes with Jelly Bean (can't recall if 4.1 or 4.2 out of the box), so everything is fast to begin with.
In this way, Android is similar to Mac OS X - initial releases were rather slow, and subsequent versions (10.1, 10.2, maybe 10.3) were faster simply because there was a lot of easy optimization work to be done.
As an iOS user I didn't really like Android until Jelly Bean.
5:5 pulldown is real (playing each frame from a 24 fps source five times on a 120 Hz display), and does not involve motion interpolation. Watching content played at constant frame raters looks better, but it's a luxury many will find unnecessary.
Some people like motion interpoltaion too.
People aren't buying expensive TVs because they are 3D; they are buying high end TVs which mostly happen to have 3D.
Now if these 3D TVs had real 120 Hz input (for two frames of 1080p60 in 3D using shutter glasses) it might be a useful feature to use without the glasses on. But so far I think they all only support two frames of 1080p30 at most - standard HDMI doesn't have enough bandwidth, and newer spec hardware and cables are required.
With 48 fps movies, we may see more TVs using 240 Hz, but probably none with any high-bandwidth inputs, especially if 3D goes away.
Each major RHEL release starts with a fork from a Fedora release.
RHEL6 is apparently based on Fedora 12/13
I think ipv6 is available across much (maybe most or all) of the Comcast network, but will only be usable with compatible clients with ipv6 DHCP support (and specifically DHCP6-PD for routers.) Most consumer routers that are currently deployed don't support IPv6 and some older ones that do might not work properly with prefix delegation. They may only enable it for modems that they have certified for IPv6.
That must be why all these large organizations, from government agencies to paranoid corporations, are supporting iOS devices instead of or in addition to the more secure blackberry devices they already have.
The way I read the article, nothing suggests the collision was caused by negligence. I think the article would have been written differently if this was the case. An attentive driver might have resulted in a 25 mph collision instead of a 45 mph collision, or hitting a car in another lane to avoid hitting the motorcycle...
FTA, the charge was "distracted driving", not something closer in meaning to "crashing into a vehicle/motorcycle and causing injury" or even "failure to control vehicle". The fine & speaking tour seems more reasonable to me considering it was for the distracted driving charge. I've known people to get more tickets in no-injury collisions.
Reading the article, it looks like this happened in 2009, and no other charges or details were mentioned - so I'm guessing there is more to the story here. There are many possibilities, but my guess is that the situation would have resulted in something happening even if the truck driver was paying full attention to the road - could have been a near miss, could have been a lower speed collision...
I agree completely. But you still haven't explained how a RCS can determine the sequence of user actions performed within an application that led to a new state without being programmed to interact with the application, or the application being programmed to interact with the RCS.
The example in my previous comment demonstrated two different sequences of events that both lead to the same result given the same original state. How does the diff between two document versions get turned into Office-style tracked changes? In a typical application, this information is lost as soon as the undo buffer is cleared.
Here is another way of posing this question: If I open a file in a text editor, make a lot of changes, write it to disk with a new name, and quit, how can you reconstruct the undo buffer given only the original file and the new version of the file?
I'm not sure if I can believe you. Such a system would have commercial value, and you should be able to refer us to the vendor.
Such a system would also need to have some awareness of the source format to approach the level of detail of change tracking in Office. For example, for ODF and OOXML, the RCS has to know at least to unzip the file and apply diff to the contents inside... and then there would have to be tools to do something with these diffs.
Assuming it can diff two documents, how does a RCS figure out the differences between these two short documents:
These changes take less than a minute to make by a user, and without application-level support, a RCS will just have the state before the user opened the file and after they saved. But integrated change tracking will generate different sequences of events depending on how the user made the change. If they selected the entire line and pasted the new content:
If they made each change individually, this will be reflected in the change history, and the changes will be logged in the order in which they were made, so this is only one of 24 possible sequences:
A sophisticated RCS with differencing support that was aware of the file format could try to recreate a history like this (by assuming all changes were made from left to right), but can't actually determine the actual sequence and timing of the changes.
The difference seems trivial with a small sentence, but it is a lot more significant when editing a bigger paragraph.
As I explained in my other comments, traditional RCS doesn't do the the same thing as change tracking. RCS will only manage .
It's a similar risk to using white-out on paper.
Involving an external central repository is a lot more complex than storing changes inside a document, which can be easily copied, sent via email, etc. And as described in my earlier comment, RCS doesn't provide anywhere near the level of change detail and metadata-dependent approve/deny/comment abilities as integrated change tracking.
Inline change tracking allows me to write a document, enable change tracking, save it, give the document to someone else, and have them change the document and save it. This file could be sent via email, saved to a system that provides simple history functionality (like Dropbox), or even commited to a traditional RCS. If changes were exclusively tracked by an external system, this process would be a lot more difficult.
Sometimes people want to easily communicate changes and comments with others. Accidental use of change tracking features is not a valid reason to prescribe the use of external RCS instead.
Integrated change tracking is a form of revision control system, embedded into some document formats and applications. It serves a different purpose than a traditional revision control system, and is useful in combination with a traditional RCS or a document management system with its own file-level revision tracking and approval systems (such as SharePoint or Alfresco).
Change tracking systems log a sequence of actions that led to the new state, store time and user metadata inline with these changes, and allow out-of-band content (comments) . The current state of a document with change tracking is (approved content + not yet approved changes + comments). In a traditional RCS, the current state of the document is just the approved content, as there's no approve/deny mechanism for individual changed sections and no metadata at the section level. ("section" here is the unit the RCS uses when differencing files - usually lines in a RCS used to manage source code changes, but in document change tracking, this is often just the part that was changed - could be a single character, could be an entire page of content, could be the metadata for a sentence, etc.)
Changes should be tracked as they are made by the user. A traditional RCS tracks the differences in an entire file between the last change and the next commit, so it can't... unless every single change results in a separate (local) commit, and saving results in those commits being pushed to a new branch. But doing this requires the application to have support for change tracking, just with the backend being a RCS instead of inline metadata in the file. And then the individual changes can only be obtained and displayed to the user by getting all of the commits in the branch and replaying them, starting with the original state in-memory.
Using RCS in this way still doesn't solve the approve/reject feature of change tracking, it doesn't solve comments, and it makes showing individual changes a lot more difficult than just storing the changes with inline metadata.
Traditional RCS doesn't know how a change was made; the application does. Changing "this is GREAT" to "that is great" could be a single change (overwrite using paste from clipboard) or many changes in the order they were performed (change "this" to "that", change "GREAT" to "great", adding bold formatting to "great"). The application knows, and it can save this data.
Traditional RCS can be used to atomically track the file-level changes to a document, but it doesn't provide anywhere near the level of detail as change tracking. I don't use MS Office, but I believe it supports both embedded (in-file) change tracking and versioning at the document level (using SharePoint or something that can pretend to be close enough, which I think Alfresco might be able to do).
"support" is probably in the form of first-class integration software and drivers, possibly for improved I/O performance, time synchronization, shutdown, disk shadow support, etc.
I've never had an iPod with a random feature. However, it does have a shuffle feature, which implies that each song will be played once (assuming repeat is not enabled), and this is exactly what the feature does.
iTunes has a random Smart Playlist feature that can randomly select songs from a selected set of songs.
You are. You said:
You backpedaled quickly when I called you on something you must have known was wrong. There's nothing Microsoft could implement on a Unix kernel they couldn't implement on a Windows kernel.
You are dishonest, arrogant, and deluded.
Did you read the first half of my comment? I mentioned modern OS features used by all kinds of systems - whether it be a iOS device, desktop computer, web server, whatever - and described how these are not exclusive to Linux at all.
Outside of Netscape and Opera, who has ever had this fear?
Of course not. But they do that because there are better and cheaper alternatives - not because Microsoft tools are fundamentally uncapable of running modern applications, and not because the unix way is the only way to run modern applications.
I think your narrow focus on UNIX has blinded you.
You are definitely doing it wrong. My MacBook Pro (running Mac OS X or Windows 7) resumes from sleep in about two seconds.
Google didn't create Android in reality, either.
Because customers call all the time to tell you that their 5 year old system is still working fine, right?
This feature is in BetterTouchTool, which I recommend if you use a Magic Mouse or a mutlitouch trackpad on a Mac (even without the snap to side feature).
And what is so different about a modern Unixlike kernel compared to the Windows NT kernel?
The major differences are in the kernel level APIs. The Windows API is a lot more verbose (
POSIX can be implemented on top of Windows (as in Services for UNIX or whatever they call it now, and as in Cygwin) because Windows NT isn't that different in functionality than Unix. All of the major kernel level operating system features are in both.
The Windows API is one of the most stable for certain types of applications. The same Windows graphics APIs used to build basic applications are still supported a few decades later and still get new/additional features (without breaking backwards compatibility). Compare to the many toolkits for X over the years; the switch from Gtk+ 1 to Gtk+ 2; switches between the various versions of Qt...
Windows's device driver interfaces are also much more stable, and better yet, the old interfaces don't get removed when new interfaces are made (allowing old drivers to be used even when the APIs have been replaced). Compare to Linux, which considers unstable kernel APIs a good thing.
The Windows 7 graphics stack is still more capable than anything in Linux when it comes to features like switching between GPUs and replacing GPU drivers without closing programs, logging out, or rebooting. This feature greatly reduces the impact of graphics driver crashes, as the graphics driver can be restarted without losing any work, and reduces power usage on laptops with discrete GPUs, as low-power integrated graphics can be used when high-power graphics are not needed.
The audio system is also more stable and more capable than Linux's.
Linux can't get video and audio working with the features and stability seen in Windows or Mac OS X in the mid 00s, let alone today.
Of course we all know that No true power user would use Windows right now, right?
The Debian and Fedora repositories are huge.
The base OpenBSD and FreeBSD distributions (without ports) are designed to be an operating system to themselves (usually with all of the source for this core checked into the same repository), similar to what passed for a commercial UNIX system two decades ago. They both happen to provide "ports" systems on top of this. Linux distributions are generally build scripts/SPEC files/whatever used to patch, compile, and package source from upstream in a certain way, and most distributions (RHEL/SLE excluded) seem to have no problem adding lots and lots of packages.
The App Store works quite well for end-user facing applications, most of which are written specifically for Mac OS X.
The dependency for programs in the App Store is Mac OS X. Generally, the core libraries in Mac OS X are rich enough that applications written for OS X don't need dependencies.
Apple does support one: MacPorts, which is hosted by Apple at MacOSforge. The packages in these distributions are almost all for developer/UNIX power user use, and serve a completely different purpose than the Mac App Store.