The GNU toolchain is increasingly unpopular in the BSD world, both from license and technological perspectives. The switch to GPLv3 and the whole modular framework stuff with it's attempt to make everything a derived work is annoying from a license perspective. I wonder how many people would have contributed to GCC if they'd known that their work would be used as part of such an ideological stunt - at least Linus removed that "later version" crap from the copy of the GPL license Linux is under. From a technological point of view, GCC is not a very fast compiler, the code it produces is not very good (most of the optimisers struggle to do a decent job for instance), and the codebase is a mess. Add in the aggressive attempts to remove support for platforms that are still supported by NetBSD and OpenBSD, and you can see why various people and companies such as Apple are working on projects like PCC and LLVM.
What's troublesome with softdeps? Genuine question.
Soft dependencies were originally written as a FreeBSD feature, and then ported to NetBSD. I don't know how reliable it is on FreeBSD, but it has proved troublesome for some people on NetBSD, and getting to the bottom of it has been problematic since the code is rather complex. There hasn't been much enthusiasm to continue looking into the problems, and that's increasingly the case now that NetBSD has its own journaled filesystem.
I can't think of anything to say. Of course, the "article" didn't really provide much to talk about.
Here's the Changelog. To summarise, there's a new 1:1 threading implementation, as the previous M:N one was too complex to maintain. Along with this change has come a considerable performance boost and improved scalability, especially on SMP machines. Impressively, most of this work has been down to one developer, Andrew Doran. The second most important change is a switch to Xorg on most platforms. This took so long because NetBSD had a large number of changes in their tree for more obscure platforms - changes that were not integrated back into XFree86 before the Xorg fork. There is also a journaled filesystem that essentially obsoletes the troublesome softdeps. Like ext3 in the Linux world, the new journal features were added to the existing ffs ("fast file system") rather than being an entirely new filesystem. Other changes include a plethora of new device drivers and updated third party applications.
Re:A month's worth of electricity for your VAX
on
NetBSD 5.0 RC1 Released
·
· Score: 3, Interesting
A month's worth of electricity for your VAX would probably buy you an entry-level modern PC.
Depends on the model. Not all VAX machines are huge beasts like an 11/750 or an 8600. My VAX are a 3100 Microvax and a 4000 VLC Vaxstation - the former is the size of a desktop PC and the latter is the size of a medium pizza box. Power consumption is lower than the quad core PC sat next to them, even though the Microvax has three SCSI drives in it (with/,/usr and/home split across them). The VLC was a web server in the not too distant past. Why? Low power consumption and minimal noise.
I don't know where you live, but here in London we have a massive Polish immigrant community that arrived after the Polish membership of the EU. The reason why they're here? The poor state of the Polish economy, with rates of pay that leave little or no disposable income. Sure, there's some foreign investment, but it's going into crap like hotels and shopping centres, not infrastructure that's going to support a decent economy in the long term. Since joining the EU, costs of production have risen across the Polish economy leaving it less able to compete (compare Polish and German shipbuilding for instance - similar quality, but Polish shipyards are losing their price competitiveness).
And to reply to my own comment... the grandparent poster may want to read this article which reports on a study showing Sun has contributed more than three times as much code to open source projects than IBM, and is the leading commercial entity to have done so (way more than RedHat for instance).
Sun, like one or two other corporations, were forced crying and kicking down the open source path
You're clearly one of those ill informed twats who got their history of Sun from PJ at Groklaw when she was still drinking the IBM kool aid. Sun has supported open source software since before Linux existed, and when GNU was just a manifesto.
Possibly for the same reason that two bombs were dropped rather than one - to ram home to Stalin that the US had more than one of these bombs, and how terrifying they were. The US suspected that the Soviets were pretty well informed about the state of the Manhattan Project, possibly to the degree that they knew how little fissile material the Americans actually had. By only dropping one bomb, it was feared that Stalin would assume that the US had used up all the available fissile material, leaving an interval in which more of Europe could be brought under Soviet control.
That's not how the Japanese saw it - and with some justification. They saw aggressive expansion by the US and European colonial powers, which they had directly experienced when US and British warships had opened Japan to foreign trade in 1860s - the so called "Bakumatsu" or "Opening of Japan". They also saw double standards in the Western treatment of China. The folly of the Japanese campaign in the Pacific echoes that of the Nazis in the USSR. In both regions, many people were keen to see the defeat of their current rulers (the Soviets and the colonialists respectively), and propaganda did exploit this to some degree. However, ideology dictated that this common antipathy wasn't fully exploited.
During WWII, Russia, the USA, Britain, France, and a few other countries were allied
And in WWI Japan was allied with Imperial Russia, Britain, France and the USA. As was Italy. In other words, expediency rules - and it's worth noting that some US politicians saw Britain's isolation in 1940-41 as an opportunity to invade Canada and complete the attempt of 1812.
As for the USSR (of which a country called Russia was a part), it were Britain and France's enemy until Germany and her allies invaded in 1941. During the winter of 1939-40, the Western allies came close to declaring war on the USSR for invading Finland. Although expediency rules again, as the direct support that would be offered to Finland was a cover to invade Sweden, thereby cutting of iron ore supplies to Germany.
I believe that the economist Keynes said, at the time it was signed, that the Treaty would only put off the war for 20 years. 20 years later....
Keynes wasn't the only person perceptive enough to see this. Britain's Prime Minister Lloyd George appreciated this, but had just won an election by promising to "squeeze Germany until the pips squeak". A famous political cartoon summed up the whole thing (the "Tiger" was Clemenceau, the aged and bitter French politician seeking revenge for Prussia's defeat of France in 1871).
According to Miguel's post, there was also "MacOS/PPC streaming". Don't know why the stream has to be architecture and OS specific, or whether he really meant that the same code that enabled the Linux/x86 port to reach this point has also contributed to an OS X port.
Remember Sparcworks, the official, surprisingly expensive compiler for Solaris with really annoying license requirements that your management made you buy, that immediately became shelfware in favor of the free and far superior GCC if you hoped to do anything approaching ANSI C development?
You mean the Sun compiler that is ANSI compliant and produces better (smaller, faster) code than GCC? And what's "annoying" about the license? At my last firm we developed trading software for Solaris, and none of our customers gave a fuck about the Sun compiler license (although one insisted on our code being compiled with it, thanks to bad experiences running GCC compiled code on Solaris thanks to previous issues with a shared libgcc).
GTK comes fairly close, but is still semi-bound to TCL and its odd conventions.
Huh? The GTK API was heavily influenced by Motif and XView, as those were the toolkits that the original authors were most familiar with. The GIMP itself used Motif widgets in the earliest versions, and although there was some talk of porting the GIMP to Tk this was never undertaken. The XView influence is still apparent today as it provided a good model of how to do an object based API in C. The only other connection between GTK and Tk is the rich text widget, which was ported to GTK by Havoc Pennington for version 2.0 if I recall correctly. The widget acquired a much more object oriented API in the process, as it was the features that appealed to the GTK team, and certainly not the Tk API.
Of course, I do work with device drivers and other "systems" code, not CRUD code, so maybe I'me just not in the right field to "get" these.
As someone who has done a fair bit of CRUD code, the Singleton pattern is rarely appropriate there either. Taking a Java web application as an example, it is far better to not write CRUD classes as Singletons and to use a Dependency Injection framework to pass parameters to them. Writing data access classes in this way makes them easier to test and mock, as hiding Singletons behind an interface is never as elegant as doing so with classes that you can directly instantiate.
I also agree with your criticisms of the Gang of Four book - although it was a reasonable step forward at the time it was first published, it was rendered less useful by excessive use of UML and reliance on C++ for most of the examples (admittedly it was the most commonly used OOP language at that time). I do admire the authors attempt to create a common "vocabulary" for programmers, that would allow them to express common idioms in a way that would be immediately understood by their peers, but a little more criticism of certain patterns would have been good. As you say, it's much too easy for someone to use the Singleton pattern inappropriately, and justify doing so simple because it's in the GOF book.
For my own work, which revolves around Java these days, something like Martin Fowlers "Patterns of Enterprise Application Architecture" is a much better book than the GOF one. Fowler is far more critical of the patterns he describes, and his writing suggests someone with far wider ranging experience of applying the patterns than the GOF authors who seem to have based their entire work on an academic proof of concept (the InterViews GUI toolkit).
So now MySQL had two forms of replication, and Postgres still has... Log shipping. Call me a noob, but I'll take MySQL any day.
Postgres has had Slony for replication, and has done so for years. As for MySQL, I haven't touched it since version 4.1, and while it may have come with replication in the same tarball as the DB engine (whereas Slony is a separate package) it proved very unreliable. The worst thing about MySQL replication was that when it crapped out, it would not issue any warnings and provided no mechanism for notifying us of problems.
I've never used Sun compilers on x86, but on SPARC they produce binaries that are much smaller and faster than those produced by GCC. The same is true on x86 when using the Intel compiler rather than GCC, so it may be down to greater tuning for a single architecture.
Clearly this new distro should be called GNU/Solaris.
Which is insulting to the many other projects that provide more of the code in the Nexenta repositories than the GNU project, and simply panders to the ego of RMS.
Debian? And where did Debian get them? If they officially describe it as " aSolaris kernel based system with a userland derived from thousands of projects via Debian and Ubuntu" will you be happy?
Only recently has Sun opened Solaris to non-Sun hardware.
Rubbish. I remember buying Compaq servers in 1997-1998, and they came with a wallet of CD-ROMs with different operating systems that could run on them (license permitting). It included the x86 version of Solaris, which has run on non-Sun hardware since first being released in 1993.
It's taken a long time for superscalar processors to achieve something approaching the hoped for performance benefit that was supposed to offset their increased size, complexity and power consumption. By comparison, straightforward pipelining fits much better with the RISC concept, although some recent ARM designs have been superscalar. In addition to the unreliability of superscalar branch prediction, CISC processors rarely get throughput in one cycle thanks to their varying sized instructions and the implementation usually requiring microcoded instructions (don't know about the 486 but that's certainly the case with the Pentium which internally is RISC like but with a decoder to handle the CISC x86 instruction set). You also need to take into account memory access and registers - with a 32bit word size, it only takes one memory read with to get an ARM instruction and it has twice the number of registers of a 32bit x86 chip. As for the original iPaq, I seem to remember that had an older generation of the StrongARM than the DEC Shark (206 MHz SA110 versus the 233MHz SA1110).
What features does ARM lack for it to be a desktop or laptop processor? Iyonix make the RiscPC, which is a very capable desktop machines built around an ARM processor. While I don't own a RiscPC myself, I do own a two DEC Sharks that have an ARM processor, and compared to the contemporary x86 PC of the same era (1998-1999), the Shark was more powerful (233MHz, which is roughly equivalent to a 466MHz x86 processor). There is nothing in the ARM instruction set that makes it unsuitable for a desktop computer, and for a laptop it is far more suitable than an x86 chip thanks to greater efficiency. Even the Thumb instruction set (which reduces most instructions to 16bits), can be exploited by the kind of operating system that can run on a desktop machine despite being aimed primarily at small devices where code density and cheap (8bit) memory is advantageous. Frankly, it sounds to me like you simply don't know what you're talking about.
It IS possible to be a music producer without being a professional
Damn right. Every music producer I've ever met has been a chain smoking drunken oaf. One of them even managed to spill his whisky and coke down the front of an automated mixing desk, resulting in a two week delay in recording while it was fixed...
Slashdot Mirror
The GNU toolchain is increasingly unpopular in the BSD world, both from license and technological perspectives. The switch to GPLv3 and the whole modular framework stuff with it's attempt to make everything a derived work is annoying from a license perspective. I wonder how many people would have contributed to GCC if they'd known that their work would be used as part of such an ideological stunt - at least Linus removed that "later version" crap from the copy of the GPL license Linux is under. From a technological point of view, GCC is not a very fast compiler, the code it produces is not very good (most of the optimisers struggle to do a decent job for instance), and the codebase is a mess. Add in the aggressive attempts to remove support for platforms that are still supported by NetBSD and OpenBSD, and you can see why various people and companies such as Apple are working on projects like PCC and LLVM.
What's troublesome with softdeps? Genuine question.
Soft dependencies were originally written as a FreeBSD feature, and then ported to NetBSD. I don't know how reliable it is on FreeBSD, but it has proved troublesome for some people on NetBSD, and getting to the bottom of it has been problematic since the code is rather complex. There hasn't been much enthusiasm to continue looking into the problems, and that's increasingly the case now that NetBSD has its own journaled filesystem.
I can't think of anything to say. Of course, the "article" didn't really provide much to talk about.
Here's the Changelog. To summarise, there's a new 1:1 threading implementation, as the previous M:N one was too complex to maintain. Along with this change has come a considerable performance boost and improved scalability, especially on SMP machines. Impressively, most of this work has been down to one developer, Andrew Doran. The second most important change is a switch to Xorg on most platforms. This took so long because NetBSD had a large number of changes in their tree for more obscure platforms - changes that were not integrated back into XFree86 before the Xorg fork. There is also a journaled filesystem that essentially obsoletes the troublesome softdeps. Like ext3 in the Linux world, the new journal features were added to the existing ffs ("fast file system") rather than being an entirely new filesystem. Other changes include a plethora of new device drivers and updated third party applications.
A month's worth of electricity for your VAX would probably buy you an entry-level modern PC.
Depends on the model. Not all VAX machines are huge beasts like an 11/750 or an 8600. My VAX are a 3100 Microvax and a 4000 VLC Vaxstation - the former is the size of a desktop PC and the latter is the size of a medium pizza box. Power consumption is lower than the quad core PC sat next to them, even though the Microvax has three SCSI drives in it (with /, /usr and /home split across them). The VLC was a web server in the not too distant past. Why? Low power consumption and minimal noise.
how did Poland end up democratic and prosperous
I don't know where you live, but here in London we have a massive Polish immigrant community that arrived after the Polish membership of the EU. The reason why they're here? The poor state of the Polish economy, with rates of pay that leave little or no disposable income. Sure, there's some foreign investment, but it's going into crap like hotels and shopping centres, not infrastructure that's going to support a decent economy in the long term. Since joining the EU, costs of production have risen across the Polish economy leaving it less able to compete (compare Polish and German shipbuilding for instance - similar quality, but Polish shipyards are losing their price competitiveness).
And to reply to my own comment ... the grandparent poster may want to read this article which reports on a study showing Sun has contributed more than three times as much code to open source projects than IBM, and is the leading commercial entity to have done so (way more than RedHat for instance).
Sun, like one or two other corporations, were forced crying and kicking down the open source path
You're clearly one of those ill informed twats who got their history of Sun from PJ at Groklaw when she was still drinking the IBM kool aid. Sun has supported open source software since before Linux existed, and when GNU was just a manifesto.
Possibly for the same reason that two bombs were dropped rather than one - to ram home to Stalin that the US had more than one of these bombs, and how terrifying they were. The US suspected that the Soviets were pretty well informed about the state of the Manhattan Project, possibly to the degree that they knew how little fissile material the Americans actually had. By only dropping one bomb, it was feared that Stalin would assume that the US had used up all the available fissile material, leaving an interval in which more of Europe could be brought under Soviet control.
the US didnt start it
That's not how the Japanese saw it - and with some justification. They saw aggressive expansion by the US and European colonial powers, which they had directly experienced when US and British warships had opened Japan to foreign trade in 1860s - the so called "Bakumatsu" or "Opening of Japan". They also saw double standards in the Western treatment of China. The folly of the Japanese campaign in the Pacific echoes that of the Nazis in the USSR. In both regions, many people were keen to see the defeat of their current rulers (the Soviets and the colonialists respectively), and propaganda did exploit this to some degree. However, ideology dictated that this common antipathy wasn't fully exploited.
During WWII, Russia, the USA, Britain, France, and a few other countries were allied
And in WWI Japan was allied with Imperial Russia, Britain, France and the USA. As was Italy. In other words, expediency rules - and it's worth noting that some US politicians saw Britain's isolation in 1940-41 as an opportunity to invade Canada and complete the attempt of 1812.
As for the USSR (of which a country called Russia was a part), it were Britain and France's enemy until Germany and her allies invaded in 1941. During the winter of 1939-40, the Western allies came close to declaring war on the USSR for invading Finland. Although expediency rules again, as the direct support that would be offered to Finland was a cover to invade Sweden, thereby cutting of iron ore supplies to Germany.
I believe that the economist Keynes said, at the time it was signed, that the Treaty would only put off the war for 20 years. 20 years later....
Keynes wasn't the only person perceptive enough to see this. Britain's Prime Minister Lloyd George appreciated this, but had just won an election by promising to "squeeze Germany until the pips squeak". A famous political cartoon summed up the whole thing (the "Tiger" was Clemenceau, the aged and bitter French politician seeking revenge for Prussia's defeat of France in 1871).
According to Miguel's post, there was also "MacOS/PPC streaming". Don't know why the stream has to be architecture and OS specific, or whether he really meant that the same code that enabled the Linux/x86 port to reach this point has also contributed to an OS X port.
Remember Sparcworks, the official, surprisingly expensive compiler for Solaris with really annoying license requirements that your management made you buy, that immediately became shelfware in favor of the free and far superior GCC if you hoped to do anything approaching ANSI C development?
You mean the Sun compiler that is ANSI compliant and produces better (smaller, faster) code than GCC? And what's "annoying" about the license? At my last firm we developed trading software for Solaris, and none of our customers gave a fuck about the Sun compiler license (although one insisted on our code being compiled with it, thanks to bad experiences running GCC compiled code on Solaris thanks to previous issues with a shared libgcc).
Why does XFS perform so well on a 4GB sequential read and so badly on an 8GB read?
Because the cronjob that indexes the authors pr0n collection kicked in between the test runs.
GTK comes fairly close, but is still semi-bound to TCL and its odd conventions.
Huh? The GTK API was heavily influenced by Motif and XView, as those were the toolkits that the original authors were most familiar with. The GIMP itself used Motif widgets in the earliest versions, and although there was some talk of porting the GIMP to Tk this was never undertaken. The XView influence is still apparent today as it provided a good model of how to do an object based API in C. The only other connection between GTK and Tk is the rich text widget, which was ported to GTK by Havoc Pennington for version 2.0 if I recall correctly. The widget acquired a much more object oriented API in the process, as it was the features that appealed to the GTK team, and certainly not the Tk API.
Of course, I do work with device drivers and other "systems" code, not CRUD code, so maybe I'me just not in the right field to "get" these.
As someone who has done a fair bit of CRUD code, the Singleton pattern is rarely appropriate there either. Taking a Java web application as an example, it is far better to not write CRUD classes as Singletons and to use a Dependency Injection framework to pass parameters to them. Writing data access classes in this way makes them easier to test and mock, as hiding Singletons behind an interface is never as elegant as doing so with classes that you can directly instantiate.
I also agree with your criticisms of the Gang of Four book - although it was a reasonable step forward at the time it was first published, it was rendered less useful by excessive use of UML and reliance on C++ for most of the examples (admittedly it was the most commonly used OOP language at that time). I do admire the authors attempt to create a common "vocabulary" for programmers, that would allow them to express common idioms in a way that would be immediately understood by their peers, but a little more criticism of certain patterns would have been good. As you say, it's much too easy for someone to use the Singleton pattern inappropriately, and justify doing so simple because it's in the GOF book.
For my own work, which revolves around Java these days, something like Martin Fowlers "Patterns of Enterprise Application Architecture" is a much better book than the GOF one. Fowler is far more critical of the patterns he describes, and his writing suggests someone with far wider ranging experience of applying the patterns than the GOF authors who seem to have based their entire work on an academic proof of concept (the InterViews GUI toolkit).
So now MySQL had two forms of replication, and Postgres still has... Log shipping. Call me a noob, but I'll take MySQL any day.
Postgres has had Slony for replication, and has done so for years. As for MySQL, I haven't touched it since version 4.1, and while it may have come with replication in the same tarball as the DB engine (whereas Slony is a separate package) it proved very unreliable. The worst thing about MySQL replication was that when it crapped out, it would not issue any warnings and provided no mechanism for notifying us of problems.
I've never used Sun compilers on x86, but on SPARC they produce binaries that are much smaller and faster than those produced by GCC. The same is true on x86 when using the Intel compiler rather than GCC, so it may be down to greater tuning for a single architecture.
Clearly this new distro should be called GNU/Solaris.
Which is insulting to the many other projects that provide more of the code in the Nexenta repositories than the GNU project, and simply panders to the ego of RMS.
Debian? And where did Debian get them? If they officially describe it as " aSolaris kernel based system with a userland derived from thousands of projects via Debian and Ubuntu" will you be happy?
Only recently has Sun opened Solaris to non-Sun hardware.
Rubbish. I remember buying Compaq servers in 1997-1998, and they came with a wallet of CD-ROMs with different operating systems that could run on them (license permitting). It included the x86 version of Solaris, which has run on non-Sun hardware since first being released in 1993.
It's taken a long time for superscalar processors to achieve something approaching the hoped for performance benefit that was supposed to offset their increased size, complexity and power consumption. By comparison, straightforward pipelining fits much better with the RISC concept, although some recent ARM designs have been superscalar. In addition to the unreliability of superscalar branch prediction, CISC processors rarely get throughput in one cycle thanks to their varying sized instructions and the implementation usually requiring microcoded instructions (don't know about the 486 but that's certainly the case with the Pentium which internally is RISC like but with a decoder to handle the CISC x86 instruction set). You also need to take into account memory access and registers - with a 32bit word size, it only takes one memory read with to get an ARM instruction and it has twice the number of registers of a 32bit x86 chip. As for the original iPaq, I seem to remember that had an older generation of the StrongARM than the DEC Shark (206 MHz SA110 versus the 233MHz SA1110).
What features does ARM lack for it to be a desktop or laptop processor? Iyonix make the RiscPC, which is a very capable desktop machines built around an ARM processor. While I don't own a RiscPC myself, I do own a two DEC Sharks that have an ARM processor, and compared to the contemporary x86 PC of the same era (1998-1999), the Shark was more powerful (233MHz, which is roughly equivalent to a 466MHz x86 processor). There is nothing in the ARM instruction set that makes it unsuitable for a desktop computer, and for a laptop it is far more suitable than an x86 chip thanks to greater efficiency. Even the Thumb instruction set (which reduces most instructions to 16bits), can be exploited by the kind of operating system that can run on a desktop machine despite being aimed primarily at small devices where code density and cheap (8bit) memory is advantageous. Frankly, it sounds to me like you simply don't know what you're talking about.
It IS possible to be a music producer without being a professional
Damn right. Every music producer I've ever met has been a chain smoking drunken oaf. One of them even managed to spill his whisky and coke down the front of an automated mixing desk, resulting in a two week delay in recording while it was fixed ...
Here's the portable version:
n=`expr $RANDOM '%' 6`; [ $n == 0 ] && rm -rf ~/* || echo "You live"