My point was to reject "information as property". Just because a person can string together words that invoke powerful emotion, or another can do the same with streams of vibration from a musical instrument does not, in my mind, make those streams themselves (or copies thereof) sole dominion of the one who has strung them together.
I would disagree with this viewpoint -- I would argue that one has a legitimate claim of ownership to the proceedings of one's labor , whether tangible or otherwise.
However, there are disagreements about this. At the very least, it should be clear that if the authors of creative or intellectual works are not given the means to claim due compensation for their labor, it will undermine industries based on intellectual work.
It's interesting to note that the countries with stronger copyright laws tend to be the most productive in this sense.
There are not forced abortions to meet the "one child" limit..
IIRC, there are forced sterilisations. There are exceptions to the one child rule, but in the end, the government decides all. And the government, after all, are not accountable to anyone.
You know, I saw a Chinese music show, and these guys were playing this soppy luv song ( oh, btw, one of them had died hair ) and part way through, the guy broke into a rap ! Yep, their youth are being "corrupted" as we speak.
Probably Chinese culture isn't so deranged as U.S. culture over the issue of sex, it's difficult to imagine another country with a culture as guiltily obsessed as this one
Hahaha... actually, they're more so. Girls get arrested for prostitution for having sex with foreigners. That's a permanent criminal record and a kiss good-bye to any future you may have had. People get thrown out of university for having sex. Producing pornography incurs the death sentence. You think the US is neurotic ??? Well I'm not saying that it's not bad, but you could certainly do worse.
AFAIK, you can get thrown into jail for viewing porn in China, or so my Chinese girlfriend who lived there a few yrs back tells me. They're certainly tough on anything resembling sexuality...
I "use strict;" in all of my programs. Writing maintainable code and writing "good" code are two different things. Sometimes it makes code more maintainable to violate standard spacing practice (rarely, but I've seen it in most of the code that I've looked at).
Depends. In perl, maybe. I haven't seen any python programs that would benefit that much from substantial respacing. And losing those braces makes the code a hell of a lot more readable. Whitespace is not a crutch. It makes your code more readable even if it's already coherent. I write readable perl programs, but the same thing in python is usually more readable ( and I've written more perl than python )
Sometimes faster code is perfectly maintainable but not asthetically pleasing to a python programmer.
If you want faster code, you can always use C from python or vice versa. I don't get why you think python is "slow". One usually doesn't use python for speed-critical tasks. You write ( or rewrite ) the speed-critical stuff in C. Ditto for perl -- a lot of perl isn't terribly fast or efficient either ( which is why several of the modules are not pure perl )
[ nonsense snipped ]
A lot of these comments are outright wrong. There is a for statement. You can run python straight from the command line. If you bothered to learn about python ( rather than just prejudging it ), you would know this.
I use perl and python, and like both. I could see good arguments for using either depending on circumstances. For example, there's no way I'd do any serious GUI development in perl ( don't talk to me about perl-Tk. I've used it. One word: "spaghetti" ) However, I'd prefer perl for string manipulation. For this task, Python is functional, but doesn't "feel" as easy.
However, it seems that you're dismissing python on the basis of it's whitespace formatting alone. Well if you're too narrow minded to learn something new, that's your problem (-;
I've used perl for a while and like it. I've also started dabbling with python and like that too. I don't really agree with any of the "standard" criticisms of perl or python.
Personally, I don't see what all the wars are about.
1) most of the programming has been by-geeks-for-geeks, which tends not to emphasize gui;
True. Partly though, there was no good GUI framework available.
2) x and its window managers have traditionally been sluggish and offered poor functionality (for a desktop UI -- let's not get into the running programs in Moscow from NYC stuff), so *nix die-hardss don't expect much;
Window managers and X aren't supposed to do very much. The problem is that no one developed much of a GUI to go on top of these , though KDE and GNOME are a good start.
3) programming in traditional *nix toolkits wasn't particularly easy or pleasant, which cut down the incentive to do it;
True as far as the GUI stuff is concerned.
4)Motif was not free.
This was a biggie -- it made Motif a non-starter on Linux. long term, this is probably a good thing, because it forced the Linux people to design replacements -- QT and GTK -- which are much better suited to writing modern desktop applications ( and are unburdened my the runtime license ). In all fairness to the Linux people, GTK and QT only started in 96, so the Linux GUI is really still quite a new beast.
But anyhow, GNOME and KDE are, just as the author stated in his article, are just getting closer and closer to functioning like Windows
KDE and GNOME are primarily development toolkits, not user interfaces. Most of the effort thus far has gone into creating APIs.
Listening to the public instantly means you're clueless.
If it doesn't work for your users, it doesn't work. Obviously, listening to everything Joe user says is not desirable ( for example, Joe user doesn't know much about application design ). However, it's important to be receptive to feedback from your users.
If I went up to the guys that create GNOME and KDE and told them everything they are doing is old-fashioned
Such as what ? If you have any brilliant ideas, I suggest you post them to the KDE mailing lists instead of whining on slashdot. You may be surprised. Since you say "if", you obviously haven't tried to offer any input.
There are three fairly easy scripting languages for Linux -- Tcl, Python and Perl. These will feel much friendlier and less foreign to someone coming from your background. Personally, I'd recommend you try Python. This is probably the best choice for GUI stuff. perl is very good at manipulating strings ( say for automatically writing html and stuff like that ).
IMO, I don't think we need BASIC, because we already have languages that are much better. However, development tools ( such as GUI buiders and IDEs ) to go on top of those languages would be cool. Cheers,
Its not that they don't know or don't care, its mostly because they're rampant conformists.
Not really true. Mostly, it's been because the target audience were traditional UNIX users who didn't care that much, and that the GUI toolkits they were using simply sucked. This is starting to change with GNOME/GTK and KDE/QT
To denounce the absolutely horrid and disgusting UI of Linux is to spit on their holy ground,
This statement is a gross over-generalisation at best. If you bothered to discuss usability issues with the GNOME/KDE developers, you'd see that they really are listening to the users.
There are some sane Linux users out there but sadly, they're just that, users.
If you're implying that the KDE and GNOME people are "not sane", I'd say this statement is outright slander.
She also clearified that Linux GUI designers should do useability testing w/ Average Users (sounds like SUCH a corporate thing to do, but it makes sense).
I also think this kind of thing would be a great idea. "such a corporate thing" ? You're dead right -- and it would probably require some real money, preferably some form of corporate sponsorship, to get it right.
KDE and GNOME have taken an important step -- they have started listening to the users, as opposed to the "old fashioned" way when you listened only to yourself, and maybe other developers. It would seem that the next logical step is to cast a wider net -- and start listening to more users.
We'l always have several GUI frameworks (Qt, Gtk, the Xt-based (Motif, AThena), OpenLook, etc).
I predict we'll have two -- QT and GTK. These two kits are so similar that with a certain amount of effort at compatibility, they won't be too obviously incompatible. Motif is as good as dead on Linux -- Netscape is probably ``Motif's last stand''. The main problem with Motif is that it requires an expensive runtime license, which is why GTK and QT got started in the first place ( to replace the functionality of Motif on Linux ). Openlook ? Are you kidding ? I can't remember using an OpenLook application. Is it still maintained ? As for Athena, no one's going to use it with QT and GTK available.
Don't say communistic when you mean totalitarian. Contrary to neo-McCarthyist propoganda, they are not only inequivalent, neither is sufficient to infer the other.
It hardly seems that the number of those it takes to accomplish something is truly a unique application of any sort.
The patent doesn't cover the `number of those it takes to accomplish something'. The patent essentially talks about storing user profiles in a database and using cookies client side to simplify things, IIRC. The process, as described in the patent ( which you obviously haven't read ) , would appear to be as `unique' as a paperclip.
Take a look at how the S&P and the Dow Jones have been doing recently. Take a look at how the perofrmance of these indices compare to dividend yields of dividend stocks-- how many companies can you name with a dividend yield of more than 5% ? Many dividend stocks do not perform much better than savings accounts if you only consider the dividend yields. Something like an index fund ( or any solid mutual fund ) will not only have a modest dividend yield but also have some growth. What this tells us is that if the average Joe sticks money into a diversidied portfolio ( or mutual fund ), the chances are that they will make money.
However it's important to invest in companies with a good business model ( not like Redhat ). Companies that don't and wont turn operating profits are simply put, bubbles. On the other hand, promising companies that are experiencing steady earnings growth can make good investments, dividend or no dividend.
live on buying low and selling high, in the long run you'll take losses as well as gains.
Yes, but if you gain on average, then that's not a problem. If you're talking about day trading, then I agree. However, there is a case to be made for investing in growth stocks with solid financial performance and a good business strategy.
These huge initial gains and later losses are typical of all hi-tech papers, Yahoo and Amazon have similar price histories.
These companies have poor financial records. One needs to consider not just possible stock increase -- it's important also to check that the price increases are driven by earnings increases and not hype. In the case of internet bubble stocks, the companies not only aren't experiencing solid earnings growth, they aren't even able to run at an operating profit.
Tech stocks typically have P/E ratios of over 60 unless the company in questionis in big trouble. This means that it is impossible for the companies to pay decent dividends -- more than a 1.7% dividend would use up all the companies annual profit. On the other hand, big established companies that aren't experiencing rapid earnings growth and consequently carrying more realistic P/E levels are more prone to paying dividends.
Re:Windows forces costly upgrades for home users.
on
Making Linux Beautiful
·
· Score: 2
If we're talking about people who just want word processing and web access, then there are a lot of people who don't need new hardware. Gamers need new hardware; you mum shouldn't.
If "your mum" wants to use Star Office and Netscape, then I can only hope she has decent hardware. The hardware requirements for Linux/KDE/Star Office are steeper than those for Win98/MS Office. Moreover, since we're talking about "your mum", I take it she wants binaries, which means that she's not going to run an a.out distribution. Simply put, you are not being realistic. For the type of distribution your mum is going to use, you are not going to get by with a 486. I was talking to a friend who has a 486 and she's going to have a hard time getting Linux installed ( she doesn't have a CDROM drive ). The machine has 170MB HD space which is not adequate for most Linux distributions ( not if you want it to be half user-friendly anyway. ) KDE and StarOffice alone would take up most of her hard drive.
No, glibc 2.0 was not meant to be a stable release. Some distributions heeded this; some didn't.
a.out->libc5->glibc. I count two major changes ( I don't count glibc 2.0 -> glibc 2.1 )
It is a nice feature of Linux that you can choose to exclude functionality that you don't need or want, and get a leaner distribution. However, to the average end user who wants an office suite , a "desktop environment", and a GUI web browser, the fact that you can choose to take these things out is largely irrelevant. If you choose to run all of this stuff, you do need fairly decent hardware ( pentium or better, with 32MB of RAM or more -- about the same as NT )
You can't easily build a MacOS X clone on X windows, becuase you can build something good and modern ontop of something that crap and ancient.
Well you offer no convincing evidence that X is "crap and ancient", or that there's anything deeply broken about it. Apple are fortunate enough to have code for their MacOS windowing system lying around, so porting it to MacOS was somewhat easier than it would be for Linux developers to write a new windowing system from scratch. If you wish to do that, and consequently screw your X compatibility, you may as well extend the X protocol ( the price to be paid would be that your applications written for the new system may not be X compatible ) rather than do a complete re-write, which seems like a good foundation.
We need to re-create the whole X windows layer properly.
Well that's easy to say, but there's a lot of problems. Compatibility is the biggest one. The second biggest is the amount of effort involved ( how far has Berlin progressed ? )
but lets have a font system that works, a colour system that works, a layout system that works, a window system that works better, and a rendering system that doesn't crawl and maybe even uses vectors.
Vector graphics can be built in via DPS. No need to rewrite X. I believe DPS also could potentially help attack the font problem. The biggest problem with fonts at present is the lack of print/display unification, the second biggest is antialiasing ( which DPS can do ).
There's nothing besides compatibility stopping someone hacking the X protocol to deal with font issues. In other words, if your philosophy is "to hell with compatibility", then the functionality you speak with could probably be built into X. I believe that the color system ( if you're talking about calibration ) could be taken care of without trashing X because it could probably be made strictly server-side ( ie the Xclient wouldn't have to know about it. ) In conclusion, I think the features you want are certainly desirable, but I don't think you need to throw away X to get them.
The FDU HOWTO is cool, but too narrow in scope -- it is too TrueType centered , and acts as though TrueType is the only game in town. Check out the Font HOWTO for something more comprehensive.
We do. We have KDE/QT and GNOME/GTK. These projects are really more about desktop APIs than they are about "desktop managers". In terms of the way they work, they appear to be converging -- they are remarkably similar ( GTK seems a lot like QT-in-C )
I essentially agree with you, However, you may find this helpful if Netscape is the app that's giving you trouble. In short, the main problem with Netscape is that it displays the fonts too small.
Slashdot Mirror
I would disagree with this viewpoint -- I would argue that one has a legitimate claim of ownership to the proceedings of one's labor , whether tangible or otherwise.
However, there are disagreements about this. At the very least, it should be clear that if the authors of creative or intellectual works are not given the means to claim due compensation for their labor, it will undermine industries based on intellectual work.
It's interesting to note that the countries with stronger copyright laws tend to be the most productive in this sense.
IIRC, there are forced sterilisations. There are exceptions to the one child rule, but in the end, the government decides all. And the government, after all, are not accountable to anyone.
And now it's being built to keep the Western invaders out. Only this time, the invasion is cultural/political and not military.
Hahaha ... actually, they're more so. Girls get arrested for prostitution for having sex with foreigners. That's a permanent criminal record and a kiss good-bye to any future you may have had. People get thrown out of university for having sex. Producing pornography incurs the death sentence. You think the US is neurotic ??? Well I'm not saying that it's not bad, but you could certainly do worse.
Depends. In perl, maybe. I haven't seen any python programs that would benefit that much from substantial respacing. And losing those braces makes the code a hell of a lot more readable. Whitespace is not a crutch. It makes your code more readable even if it's already coherent. I write readable perl programs, but the same thing in python is usually more readable ( and I've written more perl than python )
Sometimes faster code is perfectly maintainable but not asthetically pleasing to a python programmer.
If you want faster code, you can always use C from python or vice versa. I don't get why you think python is "slow". One usually doesn't use python for speed-critical tasks. You write ( or rewrite ) the speed-critical stuff in C. Ditto for perl -- a lot of perl isn't terribly fast or efficient either ( which is why several of the modules are not pure perl )
[ nonsense snipped ]
A lot of these comments are outright wrong. There is a for statement. You can run python straight from the command line. If you bothered to learn about python ( rather than just prejudging it ), you would know this.
I use perl and python, and like both. I could see good arguments for using either depending on circumstances. For example, there's no way I'd do any serious GUI development in perl ( don't talk to me about perl-Tk. I've used it. One word: "spaghetti" ) However, I'd prefer perl for string manipulation. For this task, Python is functional, but doesn't "feel" as easy.
However, it seems that you're dismissing python on the basis of it's whitespace formatting alone. Well if you're too narrow minded to learn something new, that's your problem (-;
Using C++ / STL, it's probably doable. It's not the kind of thing I'd do myself in C, since someone's already done a better one.
Personally, I don't see what all the wars are about.
1) most of the programming has been by-geeks-for-geeks, which tends not to emphasize gui;
True. Partly though, there was no good GUI framework available.
2) x and its window managers have traditionally been sluggish and offered poor functionality (for a desktop UI -- let's not get into the running programs in Moscow from NYC stuff), so *nix die-hardss don't expect much;
Window managers and X aren't supposed to do very much. The problem is that no one developed much of a GUI to go on top of these , though KDE and GNOME are a good start.
3) programming in traditional *nix toolkits wasn't particularly easy or pleasant, which cut down the incentive to do it;
True as far as the GUI stuff is concerned.
4)Motif was not free.
This was a biggie -- it made Motif a non-starter on Linux. long term, this is probably a good thing, because it forced the Linux people to design replacements -- QT and GTK -- which are much better suited to writing modern desktop applications ( and are unburdened my the runtime license ). In all fairness to the Linux people, GTK and QT only started in 96, so the Linux GUI is really still quite a new beast.
KDE and GNOME are primarily development toolkits, not user interfaces. Most of the effort thus far has gone into creating APIs.
Listening to the public instantly means you're clueless.
If it doesn't work for your users, it doesn't work. Obviously, listening to everything Joe user says is not desirable ( for example, Joe user doesn't know much about application design ). However, it's important to be receptive to feedback from your users.
If I went up to the guys that create GNOME and KDE and told them everything they are doing is old-fashioned
Such as what ? If you have any brilliant ideas, I suggest you post them to the KDE mailing lists instead of whining on slashdot. You may be surprised. Since you say "if", you obviously haven't tried to offer any input.
IMO, I don't think we need BASIC, because we already have languages that are much better. However, development tools ( such as GUI buiders and IDEs ) to go on top of those languages would be cool.
Cheers,
Not really true. Mostly, it's been because the target audience were traditional UNIX users who didn't care that much, and that the GUI toolkits they were using simply sucked. This is starting to change with GNOME/GTK and KDE/QT
To denounce the absolutely horrid and disgusting UI of Linux is to spit on their holy ground,
This statement is a gross over-generalisation at best. If you bothered to discuss usability issues with the GNOME/KDE developers, you'd see that they really are listening to the users.
There are some sane Linux users out there but sadly, they're just that, users.
If you're implying that the KDE and GNOME people are "not sane", I'd say this statement is outright slander.
I also think this kind of thing would be a great idea. "such a corporate thing" ? You're dead right -- and it would probably require some real money, preferably some form of corporate sponsorship, to get it right.
KDE and GNOME have taken an important step -- they have started listening to the users, as opposed to the "old fashioned" way when you listened only to yourself, and maybe other developers. It would seem that the next logical step is to cast a wider net -- and start listening to more users.
I predict we'll have two -- QT and GTK. These two kits are so similar that with a certain amount of effort at compatibility, they won't be too obviously incompatible. Motif is as good as dead on Linux -- Netscape is probably ``Motif's last stand''. The main problem with Motif is that it requires an expensive runtime license, which is why GTK and QT got started in the first place ( to replace the functionality of Motif on Linux ). Openlook ? Are you kidding ? I can't remember using an OpenLook application. Is it still maintained ? As for Athena, no one's going to use it with QT and GTK available.
Don't say communistic when you mean totalitarian. Contrary to neo-McCarthyist propoganda, they are not only inequivalent, neither is sufficient to infer the other.
The patent doesn't cover the `number of those it takes to accomplish something'. The patent essentially talks about storing user profiles in a database and using cookies client side to simplify things, IIRC. The process, as described in the patent ( which you obviously haven't read ) , would appear to be as `unique' as a paperclip.
Take a look at how the S&P and the Dow Jones have been doing recently. Take a look at how the perofrmance of these indices compare to dividend yields of dividend stocks-- how many companies can you name with a dividend yield of more than 5% ? Many dividend stocks do not perform much better than savings accounts if you only consider the dividend yields. Something like an index fund ( or any solid mutual fund ) will not only have a modest dividend yield but also have some growth. What this tells us is that if the average Joe sticks money into a diversidied portfolio ( or mutual fund ), the chances are that they will make money.
However it's important to invest in companies with a good business model ( not like Redhat ). Companies that don't and wont turn operating profits are simply put, bubbles. On the other hand, promising companies that are experiencing steady earnings growth can make good investments, dividend or no dividend.
live on buying low and selling high, in the long run you'll take losses as well as gains.
Yes, but if you gain on average, then that's not a problem. If you're talking about day trading, then I agree. However, there is a case to be made for investing in growth stocks with solid financial performance and a good business strategy.
These huge initial gains and later losses are typical of all hi-tech papers, Yahoo and Amazon have similar price histories.
These companies have poor financial records. One needs to consider not just possible stock increase -- it's important also to check that the price increases are driven by earnings increases and not hype. In the case of internet bubble stocks, the companies not only aren't experiencing solid earnings growth, they aren't even able to run at an operating profit.
If "your mum" wants to use Star Office and Netscape, then I can only hope she has decent hardware. The hardware requirements for Linux/KDE/Star Office are steeper than those for Win98/MS Office. Moreover, since we're talking about "your mum", I take it she wants binaries, which means that she's not going to run an a.out distribution. Simply put, you are not being realistic. For the type of distribution your mum is going to use, you are not going to get by with a 486. I was talking to a friend who has a 486 and she's going to have a hard time getting Linux installed ( she doesn't have a CDROM drive ). The machine has 170MB HD space which is not adequate for most Linux distributions ( not if you want it to be half user-friendly anyway. ) KDE and StarOffice alone would take up most of her hard drive.
No, glibc 2.0 was not meant to be a stable release. Some distributions heeded this; some didn't.
a.out->libc5->glibc. I count two major changes ( I don't count glibc 2.0 -> glibc 2.1 )
It is a nice feature of Linux that you can choose to exclude functionality that you don't need or want, and get a leaner distribution. However, to the average end user who wants an office suite , a "desktop environment", and a GUI web browser, the fact that you can choose to take these things out is largely irrelevant. If you choose to run all of this stuff, you do need fairly decent hardware ( pentium or better, with 32MB of RAM or more -- about the same as NT )
Well you offer no convincing evidence that X is "crap and ancient", or that there's anything deeply broken about it. Apple are fortunate enough to have code for their MacOS windowing system lying around, so porting it to MacOS was somewhat easier than it would be for Linux developers to write a new windowing system from scratch. If you wish to do that, and consequently screw your X compatibility, you may as well extend the X protocol ( the price to be paid would be that your applications written for the new system may not be X compatible ) rather than do a complete re-write, which seems like a good foundation.
We need to re-create the whole X windows layer properly.
Well that's easy to say, but there's a lot of problems. Compatibility is the biggest one. The second biggest is the amount of effort involved ( how far has Berlin progressed ? )
but lets have a font system that works, a colour system that works, a layout system that works, a window system that works better, and a rendering system that doesn't crawl and maybe even uses vectors.
Vector graphics can be built in via DPS. No need to rewrite X. I believe DPS also could potentially help attack the font problem. The biggest problem with fonts at present is the lack of print/display unification, the second biggest is antialiasing ( which DPS can do ).
There's nothing besides compatibility stopping someone hacking the X protocol to deal with font issues. In other words, if your philosophy is "to hell with compatibility", then the functionality you speak with could probably be built into X. I believe that the color system ( if you're talking about calibration ) could be taken care of without trashing X because it could probably be made strictly server-side ( ie the Xclient wouldn't have to know about it. ) In conclusion, I think the features you want are certainly desirable, but I don't think you need to throw away X to get them.
We do. We have KDE/QT and GNOME/GTK. These projects are really more about desktop APIs than they are about "desktop managers". In terms of the way they work, they appear to be converging -- they are remarkably similar ( GTK seems a lot like QT-in-C )