Technically speaking, whitespace is just another character, so there is no reason to conceptually differentiate it from a brace.
What? There is every reason to differentiate it from a brace. A brace is a clear indicator of something. Whitespace is... nothing. The main use of whitespace is to separate tokens. Overloading whitespace so that it also has syntactic meaning is just ridiculous.
A compiler sees whitespace just as it sees braces,
What utter nonsense. Maybe a "python compiler" does it that way, but I know of no other compiler that puts any such syntax upon whitespace. Not C, not Fortran, not Cobol. No other language I know of does this. Whitespace is simply ignored (except in limited cases like "within a string constant", but that's not a syntactical interpretation of whitespace).
On a site note, I work with Java for a living and I often find myself wishing my co-workers would effectively use whitespace.
This should point out to you the fact that whitespace is a VISUAL concept, not a computer concept, and that different people use it in different ways, because "looks right" is a subjective and not objective goal. Compilers should not care if the code "looks" right, and people should not have to care if the compilers "sees" the code.
Re:Blocks by indentation
on
Hello World!
·
· Score: 1
Wrong. Oh so wrong. Try removing all redundant whitespace from a well-formatted program in a language of your choice (other than Python!) and see how readable it is compared to the original.
I think the point is that it IS still readable by humans and functional to the computer, where the python code will not be functional or readable. In fact, if you do this to C code, you can run it through "indent" and it will come out clearly indented for you. It sounds like such a program is impossible for python because it depends so much on how things are indented to start with.
First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix).
I know of no such "rule as used by Unix". I commonly use a tab setting of 3 or 4 (depends on the day and the complexity of the code) when I edit files on Unix.
Cross-platform compatibility note: because of the nature of text editors on non-UNIX platforms,
It's not a "cross-platform compatibility" issue if the issue appears on the same platform depending on the editor settings, and has nothing to do with Unix or non-Unix.
Re:HTML/CSS/JavaScript
on
Hello World!
·
· Score: 1
Of the three you list, only the last is a programming language.
If you want create a web page designer, teach them HTML and CSS.
If you want to create a programmer, teach them how to tear a complex problem apart into small bits that a computer can understand and then how to express those small bits to the computer -- in any language that doesn't have 500% overhead or arbitrary interpretations based on things like how many spaces are in the line. The former rules out COBOL, the latter python.
FORTH. Yes, you have to learn to think backwards, but it is SO easy to start with a small piece and add and combine them. Thinking backwards enforces decomposition of the process into small bits. In fact, LOGO, IIRC, was a very FORTH-like language that was intended for kids. "Move the turtle so many pixels up, turn so many degrees right..."
Re:Blocks by indentation
on
Hello World!
·
· Score: 1
... but as it is, the requirement is both functional, and visually informative.
Since compilers and interpreters don't have to SEE your code, the "visually informative" requirement exists ONLY for humans. It should not be a requirement for proper execution of the code.
Nor is whitespace a functional requirement -- unless you've defined your computer language to require it, and then you're arguing in a circle. "It's a requirement because I decided to require it" isn't enough to claim it is a functional requirement. Many languages do NOT require it, because they were not defined to require it. The vast majority of languages need whitespace only to separate tokens.
Space and Tab have ASCII codes, and they are represented in whatever interface you're using by a region of white pixels,...
No, they aren't. They are usually represented by SPACE -- a gap -- which usually appears as a section of terminal screen in whatever color the background happens to be. (Black, white, grey, yellow, pink, blue, orange, whatever...) In SOME editors, and on some systems by default, tabs are represented by a specific character, similar to the way an 'A' is represented. Some systems even have a mode where spaces are represented by a special character on the screen (like an underscore with serifs on the end.)
They aren't represented on all systems by the same amount of space, either. Some systems expand tabs to every 8 columns. I set vi to 3 or 4, usually, so that my columns don't run off the edge of the screen as I indent them.
And the same number of characters (space and tab) can result in vastly different "whitespace" representations, even assuming the same interpretation for a tab. "sp/sp/sp/sp/sp/sp/tab" will look VERY different than "tab/sp/sp/sp/sp/sp/sp", even though they are both the same number of characters.
Sane people use tabs to separate blocks for the purposes of readability, anyway. At that point, curly braces become redundant information.
Wow. Programmers who don't use tabs are insane?
No, GOOD programmers use whitespace to make their code readable by humans; they use the syntax of the language to make it readable by the compiler/interpreter. Using the VISUAL representation of the code as input to the compiler leads to nonsense like a language that says "a red flashing italic FOR compiles this way, but a blue flashing bold FOR compiles this other way...". That's just plain stupid, and anyone who defines a language like that would be laughed at.
...so anything different is bound to give rise to the knee-jerk reactions of fear and disgust.
I don't fear python, nor am I disgusted with it. I simply think that whitespace is whitespace for a reason, and that whitespace should not be part of the syntax for a language.
Any language that depends on whitespace to delimit blocks of code (e.g., the code belonging to an IF or FOR loop) is poorly defined. Whitespace exists for visual depictions of code, not internal.
I don't program python, so someone that does will have to answer this question. Does python treat 'tab''sp''sp' at the start of a line as 10 spaces of indent, or two, or 6? Or does it prohibit tabs? The standard 'typewriter' expansion is 8 spaces. When I program, I tell vi to make it four. It's one "character". Which way does python see it? (And the fact that I can ASK this question makes the point that whitespace shouldn't be syntactically important.)
FOSS isn't a reason...
on
Hello World!
·
· Score: 1
FOSS isn't a reason to use a language to teach programming.
FOSS doesn't mean there is a lot of freely available code to look at, FOSS means there is source code for the INTERPRETER that you can modify. I suspect it is written in C or C++, so you don't get any advantages in having the source for the python itself. Now, FOSS is a good argument for using gcc, since you get lots of example code...
Even "closed source" languages have freely available code to look at. MATLAB, e.g..
You do realize that "put your hat on the bar" was simply an example of how customs can be based on arbitrary rules, and not an exhaustive list or even a claim that 'twixt' or whatever was doing the equivalent, don't you?
Putting your hat on the bar doesn't have a direct impact on many people. Dragging them off to be killed in a role playing game while they are trying to chat with someone else does.
If all he had done was obey the rules that didn't involve other people being harmed by his choices, he'd have been ok. When you involve other people in your jihads, they have a right to be upset.
Not because he was being vile or crude (indeed, completely contrary to what you suggest) but by violating game defeating "customs."
Indeed, what is "vile or crude" but violation of customs? While some "customs" are based on well-demonstrated concepts (like Robert's Rules of Order running a meeting), many are simply courtesies and apparently arbitrary rules (don't put your hat on the bar, e.g.).
It sounds like he was extremely "vile or crude" because he chose to violate the customs of the people in the game deliberately. His bad.
I know this is/. and all, but you might want to browse the article, or at least the summary, before commenting.
From the summary, and this appeared in TFA as well, IIRC:
"In 2008, the DHS Science and Technology Directorate awarded a $6.2 million contract to Thales Communications to demonstrate the first-ever portable radio prototype that lets emergency responders -- police, firefighters, emergency medical personnel and others -- communicate with partner agencies, regardless of the radio band they operate on."
HAMs are allowed to encrypt according to a protocol than can be decrpted by a readily available, published method.
Part 97.113 says that "messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein;" are prohibited. (Satellite control signals are one "otherwise" exception.) It doesn't say that "messages encrypted with a published key..." are permitted, and encryption using a "published method" doesn't mean that the message can be decrypted. That's why it's encryption and not encoding. Blowfish is a published method. Blowfish without the key is obscured meaning.
The ones doing HSMM (High Speed Multi-Media, or 802.11b/g) publish the WEP key under the assumption that this is sufficient to avoid the prohibition. Clearly, the messages ARE being encoded to obscure their meaning, with the assumption that nobody but an FCC monitoring station would bother looking up the key and listening in. I don't think this has ever been tested with an official ruling. I don't think anyone really cares that much about such short range communications. In fact, ITU treaties now allow, and Austria (IIRC) has permitted, encryption on domestic traffic above 50MHz (typically short-range). The ARRL was going to ask for this here, but then backed down. I have yet to get an answer from anyone in ARRL staff why.
And this is one reason why morse code (CW) is often used with emergency communications.
No, sorry, CW is used because it can get through when voice or other modes can't, not because it obscures the meaning of anything.
Now, what IS used in emergency communications is FBB compression on packet radio systems (winlink 2000 systems, e.g.). THAT truly is "encoding" that everyone assumes is allowable because the protocol is published and thus not intended to obscure the meaning of the embedded message, even though many EMCOMM ops point to this "encoding" as security for the message. They want to have it both ways.
But after reading this file I'm starting to see how deep the rabbit hole goes.
Yes, isn't VMS fun? The files on THAT system (and many other "old" systems) aren't just "fixed-record-length" because the user wrote the code to treat them that way, the file system itself enforced it.
As I recall, there was a program called "convert" that would change a file from one thing into another, but it required an obtuse and complicated set of parameters. It might have had an option to "make this file look like that file", but I'm not sure.
It was one of the early precepts of Unix that files be "strings of bytes" that the application would deal with, instead of the OS itself. Even so, "strings of bytes" doesn't cover things like Unicode or CRLF/NL differences.
Another wonderful part of VMS was that it ran on the VAX, which didn't follow IEEE753 rules for floating point numbers, and I had the wonderful pleasure of writing code to convert raw data files (with floating point numbers) from VAX to 68000 to whatever.
Does that mean we'll have a single point of failure? Loss of heterogeneity might come at a price...
Ummm, no. Just because all radios use the same digital system doesn't mean there is a single point of failure. All the radios would have to fail. It's not like all the radios using one digital mode must communicate through one node.
Now, there IS a "single point" problem when you try to convert from simple radio systems to trunked, but "trunked" and "digital" are not synonyms.
There is nothing to be gained from "heterogeneity" other than confusion and expense. There is no advantage to a world where one communities police force uses P25 and the neighbors use something else, there is only time wasted trying to communicate when one needs help from the other. It is even worse if the police in a community use P25 and the fire department something else.
Yeah, good luck with that. If it succeeds, it'll be a portable radio that costs $10K.
It's already succeeded. It costs $5k, base. No trunking. It's got a slick LCD display. Color. It's a brick. Heavy. Large.
And Thales is getting a $6 million kickback after creating it, and $5k/radio to sell it (lots of federal grants are obtained with the keyword "interoperability").
I used to think Thales was an innovator. Now I know they are just sucking at the public tit.
...it'll need wide and narrow band coverage of 150, 450, and 800Mhz.
And 700. But who's counting?
Now, the product exists, it's being delivered, where the EMERGENCY?
Sorry, but if that applied to me, I would say "hey, the vast majority of people don't need to do this, so this is (relatively) uniquely my problem and I should find my own solution, such as conversion programs".
The problem is that the vast majority of people wouldn't know when to look for the problem and wouldn't know how to solve it when it appeared. The BEST place to solve this kind of problem is where both ends know it exists and how to solve it automatically. E.g., in FTP, where the server knows about the host's file system oddities and the client knows the client's.
I didn't ask FTP to deal with this, it was dealing with this a long time before I used it. Apparently it solved a LOT of people's problems, not just mine.
Now, since FTP already has this functionality, there's nothing wrong with using it. But that's a far cry from saying that this is really the job of a transport protocol or that it was really a good design decision to put it there.
That's right. The fact that FTP does it is not an argument that it is the best place to do it. The fact that FTP involves a server that knows about the file system it reads and writes files to, and a client that knows about the file system IT reads and writes files to, is why it is the best place to take care of the conversion. It is stupid for a program designed to transport a certain kind of file from one OS to another to simply ignore the fact that that certain kind of file needs to be converted for use.
If you don't want FTP converting things for you automatically, use BIN mode for all your transfers. I like the fact that I don't have to worry about what format the stupid text file is in when I move data around automatically.
Really, FTP worrying about this would be a little like Ethernet trying to detect and transcode streaming video.
Patently absurd. Ethernet is a hardware layer; FTP is a software layer. Ethernet has no concept of what it carries; FTP KNOWS the file structures because it has to.
... I'd be told that this functionality does not belong at the link layer and that it's the application's problem to worry about this.
That's right. And FTP is an APPLICATION. It is THE ONLY application that knows what the source and destination formats are and how to convert them. That makes FTP the right place to deal with the conversion. We aren't just talking about CRLF/NL differences, remember?
The crux of the disagreement is this: some people think that their convenience overrides what would otherwise be recognized as a poor or at least questionable design decision.
No, the crux is that some people are very limited in the experiences they have with data management and transport and assume that everything they talk to is just like what they use at home, and thus no conversions are necessary. In those few cases when they are necessary, they assume that their usage of the computer (download a few files) is what everyone else is doing, and that it is simpler to use a standalone converter to convert the "few files". This leads them to THINK that the FTP design decision was poor, when it really is their understanding of the scope of the problem that is poor.
Other people think that the soundness of a design decision should come first and convenience should be a secondary concern, particularly when there are other, quite viable options for handling the problem.
The other options are not that viable when you are dealing with large volumes of data automatically. The design decision is sound because it is both doing the work where it can be done automatically AND makes life a lot more convenient even for people who have no idea that there would otherwise be a problem.
It is patently stupid to force people to make an additional step to convert a file from an "oddball OS" structure into something usable when the transport software can do it for them. If you want an analogy, it is no different than an email program that forces
And if FTP translates oddball operating systems' conventions for text/plain files, why doesn't it do so for image files (.ppm vs..bmp), audio files (.au vs..wav), or other MIME types?
If those image files are stored in a file structure "oddball" to that OS, it does. You need to differentiate between OS-independent application-specific contents (.ppm,.bmp,.au,.wav, etc) and OS-dependent application-irrelevant ones (CRLF Windows line endings, fixed-record VMS files, etc).
Dealing with a.wav file is completely application dependent; it can happen on any OS. Dealing with a fixed-record length file structure is OS dependent, and once the file is moved from the host OS that information is lost. It has to be converted somewhere, and the easiest place to do that is on the host that knows about that format and how to convert it.
I faced the same issue a dozen years ago. Automated data transfer, reliable, retry, over slow link, etc.
As I wrote down the requirements for the system I was thinking of writing, I realized that every bit was covered by UUCP. And then I realized that t protocol was designed for used over the network.
If you want security, create an SSH tunnel and transport the UUCP over that.
It's not stupid to use existing tools as they were intended. What's stupid is rewriting the wheel.
As far as I can tell, the problem is entirely unique to notepad.
Who rated this "insightful"?
I'm sorry, but I've worked in this area for years. I was responsible for moving data and source files to and from Unix to DOS to VMS to OSs that are even deader than VMS, and the problem is hardly unique to "notepad". YOU may see it only in notepad because YOU only use Windows, but there are a lot of other OSs out there. If you've never worked on an OS that has structured files inherent in the filesystem, well, lucky you. I have. The newlines in those kinds of files are completely lost when you copy the byte stream contents, because the newlines are implicit and defined in the file structure itself. A fixed-record file doesn't need newlines because every line is the same length.
Every other text editor I've ever tried handles files with Unix-style newlines correctly.
There is much more to the world than Windows and Unix-style newlines. If all you have seen is Windows and Unix newlines, I suppose you could think the problem was limited to that, but it really isn't. In fact, if you use FTP much at all, I suspect even you have been protected by ASCII mode, to the point that you never even knew that an FTP site you visited was VMS-based. I know I've been to VMS sites, and ASCII mode is critical if you are dealing with ASCII files.
If a captive's life depends on the NYT keeping their mouth shut then they WOULD be to blame if they did otherwise.
As a resident of Iraq, my life depended upon NOT going to the specific market that a terrorist decided to suicide-bomb today. If I did otherwise, according to you, I am to blame for the deaths, not the suicide bomber.
I find that attitude repugnant, ignorant, and unacceptable for civilized society.
Slashdot Mirror
Jealous?
What? There is every reason to differentiate it from a brace. A brace is a clear indicator of something. Whitespace is ... nothing. The main use of whitespace is to separate tokens. Overloading whitespace so that it also has syntactic meaning is just ridiculous.
A compiler sees whitespace just as it sees braces,
What utter nonsense. Maybe a "python compiler" does it that way, but I know of no other compiler that puts any such syntax upon whitespace. Not C, not Fortran, not Cobol. No other language I know of does this. Whitespace is simply ignored (except in limited cases like "within a string constant", but that's not a syntactical interpretation of whitespace).
On a site note, I work with Java for a living and I often find myself wishing my co-workers would effectively use whitespace.
This should point out to you the fact that whitespace is a VISUAL concept, not a computer concept, and that different people use it in different ways, because "looks right" is a subjective and not objective goal. Compilers should not care if the code "looks" right, and people should not have to care if the compilers "sees" the code.
I think the point is that it IS still readable by humans and functional to the computer, where the python code will not be functional or readable. In fact, if you do this to C code, you can run it through "indent" and it will come out clearly indented for you. It sounds like such a program is impossible for python because it depends so much on how things are indented to start with.
First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix).
I know of no such "rule as used by Unix". I commonly use a tab setting of 3 or 4 (depends on the day and the complexity of the code) when I edit files on Unix.
Cross-platform compatibility note: because of the nature of text editors on non-UNIX platforms,
It's not a "cross-platform compatibility" issue if the issue appears on the same platform depending on the editor settings, and has nothing to do with Unix or non-Unix.
If you want create a web page designer, teach them HTML and CSS.
If you want to create a programmer, teach them how to tear a complex problem apart into small bits that a computer can understand and then how to express those small bits to the computer -- in any language that doesn't have 500% overhead or arbitrary interpretations based on things like how many spaces are in the line. The former rules out COBOL, the latter python.
FORTH. Yes, you have to learn to think backwards, but it is SO easy to start with a small piece and add and combine them. Thinking backwards enforces decomposition of the process into small bits. In fact, LOGO, IIRC, was a very FORTH-like language that was intended for kids. "Move the turtle so many pixels up, turn so many degrees right..."
Since compilers and interpreters don't have to SEE your code, the "visually informative" requirement exists ONLY for humans. It should not be a requirement for proper execution of the code.
Nor is whitespace a functional requirement -- unless you've defined your computer language to require it, and then you're arguing in a circle. "It's a requirement because I decided to require it" isn't enough to claim it is a functional requirement. Many languages do NOT require it, because they were not defined to require it. The vast majority of languages need whitespace only to separate tokens.
Space and Tab have ASCII codes, and they are represented in whatever interface you're using by a region of white pixels, ...
No, they aren't. They are usually represented by SPACE -- a gap -- which usually appears as a section of terminal screen in whatever color the background happens to be. (Black, white, grey, yellow, pink, blue, orange, whatever...) In SOME editors, and on some systems by default, tabs are represented by a specific character, similar to the way an 'A' is represented. Some systems even have a mode where spaces are represented by a special character on the screen (like an underscore with serifs on the end.)
They aren't represented on all systems by the same amount of space, either. Some systems expand tabs to every 8 columns. I set vi to 3 or 4, usually, so that my columns don't run off the edge of the screen as I indent them.
And the same number of characters (space and tab) can result in vastly different "whitespace" representations, even assuming the same interpretation for a tab. "sp/sp/sp/sp/sp/sp/tab" will look VERY different than "tab/sp/sp/sp/sp/sp/sp", even though they are both the same number of characters.
Sane people use tabs to separate blocks for the purposes of readability, anyway. At that point, curly braces become redundant information.
Wow. Programmers who don't use tabs are insane?
No, GOOD programmers use whitespace to make their code readable by humans; they use the syntax of the language to make it readable by the compiler/interpreter. Using the VISUAL representation of the code as input to the compiler leads to nonsense like a language that says "a red flashing italic FOR compiles this way, but a blue flashing bold FOR compiles this other way...". That's just plain stupid, and anyone who defines a language like that would be laughed at.
I don't fear python, nor am I disgusted with it. I simply think that whitespace is whitespace for a reason, and that whitespace should not be part of the syntax for a language.
Any language that depends on whitespace to delimit blocks of code (e.g., the code belonging to an IF or FOR loop) is poorly defined. Whitespace exists for visual depictions of code, not internal.
I don't program python, so someone that does will have to answer this question. Does python treat 'tab''sp''sp' at the start of a line as 10 spaces of indent, or two, or 6? Or does it prohibit tabs? The standard 'typewriter' expansion is 8 spaces. When I program, I tell vi to make it four. It's one "character". Which way does python see it? (And the fact that I can ASK this question makes the point that whitespace shouldn't be syntactically important.)
FOSS doesn't mean there is a lot of freely available code to look at, FOSS means there is source code for the INTERPRETER that you can modify. I suspect it is written in C or C++, so you don't get any advantages in having the source for the python itself. Now, FOSS is a good argument for using gcc, since you get lots of example code ...
Even "closed source" languages have freely available code to look at. MATLAB, e.g..
Well, it certainly gives all the insulting arrogant assholes something to talk about, now doesn't it?
The best part of that ad is "he knows what he'd do for a Klondike bar."
Putting your hat on the bar doesn't have a direct impact on many people. Dragging them off to be killed in a role playing game while they are trying to chat with someone else does.
If all he had done was obey the rules that didn't involve other people being harmed by his choices, he'd have been ok. When you involve other people in your jihads, they have a right to be upset.
Indeed, what is "vile or crude" but violation of customs? While some "customs" are based on well-demonstrated concepts (like Robert's Rules of Order running a meeting), many are simply courtesies and apparently arbitrary rules (don't put your hat on the bar, e.g.).
It sounds like he was extremely "vile or crude" because he chose to violate the customs of the people in the game deliberately. His bad.
From the summary, and this appeared in TFA as well, IIRC: "In 2008, the DHS Science and Technology Directorate awarded a $6.2 million contract to Thales Communications to demonstrate the first-ever portable radio prototype that lets emergency responders -- police, firefighters, emergency medical personnel and others -- communicate with partner agencies, regardless of the radio band they operate on."
It ain't a prototype. It's a production radio.
Part 97.113 says that "messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein;" are prohibited. (Satellite control signals are one "otherwise" exception.) It doesn't say that "messages encrypted with a published key ..." are permitted, and encryption using a "published method" doesn't mean that the message can be decrypted. That's why it's encryption and not encoding. Blowfish is a published method. Blowfish without the key is obscured meaning.
The ones doing HSMM (High Speed Multi-Media, or 802.11b/g) publish the WEP key under the assumption that this is sufficient to avoid the prohibition. Clearly, the messages ARE being encoded to obscure their meaning, with the assumption that nobody but an FCC monitoring station would bother looking up the key and listening in. I don't think this has ever been tested with an official ruling. I don't think anyone really cares that much about such short range communications. In fact, ITU treaties now allow, and Austria (IIRC) has permitted, encryption on domestic traffic above 50MHz (typically short-range). The ARRL was going to ask for this here, but then backed down. I have yet to get an answer from anyone in ARRL staff why.
And this is one reason why morse code (CW) is often used with emergency communications.
No, sorry, CW is used because it can get through when voice or other modes can't, not because it obscures the meaning of anything.
Now, what IS used in emergency communications is FBB compression on packet radio systems (winlink 2000 systems, e.g.). THAT truly is "encoding" that everyone assumes is allowable because the protocol is published and thus not intended to obscure the meaning of the embedded message, even though many EMCOMM ops point to this "encoding" as security for the message. They want to have it both ways.
Yes, isn't VMS fun? The files on THAT system (and many other "old" systems) aren't just "fixed-record-length" because the user wrote the code to treat them that way, the file system itself enforced it.
As I recall, there was a program called "convert" that would change a file from one thing into another, but it required an obtuse and complicated set of parameters. It might have had an option to "make this file look like that file", but I'm not sure.
It was one of the early precepts of Unix that files be "strings of bytes" that the application would deal with, instead of the OS itself. Even so, "strings of bytes" doesn't cover things like Unicode or CRLF/NL differences.
Another wonderful part of VMS was that it ran on the VAX, which didn't follow IEEE753 rules for floating point numbers, and I had the wonderful pleasure of writing code to convert raw data files (with floating point numbers) from VAX to 68000 to whatever.
Ummm, no. Just because all radios use the same digital system doesn't mean there is a single point of failure. All the radios would have to fail. It's not like all the radios using one digital mode must communicate through one node.
Now, there IS a "single point" problem when you try to convert from simple radio systems to trunked, but "trunked" and "digital" are not synonyms.
There is nothing to be gained from "heterogeneity" other than confusion and expense. There is no advantage to a world where one communities police force uses P25 and the neighbors use something else, there is only time wasted trying to communicate when one needs help from the other. It is even worse if the police in a community use P25 and the fire department something else.
Yes, hams do use P25, in addition to D-STAR. It's not common, but there is now a P25 section in the repeater directory along with the D-STAR section.
The goal of "interoperability" is to get rid of "many of the other digital public service protocols" and use just one.
It's already succeeded. It costs $5k, base. No trunking. It's got a slick LCD display. Color. It's a brick. Heavy. Large.
And Thales is getting a $6 million kickback after creating it, and $5k/radio to sell it (lots of federal grants are obtained with the keyword "interoperability").
I used to think Thales was an innovator. Now I know they are just sucking at the public tit.
And 700. But who's counting?
Now, the product exists, it's being delivered, where the EMERGENCY?
Thales already makes and sells a multi-band SDR handheld called the Liberty. It costs $5k for the simple (no trunking) version.
Why the hell is our government giving a company money to develop something already being sold?
The problem is that the vast majority of people wouldn't know when to look for the problem and wouldn't know how to solve it when it appeared. The BEST place to solve this kind of problem is where both ends know it exists and how to solve it automatically. E.g., in FTP, where the server knows about the host's file system oddities and the client knows the client's.
I didn't ask FTP to deal with this, it was dealing with this a long time before I used it. Apparently it solved a LOT of people's problems, not just mine.
Now, since FTP already has this functionality, there's nothing wrong with using it. But that's a far cry from saying that this is really the job of a transport protocol or that it was really a good design decision to put it there.
That's right. The fact that FTP does it is not an argument that it is the best place to do it. The fact that FTP involves a server that knows about the file system it reads and writes files to, and a client that knows about the file system IT reads and writes files to, is why it is the best place to take care of the conversion. It is stupid for a program designed to transport a certain kind of file from one OS to another to simply ignore the fact that that certain kind of file needs to be converted for use.
If you don't want FTP converting things for you automatically, use BIN mode for all your transfers. I like the fact that I don't have to worry about what format the stupid text file is in when I move data around automatically.
Really, FTP worrying about this would be a little like Ethernet trying to detect and transcode streaming video.
Patently absurd. Ethernet is a hardware layer; FTP is a software layer. Ethernet has no concept of what it carries; FTP KNOWS the file structures because it has to.
That's right. And FTP is an APPLICATION. It is THE ONLY application that knows what the source and destination formats are and how to convert them. That makes FTP the right place to deal with the conversion. We aren't just talking about CRLF/NL differences, remember?
The crux of the disagreement is this: some people think that their convenience overrides what would otherwise be recognized as a poor or at least questionable design decision.
No, the crux is that some people are very limited in the experiences they have with data management and transport and assume that everything they talk to is just like what they use at home, and thus no conversions are necessary. In those few cases when they are necessary, they assume that their usage of the computer (download a few files) is what everyone else is doing, and that it is simpler to use a standalone converter to convert the "few files". This leads them to THINK that the FTP design decision was poor, when it really is their understanding of the scope of the problem that is poor.
Other people think that the soundness of a design decision should come first and convenience should be a secondary concern, particularly when there are other, quite viable options for handling the problem.
The other options are not that viable when you are dealing with large volumes of data automatically. The design decision is sound because it is both doing the work where it can be done automatically AND makes life a lot more convenient even for people who have no idea that there would otherwise be a problem.
It is patently stupid to force people to make an additional step to convert a file from an "oddball OS" structure into something usable when the transport software can do it for them. If you want an analogy, it is no different than an email program that forces
If those image files are stored in a file structure "oddball" to that OS, it does. You need to differentiate between OS-independent application-specific contents (.ppm, .bmp, .au, .wav, etc) and OS-dependent application-irrelevant ones (CRLF Windows line endings, fixed-record VMS files, etc).
Dealing with a .wav file is completely application dependent; it can happen on any OS. Dealing with a fixed-record length file structure is OS dependent, and once the file is moved from the host OS that information is lost. It has to be converted somewhere, and the easiest place to do that is on the host that knows about that format and how to convert it.
As I wrote down the requirements for the system I was thinking of writing, I realized that every bit was covered by UUCP. And then I realized that t protocol was designed for used over the network.
If you want security, create an SSH tunnel and transport the UUCP over that.
It's not stupid to use existing tools as they were intended. What's stupid is rewriting the wheel.
Who rated this "insightful"?
I'm sorry, but I've worked in this area for years. I was responsible for moving data and source files to and from Unix to DOS to VMS to OSs that are even deader than VMS, and the problem is hardly unique to "notepad". YOU may see it only in notepad because YOU only use Windows, but there are a lot of other OSs out there. If you've never worked on an OS that has structured files inherent in the filesystem, well, lucky you. I have. The newlines in those kinds of files are completely lost when you copy the byte stream contents, because the newlines are implicit and defined in the file structure itself. A fixed-record file doesn't need newlines because every line is the same length.
Every other text editor I've ever tried handles files with Unix-style newlines correctly.
There is much more to the world than Windows and Unix-style newlines. If all you have seen is Windows and Unix newlines, I suppose you could think the problem was limited to that, but it really isn't. In fact, if you use FTP much at all, I suspect even you have been protected by ASCII mode, to the point that you never even knew that an FTP site you visited was VMS-based. I know I've been to VMS sites, and ASCII mode is critical if you are dealing with ASCII files.
And what about the New York Times? Why do people assume THEY are members of the press?
As a resident of Iraq, my life depended upon NOT going to the specific market that a terrorist decided to suicide-bomb today. If I did otherwise, according to you, I am to blame for the deaths, not the suicide bomber.
I find that attitude repugnant, ignorant, and unacceptable for civilized society.