If we take away the patent system, we'll get into another RIAA-like situation, where a group of large marketing/production companies will collect new inventions from their creators and sell them to the public, pocketing most of the revenue.
And exactly why isn't that desireable?
Sure, I'd like the inventor to profit some, but if I have to choose between (1) progress and free exchange and use of ideas, or (2) getting the inventor richer, I'd choose (1), thank you!
Chances are, if the inventor wasn't paid by a company to make his invention, it was made in his spare time, and he would probably do it anyway, because it's the most fun thing he knows. And he never intended to profit from it either. If, on the other hand, he intended to profit, he would probably also form a company to produce/market/sell it.
An individual with an idea can't go very far unless they have entrepreneurship as well. If they don't have the drive to promote an idea, what good is the idea?
This is a good point. There's really no reason we should reward people for good ideas. It's not like people would stop having them if they weren't rewarded. Just because mr Jones invented an ingenius new bird-feeding device, doesn't mean he should be entitled to profit from his invention if somebody else decides to manufacture it. At least, it's hard to see what the society at large can gain from this.
If I invented a new idea, and I couldn't distribute it, I would still have the ability to find someone else who can. Entering into a binding contract, we could create a partnership (or corporation). Until that contract is issued, I wouldn't have to explain the idea or the secrets of the idea.
Ahh, but that binding contract would be essentially impossible to write were it not for the patent system.
Say you are mr Jones, who invented a new bird-feeding device. You approach mr Dow, who has a large company specializing in manufacturing bird-feeding equipment. Naturally, he is interested in getting any new ideas, but he is not going to waste time and money unless your idea has some merit. So before you enter into a binding contract, you must answer some questions about your bird-feeding device.
Now, from these questions, mr Dow will either decide that you are a worthless looser wasting his time, or maybe he likes it. But he also has enough of the general idea to find out the rest himself. Leaving you with nothing, not even a contract. This is what the patent system is supposed to avoid. Whether there's any benefit for any other than mr Jones from such a system is another question.
The convention is thus:
We use a 'k' to denote 'kilobits'.
We us a 'K' to denote 'kilo bytes' (the real ones, not those pretender 1000's...)
No. We use a 'k' to denote the SI prefix 'kilo'. For historical and practical reasons, a kilo is either 1000 or 1024, depending on context, although (nonsuccessfull) efforts have been made to try to make people say kibi instead of kilo when they mean 1024.
However, a 'b' designates 'bit's, and a 'B' designates 'byte's. So the distinction is not between 'k' and 'K', but between 'kb', and 'kB'. A large K in this context is always wrong.
Saying 100-130K about network speed is as meaningless as saying you car has a max speed of 180K. What you are probably meaning, is 340kb/s and 180km/h. But most of us understand it even though it's wrong.
Actually, my TOS says i'm not allowed to run servers on accessible through the Internet (and if it doesn't, that's how the courts would interpret it, as they certainly can't expect me to not run e.g. X11.
So, If I decide to deliver internet mail from my box to other computers connected directly behind it, than I'm not violating terms of service.
By the way, I'm willing to offer this service to you for a modest cost, if you happen to be living in my living room, or somewhere else where it would be easy to connect with your computer.
Sure, it's the wrong k. But that doesn't mean anything for whether it's bits or bytes, although since we speak about networking, yes, they measure bits, and kilo is actually 1000 and not 1024 for once.
Well, the correct answer is that you are both wrong. CDE was never used by anybody. It was a completely useless piece of eyecandy, that didn't even look pretty, and certainly didn't perform any useful function, beyond slowing down your machine. It was a piece of bloat forced upon the customers by the marketing department of Sun and others. Most unix server administrators would be just as happy if their machines shipped without it. And they are not going to use Knome or GDE soon either.
It's kinda funny that if you buy a sparkling new Sun server with 16 processors and umpty zillion gigabytes of ram, power it up, and find out that you can't find the fucking command prompt anywhere (it's deeply hidden away in some menu), while all kinds of useless gui apps (calculators, blah, blah) easily accessible. One would think Sun should know their market a little better, the first thing you do when you get a machine like that is not to start playing Solitaire.
I've wondered about Transmeta chips: If they're so efficient at running "morphed" x86 machine code, wouldn't they be even more efficient at running code compiled to its native ISA that didn't need translation?
Probably, if you have an optimizing compiler for exactly that chip. On the other hand, the code-morphing engine is already quite efficient, and by keeping the internal ISA "hidden" or "secret", each new model can have a completely new ISA, and they never have to worry about backwards compatibility.
By the way, every x86 CPU since the pentium has had their own "internal" instruction set, where x86 instructions was translated into the internal ISA before being executed. None of these, except an early Cyrix pentium clone gave you access to their internal ISA, for much the same reasons as mentioned above. Transmeta's code-morphing just works on a larger scale than individual instructions.
The command line is a big no-no for the general public. If you tell an ordinary user they got to go to the command line for anything... even to type the word "install", they're just gonna laugh at you.
That might be true. On the other hand, when people have called me for help with something, and I explain to them how they can use the command-line to fix it, the general response is: "This is actually pretty simple! Why isn't this explained somewhere?"
An uncle of mine who wanted to make webpages had trouble getting wsftp working. Today, three years later, he still swears by the DOS ftp client , because it is simple and he can understand when and why something goes wrong.
The hostility some users have against the command line, is the result of a recent (as in century, not year) phenomenon, that it should be "trendy" to not understand how things work. Many computer hackers are guilty of it too, as if you should somehow be "proud" of not knowing how to fix your car. And among people with more normal interests, it's common to be "proud" of not having any idea how a computer works.
These ideas are extremely damaging and stupid to the society as a whole. We should not accept them, and we should not bend over to them. Just like it's useful for any driver to have a vague idea how cars work, so they can change a tire, or drive safer and more economically, it's useful for a computer user to understand a little of how computer work.
And just like few drivers are professional mechanics, few computer users need to be programmers. But there is a middle ground somewhere, and so far, I think we've been to nice to the users (something viruses and spyware is a clear example of, as they are normally transmitted by human assistance).
Finally, I also think you are missing the point. My point is not that I am against a GUI-wrapper (if you want, I can write one for apt-get install in three lines of Tcl/Tk).
My point is that this is not a problem. There are plenty of real problems with linux on the desktop that are much more important to fix. Any user can be explained to work apt-get, and make it work. But there are a lot of harder problems that can't be solved easily, even if you are told how to do it step-by-step using the command-line. Hardware support and detection, a reasonable desktop environment, a reasonable selection of apps, reasonable configuration tools, etc...
If you absolutely feel that such issues are completely unimportant, and that having a button called "install" is the most important thing for desktop users, then you are probably more dense than a wall of brick.
Yes. That was the only objection I had against GNU info that I claimed was fixable. It doesn't make info any better for that reason.
It doesn't make konqueror much better either, as this sort of thing can easily get hacked into any webbrowser, or converted on the fly through a proxy, but it is a nice touch.
In most cases, somebody has already done it, and you can use google... (And unlike GNU info, I actually like konqueror...)
I must disagree with: "When someone downloads a package for "Linux" it should work on any Linux distro out there, similar to the way which "Windows" software works (excluding win9x/NT incompatibilities) across the board. this.
"Linux" is an OS-kernel, and it should set no policy. When someone downloads a package for windows CE, they don't expect it to work on windows XP. And there are plenty of server applications that refuse to work on XP or 2K professional even without any technical reasons.
Similarly, when someone downloads a debian package, they shouldn't expect it to work on mandrake or suse. And when somebody downloads a package for a linux distribution for the ARM, they shouldn't expect it to work on one for the Itanium. And you shouldn't expect ximian rpm's to work on the fullpliant linux distribution either.
Your expectations are unrealistic. What is good for one linux distribution is not necessarily good for another. You could just as well complain that "When someone downloads a package for "Unix" it should work on any Unix distro out there, similar to the way which "Windows" software works (excluding win9x/NT incompatibilities) across the board.".
If you want the ease of windows, you have to make some choices. This includes choosing between rpm, dpkg, or something else, KDE, gnome, a mix, or something else. Supported packages, etc. Debian (and many other distributions) is a nice example of this.
But even debian gives you too many choices. I can expect most debian packages to work out of the box after installing it with apt-get, but not every combination that the package system allows would make sense for the end user.
So, we limit it further, and call it UserLinux, or something like that, which is a subset of debian. But you can't call it "Linux", because that is something else.
...And it's a real cop-out to force the user to use the command line, and get the kind of education we have in order to do this.
No, it isn't. You don't need to understand much more to be able to write "apt-get install openoffice", than you need to get down to your favourite software store, get Microsoft Office, insert the CD's and click next, next, next, and finish. I would actually go so far, as to say that debian is simpler for the end-user in this arena.
Now, I wouldn't recommend linux to non-technical users either (unless I or someone knowledgeable sysadmined the box), but having to use the command-line for access to apt-get is not the reason. They can learn that pretty fast. There are other more complicated issues that hurt the user-experience a lot more.
This is also why Microsoft WANTS there to be an enemy: they need someone to compete against to continue improving their product (which they do, even if we hate to admit it).
Uh, no. Every company has a responsability to their stockholders of getting as much money as possible. And Microsoft is not an exception. You certainly don't have to be a microsoft-hater to realize this.
The best way to for a company to get money is to become a monopoly. If I ran a company myself, I'd want to become a monopoly too. There's nothing bad about microsoft for wanting to become a monopoly, that's what almost every other company strives for too. By becoming a monopoly you can sell your goods at any price you want, and don't spend money on expensive tasks such as research and development.
The only problem with becoming a monopoly, is legal. The government might decide to split you up, and in todays internationalized economy, you might see foreign countries abandoning you. And if microsoft is artificially keeping some competitors alive, that is the reason, not because they need them to get better products.
Ahh, and it's almost the greatest thing since sliced bread too. It almost always works. And when it doesn't, it can easily be overrided. But the granularity is too big (per package, I may just want to override some options), and the user-interface is non-existent. Still, great stuff.
I think everyone agrees that rpms suck. Most of the good code comes in source tarballs - configurable for any *nix... but this is where the user experience falls apart. What person is going to want to dig out the command line to compile source code, and will he or she know about all the ocnfigure options
The person who would like to do that, is a distributor, such as the many cohorts working on the debian system, or any number of rpm packagers. It could also be sysadmins who know what they do, and has special reasons for preferring to compile the source themselves. Or developers. There is nothing wrong with this. It's called open source.
In an ideal world, packaged installs will be a compressed single file, containing all source code, configurable on any *nix like normal source code EXCEPT that now there's a graphical interface so that setting compile options, creating desktop shortcuts, and "Make clean, make install, make uninstall" now all work under X with a point-and-click.
This is known as rpm or dpkg. They are user-friendly. I hardly see your point. The dependency problems are solved in debian, and being actively worked on in rpm-based distributions. But I think no-one is seriosly considering having every package containing every library or component it needs. Luckily, or you would have something else to complain about.
If you want to click a button instead of writing "rpm -i" "dpkg -i" or "apt-get install", "emerge" in gentoo, or whatever commands you need to do for source-rpm's or source-dpkg's, then it would be a very simple to write script. I agree that it should probably exist, but fail to see the big deal. If you feel this is your biggest problem using linux, you must have one hell of a good distribution, can you tell me what you are using?
PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.
There are already thousands of people doing something about this. They are called package maintainers.
Man is out of date for a reason - it's deprecated and hasn't been used for ages. Try info instead, that's where you'll find up to date documentation for most things.
Good troll. Now, about the only person who seems to think man is deprecated is RMS and his cohorts, and as you say, they seem to prefer their own obtuse documentation system info.
While info might sound like a good idea for some developers too lazy to write man-pages, or a real manual in a readable format, it's completely ridiculous for the rest of us.
First, GNU documentation guidelines state that an info manual should be both a tutorial and a reference, which flies in the face of any advice you could get from both people experienced in reading or writing manuals. While man-pages are at least good for getting a complete reference of something, info-pages are almost always completely confused about their purpose, being as comprehensive as the average man-page, but much more wordy, making neither a good introduction nor a good reference.
Second, there is the file info.dir, which must either be manually updated, or gradually fall into a long unorganized mess of links pointing everywhere, but without any comprehensible organization.
Third, there really aren't that many programs having an info-file. While you can expect almost everything to have a man-page (and possibly point you at the info-manual), the other direction is not as common. A good documentation solution should probably have some way of accessing info-files, because of their historical significance, but it should not be based upon it, as it is quite despickable. The same can of course be said of man, but man never tried to be everything you need.
Last, the GNU info program has a loathsome user interface, with keybindings as intuitive as those found in dselect. The emacs version is slightly better, but requires you to run emacs. But apart from the other problems with info, this is actually fixable.
In conclusion; there are serious problems with GNU info. It is certainly not better than man, in any way. Man makes it easy to incorporate it as part of a better help-system. Info makes it hard, and instead tries to be everything for everyone, but fails completely at the task. A good documentation system should cater for the user, info seems to only care about the person writing info manuals.
Yeah, I've always been somewhat intrigued by com.com, since it's so nifty. And at least CNet fills it with some actual content. But who the fuck is it who has captured www.com?
I have never understood why it should be so fucking simple to shop online. I don't want it to be simple. I want it to require multiple steps that make sure no transactions go through without me wanting it. And I certainly don't want to use a credit card for it.
As long as I've lived, I've been able to securely transfer money from my bank-account, and at least for a decade, I've been able to do so electronically. Why won't online merchants accept this?
When I buy something through mail-order, I order, you send an invoice (electronically, or by snail-mail), I pay, you send the goods. Is that too fucking hard?
You must be kidding. They don't use 99.99% of their warez. You are not seriously suggesting that they should risk their computer stability for installing useless software, thus limiting their participation in the warez scene, do you?
In other words, some random author produced a small tutorial of some obvious aspect of C++ explained in almost any introductory book or tutorial. Why is this here?
I've actually read it once. A long time ago. He seems to be going in the right direction. In my opinion, this is Stroustrups "much smaller and cleaner language struggling to get out" from C++.
Getting it up to the production quality needed to compete with C++ is much more than a one-man task, though. And chances are it will die out like any other MFTL-project. But I would like to give him the benefit of doubt on this one.
Its a big mistake to confuse number of lines with a "better" language.
I would tend to disagree. There have been many studies that show that the same programmer will on average produce approximately the same number of codes in any given language. A language that offers better abstraction, will therefore give higher programmer efficiency.
To me, "better" means to more readable, more maintainable, compiles to better object core, etc, etc.
Who cares how many lines it needs?
True, there are other considerations. Python will usually make you more efficient than, say C++. But well-crafted C++ code is likely to run faster. The holy grail is good abstractions, easy (but safe) low-level access, small run-time, and fast code. I wouldn't be surprised if concept programming was a step in the right direction.
So. How often does your cable go out? And for how long?
This is really true. I don't know much more about this than your average Joe. But my cable-company specifically tells you, that if you need reliable access to emergency numbers, etc, you should have an alternative to VoIp, such as mobile phone or fixed lines.
I think that should tell you either that the cable-company is afraid of getting sued (which is quite unlikely here in Norway), or the reliability is really bad (which is much more likely, although I think it's been over a year since my IP connection used to break down regularly, and I would notice it myself).
Then we agree on hardware. But regarding "modular" software, I disagree. I think it comes from both technological gains and sociological ones. Modular OS-kernels, languages suitable for writing generic algorithms, containers, and components, component frameworks, as well as cooperation and dictatorship creates modular software. Which is most important matters little, if either the technological or sociological side is missing, it will not happen.
By the way: grouping "70's languages" together makes no sense at all. "70's languages" include as diverse things as C, Fortran, SmallTalk, COBOL, ML, Icon, CLU, Forth, PL/1, and Prolog. Some of these languages are still alive today. Some of them should be. Some of them shouldn't be. Some of them have worse modern equivalents. Some of them have better modern equivalents. And there is certainly an argument about the "superiority" of going back to using only 70's languages. Amongst other things, you will miss: C++, Java, Perl, Python, Tcl, PHP, C#, Common Lisp, Haskell, and several other languages that I certainly prefer to exist rather than being ignored because they are newer than Jan 1, 1980. In particular, all the "scripting" languages certainly have helped getting closer to the goal of "mularity".
Slashdot Mirror
And exactly why isn't that desireable?
Sure, I'd like the inventor to profit some, but if I have to choose between (1) progress and free exchange and use of ideas, or (2) getting the inventor richer, I'd choose (1), thank you!
Chances are, if the inventor wasn't paid by a company to make his invention, it was made in his spare time, and he would probably do it anyway, because it's the most fun thing he knows. And he never intended to profit from it either. If, on the other hand, he intended to profit, he would probably also form a company to produce/market/sell it.
This is a good point. There's really no reason we should reward people for good ideas. It's not like people would stop having them if they weren't rewarded. Just because mr Jones invented an ingenius new bird-feeding device, doesn't mean he should be entitled to profit from his invention if somebody else decides to manufacture it. At least, it's hard to see what the society at large can gain from this.
If I invented a new idea, and I couldn't distribute it, I would still have the ability to find someone else who can. Entering into a binding contract, we could create a partnership (or corporation). Until that contract is issued, I wouldn't have to explain the idea or the secrets of the idea.
Ahh, but that binding contract would be essentially impossible to write were it not for the patent system.
Say you are mr Jones, who invented a new bird-feeding device. You approach mr Dow, who has a large company specializing in manufacturing bird-feeding equipment. Naturally, he is interested in getting any new ideas, but he is not going to waste time and money unless your idea has some merit. So before you enter into a binding contract, you must answer some questions about your bird-feeding device.
Now, from these questions, mr Dow will either decide that you are a worthless looser wasting his time, or maybe he likes it. But he also has enough of the general idea to find out the rest himself. Leaving you with nothing, not even a contract. This is what the patent system is supposed to avoid. Whether there's any benefit for any other than mr Jones from such a system is another question.
No. We use a 'k' to denote the SI prefix 'kilo'. For historical and practical reasons, a kilo is either 1000 or 1024, depending on context, although (nonsuccessfull) efforts have been made to try to make people say kibi instead of kilo when they mean 1024.
However, a 'b' designates 'bit's, and a 'B' designates 'byte's. So the distinction is not between 'k' and 'K', but between 'kb', and 'kB'. A large K in this context is always wrong.
Saying 100-130K about network speed is as meaningless as saying you car has a max speed of 180K. What you are probably meaning, is 340kb/s and 180km/h. But most of us understand it even though it's wrong.
So, If I decide to deliver internet mail from my box to other computers connected directly behind it, than I'm not violating terms of service.
By the way, I'm willing to offer this service to you for a modest cost, if you happen to be living in my living room, or somewhere else where it would be easy to connect with your computer.
Sure, it's the wrong k. But that doesn't mean anything for whether it's bits or bytes, although since we speak about networking, yes, they measure bits, and kilo is actually 1000 and not 1024 for once.
It's kinda funny that if you buy a sparkling new Sun server with 16 processors and umpty zillion gigabytes of ram, power it up, and find out that you can't find the fucking command prompt anywhere (it's deeply hidden away in some menu), while all kinds of useless gui apps (calculators, blah, blah) easily accessible. One would think Sun should know their market a little better, the first thing you do when you get a machine like that is not to start playing Solitaire.
No.
Probably, if you have an optimizing compiler for exactly that chip. On the other hand, the code-morphing engine is already quite efficient, and by keeping the internal ISA "hidden" or "secret", each new model can have a completely new ISA, and they never have to worry about backwards compatibility.
By the way, every x86 CPU since the pentium has had their own "internal" instruction set, where x86 instructions was translated into the internal ISA before being executed. None of these, except an early Cyrix pentium clone gave you access to their internal ISA, for much the same reasons as mentioned above. Transmeta's code-morphing just works on a larger scale than individual instructions.
That might be true. On the other hand, when people have called me for help with something, and I explain to them how they can use the command-line to fix it, the general response is: "This is actually pretty simple! Why isn't this explained somewhere?"
An uncle of mine who wanted to make webpages had trouble getting wsftp working. Today, three years later, he still swears by the DOS ftp client , because it is simple and he can understand when and why something goes wrong.
The hostility some users have against the command line, is the result of a recent (as in century, not year) phenomenon, that it should be "trendy" to not understand how things work. Many computer hackers are guilty of it too, as if you should somehow be "proud" of not knowing how to fix your car. And among people with more normal interests, it's common to be "proud" of not having any idea how a computer works.
These ideas are extremely damaging and stupid to the society as a whole. We should not accept them, and we should not bend over to them. Just like it's useful for any driver to have a vague idea how cars work, so they can change a tire, or drive safer and more economically, it's useful for a computer user to understand a little of how computer work.
And just like few drivers are professional mechanics, few computer users need to be programmers. But there is a middle ground somewhere, and so far, I think we've been to nice to the users (something viruses and spyware is a clear example of, as they are normally transmitted by human assistance).
Finally, I also think you are missing the point. My point is not that I am against a GUI-wrapper (if you want, I can write one for apt-get install in three lines of Tcl/Tk).
My point is that this is not a problem. There are plenty of real problems with linux on the desktop that are much more important to fix. Any user can be explained to work apt-get, and make it work. But there are a lot of harder problems that can't be solved easily, even if you are told how to do it step-by-step using the command-line. Hardware support and detection, a reasonable desktop environment, a reasonable selection of apps, reasonable configuration tools, etc...
If you absolutely feel that such issues are completely unimportant, and that having a button called "install" is the most important thing for desktop users, then you are probably more dense than a wall of brick.
It doesn't make konqueror much better either, as this sort of thing can easily get hacked into any webbrowser, or converted on the fly through a proxy, but it is a nice touch.
In most cases, somebody has already done it, and you can use google... (And unlike GNU info, I actually like konqueror...)
I must disagree with: "When someone downloads a package for "Linux" it should work on any Linux distro out there, similar to the way which "Windows" software works (excluding win9x/NT incompatibilities) across the board. this.
"Linux" is an OS-kernel, and it should set no policy. When someone downloads a package for windows CE, they don't expect it to work on windows XP. And there are plenty of server applications that refuse to work on XP or 2K professional even without any technical reasons.
Similarly, when someone downloads a debian package, they shouldn't expect it to work on mandrake or suse. And when somebody downloads a package for a linux distribution for the ARM, they shouldn't expect it to work on one for the Itanium. And you shouldn't expect ximian rpm's to work on the fullpliant linux distribution either.
Your expectations are unrealistic. What is good for one linux distribution is not necessarily good for another. You could just as well complain that "When someone downloads a package for "Unix" it should work on any Unix distro out there, similar to the way which "Windows" software works (excluding win9x/NT incompatibilities) across the board.".
If you want the ease of windows, you have to make some choices. This includes choosing between rpm, dpkg, or something else, KDE, gnome, a mix, or something else. Supported packages, etc. Debian (and many other distributions) is a nice example of this.
But even debian gives you too many choices. I can expect most debian packages to work out of the box after installing it with apt-get, but not every combination that the package system allows would make sense for the end user.
So, we limit it further, and call it UserLinux, or something like that, which is a subset of debian. But you can't call it "Linux", because that is something else.
No, it isn't. You don't need to understand much more to be able to write "apt-get install openoffice", than you need to get down to your favourite software store, get Microsoft Office, insert the CD's and click next, next, next, and finish. I would actually go so far, as to say that debian is simpler for the end-user in this arena.
Now, I wouldn't recommend linux to non-technical users either (unless I or someone knowledgeable sysadmined the box), but having to use the command-line for access to apt-get is not the reason. They can learn that pretty fast. There are other more complicated issues that hurt the user-experience a lot more.
Uh, no. Every company has a responsability to their stockholders of getting as much money as possible. And Microsoft is not an exception. You certainly don't have to be a microsoft-hater to realize this.
The best way to for a company to get money is to become a monopoly. If I ran a company myself, I'd want to become a monopoly too. There's nothing bad about microsoft for wanting to become a monopoly, that's what almost every other company strives for too. By becoming a monopoly you can sell your goods at any price you want, and don't spend money on expensive tasks such as research and development.
The only problem with becoming a monopoly, is legal. The government might decide to split you up, and in todays internationalized economy, you might see foreign countries abandoning you. And if microsoft is artificially keeping some competitors alive, that is the reason, not because they need them to get better products.
If you don't believe me, ask Dubya.
Ok, so I've been trolled. Just couldn't resist...
Ahh, and it's almost the greatest thing since sliced bread too. It almost always works. And when it doesn't, it can easily be overrided. But the granularity is too big (per package, I may just want to override some options), and the user-interface is non-existent. Still, great stuff.
The person who would like to do that, is a distributor, such as the many cohorts working on the debian system, or any number of rpm packagers. It could also be sysadmins who know what they do, and has special reasons for preferring to compile the source themselves. Or developers. There is nothing wrong with this. It's called open source.
In an ideal world, packaged installs will be a compressed single file, containing all source code, configurable on any *nix like normal source code EXCEPT that now there's a graphical interface so that setting compile options, creating desktop shortcuts, and "Make clean, make install, make uninstall" now all work under X with a point-and-click.
This is known as rpm or dpkg. They are user-friendly. I hardly see your point. The dependency problems are solved in debian, and being actively worked on in rpm-based distributions. But I think no-one is seriosly considering having every package containing every library or component it needs. Luckily, or you would have something else to complain about.
If you want to click a button instead of writing "rpm -i" "dpkg -i" or "apt-get install", "emerge" in gentoo, or whatever commands you need to do for source-rpm's or source-dpkg's, then it would be a very simple to write script. I agree that it should probably exist, but fail to see the big deal. If you feel this is your biggest problem using linux, you must have one hell of a good distribution, can you tell me what you are using?
PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.
There are already thousands of people doing something about this. They are called package maintainers.
Good troll. Now, about the only person who seems to think man is deprecated is RMS and his cohorts, and as you say, they seem to prefer their own obtuse documentation system info.
While info might sound like a good idea for some developers too lazy to write man-pages, or a real manual in a readable format, it's completely ridiculous for the rest of us.
First, GNU documentation guidelines state that an info manual should be both a tutorial and a reference, which flies in the face of any advice you could get from both people experienced in reading or writing manuals. While man-pages are at least good for getting a complete reference of something, info-pages are almost always completely confused about their purpose, being as comprehensive as the average man-page, but much more wordy, making neither a good introduction nor a good reference.
Second, there is the file info.dir, which must either be manually updated, or gradually fall into a long unorganized mess of links pointing everywhere, but without any comprehensible organization.
Third, there really aren't that many programs having an info-file. While you can expect almost everything to have a man-page (and possibly point you at the info-manual), the other direction is not as common. A good documentation solution should probably have some way of accessing info-files, because of their historical significance, but it should not be based upon it, as it is quite despickable. The same can of course be said of man, but man never tried to be everything you need.
Last, the GNU info program has a loathsome user interface, with keybindings as intuitive as those found in dselect. The emacs version is slightly better, but requires you to run emacs. But apart from the other problems with info, this is actually fixable.
In conclusion; there are serious problems with GNU info. It is certainly not better than man, in any way. Man makes it easy to incorporate it as part of a better help-system. Info makes it hard, and instead tries to be everything for everyone, but fails completely at the task. A good documentation system should cater for the user, info seems to only care about the person writing info manuals.
Yeah, I've always been somewhat intrigued by com.com, since it's so nifty. And at least CNet fills it with some actual content. But who the fuck is it who has captured www.com?
As long as I've lived, I've been able to securely transfer money from my bank-account, and at least for a decade, I've been able to do so electronically. Why won't online merchants accept this?
When I buy something through mail-order, I order, you send an invoice (electronically, or by snail-mail), I pay, you send the goods. Is that too fucking hard?
You must be kidding. They don't use 99.99% of their warez. You are not seriously suggesting that they should risk their computer stability for installing useless software, thus limiting their participation in the warez scene, do you?
In other words, some random author produced a small tutorial of some obvious aspect of C++ explained in almost any introductory book or tutorial. Why is this here?
Getting it up to the production quality needed to compete with C++ is much more than a one-man task, though. And chances are it will die out like any other MFTL-project. But I would like to give him the benefit of doubt on this one.
Is he a friend of Alan J. Perlis, or is he just a really dangerous guy?
I would tend to disagree. There have been many studies that show that the same programmer will on average produce approximately the same number of codes in any given language. A language that offers better abstraction, will therefore give higher programmer efficiency.
To me, "better" means to more readable, more maintainable, compiles to better object core, etc, etc. Who cares how many lines it needs?
True, there are other considerations. Python will usually make you more efficient than, say C++. But well-crafted C++ code is likely to run faster. The holy grail is good abstractions, easy (but safe) low-level access, small run-time, and fast code. I wouldn't be surprised if concept programming was a step in the right direction.
This is really true. I don't know much more about this than your average Joe. But my cable-company specifically tells you, that if you need reliable access to emergency numbers, etc, you should have an alternative to VoIp, such as mobile phone or fixed lines.
I think that should tell you either that the cable-company is afraid of getting sued (which is quite unlikely here in Norway), or the reliability is really bad (which is much more likely, although I think it's been over a year since my IP connection used to break down regularly, and I would notice it myself).
"mularity" of course being a typo for "modularity"
By the way: grouping "70's languages" together makes no sense at all. "70's languages" include as diverse things as C, Fortran, SmallTalk, COBOL, ML, Icon, CLU, Forth, PL/1, and Prolog. Some of these languages are still alive today. Some of them should be. Some of them shouldn't be. Some of them have worse modern equivalents. Some of them have better modern equivalents. And there is certainly an argument about the "superiority" of going back to using only 70's languages. Amongst other things, you will miss: C++, Java, Perl, Python, Tcl, PHP, C#, Common Lisp, Haskell, and several other languages that I certainly prefer to exist rather than being ignored because they are newer than Jan 1, 1980. In particular, all the "scripting" languages certainly have helped getting closer to the goal of "mularity".