semi offtopic... If you've ever tried searching slashdot comments, it sucks (you can only search for comment titles, not the text inside). Having full text search capabilities would be a subscription selling point.
CmdrTaco has stated that they can't add features (like that) since they're too busy writing lame filters to deal with trolls. Well, most of the comments I'd like to search for are from trolls!
Wtf are you talking about? I've seen plenty of truck-driver movies, and they don't do anything like that.
Now if you'll excuse me, i have to help a beautiful hooker with a heart of gold expose the corrupt mayor that kidnapped her daughter, with the help of an adorable chinese boy we found on the street.
When is/. going to create a section for articles about sex? I like most nerds could really use a series of informative articles and discussion on the subject.
As soon as they can find an editor with experience!!
THIS IS ONLY A WORKING TRANSLATION; I DO NOT TAKE RESPONSIBILITY AS TO POSSIBLE MISTAKES OR ERRORS. I WILL NOT TAKE ANY RESPONSIBILITY CONCERNING THE CONTENT OF THE ORIGINAL TEXT.
Today, I had the possibility to have a look at the incriminating code passages.
Due to a mistake on the part of the representing lawyer's office, my colleague and I - as opposed to the 7 other representatives that were allowed to look at things today - did not have to sign a Non Disclosure Agreement. This was in full contrast to the examiners of Microsoft corp., who apparently had to maintain silence even towards their own superiors and may only give notice to the internal company audit department.
Now for the code itself:
Under the supervision of a notary public, 46 pages were shown, each containing, by one half, code from Linux (for the most part, print-outs of posts taken directly from the Linux-Kernel-Mailing List) and, by the other half, listings of SCO. Whether these are indeed sources of SysV is not comprehensible that way, as they are taken out of their context. Another interesting thing is that all date and time details have been removed from both, even from the comments.
The comments themselves are really identical here and there, even some jokes are the same on both sides. It is, however, conspicuous that in the places that correspond most, the source code that can be found in front of the comments is quite dissimilar after all. The fundamental construction of the queried functions is similar; however, the concrete implementation is quite different. Variables and names of functions are different, loops are structured differently, conditions work via chain queries (?) (Kettenabfrage) or bit patterns (?) (Bitmuster). All in all, only one thing can be said for certain: The functions offered by the respective code passages are often equal, which, however, was to be expected from the start anyway. In the concrete implementation, there are, however, so many differences, that a proof of the origin being the same will be difficult, even though certainly not impossible.
The crunch, however, is a function of the scheduler, which is, over a length of about 60 lines, indeed identical except for slight differences. In this section, there is also a whole lot of corresponding comments. Comparable similarity can only be found in one routine of the memory management, which is, however, only in the Linux version accompanied by comments.
Whether a competent proof can be made out of these two correspondences can only be estimated with certainty by a lawyer. I consider the vague similarities in other passages to be insufficient, as the same standards were the basis for both and therefore, a certain correspondence is to be expected.
Concerning the same comments to different source passages, I can see no rhyme or reason in it. This would in any case have to be investigated in again meticulously, in particular with the date and time details provided. Because only with these could a breach of copyright be proved at all.
Concerning the discussion about the part of Linux sold under the GPL by SCO/Caldera, it must be stated that up to the present, no court has had to decide on the legal validity of the GPL. Should this, however, be ascertained, which is not certain, SCO can use only those parts of Linux by way of comparison that were not published by SCO and in the development or co-development SCO did not take part. I consider this, too, a difficulty in the proceedings to come.
As the original, unpatched Linux-sources were not touched but only modifications that had been inserted by different distributors, it has to be clarified in any case whether these might have rights to the queried passages, be it directly or indirectly, e.g. through company mergers, take-overs, "all-inclusive"-deals etc.
The chances for proceedings to open are not especially good, as in most comparable cases, there were agreements out of court.
do we really need another robot article? Can't we have an interview with Goatse Man? Oh by the way, I heard he died, is it true? Do you know?
There's an interview with him here (as well as a couple more pictures, so don't click if you're at work, unless you're a gay porn star). A slashdot interview would be nice, if only to see how the moderators handled it.
I had a friend who used to buy a fifth of beefeater, and let it rest in the freezer (until he finished his 40oz of old milwaukee), and then pour it into a martini glass.
I'm not sure why he didn't just drink it straight from the bottle.
No olive, but one time we drank vodka and pickle juice.
that's also what CmdrTaco said when he fisted Hemos and pulled out a big lump of shit. I won't go into the details of what happened next, but Kathleen fent reported that his toothbrush needed replacing.
he's an idiot, but I don't see why there couldn't be a reimplementation of carbon (ala gnustep/openstep and wine/windows). I know the original macintosh OS and toolbox allowed direct memory access that memory protected systems don't allow, but i thought Carbon cleaned up most of that....
The last time i skimmed through some darwin source code (for hfschk, IIRC), NewPointer, NewHandle, etc, were re-implemented as C frontends to malloc.
maybe it's the tar.gz format that's lame. If you there's a gzipped tarball of 1,000 files, and you want to extract only the last one, you have to wait for the entire file to decompress.
That may be the unix way, but it's not the efficient way.
Cdparanois uses the term "frame jitter" for block skewing. Out of respect for them, i use their terminology.
This is what the cdparanoia faq has to say about ripping...
I can play audio CDs perfectly; why is reading the CD into a file so difficult and prone to errors? It's just the same thing.
Unfortunately, it isn't that easy.
The audio CD is not a random access format. It can only be played from some starting point in sequence until it is done, like a vinyl LP. Unlike a data CD, there are no synchronization or positioning headers in the audio data (a CD, audio or data, uses 2352 byte sectors. In a data CD, 304 bytes of each sector is used for header, sync and error correction. An audio CD uses all 2352 bytes for data). The audio CD *does* have a continuous fragmented subchannel, but this is only good for seeking +/-1 second (or 75 sectors or ~176kB) of the desired area, as per the SCSI spec.
When the CD is being played as audio, it is not only moving at 1x, the drive is keeping the media data rate (the spin speed) exactly locked to playback speed. Pick up a portable CD player while it's playing and rotate it 90 degrees. Chances are it will skip; you disturbed this delicate balance. In addition, a player is never distracted from what it's doing... it has nothing else taking up its time. Now add a non-realtime, (relatively) high-latency, multitasking kernel into the mess; it's like picking up the player and constantly shaking it.
CDROM drives generally assume that any sort of DAE will be linear and throw a readahead buffer at the task. However, the OS is reading the data as broken up, seperated read requests. The drive is doing readahead buffering and attempting to store additional data as it comes in off media while it waits for the OS to get around to reading previous blocks. Seeing as how, at 36x, data is coming in at 6.2MB/second, and each read is only 13 sectors or ~30k (due to DMA restrictions), one has to get off 208 read requests a second, minimum without any interruption, to avoid skipping. A single swap to disc or flush of filesystem cache by the OS will generally result in loss of streaming, assuming the drive is working flawlessly. Oh, and virtually no PC on earth has that kind of I/O throughput; a Sun Enterprise server might, but a PC does not. Most don't come within a factor of five, assuming perfect realtime behavior.
To keep piling on the difficulties, faster drives are often prone to vibration and alignment problems; some are total fiascos. They lose streaming *constantly* even without being interrupted. Philips determined 15 years ago that the CD could only be spun up to 50-60x until the physical CD (made of polycarbonate) would deform from centripetal force badly enough to become unreadable. Today's players are pushing physics to the limit. Few do so terribly reliably.
Note that CD 'playback speed' is an excellent example of advertisers making numbers lie for them. A 36x cdrom is generally not spinning at 36x a normal drive's speed. As a 1x drive is adjusting velocity depending on the access's distance from the hub, a 36x drive is probably using a constant angular velocity across the whole surface such that it gets 36x max at the edge. Thus it's actually spinning slower, assuming the '36x' isn't a complete lie, as it is on some drives.
Because audio discs have no headers in the data to assist in picking up where things got lost, most drives will just guess.
This doesn't even *begin* to get into stupid firmware bugs. Even Plextors have occasionally had DAE bugs (although in every case, Plextor has fixed the bug *and* replaced/repaired drives for free). Cheaper drives are often complete basket cases.
Rant Update (for those in the know):
Several folks, through personal mail and on Usenet, have pointed out that audio discs do place absolute positioning information for (at least) nine out of every ten sectors into the Q subchannel, and that my original stateme
Slashdot Mirror
Keep in mind that most slashdot readers consider masturbation to be a drop-in vagina "replacement".
semi offtopic... If you've ever tried searching slashdot comments, it sucks (you can only search for comment titles, not the text inside). Having full text search capabilities would be a subscription selling point.
CmdrTaco has stated that they can't add features (like that) since they're too busy writing lame filters to deal with trolls. Well, most of the comments I'd like to search for are from trolls!
LZW royalties are only a small part of photoshop or Fireworks, etc. I haven't saved a gif image since 2001 or earlier, since I output to jpeg and png.
Well, Al Gore is on the Apple baord of directors, and IIRC, Steve Jobs contributed to his 2000 election.
Now if you'll excuse me, i have to help a beautiful hooker with a heart of gold expose the corrupt mayor that kidnapped her daughter, with the help of an adorable chinese boy we found on the street.
Usually that's pudge's job. They're probably having a catfight right now.
Wh knows what other stuff AOL/TW might be doing when nobody is looking...
However, it should be noted that she was in the bathroom, looking at a turd that CmdrTaco couldn't flush.
... and why slashdot editors don't read slashdot.
As soon as they can find an editor with experience!!
THIS IS ONLY A WORKING TRANSLATION; I DO NOT TAKE RESPONSIBILITY AS TO POSSIBLE MISTAKES OR ERRORS. I WILL NOT TAKE ANY RESPONSIBILITY CONCERNING THE CONTENT OF THE ORIGINAL TEXT.
Today, I had the possibility to have a look at the incriminating code passages.
Due to a mistake on the part of the representing lawyer's office, my colleague and I - as opposed to the 7 other representatives that were allowed to look at things today - did not have to sign a Non Disclosure Agreement. This was in full contrast to the examiners of Microsoft corp., who apparently had to maintain silence even towards their own superiors and may only give notice to the internal company audit department.
Now for the code itself:
Under the supervision of a notary public, 46 pages were shown, each containing, by one half, code from Linux (for the most part, print-outs of posts taken directly from the Linux-Kernel-Mailing List) and, by the other half, listings of SCO. Whether these are indeed sources of SysV is not comprehensible that way, as they are taken out of their context. Another interesting thing is that all date and time details have been removed from both, even from the comments.
The comments themselves are really identical here and there, even some jokes are the same on both sides. It is, however, conspicuous that in the places that correspond most, the source code that can be found in front of the comments is quite dissimilar after all. The fundamental construction of the queried functions is similar; however, the concrete implementation is quite different. Variables and names of functions are different, loops are structured differently, conditions work via chain queries (?) (Kettenabfrage) or bit patterns (?) (Bitmuster). All in all, only one thing can be said for certain: The functions offered by the respective code passages are often equal, which, however, was to be expected from the start anyway.
In the concrete implementation, there are, however, so many differences, that a proof of the origin being the same will be difficult, even though certainly not impossible.
The crunch, however, is a function of the scheduler, which is, over a length of about 60 lines, indeed identical except for slight differences. In this section, there is also a whole lot of corresponding comments.
Comparable similarity can only be found in one routine of the memory management, which is, however, only in the Linux version accompanied by comments.
Whether a competent proof can be made out of these two correspondences can only be estimated with certainty by a lawyer. I consider the vague similarities in other passages to be insufficient, as the same standards were the basis for both and therefore, a certain correspondence is to be expected.
Concerning the same comments to different source passages, I can see no rhyme or reason in it. This would in any case have to be investigated in again meticulously, in particular with the date and time details provided. Because only with these could a breach of copyright be proved at all.
Concerning the discussion about the part of Linux sold under the GPL by SCO/Caldera, it must be stated that up to the present, no court has had to decide on the legal validity of the GPL. Should this, however, be ascertained, which is not certain, SCO can use only those parts of Linux by way of comparison that were not published by SCO and in the development or co-development SCO did not take part. I consider this, too, a difficulty in the proceedings to come.
As the original, unpatched Linux-sources were not touched but only modifications that had been inserted by different distributors, it has to be clarified in any case whether these might have rights to the queried passages, be it directly or indirectly, e.g. through company mergers, take-overs, "all-inclusive"-deals etc.
The chances for proceedings to open are not especially good, as in most comparable cases, there were agreements out of court.
This, however, is only my personal estimati
Chuck Yeager helped pioneer space flight, but he wasn't an astronaut.
There's an interview with him here (as well as a couple more pictures, so don't click if you're at work, unless you're a gay porn star). A slashdot interview would be nice, if only to see how the moderators handled it.
I'm not sure why he didn't just drink it straight from the bottle.
No olive, but one time we drank vodka and pickle juice.
that's also what CmdrTaco said when he fisted Hemos and pulled out a big lump of shit. I won't go into the details of what happened next, but Kathleen fent reported that his toothbrush needed replacing.
i know what you mean. shaved pussy is so much more sensual. Who wants to eat furburger?
the next OS X release (panther) fixes (or at least improves) the carbon font problems.
The last time i skimmed through some darwin source code (for hfschk, IIRC), NewPointer, NewHandle, etc, were re-implemented as C frontends to malloc.
the DMCA allows reverse engineering for interoperability purposes.
That may be the unix way, but it's not the efficient way.
you do realize that congress must ratify an amendment before the states have an opportunity to vote on it, don't you?
But being lactose intolerant was an advantage once fart-lighting was invented.
This is what the cdparanoia faq has to say about ripping...
I can play audio CDs perfectly; why is reading the CD into a file so difficult and prone to errors? It's just the same thing.
Unfortunately, it isn't that easy. The audio CD is not a random access format. It can only be played from some starting point in sequence until it is done, like a vinyl LP. Unlike a data CD, there are no synchronization or positioning headers in the audio data (a CD, audio or data, uses 2352 byte sectors. In a data CD, 304 bytes of each sector is used for header, sync and error correction. An audio CD uses all 2352 bytes for data). The audio CD *does* have a continuous fragmented subchannel, but this is only good for seeking +/-1 second (or 75 sectors or ~176kB) of the desired area, as per the SCSI spec.
When the CD is being played as audio, it is not only moving at 1x, the drive is keeping the media data rate (the spin speed) exactly locked to playback speed. Pick up a portable CD player while it's playing and rotate it 90 degrees. Chances are it will skip; you disturbed this delicate balance. In addition, a player is never distracted from what it's doing... it has nothing else taking up its time. Now add a non-realtime, (relatively) high-latency, multitasking kernel into the mess; it's like picking up the player and constantly shaking it.
CDROM drives generally assume that any sort of DAE will be linear and throw a readahead buffer at the task. However, the OS is reading the data as broken up, seperated read requests. The drive is doing readahead buffering and attempting to store additional data as it comes in off media while it waits for the OS to get around to reading previous blocks. Seeing as how, at 36x, data is coming in at 6.2MB/second, and each read is only 13 sectors or ~30k (due to DMA restrictions), one has to get off 208 read requests a second, minimum without any interruption, to avoid skipping. A single swap to disc or flush of filesystem cache by the OS will generally result in loss of streaming, assuming the drive is working flawlessly. Oh, and virtually no PC on earth has that kind of I/O throughput; a Sun Enterprise server might, but a PC does not. Most don't come within a factor of five, assuming perfect realtime behavior.
To keep piling on the difficulties, faster drives are often prone to vibration and alignment problems; some are total fiascos. They lose streaming *constantly* even without being interrupted. Philips determined 15 years ago that the CD could only be spun up to 50-60x until the physical CD (made of polycarbonate) would deform from centripetal force badly enough to become unreadable. Today's players are pushing physics to the limit. Few do so terribly reliably.
Note that CD 'playback speed' is an excellent example of advertisers making numbers lie for them. A 36x cdrom is generally not spinning at 36x a normal drive's speed. As a 1x drive is adjusting velocity depending on the access's distance from the hub, a 36x drive is probably using a constant angular velocity across the whole surface such that it gets 36x max at the edge. Thus it's actually spinning slower, assuming the '36x' isn't a complete lie, as it is on some drives.
Because audio discs have no headers in the data to assist in picking up where things got lost, most drives will just guess.
This doesn't even *begin* to get into stupid firmware bugs. Even Plextors have occasionally had DAE bugs (although in every case, Plextor has fixed the bug *and* replaced/repaired drives for free). Cheaper drives are often complete basket cases.
Rant Update (for those in the know):
Several folks, through personal mail and on Usenet, have pointed out that audio discs do place absolute positioning information for (at least) nine out of every ten sectors into the Q subchannel, and that my original stateme