Slashdot Mirror

At least in terms of unused code. I ran PMD's unused code rules on it and found no problems. Good stuff!

Well, the Female Body Inspectors need something to do.
http://freenet.sourceforge.net/

"Dream?" Fantasize is more like it. If "recompiling" was all it takes, there would be no differences between what is available under OS X from anything else. Recompiling of C or C++ code (so long as it doesn't need to interact with Quartz/Aqua) targeting PPC has been available since Day One for OS X.

While it is one thing to run faceless software that can connect to the BSD guts of OS X, once it needs to talk to the user it will have to interact with the Cocoa (Objective C) GUI layer, or be retricted to running from the Terminal window or X11 or maybe use a Java presentation layer -- none of which are completely satisfactory (assuming there is a significant amount of user interaction).

However, I note that SBCL is supported on both PowerPC and Intel hardware, under OS X and PPC in particular (but NOT OS X on X86), as well as most *nix flavors on X86 platforms. Windozers apparently need not apply. If you want to run SBCL on a Mac, you'd better be securing one of the last PPC Macs, as there seems to be no X86 port in progress. Sadly, the SBCL port is (apparently) *not* an Xcode implementation, as they would be able to produce a universal binary that would run under both X86 and PPC platforms by merely clicking the appropriate checkbox at build time.

I guess you fall into that camp of believers in Intel performance. I hope it comes out that way, but a lot of the PPC bigots (and I am one such) are wary of the ginormous power draws of the Intel desktop line, and are suspicious that the reduced power notebook lines give up horsepower to achieve their low power goals (which may or may not be acceptable, depending on how one uses a notebook).

Anybody got some benchmarks showing Intel notebooks vs comparable Intel desktops -- or better yet, Intel notebooks vs PowerPC notebooks, both running Linux (to remove any cloud of differing OS efficiencies that might be raised)? Such testing would make me a lot less queasy about the coming move, and guide me in whether to latch onto one of the last PPC models or wait to venture down the Intel path.

However, I do grasp onto the ray of hope that comes from the shrinking chip geometries. As they move from the 90 micron to the 65 micron production technologies, there is hope that both performance and power consumption can be improved, such that despite the (IMHO) superior RISC architecture of the PPC and the much beefier onboard vector units, the Intel design may well prove to provide greater throughput at less power. IBM seems to be (for whatever reason) 3-5 years behind Intel in implementing smaller production geometries, which do raise the stakes considerably for a chip manufacturer. But the power draws I've seen published/previewed/leaked for the coming Intel Yonah and Merom lines do not give me and comfort when compared to things like the Freescale dual core MPC8641D chip (10W at 1.4 GHz) (which inexplicably is not in the cards for Mac portable use).

Prices are another area of concern, as Intel's cpu pricing is quite a bit more (several hundred $$$) than comparable PPC chips, at least in modest quantities. Supposedly the legendary monopolistic all-your-business discount will make this less of a concern.

In any event, Mac performance/pricing had apparently little or nothing to do with the move to Intel, which was apparently based on driving the iPods into video realms that were not otherwise possible without dedicated video hardware in the iPods (although the current video iPods seem to be doing quite nicely using the Broadcom chips for H.264 manipulation).

Me too on that grain of crystalline substance thing. Time will tell, just have to wait and see what develops.

The real issue is who is going to pay for the next generation of KDE development if SuSE isn't going to pay.

Mandrake, Kubuntu/Mark Shuttleworth, Trolltech seem realize the value of KDE's superior architecture, on which many must-have KDE apps have been built. These apps don't have any gnome equivalents that are nearly as useful and feature-rich:

AmaroK music player -- Steve Jobs' nightmare, the single greatest threat to Itunes on the Free Software platform.

K3b -- Best CD and DVD authoring program with intuitive wizards, on the fly transcoding between WAV, MP3, FLAC, and Ogg Vorbis, normalization of volume levels, CDDB, DVD Ripping and DivX/XviD encoding, Save/load projects, automatic hardware detection/calibration and much more.

DigiKam -- The most feature-rich application for digital photo management.

Wireless Assistant -- Most user-friendly app for connecting to wireless networks. Managed Networks Support, WEP Encryption Support, Per Network (AP) Configuration Profiles, Automatic (DHCP, both dhcpcd and dhclient) and manual configuration options, Connection status monitoring, etc

KDE Education -- Educational (Science, Literature, Geography, etc) programs for children. Could play a big role in whether school districts decide to use Free Software in their classrooms.

Konqueror File Manager -- Embeded image/PDF/music/video viewing (via KMPlayer) and a tree-view arrangement of the filesystem familiar to Windows users (Nautilus doesn't come anywhere close)

KDE Control Center -- Centralized location for desktop control. Controls _all_ common aspects of the KDE applications: language, power settings, special effects, icon and window themes, shadows, shortcuts, printers, privacy, etc. This is what makes KDE so well integrated -- all KDE apps respect changes made here, so they all have the same feel. SUSE has even made YAST a module of the KDE control center so users can access distro-specific settings from here. Compare this to the dismembered approach Red Hat (and other gnome distros) have been forced to adopt in the absence of a centralized gnome control center. (ie. a bunch of individial programs named redhat-config-**** that nobody can ever remember)

Seamless, transparent network file access on SMB, FTP, SSH and WebDav networks from _any_ KDE application.

Kaffeine -- The most polished FOSS movie player.

MythTV -- The most advanced analog and digital TV viewer/recorder in the Free Software world (built using QT).

Baghira -- A native QT style that faithfully imitates OS X eyecandy, aimed at new users coming from the Mac world.

Klik -- Gives non-expert access to bleeding edge versions of apps without requiring any compilation or permanent installation.

KDE and QT also make up a technically superior platform for developers, drastically lowering the learning curve for programmers new to FOSS development. KDE apps can be built from the ground up using the best development tools in the Free Software world (which also happen to be built on QT/KDE):

Kdevelop for syntax highlighting, application templates, and project organization.

QT designer for GUI development

Quanta -- Rich web development environment for PHP, CSS, DocBook, HTML, XML, etc with advanced con

The real issue is who is going to pay for the next generation of KDE development if SuSE isn't going to pay.

Mandrake, Kubuntu/Mark Shuttleworth, Trolltech seem realize the value of KDE's superior architecture, on which many must-have KDE apps have been built. These apps don't have any gnome equivalents that are nearly as useful and feature-rich:

AmaroK music player -- Steve Jobs' nightmare, the single greatest threat to Itunes on the Free Software platform.

K3b -- Best CD and DVD authoring program with intuitive wizards, on the fly transcoding between WAV, MP3, FLAC, and Ogg Vorbis, normalization of volume levels, CDDB, DVD Ripping and DivX/XviD encoding, Save/load projects, automatic hardware detection/calibration and much more.

DigiKam -- The most feature-rich application for digital photo management.

Wireless Assistant -- Most user-friendly app for connecting to wireless networks. Managed Networks Support, WEP Encryption Support, Per Network (AP) Configuration Profiles, Automatic (DHCP, both dhcpcd and dhclient) and manual configuration options, Connection status monitoring, etc

KDE Education -- Educational (Science, Literature, Geography, etc) programs for children. Could play a big role in whether school districts decide to use Free Software in their classrooms.

Konqueror File Manager -- Embeded image/PDF/music/video viewing (via KMPlayer) and a tree-view arrangement of the filesystem familiar to Windows users (Nautilus doesn't come anywhere close)

KDE Control Center -- Centralized location for desktop control. Controls _all_ common aspects of the KDE applications: language, power settings, special effects, icon and window themes, shadows, shortcuts, printers, privacy, etc. This is what makes KDE so well integrated -- all KDE apps respect changes made here, so they all have the same feel. SUSE has even made YAST a module of the KDE control center so users can access distro-specific settings from here. Compare this to the dismembered approach Red Hat (and other gnome distros) have been forced to adopt in the absence of a centralized gnome control center. (ie. a bunch of individial programs named redhat-config-**** that nobody can ever remember)

Seamless, transparent network file access on SMB, FTP, SSH and WebDav networks from _any_ KDE application.

Kaffeine -- The most polished FOSS movie player.

MythTV -- The most advanced analog and digital TV viewer/recorder in the Free Software world (built using QT).

Baghira -- A native QT style that faithfully imitates OS X eyecandy, aimed at new users coming from the Mac world.

Klik -- Gives non-expert access to bleeding edge versions of apps without requiring any compilation or permanent installation.

KDE and QT also make up a technically superior platform for developers, drastically lowering the learning curve for programmers new to FOSS development. KDE apps can be built from the ground up using the best development tools in the Free Software world (which also happen to be built on QT/KDE):

Kdevelop for syntax highlighting, application templates, and project organization.

QT designer for GUI development

Quanta -- Rich web development environment for PHP, CSS, DocBook, HTML, XML, etc with advanced con

The real issue is who is going to pay for the next generation of KDE development if SuSE isn't going to pay.

Mandrake, Kubuntu/Mark Shuttleworth, Trolltech seem realize the value of KDE's superior architecture, on which many must-have KDE apps have been built. These apps don't have any gnome equivalents that are nearly as useful and feature-rich:

AmaroK music player -- Steve Jobs' nightmare, the single greatest threat to Itunes on the Free Software platform.

K3b -- Best CD and DVD authoring program with intuitive wizards, on the fly transcoding between WAV, MP3, FLAC, and Ogg Vorbis, normalization of volume levels, CDDB, DVD Ripping and DivX/XviD encoding, Save/load projects, automatic hardware detection/calibration and much more.

DigiKam -- The most feature-rich application for digital photo management.

Wireless Assistant -- Most user-friendly app for connecting to wireless networks. Managed Networks Support, WEP Encryption Support, Per Network (AP) Configuration Profiles, Automatic (DHCP, both dhcpcd and dhclient) and manual configuration options, Connection status monitoring, etc

KDE Education -- Educational (Science, Literature, Geography, etc) programs for children. Could play a big role in whether school districts decide to use Free Software in their classrooms.

Konqueror File Manager -- Embeded image/PDF/music/video viewing (via KMPlayer) and a tree-view arrangement of the filesystem familiar to Windows users (Nautilus doesn't come anywhere close)

KDE Control Center -- Centralized location for desktop control. Controls _all_ common aspects of the KDE applications: language, power settings, special effects, icon and window themes, shadows, shortcuts, printers, privacy, etc. This is what makes KDE so well integrated -- all KDE apps respect changes made here, so they all have the same feel. SUSE has even made YAST a module of the KDE control center so users can access distro-specific settings from here. Compare this to the dismembered approach Red Hat (and other gnome distros) have been forced to adopt in the absence of a centralized gnome control center. (ie. a bunch of individial programs named redhat-config-**** that nobody can ever remember)

Seamless, transparent network file access on SMB, FTP, SSH and WebDav networks from _any_ KDE application.

Kaffeine -- The most polished FOSS movie player.

MythTV -- The most advanced analog and digital TV viewer/recorder in the Free Software world (built using QT).

Baghira -- A native QT style that faithfully imitates OS X eyecandy, aimed at new users coming from the Mac world.

Klik -- Gives non-expert access to bleeding edge versions of apps without requiring any compilation or permanent installation.

KDE and QT also make up a technically superior platform for developers, drastically lowering the learning curve for programmers new to FOSS development. KDE apps can be built from the ground up using the best development tools in the Free Software world (which also happen to be built on QT/KDE):

Kdevelop for syntax highlighting, application templates, and project organization.

QT designer for GUI development

Quanta -- Rich web development environment for PHP, CSS, DocBook, HTML, XML, etc with advanced con

Actually Sandia Labs has copyrighted a number of software programs (MPQC). I rather like that they have choosen the GPL, but without doubt they are copyrighting their work. Likewise, when Maxima's predecessor (Macsyma) was originally coded for the DOE it was copyrighted, and DOE had to later be convinced to give permission for Maxima to GPLed.

For example. I'd pay a lot of money for a Tiger upgrade to the ext2fs plugin for OS X. Unfortunately, no (reasonable) amount of money will convince the author to make time for the upgrade right now.

Do you mean this one? If so, the news item posted just a few days ago says he's working on it, and has a link to his Amazon wish list for those who want to offer "encouragement". (Although you're right... It looks like there was a two-year hiatus before the recent work on Tiger...)

Slackware is certainly the most solid of the KDE-centric distros, and is even better with Dropline Gnome. ;-)

Do you seriously think that Mac isn't BUILT on eye-candy?

Mac OS X is built on quality design. That, in turn, happens to look pretty cool to most people.

I don't know about anybody else, but when I say "eye-candy" as a derrogatory term, I mean visual elements added in ignorance of any overall design. There is a reason that Mac OS X looks cool, where tacky rip-offs of the visual elements do not. When you simply "paste-on" a bunch of stuff that "looks cool", you end up with an incoherent mess. This is the dominant practice in open source UI design.

In other words, the problem isn't "glitz". It's improper use of it. Apple can afford the glitz because they have skilled designers that know how to use it properly. Open source projects do not, and they suffer by spending too much time adding "eye-candy" in without any coherent vision.

Well, I've used slackware since the pre-1.0 kernel. I am also, for reasons I really can't explain, a GNOME fan. Slackware recently decided to stop including GNOME with their releases. But instead of giving up on my distribution of choice for so many years, I turn to projects like dropline-gnome to pick up the slack. Oh. real bad pun. Sorry. But, if KDE support for SUSE starts to lag, I'm sure another project will bring it back up to speed. Don't abandon your distro so easily!! Something about slackware usally pisses me off once every few weeks and every once in awhile I'll install some new distribution on an unused partition but I always end back up with Slackware. Oh no, I've started a distro flame war. Sorry guys, I'll exit quietly with this one.. (walks backwards towards the door) ;-)

But, considering that regardless of the distro the same release number of KDE behaves the same way on all distros that deploy it, any is as good as another, all other things being equal. So KDE is not a reason to choose a distro unless that distro is the first to release with the latest version of KDE and you want to move to it.

Also, a KDE-centric distro means that default software packages offered for installation are KDE-based. So you get JuK rather than Rhythmbox, and your OpenOffice will have Qt native widgets rather than Gtk ones. Again, nothing a user can't do on his own, but why should he waste time on finding out how?

Linux distros that feature GNOME still have to install connectivity to KDE functionality because the VAST majority of applications are written using QT widgets.

I find it rather ironic that GNOME was created as a GPL response to QT's propritary widget set, but after the KDE Foundation negotiated with TrollTech to continually release a GPL version of QT the reason for GNOME's existance became moot.

But, considering that regardless of the distro the same release number of KDE behaves the same way on all distros that deploy it, any is as good as another, all other things being equal. So KDE is not a reason to choose a distro unless that distro is the first to release with the latest version of KDE and you want to move to it.

Also, a KDE-centric distro means that default software packages offered for installation are KDE-based. So you get JuK rather than Rhythmbox, and your OpenOffice will have Qt native widgets rather than Gtk ones. Again, nothing a user can't do on his own, but why should he waste time on finding out how?

Linux distros that feature GNOME still have to install connectivity to KDE functionality because the VAST majority of applications are written using QT widgets.

I find it rather ironic that GNOME was created as a GPL response to QT's propritary widget set, but after the KDE Foundation negotiated with TrollTech to continually release a GPL version of QT the reason for GNOME's existance became moot.

I think a lot of Suse customers will not be so pleased.

Of course SUSE customers won't be pleased. There are many must-have desktop apps built on the KDE framework that don't have any good gtk equivalents:

AmaroK music player -- Steve Jobs' nightmare, the single greatest threat to Itunes on the Free Software platform.

DigiKam -- The most feature-rich application for digital photo management.

Konqueror File Manager" -- Embeded image/PDF/music/video viewing (via KMPlayer) and a tree-view arrangement of the filesystem familiar to Windows users (Nautilus doesn't come anywhere close)

Seamless, transparent network file access on SMB, FTP, SSH and WebDav networks from _any_ KDE application.

Kaffeine -- The most polished FOSS movie player.

Baghira -- A native QT style that faithfully imitates OS X eyecandy, aimed at new users coming from the Mac world.

KDE and QT also make up a technically superior platform for developers, drastically lowering the learning curve for programmers new to FOSS development. KDE apps can be built from the ground up using the best development tools in the Free Software world (which also happen to be built on QT/KDE):

QT designer for GUI development

Kdevelop for syntax highliting, application templates, and project organization.

BKSys environmentfor a complete replacement of the autotool chain (libtool+automake+autoconf+make) that will make dependency a whole lot more simpler and efficient.

Gnome is way behind KDE with regards to these features. The only reason Redhat's doing so well with Gnome is because they're targeting geeky sysadmins who don't care about having a good-looking desktop. The other 99% of the world does care, and gnome just doesn't fit the bill.

I think a lot of Suse customers will not be so pleased.

Of course SUSE customers won't be pleased. There are many must-have desktop apps built on the KDE framework that don't have any good gtk equivalents:

AmaroK music player -- Steve Jobs' nightmare, the single greatest threat to Itunes on the Free Software platform.

DigiKam -- The most feature-rich application for digital photo management.

Konqueror File Manager" -- Embeded image/PDF/music/video viewing (via KMPlayer) and a tree-view arrangement of the filesystem familiar to Windows users (Nautilus doesn't come anywhere close)

Seamless, transparent network file access on SMB, FTP, SSH and WebDav networks from _any_ KDE application.

Kaffeine -- The most polished FOSS movie player.

Baghira -- A native QT style that faithfully imitates OS X eyecandy, aimed at new users coming from the Mac world.

KDE and QT also make up a technically superior platform for developers, drastically lowering the learning curve for programmers new to FOSS development. KDE apps can be built from the ground up using the best development tools in the Free Software world (which also happen to be built on QT/KDE):

QT designer for GUI development

Kdevelop for syntax highliting, application templates, and project organization.

BKSys environmentfor a complete replacement of the autotool chain (libtool+automake+autoconf+make) that will make dependency a whole lot more simpler and efficient.

Gnome is way behind KDE with regards to these features. The only reason Redhat's doing so well with Gnome is because they're targeting geeky sysadmins who don't care about having a good-looking desktop. The other 99% of the world does care, and gnome just doesn't fit the bill.

Print-on-demand was my way of publishing a textbook of Open-Source Artificial Intelligence.

Google Scholar makes the AI4U textbbok available through the Google Print Publisher Program -- so far, so good.

Amazon lets people write vicious reviews full of ignorance and lies -- not good.

Rebuttals of Amazon reviews are called for but nobody seems to care -- why not?

Association for Computing Machinery publishes the truth, but Amazon won't.

Top-notch AI researchers come to the rescue.

Disruptive technology means that all bets are off and nobody could have predicted in advance what is about to happen now.

Technological Singularity is the ultimate, ne plus ultra disruptive technology so currently unimagineable that even science fiction fails to describe what will happen beyond the few clues that we we see awakening around us.

Seed AI is the first harbinger of Open Source Artificial Intelligence metastasizing and propagating itself all over the 'Net.

Recursive self-improvement of the AI Minds leads to a hard takeoff of super-intelligent artificial intelligence.

PC-based, AI-ready robots are already being manufactured and pre-ordered by the early adopters of the disruptive AI technology.

The Mind.Forth AI Engine leads the pack of Robot AI Minds germinating and speciating from Seed AI into Singularity AI.

Artificial General Intelligence is already unpreventable and unstoppable.

Disruptive technology means that all bets are off and nobody could have predicted in advance what is about to happen now.

Technological Singularity is the ultimate, ne plus ultra disruptive technology so currently unimagineable that even science fiction fails to describe what will happen beyond the few clues that we we see awakening around us.

Seed AI is the first harbinger of Open Source Artificial Intelligence metastasizing and propagating itself all over the 'Net.

Recursive self-improvement of the AI Minds leads to a hard takeoff of super-intelligent artificial intelligence.

PC-based, AI-ready robots are already being manufactured and pre-ordered by the early adopters of the disruptive AI technology.

The Mind.Forth AI Engine leads the pack of Robot AI Minds germinating and speciating from Seed AI into Singularity AI.

Artificial General Intelligence is already unpreventable and unstoppable.

Disruptive technology means that all bets are off and nobody could have predicted in advance what is about to happen now.

Technological Singularity is the ultimate, ne plus ultra disruptive technology so currently unimagineable that even science fiction fails to describe what will happen beyond the few clues that we we see awakening around us.

Seed AI is the first harbinger of Open Source Artificial Intelligence metastasizing and propagating itself all over the 'Net.

Recursive self-improvement of the AI Minds leads to a hard takeoff of super-intelligent artificial intelligence.

PC-based, AI-ready robots are already being manufactured and pre-ordered by the early adopters of the disruptive AI technology.

The Mind.Forth AI Engine leads the pack of Robot AI Minds germinating and speciating from Seed AI into Singularity AI.

Artificial General Intelligence is already unpreventable and unstoppable.

It seems like OpenMetaverse would get some more developers with the popularity of this stuff. I never found a server that worked.

Something like this:
http://goog-ajaxslt.sourceforge.net/

That always irritated me about JAVA dependant site. not to start a flame war, but its just so bloated! its too bad Grail never took off.

Reminds me, perhaps incorrectly, of the Brix OS

http://brix-os.sourceforge.net/?p0=info

http://sourceforge.net/projects/brix-os

Reminds me, perhaps incorrectly, of the Brix OS

http://brix-os.sourceforge.net/?p0=info

http://sourceforge.net/projects/brix-os

Everything is an x86 (except for high end IBM POWER and Sun SPARC workstations, which may be dying too; embedded machines don't count). The days of choosing from a wide range of platforms are dead.

First off, I disagree that embedded platforms 'don't count': You can do increasing amounts of cool stuff with things like cell phones and gaming consoles (which are practically non-IBM-clone PCs anyway at this point), a pursuit which even includes real hardware modifications (essentially a dead hobby in the card-centric PC world).

Second, the chips made by Intel and AMD are x86 in name and ISA only. 64-bit is already a reality (albeit an expensive one) for the average non-übergeek, and dual-core is either already available or will be shortly. SIMD ISAs have been a standard on-chip component for about a decade (give or take) and modern x86 chips have been RISC in CISC clothing for even longer.

Operating systems and environments are still improving (OS X is still adding nice features, and development with GNUstep still shows just how ahead NEXTSTEP was back in the day), but nothing's happening to the core of the operating system. Where is my exokernel OS? Heck, we don't really have a pure microkernel OS in wide usage now, and that's 80's research.

Again, it may well seem that way, but look beneath the POSIX-compatible surface and you'll find unsuspected complexity and, yes, innovation. Xen, something that either is an exokernel or simply acts like one, is going to be a standard part of new Red Hat releases quite shortly now. (Slashdot had an article on this yesterday or so.) Microkernels, while they don't seem to be practical in desktop systems, have generated plenty of research on important OS topics that can be applied to more conventional kernels. Loadable modules, anyone? Linux even has userland filesystems now (the FUSE project is in the official kernel now (2.6.14-rc1)). (As an aside, look at QNX if you want to see a real-world microkernel that even runs on a variety of non-x86 hardware, to boot.)

My point in all this is that things only stay the same on the surface, largely for compatibility reasons. Compatibility is a necessary evil in an industry as large as IT has become, but it does not preclude innovation. It simply forces it to areas just beneath the surface.

Gah, if recommending a text based browser, please at least recommend a decent one! Lynx has aged rather poorly IMO, and is massively surpassed by elinks and especially w3m. In fact, w3m is good enough that sometimes I can't be bothered starting up X on my (very) aged laptop - though the lack of Unicode support in the Linux virtual console layer is annoying.

Why should HW vendors write drivers when there's almost no pressure to do so?

Pardon me, but I didn't say vendors should write drivers. I said they should open up their hardware and give developers a chance to write drivers.

ATI still won't let developers see its hardware specs for many of its cards. The people working on GATOS have been begging for some information about their cards. Recently, ATI has been more open, but in the past they've been repeatedly shooting themselves in the foot by not writing Linux drivers for their own cards and keeping the specs closed so no one else could write them.

I've just took a look at then Sofia-SIP stack. One of the most horribile pieces or code i've saw lately. I mean even oSIP which is the most rubbish SIP stack from the free world look way better than this.
I won't compare it with YASS (Yate SIP stack) which is a piece of art if you compare it with SIP stack.
I can't belive that in this days someone will write code in the way Sofia-SIP is writte. Just compare how complicated it is.

http://voip.null.ro/cgi-bin/cvsweb.cgi/yate/contri b/ysip/ - Yate SIP stack

http://savannah.gnu.org/cgi-bin/viewcvs/osip/osip/ - oSIP

http://cvs.sourceforge.net/viewcvs.py/sofia-sip/so fia-sip/ - Sofia-SIP

I think in the end that what Nokia did was just to throw some rubbish code arround hoping to get some more bug fixes.

...while we wait for Linux version, is anyone working on getting this stuff to Celestia? Would rock if the two programs could easily use the same data though.

The screenshots seem nice, but regrettably not really too much more impressive than what you can already do with Celestia. =(

``Still, I think that tools like Borland Delphi/Kylix, & yes, even RealBasic 2005 (does Win32, Linux, AND MacOS X code from a single codebase) each are "superior" tools of "RAD" design vs. C/C++ porting between platforms.''

Oh, absolutely. C is an OK language for writing operating systems in, but it's horrible for writing applications. C++ is better, but it has many problems (mostly due to Design by Committee). And with RealBasic (can't vouch for Delphi) you also get a safer language (see Better Languages for Better Software).

Of course, i'd rather you use something truely open for your RAD development - perhaps GORM, or Glade (maybe wxGlade would be a better choice for cross-platform work), or ...

``Drive Letters used in Win32 vs. Device mounting in UNIX based OS like Linux &/or MacOS X BSD heritage.

Well, that & using registry entries in Win32 vs. .ini files (or whatever filetype you use, text even etc.) & such for state storage for apps between runs so they have "memory" between runs.''

Of course, there's always stuff that's going to bite you in the ass when you use it. If you use the Windows registry, it won't work on Unix. If you use Unix sockets, it won't work on Windows. So you need to abstract away from those differences and write code that does what you really want. You want to store settings? Well, write code that stores settings and works on all platforms you support. You want IPC? Write code that does IPC and works on all supported platforms.

Eventually, you'll also have to keep in mind that to write truly great software, you have to also make it fit in with the environment it should run on. Users of all platforms tolerate some inconsistency, but a Kylix app would probably look horribly out of place on a nicely themed modern Linux desktop. The traditional wisdom still holds: separate your user interface from your engine, and then write a dedicated engine for each platform you support.

``Still, I think that tools like Borland Delphi/Kylix, & yes, even RealBasic 2005 (does Win32, Linux, AND MacOS X code from a single codebase) each are "superior" tools of "RAD" design vs. C/C++ porting between platforms.''

Oh, absolutely. C is an OK language for writing operating systems in, but it's horrible for writing applications. C++ is better, but it has many problems (mostly due to Design by Committee). And with RealBasic (can't vouch for Delphi) you also get a safer language (see Better Languages for Better Software).

Of course, i'd rather you use something truely open for your RAD development - perhaps GORM, or Glade (maybe wxGlade would be a better choice for cross-platform work), or ...

``Drive Letters used in Win32 vs. Device mounting in UNIX based OS like Linux &/or MacOS X BSD heritage.

Well, that & using registry entries in Win32 vs. .ini files (or whatever filetype you use, text even etc.) & such for state storage for apps between runs so they have "memory" between runs.''

Of course, there's always stuff that's going to bite you in the ass when you use it. If you use the Windows registry, it won't work on Unix. If you use Unix sockets, it won't work on Windows. So you need to abstract away from those differences and write code that does what you really want. You want to store settings? Well, write code that stores settings and works on all platforms you support. You want IPC? Write code that does IPC and works on all supported platforms.

Eventually, you'll also have to keep in mind that to write truly great software, you have to also make it fit in with the environment it should run on. Users of all platforms tolerate some inconsistency, but a Kylix app would probably look horribly out of place on a nicely themed modern Linux desktop. The traditional wisdom still holds: separate your user interface from your engine, and then write a dedicated engine for each platform you support.

It's amazing how quickly people have forgotten about ripping CDs. Just a few years ago, all portable MP3 players were (supposedly) sold for the purpose of playing music ripped from CDs, but today the common assumption is that all music is either legally downloaded and DRM-encrusted or illegally downloaded.

Unfortunately I'm afraid the CD's might be going away someday, because the labels want everything to be DRM-encrusted. But until they do go away, yeah I'd rather buy CD's and rip them than put up with FairPlay or its ilk; so I don't think this idea is "forgotten". Besides when you rip a CD, you can rip to FLAC for never-obsolete lossless quality; whereas iTunes is still using already-obsolete AAC-LC (they should be using AACplus by now). And if you buy used CD's like I do, it's always cheaper than iTunes. And there are legal sites where you can pay for and download non-DRM tracks, so that's the other alternative.

I think the rift between signed artists and indies is just going to keep getting wider; as DRM increases, it will become more and more possible to satisfy your musical tastes with "free" music (free of restrictions at least, even if you still have to pay a little money for it).

Now, how do you find the free music? Well iRate radio is a very good start. This project needs to be integrated into the others. E.g. I want it to stream to my SqueezeBox (and have a UI to do the rating right on the SB) and I want it to automatically put my favorites onto my portable player. Just with those features, a whole parallel universe can be developed in which the indie artists get much more exposure (among people who care about freedom at least, who, granted, are in the minority) and you the listener can find stuff you really like rather than having the labels shove it down your throat every day on the ClearChannel radio. This is my dream.

Yeah, and ffmpeg is pretty much the foundation of many or most multimedia on Linux. Take a look at the source-code sometime, it's pretty damn cool.

ffmpeg is the work of a guy called Fabrice Bellard, and probably many people who've tweaked, helped and tested.

http://sourceforge.net/forum/forum.php?thread_id=1 272272&forum_id=462894

media player classic et al....

...quality...

Compared to similar code in, say, FreeBSD, (take the USB code or the BT) it is interesting how much more detail and perfection is possible when the author of the code has 100% insight in the actual hardware. Gone are all the fiddles and the magic '#defines' - instead it actually tells you the why. Imagine a ethernet vendor or wifi card vendor doing the same!

Dw

Do they support AC3 audio? If they do it looks like they might have a problem.
http://ffmpeg.sourceforge.net/faq.html#TOC9

If your main beef is getting rid of iTunes and you're willing to use Winamp instead, look no further than ml_iPod, which allows the iPod to show up as a 'device' in the Winamp media library. Just drag to and from it, or sync with your library collection. Get it here: http://mlipod.sourceforge.net/ - I've been using it since I got my iPod about a year ago, and I've loved it since.

I'd say that's a pretty poor guess. Neuros has a history of "open source" with their media players. A few years ago they released the source code for their Neuros Syncronization Manager NSM. Their first generation player was pretty crappy in terms of hardware (FM transmitter didn't work right, only had a USB 1.1 (ugh!) interface) and the NSM software was kind of bunk; However they've had firm-ware updates for a while that support OGG and it's pretty interesting that a company is actually make a portable media player that they are encouraging (and supporting!) geek to hack (sounds like material for MAKE). I think that's a pretty post-modern (and refreshing) idea in a world where we're constantly assaulted with legal threats, DRM, etc.

Don't be so quick to judge something based on a partial quote from a magazine article. Besides, he's technically right about open-source projects. Taking a look at source-forge there are at least 100 projects that are dead for every one that is active, whether they were started by "kids" or not.

Anyway... Look a little closer at the project; there's some interesting stuff going on there.

"In a few years, there will be no real benefit to the GPU" Nonsense - we're actually going in the other direction, we need more general purpose massively parallel processing units to go beyond current hardware limitations. Dual CPUs do not come close to the level of parallelism we have on GPUs. Rendering a 1600x1200 4X AA scene with full filtering on a top tier dual core system would yield perhaps 1fps with an optimized software path. That gives you an idea of the order of magnitude you gain in performance with parallelizing these tasks on the GPU. "[GPUs] need data structures and pointers mixed with fast math - preferably double precision. You'll end up wanting a MMU" Nonsense. GPUs already do everything you need for raytracing. There are demos on the internet. Raytracing is ideally suited to GPUs - there's so much you can parallelize. "Actually at that point it makes a lot of sense to move to raytracing " Nonsense. You're off by orders of magnitude. Maybe they just haven't seen your fast code... *rolls eyes*

here you go http://xvidcap.sourceforge.net/

There's no reason there couldn't be Linux Support. At the IEEE Viz05 Conference there was a nice talk from the guys operating www.gpgpu.org about cross-platform support, and there's a couple of new languages coming out that act as wrappers for Cg/HLSL/OpenGL on both ATI & NVidia, & Windows & Linux... Check out Sh (http://libsh.sourceforge.net/ and Brook (http://brook.sourceforge.net./ Once their algorithm is discovered (Yipee for Reverse engineering), it won't be long.

There's no reason there couldn't be Linux Support. At the IEEE Viz05 Conference there was a nice talk from the guys operating www.gpgpu.org about cross-platform support, and there's a couple of new languages coming out that act as wrappers for Cg/HLSL/OpenGL on both ATI & NVidia, & Windows & Linux... Check out Sh (http://libsh.sourceforge.net/ and Brook (http://brook.sourceforge.net./ Once their algorithm is discovered (Yipee for Reverse engineering), it won't be long.

There is a fundamental problem with Blastwave and every one of the available efforts to adapt a new package management system to Solaris. Solaris has an existing package management system and all the dependencies in this system are ignored or overwritten by the new system. Alternatively the new package management system will take over and require that it be used exclusively. Let's look at a few examples:

1) rpm.rutgers.edu - this is a terrific resource that has some major advantages over blastwave. It will take your existing Solaris packages and migrate them to the rpm database, however this is a one shot deal and you are expected to manage your software with rpm from that point on. What do I do if I want to install a patch from sun or a new SUNW package?
2) Netbsd pkgsrc : Rocking good software collection and spectacular cross platform goodness, but it has no concept of the host package management system. Also I miss the ability to apt-get update ; apt-get upgrade . The source base changes every quarter. I had high hopes for http://solarpack.sourceforge.net/ but development has been dropped.
3) Sunfreeware. Solaris packages, but no dependency info is used at all.
4) Blastwave, ibiblio, and a few others. These systems use solaris packages, but don't integrate them with the Sun provided dependency database.
5) Sun's own Companion CD has Sun maintained packages (albeit not very many) that do seem to do the trick.
6) Many efforts to port apt to Solaris as detailed here:
http://solarpack.sourceforge.net/links.html#solari s

