Macintosh users (especially newer iMac users) are not going to put up with complex/user intensive installers. I know that Apple is using part of the Next-ish.App directory idea as well as/usr,/lib,/bin, etc directories, but they are also doing their best to hide this from the end-user. Does anyone know how Apple is handling installation issues in Mac OSX? Could the same approach be used to install/pkg software for Linux?
One of the things that the article emphasized, is that modern CPUs (like compilers, etc) split the work into front-ends and back-ends. Perhaps the Transmeta folks just have a CPU design in which the front-end can be switched around for different ISA's? In that case, it's possible that the Transmeta CPU will be Really Huge (power, transistor count, size, etc), but flexible (like a previous poster's musings about 'bypassing' the x86 stuff in the K7).
Have you had or will you be having discussions with other SW publishers (both OS and proprietary) about ways to integrate their products into the KDE environment? That is, if, say, Bioware wanted to develop a Linux version of a game would they be able to get assistance from your team? Yes, I know that they could just read the source code, but one of the things that keeps Mac (and, to some extent) Win programs consistent is that the UI designers can discuss their design decisions with other vendors and make it easier for them to port their applications. Along those lines, how evangalistic are you at presenting the KDE environement to folks/companies who may be interested in Linux, but just not sure where they fit in or how to get their apps up and running? Do you even think that this should be part of your role?
Actually, the NEC/Hitachi/whatever machines are NOT using standard processors. They, like the Cray J90/C90/T90/SV1 are using vector processors. These processors are highly specialized and much more expensive than regular processors (G4 notwithstanding;-). Our humble Cray J90's CPUs, for example, can process 64 array elements (each element is an 8byte word) with each vector command making it very fast for matrix-style calculations. As far as I know, the LINPAK benchmarks vectorize quite nicely, thus, giving vector machines an advantage. Unfortunately, since SGI sucked all of the life out of Cray Research, all of the recent developments in vector hardware have been from Japanese manufacturers, thus leaving many US gov't agencies without big vector iron. According to our local Cray guy, this will change with the Cray SV2, but that machine is still a year or so out and may be too little too late. Incidentally, our T3E (#56 on the list) does have off-the-shelf Alpha processors (272 of 'em).
My, my, my... What a tempest in a teapot (er; coffee mug, that is;-) we have here. Let's not forget that they sampled only 150 buisness developers for their survey. In my field, if you sampled 150 developers the #1 language would be: FORTRAN. Yup. FORTRAN. No other language has quite the support or the libraries to do full-up parallel and/or scientific programming on 'big iron' (Cray T3E) systems. As many other poster's have pointed out, VB is a good RAD tool (which, coincidentally, is probably what it was designed for). However, it is really only applicable when you are building front-ends for Windows stuff. Java is a great language to program in (read: fun) but, like C/C++ is kindof a big hammer when it comes to solving small, UI problems. Similarly, Perl is The World's Most Useful Language for textual applications, but not so good for graphical stuff. I guess my main point is that 35% of 150 people does not constitute a trend. These folks are a niche, just like supercomputing folks are in a different niche.
Computer Science (and, by extension, Software Engineering) is finally beginning to 'gel' as an engineering discipline. That is, we finally have a large body of practices, tools and examples (both good and bad) that can help to guide future projects. This is the very same process that other engineering disciplines (such as CE, EE, ME) went through on their way from an art to a science. Unfortunately, the field of SE has only been around a very small fraction of the time that the other disciplines have. Thus, the growing pains we are experiencing as our field matures is much greater than that expereinced by, say, ME (which has had hundereds of years to sort itself out). Certification and/or licensing is just the next step in the life of our field. It simply validates and regulates those things that we already know how to do. It does not prevent innovation in new areas of SE and/or programming. Just as there is always room for 'tinkering' and experimentation in electronics, there will always be room for experimentation in programming. Whether we like it or not, our efforts can have an impact on thousands (if not millions) of lives every day. It is our responsibility to ensure that we have done our best in producing software and systems. In essence: it's time to grow up.
Slashdot Mirror
Macintosh users (especially newer iMac users) are not going to put up with complex/user intensive installers. I know that Apple is using part of the Next-ish .App directory idea as well as /usr, /lib, /bin, etc directories, but they are also doing their best to hide this from the end-user. Does anyone know how Apple is handling installation issues in Mac OSX? Could the same approach be used to install/pkg software for Linux?
One of the things that the article emphasized, is that modern CPUs (like compilers, etc) split the work into front-ends and back-ends. Perhaps the Transmeta folks just have a CPU design in which the front-end can be switched around for different ISA's? In that case, it's possible that the Transmeta CPU will be Really Huge (power, transistor count, size, etc), but flexible (like a previous poster's musings about 'bypassing' the x86 stuff in the K7).
Have you had or will you be having discussions with other SW publishers (both OS and proprietary) about ways to integrate their products into the KDE environment? That is, if, say, Bioware wanted to develop a Linux version of a game would they be able to get assistance from your team?
Yes, I know that they could just read the source code, but one of the things that keeps Mac (and, to some extent) Win programs consistent is that the UI designers can discuss their design decisions with other vendors and make it easier for them to port their applications.
Along those lines, how evangalistic are you at presenting the KDE environement to folks/companies who may be interested in Linux, but just not sure where they fit in or how to get their apps up and running? Do you even think that this should be part of your role?
Actually, the NEC/Hitachi/whatever machines are NOT using standard processors. They, like the Cray J90/C90/T90/SV1 are using vector processors. These processors are highly specialized and much more expensive than regular processors (G4 notwithstanding ;-). Our humble Cray J90's CPUs, for example, can process 64 array elements (each element is an 8byte word) with each vector command making it very fast for matrix-style calculations. As far as I know, the LINPAK benchmarks vectorize quite nicely, thus, giving vector machines an advantage.
Unfortunately, since SGI sucked all of the life out of Cray Research, all of the recent developments in vector hardware have been from Japanese manufacturers, thus leaving many US gov't agencies without big vector iron. According to our local Cray guy, this will change with the Cray SV2, but that machine is still a year or so out and may be too little too late.
Incidentally, our T3E (#56 on the list) does have off-the-shelf Alpha processors (272 of 'em).
My, my, my... What a tempest in a teapot (er; coffee mug, that is ;-) we have here. Let's not forget that they sampled only 150 buisness developers for their survey. In my field, if you sampled 150 developers the #1 language would be: FORTRAN. Yup. FORTRAN. No other language has quite the support or the libraries to do full-up parallel and/or scientific programming on 'big iron' (Cray T3E) systems. As many other poster's have pointed out, VB is a good RAD tool (which, coincidentally, is probably what it was designed for). However, it is really only applicable when you are building front-ends for Windows stuff. Java is a great language to program in (read: fun) but, like C/C++ is kindof a big hammer when it comes to solving small, UI problems. Similarly, Perl is The World's Most Useful Language for textual applications, but not so good for graphical stuff. I guess my main point is that 35% of 150 people does not constitute a trend. These folks are a niche, just like supercomputing folks are in a different niche.
Computer Science (and, by extension, Software Engineering) is finally beginning to 'gel' as an engineering discipline. That is, we finally have a large body of practices, tools and examples (both good and bad) that can help to guide future projects. This is the very same process that other engineering disciplines (such as CE, EE, ME) went through on their way from an art to a science. Unfortunately, the field of SE has only been around a very small fraction of the time that the other disciplines have. Thus, the growing pains we are experiencing as our field matures is much greater than that expereinced by, say, ME (which has had hundereds of years to sort itself out).
Certification and/or licensing is just the next step in the life of our field. It simply validates and regulates those things that we already know how to do. It does not prevent innovation in new areas of SE and/or programming. Just as there is always room for 'tinkering' and experimentation in electronics, there will always be room for experimentation in programming.
Whether we like it or not, our efforts can have an impact on thousands (if not millions) of lives every day. It is our responsibility to ensure that we have done our best in producing software and systems. In essence: it's time to grow up.