Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9460 > unrolled thread

Piggypack Encoding/Decoding on RandomAccessFile

Back to article view | Back to comp.lang.java.programmer

Contents

  Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-03 19:18 +0100
    Re: Piggypack Encoding/Decoding on RandomAccessFile Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-11-03 14:32 -0500
      Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-03 20:50 +0100
        Re: Piggypack Encoding/Decoding on RandomAccessFile markspace <-@.> - 2011-11-03 13:52 -0700
          Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-03 23:13 +0100
          Re: Piggypack Encoding/Decoding on RandomAccessFile Knute Johnson <nospam@knutejohnson.com> - 2011-11-03 16:17 -0700
        Re: Piggypack Encoding/Decoding on RandomAccessFile Lew <lewbloch@gmail.com> - 2011-11-03 13:58 -0700
        Re: Piggypack Encoding/Decoding on RandomAccessFile Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-03 20:40 -0400
          Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-04 02:28 +0100
            Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-04 03:06 +0100
              Re: Piggypack Encoding/Decoding on RandomAccessFile Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-04 08:05 -0400
                Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-04 16:12 +0100
          Re: Piggypack Encoding/Decoding on RandomAccessFile rossum <rossum48@coldmail.com> - 2011-11-04 16:54 +0000
    Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-03 23:24 +0100
    Re: Piggypack Encoding/Decoding on RandomAccessFile Arne Vajhøj <arne@vajhoej.dk> - 2011-11-03 20:14 -0400
    Re: Piggypack Encoding/Decoding on RandomAccessFile Roedy Green <see_website@mindprod.com.invalid> - 2011-11-03 21:56 -0700
      [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile) Lew <lewbloch@gmail.com> - 2011-11-04 10:50 -0700
        Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile) Arne Vajhøj <arne@vajhoej.dk> - 2011-11-04 21:07 -0400
        Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile) Roedy Green <see_website@mindprod.com.invalid> - 2011-11-05 20:21 -0700
        Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile) Roedy Green <see_website@mindprod.com.invalid> - 2011-11-05 20:24 -0700
          Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile) Jan Burse <janburse@fastmail.fm> - 2011-11-06 10:36 +0100
        Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile) Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-11-06 14:16 -0600
    Re: Piggypack Encoding/Decoding on RandomAccessFile Stanimir Stamenkov <s7an10@netscape.net> - 2011-11-05 16:51 +0200
      Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-05 16:27 +0100
        Re: Piggypack Encoding/Decoding on RandomAccessFile Lew <lewbloch@gmail.com> - 2011-11-05 10:03 -0700
          Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-05 19:37 +0100
            Re: Piggypack Encoding/Decoding on RandomAccessFile Lew <lewbloch@gmail.com> - 2011-11-05 13:25 -0700
          Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-05 19:47 +0100
          Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-05 19:56 +0100
            Re: Piggypack Encoding/Decoding on RandomAccessFile Lew <lewbloch@gmail.com> - 2011-11-05 13:29 -0700
              Re: Piggypack Encoding/Decoding on RandomAccessFile Jan Burse <janburse@fastmail.fm> - 2011-11-06 10:42 +0100

Page 1 of 2  [1] 2  Next page →

#9460 — Piggypack Encoding/Decoding on RandomAccessFile

Dear All,

How can I go about and encode/decode bytes read
from a random access file.

I am used to FileInputStream and FileOutputStream,
but I don't see right now how I could piggypack
encoding/deconding on a RandomAccessFile:

http://download.oracle.com/javase/7/docs/api/java/io/RandomAccessFile.html

Should I mingle with file descriptor, and get
associated input and output streams, and then
move forward?

Bye

[toc] | [next] | [standalone]

#9461

On 11/3/2011 1:18 PM, Jan Burse wrote:
> Should I mingle with file descriptor, and get
> associated input and output streams, and then
> move forward?

The "standard way" (at least, all of the use cases I've ever had for 
RandomAccessFile) effectively uses the methods that are associated with 
java.io.DataInput to read data: read(byte[]), and read*().

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#9462

