Probably explains why you think that Mozilla is poorly designed... I have nothing against C. I code in C as well. However your comment strikes me as being entirely too similar to other comments I've heard from pure C programmers. C is just a tool like a hammer. However if it the only tool with which you have practical experience, you will see the world as a nail. There is no direct analogy between some computer languages for exactly the same reason that their is no direct translation between different human languages (precisely why interpreting between languages is so difficult a job). C code does not directly translate to component-based C++ which does not directly translate to Java.
Mozilla is C++, JavaScript and XPCOM with only a light sprinkling of C. As such they are approaching the problem correctly: attacking the interfaces and leaving the implementation optimizations until last. This is what they have done. Read the roadmap. They have stated that optimization has only started recently. They were completing the interfaces and the base implementation before optimizing.
> It would take me perhaps a few months to
> achieve the knowledge that the existing
> developers have in the project. That would be a
> waste of time because I am not a part of that
> team, and have no intentions to ever be. My time
> is best spent elsewhere.
Yes it would. It is an investment of time. IF you are not willing to invest that time, so be it. It is your decision. But do not then criticize others because they do not share your priorities.
You say that you have worked on long-term projects (libraries and kernel). And yet you have never come upon the bug that keeps getting set aside because there are more important things to a lot of people. Mozilla's bugzilla has a "most requested bug fix." This and its ilk are attacked first. It doesn't look like your pet bug are most requested by the others that use Mozilla.
Unfortunately, the Mozilla project hasn't garnered the attention that the Linux kernel has gathered. As such, it doesn't have the same amount of driving force behind it (people). And yet some filesystems have rotted and died. Some devices have fallen by the wayside. Is this because no one uses them or bemoans their loss. No. A small enough percentage stopped using them and no one with sufficient coding experience to maintain them stepped forward to claim them.
> I will suggest to you that the organization of
> Mozilla falls somewhere between messed up and
> fubarred. Now that's just my opinion based on
> looking at several pieces of the code. And I do
> think that's a major reason why Mozilla has been
> so late, runs so slow, and is riddled with bugs.
> IMHO, their whole development approach is wrong.
A component-based, language-neutral approach is wrong? No I don't think that C is obsolete and I am not suggesting it. You are basing your opinion on your past experience. I am basing mine on my past experience when actually writing/using/maintaining many disparate options (C vs. Objects vs. Components). It is obvious that we will not agree anytime soon. However I would suggest that you (re)read Design Patterns.
> The often-replied statement "submit a patch"
> is what I'm complaining about.
Really? And here I thought this was one of free software's hallmarks. I have researched the problem. I now how difficult it is. I have every right to post this. If so many people weren't resting their hopes on Mozilla, no one would care that they are taking this long or using this approach (which would have put them in the same category as 99% of all free software projects).
No, I have not been programming C as long as you have. I would have had to start when I was eight years old and my parents weren't programmers. I'm am not doubting your abilities as a C coder. I fully acknowledge that if put in a room alone, you would be able to produce better kernel code than I. I am however questioning your judgement with regards to languages other than C and your take on your pet bug not being fixed.
If a bug crashes the browser or causes it to suck up ten more megs of RAM, I sure as hell want them to ignore your bug! Let me put this to you "for the sake of informing others." Do you think a project's priority should be on making sure the browser works on multiple platforms at all or that they should take time out to make sure that someone can dictate the size of the browser on startup from the command line?
If you answer the latter, I simply agree to disagree.
marginheight and marginwidth and the W3C is doing nothing about it? Have you been asleep? This is one of the areas where CSS solves the problem. Rather than getting into the whole pissing contest about which attribute is preferred, they moved this styling concern into *shudder* the CSS styling spec.
body { margin: 0px; }
That's it. That's the solution. You put that into an external stylesheet and you have an entire site that does the same thing -- something that HTML cannot do on its own. And you know what? It conforms to W3C validation. What's the holdup? NS 4.x and the other CSS-ignorant clients.
Width of text fields? We're screwed... Oh wait! THAT'S RIGHT! It's already solved in CSS.
input.wide { width: 60px; }
- with -
<input type="text" class="wide"/>
FYI: IE's text fields are smaller by default than Netscape's.
W3C should clean up the HTML standard? That's what they've been doing! That's precisely what XHTML Strict is intended to do. What else can they do? Rewrite HTML specs so that they work in all browsers? Impossible! Browser incompatibilities are the cause of the problem, not the HTML. The fact that they render different than the spec specifies is not the fault of the spec. What else can the spec do? Recode the browser at runtime?
The W3C wasn't responsible for the old standards, is actively working to solve problems with the new standards, and trying to reduce the amount of ambiguity in the web. This will not be done with HTML alone. Take a look at the work being done at www.w3.org because you've obviously never spent any time there.
It's an open development, if the bug's that important to you, submit a patch. Don't know how to code? It's been years since Mozilla opened the code. You've had time to learn. Or did you simply want to benefit from the community without giving something back?
Take a class on C++ and dig in. No one's stopping you. The sooner you start after that bug, the sooner it will be fixed. Isn't this the free source creedo?
The Mozilla Organization discussed over a year ago that they would not support NS 4.x code. Why? Simply because NS 4.x is an abberation in browser history. If they worked on getting the tag to work in Mozilla/NS6, it means that work on CSS, DOM, XML et al would suffer. And to what end? So that developers would be more willing to write tags? NS 4.x is crap. It was crap when it was released. It is certainly crap years later. Quoting Linux kernel config -- "Let's kill this beast now."
It's better to let some things die... Netscape 4.x however could use some help putting a bullet in its head.
No reference implementation? Damn! I guess I was hallucinating when I've seen the Amaya browser touted on the W3C site *for years*.
Standards are a scam? Well then I'm sure that you're angry that there is a standard C, a standard C++, standard peripheral connectors (PCI, USB, etc.), and on and on. Or do you pine for the days when game manufacturers had to write specific support for each sound card. Why was JavaScript taken on by ECMA? Because they wanted to make a common ground so that people wouldn't have to make a JavaScript version and a JScript version of the same damned logic.
Get a clue folks! 99% of the people surfing the web today DON'T use a text-only browser. I don't dispute the greatness of Lynx. I use it occassionally on my server. But we are not necessarily the target audience for disney.com. Case in point, if your company is a graphics arts shop, why in the hell would you code for Lynx?
Your "defacto standards" are bunk! 0.5% of all sites on the web would work in that environment. How is that a defacto standard? Major browsers have supported Java since Netscape broke the ice in 2.0. How is this a major issue?
Do you seriously believe that substance will win over style? Can someone point out a case where this has happened on a medium-to-large scale *ever*? If your ideals for the web were ever followed, the web would not have ever existed. You have just described gopher! The fact that the web is so popular and gopher is effectively dead is proof positive that your suppositions are emphatically wrong.
If you want to use Lynx, go right ahead. I'm not stopping you, but stop whining because others don't want to cater to your personal whims. If enough people want Lynx-compliant pages, more people wil code Lynx-compliant pages. If people aren't coding Lynx-compliant pages, it means that Lynx users are a gross minority. Being in the minority is not a bad thing. But it entails that most things will not be catered to you.
Then you of all people should be happy about the new browsers' abilities with XML. Pure content - no layout. Isn't that what you're asking for? Can older browsers handle it? No? I guess we need the newer browsers then...
Ummm... Will the author of the previous post and all who agree with him please head on over to www.w3.org and read the XHTML spec. There is a "transitional" spec which is basically XML-compliant HTML 4.0 -- only there to act as a bridge between the past and the future. XHTML Strict is based on the preferred model -- with CSS! Death to the <font> tag!!!
KISS? Maintaining 8 different versions of HTML for each page of content is keeping it simple? Keeping web technology stuck at the level of 1996 forever is preferred? Give me a break! This sounds like folks saying that they don't understand why we need graphics for games. Yes, "Adventure" was a great game, but Quake III is never going to work properly on a Mac Classic.
Tunnel vision? Progress never occurs if you stick with the solutions of the past. Should we ditch older ways because they are older? Of course not. You're right in that many pages abuse the new specs for their gee-whiz factor. On the other hand, Netscape 4.x is NOT something to hold dear and precious. Lynx at least has a specific purpose and niche (text-only display). Netscape 4.x only serves to slow the world down.
As soon as people stop seeing NS and IE as web browsers and start seeing them as web application platforms, DHTML and CSS stop being the enemy and start to get real problems solved. There is more to DHTML than image rollovers.
Apples and oranges. SVG is a markup language for vector graphics. Flash is a renderer. Just like HTML, the markup is useless unless you have a rendering engine (browser).
Not quite true. In the case of employment, a former employer is very limited in their available contact with the new employer. When you put down the list of companies for which you have worked on your resume and when your new employer contacts your old employer(s), the former employer can only confirm or deny the contents of your resume. However, if you list someone at your former company as a reference, you are giving that person permission to give their opinion on your behalf -- for good or ill.
Your former employer may NOT contact your current employer for the purpose of spreading gossip. If you have done anything seriously out of line, they have recourse with the legal system. If their grievance has no legal standing with law enforcement, that's it. They're SOL.
But then again, this is California. I don't know about other states or federal law.
"They built a wickedly fast (albeit nonstandard) JVM way before anyone else could."
Point of order. They licensed code from Symantec for their JVM. If you look at performance comparisons from a few years ago, the Symantec JIT and the MS JIT were almost identical in performance. And until recently, the Java console in IE said as much. MS built a COM wrapper around someone else's wickedly fast JVM.
Java2? Why not? It's just another COM object. Now THAT is something that MS did right. Now Java2 can be integrated in the browser and MS doesn't have to support it. Systems integrators (DELL, Gateway, etc.) could very well include it right out of the box if there is sufficient demand for it.
Number one for me has to be Don Pederson, 6th-7th grade English/reading from Inglewood, CA. I had him for half a day during 6th and for English/reading in 7th.
What does this have to do with Slashdot? Aside from glib comments that many CS/CE graduates can barely spell, this was my first experience with complex structures and organization.
Bear in mind that this is for 11-12 year-olds:
- Poetry examination including the standard fare of onomatopoeia, alliteration and rhyme. Branches out to include the major styles of meter: dactyl, anapest, iambic and trochee. Examples drawn from Shakespeare, Edger Allen Poe (his favorite), Frost, etc.
- Works of literature including _Lord_of_the_Flies_, _The_Crucible_, _The_Martian_Chronicles_, most of the works of Edger Allen Poe (I told you he liked the guy) to name a few.
- English grammar. Yes, that's right, there were some renegade teachers who defied the decree from on high that teachers should not teach grammar. I have a theory that teaching grammar didn't make a significant effect on test scores because most teachers don't know the rules of grammar themselves. Subject-verb-direct object? P'shaw! That was a quick primer on the first day in sixth grade. I'm talking about infinitives, participles, prepositions/prepositional phrases, adverbiable clauses, noun clauses, independant clauses, relative clauses, gerands, etc.
- One of our working textbooks was Strunk & White's _Elements_of_Style_.
Its funny. I want to be a teacher but can't without a degree and credential.:(
Don't let this be relection of this teacher. I rarely did homework -- a source of great consternation to my parents and teachers to be sure.
Back to the subject, I want to be a teacher, but it was not Don Pederson that put that (masochistic?) desire into me. It was the teacher I had in the eigth grade who expected subject-verb-direct object from her students and not much more. I was disgusted! I knew that there was so much more that I had learned in the last two years. There is nothing, in my opinion, that an eleven-year-old can learn that a thirteen-year-old cannot.
I still have my class notes to this day. After him, english classes were just a few more books and writing practice. I had to re-read _Lord_of_the_Flies_ and _The_Martian_Chronicles_ again in high school. Not the worst thing in the world but isn't education supposed to be exposure to a wide variety of material so as to teach a literary roadmap? Just my humble opinion I guess.
Again, what does this have to do with Slashdot? My knowledge of grammar and sentence structure helped my ability with foreign languages (i18n & l10n). I illustrated to me the value of clear and concise writing even in technical documentation for my code. I'm not so willing to skimp on comments. The poetry training specifically helped in translating the abstract into a logical structure. Yes! Poetry taught me how to program!
<SarcasticPost intent="funny">
<Setup>
A default httpd.conf on RedHat 7 is ~40k. If
that grows to two times it's file size because
it's converted to XML, that makes it ~80k.
</Setup>
<Delivery>
80KB!?! Whatever shall we do? It's not like
we can handle that in RAM? Sheesh! That
might even make a dent in modern CPU L2
caches! Oh the horror! We'll drown in excess
info!
</Delivery>
<Reason>
OK. Back to the real world. Lines of data in
httpd.conf will not go up appreciably.
<Listen>80</Listen>
does not take up that much more room than
Listen 80
</Reason>
<Rant>
Quit trying to save that last 2k of space on
stupid details. Computer time and space is
cheap. Developer/Administrator time is
expensive. Oh, I forgot, eveything should
still be written in Assembly because speed and
space are paramount.
</Rant>
<Footnote tone="condescending">
Once again. XML is data. HTML is formatting.
The reason that HTML mail is hard to read is
because you have a gratuitous amount of
formatting information. The tags are no
harder to read than the custom syntax
currently found in config files.
</Footnote>
<SarcasticPost>
People always say, "I don't want all that Mozilla's trying to be. I just want a good web browser." The trouble is, in order to be a good web browser that also works on multiple platforms and is maintainable, you have to do what Mozilla is doing.
Galeon? Great if you're on Linux and have the GTK libraries installed. What about the Mac and Windows and all of the others?
Did anyone here download the original codebase released two years ago? If you had, you would know that it wasn't a simple case of "Let's just edit it so that it handles resizing the window better." There were fundamental flaws in the code. It was spaghetti. A simple fix here caused a new bug there.
They needed to start over and that takes time. They needed a component model so that fixes in one area didn't mess with another and that takes time. They needed to start a cross-language component model even when it was only C++ JavaScript because it can't just be blithely patched on later.
People are already using the rendering engine and that's great! People who just want their browser, can have just their browser. The Mozilla group doesn't want another browser. Mozilla is striving to be another Emacs; greater than the sum of its parts.
Netscape released what Moilla considers v0.6. But isn't that what we've all been preaching for on Slashdot for so long? Haven't we been yelling that they need to finally release a browser? Haven't we said that commercial entities also must follow market schedules to the detriment of engineering schedules? This is a textbook case. Netscape, the commercial entity, releases early to get people to use it like most companies do to avoid being forgotten. Mozilla, an open source entity, is working until it's done.
Mozilla will change the way we write software. It's just taking some people a little longer than others to realize this. It's not about NS vs. IE anymore. It's about making things better. Unfortunately, better takes time. I for one am willing to wait for someone to get it right and not just get it done.
I think you misunderstand the point of SGML and XML. XHTML was not split from XML; it uses XML as a base for ease of parsing. XML is simply organization of data. In the case of XHTML, it is the organization of layout data. The point of XML is to separate the data issues from the business logic from the presentation concerns of publishing information.
Case in point: A <p> tag in HTML is what? It is a paragraph delimiter and it signals to the browser to skip a line. The meaning and the presentation are intimately connected. But what if you don't want your paragraphs to render that way? What if you want to give your paragraphs a distinction from other paragraphs? What if it is not a paragraph at all, but you wanted a blank line (very often the case with HTML)?
XHTML also serves to normalize programmatic manipulation. That previous sentence of gibberish simply means that we can use a standard XHTML-compliant parser instead of reinventing the wheel. It means that we don't have to worry as much about some lame-brain who decided that a <body> tag should go inside of their table cell.
XML is meant to give meaning and structure where HTML could not. After you know how to organize your data, styling it with a conversion (via XSLT) to XHTML or styling it directly with CSS becomes more trivial. But why not start with HTML? Because the XML you have is only data and because that is a separate piece, a new XSLT transformation can occur or a new CSS representation can be substituted with minimal effort.
Separation of concerns also allows for someone to define a structure (schema) for the data so that a common set of stylesheets may be used. For example, in the Cocoon project (http://xml.apache.org/) it is possible to have a single data source (XML), but the output may be presented differently for different web clients, output as plain text or even output as PDF!
Combine this with something like RDF to give further context to the data and you're well on your way to avoiding the search engine hell that we have today. If I do a search for breast cancer, porno should not come up in the search results. If I want porno, I shouldn't get links to breast cancer. HTML and XHTML will never solve this issue on their own.
Is XML -> XSLT -> XHTML more complex and CPU/memory intensive than just using HTML? Yes. Does that mean we should continue to use HTML only? Absolutely not! Tuned assembly language will always be faster than the equivalent JavaScript code. So why don't we code in assembly on our web pages? The answer is that we don't want to worry about pushing onto the stack, firing an interrupt or maintaining the heap allocator when all we want is an alert box. And we want to be able to read, add to and maintain it tomorrow and the next day.
The analogue here is that we don't want to have to update the company logo on hundreds or thousands of web pages every time the company decides that it needs a new logo (don't you love the marketing department?). It means that you can change it on only a handful of stylesheets instead.
CPU time and memory consumption are relatively cheap when compared to time spent by human developers. Every 18 months, computer speed and storage capacity doubles. This is not so with the humans that use them. You do the math.
This is (mostly) not a W3C power-play. This is common sense trying to climb over the dung-heap of data known as the web. C'mon! Who better than a Swiss to get things organized?
P.S. XSLT is not a rendering/formatting mechanism. It is a schema transform mechanism. The fact that most people use it to transform to XHTML is incidental. It can (and is) be used to simply transform from one data-oriented XML document to another.
P.P.S This post was not meant for the 16-year-old updating their dog's picture on his/her "free" 5MB of web space that came with the parents' new DSL line. This is meant for those individuals who work on the web and must maintain hundreds or thousands or millions of pages of press releases, product brochures, support information, employee registries, bug tracking and project schedules. Or in the case of porn, it is meant to separate the blow-jobs from the anal sex.
And just a hop, skip and a jump to the obvious: If language advocacy is bad for the reasons presented in the article, operating system advocacy, CPU advocacy, Open Source advocacy, database advocacy and Linux/BSD distribution advocacy are all just as bad.
Technology historically oppressed more than helped
on
The Renaissance
·
· Score: 2
The Renaissance was the expression of ideas, philosophy and art. The artwork of the Renaissance was generally more vibrant and energetic than what had come before. It also signalled the decline of absolute papal rule with individuals such as Copernicus (even though his life generally sucked after his solar system discoveries went public) challenging the assumptions of the past.
Rapid technological advances signalled the end of the Renaissance and ushered in the Industrial Revolution. The Industrial Revolution, while raising overall production in the world, also served to lower the status of the individual to a cog in the machine. Technology doomed the world to shades of gray for quite some time.
> The closer Linux gets to being more like windows
> the more bloated and unstable it becomes.
Bloated with what exactly? Bloated because it supports more hardware than ever before? Bloated because it supports more platforms that ever before? Bloated because it's faster than ever before? Bloated because it handles more drive space and RAM than ever before?
Or bloated because the codebase has grown due to the above reasons? You might as well call a trilogy bloated because the first book was good.
It's GPLed code. Don't want a lot of the "bloat?" Take it out and compile just what you need. Think that the previous versions of the kernel were better? No one's stopping you from using them. Don't like the rest of the trilogy? Throw away the last two books and simply re-read the first one.
And finally, if the Linux kernel is so bloated, than how did an IBM engineer port it to a wrist watch? Answer: He took what he needed and threw the rest away.
> You know, things like khttpd and that sort of
> thing (I'm sorry, but a Web server is no more an
> integral part of the OS than a Web browser).
On the contrary, a web server has more in common with an NFS server than a web browser.
Let's think about what a web browser does. It opens socket connections, it sends requests/responses, it parses a data stream and transforms that parsed input into a visually pleasing (at least some of them...:)) GUI representation of that data.
Let's think about what a basic web server like khttpd does. I accepts socket connections, sets some variables, looks up local files and passes the file data through the client-initiated connection. Khttpd is unique in that it passes unrecognized requests to user-space (not rocket science).
Let's look at what NFS does. I accepts socket connections, looks up local files, handles file locks to avoid write contention, accepts file data sent to it, and sends file data to the client.
Both NFS and khttpd handle file I/O -- a duty generally attributed to the kernel.
> This is less of an issue in an Open-Source
> kernel than it is in a closed-source one...
#include <soapbox.h>
Open Source != less buggy. Open Source simply makes bugs visible to more people -- ESR's principle that "given enough eyes, all bugs are shallow." It is possible for a closed source alternative to be technically superior to an Open Source model. Haven't most poeple on Slashdot heard of BeOS yet!?
Microsoft did not kill (or heinously wound depending upon your point of view) IBM and Apple. Arrogance did IBM and Apple in. Microsoft was simply there to pick up the baton.
The worst thing that you can do for the Open Source (Free Software, Libre Software, whatever) movement is *assume* that the solution that you prefer is better simply because it is the solution that you prefer. This is the fastest way to become blindsided by the truth.
> However, there's the distinct problem that it
> needs better testing for security issues;
> something of this complexity can't be allowed
> into the kernel until it's rock solid for
> obvious reasons.
Your statement is inflammatory for the following reasons.
1) At this point, there isn't much in the Linux kernel that isn't complex.
2) NOTHING should be allowed into the kernel until it's rock solid for obvious reasons.
3) Comparatively little IS allowed into the stable kernel proper until it's rock solid for obvious reasons.
I say BRAVO! to the authors of this kernel hack. If it turns out to be useful, horray for Linux because it is good. If it turns out to be crippled by design, horray for Linux because they could try.
How many great works throughout history have been squashed or postponed because others said it should not be done?
Then do something about it and stop complaining. What do I mean?
PrintStream out = System.out;
now you only type
out.println(.. );
For those who have forgotten, C++'s "cout" and "cin" are merely iostream shortcuts to stdout. As far as the complaint about "System.out.println()" is concerned, has anyone compared the code necessary to do multithreaded programming, sockets or UI code? Call it slow for use as an applet. Call it constrictive because it doesn't have a template metaphor. Do NOT call it overly verbose because it doesn't have cout.
Which would you rather have: a 2,000-line program in Java or a 20,000-line program in C/C++ so that you can use printf() or cout? I'll take the former thank you.
"Buzzword compliance" has certain advantages in this case: ubiquity.
Right now there are multiple XML parsers in multiple programming languages. Their common standing? They all try to be compliant with W3C specs. For example on Java, you can use the ASF Xerces parser for a while and, assuming you used the W3C java interfaces (publicly available) in your program as you should, you could swap it out for Oracle's XML parser. As long as you maintain standards, you will have support.
XML advantages: hierarchical, normalized, Unicode compliant, simple APIs (DOM and SAX), human readable as much as HTML (ie. basically self-documenting if done correctly). FYI: DOM creates a data structure/tree representation in memory and SAX is a low memory, event-based API.
Now let's look at the alternatives:
Sendmail's config file: Many people understand it. Everything but the kitchen sink (or maybe the kitchen sink is in fact in there and undocumented). Easy to understand? No. Human readable? About as much as a programming language. Universally loved? Only by the sendmail priesthood. Unicode compliant? Umm.. what?
Apache's config file: Many people understand it. Basically a flat model of key value pairs with a second level of depth patched on because of the module and multi-server support. Easy to understand? Yep (especially with comments). Human readable. Yep (especially with comments). Universally loved? Well... much more than sendmail's config file. Unicode compliant? Oops.
Generic key/value pairs: Fast and easy to parse. Flat model -- no hierarchy. Okay, granted you could use could tweak the model to allow hierarchy. Universal key/value delimited file? Not even close. Do you use the '=' as a delimiter? What about ':'? Are comments preceeded by a '#' character or a ';'? Ready to use? Nope; everyone must write their own from scratch much of the time.
People who knock XML have obviously never used it to solve any problems. Go to the W3C site (http://www.w3.org/) and check out all of the projects related to XML that are coming to fruition. All of the projects that follow rules and have publicly created and discussed implementations.
Development tools. Libraries. Easy road to entry. XML has these in abundance. It is the simplest, most complete way to solve the babel on Linux known as/etc.
The only thing preventing a Linux-universal config file format in XML is the unified schema/DTD. That's a non-trivial task, but it's a whole hell of a lot closer than any other technology. And, in fact, universal consensus on the file format is not strictly necessary for a first step. Just by moving to XML alleviates the need for multiple types of parsers in the elusive universal configuration tool. Specifying a separate schema/DTD for each config file still affords a much easier job for the config tool authors.
I do agree with you about inertia. It's hard to change entrenched methods of doing things. However if people were to submit patches that allowed the possibility of XML config files and not unilaterally replacing the exisiting ones so that if people want XML, they can have it. Does this solve the babel problem? No, but once again, it's a viable first step.
./configure --configformat=XML
make all
You use a public parser such as the James Clark "expat" parser. You look up the internal data structure for a particular program. You connect the dots. How hard is that?
Linux/UNIX have always suffered from the babel. It's time for the/etc babelfish.
I see no mention of JavaScri... err... ECMAScript:) support in Amaya. This means no DHTML. This means that Amaya is good for static layout and validation, not for general use. Ah well. More is better. That's the power behind choice.
As long as you didn't try to version your log files (sheesh! wouldn't THAT get ugly) and were to focus all attentions on user and config data (/home and/etc), I would assume that there were innumerable benefits to this even with a speed decrease.
I guess the sticking point would be that copies of the complete files should never be kept; only the difference deltas are important. The most recent file is the "real" file and all previous revisions are converted to diff outputs. For fundamentally different changes, this would be of no benefit. However in the real world, most config files, source files, etc. are usually minor changes which would occupy only a small fraction of the original file size. Slap on a max-revision flag or LRU algorithm when disk space gets tight.
Who knows? Right now this might be a little too slow. Then again, people are looking at 3D user interfaces for the personal computer. Fifteen years ago this would have been laughed out of consideration let alone actually attempted. Now with the advent of Voodoo, TNT, GeForce, et al chipsets this isn't such a crazy idea anymore.
An idea is only a bad idea while it hasn't produced anything useful. As soon as something useful emerges, it ceases to be a bad idea.
Advantages: 45-55 mpg (better in stop-and-go than on the highway). No need to charge the battery because the gas engine does it for you. You can drive from Los Angeles to San Francisco AND BACK on a single tank of gas. (Don't know for outside California but...) Can also drive in the carpool lane even when I'm alone and I get a tax break.
Disadvantages: Small car that can be crushed easily by an SUV. Braking is a little weird; regenerative braking (charging the battery with energy reclaimed from braking) gives an initial tug at speed before "normal" braking behavior kicks in.
Personally the advantages far outweigh the disadvantages for me. Now with that background, answering the question at hand. It would take
1. an end to the stupid war of attrition with regards to vehicle size that we have here in the US. "Oh no! The other guy has a huge SUV and now I don't feel safe. I'd better get a SUV too so that I can make everyone left with a small car really paranoid!"
2. low/zero emmisions vehicles must behave like standard gas-guzzlers; there cannot be anything new-fangled or weird about the way you drive your car (Americans are creatures of habit that way).
3. gas proces need to continue going up so that there is incentive to buy a more efficient vehicle.
That being said, I think pure electric are sunk with regards to the mass market. I don't see them getting the range/size/horsepower of a gas-guzzler anytime in the foreseeable future. That and the fact that there aren't nearly enough charging stations. After all, I can't see people being happy about calling a tow-truck when all they had to do before was walk to the nearest station and fill up a gas can. And with the current maximum range for an electric (abysmal), this becomes a more real possibility.
Curent hybrids on the other hand can take advantage of the existing availability of standard unleaded gasoline. The only improvement I can see here is replacement of gasoline with a feul cell to cut emmisions.
Slashdot Mirror
Ummm... Point of order. The W3C doesn't have any such method. The reason your code is failing is because the method name is
getElementById()
Note the capitalization. You'll note that suddenly things will start working...
> I have 18 years experience coding in C.
Probably explains why you think that Mozilla is poorly designed... I have nothing against C. I code in C as well. However your comment strikes me as being entirely too similar to other comments I've heard from pure C programmers. C is just a tool like a hammer. However if it the only tool with which you have practical experience, you will see the world as a nail. There is no direct analogy between some computer languages for exactly the same reason that their is no direct translation between different human languages (precisely why interpreting between languages is so difficult a job). C code does not directly translate to component-based C++ which does not directly translate to Java.
Mozilla is C++, JavaScript and XPCOM with only a light sprinkling of C. As such they are approaching the problem correctly: attacking the interfaces and leaving the implementation optimizations until last. This is what they have done. Read the roadmap. They have stated that optimization has only started recently. They were completing the interfaces and the base implementation before optimizing.
> It would take me perhaps a few months to
> achieve the knowledge that the existing
> developers have in the project. That would be a
> waste of time because I am not a part of that
> team, and have no intentions to ever be. My time
> is best spent elsewhere.
Yes it would. It is an investment of time. IF you are not willing to invest that time, so be it. It is your decision. But do not then criticize others because they do not share your priorities.
You say that you have worked on long-term projects (libraries and kernel). And yet you have never come upon the bug that keeps getting set aside because there are more important things to a lot of people. Mozilla's bugzilla has a "most requested bug fix." This and its ilk are attacked first. It doesn't look like your pet bug are most requested by the others that use Mozilla.
Unfortunately, the Mozilla project hasn't garnered the attention that the Linux kernel has gathered. As such, it doesn't have the same amount of driving force behind it (people). And yet some filesystems have rotted and died. Some devices have fallen by the wayside. Is this because no one uses them or bemoans their loss. No. A small enough percentage stopped using them and no one with sufficient coding experience to maintain them stepped forward to claim them.
> I will suggest to you that the organization of
> Mozilla falls somewhere between messed up and
> fubarred. Now that's just my opinion based on
> looking at several pieces of the code. And I do
> think that's a major reason why Mozilla has been
> so late, runs so slow, and is riddled with bugs.
> IMHO, their whole development approach is wrong.
A component-based, language-neutral approach is wrong? No I don't think that C is obsolete and I am not suggesting it. You are basing your opinion on your past experience. I am basing mine on my past experience when actually writing/using/maintaining many disparate options (C vs. Objects vs. Components). It is obvious that we will not agree anytime soon. However I would suggest that you (re)read Design Patterns.
> The often-replied statement "submit a patch"
> is what I'm complaining about.
Really? And here I thought this was one of free software's hallmarks. I have researched the problem. I now how difficult it is. I have every right to post this. If so many people weren't resting their hopes on Mozilla, no one would care that they are taking this long or using this approach (which would have put them in the same category as 99% of all free software projects).
No, I have not been programming C as long as you have. I would have had to start when I was eight years old and my parents weren't programmers. I'm am not doubting your abilities as a C coder. I fully acknowledge that if put in a room alone, you would be able to produce better kernel code than I. I am however questioning your judgement with regards to languages other than C and your take on your pet bug not being fixed.
If a bug crashes the browser or causes it to suck up ten more megs of RAM, I sure as hell want them to ignore your bug! Let me put this to you "for the sake of informing others." Do you think a project's priority should be on making sure the browser works on multiple platforms at all or that they should take time out to make sure that someone can dictate the size of the browser on startup from the command line?
If you answer the latter, I simply agree to disagree.
marginheight and marginwidth and the W3C is doing nothing about it? Have you been asleep? This is one of the areas where CSS solves the problem. Rather than getting into the whole pissing contest about which attribute is preferred, they moved this styling concern into *shudder* the CSS styling spec.
/>
body { margin: 0px; }
That's it. That's the solution. You put that into an external stylesheet and you have an entire site that does the same thing -- something that HTML cannot do on its own. And you know what? It conforms to W3C validation. What's the holdup? NS 4.x and the other CSS-ignorant clients.
Width of text fields? We're screwed... Oh wait! THAT'S RIGHT! It's already solved in CSS.
input.wide { width: 60px; }
- with -
<input type="text" class="wide"
FYI: IE's text fields are smaller by default than Netscape's.
W3C should clean up the HTML standard? That's what they've been doing! That's precisely what XHTML Strict is intended to do. What else can they do? Rewrite HTML specs so that they work in all browsers? Impossible! Browser incompatibilities are the cause of the problem, not the HTML. The fact that they render different than the spec specifies is not the fault of the spec. What else can the spec do? Recode the browser at runtime?
The W3C wasn't responsible for the old standards, is actively working to solve problems with the new standards, and trying to reduce the amount of ambiguity in the web. This will not be done with HTML alone. Take a look at the work being done at www.w3.org because you've obviously never spent any time there.
It's an open development, if the bug's that important to you, submit a patch. Don't know how to code? It's been years since Mozilla opened the code. You've had time to learn. Or did you simply want to benefit from the community without giving something back?
Take a class on C++ and dig in. No one's stopping you. The sooner you start after that bug, the sooner it will be fixed. Isn't this the free source creedo?
The Mozilla Organization discussed over a year ago that they would not support NS 4.x code. Why? Simply because NS 4.x is an abberation in browser history. If they worked on getting the tag to work in Mozilla/NS6, it means that work on CSS, DOM, XML et al would suffer. And to what end? So that developers would be more willing to write tags? NS 4.x is crap. It was crap when it was released. It is certainly crap years later. Quoting Linux kernel config -- "Let's kill this beast now."
It's better to let some things die... Netscape 4.x however could use some help putting a bullet in its head.
No reference implementation? Damn! I guess I was hallucinating when I've seen the Amaya browser touted on the W3C site *for years*.
Standards are a scam? Well then I'm sure that you're angry that there is a standard C, a standard C++, standard peripheral connectors (PCI, USB, etc.), and on and on. Or do you pine for the days when game manufacturers had to write specific support for each sound card. Why was JavaScript taken on by ECMA? Because they wanted to make a common ground so that people wouldn't have to make a JavaScript version and a JScript version of the same damned logic.
Get a clue folks! 99% of the people surfing the web today DON'T use a text-only browser. I don't dispute the greatness of Lynx. I use it occassionally on my server. But we are not necessarily the target audience for disney.com. Case in point, if your company is a graphics arts shop, why in the hell would you code for Lynx?
Your "defacto standards" are bunk! 0.5% of all sites on the web would work in that environment. How is that a defacto standard? Major browsers have supported Java since Netscape broke the ice in 2.0. How is this a major issue?
Do you seriously believe that substance will win over style? Can someone point out a case where this has happened on a medium-to-large scale *ever*? If your ideals for the web were ever followed, the web would not have ever existed. You have just described gopher! The fact that the web is so popular and gopher is effectively dead is proof positive that your suppositions are emphatically wrong.
If you want to use Lynx, go right ahead. I'm not stopping you, but stop whining because others don't want to cater to your personal whims. If enough people want Lynx-compliant pages, more people wil code Lynx-compliant pages. If people aren't coding Lynx-compliant pages, it means that Lynx users are a gross minority. Being in the minority is not a bad thing. But it entails that most things will not be catered to you.
Then you of all people should be happy about the new browsers' abilities with XML. Pure content - no layout. Isn't that what you're asking for? Can older browsers handle it? No? I guess we need the newer browsers then...
KISS? Maintaining 8 different versions of HTML for each page of content is keeping it simple? Keeping web technology stuck at the level of 1996 forever is preferred? Give me a break! This sounds like folks saying that they don't understand why we need graphics for games. Yes, "Adventure" was a great game, but Quake III is never going to work properly on a Mac Classic.
Tunnel vision? Progress never occurs if you stick with the solutions of the past. Should we ditch older ways because they are older? Of course not. You're right in that many pages abuse the new specs for their gee-whiz factor. On the other hand, Netscape 4.x is NOT something to hold dear and precious. Lynx at least has a specific purpose and niche (text-only display). Netscape 4.x only serves to slow the world down.
As soon as people stop seeing NS and IE as web browsers and start seeing them as web application platforms, DHTML and CSS stop being the enemy and start to get real problems solved. There is more to DHTML than image rollovers.
Apples and oranges. SVG is a markup language for vector graphics. Flash is a renderer. Just like HTML, the markup is useless unless you have a rendering engine (browser).
Not quite true. In the case of employment, a former employer is very limited in their available contact with the new employer. When you put down the list of companies for which you have worked on your resume and when your new employer contacts your old employer(s), the former employer can only confirm or deny the contents of your resume. However, if you list someone at your former company as a reference, you are giving that person permission to give their opinion on your behalf -- for good or ill.
Your former employer may NOT contact your current employer for the purpose of spreading gossip. If you have done anything seriously out of line, they have recourse with the legal system. If their grievance has no legal standing with law enforcement, that's it. They're SOL.
But then again, this is California. I don't know about other states or federal law.
Yes, I visit microsoft.com through their developers' library. Useful even you're not developing for a MS-based OS.
"They built a wickedly fast (albeit nonstandard) JVM way before anyone else could."
Point of order. They licensed code from Symantec for their JVM. If you look at performance comparisons from a few years ago, the Symantec JIT and the MS JIT were almost identical in performance. And until recently, the Java console in IE said as much. MS built a COM wrapper around someone else's wickedly fast JVM.
Java2? Why not? It's just another COM object. Now THAT is something that MS did right. Now Java2 can be integrated in the browser and MS doesn't have to support it. Systems integrators (DELL, Gateway, etc.) could very well include it right out of the box if there is sufficient demand for it.
Number one for me has to be Don Pederson, 6th-7th grade English/reading from Inglewood, CA. I had him for half a day during 6th and for English/reading in 7th.
:(
What does this have to do with Slashdot? Aside from glib comments that many CS/CE graduates can barely spell, this was my first experience with complex structures and organization.
Bear in mind that this is for 11-12 year-olds:
- Poetry examination including the standard fare of onomatopoeia, alliteration and rhyme. Branches out to include the major styles of meter: dactyl, anapest, iambic and trochee. Examples drawn from Shakespeare, Edger Allen Poe (his favorite), Frost, etc.
- Works of literature including _Lord_of_the_Flies_, _The_Crucible_, _The_Martian_Chronicles_, most of the works of Edger Allen Poe (I told you he liked the guy) to name a few.
- English grammar. Yes, that's right, there were some renegade teachers who defied the decree from on high that teachers should not teach grammar. I have a theory that teaching grammar didn't make a significant effect on test scores because most teachers don't know the rules of grammar themselves. Subject-verb-direct object? P'shaw! That was a quick primer on the first day in sixth grade. I'm talking about infinitives, participles, prepositions/prepositional phrases, adverbiable clauses, noun clauses, independant clauses, relative clauses, gerands, etc.
- One of our working textbooks was Strunk & White's _Elements_of_Style_.
Its funny. I want to be a teacher but can't without a degree and credential.
Don't let this be relection of this teacher. I rarely did homework -- a source of great consternation to my parents and teachers to be sure.
Back to the subject, I want to be a teacher, but it was not Don Pederson that put that (masochistic?) desire into me. It was the teacher I had in the eigth grade who expected subject-verb-direct object from her students and not much more. I was disgusted! I knew that there was so much more that I had learned in the last two years. There is nothing, in my opinion, that an eleven-year-old can learn that a thirteen-year-old cannot.
I still have my class notes to this day. After him, english classes were just a few more books and writing practice. I had to re-read _Lord_of_the_Flies_ and _The_Martian_Chronicles_ again in high school. Not the worst thing in the world but isn't education supposed to be exposure to a wide variety of material so as to teach a literary roadmap? Just my humble opinion I guess.
Again, what does this have to do with Slashdot? My knowledge of grammar and sentence structure helped my ability with foreign languages (i18n & l10n). I illustrated to me the value of clear and concise writing even in technical documentation for my code. I'm not so willing to skimp on comments. The poetry training specifically helped in translating the abstract into a logical structure. Yes! Poetry taught me how to program!
Much props to you Mr. P.
<SarcasticPost intent="funny">
<Setup>
A default httpd.conf on RedHat 7 is ~40k. If
that grows to two times it's file size because
it's converted to XML, that makes it ~80k.
</Setup>
<Delivery>
80KB!?! Whatever shall we do? It's not like
we can handle that in RAM? Sheesh! That
might even make a dent in modern CPU L2
caches! Oh the horror! We'll drown in excess
info!
</Delivery>
<Reason>
OK. Back to the real world. Lines of data in
httpd.conf will not go up appreciably.
<Listen>80</Listen>
does not take up that much more room than
Listen 80
</Reason>
<Rant>
Quit trying to save that last 2k of space on
stupid details. Computer time and space is
cheap. Developer/Administrator time is
expensive. Oh, I forgot, eveything should
still be written in Assembly because speed and
space are paramount.
</Rant>
<Footnote tone="condescending">
Once again. XML is data. HTML is formatting.
The reason that HTML mail is hard to read is
because you have a gratuitous amount of
formatting information. The tags are no
harder to read than the custom syntax
currently found in config files.
</Footnote>
<SarcasticPost>
People always say, "I don't want all that Mozilla's trying to be. I just want a good web browser." The trouble is, in order to be a good web browser that also works on multiple platforms and is maintainable, you have to do what Mozilla is doing.
Galeon? Great if you're on Linux and have the GTK libraries installed. What about the Mac and Windows and all of the others?
Did anyone here download the original codebase released two years ago? If you had, you would know that it wasn't a simple case of "Let's just edit it so that it handles resizing the window better." There were fundamental flaws in the code. It was spaghetti. A simple fix here caused a new bug there.
They needed to start over and that takes time. They needed a component model so that fixes in one area didn't mess with another and that takes time. They needed to start a cross-language component model even when it was only C++ JavaScript because it can't just be blithely patched on later.
People are already using the rendering engine and that's great! People who just want their browser, can have just their browser. The Mozilla group doesn't want another browser. Mozilla is striving to be another Emacs; greater than the sum of its parts.
Netscape released what Moilla considers v0.6. But isn't that what we've all been preaching for on Slashdot for so long? Haven't we been yelling that they need to finally release a browser? Haven't we said that commercial entities also must follow market schedules to the detriment of engineering schedules? This is a textbook case. Netscape, the commercial entity, releases early to get people to use it like most companies do to avoid being forgotten. Mozilla, an open source entity, is working until it's done.
Mozilla will change the way we write software. It's just taking some people a little longer than others to realize this. It's not about NS vs. IE anymore. It's about making things better. Unfortunately, better takes time. I for one am willing to wait for someone to get it right and not just get it done.
I think you misunderstand the point of SGML and XML. XHTML was not split from XML; it uses XML as a base for ease of parsing. XML is simply organization of data. In the case of XHTML, it is the organization of layout data. The point of XML is to separate the data issues from the business logic from the presentation concerns of publishing information.
Case in point: A <p> tag in HTML is what? It is a paragraph delimiter and it signals to the browser to skip a line. The meaning and the presentation are intimately connected. But what if you don't want your paragraphs to render that way? What if you want to give your paragraphs a distinction from other paragraphs? What if it is not a paragraph at all, but you wanted a blank line (very often the case with HTML)?
XHTML also serves to normalize programmatic manipulation. That previous sentence of gibberish simply means that we can use a standard XHTML-compliant parser instead of reinventing the wheel. It means that we don't have to worry as much about some lame-brain who decided that a <body> tag should go inside of their table cell.
XML is meant to give meaning and structure where HTML could not. After you know how to organize your data, styling it with a conversion (via XSLT) to XHTML or styling it directly with CSS becomes more trivial. But why not start with HTML? Because the XML you have is only data and because that is a separate piece, a new XSLT transformation can occur or a new CSS representation can be substituted with minimal effort.
Separation of concerns also allows for someone to define a structure (schema) for the data so that a common set of stylesheets may be used. For example, in the Cocoon project (http://xml.apache.org/) it is possible to have a single data source (XML), but the output may be presented differently for different web clients, output as plain text or even output as PDF!
Combine this with something like RDF to give further context to the data and you're well on your way to avoiding the search engine hell that we have today. If I do a search for breast cancer, porno should not come up in the search results. If I want porno, I shouldn't get links to breast cancer. HTML and XHTML will never solve this issue on their own.
Is XML -> XSLT -> XHTML more complex and CPU/memory intensive than just using HTML? Yes. Does that mean we should continue to use HTML only? Absolutely not! Tuned assembly language will always be faster than the equivalent JavaScript code. So why don't we code in assembly on our web pages? The answer is that we don't want to worry about pushing onto the stack, firing an interrupt or maintaining the heap allocator when all we want is an alert box. And we want to be able to read, add to and maintain it tomorrow and the next day.
The analogue here is that we don't want to have to update the company logo on hundreds or thousands of web pages every time the company decides that it needs a new logo (don't you love the marketing department?). It means that you can change it on only a handful of stylesheets instead.
CPU time and memory consumption are relatively cheap when compared to time spent by human developers. Every 18 months, computer speed and storage capacity doubles. This is not so with the humans that use them. You do the math.
This is (mostly) not a W3C power-play. This is common sense trying to climb over the dung-heap of data known as the web. C'mon! Who better than a Swiss to get things organized?
P.S. XSLT is not a rendering/formatting mechanism. It is a schema transform mechanism. The fact that most people use it to transform to XHTML is incidental. It can (and is) be used to simply transform from one data-oriented XML document to another.
P.P.S This post was not meant for the 16-year-old updating their dog's picture on his/her "free" 5MB of web space that came with the parents' new DSL line. This is meant for those individuals who work on the web and must maintain hundreds or thousands or millions of pages of press releases, product brochures, support information, employee registries, bug tracking and project schedules. Or in the case of porn, it is meant to separate the blow-jobs from the anal sex.
And just a hop, skip and a jump to the obvious: If language advocacy is bad for the reasons presented in the article, operating system advocacy, CPU advocacy, Open Source advocacy, database advocacy and Linux/BSD distribution advocacy are all just as bad.
The Renaissance was the expression of ideas, philosophy and art. The artwork of the Renaissance was generally more vibrant and energetic than what had come before. It also signalled the decline of absolute papal rule with individuals such as Copernicus (even though his life generally sucked after his solar system discoveries went public) challenging the assumptions of the past.
Rapid technological advances signalled the end of the Renaissance and ushered in the Industrial Revolution. The Industrial Revolution, while raising overall production in the world, also served to lower the status of the individual to a cog in the machine. Technology doomed the world to shades of gray for quite some time.
> The closer Linux gets to being more like windows
> the more bloated and unstable it becomes.
Bloated with what exactly? Bloated because it supports more hardware than ever before? Bloated because it supports more platforms that ever before? Bloated because it's faster than ever before? Bloated because it handles more drive space and RAM than ever before?
Or bloated because the codebase has grown due to the above reasons? You might as well call a trilogy bloated because the first book was good.
It's GPLed code. Don't want a lot of the "bloat?" Take it out and compile just what you need. Think that the previous versions of the kernel were better? No one's stopping you from using them. Don't like the rest of the trilogy? Throw away the last two books and simply re-read the first one.
And finally, if the Linux kernel is so bloated, than how did an IBM engineer port it to a wrist watch? Answer: He took what he needed and threw the rest away.
> You know, things like khttpd and that sort of
:)) GUI representation of that data.
> thing (I'm sorry, but a Web server is no more an
> integral part of the OS than a Web browser).
On the contrary, a web server has more in common with an NFS server than a web browser.
Let's think about what a web browser does. It opens socket connections, it sends requests/responses, it parses a data stream and transforms that parsed input into a visually pleasing (at least some of them...
Let's think about what a basic web server like khttpd does. I accepts socket connections, sets some variables, looks up local files and passes the file data through the client-initiated connection. Khttpd is unique in that it passes unrecognized requests to user-space (not rocket science).
Let's look at what NFS does. I accepts socket connections, looks up local files, handles file locks to avoid write contention, accepts file data sent to it, and sends file data to the client.
Both NFS and khttpd handle file I/O -- a duty generally attributed to the kernel.
> This is less of an issue in an Open-Source
> kernel than it is in a closed-source one...
#include <soapbox.h>
Open Source != less buggy. Open Source simply makes bugs visible to more people -- ESR's principle that "given enough eyes, all bugs are shallow." It is possible for a closed source alternative to be technically superior to an Open Source model. Haven't most poeple on Slashdot heard of BeOS yet!?
Microsoft did not kill (or heinously wound depending upon your point of view) IBM and Apple. Arrogance did IBM and Apple in. Microsoft was simply there to pick up the baton.
The worst thing that you can do for the Open Source (Free Software, Libre Software, whatever) movement is *assume* that the solution that you prefer is better simply because it is the solution that you prefer. This is the fastest way to become blindsided by the truth.
> However, there's the distinct problem that it
> needs better testing for security issues;
> something of this complexity can't be allowed
> into the kernel until it's rock solid for
> obvious reasons.
Your statement is inflammatory for the following reasons.
1) At this point, there isn't much in the Linux kernel that isn't complex.
2) NOTHING should be allowed into the kernel until it's rock solid for obvious reasons.
3) Comparatively little IS allowed into the stable kernel proper until it's rock solid for obvious reasons.
I say BRAVO! to the authors of this kernel hack. If it turns out to be useful, horray for Linux because it is good. If it turns out to be crippled by design, horray for Linux because they could try.
How many great works throughout history have been squashed or postponed because others said it should not be done?
Then do something about it and stop complaining. What do I mean?
.. );
PrintStream out = System.out;
now you only type
out.println(
For those who have forgotten, C++'s "cout" and "cin" are merely iostream shortcuts to stdout. As far as the complaint about "System.out.println()" is concerned, has anyone compared the code necessary to do multithreaded programming, sockets or UI code? Call it slow for use as an applet. Call it constrictive because it doesn't have a template metaphor. Do NOT call it overly verbose because it doesn't have cout.
Which would you rather have: a 2,000-line program in Java or a 20,000-line program in C/C++ so that you can use printf() or cout? I'll take the former thank you.
"Buzzword compliance" has certain advantages in this case: ubiquity.
/etc.
/etc babelfish.
Right now there are multiple XML parsers in multiple programming languages. Their common standing? They all try to be compliant with W3C specs. For example on Java, you can use the ASF Xerces parser for a while and, assuming you used the W3C java interfaces (publicly available) in your program as you should, you could swap it out for Oracle's XML parser. As long as you maintain standards, you will have support.
XML advantages: hierarchical, normalized, Unicode compliant, simple APIs (DOM and SAX), human readable as much as HTML (ie. basically self-documenting if done correctly). FYI: DOM creates a data structure/tree representation in memory and SAX is a low memory, event-based API.
Now let's look at the alternatives:
Sendmail's config file: Many people understand it. Everything but the kitchen sink (or maybe the kitchen sink is in fact in there and undocumented). Easy to understand? No. Human readable? About as much as a programming language. Universally loved? Only by the sendmail priesthood. Unicode compliant? Umm.. what?
Apache's config file: Many people understand it. Basically a flat model of key value pairs with a second level of depth patched on because of the module and multi-server support. Easy to understand? Yep (especially with comments). Human readable. Yep (especially with comments). Universally loved? Well... much more than sendmail's config file. Unicode compliant? Oops.
Generic key/value pairs: Fast and easy to parse. Flat model -- no hierarchy. Okay, granted you could use could tweak the model to allow hierarchy. Universal key/value delimited file? Not even close. Do you use the '=' as a delimiter? What about ':'? Are comments preceeded by a '#' character or a ';'? Ready to use? Nope; everyone must write their own from scratch much of the time.
People who knock XML have obviously never used it to solve any problems. Go to the W3C site (http://www.w3.org/) and check out all of the projects related to XML that are coming to fruition. All of the projects that follow rules and have publicly created and discussed implementations.
Development tools. Libraries. Easy road to entry. XML has these in abundance. It is the simplest, most complete way to solve the babel on Linux known as
The only thing preventing a Linux-universal config file format in XML is the unified schema/DTD. That's a non-trivial task, but it's a whole hell of a lot closer than any other technology. And, in fact, universal consensus on the file format is not strictly necessary for a first step. Just by moving to XML alleviates the need for multiple types of parsers in the elusive universal configuration tool. Specifying a separate schema/DTD for each config file still affords a much easier job for the config tool authors.
I do agree with you about inertia. It's hard to change entrenched methods of doing things. However if people were to submit patches that allowed the possibility of XML config files and not unilaterally replacing the exisiting ones so that if people want XML, they can have it. Does this solve the babel problem? No, but once again, it's a viable first step.
./configure --configformat=XML
make all
You use a public parser such as the James Clark "expat" parser. You look up the internal data structure for a particular program. You connect the dots. How hard is that?
Linux/UNIX have always suffered from the babel. It's time for the
I see no mention of JavaScri... err... ECMAScript :) support in Amaya. This means no DHTML. This means that Amaya is good for static layout and validation, not for general use. Ah well. More is better. That's the power behind choice.
BTW: Posted with Mozilla M18.
As long as you didn't try to version your log files (sheesh! wouldn't THAT get ugly) and were to focus all attentions on user and config data (/home and /etc), I would assume that there were innumerable benefits to this even with a speed decrease.
I guess the sticking point would be that copies of the complete files should never be kept; only the difference deltas are important. The most recent file is the "real" file and all previous revisions are converted to diff outputs. For fundamentally different changes, this would be of no benefit. However in the real world, most config files, source files, etc. are usually minor changes which would occupy only a small fraction of the original file size. Slap on a max-revision flag or LRU algorithm when disk space gets tight.
Who knows? Right now this might be a little too slow. Then again, people are looking at 3D user interfaces for the personal computer. Fifteen years ago this would have been laughed out of consideration let alone actually attempted. Now with the advent of Voodoo, TNT, GeForce, et al chipsets this isn't such a crazy idea anymore.
An idea is only a bad idea while it hasn't produced anything useful. As soon as something useful emerges, it ceases to be a bad idea.
Just a thought...
Right now I have the Toyota Prius on order.
Advantages: 45-55 mpg (better in stop-and-go than on the highway). No need to charge the battery because the gas engine does it for you. You can drive from Los Angeles to San Francisco AND BACK on a single tank of gas. (Don't know for outside California but...) Can also drive in the carpool lane even when I'm alone and I get a tax break.
Disadvantages: Small car that can be crushed easily by an SUV. Braking is a little weird; regenerative braking (charging the battery with energy reclaimed from braking) gives an initial tug at speed before "normal" braking behavior kicks in.
Personally the advantages far outweigh the disadvantages for me. Now with that background, answering the question at hand. It would take
1. an end to the stupid war of attrition with regards to vehicle size that we have here in the US. "Oh no! The other guy has a huge SUV and now I don't feel safe. I'd better get a SUV too so that I can make everyone left with a small car really paranoid!"
2. low/zero emmisions vehicles must behave like standard gas-guzzlers; there cannot be anything new-fangled or weird about the way you drive your car (Americans are creatures of habit that way).
3. gas proces need to continue going up so that there is incentive to buy a more efficient vehicle.
That being said, I think pure electric are sunk with regards to the mass market. I don't see them getting the range/size/horsepower of a gas-guzzler anytime in the foreseeable future. That and the fact that there aren't nearly enough charging stations. After all, I can't see people being happy about calling a tow-truck when all they had to do before was walk to the nearest station and fill up a gas can. And with the current maximum range for an electric (abysmal), this becomes a more real possibility.
Curent hybrids on the other hand can take advantage of the existing availability of standard unleaded gasoline. The only improvement I can see here is replacement of gasoline with a feul cell to cut emmisions.