* It's for KDE, so you can print directly to postscript or a PDF. * Connect objects permanently and re-arrange them on the page without losing your connection lines. * Use any font face/size installed on KDE. * Multiple lines of text. * Create multiple pages in a single document. * Use any of 16 built-in arrowhead types. * Control line width and color. * Use object shapes and graphics from a huge collection of stencils. * Open source and free.
I just poked around with it to see what KDE had for diagraming and, as always, was floored by the quality.
Great suggestion, I think people with large volumes can really benefit from that advice.
I'm glad to see not EVERYONE makes useless posts to Slashdot just to hear themselves harrumph around acting like know-it-alls who run around rebuffing everyone who tries to help others with a little advice, but never offer any advice themselves.
Yes, learning to type is still necessary. However, I think the number of untrained typists these days proves that you can type quite well without formal training. Learning to type the formal way can speed up your rate and accuracy, but it's far from necessary.
I almost always use a middle layered server that buffers calls between applications and the database. It's job is really to coordinate transactions, users and to perform tasks that go faster natively than through a database. A middle tier invariably makes it FAR simpler switching from one database engine to another than trying to port stored procedures.
No you defined the hard way as talking to other experienced users and the developers.
No, I said they learn the hard way AND by interviewing experienced users and the developers. Here's what I said, verbatim:
They learn the hard way, the way experienced computer users do, and by interviewing users familiar with the software and even the developers themselves. Then they author something more digestible for inexperienced users.
Books on programming languages yes, languages change slowly overall. Individual open source applications often change rapidly. The books come out at best 6 months to a year after a version of the application comes out. By that time there may already have been several versions released (depending on the project).
Books don't go so far out of date they become useless to an inexperienced user learning how to use an open source application. The book teaches them how to use it; project reference shows them the current, precise way of doing a particular thing.
You're missing the point of virtually everything I say and turn everything into a point of contention while not adding to the discussion at all. I'll lay out it again; this is everything I've said right from the beginning:
Open source project developers need to provide better documentation. It needs to be good enough for experienced computer users, but shouldn't require users to be C programmers and shouldn't require them to study source code. Documentation good enough for inexperienced computer users is best provided for by third-party private authors and publishers; they have excelled in this arena historically, and will continue to do so (O'Reilly is an excellent example of this).
What the hell is there in any of that above to contend with!?!?
There are problems with using site-variable port numbers: it makes identifying traffic types a little tricky
This IS a real problem with the idea, but I think it could be worked out with some creative thinking.
Someone types in example.com - what do you need to lookup? www.example.com A, example.com A, example.com SRV? What about sites where these are different - which address do you connect to? Then, do you send them off all at once (reduces delays in the common instance but has a tendency to increase delays overall)? How long do you wait for replies? - they could come back out of order. Or do you send them serially, which will add some delay to the majority of lookups, but is on-the-whole friendlier to the networks and DNS servers.
You can still map IPs to any canonical name you want; "use IDs" wouldn't change that. You just need to provide the "use ID" to get the IP for the server you want to connect to.
One nice thing about "use IDs" though is you can STOP using canonical names like www.domainname.com to map IPs to protocols, and use them only for mapping to hosts. You would only have domainname.com and a "use ID" of HTTP. You would also have "use IDs" for other protocols used with the domain name, and you could return a different IP+port for each of them.
A web browser vendor is unlikely to be particularly happy to add and default-enable a feature that adds to the time taken to resolve the majority of names - but realistically, you won't have very high takeup on the server side until most clients threaten not to connect unless it's done. For newer protocols it's simpler, since there often need be no fallback to A record, and indeed SRV records are being used on some newer protocols. Still, the traffic identification problem is still there.
Remember, this is a re-design. I wouldn't take into account any difficulty they have converting their software to the new way of doing things. We're designing to "get it right."
Adding this to HTTP is a bit different than the case with adding MX to email: many more people will notice the increased time to resolve the name. With email, the delay is in the background, after the message has left the end-user's mail client and enters the transport system: it's almost invisible. With interactive requests such as HTTP, any delay is immediately obvious.
Why would it take more time? The only difference is that you're giving the DNS server a "use ID" and it looks up the domain name, then finds the IP+port which is mapped to that ID. That shouldn't take any noticeable additional time.
Since it doesn't really buy you anything you don't get from an address-translating device on the IP address of example.com, and given the complexities and problems it adds, who's going to use it?
Everyone, it's how things would be done in the re-design; you would have no choice.
Now I think you're just trolling, or not reading what I am writing very closely.
I don't know many experienced computer users who do it that way. Most I know beat the software with a stick and if all else fails check the documentation, if that fails check google. If that fails check other engines. If that fails, find other software.
This is precisely what I said: most experienced computer users learn the hard way. This is how authors do it and then they write documentation that is easier for people to understand.
The program is worthless if nobody can use it. Or if only people who have learned through a chain of word of mouth, starting from the developers, can use it.
What is your point? Have you not read anything I've written?
I've seen plenty, check o'reilly, there are almost no books pertaining to open source that aren't co-authored by a prominent project developer. Now if you were thinking something along the lines of dummy books, I certainly wasn't talking about that.
Again, you didn't read what I wrote. I said authors interview developers as part of their research to write their books.
For that matter I'm not even sure the dummies series of books DESERVES existance. O'Reilly books are better examples. O'Reilly books don't require you to be experienced to understand, but aren't dumbed down to the point of being useless either.
That's for each person to decide for themselves. I have heard they help a LOT of people, and they are EXTREMELY popular.
There are three reasons I don't believe books are the answer to documentation. 1, it takes too long, by they time they go through all the levels of red tape, editing, rewritting, (loop 200000 times) and then go through a similar process except pertaining to actual printing and advertising etc. They are outdated by the time they hit the shelves.
This is flat-out untrue, and now I am sure you are a troll and/or an idiot. Books are an invaluable resource for everyone, even for highly experienced programmers.
Second, nobody is going to use an application if they have to buy a book to get it installed and in a basic functional configuration. Rule of thumb, if there is any chance a company with less than 500 employees might do it, or a user at home, then it's a basic functional configuration and nothing involved should be considered "advanced".
You still aren't reading what I wrote. Successful projects provide enough documentation for experienced computer users. The entire topic has been about improving the documentation for OPEN SOURCE PROJECTS to allow them to be used by inexperienced computer users.
Inexperienced computer users can get Apache running. Only because books are available which make it simple and straight-forward. Prior to those books being available, you had this: http://apache.org/. Tell me an inexperienced computer user can get Apache going from the docs provided by the Apache foundation. They can't. Third-party commercial documentation is the only way to provide that sort of documentation, unless a professional author wants to donate his/her time to the project, or a particularly talented developer has the time for it.
Third, there are a shitload of books out there, how am I to know which is the up to date project approved documention for "Program X". Or are you suggesting that as well as providing no useful information for actually running a program, the project should not even have a 3rd party they ensure has that available?
That's why you read book reviews and talk to other people. Why are you asking me? You don't know how to select a book?
The rest of your drivel is annoying the shit out of me and is becoming plain non-sensical. I don't mind exchanging ideas, but you're just arguing to hear your own voice, I think. You aren't paying attention to anything I say, and you are saying ludicrously stupid things like "I don't think books are the answer to documentation."
Get your fucking head on straight and then continue the conversation, or just go fuck off.
If every nook and cranny isn't documented, how exactly is it you expect professional authors to learn them?
You do realize that authors today do this very thing? It isn't a matter opinion that they do: it's a fact. They learn the hard way, the way experienced computer users do, and by interviewing users familiar with the software and even the developers themselves. Then they author something more digestible for inexperienced users.
Professional programmers work on open source projects, some with and some without pay. What on earth makes you assume these things have to be done without pay?
How do you propose a dedicated, professional author be paid for his/her work if they don't write a book and get paid for it?
In many cases there is a commercial conflict of interests on open source projects though. Usually the prominent developers get paid for support (either directly or by co-authoring books), there wouldn't be as much demand for this with good solid documentation.
I haven't seen many books written for projects by the developer's themselves. The vast majority of technical books for open source software are written by third-party authors, who get paid for their work directly.
The programmers themselves should NOT be providing the documentation, they should be recruiting volunteers for that purpose.
Unfortunately, the vast majority of software projects out there have the programmers themselves writing the documentation. It would be nice if things were otherwise, but that's how it is, and that's probably why documentation is such an issue right now.
Full documentation, and no I'd completely disagree, it should NOT be a book sold by a 3rd party.
You're misreading what I said and meant. Full documentation doesn't provide hand-holding tutorials through every single nook-and-cranny a user might need or want to learn about. Full documentation is just that: full documentation. Inexperienced computer users don't usually make much sense out of regular, full software documentation. They learn much better from "Dummy" books, and they progress from book to book as they raise themselves up in competence. I don't think software projects should be providing that sort of documentation; it's far too tedious. That should be left to the private sector. There's a lot of tedious work involved, and it's almost ALWAYS done best by experienced authors who make their living at it.
Perhaps professional authors would like to join the open source movement and start authoring for OSS projects for no pay. I just wouldn't hold your breath waiting for that. More than likely, the best you can hope for is for the developers to provide better regular documentation, and leave the hand-holding to the professional authors.
Well-known ports are very problematic in that it assumes there are a fixed-number of protocols to assign standard ports to, and it assumes everyone is cooperating. By allowing the arbitrary identifiers to determine the port, you can drop "well known ports" altogether.
No, you don't. You simply move the problem from "well-known ports" to "well-known labels".
If they move to "well-known labels", isn't that "dropping well-known ports?" Ports and labels are two different animals. Well-known ports are a finite number of numbers, and labels are a nearly infinite number of text IDs. I wasn't advocating eliminating "well-known" anything, but re-designing DNS to have generic MX-like "use IDs" that return IP+port.
Not all "internet protocols" are sufficiently similar to be wedged into a single, request-response-oriented protocol. Consider X11 (6000 + display #) or VNC (5800 + display #, 5900 + display #), for instance. Or IRC (6667), to pick something a little closer to the canonical set of 'core' (text-based) internet protocols. All of these protocols have been designed with a specific task in mind, and not one of them maps well to HTTP's request-response structure: they're all asynchronous.
Which is why I only mentioned unifying protocols similar to HTTP, such as SMTP, FTP, NNTP, etc. Not all protocols could be unified that way, although you could perhaps initiate connects through a unified protocol that then handed-off to tighter, more efficient protocols.
You understood my DNS idea, I just wanted to add to your comments.
Relying on a port number would require either server (or a third server, mostly likely) to dispatch requests to a single IP, then route traffic to other IPs based on intended use. He wanted the shift the burden of traffic differentiation up a level.
This isn't how it would work. When a client resolves a domain name, it would provide a domain name and "use ID" and would get, in return, an IP address and port and would go directly to the IP/port.
It would put too much of a burden on the DNS system, only to make the lives of select few domain admins easier.
It wouldn't be any more difficult than what all mail clients have to do right now to determine the MX record for a domain name. All software would have to provide that "use ID" and then connect to an IP/port, rather than how things are done now where there is no "use ID" and the port is assumed. It wouldn't burden anyone very much.
I guess I this at the core of the issue for me. I can imagine not being to imagine right now needing anymore than what IPv6 allows.
It's not just a matter of having enough addresses for all the hosts we may have, there's an allocation issue. Every network is going to watch giant swaths of address space, so the ceiling that IPv6 provides is much lower than the sum of hosts that can fit in it. Lots of addresses are going to go to waste in one network while other networks starve for addresses.
I just think "fixed" length addresses is going to bite humans in the butt again one day.
SMTP/HTTP are not resource types. They are protocols.
You could have a "WWW" resource type, I guess.
My idea was to change DNS to allow IP numbers to be returned for arbitrary identifiers the way MX works, but more generically; not "resource types" per se. You can store numbers for HTTP, WWW, MAIL, TELNET, PORN, whatever you want.
This is already done, with well-known ports -- the advantage of using well-known ports is that the additional network traffic and latency is avoided.
Well-known ports are very problematic in that it assumes there are a fixed-number of protocols to assign standard ports to, and it assumes everyone is cooperating. By allowing the arbitrary identifiers to determine the port, you can drop "well known ports" altogether.
Hmm. I dunno. I guess you could wrap these in HTTP, but where's the benefit of doing so? You can't really reuse any significant functionality and you'd slightly increase complexity (since everything would need to be linked to an HTTP library).
Lots of reasons, but the two main ones I can think of are: combined code base (as quality of code increases, it increases for all protocols) and it would make it easier to implement protocols and work with them. All the different internet protocols, while very similar, have their own little quirks.
Also, any time you added some desired new feature to the protocol, it is immediately available to all the descendant protocols.
(DATA MERGE) Hmm. I'm not quite sure what the benefit to doing so would be.
Same as above; uniformity and a central code base simply makes it easier to implement, debug, etc. It's just a code quality, efficiency thing.
I would clean up the protocol so it's possible to concatenate multiple lines together without ambiguity, and uniformly, so the method for multiple line headers is the same as multiple lines of data.
Wouldn't this just impose overhead on protocols that use an eight-bit-clean and non-line-oriented interface, like FTP DATA?
I would actually keep the data channel FTP has and make that part of the protocol; it's very efficient. Although perhaps I would make it part of the new data scheme, where you would provide metadata through the protocol, and deliver the data either through the protocol or, optionally, through an 8-bit data connection.
Not sure what you mean... I guess you'd make every protocol SSL-tunneled? I mean, I think it's a good idea (more plaintext services becoming encrypted == better), but you can already do that, and the main reason that people don't is because of (now archaic) patent issues and because of CPU load. Also, SSL adds overhead, not just on the CPU, but in latency.
This would make shared hosting simpler and would save us a LOT of IPv4 numbers.
I don't see why this would be the case.
Hmm...hard to explain briefly. Virtual hosting is done at the HTTP layer; when a connection is made, browsers request resources by providing a domain name and resource. A web server can "switch" off to the appropriate virtual host using the domain name given. SSL is negotiated before it gets to HTTP, and the domain name is not part of the negotiation. Certificates are matched by both domain name and IP address, but there's no way to hand off a different certificate based on the domain name because SSL negotiation doesn't use domain name information during the handshake. That doesn't happen until the HTTP layer. So you need a unique IP address for each virtual web host which has an SSL certificate. If you could move SSL negotiation into the protocol layer and out of TCP, you could switch off based on the domain name given. You could, actually, switch off based on lots of different criteria, but that's how I think most hosters would do it.
XML may be the most overused and oversold format ever. It's neat for a certain set of tasks, but it has no benefit for many things that it is used for.
If you kept the same model of bit-patterning the numbers (network bits high, host bits low), a single byte (or smaller bit pattern) could be added to the packet to represent the number length (00000100 for IPv4 and 00000110 for IPv6).
Lookups could be speeded up because you could pre-hash the router lookup table by separating IP networks by length of their number. If a packet came in with an IP number length of 7, you could search for a routing solution straight out of the "size 7 table", skipping all the networks listed in the size 4, 5 and 6 tables.
I see no fundamental barrier to something like this.
Get to bed at the same time every night, and go early, not late. Lose the Conan/Kimmel/Leno habit.
Plan for 8-10 hours of sleep, not 8 max.
Eat light in the evening, but don't go to bed hungry.
Don't drink alcohol in the evenings.
Drink a little water before bed. Blow your nose. Go to the bathroom.
Focus on something untroubling before bed, such as a crossword puzzle or memorize a list of foreign language words.
Exercise regularly, and exercise hard, but never in the evenings.
Keep your bedroom dark and quiet. Install heavy curtains to block all light and keep meowing cats, barking dogs, etc. quiet. Use earplugs if you have to.
Lots of warmth, light and oxygen in the daytime. Open all your curtains, turn on overhead lights and open windows to let fresh air in. Turn the A/C down so it's a little warmer inside during the day.
Turn down the A/C so it's cooler, around 66F or less, at night.
First, I would re-design IP to take variable-length addresses, so IPv4, IPv6 and everything else to come are all compatible and interchangable.
Then I would re-design DNS so that you have to provide not just a domain name to resolve to an IP number, but a "resource type" such as SMTP, HTTP, etc. (similar to MX records, but generic). Each resource type would have its own associated IP number and port.
I would unify all the protocols under a single HTTP-like protocol and make everything, FTP, SMTP, NNTP, etc. a direct extension of it.
I would merge CGI and SMTP DATA into a single "data" mechanism that could be used with any of the protocols uniformly.
I would clean up the protocol so it's possible to concatenate multiple lines together without ambiguity, and uniformly, so the method for multiple line headers is the same as multiple lines of data.
I would also move SSL authentication into that protocol, rather than having it at the TCP level. This would make shared hosting simpler and would save us a LOT of IPv4 numbers.
I would peel the skin off of anyone who suggests that XML become an integral part of that protocol. XML is wordy, wasteful, hard to read and should be a high-level choice, not a low-level foundation.
That's not all I can think of, but that's all I'm going to bother with right now. =)
Documentation for inexperienced computer users would probably be better provided by the private publishing sector. Writing software documentation for those users is a monumental authoring task. If the market is that wide, there's probably money to be made by third-party authors who can tackle that level of writing. I would never expect programmers to EVER be able to provide that kind of documentation.
I never said I wasn't trying to get a response from you, I said your lack of response has made insulting you a fun and easy experience. Don't get me wrong, I did want a response, because that's fun, but there's still a substantial sweet pleasure in making you my bitch....and you are definitely my bitch, you skeezy fatherfucker. LOLOL
ROFL But I am laughing at you! You have taken more insults without a decent comeback more times than I can count, and you appear incapable, both in intellect and courage, to do so. It's definitely funny, tater, you're just desperately trying to make it seem like it's not funny. What a coward. LOL
Slashdot Mirror
I have to second this: Kivio works fantastic.
* It's for KDE, so you can print directly to postscript or a PDF.
* Connect objects permanently and re-arrange them on the page without losing your connection lines.
* Use any font face/size installed on KDE.
* Multiple lines of text.
* Create multiple pages in a single document.
* Use any of 16 built-in arrowhead types.
* Control line width and color.
* Use object shapes and graphics from a huge collection of stencils.
* Open source and free.
I just poked around with it to see what KDE had for diagraming and, as always, was floored by the quality.
I'll see your +1 Troll and raise you a point for posting absolutely nothing of value. Dumbass.
Great suggestion, I think people with large volumes can really benefit from that advice.
I'm glad to see not EVERYONE makes useless posts to Slashdot just to hear themselves harrumph around acting like know-it-alls who run around rebuffing everyone who tries to help others with a little advice, but never offer any advice themselves.
+1 Insightful to you, my friend.
Have cron create a .tgz backup regularly, and download it through scp on your Windows machine.
Yes, learning to type is still necessary. However, I think the number of untrained typists these days proves that you can type quite well without formal training. Learning to type the formal way can speed up your rate and accuracy, but it's far from necessary.
Do we really need an article for every corpse flower that blooms anywhere in the world?
I almost always use a middle layered server that buffers calls between applications and the database. It's job is really to coordinate transactions, users and to perform tasks that go faster natively than through a database. A middle tier invariably makes it FAR simpler switching from one database engine to another than trying to port stored procedures.
...they could make pregnant teenage girls unscrew themselves.
No, I said they learn the hard way AND by interviewing experienced users and the developers. Here's what I said, verbatim:
Books on programming languages yes, languages change slowly overall. Individual open source applications often change rapidly. The books come out at best 6 months to a year after a version of the application comes out. By that time there may already have been several versions released (depending on the project).
Books don't go so far out of date they become useless to an inexperienced user learning how to use an open source application. The book teaches them how to use it; project reference shows them the current, precise way of doing a particular thing.
You're missing the point of virtually everything I say and turn everything into a point of contention while not adding to the discussion at all. I'll lay out it again; this is everything I've said right from the beginning:
Open source project developers need to provide better documentation. It needs to be good enough for experienced computer users, but shouldn't require users to be C programmers and shouldn't require them to study source code. Documentation good enough for inexperienced computer users is best provided for by third-party private authors and publishers; they have excelled in this arena historically, and will continue to do so (O'Reilly is an excellent example of this).
What the hell is there in any of that above to contend with!?!?
There are problems with using site-variable port numbers: it makes identifying traffic types a little tricky
This IS a real problem with the idea, but I think it could be worked out with some creative thinking.
Someone types in example.com - what do you need to lookup? www.example.com A, example.com A, example.com SRV? What about sites where these are different - which address do you connect to? Then, do you send them off all at once (reduces delays in the common instance but has a tendency to increase delays overall)? How long do you wait for replies? - they could come back out of order. Or do you send them serially, which will add some delay to the majority of lookups, but is on-the-whole friendlier to the networks and DNS servers.
You can still map IPs to any canonical name you want; "use IDs" wouldn't change that. You just need to provide the "use ID" to get the IP for the server you want to connect to.
One nice thing about "use IDs" though is you can STOP using canonical names like www.domainname.com to map IPs to protocols, and use them only for mapping to hosts. You would only have domainname.com and a "use ID" of HTTP. You would also have "use IDs" for other protocols used with the domain name, and you could return a different IP+port for each of them.
A web browser vendor is unlikely to be particularly happy to add and default-enable a feature that adds to the time taken to resolve the majority of names - but realistically, you won't have very high takeup on the server side until most clients threaten not to connect unless it's done. For newer protocols it's simpler, since there often need be no fallback to A record, and indeed SRV records are being used on some newer protocols. Still, the traffic identification problem is still there.
Remember, this is a re-design. I wouldn't take into account any difficulty they have converting their software to the new way of doing things. We're designing to "get it right."
Adding this to HTTP is a bit different than the case with adding MX to email: many more people will notice the increased time to resolve the name. With email, the delay is in the background, after the message has left the end-user's mail client and enters the transport system: it's almost invisible. With interactive requests such as HTTP, any delay is immediately obvious.
Why would it take more time? The only difference is that you're giving the DNS server a "use ID" and it looks up the domain name, then finds the IP+port which is mapped to that ID. That shouldn't take any noticeable additional time.
Since it doesn't really buy you anything you don't get from an address-translating device on the IP address of example.com, and given the complexities and problems it adds, who's going to use it?
Everyone, it's how things would be done in the re-design; you would have no choice.
Now I think you're just trolling, or not reading what I am writing very closely.
I don't know many experienced computer users who do it that way. Most I know beat the software with a stick and if all else fails check the documentation, if that fails check google. If that fails check other engines. If that fails, find other software.
This is precisely what I said: most experienced computer users learn the hard way. This is how authors do it and then they write documentation that is easier for people to understand.
The program is worthless if nobody can use it. Or if only people who have learned through a chain of word of mouth, starting from the developers, can use it.
What is your point? Have you not read anything I've written?
I've seen plenty, check o'reilly, there are almost no books pertaining to open source that aren't co-authored by a prominent project developer. Now if you were thinking something along the lines of dummy books, I certainly wasn't talking about that.
Again, you didn't read what I wrote. I said authors interview developers as part of their research to write their books.
For that matter I'm not even sure the dummies series of books DESERVES existance. O'Reilly books are better examples. O'Reilly books don't require you to be experienced to understand, but aren't dumbed down to the point of being useless either.
That's for each person to decide for themselves. I have heard they help a LOT of people, and they are EXTREMELY popular.
There are three reasons I don't believe books are the answer to documentation. 1, it takes too long, by they time they go through all the levels of red tape, editing, rewritting, (loop 200000 times) and then go through a similar process except pertaining to actual printing and advertising etc. They are outdated by the time they hit the shelves.
This is flat-out untrue, and now I am sure you are a troll and/or an idiot. Books are an invaluable resource for everyone, even for highly experienced programmers.
Second, nobody is going to use an application if they have to buy a book to get it installed and in a basic functional configuration. Rule of thumb, if there is any chance a company with less than 500 employees might do it, or a user at home, then it's a basic functional configuration and nothing involved should be considered "advanced".
You still aren't reading what I wrote. Successful projects provide enough documentation for experienced computer users. The entire topic has been about improving the documentation for OPEN SOURCE PROJECTS to allow them to be used by inexperienced computer users.
Inexperienced computer users can get Apache running. Only because books are available which make it simple and straight-forward. Prior to those books being available, you had this: http://apache.org/. Tell me an inexperienced computer user can get Apache going from the docs provided by the Apache foundation. They can't. Third-party commercial documentation is the only way to provide that sort of documentation, unless a professional author wants to donate his/her time to the project, or a particularly talented developer has the time for it.
Third, there are a shitload of books out there, how am I to know which is the up to date project approved documention for "Program X". Or are you suggesting that as well as providing no useful information for actually running a program, the project should not even have a 3rd party they ensure has that available?
That's why you read book reviews and talk to other people. Why are you asking me? You don't know how to select a book?
The rest of your drivel is annoying the shit out of me and is becoming plain non-sensical. I don't mind exchanging ideas, but you're just arguing to hear your own voice, I think. You aren't paying attention to anything I say, and you are saying ludicrously stupid things like "I don't think books are the answer to documentation."
Get your fucking head on straight and then continue the conversation, or just go fuck off.
If every nook and cranny isn't documented, how exactly is it you expect professional authors to learn them?
You do realize that authors today do this very thing? It isn't a matter opinion that they do: it's a fact. They learn the hard way, the way experienced computer users do, and by interviewing users familiar with the software and even the developers themselves. Then they author something more digestible for inexperienced users.
Professional programmers work on open source projects, some with and some without pay. What on earth makes you assume these things have to be done without pay?
How do you propose a dedicated, professional author be paid for his/her work if they don't write a book and get paid for it?
In many cases there is a commercial conflict of interests on open source projects though. Usually the prominent developers get paid for support (either directly or by co-authoring books), there wouldn't be as much demand for this with good solid documentation.
I haven't seen many books written for projects by the developer's themselves. The vast majority of technical books for open source software are written by third-party authors, who get paid for their work directly.
The programmers themselves should NOT be providing the documentation, they should be recruiting volunteers for that purpose.
Unfortunately, the vast majority of software projects out there have the programmers themselves writing the documentation. It would be nice if things were otherwise, but that's how it is, and that's probably why documentation is such an issue right now.
Full documentation, and no I'd completely disagree, it should NOT be a book sold by a 3rd party.
You're misreading what I said and meant. Full documentation doesn't provide hand-holding tutorials through every single nook-and-cranny a user might need or want to learn about. Full documentation is just that: full documentation. Inexperienced computer users don't usually make much sense out of regular, full software documentation. They learn much better from "Dummy" books, and they progress from book to book as they raise themselves up in competence. I don't think software projects should be providing that sort of documentation; it's far too tedious. That should be left to the private sector. There's a lot of tedious work involved, and it's almost ALWAYS done best by experienced authors who make their living at it.
Perhaps professional authors would like to join the open source movement and start authoring for OSS projects for no pay. I just wouldn't hold your breath waiting for that. More than likely, the best you can hope for is for the developers to provide better regular documentation, and leave the hand-holding to the professional authors.
I actually think the article was redundant.
You understood my DNS idea, I just wanted to add to your comments.
Relying on a port number would require either server (or a third server, mostly likely) to dispatch requests to a single IP, then route traffic to other IPs based on intended use. He wanted the shift the burden of traffic differentiation up a level.
This isn't how it would work. When a client resolves a domain name, it would provide a domain name and "use ID" and would get, in return, an IP address and port and would go directly to the IP/port.
It would put too much of a burden on the DNS system, only to make the lives of select few domain admins easier.
It wouldn't be any more difficult than what all mail clients have to do right now to determine the MX record for a domain name. All software would have to provide that "use ID" and then connect to an IP/port, rather than how things are done now where there is no "use ID" and the port is assumed. It wouldn't burden anyone very much.
I just cannot see length being an issue again
I guess I this at the core of the issue for me. I can imagine not being to imagine right now needing anymore than what IPv6 allows.
It's not just a matter of having enough addresses for all the hosts we may have, there's an allocation issue. Every network is going to watch giant swaths of address space, so the ceiling that IPv6 provides is much lower than the sum of hosts that can fit in it. Lots of addresses are going to go to waste in one network while other networks starve for addresses.
I just think "fixed" length addresses is going to bite humans in the butt again one day.
SMTP/HTTP are not resource types. They are protocols.
... I guess you'd make every protocol SSL-tunneled? I mean, I think it's a good idea (more plaintext services becoming encrypted == better), but you can already do that, and the main reason that people don't is because of (now archaic) patent issues and because of CPU load. Also, SSL adds overhead, not just on the CPU, but in latency.
You could have a "WWW" resource type, I guess.
My idea was to change DNS to allow IP numbers to be returned for arbitrary identifiers the way MX works, but more generically; not "resource types" per se. You can store numbers for HTTP, WWW, MAIL, TELNET, PORN, whatever you want.
This is already done, with well-known ports -- the advantage of using well-known ports is that the additional network traffic and latency is avoided.
Well-known ports are very problematic in that it assumes there are a fixed-number of protocols to assign standard ports to, and it assumes everyone is cooperating. By allowing the arbitrary identifiers to determine the port, you can drop "well known ports" altogether.
Hmm. I dunno. I guess you could wrap these in HTTP, but where's the benefit of doing so? You can't really reuse any significant functionality and you'd slightly increase complexity (since everything would need to be linked to an HTTP library).
Lots of reasons, but the two main ones I can think of are: combined code base (as quality of code increases, it increases for all protocols) and it would make it easier to implement protocols and work with them. All the different internet protocols, while very similar, have their own little quirks.
Also, any time you added some desired new feature to the protocol, it is immediately available to all the descendant protocols.
(DATA MERGE) Hmm. I'm not quite sure what the benefit to doing so would be.
Same as above; uniformity and a central code base simply makes it easier to implement, debug, etc. It's just a code quality, efficiency thing.
I would clean up the protocol so it's possible to concatenate multiple lines together without ambiguity, and uniformly, so the method for multiple line headers is the same as multiple lines of data.
Wouldn't this just impose overhead on protocols that use an eight-bit-clean and non-line-oriented interface, like FTP DATA?
I would actually keep the data channel FTP has and make that part of the protocol; it's very efficient. Although perhaps I would make it part of the new data scheme, where you would provide metadata through the protocol, and deliver the data either through the protocol or, optionally, through an 8-bit data connection.
Not sure what you mean
This would make shared hosting simpler and would save us a LOT of IPv4 numbers.
I don't see why this would be the case.
Hmm...hard to explain briefly. Virtual hosting is done at the HTTP layer; when a connection is made, browsers request resources by providing a domain name and resource. A web server can "switch" off to the appropriate virtual host using the domain name given. SSL is negotiated before it gets to HTTP, and the domain name is not part of the negotiation. Certificates are matched by both domain name and IP address, but there's no way to hand off a different certificate based on the domain name because SSL negotiation doesn't use domain name information during the handshake. That doesn't happen until the HTTP layer. So you need a unique IP address for each virtual web host which has an SSL certificate. If you could move SSL negotiation into the protocol layer and out of TCP, you could switch off based on the domain name given. You could, actually, switch off based on lots of different criteria, but that's how I think most hosters would do it.
XML may be the most overused and oversold format ever. It's neat for a certain set of tasks, but it has no benefit for many things that it is used for.
I disagree with whomever feels that way, then.
If you kept the same model of bit-patterning the numbers (network bits high, host bits low), a single byte (or smaller bit pattern) could be added to the packet to represent the number length (00000100 for IPv4 and 00000110 for IPv6).
Lookups could be speeded up because you could pre-hash the router lookup table by separating IP networks by length of their number. If a packet came in with an IP number length of 7, you could search for a routing solution straight out of the "size 7 table", skipping all the networks listed in the size 4, 5 and 6 tables.
I see no fundamental barrier to something like this.
Get to bed at the same time every night, and go early, not late. Lose the Conan/Kimmel/Leno habit.
Plan for 8-10 hours of sleep, not 8 max.
Eat light in the evening, but don't go to bed hungry.
Don't drink alcohol in the evenings.
Drink a little water before bed. Blow your nose. Go to the bathroom.
Focus on something untroubling before bed, such as a crossword puzzle or memorize a list of foreign language words.
Exercise regularly, and exercise hard, but never in the evenings.
Keep your bedroom dark and quiet. Install heavy curtains to block all light and keep meowing cats, barking dogs, etc. quiet. Use earplugs if you have to.
Lots of warmth, light and oxygen in the daytime. Open all your curtains, turn on overhead lights and open windows to let fresh air in. Turn the A/C down so it's a little warmer inside during the day.
Turn down the A/C so it's cooler, around 66F or less, at night.
Be good to your loved ones.
First, I would re-design IP to take variable-length addresses, so IPv4, IPv6 and everything else to come are all compatible and interchangable.
Then I would re-design DNS so that you have to provide not just a domain name to resolve to an IP number, but a "resource type" such as SMTP, HTTP, etc. (similar to MX records, but generic). Each resource type would have its own associated IP number and port.
I would unify all the protocols under a single HTTP-like protocol and make everything, FTP, SMTP, NNTP, etc. a direct extension of it.
I would merge CGI and SMTP DATA into a single "data" mechanism that could be used with any of the protocols uniformly.
I would clean up the protocol so it's possible to concatenate multiple lines together without ambiguity, and uniformly, so the method for multiple line headers is the same as multiple lines of data.
I would also move SSL authentication into that protocol, rather than having it at the TCP level. This would make shared hosting simpler and would save us a LOT of IPv4 numbers.
I would peel the skin off of anyone who suggests that XML become an integral part of that protocol. XML is wordy, wasteful, hard to read and should be a high-level choice, not a low-level foundation.
That's not all I can think of, but that's all I'm going to bother with right now. =)
Documentation for inexperienced computer users would probably be better provided by the private publishing sector. Writing software documentation for those users is a monumental authoring task. If the market is that wide, there's probably money to be made by third-party authors who can tackle that level of writing. I would never expect programmers to EVER be able to provide that kind of documentation.
That has nothing to do with anything, spongebrain.
Remember this?
you're calling me names trying to get an angered response
You said I was trying to get a response from you, so I said:
I never said I wasn't trying to get a response from you
Brain on, dumbass. ROFL
I never said I wasn't trying to get a response from you, I said your lack of response has made insulting you a fun and easy experience. Don't get me wrong, I did want a response, because that's fun, but there's still a substantial sweet pleasure in making you my bitch. ...and you are definitely my bitch, you skeezy fatherfucker. LOLOL
ROFL But I am laughing at you! You have taken more insults without a decent comeback more times than I can count, and you appear incapable, both in intellect and courage, to do so. It's definitely funny, tater, you're just desperately trying to make it seem like it's not funny. What a coward. LOL