Printing is my major beef with KDE 4. A "desktop" without printing? WTF were they thinking? One of the primary functions of a desktop environment is to provide printing - page selection options, including odd/even, etc, is an absolute must.
I'm afraid you need to get a more up-to-date major beef. KDE 4.3 has full printing support, with collation, banners, cover pages, headers and footers, etc.
If the documentation is incomprehensible or missing, then the software generally wasn't well thought out or planned ahead of time, but rather just grew as an accretion of hacks.
This is particularly true of API documentation. I've even encountered crackpots in the Rails community who think that you don't need API documentation if you have unit tests; their code was abysmally unreliable, unstable, and performed poorly.
Yum was also a political move. They could have gone with urpmi, Smart, or APT4RPM, all of which were proven parts of other RPM-based distros at the time they decided to switch to yum.
(In fact, ideally they'd have switched to APT4RPM, and then in a later release dropped RPM in favor of dpkg, and ended up with something that actually works reliably. Unfortunately, that's never going to happen because RPM was written into LSB, RedHat would never go along with any change, and SuSE needs to stay close to RedHat for commercial reasons.)
In a way, I agree with you that Yum's snail-like speed is not that big of a deal. I've had so much pain from SuSE's supporting-and-then-not-supporting of APT, Smart and Yum, plus the pain of YaST brokenness and the injection of Mono, that I'm in the process of decommissioning SuSE servers in favor of RHEL everywhere I need commercial Linux, even though that means using Yum. But you asked what was wrong with Yum, so I answered the question.
Zypper *groan*.. what the hell was wrong with yum?
Well, for starters it's incredibly slow. I have quad-core 3GHz servers with RAID arrays that take longer to update using Yum than my 1GHz VIA C3 EPIA box does using APT.
From a brief review of the language and implementation, this doesn't appear to use what we've learned about correctness over the last thirty years.
Nor does any other language in common use. I remember during my CS degree skipping a bunch of denotational semantics and provability stuff, thinking "Pah, nobody's ever going to use this". And 20 years later, I've yet to see it in the real world.
Sure, there are a few embedded systems and chip designs that are proven correct. But 99.99% of systems out there aren't even up-to-date with what we knew about correctness 20 years ago.
His answer as to why he continues to build and expand: "Because I really enjoy it."
Well, I don't, so I have a modest proposal: Your friend gives me enough money that I can stop working tomorrow. I'll spend a good chunk of my spare time doing more work on free software, and your friend can carry on working to earn a second fortune, and we'll both be happy.
Is it really that huge a leap for Cable Companies to figure out how to supply a video-on-demand only service?
No. The problem is, the content providers won't let them. They're too addicted to subscription revenues from people forced to pay for bundles of channels they don't want.
So "what customers want" is what they are selling. That is established, it's a clear fact.
Umm, no.
What customers want is the programs they want to watch.
What the cable companies are selling is bundles of hundreds of channels.
That's why he used the words "subscription revenue". What really scares the cable company is that Internet people understand that there is no technical reason why they can't be sold just the channels they want; and on the Internet, there's no reason why they can't be sold just the shows they want. Yet the content providers won't allow a la carte, so the cable companies can't give customers what they want.
If I could have subscribed to just the channels I actually watched, I'd have kept my satellite subscription. As it was, I was forced to pay for sports, news and movie channels which I literally never watched--and channels like ESPN are the most expensive part of your cable or satellite bill. So I made the rational decision--I cut the cord, and now I buy shows from iTunes or the PlayStation store. If the shows aren't available there, I go wherever I have to go to get them, whether it's hulu or BitTorrent. I'm willing to pay, but I'm not willing to pay for bundles of crap I don't want.
That does not cover the entire scope of cases where a potential customer has acquired content that the industry has not approved.
I think you could have stated that more clearly as "That does not cover the entire scope of cases where a potential customer has acquired content that the industry will not sell."
All the TV I download from unapproved sources is material that I would pay for, but the content provider won't actually sell it to me.
For example, I was paying for and watching ABC's "Defying Gravity". When ABC canned the series mid-season, they could have put the rest of the episodes on the iTunes store, and I'd have kept on buying and watching. Instead, they decided not to make any of them available, basically driving me to BitTorrent if I wanted the rest of the story.
Similarly, if the BBC and other UK channels sold their content on the iTunes store, I'd buy it there; but since they don't...
No, it shouldn't have a button...it should have a 'key', or, rather a switch that turns like a key. In the same place that keys normally are, on the steering column. Same amount of mechanical force to turn as a key.
Why?
I'm a Prius owner, and I've never had any other car. I find the power button right there in front of me to be far easier to find than any key. When I occasionally have to deal with a rental car, fiddling with the key is awkward and error-prone.
You just like keys because it's what you're used to. If we're going to standardize on something as important as this, why not take the time to do some UI work and determine what would actually be the most safe and easy to operate in the event of an accident? I'm betting that turning a metal key in a rotary lock would not be the answer.
Things are developed independently and I believe that they even have multiple projects going on for the same thing and one gets picked and the others get scrapped.
If Vista was the one that got picked, imagine what the others must have been like.
You don't have to do a fresh install, but some people prefer to. And doing a fresh install doesn't require losing your settings on any OS other from Windows.
I think stand alone makers are fighting a losing battle, but they can bank a little bit on the notion of dedicated functions in automobiles.
There's also a niche for handheld GPS units. Mine is waterproof, will easily withstand being dropped onto rocks, and will run for several days on a set of AA cells. These are useful features if you're actually going out into the wilds of nature.
Of course, that's a pretty small niche compared to the total set of people who might want some sort of GPS capability.
Slashdot Mirror
Flickr has some diagrams of how AT&T is related to AT&T.
Maybe it's like Firefox and they don't actually fix them, just close them.
I'm afraid you need to get a more up-to-date major beef. KDE 4.3 has full printing support, with collation, banners, cover pages, headers and footers, etc.
If the documentation is incomprehensible or missing, then the software generally wasn't well thought out or planned ahead of time, but rather just grew as an accretion of hacks.
This is particularly true of API documentation. I've even encountered crackpots in the Rails community who think that you don't need API documentation if you have unit tests; their code was abysmally unreliable, unstable, and performed poorly.
Yum was also a political move. They could have gone with urpmi, Smart, or APT4RPM, all of which were proven parts of other RPM-based distros at the time they decided to switch to yum.
(In fact, ideally they'd have switched to APT4RPM, and then in a later release dropped RPM in favor of dpkg, and ended up with something that actually works reliably. Unfortunately, that's never going to happen because RPM was written into LSB, RedHat would never go along with any change, and SuSE needs to stay close to RedHat for commercial reasons.)
In a way, I agree with you that Yum's snail-like speed is not that big of a deal. I've had so much pain from SuSE's supporting-and-then-not-supporting of APT, Smart and Yum, plus the pain of YaST brokenness and the injection of Mono, that I'm in the process of decommissioning SuSE servers in favor of RHEL everywhere I need commercial Linux, even though that means using Yum. But you asked what was wrong with Yum, so I answered the question.
[Opinions mine, not IBM's.]
Yes, zypper is significantly faster.
I mentioned quad-core and RAID to reassure readers that it couldn't be a CPU or disk speed constraint causing yum's slowness.
I don't think I've ever seen yum do something I would describe as whizzing. I've seen it take a crap a few times, but that's probably due to RPM.
Well, for starters it's incredibly slow. I have quad-core 3GHz servers with RAID arrays that take longer to update using Yum than my 1GHz VIA C3 EPIA box does using APT.
Nor does any other language in common use. I remember during my CS degree skipping a bunch of denotational semantics and provability stuff, thinking "Pah, nobody's ever going to use this". And 20 years later, I've yet to see it in the real world.
Sure, there are a few embedded systems and chip designs that are proven correct. But 99.99% of systems out there aren't even up-to-date with what we knew about correctness 20 years ago.
Or try finding information about IBM's operating system for System i boxes.
The OS is called "i".
Well, I don't, so I have a modest proposal: Your friend gives me enough money that I can stop working tomorrow. I'll spend a good chunk of my spare time doing more work on free software, and your friend can carry on working to earn a second fortune, and we'll both be happy.
No. The problem is, the content providers won't let them. They're too addicted to subscription revenues from people forced to pay for bundles of channels they don't want.
Umm, no.
What customers want is the programs they want to watch.
What the cable companies are selling is bundles of hundreds of channels.
That's why he used the words "subscription revenue". What really scares the cable company is that Internet people understand that there is no technical reason why they can't be sold just the channels they want; and on the Internet, there's no reason why they can't be sold just the shows they want. Yet the content providers won't allow a la carte, so the cable companies can't give customers what they want.
If I could have subscribed to just the channels I actually watched, I'd have kept my satellite subscription. As it was, I was forced to pay for sports, news and movie channels which I literally never watched--and channels like ESPN are the most expensive part of your cable or satellite bill. So I made the rational decision--I cut the cord, and now I buy shows from iTunes or the PlayStation store. If the shows aren't available there, I go wherever I have to go to get them, whether it's hulu or BitTorrent. I'm willing to pay, but I'm not willing to pay for bundles of crap I don't want.
I think you could have stated that more clearly as "That does not cover the entire scope of cases where a potential customer has acquired content that the industry will not sell."
All the TV I download from unapproved sources is material that I would pay for, but the content provider won't actually sell it to me.
For example, I was paying for and watching ABC's "Defying Gravity". When ABC canned the series mid-season, they could have put the rest of the episodes on the iTunes store, and I'd have kept on buying and watching. Instead, they decided not to make any of them available, basically driving me to BitTorrent if I wanted the rest of the story.
Similarly, if the BBC and other UK channels sold their content on the iTunes store, I'd buy it there; but since they don't...
Why?
I'm a Prius owner, and I've never had any other car. I find the power button right there in front of me to be far easier to find than any key. When I occasionally have to deal with a rental car, fiddling with the key is awkward and error-prone.
You just like keys because it's what you're used to. If we're going to standardize on something as important as this, why not take the time to do some UI work and determine what would actually be the most safe and easy to operate in the event of an accident? I'm betting that turning a metal key in a rotary lock would not be the answer.
You haven't seen a Prius. It has no 1st or 2nd, because it has no conventional gearbox. The gearshift has reverse, neutral, and drive.
So x86_64 doesn't have this problem? That would explain why sysctl -n vm.mmap_min_addr gives me an error...
I remember a CASE tool called The Last One that was briefly hyped as making programming obsolete.
Yeah, if I had a nickel for every time a programmer has used floating point inappropriately, I'd have $319.19999999999997.
Trouble is, every now and again a good manager ends up managing someone like Jean-Louis Gassée.
If Vista was the one that got picked, imagine what the others must have been like.
You don't have to do a fresh install, but some people prefer to. And doing a fresh install doesn't require losing your settings on any OS other from Windows.
Well, I've never had a problem like that with configs... But then again, I don't use GNOME.
Why a separate /home? So that you can easily do a clean install of the next version from CD without blowing away all your data.
I learned that lesson several releases ago. I have 10GB / for the OS, and the rest in /home.
There's also a niche for handheld GPS units. Mine is waterproof, will easily withstand being dropped onto rocks, and will run for several days on a set of AA cells. These are useful features if you're actually going out into the wilds of nature.
Of course, that's a pretty small niche compared to the total set of people who might want some sort of GPS capability.
If Google at least supported S/MIME, that would be a start.