Slashdot Mirror

• Mac Rumors - Good rumors website
• Mac Slash - Slashdot like mac news site
• Mac News Bytes - Good quick links to mac related articles
• Version Tracker - Software update website. Kind of like download.com for mac.
• Mac Update - Similar to versiontracker.com
• Mac OS X Hints - Good tips site for beginners and experienced people alike.
• Think Secret - Another good rumors site. Very accurate, most of the time.
• Emulation.net - Links to game emulation for mac

• Adium - Multi-protocol IM client
• Byte Controller - Good itunes hotkey/menu pager applet
• Camino - Nice mac based gecko browser.
• Colloquy - Webkit based IRC client. not too newbish.
• Cyberduck - SFTP/FTP client for os x
• Desktop Manager - Multi desktop app for os x
• Apple X11 Server - Apple's integrated X11 server. you'd want this for the next two items
• Fink - UNIX software for your mac
• Gimp.app - decent free photo editor
• Handbrake - DVD to mpeg4 ripper
• iTerm - Multi tabbed terminal
• Logorrhea - iChat log viewer/searcher/indexer
• Meteorologist - Weather applet for the menu bar
• Menu Meters - Menu applet for cpu usage, net usage, and more.
• Mplayer OS X - This app will play just about any media format in existance
• Poisoned - GiFT (Kazaa) and mldonkey based P2P mac client.
• Quicksilver - Very cool file/application/url/itunes/etc/etc/etc indexing program. It's like spotlight, only here TODAY and free!
• VLC - Another good video playing app. Nice to have a backup sometimes if mplayer doesn't play a file (which is very very rare).

• Mac Rumors - Good rumors website
• Mac Slash - Slashdot like mac news site
• Mac News Bytes - Good quick links to mac related articles
• Version Tracker - Software update website. Kind of like download.com for mac.
• Mac Update - Similar to versiontracker.com
• Mac OS X Hints - Good tips site for beginners and experienced people alike.
• Think Secret - Another good rumors site. Very accurate, most of the time.
• Emulation.net - Links to game emulation for mac

• Adium - Multi-protocol IM client
• Byte Controller - Good itunes hotkey/menu pager applet
• Camino - Nice mac based gecko browser.
• Colloquy - Webkit based IRC client. not too newbish.
• Cyberduck - SFTP/FTP client for os x
• Desktop Manager - Multi desktop app for os x
• Apple X11 Server - Apple's integrated X11 server. you'd want this for the next two items
• Fink - UNIX software for your mac
• Gimp.app - decent free photo editor
• Handbrake - DVD to mpeg4 ripper
• iTerm - Multi tabbed terminal
• Logorrhea - iChat log viewer/searcher/indexer
• Meteorologist - Weather applet for the menu bar
• Menu Meters - Menu applet for cpu usage, net usage, and more.
• Mplayer OS X - This app will play just about any media format in existance
• Poisoned - GiFT (Kazaa) and mldonkey based P2P mac client.
• Quicksilver - Very cool file/application/url/itunes/etc/etc/etc indexing program. It's like spotlight, only here TODAY and free!
• VLC - Another good video playing app. Nice to have a backup sometimes if mplayer doesn't play a file (which is very very rare).

• Mac Rumors - Good rumors website
• Mac Slash - Slashdot like mac news site
• Mac News Bytes - Good quick links to mac related articles
• Version Tracker - Software update website. Kind of like download.com for mac.
• Mac Update - Similar to versiontracker.com
• Mac OS X Hints - Good tips site for beginners and experienced people alike.
• Think Secret - Another good rumors site. Very accurate, most of the time.
• Emulation.net - Links to game emulation for mac

• Adium - Multi-protocol IM client
• Byte Controller - Good itunes hotkey/menu pager applet
• Camino - Nice mac based gecko browser.
• Colloquy - Webkit based IRC client. not too newbish.
• Cyberduck - SFTP/FTP client for os x
• Desktop Manager - Multi desktop app for os x
• Apple X11 Server - Apple's integrated X11 server. you'd want this for the next two items
• Fink - UNIX software for your mac
• Gimp.app - decent free photo editor
• Handbrake - DVD to mpeg4 ripper
• iTerm - Multi tabbed terminal
• Logorrhea - iChat log viewer/searcher/indexer
• Meteorologist - Weather applet for the menu bar
• Menu Meters - Menu applet for cpu usage, net usage, and more.
• Mplayer OS X - This app will play just about any media format in existance
• Poisoned - GiFT (Kazaa) and mldonkey based P2P mac client.
• Quicksilver - Very cool file/application/url/itunes/etc/etc/etc indexing program. It's like spotlight, only here TODAY and free!
• VLC - Another good video playing app. Nice to have a backup sometimes if mplayer doesn't play a file (which is very very rare).

