I've never tried to update Knoppix, but I've never had a problem updating KDE under Debian.
At a guess, Knoppix implemented some ugly hack in its version numbering which broke. Certainly the unofficial KDE packages (e.g. the KDE packages for KDE 3 back when KDE 2 was standard) had great big disclaimers saying they would not guarantee a smooth upgrade.
Interesting... This really should be modded higher than zero:-(
However you missed my point very slightly. RedHat does not swap to a competing product when they have an in-house tool that does the job. When they don't have an inhouse tool they are quite happy to take a tool from somebody else.
RedHat didn't have anything that did dependency resolution, so taking from Yellow dog seems reasonable.
The best way to answer this is to encourage you to go out and make a couple of both. But, I'll try to give you a couple starting points off the top of my head. Again, you really need to try them to see.
1) Debian packages are distributed as a.orig and a.diff. The.orig should match the upstream md5sum, and the.diff is usually small enough to read easily. This has a number of benefits: For the paranoid it is much easier to see that debian is not introducting any security holes (if you know upstream are safe, then verifying the debian package is trivial). And in debugging it is easier to determine if a bug is in a debian extension or in upstream.
2) (Technically, not an advantage to the deb format, more the tools). Debian packages obtain their version depends automatically, making the depends much more reliable. All debian packages are built by the autobuilders which start with a minimal install of debian and then only install the packages in the depends, thereby ensuring that the package will install and run with the depends that have been listed.
3) Debian packages have better support for depends, build-depends, conflicts, suggests, recommends, replaces,.... RPM has some of those but it doesn't have them all. As a package maintainer, having them all just makes life easy. Incidentially, this is an area gentoo goes better than Debian, but I digress.
4) RPM does version numbering based on either packages or files, and the automated tools make it easier to do version numbering based on files. This means that unless the package maker is skillful it is easy to end up in a RedHat equivilant of DLL hell. Generally the guys at redhat are smart enough to work around this deficiency in the file format, but it is still a problem.
5) Debian packages have a very nice handling of preinst, postinst, prerm, postrm. Having all those different scripts makes it easy for the package maintainer to do things elegantly where the RPM package maintaner has to do the same job as a bit of a hack. This is pretty much only noticed by users when something goes wrong.
6) Configuration options are handled by a standard mechanism and answers stored in a database. This all makes reconfiguration, reinstallation, transferring installation, etc. much easier. Similarly, when you upgrade, you are shown diffs of your configuration files and (new feature) can even have your modifications automatically added to the new version. RPM doesn't bother with this very much at all.
7) Virtual packages are not handled well by either format, but I would say the debian version is slightly better (because of Provides:).
8) Debian pacakges are built using standard tools (ar, tar, gzip). This means they can be created, extracted and the like on a non debian system. RPMs can be extracted using rpm2cpio, but I wouldn't like trying to create a rpm on a non redhat machine.
9) Logging of all actions is supported by deb, and you can have the logs emailed, etc. This is pretty pointless if you're just managing one machine, but with many sysadmins and many machines it is very nice. On second thought, this is more a tool benefit than a file-format benefit, so I better stop here...
Most of the deficencies in RPM can be masked by a skillful maintainer. If you build a good RPM it can be about as good as a good DEB. The key difference then is that building good RPMs is more work than building good DEBs because the debian file format contains the control structure that makes doing the job easy while the RPM format only contains the control structure that makes the job possible.
Most often the deficincies manifest themselves in userspace when you're using 3rd party RPMs. Because the package manager was not as experienced at making packages as a RH employee, the RPMs don't deal with version conflicts, depends and the like so elegantly. Contrast this with 3rd party DEBs and the file format m
Sounds good, but I'm afraid I've got way too many projects on my plate currently:-( I had to drop the last project I was working on because I just ran out of time...
If you're interested, most of the infrastructure for sending packages as deltas works, but it just needs a few more key bits (integration of a now-dead module back into apache), tweak to said module to permit precomputing of the rolling checksum, inclusion of a patch to gzip that's been floating around for years now, small tweak to wget to support the checksums (basically call rsync). Can you tell I haven't quite mentally given up on it?:(
*Giggle* debsums must be a figment of my imagination then... oh and apt-get.org must be too. Of course, with over three times the number of packages as RedHat you don't need to go elsewhere so often, but it is nice to know there's many hundreds of repositories listed. I know most of the sourceforge sites include a.rpm and not a.deb. Could it be because the package is already in debian? It's damn nice to never have to go searching for software.
Gee, I wonder what I have was smoking, that halucination has lasted for years, thanks for enlightening me! Oh, and next time, try getting a clue before you post... Hints #1: Try searching for library versioning if you want to find one of the problems with RPM. #2: yum still uses RPM and so it still has all the old problems with RPM.
The Debian packaging system works pretty much perfectly. There are some tiny problems (e.g. the way apt calls dpkg means an inopportune power-cut could leave the system in a worse state than it really should, the equivs package and the meta packages are a tad crude).
Compared to yum, Debian's system works very well. flawlessly. So why doesn't RedHat use it? I rather suspect that is because RedHat didn't invent it, and RedHat has never dropped something they invented over a superior product developed elsewhere.
Debian and the derivative distributions have this sorted perfectly. Even Gentoo has this sorted better than RedHat, even BSD (ports) solves this much better than RedHat.
Yet RedHat continues to use an inferior system, and people continue to use RedHat. For some reason, those people think it is a problem with linux, instead of a problem only present on RPM distributions. Oh well...
Linux' strength (versatility) is it's achilles heel when it comes to the desktop market.
Oh come on, how many times does this argument have to be debunked? Lets try repeating your post but saying 'computer' every time you said linux...
Sun will throw all its muscle behind it's Java Desktop to deliver a polished, cohisive system. Computers will continue to be pulled in 100 directions at once.
Computers need to stop offering Gnome, KDE, fluxbox, and 9000 other window managers, and pick a path and stick to it.
There really isn't that much of a market for people who like to dick around with 10000 different ways to close a window, each with it's own myriad of quirks and bugs. They like to plug it in, turn it on, and have it work pretty much the same way as the one in the next cubicle, or the next building.
Computers' strength (versatility) is it's achilles heel when it comes to the desktop market.
Written like that, the flaw in the argument is painfully obvious. You might have a computer in your wristwatch, in your microwave, controlling your stereo, and managing the local powerplant, but they still make perfectly good desktop machines. Why? Because somebody (Microsoft) has chosen a subset of computers and presented them as a neat little package. And guess what, just because you can have a computer running your stereo doesn't prevent microsoft offering you a computer on your desktop.
Returning to Linux, that means you should not be asking if 'linux' is ready for the desktop any more than you should be asking if 'computers' are ready for the desktop. Instead you should be asking if 'fedora', or 'mandrake', or 'linspire', or 'xandros' are ready for the desktop.
Now, the answer to that might be 'yes' or 'no' depending on your point of view, but you can see that none of these offer 10000 ways to close a window. They also go out of their way to present only one window manager (though if you know what you're doing you can change which one). Xandros even drops programs if they don't match the standard interface.
The lack of explicit answers to questions about remote linking and the like are causing increasing problems with the GPL. Currently, you can not statically link to a GPLed library, nor can you dynamically link. However I believe you can dlopen a GPLed library as well as including the functionality in another program which you communicate to via RPC, provided that your program is functionally still useful without the helper program. Further, you may not link against a GPLed appliation but you may communicate with it via RPC, TCP, etc. Finally, you only need to give a copy of the source to a person who you give a copy of the binary to. This of course means that you can put a GPLed application on your webserver and you never have to give the source to anybody if you so choose, even if you make the output freely available, or if use of your application only makes sense by remote execution. So what does 'distribute' mean in this interconnected world? If I can ssh into a box and run a binary, has it been distributed to me? What if I can run it via a web server? Or a caching proxy? And I understand you don't have to release source provided you only use the application internally, but the definition of internally has a few surprises for most lay people.
Now, did anybody follow all that? And I'm not even sure I got it all right. The next version will be long overdue.
You know, we've all heard it: Sorry, your ATI card cannot run X accelerated on your computer, and the svideo port is just a lump of metal because we licenced that technology from someone else and cannot redistribute it, even though our drivers won't work in your computer. Sorry, your nvidia card won't work in the latest kernel and would be useless to any kernel developer, because we licenced that technology from someone else and cannot redistribute it...
I'm sure I could go on, but you get the point. Imagine going out for dinner and it makes you sick because it has *shrug* powdered peanuts in it. Next time, you ask for no peanuts, only to be told "Sorry, we licenced this recipe from somebody else and do not have permission to vary it, even though the current version is useless to you". There is no way you would put up with that, at the least you would walk out.
Yet for some reason in IT we accept that excuse as if nvidia hadn't just negotiated the contract that does not permit them to redistribute only weeks beforehand. Nvidia, ATI and intel are only getting away with this excuse because we tolerate it. If we instead refuse to buy the products then you can bet the next time they negotiate licencing, all the problems disappear.
You might think we are a too small group to make a difference in this regard, but you'd be wrong. You would be right that few people use linux, and even fewer user OpenBSD, but what propotion of those people have strong influence over large IT budgets? Viewed in terms of dollars controlled instead of products sold and suddenly you're talking much bigger bikkies.
Er... can you even install office 2004 on windows 98? And assuming you can, how many things will you break in doing so?
RH6.2 is stable enough when running software designed for RH6.2. Try forcing the install of fedora softare on it and you'll have to be damn careful not to break things. You say yourself in your message that you're not upgrading because it works. Well, guess what, installing your fancy new package on it is damn close to the full upgrade you're trying to avoid.
Essentially, 6.2 = stable, FC2 = fairly stable. Upgrading from 6.2 to FC2 may break things. Installing a FC2 package on 6.2 and telling the system to pull down everything it needs, well, that'll break things too.
Curiously, the only distribution I know which will gracefully handle an extremely modern package amongnst many ancient ones is gentoo. If they ever manage to get 'gentoo stable' to the same standard as debian stable, this may be exactly what you're looking for.
1) google for e-keyboard debian package, or even e-keyboard apt repository. I generally find the standard of 3rd party apt repositories is very high.
2) (if 1) fails), download the tarball, cd to it, and type dh_make. Answer 's' to make it a simple binary package. Next type debuild. next type cd.., dpkg -i e-keyboard-version.deb
dh_make will certainly not create as high quality debian packages as the ones you'll get from an official (or even 3rd party) repository. But they're still quite good enough for a single machine.
1) You assume all slashdot readers are alike. While we are are all much more alike than a random cross-section of the population, we are far from being alike. Some of us could be seen to contribute to it while others are fighting against it.
2) You've say we're hypocrites for complaining about spam that we've caused, yet the two examples you give of us 'causing' spam have only the most tenuous causation link. Apparently by not reading the fine-print on the iPod deal we deserve to be spammed, and similarly for enjoying advantage of some flash gimmick.
The thing I see in both of these cases is that we wanted a free iPod and a free gimmick, and possibly didn't bother to read some fine print. Imagine going down to the hardware store and seeing a deal "Sign up for a free color consultation", then after the consultation you get dozens of phone calls selling products that match your color choices. You're going to be pissed, right? Essentially, you got suckered at the hardware store, and the slashdotters got suckered at the free iPod website. Yet because there was a contract of sorts in both cases, you believe it was legally ok, and therefore morally ok?
Around here, there is a provision in contract law that if the contract contains a clause which a reasonable amount of care would not have noticed, then that clause is automatically voided. Crudely put, buying a $20 phone you're not really expected to read the contract, but buying a $20,000 phone system you are, but if that contract refers to documents that weren't available at the time then you might not have been expected to read them. Now, I admit I sneered when I first heard about this -- if someone is stupid enough to sign away their rights, then I thought they deserved whatever they got -- maybe they'll learn next time. But, the older I get, the more I understand that people are busy with their own little corners of existence and are largely clueless outside those corners. So it is essential to have laws like this in order to protect people.
3) You say we contribute to the spam problem. Yet I fail to see how we have either spammed, or encouraged spammers through either financial or technical means. At worst, we have inadvertently providing them with a loophole. That doesn't count as encouraged in my book.
4) I have no idea how you're trying to draw parallels to the election.
Not quite. There is no way the mini would be able to stop before the child, or else the car would be restricted to 20 mph most of the time. Instead the mini will have to swerve to avoid the child.
The semi, OTOH, is following at a safe following distance and so by definition will be able to stop (just) before the child.
I have free access to ISI through work, but I haven't used it in years because of the awful interface. It is slow and kludgy, I can invariably find things faster using google + citeseer.
You're 100% correct (of course). But try playing with some of the best software out there sometime.
It is really amazing just how much information is in the low-res source file, encoded as slight changes in colour values. And the best software does an unbelieveable job of extracting that (making huge guesses along the way). Sure, the guesses do mean it will get it totally wrong occasionally and show things that were never there, but most of the time they're right.
Sadly, few people bother with those tests, which is really silly since I bought my last graphics card based on it being passively cooled.
Oh, and even more sadly, the one game I play is a board game, and my GF4 (MX440) can't handle it with full antialiasing (http://www.pandanet.co.jp/English/glgo/).
It seems that on their cheap boards, nvidia are dropping more hardware optimisations in exchange for making the few they have fast. Who ever heard of a board game that pushes your gfx card too hard!
There is some truth in what you're saying, but I think the idea of selling cheap software is going the way of the dodo. Essentially, the free software momement appears to result in a clone of any software that's been around for a long time and has a big userbase. Of course, software got cloned before the free software movement too, but there the clones cost a similar amount to the first product and so didn't slowly suck up the profit margins, essentially they competed fairly.
There are reasons for this, but you could think them up as easily as me. More relevant are the implications. In this case, since the grandparent was able to swap to a GPLed version tells me you've got something close to a commodity. And this means you're going to have to keep innovating, staying ahead of the GPLed version, or else users will gradully shift to the cheaper, more flexible alternative.
If you want to continue selling shrinkwrapped software as a one-man team, then I suggest you look at where the free software movement has traditionally done badly -- areas where the software cannot be totally free (due to integration with non-free data), very expensive products for a small market, etc.
But I think a more viable long-term option is to start adding software modifications/consulting and the like to your portfolio.
Of course, there is no hurry for any of this, I just expect every year will be a little harder than the one before.
Which is of course why it isn't done that way (any more). I was shown a demo of a NL project a few _years_ ago (and it was nearing the end of the project then, so no doubt there are better things now). Anyway, in the demo you write in natural english and a seperate version in the awkward syntax you just described turns up in the bottom half of the screen, much like a chat window. See, most people can read that syntax, they just can't write it.
Likewise, I find most of the pages I browse work correctly. But the sites my wife browses are a different story, and for kids it is even more of a problem.
Currently we have a near monoculture in web browsers. If you're not using IE, you're pretty damn weird and you can expect many web pages to not work.
As firefox gains in popularity, web developers will have to start writing compatable HTML/JS/etc. and as a result life will become easier for the opera users out there.
Slashdot Mirror
I've never tried to update Knoppix, but I've never had a problem updating KDE under Debian.
At a guess, Knoppix implemented some ugly hack in its version numbering which broke. Certainly the unofficial KDE packages (e.g. the KDE packages for KDE 3 back when KDE 2 was standard) had great big disclaimers saying they would not guarantee a smooth upgrade.
*shrug*
Interesting... This really should be modded higher than zero :-(
However you missed my point very slightly. RedHat does not swap to a competing product when they have an in-house tool that does the job. When they don't have an inhouse tool they are quite happy to take a tool from somebody else.
RedHat didn't have anything that did dependency resolution, so taking from Yellow dog seems reasonable.
Yes, it is possible but since it is a fairly new feature it is still marked as experimental.
The best way to answer this is to encourage you to go out and make a couple of both. But, I'll try to give you a couple starting points off the top of my head. Again, you really need to try them to see.
.orig and a .diff. The .orig should match the upstream md5sum, and the .diff is usually small enough to read easily. This has a number of benefits: For the paranoid it is much easier to see that debian is not introducting any security holes (if you know upstream are safe, then verifying the debian package is trivial). And in debugging it is easier to determine if a bug is in a debian extension or in upstream.
.... RPM has some of those but it doesn't have them all. As a package maintainer, having them all just makes life easy. Incidentially, this is an area gentoo goes better than Debian, but I digress.
1) Debian packages are distributed as a
2) (Technically, not an advantage to the deb format, more the tools). Debian packages obtain their version depends automatically, making the depends much more reliable. All debian packages are built by the autobuilders which start with a minimal install of debian and then only install the packages in the depends, thereby ensuring that the package will install and run with the depends that have been listed.
3) Debian packages have better support for depends, build-depends, conflicts, suggests, recommends, replaces,
4) RPM does version numbering based on either packages or files, and the automated tools make it easier to do version numbering based on files. This means that unless the package maker is skillful it is easy to end up in a RedHat equivilant of DLL hell. Generally the guys at redhat are smart enough to work around this deficiency in the file format, but it is still a problem.
5) Debian packages have a very nice handling of preinst, postinst, prerm, postrm. Having all those different scripts makes it easy for the package maintainer to do things elegantly where the RPM package maintaner has to do the same job as a bit of a hack. This is pretty much only noticed by users when something goes wrong.
6) Configuration options are handled by a standard mechanism and answers stored in a database. This all makes reconfiguration, reinstallation, transferring installation, etc. much easier. Similarly, when you upgrade, you are shown diffs of your configuration files and (new feature) can even have your modifications automatically added to the new version. RPM doesn't bother with this very much at all.
7) Virtual packages are not handled well by either format, but I would say the debian version is slightly better (because of Provides:).
8) Debian pacakges are built using standard tools (ar, tar, gzip). This means they can be created, extracted and the like on a non debian system. RPMs can be extracted using rpm2cpio, but I wouldn't like trying to create a rpm on a non redhat machine.
9) Logging of all actions is supported by deb, and you can have the logs emailed, etc. This is pretty pointless if you're just managing one machine, but with many sysadmins and many machines it is very nice. On second thought, this is more a tool benefit than a file-format benefit, so I better stop here...
Most of the deficencies in RPM can be masked by a skillful maintainer. If you build a good RPM it can be about as good as a good DEB. The key difference then is that building good RPMs is more work than building good DEBs because the debian file format contains the control structure that makes doing the job easy while the RPM format only contains the control structure that makes the job possible.
Most often the deficincies manifest themselves in userspace when you're using 3rd party RPMs. Because the package manager was not as experienced at making packages as a RH employee, the RPMs don't deal with version conflicts, depends and the like so elegantly. Contrast this with 3rd party DEBs and the file format m
Sounds good, but I'm afraid I've got way too many projects on my plate currently :-( I had to drop the last project I was working on because I just ran out of time...
:(
If you're interested, most of the infrastructure for sending packages as deltas works, but it just needs a few more key bits (integration of a now-dead module back into apache), tweak to said module to permit precomputing of the rolling checksum, inclusion of a patch to gzip that's been floating around for years now, small tweak to wget to support the checksums (basically call rsync). Can you tell I haven't quite mentally given up on it?
*Giggle* debsums must be a figment of my imagination then... oh and apt-get.org must be too. Of course, with over three times the number of packages as RedHat you don't need to go elsewhere so often, but it is nice to know there's many hundreds of repositories listed. I know most of the sourceforge sites include a .rpm and not a .deb. Could it be because the package is already in debian? It's damn nice to never have to go searching for software.
Gee, I wonder what I have was smoking, that halucination has lasted for years, thanks for enlightening me! Oh, and next time, try getting a clue before you post... Hints #1: Try searching for library versioning if you want to find one of the problems with RPM. #2: yum still uses RPM and so it still has all the old problems with RPM.
The Debian packaging system works pretty much perfectly. There are some tiny problems (e.g. the way apt calls dpkg means an inopportune power-cut could leave the system in a worse state than it really should, the equivs package and the meta packages are a tad crude).
Compared to yum, Debian's system works very well. flawlessly. So why doesn't RedHat use it? I rather suspect that is because RedHat didn't invent it, and RedHat has never dropped something they invented over a superior product developed elsewhere.
Debian and the derivative distributions have this sorted perfectly. Even Gentoo has this sorted better than RedHat, even BSD (ports) solves this much better than RedHat.
Yet RedHat continues to use an inferior system, and people continue to use RedHat. For some reason, those people think it is a problem with linux, instead of a problem only present on RPM distributions. Oh well...
You're 100% right. I expect matrox was closely watching nivida and when it didn't backfire for them...
:-(
I am not sure who is the most open nowadays. Perhaps ATI -- at least you can get something approximating 3D acceleration from them
Use xandros at work, use linspire at home. Or ubuntu if you want to be a little different.
RH and SuSE are trying to be many things to many people. If you want a distro is to do one thing well, then pick one that is trying to do that.
Others of us quite like the flexability that the general-purpose distros offer, but hey, if that's not your then that's cool.
Oh come on, how many times does this argument have to be debunked? Lets try repeating your post but saying 'computer' every time you said linux...
Written like that, the flaw in the argument is painfully obvious. You might have a computer in your wristwatch, in your microwave, controlling your stereo, and managing the local powerplant, but they still make perfectly good desktop machines. Why? Because somebody (Microsoft) has chosen a subset of computers and presented them as a neat little package. And guess what, just because you can have a computer running your stereo doesn't prevent microsoft offering you a computer on your desktop.
Returning to Linux, that means you should not be asking if 'linux' is ready for the desktop any more than you should be asking if 'computers' are ready for the desktop. Instead you should be asking if 'fedora', or 'mandrake', or 'linspire', or 'xandros' are ready for the desktop.
Now, the answer to that might be 'yes' or 'no' depending on your point of view, but you can see that none of these offer 10000 ways to close a window. They also go out of their way to present only one window manager (though if you know what you're doing you can change which one). Xandros even drops programs if they don't match the standard interface.
The lack of explicit answers to questions about remote linking and the like are causing increasing problems with the GPL. Currently, you can not statically link to a GPLed library, nor can you dynamically link. However I believe you can dlopen a GPLed library as well as including the functionality in another program which you communicate to via RPC, provided that your program is functionally still useful without the helper program. Further, you may not link against a GPLed appliation but you may communicate with it via RPC, TCP, etc. Finally, you only need to give a copy of the source to a person who you give a copy of the binary to. This of course means that you can put a GPLed application on your webserver and you never have to give the source to anybody if you so choose, even if you make the output freely available, or if use of your application only makes sense by remote execution. So what does 'distribute' mean in this interconnected world? If I can ssh into a box and run a binary, has it been distributed to me? What if I can run it via a web server? Or a caching proxy? And I understand you don't have to release source provided you only use the application internally, but the definition of internally has a few surprises for most lay people.
Now, did anybody follow all that? And I'm not even sure I got it all right. The next version will be long overdue.
You know, we've all heard it: Sorry, your ATI card cannot run X accelerated on your computer, and the svideo port is just a lump of metal because we licenced that technology from someone else and cannot redistribute it, even though our drivers won't work in your computer. Sorry, your nvidia card won't work in the latest kernel and would be useless to any kernel developer, because we licenced that technology from someone else and cannot redistribute it...
I'm sure I could go on, but you get the point. Imagine going out for dinner and it makes you sick because it has *shrug* powdered peanuts in it. Next time, you ask for no peanuts, only to be told "Sorry, we licenced this recipe from somebody else and do not have permission to vary it, even though the current version is useless to you". There is no way you would put up with that, at the least you would walk out.
Yet for some reason in IT we accept that excuse as if nvidia hadn't just negotiated the contract that does not permit them to redistribute only weeks beforehand. Nvidia, ATI and intel are only getting away with this excuse because we tolerate it. If we instead refuse to buy the products then you can bet the next time they negotiate licencing, all the problems disappear.
You might think we are a too small group to make a difference in this regard, but you'd be wrong. You would be right that few people use linux, and even fewer user OpenBSD, but what propotion of those people have strong influence over large IT budgets? Viewed in terms of dollars controlled instead of products sold and suddenly you're talking much bigger bikkies.
Er... can you even install office 2004 on windows 98? And assuming you can, how many things will you break in doing so?
RH6.2 is stable enough when running software designed for RH6.2. Try forcing the install of fedora softare on it and you'll have to be damn careful not to break things. You say yourself in your message that you're not upgrading because it works. Well, guess what, installing your fancy new package on it is damn close to the full upgrade you're trying to avoid.
Essentially, 6.2 = stable, FC2 = fairly stable. Upgrading from 6.2 to FC2 may break things. Installing a FC2 package on 6.2 and telling the system to pull down everything it needs, well, that'll break things too.
Curiously, the only distribution I know which will gracefully handle an extremely modern package amongnst many ancient ones is gentoo. If they ever manage to get 'gentoo stable' to the same standard as debian stable, this may be exactly what you're looking for.
1) google for e-keyboard debian package, or even e-keyboard apt repository. I generally find the standard of 3rd party apt repositories is very high.
.., dpkg -i e-keyboard-version.deb
2) (if 1) fails), download the tarball, cd to it, and type dh_make. Answer 's' to make it a simple binary package. Next type debuild. next type cd
dh_make will certainly not create as high quality debian packages as the ones you'll get from an official (or even 3rd party) repository. But they're still quite good enough for a single machine.
There are a few flaws in your analysis.
1) You assume all slashdot readers are alike. While we are are all much more alike than a random cross-section of the population, we are far from being alike. Some of us could be seen to contribute to it while others are fighting against it.
2) You've say we're hypocrites for complaining about spam that we've caused, yet the two examples you give of us 'causing' spam have only the most tenuous causation link. Apparently by not reading the fine-print on the iPod deal we deserve to be spammed, and similarly for enjoying advantage of some flash gimmick.
The thing I see in both of these cases is that we wanted a free iPod and a free gimmick, and possibly didn't bother to read some fine print. Imagine going down to the hardware store and seeing a deal "Sign up for a free color consultation", then after the consultation you get dozens of phone calls selling products that match your color choices. You're going to be pissed, right? Essentially, you got suckered at the hardware store, and the slashdotters got suckered at the free iPod website. Yet because there was a contract of sorts in both cases, you believe it was legally ok, and therefore morally ok?
Around here, there is a provision in contract law that if the contract contains a clause which a reasonable amount of care would not have noticed, then that clause is automatically voided. Crudely put, buying a $20 phone you're not really expected to read the contract, but buying a $20,000 phone system you are, but if that contract refers to documents that weren't available at the time then you might not have been expected to read them. Now, I admit I sneered when I first heard about this -- if someone is stupid enough to sign away their rights, then I thought they deserved whatever they got -- maybe they'll learn next time. But, the older I get, the more I understand that people are busy with their own little corners of existence and are largely clueless outside those corners. So it is essential to have laws like this in order to protect people.
3) You say we contribute to the spam problem. Yet I fail to see how we have either spammed, or encouraged spammers through either financial or technical means. At worst, we have inadvertently providing them with a loophole. That doesn't count as encouraged in my book.
4) I have no idea how you're trying to draw parallels to the election.
Not quite. There is no way the mini would be able to stop before the child, or else the car would be restricted to 20 mph most of the time. Instead the mini will have to swerve to avoid the child.
The semi, OTOH, is following at a safe following distance and so by definition will be able to stop (just) before the child.
I have free access to ISI through work, but I haven't used it in years because of the awful interface. It is slow and kludgy, I can invariably find things faster using google + citeseer.
You're 100% correct (of course). But try playing with some of the best software out there sometime.
It is really amazing just how much information is in the low-res source file, encoded as slight changes in colour values. And the best software does an unbelieveable job of extracting that (making huge guesses along the way). Sure, the guesses do mean it will get it totally wrong occasionally and show things that were never there, but most of the time they're right.
what other metrics can be applied to video cards?
Noise, power consumption.
Sadly, few people bother with those tests, which is really silly since I bought my last graphics card based on it being passively cooled.
Oh, and even more sadly, the one game I play is a board game, and my GF4 (MX440) can't handle it with full antialiasing (http://www.pandanet.co.jp/English/glgo/).
It seems that on their cheap boards, nvidia are dropping more hardware optimisations in exchange for making the few they have fast. Who ever heard of a board game that pushes your gfx card too hard!
Few things are more sad than a man fighting the tide. And to spend your life's savings on the fight! Damn that's gotta hurt...
There is some truth in what you're saying, but I think the idea of selling cheap software is going the way of the dodo. Essentially, the free software momement appears to result in a clone of any software that's been around for a long time and has a big userbase. Of course, software got cloned before the free software movement too, but there the clones cost a similar amount to the first product and so didn't slowly suck up the profit margins, essentially they competed fairly.
There are reasons for this, but you could think them up as easily as me. More relevant are the implications. In this case, since the grandparent was able to swap to a GPLed version tells me you've got something close to a commodity. And this means you're going to have to keep innovating, staying ahead of the GPLed version, or else users will gradully shift to the cheaper, more flexible alternative.
If you want to continue selling shrinkwrapped software as a one-man team, then I suggest you look at where the free software movement has traditionally done badly -- areas where the software cannot be totally free (due to integration with non-free data), very expensive products for a small market, etc.
But I think a more viable long-term option is to start adding software modifications/consulting and the like to your portfolio.
Of course, there is no hurry for any of this, I just expect every year will be a little harder than the one before.
Which is of course why it isn't done that way (any more). I was shown a demo of a NL project a few _years_ ago (and it was nearing the end of the project then, so no doubt there are better things now). Anyway, in the demo you write in natural english and a seperate version in the awkward syntax you just described turns up in the bottom half of the screen, much like a chat window. See, most people can read that syntax, they just can't write it.
Likewise, I find most of the pages I browse work correctly. But the sites my wife browses are a different story, and for kids it is even more of a problem.
Currently we have a near monoculture in web browsers. If you're not using IE, you're pretty damn weird and you can expect many web pages to not work.
As firefox gains in popularity, web developers will have to start writing compatable HTML/JS/etc. and as a result life will become easier for the opera users out there.
YEAH!