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

Groups > comp.os.linux.misc > #13517 > unrolled thread

file location

Back to article view | Back to comp.os.linux.misc

Contents

  file location "Bill Cunningham" <nospam@nspam.invalid> - 2015-01-30 18:00 -0500
    Re: file location William Unruh <unruh@invalid.ca> - 2015-01-31 00:08 +0000
    Re: file location Rich <rich@example.invalid> - 2015-01-31 00:30 +0000
      Re: file location William Unruh <unruh@invalid.ca> - 2015-01-31 00:51 +0000
        Re: file location Richard Kettlewell <rjk@greenend.org.uk> - 2015-01-31 09:03 +0000
          Re: file location William Unruh <unruh@invalid.ca> - 2015-01-31 18:14 +0000
            Re: file location "Bill Cunningham" <nospam@nspam.invalid> - 2015-01-31 19:00 -0500
              Re: file location William Unruh <unruh@invalid.ca> - 2015-02-01 05:14 +0000
    Re: file location Zaphod Beeblebrox <none@none.org> - 2015-01-30 20:06 -0600
      Re: file location "Bill Cunningham" <nospam@nspam.invalid> - 2015-01-31 18:54 -0500
        Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-01 04:52 +0100
          Re: file location "Bill Cunningham" <nospam@nspam.invalid> - 2015-02-02 15:50 -0500
            Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-02 22:05 +0100
            Re: file location Rich <rich@example.invalid> - 2015-02-02 22:29 +0000
              Re: file location "Bill Cunningham" <nospam@nspam.invalid> - 2015-02-02 18:05 -0500
          Re: file location Chick Tower <c.tower@deadspam.com> - 2015-02-03 01:38 +0000
            Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-03 02:54 +0100
              Re: file location Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-03 09:04 +0000
                Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-03 11:27 +0100
                  Re: file location Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-03 10:56 +0000
                    Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-03 12:10 +0100
                      Re: file location Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-03 18:39 +0000
                        Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-04 01:51 +0100
                          Re: file location Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-04 09:19 +0000
                Re: file location The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 12:21 +0000
                  Re: file location Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-03 12:57 +0000
                    Re: file location William Unruh <unruh@invalid.ca> - 2015-02-03 16:58 +0000
                      Re: file location John Hasler <jhasler@newsguy.com> - 2015-02-03 11:24 -0600
                        Re: file location The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 18:21 +0000
                          Re: file location William Unruh <unruh@invalid.ca> - 2015-02-04 01:11 +0000
                            Re: file location The Natural Philosopher <tnp@invalid.invalid> - 2015-02-04 10:24 +0000
                              Re: file location William Unruh <unruh@invalid.ca> - 2015-02-04 23:19 +0000
                                Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-05 00:34 +0100
                        Re: file location William Unruh <unruh@invalid.ca> - 2015-02-04 01:08 +0000
                    Re: file location The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 17:20 +0000
              Re: file location "Bill Cunningham" <nospam@nspam.invalid> - 2015-02-03 14:47 -0500
                Re: file location Aragorn <thorongil@telenet.be.invalid> - 2015-02-04 02:10 +0100

Page 1 of 2  [1] 2  Next page →

#13517 — file location

    I would like to find a file's size (du would be good) and it's location 
on a filesystem as in an offset. So I could zero the file out several times. 
Sure I can use dd and the file's name and zero it out. But I want to go back 
to the location in a hexdump and view what's there. Find it on the MFT 
and/or journal (dealing with ntfs here). And also can you do this with ext 3 
or 4?

Hope I'm clear.

Bill

[toc] | [next] | [standalone]

#13518

On 2015-01-30, Bill Cunningham <nospam@nspam.invalid> wrote:
>     I would like to find a file's size (du would be good) and it's location 
> on a filesystem as in an offset. So I could zero the file out several times. 

It varies. 
Just keep the file, find its size and write that may zeros to it. 

> Sure I can use dd and the file's name and zero it out. But I want to go back 
> to the location in a hexdump and view what's there. Find it on the MFT 