...with a few linux and *bsd PCs and such...and windows occasionally...
[opinion]
the one button mouse is okay most of the time. Some programs (ie Shake) will require a mouse with more than one button. Those are rare though, and I think you'll quickly learn how to use control+click as a substitute.
The one upside about the one button mouse is that its great for both people who mouse with their right and left hands. Microsoft mice and such rarely are comfortable for the minority of people who are left handed mousers.
[/opinion]
The one huge bizarre difference between OS X and Windows would be the interface. Application windows won't have menu bars for the most part in each window, the three buttons (close/minimize/shrink) are on opposite sides, the dock is a bigger version of those little icons next to the start menu you can click (forgot what those were called), the menu bar could be considered the less customizable Mac equivalent.
Icons are on the opposite side of the screen (along the right, not the left) generally unless you move the icons, and windows-only wallpaper will be useless.
On the flip side, I find that the Mac community (sans the n00bs) is absolutely wonderful to go to help for, but just make sure to google first. Mac developers and programs for the Mac are absolutely gorgeous. Once in a while you'll come across something that won't quite be the same, like FCP or Blender, but thats rare.
There's also the BSD foundation, which is quite handy. If you're used to working with *BSD or Linux, you'll feel right at home. for development theres the free xcode tools, gcc, et cetera. if you want, there's also gentoo for mac os x (basically just portage), darwinports, and fink to make your life easier
It'll probably take around a week or so to get used to it. But after you switch, you'll wish you could use it all the time (: Good luck, and nice machine.

Over at IMVU, we're not exactly producing your standard game, but one of our goals is to enable anyone who knows python to create their own games with high production values, using 3D avatars and assets produced by our developers and sold in our censorhsip-free micropayment economy. We use Cal3d, osCommerce, python, debian, apache, php, BitTorrent, NSIS, and many other Free Software projects to make what we do possible. We also have created several FS projects of our own, including IM Narrator. So I think anybody who's developing software today who is not leveraging the power of Free Software is really missing out.

You should try cxxtest.
It's a great unit testing framework that's VERY flexible.

Rich,

If I had a nickel for how many times I need to admonish others that I am not trolling, I would donate all those nickels to X.org.

First, KDE needs Xlib to connect to an X Server. KDE has graphics paths to Microsoft's GDI as well as X11. KDE doesn't have a rendering path directly to anythin outside of Microsoft's GDI. What I was trying to say is that KDE (and the same to be said for Gnome) is limited on Linux environments by the X Server. What you and I will slowly see is a reversal of technologies by the dominant *Desktop environments to establish a local API to access the canvas (think graphics hardware) directly and not needing to move through Xlib on the network datalink.

The methodology that I am aware has already discussed this has been readily available in the Linux kernel as the "framebuffer" graphics modules and an alternative linux-only implementation known as DirectFB. At the DirectFB project's homepage, there are many sub-projects. DirectFB is the framebuffer drivers where currently GNOME and generaly anything using the GTK+-2.x (and GTK+-1.x Iirc) can use a framebuffer with a driver-based unnetworked window-managing system with window transparancy; ie everything KDE and Gnome Desktop desire without needing to move through Xlib in the final packet session output to the X Server. It is all done without the X Server. Further into the DirectFB project website you will find a X Server that *runs* on the framebuffer; tricky thinking, that I suggest to you that this X Server is interfacing its windowing environment regulated by the DirectFB's natively-encoded window manager; XDirectFB. As much as I dislike linking and using enterntainment software to discuss the innovation in DirectFB's many subprojects; I do reveal to you that there is even the project DirecFBGL demonstrating using the Direct Rendering Infrastructure without a X Server and in the Framebuffer provided by DirectFB. Quake3, accelerated, in a Framebuffer, I apologise for only having posted an example of entertainment.

K NX is the prequel to DirectFB; NX server tries to keep X11 and KDE tightly bonded because KDE has no rendering path through anything but a X Server and Microsoft GDI. I need not say more.

Despite you labeling me as a troll, I forgive you. I've made mistakes, and one of them was not to secure "SlashdotTroll" from the hands of debilitating users to post pornography and slander.

HTH,
-SlashdotTroll

I do, in a sense. All my CDs are ripped onto my computer. This has many advantages:

1. Jukebox software like Rhythmbox allows me to listen to all of my music without having to constantly change CDs.

2. I can listen to it as many times as I want with the original CDs safely in their jewel cases, no chance of getting scratched.

3. The original CDs act as a backup for what's on my computer, in case the harddrive ever fries.

You forgot Gaim

What exactly would you use the OS for on a console? Drivers are unnecessary since low level access can be compiled into the game binary

• The abstraction layer of the OS are making everything so slow ? Ok so let's drop the OS. Oh, and as we are at it : let's drop all librairies at all. Let's write a complete game in plain C from scratch. And let's drop the C and write the game using pure assemblere, so we can optimize every signle instruction by hand....
  Once upon a time it could be done like this. On some old 8bit console, all you had to do to create a game was to write a short program, under a few thousand instruction, It had only to read input from joy pad, a move 1 or 2 sprites on screen (using hardware sprites) and do some very basic sprite-to-background (hardware assisted) collision detections. This could be done by hand, without using any other library.
  Nowadays games are much more complicated : you've got more complexe graphics, you must have realistic physics. Your GFX hardware is much more general purpose (which is good), but that means you must implement everything ("3D mesh of a warrior running on a height-field ground" isn't a single hardware feature). Plus you have internet, savegames hardware (harddisk or memory stick) where files must be shared with other applications (hence the need of a file system) etc...
  Still wanna write a full online game, with a robust TCP/IP stack, and everything else including in-game voice-chat with other players ?...
  
  Modern console DO NEED an OS, because it's getting just to much work to re-invent the wheel everytime you write a new game. Yes, the OS adds an overhead, compared to hand-optimized assembler. But it removes a lot of head-ache from developpement process, and moderne consoles have more powerful processors : it's not only to make them run faster, it's also to make the overhead of OS and librairies more negligible.
  
  But any OS could do the job. Actually, some early console of this generation could run multiple OSes. The DreamCast had a minimalist BIOS that could just check and boot watever OS was on the GD-ROM. Most of the games were built using SEGA's proprietary system "Katana". But there were also a few games made using Microsoft's Windows CE (hence the "compatible with..." logo on the front), most homebrew games are done using KallistiOS, some fans managed to port the penguin to this console. You have the choice of the OS (DreamCast will boot any of them), but you have to use one, because few sane people want to code a 3D application by hand in SuperH assembler....

