Possible new feature for next Photoshop

Ryan McGinnis wrote:
On Sun, 16 Oct 2011, Wolfgang Weisselberg wrote:
Eric Stevens wrote:

There is also the very considerable testing required to ensure that
your software doesn't conflict with commonly available software from
others such as McAfee, Firefox etc.

And who does that testing? Nearly noone. If it conflicts with a
virus scanner, fix the scanner. If it conflicts with Firefox ---
and why should it, unless it uses it a lot --- claim that only
IE is supported. Done.

As someone who beta tested CS4 and CS5, yes, there are people doing
testing. Quite a few. Have you ever actually worked for or with a large
software company, or is the extent of your coding all Open Source / GNU?

I've worked for companies who *live* *and* *die* by the software
they produce[1]. I'm the one who's clamouring for more testing and
and more automated testing. Sometimes I don't have to actually
convert people --- I only have to get them to take the resources
to test more/better.

I have quite a good idea how much, or rather, how little testing is
done and how "conflict[s] with commonly available [but completely
unrelated] software" is handled.

As to GNU --- tests have shown long ago that GNU software is
more stable and has less bugs than vendor supplied software.
Especially on an 1:1 comparison, since the programs do the same
stuff and should have identical outputs. (Not to mention that GNU
software usually has lots more features and much less annoyances
and shortcomings.)

-Wolfgang

[1] literally. Microsoft, for example, can survive something
like Vista, Microsoft Bob, and many more. Where I worked,
such a misstep would have been fatal.

Ryan McGinnis wrote:
On Mon, 17 Oct 2011, Wolfgang Weisselberg wrote:
nospam wrote:

[DNG converter]

it's not a work around. if someone gets a new camera they can get a
newer version of camera raw and use dng converter to batch convert all
of them to dng and keep using their existing old version of photoshop.
it works fine and is fully supported. it's also totally free.

Totally free? You get the source code? You get the rights
to use, read, improve, share and share the improved versions?

Or is that just "free beer, but certainly *no* free speech"?

Free means "it costs nothing" in common language.

So "it costs nothing speech" is what the US upholds?
Fits.


If I give you a
photograph of mine "for free", that means it costs nothing.

But nospam didn't write 'it's for free'. Nospam wrote "it's
also totally free." TOTALLY free.


Most people
would not then assume that they're allowed to make 20,000 copies of the
photo and resell them.

If it's TOTALLY free, I would assume exactly that. So would
enough other people.

And if it's about software, I'd assume that twice as much.

-Wolfgang

Pete A wrote:
On 2011-10-28 00:17:30 +0100, Wolfgang Weisselberg said:
Pete A wrote:

[...]

The only thing that should be allowed to change kernel code is a vendor
supplied patch or update.

This is too stupid for words.

You probably suffer from "Patches fall from the sky and are
all distributed by Microsoft --- and there are no operating
systems outside Windows, anyway" syndrome.

Yeah. What's your excuse for writing total ******** in your reply?

********? Because e.g. Linux kernel developers *have* to compile
and change the kernel code, without going through a 'vendor'
every 10 minutes?

Not to mention that quite a few people want the freedom to change,
compile, add patches to their own kernel.

But in Pete's world users are not enabled and have to use Windows
(thank you, secure boot). Or Macs. A few may be allowed to use
Red Hat or SuSE (and nothing else) (but will be unable to boot
Windows) and that's that. Welcome to the new freedom.


Next year: "The only camera that should be allowed to take
photos is a pinhole phone camera."

-Wolfgang

Ryan McGinnis wrote:
On Mon, 24 Oct 2011, nospam wrote:
McGinnis wrote:

Adobe does not "limit compatibility". Camera makers continually change
the RAW file format over and over again, requiring Adobe to task a team of
coders to recode their RAW engine to deal with them. These employees cost
money.

that's because every new sensor is a little different. they don't sit
around and think gee how can we change something.

Every sensor is different, but with standardization, this could be
overcome.

True.