So the question is, what is the goal of all this? It looks to me like the purpose of a package management system is to minimize systems administrator labor. That means that I might be willing to manually create and maintain one or two packages, but if I am installing many packages I would like to have a dependable repository of secure, bug free packages that I can draw upon. Furthermore I need a method of doing a simple mass upgrade of packages.

The major reason for using Solaris is the get a stable platform. Solaris binaries from 10 years ago will still run unmodified on Solaris 10 from March of this year. Joel Sparsky has written at length on the subject of a stable API as being the underpinning of Microsoft's success. Industry is still willing to pay a premium for Sun hardware and software because they have a need to minimize change in the datacenter. If I want to install Gforge http://people.debian.org/~bayle/ on a stock Debian Sarge machine it will auto install more than 20 packages. On Solaris many of these packages are already provided by sun. Stripping your machine down to the kernel and a few other support packages and replacing the guts of the OS with Debian (or pkgsrc) doesn't seem to me to be the right way to go if you are looking for stability. Sun is the one making the commitment to support for 10 years not Debian. I would like to use as much Sun supported software as possible in setting up my machine.

There is a fundamental problem with Blastwave and every one of the available efforts to adapt a new package management system to Solaris. Solaris has an existing package management system and all the dependencies in this system are ignored or overwritten by the new system. Alternatively the new package management system will take over and require that it be used exclusively. Let's look at a few examples:

