As for "If SW Airlines doesn't want blind people for customers, so be it," replace with "If SW Airlines doesn't want black people or women for customers, so be it."
You will probably reply that it's different. On the other hand, it is quite possible for any web page designer to make their site usable from braille readers. The ADA was meant to keep this from happening. There aren't enough blind people in this country to have an economic impact on a company to the extent that they voluntarily make disabilities a priority. This does not mean that blind people should be shot and left at the side of the road.
There is nothing intrinsic to travel on Southwest airlines that precludes access to blind passengers. If this was a first-person shooter game, where sight and visuals are an intrinsic part of the game which cannot easily be substituted, the ADA would not apply. Southwest, however, has the cheapest fares in the area and already makes provisions in their business for blind passengers. Assuming that some other airline's web site is braille reader accessible. This means that for the same travel plans, a blind person MUST spend two or three times as much as a sighted passenger. This is effectively a tax on the blind.
But I digress. I am simply amazed that the readers of Slashdot have such a large group of people against this. At the very least, it would guarantee that large corporations make their web sites available in all browsers (think banks and their current fixation on IE). It would also limit the amount of superfluous JavaScript on pages. ISN'T THIS WHAT A LARGE GROUP OF SLASHDOT READERS WANT!?!
I, for one, have no problem with the fact that it comes on the heels of a guarantee to support blind users. To me, access to the blind is a far more noble and worthwhile goal than choice of browser and the fight against Microsoft hegemony.
But this is what I'm talking about. You're right that those are some pretty verbose names, but at least we're talking about it. It's hard to get people to even entertain the concept before deciding.
As far as existing software, I can't think of an easier patch to a program than a search and replace of "/etc". Far easier to find and fix than all the off-by-one errors out there. And as you said, config.h could have the correct directory. Is it work? Sure. Is it hard? Not in a couple year's time. Old software? I don't know of many programs on my system that are both path-dependant and that haven't had a single update in a couple of years. For folks that have server configs, those won't be changing for other reasons: the base configs are static for years minus minimal patching for stability and security.
As for POSIX, the fact that it's unlikely is saddening to me. Even if solutions are suboptimal, they aren't re-evaluated. "If it ain't broke" doesn't necessarily apply. A primary critique of Linux (and *NIX in general) is that it's difficult to use, figure out, etc. So much effort is going into this on the GUI side, and yet the lower levels are left to sit with no improvement. No matter how good the GUIs get, they will still be dependent upon decisions (justifiably) made in 1970. People aren't even willing to talk about it.
As for clever developers, I'm sure the clever ones can not only search and replace, but can easily find if/settings exists on install/compile. K&R's strcmp, strcat, strstr, strchr, etc. aren't clear names! They are artifacts of a system that could only handle commands that are six characters or less (This is why the game Adventure was originally typed in as the command 'advent').
There are many things about UNIX and POSIX that are well worth keeping. All told, they are very elegant systems. But they are not perfect and people aren't even talking about ditching the legacy cruft. This is my beef, not whether or not my ideas are implemented. If people say/settings as a bad name and wanted to find something else (maybe something that isn't filesystem dependant -- I don't know), I'd be fine with that. But people aren't even allowing for the possibility of debate on the topic!
I only had a couple of responses saying "It can't be done; There's too much software out there," or "It can't be done; It's always been/etc so why change it." I have yet to hear, "It might be worth it, but it'll take a few years," so that we can at least get a gameplan going. I don't really care about/etc; That's just a symptom.
I agree, unnecessary. But it would be less cryptic and therefore easier to intuitively figure out. But it is not for you or I to decide that someone isn't worthy enough to tweak settings because their first foray into the Linux operating system didn't include the knowledge that system config settings are in/etc.
GUIs are great for getting a job done sometimes, but they are horrible for figuring out the layout of a working system. This is a primary complaint that I have had with Windows. Control Panel tells me nothing about how it works, where the files are defined or what format they're in. There is indeed developer documentation for this, but it's basically obscure.
GUIs are also horrible for showing all of the options. GUIs will often fall one step behind the actual functionality. Look at a config file in Linux and you generally see all of the options, unused options commented out, and their defaults. I can tell you plenty of times where I've had to tweak a settings that wasn't represented in the GUI for whatever reason. A new user, when using a GUI, wouldn't know where the base configuration settings were, wouldn't know that they even exist, and will throw their hands up in disgust, walk away from Linux, and bad-mouth the OS to everyone they meet because Windows has a GUI for the option.
Admittedly, this can be greatly bypassed by making all of the configuration files a uniform file format with a defined schema that GUI tools can use to make intelligent admin GUI options, but it highlights a culture in the Linux (and UNIX) world: I had to learn it, I now know it, and everyone else should have to do the same. Some folks have known it for so long, they don't remember what it was like when they didn't know it.
Inertia isn't necessarily a bad thing. Neither is tradition. But when there are better options available, to ignore them is foolish. In these cases, they are elitist. No one has argued that/etc is an obvious label, but rather than make any effort to remedy this, it is accepted, new users are just told to shut up and use the GUI, and if they get frustrated with the generally poor state of GUI tools on Linux (as compared to Mac OS X for example), they are told that if they're too stupid to intrinsically know that/etc means "settings," they deserve the frustration they encounter.
If you want a good harvest, you need to be willing to turn the field upside down every season. (Note I did say to keep symlinks around for backward compatibility for a few years.)
If you can make fun of folks who can't remember/etc, be prepared for me to ridicule you for not being able to remember that/settings is the new directory.
Even though/usr,/var,/tmp,/etc are ridiculously cryptic, changing them would be horrible?
Get this:
Change/etc to/settings or/config
Change/var/log to/logs
Change/var to/data (or something like it)
Change/tmp to/temp (saving one character? sheesh!)
Change/usr to/programs
Change/bin to/system_programs
and then (drumroll) make symbolic links so that old scripts and programs still work. You leave that in place for a couple of years, and then you remove the symbolic links. All that's left are logical names that actually convey information. And before people complain about the amount of extra typing, please tell me that you know how to use <tab> for filename completion (se<tab> gets you settings for example).
Users who can't remember that config files live in/etc may have difficulty configuring their box to be sure. But they'll have less difficulty if the directory is named/configuration or/settings won't they? The operating system shouldn't be some kind of high bar or IQ test. It should be a tool to get a job done./etc to/settings doesn't make your life and my life appreciably harder and it makes life for newbies that much easier.
And how, by any stretch of the imagination, is/etc less oddball than/settings? What universe do you live in? The directory name "etc" is an artifact of history, not a brilliant design plan. 1K of memory was expensive so the directory names were kept as short as possible. Now 1K is a rounding error. The reasons for "etc" no longer exist today. You might as well tell me that people should still hone their PDP-11 assembly skills before doing any programming in a high-level language.
You're used to/etc. Good for you. After the rest of the world moves on, you can make your symbolic links. The rest of the world -- this includes all of those folks who accurately regard a computer and operating system as merely tools -- is used to descriptive names./etc ain't descriptive. It's the UNIX club's code word for/settings. They like code words. It's like a secret handshake. It maintains a feeling of superiority however obviously false that feeling may be.
But system documentation is fundamentally different from technical documentation (DocBook)? If a new schema is made, I would hope that it's at least a subset of DocBook (like already existing Simplified DocBook).
Other than that, you took the words right out of my mouth. An LDAP interface to general configuration info would be nice too: network aware and accessible configuration and authentication info as a standard feature (but network access to it turned off by default of course for security reasons).
actually, the IDE layer WAS completely reworked. And it didn't work...for a long time. It was scrapped and a slightly modified 2.4 IDE layer was front ported to get back to stable code.
Expensive alternative? Like PostgreSQL? Seems to me they were knocking MySQL specifically. At the IBM booth at LinuxWorld, when I mentioned PostgreSQL, the guy had nothing bad to say about it for smaller installations. For a single box, he thought it was a great product and definitely a long way better than MySQL.
Then he pointed out the server farm (I think something like forty boxes in a rack) running effectively one single instance of DB2. They all handle queries, they load balance, and if one goes down, the rest pick up the slack immediately with no downtime.
Okay, you're not running a bank. What if some site (let's call it slashdot for brevity) wanted to award 10 karma points to everyone who's been a user for longer than a year -- kind of a "thanks for your support" gesture.
So we have the following (note: I know that the slashdot schema doesn't look like this -- illustrative purposes only):
SELECT userid, karma FROM users WHERE user_created < cast_to_date('20010923');
Yes, I know that's not MySQL syntax, but you get the picture. You'd also probably want to use a cursor here, but I'll keep it simple...
UPDATE users set (karma) VALUES ($old_karma + 10) WHERE userid = $some_id;
Where do you put the lock? I guess around the whole thing (or around the cursors if you are saavy enough to know better). I wouldn't think that would be particularly fast.
But wait! Slashdot experiences yet another database outage (and we all must acknowledge that these occur from time to time)! Which records were awarded 10 karma points!?! If you re-award them, some folks will get 20 points! If you pull them back, some people will get docked 10 (or end up with no extra points). By golly! The database has been left in an inconsistent state!
This is why transactions are necessary. And yes, I am calm. I don't use MySQL. I don't have to wait for them to be implemented and for them to be in a stable version of a product. I use one of the other Open Source database products that have had transactions for years. And that transaction support has been stable for years. And the price for the other database products is just as right as MySQL's price.
Telling people to use MySQL today because it will have a complete feature-set tomorrow is like when Microsoft told people to buy Windows ME because Windows will be getting more stable and secure tomorrow. The logic works fine until you see that there are alternatives that have already done what is needed...yesterday.
A Slashdot article about XHTML 2.0 and the wave of the future and yet the top of every page has the line:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
3.2? Now that's a blast from the past. How much do you want to bet that Slashdot's audience by and large uses browsers that are compatible with XHTML 1.1? This isn't the AOL start page after all...
Mozilla does NOT support DOM better than IE. DHTML is faster in IE by a large margin (getting smaller but large nonetheless). Feature-wise they are about equal. Speed-wise there is no real competition.
So don't use Mozilla. Last time I checked, no one was forcing its use.
"I want a web browser."
So get a web browser. You have Opera, IE, Mozilla, Konqueror and derivatives of them. Personally I want the application platform tailored to network content and display. There's too much associated with the word "browser." Some folks -- like you -- just want a basic rendering engine. Other folks want a rendering engine with a lot of scripting ability. Still others -- like me -- want to reuse pieces of the browser in applications that I write because I have little desire to reimplement an HTTP client, a rendering engine, a JavaScript engine, etc. The great thing about having all of these different products is that at least one of them should serve your needs. Of course having multiple solutions means that it would be a good idea to share a common method of authoring -- some would call them "standards."
As for the mail client, the client to Mozilla isn't "bolted on" but rather uses many of the same components that the browser uses. Do you have something against code reuse? Or should Mozilla's mail client reimplement the networking layer? How about viewing messages? Most modern email client support HTML email so I assume that Mozilla developers should have written a separate renderer just for the mail client.
Different strokes for different folks. Stop whining. And for the record, if you use Netscape, you *are* using AOL.
It's on a production box, but it hasn't gone "live" yet (meaning: we haven't told people the URL yet).
It works as advertised in that it's serving static content and very quickly. Tomcat serves the dynamic requests that TUX passes on to userland.
One caveat is that you have to use the HTTP 1.0 connector in Tomcat. I figured this out after almost a week of pulling my hair out. Since Tomcat uses HTTP 1.1 by default and HTTP 1.1 keeps connections alive to save socket negotiation time, it wasn't letting go of the socket and serving out 404s instead of letting TUX handle the next request. As time permits, I plan on tweaking the Tomcat code to disable keep-alives.
But other than that, it works just fine. Since Tomcat is handling dynamic requests which involve some processing time, the extra overhead associated with HTTP 1.0 is not an issue. We've load testing it with JMeter on a few hosts with no obvious problems -- but I'm sure that sending it live will uncover some hiccups (it always does).
If speed your concern for static content, put TUX in front of tomcat. No config changes are necessary for tomcat and TUX can saturate gigabit ethernet adapters easily and with comparatively little CPU overhead (more CPU free for tomcat to handle the dynamic stuff).
Not true when compared against modern C++ (and its compilers). C's libraries may not be (and may never be due to compiler pointer aliasing issues), but C++'s are. One in particular is Blitz++.
Not to take away from Fortran. Language in general means far less to performance than an experienced programmer and good algorithms. A good compiler helps too. After that, it's all ones and zeros -- not a language that most humans can understand.
You're pushing the app, the burden is on you. I can't be bothered. All I know is that what I see in front of me with Mozilla 1.0 and 1.1 If the benchmarks don't reflect that then there's something wrong with the benchmark.
Please double-check the discussion. When did I ever say that Mozilla has no performance problems. I merely implied that singly out XUL as the cause was a red herring. And after checking the Mozilla release notes, I found this interesting tidbit
XUL.mfasl
XUL fast load file. Contains precompiled chrome and JavaScript.
Not an interpreter problem apparently. Must be something in the rendering engine. But that's Gecko. That must mean there's something to optimize in the rendering engine to get better performance. This means that many web pages would get faster if Gecko is worked on. It also means that XUL is merely a side-effect -- thus a red herring. Personally, UI performance hasn't been an issue for me. If it feels too slow for you to work with it, by all means, use something else for now. I hope you come back to Mozilla (or one of its derivatives) someday.
Can't afford to wait "two years" for Mozilla? Try Galeon or K-Meleon. Native widgets and uses the same rendering engine as Mozilla. Isn't that what you asked for? In fact, they're all free/libre software. If you really wanted to do so, you could just download the Galeon source and make it say that it's Mozilla so the picture would be complete.
Anything you want man. Although I have to warn you that Opera has more rendering problems with today's web pages than Mozilla, and Konqueror has scripting problems especially with regard to the DOM. Your choice.
XUL and Java aren't emulated. Emulation is a different animal entirely -- but I digress.
Also, you should try K-Meleon on a Windows box. Quite zippy -- even though its UI is read from a text UI description file. But that's different from reading an XML description file, right? The thing in K-Meleon only reads from the text file. The actual UI renderer is compiled...just like the XUL engine...err...ummm...
You're probably right about Mozilla for BeOS performance. I am not running BeOS nor is it a primary development platform for Mozilla. (I'm not saying that BeOS is bad, merely somewhat neglected.)
I was apparently also incorrect about AbiWord. I went to the AbiWord download page and only saw (apparently) a partial list. With regard to OS 9 being dead, there are many people who have pre-G3 Macs who can't upgrade to OS X. Apple may want to sell new boxes and tell developers to focus on OS X (which I think is generally a good thing), but I must remind you that more people today run OS 9 and earlier than BeOS. Why should BeOS get priority?
So all UI code should be compiled eh? What if XUL were compiled? Would you still have objection to it? I ask because recent Mozilla builds (including 1.0) have a file called XUL.mfasl. To quote the release notes
XUL fast load file. Contains precompiled chrome and JavaScript.
Is this what you had in mind or does it have to be C? By the way, sorry for the insults.
Your points about being consistent with the underlying GUI are well founded, but I think it would be easier to edit the CSS files involved than to write the native interface. Galeon has a fair amount of support and I think that makes the difference. If someone (not me -- I don't care enough about it) were to take some time with the CSS files that determine the appearance of XUL widgets, I think the classic theme could be whipped into shape. But then, we are again talking about a CSS file for each and every platform.
It's a good thing that Mozilla is free software or else someone who thought it was important wouldn't have the means to help out in this area. I mean personally, I'd rather see SVG support in the default builds than native-looking widgets. To each his own.
Then again, Mozilla could be released as native widget versions. But then why would anyone use Galeon, K-Meleon, or Chimera. Aren't those native widget ports of Mozilla? Isn't that what you asked for: a default build of XUL with popular platforms having a native widget option? Where's the problem?
C isn't the hottest language for compile-time processing. The preprocessor is a third-party that completely disregards C syntax and correctness. Sure it can "inline" some commonly used routines, but it does so at the expense of type safety.
C also lacks any facilities for generic programming and thus loses out on many possible compile-time optimization types: functors, type traits, etc.
Sorry folks, but I just couldn't resist. C-zealots, who think that it is the one and true language, really sadden me. Wanting to compile your UIs ahead of time is silly to me, but at least has a foothold in logic with regard to "raw speed" issues. Writing them in C just strikes me as a supreme waste of time; there are better compilative languages out there do work with UIs than C.
Here's a hint: if you see void*, you're looking at a runtime, can't be well-optimized chunk of code. Every time through the path of execution, that pointer's got to be dereferenced even though its target may never change. Every function pointer call has more overhead than a raw function call or a (perhaps inlined) functor call.
Premature optimization is the root of all evil. Unless you're kernel hacking (or equivalent), C is one great big premature optimization. Write it the easy way, and only after a problem presents itself, rewrite it in C (or a more flexible compilative language).
But that's okay. For some reason, many C coders seem to think that since it was difficult, since it is the original language of UNIX, since they have a collective big-dick complex about programming languages, it takes away from their intense need to get a date and a life.;-)
For text, it's fine. For everything else, Gecko is slow. As pages are mostly text, the slowness of Gecko doesn't matter much; for XUL, you really notice it, especially because normally, widgets are faster than any other part of the UI (even when Gecko isn't a factor).
You're helping to prove my point about C and compilers although I'm a bit lost with regard to your speed statements. Menus, dropdowns, and other bread-and-butter XUL widgets are not based in graphics. Last I checked (using Mozilla right now), the menus were text-based. That said, the issue is not XUL but Gecko's image handling speed. XUL is only a side effect. Animated graphics were found to be a major time sink when the throbber (top-right logo) was found to be the source of slowdowns. They worked on animated GIF performance and the XUL UI became faster. If Gecko's image handling is sped up (I wasn't aware of any major problems with static image loading by the way) then XUL again speeds up.
AbiWord is the same way, but it uses native widgets, and clicking an AbiWord menu works instantaneously, whereas clicking a Moz menu takes multiple seconds to load - it just doesn't feel clean.
Okay, I've been trolled. C'mon now. "A couple of seconds"? I'm writing this on a P2-300 Vaio laptop. If a menu took a single second to load, Mozilla would be usuable for me. I seriously doubt that you have used Mozilla in the last year. If you have, then you are just lying or trying to run it on a 486 with 16MB of RAM. If you are talking about the preferences dialog, you aren't looking at an inherent slowness of XUL. It's lazy loading of preferences -- an algorithm choice. The UI slowness is a red-herring. Preferences performance is (a) low priority compared to other things thank god, (b) nothing to do with XUL performance, and (c) akin to people blaming a web browser for speed issues when they're using a 14.4 modem. Speed up the net connection, and the web browser gets faster. Optimize the preferences dialog algorithms, and XUL will seem faster.
Re: AbiWord Don't misunderstand; I have no end of respect for the AbiWord developers. But comparing Mozilla's portability with that of AbiWord is foolish. AbiWord supports Windows, Linux, FreeBSD, Mac OS X, and QNX. That's it. You are not talking about the same scope. There is no version for Mac OS 9.x and earlier unlike Mozilla. There is no port for BeOS unlike Mozilla. I submit that it is faster and easier for Mozilla to be ported to a new platform than AbiWord, and I also submit that XUL has a great deal to do with this. For Mozilla, developers must write a Netscape Portable Runtime implementation for the new platform, and perhaps make some tweaks to handle the graphics primatives. AbiWord would have to completely rewrite the UI after having someone learn the new widget API for the platform. And AbiWord doesn't even deal with advanced threading or network issues!
I suppose you like Word's UI then? Or would you rather use a less bloated word processor?
Honestly, I don't know a single person who truly prefers complex interfaces to simple ones.
You misunderstood my point. Mozilla's UI is more complex, yes. Galeon's interface is simple and clean, yes. I don't dispute those points. My point was that Galeon does less than Mozilla. In addition, I believe that a new XUL "theme" (for lack of a better word) could make Mozilla look exactly like Galeon with comparable speed. How? Reducing the number of widgets makes anything faster and reducing the functionality of the browser (Galeon does less on the backend than full Mozilla even if XUL is taken out of the equation) and the number of components that get loaded.
In C programs, after compilation and linking, the program is ultimately written in machine-language. It's a native program. Similarly, in AbiWord, the cross-platform bit is taken care of at compile-time, leaving you with native widgets at native speed when you run. Mozilla is more like Java. You run the widgets in emulation; the compilation doesn't happen at run-time.
There's a place for emulated languages. Java applets are nice on webpages where speed is less important than portability, and Perl or Python are good for their flexibility. But for a project like Mozilla, I'd rather see it follow the C paradigm, and optimize at compile-time.
Oh where to begin. Let's take a trip down memory lane about thirty years ago when C compilers were relatively new. The arguments most often heard were that C was bloated, it could never compete with assembly for speed, it was too easy, it may be good for portability, but only a few platforms are important, etc.
Sounds very similar to the arguments you are making now.
How about twenty years ago when the X Windows System was first being proposed. Why on earth would anyone want a universal windowing system? It will be the death of innovation and speed.
I was just playing Quake 3 a little while ago on it. I guess it got faster. Now aside from the fact that Java has proven itself to be much more able on the server side than as a client-side applet (I feel the flamewar igniting again), study after study, research project after research project has demonstrated that productivity skyrockets after using a scripting language in place of a compiled language like C. These same real-world study documents also demonstrate no great speed increase in most (>90%) applications when C is used.
Remember Knuth's 80-20 rule? You did read Knuth's work right? 80% of running time is in 20% of the code. How much time do you think the UI is taking in processing time? Let's suppose for the moment that you're right, I'm wrong, and XUL is the source of all of the problems with speed in Mozilla. In most browsing sessions, I barely touch the menubar; most of my time is spent in the main browser area. If I'm not interacting with XUL most of the time, how can it be such a horrible timesink in real-world use.
That said, I assert that you have not put a profiler on Mozilla and are talking out of your ass with regard to the XUL engine. You might say that the UI design is bad. You might say that some of the backend component calls could use some optimization, but when you say that XUL is too slow to comfortably use, you sound like a fool.
Repeat a lie enough and it will become truth I guess.
The real skinny on XUL: It is not as slow as people make it out to be. It is not the reason for Mozilla having any speed problems. It *is* compiled into native instructions when your browser is up and running. This functionality made it into the tree some time ago. Too many people were howling about the slowness of XUL two years ago to notice apparently.
Don't believe me? Try running a profiler on Mozilla sometime and report back the hotspots. What's that? Even though the source is available and people have access to profilers, not one of the XUL naysayers here even tried? But that would mean that they pulled XUL performance stats out of their asses. (To be fair, a couple of years ago, XUL had some major redrawing and rendering issues -- not the case today. Maybe it's just a case of stale info that desperately needs to be thrown away) In addition, projects like Galeon are not faster because of native widgets (although it may have been the case a couple of years ago). IF you look at feature-to-feature, Mozilla does more than Galeon. Just look at the JavaScript engines, the DOM handling (the DOM debugger, the DOM inspector,
etc.), the fact that Galeon only runs on one platform(!), etc. Galeon is not Mozilla + native widgets. Galeon is Mozilla-- + native widgets.
Does XUL intrinsically look exactly like native widgets? No. Does the classic theme look very much like native widgets. Absolutely. Does the modern theme look like native widgets? No. Was it planned to look "native"? No! Modern theme looks the same no matter what platform you are on. If you want consistency of browser UI when using multiple operating systems (as I do), then use Modern. If you want something more akin to a native feel, use classic. If you absolutely want native widgets, use Galeon, K-Meleon, or Chimera. That's what these projects are there for!
As a side note, XUL is rendered by Gecko. You can't say that one is slow while the other is fast. They are different limbs of the same beast.
As was pointed out on the Mozilla performance newsgroup, there is no magic "native" flag that makes video cards paint faster. Whether a widget is linked from a shared library, compiled from C, or read from an XML file (and later translated to machine instructions), they all paint to the same canvas: the system graphics library. If MFC has some innate advantage here, I'm sure that the folks who write Qt and WxWindows would love to hear about it as well as they would no longer be "native" either.
The reason that Mozilla developers can handle the large number of platforms that Mozilla runs on is because of XUL. The code is amazing in its cross-platform purity. Fix a mail client bug here and it's fixed everywhere. Fix a UI bug there and its fixed everywhere. Contrast this with fixing a UI bug in the Windows code and it must be fixed in Mac (OS 9- and OS 10+), X (Xlib, GTK+ and Qt ports), BeOS, OS/2, OpenVMS(!), Amiga, etc.
I'm not saying that XUL didn't take a long time. I'm not saying that it saved a whole lot of development time until recently. What I am asserting is that all new bugfixes and enhancements can now happen much faster (and have been for the last year or so) than would be possible with native libraries and widgets. And it's not like Mozilla isn't modular and reusable; how do you think Galeon and K-Meleon were able to be released so quickly? They whipped up a barebones UI up on the infrastructure written by Mozilla developers. If you like Galeon, K-Meleon, and Chimera, it probably has more to do with liking barebones UIs than an inherent deficiency in Mozilla's UI. That said, if that's your preference, more power to you. Just don't shit on someone else's meal when your food comes from the same kitchen.
What the Mozilla developers have done is akin to shunning assembly language for C. Back in the day, C was slow and bloated as compared to hand-crafted assembly. Then people noticed that they wrote more and with fewer bugs with C. Then the compilers got better. Then assembly didn't make much sense except in small niches. Imagine! Writing your UI in a simple text file and handling UI events in a simple scripting language. Don't like the UI colors? Just edit CSS files instead of editing.c files and waiting for the recompile. Your program UI can be as simple as editing a web page!
But I can hear it now. "But it's not as fast as compiled UIs." "It uses more memory." In a couple of years, advances in the rendering engine and the XUL processor (think 'compiler') will narrow the gap so far as to make the gap imperceptible. It's assembly versus C all over again. Which side do you want to be on? Personally, I think life is too short for recompiles.
If you want to get down and dirty, recompiling at every step, write an operating system or help out on the Gecko renderer and XUL processor. For everything else, there's XUL, scripting, and CSS.
I love the show. I watch the show. I bought the DVD set.
It is NOT like stopping black folks from voting. Hmmm... Yeah, I could see how you would draw a parallel... TV show is denied opportunity to get Hollywood award. Segment of population denied rights as citizens.
Slashdot Mirror
Fine. How about ATMs that only white men can use?
As for "If SW Airlines doesn't want blind people for customers, so be it," replace with "If SW Airlines doesn't want black people or women for customers, so be it."
You will probably reply that it's different. On the other hand, it is quite possible for any web page designer to make their site usable from braille readers. The ADA was meant to keep this from happening. There aren't enough blind people in this country to have an economic impact on a company to the extent that they voluntarily make disabilities a priority. This does not mean that blind people should be shot and left at the side of the road.
There is nothing intrinsic to travel on Southwest airlines that precludes access to blind passengers. If this was a first-person shooter game, where sight and visuals are an intrinsic part of the game which cannot easily be substituted, the ADA would not apply. Southwest, however, has the cheapest fares in the area and already makes provisions in their business for blind passengers. Assuming that some other airline's web site is braille reader accessible. This means that for the same travel plans, a blind person MUST spend two or three times as much as a sighted passenger. This is effectively a tax on the blind.
But I digress. I am simply amazed that the readers of Slashdot have such a large group of people against this. At the very least, it would guarantee that large corporations make their web sites available in all browsers (think banks and their current fixation on IE). It would also limit the amount of superfluous JavaScript on pages. ISN'T THIS WHAT A LARGE GROUP OF SLASHDOT READERS WANT!?!
I, for one, have no problem with the fact that it comes on the heels of a guarantee to support blind users. To me, access to the blind is a far more noble and worthwhile goal than choice of browser and the fight against Microsoft hegemony.
But this is what I'm talking about. You're right that those are some pretty verbose names, but at least we're talking about it. It's hard to get people to even entertain the concept before deciding.
/settings exists on install/compile. K&R's strcmp, strcat, strstr, strchr, etc. aren't clear names! They are artifacts of a system that could only handle commands that are six characters or less (This is why the game Adventure was originally typed in as the command 'advent').
/settings as a bad name and wanted to find something else (maybe something that isn't filesystem dependant -- I don't know), I'd be fine with that. But people aren't even allowing for the possibility of debate on the topic!
/etc so why change it." I have yet to hear, "It might be worth it, but it'll take a few years," so that we can at least get a gameplan going. I don't really care about /etc; That's just a symptom.
As far as existing software, I can't think of an easier patch to a program than a search and replace of "/etc". Far easier to find and fix than all the off-by-one errors out there. And as you said, config.h could have the correct directory. Is it work? Sure. Is it hard? Not in a couple year's time. Old software? I don't know of many programs on my system that are both path-dependant and that haven't had a single update in a couple of years. For folks that have server configs, those won't be changing for other reasons: the base configs are static for years minus minimal patching for stability and security.
As for POSIX, the fact that it's unlikely is saddening to me. Even if solutions are suboptimal, they aren't re-evaluated. "If it ain't broke" doesn't necessarily apply. A primary critique of Linux (and *NIX in general) is that it's difficult to use, figure out, etc. So much effort is going into this on the GUI side, and yet the lower levels are left to sit with no improvement. No matter how good the GUIs get, they will still be dependent upon decisions (justifiably) made in 1970. People aren't even willing to talk about it.
As for clever developers, I'm sure the clever ones can not only search and replace, but can easily find if
There are many things about UNIX and POSIX that are well worth keeping. All told, they are very elegant systems. But they are not perfect and people aren't even talking about ditching the legacy cruft. This is my beef, not whether or not my ideas are implemented. If people say
I only had a couple of responses saying "It can't be done; There's too much software out there," or "It can't be done; It's always been
I agree, unnecessary. But it would be less cryptic and therefore easier to intuitively figure out. But it is not for you or I to decide that someone isn't worthy enough to tweak settings because their first foray into the Linux operating system didn't include the knowledge that system config settings are in /etc.
/etc is an obvious label, but rather than make any effort to remedy this, it is accepted, new users are just told to shut up and use the GUI, and if they get frustrated with the generally poor state of GUI tools on Linux (as compared to Mac OS X for example), they are told that if they're too stupid to intrinsically know that /etc means "settings," they deserve the frustration they encounter.
/etc, be prepared for me to ridicule you for not being able to remember that /settings is the new directory.
GUIs are great for getting a job done sometimes, but they are horrible for figuring out the layout of a working system. This is a primary complaint that I have had with Windows. Control Panel tells me nothing about how it works, where the files are defined or what format they're in. There is indeed developer documentation for this, but it's basically obscure.
GUIs are also horrible for showing all of the options. GUIs will often fall one step behind the actual functionality. Look at a config file in Linux and you generally see all of the options, unused options commented out, and their defaults. I can tell you plenty of times where I've had to tweak a settings that wasn't represented in the GUI for whatever reason. A new user, when using a GUI, wouldn't know where the base configuration settings were, wouldn't know that they even exist, and will throw their hands up in disgust, walk away from Linux, and bad-mouth the OS to everyone they meet because Windows has a GUI for the option.
Admittedly, this can be greatly bypassed by making all of the configuration files a uniform file format with a defined schema that GUI tools can use to make intelligent admin GUI options, but it highlights a culture in the Linux (and UNIX) world: I had to learn it, I now know it, and everyone else should have to do the same. Some folks have known it for so long, they don't remember what it was like when they didn't know it.
Inertia isn't necessarily a bad thing. Neither is tradition. But when there are better options available, to ignore them is foolish. In these cases, they are elitist. No one has argued that
If you want a good harvest, you need to be willing to turn the field upside down every season. (Note I did say to keep symlinks around for backward compatibility for a few years.)
If you can make fun of folks who can't remember
Written in assembly hunh? I'm sure that aids portability doesn't it? I was under the impression that compilers were pretty good nowadays.
Even though /usr, /var, /tmp, /etc are ridiculously cryptic, changing them would be horrible?
/etc to /settings or /config /var/log to /logs /var to /data (or something like it) /tmp to /temp (saving one character? sheesh!) /usr to /programs /bin to /system_programs
/etc may have difficulty configuring their box to be sure. But they'll have less difficulty if the directory is named /configuration or /settings won't they? The operating system shouldn't be some kind of high bar or IQ test. It should be a tool to get a job done. /etc to /settings doesn't make your life and my life appreciably harder and it makes life for newbies that much easier.
/etc less oddball than /settings? What universe do you live in? The directory name "etc" is an artifact of history, not a brilliant design plan. 1K of memory was expensive so the directory names were kept as short as possible. Now 1K is a rounding error. The reasons for "etc" no longer exist today. You might as well tell me that people should still hone their PDP-11 assembly skills before doing any programming in a high-level language.
/etc. Good for you. After the rest of the world moves on, you can make your symbolic links. The rest of the world -- this includes all of those folks who accurately regard a computer and operating system as merely tools -- is used to descriptive names. /etc ain't descriptive. It's the UNIX club's code word for /settings. They like code words. It's like a secret handshake. It maintains a feeling of superiority however obviously false that feeling may be.
Get this:
Change
Change
Change
Change
Change
Change
and then (drumroll) make symbolic links so that old scripts and programs still work. You leave that in place for a couple of years, and then you remove the symbolic links. All that's left are logical names that actually convey information. And before people complain about the amount of extra typing, please tell me that you know how to use <tab> for filename completion (se<tab> gets you settings for example).
Users who can't remember that config files live in
And how, by any stretch of the imagination, is
You're used to
But system documentation is fundamentally different from technical documentation (DocBook)? If a new schema is made, I would hope that it's at least a subset of DocBook (like already existing Simplified DocBook).
Other than that, you took the words right out of my mouth. An LDAP interface to general configuration info would be nice too: network aware and accessible configuration and authentication info as a standard feature (but network access to it turned off by default of course for security reasons).
actually, the IDE layer WAS completely reworked. And it didn't work...for a long time. It was scrapped and a slightly modified 2.4 IDE layer was front ported to get back to stable code.
Other than that, I agree with you.
Expensive alternative? Like PostgreSQL? Seems to me they were knocking MySQL specifically. At the IBM booth at LinuxWorld, when I mentioned PostgreSQL, the guy had nothing bad to say about it for smaller installations. For a single box, he thought it was a great product and definitely a long way better than MySQL.
Then he pointed out the server farm (I think something like forty boxes in a rack) running effectively one single instance of DB2. They all handle queries, they load balance, and if one goes down, the rest pick up the slack immediately with no downtime.
Now THAT's enterprise.
Okay, you're not running a bank. What if some site (let's call it slashdot for brevity) wanted to award 10 karma points to everyone who's been a user for longer than a year -- kind of a "thanks for your support" gesture.
So we have the following (note: I know that the slashdot schema doesn't look like this -- illustrative purposes only):
SELECT userid, karma FROM users WHERE user_created < cast_to_date('20010923');
Yes, I know that's not MySQL syntax, but you get the picture. You'd also probably want to use a cursor here, but I'll keep it simple...
UPDATE users set (karma) VALUES ($old_karma + 10) WHERE userid = $some_id;
Where do you put the lock? I guess around the whole thing (or around the cursors if you are saavy enough to know better). I wouldn't think that would be particularly fast.
But wait! Slashdot experiences yet another database outage (and we all must acknowledge that these occur from time to time)! Which records were awarded 10 karma points!?! If you re-award them, some folks will get 20 points! If you pull them back, some people will get docked 10 (or end up with no extra points). By golly! The database has been left in an inconsistent state!
This is why transactions are necessary. And yes, I am calm. I don't use MySQL. I don't have to wait for them to be implemented and for them to be in a stable version of a product. I use one of the other Open Source database products that have had transactions for years. And that transaction support has been stable for years. And the price for the other database products is just as right as MySQL's price.
Telling people to use MySQL today because it will have a complete feature-set tomorrow is like when Microsoft told people to buy Windows ME because Windows will be getting more stable and secure tomorrow. The logic works fine until you see that there are alternatives that have already done what is needed...yesterday.
A Slashdot article about XHTML 2.0 and the wave of the future and yet the top of every page has the line:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
3.2? Now that's a blast from the past. How much do you want to bet that Slashdot's audience by and large uses browsers that are compatible with XHTML 1.1? This isn't the AOL start page after all...
Well...at least they have an XML and an RDF feed.
Mozilla does NOT support DOM better than IE. DHTML is faster in IE by a large margin (getting smaller but large nonetheless). Feature-wise they are about equal. Speed-wise there is no real competition.
Posted from Mozilla July 30th nightly build.
So don't use Mozilla. Last time I checked, no one was forcing its use.
"I want a web browser."
So get a web browser. You have Opera, IE, Mozilla, Konqueror and derivatives of them. Personally I want the application platform tailored to network content and display. There's too much associated with the word "browser." Some folks -- like you -- just want a basic rendering engine. Other folks want a rendering engine with a lot of scripting ability. Still others -- like me -- want to reuse pieces of the browser in applications that I write because I have little desire to reimplement an HTTP client, a rendering engine, a JavaScript engine, etc. The great thing about having all of these different products is that at least one of them should serve your needs. Of course having multiple solutions means that it would be a good idea to share a common method of authoring -- some would call them "standards."
As for the mail client, the client to Mozilla isn't "bolted on" but rather uses many of the same components that the browser uses. Do you have something against code reuse? Or should Mozilla's mail client reimplement the networking layer? How about viewing messages? Most modern email client support HTML email so I assume that Mozilla developers should have written a separate renderer just for the mail client.
Different strokes for different folks. Stop whining. And for the record, if you use Netscape, you *are* using AOL.
It's on a production box, but it hasn't gone "live" yet (meaning: we haven't told people the URL yet).
It works as advertised in that it's serving static content and very quickly. Tomcat serves the dynamic requests that TUX passes on to userland.
One caveat is that you have to use the HTTP 1.0 connector in Tomcat. I figured this out after almost a week of pulling my hair out. Since Tomcat uses HTTP 1.1 by default and HTTP 1.1 keeps connections alive to save socket negotiation time, it wasn't letting go of the socket and serving out 404s instead of letting TUX handle the next request. As time permits, I plan on tweaking the Tomcat code to disable keep-alives.
But other than that, it works just fine. Since Tomcat is handling dynamic requests which involve some processing time, the extra overhead associated with HTTP 1.0 is not an issue. We've load testing it with JMeter on a few hosts with no obvious problems -- but I'm sure that sending it live will uncover some hiccups (it always does).
If speed your concern for static content, put TUX in front of tomcat. No config changes are necessary for tomcat and TUX can saturate gigabit ethernet adapters easily and with comparatively little CPU overhead (more CPU free for tomcat to handle the dynamic stuff).
You can read more about TUX here.
Did I miss something? What is an "icon-based programming language" such as the one mentioned in the article?
Is this dragging the "for" icon on top of the "database cursor" icon and filling in a SQL query after a right-click context menu?
Not true when compared against modern C++ (and its compilers). C's libraries may not be (and may never be due to compiler pointer aliasing issues), but C++'s are. One in particular is Blitz++.
Not to take away from Fortran. Language in general means far less to performance than an experienced programmer and good algorithms. A good compiler helps too. After that, it's all ones and zeros -- not a language that most humans can understand.
C's libraries may not be (and may never be due to compiler pointer aliasing issues), but C++'s are. One in particular is Blitz++.
Not to take away from Fortran. Language in general means far less to performance than an experienced programmer and good algorithms.
Can't afford to wait "two years" for Mozilla? Try Galeon or K-Meleon. Native widgets and uses the same rendering engine as Mozilla. Isn't that what you asked for? In fact, they're all free/libre software. If you really wanted to do so, you could just download the Galeon source and make it say that it's Mozilla so the picture would be complete.
Anything you want man. Although I have to warn you that Opera has more rendering problems with today's web pages than Mozilla, and Konqueror has scripting problems especially with regard to the DOM. Your choice.
XUL and Java aren't emulated. Emulation is a different animal entirely -- but I digress.
Also, you should try K-Meleon on a Windows box. Quite zippy -- even though its UI is read from a text UI description file. But that's different from reading an XML description file, right? The thing in K-Meleon only reads from the text file. The actual UI renderer is compiled...just like the XUL engine...err...ummm...
I was apparently also incorrect about AbiWord. I went to the AbiWord download page and only saw (apparently) a partial list. With regard to OS 9 being dead, there are many people who have pre-G3 Macs who can't upgrade to OS X. Apple may want to sell new boxes and tell developers to focus on OS X (which I think is generally a good thing), but I must remind you that more people today run OS 9 and earlier than BeOS. Why should BeOS get priority?
So all UI code should be compiled eh? What if XUL were compiled? Would you still have objection to it? I ask because recent Mozilla builds (including 1.0) have a file called XUL.mfasl. To quote the release notes Is this what you had in mind or does it have to be C? By the way, sorry for the insults.
Your points about being consistent with the underlying GUI are well founded, but I think it would be easier to edit the CSS files involved than to write the native interface. Galeon has a fair amount of support and I think that makes the difference. If someone (not me -- I don't care enough about it) were to take some time with the CSS files that determine the appearance of XUL widgets, I think the classic theme could be whipped into shape. But then, we are again talking about a CSS file for each and every platform.
It's a good thing that Mozilla is free software or else someone who thought it was important wouldn't have the means to help out in this area. I mean personally, I'd rather see SVG support in the default builds than native-looking widgets. To each his own.
Then again, Mozilla could be released as native widget versions. But then why would anyone use Galeon, K-Meleon, or Chimera. Aren't those native widget ports of Mozilla? Isn't that what you asked for: a default build of XUL with popular platforms having a native widget option? Where's the problem?
C isn't the hottest language for compile-time processing. The preprocessor is a third-party that completely disregards C syntax and correctness. Sure it can "inline" some commonly used routines, but it does so at the expense of type safety.
;-)
C also lacks any facilities for generic programming and thus loses out on many possible compile-time optimization types: functors, type traits, etc.
Sorry folks, but I just couldn't resist. C-zealots, who think that it is the one and true language, really sadden me. Wanting to compile your UIs ahead of time is silly to me, but at least has a foothold in logic with regard to "raw speed" issues. Writing them in C just strikes me as a supreme waste of time; there are better compilative languages out there do work with UIs than C.
Here's a hint: if you see void*, you're looking at a runtime, can't be well-optimized chunk of code. Every time through the path of execution, that pointer's got to be dereferenced even though its target may never change. Every function pointer call has more overhead than a raw function call or a (perhaps inlined) functor call.
Premature optimization is the root of all evil. Unless you're kernel hacking (or equivalent), C is one great big premature optimization. Write it the easy way, and only after a problem presents itself, rewrite it in C (or a more flexible compilative language).
But that's okay. For some reason, many C coders seem to think that since it was difficult, since it is the original language of UNIX, since they have a collective big-dick complex about programming languages, it takes away from their intense need to get a date and a life.
If a menu took a single second to load, Mozilla would not be usuable for me.
Re: AbiWord
Don't misunderstand; I have no end of respect for the AbiWord developers. But comparing Mozilla's portability with that of AbiWord is foolish. AbiWord supports Windows, Linux, FreeBSD, Mac OS X, and QNX. That's it. You are not talking about the same scope. There is no version for Mac OS 9.x and earlier unlike Mozilla. There is no port for BeOS unlike Mozilla. I submit that it is faster and easier for Mozilla to be ported to a new platform than AbiWord, and I also submit that XUL has a great deal to do with this. For Mozilla, developers must write a Netscape Portable Runtime implementation for the new platform, and perhaps make some tweaks to handle the graphics primatives. AbiWord would have to completely rewrite the UI after having someone learn the new widget API for the platform. And AbiWord doesn't even deal with advanced threading or network issues! You misunderstood my point. Mozilla's UI is more complex, yes. Galeon's interface is simple and clean, yes. I don't dispute those points. My point was that Galeon does less than Mozilla. In addition, I believe that a new XUL "theme" (for lack of a better word) could make Mozilla look exactly like Galeon with comparable speed. How? Reducing the number of widgets makes anything faster and reducing the functionality of the browser (Galeon does less on the backend than full Mozilla even if XUL is taken out of the equation) and the number of components that get loaded. Oh where to begin. Let's take a trip down memory lane about thirty years ago when C compilers were relatively new. The arguments most often heard were that C was bloated, it could never compete with assembly for speed, it was too easy, it may be good for portability, but only a few platforms are important, etc.
Sounds very similar to the arguments you are making now.
How about twenty years ago when the X Windows System was first being proposed. Why on earth would anyone want a universal windowing system? It will be the death of innovation and speed.
I was just playing Quake 3 a little while ago on it. I guess it got faster. Now aside from the fact that Java has proven itself to be much more able on the server side than as a client-side applet (I feel the flamewar igniting again), study after study, research project after research project has demonstrated that productivity skyrockets after using a scripting language in place of a compiled language like C. These same real-world study documents also demonstrate no great speed increase in most (>90%) applications when C is used.
Remember Knuth's 80-20 rule? You did read Knuth's work right? 80% of running time is in 20% of the code. How much time do you think the UI is taking in processing time? Let's suppose for the moment that you're right, I'm wrong, and XUL is the source of all of the problems with speed in Mozilla. In most browsing sessions, I barely touch the menubar; most of my time is spent in the main browser area. If I'm not interacting with XUL most of the time, how can it be such a horrible timesink in real-world use.
That said, I assert that you have not put a profiler on Mozilla and are talking out of your ass with regard to the XUL engine. You might say that the UI design is bad. You might say that some of the backend component calls could use some optimization, but when you say that XUL is too slow to comfortably use, you sound like a fool.
*sigh*
.c files and waiting for the recompile. Your program UI can be as simple as editing a web page!
Repeat a lie enough and it will become truth I guess.
The real skinny on XUL: It is not as slow as people make it out to be. It is not the reason for Mozilla having any speed problems. It *is* compiled into native instructions when your browser is up and running. This functionality made it into the tree some time ago. Too many people were howling about the slowness of XUL two years ago to notice apparently.
Don't believe me? Try running a profiler on Mozilla sometime and report back the hotspots. What's that? Even though the source is available and people have access to profilers, not one of the XUL naysayers here even tried? But that would mean that they pulled XUL performance stats out of their asses. (To be fair, a couple of years ago, XUL had some major redrawing and rendering issues -- not the case today. Maybe it's just a case of stale info that desperately needs to be thrown away) In addition, projects like Galeon are not faster because of native widgets (although it may have been the case a couple of years ago). IF you look at feature-to-feature, Mozilla does more than Galeon. Just look at the JavaScript engines, the DOM handling (the DOM debugger, the DOM inspector,
etc.), the fact that Galeon only runs on one platform(!), etc. Galeon is not Mozilla + native widgets. Galeon is Mozilla-- + native widgets.
Does XUL intrinsically look exactly like native widgets? No. Does the classic theme look very much like native widgets. Absolutely. Does the modern theme look like native widgets? No. Was it planned to look "native"? No! Modern theme looks the same no matter what platform you are on. If you want consistency of browser UI when using multiple operating systems (as I do), then use Modern. If you want something more akin to a native feel, use classic. If you absolutely want native widgets, use Galeon, K-Meleon, or Chimera. That's what these projects are there for!
As a side note, XUL is rendered by Gecko. You can't say that one is slow while the other is fast. They are different limbs of the same beast.
As was pointed out on the Mozilla performance newsgroup, there is no magic "native" flag that makes video cards paint faster. Whether a widget is linked from a shared library, compiled from C, or read from an XML file (and later translated to machine instructions), they all paint to the same canvas: the system graphics library. If MFC has some innate advantage here, I'm sure that the folks who write Qt and WxWindows would love to hear about it as well as they would no longer be "native" either.
The reason that Mozilla developers can handle the large number of platforms that Mozilla runs on is because of XUL. The code is amazing in its cross-platform purity. Fix a mail client bug here and it's fixed everywhere. Fix a UI bug there and its fixed everywhere. Contrast this with fixing a UI bug in the Windows code and it must be fixed in Mac (OS 9- and OS 10+), X (Xlib, GTK+ and Qt ports), BeOS, OS/2, OpenVMS(!), Amiga, etc.
I'm not saying that XUL didn't take a long time. I'm not saying that it saved a whole lot of development time until recently. What I am asserting is that all new bugfixes and enhancements can now happen much faster (and have been for the last year or so) than would be possible with native libraries and widgets. And it's not like Mozilla isn't modular and reusable; how do you think Galeon and K-Meleon were able to be released so quickly? They whipped up a barebones UI up on the infrastructure written by Mozilla developers. If you like Galeon, K-Meleon, and Chimera, it probably has more to do with liking barebones UIs than an inherent deficiency in Mozilla's UI. That said, if that's your preference, more power to you. Just don't shit on someone else's meal when your food comes from the same kitchen.
What the Mozilla developers have done is akin to shunning assembly language for C. Back in the day, C was slow and bloated as compared to hand-crafted assembly. Then people noticed that they wrote more and with fewer bugs with C. Then the compilers got better. Then assembly didn't make much sense except in small niches. Imagine! Writing your UI in a simple text file and handling UI events in a simple scripting language. Don't like the UI colors? Just edit CSS files instead of editing
But I can hear it now. "But it's not as fast as compiled UIs." "It uses more memory." In a couple of years, advances in the rendering engine and the XUL processor (think 'compiler') will narrow the gap so far as to make the gap imperceptible. It's assembly versus C all over again. Which side do you want to be on? Personally, I think life is too short for recompiles.
If you want to get down and dirty, recompiling at every step, write an operating system or help out on the Gecko renderer and XUL processor. For everything else, there's XUL, scripting, and CSS.
I love the show. I watch the show. I bought the DVD set.
It is NOT like stopping black folks from voting. Hmmm... Yeah, I could see how you would draw a parallel... TV show is denied opportunity to get Hollywood award. Segment of population denied rights as citizens.