It will be 0 why do you want to look. If it is not, then your system is
completely fucked up and you need to chuck it. 

> and/or journal (dealing with ntfs here). And also can you do this with ext 3 

No idea why you want to handle ntfs. 


> or 4?
>
> Hope I'm clear.
>
> Bill
>
>

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

#13519

Bill Cunningham <nospam@nspam.invalid> wrote:
>     I would like to find a file's size (du would be good) and it's location 
> ...

> Hope I'm clear.

Not in the least.

But trying to figure out what you are trying to say through all the
lack of clarity, it sounds like you might be looking for this:

  shred

  https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html

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

#13520

On 2015-01-31, Rich <rich@example.invalid> wrote:
> Bill Cunningham <nospam@nspam.invalid> wrote:
>>     I would like to find a file's size (du would be good) and it's location 
>> ...
>
>> Hope I'm clear.
>
> Not in the least.
>
> But trying to figure out what you are trying to say through all the
> lack of clarity, it sounds like you might be looking for this:
>
>   shred
>
>   https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html

In addition to the problems with journaled file systems, etc, it is also
based on a mistaken view that there is a problem. Ie, if one simply
overwrites the data, that somehow the old data is still recoverable.
That is almost certainly false with any modern disk. Disk manufacturers
want to squeeze as much data into any location on the disk as possible.
any redundancy (eg that a 0 written over a 1 is different somehow than a
zero overwriten on a 0) is actually an opportunity to squeeze more data
onto the disk instead. And they have spent the past 20 years figuring
out how to do that. (in 1985 I bought my first disk. A huge thing in
terms of the data it held-- all of 10 MB. Now on a disk much smaller
than that one I can store 10 or 100 TB. ( a million times as much data)
They did that by squeezing out all of the redundancy in disk storage.
Ie, there is no evidence that any old data can be recovered from a disk
overwritten even once. 

>

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

#13524

William Unruh <unruh@invalid.ca> writes:
> In addition to the problems with journaled file systems, etc, it is also
> based on a mistaken view that there is a problem. Ie, if one simply
> overwrites the data, that somehow the old data is still recoverable.
> That is almost certainly false with any modern disk. Disk manufacturers
> want to squeeze as much data into any location on the disk as possible.
> any redundancy (eg that a 0 written over a 1 is different somehow than a
> zero overwriten on a 0) is actually an opportunity to squeeze more data
> onto the disk instead. And they have spent the past 20 years figuring
> out how to do that. (in 1985 I bought my first disk. A huge thing in
> terms of the data it held-- all of 10 MB. Now on a disk much smaller
> than that one I can store 10 or 100 TB. ( a million times as much data)
> They did that by squeezing out all of the redundancy in disk storage.
> Ie, there is no evidence that any old data can be recovered from a disk
> overwritten even once. 

For an SSD the situation is rather different.  Two writes to one logical
address will not, in general, modify the same underlying storage.  An
attacker with physical access to the underlying storage may indeed be
able to recover data you thought you’d overwritten.

As ever the answer is to encrypt files you wish to keep secret.

-- 
http://www.greenend.org.uk/rjk/

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

#13526

On 2015-01-31, Richard Kettlewell <rjk@greenend.org.uk> wrote:
> William Unruh <unruh@invalid.ca> writes:
>> In addition to the problems with journaled file systems, etc, it is also
>> based on a mistaken view that there is a problem. Ie, if one simply
>> overwrites the data, that somehow the old data is still recoverable.
>> That is almost certainly false with any modern disk. Disk manufacturers
>> want to squeeze as much data into any location on the disk as possible.
>> any redundancy (eg that a 0 written over a 1 is different somehow than a
>> zero overwriten on a 0) is actually an opportunity to squeeze more data
>> onto the disk instead. And they have spent the past 20 years figuring
>> out how to do that. (in 1985 I bought my first disk. A huge thing in
>> terms of the data it held-- all of 10 MB. Now on a disk much smaller
>> than that one I can store 10 or 100 TB. ( a million times as much data)
>> They did that by squeezing out all of the redundancy in disk storage.
>> Ie, there is no evidence that any old data can be recovered from a disk
>> overwritten even once. 
>
> For an SSD the situation is rather different.  Two writes to one logical
> address will not, in general, modify the same underlying storage.  An
> attacker with physical access to the underlying storage may indeed be
> able to recover data you thought you???d overwritten.

Agreed. If you cannot overwrite the data even once then overwriting will
not destroy the data. And encryption is the way. Of course if you then
forget the key, it will be hidden even from you. 

> As ever the answer is to encrypt files you wish to keep secret.
>

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

#13533

"William Unruh" <unruh@invalid.ca> wrote in message 
news:maj622$jl4$2@dont-email.me...

>> As ever the answer is to encrypt files you wish to >>keep secret.

    Here's the thing with that though. There is no unbreakable encryption. 
Just how long does it take to decrypt. And btw I do use mcrypt and have 
shred. Scrub is also another one. As processors get faster algoriths are 
outdated and such. Do you need 256 bit encryption or is 128 bit enough? You 
have to constantly keep up with it.

    SAE or AES ? PGP enough? I don't know.

Bill

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

#13535

On 2015-02-01, Bill Cunningham <nospam@nspam.invalid> wrote:
>
> "William Unruh" <unruh@invalid.ca> wrote in message 
> news:maj622$jl4$2@dont-email.me...
>
>>> As ever the answer is to encrypt files you wish to >>keep secret.
>
>     Here's the thing with that though. There is no unbreakable encryption. 

Yes there is, but it is unuseable. (One time pad) But modern algorithms
have withstood a huge amount of study. 

> Just how long does it take to decrypt. And btw I do use mcrypt and have 

If you know the key? very fast. That is one of the requirements of
modern encryption. 
As I said shred and scrub are near useless. 

> shred. Scrub is also another one. As processors get faster algoriths are 
> outdated and such. Do you need 256 bit encryption or is 128 bit enough? You 
> have to constantly keep up with it.

Well, sort of. But yes 128 bit is fine. 

>
>     SAE or AES ? PGP enough? I don't know.

Those are by far the elast of your worries. You will be comprimised not
by any weakness in the crypto but by your actions. 

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

#13521

On Fri, 30 Jan 2015 18:00:14 -0500, Bill Cunningham wrote:

> I would like to find a file's size (du would be good) and it's location
> on a filesystem as in an offset. So I could zero the file out several
> times.

The file you want probably doesn't have 'a location' but is scattered
all over the disk. In the old days you could track pointers to direct
blocks, then to indirect blocks, then to doubly-indirect blocks, etc.
but it would make your head swim. With modern filesystems, forget it.
Only the OS can keep that stuff straight.

Oh, you're talking about NTFS. That's not really a modern filesystem.
The file might be contiguous if the filesystem has been defragmented,
but that's a gamble. Ever run defrag? Maybe you should ask on an MS group.

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

#13532

"Zaphod Beeblebrox" <none@none.org> wrote in message 
news:v6KdnZ5mYvI-pVHJnZ2dnUU7-RmdnZ2d@posted.cavenetllc...
> On Fri, 30 Jan 2015 18:00:14 -0500, Bill Cunningham wrote:
>
>> I would like to find a file's size (du would be good) and it's location
>> on a filesystem as in an offset. So I could zero the file out several
>> times.
>
> The file you want probably doesn't have 'a location' but is scattered
> all over the disk. In the old days you could track pointers to direct
> blocks, then to indirect blocks, then to doubly-indirect blocks, etc.
> but it would make your head swim. With modern filesystems, forget it.
> Only the OS can keep that stuff straight.
>
> Oh, you're talking about NTFS. That's not really a modern filesystem.
> The file might be contiguous if the filesystem has been defragmented,
> but that's a gamble. Ever run defrag? Maybe you should ask on an MS group.

    Run defrag? All the time. But the only reason really that it was 
mentioned was because I have it sometimes to access from linux. Right now I 
have ext2 running. Yeah I know. But usually I have the journal and run ext3. 
I never use lvms (but have), btrfs, xfs, and so on that are actually modern. 
The maintainers of the ext family say ext4 was a "catch up" and not the 
future. I have been told that ext3 and definately ext4 doesnot frag. Is that 
possible? My fragmentation usually runs at most 6% on ntfs and I defrag 
after that. I can keep it at 1-2% as reported anyway which is about the same 
as ext4.

    Bill

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

#13534

On Sunday 01 February 2015 00:54, Bill Cunningham conveyed the following 
to comp.os.linux.misc...

> "Zaphod Beeblebrox" <none@none.org> wrote in message
> news:v6KdnZ5mYvI-pVHJnZ2dnUU7-RmdnZ2d@posted.cavenetllc...
>
>> Oh, you're talking about NTFS. That's not really a modern filesystem.
>> The file might be contiguous if the filesystem has been defragmented,
>> but that's a gamble. Ever run defrag? Maybe you should ask on an MS
>> group.
> 
>     Run defrag? All the time. But the only reason really that it was
> mentioned was because I have it sometimes to access from linux. Right
> now I have ext2 running. Yeah I know. But usually I have the journal
> and run ext3. I never use lvms (but have), btrfs, xfs, and so on that
> are actually modern.

Well, you should.  Not btrfs per se, because that's still not 
sufficiently tested, in my personal opinion, and the toolchain is also 
still lacking at the moment.  XFS on the other hand is an industry 
standard and is highly reliable, but it does require that you have the 
machine running on a UPS due to its aggressive caching and delayed 
allocation.  A sudden power loss can result in data loss.

> The maintainers of the ext family say ext4 was a "catch up" and not
> the future.

Yes, ext4 brings some features from the more advanced filesystems like 
XFS to the ext? family of filesystems, and it performs a lot better than 
ext3, but the maintainer/developer of ext4 actually considers btrfs the 
next step.

> I have been told that ext3 and definately ext4 doesnot frag. Is that
> possible?

Hmm...  That's putting it a bit extreme.  All filesystems eventually do 
suffer from fragmentation as the filesystem fills up and free space 
becomes more scarce.  However, the Linux kernel's filesystem layer is 
very clever and avoids fragmentation as much as possible.  Filesystems 
like ext4 and XFS ─ as well as reiser4, but that one is not in the 
upstream the kernel ─ are even better at that because of their delayed 
allocation algorithm and their aggressive caching.

Furthermore, fragmentation does not need to be something negative per 
se.  It all depends on the filesystem and on the load of the system.  
This is GNU/Linux, a multitasking operating system, so you can have 
multiple disk I/O threads going on at the same time, and the kernel will 
schedule those operations in such a way that the least amount of head 
displacement is required.  

Well, unless you use the "noop" scheduler, that is.  "noop" is better if 
you have multiple hard disks attached to a _hardware_ RAID controller, 
because then the controller itself will have its own scheduler, and if 
you're using an SSD instead of a drive with spinning platters, then 
"noop" or "deadline" might be better choices than the default "cfq" 
("completely fair queuing") or "anticipatory" schedulers.

> My fragmentation usually runs at most 6% on ntfs and I defrag after
> that. I can keep it at 1-2% as reported anyway which is about the same
> as ext4.

Well, NTFS is a particularly horrible filesystem, and Microsoft Windows 
is a particularly horrible operating system design which constantly 
writes and deletes temporary files all over the tree, leaving plenty of 
gaps, so it's no surprise that NTFS suffers from high degrees of 
fragmentation.

In fact, HPFS, the old filesystem used in OS/2 and upon which NTFS is 
supposed to be based, already had algorithms to reduce the amount of 
fragmentation by intelligent file placement, but for some reason, 
Microsoft never incorporated that into NTFS.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#13543

"Aragorn" <thorongil@telenet.be.invalid> wrote in message 
news:mak7sj$ci8$1@dont-email.me...

> In fact, HPFS, the old filesystem used in OS/2 and upon which NTFS is
> supposed to be based, already had algorithms to reduce the amount of
> fragmentation by intelligent file placement, but for some reason,
> Microsoft never incorporated that into NTFS.

    HPFS hum is that compatible to linux. Does the kernel recognize it and 
could a driver be designed if not already? There is FFS for Unix but I don't 
know if it is linux compatible or not.

Bill

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

#13545

On Monday 02 February 2015 21:50, Bill Cunningham conveyed the following 
to comp.os.linux.misc...

> "Aragorn" <thorongil@telenet.be.invalid> wrote in message
> news:mak7sj$ci8$1@dont-email.me...
> 
>> In fact, HPFS, the old filesystem used in OS/2 and upon which NTFS is
>> supposed to be based, already had algorithms to reduce the amount of
>> fragmentation by intelligent file placement, but for some reason,
>> Microsoft never incorporated that into NTFS.
> 
>     HPFS hum is that compatible to linux.

The kernel has read and write support for it, but it is not a filesystem 
with support for POSIX file ownerships and permissions, so it would be 
unsuitable as the host filesystem for a GNU/Linux operating system.  

POSIX permissions and ownerships must be faked in the virtual filesystem 
layer at mount time via a mount option, similar to vfat and ntfs.

>     Does the kernel recognize it and could a driver be designed if not
> already?

There is an upstream kernel module driver for it, and it should thus be 
included in every distribution.

> There is FFS for Unix but I don't know if it is linux compatible or
> not.

Just what exactly are you trying to achieve?  If you need a filesystem 
for usage with GNU/Linux and you don't need compatibility with Microsoft 
Windows [*], then why not use a Linux-native filesystem such as ext4 or 
XFS?  

I myself even use ext2 on my USB thumbdrives as opposed to vfat or ntfs 
because I don't use Microsoft Windows and then I can at least have 
native POSIX permissions and file ownerships.


[*] Modern versions of Microsoft Windows no longer have support for
    HPFS.  As I understand it, the last Windows version to support it
    was Windows NT 4.0, or possibly NT 5.0 (alias Windows 2000).

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#13546

Bill Cunningham <nospam@nspam.invalid> wrote:

> "Aragorn" <thorongil@telenet.be.invalid> wrote in message 
> news:mak7sj$ci8$1@dont-email.me...

> > In fact, HPFS, the old filesystem used in OS/2 and upon which NTFS is
> > supposed to be based, already had algorithms to reduce the amount of
> > fragmentation by intelligent file placement, but for some reason,
> > Microsoft never incorporated that into NTFS.

>     HPFS hum is that compatible to linux. Does the kernel recognize it and 
> could a driver be designed if not already? There is FFS for Unix but I don't 
> know if it is linux compatible or not.

Google is your friend for these sorts of questions:

Google for "HPFS linux driver" and then read the top hit.

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

#13549

"Rich" <rich@example.invalid> wrote in message 
news:maotos$dvo$1@dont-email.me...

> Google is your friend for these sorts of questions:
>
> Google for "HPFS linux driver" and then read the top hit.

    It sure has a lot to show me. I don't know maybe I'm not trying things 
in right I don't know. If I ask about something. Rest assured I have googled 
and not found anything.

BIll

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

#13557

On 2015-02-01, Aragorn <thorongil@telenet.be.invalid> wrote:
> In fact, HPFS, the old filesystem used in OS/2 and upon which NTFS is 
> supposed to be based, ....

I thought NTFS was loosely based on VMS, since Microsoft hired the 
designer of VMS, (Dave?) Cutler, to design NTFS.  I guess he was free 
to draw inspiration for NTFS from anywhere he chose, but that's what I 
remember reading.  And I'm not trying to start a flame war.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

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

#13558

On Tuesday 03 February 2015 02:38, Chick Tower conveyed the following to 
comp.os.linux.misc...

> On 2015-02-01, Aragorn <thorongil@telenet.be.invalid> wrote:
>
>> In fact, HPFS, the old filesystem used in OS/2 and upon which NTFS is
>> supposed to be based, ....
> 
> I thought NTFS was loosely based on VMS, since Microsoft hired the
> designer of VMS, (Dave?) Cutler, to design NTFS.

His name is Dave Cutler, yes, and he more or less copied over the VMS 
kernel code into the NT kernel, but simply renamed the functions and the 
variables.  That's why DEC fired him on the spot and sued Microsoft, but 
Gates settled the matter out of court by paying DEC a large sum of money 
and conceding to supporting DEC's Alpha processor in NT.

> I guess he was free to draw inspiration for NTFS from anywhere he
> chose, but that's what I remember reading.  And I'm not trying to
> start a flame war.

Yeah.  It is possible that VMS served as the template for the NTFS 
filesystem itself as well, but as I understand it, they also reused some 
of the code from HPFS.  Certainly not all of it, because HPFS was a very 
clean filesystem, whereas NTFS is an ugly mess.  But then again, it 
comes from an ugly company. :p


-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#13561

Aragorn <thorongil@telenet.be.invalid> writes:
> His name is Dave Cutler, yes, and he more or less copied over the VMS
> kernel code into the NT kernel, but simply renamed the functions and
> the variables.  That's why DEC fired him on the spot and sued
> Microsoft, but Gates settled the matter out of court by paying DEC a
> large sum of money and conceding to supporting DEC's Alpha processor
> in NT.

As far as I can tell this (intrinsically rather unlikely) claim is
something that ‘Aragorn’ has simply made up.

-- 
http://www.greenend.org.uk/rjk/

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

#13563

On Tuesday 03 February 2015 10:04, Richard Kettlewell conveyed the 
following to comp.os.linux.misc...

> Aragorn <thorongil@telenet.be.invalid> writes:
>
>> His name is Dave Cutler, yes, and he more or less copied over the VMS
>> kernel code into the NT kernel, but simply renamed the functions and
>> the variables.  That's why DEC fired him on the spot and sued
>> Microsoft, but Gates settled the matter out of court by paying DEC a
>> large sum of money and conceding to supporting DEC's Alpha processor
>> in NT.
> 
> As far as I can tell this (intrinsically rather unlikely) claim is
> something that ‘Aragorn’ has simply made up.

And as far as I myself can tell, I have not made that up at all.  I've 
heard it from someone ─ actually, multiple people ─ who was(/were) 
"there".  You, however, are free to believe what you want, including the 
cleaned up "official version" as posted on Wikipedia.

If you want evidence, then I'm sure that lawsuit between DEC and 
Microsoft will have left traces somewhere, in spite of having been 
settled out of court eventually.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#13564

Aragorn <thorongil@telenet.be.invalid> writes:
> Richard Kettlewell conveyed the following to comp.os.linux.misc...
>> Aragorn <thorongil@telenet.be.invalid> writes:
>>> His name is Dave Cutler, yes, and he more or less copied over the VMS
>>> kernel code into the NT kernel, but simply renamed the functions and
>>> the variables.  That's why DEC fired him on the spot and sued
>>> Microsoft, but Gates settled the matter out of court by paying DEC a
>>> large sum of money and conceding to supporting DEC's Alpha processor
>>> in NT.
>> 
>> As far as I can tell this (intrinsically rather unlikely) claim is
>> something that ‘Aragorn’ has simply made up.
>
> And as far as I myself can tell, I have not made that up at all.  I've 
> heard it from someone ─ actually, multiple people ─ who was(/were) 
> "there".  You, however, are free to believe what you want, including the 
> cleaned up "official version" as posted on Wikipedia.
>
> If you want evidence, then I'm sure that lawsuit between DEC and 
> Microsoft will have left traces somewhere, in spite of having been 
> settled out of court eventually.

So produce some evidence.

Wait, I already challenged you to do that, and we already both know that
you can’t.

-- 
http://www.greenend.org.uk/rjk/

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web