Joshua Cranmer schrieb:
> The "standard way" (at least, all of the use cases I've ever had for
> RandomAccessFile) effectively uses the methods that are associated with
> java.io.DataInput to read data: read(byte[]), and read*().

I would like to use an arbirary encoding/decoding on top of the
byte stream to get a character stream. But since RandomAccessFile
does not implement InputStream/OutputStream, I cannot create
a InputStreamReader/OutputStreamWrite on top.

Bye

[toc] | [prev] | [next] | [standalone]

#9466

On 11/3/2011 12:50 PM, Jan Burse wrote:
> Joshua Cranmer schrieb:
>> The "standard way" (at least, all of the use cases I've ever had for
>> RandomAccessFile) effectively uses the methods that are associated with
>> java.io.DataInput to read data: read(byte[]), and read*().
>
> I would like to use an arbirary encoding/decoding on top of the
> byte stream to get a character stream. But since RandomAccessFile
> does not implement InputStream/OutputStream, I cannot create
> a InputStreamReader/OutputStreamWrite on top.
>
> Bye
>

5 minutes, untested:


package quicktest;

import java.io.IOException;
import java.io.InputStream;
import java.io.RandomAccessFile;

/**
  *
  * @author Brenden
  */
public class RndFileStream extends InputStream {

    private final RandomAccessFile raf;

    public RndFileStream(RandomAccessFile raf) {
       this.raf = raf;
    }

    @Override
    public int read() throws IOException {
       return raf.read();
    }


    public void seek( long pos ) throws IOException {
       raf.seek(pos);
    }

}

[toc] | [prev] | [next] | [standalone]

#9473

markspace schrieb:
>
>     public void seek( long pos ) throws IOException {
>        raf.seek(pos);
>     }


public void skip(long n) {
    raf.seek(raf.getFilePosition()+n);
}

Or some such....

[toc] | [prev] | [next] | [standalone]

#9478

On 11/3/2011 1:52 PM, markspace wrote:
> On 11/3/2011 12:50 PM, Jan Burse wrote:
>> Joshua Cranmer schrieb:
>>> The "standard way" (at least, all of the use cases I've ever had for
>>> RandomAccessFile) effectively uses the methods that are associated with
>>> java.io.DataInput to read data: read(byte[]), and read*().
>>
>> I would like to use an arbirary encoding/decoding on top of the
>> byte stream to get a character stream. But since RandomAccessFile
>> does not implement InputStream/OutputStream, I cannot create
>> a InputStreamReader/OutputStreamWrite on top.
>>
>> Bye
>>
>
> 5 minutes, untested:
>
>
> package quicktest;
>
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.RandomAccessFile;
>
> /**
> *
> * @author Brenden
> */
> public class RndFileStream extends InputStream {
>
> private final RandomAccessFile raf;
>
> public RndFileStream(RandomAccessFile raf) {
> this.raf = raf;
> }
>
> @Override
> public int read() throws IOException {
> return raf.read();
> }
>
>
> public void seek( long pos ) throws IOException {
> raf.seek(pos);
> }
>
> }
>

I like that, I'm going to have to give it a try.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#9471

On Thursday, November 3, 2011 12:50:45 PM UTC-7, Jan Burse wrote:
> Joshua Cranmer schrieb:
> > The "standard way" (at least, all of the use cases I've ever had for
> > RandomAccessFile) effectively uses the methods that are associated with
> > java.io.DataInput to read data: read(byte[]), and read*().
> 
> I would like to use an arbirary encoding/decoding on top of the
> byte stream to get a character stream. But since RandomAccessFile
> does not implement InputStream/OutputStream, I cannot create
> a InputStreamReader/OutputStreamWrite on top.

No, but you can use the 'DataInput' (and 'DataOutput') methods, as Joshua indicated.

However, the notion of encoding / decoding from a random access file seems fraught with peril.  You have to ensure that you start from a valid position in the file, not, for example, in the second byte of a three-byte character.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9482

