A rootkit provides either control or access via external software that gains access to the system (as a trojan, worm, virus or manually planted).
Wrong.
I wish you people would actually look up the definition of "rootkit" before expounding.
A rootkit can do anything or nothing. It is not what it does that makes it a rootkit. A rootkit is any piece of software that is specifically designed to hide its existence from the OS, or more specifically, to the system administrator. In almost every case, this is done by modifying or replacing system files, so that, for example, the API calls which return a list of processes conventiently now skip over any processes which are owned by the rootkit.
Sony's rootkit was a true rootkit. It was not designed to provide a backdoor, either actively or passively. It was designed to enforce copy protection. Now, beacuse it was piss-poor software, it also was exploitable, but that was due to poor design, not intention. It was not the exploitability of their software that made it a rootkit. It was the fact that it hid its processes from the system administrator.
Warden is not a rootkit, because it makes no attempt whatsoever to hide its existence from the system or the user.
Leading several prominent Ziff Davis publications to report, "The Open Document Format has been abandoned, as its parent organization has closed its doors."
Goodbye and good riddance to the trolling trio and their self-serving vaporware specification.
You are not a geek (which would mean that you got lost and landed on Slashdot by accident).
So I'll vote for #2
Re:You have no idea what you are talking about
on
GIMP 2.4 Released
·
· Score: 1
I do not mean to say that CMYK is irrelevant. Not at all. CMYK workflows are still the norm, and as long as this is the case, we will always need CMYK editing tools. I meant to say that as the shift to 16-bit processing, and RIP-centric color takes place, many of the reasons to stay in CMYK are eliminated. Thus, in the long term, good 16-bit support is more important than CMYK support.
And you're not wrong. In CMYK workflows, it is very common to have your artists doing work on profiled monitors, in the CMYK colorspace of your output device, be it press, ink jet, etc. In that case the tools must support CMYK channels for all editing. That works great for shops with one or similar presses. It is a pain in the ass when you are working with a variety of output devices. It is completely wrong if you are working with HiFi color (more than 4 channels). The "right" way to do it is RGB-centric. Do your work in a neutral RGB colorspace that best represents your workflow. Standardize on this. Then let each individual device's RIP handle the RGB->CMYK conversion for you, and invest in some very good color profiling software and keep your devices calibrated so the output from device to device is consistent. This is where the digital color world is heading.
As to the question of 16-bit integers vs. floating point, the battle was never fought in the first place, so there is nothing to head off. Pixels in RGB documents are almost always expressed as either 8 bit (256 level) integers, or 16-bit integers (actually 32K levels in Adobe Photoshop, but 64K in theory). Don't get me wrong. 16-bit floating point is still possible. TIFF supports it, for instance. Most of the tools do not, or if they do, they convert to integer channel data first (Which in the older Adobe products really screws things up, since their filters are aften doing floating point math on integer data, and introducing errors which leads to color shifts.)
The ICC profile standard expresses conversions in the same way. CIELab color can easily be done in floating point. In fact Apple's colorsync engine uses 32-bit per channel CIELab calculations to eliminate errors. But the end product is still expressed in integers.
The biggest problem with 16-bit RGB presently seems to be Adobe's half-assed way of implementing it with 15-bit math. This has probably improved in CS3. Not sure yet.
Re:16 bit RGB support is more important than CMYK
on
GIMP 2.4 Released
·
· Score: 1
That is true enough with the older tools. However, I am used to using very modern RIPs where trapping has become so bloody good that we never ever have to touch it. On our DI press, the dot gain is so consistent that we do not even think about it anymore.
Re:16 bit RGB support is more important than CMYK
on
GIMP 2.4 Released
·
· Score: 1
Ink management should never be done in your raster editor. That is, and should always be, a function of the RIP. In an RGB workflow, it HAS to be.
For Pantone monochrome, duotone, tritone, etc., RGB can't be used. But who works with spot colors even in Photoshop? It's done, but it's rare.
Re:You have no idea what you are talking about
on
GIMP 2.4 Released
·
· Score: 2, Insightful
You know, there is always somebody on Slashdot who reads too fast, hits reply, and starts his posts with "You have no idea what you are talking about".
I Am Not An Idiot. I work with CMYK color all day every day. 4 color DI presses. Wide format digital ink jet. (4 and 7 color). Short run toner-based crap. I have profiled every device in this shop, most of them several times over. I have done the same for other shops on contract. I know color.
Your talk of integer math vs. half-float math is irrelevant in the real printing world. 16-bit ICC profiles are expressed in unsigned integers. 16-bit RGB images are store as unsigned integers. Whatever math you use to get there, you end up at an integer representation.
Did you catch the part about "cube-hypercube" conversion in my post? That's the same as saying 3D-4D. (duh!)
As to your comment about printing devices, that's true enough for presses, but not true at all for ink jet. Presses are sloppy, even the best of them. Small errors blend in. You can't see them anymore. Modern ink jet is so precise that small errors become very evident. Stippling from shadows to highlights. Uneven gradiants. Loss of detail in shadows. Move into the 7 channel HIFI color world (CMYK+ RGB, OG, GB, etc.), and you really notice the limitations.
In the end, you and I are talking apples and oranges. There are two different processes here at work: The math which generates the Lab CMYK tables, and the conversion of a given Lab color to CMYK (In this case it is RGB -> LAB -> CMYK). The former is not 3D-4D at all. The latter is.
It is the Lab -> CMYK conversion that is from a 3 coordinate system to a 4 coordinate system. Because the profile would be so large as to be unusable if it contained a value for every possible Lab combination, interpolation must be done. It is that interpolation where the 3D-4D math comes in, and it is there that the precision problem is introduced. It is for this reason that when doing CMYK-CMYK conversions, device link profiles are the preferred method, since there is no intermediate conversion to LAB, and 4D-4D math is less prone to errors.
The math which generates the LAB -> CMYK conversion LUT is another animal entirely. This is not cube-hypercube, because the problem is separated into two separate operations. The color component of any given pixel is separated from from the grayscale component. A black generation method is then applied whereby a certain amount of CMY is replaced with K. Here is where the finesse comes in the production of color profiles. RBG images have no black generation method. Black is black is black. CMYK images throw this out the window. It is your black generation curve that is going to give you that added contrast and detail that is device dependent.
Using four channels does give you a finer degree of control. The same image expressed in 8-bit RGB lacks this precision, and it lacks it in a manner that is visible to the naked eye. Again, this is because of gamut. Your typical CMYK image does not not map to the full gamut of a given RGB color space. In an 8-bit space, a CMYK image does not get to use all 256 steps in any given channel. As I said at the beginning, 16-bit precision eliminates most of these issues. Precision errors are relegated to noise. Gamut compression becomes irrelevant. Are you listening now?
Re:16 bit RGB support is more important than CMYK
on
GIMP 2.4 Released
·
· Score: 1
Regarding duotone, you are correct. Gimp can't handle it. However, as for ink management, that should not be a function of a raster editor in the first place. That's for RIPs.
16 bit RGB support is more important than CMYK
on
GIMP 2.4 Released
·
· Score: 3, Informative
The digital color world is slowly but steadily shifting to an RGB workflow. The one thing that has impeded this move is the use of 8-bit color, which effectively means mapping a 32-bit color space to a 24-bit space. This mapping is a cube-hypercube mapping done via an ICC colorspace conversion. The cube-hypercube mapping is subject to error. This error is trivialized once the RGB colorspace is in 16-bit. Then the conversion is 48-bit to 32-bit, relegating conversion errors to noise that is below the threshold of vision, or even of the output devices.
Furthermore, RGB colorspaces almost always have a wider gamut than standard CMYK colorspaces such as ISO, SWOP, and GRACoL. Here again, the 8-bit problem comes into play. When RGB color is converted to a standard CMYK colorspace, the conversion is not really even 24->32 bit, since part of the RGB space is outside the gamut of the CMYK colorspace. Effectively, this means that instead of getting a 256-step gradation in any given channel, you get a smaller gradation, sometimes (for instance in the case of Adobe98 RGB -> SWOP) a MUCH smaller gradation. This leads to stepping problems in gradiants and a loss of detail in images, particularly in shadows. Once more, the move to 16-bit RGB color eliminates these problems.
So, here's the point: By working in a 16-bit RGB color space, one can effectively do anything that they could in a CMYK colorspace. (Yes, the extra channel is nice for color correction, but not necessary). The final step, conversion to CMYK, has already been implemented in at least two open source engines: ArgyleCMS and LCMS. The conversion to CMYK in an RGB workflow, is the final step. (Unless, of course, you are printing to a lightjet, lamba, etc). The CMYK colorspace that would be used is the colorspace of the output device.
In professional color, this is not even an issue, for the most part, since most modern RIPs do this conversion for you. 16-bit color support is now starting to become universal in the RIP world. As that happens, the Gimp becomes a viable tool for professional color work.
And you immediately make the false assumption that I expect "Not a single one" to be the answer. It never occurred to you that when I said "I wonder how many" that I really meant "I wonder how many".
I may or may not be an idiot. But you are most definitely a sarcastic jerk.
Bingo! I have to wonder how many of the studies tracking CO2 concentrations against temperature, have bothered to ask the question whether or not the increase in CO2 is the cause or the effect.
Furthermore, has anyone found any way to actually measure what effect increases in CO2 have in the incredibly complex and extraordinary difficult to model atmosphere of the earth itself, vs. the very simple cloud chambers they use in the lab?
Pr0ntab: A score, equal to the amount of time in tenths of a minute, that elapses from the moment a news article is posted to the first comment relating said article to a person's porn collection or viewing habits.
Pr0ntible: The statistical likelihood that any given article will have a low Pr0ntab score, where 1.0 is the highest score, and 0 the lowest.
Pr0ntabulary: A time sensitive, categorical table of subject matter, where each category is assigned a Pr0ntible, and said table is organized in descending order by Pr0ntible.
Example: On today's Pr0ntabulary, the Storage category ranks near the top.
So would I be a bad person if I walked like a Tai Chi master on such a floor, thus keeping my surplus energy to myself (or is that surplus chi)?
The difference is placing your foot and transferring weight by shifting your center of balance, rather than "falling" from foot to foot like most people walk.
One of the oft repeated tenets of those who believe in the moon landing hoax theory is that the Saturn V was such a piss poor design that it was no way robust enough to get us safely to the moon and back.
And so NASA now gives the hoax believers ammo, by confiscating and banning all internal plans and diagrams for the rocket. Obviously they don't want anyone to know...
I once read an article that heavily criticized the complexity of HDMI which made it extremely challenging to create cables of any length. The issue seemed to be that instead of simply implementing a serial stream of data, they have several parallel streams traveling over different twisted pairs, which all need to keep in sync in order to get a clean picture. Easy with lower resolutions or very short cable runs, but once you pump up the resolution you must also pump up the bandwidth. The greater the rez, the worse it gets. This is largely responsible for the high prices of HDMI cabling. It's a real bear to do right. (Plus there is the added cost of licensing the technology, which also sucks.)
So, my question is, has DisplayPort simplified any of this? Are they sending all video data as a single digital stream over a single twisted pair? If so, despite all the DRM BS, this is a huge reason to support DisplayPort vs. HDMI. It should also make it possible to run the data stream over coax for much longer distances (mix in the DRM, though, and that probably isn't possible).
Insofar as supernatural explanations have been a priori eliminated from any consideration, in no way can you legitimately make the claim that "all the evidence so far does not point to God." Thus my contention that the difference between the two camps can never be fruitfully discussed on the basis of arguments concerning the process of evolution.
It is the premise that must first be addressed: naturalism vs. ID, both of which are unfalsifiable. The claim of scientific isolationism from any such "philosophical" discussion is not accurate. If evolution is to be considered as a legitimate explanation for all life, it relies upon naturalism as its essential premise, a premise that cannot be falsified. Like it or not, you cannot have a fruitful debate on the subject of origins unless you first deal with the premises upon which each theory relies. The unwillingness shown by the majority of evolutionists to enter this debate is understandable.
You, like the above poster, have read my argument, and assumed you know everything I think about evolution. Now, if you wish to debate ME, then do not form an argument in such a manner as: "Creations love to . .." and therefore I must also. Foolish of you, for I actually read what evolutionists write, and know their arguments. Don't believe me? Then I invite you to take it offline with me and find out. My email is mwdiers [-at-] gmail dot com.
Now, I have said nothing to insult the intelligence of evolutionists. Yet you, as do so many others who are unable to hold a dispassionate debate on this subject, attempt to blaspheme my religion. Like it or not, that is ad hominem.
I said life from nothing to cut through the question of the mechanics of evolution, and get down to the brass tacks. If you had read the GP, you would know this. Ultimately, one arrives at the question of naturalism vs. ID, a question upon which evolution relies as its essential premise. If the answer to that either-or debate is naturalism, then evolution must, by necessity, be valid and true. If, on the other hand, naturalism is false, then a key supporting pillar of evolution has been shaken, and the theory, as a theory, is no longer a requirement, but merely a possibility. It would then have to be held to a higher standard of proof, because by necessity, it would have to subject itself not only to the natural laws as we know them, but also the supernatural laws which we do not yet know.
So, since you cannot separate evolution from naturalism, I ask you, and hope you will answer, is naturalism falsifiable?
Please read my response to the other Slashdotter who responded to me. It answers you as well, since you both make the same arguments.
And you obviously do not listen, because your "God poofed the first critter into existence?" argument has nothing to do with what I said. Nor anywhere did I deny natural selection, mutation, genetic drift, etc. I believe in all of these things. How easy it is to pigeonhole your intellectual adversaries, and thus evade an answer. Would you agree with this statement? "He who disagrees with me must by definition be an ignoramus." Nevertheless that is what you have done. I do not believe you are an ignoramus, but you find it much easier to treat me so. After all, why argue with ignorant people who do not know what they are talking about?
I do not believe that evolution is a religion. It is an internally consistent scientific theory. Evolutionism is an ideology, a belief in the theory of evolution.
Yes, I said life from nothing, because that is precisely what evolution demands, life from nothing. When speaking of the origin of life, one cannot, as you seem wont to do, divorce it from the question of the origin of the universe itself. Even evolution relies upon a universe which has pre-existing and consistent laws. These laws either spontaneously arose from nothing in the big bang, or they were created from nothing. If you are dealing with the question of evolution as opposed to creation as an explanation for life as we know it, then you cannot separate these two subjects.
Remarkable that I would be called a troll. On what basis? This shows how bigotted so much of Slashdot is when it comes to a serious debate on this topic. Don't agree with your opponent? Then Mod down! I NEVER mod down a person simply because I do not agree with him.
I have seen many abortive attempts here at defending creationism, which generally end up adopting the same invalid arguments as do evolutionists, thus posing the question rather than answering it. Thank you for cutting to the heart of the argument. It is here that the debate must be carried out if it is going to be effective.
As an earlier post here notes, the essential tenet of evolutionism, spontaneous life from nothing, or taking it a step further, spontaneous something from nothing, is also unfalsifiable. This leaves us at an impasse by this standard of judgment. If both ID and naturalism are at their very core unfalsifiable, then one is required to choose one or the other as a premise, a premise that cannot be disproven, for all that follows thereafter. As an internally consistent model which explains the observed universe may be developed from either premise, one is left with a choice which cannot be based upon any objective standard but only upon one's personal aversions.
If any of my children plan [subjunctive active] on becoming [copulative participle] a writer, I will [future auxiliary] definitely not allow [active] them to attend [active infinitive] NCSU.
To my knowledge there was no 2.0 Ghz G4 Powerbook, except via aftermarket upgrade. You are nitpicking.
My specs: 1.67Ghz G4 Powerbook with 1.5Gb RAM.
NeoOffice: From cold launch to Splash screen: 35 seconds.
From cold launch to blinking curser in Writer: 70 seconds.
To load a 1 page text document: 8 seconds.
To load a 50 page text document: 19 seconds.
To open a new spreadsheet: 5 seconds.
To open a spreadsheet with 300 rows: 11 seconds.
Office 2004:
From cold launch to Splash screen: 4 seconds.
From cold launch to blinking curser in Word document: 21 seconds.
To open a 2 page text document: 1.5 seconds.
To open an 18 page text document: 1.5 seconds.
To open a new spreadsheet: 1 second.
To open a 350 row spreadsheet: 1 second.
You were saying?
That said, I hate Office 04, and would never choose to run it. Way too many issues despite it's relative speed advantages over NeoOffice.
If you read carefully, I said that the X11 port has the font and printing issues.
Seems like you have a problem with NeoOffice/OOo in general...
This is the kneejerk reaction that I would expect from a typical Slashdot fanboy, which I am sure you are not. (You are welcome to correct me if I am wrong). I am an avid OOo user, and have been for as long as the product forked from StarOffice. The first thing I installed on my first Mac (the Powerbook G4 1.6Ghz that I am typing on right now) was the X11 build of OOo, because I already knew it well, and had an extensive library of docs in ODT and SXW format (Some 3 to 4 hundred to be exact, of my own writing). My previous laptop was a Sony Vaio running Gentoo. At home, on both my wife's and my Windows boxes, we run OOo for everything.
If you think that NeoOffice runs fine on your Powerbook G4, then you are either more patient than I, or you are not being honest with yourself. I mean, I can sit there watch the text from a freshly opened Writer document redraw, sometimes two or three times. Scrolling is slow, and halting. (although the X11 build is worse in this area). Ridiculous.
And that is precisely the problem. Your increase in speed has absolutely nothing to do with the latest NeoOffice build, and everything to do with your Intel Mac. In 100% of the cases that I have heard NeoOffice users claiming that NeoOffice has improved, it is because they upgraded to an Intel Mac. Hello?! (And by the way, gasoline must really have improved recently, because I can suddenly drive a lot faster after I upgraded my '84 Honda Civic to a '07 T-bird).
That's great for you. I envy you. But there are a ton of G4's out there that cannot use NeoOffice. Even on my 1.6Ghz G4 (note: the fastest G4 available), NeoOffice is barely usable. Not only does it start slow, the whole interface is a slug. I can run Office 2000 via VirtualPC faster than I can run NeoOffice natively. I am not kidding. I tested it.
The newest Java-Cocoa version of NeoOffice is no faster than the older Java-Carbon versions. It just looks prettier. (Oh, and it has docx and VBA support, ripped from other projects, which will soon be in the trunk anyway. Please.) If the OOo port had reliable font and printer support (and no, the fondue kludge is nowhere near reliable) I would gladly use it's ugly X11 interface for all my work. For word processing, though, I gave up and bought Mellel.
Slashdot Mirror
Ok, I've been spanked.
Peace?
Wrong.
I wish you people would actually look up the definition of "rootkit" before expounding.
A rootkit can do anything or nothing. It is not what it does that makes it a rootkit. A rootkit is any piece of software that is specifically designed to hide its existence from the OS, or more specifically, to the system administrator. In almost every case, this is done by modifying or replacing system files, so that, for example, the API calls which return a list of processes conventiently now skip over any processes which are owned by the rootkit.
Sony's rootkit was a true rootkit. It was not designed to provide a backdoor, either actively or passively. It was designed to enforce copy protection. Now, beacuse it was piss-poor software, it also was exploitable, but that was due to poor design, not intention. It was not the exploitability of their software that made it a rootkit. It was the fact that it hid its processes from the system administrator.
Warden is not a rootkit, because it makes no attempt whatsoever to hide its existence from the system or the user.
Leading several prominent Ziff Davis publications to report, "The Open Document Format has been abandoned, as its parent organization has closed its doors."
Goodbye and good riddance to the trolling trio and their self-serving vaporware specification.
So I'll vote for #2
I do not mean to say that CMYK is irrelevant. Not at all. CMYK workflows are still the norm, and as long as this is the case, we will always need CMYK editing tools. I meant to say that as the shift to 16-bit processing, and RIP-centric color takes place, many of the reasons to stay in CMYK are eliminated. Thus, in the long term, good 16-bit support is more important than CMYK support.
And you're not wrong. In CMYK workflows, it is very common to have your artists doing work on profiled monitors, in the CMYK colorspace of your output device, be it press, ink jet, etc. In that case the tools must support CMYK channels for all editing. That works great for shops with one or similar presses. It is a pain in the ass when you are working with a variety of output devices. It is completely wrong if you are working with HiFi color (more than 4 channels). The "right" way to do it is RGB-centric. Do your work in a neutral RGB colorspace that best represents your workflow. Standardize on this. Then let each individual device's RIP handle the RGB->CMYK conversion for you, and invest in some very good color profiling software and keep your devices calibrated so the output from device to device is consistent. This is where the digital color world is heading.
As to the question of 16-bit integers vs. floating point, the battle was never fought in the first place, so there is nothing to head off. Pixels in RGB documents are almost always expressed as either 8 bit (256 level) integers, or 16-bit integers (actually 32K levels in Adobe Photoshop, but 64K in theory). Don't get me wrong. 16-bit floating point is still possible. TIFF supports it, for instance. Most of the tools do not, or if they do, they convert to integer channel data first (Which in the older Adobe products really screws things up, since their filters are aften doing floating point math on integer data, and introducing errors which leads to color shifts.)
The ICC profile standard expresses conversions in the same way. CIELab color can easily be done in floating point. In fact Apple's colorsync engine uses 32-bit per channel CIELab calculations to eliminate errors. But the end product is still expressed in integers.
The biggest problem with 16-bit RGB presently seems to be Adobe's half-assed way of implementing it with 15-bit math. This has probably improved in CS3. Not sure yet.
See here: http://www.rags-int-inc.com/PhotoTechStuff/ColorCalculator/AdobeMath.html
That is true enough with the older tools. However, I am used to using very modern RIPs where trapping has become so bloody good that we never ever have to touch it. On our DI press, the dot gain is so consistent that we do not even think about it anymore.
Ink management should never be done in your raster editor. That is, and should always be, a function of the RIP. In an RGB workflow, it HAS to be.
For Pantone monochrome, duotone, tritone, etc., RGB can't be used. But who works with spot colors even in Photoshop? It's done, but it's rare.
You know, there is always somebody on Slashdot who reads too fast, hits reply, and starts his posts with "You have no idea what you are talking about".
I Am Not An Idiot. I work with CMYK color all day every day. 4 color DI presses. Wide format digital ink jet. (4 and 7 color). Short run toner-based crap. I have profiled every device in this shop, most of them several times over. I have done the same for other shops on contract. I know color.
Your talk of integer math vs. half-float math is irrelevant in the real printing world. 16-bit ICC profiles are expressed in unsigned integers. 16-bit RGB images are store as unsigned integers. Whatever math you use to get there, you end up at an integer representation.
Did you catch the part about "cube-hypercube" conversion in my post? That's the same as saying 3D-4D. (duh!)
As to your comment about printing devices, that's true enough for presses, but not true at all for ink jet. Presses are sloppy, even the best of them. Small errors blend in. You can't see them anymore. Modern ink jet is so precise that small errors become very evident. Stippling from shadows to highlights. Uneven gradiants. Loss of detail in shadows. Move into the 7 channel HIFI color world (CMYK+ RGB, OG, GB, etc.), and you really notice the limitations.
In the end, you and I are talking apples and oranges. There are two different processes here at work: The math which generates the Lab CMYK tables, and the conversion of a given Lab color to CMYK (In this case it is RGB -> LAB -> CMYK). The former is not 3D-4D at all. The latter is.
It is the Lab -> CMYK conversion that is from a 3 coordinate system to a 4 coordinate system. Because the profile would be so large as to be unusable if it contained a value for every possible Lab combination, interpolation must be done. It is that interpolation where the 3D-4D math comes in, and it is there that the precision problem is introduced. It is for this reason that when doing CMYK-CMYK conversions, device link profiles are the preferred method, since there is no intermediate conversion to LAB, and 4D-4D math is less prone to errors.
The math which generates the LAB -> CMYK conversion LUT is another animal entirely. This is not cube-hypercube, because the problem is separated into two separate operations. The color component of any given pixel is separated from from the grayscale component. A black generation method is then applied whereby a certain amount of CMY is replaced with K. Here is where the finesse comes in the production of color profiles. RBG images have no black generation method. Black is black is black. CMYK images throw this out the window. It is your black generation curve that is going to give you that added contrast and detail that is device dependent.
Using four channels does give you a finer degree of control. The same image expressed in 8-bit RGB lacks this precision, and it lacks it in a manner that is visible to the naked eye. Again, this is because of gamut. Your typical CMYK image does not not map to the full gamut of a given RGB color space. In an 8-bit space, a CMYK image does not get to use all 256 steps in any given channel. As I said at the beginning, 16-bit precision eliminates most of these issues. Precision errors are relegated to noise. Gamut compression becomes irrelevant. Are you listening now?
Regarding duotone, you are correct. Gimp can't handle it. However, as for ink management, that should not be a function of a raster editor in the first place. That's for RIPs.
The digital color world is slowly but steadily shifting to an RGB workflow. The one thing that has impeded this move is the use of 8-bit color, which effectively means mapping a 32-bit color space to a 24-bit space. This mapping is a cube-hypercube mapping done via an ICC colorspace conversion. The cube-hypercube mapping is subject to error. This error is trivialized once the RGB colorspace is in 16-bit. Then the conversion is 48-bit to 32-bit, relegating conversion errors to noise that is below the threshold of vision, or even of the output devices.
Furthermore, RGB colorspaces almost always have a wider gamut than standard CMYK colorspaces such as ISO, SWOP, and GRACoL. Here again, the 8-bit problem comes into play. When RGB color is converted to a standard CMYK colorspace, the conversion is not really even 24->32 bit, since part of the RGB space is outside the gamut of the CMYK colorspace. Effectively, this means that instead of getting a 256-step gradation in any given channel, you get a smaller gradation, sometimes (for instance in the case of Adobe98 RGB -> SWOP) a MUCH smaller gradation. This leads to stepping problems in gradiants and a loss of detail in images, particularly in shadows. Once more, the move to 16-bit RGB color eliminates these problems.
So, here's the point: By working in a 16-bit RGB color space, one can effectively do anything that they could in a CMYK colorspace. (Yes, the extra channel is nice for color correction, but not necessary). The final step, conversion to CMYK, has already been implemented in at least two open source engines: ArgyleCMS and LCMS. The conversion to CMYK in an RGB workflow, is the final step. (Unless, of course, you are printing to a lightjet, lamba, etc). The CMYK colorspace that would be used is the colorspace of the output device.
In professional color, this is not even an issue, for the most part, since most modern RIPs do this conversion for you. 16-bit color support is now starting to become universal in the RIP world. As that happens, the Gimp becomes a viable tool for professional color work.
And you immediately make the false assumption that I expect "Not a single one" to be the answer. It never occurred to you that when I said "I wonder how many" that I really meant "I wonder how many".
I may or may not be an idiot. But you are most definitely a sarcastic jerk.
Bingo! I have to wonder how many of the studies tracking CO2 concentrations against temperature, have bothered to ask the question whether or not the increase in CO2 is the cause or the effect.
Furthermore, has anyone found any way to actually measure what effect increases in CO2 have in the incredibly complex and extraordinary difficult to model atmosphere of the earth itself, vs. the very simple cloud chambers they use in the lab?
Pr0ntab: A score, equal to the amount of time in tenths of a minute, that elapses from the moment a news article is posted to the first comment relating said article to a person's porn collection or viewing habits.
Pr0ntible: The statistical likelihood that any given article will have a low Pr0ntab score, where 1.0 is the highest score, and 0 the lowest.
Pr0ntabulary: A time sensitive, categorical table of subject matter, where each category is assigned a Pr0ntible, and said table is organized in descending order by Pr0ntible.
Example: On today's Pr0ntabulary, the Storage category ranks near the top.
They can read, can't they? Duh!
So would I be a bad person if I walked like a Tai Chi master on such a floor, thus keeping my surplus energy to myself (or is that surplus chi)?
The difference is placing your foot and transferring weight by shifting your center of balance, rather than "falling" from foot to foot like most people walk.
One of the oft repeated tenets of those who believe in the moon landing hoax theory is that the Saturn V was such a piss poor design that it was no way robust enough to get us safely to the moon and back.
And so NASA now gives the hoax believers ammo, by confiscating and banning all internal plans and diagrams for the rocket. Obviously they don't want anyone to know...
I once read an article that heavily criticized the complexity of HDMI which made it extremely challenging to create cables of any length. The issue seemed to be that instead of simply implementing a serial stream of data, they have several parallel streams traveling over different twisted pairs, which all need to keep in sync in order to get a clean picture. Easy with lower resolutions or very short cable runs, but once you pump up the resolution you must also pump up the bandwidth. The greater the rez, the worse it gets. This is largely responsible for the high prices of HDMI cabling. It's a real bear to do right. (Plus there is the added cost of licensing the technology, which also sucks.)
So, my question is, has DisplayPort simplified any of this? Are they sending all video data as a single digital stream over a single twisted pair? If so, despite all the DRM BS, this is a huge reason to support DisplayPort vs. HDMI. It should also make it possible to run the data stream over coax for much longer distances (mix in the DRM, though, and that probably isn't possible).
Insofar as supernatural explanations have been a priori eliminated from any consideration, in no way can you legitimately make the claim that "all the evidence so far does not point to God." Thus my contention that the difference between the two camps can never be fruitfully discussed on the basis of arguments concerning the process of evolution.
It is the premise that must first be addressed: naturalism vs. ID, both of which are unfalsifiable. The claim of scientific isolationism from any such "philosophical" discussion is not accurate. If evolution is to be considered as a legitimate explanation for all life, it relies upon naturalism as its essential premise, a premise that cannot be falsified. Like it or not, you cannot have a fruitful debate on the subject of origins unless you first deal with the premises upon which each theory relies. The unwillingness shown by the majority of evolutionists to enter this debate is understandable.
You, like the above poster, have read my argument, and assumed you know everything I think about evolution. Now, if you wish to debate ME, then do not form an argument in such a manner as: "Creations love to . . ." and therefore I must also. Foolish of you, for I actually read what evolutionists write, and know their arguments. Don't believe me? Then I invite you to take it offline with me and find out. My email is mwdiers [-at-] gmail dot com.
Now, I have said nothing to insult the intelligence of evolutionists. Yet you, as do so many others who are unable to hold a dispassionate debate on this subject, attempt to blaspheme my religion. Like it or not, that is ad hominem.
I said life from nothing to cut through the question of the mechanics of evolution, and get down to the brass tacks. If you had read the GP, you would know this. Ultimately, one arrives at the question of naturalism vs. ID, a question upon which evolution relies as its essential premise. If the answer to that either-or debate is naturalism, then evolution must, by necessity, be valid and true. If, on the other hand, naturalism is false, then a key supporting pillar of evolution has been shaken, and the theory, as a theory, is no longer a requirement, but merely a possibility. It would then have to be held to a higher standard of proof, because by necessity, it would have to subject itself not only to the natural laws as we know them, but also the supernatural laws which we do not yet know.
So, since you cannot separate evolution from naturalism, I ask you, and hope you will answer, is naturalism falsifiable?
Please read my response to the other Slashdotter who responded to me. It answers you as well, since you both make the same arguments.
And you obviously do not listen, because your "God poofed the first critter into existence?" argument has nothing to do with what I said. Nor anywhere did I deny natural selection, mutation, genetic drift, etc. I believe in all of these things. How easy it is to pigeonhole your intellectual adversaries, and thus evade an answer. Would you agree with this statement? "He who disagrees with me must by definition be an ignoramus." Nevertheless that is what you have done. I do not believe you are an ignoramus, but you find it much easier to treat me so. After all, why argue with ignorant people who do not know what they are talking about?
I do not believe that evolution is a religion. It is an internally consistent scientific theory. Evolutionism is an ideology, a belief in the theory of evolution.
Yes, I said life from nothing, because that is precisely what evolution demands, life from nothing. When speaking of the origin of life, one cannot, as you seem wont to do, divorce it from the question of the origin of the universe itself. Even evolution relies upon a universe which has pre-existing and consistent laws. These laws either spontaneously arose from nothing in the big bang, or they were created from nothing. If you are dealing with the question of evolution as opposed to creation as an explanation for life as we know it, then you cannot separate these two subjects.
Remarkable that I would be called a troll. On what basis? This shows how bigotted so much of Slashdot is when it comes to a serious debate on this topic. Don't agree with your opponent? Then Mod down! I NEVER mod down a person simply because I do not agree with him.
I have seen many abortive attempts here at defending creationism, which generally end up adopting the same invalid arguments as do evolutionists, thus posing the question rather than answering it. Thank you for cutting to the heart of the argument. It is here that the debate must be carried out if it is going to be effective.
As an earlier post here notes, the essential tenet of evolutionism, spontaneous life from nothing, or taking it a step further, spontaneous something from nothing, is also unfalsifiable. This leaves us at an impasse by this standard of judgment. If both ID and naturalism are at their very core unfalsifiable, then one is required to choose one or the other as a premise, a premise that cannot be disproven, for all that follows thereafter. As an internally consistent model which explains the observed universe may be developed from either premise, one is left with a choice which cannot be based upon any objective standard but only upon one's personal aversions.
If any of my children plan [subjunctive active] on becoming [copulative participle] a writer, I will [future auxiliary] definitely not allow [active] them to attend [active infinitive] NCSU.
Way to go, Cliff Clavin!
To my knowledge there was no 2.0 Ghz G4 Powerbook, except via aftermarket upgrade. You are nitpicking.
My specs: 1.67Ghz G4 Powerbook with 1.5Gb RAM.
NeoOffice:
From cold launch to Splash screen: 35 seconds.
From cold launch to blinking curser in Writer: 70 seconds.
To load a 1 page text document: 8 seconds.
To load a 50 page text document: 19 seconds.
To open a new spreadsheet: 5 seconds.
To open a spreadsheet with 300 rows: 11 seconds.
Office 2004:
From cold launch to Splash screen: 4 seconds.
From cold launch to blinking curser in Word document: 21 seconds.
To open a 2 page text document: 1.5 seconds.
To open an 18 page text document: 1.5 seconds.
To open a new spreadsheet: 1 second.
To open a 350 row spreadsheet: 1 second.
You were saying?
That said, I hate Office 04, and would never choose to run it. Way too many issues despite it's relative speed advantages over NeoOffice.
If you read carefully, I said that the X11 port has the font and printing issues.
This is the kneejerk reaction that I would expect from a typical Slashdot fanboy, which I am sure you are not. (You are welcome to correct me if I am wrong). I am an avid OOo user, and have been for as long as the product forked from StarOffice. The first thing I installed on my first Mac (the Powerbook G4 1.6Ghz that I am typing on right now) was the X11 build of OOo, because I already knew it well, and had an extensive library of docs in ODT and SXW format (Some 3 to 4 hundred to be exact, of my own writing). My previous laptop was a Sony Vaio running Gentoo. At home, on both my wife's and my Windows boxes, we run OOo for everything.
If you think that NeoOffice runs fine on your Powerbook G4, then you are either more patient than I, or you are not being honest with yourself. I mean, I can sit there watch the text from a freshly opened Writer document redraw, sometimes two or three times. Scrolling is slow, and halting. (although the X11 build is worse in this area). Ridiculous.
And that is precisely the problem. Your increase in speed has absolutely nothing to do with the latest NeoOffice build, and everything to do with your Intel Mac. In 100% of the cases that I have heard NeoOffice users claiming that NeoOffice has improved, it is because they upgraded to an Intel Mac. Hello?! (And by the way, gasoline must really have improved recently, because I can suddenly drive a lot faster after I upgraded my '84 Honda Civic to a '07 T-bird).
That's great for you. I envy you. But there are a ton of G4's out there that cannot use NeoOffice. Even on my 1.6Ghz G4 (note: the fastest G4 available), NeoOffice is barely usable. Not only does it start slow, the whole interface is a slug. I can run Office 2000 via VirtualPC faster than I can run NeoOffice natively. I am not kidding. I tested it.
The newest Java-Cocoa version of NeoOffice is no faster than the older Java-Carbon versions. It just looks prettier. (Oh, and it has docx and VBA support, ripped from other projects, which will soon be in the trunk anyway. Please.) If the OOo port had reliable font and printer support (and no, the fondue kludge is nowhere near reliable) I would gladly use it's ugly X11 interface for all my work. For word processing, though, I gave up and bought Mellel.