Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment: Re:Most degrees from India... (Score 2, Interesting) 264

The next time you want to post a broad, bigoted claim that covers well over a billion people, at least have the courage to do so with your own account instead of AC. If you're afraid of the repercussions of doing so, maybe you should stop and ask yourself why there would be repercussions in the first place.

Comment: Re:Wikipedia? Really? (Score 1) 144

by QilessQi (#49181337) Attached to: Technology's Legacy: the 'Loser Edit' Awaits Us All

All of those testimonies against Rappe were also unproven allegations and rumors. Your own source makes that clear.

You seem to find it easy to vigorously defend a man's reputation against unfounded allegations, but you call a woman a hooker or "too close to call" based on... no such allegations. Interesting.

Comment: Re:"Loser edit" is a new name for a very old evil. (Score 1, Informative) 144

by QilessQi (#49180357) Attached to: Technology's Legacy: the 'Loser Edit' Awaits Us All

Virginia Rappe was not a hooker, she was an actress. There was at least one person who accused Arbuckle of violently raping or assaulting her at the party, resulting in the ruptured bladder that caused her death. There were numerous conflicting accounts at the time. The case dragged on through three trials; he was only acquitted in the third trial. It's still not clear what actually happened.

http://en.wikipedia.org/wiki/V...

Comment: Re:Yes, I agree (Score 1) 564

by QilessQi (#49180285) Attached to: Why We Should Stop Hiding File-Name Extensions

I'm proposing a little more than that. Magic cookies are ad-hoc; as far as I know there is no consistent standard for them. I'm proposing a standard header syntax which would be...

-- Self-evident to anyone who looks at the header of a file with an ordinary text editor or string-dumper

-- Aligned with the existing RFCs for MIME content types

-- Extensible to allow other file metadata such as the program that created the file, the date of creation or last modification, etc. Each content type or subtype could define format-specific extension tags which would be easily available to any program. E.g.:

      Content-type: audio/mp3
      Creator: grip 5.1 (Linux)
      Audio-title: Despicable Me
      Audio-album: Despicable Me Soundtrack
      Audio-genre: Soundtracks
      Audio-artist: Pharrel
      Audio-mp3-sampling-rate: 44100K

      {conventional binary mp3 data....}

Eh, maybe that goes too far, but you get the idea. Me, I'd just be happy if we all agreed that the standard cookie format at the head of a file would be this:

      Content-type: {{mime-type}}[CR][LF]

Everything else could be taken care of by the format itself.

Comment: Re:Yes, I agree (Score 1) 564

by QilessQi (#49176011) Attached to: Why We Should Stop Hiding File-Name Extensions

Then apologies, I misunderstood you. :-) I was keying in on this sentence:

If it's not really the same file, then the bug is that the OS has allowed the person to call multiple documents by the same name.

Certainly they are not the same file, but the OS is not at fault here. The OS (well, technically, the Windows filesystem) properly keeps track of the full filename -- it is the Windows desktop user interface that is at fault by hiding information.

But there is a hack in Windows, which is that changing the filename extension changes what Windows thinks that the file holds, and what application it launches. That's why I think we need a consistent content envelope across operating systems which makes use of established MIME content-types.

 

Comment: Re:Yes, I agree (Score 2) 564

by QilessQi (#49174779) Attached to: Why We Should Stop Hiding File-Name Extensions

I have to disagree. The extensions are part of the unique filename; that much is well established across different operating systems. The only hack is using extensions to indicate the content type to the OS.

Apple got this right ages ago, by using the resource fork as a place to keep file metadata. They had their own version of MIME types ages ago, whereby they encoded both the file type and the program that created the file in the resource fork. A user could rename a .jpg to a .doc and the OS would still know that it was really a JPEG. Well behaved Linux/UNIX systems do this with magic cookies, but those are really an awful hack.

My opinion FWIW: every file format should start with a MIME header in UTF8, in which the content-type of the "rest" of the file after the header should be kept. The header could always begin with the sequence "Content-type:" to act as a magic cookie indicating the presence of a MIME-header.

So here's a possible JPG file, where [CR][LF] is a carriage-return linefeed sequence:

        Content-type: image/jpeg [CR][LF]
        [CR][LF]
        {old-school binary JPEG data...}

Existing programs should be able to be retrofitted pretty easily: if the input file starts with "Content-type:", skip to the end of the MIME header and do traditional processing from there. Otherwise, assume that it's an old-school file. This allows us to put all sorts of metadata in the file header:

        Content-type: image/jpeg
        Creator: Adobe Photoshop
        Created-on: 2015-03-02T11:23:34Z
        Content-disposition: inline; filename="IMG-1234.jpg"

        {old-school binary JPEG data...}

One content envelope to rule them all. :-)

 

Don't panic.

Working...