Indeed... The question we need to ask ourselves is, do we as a nation, want space research and exploration, or another Post Office.
Making the Post Office self-supporting, as we did several years ago, doesn't seem to have helped it very much. In fact, one of the big reasons for the last.01 postal increase was, and I quote the Post Office, "to provide better bulk rate mail". Seeing as the junk mail industry represents a large part of their customer base, this makes sense from a business perspective.
I don't want to see NASA pander to commercial needs in this way... There would be little, if any room left for innovations like the Pathfinder, which would no doubt be steamrolled by business practices such as practicality, and maintaining the bottom line.
If, like me, you are concerned about recent talk of NASA budget cuts, I suggest writing a letter to your congressman. Contact info is at www.house.gov, some of them even accept email.
For a country that brought us the split baud rate Videotex terminal (75 baud TX/1200 baud RX), this doesn't surprise me. Ever wonder why various comm api's require us to specify a transmit and a receive baud rate? This is why...
In this ZDNet article, apparently investigators state that "Smith threw his computer equipment into one of the trash bins at his apartment complex". I would not presume him guilty based on this evidence...It sure looks pretty incriminating, though.
Thanks for your posts, helping me cut through my ignorance. I read one of the other specs and it sez
8.2.3 Document-format Name-Length : 15 Name : Document-Format Syntax: Keyword - values taken from [RFC 1759] Meaning: Specifies the type of data included; PCL, PostScript, etc.
So it appears that one needs not only the IPP client software, but also a print driver matching the remote print device on the client machine (or ~shiver~ one emulated by the remote) to initiate a print job.
To quote the IPP ftp://ftp.pwg.org/pub/pwg/ ipp/new_REQ/ipp-req-981116.txt"Driver here refers to the code installed in some client operating system to generate the print data stream for the intended printer. The actual details for installing a printer driver are operating system dependent and are also outside the scope of IPP. However, an IPP printer or a directory service advertising an IPP Printer should be capable of telling a client what drivers are available and/or required, where they can be found, and provide pointers to installation instructions, installation code or initialization strings required to install the driver. See section 4.1 (SECURITY CONSIDERATIONS) for security implications of driver download and installation."
Am I missing something here?
IPP in concept may be a good idea and we may well find ourselves shipping things to Kinko's for output in the future. Why not use PostScript instead of creating a whole new markup language that will no doubt end up with vendor-specific rendering issues similar to current web browsers? Anyone who has tried to make a webpage look good cross-platform/cross-browser knows what I am talking about...
Save your flames about PostScript being a proprietary architechture; one of the things Adobe has been able to pull off with PostScript is a standard for printing that you can send anywhere and obtain predictable results in the output, which is exactly what I would want if I were sending output to a client as described in Brice's hypothetical situation.
It seems not... At least my experience, prior to owning a Palm was that I thought they were toys. "Who would want one of those things?" I used to say.
Shortly after owning my Palm, which I purchased only because I thought I was going to write some software for it, I realized that "handheld computer" is the wrong paradigm and "data acquisition device" is the correct one.
Now I'm a total convert. And how cool is it to sync with my notebook computer with just a click of a button? A friend of mine uses CE. Syncing anything except the address book is a major pain in the processor, I mean brain.
Checkout ByteMark documentation at http://www.byte.com/bmark/bdoc.htm, which is the benchmark Apple used for their G3 vs. P-II comparison. BTW this link used to be on Apple's G3 benchmark pages, but not any more. A careful and informed reading of the ByteMARK doc reveals that even the integer results are twisted.
Choosing CodeWarrior for the Mac vs. Watcom 10.0 for the PC is totally laughable.
Another note: it appears that there are no results on www.spec.org for Apple systems. SPECint95 is a relatively fair crossplatform test. I wonder why Apple has not posted results there.
Slashdot Mirror
"along with support for a 100MHz system bus" Silly me, I thought the Celeron supported 100+Mhz bus for quite some time now. =)
Indeed... The question we need to ask ourselves is, do we as a nation, want space research and exploration, or another Post Office.
.01 postal increase was, and I quote the Post Office, "to provide better bulk rate mail". Seeing as the junk mail industry represents a large part of their customer base, this makes sense from a business perspective.
Making the Post Office self-supporting, as we did several years ago, doesn't seem to have helped it very much. In fact, one of the big reasons for the last
I don't want to see NASA pander to commercial needs in this way... There would be little, if any room left for innovations like the Pathfinder, which would no doubt be steamrolled by business practices such as practicality, and maintaining the bottom line.
If, like me, you are concerned about recent talk of NASA budget cuts, I suggest writing a letter to your congressman. Contact info is at www.house.gov, some of them even accept email.
For a country that brought us the split baud rate Videotex terminal (75 baud TX/1200 baud RX), this doesn't surprise me. Ever wonder why various comm api's require us to specify a transmit and a receive baud rate? This is why...
Wirehead is what I call myself at times.
In this ZDNet article, apparently investigators state that "Smith threw his computer equipment into one of the trash bins at his apartment complex". I would not presume him guilty based on this evidence...It sure looks pretty incriminating, though.
Thanks for your posts, helping me cut through my ignorance. I read one of the other specs and it sez
8.2.3 Document-format
Name-Length : 15
Name : Document-Format
Syntax: Keyword - values taken from [RFC 1759]
Meaning: Specifies the type of data included; PCL, PostScript, etc.
So it appears that one needs not only the IPP client software, but also a print driver matching the remote print device on the client machine (or ~shiver~ one emulated by the remote) to initiate a print job.
To quote the IPP ftp://ftp.pwg.org/pub/pwg/ ipp/new_REQ/ipp-req-981116.txt "Driver here refers to the code installed in some client operating system to generate the print data stream for the intended printer. The actual details for installing a printer driver are operating system dependent and are also outside the scope of IPP. However, an IPP printer or a directory service advertising an IPP Printer should be capable of telling a client what drivers are available and /or required, where they can be found, and provide pointers to installation instructions, installation code or initialization strings required to install the driver. See section 4.1 (SECURITY CONSIDERATIONS) for security implications of driver download and installation."
Am I missing something here?
IPP in concept may be a good idea and we may well find ourselves shipping things to Kinko's for output in the future. Why not use PostScript instead of creating a whole new markup language that will no doubt end up with vendor-specific rendering issues similar to current web browsers? Anyone who has tried to make a webpage look good cross-platform/cross-browser knows what I am talking about...
Save your flames about PostScript being a proprietary architechture; one of the things Adobe has been able to pull off with PostScript is a standard for printing that you can send anywhere and obtain predictable results in the output, which is exactly what I would want if I were sending output to a client as described in Brice's hypothetical situation.
It seems not... At least my experience, prior to owning a Palm was that I thought they were toys. "Who would want one of those things?" I used to say.
Shortly after owning my Palm, which I purchased only because I thought I was going to write some software for it, I realized that "handheld computer" is the wrong paradigm and "data acquisition device" is the correct one.
Now I'm a total convert. And how cool is it to sync with my notebook computer with just a click of a button? A friend of mine uses CE. Syncing anything except the address book is a major pain in the processor, I mean brain.
Checkout ByteMark documentation at http://www.byte.com/bmark/bdoc.htm, which is the benchmark Apple used for their G3 vs. P-II comparison. BTW this link used to be on Apple's G3 benchmark pages, but not any more. A careful and informed reading of the ByteMARK doc reveals that even the integer results are twisted.
Choosing CodeWarrior for the Mac vs. Watcom 10.0 for the PC is totally laughable.
Another note: it appears that there are no results on www.spec.org for Apple systems. SPECint95 is a relatively fair crossplatform test. I wonder why Apple has not posted results there.
BTW 1st post