1) rpm.rutgers.edu - this is a terrific resource that has some major advantages over blastwave. It will take your existing Solaris packages and migrate them to the rpm database, however this is a one shot deal and you are expected to manage your software with rpm from that point on. What do I do if I want to install a patch from sun or a new SUNW package?
2) Netbsd pkgsrc : Rocking good software collection and spectacular cross platform goodness, but it has no concept of the host package management system. Also I miss the ability to apt-get update ; apt-get upgrade . The source base changes every quarter. I had high hopes for http://solarpack.sourceforge.net/ but development has been dropped.
3) Sunfreeware. Solaris packages, but no dependency info is used at all.
4) Blastwave, ibiblio, and a few others. These systems use solaris packages, but don't integrate them with the Sun provided dependency database.
5) Sun's own Companion CD has Sun maintained packages (albeit not very many) that do seem to do the trick.
6) Many efforts to port apt to Solaris as detailed here:
http://solarpack.sourceforge.net/links.html#solari s

So the question is, what is the goal of all this? It looks to me like the purpose of a package management system is to minimize systems administrator labor. That means that I might be willing to manually create and maintain one or two packages, but if I am installing many packages I would like to have a dependable repository of secure, bug free packages that I can draw upon. Furthermore I need a method of doing a simple mass upgrade of packages.

