All it takes is defining a specialized version of "use strict" that reduces the language down to what you need, and suddenly perl 6 is some very simple, simple, easy to understand language
And I'm not so sure I agree with this approach, since new developers would need to be trained first on Perl6, and then on the "enterprise"'s special enhancements to the language meant to reign it back.
Everyone should keep in mind that all of Perl6's new complexity, its new features and grammars are optional. You can very easily continue to write very simple, very readable scripts (and in many cases, even simpler and more readable than Perl5). The extra "stuff" is there for when you actually do need it, for when you're trying to do tricky stuff or trying to optimize your script by providing hints to the compiler. I wouldn't want some enterprise language layer mucking those abilities up for me.
Perl 6 is as hairy as you want it to be, and no more.
Keep in mind that all of Perl6's new "cleverness" will be completely optional! If you don't want/need strong typing, you can completely ignore the new type system and continue to go typeless.
This is one of the things that makes Perl so attractive as a utility and a glue language: you can continue to do the simple stuff very easily, but you now have more tools to do the complex stuff too.
And as another poster pointed out, the language is entirely adaptable (at the expense of readability and maintainability by others, obviously), and you could always write a new front-end to the Parrot VM in whatever language you want. They already have several. Perl6 is just the new emerging Perl.
Even though this article isn't really about DLL's, why do we have NEWER versions of DLL's breaking applications anyway? The whole point of making a new minor release of a piece of software (DLL, component, whatever), is to fix things, NEVER to change the API or change the behavior of existing functions. It's these changes that break existing applications.
New major releases should be considered a completely different DLL/component, since it conceivably has a different API or changes its behavior in some incompatible way.
It seems to me that DLL's/components need to be treated as self-contained applications. They need to go through a rigorous testing and QA cycle (except that they don't generally expose anything directly to the users, but to other applications), and need to be installed as if they were their own application. Windows applications that have dependencies on DLL's can, during installation, tell the OS which DLL's they need and what the minimum version should be.
Bundle these with the application if you need to, but to suggest that DLL's/components need to be kept at the same *minor* version to avoid breaking applications indicates a bad problem with how you build and test DLL's. I'd rather fix this problem than introduce this layer of version matching.
Once you scale yourself up to large mega-cabinet servers with dozens of processors, hardware partitioning, OS virtualization, etc., you're in the right ballpark, and Linux doesn't play there yet.
I haven't seen stability problems either, at the scale Linux operates at.
Step 1. Turn brightness all the way down and contrast all the way up.
Step 2. Turn brightness up just below the point where 'black' ceases to be black.
Step 3. Turn contrast down to the point where 'white' matches the intensity of ambient white.
Step 4. Adjust gamma to the point where rows of white/black/white/black lines look about the same as 50% gray (usually a side-by-side comparison)
Step 5. Adjust color temperature (or other color-matching settings) so that 'white' matches the color of ambient white. Some applications ship with color matching tiles so that you can fine-tune red, green and blue to match real-world colors on the tiles.
You do remember that DSL runs over your EXISTING phone line. Do you remember that much?
Just having copper is insufficient. DSL has high signal requirements and ceases to function reliably over extended distances that normal telephone connections require.
The solution is to construct "mini-central offices" in places where line lengths are extended in order to reliably provide DSL service.
Frequently line quality itself is poor, requiring some copper lines to be re-run.
All of this costs money, obviously. Things aren't as simple as you'd like to believe. To suggest that all the phone companies need to do is flip a switch to provide DSL to everyone that has copper is rather silly.
If you're really bothered by the fact that Microsoft knows you've just downloaded a particular software patch from them, perhaps you should consider a different mechanism and vendor for getting software patches.
He wasn't saying the reporter wasn't doing anything illegal. He was trying to point out that criminal trespass (as opposed to an ordinary trespassing charge) would require criminal intent, which is usually quite absent in situations like this.
Now I'm not saying he's right, as I'm not a lawyer, but it seems as though you missed his point. The reporter can probably still be charged with something (and maybe even something fairly nasty), but not with the crime that the original poster was talking about. (At least that's what he was trying to say...)
Don't be a troll. DPI is just as valid in the world of monitors as printers. Maybe "PPI" (pixels per inch) might be more appropriate, but it's stupid to invent new terms when the existing one works just fine.
Really, when you change screen resolutions, you ought to change your system's DPI settings to compensate, so that a 12pt font looks the same size no matter what screen resolution you're running at. So, you see, DPI settings do have a value in the world of computer screens.
why everyone says that having light from a lightbulb flickering at 60hz reflected into your eyes via a sheet of paper is inherently better
It takes a certain amount of time for light to "fall off" when an electrical current stops or is reversed. For typical incandescent filaments, that "fall off" time is very long, so you would find it very difficult to measure any flickering.
For fluorescent lamps (especially older ones), the difference is more severe, as the light falls away rather quickly. Fluorescent lights used to be a huge health issue in offices. Nowadays, the phosphores tend to emit light for longer periods, so the flickering isn't as bad.
Monitors are the worst, though, since they need to be able to react to high-speed motion, so the image persistence needs to be very short.
Fortunately, you'll be hard pressed to find a monitor nowadays that's limited to 60Hz. 85Hz is typically a standard minimum and that tends to reduce the apparent flickering significantly (though there will always be some that say they can still see it). Get up to 100Hz or better and you're fine.
b) increase the contrast to maximum, decrease the brightness all the way down (or as far as it will go down)
This is the wrong way to go about it. Generally, good color calibration tools require that you first set your monitor's brightness and contrast settings to a "sane" value first, where that "sane" value means the brightest white on your screen matches the brightest white around your screen (e.g. a sheet of paper). The goal there is to match your monitor's lighting with your ambient lighting. Once that's done, additional gamma or color profile settings can be used to scale your grays and match colors properly. But still, fixing your lighting is probably the biggest thing to help your eyes.
Studies actually show the opposite is true: reading dark text on a light (reflective) background is easier on the eyes.
You're right in that the biggest contributor to eye strain here is the bright flickering light in your eyes.
The solution to this is to operate your monitor at the highest refresh rate it will support and to adjust the brightness, contrast and color temperature settings to match your environment. If I open up a window that's all white, and hold up a white sheet of paper next to the monitor, the brightness and color should match. For me, this means raising the refresh rate of my monitor to 85+Hz, dropping the color temperature rather significantly and reducing the contrast.
Secondary to that, consider raising the resolution of your monitor as high as it'll go without sacrificing the refresh rate. To compensate for the apparent shrinkage in size of all of your display elements and text, instead of just making those things bigger, raise your system's DPI settings. In theory, everything should look exactly the same size that it did before you raised your screen resolution, except it'll be sharper and clearer. A 12pt font should appear the same size regardless of medium and resolution.
A lot of readability problems have to do with poor lighting. Really, the brightest white on your screen should match both the color and luminosity of a piece of white paper held up next to it.
Adjusting your monitor's brightness, contrast and color temperature settings can make a huge difference in eye strain.
The second recommendation I would make would be to put your monitor at the highest resolution and refresh rate it'll support (don't sacrifice resolution for refresh rate, though) and adjust your system's DPI settings to compensate. This ensures a 12pt font is displayed as 12pt and not scaled to something annoyingly small.
Why is it bullshit? They're SBC's lines! They paid for the copper and it was there guys that ran the lines. You're saying they should just let anyone and everyone walk in and do "maintenance" on them?
And when they fuck it up, who has to fix it? SBC, of course.
What if one of the two operating systems doesn't even use an ASCII-based character set? Transferring text from such an OS to a Windows PC would cause the text to be unreadable, to say nothing about something minor like newline conventions.
What you don't seem to be accepting here is that text is a logical data format, not a binary one. Text is a sequence of characters. A character set and newline convention "render" that sequence into an octet stream. That octet stream is specific to that character set and newline convention.
How is an automatic newline conversion bad?
Are you honestly suggesting that every text manipulation software in the world stop using native OS calls to manipulate text and start working at the binary level, "detecting" things like character sets and newlines? Why even have a native text format at all then if you're going to avoid it?
I don't think you're looking at the bigger picture here.
I know that's not directly addressing your concerns, but it does point out that DNS is a better "real world" locator than you believe.
Only because of litigation, only because bigger "more visible" companies have managed to weasel "their" domains from other perfectly reasonable holders.
Your examples only work for well-known entities that either grabbed those DNS domains early, or were able to litigate to claim ownership of them. Every "confusingly similar" DNS domain now belongs to the companies that have the resources to take them, and that is what makes DNS a workable "locator service" for those companies.
But what about the small guys? There are a hundred companies that could just as easily claim ownership of "apple.com" but they can't, because it's already claimed. So they have to lengthen things, maybe "apple-bookstore.com", "applebookstore.com" or a handful of variants, so that DNS *can* be used as a locator for their business. What about a different "apple bookstore" in a neighboring state? Both have just as much claim to this same name.
Just because you use DNS today as a locator service does NOT mean DNS should be in this role, or that it even does this job very effectively.
This is making the bad assumption that phone numbers are currently and will always be mapped to political (ccTLD) boundaries.
Phone number prefixes (country codes) are actually handled by the ITU, so "top-level" numbers in a given phone number are not under the control of the country they map to.
In addition, a lot of countries use the same prefixes (e.g. US and Canadian numbers). If you're looking at a phone number, how will you know which country-specific TLD it's supposed to map to? You'd have to do another lookup to figure out which TLD has ownership of that prefix, then do a lookup against that TLD's phone number set.
Phone numbers are really already built with sufficient information to get it routed to the right geographical region anywhere in the world. They were designed that way. That's how international dialing is even possible. It seems redundant to try and force these numbers within political boundaries of a ccTLD when the number itself already has sufficient information to support delegation.
No, in-addr.arpa is used for Internet address lookups. The arpa TLD is there to act as a TLD for services like this. The service itself is always represented as a second-level domain under arpa.
In my experience, saving text files (e.g. html, css, text) from within your browser yields unpredictible results. Sometimes I get Unix newlines in the file, sometimes I get DOS newlines. So user agents today do not appear to universally translate this for us.
I believe the HTTP spec just says user agents should *treat* all newlines equally, in that it's all whitespace, though it doesn't explicitly say how the browser should save that text should the user ask it to be saved.
Plain-text should be saved using the OS-native text conventions, not as a binary stream that's "close enough" to plain-text.
But, again, conversions are a transport-layer issue (HTTP), not a user-agent issue. Browsers shouldn't have to know how every other OS handles its text. It should just have to know about the network/canonical form and the native form (assuming it allows saving).
Or, even better, the OS should have a library designed to go from network/canonical form to/from native.
Remember also that not all OS's use ASCII-based character sets...
Not a lot, provided the newlines are sane and consistent. In my opinion, though, user agents shouldn't have to do that work in the first place. The only piece of software that can know for sure what the newline convention is of that document is the web server itself. It knows this because it's running on the system that this text sits on. Only this software is in a position to know how to turn this logical, native text into a network-friendly octet-stream. What the HTTP spec has basically done is to say, "Everyone that uses Unix/Win32/MacOS newlines can use whatever of the three they want, but everyone else must convert to Unix/Win32/MacOS newlines." This isn't very fair.
There *is* a canonical text representation in most every Internet protocol (including HTTP headers themselves). But since the HTTP authors figured that there were going to be lots of web server operators that were going to be serving up text/* content without proper native newlines, and/or web server authors were going to write web servers and that didn't know how to convert text to a canonical form, they said "Yah, we know MIME and HTML specs say that text should have newlines represented with CRLF, but we're not going to make you do that." So now they've taken something that could have been handled with authority on the web server side and turned it into something that has to be handled with guesswork on the user agent side.
I'm not saying that web servers and user agents *can't* work around this short-sightedness 99% of the time with this guesswork, but I do think that all of this could have been done cleaner in the first place. After all, FTP knows nothing about media types. If it did, there wouldn't need to be separate user-selectable modes for 'ASCII' and 'Binary', it would just automatically know that text/* is text, and should have newlines translated in transit. HTTP has that advantage over FTP, yet they chose not to take advantage of it, prefering instead to try and make things easier on web server and user agent authors, at the expense of text usability.
The very reason we have more than one newline format is because plain-text is more of a logical concept than a "hard" binary concept. A logical plain-text character can be represented a number of different ways in the actual binary stream, depending upon the character set used and the newline encoding convention.
What you're basically advocating is to have people sending text files in their own local native OS format, which means that these files will be unreadable on incompatible operating systems. Have you ever tried to read a Unix text file on Windows, or a Windows text file on MacOS? You have to figure out what newline convention is in use and convert it before it's usable in your native OS.
Remember that "text" is a logical concept here. You cannot tie plain text to an octet stream without knowing the character set and newline convention. To suggest that all text be treated as an octet stream isn't very realistic.
HTTP basically works around the problem by saying every major newline convention is acceptable, and leaves it up to the browser to figure out what it's doing and how it should save stuff, while FTP does explicit conversions in-transit. The FTP option is far cleaner.
FTP has generally better support for transferring plain-text. By downloading a document using the ASCII protocol, FTP automatically fixes up newline conventions to match your native OS. HTTP doesn't do that and requires user agents to respect most every ASCII-based newline convention. Unless your user agent is really intelligent in that regard and fixes up newlines automagically, you'll probably end up with text using newlines incompatible with your environment.
This is one area that I feel HTTP was deliberately weak on. I can't see any reason why HTTP couldn't require any text/* media type to be sent in a canonical format, with "network" newlines. If every Internet transport protocol did this properly, there would never be a situation where you have a file on your computer using the wrong type of newline.
Slashdot Mirror
All it takes is defining a specialized version of "use strict" that reduces the language down to what you need, and suddenly perl 6 is some very simple, simple, easy to understand language
And I'm not so sure I agree with this approach, since new developers would need to be trained first on Perl6, and then on the "enterprise"'s special enhancements to the language meant to reign it back.
Everyone should keep in mind that all of Perl6's new complexity, its new features and grammars are optional. You can very easily continue to write very simple, very readable scripts (and in many cases, even simpler and more readable than Perl5). The extra "stuff" is there for when you actually do need it, for when you're trying to do tricky stuff or trying to optimize your script by providing hints to the compiler. I wouldn't want some enterprise language layer mucking those abilities up for me.
Perl 6 is as hairy as you want it to be, and no more.
Exactly.
Keep in mind that all of Perl6's new "cleverness" will be completely optional! If you don't want/need strong typing, you can completely ignore the new type system and continue to go typeless.
This is one of the things that makes Perl so attractive as a utility and a glue language: you can continue to do the simple stuff very easily, but you now have more tools to do the complex stuff too.
And as another poster pointed out, the language is entirely adaptable (at the expense of readability and maintainability by others, obviously), and you could always write a new front-end to the Parrot VM in whatever language you want. They already have several. Perl6 is just the new emerging Perl.
Even though this article isn't really about DLL's, why do we have NEWER versions of DLL's breaking applications anyway? The whole point of making a new minor release of a piece of software (DLL, component, whatever), is to fix things, NEVER to change the API or change the behavior of existing functions. It's these changes that break existing applications.
New major releases should be considered a completely different DLL/component, since it conceivably has a different API or changes its behavior in some incompatible way.
It seems to me that DLL's/components need to be treated as self-contained applications. They need to go through a rigorous testing and QA cycle (except that they don't generally expose anything directly to the users, but to other applications), and need to be installed as if they were their own application. Windows applications that have dependencies on DLL's can, during installation, tell the OS which DLL's they need and what the minimum version should be.
Bundle these with the application if you need to, but to suggest that DLL's/components need to be kept at the same *minor* version to avoid breaking applications indicates a bad problem with how you build and test DLL's. I'd rather fix this problem than introduce this layer of version matching.
So what you're saying is that this article is moot and meaningless, since "most Linux users" don't care about high-end Unix features.
Sorry I thought this article was about high-end Unix features, not "most Linux users" features.
Once you scale yourself up to large mega-cabinet servers with dozens of processors, hardware partitioning, OS virtualization, etc., you're in the right ballpark, and Linux doesn't play there yet.
I haven't seen stability problems either, at the scale Linux operates at.
It's usually worded something like this:
Step 1. Turn brightness all the way down and contrast all the way up.
Step 2. Turn brightness up just below the point where 'black' ceases to be black.
Step 3. Turn contrast down to the point where 'white' matches the intensity of ambient white.
Step 4. Adjust gamma to the point where rows of white/black/white/black lines look about the same as 50% gray (usually a side-by-side comparison)
Step 5. Adjust color temperature (or other color-matching settings) so that 'white' matches the color of ambient white. Some applications ship with color matching tiles so that you can fine-tune red, green and blue to match real-world colors on the tiles.
You do remember that DSL runs over your EXISTING phone line. Do you remember that much?
Just having copper is insufficient. DSL has high signal requirements and ceases to function reliably over extended distances that normal telephone connections require.
The solution is to construct "mini-central offices" in places where line lengths are extended in order to reliably provide DSL service.
Frequently line quality itself is poor, requiring some copper lines to be re-run.
All of this costs money, obviously. Things aren't as simple as you'd like to believe. To suggest that all the phone companies need to do is flip a switch to provide DSL to everyone that has copper is rather silly.
If you're really bothered by the fact that Microsoft knows you've just downloaded a particular software patch from them, perhaps you should consider a different mechanism and vendor for getting software patches.
He wasn't saying the reporter wasn't doing anything illegal. He was trying to point out that criminal trespass (as opposed to an ordinary trespassing charge) would require criminal intent, which is usually quite absent in situations like this.
Now I'm not saying he's right, as I'm not a lawyer, but it seems as though you missed his point. The reporter can probably still be charged with something (and maybe even something fairly nasty), but not with the crime that the original poster was talking about. (At least that's what he was trying to say...)
Don't be a troll. DPI is just as valid in the world of monitors as printers. Maybe "PPI" (pixels per inch) might be more appropriate, but it's stupid to invent new terms when the existing one works just fine.
Really, when you change screen resolutions, you ought to change your system's DPI settings to compensate, so that a 12pt font looks the same size no matter what screen resolution you're running at. So, you see, DPI settings do have a value in the world of computer screens.
why everyone says that having light from a lightbulb flickering at 60hz reflected into your eyes via a sheet of paper is inherently better
It takes a certain amount of time for light to "fall off" when an electrical current stops or is reversed. For typical incandescent filaments, that "fall off" time is very long, so you would find it very difficult to measure any flickering.
For fluorescent lamps (especially older ones), the difference is more severe, as the light falls away rather quickly. Fluorescent lights used to be a huge health issue in offices. Nowadays, the phosphores tend to emit light for longer periods, so the flickering isn't as bad.
Monitors are the worst, though, since they need to be able to react to high-speed motion, so the image persistence needs to be very short.
Fortunately, you'll be hard pressed to find a monitor nowadays that's limited to 60Hz. 85Hz is typically a standard minimum and that tends to reduce the apparent flickering significantly (though there will always be some that say they can still see it). Get up to 100Hz or better and you're fine.
b) increase the contrast to maximum, decrease the brightness all the way down (or as far as it will go down)
This is the wrong way to go about it. Generally, good color calibration tools require that you first set your monitor's brightness and contrast settings to a "sane" value first, where that "sane" value means the brightest white on your screen matches the brightest white around your screen (e.g. a sheet of paper). The goal there is to match your monitor's lighting with your ambient lighting. Once that's done, additional gamma or color profile settings can be used to scale your grays and match colors properly. But still, fixing your lighting is probably the biggest thing to help your eyes.
Studies actually show the opposite is true: reading dark text on a light (reflective) background is easier on the eyes.
You're right in that the biggest contributor to eye strain here is the bright flickering light in your eyes.
The solution to this is to operate your monitor at the highest refresh rate it will support and to adjust the brightness, contrast and color temperature settings to match your environment. If I open up a window that's all white, and hold up a white sheet of paper next to the monitor, the brightness and color should match. For me, this means raising the refresh rate of my monitor to 85+Hz, dropping the color temperature rather significantly and reducing the contrast.
Secondary to that, consider raising the resolution of your monitor as high as it'll go without sacrificing the refresh rate. To compensate for the apparent shrinkage in size of all of your display elements and text, instead of just making those things bigger, raise your system's DPI settings. In theory, everything should look exactly the same size that it did before you raised your screen resolution, except it'll be sharper and clearer. A 12pt font should appear the same size regardless of medium and resolution.
A lot of readability problems have to do with poor lighting. Really, the brightest white on your screen should match both the color and luminosity of a piece of white paper held up next to it.
Adjusting your monitor's brightness, contrast and color temperature settings can make a huge difference in eye strain.
The second recommendation I would make would be to put your monitor at the highest resolution and refresh rate it'll support (don't sacrifice resolution for refresh rate, though) and adjust your system's DPI settings to compensate. This ensures a 12pt font is displayed as 12pt and not scaled to something annoyingly small.
And by 'there' of course I meant 'their'. Need coffee..
Why is it bullshit? They're SBC's lines! They paid for the copper and it was there guys that ran the lines. You're saying they should just let anyone and everyone walk in and do "maintenance" on them?
And when they fuck it up, who has to fix it? SBC, of course.
What if one of the two operating systems doesn't even use an ASCII-based character set? Transferring text from such an OS to a Windows PC would cause the text to be unreadable, to say nothing about something minor like newline conventions.
What you don't seem to be accepting here is that text is a logical data format, not a binary one. Text is a sequence of characters. A character set and newline convention "render" that sequence into an octet stream. That octet stream is specific to that character set and newline convention.
How is an automatic newline conversion bad?
Are you honestly suggesting that every text manipulation software in the world stop using native OS calls to manipulate text and start working at the binary level, "detecting" things like character sets and newlines? Why even have a native text format at all then if you're going to avoid it?
I don't think you're looking at the bigger picture here.
I suspect this was a situation where they came to his parents, and his parents agreed to have him arrested to scare him. This isn't that uncommon.
I know that's not directly addressing your concerns, but it does point out that DNS is a better "real world" locator than you believe.
Only because of litigation, only because bigger "more visible" companies have managed to weasel "their" domains from other perfectly reasonable holders.
Your examples only work for well-known entities that either grabbed those DNS domains early, or were able to litigate to claim ownership of them. Every "confusingly similar" DNS domain now belongs to the companies that have the resources to take them, and that is what makes DNS a workable "locator service" for those companies.
But what about the small guys? There are a hundred companies that could just as easily claim ownership of "apple.com" but they can't, because it's already claimed. So they have to lengthen things, maybe "apple-bookstore.com", "applebookstore.com" or a handful of variants, so that DNS *can* be used as a locator for their business. What about a different "apple bookstore" in a neighboring state? Both have just as much claim to this same name.
Just because you use DNS today as a locator service does NOT mean DNS should be in this role, or that it even does this job very effectively.
This is making the bad assumption that phone numbers are currently and will always be mapped to political (ccTLD) boundaries.
Phone number prefixes (country codes) are actually handled by the ITU, so "top-level" numbers in a given phone number are not under the control of the country they map to.
In addition, a lot of countries use the same prefixes (e.g. US and Canadian numbers). If you're looking at a phone number, how will you know which country-specific TLD it's supposed to map to? You'd have to do another lookup to figure out which TLD has ownership of that prefix, then do a lookup against that TLD's phone number set.
Phone numbers are really already built with sufficient information to get it routed to the right geographical region anywhere in the world. They were designed that way. That's how international dialing is even possible. It seems redundant to try and force these numbers within political boundaries of a ccTLD when the number itself already has sufficient information to support delegation.
No, in-addr.arpa is used for Internet address lookups. The arpa TLD is there to act as a TLD for services like this. The service itself is always represented as a second-level domain under arpa.
In my experience, saving text files (e.g. html, css, text) from within your browser yields unpredictible results. Sometimes I get Unix newlines in the file, sometimes I get DOS newlines. So user agents today do not appear to universally translate this for us.
I believe the HTTP spec just says user agents should *treat* all newlines equally, in that it's all whitespace, though it doesn't explicitly say how the browser should save that text should the user ask it to be saved.
Plain-text should be saved using the OS-native text conventions, not as a binary stream that's "close enough" to plain-text.
But, again, conversions are a transport-layer issue (HTTP), not a user-agent issue. Browsers shouldn't have to know how every other OS handles its text. It should just have to know about the network/canonical form and the native form (assuming it allows saving).
Or, even better, the OS should have a library designed to go from network/canonical form to/from native.
Remember also that not all OS's use ASCII-based character sets...
Not a lot, provided the newlines are sane and consistent. In my opinion, though, user agents shouldn't have to do that work in the first place. The only piece of software that can know for sure what the newline convention is of that document is the web server itself. It knows this because it's running on the system that this text sits on. Only this software is in a position to know how to turn this logical, native text into a network-friendly octet-stream. What the HTTP spec has basically done is to say, "Everyone that uses Unix/Win32/MacOS newlines can use whatever of the three they want, but everyone else must convert to Unix/Win32/MacOS newlines." This isn't very fair.
There *is* a canonical text representation in most every Internet protocol (including HTTP headers themselves). But since the HTTP authors figured that there were going to be lots of web server operators that were going to be serving up text/* content without proper native newlines, and/or web server authors were going to write web servers and that didn't know how to convert text to a canonical form, they said "Yah, we know MIME and HTML specs say that text should have newlines represented with CRLF, but we're not going to make you do that." So now they've taken something that could have been handled with authority on the web server side and turned it into something that has to be handled with guesswork on the user agent side.
I'm not saying that web servers and user agents *can't* work around this short-sightedness 99% of the time with this guesswork, but I do think that all of this could have been done cleaner in the first place. After all, FTP knows nothing about media types. If it did, there wouldn't need to be separate user-selectable modes for 'ASCII' and 'Binary', it would just automatically know that text/* is text, and should have newlines translated in transit. HTTP has that advantage over FTP, yet they chose not to take advantage of it, prefering instead to try and make things easier on web server and user agent authors, at the expense of text usability.
The very reason we have more than one newline format is because plain-text is more of a logical concept than a "hard" binary concept. A logical plain-text character can be represented a number of different ways in the actual binary stream, depending upon the character set used and the newline encoding convention.
What you're basically advocating is to have people sending text files in their own local native OS format, which means that these files will be unreadable on incompatible operating systems. Have you ever tried to read a Unix text file on Windows, or a Windows text file on MacOS? You have to figure out what newline convention is in use and convert it before it's usable in your native OS.
Remember that "text" is a logical concept here. You cannot tie plain text to an octet stream without knowing the character set and newline convention. To suggest that all text be treated as an octet stream isn't very realistic.
HTTP basically works around the problem by saying every major newline convention is acceptable, and leaves it up to the browser to figure out what it's doing and how it should save stuff, while FTP does explicit conversions in-transit. The FTP option is far cleaner.
FTP has generally better support for transferring plain-text. By downloading a document using the ASCII protocol, FTP automatically fixes up newline conventions to match your native OS. HTTP doesn't do that and requires user agents to respect most every ASCII-based newline convention. Unless your user agent is really intelligent in that regard and fixes up newlines automagically, you'll probably end up with text using newlines incompatible with your environment.
This is one area that I feel HTTP was deliberately weak on. I can't see any reason why HTTP couldn't require any text/* media type to be sent in a canonical format, with "network" newlines. If every Internet transport protocol did this properly, there would never be a situation where you have a file on your computer using the wrong type of newline.