Linked by Thom Holwerda on Tue 9th Feb 2010 19:06 UTC, submitted by diegocg
KDE And there we are, the KDE team has released KDE Software Compilation 4.4, formerly known as, well, KDE. Major new features include social networking and online collaboration integration, the new netbook interface, the KAuth authentication framework, and a lot more.
Thread beginning with comment 408719
To view parent comment, click here.
To read all comments associated with this story, please click here.
nt_jerkface
Member since:
2009-08-26

If you're trying to install things from source, sure. But if you stick to your distributor's repositories, you'll probably be fine.


Probably isn't good enough and users shouldn't have to wait for a repository update just to run the latest version of a browser. It's also a complete waste of labor hunting down dependency bugs.


Dependancy resolution seems like a consistent gripe of yours; I'm a littel curious about what actually happened to get you so convinced that it's such a pressing problem.


I think it's an archaic system that causes needless problems. Shared libraries made more sense in the 70's when hardware resources were severely limited.


Also, my fonts look fine, and have since forever on pretty much any Linux and any hardware I've used. But I'm not a typographer, so as long as they're legible and not highly aliased, I'm O.K. with them.


Well I don't like the sub-pixel rendering in Linux and I'm not the only one. It isn't simply that I'm used to Windows either. I find the font rendering in the iphone to be easier on the eyes as well.

Reply Parent Score: 2

boldingd Member since:
2009-02-19

"If you're trying to install things from source, sure. But if you stick to your distributor's repositories, you'll probably be fine.


Probably isn't good enough and users shouldn't have to wait for a repository update just to run the latest version of a browser. It's also a complete waste of labor hunting down dependency bugs.
"

Frankly, "probably" is all you really get in software. Probably's all you get in Windows or OS X, where any given third-party installation may or may not work. True, the odds of failure are pretty low, usually, but then again, the odds of a modern package management system failing are also pretty low. (I've yet to see it happen - at least, out of Fedora, Ubuntu, Debian, and Sidux. I have imploded Gentoo quite dramatically... but then, that's Gentoo.)

I'm OK with waiting for my distributor to package an upgrade - certainly if I'm using a distribution that does so in a reasonable amount of time. Fedora and Ubuntu give you a decently new version of most packages.

Frankly, if you consider a lag while you wait for the distributor to package software a cost of having a centralized installation/update point, then I still think a repository system is worth it -- even with that minus, I still think it's more pluses than minuses.

And, anyway, you can just get your dependancies from the package management infrastructure, and build from source, if you're that impatient.

Reply Parent Score: 4

nt_jerkface Member since:
2009-08-26


Frankly, "probably" is all you really get in software. Probably's all you get in Windows or OS X, where any given third-party installation may or may not work. True, the odds of failure are pretty low, usually, but then again, the odds of a modern package management system failing are also pretty low.


Odds of a user having dependency issues than problems with an exe are much higher.


Frankly, if you consider a lag while you wait for the distributor to package software a cost of having a centralized installation/update point, then I still think a repository system is worth it -- even with that minus, I still think it's more pluses than minuses.


The repository system is lousy for proprietary software and the latest versions of open source. It's also quite messy from a software engineering POV. You could have a repository without the shared libraries. A repository of independent programs would be much cleaner and would increase stability.


And, anyway, you can just get your dependancies from the package management infrastructure, and build from source, if you're that impatient.

Yes I'm quite aware of that but it's unrealistic to expect users to compile software, ever. All they hear is "do all this ugly crap to upgrade" when in Windows/OSX it is just a couple clicks .

Reply Parent Score: 2

WereCatf Member since:
2006-02-15

Probably isn't good enough and users shouldn't have to wait for a repository update just to run the latest version of a browser.

So, is manually having to update every single application any better? I've got several browsers and a load of other applications, every single one of them having an updater of their own. You can't update them all at once. THAT's what I call bad design.

I think it's an archaic system that causes needless problems. Shared libraries made more sense in the 70's when hardware resources were severely limited.