The major reason for using Solaris is the get a stable platform. Solaris binaries from 10 years ago will still run unmodified on Solaris 10 from March of this year. Joel Sparsky has written at length on the subject of a stable API as being the underpinning of Microsoft's success. Industry is still willing to pay a premium for Sun hardware and software because they have a need to minimize change in the datacenter. If I want to install Gforge http://people.debian.org/~bayle/ on a stock Debian Sarge machine it will auto install more than 20 packages. On Solaris many of these packages are already provided by sun. Stripping your machine down to the kernel and a few other support packages and replacing the guts of the OS with Debian (or pkgsrc) doesn't seem to me to be the right way to go if you are looking for stability. Sun is the one making the commitment to support for 10 years not Debian. I would like to use as much Sun supported software as possible in setting up my machine.

First, the way the interface looks is irrelevant. A GNUstep theme engine is available here. There's a nice theme in progress called Nesedah (mockup and screenshot of IRC client along with OS X comparison shot)

Second, why is this such a big deal? Don't QT, Visual Basic, and Delphi provide the same RAD approach? No. I've used all of those tools and they just don't stack up. QT is about as good as you're going to get out of a static compile-time-oriented C++ approach. But it's not as simple or direct as a runtime-oriented OO solution like Smalltalk or Objective-C. This is the power of Cocoa/OpenStep/GNUstep.