That would however mean that all sensors would have to conform to
whatever the standard allows. And we all know how far-looking
standards can be. Like ... being able to address only 1 MByte
(640k should be enough for everyone), FAT and large disks
(that's why we have FAT32 and co. now ... for now), disks
~2 GB and booting, the various SD, SDHC, SDXC variants, and a
million other examples.

So that would hinder experimentation and improvements.


Every camera is different, but so far all programs that I use
to view JPEGs don't care (or even know) what camera or software the JPEG
came from.

Many programs cannot even deal properly with aRGB JPEGs, never mind
other colourspaces. Or anything outside the basic JPEG structure.

And basic JPEG is an end product. Made for an unchanging target.

There is no reason this could not be the case with RAW as well

RAW is a source format, which changes as technology improves
or changes.

-- indeed, DNG (Adobe's format) supports all cameras.

No, it doesn't. Try Lytro.
It's support at best allows most data to be written. It doesn't
mean the data is understood. Rectangular pixels, for example,
or hexagonal ones --- whoever reads the DNG must *know* not only
these facts, but also how to *deal* with them.

So at the very best DNG is somewhat like unicode: you can write
lots of characters --- but you also must display the glyphs of the
characters in some font (which means you need to have the font)
and even with all that you'll likely not make any sense out of
most languages.

As you put it,
there is little motivation for cameramakers to standardize. This is not
Adobe's fault.

Why should camera makers help Adobe, anyway, and punish Adobe's
competition? After all, most camera makers have their own
specialized RAW converter that does exactly what the camera
needs ...

-Wolfgang

On 2011-10-29 00:23:31 +0100, Wolfgang Weisselberg said:

Pete A wrote:
On 2011-10-28 00:17:30 +0100, Wolfgang Weisselberg said:
Pete A wrote:

[...]

The only thing that should be allowed to change kernel code is a vendor
supplied patch or update.

This is too stupid for words.

You probably suffer from "Patches fall from the sky and are
all distributed by Microsoft --- and there are no operating
systems outside Windows, anyway" syndrome.

Yeah. What's your excuse for writing total ******** in your reply?

********? Because e.g. Linux kernel developers *have* to compile
and change the kernel code, without going through a 'vendor'
every 10 minutes?

Kernel developers write kernel code and make it available to end users
via a vending mechanism. Strangely enough, these are called patches or
updates as appropriate. RPMs are one example of packaging and delivery
methods. Those who release Linux kernels are the vendors. So, what was
"too stupid for words?"

Not to mention that quite a few people want the freedom to change,
compile, add patches to their own kernel.

Now you have digressed from secure OSs. For experimental systems or
systems for which security is not a high priority, of course anyone can
modify their own OS.

But in Pete's world users are not enabled and have to use Windows
(thank you, secure boot). Or Macs. A few may be allowed to use
Red Hat or SuSE (and nothing else) (but will be unable to boot
Windows) and that's that. Welcome to the new freedom.

Quite a few corporations would be a little upset if an employee changed
kernel code!

Next year: "The only camera that should be allowed to take
photos is a pinhole phone camera."

Nah, phone cameras are less secure than stand-alone models.


By the way, Pascal strings are NOT packed arrays of char - you would
know this if you had ever used the language. Furthermore, any Pascal
that allows the copy in your example is not using an extension, it is
using a broken compiler :-)

Ryan McGinnis wrote:
On Sat, 29 Oct 2011, Wolfgang Weisselberg wrote:

I've worked for companies who *live* *and* *die* by the software
they produce[1]. I'm the one who's clamouring for more testing and
and more automated testing. Sometimes I don't have to actually
convert people --- I only have to get them to take the resources
to test more/better.

I have quite a good idea how much, or rather, how little testing is
done and how "conflict[s] with commonly available [but completely
unrelated] software" is handled.

I asked if you'd ever worked at a large software company.

I've never worked for Microsoft, no. But they also make hardware,
so they wouldn't count as a software company, I guess.

Should I take
this as a no? I asked because you seemed to feel extremely familiar with
Adobe's testing and debugging procedures. I doubt this is the case.

I understand you work for Adobe, then?


Have *you* ever worked in a position where you were privy to
the testing procedures of software that was mission critical?

-Wolfgang

