For a simple thing to configure, yes that probably works. So much for using a simple example. Choose a complex one where nested contexts are needed. Does XML let you nest within a tag? I've never seen it done. Add some routing information and firewall rules to the ethernet device and see how it looks in XML and HSI.
This is an example of why every GUI tool must have a lean text version of itself (not as a monster executeable that can do everything), so it can fit and run from the rescue disk, without X, without SVGAlib.
I would not want text/document/markup experts telling me how to do everything else in the world with their tools. No one is an expert at everything. You might find some who know how to administer a system, but in general that isn't an expected skill. I don't profess to be a text/document/markup expert at all, so I would not presume to tell them how best to solve problems in that area. In fact, I find the solutions that are coming out for that purpos are working quite well. But success there doesn't mean it can be applied everywhere else.
The example I gave showed a simple configuration in both one possible XML format and one possible HSI format. Just because it was a simple example does not imply that either format is limited to only simple cases. You seem to be implying that while XML is not so limited, that HSI is. This is absolutely not true.
The day that effective tools allow me to abandon any use of a text editor under every context, then I won't care what format the file is in. But as long as GUI based tools fail to allow every possible configuration the way I want it, then I need to stick with the tool (my swiss army knife which consists of both vi and emacs) that does let me do what I need to do to make things work. And I therefore need to stick with a reasonable file format that is oriented to human editing.
Fix the GUI interfaces and logic, first, then come back and redesign the underlying system files.
Given the quality of GUI tools we have now, that day appears to still be a long ways away. If it is the case that XML is what will make the GUI tools work, where they are failing to work now, then maybe XML is worth considering (but I see no XML porponent suggesting that XML is what will fix all the GUI tools).
GUI tools need to be able to handle every possible state of configuration for them to be able to be used. They also have to work in every context. For example, if I have the system drive from another machine attached as a 2nd drive on my current machine, every GUI tool MUST (no exceptions allowed upon penalty of death) be able to operate on the attached system drive. For GUI to be effective, it must operate anywhere and everywhere a text editor does, and that include in text console single user mode (X and SVGAlib are not available).
I've heard that before about languages forcing discipline. I then look at C++ and all the masses of undisciplined programmers out there that think they are good at object oriented design because they use C++. I then ROFLMAO.
XML does have its advantages. It sells bigger disk drives. It sells more bandwidth. But that was probably going to happen anyway. It can be useful for database transfers and such, though probably no more or less so than some other things that have been proposed.
What XML already does seem to be great in is tagging extractable data from document oriented storage. With XML, you can mix information and presentation together. Non-conflicting DTDs (that will be interesting to see) can be merged. You can, for example, add tags that pinpoint data and data types in an HTML document, provided that the DTD used for those tags has not conflict with HTML (not at all hard to do if you make sure this was a spec/goal in the first place).
Like I replied above, httpd.conf is not XML, and only barely has a hint of XML. It has contexts like XML, but the directives are somewhere between command and ini style. That little touch of XML-ishness isn't causing any problem (though the ever changing semantics of does tend to be annoying). If XML is carried to the extreme, where every piece of data is expressed with XML tags, then it becomes hard to read. If the XML tools all "did the right thing" (which is doubtful for a few to many years yet) then you would never see the XML-ishness at all. But until that day, I will not design any system that reads XML for configuration state.
For other things like bulk data transfers between databases, where the data is generated by program, and parsed by program, and no human needs to even read it, then XML won't really cause too much of a problem (disk drives are bigger these days so XML's inefficiency in storage is probably not much of an issue, now, either).
I'm not opposed to making things better. And I'll even say that GUI has the potential to definitely be better than text editor is now. However, I have not yet seen any GUI config tool that is better. I've used tools from Redhat, SuSE, Solaris, SCO, and they all leave me wanting to go back to editing (and even vi would be better despite my preference for emacs which isn't always available).
Until such time as GUI interfaces can be devised that can handle every... and let me stress that... EVERY... possible configuration state, the configuration needs to remain where it can be edited as text, by a real human. I rarely have time to figure out why some GUI tool won't let me do what I want to do. Most seem to be intent on narrowing the scope of what can be done.
I'm designing scripts now to automate system configurations. The scripts get data from a central (not on the same machine) database which describes what services are to be performed and assignments of which machine is to perform them. They will then construct the config files (such as Apache httpd.conf for web sites to be served) to conform. GUI tools would only get in the way unless they are the ones used to update the database over on the central server.
If you are going to start again from scratch and define new syntax for UN*X configuration files, and you choose to use anything other than XML, you really are going to need to have a very good reason for doing so.
How about having a good reason for XML? I have seen some good reasons for XML, but those very same reasons apply to other proposals, as well.
And LISP SEXPR isn't the only other option (though I do like it better than XML).
Everything you've described as a feature of XML is a feature of the alternative I've proposed, and appears to be features of many of the other proposals, as well.
What I find that XML does NOT have is "non-clutterness".
XML may have some cool features, and be useful for embedding information descriptors and tags in documents, but for building config files, it's hard to read and basically sucks.
Basically, what is essential here is that we all agree on what kind of slot to use between the screwdriver and the screws. Then we can use a hand turned screwdriver or a motor driven screwdriver. And we can use self-tapping screws, or machine screws, or whatever we like.
If the configuration state is stored in a file with a document that makes the file format open, then you can use fancy GUI tools, or vi, or a script, to manage the configuration. This is what we need to require... pluggable tools.
And that is IMHBWSO an unconstitutional aspect of the DCMA. Mere accusation alone should never have the force of law to shut someone down. Even judges want to see some kind of evidence of at least a possible successful judgement to issue a temorary order. If I get a letter like that asking me to shut down one of my customers, what I will do with it, since I am not a lawyer, is first have my lawyer check its validity. Let them eat my bureaucracy.
When you view the total solar eclipse of the sun by the earth from the moon, you have one factor that you don't have the other way around. That is the earth's atmosphere. You'll get to see a big red ring that is basically the same effect as a sunset. This is where the moon gets that reddish color.
An ISP that triggers limits like that on an automatic basis so quickly is not one that ANYONE should use at ANY price range. Any decent ISP (and there are way too few of them) would recognize a spike and just ride it out for at least a day, with a review to be done by a human. Checks should be made to make sure they aren't posting the newest Redhat ISO image or something like that. Sure, if they buy the low level of service, then they shouldn't be expected to sustain a continuous 10000/hr rate (as being slashdotted could potentially do for a day or so for the most popular sites). But it doesn't help the ISP any to give 500 when slashdotted.
If Hedy Lamarr, or anyone else, had patented something as simple as spread spectrum today, it would be a joke patent, much like so many others. In the 1940's, however, it was a marvelous new idea that should have been used more than it was.
If no one else can figure out how to solve a real problem, then one person figures out a solution, that's a real patentable idea. Sometimes it's hard to tell if it's a solution seeking a problem. But stupidly obvious stuff like saving your credit card info in a server indexed by username or cookie, is not worthy of a patent (even if some.COM wasted 999 man*hours implementing it).
If Hedy Lamarr had been in her prime at the launch of the Internet, she probably would have been a great contributor.
It was obvious from the title what this was about. I happened to be particularly interested because I was in a discussion just yesterday about her invention of spread spectrum.
Start by getting capital financing. You don't need millions on day 1, but you do need to put together a good business executive team consisting of at minimum, a good finance/accounting/tax expert who can line up the initial and following funding, a good marketing/sales/leadership expert who can make your business known and bring in customers, and of course a good technical/networking/server expert who can put all this together and make it work solidly, securely, and reliably. A good tech support department is also essential. And don't forget a solid business plan.
Given your question, I take it you aren't the technical expert so you wouldn't be CTO. Are you a finance guy? A marketing guy? A sidelines investor? Or someone to answer the phones?
Unlimited bandwidth is just a marketing ploy. As you point out, once you start chugging gigs, things start to change.
I'd have more trust in a web hoster that charged by usage. And I don't mean a sudden kick to the next pricing tier once you pull 1.000001 gig. I mean basic smooth (probably linear) rate per meg. That's the only way I'd do it. I wouldn't want to have to be in the position of kicking someone out because they chug gigs, if they could pay appropriately for it. I wouldn't be in the business to be giving it away.
How many good technical people are out their in Slashdot reader land who could put together a solid and reliable web hosting, colocation, and/or internet access facility, IFF you could just find the right financing and marketing partners to make that end of the business (such as getting enough starting capital and new clients to make it fly), and make it absolutely rock?
I would bet there are quite a few of us.
Now ask the same question from the perspective of the finance guys or the marketing guys who might be looking for techies? Would there be people in that group who would feel they are the best at what they do and are looking for the best techies to be partners with?
Every poorly performing business I have seen seems to have problems in almost every area. But the biggest problems seem to be in committing the resources to the facilities sufficiently to avoid the kinds of problems that make customers leave. Sticking a T3 into a Cisco router and attaching a couple servers just doesn't cut it. And there are some hosters which aren't much more than that.
Finance and Marketing types should hang around/. and pick up some techie partners that know what they are doing.
Where can we download a Jesse Kovach CA root certificate? You do support all browsers, right?
Why isn't Entrust in at least the newest browsers?
Really, the only root cert that comes in a browsers should be the browser maker's own, and then the browser maker would sign, using the private half of this cert, the CA certificates, which should be obtained dynamically via HTTP. Then new CAs can be added more readily.
I use Netscape 3.04 instead of Netscape 4.X for technical reasons (unbearable bugs in Netscape 4.X). The Verisign CA in Netscape 3.04 (and earliest 4.X) expired Dec 31, 1999. I went to download a new CA certificate and found that none was available. An exchange of e-mail with tech support, after a couple rounds of trying to explain to them what I even wanted, their only excuse was "We only support Netscape 4, you should upgrade". AFAIC, if they "support" it, they should fix it (but they declined).
I went to the Entrust site to see if they might have a root CA certificate I could download. Bingo! They do!
Now tell me why a big resourceful company like Verisign is totally unable to build a root CA certificate for Netscape 3.04 while a little puny company like Entrust has the resources to pull it off (and even earlier versions).
And Verisign can't even get their web site to work without having to type in the "www." while most places, including Entrust and Slashdot can.
Seeing that signature at the bottom confirms to me that ESR is a person who takes the issues of individual freedoms seriously and consistently. Perhaps you should reconsider why, while you seem to advocate personal freedoms in one area, that you feel the government should have control over some other aspect of your life.
Slashdot Mirror
For a simple thing to configure, yes that probably works. So much for using a simple example. Choose a complex one where nested contexts are needed. Does XML let you nest within a tag? I've never seen it done. Add some routing information and firewall rules to the ethernet device and see how it looks in XML and HSI.
This is an example of why every GUI tool must have a lean text version of itself (not as a monster executeable that can do everything), so it can fit and run from the rescue disk, without X, without SVGAlib.
I would not want text/document/markup experts telling me how to do everything else in the world with their tools. No one is an expert at everything. You might find some who know how to administer a system, but in general that isn't an expected skill. I don't profess to be a text/document/markup expert at all, so I would not presume to tell them how best to solve problems in that area. In fact, I find the solutions that are coming out for that purpos are working quite well. But success there doesn't mean it can be applied everywhere else.
The example I gave showed a simple configuration in both one possible XML format and one possible HSI format. Just because it was a simple example does not imply that either format is limited to only simple cases. You seem to be implying that while XML is not so limited, that HSI is. This is absolutely not true.
The day that effective tools allow me to abandon any use of a text editor under every context, then I won't care what format the file is in. But as long as GUI based tools fail to allow every possible configuration the way I want it, then I need to stick with the tool (my swiss army knife which consists of both vi and emacs) that does let me do what I need to do to make things work. And I therefore need to stick with a reasonable file format that is oriented to human editing.
Fix the GUI interfaces and logic, first, then come back and redesign the underlying system files.
Given the quality of GUI tools we have now, that day appears to still be a long ways away. If it is the case that XML is what will make the GUI tools work, where they are failing to work now, then maybe XML is worth considering (but I see no XML porponent suggesting that XML is what will fix all the GUI tools).
GUI tools need to be able to handle every possible state of configuration for them to be able to be used. They also have to work in every context. For example, if I have the system drive from another machine attached as a 2nd drive on my current machine, every GUI tool MUST (no exceptions allowed upon penalty of death) be able to operate on the attached system drive. For GUI to be effective, it must operate anywhere and everywhere a text editor does, and that include in text console single user mode (X and SVGAlib are not available).
I've heard that before about languages forcing discipline. I then look at C++ and all the masses of undisciplined programmers out there that think they are good at object oriented design because they use C++. I then ROFLMAO.
XML does have its advantages. It sells bigger disk drives. It sells more bandwidth. But that was probably going to happen anyway. It can be useful for database transfers and such, though probably no more or less so than some other things that have been proposed.
What XML already does seem to be great in is tagging extractable data from document oriented storage. With XML, you can mix information and presentation together. Non-conflicting DTDs (that will be interesting to see) can be merged. You can, for example, add tags that pinpoint data and data types in an HTML document, provided that the DTD used for those tags has not conflict with HTML (not at all hard to do if you make sure this was a spec/goal in the first place).
Like I replied above, httpd.conf is not XML, and only barely has a hint of XML. It has contexts like XML, but the directives are somewhere between command and ini style. That little touch of XML-ishness isn't causing any problem (though the ever changing semantics of does tend to be annoying). If XML is carried to the extreme, where every piece of data is expressed with XML tags, then it becomes hard to read. If the XML tools all "did the right thing" (which is doubtful for a few to many years yet) then you would never see the XML-ishness at all. But until that day, I will not design any system that reads XML for configuration state.
For other things like bulk data transfers between databases, where the data is generated by program, and parsed by program, and no human needs to even read it, then XML won't really cause too much of a problem (disk drives are bigger these days so XML's inefficiency in storage is probably not much of an issue, now, either).
I'm not opposed to making things better. And I'll even say that GUI has the potential to definitely be better than text editor is now. However, I have not yet seen any GUI config tool that is better. I've used tools from Redhat, SuSE, Solaris, SCO, and they all leave me wanting to go back to editing (and even vi would be better despite my preference for emacs which isn't always available).
... and let me stress that ... EVERY ... possible configuration state, the configuration needs to remain where it can be edited as text, by a real human. I rarely have time to figure out why some GUI tool won't let me do what I want to do. Most seem to be intent on narrowing the scope of what can be done.
Until such time as GUI interfaces can be devised that can handle every
I'm designing scripts now to automate system configurations. The scripts get data from a central (not on the same machine) database which describes what services are to be performed and assignments of which machine is to perform them. They will then construct the config files (such as Apache httpd.conf for web sites to be served) to conform. GUI tools would only get in the way unless they are the ones used to update the database over on the central server.
And LISP SEXPR isn't the only other option (though I do like it better than XML).
Everything you've described as a feature of XML is a feature of the alternative I've proposed, and appears to be features of many of the other proposals, as well.
What I find that XML does NOT have is "non-clutterness".
Who agreed on XML? That's BS. This debate is just beginning.
There isn't a Yet Another Standard. What I've proposed has been around since the early 1980's.
Apache's httpd.conf is NOT full blown XML, which some are suggesting. It is minimally XML-ish for contexts.
Existing tools abound for ALL the choices.
Instead of:
<device>
<name>eth0</name>
<address>192.168.1.2</address>
<netmask>255.255.255.0</netmask>
<onboot>yes</onboot>
</device>
I'd rather have:
device = (
name = eth0
address = 192.168.1.2
netmask = 255.255.255.0
onboot = yes
)
XML may have some cool features, and be useful for embedding information descriptors and tags in documents, but for building config files, it's hard to read and basically sucks.
Basically, what is essential here is that we all agree on what kind of slot to use between the screwdriver and the screws. Then we can use a hand turned screwdriver or a motor driven screwdriver. And we can use self-tapping screws, or machine screws, or whatever we like.
... pluggable tools.
If the configuration state is stored in a file with a document that makes the file format open, then you can use fancy GUI tools, or vi, or a script, to manage the configuration. This is what we need to require
And that is IMHBWSO an unconstitutional aspect of the DCMA. Mere accusation alone should never have the force of law to shut someone down. Even judges want to see some kind of evidence of at least a possible successful judgement to issue a temorary order. If I get a letter like that asking me to shut down one of my customers, what I will do with it, since I am not a lawyer, is first have my lawyer check its validity. Let them eat my bureaucracy.
When you view the total solar eclipse of the sun by the earth from the moon, you have one factor that you don't have the other way around. That is the earth's atmosphere. You'll get to see a big red ring that is basically the same effect as a sunset. This is where the moon gets that reddish color.
An ISP that triggers limits like that on an automatic basis so quickly is not one that ANYONE should use at ANY price range. Any decent ISP (and there are way too few of them) would recognize a spike and just ride it out for at least a day, with a review to be done by a human. Checks should be made to make sure they aren't posting the newest Redhat ISO image or something like that. Sure, if they buy the low level of service, then they shouldn't be expected to sustain a continuous 10000/hr rate (as being slashdotted could potentially do for a day or so for the most popular sites). But it doesn't help the ISP any to give 500 when slashdotted.
If you know how to do a web search, then search, and learn the truth.
If Hedy Lamarr, or anyone else, had patented something as simple as spread spectrum today, it would be a joke patent, much like so many others. In the 1940's, however, it was a marvelous new idea that should have been used more than it was.
.COM wasted 999 man*hours implementing it).
If no one else can figure out how to solve a real problem, then one person figures out a solution, that's a real patentable idea. Sometimes it's hard to tell if it's a solution seeking a problem. But stupidly obvious stuff like saving your credit card info in a server indexed by username or cookie, is not worthy of a patent (even if some
If Hedy Lamarr had been in her prime at the launch of the Internet, she probably would have been a great contributor.
It was obvious from the title what this was about. I happened to be particularly interested because I was in a discussion just yesterday about her invention of spread spectrum.
Yet another lame web host site starts up!
Start by getting capital financing. You don't need millions on day 1, but you do need to put together a good business executive team consisting of at minimum, a good finance/accounting/tax expert who can line up the initial and following funding, a good marketing/sales/leadership expert who can make your business known and bring in customers, and of course a good technical/networking/server expert who can put all this together and make it work solidly, securely, and reliably. A good tech support department is also essential. And don't forget a solid business plan.
Given your question, I take it you aren't the technical expert so you wouldn't be CTO. Are you a finance guy? A marketing guy? A sidelines investor? Or someone to answer the phones?
Unlimited bandwidth is just a marketing ploy. As you point out, once you start chugging gigs, things start to change.
I'd have more trust in a web hoster that charged by usage. And I don't mean a sudden kick to the next pricing tier once you pull 1.000001 gig. I mean basic smooth (probably linear) rate per meg. That's the only way I'd do it. I wouldn't want to have to be in the position of kicking someone out because they chug gigs, if they could pay appropriately for it. I wouldn't be in the business to be giving it away.
How many good technical people are out their in Slashdot reader land who could put together a solid and reliable web hosting, colocation, and/or internet access facility, IFF you could just find the right financing and marketing partners to make that end of the business (such as getting enough starting capital and new clients to make it fly), and make it absolutely rock?
/. and pick up some techie partners that know what they are doing.
I would bet there are quite a few of us.
Now ask the same question from the perspective of the finance guys or the marketing guys who might be looking for techies? Would there be people in that group who would feel they are the best at what they do and are looking for the best techies to be partners with?
Every poorly performing business I have seen seems to have problems in almost every area. But the biggest problems seem to be in committing the resources to the facilities sufficiently to avoid the kinds of problems that make customers leave. Sticking a T3 into a Cisco router and attaching a couple servers just doesn't cut it. And there are some hosters which aren't much more than that.
Finance and Marketing types should hang around
Where can we download a Jesse Kovach CA root certificate? You do support all browsers, right?
Why isn't Entrust in at least the newest browsers?
Really, the only root cert that comes in a browsers should be the browser maker's own, and then the browser maker would sign, using the private half of this cert, the CA certificates, which should be obtained dynamically via HTTP. Then new CAs can be added more readily.
An alternative would be to cease including root CA certificates in browsers, and instead provide a place for people to install them.
If course this will confuse the 99.9% clueless biomass that has infested the net these days.
Slashdot should generate their own root CA certs and let us install them ourselves.
I use Netscape 3.04 instead of Netscape 4.X for technical reasons (unbearable bugs in Netscape 4.X). The Verisign CA in Netscape 3.04 (and earliest 4.X) expired Dec 31, 1999. I went to download a new CA certificate and found that none was available. An exchange of e-mail with tech support, after a couple rounds of trying to explain to them what I even wanted, their only excuse was "We only support Netscape 4, you should upgrade". AFAIC, if they "support" it, they should fix it (but they declined).
I went to the Entrust site to see if they might have a root CA certificate I could download. Bingo! They do!
Now tell me why a big resourceful company like Verisign is totally unable to build a root CA certificate for Netscape 3.04 while a little puny company like Entrust has the resources to pull it off (and even earlier versions).
And Verisign can't even get their web site to work without having to type in the "www." while most places, including Entrust and Slashdot can.
Seeing that signature at the bottom confirms to me that ESR is a person who takes the issues of individual freedoms seriously and consistently. Perhaps you should reconsider why, while you seem to advocate personal freedoms in one area, that you feel the government should have control over some other aspect of your life.
Why would anyone in their right mind (at least before the first one) want to drink beer with a Y2K bug?