I hear you. Maybe context separation is an unfair assumption on the part of most 'microkernel haters'.
(Hey, I'm not a hater, I just have an opinion:P)
Your comments about relocation are all fine and good, but that doesn't fully clear the air. Van Jacobson pointed out recently in a presentation about abandoning the Berkeley network design that a modern Pentium can do something like 400 instructions in the time it takes to do a single fetch.
So it may just be that the microkernel approach requires tinkering with a linked list. Now you have to consider the behavior of a linked list. Now, if the design works out such that your allocation overhead is minimal and you're cache hot, your overhead may be pretty small. And if you take it a step further and talk about a synchronous queue, then let's say you avoid that altogether.
At this point, I ask you -- what are you doing? What is the benefit of the design decision you are making?
It's not that microkernels can't be fast under ideal conditions. It's just that if you start to use a microkernel in ways people like to think microkernels are good (split things off into different contexts, achieve some super geekdom through message passing, etc) your performance begins to suffer.
It's just like people that get excited about beans and RMI and all that nonsense and write terrible web applications. They could have done it all in native everyday raw Java, and while it wouldn't be really fast it might be tolerable.
I'm aware that a monolithic design doesn't need any kind of context separation (in fact, for supervisor tasks, most don't have any at all). That's pretty obvious because context separation is not an inherent property of monolithic design.
One thing I do find remarkably interesting is how you've now referred to the possibility of network bridging kernel components a couple of times now. I can think of another technology that does this; it's called J2EE. And when you start to rely on such *nonsense*, you get these wonderful applications that take 90+ seconds to answer a fucking query. (I've seen it happen in the corporate world to that insane degree).
I guess my beef with microkernels is the same as my beef with Java. "Remove the useless cruft and overhead," you might hear me saying.
But I like this example of being able to 'tear off' the filesystem and put it on the other end of a network. The problem is, it's terribly impractical. It would be absolutely worthless for anything other than academic reasons (especially considering that no one filesystem is 'generic' enough to behave optimally in both local and remote configurations). In fact, if you wanted to move into any kind of production with a disconnected FS, you'd need extensive security checking on the inbound queue.
Then, if you decided to make it a local FS again, your performance *would blow*.
Building an entire kernel out of little queues is just insane and infeasible in the real world. There's no reason to build in all kinds of overhead.
I hear you about fork()/exec() (granted, modern systems do things even more sanely, between vfork() and COW). But there's a difference between process creation time and the time it takes to do *ANYTHING* in the kernel. If you doubt that, compare the number of people bitching about how long it takes to run 'ls' to the number of people who think context separation in kernels is a joke.
Your comment about dynamic linking is funny. It's one of those things that is just a 'good trade'. Imagine, say, the memory consumption of a modern desktop system where nothing was dynamically linked. Or the pain you must go through when you find out that someone didn't check a buffer in zlib.
It's a bogus comparison anyway. The cost of dynamic linking is typically very small and has been improved through mechanisms like prelink. It's negligible for commands, and sad on general abortions like OpenOffice. For these big behemoths where linking is a pain in the ass, you pay the linking cost only once. In a microkernel, your overhead is there, looming over you, regardless of what you ever do.
I'll end this post simply. Call me when someone builds a feasible microkernel for general purpose computing that doesn't perform like ass.
Funny, all the 'big name' modern microkernels I'm aware of either currently exploit context separation, or they used to (and stopped because of the terrible performance). Is that to say that there are 'microkernels' on other platforms that do not have -- and never had -- this property? No, of course not.
Now I'll admit that I don't know a whole lot about microkernels, but I do know that every piece of literature (and argumentation) I've ever come across about microkernels has emphasized process separation (or the failure of process separation). So I suppose Wikipedia leads the pack of non-authoritative sources. Tell me then, sir, just who is the authoritative source?
Now we come back around to the question of overhead. Tell me... if a property of microkernels isn't process separation, and you contend that message passing consumes roughly the same number of instructions (cycles being the important variable you've ignored), just how different is a microkernel and a monolithic kernel, in your view?
Granted, Mach is probably one of the worst examples of a microkernel. But I disagree that context separation is not a fundamental property of a bona fide microkernel; even Wikipedia says "All other services, those normally provided by the kernel such as networking, are implemented in user-space programs referred to as servers.", though it notes many implementations include a filesystem or device drivers in kernel space.
Regardless of what kind of magic algorithms your queueing mechanism may use, I simply don't see how a microkernel can be 'as fast' as a monolithic kernel. (Pick some random task) in a microkernel involves building a message / marshalling, while the same task in a monolithic kernel involves a direct function call. This is ignoring entirely the 'true' microkernel approach that does maintain context separation (which is quite detrimental to performance).
And I'll also grant that microkernels have penetration in some mission critical markets. But there's a difference between a requirement for consistent performance and latency, and a requirement for *high* performance and *low* latency.
Microkernels aren't without place or interest, but in my opinion, they are inferior to well-designed monolithic kernels (such as Linux) in today's computing world.
An interesting read along these lines can be found on the Wikipedia page for Mach:
This is retarded. Mac OS X - which is based on one of the slowest operating systems in the history of UNIX (Mach) - performs terribly. Microkernels were a terrible idea in practice; that's why everyone moved their shit into kernel space (and gave up the benefit of having a microkernel in the first place).
It took Apple until the Tiger release to make the kernel's locking scheme any finer than ONE network lock, and ONE "everything else" lock. Reminds me of the days of cli()/sti()/lock_kernel() in Linux. (In Tiger, there are something like 5 or 6 locks -- still a disaster.)
The funny thing is when Anandtech did a Tiger review some time back to measure the performance. Considering the delta between modern Linux and OS X (Linux measuring in at ten times faster in some places), it's outstandingly shocking that anyone would say OS X performs at all. Windows puts up a *much* better fight.
I must admit, it's sad to see that Dan hasn't patched the qmail-smtpd portability problem. I don't think you can call it anything but a bug.
If it's a vulnerability, it's a *very* unlikely one, for the simple reason that almost no configuration on earth gives a single qmail-smtpd 2GB+ of memory.
If I were Bernstein, I'd have given the $500 away and renewed the guarantee. I'd have said that the bug was tremendously unlikely to ever work, and impossible for it to work if you followed good practices in your installation. I'd have stated that the $500 was given away simply because it was a gray area.
But hey, I'm not Dan. What I am is a proud qmail user. It's still beyond a doubt the most secure MTA on the planet.
A lot of people rave about Postfix, but I'll never forget just how 'secure' that mailer originally was. The reason this qmail stuff is getting much attention at all is precisely because of qmail's great fame for its security. If someone found a 64 bit portability problem in Windows (hell, there are probably a zillion), you'd never hear about it. Just the way the cookie crumbles I guess.
You know folks, free software developers work their asses off to bring you a quality operating system. Sometimes a project needs money in order to sustain itself.
It's funny... back when I used Windows and fought through nagware like Winzip or Trillian, I shuddered at the thought of paying my hard earned dollars for software. Now that I have a free software desktop, I've donated to a lot of projects. I try to pick a new one every month or two, just to send $20 their way.
This news about the OpenBSD project reminded me how important it is to donate money to the great projects you depend on, in order to help keep them alive.
Unfortunately, I couldn't find a donation link on kernel.org, so I sent this month's $20 to Gentoo Linux. I can only hope that you'll choose to do the same for your Linux distribution.
Yes, but if you read the GPL's section 9, you'll start to wonder why that clause about "not specifying a version" would be there at all. Even the GPL v1 (where section 9 originated) said "GPL Version 1" in the license. So if we were to accept that the GPL's version number was the "Program's" specification of GPL's version number, then this sentence in section 9 would be 100% useless because it would never, ever apply to anyone.
I went to Bell South's website to find some contact information and send my thoughts, and it tells me that my web browser must be upgraded to "Netscape Navigator" or "Internet Explorer". I'm not using an ancient browser either - the latest KDE Konqueror, powered by the first HTML engine to ever pass ACID2.
Verizon FIOS is available today, at my curb, at rates competitive to my Comcast service (while offering much more bandwidth). After hearing Verizon had this attitude recently, I decided that I won't be upgrading.
Re:Too many changes all at once
on
What is Perl 6?
·
· Score: 3, Insightful
Whenever I hear people saying things like this I think that they really lack visibility or understanding into the language's design process. Granted, the coming-to-life of Perl 6 hasn't been the quickest miracle we've seen, but I'm a hundred thousand percent positive that its being done in the best possible manner.
Think about it. Larry Wall accepted numerous RFCs from programmers of all walks, discussing Perl's problems / desires for new features / suggestions for new implementations / ideas how to change the syntax. He commented on each one, indicating whether (1) he agreed with the problem, (2) whether he agreed with the solution, (3) what, if anything, he thought should be done about it.
In the mean time, a radically new language glue system is introduced - Parrot. Perl had such wild success with XS - granted, Parrot isn't just about making language A talk to language B, but it's certainly an example of natural evolution.
As for Pugs, it's been fantastic. It's allowed lots of people to write real and working Perl 6 code (including lots of tests) to evaluate all aspects of the Perl 6 design before it goes into production.
Now, I'm not addressing you directly with this last part; rather, a greater community of Slashdot trolls. If you don't feel like Perl is for you, or if you feel like Perl is no longer for you, fine. Find your way to Ruby, Python, Java or whatever floats your boat.
But please, it's getting really goddamned irritating to have to sift through the comments of a handful of armchair morons that sit at home, interfacing with something called "comments.pl", eating doritos and talking about how the greater Perl community should just drop everything and go to language X, or repeating a tired meme about how the language is making no progress at all (when all they need to do to see the massive progress is read Audrey Tang's blog or visit pugscode.org). And then, there are some mods that feel it appropriate to mark clueless jabs as "insightful".
I am thankful of one thing - Perl's momentum. While everyone else is barking about how (name my scripting language) is great this week for doing web pages or some nonsense, there is still a huge community of devoted, bleeding edge language researchers and smart people, chisel in hand, forming Perl 6 from the rocks.
And while the naysayers are switching languages once a week as they make incremental advantages over eachother -- while they're totally clueless that so many of the 'advancements' in their own languages over the years have been 'borrowed' from or 'inspired' by perl, the aforementioned language scientists are preparing to do once again what Larry Wall did, intentionally or not, when he released Perl on the world - bring about a revolution.
Whoever thinks that the "Start Menu" in modern X desktop environments is "unorganized" is smoking some serious crack. In Windows, the Start menu *comes* organized into distinct categories - Accessories, etc... but it *never* stays that way. Each application you install insists on adding a root level menu with shortcuts to its help and uninstall functions.
By contrast, each X app you install (or get with your distribution) *is* organized cleanly into one of the categories, and the only icon present is the only one you typically use - the application itself!
If you want "Help", you can visit the help menu of your application or help center of your desktop distribution. If you want to uninstall something, you can use your package manager and/or its GUI, and unless it smokes donkey balls on the weekend, the installation will be clean and successful time and time again. (This is directly contrary to uninstalls in Windows which are problematic, leave stuff behind and bitch unlegibly for no reason)
It turns out that the user interface simplicity I was only partially talking about that you fully latched on to goes hand in hand with something else - the simplicity of the application code itself. Even if you refuse to install any Firefox extensions, the bloat still hits you in the face like a sack of bricks because it insists on using fucking XUL and the rendering engine to render the whole UI.
Without being an actual Gecko developer, I can't tell you if that is its main problem (but it's likely to be a 'big one'). What I do know is that the memory savings and performance benefits from using Konqueror are downright impressive.
- Lost+Found (Linux loser since, well, a long time ago... and loving it!)
If you think KDE devs spend their time trying to be like OSX, then you've obviously only ever used KDE or OSX. Support for "dashboard widgets" turns out to be a relatively simple thing to do because of a few things (A) Plasma and (B) the fact that Apple based all of their HTML rendering on KDE technology. Dashboard widget support would be a single (optional!) feature in a sea of others. Last time I checked, (uh, right now... I'm typing this post on a KDE desktop and sitting next to a Powerbook laptop), KDE's differences from OSX make it *vastly* more usable.
Will I use dashboard widgets in KDE? Likely, no. But I'll be happy to have the choice.
Early CRTs? Hell yeah, you could damage them, or in the worst case, maybe set them on fire. Modern CRTs? Nope... not only are they a lot more tolerant... I'm pretty sure they have safeguards.
Har har but no. Cryptography is an obvious solution to this problem... have the stations sign the goddamned content and don't display content signed with keys you don't trust. I predict as the flow of information becomes more ubiquitous - more digital - and more Internet-centric, PKI will grow in importance and implementation. It's just one logical solution to a million big problems.
Excuse me... have I stumbled into the wrong conference room^H^H^H^H^H...programming language? You are talking about Python, right - the language that *begins* by forcing a style of indentation....? No?
Ok, maybe it's your assertion:
> The freedom of the language has nothing to do with its syntactic cleanliness.
That's off. On the contrary, having a flexible grammar allows you to do, well, flexible things. I for instance was able to throw together my own data modelling syntax using Perl's function prototypes. When the language is willing to *bend over backwards* to accomodate you, no matter how unreasonably outrageous of a demand you make, you can twist it into the wildest contortions and pure art emerges.
Say what you want about the rest of the world, but I think what people like you (not meaning "people like you" as an attack) don't always see is that there is a simply *insane* number of Perl programmers and Perl programs.
If the language is so rotten, why do you think that it's so incredibly popular? Why is it so *wildly* portable (even moreso than Java)? Why do huge sites like Amazon.com and Ticketmaster.com and Slashdot.org rely on it for their core business? What other language with humble beginnings found its way into, well, everything? Why does every other language feel it necessary to *copy* Perl Regular Expressions - perhaps the *ugliest* part about Perl?
It's funny... people seem to get so caught up in the fact that if you're a bad programmer you'll do *really* bad in Perl... and they miss all of the things that Perl and its community have contributed to make life better.
Just look at how many comprehensive and powerful testing modules are available, for example, and how many quality module distributions make extensive use for them.
If someone reading this thinks it's impossible to write maintainable Perl code, I ask you to look at CPAN which is simply by far wildly more comprehensive than ANY of its copies (and where it exists for other languages, they are copies - CPAN *wannabes*). Seems like a hell of a lot of maintainable code to me... and that's just a collection of utilities.
Have you ever been in perl's guts? It shares a property of Perl that I find most interesting... when you first look at it and try to become comfortable with it, well, it makes grown men cry.
But then you have this moment where something in your head *clicks* and then you understand... and after that it is beautiful and logical and makes infinite sense.
Slashdot Mirror
They forgot to include the performance!
I hear you. Maybe context separation is an unfair assumption on the part of most 'microkernel haters'.
:P)
(Hey, I'm not a hater, I just have an opinion
Your comments about relocation are all fine and good, but that doesn't fully clear the air. Van Jacobson pointed out recently in a presentation about abandoning the Berkeley network design that a modern Pentium can do something like 400 instructions in the time it takes to do a single fetch.
So it may just be that the microkernel approach requires tinkering with a linked list. Now you have to consider the behavior of a linked list. Now, if the design works out such that your allocation overhead is minimal and you're cache hot, your overhead may be pretty small. And if you take it a step further and talk about a synchronous queue, then let's say you avoid that altogether.
At this point, I ask you -- what are you doing? What is the benefit of the design decision you are making?
It's not that microkernels can't be fast under ideal conditions. It's just that if you start to use a microkernel in ways people like to think microkernels are good (split things off into different contexts, achieve some super geekdom through message passing, etc) your performance begins to suffer.
It's just like people that get excited about beans and RMI and all that nonsense and write terrible web applications. They could have done it all in native everyday raw Java, and while it wouldn't be really fast it might be tolerable.
Wow. You must share some of what you are smoking.
I'm aware that a monolithic design doesn't need any kind of context separation (in fact, for supervisor tasks, most don't have any at all). That's pretty obvious because context separation is not an inherent property of monolithic design.
One thing I do find remarkably interesting is how you've now referred to the possibility of network bridging kernel components a couple of times now. I can think of another technology that does this; it's called J2EE. And when you start to rely on such *nonsense*, you get these wonderful applications that take 90+ seconds to answer a fucking query. (I've seen it happen in the corporate world to that insane degree).
I guess my beef with microkernels is the same as my beef with Java. "Remove the useless cruft and overhead," you might hear me saying.
But I like this example of being able to 'tear off' the filesystem and put it on the other end of a network. The problem is, it's terribly impractical. It would be absolutely worthless for anything other than academic reasons (especially considering that no one filesystem is 'generic' enough to behave optimally in both local and remote configurations). In fact, if you wanted to move into any kind of production with a disconnected FS, you'd need extensive security checking on the inbound queue.
Then, if you decided to make it a local FS again, your performance *would blow*.
Building an entire kernel out of little queues is just insane and infeasible in the real world. There's no reason to build in all kinds of overhead.
I hear you about fork()/exec() (granted, modern systems do things even more sanely, between vfork() and COW). But there's a difference between process creation time and the time it takes to do *ANYTHING* in the kernel. If you doubt that, compare the number of people bitching about how long it takes to run 'ls' to the number of people who think context separation in kernels is a joke.
Your comment about dynamic linking is funny. It's one of those things that is just a 'good trade'. Imagine, say, the memory consumption of a modern desktop system where nothing was dynamically linked. Or the pain you must go through when you find out that someone didn't check a buffer in zlib.
It's a bogus comparison anyway. The cost of dynamic linking is typically very small and has been improved through mechanisms like prelink. It's negligible for commands, and sad on general abortions like OpenOffice. For these big behemoths where linking is a pain in the ass, you pay the linking cost only once. In a microkernel, your overhead is there, looming over you, regardless of what you ever do.
I'll end this post simply. Call me when someone builds a feasible microkernel for general purpose computing that doesn't perform like ass.
Funny, all the 'big name' modern microkernels I'm aware of either currently exploit context separation, or they used to (and stopped because of the terrible performance). Is that to say that there are 'microkernels' on other platforms that do not have -- and never had -- this property? No, of course not.
Now I'll admit that I don't know a whole lot about microkernels, but I do know that every piece of literature (and argumentation) I've ever come across about microkernels has emphasized process separation (or the failure of process separation). So I suppose Wikipedia leads the pack of non-authoritative sources. Tell me then, sir, just who is the authoritative source?
Now we come back around to the question of overhead. Tell me... if a property of microkernels isn't process separation, and you contend that message passing consumes roughly the same number of instructions (cycles being the important variable you've ignored), just how different is a microkernel and a monolithic kernel, in your view?
Granted, Mach is probably one of the worst examples of a microkernel. But I disagree that context separation is not a fundamental property of a bona fide microkernel; even Wikipedia says "All other services, those normally provided by the kernel such as networking, are implemented in user-space programs referred to as servers.", though it notes many implementations include a filesystem or device drivers in kernel space.
Regardless of what kind of magic algorithms your queueing mechanism may use, I simply don't see how a microkernel can be 'as fast' as a monolithic kernel. (Pick some random task) in a microkernel involves building a message / marshalling, while the same task in a monolithic kernel involves a direct function call. This is ignoring entirely the 'true' microkernel approach that does maintain context separation (which is quite detrimental to performance).
And I'll also grant that microkernels have penetration in some mission critical markets. But there's a difference between a requirement for consistent performance and latency, and a requirement for *high* performance and *low* latency.
Microkernels aren't without place or interest, but in my opinion, they are inferior to well-designed monolithic kernels (such as Linux) in today's computing world.
An interesting read along these lines can be found on the Wikipedia page for Mach:
http://en.wikipedia.org/wiki/Mach_kernel
I suppose I should expect this message to get marked 'Troll' as well. Funny how having an unpopular opinion on Slashdot warrants such a branding.
This is retarded. Mac OS X - which is based on one of the slowest operating systems in the history of UNIX (Mach) - performs terribly. Microkernels were a terrible idea in practice; that's why everyone moved their shit into kernel space (and gave up the benefit of having a microkernel in the first place).
p =1
It took Apple until the Tiger release to make the kernel's locking scheme any finer than ONE network lock, and ONE "everything else" lock. Reminds me of the days of cli()/sti()/lock_kernel() in Linux. (In Tiger, there are something like 5 or 6 locks -- still a disaster.)
The funny thing is when Anandtech did a Tiger review some time back to measure the performance. Considering the delta between modern Linux and OS X (Linux measuring in at ten times faster in some places), it's outstandingly shocking that anyone would say OS X performs at all. Windows puts up a *much* better fight.
http://www.anandtech.com/mac/showdoc.aspx?i=2436&
I must admit, it's sad to see that Dan hasn't patched the qmail-smtpd portability problem. I don't think you can call it anything but a bug.
If it's a vulnerability, it's a *very* unlikely one, for the simple reason that almost no configuration on earth gives a single qmail-smtpd 2GB+ of memory.
If I were Bernstein, I'd have given the $500 away and renewed the guarantee. I'd have said that the bug was tremendously unlikely to ever work, and impossible for it to work if you followed good practices in your installation. I'd have stated that the $500 was given away simply because it was a gray area.
But hey, I'm not Dan. What I am is a proud qmail user. It's still beyond a doubt the most secure MTA on the planet.
A lot of people rave about Postfix, but I'll never forget just how 'secure' that mailer originally was. The reason this qmail stuff is getting much attention at all is precisely because of qmail's great fame for its security. If someone found a 64 bit portability problem in Windows (hell, there are probably a zillion), you'd never hear about it. Just the way the cookie crumbles I guess.
You know folks, free software developers work their asses off to bring you
a quality operating system. Sometimes a project needs money in order to
sustain itself.
It's funny... back when I used Windows and fought through nagware like
Winzip or Trillian, I shuddered at the thought of paying my hard earned
dollars for software. Now that I have a free software desktop, I've donated
to a lot of projects. I try to pick a new one every month or two, just
to send $20 their way.
This news about the OpenBSD project reminded me how important it is to
donate money to the great projects you depend on, in order to help keep them alive.
Unfortunately, I couldn't find a donation link on kernel.org, so I sent
this month's $20 to Gentoo Linux. I can only hope that you'll choose
to do the same for your Linux distribution.
Yes, but if you read the GPL's section 9, you'll start to wonder why that clause about "not specifying a version" would be there at all. Even the GPL v1 (where section 9 originated) said "GPL Version 1" in the license. So if we were to accept that the GPL's version number was the "Program's" specification of GPL's version number, then this sentence in section 9 would be 100% useless because it would never, ever apply to anyone.
I went to Bell South's website to find some contact information and send my thoughts, and it tells me that my web browser must be upgraded to "Netscape Navigator" or "Internet Explorer". I'm not using an ancient browser either - the latest KDE Konqueror, powered by the first HTML engine to ever pass ACID2.
Verizon FIOS is available today, at my curb, at rates competitive to my Comcast service (while offering much more bandwidth). After hearing Verizon had this attitude recently, I decided that I won't be upgrading.
Whenever I hear people saying things like this I think that they really lack visibility or understanding into the language's design process. Granted, the coming-to-life of Perl 6 hasn't been the quickest miracle we've seen, but I'm a hundred thousand percent positive that its being done in the best possible manner.
Think about it. Larry Wall accepted numerous RFCs from programmers of all walks, discussing Perl's problems / desires for new features / suggestions for new implementations / ideas how to change the syntax. He commented on each one, indicating whether (1) he agreed with the problem, (2) whether he agreed with the solution, (3) what, if anything, he thought should be done about it.
In the mean time, a radically new language glue system is introduced - Parrot. Perl had such wild success with XS - granted, Parrot isn't just about making language A talk to language B, but it's certainly an example of natural evolution.
As for Pugs, it's been fantastic. It's allowed lots of people to write real and working Perl 6 code (including lots of tests) to evaluate all aspects of the Perl 6 design before it goes into production.
Now, I'm not addressing you directly with this last part; rather, a greater community of Slashdot trolls. If you don't feel like Perl is for you, or if you feel like Perl is no longer for you, fine. Find your way to Ruby, Python, Java or whatever floats your boat.
But please, it's getting really goddamned irritating to have to sift through the comments of a handful of armchair morons that sit at home, interfacing with something called "comments.pl", eating doritos and talking about how the greater Perl community should just drop everything and go to language X, or repeating a tired meme about how the language is making no progress at all (when all they need to do to see the massive progress is read Audrey Tang's blog or visit pugscode.org). And then, there are some mods that feel it appropriate to mark clueless jabs as "insightful".
I am thankful of one thing - Perl's momentum. While everyone else is barking about how (name my scripting language) is great this week for doing web pages or some nonsense, there is still a huge community of devoted, bleeding edge language researchers and smart people, chisel in hand, forming Perl 6 from the rocks.
And while the naysayers are switching languages once a week as they make incremental advantages over eachother -- while they're totally clueless that so many of the 'advancements' in their own languages over the years have been 'borrowed' from or 'inspired' by perl, the aforementioned language scientists are preparing to do once again what Larry Wall did, intentionally or not, when he released Perl on the world - bring about a revolution.
People really ought to know something about a subject before they comment on it.
Why?
Because it would save them from looking like a complete and utter jackass when their comments are read by the people that *do*.
Whoever thinks that the "Start Menu" in modern X desktop environments is "unorganized" is smoking some serious crack. In Windows, the Start menu *comes* organized into distinct categories - Accessories, etc... but it *never* stays that way. Each application you install insists on adding a root level menu with shortcuts to its help and uninstall functions.
By contrast, each X app you install (or get with your distribution) *is* organized cleanly into one of the categories, and the only icon present is the only one you typically use - the application itself!
If you want "Help", you can visit the help menu of your application or help center of your desktop distribution. If you want to uninstall something, you can use your package manager and/or its GUI, and unless it smokes donkey balls on the weekend, the installation will be clean and successful time and time again. (This is directly contrary to uninstalls in Windows which are problematic, leave stuff behind and bitch unlegibly for no reason)
Do you enjoy flaming for fun on the internet?
It turns out that the user interface simplicity I was only partially talking about that you fully latched on to goes hand in hand with something else - the simplicity of the application code itself. Even if you refuse to install any Firefox extensions, the bloat still hits you in the face like a sack of bricks because it insists on using fucking XUL and the rendering engine to render the whole UI.
Without being an actual Gecko developer, I can't tell you if that is its main problem (but it's likely to be a 'big one'). What I do know is that the memory savings and performance benefits from using Konqueror are downright impressive.
- Lost+Found (Linux loser since, well, a long time ago... and loving it!)
...simplicity. Or, rather, I prefer simplicity in my browser. And every time I check, Firefox is getting worse.
Thankfully, I'm a Linux user, so I'm not limited to Opera and Internet Explorer. I do my surfing on Konqueror.
Ought oh, they used an "i" in their product name. Apple must be charging up their iAttorneys as we speak.
If you think KDE devs spend their time trying to be like OSX, then you've obviously only ever used KDE or OSX. Support for "dashboard widgets" turns out to be a relatively simple thing to do because of a few things (A) Plasma and (B) the fact that Apple based all of their HTML rendering on KDE technology. Dashboard widget support would be a single (optional!) feature in a sea of others. Last time I checked, (uh, right now... I'm typing this post on a KDE desktop and sitting next to a Powerbook laptop), KDE's differences from OSX make it *vastly* more usable.
Will I use dashboard widgets in KDE? Likely, no. But I'll be happy to have the choice.
Signed content != DRM. It just so happens that crypto can be used for DRM.
And I do agree... I'd like to cut out the middlemen and get real content. But I'm not willing to hand over the keys to my computer and my TV to do it.
Early CRTs? Hell yeah, you could damage them, or in the worst case, maybe set them on fire. Modern CRTs? Nope... not only are they a lot more tolerant... I'm pretty sure they have safeguards.
Har har but no. Cryptography is an obvious solution to this problem... have the stations sign the goddamned content and don't display content signed with keys you don't trust. I predict as the flow of information becomes more ubiquitous - more digital - and more Internet-centric, PKI will grow in importance and implementation. It's just one logical solution to a million big problems.
Excuse me... have I stumbled into the wrong conference room^H^H^H^H^H...programming language? You are talking about Python, right - the language that *begins* by forcing a style of indentation....? No?
Ok, maybe it's your assertion:
> The freedom of the language has nothing to do with its syntactic cleanliness.
That's off. On the contrary, having a flexible grammar allows you to do, well, flexible things. I for instance was able to throw together my own data modelling syntax using Perl's function prototypes. When the language is willing to *bend over backwards* to accomodate you, no matter how unreasonably outrageous of a demand you make, you can twist it into the wildest contortions and pure art emerges.
Say what you want about the rest of the world, but I think what people like you (not meaning "people like you" as an attack) don't always see is that there is a simply *insane* number of Perl programmers and Perl programs.
If the language is so rotten, why do you think that it's so incredibly popular?
Why is it so *wildly* portable (even moreso than Java)?
Why do huge sites like Amazon.com and Ticketmaster.com and Slashdot.org rely on it for their core business?
What other language with humble beginnings found its way into, well, everything?
Why does every other language feel it necessary to *copy* Perl Regular Expressions - perhaps the *ugliest* part about Perl?
It's funny... people seem to get so caught up in the fact that if you're a bad programmer you'll do *really* bad in Perl... and they miss all of the things that Perl and its community have contributed to make life better.
Just look at how many comprehensive and powerful testing modules are available, for example, and how many quality module distributions make extensive use for them.
If someone reading this thinks it's impossible to write maintainable Perl code, I ask you to look at CPAN which is simply by far wildly more comprehensive than ANY of its copies (and where it exists for other languages, they are copies - CPAN *wannabes*). Seems like a hell of a lot of maintainable code to me... and that's just a collection of utilities.
Have you ever been in perl's guts? It shares a property of Perl that I find most interesting... when you first look at it and try to become comfortable with it, well, it makes grown men cry.
But then you have this moment where something in your head *clicks* and then you understand... and after that it is beautiful and logical and makes infinite sense.
It really was better than acid...