Pete A wrote:
On 2011-10-29 00:23:31 +0100, Wolfgang Weisselberg said:
Pete A wrote:
On 2011-10-28 00:17:30 +0100, Wolfgang Weisselberg said:
Pete A wrote:

The only thing that should be allowed to change kernel code is a vendor
supplied patch or update.

This is too stupid for words.

You probably suffer from "Patches fall from the sky and are
all distributed by Microsoft --- and there are no operating
systems outside Windows, anyway" syndrome.

Yeah. What's your excuse for writing total ******** in your reply?

********? Because e.g. Linux kernel developers *have* to compile
and change the kernel code, without going through a 'vendor'
every 10 minutes?

Kernel developers write kernel code and make it available to end users
via a vending mechanism.

git is a vending mechanism? Funny.

Strangely enough, these are called patches or
updates as appropriate. RPMs are one example of packaging and delivery
methods. Those who release Linux kernels are the vendors.

You're not very familiar with Linux kernel development,
right? Else you'd know that you'd get the kernel as a
(signed) tarball or as a git pull.

Individuals, volunteers and some companies then turn the
kernel into RPMs or DEBs. I've done so myself, when I wanted
*my* choices of drivers build, either into the kernel or as
modules.

Heck, everyone using nvidia's proprietary driver is *compiling*
a wrapper for it and *inserting* it into the 'kernel code'.


So, what was
"too stupid for words?"

How do the developers --- of which there are thousands, and most
of them are not fulltime developers or vendors --- test their own
changes when they're not allowed to update the kernel, since it
doesn't come from a vendor?


Not to mention that quite a few people want the freedom to change,
compile, add patches to their own kernel.

Now you have digressed from secure OSs.

Which was never the topic. The topic was your dream of a
world where only Microsoft Windows will run.


For experimental systems or
systems for which security is not a high priority, of course anyone can
modify their own OS.

And how do I tell my system it's an "experimental system"
without any malware being able to do the very same?


But in Pete's world users are not enabled and have to use Windows
(thank you, secure boot). Or Macs. A few may be allowed to use
Red Hat or SuSE (and nothing else) (but will be unable to boot
Windows) and that's that. Welcome to the new freedom.

Quite a few corporations would be a little upset if an employee changed
kernel code!

If you don't want a certain employee to be able to change kernel,
programs, data etc. on certain machines, just don't give them the
rights to do that. Easy as apple pie, and a complete no-brainer.

It's *not* necessary to remove that right from the whole
world for everyone else, though, that would be using
100-megaton nukes against gnats.


Next year: "The only camera that should be allowed to take
photos is a pinhole phone camera."

Nah, phone cameras are less secure than stand-alone models.

Don't forget the straight jackets for everyone.


By the way, Pascal strings are NOT packed arrays of char - you would
know this if you had ever used the language.

Would you kindly tell me what strings are per ISO 7185?


Furthermore, any Pascal
that allows the copy in your example is not using an extension, it is
using a broken compiler :-)

Read
http://www.lysator.liu.se/c/bwk-on-pascal.html

Then kindly start rewriting all the system tools in Pascal,
just for fun.

-Wolfgang

On 2011-11-01 18:49:41 +0000, Wolfgang Weisselberg said:

Pete A wrote:
[...]
Now you have digressed from secure OSs.

Which was never the topic. The topic was your dream of a
world where only Microsoft Windows will run.

Rubbish: read my posts and you'll see that since I retired after making
loads of money from MS systems, I no longer have to use them. Bliss :-)
My Usenet client alone should've made that obvious to you, duh!

[more ******** removed]

By the way, Pascal strings are NOT packed arrays of char - you would
know this if you had ever used the language.

Would you kindly tell me what strings are per ISO 7185?

Your inability to understand the essence of my posts is priceless.

The first element of a traditional Pascal string is the length
indicator - hardly a "packed array of char" is it? Had you advanced to
the stage of writing "Hello World." in Pascal you would've known that.