On 11/3/2011 3:50 PM, Jan Burse wrote:
> Joshua Cranmer schrieb:
>> The "standard way" (at least, all of the use cases I've ever had for
>> RandomAccessFile) effectively uses the methods that are associated with
>> java.io.DataInput to read data: read(byte[]), and read*().
>
> I would like to use an arbirary encoding/decoding on top of the
> byte stream to get a character stream. But since RandomAccessFile
> does not implement InputStream/OutputStream, I cannot create
> a InputStreamReader/OutputStreamWrite on top.

     For a completely "arbitrary" encoding, I think you're out of luck.
Stateful encodings (where the encoding of byte B[n] is a function of
B[n-1],B[n-2],...) make it difficult to begin in medias res: You cannot
know how to decode the first byte you read without already having seen
all its predecessors.

     To support random access, where you'd like to jump directly to B[n]
without plowing through all that goes before, one usually addresses the
problem by restricting the valid n to multiples of some "block size,"
and encoding each "block" independently. You seek to the next lower
multiple of 32K or whatever, set your decryptor/compressor/decoder to
its initial state, and roll merrily along.

     There's a problem if the encoding does not always map K input bytes
to f(K) output bytes: compressors, for example, output different amounts
of data depending on the values of the bytes compressed.  There are two
principal methods for dealing with this difficulty:

     1) Encode the original in blocks of 32K (say), and store each
encoded block in a file region that's sure to be large enough -- 40K,
perhaps.  Pad with nulls or other junk values as needed, so long as
your decompressor can recognize and ignore the padding.  Then original
byte N is in block number N/32K, whose encoding starts at (N/32K)*40K
in the file; seek to that spot and start decoding.

     2) As before, encode the original in fixed-size blocks, but write
them cheek by jowl to the file.  As you do so, also write an index file
that's essentially Map<OriginalByteNumber,EncodedByteNumber> for each
block boundary.  Then original byte N is in the block beginning at
theMap.get(N/32K); seek to that spot and start decoding.

     Elsethread you mention that RandomAccessFile provides neither
InputStream nor OutputStream.  If you think about this a bit, you'll
see it's a natural consequence of the "Random" part: a Stream provides
the abstraction of a linear sequence of things, and does not admit of
leaping forward or backward to unrelated positions.  Yes, there are
skip() and mark() and reset(), but I think you'll agree these are of
a different character than "read bytes 3000-3999, then 10000-10999,
then 936-22728."  Streams are sequential; Random isn't.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9490

Eric Sosman schrieb:
> Elsethread you mention that RandomAccessFile provides neither
> InputStream nor OutputStream.  If you think about this a bit, you'll
> see it's a natural consequence of the "Random" part: a Stream provides
> the abstraction of a linear sequence of things, and does not admit of
> leaping forward or backward to unrelated positions.  Yes, there are
> skip() and mark() and reset(), but I think you'll agree these are of
> a different character than "read bytes 3000-3999, then 10000-10999,
> then 936-22728."  Streams are sequential; Random isn't.

It seems that the FileInputStream reacts on the what is
done with the underlying RandomAccessFile. Since it is
not buffering and since it shares the same file descriptor.

But I have only done a small testing. Something allong:

    Writing "Hello World!" to a file.

    Random access opening the file.

    Doing a FileInputStream on the random access
    file via the file descriptor.

    Seeking the random access file to position 6.

    Reading from FileInputStream, and you get "World!"

So they are somehow interlocked.

Bye

[toc] | [prev] | [next] | [standalone]

#9496

Jan Burse schrieb:
>
> So they are somehow interlocked.

 From the file channel java doc we have:

	"Where the file channel is obtained from an existing stream or
	random access file then the state of the file channel is
	intimately connected to that of the object whose getChannel
	method returned the channel. Changing the channel's position,
	whether explicitly or by reading or writing bytes, will change
	the file position of the originating object, and vice versa.
	Changing the file's length via the file channel will change the
	length seen via the originating object, and vice versa.
	Changing the file's content by writing bytes will change the
	content seen by the originating object, and vice versa."

In case that the file input/output stream is interchangeable
with the file channel, then they are interwoven.

Bye

[toc] | [prev] | [next] | [standalone]

#9513