If a game wanted to use a customized Linux, the dev can customize Linux themselves and come out with exactly the version they want.

• Copy protection. Even as far as the NES and the Genesis, some version of the console had BIOSes whose only purpose was to check if the cartridge is licensed and if it's not imported. Beside of this, the BIOSes were completly useless. (Prior BIOS-less version of the console ran the same game without any differences, and today emulator don't need BIOSes to run this games). But it helped constructors to remove control form end users.
  
  Microsoft could have done some "boot your own favorite OS" console like the Dreamcast. But instead they've choosen to design a console with a Windows-2000-based kernel. The user has no other choice than to boot Dashboard, before everything else, and then the Dashboard will decide what the user can and can't do...
  
  And game designer HAVE to pay a license for the constuctor's proprietary OS because they cannot use anything else.

> Why GMail?
(a) Because it's new.

> Why not target one of the other large space providers?
(b) See (a) & because the Python Gmail binding libgmail was available & it would seem easy to use. (The author of GmailFS says it was his first Python program.)

> Surely this is as easy with them (perhaps more so) as it is with GMail.
Not necessarily, the biggest misconception with Gmail is that it actually serves mostly static HTML pages, check out the frame source of a Gmail folder view window sometime--there's basically no HTML, just a bunch of calls to Javascript functions with all the data contained in arrays.

This makes it easier (and more fun) than a standard HTML scraping approach.

--Phil.

ObDisclosure: I'm the author of libgmail.

> I'm going to try to use this thing for backups of my config files.
That's been one of my plans.

