I was going to mod you up, until I read about you switching NT Workstation to NT Server by switching these two registry keys. I very much doubt you've done it.
The original Dr Dobbs* article where it told you how to do this, points out that NT has some hooks in the registry to detect changes to these keys, which automatically revert them if you try and change them. Now the people who wrote the article actually figured out a way to point those hooks elsewhere, allowing you to change the keys and thus convert your NT Workstation to "NT Server". However MS lawyers didn't like that too much, and performed one of the most amazing cleanups I've ever seen - every link to that utility was removed from the net, to the point where it's no longer possible to find that magic tool (at least last time I checked).
But the point overall is that you pay extra for NT Server because you get the extra tools, plus support for those tools. If you don't pay for Server, you won't be able to get support for the extra tools you managed to get working on your converted copy.
The solution of course is to install a free OS:-)
* I think it was Dr Dobbs, though it may have been Byte, or NTinternals
Go see an accountant instead. They know the ins and outs probably better than a lawyer will anyway, and will most likely be able to give you a free consultation before you sign them up.
But make no mistake about it - starting a business costs money. There are various ways to get that money (don't even think of VC's right now), such as government initiatives. You local government may also have a small business bureau of some sort - go and speak to them - that's why they are there.
For whatever it's worth, the software division was hardly a new venture for O'Reilly. Their "Internet in a Box" was the first product to give windows users access to the internet, and it came out of the software division back in (I think) 1993.
O'Reilly are first and foremost a book company, and they're a damn good one. This is where their efforts should lie
That doesn't seem to follow with their current path of expanding into conferences then...:-)
The XML lingo you are looking for is RSS, which in the 0.9 format from Netscape was a form of RDF, then UserLand software decided to bastardise it into "Rich Site Summary", removing the RDFness. This is the most common format available now - RSS 0.91 (they've recently released 0.92). Luckily some very smart XML geeks saw this was a bad thing, and took RSS under their wings to create RSS 1.0, which *is* a form of RDF again.
But please, do not call RSS files "RDF". There are many forms that RDF can take. RDF is just a directed graph syntax in XML - its possibilities are endless and not limited to headline summaries. You are doing yourself an injustice by calling RSS "RDF", because I could not feed you my geneology graph in RDF format and expect you to be able to make headlines out of it.
You want RSS feeds, which you can find at http://www.xmltree.com/
Now, it might not be a standard, it might not be as open as, say perl - but if I took perl and extended it, and wrote something that used those extensions, it wouldn't work on everyone elses system
Tell me again how that would be writing cross platform applications? I'm not sure I get your point. Have you ever known anybody do this and then complain that their application doesn't work across platforms? No, because you would slap them with a wet kipper if they did.
First off, this is not meant as flamebait, but a general warning - call it a review, of jabber clients on Linux.
We were going to use Jabber on a project I'm working on as part of the application. We've now decided against that until the clients become more stable and more usable.
The server I'm sure is fine. I downloaded a binary from jabber.org and ran it after editing the configuration file. I think its still running.
But the clients were a different issue. On Linux you have 4 or 5 choices. My first try was the Perl client. That actually downloaded and worked pretty well after a very lengthy compile phase (it compiles Tk). But the language it uses is confusing - the jabber client developers have obviously used some of the server jargon in the clients. This made it extremely odd to use. Whereas with AIM it was enter user/password and I was off, with Jabber it seemed more confusing. Plus I didn't know anyone who used Jabber, so I had to try the AOL or IRC bindings. Those didn't work well and/or were confusing as hell.
Next I tried the Gnome/GTK+ client. After realising the dependencies were spiralling out of control I gave up. Nobody should have to update their entire (up to date Helix) gnome install just to get a jabber client running. OK, I'm exhagerating a little. But it was enough to put me off, and certainly not something we could force on our customers.
Then I tried the Python client. That proved impossible to download, but the homepage wasn't exactly encouraging about its functionality.
Finally the one glimmer of hope was the Mozilla client. That installed with just a few clicks and a restart. Unfortunately it didn't seem to support the alternative protocol bindings, so I was stuck not knowing any jabber users.
In short, my conclusion for now for our project (based on the knowledge of our user's abilities) is that Jabber just isn't there yet on the client front, on Linux. Maybe it will be in 6 months or more. For now, AIM is a great alternative, despite the worrys of AOL's control over the protocol.
2) a. The weather in the game is equal to the weather of where you live.
Oh thats just great. Wonderful. So not only do I have to put up with this rain in real life, I have to live with it in the game too, while my boss in California gets to play in glorious sunshine. How nice for me!
I have a LyX2DocBook in the works, which would solve your editor issue, but I'd only give it to you if you consider AxKit rather than Cocoon:-) (I'm just kidding).
FWIW, all the AxKit documentation is DocBook, and converted on the fly to HTML, source and stylesheets available to download from the site (link in.sig).
For Perl users out there, don't forget about AxKit - an implementation of some of the same technology as Cocoon, but in a mod_perl framework (with a few differences too). Of course we support some different technology, and have a few different tacks on the same ideas, but the idea of using W3C recommendations to implement a server framework is the same.
For the person in this thread saying that Cocoon is slow, you might be interested to know that Covalent had to drop Cocoon and replace it with AxKit for the Apache mailing list archives at http://archive.covalent.net/ - I don't have specific details of why Cocoon couldn't hold up (it continually crashed when the hits went higher than 3 hits/sec), only that AxKit does hold up to the strain (Of course, I'm biased)
I think you'll find that Nedit was there before most of them. Maybe all of them with the exception of vi and ed! (exhagerating I know, but this is an old project, not some new upstart editor).
So what possessed him to write an X based editor? There were none freely available at the time. Simple. Editor X didn't exist.
If only that came without all the extra cruft with rooms and floors etc. We're only talking 2 or 3 people here, so at the moment we certainly don't need all that. However it does look very interesting, and I'm going to play with it a bit in the next few days.
I hate to say it too, but did you miss the bit about me not using windows? I have one NT box in my office for testing Perl code on NT, but I only ever access it via VNC (it has no monitor). I can't imagine how nasty it would be to have to access a real time environment like a whiteboard over VNC, even on the local network, its just not fast.
Actually VNC is what we use right now, and it kinda works quite nicely. But I'd still like to see something with the following that is just a pure GTK or KDE app:
An area you can draw on, with some simple primitives available. You should be able to do multiline text as though it were a text editor, and yet still draw anywhere on that text.
The ability to select who is drawing from a list of logged on users. It would just put a big "pen" besides their name.
Save to PNG.
Unfortunately VNC doesn't really offer these, and no, firing up the GIMP in VNC isn't a great solution, IMHO, as it doesn't solve the "only one person has the pen" problem.
For the systems (and users) I'm thinking of, I don't think truly random generated passwords would go down well with our user base. I was thinking of random picks from a dictionary.
Thats not to invalidate your reply though - its all valid information. The solution I'm thinking of is the MD5 URL to visit to reset your password. It could be one-time generated with the current time, the user_id and a secret. Thus impossible to guess, and again, the password doesn't get reset until the URL is visited.
Why carry two devices? Get an SMS capable phone and setup an email to SMS gateway (there are tons of free or cheap ones on the 'net) to forward an email address to your phone (that way they're not sending SMS messages to YOUR_NUMBER@sms.gateway.net). I just use a.qmail file on my server to forward all email to a certain address to +44123456789@sms.genie.co.uk. Works beautifully (although genie is UK only and very slow during the day).
The question then becomes how do you implement forgotten passwords?
Generated passwords (emailed to you) opens you up to some sort of randomization attacks.
"Hint" questions are a bad idea, because finding out the sorts of things that people use for hints on the internet is fairly trivial. If someone breaks into the DB and gets the Hints database, they can probably figure out your password. Besides, what can you use for a hint for "aF3g!5%fg" ?
A base64 encoded Unique URL to visit is probably the best thing. Mail that to the user, and get them to click on the link.
I'm talking about people on slow links USING your web site. People with modems. I don't care how fast your pipe is outgoing - these people on slow modems can effectively crush your site, shocking as it may sound, because they end up spawning more httpd's, eventually either forcing you to your httpd limit (if you've taken the time to set it sensibly), or forcing your server into swap. And you don't want that to happen.
Please go and read some real quality information on people who have worked with these high end solutions before thinking about replying again. Such as the mod_perl guide, at http://perl.apache.org/guide/
It all depends on your architecture. Sure if you have a caching proxy front end it might not be worth it. But if you don't, and have a slow client connecting (say a 56K modem), the time taken to gzip a 700K file (assuming this is mostly text) vs the time it takes to actually download that file make the benefit definitely worthwhile.
People easily forget that, and assume that their bandwidth is big enough that the file will just instantly disappear down the pipe. Your server will get overloaded an awful lot quicker if every httpd is waiting on a slow client to download 700K when they could be downloading 100K.
This is a bit of a plug, but I found a really big win for the server side (not the client side) when I added this feature to AxKit (link in.sig). I'm behind a 64Kb line, and some of the AxKit pages are pure documentation. This feature reduced the outgoing page size by about 80% for many pages, which seriously helps me deliver more content to my users. And the gzipped content is cached, so its just as fast as the non-gzipped content when using cacheable pages.
Yes, its not much help for images, but then you just shouldn't enable this concept for images.
Apache::GzipChain can also provide this option for people working with static pages on mod_perl enabled servers, but it has a serious memory leak in it that I found last week (and posted details of to the mod_perl mailing list).
The 1x1 gif confirms that your email address is active and that you viewed the email. Another strong argument for text based email readers, I'm afraid. I really home that both KDE and Gnome are taking this into account when they create their funky new email clients with the ability to read HTML content.
Slashdot Mirror
DTD's are nothing like namespaces, and your conclusion is incorrect.
There is a PUBLIC identifier allowed in the XML DOCTYPE which is purely symbolic, but that's not what we're talking about here.
The current version of HTML::Parser is written in C, with an XS interface. Maybe you aught to take a visit to CPAN?
I was going to mod you up, until I read about you switching NT Workstation to NT Server by switching these two registry keys. I very much doubt you've done it.
:-)
The original Dr Dobbs* article where it told you how to do this, points out that NT has some hooks in the registry to detect changes to these keys, which automatically revert them if you try and change them. Now the people who wrote the article actually figured out a way to point those hooks elsewhere, allowing you to change the keys and thus convert your NT Workstation to "NT Server". However MS lawyers didn't like that too much, and performed one of the most amazing cleanups I've ever seen - every link to that utility was removed from the net, to the point where it's no longer possible to find that magic tool (at least last time I checked).
But the point overall is that you pay extra for NT Server because you get the extra tools, plus support for those tools. If you don't pay for Server, you won't be able to get support for the extra tools you managed to get working on your converted copy.
The solution of course is to install a free OS
* I think it was Dr Dobbs, though it may have been Byte, or NTinternals
Go see an accountant instead. They know the ins and outs probably better than a lawyer will anyway, and will most likely be able to give you a free consultation before you sign them up.
But make no mistake about it - starting a business costs money. There are various ways to get that money (don't even think of VC's right now), such as government initiatives. You local government may also have a small business bureau of some sort - go and speak to them - that's why they are there.
That doesn't seem to follow with their current path of expanding into conferences then... :-)
I get so frustrated with this error...
:-)
The XML lingo you are looking for is RSS, which in the 0.9 format from Netscape was a form of RDF, then UserLand software decided to bastardise it into "Rich Site Summary", removing the RDFness. This is the most common format available now - RSS 0.91 (they've recently released 0.92). Luckily some very smart XML geeks saw this was a bad thing, and took RSS under their wings to create RSS 1.0, which *is* a form of RDF again.
But please, do not call RSS files "RDF". There are many forms that RDF can take. RDF is just a directed graph syntax in XML - its possibilities are endless and not limited to headline summaries. You are doing yourself an injustice by calling RSS "RDF", because I could not feed you my geneology graph in RDF format and expect you to be able to make headlines out of it.
You want RSS feeds, which you can find at http://www.xmltree.com/
Thank you and goodnight
Tell me again how that would be writing cross platform applications? I'm not sure I get your point. Have you ever known anybody do this and then complain that their application doesn't work across platforms? No, because you would slap them with a wet kipper if they did.
First off, this is not meant as flamebait, but a general warning - call it a review, of jabber clients on Linux.
We were going to use Jabber on a project I'm working on as part of the application. We've now decided against that until the clients become more stable and more usable.
The server I'm sure is fine. I downloaded a binary from jabber.org and ran it after editing the configuration file. I think its still running.
But the clients were a different issue. On Linux you have 4 or 5 choices. My first try was the Perl client. That actually downloaded and worked pretty well after a very lengthy compile phase (it compiles Tk). But the language it uses is confusing - the jabber client developers have obviously used some of the server jargon in the clients. This made it extremely odd to use. Whereas with AIM it was enter user/password and I was off, with Jabber it seemed more confusing. Plus I didn't know anyone who used Jabber, so I had to try the AOL or IRC bindings. Those didn't work well and/or were confusing as hell.
Next I tried the Gnome/GTK+ client. After realising the dependencies were spiralling out of control I gave up. Nobody should have to update their entire (up to date Helix) gnome install just to get a jabber client running. OK, I'm exhagerating a little. But it was enough to put me off, and certainly not something we could force on our customers.
Then I tried the Python client. That proved impossible to download, but the homepage wasn't exactly encouraging about its functionality.
Finally the one glimmer of hope was the Mozilla client. That installed with just a few clicks and a restart. Unfortunately it didn't seem to support the alternative protocol bindings, so I was stuck not knowing any jabber users.
In short, my conclusion for now for our project (based on the knowledge of our user's abilities) is that Jabber just isn't there yet on the client front, on Linux. Maybe it will be in 6 months or more. For now, AIM is a great alternative, despite the worrys of AOL's control over the protocol.
Oh thats just great. Wonderful. So not only do I have to put up with this rain in real life, I have to live with it in the game too, while my boss in California gets to play in glorious sunshine. How nice for me!
(living in sunny Scotland)
I have a LyX2DocBook in the works, which would solve your editor issue, but I'd only give it to you if you consider AxKit rather than Cocoon :-) (I'm just kidding).
.sig).
FWIW, all the AxKit documentation is DocBook, and converted on the fly to HTML, source and stylesheets available to download from the site (link in
For Perl users out there, don't forget about AxKit - an implementation of some of the same technology as Cocoon, but in a mod_perl framework (with a few differences too). Of course we support some different technology, and have a few different tacks on the same ideas, but the idea of using W3C recommendations to implement a server framework is the same.
For the person in this thread saying that Cocoon is slow, you might be interested to know that Covalent had to drop Cocoon and replace it with AxKit for the Apache mailing list archives at http://archive.covalent.net/ - I don't have specific details of why Cocoon couldn't hold up (it continually crashed when the hits went higher than 3 hits/sec), only that AxKit does hold up to the strain (Of course, I'm biased)
I think you'll find that Nedit was there before most of them. Maybe all of them with the exception of vi and ed! (exhagerating I know, but this is an old project, not some new upstart editor).
So what possessed him to write an X based editor? There were none freely available at the time. Simple. Editor X didn't exist.
If only that came without all the extra cruft with rooms and floors etc. We're only talking 2 or 3 people here, so at the moment we certainly don't need all that. However it does look very interesting, and I'm going to play with it a bit in the next few days.
Thanks!
I hate to say it too, but did you miss the bit about me not using windows? I have one NT box in my office for testing Perl code on NT, but I only ever access it via VNC (it has no monitor). I can't imagine how nasty it would be to have to access a real time environment like a whiteboard over VNC, even on the local network, its just not fast.
Actually VNC is what we use right now, and it kinda works quite nicely. But I'd still like to see something with the following that is just a pure GTK or KDE app:
An area you can draw on, with some simple primitives available. You should be able to do multiline text as though it were a text editor, and yet still draw anywhere on that text.
The ability to select who is drawing from a list of logged on users. It would just put a big "pen" besides their name.
Save to PNG.
Unfortunately VNC doesn't really offer these, and no, firing up the GIMP in VNC isn't a great solution, IMHO, as it doesn't solve the "only one person has the pen" problem.
For the systems (and users) I'm thinking of, I don't think truly random generated passwords would go down well with our user base. I was thinking of random picks from a dictionary.
Thats not to invalidate your reply though - its all valid information. The solution I'm thinking of is the MD5 URL to visit to reset your password. It could be one-time generated with the current time, the user_id and a secret. Thus impossible to guess, and again, the password doesn't get reset until the URL is visited.
Why carry two devices? Get an SMS capable phone and setup an email to SMS gateway (there are tons of free or cheap ones on the 'net) to forward an email address to your phone (that way they're not sending SMS messages to YOUR_NUMBER@sms.gateway.net). I just use a .qmail file on my server to forward all email to a certain address to +44123456789@sms.genie.co.uk. Works beautifully (although genie is UK only and very slow during the day).
Of course, when I say Base64 here, I mean MD5.
Just shoot me.
The question then becomes how do you implement forgotten passwords?
Generated passwords (emailed to you) opens you up to some sort of randomization attacks.
"Hint" questions are a bad idea, because finding out the sorts of things that people use for hints on the internet is fairly trivial. If someone breaks into the DB and gets the Hints database, they can probably figure out your password. Besides, what can you use for a hint for "aF3g!5%fg" ?
A base64 encoded Unique URL to visit is probably the best thing. Mail that to the user, and get them to click on the link.
Any other thoughts on this?
bleh, dead web site. Try axkit.org.
Not if you don't want them! ;-)
I'm not talking about outgoing bandwidth!!!
I'm talking about people on slow links USING your web site. People with modems. I don't care how fast your pipe is outgoing - these people on slow modems can effectively crush your site, shocking as it may sound, because they end up spawning more httpd's, eventually either forcing you to your httpd limit (if you've taken the time to set it sensibly), or forcing your server into swap. And you don't want that to happen.
Please go and read some real quality information on people who have worked with these high end solutions before thinking about replying again. Such as the mod_perl guide, at http://perl.apache.org/guide/
It all depends on your architecture. Sure if you have a caching proxy front end it might not be worth it. But if you don't, and have a slow client connecting (say a 56K modem), the time taken to gzip a 700K file (assuming this is mostly text) vs the time it takes to actually download that file make the benefit definitely worthwhile.
People easily forget that, and assume that their bandwidth is big enough that the file will just instantly disappear down the pipe. Your server will get overloaded an awful lot quicker if every httpd is waiting on a slow client to download 700K when they could be downloading 100K.
This is a bit of a plug, but I found a really big win for the server side (not the client side) when I added this feature to AxKit (link in .sig). I'm behind a 64Kb line, and some of the AxKit pages are pure documentation. This feature reduced the outgoing page size by about 80% for many pages, which seriously helps me deliver more content to my users. And the gzipped content is cached, so its just as fast as the non-gzipped content when using cacheable pages.
Yes, its not much help for images, but then you just shouldn't enable this concept for images.
Apache::GzipChain can also provide this option for people working with static pages on mod_perl enabled servers, but it has a serious memory leak in it that I found last week (and posted details of to the mod_perl mailing list).
The 1x1 gif confirms that your email address is active and that you viewed the email. Another strong argument for text based email readers, I'm afraid. I really home that both KDE and Gnome are taking this into account when they create their funky new email clients with the ability to read HTML content.