On 11/3/2011 10:06 PM, Jan Burse wrote:
> Jan Burse schrieb:
>>
>> So they are somehow interlocked.
>
>  From the file channel java doc we have:
>
> "Where the file channel is obtained from an existing stream or
> random access file then the state of the file channel is
> intimately connected to that of the object whose getChannel
> method returned the channel. Changing the channel's position,
> whether explicitly or by reading or writing bytes, will change
> the file position of the originating object, and vice versa.
> Changing the file's length via the file channel will change the
> length seen via the originating object, and vice versa.
> Changing the file's content by writing bytes will change the
> content seen by the originating object, and vice versa."
>
> In case that the file input/output stream is interchangeable
> with the file channel, then they are interwoven.

     But how do you maintain the state of the encoder/decoder,
if that state is a function of anything more than just the
file position itself?  If the decoder must process all the
bytes prior to B[n] to get itself into the proper state for
decoding B[n], random access just makes no sense.

     Well, I guess you *could* make a preliminary sequential
pass over the data, and build a Map<ByteOffset,DecoderState> for
selected positions.  You could even build the map incrementally,
adding new entries whenever the random access pattern takes you
into formerly uncharted territory.  Either way, though, the first
exploration of each byte position has to be sequential to allow
the decoder to accumulate its state.  And if you ever *write* to
the middle of the file (which changes the encoding of all the
bytes that follow), ...  I think the cases in which such a scheme
might be practical would be "unusual," if not downright "contrived."


-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9516

Eric Sosman schrieb:
>      But how do you maintain the state of the encoder/decoder,
> if that state is a function of anything more than just the
> file position itself?  If the decoder must process all the
> bytes prior to B[n] to get itself into the proper state for
> decoding B[n], random access just makes no sense.

I guess in the optimal case, the decoder only needs state
inside reading a single char. So it needs state until it
has consumed all bytes to produce a single char. This
holds for sure for UTF-8 and UTF-16.

So since I am piggypacking decoder/encoder and then
reading and writing char. Not much evil should happen.
But of course it depends on the decoder implementation,
and whether it does some extra read ahead, like a buffered
read, which is also a form of state.

Enventually the decoder object has some API. I didn't
yet check. The encoder can be flushed via the normal
character stream flush operation. So there should be much
issue. But the decoder, I am not sure how to control.

Just imaginge a lexicon implementation via Random Access,
so file includes some index and file offsets. So when
presented with a word, would first go through the index,
and then via the file offset go to the gloss. And read
it by piggypacking a decoder.

But what Roedy and others were suggesting, is of course
also a solution, to first obtain the bytes and then
do a in-memory conversion.

But if the gloss entries are just subtress in (character
encoded) XML, then I could read/decode and look for the
end-tag, and don't need to store some entry length.
Would only need the ability to navigate to entry
offsets.

For one time access a skip() would be ok. But for random
access, I guess this type of file is made for that!

Bye

[toc] | [prev] | [next] | [standalone]

#9519

On Thu, 03 Nov 2011 20:40:08 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>     For a completely "arbitrary" encoding, I think you're out of luck.
>Stateful encodings (where the encoding of byte B[n] is a function of
>B[n-1],B[n-2],...) make it difficult to begin in medias res: You cannot
>know how to decode the first byte you read without already having seen
>all its predecessors.
Use a block cypher in Counter mode.  You can immediately calculate the
relevant block, and find the relevant byte within that block.  If you
are retrieving less than a block (typically 128 bits) then there will
be some extra work to do, but it shouldn't be excessive.

rossum

[toc] | [prev] | [next] | [standalone]

#9474

Jan Burse schrieb:
> Should I mingle with file descriptor, and get
> associated input and output streams, and then
> move forward?

BTW: The file descriptor route works as follows:


     RandomAccessFile raf = new RandomAccessFile(..., "r");
     FileInputStream fi = new FileInputStream(raf.getFD());

     ... change file position ...

     ... piggypack a InputStreamReader ...

     ... change file position ...

     ... piggypack another InputStreamReader ...

     fi.close();
     raf.close();

Works also for FileOutputStream.

But I am not sure whether it is the prefered route...

Also since javadoc for InputStreamReader says:

	"To enable the efficient conversion of bytes to
	characters, more bytes may be read ahead
	from the underlying stream than are necessary
	to satisfy the current read operation."

