Sure, a labeling system for liability makes sense in principle. Note that RedHat could sell RHL with a higher rating if they wanted; the point is: it's the ultimate vendor, not the creator, of the software that's responsible for any guarantees.
I question, though, whether it's practical. Many software problems are actually not bugs, they are user error. While user error are also often due to bad UI or documentation, the responsibility is shared between the vendor and the user. And many other software problems involve interactions between multiple components; when Adobe Photoshop kills your image while you are working in a plug-in, how do we determine who is responsible?
Now see I really think that the person defrauding customers might share just a little bit of the blame. I mean they are the criminal right?
You can blame them if you like, but it isn't rational to spend our tax dollars on tracking them down and convicting them.
Also, where do you draw the line? If typing "http://somebank.com/index.html" crashes their server and their "official" home page is "http://somebank.com/index.htm", am I guilty of computer hacking and tampering? Companies are starting to argue that. We should put a stop to that--it's unnecessary. Companies have the resources and skills to protect themselves against security problems.
I was actually wondering about this. If you look around, you'll find that the 4G Nano is amazingly cheap--cheaper than 2G flash players from manufacturers that are usually much cheaper than Apple.
However, Apple may have been able to get such a discount legitimately: usually, the price of chips like this falls because manufacturers need to recover their initial costs; if Apple's contract lets them do that through a sufficiently large initial volume, it may have made sense for them to go for it.
Still, if Apple gets conditions that are much better than those for other manufacturers, that is a concern. If Apple manages to grab a big chunk of the production of high capacity flash chips at a low price, then it may be hard for other manufacturers to stay in the market. You may like iPods a lot, but it would still be good to have competition. Some of the other manufacturers of flash players offer better battery life, real-time MP3 recording, MPEG4 playback, and many other features that Apple just doesn't have in the Nano.
The fact is that the market has already decided the answer to this. People buy the least expensive software they can get away with.
That's because quality and security are properties of software that are difficult to evaluate for most buyers; people end up with worse software than they actually need. This is a standard example where markets fail to reach the overall optimal outcome.
It doesn't make economic sense to create some kind of liability for the authors of software; there is no single level of quality that everybody needs.
The best thing we can do to increase software quality is to hold the people responsible who can actually do something about it: the people who buy software.
If your Windows PC crashes and you lose data, that's your responsibility; you could have gotten something different.
If the bank's Microsoft-based database server has a serious security hole and someone breaks in and defrauds customers, then the bank should be held fully responsible for that; they shouldn't be able to shift responsibility to either Microsoft or the person who broke in. That will force institutions like banks to negotiate contracts with software vendors that ensure an appropriately high level of correctness. And there is no need to burden our courts with "hackers"--you won't be able to find and lock them all up, so locking up some of them is not a rational strategy for making computers secure.
In any case, if one wanted to, one could easily make legal distinctions betwen FOSS and Microsoft/Apple when it comes to liability. First, expert users generally have to accept a higher level of responsibility than non-experts. Arguably, FOSS users are, by definition, expert users. Also, for-pay software involves an actual sale, which can easily and sensibly be regulated differently from non-sale distribution when it comes to liability.
Yeah. I think it will be worth looking at again after Glasgow comes out. Right now, it's aimed at a niche market and it still has the somewhat cumbersome architecture of the original Gimp.
Please forgive me if I'm wrong but don't most image editing functions work in float and then just clamp the results?
Historically, almost no image editing or processing was using floating point (floating point used to be quite slow). Today, floating point is somewhat more common. However, even if all the calculations are done in floating point, if you convert to 8 bit for intermediate results, you still get most of the artifacts and problems of integer processing.
In the end, if you want the benefits of >8 bits per channel, you need to store your images that way, both in memory and on disk. And while 32 bit floating point is overkill in terms of dynamic range (16 bits per channel is probably enough for almost everything), it's probably time to move directly to 32 bits because it means there are a lot of messy details you just don't have to think about anymore and that slow down development.
The primary reason for needing 16 bit and 32 bit per channel data is not for display but for editing and processing; with 8 bits per channel, there is very little room for adjustments and corrections. And you don't need a display with more than 8 bits per channel for editing 16 bit or 32 bit per channel images, or to see the artefacts resulting from working with 8 bit per channel images.
Most of the time, efficient code is the code that is easy to write without too many dangerous bugs, easy to debug, easy to deploy and easy and maintain. And Java is the right language when you use such definition.
I agree that writing good, straightforward code is what one should aim for, but you can do that in many languages (C/C++ being notable exceptions). The problem with Java is that straightforward code tends to be unnecessarily slow, and that is why Java deserves its reputation for being a "slow language". It has nothing to do with garbage collection, and everything with language misfeatures specific to Java.
I fully agree: Apple's decision to go with Object Pascal, and then a collection of assembly-language toolboxes had really bad consequences for the industry, consequences that we suffer from to this day.
I disagree, though, with your assessment of the relationships of the different languages; Java, unfortunately, is not the son of Objective-C, it is the son of Object Pascal and C++. Objective-C would have been the right language for the original Macintosh--close to the machine to allow Apple to meet their price targets, but dynamic enough to eventually turn into something decent. Instead, Appple led the industry on a 20 year detour into static object-oriented languages and, worse, "toolboxes", and is now returning to a dynamic language that is 20 years out of date.
Fortunately, C# and Java do address this problem. While the C# and Java languages themselves are cumbersome and static, their runtimes are sufficiently powerful to put decent dynamic languages on top of them and still interoperate with the unwashed masses of static object-oriented programmers.
Objective-C's object system and general philosophy is _very_ smalltalk-ish.
Yes, Objective-C has late binding and limited dynamic typing, but that's only a tiny part of what Smalltalk offered in 1980.
The sad fact is that it is Apple, more than any other company, that is responsible for the bloated toolkits and libraries that we see today: they set the pattern with the Lisa and the Macintosh toolboxes, and everybody else copied it, up to and including Java and C#. And while Objective-C happens to copy some of Smalltalk's nice object features, it is has grave deficiencies in areas like run-time safety, reflection, and resource management.
I had a Lisa, and Apple made the same mistakes with the Lisa as Xerox had made with the Star: it was too expensive, in particular for the limited hardware and completely incompatible software you got.
Claims that the Lisa represented significant technological innovation seem dubious to me. You need to compare the Lisa to the totality of R&D efforts around at the time, not just the Star. Xerox alone had Alto, Star, Smalltalk, and probably others. The GUI of the Lisa was an evolutionary change, and not always for the better; what was under the hood of the Lisa can charitably be described as pedestrian. It took Apple 20 years to catch up and finally adopt system software that even is in the same league as Smalltalk-80 (that's "80" as in "1980"; Smalltalk-80 is the language and platform that Objective-C and Cocoa are modeled on).
Lisa's main significance was to be a prototype for, and cannibalized for, Macintosh (and it served as the main development machine for Macintosh apps for a while), but I can't think of any significant new technology it introduced.
Garbage collection is generally more efficient, byte for byte allocated, than malloc.
The problem is that Java programmers and Java libraries tend to be written in such a way that they do a lot more memory allocation, just because it's so easy to do. The quality of Java code in general is not very impressive (and this include Sun's own libraries). And Java itself makes writing efficient code harder than it needs to be.
So, people can write highly efficient code in garbage collected languages, and even in Java. But Java programmers generally don't bother, and that's the reason why Java has such a bad reputation, and it deserves it.
SVG is primarily a vector graphics format--kind of like a PNG or JPEG, only that you can scale it up without seeing pixels. Another way of looking at it is that it is roughly equivalent to Adobe Illustrator files. SVG can also be used for animation, like Flash, but that's not its main purpose in life, at least not in the short term. Right now, SVG is being used more and more for icons, user interface elements, diagrams, figures, and other static images.
Oh, I agree: 32bit is a must. It's a major deficiency that the Gimp doesn't have it, and it was a major deficiency when Photoshop didn't have it.
I don't think retrofitting the Gimp is the right approach, though. Writing 32bit imaging tools (and I have been doing that for a couple of decades) is very different from writing 8bit imaging tools.
A Leica M lacks what a Canon SureShot has out of the box; that doesn't make the SureShot a better or more professional tool camera. Ease of use and multitude of features are not the measure of how good a tool is for commercial use.
I think both the Gimp and Photoshop are poor photo editing applications for professional users because they have too many extraneous features and don't focus on addressing the essentials well.
In the case of Photoshop, its real problem is that, in addition to trying to be a photo editing application, it's a web design application, an application for creating computer art, and lots more. It's the typical feature bloat that successful Windows applications experience.
SIOX is machine vision; this kind of algorithm has been developed before, but I don't know about the relationship between SIOX and previous methods--maybe the Berlin guys improved on prior work, or maybe they just didn't know about it.
Now, that Microsoft is tightening it down and including a virus scanner,
Including a virus scanner is not "tightening it down", it's treating a symptom. And it's treating a symptom that Microsoft copied again from someone else.
I'm somewhat sympathetic to Symantec: Microsoft really is doing what they have been doing with other applications before, driving a vendor out of business by bundling their own (often inferior software) with the OS.
If Microsoft wants to tighten down Windows, they need to fix it, not add a virus scanner.
Sadly, apparently it isn't. The content creators might argue that that kind of re-purchasing is already factored in into their "already thin" profit margins.
Slashdot Mirror
This seems like a pretty direct observation.
Since when did scientists start behaving like fundies?
It's always been that way. Hence, the saying that old scientific theories don't go away until their proponents are all dead.
It's not a big deal, though: even though old scientists usually don't learn, the next generation is open to new ideas.
who at 11 one evening was reading email from employees at home while nursing a vodka
So, one wonders: had those E-mails actually been sent to him, or was he just spying on their mailboxes?
Sure, a labeling system for liability makes sense in principle. Note that RedHat could sell RHL with a higher rating if they wanted; the point is: it's the ultimate vendor, not the creator, of the software that's responsible for any guarantees.
I question, though, whether it's practical. Many software problems are actually not bugs, they are user error. While user error are also often due to bad UI or documentation, the responsibility is shared between the vendor and the user. And many other software problems involve interactions between multiple components; when Adobe Photoshop kills your image while you are working in a plug-in, how do we determine who is responsible?
Now see I really think that the person defrauding customers might share just a little bit of the blame. I mean they are the criminal right?
You can blame them if you like, but it isn't rational to spend our tax dollars on tracking them down and convicting them.
Also, where do you draw the line? If typing "http://somebank.com/index.html" crashes their server and their "official" home page is "http://somebank.com/index.htm", am I guilty of computer hacking and tampering? Companies are starting to argue that. We should put a stop to that--it's unnecessary. Companies have the resources and skills to protect themselves against security problems.
I was actually wondering about this. If you look around, you'll find that the 4G Nano is amazingly cheap--cheaper than 2G flash players from manufacturers that are usually much cheaper than Apple.
However, Apple may have been able to get such a discount legitimately: usually, the price of chips like this falls because manufacturers need to recover their initial costs; if Apple's contract lets them do that through a sufficiently large initial volume, it may have made sense for them to go for it.
Still, if Apple gets conditions that are much better than those for other manufacturers, that is a concern. If Apple manages to grab a big chunk of the production of high capacity flash chips at a low price, then it may be hard for other manufacturers to stay in the market. You may like iPods a lot, but it would still be good to have competition. Some of the other manufacturers of flash players offer better battery life, real-time MP3 recording, MPEG4 playback, and many other features that Apple just doesn't have in the Nano.
The fact is that the market has already decided the answer to this. People buy the least expensive software they can get away with.
That's because quality and security are properties of software that are difficult to evaluate for most buyers; people end up with worse software than they actually need. This is a standard example where markets fail to reach the overall optimal outcome.
It doesn't make economic sense to create some kind of liability for the authors of software; there is no single level of quality that everybody needs.
The best thing we can do to increase software quality is to hold the people responsible who can actually do something about it: the people who buy software.
If your Windows PC crashes and you lose data, that's your responsibility; you could have gotten something different.
If the bank's Microsoft-based database server has a serious security hole and someone breaks in and defrauds customers, then the bank should be held fully responsible for that; they shouldn't be able to shift responsibility to either Microsoft or the person who broke in. That will force institutions like banks to negotiate contracts with software vendors that ensure an appropriately high level of correctness. And there is no need to burden our courts with "hackers"--you won't be able to find and lock them all up, so locking up some of them is not a rational strategy for making computers secure.
In any case, if one wanted to, one could easily make legal distinctions betwen FOSS and Microsoft/Apple when it comes to liability. First, expert users generally have to accept a higher level of responsibility than non-experts. Arguably, FOSS users are, by definition, expert users. Also, for-pay software involves an actual sale, which can easily and sensibly be regulated differently from non-sale distribution when it comes to liability.
Wrong. Java Was Strongly Influenced by Objective-C
It doesn't matter who Naughton's muse was, Java's object model is close to C++, and very different from Objective-C.
Yeah. I think it will be worth looking at again after Glasgow comes out. Right now, it's aimed at a niche market and it still has the somewhat cumbersome architecture of the original Gimp.
Please forgive me if I'm wrong but don't most image editing functions work in float and then just clamp the results?
Historically, almost no image editing or processing was using floating point (floating point used to be quite slow). Today, floating point is somewhat more common. However, even if all the calculations are done in floating point, if you convert to 8 bit for intermediate results, you still get most of the artifacts and problems of integer processing.
In the end, if you want the benefits of >8 bits per channel, you need to store your images that way, both in memory and on disk. And while 32 bit floating point is overkill in terms of dynamic range (16 bits per channel is probably enough for almost everything), it's probably time to move directly to 32 bits because it means there are a lot of messy details you just don't have to think about anymore and that slow down development.
The primary reason for needing 16 bit and 32 bit per channel data is not for display but for editing and processing; with 8 bits per channel, there is very little room for adjustments and corrections. And you don't need a display with more than 8 bits per channel for editing 16 bit or 32 bit per channel images, or to see the artefacts resulting from working with 8 bit per channel images.
Most of the time, efficient code is the code that is easy to write without too many dangerous bugs, easy to debug, easy to deploy and easy and maintain. And Java is the right language when you use such definition.
I agree that writing good, straightforward code is what one should aim for, but you can do that in many languages (C/C++ being notable exceptions). The problem with Java is that straightforward code tends to be unnecessarily slow, and that is why Java deserves its reputation for being a "slow language". It has nothing to do with garbage collection, and everything with language misfeatures specific to Java.
I fully agree: Apple's decision to go with Object Pascal, and then a collection of assembly-language toolboxes had really bad consequences for the industry, consequences that we suffer from to this day.
I disagree, though, with your assessment of the relationships of the different languages; Java, unfortunately, is not the son of Objective-C, it is the son of Object Pascal and C++. Objective-C would have been the right language for the original Macintosh--close to the machine to allow Apple to meet their price targets, but dynamic enough to eventually turn into something decent. Instead, Appple led the industry on a 20 year detour into static object-oriented languages and, worse, "toolboxes", and is now returning to a dynamic language that is 20 years out of date.
Fortunately, C# and Java do address this problem. While the C# and Java languages themselves are cumbersome and static, their runtimes are sufficiently powerful to put decent dynamic languages on top of them and still interoperate with the unwashed masses of static object-oriented programmers.
Objective-C's object system and general philosophy is _very_ smalltalk-ish.
Yes, Objective-C has late binding and limited dynamic typing, but that's only a tiny part of what Smalltalk offered in 1980.
The sad fact is that it is Apple, more than any other company, that is responsible for the bloated toolkits and libraries that we see today: they set the pattern with the Lisa and the Macintosh toolboxes, and everybody else copied it, up to and including Java and C#. And while Objective-C happens to copy some of Smalltalk's nice object features, it is has grave deficiencies in areas like run-time safety, reflection, and resource management.
I had a Lisa, and Apple made the same mistakes with the Lisa as Xerox had made with the Star: it was too expensive, in particular for the limited hardware and completely incompatible software you got.
Claims that the Lisa represented significant technological innovation seem dubious to me. You need to compare the Lisa to the totality of R&D efforts around at the time, not just the Star. Xerox alone had Alto, Star, Smalltalk, and probably others. The GUI of the Lisa was an evolutionary change, and not always for the better; what was under the hood of the Lisa can charitably be described as pedestrian. It took Apple 20 years to catch up and finally adopt system software that even is in the same league as Smalltalk-80 (that's "80" as in "1980"; Smalltalk-80 is the language and platform that Objective-C and Cocoa are modeled on).
Lisa's main significance was to be a prototype for, and cannibalized for, Macintosh (and it served as the main development machine for Macintosh apps for a while), but I can't think of any significant new technology it introduced.
Garbage collection is generally more efficient, byte for byte allocated, than malloc.
The problem is that Java programmers and Java libraries tend to be written in such a way that they do a lot more memory allocation, just because it's so easy to do. The quality of Java code in general is not very impressive (and this include Sun's own libraries). And Java itself makes writing efficient code harder than it needs to be.
So, people can write highly efficient code in garbage collected languages, and even in Java. But Java programmers generally don't bother, and that's the reason why Java has such a bad reputation, and it deserves it.
That is wrong. Images with anywhere from 1bit to 64bit per channel are in use, with anywhere from 1 channel to hundreds of channels.
As it turns out, even many modern consumer cameras give you 12bit or 16bit per channel, and many modern displays can display that.
The biggest holdback right now is that common image formats like JPEG are still limited to 8bit per channel.
SVG is primarily a vector graphics format--kind of like a PNG or JPEG, only that you can scale it up without seeing pixels. Another way of looking at it is that it is roughly equivalent to Adobe Illustrator files. SVG can also be used for animation, like Flash, but that's not its main purpose in life, at least not in the short term. Right now, SVG is being used more and more for icons, user interface elements, diagrams, figures, and other static images.
Oh, I agree: 32bit is a must. It's a major deficiency that the Gimp doesn't have it, and it was a major deficiency when Photoshop didn't have it.
I don't think retrofitting the Gimp is the right approach, though. Writing 32bit imaging tools (and I have been doing that for a couple of decades) is very different from writing 8bit imaging tools.
A Leica M lacks what a Canon SureShot has out of the box; that doesn't make the SureShot a better or more professional tool camera. Ease of use and multitude of features are not the measure of how good a tool is for commercial use.
I think both the Gimp and Photoshop are poor photo editing applications for professional users because they have too many extraneous features and don't focus on addressing the essentials well.
In the case of Photoshop, its real problem is that, in addition to trying to be a photo editing application, it's a web design application, an application for creating computer art, and lots more. It's the typical feature bloat that successful Windows applications experience.
SIOX is machine vision; this kind of algorithm has been developed before, but I don't know about the relationship between SIOX and previous methods--maybe the Berlin guys improved on prior work, or maybe they just didn't know about it.
The issue isn't numbers, it's genetic and ecological diversity.
If they were introduced by humans, they should be eliminated from Australia, since they are likely going to make native species extinct.
Now, that Microsoft is tightening it down and including a virus scanner,
Including a virus scanner is not "tightening it down", it's treating a symptom. And it's treating a symptom that Microsoft copied again from someone else.
I'm somewhat sympathetic to Symantec: Microsoft really is doing what they have been doing with other applications before, driving a vendor out of business by bundling their own (often inferior software) with the OS.
If Microsoft wants to tighten down Windows, they need to fix it, not add a virus scanner.
Sadly, apparently it isn't. The content creators might argue that that kind of re-purchasing is already factored in into their "already thin" profit margins.