What I would really like to see is IBM using some of the weight it has to pressure hardware vendors into giving us more documentation. We have shown again and again that we don't need a lot of corporate support to produce drivers -- all we need is good documentation and IBM might be one of the 5 companies out there that might have the strength to make a difference with this.
So my question to you is: Do you in any way see the possibility of putting pressure on companies like nVidia or Promise to give us documentation on their hardware?
I Have taught three CS1 classes at the university I went to, two as an instructor (coteacher) and one as the "head" teacher.
My experience says that for CS1 you have to choose a language that completely hides away computer internals and focuses on syntax and semantics. Having to deal with hardware complexity is too much for the first class. Remember that a surprising amount of those taking the class have never ever used a texteditor before.
IMHO the best language for teaching CS1 is python. This is a very well designed language that makes you do stuff with very little hassle. The first CS1 class I taught was using python and it worked brilliantly.
The two others I did were using Java and this is somewhat harder. Take a look at a hello world:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
This is a disaster compared to the python
print "Hello World"
All those who are crying "any skilled programmer must know the internals of a computer -> force them to start with C or assembler" are wrong because this attempts to teach everything at once. For a CS1 you should be happy just teaching every basic construct of normal (imperative) programming languages.
I don't believe OO is a good idea for the first one either, because noone can truly appreciate OO before they have a course on OO analysis and design. So hold the OO to this course.
I went to a talk by a guy doing human--computer interfaces and he mentioned the paperclip and the other type of automatic help agents they used to supply.
He said one thing that really shows what the situation is with this: "Every time Microsoft Office is released, it is with a new help agent. This shows that not a single implementation they had actually made sense."
Now they kill the paperclip and for the next Office version they will kill the new one. Be sure of it.
I'm a bit surprised about this comment. It mentions that you can get an easy upgrade to a 2.4.something kernel by using a Red Hat or Mandrake beta release. How about mentioning that SuSE 7.1 is released with a 2.4.1? I should think this was even easier than using a bumpy beta release.
Can someone tell me why on earth I should buy a machine that will probably have the same fate as the Dreamcast I -- they kill it completely just before launching DCII which means support for this platform is a dead end and will not be supported in a couple of years.
Contrast this with Sony support on the Playstation. Just before they launch PS2, they refit the PS1 and start shipping this. Which is a clear sign to gamemakers that the PS1 is not dead even though PS2 is out.
Sega has shown their intentions and has made sure that I for one will go for another platform if I decide to buy a console.
On the side of the pages: "Sponsored by Business Web Services from Microsoft". So much for independent journalism.
Not very interesting for non-pda employment
on
GTK+ without X!
·
· Score: 5
There's one very common misunderstanding about the framebuffer: Speed. People seems to think that fb is fast because it talks directly to the hardware. It is not. In fact it is so painfully slow that anything resembling normal X resolutions and colordepths will be a horrible experience. Just try running an actual graphical application on fb, it will feel like java on a P166.
Where it could get interesting is if this would change for the better. There's no reason that the kernel drivers for fb couldn't be faster than they are right now. One problem would of course be that good drivers will have to be written for both X and the kernel where presently the kernel drivers are extremely basic. But when you start wanting 3D drivers, network transparency etc. you'll end up with something just as big as X anyway. (And having X or something of it's size in the kernel seems like a very bad idea.) The reasons for replacing X has nothing to do with speed or memory use.
When Qt embedded was GPL'ed and later when Konqueror embedded was released, there was a LOT of people talking about running KDE on fb. The speed problem alone makes this unusable for now, but even if this could be solved, KDE classes use quite a lot of X calls to perform as fast as possible. While it might or might not be as big a problem with Gnome, you will still have the situation where you now have two different underlying implementations which is much more awkward than just using X natively.
One place this will definately NOT benefit is LILO. The framebuffer is implemented by the kernel and LILO is used to load the kernel. This means that there is no way LILO can ever use the kernel's fb implementation. At least not unless someone finishes the kernel-in-bios hack but that's someway off in the future yet.
I'm surprised that noone has mentioned Slashdot's favourite security author, Bruce Schneier. He says the thing that IMHO closes this article: No matter how good a security technology is, it won't help you if the people don't behave in a secure manner.
This fits perfectly here. If people accepts using an unknown key, they're in for it. The problem is that it's a lot easier to do it than it is to get the key in a secure way.
Now Seidfrieds/Silvermans articles does have the simple point that the users need to worry about security themselves and don't expect technology to solve it for them. This can't be repeated too many times, since people still don't think computercrime will hit them in exactly the same way that people think no burglar will target their house and only buy security when it is too late.
So, try to read around the exagerated scoop style of seidfried, and heed the real advice here: Protect yourself, no technology will do it.
There's one more reason that this might not be a problem for Microsoft: When has Intel been able to ship a stable (in the serversense of the word) processor on deadline? On the other hand when has Microsoft been able to?
>Well, looks like the film industry is done with NT and who can blame them?
>Within six months, a significant percentage of 3D work will shift to the Linux platform.
What on earth makes you say that? Having a good linux server with apache is both better and cheaper than NT/IIS, but that has not convinced people to switch anyway.
Solaris has had good OpenGL solutions for years now, and the Unix world is not going to shift to Linux because the XFree team has a beta of version 4 out. (Yes, the XFree versions are to be treated as betas.)
>Why would you choose anything else for your render-farm?
Actually I would choose something else. If I was stuck with x86, I would probably go for FreeBSD. On SPARC I wouldn't even dream of running Linux - choose Solaris. On alpha's Linux would probably be the choice though. Remember that the cost of a renderfarm is so huge that the OS doesn't even have a pricetag. Pixar's renderfarm consists of 96 Sun machines with 14 UltraSPARC 2's in each for instance. Don't even think about running Linux on this.
>With the interactive apps becoming available, this will drive demand for real hardware OpenGL on Linux, which will benefit the casual linux user because games will run well.
In some cases yes. But the professional OpenGL cards accelerate completely different parts of the pipeline than gamecards. Running Quake on a FireGL 1 or a Wildcat is not good, but interactive modelling is a lot faster than the game cards.
>For someone like me, who is already doing all his 3D work in Linux with Blender and Corel PhotoPaint, this news comes as no surprise.
>It really is a better platform for 3D work.
Most definately not! The OpenGL drivers for SGI machines running IRIX, Sun boxes and even Windows are much faster and more reliable than the Linux ones. The only descent drivers for Linux are the nvidia ones, and they're not open source. (Matrox drivers are an exception here. The Windows OpenGL sucks so much it's hard to believe, where the oss Linux drivers are good.)
>After suffering through the frequent crashes and general wierdness of Windows, my apps run rock-stable on linux, perform better and i...
Wether or not your app is running more stable on Linux is a matter of programming it correctly. This has nothing to do with the unstability of Windows. As for performance, even the fastest OpenGL drivers for Linux are smoked completely by their Windows counterparts. Nvidia are very close (just a couple frames slower with Quake), and Matrox is the exception.
>... couldn't be happier that its cost me nothing (well, if you count a couple of years slaving away figuring all this stuff out 'nothing')
Exactly. Saying Linux is free means nothing for businesses who have to pay their sysadmins.
All in all, I generally disagree with you completely. That being said, I develop an OpenGL program on Linux and Solaris, and after all the trouble of setting it up on Linux, I have no problems here. And development on Unix is definately a lot nicer than on Windows. The Redmond guys make a shitty OS, but they make catastrophical API's.
Slashdot Mirror
What I would really like to see is IBM using some of the weight it has to pressure hardware vendors into giving us more documentation. We have shown again and again that we don't need a lot of corporate support to produce drivers -- all we need is good documentation and IBM might be one of the 5 companies out there that might have the strength to make a difference with this.
So my question to you is: Do you in any way see the possibility of putting pressure on companies like nVidia or Promise to give us documentation on their hardware?
I Have taught three CS1 classes at the university I went to, two as an instructor (coteacher) and one as the "head" teacher.
My experience says that for CS1 you have to choose a language that completely hides away computer internals and focuses on syntax and semantics. Having to deal with hardware complexity is too much for the first class. Remember that a surprising amount of those taking the class have never ever used a texteditor before.
IMHO the best language for teaching CS1 is python. This is a very well designed language that makes you do stuff with very little hassle. The first CS1 class I taught was using python and it worked brilliantly.
The two others I did were using Java and this is somewhat harder. Take a look at a hello world:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
This is a disaster compared to the python
print "Hello World"
All those who are crying "any skilled programmer must know the internals of a computer -> force them to start with C or assembler" are wrong because this attempts to teach everything at once. For a CS1 you should be happy just teaching every basic construct of normal (imperative) programming languages.
I don't believe OO is a good idea for the first one either, because noone can truly appreciate OO before they have a course on OO analysis and design. So hold the OO to this course.
I went to a talk by a guy doing human--computer interfaces and he mentioned the paperclip and the other type of automatic help agents they used to supply.
He said one thing that really shows what the situation is with this: "Every time Microsoft Office is released, it is with a new help agent. This shows that not a single implementation they had actually made sense."
Now they kill the paperclip and for the next Office version they will kill the new one. Be sure of it.
I'm a bit surprised about this comment. It mentions that you can get an easy upgrade to a 2.4.something kernel by using a Red Hat or Mandrake beta release. How about mentioning that SuSE 7.1 is released with a 2.4.1? I should think this was even easier than using a bumpy beta release.
Can someone tell me why on earth I should buy a machine that will probably have the same fate as the Dreamcast I -- they kill it completely just before launching DCII which means support for this platform is a dead end and will not be supported in a couple of years.
Contrast this with Sony support on the Playstation. Just before they launch PS2, they refit the PS1 and start shipping this. Which is a clear sign to gamemakers that the PS1 is not dead even though PS2 is out.
Sega has shown their intentions and has made sure that I for one will go for another platform if I decide to buy a console.
On the side of the pages: "Sponsored by Business Web Services from Microsoft". So much for independent journalism.
There's one very common misunderstanding about the framebuffer: Speed. People seems to think that fb is fast because it talks directly to the hardware. It is not. In fact it is so painfully slow that anything resembling normal X resolutions and colordepths will be a horrible experience. Just try running an actual graphical application on fb, it will feel like java on a P166.
Where it could get interesting is if this would change for the better. There's no reason that the kernel drivers for fb couldn't be faster than they are right now. One problem would of course be that good drivers will have to be written for both X and the kernel where presently the kernel drivers are extremely basic. But when you start wanting 3D drivers, network transparency etc. you'll end up with something just as big as X anyway. (And having X or something of it's size in the kernel seems like a very bad idea.) The reasons for replacing X has nothing to do with speed or memory use.
When Qt embedded was GPL'ed and later when Konqueror embedded was released, there was a LOT of people talking about running KDE on fb. The speed problem alone makes this unusable for now, but even if this could be solved, KDE classes use quite a lot of X calls to perform as fast as possible. While it might or might not be as big a problem with Gnome, you will still have the situation where you now have two different underlying implementations which is much more awkward than just using X natively.
One place this will definately NOT benefit is LILO. The framebuffer is implemented by the kernel and LILO is used to load the kernel. This means that there is no way LILO can ever use the kernel's fb implementation. At least not unless someone finishes the kernel-in-bios hack but that's someway off in the future yet.
I'm surprised that noone has mentioned Slashdot's favourite security author, Bruce Schneier. He says the thing that IMHO closes this article: No matter how good a security technology is, it won't help you if the people don't behave in a secure manner.
This fits perfectly here. If people accepts using an unknown key, they're in for it. The problem is that it's a lot easier to do it than it is to get the key in a secure way.
Now Seidfrieds/Silvermans articles does have the simple point that the users need to worry about security themselves and don't expect technology to solve it for them. This can't be repeated too many times, since people still don't think computercrime will hit them in exactly the same way that people think no burglar will target their house and only buy security when it is too late.
So, try to read around the exagerated scoop style of seidfried, and heed the real advice here: Protect yourself, no technology will do it.
There's one more reason that this might not be a problem for Microsoft: When has Intel been able to ship a stable (in the serversense of the word) processor on deadline? On the other hand when has Microsoft been able to?
>Well, looks like the film industry is done with NT and who can blame them?
>Within six months, a significant percentage of 3D work will shift to the Linux platform.
What on earth makes you say that? Having a good linux server with apache is both better and cheaper than NT/IIS, but that has not convinced people to switch anyway.
Solaris has had good OpenGL solutions for years now, and the Unix world is not going to shift to Linux because the XFree team has a beta of version 4 out. (Yes, the XFree versions are to be treated as betas.)
>Why would you choose anything else for your render-farm?
Actually I would choose something else. If I was stuck with x86, I would probably go for FreeBSD. On SPARC I wouldn't even dream of running Linux - choose Solaris. On alpha's Linux would probably be the choice though. Remember that the cost of a renderfarm is so huge that the OS doesn't even have a pricetag. Pixar's renderfarm consists of 96 Sun machines with 14 UltraSPARC 2's in each for instance. Don't even think about running Linux on this.
>With the interactive apps becoming available, this will drive demand for real hardware OpenGL on Linux, which will benefit the casual linux user because games will run well.
In some cases yes. But the professional OpenGL cards accelerate completely different parts of the pipeline than gamecards. Running Quake on a FireGL 1 or a Wildcat is not good, but interactive modelling is a lot faster than the game cards.
>For someone like me, who is already doing all his 3D work in Linux with Blender and Corel PhotoPaint, this news comes as no surprise.
>It really is a better platform for 3D work.
Most definately not! The OpenGL drivers for SGI machines running IRIX, Sun boxes and even Windows are much faster and more reliable than the Linux ones. The only descent drivers for Linux are the nvidia ones, and they're not open source. (Matrox drivers are an exception here. The Windows OpenGL sucks so much it's hard to believe, where the oss Linux drivers are good.)
>After suffering through the frequent crashes and general wierdness of Windows, my apps run rock-stable on linux, perform better and i...
Wether or not your app is running more stable on Linux is a matter of programming it correctly. This has nothing to do with the unstability of Windows. As for performance, even the fastest OpenGL drivers for Linux are smoked completely by their Windows counterparts. Nvidia are very close (just a couple frames slower with Quake), and Matrox is the exception.
>... couldn't be happier that its cost me nothing (well, if you count a couple of years slaving away figuring all this stuff out 'nothing')
Exactly. Saying Linux is free means nothing for businesses who have to pay their sysadmins.
All in all, I generally disagree with you completely. That being said, I develop an OpenGL program on Linux and Solaris, and after all the trouble of setting it up on Linux, I have no problems here. And development on Unix is definately a lot nicer than on Windows. The Redmond guys make a shitty OS, but they make catastrophical API's.