Reading the file position after some read from InputStreamReader
will probably not give a reliable position.

But advantage over a normal InputStreamReader, which has only
a skip(), would be for example that a rewind() can be implemented
via a seek(0).

Bye

[toc] | [prev] | [next] | [standalone]

#9480

On 11/3/2011 2:18 PM, Jan Burse wrote:
> How can I go about and encode/decode bytes read
> from a random access file.
>
> I am used to FileInputStream and FileOutputStream,
> but I don't see right now how I could piggypack
> encoding/deconding on a RandomAccessFile:
>
> http://download.oracle.com/javase/7/docs/api/java/io/RandomAccessFile.html
>
> Should I mingle with file descriptor, and get
> associated input and output streams, and then
> move forward?

I think the most clean code would be to separate the logic
in two layers:
- a lower layer that uses RandomAccessFile and use byte[]
   for in and out data
- a higher layer that uses String getBytes and constructor

Arne

[toc] | [prev] | [next] | [standalone]

#9502

On Thu, 03 Nov 2011 19:18:50 +0100, Jan Burse <janburse@fastmail.fm>
wrote, quoted or indirectly quoted someone who said :

>How can I go about and encode/decode bytes read
>from a random access file.

A random access file is not something generally you create with a word
processor. It is an internal file created programmatically.  So I
would use its native binary format, e.g. RandomAccessFile.writeUTF,
writeLong...

Another other way to handle it is to use a ByteArrayOutputStream to
create an array of bytes representing serialised objects and write
them as byte[]  with RandomAccessFile.writeBytes

See http://mindprod.com/applet/fileio.html for sample code.

If you really want to read and write encoded strings, read them as
byte[] and decode them in RAM to Strings.  See
http://mindprod.com/jgloss/encoding.html

Encoded strings are tricky to handle in a RandomAccessFile because it
is hard to pin down the length.  You have various flavours of single
byte and multi-byte chars intermixed. You pretty well have to embed
the length in BYTES along with the data.  That is pretty much what
RandomAccessFile.readUTF does, except it uses a variant of UTF-8 all
the time.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

#9523 — [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile)

Roedy Green wrote in his tag line:
> Capitalism has spurred the competition that makes CPUs faster and 
> faster each year, but the focus on money makes software manufacturers 
> do some peculiar things like deliberately leaving bugs and deficiencies
> in the software so they can soak the customers for upgrades later.

Facts not in evidence.

You have not established that bugs are left in deliberately, nor that even if they are it's the "focus on money" that makes them do that.

Pure B.S., like most pseudo-socialist rhetoric.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9551 — Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile)

On 11/4/2011 1:50 PM, Lew wrote:
> Roedy Green wrote in his tag line:
>> Capitalism has spurred the competition that makes CPUs faster and
>> faster each year, but the focus on money makes software manufacturers
>> do some peculiar things like deliberately leaving bugs and deficiencies
>> in the software so they can soak the customers for upgrades later.
>
> Facts not in evidence.
>
> You have not established that bugs are left in deliberately, nor that even if they are it's the "focus on money" that makes them do that.

I don't think it is general practice.

The invisible hand should eventually take care of such companies
if there are any competition.

But hey - we do not know how Roedy do software - we can only say that
we don't do it that way!

Arne

[toc] | [prev] | [next] | [standalone]

#9637 — Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile)

On Fri, 4 Nov 2011 10:50:17 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>You have not established that bugs are left in deliberately, nor that even if they are it's the "focus on money" that makes them do that.

Then I suggest start reporting bugs and joining beta forums.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

#9638 — Re: [OT] Conspiracy theories are BS (Was: Piggypack Encoding/Decoding on RandomAccessFile)

On Fri, 4 Nov 2011 10:50:17 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>You have not established that bugs are left in deliberately, nor that even if they are it's the "focus on money" that makes them do that.
>
>Pure B.S., like most pseudo-socialist rhetoric.


Another source of evidence is the release notes of when the vendor
expects you to pay for an upgrade when the only important difference
is bug fixes.  The sloppier he is initially, the more money he makes.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web