Shipping a 32-bit browser requires much more than distributing a different build. You also need 32-bit versions of all of the browser's runtime dependencies.
On my box, I see at least the following dependencies for Firefox 3:
So, you'd need 32-bit builds of pthread, libc, libgcc, libstdc++, etc., which implies pretty much a complete 32-bit runtime. I also suspect that GLib and Gtk+ should be in that list, which would further bloat the redundant set of libraries.
After a certain point, you should probably just run the browser inside a 32-bit virtual machine, hosted on a 64-bit OS, since you're already going to have to distribute about half a complete distro in runtime requirements.
I'm constantly surprised at how often I have to explain the Kerberos protocol, and why it works so well for many SSO situations, to otherwise experienced and knowledgeable developers. Especially in the web space, there seems to be approximately zero awareness of Kerberos, which constantly leaves people inventing new authentications mechanisms without the benefit of the strong formal and pragmatic review and hardening Kerberos has received over the years.
Coupled with something like WebAuth or Cosign, it even makes a pretty good website authentication mechanism. Also, sites using Kerberos for user authentication can also use it to protect user data on the backend, by forcing the web server to re-authenticate using delegated user credentials before performing privileged updates on backend databases. (PostgreSQL and Oracle both support Kerberos auth, as do most LDAP directories and many network filesystems.)
This is very true and works very efficiently. ..However, do you really think Microsoft would agree to use something for security that it didn't develop or create. ..Without Microsoft's high level security functions can you imagine how many developers would be out of work, without the ability to secure all of the flaws
Actually, MS does use Kerberos, and has supported it pretty well as the default authentication mechanism for Windows domain clients since Win2k.
Unfortunately, they also still support NTLM hashes for compatibility with "Home" editions of Windows, which means that it's almost always easier to just attack those weak hashes on the server or flying over-the-wire than it is to go after the Kerberos key store.
When I'm feeling less-than-excited about work, I'll take the time to do something random but interesting for a few weeks. Recent things I've tried: volunteer for a political campaign; learn to make bacon and sausage; take a graduate CS class at the local university.
Each one has given me a better sense of perspective about the relative importance and value of my job, and most have taught me things that were worth applying at the office.
At the very least, having something current other than TV shows and weather to talk about with my co-workers makes me feel like a more well-rounded individual, and makes getting through the work day that much easier.
> (Turns out to be a route for some annoying door-to-door salesman. > Boy, wonder what he feels like when he finds out someone sent a > completely misleading solution! At least sanity-check them first =)
[begin CS wankery] Actually, verification of a solution to any NP-complete problem (like traveling salesman) can be done in polynomial time, so you could completely automate that part. [end CS wankery]
I'm not sure why you would think that being a bike messenger is "not stressful," but I can't imagine that being narrowly-missed (or hit) by cars and getting yelled at by stressed-out business people while trying to rush *everywhere* could be that much more relaxing than sitting in a cubicle all day.
Don't get me wrong: I relish my time in the saddle outside of work, but I'm also glad that I don't have to put up with all that crap, especially given how little bike messengers get paid.
Leave most of that crap at home. Walking around with an iPod and a digital camera is probably the best way I can think of to mark yourself as a rich tourist if you're in the developing world, and almost equally likely to guarantee you don't really interact with anything or anyone you encounter.
Do take a camera, but make it as old-fashioned and cheap-looking as possible. If you're not comfortable with, say, and old manual SLR, look for something like the Olympus Stylus Epic. It's autofocus and auto-exposure, runs forever on one battery, and has weather sealing as good as most professional-grade SLRs. A tripod isn't a bad idea, though one of the monopod/walking stick combo units might be more useful if you expect to do any real hiking.
Keep your notes in a Moleskin or on an old Palm device that runs on AAAs. If you absolutely must blog about the experience while you're on the road, do it from internet cafes.
Unforuntately, Cingular at least does not allow unsigned MIDlets (including FloydSSH) to open socket connections. The Nokia tablet is a truly open platform, allowing you to run any software you can compile for (or on) it.
Automakers publish guidelines for vehicle maintenance, and owners who fail to perform "reasonable" upkeep (changing the oil and tires, checking diagnostic codes when the "check engine" light is on, etc.) are seen as liable for many potential failures.
If we're to emulate automotive engineering, shouldn't users be essentially the ones at fault, as most completely fail to respect the most basic preventative maintenance procedures? If you keep up-to-date on your security patches and virus definitions, don't click on attachments or download software from unknown vendors, etc., your exposure to potential security holes should be entirely manageable.
Plus, drivers are expected to be licensed and insured, and therefore vetted by a number of authoritative sources as having the basic knowledge needed to responsibly operate a motor vehicle. Since any schmuck with $400 in his pocket can buy a beige-box PC and go online, can you really hold software vendors or developers responsible for every way they find to get themselves 0wned?
One skilled in the art will appreciate that preferred embodiments of the method of the present invention may take on many different forms depending on the particular application intended. In light of this, the preferred embodiment presented here has been designed primarily to teach many of the important aspects and implications of the method of the present invention in a context which can be readily learned. Once taught the method, one skilled in the art will appreciate many alternative and preferred means for implementing individual aspects of it, depending upon their specific purpose.
After re-reading that a few times, I think I've figured out that it's basically saying that this isn't an invention, it's a philosophy. This is so fscking general it could be equally validly applied to hypermedia, or frame logic, or tuple spaces, or any of the thousands of schema-less data representation models out there.
Really, the whole patent begs the following three obvious questions:
The icons are actually from Thunderbird, so I would assume that there won't be any legal problems.
Design-wise, this really does beat most any webmail interface (and event many native mail clients) I've seen pretty handily. Even Zimbra has that awful "brushed plastic" look, wheras RoundCube sticks with a much cleaner smooth gradient look.
This is also one of the least-intuitive HCI events I've ever seen. Even as a "power user", I often find myself doing the drag-and-drop with the left mouse button, realizing my mistake, and having to start over with the right button.
It adds timing constraints (right click and drag vs. simple right click) that, like double clicking, auto-rename of a selected item, and a handful of other "convenience" actions, have been the result of far too many hours of my life being spent explaining various types of finger-judo to family, friends, and coworkers.
The entire user experience on the Mac has always been cleaner and simpler than it was on Windows, which is a major selling point for me, and a reason I recommended Macs to inexperienced users. OS X has been walking the line between the maintenance of this ease of use and the introduction of new "power tools" and features to help the workflow of pros, (see Expose, for example) but dumping lame interaction ideas from Windows into it won't help.
FYI, Firefox (like all does have pre-defined sets of permissions that cover a number of more fine-grained access rules. I've written packages of Javascript code (not extensions, just an in-page library) that do local I/O to assist the user with software installation tasks, and they produce the standard "this Javascript is requesting the following permissions:..." messages, giving the user the chance to opt-out of letting the code run.
In addition, there's full support for cryptographically signing extensions to allow "trusted" sources to run code without exposing your machine to rogue scripts from any host claiming to be, for example, mozdev.org. Unfortunately, there are effectively zero signed extensions in the wild. If developers were accustomed to having to acquire a cert and sign every piece of code they released, many common security problems with code pulled from the net could probably be avoided.
You want seperate "run-as" permissions for individual chunks of Javascript code? Fine, you write the code that runs a Javascript interpreter that shares access to the current browser's complete object model, (incl. active page DOMs) but is hosted in a seperate process running under those other credentials.
Then, make it more secure than the current (entirely decent) Firefox security sandbox. Oh, and make sure it's completely cross-platform -- Windows, Mac OS, and *NIX all have pretty much identical security and process models, right?
I'm not trying to be a jerk here, but you really need to realize how difficult the problem you're casually throwing around is.
Firefox does have a security sandbox for all Javascript code running in the browser -- you have to request access to any XPCOM objects that handle local or network I/O, user and preferences data, etc. However, once you've downloaded and installed an extension, it is considered "trusted," and can access those objects freely.
Remember, though, this is only for extensions, not arbitrary Javascript loaded from a remote site. Yes, that puts a burden on the extension writer (and the user) to verify the security of their code, but it's no different from ActiveX, or downloading and then running any other executable code from the net.
For most users, the idea of manually setting ACLs for Javascript API calls is going to shoot right over their head. Remember, we're talking about a population that still has a tendency to double-click on email attachments before thinking about the trustworthiness of the source.
In other words, the decision about how to handle extension code security is a usability issue, too.
If PHP may be loaded in a multi-threaded Apache server, and uses an extension module which depends on libraries which are not thread-safe, then the affected PHP module (and/or the underlying library) is broken, not Apache2.
Really, people. This is like telling people not to switch from a 2.2 kernel to 2.6, because your app breaks under everything newer than 2.2.19 or something, and you can't be bothered to find out why and fix it.
I went to a Japanese immersion high school, and we used our technology resources for two major things: multimedia production, and access to reference materials such as encyclopedias, Japanese/English dictionaries, etc.
Skills like desktop publishing, A/V creation and editing, and programming were not taught in seperate classes or even as subjects in their own right. Instead, students worked on quarterly projects that included research, design, and presentation of their finished product. That meant that we had to learn how to use the tools and techniques required for each project in context, not in the abstract.
That required that the basic equipment and software (Macs and PCs, audio and video recording gear, media editing software, word processors, programming tools) were left openly available to students, both during regular classes and outside of school. We had deadlines for the projects, and the help of teachers in finding basic reference materials, but it was up to us to figure out which tools we needed, and then to share or develop the knowledge needed to utilize them.
Second, and probably even more significantly, the teaching staff recognized their limited technical expertise, and actively encouraged students to train each other and learn from each others' experience. By integrating research, writing, media, and public performance into the projects, it was also possible to involve every student in the group's work -- techies like me could do media and Internet research, artistic kids could handle original art, costumes, etc., and the socially-gifted ones could be the public voice as actors or speakers.
In short, the smaller and more limited your resources, the more I think you gain by basically letting the kids just experiment with what's available. It requires trust to let a 14 year-old take a school-owned DV camera home for the weekend, or work in a computer lab for hours after school with only minimal supervision, but the results will astound you.
If you want a shopping list, get as much as possible of the following:
* PCs or Macs stuffed with media production tools (Linux boxes might be a good choice if your software budget is small) * Solid video editing (think FCP Express, not iMovie) and audio editing and sequencing software * Several decent video cameras, tripods, microphones, etc. (pref. with cases that put everything into a package a kid can take home) * Projectors or large monitors with laptops, desktops on carts, or at least DVD players, for presentations * Up-to-date CD-ROM or web-based encyclopedias and language dictionaries -- pay for these if you need to, as bad research info will mean bad conclusions * CD burners for student projects, backups, and portfolios (the latter being very, very cool and motivating) * High-level programming tools for media (Flash, SuperCard, iShell) and simulation (Stella, Swarm) * Photoshop/Gimp, Illustrator/Inkscape, Frontpage/Bluefish, etc., etc.
In short, give the kids access to pro-grade (or at least searious amateur-level) tools, and they may well just produce some scarily professional work.
Re:It's like a BSD golden age lately
on
OpenBSD 3.6 Released!
·
· Score: 2, Informative
No way there was a PPC NeXT box -- they had already ported the OS to X86 by the time the 601 hit production. My guess is that you're remembering a BeBox review.
Ruby has first-class functions; you just have to disambiguate them syntactically, since bare property access (like foo.bar) is actually calling method bar on the object foo. So, if you want to reference the method explicitly, you have to write foo.method(:foo), which returns a Method instance which can be invoked or used like any other scalar value.
So, while in Python, you might write something like this: controller.set_handler('some_action', myObject.handle_some_action) ...the Ruby idiom would be one of the following: controller.set_handler('some_action', myObject.method(:handle_some_action))
The extra method(...) syntax is needed to ensure that all communication between objects is via method calls, rather than direct property access. Python allows you to directly assign to and read from object attributes, much like public members in C++ or Java classes. Ruby forces all attribute access to be wrapped in get/set methods, but provides a lot of support to make implementing those methods effectively automatic.
The latter example also uses a code block, cover many cases where first-class functions would be otherwise -- they're basically a compact syntax for lambda expressions, and prevent you from needed sugar like list comprehensions in most situations.
For example, instead of the following Python list comprehension: [x*2 for x in myArrayOfValues if x % 3 == 0]
...you would use this: myArrayOfValues.map {|x| x*2}.find_all {|x| x % 3 == 0}
Blocks are also a general idiom used throughout the standard library and most Ruby code in the wild. You can use them to write callbacks, query databases, and even to build domain-specific languages (another traditional stronghold of functional languages).
Really, though, neither Ruby or Python is a truly functional language; both borrow from the more "academic" languages those features and concepts they find useful, and leave behind those that the maintainers and users don't want, need, or understand. (Except for continuations, of course -- Ruby has those, and I would guess that only a very small percentage of Ruby coders ever grok them.)
GNU ld on Itanium also can't load IA-32 shared objects, which makes binary compatibility much less useful than it would be otherwise. I don't know about you, but I tend to use dynamic loading quite a bit in most of my significant projects.
In the announcement they note that Ruby scripting has been added in this version, so presumably you could actually add quite sophisticated game logic. It just depends on how rich they made the scripting API.
Pretty much all Japanese fonts include Roman characters, so this shouldn't be a problem. You may have a hard time *entering* lots of English text, but I suppose you could always just create it a normal text editor and import/copy-and-paste it into the application.
Re:Server is already slow - here's the text
on
iPod Mini Autopsy
·
· Score: 1
I know the guy, and he's definitely working on a Mac. The iPod hard drives are all FAT32 formatted, IIRC, so it probably would have mounted successfully if the CF drives weren't crippled (as a number of other articles have already reported).
This doesn't put a SQL interface on top of Java objects, or even support serialization of said data to rows in the database. It just lets you extend the range of user-defined functions (i.e., data type conversions, aggregate operators, etc.) to those implemented in Java.
Anyone care to weigh in with an example of their successes (or lack thereof) running an equivalent.NET/Vistual Studio/IIS dev environment on a machine with 128MB of RAM?
Sorry for the dig, but I'm consistently astounded by the gains that all of the major open source Java and desktop tools have made in their efficiency and reliability. I still remember being completely fsck'd by the overhead of green threads with the IBM JDK 1.1.X on a 2.2 kernel whenever I tried to run more than one JVM instance at once...though it was good for building stingy habits w.r.t. runtime object (and esp. thread) allocation.
Slashdot Mirror
Shipping a 32-bit browser requires much more than distributing a different build. You also need 32-bit versions of all of the browser's runtime dependencies.
On my box, I see at least the following dependencies for Firefox 3:
So, you'd need 32-bit builds of pthread, libc, libgcc, libstdc++, etc., which implies pretty much a complete 32-bit runtime. I also suspect that GLib and Gtk+ should be in that list, which would further bloat the redundant set of libraries.
After a certain point, you should probably just run the browser inside a 32-bit virtual machine, hosted on a 64-bit OS, since you're already going to have to distribute about half a complete distro in runtime requirements.
I'm constantly surprised at how often I have to explain the Kerberos protocol, and why it works so well for many SSO situations, to otherwise experienced and knowledgeable developers. Especially in the web space, there seems to be approximately zero awareness of Kerberos, which constantly leaves people inventing new authentications mechanisms without the benefit of the strong formal and pragmatic review and hardening Kerberos has received over the years.
Coupled with something like WebAuth or Cosign, it even makes a pretty good website authentication mechanism. Also, sites using Kerberos for user authentication can also use it to protect user data on the backend, by forcing the web server to re-authenticate using delegated user credentials before performing privileged updates on backend databases. (PostgreSQL and Oracle both support Kerberos auth, as do most LDAP directories and many network filesystems.)
This is very true and works very efficiently. . .However, do you really think Microsoft would agree to use something for security that it didn't develop or create. . .Without Microsoft's high level security functions can you imagine how many developers would be out of work, without the ability to secure all of the flaws
Actually, MS does use Kerberos, and has supported it pretty well as the default authentication mechanism for Windows domain clients since Win2k.
Unfortunately, they also still support NTLM hashes for compatibility with "Home" editions of Windows, which means that it's almost always easier to just attack those weak hashes on the server or flying over-the-wire than it is to go after the Kerberos key store.
When I'm feeling less-than-excited about work, I'll take the time to do something random but interesting for a few weeks. Recent things I've tried: volunteer for a political campaign; learn to make bacon and sausage; take a graduate CS class at the local university.
Each one has given me a better sense of perspective about the relative importance and value of my job, and most have taught me things that were worth applying at the office.
At the very least, having something current other than TV shows and weather to talk about with my co-workers makes me feel like a more well-rounded individual, and makes getting through the work day that much easier.
> (Turns out to be a route for some annoying door-to-door salesman.
> Boy, wonder what he feels like when he finds out someone sent a
> completely misleading solution! At least sanity-check them first =)
[begin CS wankery]
Actually, verification of a solution to any NP-complete problem (like traveling salesman) can be done in polynomial time, so you could completely automate that part.
[end CS wankery]
I'm not sure why you would think that being a bike messenger is "not stressful," but I can't imagine that being narrowly-missed (or hit) by cars and getting yelled at by stressed-out business people while trying to rush *everywhere* could be that much more relaxing than sitting in a cubicle all day.
Don't get me wrong: I relish my time in the saddle outside of work, but I'm also glad that I don't have to put up with all that crap, especially given how little bike messengers get paid.
Leave most of that crap at home. Walking around with an iPod and a digital camera is probably the best way I can think of to mark yourself as a rich tourist if you're in the developing world, and almost equally likely to guarantee you don't really interact with anything or anyone you encounter.
Do take a camera, but make it as old-fashioned and cheap-looking as possible. If you're not comfortable with, say, and old manual SLR, look for something like the Olympus Stylus Epic. It's autofocus and auto-exposure, runs forever on one battery, and has weather sealing as good as most professional-grade SLRs. A tripod isn't a bad idea, though one of the monopod/walking stick combo units might be more useful if you expect to do any real hiking.
Keep your notes in a Moleskin or on an old Palm device that runs on AAAs. If you absolutely must blog about the experience while you're on the road, do it from internet cafes.
Unforuntately, Cingular at least does not allow unsigned MIDlets (including FloydSSH) to open socket connections. The Nokia tablet is a truly open platform, allowing you to run any software you can compile for (or on) it.
Automakers publish guidelines for vehicle maintenance, and owners who fail to perform "reasonable" upkeep (changing the oil and tires, checking diagnostic codes when the "check engine" light is on, etc.) are seen as liable for many potential failures.
If we're to emulate automotive engineering, shouldn't users be essentially the ones at fault, as most completely fail to respect the most basic preventative maintenance procedures? If you keep up-to-date on your security patches and virus definitions, don't click on attachments or download software from unknown vendors, etc., your exposure to potential security holes should be entirely manageable.
Plus, drivers are expected to be licensed and insured, and therefore vetted by a number of authoritative sources as having the basic knowledge needed to responsibly operate a motor vehicle. Since any schmuck with $400 in his pocket can buy a beige-box PC and go online, can you really hold software vendors or developers responsible for every way they find to get themselves 0wned?
From patent #5,842,213:
After re-reading that a few times, I think I've figured out that it's basically saying that this isn't an invention, it's a philosophy. This is so fscking general it could be equally validly applied to hypermedia, or frame logic, or tuple spaces, or any of the thousands of schema-less data representation models out there.
Really, the whole patent begs the following three obvious questions:
The icons are actually from Thunderbird, so I would assume that there won't be any legal problems.
Design-wise, this really does beat most any webmail interface (and event many native mail clients) I've seen pretty handily. Even Zimbra has that awful "brushed plastic" look, wheras RoundCube sticks with a much cleaner smooth gradient look.
This is also one of the least-intuitive HCI events I've ever seen. Even as a "power user", I often find myself doing the drag-and-drop with the left mouse button, realizing my mistake, and having to start over with the right button.
It adds timing constraints (right click and drag vs. simple right click) that, like double clicking, auto-rename of a selected item, and a handful of other "convenience" actions, have been the result of far too many hours of my life being spent explaining various types of finger-judo to family, friends, and coworkers.
The entire user experience on the Mac has always been cleaner and simpler than it was on Windows, which is a major selling point for me, and a reason I recommended Macs to inexperienced users. OS X has been walking the line between the maintenance of this ease of use and the introduction of new "power tools" and features to help the workflow of pros, (see Expose, for example) but dumping lame interaction ideas from Windows into it won't help.
FYI, Firefox (like all does have pre-defined sets of permissions that cover a number of more fine-grained access rules. I've written packages of Javascript code (not extensions, just an in-page library) that do local I/O to assist the user with software installation tasks, and they produce the standard "this Javascript is requesting the following permissions: ..." messages, giving the user the chance to opt-out of letting the code run.
In addition, there's full support for cryptographically signing extensions to allow "trusted" sources to run code without exposing your machine to rogue scripts from any host claiming to be, for example, mozdev.org. Unfortunately, there are effectively zero signed extensions in the wild. If developers were accustomed to having to acquire a cert and sign every piece of code they released, many common security problems with code pulled from the net could probably be avoided.
You want seperate "run-as" permissions for individual chunks of Javascript code? Fine, you write the code that runs a Javascript interpreter that shares access to the current browser's complete object model, (incl. active page DOMs) but is hosted in a seperate process running under those other credentials.
Then, make it more secure than the current (entirely decent) Firefox security sandbox. Oh, and make sure it's completely cross-platform -- Windows, Mac OS, and *NIX all have pretty much identical security and process models, right?
I'm not trying to be a jerk here, but you really need to realize how difficult the problem you're casually throwing around is.
Firefox does have a security sandbox for all Javascript code running in the browser -- you have to request access to any XPCOM objects that handle local or network I/O, user and preferences data, etc. However, once you've downloaded and installed an extension, it is considered "trusted," and can access those objects freely.
Remember, though, this is only for extensions, not arbitrary Javascript loaded from a remote site. Yes, that puts a burden on the extension writer (and the user) to verify the security of their code, but it's no different from ActiveX, or downloading and then running any other executable code from the net.
For most users, the idea of manually setting ACLs for Javascript API calls is going to shoot right over their head. Remember, we're talking about a population that still has a tendency to double-click on email attachments before thinking about the trustworthiness of the source.
In other words, the decision about how to handle extension code security is a usability issue, too.
If PHP may be loaded in a multi-threaded Apache server, and uses an extension module which depends on libraries which are not thread-safe, then the affected PHP module (and/or the underlying library) is broken, not Apache2.
Really, people. This is like telling people not to switch from a 2.2 kernel to 2.6, because your app breaks under everything newer than 2.2.19 or something, and you can't be bothered to find out why and fix it.
I went to a Japanese immersion high school, and we used our technology resources for two major things: multimedia production, and access to reference materials such as encyclopedias, Japanese/English dictionaries, etc.
Skills like desktop publishing, A/V creation and editing, and programming were not taught in seperate classes or even as subjects in their own right. Instead, students worked on quarterly projects that included research, design, and presentation of their finished product. That meant that we had to learn how to use the tools and techniques required for each project in context, not in the abstract.
That required that the basic equipment and software (Macs and PCs, audio and video recording gear, media editing software, word processors, programming tools) were left openly available to students, both during regular classes and outside of school. We had deadlines for the projects, and the help of teachers in finding basic reference materials, but it was up to us to figure out which tools we needed, and then to share or develop the knowledge needed to utilize them.
Second, and probably even more significantly, the teaching staff recognized their limited technical expertise, and actively encouraged students to train each other and learn from each others' experience. By integrating research, writing, media, and public performance into the projects, it was also possible to involve every student in the group's work -- techies like me could do media and Internet research, artistic kids could handle original art, costumes, etc., and the socially-gifted ones could be the public voice as actors or speakers.
In short, the smaller and more limited your resources, the more I think you gain by basically letting the kids just experiment with what's available. It requires trust to let a 14 year-old take a school-owned DV camera home for the weekend, or work in a computer lab for hours after school with only minimal supervision, but the results will astound you.
If you want a shopping list, get as much as possible of the following:
* PCs or Macs stuffed with media production tools (Linux boxes might be a good choice if your software budget is small)
* Solid video editing (think FCP Express, not iMovie) and audio editing and sequencing software
* Several decent video cameras, tripods, microphones, etc. (pref. with cases that put everything into a package a kid can take home)
* Projectors or large monitors with laptops, desktops on carts, or at least DVD players, for presentations
* Up-to-date CD-ROM or web-based encyclopedias and language dictionaries -- pay for these if you need to, as bad research info will mean bad conclusions
* CD burners for student projects, backups, and portfolios (the latter being very, very cool and motivating)
* High-level programming tools for media (Flash, SuperCard, iShell) and simulation (Stella, Swarm)
* Photoshop/Gimp, Illustrator/Inkscape, Frontpage/Bluefish, etc., etc.
In short, give the kids access to pro-grade (or at least searious amateur-level) tools, and they may well just produce some scarily professional work.
No way there was a PPC NeXT box -- they had already ported the OS to X86 by the time the 601 hit production. My guess is that you're remembering a BeBox review.
Ruby has first-class functions; you just have to disambiguate them syntactically, since bare property access (like foo.bar) is actually calling method bar on the object foo. So, if you want to reference the method explicitly, you have to write foo.method(:foo), which returns a Method instance which can be invoked or used like any other scalar value.
...the Ruby idiom would be one of the following:
...you would use this:
So, while in Python, you might write something like this:
controller.set_handler('some_action', myObject.handle_some_action)
controller.set_handler('some_action', myObject.method(:handle_some_action))
-or-
controller.set_handler('some_action') { myObject.handle_some_action }
The extra method(...) syntax is needed to ensure that all communication between objects is via method calls, rather than direct property access. Python allows you to directly assign to and read from object attributes, much like public members in C++ or Java classes. Ruby forces all attribute access to be wrapped in get/set methods, but provides a lot of support to make implementing those methods effectively automatic.
The latter example also uses a code block, cover many cases where first-class functions would be otherwise -- they're basically a compact syntax for lambda expressions, and prevent you from needed sugar like list comprehensions in most situations.
For example, instead of the following Python list comprehension:
[x*2 for x in myArrayOfValues if x % 3 == 0]
myArrayOfValues.map {|x| x*2}.find_all {|x| x % 3 == 0}
Blocks are also a general idiom used throughout the standard library and most Ruby code in the wild. You can use them to write callbacks, query databases, and even to build domain-specific languages (another traditional stronghold of functional languages).
Really, though, neither Ruby or Python is a truly functional language; both borrow from the more "academic" languages those features and concepts they find useful, and leave behind those that the maintainers and users don't want, need, or understand. (Except for continuations, of course -- Ruby has those, and I would guess that only a very small percentage of Ruby coders ever grok them.)
GNU ld on Itanium also can't load IA-32 shared objects, which makes binary compatibility much less useful than it would be otherwise. I don't know about you, but I tend to use dynamic loading quite a bit in most of my significant projects.
In the announcement they note that Ruby scripting has been added in this version, so presumably you could actually add quite sophisticated game logic. It just depends on how rich they made the scripting API.
Pretty much all Japanese fonts include Roman characters, so this shouldn't be a problem. You may have a hard time *entering* lots of English text, but I suppose you could always just create it a normal text editor and import/copy-and-paste it into the application.
I know the guy, and he's definitely working on a Mac. The iPod hard drives are all FAT32 formatted, IIRC, so it probably would have mounted successfully if the CF drives weren't crippled (as a number of other articles have already reported).
This doesn't put a SQL interface on top of Java objects, or even support serialization of said data to rows in the database. It just lets you extend the range of user-defined functions (i.e., data type conversions, aggregate operators, etc.) to those implemented in Java.
Anyone care to weigh in with an example of their successes (or lack thereof) running an equivalent .NET/Vistual Studio/IIS dev environment on a machine with 128MB of RAM?
Sorry for the dig, but I'm consistently astounded by the gains that all of the major open source Java and desktop tools have made in their efficiency and reliability. I still remember being completely fsck'd by the overhead of green threads with the IBM JDK 1.1.X on a 2.2 kernel whenever I tried to run more than one JVM instance at once...though it was good for building stingy habits w.r.t. runtime object (and esp. thread) allocation.