Delphi, .NET, and QT GUI designers focus on generating code. This is cumbersome and brittle. But Apple/NeXT's Interface Builder and GNUstep's Gorm take a different approach. They actually instantiate objects, set state, create inter-object connnections, and then persist the in-memory objects to disk. When your application is loaded, these objects are unarchived and your application connects to them. This prevents the OO-mocking approach of subclassing a Window class just to create your own instance--something that always makes me laugh but is ubiquitous in the Windows world and has been blindly copied by KDE and GNOME.

Finally, the poster is not a native speaker of English and clearly was not able to convey the sense of humor intended.

First, the way the interface looks is irrelevant. A GNUstep theme engine is available here. There's a nice theme in progress called Nesedah (mockup and screenshot of IRC client along with OS X comparison shot)

Second, why is this such a big deal? Don't QT, Visual Basic, and Delphi provide the same RAD approach? No. I've used all of those tools and they just don't stack up. QT is about as good as you're going to get out of a static compile-time-oriented C++ approach. But it's not as simple or direct as a runtime-oriented OO solution like Smalltalk or Objective-C. This is the power of Cocoa/OpenStep/GNUstep.

Delphi, .NET, and QT GUI designers focus on generating code. This is cumbersome and brittle. But Apple/NeXT's Interface Builder and GNUstep's Gorm take a different approach. They actually instantiate objects, set state, create inter-object connnections, and then persist the in-memory objects to disk. When your application is loaded, these objects are unarchived and your application connects to them. This prevents the OO-mocking approach of subclassing a Window class just to create your own instance--something that always makes me laugh but is ubiquitous in the Windows world and has been blindly copied by KDE and GNOME.

