$COMPANY made a point of stating that they don't believe their product violates any of Microsoft's patents. Nor, $COMPANY said, did the software giant share with them exactly which patents they believe Linux violates. Just the same, $COMPANY is disappointed with the reaction they've received from the open source community.
Machine simulation of genetic/evolutionary algorithms often produces so-called "junk" which when analysed further, this frequently proves to be tied to the function of the overall organism in mysterious ways. I'm sure that leading GA researcher John Koza made this observation in early papers, but it's something that anyone playing with genetic algorithms will encounter sooner or later.
I couldn't find the quote I was looking for, but only this broad statement from Genetic Programming: Biologically Inspired
Computation that Creatively Solves Non-Trivial
Problems, Koza (1998):
The design of complex entities by the evolutionary process in nature is another important type of problemsolving
that is not governed by logic. In nature, solutions to design problems are discovered by the probabilistic
process of evolution and natural selection. There is nothing logical about this process. Indeed, inconsistent and
contradictory alternatives abound. In fact, such genetic diversity is necessary for the evolutionary process to
succeed. Significantly, the solutions evolved by evolution and natural selection almost always differ from those
created by conventional methods of artificial intelligence and machine learning in one very important respect.
Evolved solutions are not brittle; they are usually able to grapple with the perpetual novelty of real environments.
HFS+ may date only from System 8.1, but HFS is considerably older - nearly 22 years now. It's very mature and stable code, even the POSIX stuff they bolted on later for HFS+.
Well, we can wait a bit longer for ZFS. If you can't wait, grab a Solaris 10,Solaris Express, or OpenSolaris distribution and start playing today! I'm not comfortable committing precious data to anything else.
One day most of our day-to-day filesystems will incorporate the ideas in ZFS - one or two have been seen before, but never in such a devastating ensemble. The 'Z' may as well stand for 'Zen': Grokking why ZFS is revolutionary seems to be a Zen-like enlightenment:) Many people still wonder "huh? what's the fuss?", as happens with any generational change...
Somehow I had it in my head that it was Viking. I remember seeing the pictures in National Geographic at the time - I'm sure the Io volcano was a cover image.
I'm sure, California being California (and the article does hint at some of Knoll's business savvy) that the Knolls are not exactly starving. His name is still first in the splash screen credits, last I looked...
Future submitters, just keep this text on hand the next time some idiot signs a deal with Microshaft:
$COMPANY made a point of stating that they don't believe their product violates any of Microsoft's patents. Nor, $COMPANY said, did the software giant share with them exactly which patents they believe Linux violates. Just the same, $COMPANY is disappointed with the reaction they've received from the open source community.
It's almost beyond belief that these guys keep giving the community a great big "FUCK YOU", and yet are always surprised when we don't welcome them as liberators, with flowers and open wallets.
... booting OS X on a Mac and booting Solaris 10 on a *** are completely different questions.
I don't see why Apple couldn't complete this functionality on that schedule: They know their operating system and integrated hardware intimately, are not burdened by Sun's qualification requirements, and have had considerable time (including the post-iPhone extension) to work on it.
The publication does not want to take responsibility.
It is true that RGB->CMYK separation is non-linear, non-reversible, and for optimal results depends on complex details of the actual printing process. Asking for CMYK images is certainly not a solution, for all those reasons, and fundamentally there is no assurance that what the author sees is what will be printed, even - or especially - if she delivers a CMYK file.
Consider what the author is "seeing", and imagines she'll see on paper: Is it an image on her CRT (likely to be wildly different from the magazine she'll have in her hand later)? Is it an image from her desktop printer (ditto)? The only way the author can have confidence in what her picture will look like, is if the publication provides a "contract proof", with adequate time for a revision cycle, before publication. That's the traditional way.
The digital workflow introduces more room for error, because 1) the author generally isn't trained to make separations, even if the publication provides a specification (those are often ambiguous and confusing); 2) the author isn't equipped to proof them; 3) the author usually won't understand the limitations of the rest of the production process, and she'll eventually have to suck it up when it goes pear-shaped and the picture is nothing like she imagined it would be.
Of course this can all happen with RGB submissions too, but there are fewer pitfalls. For example, a well-trained separator will recognise if an image has a lot of colours outside CMYK's reproducible gamut, and can bring this problem to the author's attention. If properly configured, Photoshop can produce a decent 'soft proof' which will reveal such problems. But the devil is in the details, and 99% of users won't have the training to configure it (and virtually no scientific authors will have calibrated monitors).
The crucial ingredient here - often skipped - is the proof/approval process. A colour-calibrated PDF is better than nothing, but still depends on the viewing conditions.
Some journals are certainly still geared up to use CMYK.
Of course they are. This doesn't change my point at all.
My assertion is that Photoshop's CMYK features are not needed, and in fact, it's a bad idea for authors to make their own separations (in my experience). The publication should do it, and take responsibility for them.
However, with some features of CS3, Adobe is indeed making a play for the scientific image processing market, having saturated graphic arts. This rarely works out. When the monopoly player's only remaining strategy is to conquer new vertical markets adequately served by existing third parties, the results are usually the worst of both worlds (cf: Microsoft).
it is trivial these days to convert from RGB to CMYK in production,
Indeed, and I mentioned this above. In fact, it's been trivial since Photoshop 1.0 was released (it always did good separations). However, there is no reason why the author should make such separations, and it's usually best if they don't try, as the result is rarely going to be optimal for the particular publication, despite Photoshop's abilities.
Your point about Powerpoint is very familiar to graphic arts people and bureau operators. Anything except EPS/PDF is likely to reproduce incorrectly (and even then, there are many gotchas). This has been true since the emergence of PostScript based digital pre-press (more than 20 years now).
There is no way to safely avoid a proper approval process (round tripping proofs to authors) because of the myriad ways things can screw up undetected. Just as the paper author is not expert in making separations, the bureau/printer staff are likely to miss errors in a proof that are obvious to the author.
Never get the bureau or printer to make corrections: They frequently introduce new errors in doing so. (I'm speaking from long experience:); and never allow anything to be printed without seeing a "contract" or approval proof first - you will eventually suffer embarrassment or worse.
the lack of proper CYMK support in GIMP is a bit of a setback
In pre-press, yes (most of my career is in digital graphic arts). In scientific imaging, is it really a must-have feature? It's very hard to imagine CMYK being useful at all; it's entirely based on the properties of particular printing inks.
Even its importance in pre-press is waning, as the industry has already moved away from pre-separated film-based imagery (transparencies drum scanned to CMYK) and towards digital images in native RGB. I know that a lot of my time in the past 5 years was spent learning how to colour-correct and separate RGB images directly (a lot of photographers - who might have been top notch in film - produce awful digital shots).
Can you tell me then... why Photoshop's admittedly excellent CMYK support is important to scientific image processing?? Is it in order to provide separations of RGB images for publication? Even in the rare case that a magazine has provided sensible and complete specifications for its separations, that's not a task that most Photoshop users are competent to do, in any case (trust me:).
Express was a labor of love. It was a small miracle getting Express to be available both for free and for commercial use for customers let alone the engineering work to get it up and running, We made a business decision to not allow 3rd party extensibility in Express. The reason we're able to offer Express for free and even let developers build commercial applications with Express is because we limit 3rd party extensibility of Express, specifically by removing support macros, add-ins, and VSIP packages.
Translation: "It's practically impossible for us to deliver what people actually want."
One day guys like Dan Fernandez, with their incredible, heartrending passion to defeat internal obstacles to actually help customers, might figure out that it's a heck of a lot easier to do that when you live OUTSIDE the Green Zone.
But it's not clear what role "ripping out useful features" plays in actually helping people. Hey Dan, in the open source world, we don't have to cripple products to be allowed to ship them... free.
Slashdot Mirror
I think the press release will read:
Machine simulation of genetic/evolutionary algorithms often produces so-called "junk" which when analysed further, this frequently proves to be tied to the function of the overall organism in mysterious ways. I'm sure that leading GA researcher John Koza made this observation in early papers, but it's something that anyone playing with genetic algorithms will encounter sooner or later.
I couldn't find the quote I was looking for, but only this broad statement from Genetic Programming: Biologically Inspired Computation that Creatively Solves Non-Trivial Problems, Koza (1998):
It's amazing people still write headlines and article summaries without mentioning the enabling technology in question.
When the monopoly is finally busted, I guess it will no longer be implicit that "We're talking about Windows, of course."
HFS+ may date only from System 8.1, but HFS is considerably older - nearly 22 years now. It's very mature and stable code, even the POSIX stuff they bolted on later for HFS+.
:) Many people still wonder "huh? what's the fuss?", as happens with any generational change...
Well, we can wait a bit longer for ZFS. If you can't wait, grab a Solaris 10, Solaris Express, or OpenSolaris distribution and start playing today! I'm not comfortable committing precious data to anything else.
One day most of our day-to-day filesystems will incorporate the ideas in ZFS - one or two have been seen before, but never in such a devastating ensemble. The 'Z' may as well stand for 'Zen': Grokking why ZFS is revolutionary seems to be a Zen-like enlightenment
That every antitrust story is tagged politics but never crime?
A curious clue to contemporary American thought patterns?
So you're a fan of security by obscurity?
Ever notice how the really secure systems (*BSD, Solaris, etc) have every line of code public?
PS. It's spelled "kernel".
Stupid mistake, thx ;)
Somehow I had it in my head that it was Viking. I remember seeing the pictures in National Geographic at the time - I'm sure the Io volcano was a cover image.
I'm sure, California being California (and the article does hint at some of Knoll's business savvy) that the Knolls are not exactly starving. His name is still first in the splash screen credits, last I looked...
Io, one of the moons of Jupiter, showing a volcanic eruption on the rim, 1979.
Water flows like dry silt.
'you know, Microsoft isn't ALWAYS evil'
I never said anything like that! Check my posting history if you don't believe me, kthxbai
Future submitters, just keep this text on hand the next time some idiot signs a deal with Microshaft:
It's almost beyond belief that these guys keep giving the community a great big "FUCK YOU", and yet are always surprised when we don't welcome them as liberators, with flowers and open wallets.
The chance that Linux does not infringe at all is rather small.
The chance that Linux infringes after said "infringements" are detailed with specificity, and subsequently coded around, is zero.
they shocked us when they did it off the 10.4 base.
It did not shock those of us who know that NEXTSTEP was transparently portable to at least four architectures.
... booting OS X on a Mac and booting Solaris 10 on a *** are completely different questions.
I don't see why Apple couldn't complete this functionality on that schedule: They know their operating system and integrated hardware intimately, are not burdened by Sun's qualification requirements, and have had considerable time (including the post-iPhone extension) to work on it.
5:1 they ship with ZFS boot.
n/t
when they cancel this offering in a year or two due to poor sales, they can say they tried, but Linux on the desktop just doesn't work.
I can see one 500-pound gorilla that is really keen for things to play out that way.
Does the phrase "poisoned chalice" mean anything to you?
The publication does not want to take responsibility.
It is true that RGB->CMYK separation is non-linear, non-reversible, and for optimal results depends on complex details of the actual printing process. Asking for CMYK images is certainly not a solution, for all those reasons, and fundamentally there is no assurance that what the author sees is what will be printed, even - or especially - if she delivers a CMYK file.
Consider what the author is "seeing", and imagines she'll see on paper: Is it an image on her CRT (likely to be wildly different from the magazine she'll have in her hand later)? Is it an image from her desktop printer (ditto)? The only way the author can have confidence in what her picture will look like, is if the publication provides a "contract proof", with adequate time for a revision cycle, before publication. That's the traditional way.
The digital workflow introduces more room for error, because 1) the author generally isn't trained to make separations, even if the publication provides a specification (those are often ambiguous and confusing); 2) the author isn't equipped to proof them; 3) the author usually won't understand the limitations of the rest of the production process, and she'll eventually have to suck it up when it goes pear-shaped and the picture is nothing like she imagined it would be.
Of course this can all happen with RGB submissions too, but there are fewer pitfalls. For example, a well-trained separator will recognise if an image has a lot of colours outside CMYK's reproducible gamut, and can bring this problem to the author's attention. If properly configured, Photoshop can produce a decent 'soft proof' which will reveal such problems. But the devil is in the details, and 99% of users won't have the training to configure it (and virtually no scientific authors will have calibrated monitors).
The crucial ingredient here - often skipped - is the proof/approval process. A colour-calibrated PDF is better than nothing, but still depends on the viewing conditions.
Some journals are certainly still geared up to use CMYK.
Of course they are. This doesn't change my point at all.
My assertion is that Photoshop's CMYK features are not needed, and in fact, it's a bad idea for authors to make their own separations (in my experience). The publication should do it, and take responsibility for them.
However, with some features of CS3, Adobe is indeed making a play for the scientific image processing market, having saturated graphic arts. This rarely works out. When the monopoly player's only remaining strategy is to conquer new vertical markets adequately served by existing third parties, the results are usually the worst of both worlds (cf: Microsoft).
it is trivial these days to convert from RGB to CMYK in production,
Indeed, and I mentioned this above. In fact, it's been trivial since Photoshop 1.0 was released (it always did good separations). However, there is no reason why the author should make such separations, and it's usually best if they don't try, as the result is rarely going to be optimal for the particular publication, despite Photoshop's abilities.
Your point about Powerpoint is very familiar to graphic arts people and bureau operators. Anything except EPS/PDF is likely to reproduce incorrectly (and even then, there are many gotchas). This has been true since the emergence of PostScript based digital pre-press (more than 20 years now).
There is no way to safely avoid a proper approval process (round tripping proofs to authors) because of the myriad ways things can screw up undetected. Just as the paper author is not expert in making separations, the bureau/printer staff are likely to miss errors in a proof that are obvious to the author.
Never get the bureau or printer to make corrections: They frequently introduce new errors in doing so. (I'm speaking from long experience:); and never allow anything to be printed without seeing a "contract" or approval proof first - you will eventually suffer embarrassment or worse.
the lack of proper CYMK support in GIMP is a bit of a setback
In pre-press, yes (most of my career is in digital graphic arts). In scientific imaging, is it really a must-have feature? It's very hard to imagine CMYK being useful at all; it's entirely based on the properties of particular printing inks.
Even its importance in pre-press is waning, as the industry has already moved away from pre-separated film-based imagery (transparencies drum scanned to CMYK) and towards digital images in native RGB. I know that a lot of my time in the past 5 years was spent learning how to colour-correct and separate RGB images directly (a lot of photographers - who might have been top notch in film - produce awful digital shots).
Can you tell me then... why Photoshop's admittedly excellent CMYK support is important to scientific image processing?? Is it in order to provide separations of RGB images for publication? Even in the rare case that a magazine has provided sensible and complete specifications for its separations, that's not a task that most Photoshop users are competent to do, in any case (trust me :).
Express was a labor of love. It was a small miracle getting Express to be available both for free and for commercial use for customers let alone the engineering work to get it up and running, We made a business decision to not allow 3rd party extensibility in Express. The reason we're able to offer Express for free and even let developers build commercial applications with Express is because we limit 3rd party extensibility of Express, specifically by removing support macros, add-ins, and VSIP packages.
Translation: "It's practically impossible for us to deliver what people actually want."
One day guys like Dan Fernandez, with their incredible, heartrending passion to defeat internal obstacles to actually help customers, might figure out that it's a heck of a lot easier to do that when you live OUTSIDE the Green Zone.
But it's not clear what role "ripping out useful features" plays in actually helping people. Hey Dan, in the open source world, we don't have to cripple products to be allowed to ship them ... free.
Mircosfot make great benefit to nation America!
Heh, thanks. My brain's faded more in those 20 years than I thought :-)