"do not understand how patents can be bad for some technical fields and good for others. They work just fine for machines and medicines then why not for software?"
Medical patents are used to patent newly developed drugs.
Mechanical patents are used to patent specific designs (an improved mousetrap; if you need a better example, feel free to supply your own)
Software patents are being used to patent such items as "tabbing through links in a web page" and "making a purchase with only a single mouse click" and "a display of text incorporating highlighted segments which when activated link to a related text"
To apply similar logic to medicine, you would allow patents on pills, injections and invasive surgery.
The analogy for mechanics is to allow patents on the _concepts_ of "locks and keys", "electrically powered illumination" or "knives".
Essentially; old-economy patents cover specific designs and NEW inventions. SW-patents are being used to patent BASIC (frequently OBVIOUS) and GENERAL ideas, not designs, and not inventions.
"Convicted felons are a highly Democrat voting group."
That seems to be a seperate symptom of your country's stagnant, possibly moribund political system, rather than a good reason to accept nullifying legitmate votes...
"The number of illegal double voters in Florida and several other states is quite likely to have exceeded the margin of victory in those states in the 2000 presidential election."
In the words of one of my country's previous prime ministers; I refer you to my previous response.
These are other symptoms of a problem, not reasons to perpetuate / exacerbate that problem.
Surely the priority of ALL democratic systems should be to ensure + encourage the right of legitimate voters, rather than to restrict the opportunity for illegitimate voters.
i.e. your system for preventing banned voters and preventing fraudulent voting should not prejudice the ability of the general populace to vote...
The problem with the camera on your (and my) phone is NOT its resolution.
Its the shitty, shitty, shitty lens put on it. I look at my phone and I see a lens that, ooh, maybe 1mm diameter. You could put a professional level CCD, resolving 11Mp behind that, and it would still take pictures similar to a pinhole camera made from a cornflakes box, using a cat's teeth to make the pinhole!
I know (many) people who _loathe_ the GC controller (for instance, I sold my GC after a very short period because I could _not_ get to grips with it), also MS actually had to change the controller they shipped with the xbox in the UK, so universally was it disliked.
How many people do you know who actively complain about the PS controllers?
Has always been a "quantity rather than quality" formula; the only 2 things the playstation (1 or 2) ever got right were: "have the best controller on the market" (by far), and "have the most games on the market" (by far, and in PS2's case by backwards compatibility; masterstroke!).
The first makes their machine the most comfortable to use.
The second means that any given consumer is more likely to find a game that appeals to them for that machine. (the fact that once they get the machine plus game home, the game may not live up to the appeal does not matter - now they have the machine and wil continue to buy games for it)
This combination is more than enough to tie up the console market for you, MS failed to realise this (they thought having the most impressive machine was the key, probably due to the fact that in the dramcast/n64/playstation generation, sony also just happenend to have the most impressive machine as a side issue)
I suppose, in short, what I'm saying is that more than any of their competitors, sony have understood the marketing of consoles and console games; consoles sell by being OK in and of them selves (the controller being an amazingly important aspect of that), and by having 1+ games that _any_ person in the market is interested in (i.e. not by having 1 to 3 really top flight games; by having lots of good-enough games).
"would it make a difference to you if Google explicitly guaranteed that no *human* entity would get to look at your data, and that any machine-automated use of the data would be limited to a specific task (and nothing else, and never would this be changed without your consent)?"
"you need to use things for which there are no standards, such as Flash"
Just an assinine aside, but nobody in the entire history of the world has ever needed to use flash.
Wanted to, yes.
Decided to, yes.
Been told to, yes. needed to, no.
"Well, the problem with the first approach is it just plainly doesn't work. Whether or not something should work a particular way in a particular browser doesn't matter - it's whether or not it does work that matters. Every browser renders CSS a little differently, for example; even the functions that actually do work across browsers just look different depending on which browser you're running."
No! No! and thrice No!
If you code to the standards, you have coded your pages correctly if any given browser fails to handle correct pages properly, it is broken.
If you then proceed to pander to any or all broken browsers you allow the vendor to perpetuate their lazyness, and (in a certain case) to de-facto poison the standards.
What you should do is only work around errors that you know of which prevent your pages from working at all, and in your help section have a little note that "if your browser does not display correctly - please inform the vendor that they are not standards compliant"
If enough sites coded to the standard not the browser, and enough users told the vendor that the browser was broken, not the designer that the site was broken, then just maybe the standards would be worth something...
Pretty,
but possibly the most useless UI for list-format data ever; I can only read the first (counts) 19 entries, (can't read the numbers after 10). After that you have to do random sampling.
Browsable Lists - the past and future of basic data presentation!
"having the contact information centralized and standard in every Gnome installation means that other Gnome applications can use that data"
Seriously now. Replace "contact information" with "browser engine" or "media player engine" and you have the EXACT line of thought that embedded IE and MediaPlayer into Windows.
Later, he admitted that he could also have put a text label on both buttons, but back then he thought that were ugly.
Surely, what he should have admitted was that he was a dick, and should have credited the rest of the world with the ability to tell right from left?!?
After all, he's been proven SO wrong by... every other computer system in history. Way to go, bud.
Basically TouchTypying is a skill that is only useful for COPYING text. You gain the luxury of looking at what you're doing if you are creating as you type. Then review / edit when you've done a section.
Likewise, typing speed is only the most important element if there is no thought required during the typing.
In other words, if you are more than a copyist style and content are more important than raw speed.
Never forget; the qwerty layout is a deliberately AWFUL keyboard design, meant to slow you down; dating from the earliest typewriters which jammed very easily.
Also remember that the very best way to get RSI is to touch type for long periods.
A bit of a ramble:) My thoughts on design/methods that could move the electronic book ahead of the paper book...
Form Factor; Clam shell (thinking Nintendo DS non its side, kind of), left and right screens. Reasonably large screens (I foresee pocketbook, softback novel, hardback novel, reference and cofee table sized readers being available ultimately) full colour and good definition. Front of reader, when closed, has a small screen allowing display of what book this reader currently "is", some controls on outside.
Rationale; able to display magazine / website content as well as "book" content. Reasonable approximation of book format, but allows enhanced capabilities (could open 1 book in each screen, navigate each screen through a book seperately etc - useful for cross reference; tabbed book reading the extension of tabbed browsing now?)
Ergonomics;
The reader is quite heavy (each version being the same weight as the equivalent real book, possibly lighter in the case of the really big ones). The reader is also rugged; as in kick around the floor and still works, rugged. Ideally it would have good battery life, and a cradle to charge (possibly induction; like my electric toothbrush)
Behaviour; I see the default behaviours being as close to physical book as possible. I.e. you open the reader to power on, it defaults to presenting the same state that you last had that reader in - i.e. reader "becomes" a book when used. You then have availability of enhanced functionality if and when you want it. (say to load a stored state of a different book, to load annotations for a book (not just your own - think english lit study aids, or collaborative work, revision history etc)
Rationale; basic behaviour is book like for familiarity, but reader also works as a library interface)
File Format; For my money the format should be working towards XML + XMSLT + required extra files (Fonts / Images, whatever). This is then wrapped in a common format "wrapper" file. This wrapper contains the DRM facilities as required. The end user has software that will read files, DRM allowing as necessary. End user can also have software that will compile (and possibly DRM setup) files of their own, software to convert older / other formats into this format. Nobody _needs_ software to unwrap a book once its wrapped. (not that this means it won't happen, but thats the theory)
Rationale; one format, allows DRM, actual content in non-proprietary format - many makes of reader, all books readable, huzzah!
Library; I see the need for "Library Servers"; possibly local (wireless networking), possibly internet based, possibly both. The concept is; you book (gained however) sits in the library. The library can track what books you have, what page you were last on, which reader device you were using, any manual bookmarks you've added, annotations, whatever.
The reader can download from the library the book to read, what page etc. It can also upload to the server what book / page etc when you finish with it. (allowing the pick up and continue behaviour above)
Obviously this syncing could be automatic (the bedside reader which keeps page every night, and only changes book when finished), manual (a reader loaded with books because you're going away on a trip), or disabled (the reader that lives in the lounge for anyone to browse at whim, or your reader that you've been reading playboy in, that you don't want to have auto-load the centerfold when the kids pick it up!)
This library could be a machine at home, scaled to handle your family, plus visitors. Or it could be a central server, so that you can sync while on holiday (both so that the book you buy away from home goes home, or so that you can pick up the book you left at home while away from home) Whether this would be your machine having an externally accessible port, or a "trusted" service provider, I leave to your imaginations.
Rationale; books not lost if reader lost/destroyed. A
"This is not a problem. Not only is it not a problem, but it is at the core of getting great software out."
You've obviously never come accross the concept of "domain experts" or "requirements ellicitation".
In essence; there are two types of people in the softeware creation environment (environment specific to each piece/type of software).
Firstly there are those who have skills and familiarity with the internals of the software in question. (i.e. the white box) These are the best people to develop the software.
Secondly there are those who have skills and familiarity in the problem domain (graphic design / manipulation in the example of the gimp). These are the best people to get information on what the software needs to do, and how it should behave.(i.e. the black box)
There are maybe 10% of those who come into contact with the software, from either direction, who will have an appreciable cross over from these two camps. Admittedly these people are like gold, but like gold they are rare.
The conclusion; the best people to get feedback on what your program does or how it behaves are EXTREMELY unlikely to be in a position to help implement the changes they suggest. Generally the less technical the request "It doesn't deal with colour properly" the more insightful for the project it is likely to be.
To get specific again; if the developers have any aspirations of getting the gimp accepted by real graphic designers, then when those designers say it does something "wrong" - it does it WRONG.
Another fatuous example; if the sole of your shoe falls off; I don't need to be able to fix it for you, in order to point out the problem.
"Of course, the making of a noise may be the whole be all and end all to the complaining, with no intention of wanting a fix in the first place. Some people are like that, and that's just unfair."
See above coments, and I think you begin to see how immature this pair of sentences is.
Ugh!
some facts of computing for you all:
"possible" != "useable"
"rtfm" != "adequately explained"
"i know how" != "accessible to general public"
and finally
"i can answer specific instance" != "generic argument discredited"
"Trying to "unify" all the different distos so that they all can use each other's packages is missing the point. That is addressed by the GNU build tools (gcc, make, autoconf, automake, etc)."
I think, if you reflect, you'll find that you've missed the point. neither I nor the article mentioned having all the distributions use the same packaging system. Ever.
The original article suggested a unified GUI to control (graphically) any of the varying install methods in some sort of "unified" method - that doesn't imply shoe-horning them all to use the exact same wizard / controls, just having a single application in the desktop system to drive the correct one. (Think: gnome/kde/whatever provides the very basic/generic controller, each distributor can write the specific handler for their distribution and add that to their install
My comment was more a rant against the depth to which a NEW user has to read in order to first; find out what bizarre name this distribution has given to the mechanism for "Install New Program" or "Upgrade Installed Program" - hint; its never "Install Program"! And second the further depth to which I must plunge in order to do this; hint 2 "make all" is not a suitable install method in the 21st century - unless you are a sysadmin/nerd.
"The answer could be an installation application that can speak to all of the popular distributions. It could be built in such a modular way as to allow new backends and functionality. Alternatively, a standard application installation procedure could be created that is supported by the majority of distributions (perhaps in addition to the native methodology)."
As a long-time Windows user, on and off trying to make a transition to Linux (as in tried several times, always reinstalled windows in the end) this is the single thing that jumped to my mind when trying Linux.
Basically, how the **** do I install / update programs?!? (I know, I RTFM; but why do I have to read a different friendly manual for each distribution I trial run?)
WTF is an emerge, and if its so great, why does only gentoo use it? What is an RPM? Exactly HOW do I install or upgrade on mandrake (realy; i have no idea!) What is a modprobe - and why should I need to know? For a desktop OS, _no_ configuration change should be commandline only... (like samba; I got it working no problems, but had to go to a root prompt and edit a file in vi - WTF?)
All these rants and more should not go through the new adopter's mind, if Linux is to ever become a mainstream desktop OS - because average users don't RTFM (you don't have to if you want to be a dumb-user in windows/macos), and don't have friendly sysadmins to do the setup for them./Rant
If that were true, the right hand edge of the calculator would not be vertical.
One of two things is demonstrated in that image;
either
1: there is something wonky in the rendering of that set of windows.
or
2: that kind of 3d rendering of a desktop makes some or all users think that something is wonky with the rendering.
I think that its a situation similar to motion sickness, where your inner ear reports that you are in motion and your eyes report that your surroundings aren't moving; recult is nausea.
In this case part of your brain thinks "thats a 3d thing, with intersections and stuff" and the rest is thinking "its on a flat panel". Result, a vague unease about the entire display.
At least thats what I felt looking at the intersection and "sphere" demo images. I got the distinct impression that those desktops would give me a headache in around 5 minutes.
YMMV, of course.
Slashdot Mirror
"do not understand how patents can be bad for some technical fields and good for others. They work just fine for machines and medicines then why not for software?"
Medical patents are used to patent newly developed drugs.
Mechanical patents are used to patent specific designs (an improved mousetrap; if you need a better example, feel free to supply your own)
Software patents are being used to patent such items as "tabbing through links in a web page" and "making a purchase with only a single mouse click" and "a display of text incorporating highlighted segments which when activated link to a related text"
To apply similar logic to medicine, you would allow patents on pills, injections and invasive surgery.
The analogy for mechanics is to allow patents on the _concepts_ of "locks and keys", "electrically powered illumination" or "knives".
Essentially; old-economy patents cover specific designs and NEW inventions. SW-patents are being used to patent BASIC (frequently OBVIOUS) and GENERAL ideas, not designs, and not inventions.
"In fact, medical research thrives on patent protection."
And the third world DIES because of medicine patents.
Nice call there.
"Convicted felons are a highly Democrat voting group."
That seems to be a seperate symptom of your country's stagnant, possibly moribund political system, rather than a good reason to accept nullifying legitmate votes...
"The number of illegal double voters in Florida and several other states is quite likely to have exceeded the margin of victory in those states in the 2000 presidential election."
In the words of one of my country's previous prime ministers; I refer you to my previous response.
These are other symptoms of a problem, not reasons to perpetuate / exacerbate that problem.
Surely the priority of ALL democratic systems should be to ensure + encourage the right of legitimate voters, rather than to restrict the opportunity for illegitimate voters.
i.e. your system for preventing banned voters and preventing fraudulent voting should not prejudice the ability of the general populace to vote...
"better camera (can we get 2mp on a cell phone?)"
The problem with the camera on your (and my) phone is NOT its resolution.
Its the shitty, shitty, shitty lens put on it. I look at my phone and I see a lens that, ooh, maybe 1mm diameter. You could put a professional level CCD, resolving 11Mp behind that, and it would still take pictures similar to a pinhole camera made from a cornflakes box, using a cat's teeth to make the pinhole!
No, dumbass.
Print your page at 150 and at 300 dpi (older and this newe ppi approximations)
Now use 2.2 inch diagonal paper to print those pages.
They will BOTH be unusable, due to being TINY.
resolution does NOT directly equate to legibility.
RTFA; in the image of their screen; do you recon you could actually READ that url in the browser??
You're looking at this backward;
I know (many) people who _loathe_ the GC controller (for instance, I sold my GC after a very short period because I could _not_ get to grips with it), also MS actually had to change the controller they shipped with the xbox in the UK, so universally was it disliked.
How many people do you know who actively complain about the PS controllers?
Best controller design.
By FAR.
Sony + Playstation + Games
Has always been a "quantity rather than quality" formula; the only 2 things the playstation (1 or 2) ever got right were: "have the best controller on the market" (by far), and "have the most games on the market" (by far, and in PS2's case by backwards compatibility; masterstroke!).
The first makes their machine the most comfortable to use.
The second means that any given consumer is more likely to find a game that appeals to them for that machine. (the fact that once they get the machine plus game home, the game may not live up to the appeal does not matter - now they have the machine and wil continue to buy games for it)
This combination is more than enough to tie up the console market for you, MS failed to realise this (they thought having the most impressive machine was the key, probably due to the fact that in the dramcast/n64/playstation generation, sony also just happenend to have the most impressive machine as a side issue)
I suppose, in short, what I'm saying is that more than any of their competitors, sony have understood the marketing of consoles and console games; consoles sell by being OK in and of them selves (the controller being an amazingly important aspect of that), and by having 1+ games that _any_ person in the market is interested in (i.e. not by having 1 to 3 really top flight games; by having lots of good-enough games).
Notice how quality is secondary in that...
"the greatest trick the devil ever pulled was convincing the world he doesn't exist"
"the greatest trick that google ever pulled was convincing the world they were interested in anything other than new vectors for advertising..."
"would it make a difference to you if Google explicitly guaranteed that no *human* entity would get to look at your data, and that any machine-automated use of the data would be limited to a specific task (and nothing else, and never would this be changed without your consent)?"
No.
"you need to use things for which there are no standards, such as Flash"
Just an assinine aside, but nobody in the entire history of the world has ever needed to use flash.
Wanted to, yes.
Decided to, yes.
Been told to, yes.
needed to, no.
"Well, the problem with the first approach is it just plainly doesn't work. Whether or not something should work a particular way in a particular browser doesn't matter - it's whether or not it does work that matters. Every browser renders CSS a little differently, for example; even the functions that actually do work across browsers just look different depending on which browser you're running."
No! No! and thrice No!
If you code to the standards, you have coded your pages correctly if any given browser fails to handle correct pages properly, it is broken.
If you then proceed to pander to any or all broken browsers you allow the vendor to perpetuate their lazyness, and (in a certain case) to de-facto poison the standards.
What you should do is only work around errors that you know of which prevent your pages from working at all, and in your help section have a little note that "if your browser does not display correctly - please inform the vendor that they are not standards compliant"
If enough sites coded to the standard not the browser, and enough users told the vendor that the browser was broken, not the designer that the site was broken, then just maybe the standards would be worth something...
Pretty,
but possibly the most useless UI for list-format data ever; I can only read the first (counts) 19 entries, (can't read the numbers after 10). After that you have to do random sampling.
Browsable Lists - the past and future of basic data presentation!
"having the contact information centralized and standard in every Gnome installation means that other Gnome applications can use that data"
Seriously now. Replace "contact information" with "browser engine" or "media player engine" and you have the EXACT line of thought that embedded IE and MediaPlayer into Windows.
And how great a feckin' idea was THAT?!?
Slippery slope, friends...
Surely, what he should have admitted was that he was a dick, and should have credited the rest of the world with the ability to tell right from left?!?
After all, he's been proven SO wrong by... every other computer system in history. Way to go, bud.
Basically TouchTypying is a skill that is only useful for COPYING text. You gain the luxury of looking at what you're doing if you are creating as you type. Then review / edit when you've done a section.
Likewise, typing speed is only the most important element if there is no thought required during the typing.
In other words, if you are more than a copyist style and content are more important than raw speed.
Never forget; the qwerty layout is a deliberately AWFUL keyboard design, meant to slow you down; dating from the earliest typewriters which jammed very easily.
Also remember that the very best way to get RSI is to touch type for long periods.
A bit of a ramble :) My thoughts on design/methods that could move the electronic book ahead of the paper book...
Form Factor;
Clam shell (thinking Nintendo DS non its side, kind of), left and right screens. Reasonably large screens (I foresee pocketbook, softback novel, hardback novel, reference and cofee table sized readers being available ultimately) full colour and good definition. Front of reader, when closed, has a small screen allowing display of what book this reader currently "is", some controls on outside.
Rationale; able to display magazine / website content as well as "book" content. Reasonable approximation of book format, but allows enhanced capabilities (could open 1 book in each screen, navigate each screen through a book seperately etc - useful for cross reference; tabbed book reading the extension of tabbed browsing now?)
Ergonomics;
The reader is quite heavy (each version being the same weight as the equivalent real book, possibly lighter in the case of the really big ones). The reader is also rugged; as in kick around the floor and still works, rugged. Ideally it would have good battery life, and a cradle to charge (possibly induction; like my electric toothbrush)
Behaviour;
I see the default behaviours being as close to physical book as possible. I.e. you open the reader to power on, it defaults to presenting the same state that you last had that reader in - i.e. reader "becomes" a book when used. You then have availability of enhanced functionality if and when you want it. (say to load a stored state of a different book, to load annotations for a book (not just your own - think english lit study aids, or collaborative work, revision history etc)
Rationale; basic behaviour is book like for familiarity, but reader also works as a library interface)
File Format;
For my money the format should be working towards XML + XMSLT + required extra files (Fonts / Images, whatever). This is then wrapped in a common format "wrapper" file. This wrapper contains the DRM facilities as required. The end user has software that will read files, DRM allowing as necessary. End user can also have software that will compile (and possibly DRM setup) files of their own, software to convert older / other formats into this format. Nobody _needs_ software to unwrap a book once its wrapped. (not that this means it won't happen, but thats the theory)
Rationale; one format, allows DRM, actual content in non-proprietary format - many makes of reader, all books readable, huzzah!
Library;
I see the need for "Library Servers"; possibly local (wireless networking), possibly internet based, possibly both. The concept is; you book (gained however) sits in the library. The library can track what books you have, what page you were last on, which reader device you were using, any manual bookmarks you've added, annotations, whatever.
The reader can download from the library the book to read, what page etc. It can also upload to the server what book / page etc when you finish with it. (allowing the pick up and continue behaviour above)
Obviously this syncing could be automatic (the bedside reader which keeps page every night, and only changes book when finished), manual (a reader loaded with books because you're going away on a trip), or disabled (the reader that lives in the lounge for anyone to browse at whim, or your reader that you've been reading playboy in, that you don't want to have auto-load the centerfold when the kids pick it up!)
This library could be a machine at home, scaled to handle your family, plus visitors. Or it could be a central server, so that you can sync while on holiday (both so that the book you buy away from home goes home, or so that you can pick up the book you left at home while away from home) Whether this would be your machine having an externally accessible port, or a "trusted" service provider, I leave to your imaginations.
Rationale; books not lost if reader lost/destroyed. A
"This is not a problem. Not only is it not a problem, but it is at the core of getting great software out."
You've obviously never come accross the concept of "domain experts" or "requirements ellicitation".
In essence; there are two types of people in the softeware creation environment (environment specific to each piece/type of software).
Firstly there are those who have skills and familiarity with the internals of the software in question. (i.e. the white box) These are the best people to develop the software.
Secondly there are those who have skills and familiarity in the problem domain (graphic design / manipulation in the example of the gimp). These are the best people to get information on what the software needs to do, and how it should behave.(i.e. the black box)
There are maybe 10% of those who come into contact with the software, from either direction, who will have an appreciable cross over from these two camps. Admittedly these people are like gold, but like gold they are rare.
The conclusion; the best people to get feedback on what your program does or how it behaves are EXTREMELY unlikely to be in a position to help implement the changes they suggest. Generally the less technical the request "It doesn't deal with colour properly" the more insightful for the project it is likely to be.
To get specific again; if the developers have any aspirations of getting the gimp accepted by real graphic designers, then when those designers say it does something "wrong" - it does it WRONG.
Another fatuous example; if the sole of your shoe falls off; I don't need to be able to fix it for you, in order to point out the problem.
"Of course, the making of a noise may be the whole be all and end all to the complaining, with no intention of wanting a fix in the first place. Some people are like that, and that's just unfair."
See above coments, and I think you begin to see how immature this pair of sentences is.
Ugh! some facts of computing for you all: "possible" != "useable" "rtfm" != "adequately explained" "i know how" != "accessible to general public" and finally "i can answer specific instance" != "generic argument discredited"
"Trying to "unify" all the different distos so that they all can use each other's packages is missing the point. That is addressed by the GNU build tools (gcc, make, autoconf, automake, etc)." I think, if you reflect, you'll find that you've missed the point. neither I nor the article mentioned having all the distributions use the same packaging system. Ever. The original article suggested a unified GUI to control (graphically) any of the varying install methods in some sort of "unified" method - that doesn't imply shoe-horning them all to use the exact same wizard / controls, just having a single application in the desktop system to drive the correct one. (Think: gnome/kde/whatever provides the very basic/generic controller, each distributor can write the specific handler for their distribution and add that to their install My comment was more a rant against the depth to which a NEW user has to read in order to first; find out what bizarre name this distribution has given to the mechanism for "Install New Program" or "Upgrade Installed Program" - hint; its never "Install Program"! And second the further depth to which I must plunge in order to do this; hint 2 "make all" is not a suitable install method in the 21st century - unless you are a sysadmin/nerd.
"The answer could be an installation application that can speak to all of the popular distributions. It could be built in such a modular way as to allow new backends and functionality. Alternatively, a standard application installation procedure could be created that is supported by the majority of distributions (perhaps in addition to the native methodology)."
/Rant
;)
As a long-time Windows user, on and off trying to make a transition to Linux (as in tried several times, always reinstalled windows in the end) this is the single thing that jumped to my mind when trying Linux.
Basically, how the **** do I install / update programs?!? (I know, I RTFM; but why do I have to read a different friendly manual for each distribution I trial run?)
WTF is an emerge, and if its so great, why does only gentoo use it? What is an RPM? Exactly HOW do I install or upgrade on mandrake (realy; i have no idea!) What is a modprobe - and why should I need to know? For a desktop OS, _no_ configuration change should be commandline only... (like samba; I got it working no problems, but had to go to a root prompt and edit a file in vi - WTF?)
All these rants and more should not go through the new adopter's mind, if Linux is to ever become a mainstream desktop OS - because average users don't RTFM (you don't have to if you want to be a dumb-user in windows/macos), and don't have friendly sysadmins to do the setup for them.
thanks for your patience; feel much better now
You forgot Assumptions -1 and 0 in the above:
-1 That the user already knows about man in order to try it.
0 That the user has another machine on which to use google to find out how to use the fort one
Pretty big Ass-U-Me's there.
If that were true, the right hand edge of the calculator would not be vertical. One of two things is demonstrated in that image; either 1: there is something wonky in the rendering of that set of windows. or 2: that kind of 3d rendering of a desktop makes some or all users think that something is wonky with the rendering. I think that its a situation similar to motion sickness, where your inner ear reports that you are in motion and your eyes report that your surroundings aren't moving; recult is nausea. In this case part of your brain thinks "thats a 3d thing, with intersections and stuff" and the rest is thinking "its on a flat panel". Result, a vague unease about the entire display. At least thats what I felt looking at the intersection and "sphere" demo images. I got the distinct impression that those desktops would give me a headache in around 5 minutes. YMMV, of course.