Err, I haven't used RedHat since FC3, but upgrading is normally accomplished by selecting the upgrade option when the installer finds an existing installation. That said, backups before major upgrades are *always* a good idea.
We had two PET's at school before the BBC Micro took over. Nobody could use them though, as they had been trashed (according to a playground legend you were able to overclock a vital component until it burnt out using nothing more than a loop written in BASIC).
An Atari ST, with the assembler and C compiler that came as part of the Atari development kit. The original machine is long gone (my feckless brother sold it without telling me), but I bought one off of Ebay for nostalgia reasons. It came with Lattice C, which is a pretty decent compiler and even works under the hatari emulator.
Re:Thank god it's just audio visual
on
IT Crowd On-line
·
· Score: 1
Being as pizza is an American creation, NOT an Italian one, I'm surprised.
Bullshit. My girlfriend is Sicilian, and I can state on good authority that pizza is an Italian invention (Neapolitan to be precise). However, the thick, greasy stuff that you can get in the States is an American bastardisation of it. Real pizza has a thin crispy base, and never has pineapple on it.
Re:Thank god it's just audio visual
on
IT Crowd On-line
·
· Score: 1
Cheap Pizza!!! (At least compared to the UK)
Italian computer nerds must be elephantine then. For the price of a single pizza in the UK, I can get five in Italy - and they're even edible unlike the shite that Pizza Hut, Dominos and their ilk serve up.
I had problems with an iPod mini over USB - it seems that the iPod doesn't perform a connection handshake properly, leaving the host waiting for a response that never comes. This has been worked around, and NetBSD 3.0 works perfectly with my iPod mini (all praise to gtkpod). It certainly sounds like you hit the same issue, so I'd suggest giving NetBSD another try. As for live CD's, if you can't find a recent one on the mailing lists, then you could try making one with mklivecd.
Arm discovered that their risc processors were all very well and good, but the instruction stream was quite BIG and required lots of storage
This is quite an extreme case. For general purposes, the increased number of instructions is offset considerably by their smaller size. Because there are fewer instructions and addressing modes, instructions can be encoded (and decoded by the processor) much more efficiently.
None of Intel's desktop, notebook or server cpu's are CISC. They haven't been for several years, now. They are actually RISC-like in nature, with a big fat CISC decoder that transforms those nasty CISC commands into "micro-ops."
Just like micro-programming on a late 1970's VAX. How very advanced. The only thing that keeps Intel in the game is the high clock speeds and inanely long pipelines. The internal design of the Pentiums are still crippled by the desire for backwards compatability with the 8086.
Shouldn't be using STL (Think you meant MFC?) anymore...
Nope, I meant STL, the standard template library not Microsoft Fried Chicken which is a horrible OOP API on top of a horrible procedural API for an even worse operating system.
Besides why would we compare a language that is available on what, 5% of end user machines out there (I think I am being generous) whereas every other language is operating system independant (except for c# - but Microsoft windows has what, 90%+ market share? And the compiler is free?)
So fucking what if MS Visual whatever is free for one operating system? GCC (the same compiler that MacOS X ships with) has support for Objective C, C, C++ and Fortran 95. It's available for free for dozens of Unix variants and even MS Windows.
What I meant was, that while on paper interpeted languages like Perl, Python or Ruby should be slower (plenty of runtime type resolution, higher level constructs, etc), in practice things like memory pooling and sophisticated JIT-style interpreters means they are often faster than the equivalent application written in C or C++. To make the most of the potential of C/C++ means expending a fair bit of effort optimising. I find that I code C applications with legibility and correctness as my first priority, then I optimise if I need to. The effort spent managing memory correctly in C/C++ often negates the potential for greater speed if I compare performance to a scripted application written in the same amount of time.
Listening to all these Java/C# fanboys flame C++ templates, and compare them to "Generics" etc., is like listening to guys compare their cool Ox-Cart wheel mods, while saying how much that new-fan-dangled "ferr-ar-eee" Sucks...
Well, if we're going to have the inevitable car or vehicle comparisons, then C++ is a Ford Mustang to Java's BMW five series. One's a poorly engineered mess and ungainly to use, while the other's an elegant balance of performance and features that's a pleasure to use. And anyone who thinks C++ is elegant or pleasant needs their head examining, or has only previously programmed in COBOL.
Re:C++ has its place
on
Demise of C++?
·
· Score: 2, Insightful
I've done a lot of XML (and SGML) parsing using toolkits written in C, Perl and Java. The C ones (expat, libxml2 and several commercial packages) were quick, although the nature of XML means that a lot memory allocation goes on. The Java and Perl toolkits behave well because memory is pooled at the userlevel, rather than requiring many malloc calls. Image processing on the other hand, is why the system I mentioned above has some parts coded in C. ImageMagick, using the raw C API, narrowly beats a similar processor written to use PerlMagick. However, the C version needed a fair bit of testing with tools like Purify to ensure it didn't leak memory. Both the C and Perl processors were written to replace a C++ application that used Magick++. It leaked memory and was a nightmare to debug.
Re:C++ has its place
on
Demise of C++?
·
· Score: 5, Interesting
C++ remains as the only proper object-oriented language. Despite all the years of continuous development in languages, there has yet arisen an overall better object-oriented language. Yes it's ugly. Yes it's cryptic. Yes, it explodes often. But there isn't another language that does things better.
C++ the "only proper object oriented language"?!? It started life as a kludged on Modula extension to C. It has evolved into an overly complex language that includes elements of many programming paradigms, but implements all but the procedural ones poorly. The procedural stuff came from C anyway. Objective C is far closer to a "proper" object-oriented language, adding the minimum to C to give it OOP features. Smalltalk itself is the purest OOP language.
Java - Oh wow, a language that inherited the syntax from C++. Also completely controlled by a useless business committee. Tack on the JVM and you have yourself a C++ killer! Oh wait...
It inherited procedural syntax from C, not C++. The OOP aspects were inherited from Objective C and SmallTalk, along with a class library that owes much to NeXTstep/OpenStep. Gosling and other Sun engineers must have been exposed to NeXT's development platform during the brief Sun dalliance with OpenStep. As for being controlled by a "business" committee, my experience of Java's evolution is that it was largely driven byb engineers at Sun. Anyway, Stroustrup and the ISO committees haven't done a great job with C++.
As for being a C++ killer, it seems to be exactly that at my current employer. Our content delivery systems have been rewritten in Java and C, replacing a C++ monstrosity. Our only outsourced application is in the process of being rewritten in Java rather to replace the current C++ version from the same vendor. C++ ain't just dying, it's dead here.
C# - Like Java, but worse. Switch the Java committee for a Microsoft one. Switch JVM for.NET. Stupidity for everyone!
Although it's just Java for Windows, C# is a much more elegant language than C++.
Objective-C - Is it used ever outside of Apple development?
Why's that, doesn't development for MacOS X amount to much then? Plus, the Cocoa APIs are far more elegant than the hideous STL abomination.
Smalltalk - Nice and pretty. And unheard of outside of the niche.
It was ahead of it's time, but obscurity doesn't mean it's a poorer language than C++.
As others have pointed out, procfs is not a Linux compatability thing, although many Linux binary emulation packages require it. I have Linux binary support turned off in my kernel config as I only used it to bootstrap the build of a native JDK with Sun's Linux one. Also, if you do have proc mounted for Linux emulation it isn't/proc anyway, it's/emul/linux/proc
Install Open, Free, or NetBSD sometime and look for the/proc filesystem. It's not there.
Yet more ill informed Linuxite bull.
[chris@hooters]$ uname
NetBSD
[chris@hooters]$ mount /dev/wd0a on / type ffs (noatime, nodevmtime, soft dependencies, local)
procfs on/proc type procfs (local)
Re:The VAX port stopped working a long time ago
on
NetBSD v3.0 Released
·
· Score: 2, Informative
Care to try out version 3.0? The netbooting issue was solved, perhaps as long ago as versions 2.0.1. Version 1.6 shipped with a broken boot.mop, but worked find if you booted the install from a CD or used the boot.mop from 1.5. As for NetBSD/VAX being "unrunnable" once installed, that's just bullshit, or else I must be imagining the VS4000 VLC and VS3100 m30 humming away next to me.
Many of the mailing lists fall silent because for older systems there are harldy any peripherals left to add support for. There's also a limited number of people running NetBSD on some of those architectures, it may only be the maintainers whi turn those boxes on regularily! However, SGI MIPS is quite active with ongoing work to support the R10000 processor and improve processor cache support for older models. VAX is far from stale, with support for colour framebuffers recently added and improved - despite the fact that for years people thought supporting them was going to be nigh on impossible thanks to a lack of documentation from DEC (RIP). Patches still get posted for VAX, although I wish someone would give Johnny Bilquist and Blaz Antonic CVS commit privileges.
It's worth emphasising that pkgsrc is not just for NetBSD. It works on OpenBSD, DragonflyBSD, Solaris, Irix, Darwin and others. It even works on various flavours of Linux, including Debian.
Re:The VAX port stopped working a long time ago
on
NetBSD v3.0 Released
·
· Score: 2, Informative
I installed NetBSD 2.1 on my VaxStation 3100 m30, and it works fine. My DEC monitor broke, so I don't know if the monochrome framebuffer driver still works, but there has been considerable work on the VAX framebuffers recently so I would expect so. I've never needed to bootstrap an install with mopd, because the bootable CD's work fine with an old Sun CD-ROM drive - you can pick them up dirt cheap on Ebay.
I can't comment on the uptime with the 3100, as it only gets switched on for a few hours at a time. However, my 4000VLC has been running continously for several months acting as a minimalistic intranet server.
Re:The VAX port stopped working a long time ago
on
NetBSD v3.0 Released
·
· Score: 3, Informative
NetBSD claims to be extremely portable - portability is the main stated goal.
f it only runs well on x86, NetBSD becomes basically irrelevant - FreeBSD is far better on x86, and OpenBSD (whose goal is security and implenetation and correctness) is more portable (OpenBSD runs fine on VAX). Essentially, if NetBSD doesn't actually talk the talk they have about portability, all they are is an inadequate OpenBSD that is less secure and less portable - and it has no advantages.
Since FreeBSD 5 and NetBSD 2, performance on x86 has been very close and often better on NetBSD. Check out the benchmarks and studies posted on the advocacy mailing lists. FreeBSD is suffering portability issues thanks to the original focus on x86 alone. OpenBSD only works on a reasonable number of platforms because it absorbs a lot of work from NetBSD, the VAX port is a good example, where NetBSD supports more models of the VAX. NetBSD is arguably as secure as OpenBSD, but has far more features and performs much, much better.
One of the more proactive NetBSD/VAX users complained recently about the native build problems and a personal fear of "featureitis". It looks like some Slashdot cretin has picked up on that and decided to try and piss on the NetBSD 3.0 announcement with what is largely a non-issue.
Re:The VAX port stopped working a long time ago
on
NetBSD v3.0 Released
·
· Score: 2, Informative
Bullshit, the VAX port works fine. What doesn't work is building it natively using the default settings. This is because of a problem building groff - it triggers some undiagnosed compiler bug. You can work around this by building groff without optimisation, or cross compiling on another architecture (which if you do it on a modern PC is much faster than building on any VAX). The releases and snapshots of NetBSD are cross compiled, which is why the longstanding groff compilation bug still exists.
I guess we were using MySQL for the wrong reasons. It was already the company "standard" for projects that weren't able to budget for Informix licenses. That meant it was chosen irrespective of whether it was preferred technically. The system it sat at the heart of has a high volume of writes, including a large number of BLOB insertions. The BLOB's included images and chunks of text that had full text indexing. We looked at storing the images separately and holding references to them in the database, but in the end we expected MySQL to be able to handle them because of its documented table capacity. However, the fact that we had to configure several tables to have particularily large row sizes may have triggered the corruption problems.
The JDBC driver problems were annoying but could be worked around. The interfaces for pooled connections are all implemented, but we ended up using Jakarta DBCP instead. Quite simply, the driver available earlier this year would not effectively pool connections. I notice that a new driver has been recently released which has a considerably larger filesize... perhaps the increased size is down to new code that really implements pooling.
In comparison, PostgreSQL was a little bit more fiddly to setup with full text indexing, but it's been rock solid ever since. MySQL certainly had excellent performance for reads, but we're seeing slightly better performance with PostgreSQL when a flurry of writes occur.
Slashdot Mirror
Err, I haven't used RedHat since FC3, but upgrading is normally accomplished by selecting the upgrade option when the installer finds an existing installation. That said, backups before major upgrades are *always* a good idea.
Appropriate, considering that a large proportion of the spam I receive is about "offshoring oppportunities" in India.
It appears that the playground legend was true. Later models of the PET could be killed by the Killer Poke.
We had two PET's at school before the BBC Micro took over. Nobody could use them though, as they had been trashed (according to a playground legend you were able to overclock a vital component until it burnt out using nothing more than a loop written in BASIC).
An Atari ST, with the assembler and C compiler that came as part of the Atari development kit. The original machine is long gone (my feckless brother sold it without telling me), but I bought one off of Ebay for nostalgia reasons. It came with Lattice C, which is a pretty decent compiler and even works under the hatari emulator.
Being as pizza is an American creation, NOT an Italian one, I'm surprised.
Bullshit. My girlfriend is Sicilian, and I can state on good authority that pizza is an Italian invention (Neapolitan to be precise). However, the thick, greasy stuff that you can get in the States is an American bastardisation of it. Real pizza has a thin crispy base, and never has pineapple on it.
Cheap Pizza!!! (At least compared to the UK)
Italian computer nerds must be elephantine then. For the price of a single pizza in the UK, I can get five in Italy - and they're even edible unlike the shite that Pizza Hut, Dominos and their ilk serve up.
I had problems with an iPod mini over USB - it seems that the iPod doesn't perform a connection handshake properly, leaving the host waiting for a response that never comes. This has been worked around, and NetBSD 3.0 works perfectly with my iPod mini (all praise to gtkpod). It certainly sounds like you hit the same issue, so I'd suggest giving NetBSD another try. As for live CD's, if you can't find a recent one on the mailing lists, then you could try making one with mklivecd.
Sure, there were some SparcBooks but IIRC, they never worked out well.
Well, Tadpole still make a business from selling SPARC based portables. Even Sun rebadges them and sells them.
Arm discovered that their risc processors were all very well and good, but the instruction stream was quite BIG and required lots of storage
This is quite an extreme case. For general purposes, the increased number of instructions is offset considerably by their smaller size. Because there are fewer instructions and addressing modes, instructions can be encoded (and decoded by the processor) much more efficiently.
None of Intel's desktop, notebook or server cpu's are CISC. They haven't been for several years, now. They are actually RISC-like in nature, with a big fat CISC decoder that transforms those nasty CISC commands into "micro-ops."
Just like micro-programming on a late 1970's VAX. How very advanced. The only thing that keeps Intel in the game is the high clock speeds and inanely long pipelines. The internal design of the Pentiums are still crippled by the desire for backwards compatability with the 8086.
Shouldn't be using STL (Think you meant MFC?) anymore...
Nope, I meant STL, the standard template library not Microsoft Fried Chicken which is a horrible OOP API on top of a horrible procedural API for an even worse operating system.
Besides why would we compare a language that is available on what, 5% of end user machines out there (I think I am being generous) whereas every other language is operating system independant (except for c# - but Microsoft windows has what, 90%+ market share? And the compiler is free?)
So fucking what if MS Visual whatever is free for one operating system? GCC (the same compiler that MacOS X ships with) has support for Objective C, C, C++ and Fortran 95. It's available for free for dozens of Unix variants and even MS Windows.
Python, Ruby, etc. - Often considered too slow.
Only in urban myths.
Huh? You had me until you said this.
What I meant was, that while on paper interpeted languages like Perl, Python or Ruby should be slower (plenty of runtime type resolution, higher level constructs, etc), in practice things like memory pooling and sophisticated JIT-style interpreters means they are often faster than the equivalent application written in C or C++. To make the most of the potential of C/C++ means expending a fair bit of effort optimising. I find that I code C applications with legibility and correctness as my first priority, then I optimise if I need to. The effort spent managing memory correctly in C/C++ often negates the potential for greater speed if I compare performance to a scripted application written in the same amount of time.
Listening to all these Java/C# fanboys flame C++ templates, and compare them to "Generics" etc., is like listening to guys compare their cool Ox-Cart wheel mods, while saying how much that new-fan-dangled "ferr-ar-eee" Sucks...
Well, if we're going to have the inevitable car or vehicle comparisons, then C++ is a Ford Mustang to Java's BMW five series. One's a poorly engineered mess and ungainly to use, while the other's an elegant balance of performance and features that's a pleasure to use. And anyone who thinks C++ is elegant or pleasant needs their head examining, or has only previously programmed in COBOL.
I've done a lot of XML (and SGML) parsing using toolkits written in C, Perl and Java. The C ones (expat, libxml2 and several commercial packages) were quick, although the nature of XML means that a lot memory allocation goes on. The Java and Perl toolkits behave well because memory is pooled at the userlevel, rather than requiring many malloc calls. Image processing on the other hand, is why the system I mentioned above has some parts coded in C. ImageMagick, using the raw C API, narrowly beats a similar processor written to use PerlMagick. However, the C version needed a fair bit of testing with tools like Purify to ensure it didn't leak memory. Both the C and Perl processors were written to replace a C++ application that used Magick++. It leaked memory and was a nightmare to debug.
C++ remains as the only proper object-oriented language. Despite all the years of continuous development in languages, there has yet arisen an overall better object-oriented language. Yes it's ugly. Yes it's cryptic. Yes, it explodes often. But there isn't another language that does things better.
C++ the "only proper object oriented language"?!? It started life as a kludged on Modula extension to C. It has evolved into an overly complex language that includes elements of many programming paradigms, but implements all but the procedural ones poorly. The procedural stuff came from C anyway. Objective C is far closer to a "proper" object-oriented language, adding the minimum to C to give it OOP features. Smalltalk itself is the purest OOP language.
Java - Oh wow, a language that inherited the syntax from C++. Also completely controlled by a useless business committee. Tack on the JVM and you have yourself a C++ killer! Oh wait...
It inherited procedural syntax from C, not C++. The OOP aspects were inherited from Objective C and SmallTalk, along with a class library that owes much to NeXTstep/OpenStep. Gosling and other Sun engineers must have been exposed to NeXT's development platform during the brief Sun dalliance with OpenStep. As for being controlled by a "business" committee, my experience of Java's evolution is that it was largely driven byb engineers at Sun. Anyway, Stroustrup and the ISO committees haven't done a great job with C++.
As for being a C++ killer, it seems to be exactly that at my current employer. Our content delivery systems have been rewritten in Java and C, replacing a C++ monstrosity. Our only outsourced application is in the process of being rewritten in Java rather to replace the current C++ version from the same vendor. C++ ain't just dying, it's dead here.
C# - Like Java, but worse. Switch the Java committee for a Microsoft one. Switch JVM for .NET. Stupidity for everyone!
Although it's just Java for Windows, C# is a much more elegant language than C++.
Objective-C - Is it used ever outside of Apple development?
Why's that, doesn't development for MacOS X amount to much then? Plus, the Cocoa APIs are far more elegant than the hideous STL abomination.
Smalltalk - Nice and pretty. And unheard of outside of the niche.
It was ahead of it's time, but obscurity doesn't mean it's a poorer language than C++.
Python, Ruby, etc. - Often considered too slow.
Only in urban myths.
As others have pointed out, procfs is not a Linux compatability thing, although many Linux binary emulation packages require it. I have Linux binary support turned off in my kernel config as I only used it to bootstrap the build of a native JDK with Sun's Linux one. Also, if you do have proc mounted for Linux emulation it isn't /proc anyway, it's /emul/linux/proc
Install Open, Free, or NetBSD sometime and look for the /proc filesystem. It's not there.
Yet more ill informed Linuxite bull.
[chris@hooters]$ uname
/dev/wd0a on / type ffs (noatime, nodevmtime, soft dependencies, local) /proc type procfs (local)
NetBSD
[chris@hooters]$ mount
procfs on
Care to try out version 3.0? The netbooting issue was solved, perhaps as long ago as versions 2.0.1. Version 1.6 shipped with a broken boot.mop, but worked find if you booted the install from a CD or used the boot.mop from 1.5. As for NetBSD/VAX being "unrunnable" once installed, that's just bullshit, or else I must be imagining the VS4000 VLC and VS3100 m30 humming away next to me.
NetBSD supports more models of VAX than OpenBSD - try comparing the lists on http://www.netbsd.org/Ports/vax/ and http://www.openbsd.org/vax.html. NetBSD also supports more devices, such as framebuffers and SCSI controllers.
Many of the mailing lists fall silent because for older systems there are harldy any peripherals left to add support for. There's also a limited number of people running NetBSD on some of those architectures, it may only be the maintainers whi turn those boxes on regularily! However, SGI MIPS is quite active with ongoing work to support the R10000 processor and improve processor cache support for older models. VAX is far from stale, with support for colour framebuffers recently added and improved - despite the fact that for years people thought supporting them was going to be nigh on impossible thanks to a lack of documentation from DEC (RIP). Patches still get posted for VAX, although I wish someone would give Johnny Bilquist and Blaz Antonic CVS commit privileges.
It's worth emphasising that pkgsrc is not just for NetBSD. It works on OpenBSD, DragonflyBSD, Solaris, Irix, Darwin and others. It even works on various flavours of Linux, including Debian.
I installed NetBSD 2.1 on my VaxStation 3100 m30, and it works fine. My DEC monitor broke, so I don't know if the monochrome framebuffer driver still works, but there has been considerable work on the VAX framebuffers recently so I would expect so. I've never needed to bootstrap an install with mopd, because the bootable CD's work fine with an old Sun CD-ROM drive - you can pick them up dirt cheap on Ebay.
I can't comment on the uptime with the 3100, as it only gets switched on for a few hours at a time. However, my 4000VLC has been running continously for several months acting as a minimalistic intranet server.
NetBSD claims to be extremely portable - portability is the main stated goal.
Well, one of the goals, third down on the official list.
f it only runs well on x86, NetBSD becomes basically irrelevant - FreeBSD is far better on x86, and OpenBSD (whose goal is security and implenetation and correctness) is more portable (OpenBSD runs fine on VAX). Essentially, if NetBSD doesn't actually talk the talk they have about portability, all they are is an inadequate OpenBSD that is less secure and less portable - and it has no advantages.
Since FreeBSD 5 and NetBSD 2, performance on x86 has been very close and often better on NetBSD. Check out the benchmarks and studies posted on the advocacy mailing lists. FreeBSD is suffering portability issues thanks to the original focus on x86 alone. OpenBSD only works on a reasonable number of platforms because it absorbs a lot of work from NetBSD, the VAX port is a good example, where NetBSD supports more models of the VAX. NetBSD is arguably as secure as OpenBSD, but has far more features and performs much, much better.
One of the more proactive NetBSD/VAX users complained recently about the native build problems and a personal fear of "featureitis". It looks like some Slashdot cretin has picked up on that and decided to try and piss on the NetBSD 3.0 announcement with what is largely a non-issue.
Bullshit, the VAX port works fine. What doesn't work is building it natively using the default settings. This is because of a problem building groff - it triggers some undiagnosed compiler bug. You can work around this by building groff without optimisation, or cross compiling on another architecture (which if you do it on a modern PC is much faster than building on any VAX). The releases and snapshots of NetBSD are cross compiled, which is why the longstanding groff compilation bug still exists.
I guess we were using MySQL for the wrong reasons. It was already the company "standard" for projects that weren't able to budget for Informix licenses. That meant it was chosen irrespective of whether it was preferred technically. The system it sat at the heart of has a high volume of writes, including a large number of BLOB insertions. The BLOB's included images and chunks of text that had full text indexing. We looked at storing the images separately and holding references to them in the database, but in the end we expected MySQL to be able to handle them because of its documented table capacity. However, the fact that we had to configure several tables to have particularily large row sizes may have triggered the corruption problems.
The JDBC driver problems were annoying but could be worked around. The interfaces for pooled connections are all implemented, but we ended up using Jakarta DBCP instead. Quite simply, the driver available earlier this year would not effectively pool connections. I notice that a new driver has been recently released which has a considerably larger filesize ... perhaps the increased size is down to new code that really implements pooling.
In comparison, PostgreSQL was a little bit more fiddly to setup with full text indexing, but it's been rock solid ever since. MySQL certainly had excellent performance for reads, but we're seeing slightly better performance with PostgreSQL when a flurry of writes occur.