Finally, the poster is not a native speaker of English and clearly was not able to convey the sense of humor intended.

To see the latest generation of this work, check out their sourceforge page:
http://openvidia.sourceforge.net/

Wow! I think the "VB on Linux" comment generated more heat than just about anything else the author posted.

If everyone who wanted to bash this guy in the head over his suggestion would RTFA again, they would see that he was talking about VB in the same context as Wine and other migration paths for Windows developers. I realize that VB is a poor substitute for just about everything else, but it is the lingua franca for, as one /.er put it, a "metric tonne" of programmers. Why not provide a tool that offers the same programming functions as VB on the Linux desktop?

I'm not advocating VB as a developer's tool, I am advocating migrating Windows programmers away from Windows.

If giving them a VB equivalent (many thanks to the original link provider) means stealing mindshare (whom we can then mold into our own programmers), Linux wins.

you might want to check out gambas http://gambas.sourceforge.net/.
It's not exactly VB but anyone with experience with VB should take to it like a duck to water.
Benoit has brought the stable version up to 1.0.11 and the development version is going well.

I switched back to Mozilla solely because Mozilla uses a single text input field for both URLs and search (eg. Google). That field is like a commandline - not only can I type (and edit) URLs, but I can Google searches on those URLs (with site:), do math, unit conversions, definitions, etc. All of which produce linked webpages in the pane below. I want more CLIWWW action, like the idled XMLterm project, not less. Firefox splits the URL/search field in two, even making the search field only a few characters wide. That crimps most of my most productive webbing. Now, a "reunification" patch to Firefox would get me to switch back...