It is as simple as that. You can be very quirky as long as you deliver good work. This guy did not get fired because he was quirky, but because he was unable to produce a working program.
If he was such a guru he would have delivered a brilliant, modular, working program, and the people would have coped with his smell. But he did not, and so they rightfully fired him.
A fine example for this is John Carmack. The guy is so quirky that he builds hydrogen peroxide powered rocketships(!) in his pastime. It is quite possible that he will blow himself up one day. But until that day he writes damn fine code, and so every game company would love to hire him.
Lyx is a real killer application for scientific computing. Everyone who does Math, Engineering or something similar will be much more productive in Lyx than in Word or any other text processor.
It's a shame Lyx still uses this *ugly* xforms library. But that is about to change. There is a gui-independent version in the works, which will work with Qt or GTK, so most linux users should be happy!
I have an OS (SuSE Linux 7.3) that does absolutely everything I want. It is easy to install, and it does not come with any legal crap. I can use it to develop applications, and even my girlfriend and my mother can use it to browse the net, write E-Mail and write simple letters. That is all they want from a computer.
And now I am supposed to install WinXP and put up with all that crap from microsoft just because Linux lost the "war for the desktop"? We are not even fighting a stupid war.
And I don't care what this guy says. Linux with KDE and StarOffice is good enough for maybe 90% of all enterprise computer users.
That is not true. Virtual Machines do not always result in lower performance. And the benefits of a platform-independent binary format would be *huge*. Imagine having the same binary for KDE/BSD, KDE/Linux and KDE/Solaris.
Ordinary people do not want to compile source code. They do not want to know that they have to use --prefix=/usr with debian and --prefix=/opt with suse. They want to remove applications by deleting a directory. All this is trivial with a decent high-level object format, and almost impossible with C++.
C++ is not the best language to write large desktop environments. Objective C is much better, and Java or C# would be heaven!
There is lots of software that would benefit from lower latency. Human perception is not as slow as you think. Just play some mp3's in XMMS and then change the volume. It is really annoying that there is a lag until the volume really changes.
The reason for the lag is that there is a quite large buffer for the audio output. And the reason for this buffer is that sometimes the latency of the linux kernel gets really bad, and you do not want interrupted music when doing disk I/O.
I would love to have a high latency patch available, even if the peak performance would be reduced by, say, 5%. This is a desktop machine, and it is idle most of the time anyway.
I know that there is a huge amount of confusion about the.NET architecture. Microsoft basically labels everything new they produce.NET, and they themselves never made it entirely clear what the core aspect of.NET is.
But hidden deep in a cloud of marketing buzzwords there is a new and quite interesting development technology. The most important use of.NET will be as a replacement for the old win32 API. Of course it also defines data interchange and storage formats, so it can also be used for data exchange between different (windows) machines.
But basically,.NET is win32 TNG.
If you want to know what parts of the.NET architecture are really interesting technologies and not just buzzwords, take a look at
I think these kernel scheduler entities are a very nifty feature. As far as I understand it you can have many userspace threads for each process, and when one of these userspace threads does a blocking system call the userspace scheduler for the process is notified and can activate another userspace thread. When the system call is done the userspace scheduler is notified again.
The result is that you have very fast thread switching and still all the advantages of SMP.
I think the current Linux pthreads implementation implements threads as heavyweight processes that share the same memory. The effort of switching threads in linux is thus almost the same as switching processes. This is not good!
Does anybody know wether there is a mechanism similar to KSE in the linux 2.4 kernel?
It would be very nice to have a platform-independent intermediate binary format for KDE/Qt. That way you would have one application binary for all KDE compatible systems, instead of having hundreds of different binaries for i386 glibc 2.1, i386 glibc 2.2, Solaris, AIX etc.
Garbage Collection would also be nice, but the main advantage is IMHO the platform-independent binaries. Another huge advantage of using CLR would be to be able to program in many different programming languages without waiting for language bindings.
Open source advocates will say at this point that there is no need for an intermediate binary format because we have the source, but they are missing the point. Joe Sixpack users don't want to do./configure --prefix=whatever && make && make install every time they install a new application. It is simply not an option for them! And even if there were an installer program to hide this complexity, compiling a program from source takes much more time than compiling it from bytecode.
But one thing to keep in mind is that Qt is a very successful commercial cross-platform library, and the fine people at TrollTech will only consider moving to a more powerful runtime when this runtime becomes available on almost all their target platforms (Windows, OS X, Linux, various commercial UNIXe).
I really hope that the mono project or some other project will succeed in making a CLR available on most UNIX machines. Then it would be possible to port Qt and KDE to C# or managed C++ without making big changes to the program logic. Maybe it would even be possible to automate parts of the process.
Slashdot Mirror
It is as simple as that. You can be very quirky as long as you deliver good work. This guy did not get fired because he was quirky, but because he was unable to produce a working program.
If he was such a guru he would have delivered a brilliant, modular, working program, and the people would have coped with his smell. But he did not, and so they rightfully fired him.
A fine example for this is John Carmack. The guy is so quirky that he builds hydrogen peroxide powered rocketships(!) in his pastime. It is quite possible that he will blow himself up one day. But until that day he writes damn fine code, and so every game company would love to hire him.
You are right of course.
Lyx is a real killer application for scientific computing. Everyone who does Math, Engineering or something similar will be much more productive in Lyx than in Word or any other text processor.
It's a shame Lyx still uses this *ugly* xforms library. But that is about to change. There is a gui-independent version in the works, which will work with Qt or GTK, so most linux users should be happy!
Ok. Let's see.
I have an OS (SuSE Linux 7.3) that does absolutely everything I want. It is easy to install, and it does not come with any legal crap. I can use it to develop applications, and even my girlfriend and my mother can use it to browse the net, write E-Mail and write simple letters. That is all they want from a computer.
And now I am supposed to install WinXP and put up with all that crap from microsoft just because Linux lost the "war for the desktop"? We are not even fighting a stupid war.
And I don't care what this guy says. Linux with KDE and StarOffice is good enough for maybe 90% of all enterprise computer users.
regards,
Androgynous Howard
That is not true. Virtual Machines do not always result in lower performance. And the benefits of a platform-independent binary format would be *huge*. Imagine having the same binary for KDE/BSD, KDE/Linux and KDE/Solaris. Ordinary people do not want to compile source code. They do not want to know that they have to use --prefix=/usr with debian and --prefix=/opt with suse. They want to remove applications by deleting a directory. All this is trivial with a decent high-level object format, and almost impossible with C++. C++ is not the best language to write large desktop environments. Objective C is much better, and Java or C# would be heaven!
There is lots of software that would benefit from lower latency. Human perception is not as slow as you think. Just play some mp3's in XMMS and then change the volume. It is really annoying that there is a lag until the volume really changes.
The reason for the lag is that there is a quite large buffer for the audio output. And the reason for this buffer is that sometimes the latency of the linux kernel gets really bad, and you do not want interrupted music when doing disk I/O.
I would love to have a high latency patch available, even if the peak performance would be reduced by, say, 5%. This is a desktop machine, and it is idle most of the time anyway.
regards,
Androgynous Howard
I know that there is a huge amount of confusion about the .NET architecture. Microsoft basically labels everything new they produce .NET, and they themselves never made it entirely clear what the core aspect of .NET is.
But hidden deep in a cloud of marketing buzzwords there is a new and quite interesting development technology. The most important use of .NET will be as a replacement for the old win32 API. Of course it also defines data interchange and storage formats, so it can also be used for data exchange between different (windows) machines.
But basically, .NET is win32 TNG.
If you want to know what parts of the .NET architecture are really interesting technologies and not just buzzwords, take a look at
I think these kernel scheduler entities are a very nifty feature. As far as I understand it you can have many userspace threads for each process, and when one of these userspace threads does a blocking system call the userspace scheduler for the process is notified and can activate another userspace thread. When the system call is done the userspace scheduler is notified again.
The result is that you have very fast thread switching and still all the advantages of SMP.
I think the current Linux pthreads implementation implements threads as heavyweight processes that share the same memory. The effort of switching threads in linux is thus almost the same as switching processes. This is not good!
Does anybody know wether there is a mechanism similar to KSE in the linux 2.4 kernel?
You are right.
./configure --prefix=whatever && make && make install every time they install a new application. It is simply not an option for them! And even if there were an installer program to hide this complexity, compiling a program from source takes much more time than compiling it from bytecode.
It would be very nice to have a platform-independent intermediate binary format for KDE/Qt. That way you would have one application binary for all KDE compatible systems, instead of having hundreds of different binaries for i386 glibc 2.1, i386 glibc 2.2, Solaris, AIX etc.
Garbage Collection would also be nice, but the main advantage is IMHO the platform-independent binaries. Another huge advantage of using CLR would be to be able to program in many different programming languages without waiting for language bindings.
Open source advocates will say at this point that there is no need for an intermediate binary format because we have the source, but they are missing the point. Joe Sixpack users don't want to do
But one thing to keep in mind is that Qt is a very successful commercial cross-platform library, and the fine people at TrollTech will only consider moving to a more powerful runtime when this runtime becomes available on almost all their target platforms (Windows, OS X, Linux, various commercial UNIXe).
I really hope that the mono project or some other project will succeed in making a CLR available on most UNIX machines. Then it would be possible to port Qt and KDE to C# or managed C++ without making big changes to the program logic. Maybe it would even be possible to automate parts of the process.
regards,
Androgynous Howard