You're just being biased. First of all, Linux is used on all kinds of computers, ranging from really small dedicated systems to large mainframes. Shared libraries use less memory than static libraries, and on small-scale machines every bit counts. On large mainframes with a dozen virtual machines it also helps as there the memory is needed for data. Having a gazillion different static copies of the same library eats memory unnecessarily.

Oh, and if you didn't know: OSX and Windows support shared libraries too.

Reply Parent Score: 4

boldingd Member since:
2009-02-19

"Probably isn't good enough and users shouldn't have to wait for a repository update just to run the latest version of a browser.


So, is manually having to update every single application any better? I've got several browsers and a load of other applications, every single one of them having an updater of their own. You can't update them all at once. THAT's what I call bad design.
"

I agree completely, and that's the kind of thing I was thinking of. Not having a single channel for software distributing and updating has its own hassles; there's a reason other people have lamented that they can't hook third-party applications into Window's updating agent. On balence, I'd rather have a centralized packaging system.

And before nt-jerkface points out that a shared-library system and a package management system are different things -- I know. As I've said over and over: linux software distribution could be done through large, statically-linked binaries. It's just that it's better to use shared libraries, if you're already using a package-management system.

Well, and the other thing is, a shared-library system is better if there's no one set of blessed libraries that make up the OS -- and, in the case of the Linux kernel and Linux distributions, this is very much the case.

"I think it's an archaic system that causes needless problems. Shared libraries made more sense in the 70's when hardware resources were severely limited.


You're just being biased. First of all, Linux is used on all kinds of computers, ranging from really small dedicated systems to large mainframes. Shared libraries use less memory than static libraries, and on small-scale machines every bit counts. On large mainframes with a dozen virtual machines it also helps as there the memory is needed for data. Having a gazillion different static copies of the same library eats memory unnecessarily.

Oh, and if you didn't know: OSX and Windows support shared libraries too.
"

They do: it's just that the libraries they share are standardized (i.e. some DLL's can be reasonably guaranteed to be present on every single Windows system), which obviates a lot of the hassles you encounter with dependancy resolution on Linux. The real problem is that system components like the sound service or the Windowing service or the password-management service are interchangeable -- or might not be present at all. If there was a blessed-and-required set of libraries -- like, "there will always be a /lib/libfictitiousstdsound.so" -- then Linux's shared library system would work as smoothly as Windows'. But there isn't, and that is largely by design, not malice or ignorance: it's part of the trade-off of creating a highly flexible system.

Edited 2010-02-11 00:07 UTC

Reply Parent Score: 3

lemur2 Member since:
2007-02-17

"Probably isn't good enough and users shouldn't have to wait for a repository update just to run the latest version of a browser.

So, is manually having to update every single application any better? I've got several browsers and a load of other applications, every single one of them having an updater of their own. You can't update them all at once. THAT's what I call bad design.
"

Spot on. Precisely correct.

The application finding/downloading, installation and updating system in Windows is absolute dreck. Utterly broken. It is a HUGE PITA, and it is also an absolute wide-open doorway for trojans and malware of all kinds to find its way on to end users Windows systems.

There is absolutely no way for end users to be able to assure themselves about the quality and lack of anti-features for much of the software for Windows that they install. It all has to be taken on trust ... and that trust is all-too-often abused.

Open source software and the repository system used in modern Linux distributions, on the other hand, is utopia in comparison. It is trouble-free installation and update of software, it is a way to easily avoid any malware, and it also means freedom for people from "anti-features".

http://computerworld.co.nz/news.nsf/development/8FC32A7B611E877ACC2...

I am using Arch Linux at the moment, and this distribution uses a "rolling release" system. This means that Arch Linux repositories today support KDE SC 4.4, just a few days after it was released by the KDE project.

http://www.archlinux.org/news/483/

This is the type of information that Windows supporters just don't want people to know about. Hence the abundance of bias and plethora of absolute misinformation spread about Linux, FOSS, and the elegant and effective software distribution methods it uses.

Edited 2010-02-11 00:21 UTC

Reply Parent Score: 3