Please check your history before you post. The Palestinians did not come into existence until 16 years after the British handed over 1/3 of what the UN resolution required to form present-day Israel.
That's either amazing ignorance you've got there, or just the most blatant bit of lying I've seen on Slashdot for days. The "protectorate" of Palestine existed between the two world wars, and was effectively a colony of the British Empire. Jewish immigration increased dramatically during this period, a result of increased interest in Zionism, itself largely a result of anti-Jewish activity in Europe.
Palestine may not have been an independent nation state, but the Palestinian people had existed as a distinct race since biblical times when the Semitic tribes split along religious grounds. Remember that Jews and Palestinians are both Semitic races.
Israel was created following the even bigger influx of Jewsih refugees after the Second World War. Many of these refugees brought bitter memories of the concenration camps with them, and a willingness to use force to gain a nation state. The British were unable to control the situation, having been effectively bankrupted by the war, and eventually pulled out after increased bombings of their official buildings, etc. The result was bloodshed, as the Jewish militias ehnically cleansed large parts of Palestine. Pretty ironic considering the background to the Jewish desire for a nation state.
That same argument again? It does matter what language you write in, you can still get appalling code if you don't know what you're doing.
I am still yet to see a good reason why Perl cannot be _effectively_ used for anything other than a small/stopgap system.
Perl encourages bad coding style in the same way that C++ does. Both languages have a number of idioms for coding the same thing, and that often leads to highly "personalised" code. I have seen too many projects where Perl was chosen as the implementation language, and then the whole thing became unmaintainable once the original coder(s) moved on. In fact I used to make a living from going into companies as a contractor and fixing such abortions. The fact that I was in such high demand suggests this is a common problem. Ultimately I got sick of doing it, as it's not a very satisfying job. I then expunged the word "Perl" from my CV.
In contrast, Java enforces a more limited set of programming idioms. Some people rail against this, claiming (wrongly in my view) that the limited syntax and lack of things like a preprocessor make coding considerably harder. However I see far less spaghetti code written in Java than I ever saw Perl programmers produce. Ditto for C compared to C++.
Perl may be a good choice as long as you can enforce good coding standards and peer review, but how many typical software houses do that? I've worked at a large number ranging from small to massive, and very few have either policy and even less actually enforce them.
Now you're most likely going to come back with the tired "you're blaming bad programming practices on Perl". But the reality is most companies have bad programming practices, and Perl excacerbates them.
Chris
(Who once believed Perl was the panacea to everything, but nowadays isn't foolish enough to think that either it or Java is).
The poster you're denigrating was right, even if he looks like he's quoting from a textbook. If you can't write a simple frontend for your database using Java and JDBC, then it suggests either your database design is poor, or that you're an appalling programmer. I find Java, JDBC and a RDBMS to be a an excellent combination - far superior to embedded SQL with a lower level language. As for Perl and the DB modules, they're great for small or stopgap systems, but are disastrous for complex systems unless very strict coding standards and thorough peer review are employed[1]. Don't know how Python compares though...
Chris
[1] one man's Perl code is another mans line noise
Could you explain why, exactly, this is a problem? If someone chooses to sell their vote, why shouldn't they be allowed to do so? This is a serious question.
Because it undermines the whole notion of voting for a candidate because of the things they promise to do once in power. Bad election practices such as these were common in parts of England until the nineteenth century. "Rotten boroughs" with small numbers of eligible voters could be used to ensure a candidate got into parliament. Even after the widening of the franchise a mixture of bribery and coercion was common, with small farmers and manual labourers expected to vote how their bosses saw fit.
Despite it's naff name, the Happy Hacker keyboard is quite good. It's small as well as having the Control and Caps Lock keys in the correct place. It still doesn't beat the Sun Type 5 keyboard, but I don't know if you can connect one of them to a PC.
It was mature long before the free BSD's were, and as a result gained a foothold in the ISP market when the Internet started to expand. You could also get the source for what was a comparatively reasonable license cost at the time, (early to mid nineties). As an example, Stephen's seminal "Advanced Programming in the Unix Environment" was so informative in part because of the authors ability to poke around the BSD/OS source code.
There are very few reasons, from a technical perspective, to use proprietary operating systems instead of GNU.
How about the fact that the Linux kernel is geared towards desktop and server machines, and as a result it's very hard to strip the kernel down to a reasonable size? Linux isn't a "one size fits all" solution, and projects like uCLinux are only applicable to a small subset of embedded projects. Another problem with Linux from an embedded developer's point of view, is the regularity with which key subsystems are replaced or radically altered. The endless overhauling of the scheduler is a fine example - such changes benefit desktop users but causes all kinds of headaches for embedded people when they update their kernels.
2.11BSD is a misnomer, because 2.11BSD was intermingled with AT&T Unix
Yup, but I think 2.11BSD was one of the ancient Unix releases that SCO (as Caldera) put under a BSD license. however, since my original post Bruce Perens has done a much more thorough analysis of where this code came from.
While it's true that the code was released under a BSD-style license, that license requires that credit be given to Caldera in derivative products. That credit, as far as I'm aware, was not given
The code in question was submitted to Linus by SGI, and was subsequently removed two months ago. Given that SCO decided to use an example of alleged code copying at their Forum, you think they'd using something a little more incriminating. The example has been published in books and released under at least one BSD license - the code's in 2.11BSD, so chances are it was in the 4.4BSD Lite release as well.
All configs were in text files including the Wharf (called Icon Dock in Next).
And that's a bad thing, how?
If it still used the same configuration format as fvwm, then you not only had to hand edit some terrible looking pseudo scripts, you then had to run them through a processor (m4 if memory serves). Remember that not all text configuration files are good (think Sendmail). Given the emphasis on XML in this new version of AfterStep, I'd be surprised if the config files haven't been improved if they hadn't been already.
Certainly does. He also dislikes C, yet he programs using GTK+. I guess he must be a fan of gtkmm. Frankly, I get the impression that the articles author is a little bit inexperienced, and would be better off learning Java and its Swing API. That will give him a decent grounding in MVC architecture, while keeping him otherwise occupied so that he doesn't write any more articles:)
When I lived in Oxford, UK one of the members of the local LUG was also a Sinclair C5 fan. He occasionally uses his C5 to travel to work, having kitted it out with two flourescent flags on poles to make the machine a bit more visible. He also does long distance trips for charity once a year - I recall that the last one was an attempt to travel the length of the country. Spares are fairly easy to come by, one good consequence of Sinclair using off the shelf parts. The tyres for instance, are similar to those used on many prams(!).
Yes there really was a 80186 but it was never used officially by IBM in any PC model, hence very few clone makers used it either.
An ex-colleague had an 80186 PC in that small timeframe before the 80286 was available. He had been a contractor at the time, and just had to have the latest bit of kit. He used the 186 box for a few months and then it went into the back of his garage when the 286 came out. When he told me this about six years ago I thought he was bullshitting me, but he dug the machine out to prove it. Can't remember the brand name of the manufacturer though.
C# is a Java wannabe, and can hardly compete with C++ in areas where Java can't compete with C++ (i.e. severely cramped power-performance-memory critical environments).
On "power-performance-memory critical environments" you wouldn't be wanting to use C++ anyway - unless it's in a very limited "better C" kind of way. The sorts of devices you seem to be describing are generally programmed in C or assembler. Anything more powerfull will probably run Java - which is why I'll now get back to programming a Java app for Symbol handheld devices...
The article is missing the single largest UNIX distribution in terms of licenses shipped, OS X.
Have they really shipped that many OS X licenses in the short time it's been available? Surely Sun has still shipped more SunOS licenses in all the years they've been selling Unix? I expect Apple to surpass everyone else at some point, but I find it hard to believe they've done so already.
pointing out SCO UNIX sucking has become a guaranteed way to get Slashdot to link to your article, where you can do fun and silly things like promote BSD as being more "scalable" than Linux
The author of the jemreport article certainly included some provocative comments, like the statement that Linux is less mature than the *BSD's. That kind of thing definitely needs backing up if it's true, (it clearly isn't). The "standard" Linus endorsed kernel may have quality problems at times, but one of the goals of Linux is to include new features even if they are a bit half baked - the argument being that they wont have the bugs shaken out until they reach a bigger audience. Of course, part of the value that a Linux distribution adds is quality control. RedHat never ships a vanilla Linus kernel for instance.
Anyway, onto the scalabilty claim. The jemreport guy needs to qualify that as well. If it was something I wanted to argue, then I'd point out that while Linux clearly scales lot better on the SMP front, it offers little or no benefit over the BSD's when you consider most peoples "scalable environment". Unless you're lucky enough to have an IBM mainframe, the most likely way you'll ensure scalablity is by having a server farm of uniprocessor machines - hence the profusion of "blade" machines nowadays. In this kind of setup my first choice would likely to be FreeBSD. I ran a number of performance tests using Linux and FreeBSD before settling on the latter for the last server farm I setup. Obviously things change, and I would have to run more tests prior setting up a similar system in the future.
I tried PlanetCCRMA a couple of months ago. My machine is a dual boot NetBSD/Redhat Linux box, and the PlanetCCRMA stuff installed very smoothly. However, I can't get Linux to recognise my USB MIDI interface. It's a Yamaha UX-96, which is recognised immediately by NetBSD, but Linux is unable to see it. There is definitely ALSA support for the UX-96, so I can only assume I need some magic incantation in my modutils config file.
Someone with the bandwidth to download this might be able to confirm this, but it appears that the beta doesn't come with ALSA. A shame for those of us who like RedHat, but want to use the latest MIDI apps "out of the box".
Only recent ones! I picked up a reasonably priced NeXT slab on Ebay - it's in mint condition with colour monitor, original software and manuals. The quality of the GUI and API's is amazing, especially when you consider that the thing's only got a Motorola 68030 in it. My Macinstosh LC II (running MacOS 6) has a responsive and pleasant GUI, but using the Programmers Workbench is nowhere near as fun as developing with the NeXT stuff.
Despite my love of NetBSD, I'm giving serious consideration to buying an Apple laptop and running MacOS X on it.
Definitely an interesting article, and I'm even inclined to read some of the authors stuff. However, he might need to clarify that bit about the Dhrystone benchmark being thirty or more years old. If it is, then it wasn't written to allow comparison against the performance of the Vax as he claims. The first Vax systems didn't ship until the late 1970's, a little over twenty years ago.
Java and C# got large parts of their syntax and semantics from C and C++.
C and Objective-C actually - the influence of C++ on Java was minimal except in the "that's how not to do it" sense. There's two main strands of OOP languages, those that can trace their lineage back to Modula and those that trace it back to Smalltalk. Java (and C# as it's just MS Java), are more heavily influenced by the Smalltalk style of OOP.
a decent number of Linux apps assume they're on an x86
Which makes them badly written apps. The only situation where the instruction set should be a factor is if your program includes assembler for a crucial section of code. Then the commonly accepted "good practice" is to first code the section in a higher level language like C, and only build the hand crafted assembler version if the build/configuration system determines you're on a suitable platform.
The big killer between x86 and PPC, I think, is byte order
That's as well as the usual stuff like travel, reading, clubbing and gig-going that any normal person does. Though I suppose there are plenty of abnormal people among the Slashdot readership...
Slashdot Mirror
Please check your history before you post. The Palestinians did not come into existence until 16 years after the British handed over 1/3 of what the UN resolution required to form present-day Israel.
That's either amazing ignorance you've got there, or just the most blatant bit of lying I've seen on Slashdot for days. The "protectorate" of Palestine existed between the two world wars, and was effectively a colony of the British Empire. Jewish immigration increased dramatically during this period, a result of increased interest in Zionism, itself largely a result of anti-Jewish activity in Europe.
Palestine may not have been an independent nation state, but the Palestinian people had existed as a distinct race since biblical times when the Semitic tribes split along religious grounds. Remember that Jews and Palestinians are both Semitic races.
Israel was created following the even bigger influx of Jewsih refugees after the Second World War. Many of these refugees brought bitter memories of the concenration camps with them, and a willingness to use force to gain a nation state. The British were unable to control the situation, having been effectively bankrupted by the war, and eventually pulled out after increased bombings of their official buildings, etc. The result was bloodshed, as the Jewish militias ehnically cleansed large parts of Palestine. Pretty ironic considering the background to the Jewish desire for a nation state.
Chris
I thought I'd amuse myself by checking out your website, and came across this gem:
Funny Code
... which starts off by cataloging some Perl atrocities. Then under the C/C++ section you write:
haven't got any good examples of C/C++ funny code yet
... and you still felt the need to question my own dislike of Perl?
Chris
That same argument again? It does matter what language you write in, you can still get appalling code if you don't know what you're doing.
I am still yet to see a good reason why Perl cannot be _effectively_ used for anything other than a small/stopgap system.
Perl encourages bad coding style in the same way that C++ does. Both languages have a number of idioms for coding the same thing, and that often leads to highly "personalised" code. I have seen too many projects where Perl was chosen as the implementation language, and then the whole thing became unmaintainable once the original coder(s) moved on. In fact I used to make a living from going into companies as a contractor and fixing such abortions. The fact that I was in such high demand suggests this is a common problem. Ultimately I got sick of doing it, as it's not a very satisfying job. I then expunged the word "Perl" from my CV.
In contrast, Java enforces a more limited set of programming idioms. Some people rail against this, claiming (wrongly in my view) that the limited syntax and lack of things like a preprocessor make coding considerably harder. However I see far less spaghetti code written in Java than I ever saw Perl programmers produce. Ditto for C compared to C++.
Perl may be a good choice as long as you can enforce good coding standards and peer review, but how many typical software houses do that? I've worked at a large number ranging from small to massive, and very few have either policy and even less actually enforce them.
Now you're most likely going to come back with the tired "you're blaming bad programming practices on Perl". But the reality is most companies have bad programming practices, and Perl excacerbates them.
Chris
(Who once believed Perl was the panacea to everything, but nowadays isn't foolish enough to think that either it or Java is).
The poster you're denigrating was right, even if he looks like he's quoting from a textbook. If you can't write a simple frontend for your database using Java and JDBC, then it suggests either your database design is poor, or that you're an appalling programmer. I find Java, JDBC and a RDBMS to be a an excellent combination - far superior to embedded SQL with a lower level language. As for Perl and the DB modules, they're great for small or stopgap systems, but are disastrous for complex systems unless very strict coding standards and thorough peer review are employed[1]. Don't know how Python compares though ...
Chris
[1] one man's Perl code is another mans line noise
Could you explain why, exactly, this is a problem? If someone chooses to sell their vote, why shouldn't they be allowed to do so? This is a serious question.
Because it undermines the whole notion of voting for a candidate because of the things they promise to do once in power. Bad election practices such as these were common in parts of England until the nineteenth century. "Rotten boroughs" with small numbers of eligible voters could be used to ensure a candidate got into parliament. Even after the widening of the franchise a mixture of bribery and coercion was common, with small farmers and manual labourers expected to vote how their bosses saw fit.
Chris
Despite it's naff name, the Happy Hacker keyboard is quite good. It's small as well as having the Control and Caps Lock keys in the correct place. It still doesn't beat the Sun Type 5 keyboard, but I don't know if you can connect one of them to a PC.
Chris
Was BSD/OS popular before the free BSDs?
It was mature long before the free BSD's were, and as a result gained a foothold in the ISP market when the Internet started to expand. You could also get the source for what was a comparatively reasonable license cost at the time, (early to mid nineties). As an example, Stephen's seminal "Advanced Programming in the Unix Environment" was so informative in part because of the authors ability to poke around the BSD/OS source code.
Chris
There are very few reasons, from a technical perspective, to use proprietary operating systems instead of GNU.
How about the fact that the Linux kernel is geared towards desktop and server machines, and as a result it's very hard to strip the kernel down to a reasonable size? Linux isn't a "one size fits all" solution, and projects like uCLinux are only applicable to a small subset of embedded projects. Another problem with Linux from an embedded developer's point of view, is the regularity with which key subsystems are replaced or radically altered. The endless overhauling of the scheduler is a fine example - such changes benefit desktop users but causes all kinds of headaches for embedded people when they update their kernels.
Chris
2.11BSD is a misnomer, because 2.11BSD was intermingled with AT&T Unix
Yup, but I think 2.11BSD was one of the ancient Unix releases that SCO (as Caldera) put under a BSD license. however, since my original post Bruce Perens has done a much more thorough analysis of where this code came from.
Chris
While it's true that the code was released under a BSD-style license, that license requires that credit be given to Caldera in derivative products. That credit, as far as I'm aware, was not given
The code in question was submitted to Linus by SGI, and was subsequently removed two months ago. Given that SCO decided to use an example of alleged code copying at their Forum, you think they'd using something a little more incriminating. The example has been published in books and released under at least one BSD license - the code's in 2.11BSD, so chances are it was in the 4.4BSD Lite release as well.
Chris
All configs were in text files including the Wharf (called Icon Dock in Next).
And that's a bad thing, how?If it still used the same configuration format as fvwm, then you not only had to hand edit some terrible looking pseudo scripts, you then had to run them through a processor (m4 if memory serves). Remember that not all text configuration files are good (think Sendmail). Given the emphasis on XML in this new version of AfterStep, I'd be surprised if the config files haven't been improved if they hadn't been already.
Chris
This article reads like a Qt flamefest.
Certainly does. He also dislikes C, yet he programs using GTK+. I guess he must be a fan of gtkmm. Frankly, I get the impression that the articles author is a little bit inexperienced, and would be better off learning Java and its Swing API. That will give him a decent grounding in MVC architecture, while keeping him otherwise occupied so that he doesn't write any more articles :)
Chris
When I lived in Oxford, UK one of the members of the local LUG was also a Sinclair C5 fan. He occasionally uses his C5 to travel to work, having kitted it out with two flourescent flags on poles to make the machine a bit more visible. He also does long distance trips for charity once a year - I recall that the last one was an attempt to travel the length of the country. Spares are fairly easy to come by, one good consequence of Sinclair using off the shelf parts. The tyres for instance, are similar to those used on many prams(!).
Chris
Yes there really was a 80186 but it was never used officially by IBM in any PC model, hence very few clone makers used it either.
An ex-colleague had an 80186 PC in that small timeframe before the 80286 was available. He had been a contractor at the time, and just had to have the latest bit of kit. He used the 186 box for a few months and then it went into the back of his garage when the 286 came out. When he told me this about six years ago I thought he was bullshitting me, but he dug the machine out to prove it. Can't remember the brand name of the manufacturer though.
Chris
C# is a Java wannabe, and can hardly compete with C++ in areas where Java can't compete with C++ (i.e. severely cramped power-performance-memory critical environments).
On "power-performance-memory critical environments" you wouldn't be wanting to use C++ anyway - unless it's in a very limited "better C" kind of way. The sorts of devices you seem to be describing are generally programmed in C or assembler. Anything more powerfull will probably run Java - which is why I'll now get back to programming a Java app for Symbol handheld devices ...
Chris
It's also missing IRIX.
And HP-UX - although I vaguely recall that it's being phased out along with Digital/Compaq/HP Tru64.
Chris
The article is missing the single largest UNIX distribution in terms of licenses shipped, OS X.
Have they really shipped that many OS X licenses in the short time it's been available? Surely Sun has still shipped more SunOS licenses in all the years they've been selling Unix? I expect Apple to surpass everyone else at some point, but I find it hard to believe they've done so already.
Chris
pointing out SCO UNIX sucking has become a guaranteed way to get Slashdot to link to your article, where you can do fun and silly things like promote BSD as being more "scalable" than Linux
The author of the jemreport article certainly included some provocative comments, like the statement that Linux is less mature than the *BSD's. That kind of thing definitely needs backing up if it's true, (it clearly isn't). The "standard" Linus endorsed kernel may have quality problems at times, but one of the goals of Linux is to include new features even if they are a bit half baked - the argument being that they wont have the bugs shaken out until they reach a bigger audience. Of course, part of the value that a Linux distribution adds is quality control. RedHat never ships a vanilla Linus kernel for instance.
Anyway, onto the scalabilty claim. The jemreport guy needs to qualify that as well. If it was something I wanted to argue, then I'd point out that while Linux clearly scales lot better on the SMP front, it offers little or no benefit over the BSD's when you consider most peoples "scalable environment". Unless you're lucky enough to have an IBM mainframe, the most likely way you'll ensure scalablity is by having a server farm of uniprocessor machines - hence the profusion of "blade" machines nowadays. In this kind of setup my first choice would likely to be FreeBSD. I ran a number of performance tests using Linux and FreeBSD before settling on the latter for the last server farm I setup. Obviously things change, and I would have to run more tests prior setting up a similar system in the future.
Chris
I tried PlanetCCRMA a couple of months ago. My machine is a dual boot NetBSD/Redhat Linux box, and the PlanetCCRMA stuff installed very smoothly. However, I can't get Linux to recognise my USB MIDI interface. It's a Yamaha UX-96, which is recognised immediately by NetBSD, but Linux is unable to see it. There is definitely ALSA support for the UX-96, so I can only assume I need some magic incantation in my modutils config file.
Chris
Someone with the bandwidth to download this might be able to confirm this, but it appears that the beta doesn't come with ALSA. A shame for those of us who like RedHat, but want to use the latest MIDI apps "out of the box".
Chris
anybody else have fond NeXT memories?
Only recent ones! I picked up a reasonably priced NeXT slab on Ebay - it's in mint condition with colour monitor, original software and manuals. The quality of the GUI and API's is amazing, especially when you consider that the thing's only got a Motorola 68030 in it. My Macinstosh LC II (running MacOS 6) has a responsive and pleasant GUI, but using the Programmers Workbench is nowhere near as fun as developing with the NeXT stuff.
Despite my love of NetBSD, I'm giving serious consideration to buying an Apple laptop and running MacOS X on it.
Chris
Definitely an interesting article, and I'm even inclined to read some of the authors stuff. However, he might need to clarify that bit about the Dhrystone benchmark being thirty or more years old. If it is, then it wasn't written to allow comparison against the performance of the Vax as he claims. The first Vax systems didn't ship until the late 1970's, a little over twenty years ago.
Chris
Java and C# got large parts of their syntax and semantics from C and C++.
C and Objective-C actually - the influence of C++ on Java was minimal except in the "that's how not to do it" sense. There's two main strands of OOP languages, those that can trace their lineage back to Modula and those that trace it back to Smalltalk. Java (and C# as it's just MS Java), are more heavily influenced by the Smalltalk style of OOP.
Chris
a decent number of Linux apps assume they're on an x86
Which makes them badly written apps. The only situation where the instruction set should be a factor is if your program includes assembler for a crucial section of code. Then the commonly accepted "good practice" is to first code the section in a higher level language like C, and only build the hand crafted assembler version if the build/configuration system determines you're on a suitable platform.
The big killer between x86 and PPC, I think, is byte order
The PPC can switch between endian states.
Chris
Non-techie stuff I do:
That's as well as the usual stuff like travel, reading, clubbing and gig-going that any normal person does. Though I suppose there are plenty of abnormal people among the Slashdot readership ...
Chris