The enhanced Pascal strings to encompass Unicode; compatibility with C
function calling; copy-on-write semantics for efficiency in memory
management; passing by reference instead of a copy or pointer means
that the storage container cannot possibly be a "packed array of char"
or WideChar as they are in C. Negative offsets into the storage
(inacessible to the programmer) are used to manage these enhanced
reference-counted strings via a memory management system that paved the
way to some of the languages we have now. There is nothing in the C
runtime libraries that can hold a candle to at least two breeds of
modern Pascal.

Type libraries are a classic example of the limitation of C and C++ in
supporting only static construction of objects. COM and COM+ exemplify
this limitation with their idiotic error-prone complexity, incessant
need for updates and resulting system incompatibilities. I.e.
application updates usually require corresponding (though incompatible)
system updates. It results in both "DLL Hell" and type library hell.
Object Pascal was dynamic from its inception and rarely suffers from
these horrendous problems.

If you knew the bare-bones of fundamental computer programming right
through to complex systems engineering you would not have made the
catalogue of errors in your posts.

Furthermore, any Pascal
that allows the copy in your example is not using an extension, it is
using a broken compiler :-)

Read
http://www.lysator.liu.se/c/bwk-on-pascal.html

Then kindly start rewriting all the system tools in Pascal,
just for fun.

Again, start from Computer Programming 101: you obviously dived into
computing without understanding the basic essentials. No, don't give me
your CV because you've already shown it for what it is. I have never
employed an argumentative git.

Had you learnt from the ground up, then decades later read "Advanced
C++. Programming Styles and Idioms.", you would not be making yourself
look like an ass now.

Asking me to explain strings in terms of ISO 7185 is as stupid as me
asking you to explain your computer in terms of BS 1363.

As always, your bluster, occasional bluff at a reference or two, and ad
hominem replies are your trademarks. Chill out, for goodness sake -
you'll live longer. Sometimes your observations and thoughts make
worthwhile reading; sometimes your replies are insightfully humorous -
in this thread they are neither of these.

Pete A wrote:
On 2011-10-23 03:04:19 +0100, Ray Fischer said:

Pete A wrote:
On 2011-10-14 21:17:04 +0100, Charles E. Hardwidge said:

[...]
Microsoft made a huge deal out of dropping 16 bit support in 64 bit OS, and
after reading through the (junior) development team's report explaining why
spotted where they'd made some mistakes. The reality is they just weren't
capable enough to figure out how to do it and the clock was ticking.

Money, money, money.

Exactly. Intel CPUs maintain 16-bit emulation mode available for any
_competent_ OS designer to support. The fact that most hardware vendors
no longer provide a floppy disk drive does not mean the CPU is
incapable of running 16-bit DOS programs. To me, this shows an
incredible feat of backwards compatibility engineering by Intel and the
incredible level of incompetence of some OS vendors.

You should realize that that backwards compatibility comes at a price.
Higher prices and lower performance.

Windows has both.

The subject is the Intel processor. Having trouble staying focussed?

--
Ray Fischer | Mendocracy (n.) government by lying
| The new GOP ideal

J. Clarke wrote:
says...
On 2011-10-23 03:04:19 +0100, Ray Fischer said:
Pete A wrote:
On 2011-10-14 21:17:04 +0100, Charles E. Hardwidge said:

[...]
Microsoft made a huge deal out of dropping 16 bit support in 64 bit OS, and
after reading through the (junior) development team's report explaining why
spotted where they'd made some mistakes. The reality is they just weren't
capable enough to figure out how to do it and the clock was ticking.

Money, money, money.

Exactly. Intel CPUs maintain 16-bit emulation mode available for any
_competent_ OS designer to support. The fact that most hardware vendors
no longer provide a floppy disk drive does not mean the CPU is
incapable of running 16-bit DOS programs. To me, this shows an
incredible feat of backwards compatibility engineering by Intel and the
incredible level of incompetence of some OS vendors.

You should realize that that backwards compatibility comes at a price.
Higher prices and lower performance.

Windows has both.

I'd like to know who is making faster cheaper processors today by
sacrificing backwards compatibility.

Notice that Intel isn't able to compete in the mobile market.

--
Ray Fischer | Mendocracy (n.) government by lying
| The new GOP ideal