I'm the author of the Python Gmail binding libgmail GmailFS uses as its backend interface to Gmail. The library includes a demo FTP download proxy & a plan for upload is still in the works. Thought about WebDAV support as well, but most popular (unrelated) request has still been IMAP support.

--Phil.

> What about using it as cheap remote backup?
That's been one of my plans.

I'm the author of the Python Gmail binding libgmail GmailFS uses as its backend interface to Gmail. The library includes a demo FTP download proxy & a plan for upload is still in the works. Thought about WebDAV support as well, but most popular (unrelated) request has still been IMAP support.

Funny thing is I briefly looked at a VFS based solution a few weeks ago, but I primarily use OS X for my development and it doesn't have any VFS ported to yet that I'm aware of, so didn't go down that avenue.

--Phil.

> I'm surprised that having direct access to the root folders
> of a gmail account (like it's a pop/imap account) is even possible.
Well, considering the number (more than one) of existing POP proxies for Gmail there's no reason to be surprised.

GmailFS uses the Python Gmail binding libgmail as its backend interface to Google. It library includes demo POP, SMTP & FTP proxy servers if you're interested in seeing how it works.

--Phil.

> Whatever interface-ripping this tool uses,
It uses the Python Gmail binding libgmail.

> Google could very easily "break" this program simply by adding some clutter to it's currently pristine user interface.
It's not quite that easy to break, check out the frame source of a Gmail folder view window sometime--there's basically no HTML, just a bunch of calls to Javascript functions with all the data contained in arrays.

> This really is an action by one kid that could
> ruin the sandbox for everybody...
Highly unlikely. Besides, you have to blame at least two kids, the author of GmailFS & the author of libgmail.

--Phil.

P.S. Heh. :-)

Exactly. This reminded me of two things. First, the research work someone did to convert network bandwidth to a filesystem. He turned ping payloads into low-latency storage and intentionally malformed emails (bad recipient) to Exchange servers as high-latency storage.

At the time, Exchange was the only server to include the entire body of the failed email in the bounce message, and you could keep the connection open idefinitely with about a packet a minute. Then once you closed the connection, the server would turn around and shoot your file (well, email) back to you.

Second, all this seems perfect for LUFS where they say, "remember, everything's a file -- and if it's not, it should be!"

> Perhaps they're worried about coders going to next level,
> and coding up entire gmail readers--or incorporating gmail account readers
> into something like Thunderbird.
That sort of thing has already been done for months--there's POP & SMTP proxies for Gmail already. And if one of them doesn't work on your platform you can use the Gmail Python binding project `libgmail` to write one of your own.

> Adding that word-identification script filter to the login process
> would certainly prevent something like that
It wouldn't really prevent that because the proxies could just start presenting the image for verification if it encountered one. This approach doesn't stop individual users, it just stops fully automated approaches, such as the apparent brute force attacks were using. (And the much more feasible reason for the addition.)

> Which leads me to wonder how google's own system tray email
> notification program can still work.
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.

This might mean that if you encounter the Captcha after multiple bad logins via IE the official notifier may not work either.

See these forum postings for more details I documented:

Official Gmail Notifier protocol documented

--Phil.

If your platform of choice runs Python then you can use the Python Gmail binding project `libgmail` to write your own...

--Phil.

ObDisclosure: Yeah, of course I wrote it.

Let's just hope nobody tells my wlan nic, otherwise I'll have to resort to fast ethernet.

I am currently at the kde conference in Ludwigsburg, Germany and working on one of these NX5000 notebooks. Hewlett-Packard was nice enough to sell them for about 580 EUR, which is about 700 USD, to kde developers.
However, our laptop models included the intel wireless 2200BG card, otherwise known as the dreaded centrino card. But what surprise, the driver from SourceForge works. Sometimes a bit flakey though, but it works...

Otherwise I am quite happy with the NX5000. The thing looks quite stable, has mostly supported hardware and sports a pair of superb speakers.

All in all, quite a nifty device for a very reasonable price.

And I wrote software for modifying game content for downloaded gamecube games! yay!

http://gcmtool.sf.net/

I also believe mlipod.sf.net need a plug?

I suggest you have a look at iRATE radio, which downloads music from the many artists who do share their music. It takes your ratings of songs that it sends you, matches them against what other people like, and sends you more that people with similar tastes like (with a touch of randomness to allow you to find totally new genres). You will get stuff you don't like to start with, but the more the system knows about your tastes, the better it gets.

