mono
Latest
GRID 2 BAC Mono Edition is £125,000
You might be thinking that some countries use commas instead of decimal points, but the headline above does indeed say one hundred and twenty-five thousand British Pounds ($188,700). You might also think that's awfully expensive for the special edition of a racing game (any game, really), but allow us to put things in perspective. The GRID 2 BAC Mono Edition isn't so much a special edition of a game as it is a luxury sports car that happens to come with a game. Specifically, the BAC Mono Edition comes with the Mono, essentially a street legal formula racing car. Also included is a racing suit and helmet, a copy of GRID 2 and a PlayStation 3 on which to play it. According to BAC's website, a Mono with no frills has a base price of £96,495 ($145,919), and that's before throwing in VAT. Only one copy of the BAC Mono Edition is being manufactured, making it something a collector's item. You can place your pre-order exclusively with GAME. Oh, and shipping is free. Not to be left out, Best Buy is hosting a special edition of GRID 2 in North America. It includes the IndyCar DLC pack and retails for $59.99. GRID 2 comes out next week.%Gallery-189346%
GRID 2 Mono Edition: buy a £125,000 racing game, get a supercar for free
While we like our collector's edition games, there's no question that even the better bundles are full of knick-knacks we'll use just once or twice. No one will say the same for Codemaster's GRID 2: Mono Edition, though. The UK-only bundle includes the GRID 2 racing game, a PS3 to play it on... and a very real BAC Mono supercar. Whoever buys the £125,000 ($188,700) kit will get to both pick up the 280HP single-seater as well as customize it at the BAC factory, including the racing suit for those inevitable track days. With just one instance available for GRID 2's May 31st release, the Mono Edition bundle is more of a promotional stunt than a business strategy -- but it might be the only special edition where the extras are more exciting than the game itself.
Sony's Digital Link Sound System brings all-in-one iOS integration to your dashboard
Is your car yearning for more iOS integration? Sony's got you covered, with its new Digital Link Sound System. The company's new audio package is available in two models: the all-in-one XDP-PK1000 and the more compact XDP-MU110. The former consists of five components, including an iPhone / iPod Touch cradle (pictured above), wireless remote control, customizable digital sound processor, 12-inch box subwoofer and 300 watt Class D mono block amp. The XDP-MU110, on the other hand, is geared toward drivers who are already content with their amp / subwoofer setup, but simply want to outfit their ride with a fresh audio system, with the help of Sony's cradle, processor and remote. If you're interested in getting one, however, you'll have to wait a little longer; the XDP-PK1000 is expected to start shipping in September, for about $800, with the XDP-MU110 slated to ship in November, for $400. Cruise past the break for more information, in the full PR.
Novell's Mono tools let devs create .NET apps for Android devices
If app developers have a pattern of going after the iPhone first and Android second, well, the same is apparently true of the folks who write software for the code monkeys. Novell just announced Mono for Android, the first set of tools that lets devs write .NET and C# apps for Android phones and tablets. Novell already lets developers do the same for Linux, iOS, and Mac OS X and, as always, lets coders continue to use Microsoft Visual Studio 2010 to write applications -- if that's the testing software they're used to. In addition to the Visual Studio plug-in, you get bindings for native Android APIs and the core Mono runtime. It's available now, starting at $99 for students (minus the ability to, you know, send finished apps to Android Market) and $399 for everybody else. Already developing for the iPhone? Prove that you own MonoTouch (essentially, the same Novell product for iOS devices) and get 50 percent off an Android tool kit.
Apple confirms some WebKit optimizations unavailable to iOS Apps
The web performance enhancements included in Apple's latest mobile operating system, iOS 4.3, are exclusively available to the Mobile Safari web browser, an Apple spokesperson has confirmed. The optimizations, which double JavaScript performance in Mobile Safari, are not available to the underlying web view framework that powers the embedded browsers in other apps. "The embedded web viewer does not take advantage of Safari's web performance optimizations," Trudy Muller, a spokesperson for Apple, told The Register. Apple's statement comes as a response to controversy started earlier this week when developers first recognized the notable performance gap between Mobile Safari and the embedded web views in their own applications. The debate deepened yesterday when Blaze Software released the results of a study that implied Android loaded web pages 52 percent faster than the iPhone 4. Apple refuted Blaze's results, citing the differences between Safari and the embedded web viewer. Many developers voiced concerns about Apple's decision to exclude third-party apps from taking advantage of the Nitro JavaScript engine included in iOS 4.3. One anonymous developer suggested Apple purposefully omitted the enhancements to subtly degrade the web experience in non-Apple browsers and web apps launched from the home screen. "Apple is basically using subtle defects to make web apps appear to be low quality - even when they claim HTML5 is a fully supported platform," the developer claimed in The Register. Matt Asay, vice president of business development for Strobe, indicated that Apple filed the performance gap as a bug but marked it "not to be fixed by exec order." On Twitter, Asay called the scenario "slimy" and suggested it's partly a tactic for convincing developers to focus on the development of native apps. The real reasons for the performance gap may not be so sordid. Ars Technica observes the Nitro JavaScript engine uses a technique called "just-in-time [JIT] compilation" to transform dynamic JavaScript code into machine code optimized for the ARM processor architecture. Nitro's ability to dynamically generate and execute code enables it to process JavaScript much faster than its predecessors. Unfortunately, for security reasons, other applications developed for iOS aren't typically granted permission to execute dynamically generated native code. Miguel de Icaza, a lead developer for both GNOME and Mono, said he suspects the issues are legitimate technical problems and not a conspiracy. "It seems that people are attributing to malice what can easily be explained by history - iOS has never allowed user code to generate code on demand, and this has for years prevented JIT compilation from taking place," Icaza told Ars Technica. "Third parties have never been able to get access to this - not Mono, not Java, not Lua, not JavaScript, or any other runtime, compiler, or library that generates native code dynamically." As a result, applications that use the UIWebView framework, including web apps launched from the home screen, will not enjoy the performance optimizations available to Apple's Mobile Safari web browser. Despite the technical challenges in adapting Nitro to work safely within the UIWebView framework, developers like Icaza are optimistic Apple will enable the new JavaScript engine for apps with embedded web views. "Since this is the first OS release with Nitro on the Mobile Safari browser, it is probably safe to assume that this is merely a bug or limitation," he said. Is this a conspiracy worth dubbing "browser-gate," or simply a small speed bump in this tale of two JavaScript rendering engines? Please use the comments below to discuss. [via The Mac Observer]
Unicat retro TV channels the 1940s, bidding now underway
How does technology a half-century old manage to be this sexy? We're not certain. But this one-of-a-kind, handmade retro television -- which seemingly combines an old desktop lamp and a giant magnifying glass -- definitely tugs at our heartstrings. With a 5.5-inch monochrome CRT screen and no inputs to speak of, you won't be watching Blu-rays on this set, and its PAL standard and 220V plug mean non-Europeans might not be bothered to try. Still, for an old over-the-air TV, it's remarkably full-featured, with knobs for volume, band (VHF-L / VHF-H / UHF), brightness, contrast and V-sync, and we can't get over its clean, handsome design. If your Nixie tube collection is getting lonely, check out the auction at our source link; bidding starts at €300.%Gallery-90244% [Thanks, Alex]
Second Life script limitations to prejudice against Mono?
In a sense, script memory limitations aren't coming to Second Life; they already exist. What's going on is the process of Linden Lab making those limits predictable, and setting things up in such a way that script memory usage doesn't cause simulator processes to thrash madly (from paging memory to and from disk). There's some interesting side-effects emerging from the overall prototype implementation, however. Mono (and, eventually C# when or if it becomes implemented as a scripting language) look like the losers.
Linden Lab investigates new/updated technologies for Second Life
Over the last few weeks, Linden Lab staff have been talking about a few upcoming Second Life projects during their in-world office-hours sessions. Now the Lab has always been quick to stress that the accuracy and reliability of information obtained through those venues is questionable, and that we shouldn't assume that anything said at them is actually accurate. With that in mind, we went back to the Lab about several identifiable (or at least apparent) projects to get the skinny on them and find out what's actually happening with them, and where they're at.
Two Growl styles worth a serious look
Designer/Developer Christopher Lobay has been hard at work making some excellent Styles for the system notification app, Growl. Growl displays temporary, floating notification windows above your desktop to let you know about things like new messages, completed downloads, changes in Skype availability, etc. Many applications have Growl support built in, so if you're not using it already, you should check it out. Once you do, you'll want to customize the way it looks, and that's where Christopher, among legions of others, comes in. Published a while back, the first Growl style I want to highlight is "Basics." Basics provides a very minimalist black background on which it animates the icon of the application responsible for the notification. If you, like me, have grown all too accustomed to notifications popping up around your desktop, this little bit of animation (just a slide across the bar) can make the popups much more eye-catching, without being distracting. It is, as its name implies, basic, but has an air of class not always seen in Growl styles. Second -- and brand new right now -- is "Mono." This latest one is even more subdued, with a very nice bezel and it's the text that animates rather than the icon. This has much the same eye-attracting effect but is even less distracting. It's some great work by Christopher, and definitely worth a peek if you're using Growl. Both styles are available for free, so go get 'em!
Long-delayed Second Life script-limitations back in the public eye
It's now just over one year since Linden Lab announced that they would be implementing a some manner of script limitations over and above those which are presently a part of Second Life as it stands today. It is just over eleven months since those limitations were rescheduled to go ahead in Q3 2009 – which time has definitely long passed. Nevertheless, the script limitations system is alive and well and coming up, apparently in 2010. This constitutes good news, very good news and not so good news (in roughly that order).
Yuen'To's Music Balloon speaker is fabulous, price tag is ferocious
If you like cute, puffy things, enjoy subjecting strangers to your obscure tastes in music, and have tons of excess cash to burn on nigh-useless gadgets, get a load of this! It's the Yuen'To Music Ball, aka the Music Balloon, a rechargeable auxiliary mono speaker for any portable audio device. It offers a meager .7-watts of power, lasts a measly 2 hours on a charge, yet costs a massive $76.16. (Yorozu's overpriced $80 mono speaker at least packed 2-watts.) It is, however, available in your choice of passion pink, mellow yellow, romantic red, bombastic blue, or boring black. Who can resist?[Via Akihabara]
A brief history of void simulators/openspaces
The context in which the Second Life issue of the void/openspaces price-rise exists is a rather complex one, going all the way back to 2006. So, in order to get the whole issue in perspective, we've rounded up the history of void simulators, costs and conditions, all the way back to the beginning. And it is a far more interesting progression of events than you might think. On with the show.
Second Life SLS-1.24.6 rolling out this week
Continuing the attempts to further stabilize the new Second Life server code, SLS-1.24.5 will be replaced with SLS-1.24.6 in the latter half of this week, Wednesday through Friday. There are also some signs that precursors to yet another revision, SLS-1.24.7 are already undergoing preliminary testing. The version that is slated for deployment this week appears to be build 96673, which is marked as containing fixes for two bugs - one of which was supposed to have been fixed in SLS-1.24.5, and another which was partially fixed in that release. Both bugs impact scripts, as you might expect, and have impaired and disrupted a large quantity of post-mono user-generated content, sometimes in quite subtle ways. Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop.
Second Life 1.21(RC2) available. SLS-1.24.5 rolled out
Linden Lab have been working very hard to attempt to bug-fix and stabilize the SLS-1.24 Mono-enabled Second Life simulator server software (try saying that three times, fast). Since Monday, the 8th of September, we've counted no less than 19 distinct versions of 1.24.5 that got far enough along to test. Right now, the top candidate (and the version that has been rolling out onto the Second Life grid) is build 96115. A test rollout of build 96378 was attempted, but was somewhat crashier than 96115, so it was replaced with the slightly earlier build. There are several later builds already being tested and assessed as candidates for the next rollout, the latest being build 96505. There's quite a list of fixes, almost (but not entirely all scripting related). Notes for builds up to 96378 are available, however it isn't yet clear what any more recent builds might contain. While all this is going on, the viewer team has managed to crank out a new release-candidate (1.21-RC2), which runs on the Mac PPC, and for those of you who were having that nasty crash-or-freeze-every-minute-or-six problem, or issues with sculpt textures, there's a fix for those too. Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop.
Major failure plagues Second Life Mono deployment
Over the course of the week, we've been getting scattered reports of problems on the Second Life grid relating to the new Mono script-engine runtime that was deployed as a part of SLS-1.24. The key phrase seems to be "catastrophic mono bytecode serialization failure". The problem itself doesn't appear to be highly reproducible, but by the accounts we're getting, when it occurs, the Mono runtime flings a complex exception, and most or all of the Mono scripts in the simulator where the exception occurred shut down, and stay that way, pending individual and manual attention. SLS-1.24.4 rolled out on 3 September, though that apparently did not correct the problem, as we have reports of it from users as late as 4 September, despite the relative infrequency of its occurrence. Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop.
Second Life Mono-enabled deployment rolling after multiple delays
You might be wondering, you know after all the hooraw last week, just what precisely happened to SLS1.24, the Mono-enabled deployment of the Second Life server code that was supposed to deploy on Tuesday, Wednesday and Thursday last week. Well, that was 1.24.0, and as you may recall that not long after the pilot deployment the Second Life grid went kind of whack. But that's alright, because 1.24.1 to the rescue! Nobody said quite what was wrong -- heck, maybe they can't -- but 1.24.1 fixed that and it was rolled out to replace 1.24.0 on the pilot simulators. Now, stop us if you've heard this one before, but while 1.24.1 fixed whatever it was that was wrong with 1.24.0, but was kind of well ... crashy. Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop.
SLS 1.24: Second Life rolling update, rolling out now
According to an announcement by Linden Lab, the SLS1.24 (version 1.24 of the Second Life server/simulator code) rollout to servers is happening right now. While Linden Lab have normally given at least a little advance notice, and a schedule for the server-side software updates (which can be disruptive), no such notice or schedule were published. All we have been told is that it will "take a number of days"; we assume that is probably different to the usual three-day schedule. Actually, if you haven't been reading Massively lately, this whole update probably comes as a complete surprise. As we mentioned previously, the 1.21 release candidate viewer that you'll need in order to take full advantage of this release isn't due until next week, though you can probably access the Mono functionality with the preview grid viewers -- just remember to change the grid target to -grid agni in order to access the main grid. Patch notes are after the jump. Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop.
New Second Life features due next week
Linden Lab is expected to roll out SLS1.24 (version 1.24 of the Second Life server/simulator code) this coming week with both the new Mono script-engine runtime and Qarl Linden's new touch-position code. We're confident that you'll see announcements for those on Monday or Tuesday (the 18th or 19th) describing the update schedule through the course of the week. We wouldn't be surprised to see something of a media push accompanying it; that would be consistent with the way the new Lab is operating these days. The Mono script-engine runtime increases the amount of memory available to new or recompiled LSL scripts (from 16K to 64K) -- though at the expense of increased memory consumption -- while also largely increasing the speed of them, especially for intensive calculations. Mono is, primarily, part of the platform stabilization project rather than a new feature for the sake of new features. Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop.
Mono coming soon. Very soon.
Depending on how the new code travels through the QA process, Mono could come to the main Second Life grid within the next four weeks, says Linden Lab. Mono (an open source implementation of Microsoft's .NET) is to be deployed as an additional, faster script runtime engine that should greatly speed many common scripting operations, increase stability and reduce load. Linden Lab says that it is unlikely that we'll see Mono deployed within two weeks, but within four is certainly not out of the ballpark. Currently Mono is available for testing on the Beta grid, and scripters should take the opportunity to test their scripts there and get bug-reports filed sooner, rather than later. The new script runtime engine does not add (and is not presently intended to add) support for any languages other than the already existing LSL.
LSL vs Mono deathmatch
While the upcoming Mono is agreeably faster than LSL for Second Life scripts, and in many cases a lot faster, there are some situations where this does not always appear to hold true. One such case is object updates. At present scripts that perform object updates might not perform faster than LSL - and might actually be a bit slower. Thanks to Todd Borst, we can show that to you, in glorious video, direct from the beta-grid!
