Whenever there is any discussion on Enlightenment, many people complain about how slow it is, while many other people comment on how fast it is. The truth is that it is highly configurable, and if you use the features, you pay in RAM and CPU. One option is to play with all the different features, and find a good balance of featurefull-ness. This takes time. Perhaps it would be easier to obtain this balance if E's configuration program gave the user some indication of how much resources their configuration was taking up. -- Man is most nearly himself when he achieves the seriousness of a child at play.
The problem with this WM is that it makes Windows users think that they know what they are doing, when actually, the system works completely differently. Also, there are subtle differences in look and feel.
I would go with windowmaker in this situation. You can build a pretty cool environment: make buttons for the applications that you need, and associate icons with them (if necessary). -- Man is most nearly himself when he achieves the seriousness of a child at play.
"Red Hat's new release of the Linux operating system has been optimized for the Pentium III Xeon processor and this combination offers customers the performance that is required in today's Internet economy." Does this mean that it doesn't run on a 386? -- Man is most nearly himself when he achieves the seriousness of a child at play.
I believe that you are talking about COLD Fusion. This article was about CODE Fusion. -- Man is most nearly himself when he achieves the seriousness of a child at play.
Java will never be as fast as C. It simply isn't appropriate for an OS. I believe that the JavaOS was to be written mostly in Java, with device drivers etc. in C. However it makes much more sense to start with a functional, speedy OS (say, Linux) and wrap the kernel/libc functionality in Java code. -- Man is most nearly himself when he achieves the seriousness of a child at play.
You are correct that the book is about inefficiencies brought about when there are several programmers. However, the whole point is that big projects require big teams of programmers (projects such as IBM's OS/360 (Brooks was the manager)). In a nutshell, Brooks said that the project needs to have one person who determines the architecture. By this term he means the user specifications. There should be a separate person who is the chief implementor.
-- Man is most nearly himself when he achieves the seriousness of a child at play.
: It's worth noting that G, A, T, and C are the : four symbols in your DNA. : : There is no I.
When I first looked at this comment, I noticed that GCAT are not themselves part of your DNA, but merely represent the molecules that do constitute your DNA. Thats when the other meaning of the second sentence hit me. (Insert Hofstadter (The Mind's Eye/GEB) and Dawkins (The Selfish Gene) blather here) -- Man is most nearly himself when he achieves the seriousness of a child at play.
I just found this movie site two days ago, and its great. Its called "coming attractions" and it has lotsa great info on upcomming movies. Anyhoo, there is something similar (out of the mouth of Tarantino, no less!): pulp muppets.
Whoops, forgot to mention how ironic my evidence-gathering is. man, I crack myself up. -- Man is most nearly himself when he achieves the seriousness of a child at play.
You are absolutely correct. Now that I think about it, when I am in "hack mode" the command line is definitely better. However, GUIs are nicer when you don't really want to think. GUIs are "push", and CLIs are "pull". (This analogy works pretty well, except when it comes to web browsing. Thats definitely more "pull", as the user is in total control over what content appears.) One thing that I didn't stress, but is implicitly in what I said, is that it is best to have both. For example, a sophisticated user can type ls -lat *.txt | head much faster than figuring out how to do something equivalent in a GUI.
Personally, I think that scalability is the key. The canonical example is accelerator keys. Sure, to save your work you click on the "file" menu, then click on the "save" item. But after seeing "Alt-S" next to "save" repeatedly, more advanced users can quickly use the shortcut, and not take their hands away from the keyboard (assuming that they were typing).
I was dead serious when I said that a program is a failure when you needed to consult the documentation. I resent having to type "man foo" to find out the name of an option, or to learn what options are there. When you are coding, man pages are the right thing. But GUIs are apparently useful for this - a friend of mine recently told me M$ visual C++ product is really good. He definitely knows his stuff - he recently helped me hack the redhat 6.0 install so I could install directly off my paride cd-rom.
By the way, here is some evidence:
[kip@chimera kip]$ history | cut -c 8- | cut -d" " -f1|sort | uniq -c | sort -rn|head 139 fg 115 jobs 99 ls 98 l # aliased to ls -l 73 cd 66 nls # basically nfrm 50 less 36 pine 26 cly # lynx -color + a pun;-)
-- Man is most nearly himself when he achieves the seriousness of a child at play.
I recently installed RH6.0, and KDE 1.1.1. I am very impressed so far with the ease of use of the integrated WM, panel, taskbar, etc. I haven't even spent any time playing with any of the Kapplications yet. I would like to make a few comments on the importance of Desktop Environments:
Ease of use for newbies. Consider the file manager/web browser. How many CLI utils does it supplant? Well letsee, theres man, ls, file, pwd, cd, pushd/popd, mkdir, cp, mv, rm, chmod, tree... (BTW: some of these are implemented in the shell, but thats not relevant to my point) True, KFM doesn't have as much functionality/configurability as these tools + scripts and aliases. I bet that 99% of the time when you use the 'ls' command, you don't use any of these functions (not counting alias ls='ls -kitcnsink'). For a linux newbie, KFM is much easier than remembering/learning:
what the commands are called (btw: note cd/chdir/md/mkdir inconsistency)
how to use them
how to get help on them
how to decipher/grep through the resulting man page
how to save options (i.e. with aliases)
how to do things to groups of files (if you try to figure out mv *~ tmp from the man pages, you need to wade through the bash documentation. The KDE help docs say that I can select multiple files by right clicking on each, but it doesn't say anything about the edit>>select command (where I can type in *~))
This is all well and good for newbies, but what about the power users? well, the command line isn't going anywhere. And if you can accomplish 90% of your goals in a simple, consistent manner, more power to you. I may be a relatively sophisticated linux user, but that doesn't mean that I want to read man pages. This brings me to my second point:
Bloat is good. Lets say it costs you, a Linux user who "knows where his towel is", $100 to upgrade your computers RAM to run KDE or Gnome. Lets assume that you spend 10 minutes a day remembering the names of common commands, reading man pages, mis-spelling 'chmod', using the wrong one-letter options (let me tell you, when I first started using gcc I figured gcc -o foo.c should do what gcc -c foo.c does. oops), reading and understanding error messages, etc. Lets further assume that these mistakes are eliminated by going to KFM, so you save the 10 mins a day. If you time is worth 10 bucks an hour, you save 10/6 = $1.6 a day. You only need 100/1.6 = 60 days to recoup your investment. After that, its pure profit, baby! This doesn't take into account subjective improvements, like ease of use.
One more thing: one goal of user-interface design (especially GUI design) is to make the system "self-documenting", i.e. its pretty intuitive how to do simple things, and when the user wants to do more complex things, he is exposed to more stuff and it is pretty clear how to proceed. Its usually easier to mess around with a program than to read a manual (or man page, eek). In fact, if a user needs to read documentation, the program is a failure. This is just an elaboration of the 'subjective enjoyment' point above.
KDE vs. M$ - true, the enhancements listed here already exist in M$ winblows. however, I want to point out that
KDE doesn't have a marketing department (despite the tenor of the 2.0 annoucement). Therefore KDE developers can focus on the features users actually want, not what somebody thinks that the users think that they want.
As KDE is opensource, incremental change is "free" and continuous. This last point is actually very important, as the little bugs are really the most annoying/disruptive.
Finally, (and this point actually distinguishes between KDE and Gnome), it appears to me that KDE is more focused on actual usability. Take the whole 'themes' mess for example. Ok, so Gnome has better theme support right now. So what? Themes are counterproductive, IMHO. If every user has different keybindings and widgets that look and act differently, that is definite lossage, when it comes to usability. (note that I don't have experience with themability, I might be wrong about this). However, I think that we will all agree that Enlightenment's excesses are gratuitous, and, ultimately, useless eye-candy. (sweets are good...but my P 100/ 40MB ram laptop is on a diet) And another thing. Quoting Object-Oriented Software Construction (Bertrand Meyer): "Correctness is the prime quality. If a system does not do what it is supposed to do, everything else about it - whether it is fast, has a nice user interface... - matters little." If a program crashes, it is not correct. KDE appears to focus on this more than Gnome. (read this book. Even if you only read p.3 - p.20, on the definition of software quality.)
well, thats my 2 cents. Don't spend it all in one place!
(OT: this new version of lynx is great, I love being able to use emacs for doing form input. The old way truly was bletcherous.) -- Man is most nearly himself when he achieves the seriousness of a child at play.
I believe he means something like int* foo (int bar) { return &bar; } because in C, parameters to functions are stored on the stack. I bet auto variables (like ralph) are also stored on the stack, but your code is fine; you don't return the address of ralph. [Just don't forget to free;-)] -- Man is most nearly himself when he achieves the seriousness of a child at play.
I just wanted to point out that each book review is done by a different person, with a different idea of what they want in a book, what qualifies as a '10', etc. As others have pointed out, the reviewer doesn't really talk about using this book and the standard Perl docs together. As far as introductory Perl books go, IMHO the most important aspect is how well scalar/list context is explained. In all other prog. langs that I can think of, whatever is inside the parens is not affected by whats outside. I don't know how well this book explains this, however. -- Man is most nearly himself when he achieves the seriousness of a child at play.
The GPL says no such thing. However, seeing as the software is freely downloadable, it would be difficult to convince someone to pay beaucoup bux. -- Man is most nearly himself when he achieves the seriousness of a child at play.
Opensource style development is incompatible with tradional HCI. When someone has an 'scratches an itch' and writes code, he typically does it for new features. While this is a decent way to add functionality, ease of use cannot be added in such a slipshod way. UI "Refactorings" are pretty uncommon in practice, I think. -- Man is most nearly himself when he achieves the seriousness of a child at play.
Although the kernel is GPL'ed, the FSF does not own the copywright. The FSF insists on owning the copywright for all the code. You can get it straight from the horses mouth here. -- Man is most nearly himself when he achieves the seriousness of a child at play.
preferences just plain don't work
on
Slashdot Updates
·
· Score: 1
thats what quotemeta is for. -- Man is most nearly himself when he achieves the seriousness of a child at play.
This is a big problem. If there is a loss of power for more then 3 days, there WILL be meltdowns. The problem is that so much is dependent on power, railroads, oil. The big one, of course, is power. If there are major power outages, it will severely harm all other industries. Not scared yet? checkout this site.
-- Man is most nearly himself when he achieves the seriousness of a child at play.
Slashdot Mirror
Actually, I use KDE. I also used to use windowmaker.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Whenever there is any discussion on Enlightenment, many people complain about how slow it is, while many other people comment on how fast it is. The truth is that it is highly configurable, and if you use the features, you pay in RAM and CPU. One option is to play with all the different features, and find a good balance of featurefull-ness. This takes time. Perhaps it would be easier to obtain this balance if E's configuration program gave the user some indication of how much resources their configuration was taking up.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
I would go with windowmaker in this situation. You can build a pretty cool environment: make buttons for the applications that you need, and associate icons with them (if necessary).
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Obviously, it was the original Anonymous Coward.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
"Red Hat's new release of the Linux operating system has been optimized for the Pentium III Xeon processor and this combination offers customers the performance that is required in today's Internet economy." Does this mean that it doesn't run on a 386?
--
Man is most nearly himself when he achieves the seriousness of a child at play.
feeBSD? ;-)
--
Man is most nearly himself when he achieves the seriousness of a child at play.
I believe that you are talking about COLD Fusion. This article was about CODE Fusion.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Java will never be as fast as C. It simply isn't appropriate for an OS. I believe that the JavaOS was to be written mostly in Java, with device drivers etc. in C. However it makes much more sense to start with a functional, speedy OS (say, Linux) and wrap the kernel/libc functionality in Java code.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Perl's expressions are far from regular. They are NP-Complete.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
: four symbols in your DNA.
: There is no I.
When I first looked at this comment, I noticed that GCAT are not themselves part of your DNA, but merely represent the molecules that do constitute your DNA. Thats when the other meaning of the second sentence hit me. (Insert Hofstadter (The Mind's Eye/GEB) and Dawkins (The Selfish Gene) blather here)
--
Man is most nearly himself when he achieves the seriousness of a child at play.
http://corona.bc.ca/films/details/pu lpmuppets.html
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Whoops, forgot to mention how ironic my evidence-gathering is. man, I crack myself up.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Personally, I think that scalability is the key. The canonical example is accelerator keys. Sure, to save your work you click on the "file" menu, then click on the "save" item. But after seeing "Alt-S" next to "save" repeatedly, more advanced users can quickly use the shortcut, and not take their hands away from the keyboard (assuming that they were typing).
I was dead serious when I said that a program is a failure when you needed to consult the documentation. I resent having to type "man foo" to find out the name of an option, or to learn what options are there. When you are coding, man pages are the right thing. But GUIs are apparently useful for this - a friend of mine recently told me M$ visual C++ product is really good. He definitely knows his stuff - he recently helped me hack the redhat 6.0 install so I could install directly off my paride cd-rom.
By the way, here is some evidence:
[kip@chimera kip]$ history | cut -c 8- | cut -d" " -f1|sort | uniq -c | sort -rn|head ;-)
139 fg
115 jobs
99 ls
98 l # aliased to ls -l
73 cd
66 nls # basically nfrm
50 less
36 pine
26 cly # lynx -color + a pun
--
Man is most nearly himself when he achieves the seriousness of a child at play.
- Ease of use for newbies. Consider the file manager/web browser. How many CLI utils does it supplant? Well letsee, theres man, ls, file, pwd, cd, pushd/popd, mkdir, cp, mv, rm, chmod, tree... (BTW: some of these are implemented in the shell, but thats not relevant to my point) True, KFM doesn't have as much functionality/configurability as these tools + scripts and aliases. I bet that 99% of the time when you use the 'ls' command, you don't use any of these functions (not counting alias ls='ls -kitcnsink'). For a linux newbie, KFM is much easier than remembering/learning:
- Bloat is good. Lets say it costs you, a Linux user who "knows where his towel is", $100 to upgrade your computers RAM to run KDE or Gnome. Lets assume that you spend 10 minutes a day remembering the names of common commands, reading man pages, mis-spelling 'chmod', using the wrong one-letter options (let me tell you, when I first started using gcc I figured gcc -o foo.c should do what gcc -c foo.c does. oops), reading and understanding error messages, etc. Lets further assume that these mistakes are eliminated by going to KFM, so you save the 10 mins a day. If you time is worth 10 bucks an hour, you save 10/6 = $1.6 a day. You only need 100/1.6 = 60 days to recoup your investment. After that, its pure profit, baby! This doesn't take into account subjective improvements, like ease of use.
- KDE vs. M$ - true, the enhancements listed here already exist in M$ winblows. however, I want to point out that
- KDE doesn't have a marketing department (despite the tenor of the 2.0 annoucement). Therefore KDE developers can focus on the features users actually want, not what somebody thinks that the users think that they want.
- As KDE is opensource, incremental change is "free" and continuous. This last point is actually very important, as the little bugs are really the most annoying/disruptive.
- Finally, (and this point actually distinguishes between KDE and Gnome), it appears to me that KDE is more focused on actual usability. Take the whole 'themes' mess for example. Ok, so Gnome has better theme support right now. So what? Themes are counterproductive, IMHO. If every user has different keybindings and widgets that look and act differently, that is definite lossage, when it comes to usability. (note that I don't have experience with themability, I might be wrong about this). However, I think that we will all agree that Enlightenment's excesses are gratuitous, and, ultimately, useless eye-candy. (sweets are good...but my P 100/ 40MB ram laptop is on a diet) And another thing. Quoting Object-Oriented Software Construction (Bertrand Meyer): "Correctness is the prime quality. If a system does not do what it is supposed to do, everything else about it - whether it is fast, has a nice user interface... - matters little." If a program crashes, it is not correct. KDE appears to focus on this more than Gnome. (read this book. Even if you only read p.3 - p.20, on the definition of software quality.)
well, thats my 2 cents. Don't spend it all in one place!- what the commands are called (btw: note cd/chdir/md/mkdir inconsistency)
- how to use them
- how to get help on them
- how to decipher/grep through the resulting man page
- how to save options (i.e. with aliases)
- how to do things to groups of files (if you try to figure out mv *~ tmp from the man pages, you need to wade through the bash documentation. The KDE help docs say that I can select multiple files by right clicking on each, but it doesn't say anything about the edit>>select command (where I can type in *~))
This is all well and good for newbies, but what about the power users? well, the command line isn't going anywhere. And if you can accomplish 90% of your goals in a simple, consistent manner, more power to you. I may be a relatively sophisticated linux user, but that doesn't mean that I want to read man pages. This brings me to my second point:One more thing: one goal of user-interface design (especially GUI design) is to make the system "self-documenting", i.e. its pretty intuitive how to do simple things, and when the user wants to do more complex things, he is exposed to more stuff and it is pretty clear how to proceed. Its usually easier to mess around with a program than to read a manual (or man page, eek). In fact, if a user needs to read documentation, the program is a failure. This is just an elaboration of the 'subjective enjoyment' point above.
(OT: this new version of lynx is great, I love being able to use emacs for doing form input. The old way truly was bletcherous.)
--
Man is most nearly himself when he achieves the seriousness of a child at play.
I believe he means something like ;-)]
int* foo (int bar) {
return &bar;
}
because in C, parameters to functions are stored
on the stack. I bet auto variables (like ralph) are
also stored on the stack, but your code is fine; you don't return the address of ralph.
[Just don't forget to free
--
Man is most nearly himself when he achieves the seriousness of a child at play.
I just wanted to point out that each book review is done by a different person, with a different idea of what they want in a book, what qualifies as a '10', etc. As others have pointed out, the reviewer doesn't really talk about using this book and the standard Perl docs together. As far as introductory Perl books go, IMHO the most important aspect is how well scalar/list context is explained. In all other prog. langs that I can think of, whatever is inside the parens is not affected by whats outside. I don't know how well this book explains this, however.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
The GPL says no such thing. However, seeing as the software is freely downloadable, it would be difficult to convince someone to pay beaucoup bux.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
geez claudius...
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Opensource style development is incompatible with tradional HCI. When someone has an 'scratches an itch' and writes code, he typically does it for new features. While this is a decent way to add functionality, ease of use cannot be added in such a slipshod way. UI "Refactorings" are pretty uncommon in practice, I think.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
s/Arthur/Alfred/;
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Although the kernel is GPL'ed, the FSF does not own the copywright. The FSF insists on owning the copywright for all the code. You can get it straight from the horses mouth here.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
thats what quotemeta is for.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
This is a big problem. If there is a loss of power for more then 3 days, there WILL be meltdowns. The problem is that so much is dependent on power, railroads, oil. The big one, of course, is power. If there are major power outages, it will severely harm all other industries. Not scared yet? checkout
this site.
--
Man is most nearly himself when he achieves the seriousness of a child at play.
> Of course, there are things that absolutely must be GUI. Like, web browsers.
I just wanted to mention that I am posting this from lynx...