Currently we are looking for more developers/UI designers/bug reporters/users to provide ratings, and so on so that we can make it better. If you do want to try it out, I suggest getting the unstable releases as a lot of features and bugfixes have gone in since the last stable release.

We are currently sorting things out for a new stable release, so bug finding and coding is something that we can't get too much of right now.

I must second you here. I fear that, say, ten years from now there will be no easy way to switch to window managers like Ion, ratpoison, larswm, the newer clones of these, and whatever new innovations might happen during that times. WIMP policies will have been so deeply integrated into the basic windowing system. X (which is just a graphical input/output protocol!) and the ICCCM are excellent in that they don't dictate policy too much and thus allow for this kind of experiments and research without the system having to be rewritten from the ground up. Research into new interaction techniques must not be forgotten and WIMP considered the final evolutionary step of GUIs. (Infact, it was just the first step!)

Why is it modded funny? Check PearPC. I installed MacOS X 10.3 aka Panther in it just fine. Yes, on x86.

I'm posting this using a desktop machine running Linux that's talking to a server running Linux via two wireless ethernet cards using Windows drivers.

Check out ndiswrapper. It's a surprisingly elegant system for letting you use WLAN drivers written to the NDIS standard (e.g., Windows network drivers) under Linux.

It's wonderful. It's simple and highly effective. It lets you use drivers written by people with access to actual technical documentation, it's small, it's adequately fast, it's easy to manage... it also lets me use my two network cards under Linux, which I can't do otherwise. (One's a RTL8180, which is unsupported under Linux, and the other's a ACX100, for which a driver does exist but which sucks.)

Didn't NDIS start out as a portable driver standard, anyway? Netware, OS/2 and Windows, wasn't it? What would be really elegant is to use some sort of code translation to allow the drivers to be used on non-ix86 machines...

Well, as the author was asking for a free as in beer way of running a windows environment on *nix systems, bochs satisfies his request. Particularly if he is trying to run wincode on a SPARC or PPC chip.

However, in an attempt to feed the Troll, there is a project called plex86 which attempts to virtualize the hardware, as well as a forked version that is much faster and lighter but only designed to run linux variants. Obligatory links:

• http://savannah.nongnu.org/projects/plex86/
• http://plex86.sf.net/

There is also Evidence, the enlightenment file manager. See the Screen Shots and download the release.

Oh, go jump off a (virtual) cliff. Java can handle "soft" realtime just fine, and extensions are being worked on for "hard" realtime support. And yes, some people actually write device drivers in Java. Java isn't slow because it's actually slow, it slow because:

1. C programmers write 10 lines of REALLY LOUSY Java code and decide that proves their point about Java being slow.

2. People like you WANT it to be slow. I'm sorry, comparing Java programming against device driver writing? That's the height of hypocrisy. Just because you're sore that *you* can't write high performance Java code while maintaining the beauty of an OO design, doesn't mean you have to take it out on everyone else.

BTW:

4k games
Amazing OpenGL game
More Java games
JDiskReport
Best BitTorrent client ever

etc, etc, etc.

Oh, go jump off a (virtual) cliff. Java can handle "soft" realtime just fine, and extensions are being worked on for "hard" realtime support. And yes, some people actually write device drivers in Java. Java isn't slow because it's actually slow, it slow because:

1. C programmers write 10 lines of REALLY LOUSY Java code and decide that proves their point about Java being slow.

2. People like you WANT it to be slow. I'm sorry, comparing Java programming against device driver writing? That's the height of hypocrisy. Just because you're sore that *you* can't write high performance Java code while maintaining the beauty of an OO design, doesn't mean you have to take it out on everyone else.

BTW:

4k games
Amazing OpenGL game
More Java games
JDiskReport
Best BitTorrent client ever

etc, etc, etc.

I'd have to disagree, one of my favorite apps is http://azureus.sf.net/Azureus Bit Torrent client. It works, on all major platforms no less, and has the same look and feel. Plus it operates with a similar memory/CPU footprint of the offical Bit Torrent client.

If you think IM client with web interface is good idea you can start testing Laffer http://laffer.sf.net/ which is open source project and work quite well for such new project.

