Fýrst, it's been a long time since I posted this. The QT license was not revised (it's now DFSG compliant I guess) back then. And I say that the license does matter. GUI stuff is very basic and I'd like it the "free" way.
Second, I know it's been quite biased ýn favor of GTK, but I couldn't help. By the way, although GTK seems better designed, the implementation has a very steep learning curve, someone said it's a resource hog.
After I posted the question, it didn't appear for quite a long time, so I had to revise it. However, the rev. version is not here. Sorry. I had removed the "license is boring" part. And added that interpreted languages should be considered.
Okay, I wrote a pretty huge DICOM3.0 implementation for the university and I was thinking what license to go. As I thought over and over, I realized that medical software simply costs too much and an open source model could keep software solutions with a very limited budget.
In my case, this might mean that many hospitals could be provided with low-cost and highly-available medical imaging workstations. Linux boxes with internet connection would be the way to go.
So I say GPL it. It will work very good at least for the non-ultra-critical kind of medical software. And who says that free software can't do it. I think my lib surpasses most of the commercial DICOM implementations, and it's gonna be truly free.
By the term technical, I suppose I have made it clear that I don't refer to tasks which require programming knowledge. Therefore, I include in the technical professions linguistics, graphic design and ergonomics among others. It is likely that we'd agree on the variety of their social aspects.
I'd like to restate that those are technical but definitely mandatory skills for UI design.
Another point to which I'd oppose is the claim that Windows has been successful in capturing the workflow of an everyday user. To the contrary, Windows has designated pseudo standards and have enforced people to comply with them.
You know, when you talk about NAF, I expect something that, uh lets you abstract the whole network issue and have some language bindings. Way to go distributed.
But I feel it has too much emphasis on Windoze stuff. You know, I never liked Winsock2.0.;) And I don't think I'll be CORBA-ing in windows..
You know, when you talk about NAF, I expect something that, uh lets you abstract the whole network issue and have some language bindings. Way to go distributed.
But I feel it has too much emphasis on Windoze stuff. You know, I never like Winsock2.0.;) And I don't I'll be CORBA-ing in windows..
The author's belief that users should develop the user interfaces rather than the programmers is a fallible and misleading suggestion. I haven't encountered a user developed UI that could be credited as the state-of-the-art human computer interaction. Indeed, there is a trend in disabling customization features for the commmon user because they can create distracting environments.
UI design is a very difficult and technical problem which requires profession in computer sciences, linguistics, human form factors (ergonomics), graphic design, etc. While it is true that the UI design obligates a team comprised not only by programmers, it by no means implies that users can be UI designers.
I suspect that a causal user can only be involved as the subject of experiments or beta-tests. Nevertheless, the member of a UI design team would need to be a very good user himself, for him to understand issues closely. Also, I don't think it would be harsh to state that a good programmer has to be a good user.
Also, the definitions and examples in the article are insufficient. I see little light of history and UI design academia there. Tasteless.
On the other hand, it is true that Linux developers have not been very successful. Surely, GNOME and KDE sometimes look like rip-offs and E is entirely a desperate matter... But this doesn't mean ppl are not good programmers, it's simply that UI design is sophisticated task and it must not be taken too lightly..
I really don't know, I've had a tough time studying all those Chomsky-ish phrase structure grammars and non Chomsky-ish categorial grammars...
Anyway, deriving semantics from phonological information (speech -> phonemes -> morphemes -> lexemes -> semantics) and then converting back into another language never seemed to me as a trivial task. The plethora of phenomena in language are just intimidating.
I do understand that the evolution of standards can be painstaking. (I wrote an almost complete DICOM implementation) The compromises don't always lead to the most elegant or desirable solution.
However, a mapping as you describe would be perfect. Though I won't be holding my breath. Till then, the wisest thing to do is keeping your book as the CORBA-with-C++ guide.
It seems to me that the bottom-up development does not always scale well. I believe that there have been examples of that, such as the imperfections in Linux kernel, the unstability of GNOME or like. I don't wish to accuse or undermine any work contributed to the community. However, I'd like to point out to the prominence of "design" which is somewhat ignored at times.
Now, it's clear that there are no absolute rules for managing or directing or x-ing a free software project. Besides, we'd rather not have any strict rules -- all the excitement would end. In particular, I don't see why there should be a single manager or a management team comprised of, say, 3 ppl. It seems that some ego problems are sure to break out if you insist on duplicating the corporate management hierarchy. [Don't flame me at this point;) ]
In addition to this, I don't see any reason why the proper credit for good work would not be granted to the participant. Taking credit is part of the motivation.
A suggestion may form around the following lines: There should be little distinction between the contributors. The design, implementation, testing, documentation and other leading activities should all be equally publicized and freed. It occurs to me that it is not altogether trivial to achieve this, especially for the larger tasks [thinking about the HURD kernel, GNU ppl couldn't really finish that]
It's all about the welfare of the people who use the software, and of the people who develop it. There should be a mid-way between a top-down and bottom-up development. The MS coding machine doesn't produce quality. Sometimes patches aren't good enough. But if we did design in the "open", "free", whatever way I think it would be a bit different./. is sometimes very good at developing "ideas", perhaps the same process may recur at the design time. You aim some features, some versions. You decide on the implementation environment, tools, algorithms, languages... You define modules, do analysis (excuse me, do you have an OOA?), have your interfaces sorted out. The usual design stuff, and the best part is: you do it all together. And still, people can get credit for what they've done.
Transmeta, or another company which can offer technologies as exciting as rumored would make good partners with Amiga. However, using the Linux kernel gives rise to the practical issue of running Linux applications on the new Amiga hardware/software.
In my opinion, the Amiga "layer" would be dependent on a common set of GNU programs (tools) together with the already mentioned Linux kernel. At this stage, I would like to remind that Linus is very interested in "scaling down", and Collas promises a "clean kernel configuration". I would at least expect a nice bash shell that alignes with the expectations of a ordinary Linux user.
Now, in order to ensure compatibility with myriad of Linux applications you have to set some standards. I think that Debian's way of packaging, testing, porting, and permitting customized distributions is very suitable for the Amiga. In this manner, the Amiga can make a distribution that supplies a lot of Linux programs as an option. I believe that the option would be attractive if the Amiga develops X11 compatibility and allows other stuff (so you can have your usual internet stuff,etc. if you want) to be installed properly on the desktop computer [tagged with the staggering "multimedia convergence" definition]. Of course, other targeted products should also maintain the same Amiga software "layer". Then we'd have very *NIX capable multimedia computers and very fancy info appliances based on the same technology. That would make a great bet.
Please comment on how appropriate Debian is for the Amiga.
PS: Note that the strengths/weaknesses of Debian at both technology and policy are considerable.
I think that's all right, it's okay to go with a known distribution, customize it, and distribute it. I think it would be very nice, for instance, to go with Debian. I see little problems with X and libs also since shared libraries get loaded only when needed.;)
Since Amiga will be featuring a lot of multimedia, I suppose that they'll be able to support an X11R6 API. I don't know if they will base their work on XFree86, but they don't have to. Also, we don't know if they'll be using Mesa. I think it would be nice if Amiga contributed to PI's efforts.
On the other hand, it isn't stupid to assume that new Amiga software will be friendly with the conventions and leading applications on Linux. Supporting a technically sound distribution is one way to do this.
It might well be a software option to install Linux applications (and of course all the stuff that they depend on). I'd envision an Amiga system that's dependent on the Linux kernel, the common GNU tools but not on XFree86 or GNOME.
[Hmm, I gotta post this as a kind proposal for the kind of distribution Amiga should have]
All coders know about the fancies of how to reverse-engineer code, crack copy-protection, fix bugs. Back in the Amiga days, I had the pleasure of using very fine reverse-engineering programs so I would clip portions of demos / games and stuff and turn them into relative assembly code.
Indeed, it always seemed wierd when the program was written in C. However, C is a low level language, and a good programmer can figure it out. As of '99 things have changed a bit. First of all, the complexity of the programs have increased both in size and functionality [ so we can talk about kolmogorov complexity;) ]
Now imagine a hardware whose specs aren't available. In the case of RIVA TNT, I was really pissed off and almost going to work on cracking the windows GL drivers open and writing Mesa stuff for it before the free stuff came in. Guess what! I never started it, let's say it didn't turn me on. The real reason, of course, is that it would be almost an impossible task. Although one could argue that the modularity in the hardware design would lead to modularity in the driver code, thus comprehensible assembly stuff. I wouldn't be so jumpy about it, it's still an undecidable problem folks!
Sincerely, I don't think I could accomplish that without knowing card's specs. I recall that it was quite difficult to find out Amiga AGA's specs by disassembling the AmigaOS3.0 ROM. And that was just 2d.
I think that was pretty well suited for a demo OS, it had interrupt manager, file system, exe loader, small fast sound gfx libs... kinda blurry but it was cool 68k assembly. Yay for Chaos!!
I suppose that the following points hold even if the mail is a hoax, though it seems to be real.
Among the Amigans addressed, I belive that there will be others with similar suspicions to mine. The Amiga has once been revolutionary, and basically that's why we love it so much. It has made many attempts at a come-back, and haven't reached a desired position. Now Mr. Collas promises that the next generation Amigas will be as revolutionary as their first ancestors.
However, I am skeptical whether making some desktop machines + handheld devices which run Linux and Java is sufficiently revolutionary. In my opinion and thus from a developer's viewpoint, it's difficult to see what the Amiga Operating Environment can accomplish that a plain Linux distribution cannot.
At any rate, I would be definitely pleased to see Amiga to revive, and in good shape. I mean, not like your casual mummy. I will have to attain both the goodies (standards, swift desktop..) and the fancies (the rev. part as we hear it). I think that Amiga has the chance to make it, and free software/open source/whatever-you-call-it community will certainly benefit from it by some contributions from the Amiga (at least some kernel configs are on the way as Collas states)
I don't get it! QNX kernel seemed to rule, and Photon UI is really usable. Hey, it's great that Amiga Inc. are on the free software bandwagon. I do hope to see their distros, and perhaps a really cool desktop environment. Sorry E/GNOME folks but I still can't use the desktop on a regular basis. As an ace Amigan I'm pleased with whatever happens with Amiga. What can I do?
why don't you check the Amiga web site, the new gen. Amigas are based on QNX, that's what the whole story is about. And guess right, the new amiga is probably going to work on a variety of hardware. and QNX is NOT a dead-end OS. Linux sucks in terms of programming skills, flame me if you will. but QNX is a superior OS.
You know, Linux is not the only POSIX OS out there! QNX bears modularity, scalability, expandililty, reliability at its best. Get to know QNX before you flame it.
The second "sequel" to 2001: A Space Odyssy features landing on the Halley comet. Guessed right, the next visit is on 2061. Actually, it's one of the best in the series, so go get it if you still haven't read.
You know, according to the "hacker" hype, we have to deal with sci-fi extensively. No problem with me though, I just love sci-fi.
Slashdot Mirror
Fýrst, it's been a long time since I posted this. The QT license was not revised (it's now DFSG compliant I guess) back then. And I say that the license does matter. GUI stuff is very basic and I'd like it the "free" way.
Second, I know it's been quite biased ýn favor of GTK, but I couldn't help. By the way, although GTK seems better designed, the implementation has a very steep learning curve, someone said it's a resource hog.
After I posted the question, it didn't appear for quite a long time, so I had to revise it. However, the rev. version is not here. Sorry. I had removed the "license is boring" part. And added that interpreted languages should be considered.
Okay, I wrote a pretty huge DICOM3.0 implementation for the university and I was thinking what license to go. As I thought over and over, I realized that medical software simply costs too much and an open source model could keep software solutions with a very limited budget.
In my case, this might mean that many hospitals could be provided with low-cost and highly-available medical imaging workstations. Linux boxes with internet connection would be the way to go.
So I say GPL it. It will work very good at least for the non-ultra-critical kind of medical software. And who says that free software can't do it. I think my lib surpasses most of the commercial DICOM implementations, and it's gonna be truly free.
Great. Without the Debian distro the Amiga ball would wear that red hat. which doesn't look good.
By the term technical, I suppose I have made it clear that I don't refer to tasks which require programming knowledge. Therefore, I include in the technical professions linguistics, graphic design and ergonomics among others. It is likely that we'd agree on the variety of their social aspects.
I'd like to restate that those are technical but definitely mandatory skills for UI design.
Another point to which I'd oppose is the claim that Windows has been successful in capturing the workflow of an everyday user. To the contrary, Windows has designated pseudo standards and have enforced people to comply with them.
You know, when you talk about NAF, I expect something that, uh lets you abstract the whole network issue and have some language bindings. Way to go distributed.
;) And I don't think I'll be CORBA-ing in windows..
But I feel it has too much emphasis on Windoze stuff. You know, I never liked Winsock2.0.
You know, when you talk about NAF, I expect something that, uh lets you abstract the whole network issue and have some language bindings. Way to go distributed.
;) And I don't I'll be CORBA-ing in windows..
But I feel it has too much emphasis on Windoze stuff. You know, I never like Winsock2.0.
The author's belief that users should develop the user interfaces rather than the programmers is a fallible and misleading suggestion. I haven't encountered a user developed UI that could be credited as the state-of-the-art human computer interaction. Indeed, there is a trend in disabling customization features for the commmon user because they can create distracting environments.
UI design is a very difficult and technical problem which requires profession in computer sciences, linguistics, human form factors (ergonomics), graphic design, etc. While it is true that the UI design obligates a team comprised not only by programmers, it by no means implies that users can be UI designers.
I suspect that a causal user can only be involved as the subject of experiments or beta-tests. Nevertheless, the member of a UI design team would need to be a very good user himself, for him to understand issues closely. Also, I don't think it would be harsh to state that a good programmer has to be a good user.
Also, the definitions and examples in the article are insufficient. I see little light of history and UI design academia there. Tasteless.
On the other hand, it is true that Linux developers have not been very successful. Surely, GNOME and KDE sometimes look like rip-offs and E is entirely a desperate matter... But this doesn't mean ppl are not good programmers, it's simply that UI design is sophisticated task and it must not be taken too lightly..
I really don't know, I've had a tough time studying all those Chomsky-ish phrase structure grammars and non Chomsky-ish categorial grammars...
;)
Anyway, deriving semantics from phonological information (speech -> phonemes -> morphemes -> lexemes -> semantics) and then converting back into another language never seemed to me as a trivial task.
The plethora of phenomena in language are just intimidating.
I still doubt it's an AI-complete problem
I do understand that the evolution of standards can be painstaking. (I wrote an almost complete DICOM implementation) The compromises don't always lead to the most elegant or desirable solution.
However, a mapping as you describe would be perfect. Though I won't be holding my breath. Till then, the wisest thing to do is keeping your book as the CORBA-with-C++ guide.
yes, yes, but you know COBRA implies male genitals as well... ;)
It seems to me that the bottom-up development does not always scale well. I believe that there have been examples of that, such as the imperfections in Linux kernel, the unstability of GNOME or like. I don't wish to accuse or undermine any work contributed to the community. However, I'd like to point out to the prominence of "design" which is somewhat ignored at times.
;) ]
/. is sometimes very good at developing "ideas", perhaps the same process may recur at the design time. You aim some features, some versions. You decide on the implementation environment, tools, algorithms, languages... You define modules, do analysis (excuse me, do you have an OOA?), have your interfaces sorted out. The usual design stuff, and the best part is: you do it all together. And still, people can get credit for what they've done.
Now, it's clear that there are no absolute rules for managing or directing or x-ing a free software project. Besides, we'd rather not have any strict rules -- all the excitement would end. In particular, I don't see why there should be a single manager or a management team comprised of, say, 3 ppl. It seems that some ego problems are sure to break out if you insist on duplicating the corporate management hierarchy. [Don't flame me at this point
In addition to this, I don't see any reason why the proper credit for good work would not be granted to the participant. Taking credit is part of the motivation.
A suggestion may form around the following lines: There should be little distinction between the contributors. The design, implementation, testing, documentation and other leading activities should all be equally publicized and freed. It occurs to me that it is not altogether trivial to achieve this, especially for the larger tasks [thinking about the HURD kernel, GNU ppl couldn't really finish that]
It's all about the welfare of the people who use the software, and of the people who develop it. There should be a mid-way between a top-down and bottom-up development. The MS coding machine doesn't produce quality. Sometimes patches aren't good enough. But if we did design in the "open", "free", whatever way I think it would be a bit different.
What do you think?
What do you think?
Transmeta, or another company which can offer technologies as exciting as rumored would make good partners with Amiga. However, using the Linux kernel gives rise to the practical issue of running Linux applications on the new Amiga hardware/software.
In my opinion, the Amiga "layer" would be dependent on a common set of GNU programs (tools) together with the already mentioned Linux kernel. At this stage, I would like to remind that Linus is very interested in "scaling down", and Collas promises a "clean kernel configuration". I would at least expect a nice bash shell that alignes with the expectations of a ordinary Linux user.
Now, in order to ensure compatibility with myriad of Linux applications you have to set some standards. I think that Debian's way of packaging, testing, porting, and permitting customized distributions is very suitable for the Amiga. In this manner, the Amiga can make a distribution that supplies a lot of Linux programs as an option. I believe that the option would be attractive if the Amiga develops X11 compatibility and allows other stuff (so you can have your usual internet stuff,etc. if you want) to be installed properly on the desktop computer [tagged with the staggering "multimedia convergence" definition]. Of course, other targeted products should also maintain the same Amiga software "layer". Then we'd have very *NIX capable multimedia computers and very fancy info appliances based on the same technology. That would make a great bet.
Please comment on how appropriate Debian is for the Amiga.
PS: Note that the strengths/weaknesses of Debian at both technology and policy are considerable.
I think that's all right, it's okay to go with a known distribution, customize it, and distribute it. I think it would be very nice, for instance, to go with Debian. I see little problems with X and libs also since shared libraries get loaded only when needed. ;)
Since Amiga will be featuring a lot of multimedia, I suppose that they'll be able to support an X11R6 API. I don't know if they will base their work on XFree86, but they don't have to. Also, we don't know if they'll be using Mesa. I think it would be nice if Amiga contributed to PI's efforts.
On the other hand, it isn't stupid to assume that new Amiga software will be friendly with the conventions and leading applications on Linux. Supporting a technically sound distribution is one way to do this.
It might well be a software option to install Linux applications (and of course all the stuff that they depend on). I'd envision an Amiga system that's dependent on the Linux kernel, the common GNU tools but not on XFree86 or GNOME.
[Hmm, I gotta post this as a kind proposal for the kind of distribution Amiga should have]
Enuff to degrade AmigaOS to a toy. You know it existed and worked very well for (almost) a decade before Linux.
Furthermore, I don't think Linux has the kind of flexibility AmigaOS has.
All coders know about the fancies of how to reverse-engineer code, crack copy-protection, fix bugs. Back in the Amiga days, I had the pleasure of using very fine reverse-engineering programs so I would clip portions of demos / games and stuff and turn them into relative assembly code.
;) ]
Indeed, it always seemed wierd when the program was written in C. However, C is a low level language, and a good programmer can figure it out. As of '99 things have changed a bit. First of all, the complexity of the programs have increased both in size and functionality [ so we can talk about kolmogorov complexity
Now imagine a hardware whose specs aren't available. In the case of RIVA TNT, I was really pissed off and almost going to work on cracking the windows GL drivers open and writing Mesa stuff for it before the free stuff came in. Guess what! I never started it, let's say it didn't turn me on. The real reason, of course, is that it would be almost an impossible task. Although one could argue that the modularity in the hardware design would lead to modularity in the driver code, thus comprehensible assembly stuff. I wouldn't be so jumpy about it, it's still an undecidable problem folks!
Sincerely, I don't think I could accomplish that without knowing card's specs. I recall that it was quite difficult to find out Amiga AGA's specs by disassembling the AmigaOS3.0 ROM. And that was just 2d.
I think that was pretty well suited for a demo OS, it had interrupt manager, file system, exe loader, small fast sound gfx libs... kinda blurry but it was cool 68k assembly. Yay for Chaos!!
Looking forward to the technology brief.
man, I have some grammar errors. forgive me :)
I suppose that the following points hold even if the mail is a hoax, though it seems to be real.
Among the Amigans addressed, I belive that there will be others with similar suspicions to mine. The Amiga has once been revolutionary, and basically that's why we love it so much. It has made many attempts at a come-back, and haven't reached a desired position. Now Mr. Collas promises that the next generation Amigas will be as revolutionary as their first ancestors.
However, I am skeptical whether making some desktop machines + handheld devices which run Linux and Java is sufficiently revolutionary. In my opinion and thus from a developer's viewpoint, it's difficult to see what the Amiga Operating Environment can accomplish that a plain Linux distribution cannot.
At any rate, I would be definitely pleased to see Amiga to revive, and in good shape. I mean, not like your casual mummy. I will have to attain both the goodies (standards, swift desktop..) and the fancies (the rev. part as we hear it). I think that Amiga has the chance to make it, and free software/open source/whatever-you-call-it community will certainly benefit from it by some contributions from the Amiga (at least some kernel configs are on the way as Collas states)
I don't get it! QNX kernel seemed to rule, and Photon UI is really usable. Hey, it's great that Amiga Inc. are on the free software bandwagon. I do hope to see their distros, and perhaps a really cool desktop environment. Sorry E/GNOME folks but I still can't use the desktop on a regular basis. As an ace Amigan I'm pleased with whatever happens with Amiga. What can I do?
okay, linux is chosen by Amiga. Instead of QNX. Fokk me.
why don't you check the Amiga web site, the new gen. Amigas are based on QNX, that's what the whole story is about. And guess right, the new amiga is probably going to work on a variety of hardware. and QNX is NOT a dead-end OS. Linux sucks in terms of programming skills, flame me if you will. but QNX is a superior OS.
You know, Linux is not the only POSIX OS out there! QNX bears modularity, scalability, expandililty, reliability at its best. Get to know QNX before you flame it.
The second "sequel" to 2001: A Space Odyssy features landing on the Halley comet. Guessed right, the next visit is on 2061. Actually, it's one of the best in the series, so go get it if you still haven't read.
You know, according to the "hacker" hype, we have to deal with sci-fi extensively. No problem with me though, I just love sci-fi.