The why are all the "supported distributions" Debian based ones, and the documentation page on "Using with Other Distributions" only lists SuSE as non Debian based, says it is "harder to support" and then has a long set of instructions for what you need to do to make it work? That does not sound like easy installation to me... it sounds like rather painfully difficult installation for any non Debian based distributions.
Klik is a very nice system, and it works admirably for Debian based systems, but ostensibly its just providing Debian packages the same as the Debian repository. Any packages it provides that aren't already in the Debian repository have been packaged for Debian. Therefore it isn't really a solution to third party packaging issues (which was the original point I was replying to).
It does not solve what is the real difficulty with installing Linux software: Installing something that has not been prepackaged for you by your distribution.
Let's be clear then: Klik is fantastic if you are installing a package from Debian. Klik is completely useless to you if you are running SuSE, Fedora, Mandrake, Gentoo, or any other non Debian based distribution. Klik makes installing Debian packages easy, but so does apt and Synaptic (in a different way). It does not solve what is the real difficulty with installing Linux software: Installing something that has been prepackaged for you by your distribution. Installing new software on Debian is trivial, and Klik adds a convenient new layer to that by making it accessible to users who don't have root access. It doesn't address the problem that is always brought up when people claim about hard to install software on Linux. Read some of the complaints about Linux from Windows and Mac users. Once your want something not prepacked by your distribution for you, you're pretty much back to compiling it yourself. It is this that Autopackage hopes to solve, while at the same time making user installs of software easy.
Then we're talking around each other, because you seem to have missed my point.
Debian's "easy" system isn't easy because of its size (as the autopackage faq suggests) but rather because of their strict adherence to policy standards.
We're talking about installing some software. It is "easy" to install software on Debian if it is in the Debian package repository. If it is not, then how exactly are you planning on installing it? Compile from source? Not "easy". Download a third party provided DEB package? That ought to work, but that's hardly easy for the developer who has to provide a DEB package, a Fedora RPM, a SuSE RPM, a mandrake RPM etc., and then there's the issue that maybe the DEB was for Ubuntu and linked against some libraries in Ubuntu that aren't in Debian stable yet. In short, installing software that is not in Debian's repositories is hard. This mostly doesn't matter because Debian's repositories are BIG so the odds of wanting to install something that isn't there are rather small.
You can discuss policy standards all you like, but in the end if the software isn't in Debian, it isn't likely to be following those standards.
Let's be clear anyway: Autopackage is not a replacement for dpkg, apt, and all the usual Debian goodness. It is complementary to all of that, and is meant to provide an easy way for those "not in the Debian repository" packages to still be easy to install (and at the same time allow developers to package once, instead of "once for each distribution").
And you've missed a different point. klik-style packages ideally are to be installed by end users, not administrators.
Autopackage is about empowering users not just administrators. A user can go to the homepage for [insert random application here], download the autopackage file provided there by the developers, then just double click to run it and up comes a little installer that checks and resolves dependencies. One of the key points of Autopackage is for binaries to be relocatable. That means a non-root user can still install an autopackaged file - it just gets installed to their home directory instead of systemwide. Autopackage is not meant to manage a distribution - Debian and Redhat and SuSE already do that pretty well. It is about providing a way for extra third party application not already in the distribution to be easily installed by users.
I personally disagree with your above assessment -- the Mac OS X style of program installation and packaging is exactly what Linux should be striving for. In this configuration, a single application package can contain executable forks for multiple operating systems/distributions in a single package, which can be stored in a disk image and "installed" merely by dragging and dropping it into its target directory. Everything that is part of the program is then part of the package itself -- there is no need for an application to pollute the rest of the system by dropping files all over the place. Deletion is as simple as deleting the program icon/directory, and presto -- it's gone.
I think I've already written on tract about different systems for handling installation, and the pros and cons thereof, but that was in comparison to Windows. It looks as if it is time to discuss MacOS X.
Yes the OS X system is beguilingly simple in its ease of use. Drag and drop, multiple architectures in one package, no files strewn across the file system for each package, clean and simple. This does have its drawbacks though. One drawaback is shared libraries. MacOS X largely gets around this issue by having a huge monoloithic, heavily standardised base set of libraries to do, well, most everything. That core set of libraries is religiously controlled by Apple, and no one tinkers or changes it unless they buy the latest upgrade from Apple. That means application developers have a nice fixed set of shared libraries they can link to without having to worry about dependencies. Of course, anything outside that base set of libraries either has to reinvent the wheel each time, or have multiple copies of the same library not being shared between apps. Multiple copies of the same library has a few problems, the biggest being that it tends to hog more RAM than needed, and for security purposes there's no central place to upgrade/fix the library. Still the end result still works pretty well, and as you say, it's a ncie system to use. It is worth noting, however, that Apple themselves are moving away from App Folders and tend to have installer programs for even their own applications now.
So why can't Linux just do like Apple? There is no core set of libraries that everyone can be fully expected to have. Contrary to popular opinion this is less to do with the "Desktop War" between GNOME and KDE, and more to do with the release early, release often philosophy of open source. New versions of widget toolkits, CD backend libraries, and who knows what come out with startling regularity: Core libraries are a moving target. This is, of course, good in that open source software is continuing to advance and improve at a very impressive rate, and everyone can develop against the very latest if they want to. It's bad for installers though, because you don't have a 100% locked down "This Is How It Shall Be" set of shared libraries. This will not change. Open source is always going to be release early, release often, and developers of open source apps are always going to try and develop against the cutting edge of code. At the same time, because there is so much code out there, freely redistributable, there is a lot more shared code, and hence a lot more shared libraries that cover all manner of obscure things. Again, that's good, but again, its an issue for installation. That won't change either though - this is open source, so everything will be open and code reuse will be rampant (that's part of the point really!).
At it's core open source simply has philosophic issues that make App Folders something that just won't fit in with the open source world. Don't despair though, there's no reason a drag and drop front end that makes RPMs or DEBs look like App Folders can't be written - it simply interacts with the package database instead of directly with the filesystem. The visible results for users can be made to look identical.
As to how to actually handle software installation
Thats all fine and dandy but they have all of eight "packages" to install.
Is there a seperate package repoisitory somewhere?
They have so few packages because they are still in development on the packaging system. As I said, an application (or library) developer does need to make some changes to the code to make it autopackage ready. The changes are small, and are very little work, but they do need to be made.
As to other repositories - anyone can set up their own autopackage repositiory, so a third party software developer can simply set one up when they package their software. The end result is meant to be akin to the Windows way of downloading and running a package, but with the added bonus that it resolves dependencies too.
For now Autopackage is something for developers, not users - anybody writing code that they want to package up themselves for people to download ought to be looking at autopackage and using that for their packaging needs instead of RPM, or DEB. Once that starts happening you'll find a lot more applications available as autopackages, and it will start being very useful for users too.
Seriously though, just being able to click on a link, save to a directory, and run a program, is such a nice thing. I don't care how it is bundled up, just make the darn thing run!
This is actually a much harder problem that you might think. There are a few different solutions. The Windows solution has been a combination of trying to bolt down a core set of libraries that everyone can be expected to have, and generally completely ignoring dependencies/shared libraries and letting the installers either trample each other, or install multiple versions of the same thing in different places. It kind of works, but does have drawbacks.
On Linux you could effectively do this by just having all packages statically linked, or have each package bundle up its own versions of all the libraries it will ever need. Neither is a very efficient solution for either disk space, or more importantly RAM (which is where shared libraries really start to earn their keep). The problem is partly that open source has a release early, release often approach, which means the base set of libraries (which Microsoft simply bolts down) tends to be an ever moving target (Microsoft simply does everything in huge upgrade jumps every now and then instead... except for a few things like DirectX). The other half of the problem is that with all that source code out there being shared freely there's an awful lot more code reuse and a much broader range of shared libraries and hence dependencies. This is a good thing most of the time, but causes issues for installing software.
Linux got around these dependency issues by having distributions which package up all the dependencies for you. This works very well, especially with apt, apt-rpm, yum, portage, and all the other fun dependency resolving tools, but has one drawback: If you aren't installing a distribution provided package the system has a lot more trouble tracking (and especially resolving) your dependencies. That means installing and maintaining a Linux system is easy, but adding new software from third parties can be a pain in the ass. Debian and Gentoo attempt to solve this dilemma by havign so many packages available from the distribution that you don't want for anything. As well as this works, it again isn't quite a complete solution.
Which finally brings us around to the open source attempts to try and provide systems to allow third parties to package software. The principle now is: You let the distribution do the hard yards of installing and maintaining the syste with their packaging and dependency resolving systems, and simply provide some distribution neutral package format that can still slot in amongst all of this. There are several solutions, each taking a slightly different approach such as ZeroInstall and Autopackage. They are still in the works, but look to have some surprisingly good solutions. They are definitely worth a look.
So, in summary, Windows manages to have their system by: (1) Locking you down on base libraries, and having a slow upgrade cycle on those. (2) Windows developers not sharing as much code, and not caring about actually sharing libraries even when they do.
That is a perfectly valid solution, and it does work, but its never going to fit with open source, which has a pretty fast developing set of base libraries (which is a good thing), a lot more emphasis on code sharing, and an eye for efficiency. That doesn't mean open source can't have easy to install software (it already does for anything distribution packaged, and various solutions for third party software are well on the way), merely that, because of some fundamental philosophic tenets of open source, it is a harder problem than on Windows, and requires more cunning solutions.
There is just one area where linux does have a problem when it comes to installing programs and that's when the program is not provided by the distribution.
Unfortunately I don't think klik, as nice as it is, is quite the solution to this. I would suggest, instead, that Autopackage is a far better solution for providing a means for installing third party packages. The people writing autopackage have spent much time carefully considering the difficulties involved, and have some very cunning solutions to some of the problems.
What does Autopackage do well? For starters it does the basic things that you'd expect well - it's got a nice GUI installer, it can fall back to a console installer, and it nicely wraps up a binary package in a "download and run it to install it" system. It has other bonuses that are more subtle, but for third party packages, suprisingly necessary. For starters it is distribution neutral, but at the same time does dependency checking and resolution. That's not so easy if you actually think about what it requires.
Autopackage is, of course, still in development. The really nice features (integrating in with rpm and dpkg databases etc.) aren't coming for a very long time yet. For now though it does work, and can install packages. If you're writing software it may be worth your while to look at what Autopackage asks of developers (you do need to do a little work to make code autopackageable) and keep it in mind as you go.
Many many people are descended from the founders of the Mormon church. Honestly, check how many wives, and how many children they had - some of them had as many as 50 children (via 20 or so wives). Do that for a few of generations while polygamy is still acceptable and you could end up with over 100,000 descendants...
I think knowingly teaching children something that is false is worthy of some sort of warning...
You mean, akin to the way we teach then Newtonian mechanics, then General Relativity, both of which we know to be wrong without putting warning stickers on books? Or how about basic economics? each progressive year of economics amounts to being told "All that stuff we told you last year... It isn't entirely true. Here's the real version..." No warnings on Economics textbooks either. It happens all the time, and we simply expect children (and teachers!) to be aware that what they're being taught is the older simpler theory so they can build toward the cutting edge.
What a ridiculous comment. People aren't in disagreement over laws of physics, they are in disagreement over evolution. Duh.
Tell that to the Flat Earth Society. They're pretty certain our "laws of physics" which are taught as fact are "just a theory" and probably shouldn't be taught in schools.
Yeah, right. I've seen heaps of stuff evolve. I am of course, very very very very old.
Not everything lives and breeds on the same timescale as humans. Evolution has been observed in a variety of creatures - naturally mostly those with very short breeding cycles such as insects and bacteria.
The best way around someone who is convinced that it is too hard is to select a good "hard" problem and then help them do it - they key is to provide as little help as possible; more just cajoling and encouranging ("yeah, that's the right idea, keep going with that" etc.) as they go. Once they have a few problems under their belt they start to decide its not so bad.
Most often it is multistep problems that are perceived as "hard", which often means basic algebra or related problems. The catch is that more often than not people actually know what to do they're just afraid and lack the confidence to do it, so they don't try and immediately get bogged down. They're afraid of doing the wrong thing, or heading down a dead end. All you really have to do is give them the encouragement to keep trying, and take the next step.
Lastly, no need to end it there... why not show some other cool things in ultra-advanced physics?
Usually the reason is that, to understand it properly you need some "ultra-advanced" math. Not that the mathematics required is actually all that hard - if we actually tried teaching some of the basics of it to kids at a young age I think they'd manage fine - mostly it's just things you won't encounter until advanced University study (modern algebra: groups, rings, fields, algebras etc., and differential geometry: where calculus starts to make sense). Without the math you're just blithely glossing over the whole thing. No, you don't need to understand it completely, but just consider how misunderstood quantum physics is by the average person - it's precisely because they get nothing but the simplified explanations which, in the end, badly misrepresent the whole concept.
Enthusiasm for the subject on the part of the teacher is worth more than a world of interpretive dances and rap tunes.
Absolutely!
I'm a professional mathematician. I've had to help a lot of people with their math, and there seems to be a pretty common problem: A bad teacher. Oddly, if you ask most people, they actually enjoyed math for a while, then had a bad teacher and they fell behind or were otherwise discouraged, found it hard, and stopped enjoying it. More often than not the "bad teacher" occurs in early primary school. Ask a few questions about why the teacher was bad and it can be easily tracked to a complete lack of enthusiasm and interest in the subject. They teach it in the most rote, boring way possible, because they (the teacher!) doesn't really want to be doing it. The reason is easy enough: The majority of people who have an interest in primary education are the sort of people who hated math at school. They then help instill this attitude in all the impressionable young kids. Attitude is infectious, especially to young minds, and someone who doesn't care about math will teach the kids not to care either.
The fact is, kids are taught that mathematics is hard and that mathematics is boring from a very young age. Tell people that it is easy, and that they can do it, and present it with a little enthusiasm and interest, and people do get interested in mathematics again. I've had little difficulty in getting people interested in mathematics no matter how old they are - all you have to do is break through the instilled "it's hard and it's boring" attitude, there are no gimmicks required.
I must admit that Sin City is one of the few upcoming "comic book adaptations" that I'm actually contemplating seeing. Most everything else looks to be drivel in the same mould as Daredevil and Hulk. Comic book based films haven't generally proved to be as bad films based on computer games, but they do seem to do a fine job of butchering them none the less. The problem mostly seems to be that the filmmakers don't seem to get the comics - they seem to presume that if you translate the characters and something resembling the storylines over they've got all they need. What they lack is the feel, the spirit, the essence, the thing that gave the comic interest and vitality. I have to credit Sin City, because from what I've seen of the previews, at least they're trying to actually translate the feel and the style to screen. Whether it works is yet to be seen, but at least it doesn't look like every other standard Hollywood film.
It's the geothermal power that Iceland has in abundance that's a big help here. There's absolutely no shortage of it available. I guess the key is that Iceland has made full use of it for their energy needs. Not all countries have it quite so easy with readily available energy sources, making the 70% of energy needs from green power a little harder to attain. Then again, a few steps in the direction of energy efficiency could actually make significant impact in some of the countries guilty of rather conspicuous consumption when it comes to energy (not pointing any fingers or anything...)
It is good to see countries taking positive steps though: if you have a surfeit of electrical power readily available, why not make the move to hydrogen powered transport? Hopefully a few other countries that are naturally well stocked in clean electricity generation (eg. those with a good supply of, for example, hydroelectric power) can make similar moves. The road ahead looks like it will be an interesting one.
I'm asserting that if the objectification is roughly equal, then it isn't a "woman's issue" in that it applies to everyone equally.
I think it is the manner and intent of the objectification that women are finding offensive. The "big brawny men" in the games aren't as overtly and pointlessly sexualised as the women. I suspect if the men were portrayed wearing extremely suggestive leather outfits, prominent and oversized (and carefully animated) codpieces, and all the animations tended to involve splyed legs to show off the carefully animated penis wobbles and endless suggestive hip movements... well, I suspect guys wouldn't be quite so happy with such characters.
The biggest market for video games are males aged 12-25. Big breasted women helps sell games to this demographic. That is all.
Had you considered that males 12-25 year olds make up the biggest market in a large part because that's who games are targetted for? Females aged 12-25 are about as large a potential market (just witness the effectiveness of various popular "music" campaigns targetted at such audiences, or likewise films), there simply aren't very many games that currently interest them to quite the same degree. This is not necessarily because they are not interested in computer games at all... they are simply not as interested in the current crop of games. If all the films were nothing but mass market drivel for 15 year old boys (they way most games are) you'd be claiming girls aren't interested in movies.
The truth is that games are a fairly new medium really, and game makers have found an early market and are tapping it as much as they can possibly manage. Eventually games, in general, will evolve, grow, and become more interestin to a much broader demographic. Current games are a long way from that however.
Occasionally it is explicitly stated in the message, most often not, but you can usually, at the start of the conversation state that you don't want your call either monitored or recorded. It is surprising how often the person at the other end will agree and do something about it (I regularly make a request to not be monitored or recorded in such situations). If they refuse... well, just demand to talk to someone who will allow your call to not be monitored.
As to whether they actually do stop any recording or monitoring... You can never know. They are legally bound to warn you that you may be monitored or recorded however, so if the person at the other end agrees to turn off all monitoring and recording and fails to do so, that has consequences should it ever come to light. It's the same as monitoring your call without telling you... which many places may be doing anyway. If you want to be ultra-paranoid, don't use the phone. If you just want a little privacy, ask for any monitoring to be disabled.
Apparently the servers to serve up the server load graph couldn't handle the load.
Ever vigilant, the BBC seems to have noted the influx and taken action. After initially failing for me, it now seems to be working again.
Oops. I was about to look up on their duty roster as to who had done the fine work, but alas, the next load of slashdotters seem to have arrived, and the page is again down. At least they're trying...
Been predicted over and over again, but "major inroads"? Linux will grow gradually, but I can't see how he missed a glaring hole: Linux wireless support. My prediction for 2005 would have been wireless drivers for Linux that work just as easily as the built in networking drivers we have now.
This has always been a chicken and egg situation with hardware support for Linux. Anything that is "fringe" appears to be poorly supported - the fringe is constantly moving though. I remember a time when you had to check a little carefully when buying network cards as Linux support on some chipsets was dodgy at best. The last network card I bought came complete with a Penguin logo on the box, right next to the Windows and Mac logos (and they kindly included OpenOffice.org and Gimp on the drivers CD). Video cards and sound cards also used to be the stuff of nightmares if you had anything that wasn't quite normal. These days they all just work with most modern distros.
So yes, for now wireless support is a little lacking, but as more people use Linux, and hence more people are interested in wireless support for Linux you'll see more kernel hackers writing drivers and more support from wireless manufacturers resulting in pretty broad, reliable wireless support on Linux.
Linux inroads to the desktop do have to come first though. Without desktop Linux making greater inroads there simply won't be enough demand for Linux wireless support to ensure it gets the kind of attention it needs. The desktop is coming, slowly, and I think Cringely is right, this year will see significant inroads - not a revolution, not even much of a dent in total marketshare, mostly just a change in perception of Linux into something that is viable on average desktops.
Have patience. While progress has been a little slow at times, the one thing is has been is steady. Sit back and look at Desktop Linux from 5 or 6 years ago. Try loading up a system with Redhat 6 (or even worse Redhat 5 or older). Things have actually come a remarkably long way in a relatively short time.
Does anyone want to enlighten me as to how a 15 line P2P app means that it is pointless and silly to ban them?
The point is that a ban would be ridiculously hard to enforce as pretty much anyone could write a new P2P app, which could quickly rise to popularity. You'd be fighting an endless battle with no hop of victory unless you start putting serious restrictions on compilers etc. at which stage... well...
Slashdot Mirror
The why are all the "supported distributions" Debian based ones, and the documentation page on "Using with Other Distributions" only lists SuSE as non Debian based, says it is "harder to support" and then has a long set of instructions for what you need to do to make it work? That does not sound like easy installation to me... it sounds like rather painfully difficult installation for any non Debian based distributions.
Klik is a very nice system, and it works admirably for Debian based systems, but ostensibly its just providing Debian packages the same as the Debian repository. Any packages it provides that aren't already in the Debian repository have been packaged for Debian. Therefore it isn't really a solution to third party packaging issues (which was the original point I was replying to).
Jedidiah.
Sorry, typo:
It does not solve what is the real difficulty with installing Linux software: Installing something that has not been prepackaged for you by your distribution.
Let's be clear then: Klik is fantastic if you are installing a package from Debian. Klik is completely useless to you if you are running SuSE, Fedora, Mandrake, Gentoo, or any other non Debian based distribution. Klik makes installing Debian packages easy, but so does apt and Synaptic (in a different way). It does not solve what is the real difficulty with installing Linux software: Installing something that has been prepackaged for you by your distribution. Installing new software on Debian is trivial, and Klik adds a convenient new layer to that by making it accessible to users who don't have root access. It doesn't address the problem that is always brought up when people claim about hard to install software on Linux. Read some of the complaints about Linux from Windows and Mac users. Once your want something not prepacked by your distribution for you, you're pretty much back to compiling it yourself. It is this that Autopackage hopes to solve, while at the same time making user installs of software easy.
Jedidiah.
completely missed the point.
Then we're talking around each other, because you seem to have missed my point.
Debian's "easy" system isn't easy because of its size (as the autopackage faq suggests) but rather because of their strict adherence to policy standards.
We're talking about installing some software. It is "easy" to install software on Debian if it is in the Debian package repository. If it is not, then how exactly are you planning on installing it? Compile from source? Not "easy". Download a third party provided DEB package? That ought to work, but that's hardly easy for the developer who has to provide a DEB package, a Fedora RPM, a SuSE RPM, a mandrake RPM etc., and then there's the issue that maybe the DEB was for Ubuntu and linked against some libraries in Ubuntu that aren't in Debian stable yet. In short, installing software that is not in Debian's repositories is hard. This mostly doesn't matter because Debian's repositories are BIG so the odds of wanting to install something that isn't there are rather small.
You can discuss policy standards all you like, but in the end if the software isn't in Debian, it isn't likely to be following those standards.
Let's be clear anyway: Autopackage is not a replacement for dpkg, apt, and all the usual Debian goodness. It is complementary to all of that, and is meant to provide an easy way for those "not in the Debian repository" packages to still be easy to install (and at the same time allow developers to package once, instead of "once for each distribution").
And you've missed a different point. klik-style packages ideally are to be installed by end users, not administrators.
Autopackage is about empowering users not just administrators. A user can go to the homepage for [insert random application here], download the autopackage file provided there by the developers, then just double click to run it and up comes a little installer that checks and resolves dependencies. One of the key points of Autopackage is for binaries to be relocatable. That means a non-root user can still install an autopackaged file - it just gets installed to their home directory instead of systemwide. Autopackage is not meant to manage a distribution - Debian and Redhat and SuSE already do that pretty well. It is about providing a way for extra third party application not already in the distribution to be easily installed by users.
Jedidiah.
I personally disagree with your above assessment -- the Mac OS X style of program installation and packaging is exactly what Linux should be striving for. In this configuration, a single application package can contain executable forks for multiple operating systems/distributions in a single package, which can be stored in a disk image and "installed" merely by dragging and dropping it into its target directory. Everything that is part of the program is then part of the package itself -- there is no need for an application to pollute the rest of the system by dropping files all over the place. Deletion is as simple as deleting the program icon/directory, and presto -- it's gone.
I think I've already written on tract about different systems for handling installation, and the pros and cons thereof, but that was in comparison to Windows. It looks as if it is time to discuss MacOS X.
Yes the OS X system is beguilingly simple in its ease of use. Drag and drop, multiple architectures in one package, no files strewn across the file system for each package, clean and simple. This does have its drawbacks though. One drawaback is shared libraries. MacOS X largely gets around this issue by having a huge monoloithic, heavily standardised base set of libraries to do, well, most everything. That core set of libraries is religiously controlled by Apple, and no one tinkers or changes it unless they buy the latest upgrade from Apple. That means application developers have a nice fixed set of shared libraries they can link to without having to worry about dependencies. Of course, anything outside that base set of libraries either has to reinvent the wheel each time, or have multiple copies of the same library not being shared between apps. Multiple copies of the same library has a few problems, the biggest being that it tends to hog more RAM than needed, and for security purposes there's no central place to upgrade/fix the library. Still the end result still works pretty well, and as you say, it's a ncie system to use. It is worth noting, however, that Apple themselves are moving away from App Folders and tend to have installer programs for even their own applications now.
So why can't Linux just do like Apple? There is no core set of libraries that everyone can be fully expected to have. Contrary to popular opinion this is less to do with the "Desktop War" between GNOME and KDE, and more to do with the release early, release often philosophy of open source. New versions of widget toolkits, CD backend libraries, and who knows what come out with startling regularity: Core libraries are a moving target. This is, of course, good in that open source software is continuing to advance and improve at a very impressive rate, and everyone can develop against the very latest if they want to. It's bad for installers though, because you don't have a 100% locked down "This Is How It Shall Be" set of shared libraries. This will not change. Open source is always going to be release early, release often, and developers of open source apps are always going to try and develop against the cutting edge of code. At the same time, because there is so much code out there, freely redistributable, there is a lot more shared code, and hence a lot more shared libraries that cover all manner of obscure things. Again, that's good, but again, its an issue for installation. That won't change either though - this is open source, so everything will be open and code reuse will be rampant (that's part of the point really!).
At it's core open source simply has philosophic issues that make App Folders something that just won't fit in with the open source world. Don't despair though, there's no reason a drag and drop front end that makes RPMs or DEBs look like App Folders can't be written - it simply interacts with the package database instead of directly with the filesystem. The visible results for users can be made to look identical.
As to how to actually handle software installation
Thats all fine and dandy but they have all of eight "packages" to install.
Is there a seperate package repoisitory somewhere?
They have so few packages because they are still in development on the packaging system. As I said, an application (or library) developer does need to make some changes to the code to make it autopackage ready. The changes are small, and are very little work, but they do need to be made.
As to other repositories - anyone can set up their own autopackage repositiory, so a third party software developer can simply set one up when they package their software. The end result is meant to be akin to the Windows way of downloading and running a package, but with the added bonus that it resolves dependencies too.
For now Autopackage is something for developers, not users - anybody writing code that they want to package up themselves for people to download ought to be looking at autopackage and using that for their packaging needs instead of RPM, or DEB. Once that starts happening you'll find a lot more applications available as autopackages, and it will start being very useful for users too.
Jedidiah.
Seriously though, just being able to click on a link, save to a directory, and run a program, is such a nice thing. I don't care how it is bundled up, just make the darn thing run!
This is actually a much harder problem that you might think. There are a few different solutions. The Windows solution has been a combination of trying to bolt down a core set of libraries that everyone can be expected to have, and generally completely ignoring dependencies/shared libraries and letting the installers either trample each other, or install multiple versions of the same thing in different places. It kind of works, but does have drawbacks.
On Linux you could effectively do this by just having all packages statically linked, or have each package bundle up its own versions of all the libraries it will ever need. Neither is a very efficient solution for either disk space, or more importantly RAM (which is where shared libraries really start to earn their keep). The problem is partly that open source has a release early, release often approach, which means the base set of libraries (which Microsoft simply bolts down) tends to be an ever moving target (Microsoft simply does everything in huge upgrade jumps every now and then instead... except for a few things like DirectX). The other half of the problem is that with all that source code out there being shared freely there's an awful lot more code reuse and a much broader range of shared libraries and hence dependencies. This is a good thing most of the time, but causes issues for installing software.
Linux got around these dependency issues by having distributions which package up all the dependencies for you. This works very well, especially with apt, apt-rpm, yum, portage, and all the other fun dependency resolving tools, but has one drawback: If you aren't installing a distribution provided package the system has a lot more trouble tracking (and especially resolving) your dependencies. That means installing and maintaining a Linux system is easy, but adding new software from third parties can be a pain in the ass. Debian and Gentoo attempt to solve this dilemma by havign so many packages available from the distribution that you don't want for anything. As well as this works, it again isn't quite a complete solution.
Which finally brings us around to the open source attempts to try and provide systems to allow third parties to package software. The principle now is: You let the distribution do the hard yards of installing and maintaining the syste with their packaging and dependency resolving systems, and simply provide some distribution neutral package format that can still slot in amongst all of this. There are several solutions, each taking a slightly different approach such as ZeroInstall and Autopackage. They are still in the works, but look to have some surprisingly good solutions. They are definitely worth a look.
So, in summary, Windows manages to have their system by:
(1) Locking you down on base libraries, and having a slow upgrade cycle on those.
(2) Windows developers not sharing as much code, and not caring about actually sharing libraries even when they do.
That is a perfectly valid solution, and it does work, but its never going to fit with open source, which has a pretty fast developing set of base libraries (which is a good thing), a lot more emphasis on code sharing, and an eye for efficiency. That doesn't mean open source can't have easy to install software (it already does for anything distribution packaged, and various solutions for third party software are well on the way), merely that, because of some fundamental philosophic tenets of open source, it is a harder problem than on Windows, and requires more cunning solutions.
Jedidiah.
There is just one area where linux does have a problem when it comes to installing programs and that's when the program is not provided by the distribution.
Unfortunately I don't think klik, as nice as it is, is quite the solution to this. I would suggest, instead, that Autopackage is a far better solution for providing a means for installing third party packages. The people writing autopackage have spent much time carefully considering the difficulties involved, and have some very cunning solutions to some of the problems.
What does Autopackage do well? For starters it does the basic things that you'd expect well - it's got a nice GUI installer, it can fall back to a console installer, and it nicely wraps up a binary package in a "download and run it to install it" system. It has other bonuses that are more subtle, but for third party packages, suprisingly necessary. For starters it is distribution neutral, but at the same time does dependency checking and resolution. That's not so easy if you actually think about what it requires.
Autopackage is, of course, still in development. The really nice features (integrating in with rpm and dpkg databases etc.) aren't coming for a very long time yet. For now though it does work, and can install packages. If you're writing software it may be worth your while to look at what Autopackage asks of developers (you do need to do a little work to make code autopackageable) and keep it in mind as you go.
Jedidiah.
Many many people are descended from the founders of the Mormon church. Honestly, check how many wives, and how many children they had - some of them had as many as 50 children (via 20 or so wives). Do that for a few of generations while polygamy is still acceptable and you could end up with over 100,000 descendants...
Jedidiah.
I think knowingly teaching children something that is false is worthy of some sort of warning...
You mean, akin to the way we teach then Newtonian mechanics, then General Relativity, both of which we know to be wrong without putting warning stickers on books? Or how about basic economics? each progressive year of economics amounts to being told "All that stuff we told you last year... It isn't entirely true. Here's the real version..." No warnings on Economics textbooks either. It happens all the time, and we simply expect children (and teachers!) to be aware that what they're being taught is the older simpler theory so they can build toward the cutting edge.
Jedidiah.
Want to make that deal? Schools teach about God and we'll put stickers on The Bible and other books in that class for you?
I take it then that you're all for altering the pledge of allegiance to:
"...One nation unde God, which is a mythical entity, not a fact, indivisible..."
These arguments are all so silly.
Jedidiah.
What a ridiculous comment. People aren't in disagreement over laws of physics, they are in disagreement over evolution. Duh.
Tell that to the Flat Earth Society. They're pretty certain our "laws of physics" which are taught as fact are "just a theory" and probably shouldn't be taught in schools.
Jedidiah.
Yeah, right. I've seen heaps of stuff evolve. I am of course, very very very very old.
Not everything lives and breeds on the same timescale as humans. Evolution has been observed in a variety of creatures - naturally mostly those with very short breeding cycles such as insects and bacteria.
Jedidiah.
The best way around someone who is convinced that it is too hard is to select a good "hard" problem and then help them do it - they key is to provide as little help as possible; more just cajoling and encouranging ("yeah, that's the right idea, keep going with that" etc.) as they go. Once they have a few problems under their belt they start to decide its not so bad.
Most often it is multistep problems that are perceived as "hard", which often means basic algebra or related problems. The catch is that more often than not people actually know what to do they're just afraid and lack the confidence to do it, so they don't try and immediately get bogged down. They're afraid of doing the wrong thing, or heading down a dead end. All you really have to do is give them the encouragement to keep trying, and take the next step.
Jedidiah.
Lastly, no need to end it there... why not show some other cool things in ultra-advanced physics?
Usually the reason is that, to understand it properly you need some "ultra-advanced" math. Not that the mathematics required is actually all that hard - if we actually tried teaching some of the basics of it to kids at a young age I think they'd manage fine - mostly it's just things you won't encounter until advanced University study (modern algebra: groups, rings, fields, algebras etc., and differential geometry: where calculus starts to make sense). Without the math you're just blithely glossing over the whole thing. No, you don't need to understand it completely, but just consider how misunderstood quantum physics is by the average person - it's precisely because they get nothing but the simplified explanations which, in the end, badly misrepresent the whole concept.
Jedidiah.
Enthusiasm for the subject on the part of the teacher is worth more than a world of interpretive dances and rap tunes.
Absolutely!
I'm a professional mathematician. I've had to help a lot of people with their math, and there seems to be a pretty common problem: A bad teacher. Oddly, if you ask most people, they actually enjoyed math for a while, then had a bad teacher and they fell behind or were otherwise discouraged, found it hard, and stopped enjoying it. More often than not the "bad teacher" occurs in early primary school. Ask a few questions about why the teacher was bad and it can be easily tracked to a complete lack of enthusiasm and interest in the subject. They teach it in the most rote, boring way possible, because they (the teacher!) doesn't really want to be doing it. The reason is easy enough: The majority of people who have an interest in primary education are the sort of people who hated math at school. They then help instill this attitude in all the impressionable young kids. Attitude is infectious, especially to young minds, and someone who doesn't care about math will teach the kids not to care either.
The fact is, kids are taught that mathematics is hard and that mathematics is boring from a very young age. Tell people that it is easy, and that they can do it, and present it with a little enthusiasm and interest, and people do get interested in mathematics again. I've had little difficulty in getting people interested in mathematics no matter how old they are - all you have to do is break through the instilled "it's hard and it's boring" attitude, there are no gimmicks required.
Jedidiah.
I'm certainly looking forward to Sin City, tho.
I must admit that Sin City is one of the few upcoming "comic book adaptations" that I'm actually contemplating seeing. Most everything else looks to be drivel in the same mould as Daredevil and Hulk. Comic book based films haven't generally proved to be as bad films based on computer games, but they do seem to do a fine job of butchering them none the less. The problem mostly seems to be that the filmmakers don't seem to get the comics - they seem to presume that if you translate the characters and something resembling the storylines over they've got all they need. What they lack is the feel, the spirit, the essence, the thing that gave the comic interest and vitality. I have to credit Sin City, because from what I've seen of the previews, at least they're trying to actually translate the feel and the style to screen. Whether it works is yet to be seen, but at least it doesn't look like every other standard Hollywood film.
Jedidiah.
It's the geothermal power that Iceland has in abundance that's a big help here. There's absolutely no shortage of it available. I guess the key is that Iceland has made full use of it for their energy needs. Not all countries have it quite so easy with readily available energy sources, making the 70% of energy needs from green power a little harder to attain. Then again, a few steps in the direction of energy efficiency could actually make significant impact in some of the countries guilty of rather conspicuous consumption when it comes to energy (not pointing any fingers or anything...)
It is good to see countries taking positive steps though: if you have a surfeit of electrical power readily available, why not make the move to hydrogen powered transport? Hopefully a few other countries that are naturally well stocked in clean electricity generation (eg. those with a good supply of, for example, hydroelectric power) can make similar moves. The road ahead looks like it will be an interesting one.
Jedidiah.
I'm asserting that if the objectification is roughly equal, then it isn't a "woman's issue" in that it applies to everyone equally.
I think it is the manner and intent of the objectification that women are finding offensive. The "big brawny men" in the games aren't as overtly and pointlessly sexualised as the women. I suspect if the men were portrayed wearing extremely suggestive leather outfits, prominent and oversized (and carefully animated) codpieces, and all the animations tended to involve splyed legs to show off the carefully animated penis wobbles and endless suggestive hip movements... well, I suspect guys wouldn't be quite so happy with such characters.
Jedidiah.
The biggest market for video games are males aged 12-25. Big breasted women helps sell games to this demographic. That is all.
Had you considered that males 12-25 year olds make up the biggest market in a large part because that's who games are targetted for? Females aged 12-25 are about as large a potential market (just witness the effectiveness of various popular "music" campaigns targetted at such audiences, or likewise films), there simply aren't very many games that currently interest them to quite the same degree. This is not necessarily because they are not interested in computer games at all... they are simply not as interested in the current crop of games. If all the films were nothing but mass market drivel for 15 year old boys (they way most games are) you'd be claiming girls aren't interested in movies.
The truth is that games are a fairly new medium really, and game makers have found an early market and are tapping it as much as they can possibly manage. Eventually games, in general, will evolve, grow, and become more interestin to a much broader demographic. Current games are a long way from that however.
Jedidiah.
Occasionally it is explicitly stated in the message, most often not, but you can usually, at the start of the conversation state that you don't want your call either monitored or recorded. It is surprising how often the person at the other end will agree and do something about it (I regularly make a request to not be monitored or recorded in such situations). If they refuse... well, just demand to talk to someone who will allow your call to not be monitored.
As to whether they actually do stop any recording or monitoring... You can never know. They are legally bound to warn you that you may be monitored or recorded however, so if the person at the other end agrees to turn off all monitoring and recording and fails to do so, that has consequences should it ever come to light. It's the same as monitoring your call without telling you... which many places may be doing anyway. If you want to be ultra-paranoid, don't use the phone. If you just want a little privacy, ask for any monitoring to be disabled.
Jedidiah.
And it seems it is back up again, so kudos to:
Chris
Craig
Damion
Declan
Jenny
Jon
Will
Who seem to have the duty for today.
Jedidiah.
Apparently the servers to serve up the server load graph couldn't handle the load.
Ever vigilant, the BBC seems to have noted the influx and taken action. After initially failing for me, it now seems to be working again.
Oops. I was about to look up on their duty roster as to who had done the fine work, but alas, the next load of slashdotters seem to have arrived, and the page is again down. At least they're trying...
Jedidiah.
Been predicted over and over again, but "major inroads"? Linux will grow gradually, but I can't see how he missed a glaring hole: Linux wireless support. My prediction for 2005 would have been wireless drivers for Linux that work just as easily as the built in networking drivers we have now.
This has always been a chicken and egg situation with hardware support for Linux. Anything that is "fringe" appears to be poorly supported - the fringe is constantly moving though. I remember a time when you had to check a little carefully when buying network cards as Linux support on some chipsets was dodgy at best. The last network card I bought came complete with a Penguin logo on the box, right next to the Windows and Mac logos (and they kindly included OpenOffice.org and Gimp on the drivers CD). Video cards and sound cards also used to be the stuff of nightmares if you had anything that wasn't quite normal. These days they all just work with most modern distros.
So yes, for now wireless support is a little lacking, but as more people use Linux, and hence more people are interested in wireless support for Linux you'll see more kernel hackers writing drivers and more support from wireless manufacturers resulting in pretty broad, reliable wireless support on Linux.
Linux inroads to the desktop do have to come first though. Without desktop Linux making greater inroads there simply won't be enough demand for Linux wireless support to ensure it gets the kind of attention it needs. The desktop is coming, slowly, and I think Cringely is right, this year will see significant inroads - not a revolution, not even much of a dent in total marketshare, mostly just a change in perception of Linux into something that is viable on average desktops.
Have patience. While progress has been a little slow at times, the one thing is has been is steady. Sit back and look at Desktop Linux from 5 or 6 years ago. Try loading up a system with Redhat 6 (or even worse Redhat 5 or older). Things have actually come a remarkably long way in a relatively short time.
Jedidiah.
Does anyone want to enlighten me as to how a 15 line P2P app means that it is pointless and silly to ban them?
The point is that a ban would be ridiculously hard to enforce as pretty much anyone could write a new P2P app, which could quickly rise to popularity. You'd be fighting an endless battle with no hop of victory unless you start putting serious restrictions on compilers etc. at which stage... well...
Jedidiah.