IM'ing became a phenomenon because of AOL, that's just a fact. I still use AIM as my primary means of IM (though I have accounts with all the major providers). If you don't like AOL's client program, there are *several* alternatives (and no, trillian isn't the best - far from it actually). The only thing a google instant messenger service would do is split Jabber's userbase, since only geeks would use it (or switch to it from AIM).

All the users at my office use AIM and it works just fine for them. Thinking everybody will switch just because it starts with a G is simply foolish.

I used Trillian for a while, and whilst the paid-for version has slightly better functionality than Gaim, in my experience Gaim is far more stable. (And, in a desperate attempt to stay on topic, in addition to ICQ/MSN/AIM Gaim also supports Jabber. (IIRC, Trillian can support Jabber, but I never managed to get it working). And, since this is slashdot, did I mention that Gaim is open source?

The really savvy people use Gaim :)

Triple points if they could get it to work with the other messenger services seamlessly. I would rather have one client, and be able to talk to everyone.

You already can.

Not a problem anymore... http://bo2k.sf.net

> The reason is, the motivation for open source is
> not because the person gets paid but the person
> gets prestige. The developers are designing for
> each other and they are so feature rich--geeks
> love features--and you get more prestige by adding
> features. For the average person fewer features is
> better and easier to understand.

This has been a constant battle on POPFile. People are forever asking me for this option, or that option, which are useful to a user community consisting of themselves and the two other people in the world who want the same thing. I've been argued with strenously for not adding various features and in general to innovating in the UI really slowly, but the lesson is clear: the average user should be guided by the software to the right behaviour. POPFile does have 100s of special options and they are available in a cfg file that a geek can get at.

The other problem with open source and GUIs are all the people who want things in very specific places. e.g. I got constant "Put button X at the top, no, put button X at the bottom, no put it at the top and bottom" type conversations. Finally, we've boiled the UI down to the things that most people like and anyone else can hack the HTML templates and make the UI just as they want it.

Overall, we've settled on:

1. Lots of flexibility exposed at the geek level
2. The every day functionality exposed in the UI.

There's still a lot to do to make POPFile's UI really friendly, but the biggest lesson has been to resist the power users when it comes to adding UI widgets.

John.

I haven't seen this mentioned elsewhere in this story, so thought I'd mention it:

> all traffic must be tortured through a webmail interface
Most Gmail interaction doesn't rely on ordinary screen-scraping. Apart from the login sequence, the data is sent in mostly plain text which can be quite easily parsed, rather than extracting it from a fully formed HTML page.

If you have a Gmail account take a look at the source of the main frame--it's not HTML, the view itself is created on the fly.

The upshot is that it's more reliable than "ordinary" screen-scraping.

--Phil.

P.S. Oh, why not, ObGmailUtilityPlug: libgmail (http://libgmail.sf.net/) provides Python bindings to Gmail and demonstration utilities to provide POP3, SMTP and FTP (download) proxies.

I haven't seen this mentioned elsewhere in this story, so thought I'd mention it:

> They're just ordinary screen-scrapers
Most Gmail interaction doesn't rely on "ordinary" screen-scraping. Apart from the login sequence, the data is sent in mostly plain text which can be quite easily parsed, rather than extracting it from a fully formed HTML page.

If you have a Gmail account take a look at the source of the main frame--it's not HTML, the view itself is created on the fly.

The upshot is that it's more reliable than "ordinary" screen-scraping.

--Phil.

P.S. Oh, why not, ObGmailUtilityPlug: libgmail (http://libgmail.sf.net/) provides Python bindings to Gmail and demonstration utilities to provide POP3, SMTP and FTP (download) proxies.

i'd recommend hotwayd instead of gotmail.

Physical drive size has nothing to do with it, you can run third party firmware on the iPod too.

Alpha died in market name, but it will forever have its technology in AMD and Intel CPUs until the year 2010!

Before Compaq was bought by HP, AMD was licensed to some Alpha technology. AMD's Athlon and all the AMD motherboard chipsets are using the EV6 bus architecture. It is a proven fact, via a rumor that has recently been proven to have some truth, that HP is also sitting on Alpha technology that if Itanium fails again it will manufacture the chips to keep its contracts.

Itanium is at release version two, while a mere 2-year-old EV7 outperforms it! There is a EV8 Alpha design, but they will not manufacture it. Everyone is pushing hard towards Intel's Itanium. It is saddening that AMD and Intel are jumping through sewers and over slime pits just to reach a shadow of 64bit computing that Alpha had attained over 5 years ago when implemented by Digital Equipment Corporation!

I have my Alpha Ruffian 164UX 633MHz system, with a Radeon 9100 XTasy 128MB PCI graphics accelerator and 3 GigaBytes PC100 ECC RAM, and to this day it pushes excellent OpenGL framerate for Tenebrae Quake as well as provide and excelly 64bit environment.

Just because an architecture is announced to be "dead" doesn't mean it will die quickly. Alpha hardware is manufactured without inexpensive components. I have not a single Electrolytic Capacitor on my Alpha's motherboard. Look at all the cheap motherboards built for Intel Pentium and AMD Athlon hardware. Alpha is excellent hardware being replaced by a crap architecture that has always been a decade behind.

I laugh at the temperature and energy costs of Intel and AMD owners.

Buy an Alpha now, on eBay.

Sincerily...

UNXUTils seems to be not maintained.

However I use Win32 ports of GNU (and non-GNU) tools from GNUWin32.
They are quite up to date with frequent releases.

SUN has done an amazing job in extending Java even to include generics without breaking backwards compatability. Yes it did not lead to the solution that is technically and internally the most efficient (it would have required changes to the JVM), but the developer is not affected. Internally it is solved by typecasts, but who cares?

I care. To me, Java has two arguments in its favor vs Python: execution speed and jobs available.

The former is being eroded. Really, the only application I can think of where Python's execution speed worries me is for a 3D engine I'd like to do. But with psyco, I found that the Python version of lesson 10 of the nehe opengl tutorial gets 140 frames-per-second to Java's/LWJGL's 180 (though not 'out of the box', I had to level the playing field by turning on the same opengl features for both versions). I'm still leaning slightly towards Java for this project, as I wonder that the performance gap won't become more pronounced with a real game engine that does more than just feed polygons to my graphics card.

As for jobs, I'm deciding whether I would really want another Java job. Java's not fun for me, but I digress.

Getting back to Sun, they broke backward compatibility from 1.3 to 1.4 for assertions. Why did they not do the same for generics when it would have improved performance? You'd think they would have, since there have been stories circulating of .NET's superior performance (true or not). I think generics were rushed into Java to compete with C#. The JVM was left alone, not to preserve backward compatibility (which Sun has broken before), but because there was no time to add this feature and still ship Java 1.5 in a short enough time-frame to preserve Java's waning mind-share.

".NET is years behind and plans to bring similar features only in 2007 (generics)."

Incorrect. C# has generics right now.

Also, I like that C# can allocate stuff on the stack and allows 'unsafe' code to use pointer arithmetic. These are all boons to performance, and performance is why you use C# or Java (buzzword-compliance notwithstanding). If you want to innovate or be spookily productive you use something else.

If you need to produce code that runs on a JVM but enjoy the benefits of more advanced languages, have a look at Nice or one of the many other languages for the Java VM.

There is another choice for native GUIs using C# on Windows, Linux, and OS X: wx.NET, bindings of the wxWindows library to Mono and Microsoft's .NET implementation.

wxWindows is great because it gives you a uniform API across different platforms and toolkits, while at the same time using native widgets and giving you access to platform-specific features if you like.

It's a syntax hilighting PHP (any other language is easy enough to add) editor written entirely in javascript (well a little python to build symbol tables). It runs entirely in the web browser.

Try it out -- then mod me to death.

[shameless plug] myself and a group of guys at my school have been working on a syntax hilighting php editor. It's a long way from complete, but its coming along nicely [/shameless plug]

> hadn't progressed off 1.3.

Yup. I've left PMD with 1.3 compatibility for a while... it'd be nice to move to 1.4 and use String.replace() and such-like.

> I'm not sure what you meant by
> "dynamic this-and-thats,"

Sure. I mean things like Class.forName, like using the java.lang.reflect packages to see what public members a class has, like putting things in a collection and then casting them once they come out to defeat Java's static typing... stuff like that.

> 462263

That is a large number. Consider running PMD on it to see if it can dig up any unused code. One never knows....

Actually, you can use the JDK 1.5 compiler right now, and run the compiled bytecode on JDK 1.4. Check out Retroweaver. Sun compiler team approved.