The KDE Project Ships the Third-Generation of the Leading
Desktop for Linux/UNIX, Offering Enterprises, Governments, Schools,
and Businesses an Outstanding Free and Open Desktop Solution
So what exactly is the difference between an Enterprise and a Business?
C has some special syntax so that if you have a function pointer c, you can call it as just c(). The more longwinded (*c)() also works. But this syntactic sugar doesn't mean they are the same - clearly you can assign a new value to c(), but a function defined as foo() cannot be 'assigned to'.
There was once an article linked from Slashdot ('tips for C programmers' or the like) which explained this clearly - but I can't find the link now:-(. Essentially, you have to consider the C declaration syntax as a kind of logical puzzle.
Take 'char *c'. This says that *c is a char. So what is the type of c? Working backwards, it must be pointer to char. Or with 'char (*c(int))' you can see that *c(int) has type char, so *c must be a function taking int and returning char, so c is a pointer to such a function. The cdecl tool can help with figuring out the more complex cases:-).
The best practice, IMHO, is just to follow whatever the language's author prefers. He or she is likely to have quite a bit of experience, right? And presumably if you like the language then you already agree that its designer has some degree of good taste.
This means: for C, follow the style in K for C++ get a copy of Stroustrup's book and follow the style he uses; for Perl read the perlstyle(1) manual page; and for Java follow Sun's conventions. This gives you the best chance of interoperating with other people's code.
Of course, if you're doing development within a larger project, such as adding code to an existing program or writing a new utility to add to OpenBSD, then you should follow the local style conventions. Just find what the local 'source of authority' is, and follow that.
It's ironic that the most popular language with taint checking doesn't have any static typing, and all taint checks are done at runtime. Because compile-time taint checking would be really cool and not hard to do.
Part of the appeal of compile-time type checking is quicker feedback on what went wrong. It's certainly much faster to have an error reported by the compiler, go back and fix it and recompile, than to start running your app, run the test cases, wait for the particular test case that exercises the bit of code you just wrote, and find a type error at runtime. Even with a scripting language like Perl of Python you still have a compiler which checks the syntax of the code - would you really want to not find out about syntax errors until that particular line of code actually gets executed? (Like in old versions of Tcl, I think.)
Type checking is not a substitute for testing but it is handy to get quick feedback on your code.
The thing is, 'windows' may be a generic term, but Lindows are not trying to make an operating system that just happens to have a windowing GUI. They are trying to make a substitute for Microsoft Windows. I am sure they will market it on this basis too.
However, in any sane trademark system you'd credit the consumer with a minimal amount of intelligence and assume that Lindows can be distinguished from Windows, as Radiation Dude from Radioactive Man. Who knows, perhaps this will even be the outcome.
In fact it is widely held that Teletubbies represents a future world where the underground house is a nuclear bunker, the talking periscopes that rise from the ground issue instructions from a totalitarian government, etc etc.
Actually, wearing a tiara does not depend upon rank. It's traditionally associated with marriage, and you do have to be female, but Leia could still wear her tiara even if she were no longer a princess.
The PPro sucked at runnin 16 bit code - because at the time it was designed Intel didn't anticipate that people would _still_ be running 16-bit stuff in the mid-90s - but the next iteration the Pentium II was better. I wonder if McKinley is expected to give a boost to legacy code compared to Itanic.
If the entire critical loop is in assembler (not just a small part of it) then it could be worth switching. Although based on what another poster wrote, it sounds like the emulation is so lousy that no matter how suboptimal gcc's code generation
I have one of those at home, ex-Midland Bank fileserver, I put Linux on it. Although it now has an IBM Blue Lightning CPU instead of the original 386 processor, and more than the original 12 megs of memory.
Quite obviously, inline assembly must be rewritten from scratch.
I don't see what is so obvious - isn't one of the selling points of Itanium its backward i386 compatibility? Even if running the 64-bit version of Linux it should still be possible to switch the processor into i386-compatible mode to execute some 386 opcodes and then back again. After all, the claim is that old Linux/i386 binaries will continue to work. Or is there some factor that means the choice of 32 bit vs 64 bit code must be made process-by-process?
Interesting question: which would run faster, hand-optimized i386 code running under emulation on an Itanium, or native IA-64 code produced by gcc? They say that writing a decent IA-64 compiler is difficult, and I'm sure Intel has put a lot of work into making the backwards compatibility perform at a reasonable speed (if not quite as fast as a P4 at the same clock).
Back in the early '80s, nobody at Intel thought their microprocessors would one day
be used for servers; the inherent architecture of the i386 family shows that clearly.
That's funny, I thought that the i386 was specifically designed to run MULTICS, which was the very definition of a 'server' operating system (computing power as a utility, like water and electricity). The early 80s was the time Intel designed the i386 wasn't it?
Well obviously what we'll see next is a kernel extension that dynamically 'ports' all your applications to IA-64 and transparently migrates them to IA-64 machines elsewhere in the cluster. When Intel's next Great Leap Forward is released, you'll be able to transparently migrate to that as well. In fact it will be so transparent, you won't notice any difference and you can continue working at your 80286-based machine without any interruption.
Re:Design patterns and Lisp
on
Bitter Java
·
· Score: 3, Informative
I just fininished reading Modern C++ Design by Andrei Alexandrescu, which explains all sorts of cool hacks you can do with templates in C++. Or to put it in more sober language, how to implement reusable design patterns using C++'s templates and compile-time polymorphism.
It's a great read and really demonstrates just how powerful C++'s templating system is. It shows how to do just what you say - create a general macro from a specific pattern instance - for example making reusable templates to efficiently implement multiple dispatch and the Visitor pattern. And C++'s template specialization happens at compile time, which with a good optimizing compiler gives you performance as good as handwritten code. I haven't used Common Lisp so I can't compare C++ templates to CL macros - but you shouldn't underestimate C++'s macro-ing and code reuse abilities. The syntax is horrible, but there do exist people who don't like Lisp syntax either...
The fact that early C++ implementations were using the cfront preprocessor doesn't really say much about the language - just that it had an unwieldy first implementation. All current C++ compilers really do handle the language natively (g++ for one). You can find all sorts of reasons for saying C++ is unpleasant and ugly, but cfront is not one of them. OTOH, if you were saying that Lisp is more powerful than C because it is much easier to add objects to Lisp than to add them to C: well of course, everyone knew that already.
Obligatory browser-plugging comment: Dillo is free and very fast. It doesn't support frames or Javascript, but they suck anyway. I'm using it to read Slashdot and post this comment now (while pouring hot grits down my pants;-)).
The best tool for compressing scanned documents is tic98, written as part of someone's PhD thesis. It is GPLed, but unfortunately the website has disappeared except from Google's cache. Does anyone have a copy of the source tarball?
The IBM Model M keyboard has detachable keycaps which you can just pop off and wash. I had a keyboard in a dark cupboard for a year or so, and it started to grow a kind of orange mould or yeast from a spillage made years ago. Fortunately I was able to remove all the keycaps, wash them with hot water and soap, and put them back after drying.
I believe that it is safe to put a keyboard in the dishwasher, provided you give it _lots_ of time to dry off afterwards before trying to use it again.
Apparently studies show that girls with brothers are healthier than those without. The reason is thought to be more exposure to dirt and germs. Some children are being prescribed soil injections to stimulate the immune system. (sorry no link - but search yourself to see if I am correct)
The co-operative multitasking wasn't really a design choice; it was just that the Arthur operating system was hacked together in a hurry and didn't have multitasking (in many ways it was like a port of the BBC Micro operating system to 32-bit hardware). Then RISC OS 2, based on Arthur, used co-operative multitasking with a polling loop *probably* because this was the easiest thing to do without starting from scratch and building a new OS. It did give good performance though - provided apps didn't hang. There was some memory protection so it wasn't a completely braindead system - but still, I believe later RISC OS versions (4.x?) added true multitasking.
A few random links: Riscose, kind of the equivalent of Wine, except it isn't nearly as finished (it does include an ARM CPU emulator though). Riscose ties in somehow with the 'RISC OS emulator' package somebody mentioned at the top of this article's comments. Although I very much doubt that such a system is ready for any real work, even as a testbed for embedded code. RISC OS included an interpreter for the BBC Basic language (again essentially a port from the BBC Micro with some improvements), and Brandy is a free interpreter for that language. Finally, Arcem is an emulator (a la Bochs) of the original Archimedes hardware. It will run RISC OS 2.0 and 3.x well enough, if you can get hold of the ROM images. On a 1GHz machine, arcem should be just about fast enough to emulate the original 8MHz Archimedes in real time.
If all you have is a modem, then wwwoffle is an even better proxy server than Squid, because it knows about 'online' and 'offline'. If you go offline then the proxy server never tries to download anything - it always serves the page in the cache without checking the (unreachable) server for a new version. So you can browse through already-visited sites without any hassle.
More than that, if you visit while offline a page you haven't seen before, then wwwoffle returns a message saying 'I don't have this page, but I will fetch it'. Next time you go online, you can run 'wwwoffle -fetch' and all the queued pages will be fetched. So in effect you can keep browsing while the phone line is disconnected, and then 'catch up' afterwards.
Slashdot Mirror
C has some special syntax so that if you have a function pointer c, you can call it as just c(). The more longwinded (*c)() also works. But this syntactic sugar doesn't mean they are the same - clearly you can assign a new value to c(), but a function defined as foo() cannot be 'assigned to'.
There was once an article linked from Slashdot ('tips for C programmers' or the like) which explained this clearly - but I can't find the link now :-(. Essentially, you have to consider the C declaration syntax as a kind of logical puzzle.
:-).
Take 'char *c'. This says that *c is a char. So what is the type of c? Working backwards, it must be pointer to char. Or with 'char (*c(int))' you can see that *c(int) has type char, so *c must be a function taking int and returning char, so c is a pointer to such a function. The cdecl tool can help with figuring out the more complex cases
The best practice, IMHO, is just to follow whatever the language's author prefers. He or she is likely to have quite a bit of experience, right? And presumably if you like the language then you already agree that its designer has some degree of good taste.
This means: for C, follow the style in K for C++ get a copy of Stroustrup's book and follow the style he uses; for Perl read the perlstyle(1) manual page; and for Java follow Sun's conventions. This gives you the best chance of interoperating with other people's code.
Of course, if you're doing development within a larger project, such as adding code to an existing program or writing a new utility to add to OpenBSD, then you should follow the local style conventions. Just find what the local 'source of authority' is, and follow that.
I find 'use strict' invaluable for catching common errors statically. Do you mean it doesn't go far enough, or that it's too strict already?
It's ironic that the most popular language with taint checking doesn't have any static typing, and all taint checks are done at runtime. Because compile-time taint checking would be really cool and not hard to do.
Part of the appeal of compile-time type checking is quicker feedback on what went wrong. It's certainly much faster to have an error reported by the compiler, go back and fix it and recompile, than to start running your app, run the test cases, wait for the particular test case that exercises the bit of code you just wrote, and find a type error at runtime. Even with a scripting language like Perl of Python you still have a compiler which checks the syntax of the code - would you really want to not find out about syntax errors until that particular line of code actually gets executed? (Like in old versions of Tcl, I think.)
Type checking is not a substitute for testing but it is handy to get quick feedback on your code.
The thing is, 'windows' may be a generic term, but Lindows are not trying to make an operating system that just happens to have a windowing GUI. They are trying to make a substitute for Microsoft Windows. I am sure they will market it on this basis too.
However, in any sane trademark system you'd credit the consumer with a minimal amount of intelligence and assume that Lindows can be distinguished from Windows, as Radiation Dude from Radioactive Man. Who knows, perhaps this will even be the outcome.
In fact it is widely held that Teletubbies represents a future world where the underground house is a nuclear bunker, the talking periscopes that rise from the ground issue instructions from a totalitarian government, etc etc.
Actually, wearing a tiara does not depend upon rank. It's traditionally associated with marriage, and you do have to be female, but Leia could still wear her tiara even if she were no longer a princess.
The PPro sucked at runnin 16 bit code - because at the time it was designed Intel didn't anticipate that people would _still_ be running 16-bit stuff in the mid-90s - but the next iteration the Pentium II was better. I wonder if McKinley is expected to give a boost to legacy code compared to Itanic.
If the entire critical loop is in assembler (not just a small part of it) then it could be worth switching. Although based on what another poster wrote, it sounds like the emulation is so lousy that no matter how suboptimal gcc's code generation
I have one of those at home, ex-Midland Bank fileserver, I put Linux on it. Although it now has an IBM Blue Lightning CPU instead of the original 386 processor, and more than the original 12 megs of memory.
I don't see what is so obvious - isn't one of the selling points of Itanium its backward i386 compatibility? Even if running the 64-bit version of Linux it should still be possible to switch the processor into i386-compatible mode to execute some 386 opcodes and then back again. After all, the claim is that old Linux/i386 binaries will continue to work. Or is there some factor that means the choice of 32 bit vs 64 bit code must be made process-by-process?
Interesting question: which would run faster, hand-optimized i386 code running under emulation on an Itanium, or native IA-64 code produced by gcc? They say that writing a decent IA-64 compiler is difficult, and I'm sure Intel has put a lot of work into making the backwards compatibility perform at a reasonable speed (if not quite as fast as a P4 at the same clock).
Well obviously what we'll see next is a kernel extension that dynamically 'ports' all your applications to IA-64 and transparently migrates them to IA-64 machines elsewhere in the cluster. When Intel's next Great Leap Forward is released, you'll be able to transparently migrate to that as well. In fact it will be so transparent, you won't notice any difference and you can continue working at your 80286-based machine without any interruption.
I just fininished reading Modern C++ Design by Andrei Alexandrescu, which explains all sorts of cool hacks you can do with templates in C++. Or to put it in more sober language, how to implement reusable design patterns using C++'s templates and compile-time polymorphism.
It's a great read and really demonstrates just how powerful C++'s templating system is. It shows how to do just what you say - create a general macro from a specific pattern instance - for example making reusable templates to efficiently implement multiple dispatch and the Visitor pattern. And C++'s template specialization happens at compile time, which with a good optimizing compiler gives you performance as good as handwritten code. I haven't used Common Lisp so I can't compare C++ templates to CL macros - but you shouldn't underestimate C++'s macro-ing and code reuse abilities. The syntax is horrible, but there do exist people who don't like Lisp syntax either...
The fact that early C++ implementations were using the cfront preprocessor doesn't really say much about the language - just that it had an unwieldy first implementation. All current C++ compilers really do handle the language natively (g++ for one). You can find all sorts of reasons for saying C++ is unpleasant and ugly, but cfront is not one of them. OTOH, if you were saying that Lisp is more powerful than C because it is much easier to add objects to Lisp than to add them to C: well of course, everyone knew that already.
If Pong is 100% analogue, how does it keep track of the score?
Obligatory browser-plugging comment: Dillo is free and very fast. It doesn't support frames or Javascript, but they suck anyway. I'm using it to read Slashdot and post this comment now (while pouring hot grits down my pants ;-)).
Update: tic98, the tightest (lossless) compressor for scanned documents, is back online.
The best tool for compressing scanned documents is tic98, written as part of someone's PhD thesis. It is GPLed, but unfortunately the website has disappeared except from Google's cache. Does anyone have a copy of the source tarball?
The IBM Model M keyboard has detachable keycaps which you can just pop off and wash. I had a keyboard in a dark cupboard for a year or so, and it started to grow a kind of orange mould or yeast from a spillage made years ago. Fortunately I was able to remove all the keycaps, wash them with hot water and soap, and put them back after drying.
I believe that it is safe to put a keyboard in the dishwasher, provided you give it _lots_ of time to dry off afterwards before trying to use it again.
Apparently studies show that girls with brothers are healthier than those without. The reason is thought to be more exposure to dirt and germs. Some children are being prescribed soil injections to stimulate the immune system. (sorry no link - but search yourself to see if I am correct)
The co-operative multitasking wasn't really a design choice; it was just that the Arthur operating system was hacked together in a hurry and didn't have multitasking (in many ways it was like a port of the BBC Micro operating system to 32-bit hardware). Then RISC OS 2, based on Arthur, used co-operative multitasking with a polling loop *probably* because this was the easiest thing to do without starting from scratch and building a new OS. It did give good performance though - provided apps didn't hang. There was some memory protection so it wasn't a completely braindead system - but still, I believe later RISC OS versions (4.x?) added true multitasking.
A few random links: Riscose, kind of the equivalent of Wine, except it isn't nearly as finished (it does include an ARM CPU emulator though). Riscose ties in somehow with the 'RISC OS emulator' package somebody mentioned at the top of this article's comments. Although I very much doubt that such a system is ready for any real work, even as a testbed for embedded code. RISC OS included an interpreter for the BBC Basic language (again essentially a port from the BBC Micro with some improvements), and Brandy is a free interpreter for that language. Finally, Arcem is an emulator (a la Bochs) of the original Archimedes hardware. It will run RISC OS 2.0 and 3.x well enough, if you can get hold of the ROM images. On a 1GHz machine, arcem should be just about fast enough to emulate the original 8MHz Archimedes in real time.
If all you have is a modem, then wwwoffle is an even better proxy server than Squid, because it knows about 'online' and 'offline'. If you go offline then the proxy server never tries to download anything - it always serves the page in the cache without checking the (unreachable) server for a new version. So you can browse through already-visited sites without any hassle.
More than that, if you visit while offline a page you haven't seen before, then wwwoffle returns a message saying 'I don't have this page, but I will fetch it'. Next time you go online, you can run 'wwwoffle -fetch' and all the queued pages will be fetched. So in effect you can keep browsing while the phone line is disconnected, and then 'catch up' afterwards.