If the same intermediate language is generated from the Java frontend and the C frontend
It isn't, if you're targetting bytecode. Bytecode is handled as a special case which bypasses GCC's RTL representation.
Since the JVM doesn't allow arbitrary access to memory, it's not feasible to make a Java bytecode backend for GCC. (Java bytecode is Turing complete, so it's technically possible; but you'd have to resort to ugly hacks like representing memory as a gigantic, flat array of bytes.)
Unfortunately, I can verify the AHCI problem. In my case, it claims the device verification fails whenever I soft-reboot. It's annoying enough that I just run the SATA controller in Legacy IDE mode.
Otherwise, though, my AB9 Pro has been reasonably solid. Considering the dearth of good 965 motherboards -- and the expense of Conroe-compatible 975 motherboards -- it's probably the best of a limited pack right now.
I'm betting the sony is a closed system, where you can web browse but I bet you can't run your own software on it.
I'm betting you didn't read the article, where they discuss the Mylo's support for the open-source Qtopia platform and the open-spec (and soon-to-be-open-source) Java platform.
Isn't FC intended as a test distro for new Red Hat stuff? I'm not a seasoned FC user but I've always thought FC releases were not first and foremost stable so much as innovative.
The article is about Ubuntu 6.06, which is still in alpha. I'm using it right now on my home PC, and its alpha status shows at times: every once in a while, they'll release an update that'll suddenly break a program. You probably installed Ubuntu 5.10, which like RHEL is "stable" in the sense that they rarely release updates that add new features: almost all the updates are for security patching and bug-fixing. (As a result, it's also stable in the other sense, since they generally won't push out updates that haven't been tested thoroughly.)
Fedora Core tends to walk a thin line between the two styles of releases, in that they'll frequently update packages to add new features, but they also test them at least a little before sending them out to the general public. I've been using Fedora Core on my work PC since FC3, and generally it's been rock-solid, despite the frequent updates. But some people seem to have had bad experiences with it, so YMMV.
Let's combine the wiki with an infinite number of typing monkeys. Eventually one of them will type up a LaTeX file that the STOC or FOCS conference reviewers would accept as a solution finally disproving P=?NP.
Alternatively, you could use just one monkey, and then submit the results to WMSCI or GESTS.
How is that more secure than enabling the root account?
Aside from making dictionary attacks a little harder to pull off, it isn't really inherently more secure. But Ubuntu is often recommended for new converts from Windows, where people are used to doing everything as root. Ubuntu disables the root account out-of-the-box to strongly discourage people from logging in as root for daily work, where they can unintentionally do a lot of damage.
This creates a "lowest common denominator" problem, however, since you inevitably have to stick to only using those widgets which all your target platforms have...
Alternatively, you can emulate widgets that aren't natively supported by your target platform by drawing them yourself. This is the approach that SWT takes: whenever a "core" widget isn't supported by the native toolkit, fake it. AWT unfortunately took the "lowest common denominator" path, which is part of why developers are so loathe to use it.
You may want to check out the Hong Kong DVD packs. . . . It's legal but hard to find.
Unfortunately, most of the anime DVDs (and, increasingly, other DVDs) that people buy from Hong Kong are bootlegs. For example, the legitimate HK versions of Stand Alone Complex Season 1 are sold in 2 boxsets of 4 DVDs each, for about $45 USa pop. True, it's cheaper than the ~$120-$150 that the first season will run you in the U.S., but it's definitely not $40. Legitmate releases are also typically (but not always) Region 3 coded, which means most people in the U.S. won't be able to watch them.
Sadly, eBay (and, from what I hear, many conventions) are flooded with bootlegs from Hong Kong, and I don't think most people know that what they're buying isn't legitimate. Search eBay, Half.com, or Amazon.com for a popular TV series like 24 or The Sopranos, and see just how many copies turn up that are described as "import" versions with "Chinese writing" on the box.
Anyway, to answer the grandparent's question, there's finally a trend starting where R1 anime companies release season/series sets in thinpak sets for a fraction of the price of the original discs, typically 6 months to a year after the last individual volume of the series is released. You lose the pack-in (and, sometimes, on-disc) extras, but the prices are far easier for the casual fan to swallow. For example, Amazon.com is selling Neon Genesis Evangelion -- once infamous for being ADV's cash cow -- for under $50 for the whole series. It's not quite on par with the pricing for most domestic TV series, but it's close.
Unfortunately, there's no word yet of packaging Stand Alone Complex in a cheaper collection, at least not in Region 1. Bandai and/or Manga have apparently decided there's still too much demand for the more-expensive individual volumes.
Visio can work with OmniGraffle Pro ($150). I really like Graffle; the non-pro version comes with some Macs, so you can upgrade for less. My PowerBook included non-pro version 3.
As much as I prefer OmniGraffle to Visio, it's worth pointing out that OmniGraffle Pro only supports importing and exporting Visio's XML data format, not the default binary format. If you absolutely must read legacy Visio files, then you need to keep a Windows workstation (or a Windows image in Virtual PC) around for conversion purposes.
Newer x86 chips (i.e., anything you'd want to combine with 2GB+ of RAM) have a mode which supports up to 64GB of RAM. Linux and Windows both support this mode.
However, you're still limited to 4GB of addressable memory per process. If you need more than that, you have to go 64-bit.
That being said there are still white patches in the standard Java class libraries; like RS232 support for example which, surprise, surprise, is still widely used. The last time I looked this was only implemented for Sun and Linux but not Windows, OS.X and other OS'es
See RXTX for all your cross-platform RS232 needs. The compilation process is a little long-in-the-tooth, but you only need to do that once per platform. I've personally used it on Linux, OS X, and Windows CE.
Either Ebert is wrong, or the Blockbuster policy is unenforced. I actually spoke too soon when I said that I've never seen an NC-17 rated movie at Blockbuster. I've seen DVDs of Evil Dead on the shelves at a couple of local Blockbusters. All editions of Evil Dead released on DVD in the United States contain the original, NC-17 rated theatrical cut.
Careful there... was it the vast majority of theaters or the vast majority of theater chains? If the 3 largest theater CHAINS, which control most of the theaters out there do have policies against showing NC-17 movies, then the grandparent poster's point would be valid.
Unfortunately, it's been a while since I read the article that printed the results of the survey, and I haven't kept a copy, so I'm not 100% sure of the methodology. But I'm fairly certain that it said that the three major chains left whether or not to show NC-17 rated movies to the discretion of individual theaters.
Most theatres have a policy of not showing NC-17 movies.
This is untrue. Back when there was talk of Lion's Gate screening High Tension uncut, there was a survey of theaters that showed that the vast majority had no policy against showing NC-17 rated movies. There's a perception among studios that NC-17 is the kiss-of-death, but it mainly comes from the commerical failure of Showgirls (which was due to a number of factors besides its rating).
Blockbuster won't carry NC-17 or "unrated" versions of movies.
This is also untrue. I haven't seen any NC-17 rated movies at Blockbuster, but that's probably because there haven't been any NC-17 rated movies released by a major studio in a decade. I've seen plenty of unrated versions of movies, though.
Blockbuster is a franchise chain, so individual stores may have different policies on what they'll carry. But AFAIK it's not official Blockbuster policy to carry NC-17 or unrated movies -- and if it is, then plenty of stores violate that policy anyway.
It'll gain some interest in movie geeks, but interest will be lost to the casual movie fan
The casual movie fan's interest was already lost when the directors decided to make a documentary about the MPAA rating system. The film's target audience was already small before the MPAA slapped a rating on it, and that audience probably won't be deterred by an NC-17 rating. If anything, like the grandparent pointed out, the extra press will only help.
You don't need the code. The author has written multiple papers on its inner workings. He even gave a talk to our CS department that gave more than enough information for someone to duplicate his work, were they so inclined.
Doesn't that use J2ME though? And, I would assume, J2ME gives you less facilities than J2SE and J2EE, so are we comparing like with like?
(Note: lots of technical abbreviations follow. There's no way I'm going to link to definitions of all of them. Use Google, or shoot Sun's marketing team; preferably, both.)
J2ME is an umbrella term that covers basically any Java runtime targetted at something larger than a smart card but smaller than a desktop. That includes two different VM specifications and several different class libraries running on top of those VMs.
When most people talk about "J2ME", they're talking about one or another version of the MIDP class library running on top of a CLDC-compliant VM, since that's what nearly all mobile phones use. Besides having a much smaller class library, the VM places some restrictions on apps that aren't present in J2SE runtimes. For example, there's no built-in object serialization mechanism, and reflection is fairly limited. Nor do older CLDC VMs support float or double primitives (these were added in a later version of the specification).
So, in some ways, it's not possible to make a direct 1-to-1 performance comparison. For example, MIDP uses a completely different UI library from J2SE, with a completely different set of capabilities. MIDP's LCDUI toolkit is designed to perform well on small devices, at the cost of apps looking completely different from device to device. Swing, on the other hand, is designed to have largely the same look-and-feel on any platform, but you pay a pretty heavy performance penalty for using it. (Sun claims that Swing doesn't actually carry a big performance penalty anymore, but in my personal experience, they're full of it.) Comparing the two isn't fair, since they set out to do different things on different kinds of devices.
This particular article, though, is only concerned about the cost of memory allocation and garbage collection. J2ME uses the same memory allocation model as J2SE, and so the comparison is apt in this case.
to be fair, as of C99, C has boolean types as well.
although its hardly used in C, and not as well defined in C, but thats how afterthoughts typically work.
Java's boolean type is a little bit different from C99's bool type in that it's a seperate primitive which cannot be cast back and forth between int. So code like
int foo = 0; bool bar = (foo = 1);
will compile and run in C (probably even without a warning, depending on which compiler you're using), but it probably won't do what you expect. Whereas boolean bar = (foo = 1); is not valid Java syntax, and so the compiler will catch it before it becomes a runtime error.
I'm not fond of all the decisions Sun made while designing Java (see also: multiple inheritence, lack thereof) but this was probably one of the better ones.
There ARE good audio chips available. Sometimes they even make it on to motherboards. Albatron ships a few boards with the sounds-better-than-Creative Via Envy chipset. They even throw in a daughterboard with both types of digital input and output.
The problem for most people (i.e., people using the analog outs) isn't just the sound chip. The quality of components like the DACs can also play a huge role in how good the audio is. In order to keep costs down, motherboard manufacturers either like to use sound chips with integrated DACs (which are usually of poor quality) or just include the cheapest DACs they can find. They also rarely pay attention to board layout enough to minimize the amount of noise picked up from other components. (I've got a Dell at work where I can literally hear windows redraw when my headphones are plugged in.) This won't really matter people who just care about system noises and the occasional Flash applet. But if you want to listen to music, the distortion and hiss is just painful to listen to.
This, incidentally, is usually what seperates the $50 Envy24HT boards from the $20 ones: the more expensive boards often use Wolfson DACs on one or more of the analog outs, which results in much better audio quality.
One of the nice things that Soundstorm did was place minimum requirements on things like the signal-to-noise ratio from the analog outs. If you bought a Soundstorm-certified motherboard, you knew the audio quality was going to be fairly good.
Well, the heavy lifting is done within HAL. GNOME Power Manager provides a little bit of glue (which is desktop-independent and already packaged seperately) and a nice GUI to sit on top of it.
So short of the configuration GUI needing to be re-implemented for each desktop environment, there's not really any fragmentation going on there.
It would also help if we worked harder on well-defined and standardized APIs, so that it would be easier to get things working with each other. For example, a standardized hardware configuration API would help make "control center" type apps a lot easier to make, etc.
This is where HAL comes in. (Cue the 2001 jokes.) It's pretty new, so it's mostly being used for things like auto-mounting devices in KDE and GNOME currently; but tools like GNOME Power Manager are starting to be built on top of it.
Right now it's Linux-only, but AFAIK there's nothing that inherently prevents it from being ported to one of the BSDs.
In this situation, however, I suggest that you find another algorithm that is good enough and use that instead. It's not like there's any shortage of them...
Which is exactly what the FreeType people did. Normally TrueType typefaces contain a miniature program to help with hinting on a per-typeface basis. Apple's patents prevent FreeType from using these programs by default. So, FreeType 2 contains generic auto-hinting code.
The result is fonts are hinted differently than Windows and OS X. Whether the hinting is actually worse is mostly a matter of opinion -- I prefer FreeType's hinting over Windows's for the most part, although there are specific typefaces (like Verdana) that are hinted pretty badly with FreeType if you don't use anti-aliasing.
At any rate, if you live in a country that isn't covered by Apple patents (or if you just don't care about violating them), you can unofficially enable the patent-protected hinting in FreeType by getting a copy with said code enabled. Instructions are available here.
Re:Still ugly fonts - this works too!
on
GNOME 2.12 Previewed
·
· Score: 2, Informative
If all you want to do is adjust the font DPI, you can do that from the GNOME Font Preferences. KDE's Control Center has a similar option. No manual configuration-file editing is necessary.
The configuration-file editing is only necessary if fonts are the wrong size because X guessed your monitor size incorrectly (which is very rare in my experience, since it just fetches that information straight from the monitor, but it does happen). At any rate, Windows doesn't have the ability -- GUIfied or otherwise -- to override monitor geometry, at least as far as I can tell. I'd be a little surprised if OS X does, although it might since Macs are used in graphics work so often.
Gnome is great at turning a fast computer into a sluggish one. Just because you have all of those CPU cycles doesn't mean that they have to use them, especially when lots of them seem to be wasted.
For instance: if you look (strace) at a typical gnome program when it starts up, it stats zillions of files; many of them more than once. This is why startup is so sloooooow.
I've been following GNOME development on Planet GNOME and there's recently been a push to profile and optimize core GNOME libraries and apps to bring down startup time and memory usage. I doubt you'll see much talk about it in the GNOME preview release notes, though, because (a) it's still ongoing; and (b) the GNOME release notes are pretty high-level, so it doesn't include much beyond user-visible changes.
I agree that it's about time, though: I'm saddled with a 4-year-old Vaio notebook until my new Powerbook ships, and running GNOME 2.10 with 128 MB of RAM is just painful. With XFCE 4.2 at least I can load Firefox and Evolution simultaneously without the hard disk constantly thrashing; under GNOME I had to resort to elinks and mutt just so that the system was usuable.
I never really got it, why does the IE UA have Mozilla_4.0 in it?
Long before Web developers started blocking browsers without the IE UA, they blocked browsers without the Netscape UA. (Mozilla was the code name for Netscape long before the open-source Mozilla project started, which is why "Mozilla" was in the Netscape UA.) Microsoft countered by using the Mozilla/x.x part of the Netscape UA, and then embedding the fact that it was really IE in the parentheses (which nobody really parsed at the time).
It isn't, if you're targetting bytecode. Bytecode is handled as a special case which bypasses GCC's RTL representation.
Since the JVM doesn't allow arbitrary access to memory, it's not feasible to make a Java bytecode backend for GCC. (Java bytecode is Turing complete, so it's technically possible; but you'd have to resort to ugly hacks like representing memory as a gigantic, flat array of bytes.)
Unfortunately, I can verify the AHCI problem. In my case, it claims the device verification fails whenever I soft-reboot. It's annoying enough that I just run the SATA controller in Legacy IDE mode.
Otherwise, though, my AB9 Pro has been reasonably solid. Considering the dearth of good 965 motherboards -- and the expense of Conroe-compatible 975 motherboards -- it's probably the best of a limited pack right now.
Fedora Core tends to walk a thin line between the two styles of releases, in that they'll frequently update packages to add new features, but they also test them at least a little before sending them out to the general public. I've been using Fedora Core on my work PC since FC3, and generally it's been rock-solid, despite the frequent updates. But some people seem to have had bad experiences with it, so YMMV.
Sadly, eBay (and, from what I hear, many conventions) are flooded with bootlegs from Hong Kong, and I don't think most people know that what they're buying isn't legitimate. Search eBay, Half.com, or Amazon.com for a popular TV series like 24 or The Sopranos, and see just how many copies turn up that are described as "import" versions with "Chinese writing" on the box.
Anyway, to answer the grandparent's question, there's finally a trend starting where R1 anime companies release season/series sets in thinpak sets for a fraction of the price of the original discs, typically 6 months to a year after the last individual volume of the series is released. You lose the pack-in (and, sometimes, on-disc) extras, but the prices are far easier for the casual fan to swallow. For example, Amazon.com is selling Neon Genesis Evangelion -- once infamous for being ADV's cash cow -- for under $50 for the whole series. It's not quite on par with the pricing for most domestic TV series, but it's close.
Unfortunately, there's no word yet of packaging Stand Alone Complex in a cheaper collection, at least not in Region 1. Bandai and/or Manga have apparently decided there's still too much demand for the more-expensive individual volumes.
However, you're still limited to 4GB of addressable memory per process. If you need more than that, you have to go 64-bit.
Either Ebert is wrong, or the Blockbuster policy is unenforced. I actually spoke too soon when I said that I've never seen an NC-17 rated movie at Blockbuster. I've seen DVDs of Evil Dead on the shelves at a couple of local Blockbusters. All editions of Evil Dead released on DVD in the United States contain the original, NC-17 rated theatrical cut.
Blockbuster is a franchise chain, so individual stores may have different policies on what they'll carry. But AFAIK it's not official Blockbuster policy to carry NC-17 or unrated movies -- and if it is, then plenty of stores violate that policy anyway.
The casual movie fan's interest was already lost when the directors decided to make a documentary about the MPAA rating system. The film's target audience was already small before the MPAA slapped a rating on it, and that audience probably won't be deterred by an NC-17 rating. If anything, like the grandparent pointed out, the extra press will only help.You don't need the code. The author has written multiple papers on its inner workings. He even gave a talk to our CS department that gave more than enough information for someone to duplicate his work, were they so inclined.
J2ME is an umbrella term that covers basically any Java runtime targetted at something larger than a smart card but smaller than a desktop. That includes two different VM specifications and several different class libraries running on top of those VMs.
When most people talk about "J2ME", they're talking about one or another version of the MIDP class library running on top of a CLDC-compliant VM, since that's what nearly all mobile phones use. Besides having a much smaller class library, the VM places some restrictions on apps that aren't present in J2SE runtimes. For example, there's no built-in object serialization mechanism, and reflection is fairly limited. Nor do older CLDC VMs support float or double primitives (these were added in a later version of the specification).
So, in some ways, it's not possible to make a direct 1-to-1 performance comparison. For example, MIDP uses a completely different UI library from J2SE, with a completely different set of capabilities. MIDP's LCDUI toolkit is designed to perform well on small devices, at the cost of apps looking completely different from device to device. Swing, on the other hand, is designed to have largely the same look-and-feel on any platform, but you pay a pretty heavy performance penalty for using it. (Sun claims that Swing doesn't actually carry a big performance penalty anymore, but in my personal experience, they're full of it.) Comparing the two isn't fair, since they set out to do different things on different kinds of devices.
This particular article, though, is only concerned about the cost of memory allocation and garbage collection. J2ME uses the same memory allocation model as J2SE, and so the comparison is apt in this case.
I'm not fond of all the decisions Sun made while designing Java (see also: multiple inheritence, lack thereof) but this was probably one of the better ones.
This, incidentally, is usually what seperates the $50 Envy24HT boards from the $20 ones: the more expensive boards often use Wolfson DACs on one or more of the analog outs, which results in much better audio quality.
One of the nice things that Soundstorm did was place minimum requirements on things like the signal-to-noise ratio from the analog outs. If you bought a Soundstorm-certified motherboard, you knew the audio quality was going to be fairly good.
So short of the configuration GUI needing to be re-implemented for each desktop environment, there's not really any fragmentation going on there.
This is where HAL comes in. (Cue the 2001 jokes.) It's pretty new, so it's mostly being used for things like auto-mounting devices in KDE and GNOME currently; but tools like GNOME Power Manager are starting to be built on top of it.
Right now it's Linux-only, but AFAIK there's nothing that inherently prevents it from being ported to one of the BSDs.
The result is fonts are hinted differently than Windows and OS X. Whether the hinting is actually worse is mostly a matter of opinion -- I prefer FreeType's hinting over Windows's for the most part, although there are specific typefaces (like Verdana) that are hinted pretty badly with FreeType if you don't use anti-aliasing.
At any rate, if you live in a country that isn't covered by Apple patents (or if you just don't care about violating them), you can unofficially enable the patent-protected hinting in FreeType by getting a copy with said code enabled. Instructions are available here.
The configuration-file editing is only necessary if fonts are the wrong size because X guessed your monitor size incorrectly (which is very rare in my experience, since it just fetches that information straight from the monitor, but it does happen). At any rate, Windows doesn't have the ability -- GUIfied or otherwise -- to override monitor geometry, at least as far as I can tell. I'd be a little surprised if OS X does, although it might since Macs are used in graphics work so often.
I agree that it's about time, though: I'm saddled with a 4-year-old Vaio notebook until my new Powerbook ships, and running GNOME 2.10 with 128 MB of RAM is just painful. With XFCE 4.2 at least I can load Firefox and Evolution simultaneously without the hard disk constantly thrashing; under GNOME I had to resort to elinks and mutt just so that the system was usuable.