I thought that IE 9, with its much-improved standards compliance, was also going to support MathML. After seeing your post I did a quick search and found that it turns out that IE 9 doesn't even allow good MathML support with the proprietary (but free) MathPlayer plugin. Since this is one of the few features I have a reason to care about, I'm quite disappointed.
All the more reason for LED lights- one of the few applications where >5W LED lights have really taken off is installation in places where it would be difficult to replace a bulb, since the lifespan is tremendously longer than either incandescents or compact flourescents.
I think that the government move comes at a really unfortunate time. The novelty of cheap widespread CFLs has worn out- people don't like the warmup delay, the higher cost, the much-lower-than-advertised durability, and the disposal inconveniences. The thing to do with florescents is to rethink your lighting fixtures so you can use a non-compact florescent (better efficiency and lifespan) rather than a dozen separate bulbs.
LED lights are getting better all the time, and people are starting to find them to be worthwhile and practical for a lot of situations. I worry, however, that average consumers looking for solutions now will be turned off by the current high prices and other issues, and that improved LEDs a few years from now (by which time consumers may get fed up and get this bill repealed) will have a harder time catching on because of it.
Please try reading what you're replying to before replying. He wasn't saying energy use of an LED in service was high, he was saying manufacturing an LED takes more energy than manufacturing an incandescent.
I thought everyone who owned an iPhone prayed to Jobs (thrice daily, while facing Cupertino), has WWDC and Macworld Expo instead of communion, confessed their dalliances with non-Apple products to Geniuses at the Apple Store, and did penance by lashing out at those who criticize Apple products online.
Wouldn't being involved in Catholicism violate their First Commandment or something?
Blame the curb weight arms race in safety regulations. Since heavier vehicles have better survivability than light vehicles in head-on collisions between the two, we all need our cars to weigh more, right? And you surely wouldn't purchase a car with less than perfect safety ratings, especially if you have a family! Four ton cars for everyone! Oh wait, if other peoples' cars coming at me weigh four tons, mine better weigh eight tons, just in case there's an accident...
Decades of engineering and advances in materials are going mostly towards offsetting higher curb weights "for safety's sake" rather than improving fuel mileage or power. I hope at some point people start to understand the tradeoffs involved and demand revised regulations and lighter, more efficient automobiles rather than taking one look at innovations (e.g. the Smartcar) and dismissing them as death traps just because they aren't heavy tanks.
From what I understand this has been brought up multiple times and they've basically said "sorry, we made a decision, we're stuck with it." When you've made a decision that causes practically everyone who hears of your product to do a facepalm and/or to groan "OH, THE HUMANITY!" you really need to learn that bad decisions can be unmade.
Like a lot of open-source software (most famously Linux before they decided everything from here on out would be 2.6), the odd point releases are the development branches.
I tried a random sampling of the humongous archive.org pdfs you linked to in a prerelease version of Sumatra and had no crashes and fairly decent performance. Dealing with ridiculous zoom levels, especially on raster images, is something they've fixed only recently, and no software is going to have fantastic performance at upscaling raster images (try using a 1600% zoom in the Gimp, for instance)- hardware acceleration can help, but most viewers don't have it.
Raster scans are a terrible way to use PDF, which, as a page description language, was designed primarily for text and vector graphics (with the occasional raster illustration). You'll notice archive.org also provides them in DjVu, which is designed for scanned documents; the djvu versions are about 1/3 the size of the pdfs and render faster than any pdf viewer can render the pdfs.
Would you be willing to describe your other issues besides >400% zoom levels and/or see if your files are working better with a pre-1.3 version?
I'm surprised to hear you say Sumatra has "poor rendering, performance and stability." Could you explain some of what you're referring to?
I wonder what the last version you tried was. The underlying MuPDF engine has come a long way since Krzysztof Kowalczyk decided to drop the option of using Poppler as a backend and focus on MuPDF back in version.9 two years ago.
All the news articles I see say that the Lockheed-Martin hard drive fiasco included a missile defense system and data about the company (employees etc) but no aircraft data or blueprints.
At first glance, that looks exceedingly like an F-22 (I'm no expert-maybe specialists here can point out differences). I wonder what the odds are that this- like so many Chinese knockoffs- was designed with extensive engineering details about its competitors, gained in a clandestine manner?
No. The only way to make rare earths less rare is to make more earths, duh. Among other things, the cost of shipping a whole factory-built planet to the nearest Sol-like stars and the loud-mouthed protests of tree-huggers whining about resource depletion (jeez, it's not like anybody else was USING every little yottagram of that feldspar anyway) tend to discourage this.
On a side note: at least the FedEx guy could be a little more POLITE in telling me they don't ship to Tau Ceti. Sheesh. And just FYI, the USPS flat-rate boxes top out at a pathetic 1.3E-11 km^3.
And all zero of the posts about crashes due to firmware being distributed with the kernel. How did you get the idea that the topic at hand had anything to do with proprietary drivers?
Goldeneye's single player campaign was actually *better* than the movie. I played through it, thought "this was really neat, I should rent the movie!" and was thoroughly disappointed with it because its plot and script didn't compare well to the game's.
Uh- he didn't introduce those compromises as a "bridging the divide" type thing, he did those because there was absolutely no way a public option or a tax bill not extending the full Bush tax cut would have made it through Congress. Can't really credit him as a unifier for doing that when he only did so because circumstances forced him to --esp. the fact that not everyone in the Democratic caucus is on the far left*, the voters' rejection of the broader health care tack as manifest in the Scott Brown election and the loss of a filibuster-proof majority, and the imminent GOP House takeover.
Republicans aren't asking him to quit, just to come to the table and try to reach agreement *first* rather than only resorting to it when it's become apparent the legislation preferred by the left wing of his party can't be ramrodded down the nation's throat.
The level of political discourse has really dropped a lot over the past decade. The 2008 presidential debates and the petty partisanship of Congress over the last few years make even the 2000 Bush-Gore debates and the Clinton impeachment debacle look like Webster v Calhoun and the Constitutional Convention by comparison.
*I really think it's unfortunate that so many of the Blue Dog Democrats lost office in this election. The effect is to push the Democratic party further left at a time when it really needs to rethink the hard left turn the party took when Pelosi became Minority Leader. They were often replaced by Tea Partiers who seem to be frothing at the mouth- I think many of the principles the Tea Partiers claim to represent are worthy enough, but most of the politicians affiliated with it are total loons and an embarrassment to those principles.
I certainly wasn't saying that there aren't any use cases for >4GB. I'm saying that those uses are a minuscule fraction of all systems and zero percent of mobile systems. I'm also saying that the idea that it's inevitable that Moore's law and growing memory demands will soon make 64-bit pointers the best option for all kinds of uses, from the average user's desktop to microcontrollers, is mistaken.
PAE _is_ frequently used- whenever an x86-64 processor is in long mode it's using PAE. PAE has been around for a lot longer than long mode but few people had much of a reason to use it before long mode came around- not because it didn't accomplish anything but because memory was too expensive and people had little reason to use that much. On a processor where long mode is available there's little reason to use PAE without long mode- long mode gives you all those extra registers etc.
What I and my homeboy Knuth are talking about for x86 has more to do with the ABI than with hardware. As Knuth says some of the first places work would need to be done are the compiler etc and the libc; some OS support would also be required.
Yes, current 64-bit processors can't use more than 40 bits of physical memory or 48 bits of virtual. But the pointers are still the full 64 bits wide, and at no point does the processor store them in anything less than 64 bits. Limiting things to only using 48 bits of address space just simplifies MMUs etc, it doesn't save space. Trying to store other things in the unused bits in a register holding a 48 bit pointer would be more hassle than anybody wants to deal with. I mean, sure, you can do a bunch of bit twiddling to try to put junk in those other bits when you're storing a pointer, but it's going to be more expensive than it's worth.
I don't think there's any game out there which uses more than 4GB of address space in a single process, regardless of the settings you're using. If you can find concrete evidence of one, let me know.
Even finding situations where games really benefit from more than 4GB of total system memory is rare. I haven't seen too much in the way of benchmarks comparing differing amounts of RAM for this year's DX11 games, but I know that practically no games released before this year benefit from more than 3GB of system memory (of the benchmarks I saw the one which really contested that was published by Corsair, and they can't be accused of being indifferent to how much memory people buy). For games that do appear to benefit at their very highest detail settings at extreme resolutions, I'd still like to see evidence that the visual quality is noticeably different from what you get when you bump the settings down a notch and save a gig of RAM.
It's true that people working on films in ridiculously high resolutions and some 3d modeling/rendering/CAD folks may want more than 4GB of RAM available to a single process. But those and the other uses for >4GB in one process are a tiny portion of the overall market and have nothing at all to do with ARM and mobile. And you've vastly overstated the effort it takes to be able to support smaller pointers and the simplifications available if you stick with 64-bit.
Well, if taking that quote out of context gives you a chuckle or at least an ironic smirk, all the better. That's what I got out of taking the Poettering quote out of context and felt like sharing- of course it didn't prove anything.
I certainly don't hate the guy, and he's got a lot of talent and interesting ideas. It just seems that things would work out a lot better for everyone if he were a little more ready to consider others' ideas esp. if he actively solicited design input from those most likely to be impacted by his "brilliant redesigns". His saying over and over that Linus is an idiot for wanting to make tty-based cgroups an in-kernel default doesn't exactly inspire confidence in the notion that this ought to be in user space.
This isn't like the 16->32 bit transition where it quickly became apparent that the benefits were large enough and the costs both small enough and rapidly decreasing that all but the smallest microcontrollers could benefit from both the switch and the economies of scale. 64-bit pointers help only in select situations, they come at a large cost, and as fabs start reaching the atomic scale we're much less confident that Moore's Law will decrease those costs to the level of irrelevance anytime soon.
Most uses don't need >4 gigabytes of RAM, and it takes extra memory to compensate for huge pointers. Cache pressure increases, causing a performance drop. Sure, often x86-64 code beats 32-bit x86 code, but that's mostly because x86-64 adds registers on a very register-constrained architecture and partly because of wider integer and FP units. 64-bit addressing is usually a drag, and it's the addressing that makes a CPU "64-bit". ARM doesn't have a similar register constraint problem, and the cost of 64-bit pointers would be especially obvious in the mobile space, where cache is more constrained- one of the most important things ARM has done to increase performance in recent years was Thumb mode i.e. 16-bit instructions, decreasing cache pressure.
Most of those who do need more than 4GB don't need more than 4G of virtual address space for a single process, in which case having the OS use 64-bit addressing while apps use 32-bit pointers is a performance boon. The ideal for x86 (which nobody seems to have tried) would be to have x86-64 instructions and registers available to programs but have the programs use 32-bit pointers, as noted by no less than Don Knuth:
It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache.
The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space.
Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc.
Please, somebody, make that possible.
It's funny to continually hear people clamoring for native 64-bit versions of their applications when that often will just slow things down. One notable instance: Sun/Oracle have told people all along not to use a 64-bit JVM unless they really need a single JVM instance to use more than 4GB of memory, and the pointer compression scheme they use for the 64-bit JVM is vital to keeping a reasonable level of performance with today's systems.
If I compare the things Linus has done with what Poettering has done I think I know whose ideas I trust more.
Poettering seems to find things which are a mess and say "THIS looks like a job for SUPERMAN!!!!!!11" Since he's so brilliant and all, his design (done without consulting much with lesser mortals ) must be right, and if it breaks everything in the world and brings lots of design criticisms, well, the rest of the world and the critics (i.e. the morons) are what need fixing. Pulse was a disaster for years.
I posted this elsewhere first- in a discussion about how automakers complain that the MPG targets set for them are unrealistic- but it seems to fit here:
Advances in efficiency are offset by increased curb weight due to overdone crashworthiness standards and a crashworthiness arms race. If _your_ vehicle has a lot of mass between you and the front of the car, you're safer in a head-on collision. But if _everybody's_ cars have that increased mass, then you're not really safer.
Other reasons for a lack of progress include people's demands for higher acceleration performance (leading to big, heavy engines which use a lot of fuel) and other amenities. The automakers are right that the demand for higher efficiency isn't strong enough to outweigh costs and the demands for other amenities, and the only way this is likely to change is if fuel prices increase.
Fuel taxes and more balanced safety standards (recognizing safety v. efficiency is generally a tradeoff and so we really _don't_ want the safest cars possible) are the only things the government can do that will have a reliable and sizable effect in increasing average fleet efficiency. Just yelling at auto manufacturers for selling people what they want to buy isn't going to help.
They are essential. But they're also a lot more replaceable than core developers, and a project's development momentum doesn't depend that much on its tech support people. The article title makes it sound like "OMG, OpenOffice is going to stagnate and LibreOffice will rapidly become the New Shiny!" but Oracle still pays the bills for more of the actual programming effort than all the other contributors combined.
I'd sure like to see the community situation improved, but I don't think the LibreOffice folks have gone about this very well. Hopefully they and Oracle can get heads together and overcome this disappointing start.
If Apple had let Sun maintain the JVM for OS X, I really think desktop Java might have caught on. But Apple has long since treated Java like an unwanted stepchild- not only dragging their feet big time on Cocoa etc bindings for Java (they deprecated that in 2005) but hardly maintaining their own JVM.
As documented here, Apple waited a long time to make new versions of Java available- and then required an upgrade to get it. Users had to
wait 6 1/2 months for J2SE 1.4 (February 6- August 24, 2002) and pay $130 to upgrade to Jaguar
wait 7 months for J2SE 5.0 (September 30, 2004-April 29, 2005) and pay $130 to upgrade to Panther
wait 10 months for Java SE 6 (December 11, 2006-October 26, 2007)and pay $130 to upgrade to Leopard
On top of the wait and the pricing, each new OS release had a new list of unsupported machines. The end result is that even several years after a Java version update, you couldn't count on Mac users having the newer version. Even simple bugfixes and security updates took forever as well.
If Apple had allowed using a Sun or third-party JVM, this might not have been such a big deal. But when you can't count on having reasonable support on the platform with the second-biggest user base, the vaunted cross-platform compatibility meant little to application developers.
Why did apple do this? Does anybody have Apple or Sun inside info on this? I could understand abusing and discouraging Java after the success of the iPhone and the move toward being more of a walled playground- "use our API and our language or get lost" seems to have been the spiel since then-, but Apple's idiotic behavior in regards to Java started long before that point.
Slashdot Mirror
I thought that IE 9, with its much-improved standards compliance, was also going to support MathML. After seeing your post I did a quick search and found that it turns out that IE 9 doesn't even allow good MathML support with the proprietary (but free) MathPlayer plugin. Since this is one of the few features I have a reason to care about, I'm quite disappointed.
All the more reason for LED lights- one of the few applications where >5W LED lights have really taken off is installation in places where it would be difficult to replace a bulb, since the lifespan is tremendously longer than either incandescents or compact flourescents.
I think that the government move comes at a really unfortunate time. The novelty of cheap widespread CFLs has worn out- people don't like the warmup delay, the higher cost, the much-lower-than-advertised durability, and the disposal inconveniences. The thing to do with florescents is to rethink your lighting fixtures so you can use a non-compact florescent (better efficiency and lifespan) rather than a dozen separate bulbs.
LED lights are getting better all the time, and people are starting to find them to be worthwhile and practical for a lot of situations. I worry, however, that average consumers looking for solutions now will be turned off by the current high prices and other issues, and that improved LEDs a few years from now (by which time consumers may get fed up and get this bill repealed) will have a harder time catching on because of it.
Please try reading what you're replying to before replying. He wasn't saying energy use of an LED in service was high, he was saying manufacturing an LED takes more energy than manufacturing an incandescent.
Ok, if you were going to post a knee-jerk response about their intentions, motivation etc please note that MPEG != MPEG-LA.
I thought everyone who owned an iPhone prayed to Jobs (thrice daily, while facing Cupertino), has WWDC and Macworld Expo instead of communion, confessed their dalliances with non-Apple products to Geniuses at the Apple Store, and did penance by lashing out at those who criticize Apple products online.
Wouldn't being involved in Catholicism violate their First Commandment or something?
No kidding. And even with the dozens of hybrids out there, the 3rd most fuel-efficient car from the last 30 years (after the Prius and the Insight) is the 26-year-old Chevy Sprint (see http://www.popularmechanics.com/cars/news/fuel-economy/epa-fuel-efficient-cars-chevy-sprint ). Why hasn't three decades of engineering brought more progress?
Blame the curb weight arms race in safety regulations. Since heavier vehicles have better survivability than light vehicles in head-on collisions between the two, we all need our cars to weigh more, right? And you surely wouldn't purchase a car with less than perfect safety ratings, especially if you have a family! Four ton cars for everyone! Oh wait, if other peoples' cars coming at me weigh four tons, mine better weigh eight tons, just in case there's an accident...
Decades of engineering and advances in materials are going mostly towards offsetting higher curb weights "for safety's sake" rather than improving fuel mileage or power. I hope at some point people start to understand the tradeoffs involved and demand revised regulations and lighter, more efficient automobiles rather than taking one look at innovations (e.g. the Smartcar) and dismissing them as death traps just because they aren't heavy tanks.
From what I understand this has been brought up multiple times and they've basically said "sorry, we made a decision, we're stuck with it." When you've made a decision that causes practically everyone who hears of your product to do a facepalm and/or to groan "OH, THE HUMANITY!" you really need to learn that bad decisions can be unmade.
Like a lot of open-source software (most famously Linux before they decided everything from here on out would be 2.6), the odd point releases are the development branches.
I tried a random sampling of the humongous archive.org pdfs you linked to in a prerelease version of Sumatra and had no crashes and fairly decent performance. Dealing with ridiculous zoom levels, especially on raster images, is something they've fixed only recently, and no software is going to have fantastic performance at upscaling raster images (try using a 1600% zoom in the Gimp, for instance)- hardware acceleration can help, but most viewers don't have it.
Raster scans are a terrible way to use PDF, which, as a page description language, was designed primarily for text and vector graphics (with the occasional raster illustration). You'll notice archive.org also provides them in DjVu, which is designed for scanned documents; the djvu versions are about 1/3 the size of the pdfs and render faster than any pdf viewer can render the pdfs.
Would you be willing to describe your other issues besides >400% zoom levels and/or see if your files are working better with a pre-1.3 version?
I'm surprised to hear you say Sumatra has "poor rendering, performance and stability." Could you explain some of what you're referring to?
I wonder what the last version you tried was. The underlying MuPDF engine has come a long way since Krzysztof Kowalczyk decided to drop the option of using Poppler as a backend and focus on MuPDF back in version .9 two years ago.
[citation needed]
All the news articles I see say that the Lockheed-Martin hard drive fiasco included a missile defense system and data about the company (employees etc) but no aircraft data or blueprints.
At first glance, that looks exceedingly like an F-22 (I'm no expert-maybe specialists here can point out differences). I wonder what the odds are that this- like so many Chinese knockoffs- was designed with extensive engineering details about its competitors, gained in a clandestine manner?
No. The only way to make rare earths less rare is to make more earths, duh. Among other things, the cost of shipping a whole factory-built planet to the nearest Sol-like stars and the loud-mouthed protests of tree-huggers whining about resource depletion (jeez, it's not like anybody else was USING every little yottagram of that feldspar anyway) tend to discourage this.
On a side note: at least the FedEx guy could be a little more POLITE in telling me they don't ship to Tau Ceti. Sheesh. And just FYI, the USPS flat-rate boxes top out at a pathetic 1.3E-11 km^3.
And all zero of the posts about crashes due to firmware being distributed with the kernel. How did you get the idea that the topic at hand had anything to do with proprietary drivers?
Goldeneye's single player campaign was actually *better* than the movie. I played through it, thought "this was really neat, I should rent the movie!" and was thoroughly disappointed with it because its plot and script didn't compare well to the game's.
Uh- he didn't introduce those compromises as a "bridging the divide" type thing, he did those because there was absolutely no way a public option or a tax bill not extending the full Bush tax cut would have made it through Congress. Can't really credit him as a unifier for doing that when he only did so because circumstances forced him to --esp. the fact that not everyone in the Democratic caucus is on the far left*, the voters' rejection of the broader health care tack as manifest in the Scott Brown election and the loss of a filibuster-proof majority, and the imminent GOP House takeover.
Republicans aren't asking him to quit, just to come to the table and try to reach agreement *first* rather than only resorting to it when it's become apparent the legislation preferred by the left wing of his party can't be ramrodded down the nation's throat.
The level of political discourse has really dropped a lot over the past decade. The 2008 presidential debates and the petty partisanship of Congress over the last few years make even the 2000 Bush-Gore debates and the Clinton impeachment debacle look like Webster v Calhoun and the Constitutional Convention by comparison.
*I really think it's unfortunate that so many of the Blue Dog Democrats lost office in this election. The effect is to push the Democratic party further left at a time when it really needs to rethink the hard left turn the party took when Pelosi became Minority Leader. They were often replaced by Tea Partiers who seem to be frothing at the mouth- I think many of the principles the Tea Partiers claim to represent are worthy enough, but most of the politicians affiliated with it are total loons and an embarrassment to those principles.
I certainly wasn't saying that there aren't any use cases for >4GB. I'm saying that those uses are a minuscule fraction of all systems and zero percent of mobile systems. I'm also saying that the idea that it's inevitable that Moore's law and growing memory demands will soon make 64-bit pointers the best option for all kinds of uses, from the average user's desktop to microcontrollers, is mistaken.
PAE _is_ frequently used- whenever an x86-64 processor is in long mode it's using PAE. PAE has been around for a lot longer than long mode but few people had much of a reason to use it before long mode came around- not because it didn't accomplish anything but because memory was too expensive and people had little reason to use that much. On a processor where long mode is available there's little reason to use PAE without long mode- long mode gives you all those extra registers etc.
What I and my homeboy Knuth are talking about for x86 has more to do with the ABI than with hardware. As Knuth says some of the first places work would need to be done are the compiler etc and the libc; some OS support would also be required.
Yes, current 64-bit processors can't use more than 40 bits of physical memory or 48 bits of virtual. But the pointers are still the full 64 bits wide, and at no point does the processor store them in anything less than 64 bits. Limiting things to only using 48 bits of address space just simplifies MMUs etc, it doesn't save space. Trying to store other things in the unused bits in a register holding a 48 bit pointer would be more hassle than anybody wants to deal with. I mean, sure, you can do a bunch of bit twiddling to try to put junk in those other bits when you're storing a pointer, but it's going to be more expensive than it's worth.
I don't think there's any game out there which uses more than 4GB of address space in a single process, regardless of the settings you're using. If you can find concrete evidence of one, let me know.
Even finding situations where games really benefit from more than 4GB of total system memory is rare. I haven't seen too much in the way of benchmarks comparing differing amounts of RAM for this year's DX11 games, but I know that practically no games released before this year benefit from more than 3GB of system memory (of the benchmarks I saw the one which really contested that was published by Corsair, and they can't be accused of being indifferent to how much memory people buy). For games that do appear to benefit at their very highest detail settings at extreme resolutions, I'd still like to see evidence that the visual quality is noticeably different from what you get when you bump the settings down a notch and save a gig of RAM.
It's true that people working on films in ridiculously high resolutions and some 3d modeling/rendering/CAD folks may want more than 4GB of RAM available to a single process. But those and the other uses for >4GB in one process are a tiny portion of the overall market and have nothing at all to do with ARM and mobile. And you've vastly overstated the effort it takes to be able to support smaller pointers and the simplifications available if you stick with 64-bit.
Well, if taking that quote out of context gives you a chuckle or at least an ironic smirk, all the better. That's what I got out of taking the Poettering quote out of context and felt like sharing- of course it didn't prove anything.
I certainly don't hate the guy, and he's got a lot of talent and interesting ideas. It just seems that things would work out a lot better for everyone if he were a little more ready to consider others' ideas esp. if he actively solicited design input from those most likely to be impacted by his "brilliant redesigns". His saying over and over that Linus is an idiot for wanting to make tty-based cgroups an in-kernel default doesn't exactly inspire confidence in the notion that this ought to be in user space.
This isn't like the 16->32 bit transition where it quickly became apparent that the benefits were large enough and the costs both small enough and rapidly decreasing that all but the smallest microcontrollers could benefit from both the switch and the economies of scale. 64-bit pointers help only in select situations, they come at a large cost, and as fabs start reaching the atomic scale we're much less confident that Moore's Law will decrease those costs to the level of irrelevance anytime soon.
Most uses don't need >4 gigabytes of RAM, and it takes extra memory to compensate for huge pointers. Cache pressure increases, causing a performance drop. Sure, often x86-64 code beats 32-bit x86 code, but that's mostly because x86-64 adds registers on a very register-constrained architecture and partly because of wider integer and FP units. 64-bit addressing is usually a drag, and it's the addressing that makes a CPU "64-bit". ARM doesn't have a similar register constraint problem, and the cost of 64-bit pointers would be especially obvious in the mobile space, where cache is more constrained- one of the most important things ARM has done to increase performance in recent years was Thumb mode i.e. 16-bit instructions, decreasing cache pressure.
Most of those who do need more than 4GB don't need more than 4G of virtual address space for a single process, in which case having the OS use 64-bit addressing while apps use 32-bit pointers is a performance boon. The ideal for x86 (which nobody seems to have tried) would be to have x86-64 instructions and registers available to programs but have the programs use 32-bit pointers, as noted by no less than Don Knuth:
It's funny to continually hear people clamoring for native 64-bit versions of their applications when that often will just slow things down. One notable instance: Sun/Oracle have told people all along not to use a 64-bit JVM unless they really need a single JVM instance to use more than 4GB of memory, and the pointer compression scheme they use for the 64-bit JVM is vital to keeping a reasonable level of performance with today's systems.
If I compare the things Linus has done with what Poettering has done I think I know whose ideas I trust more.
Poettering seems to find things which are a mess and say "THIS looks like a job for SUPERMAN!!!!!!11" Since he's so brilliant and all, his design (done without consulting much with lesser mortals ) must be right, and if it breaks everything in the world and brings lots of design criticisms, well, the rest of the world and the critics (i.e. the morons) are what need fixing. Pulse was a disaster for years.
Favorite Poettering quote from this discussion: "Well, that nightmare already exists. It's systemd." Nightmare indeed.
I posted this elsewhere first- in a discussion about how automakers complain that the MPG targets set for them are unrealistic- but it seems to fit here:
The 3rd most fuel-efficient car in the last 30 years, after the Prius and the Insight, was the 26-year-old Chevy Sprint (see http://www.popularmechanics.com/cars/news/fuel-economy/epa-fuel-efficient-cars-chevy-sprint ). Overall, despite all the progress in engineering over the last 30 years, fuel efficiency hasn't increased all that much on average.
Advances in efficiency are offset by increased curb weight due to overdone crashworthiness standards and a crashworthiness arms race. If _your_ vehicle has a lot of mass between you and the front of the car, you're safer in a head-on collision. But if _everybody's_ cars have that increased mass, then you're not really safer.
Other reasons for a lack of progress include people's demands for higher acceleration performance (leading to big, heavy engines which use a lot of fuel) and other amenities. The automakers are right that the demand for higher efficiency isn't strong enough to outweigh costs and the demands for other amenities, and the only way this is likely to change is if fuel prices increase.
Fuel taxes and more balanced safety standards (recognizing safety v. efficiency is generally a tradeoff and so we really _don't_ want the safest cars possible) are the only things the government can do that will have a reliable and sizable effect in increasing average fleet efficiency. Just yelling at auto manufacturers for selling people what they want to buy isn't going to help.
They are essential. But they're also a lot more replaceable than core developers, and a project's development momentum doesn't depend that much on its tech support people. The article title makes it sound like "OMG, OpenOffice is going to stagnate and LibreOffice will rapidly become the New Shiny!" but Oracle still pays the bills for more of the actual programming effort than all the other contributors combined.
I'd sure like to see the community situation improved, but I don't think the LibreOffice folks have gone about this very well. Hopefully they and Oracle can get heads together and overcome this disappointing start.
That's the best comment I've seen on /. for a good while. Thanks.
On top of the wait and the pricing, each new OS release had a new list of unsupported machines. The end result is that even several years after a Java version update, you couldn't count on Mac users having the newer version. Even simple bugfixes and security updates took forever as well.
If Apple had allowed using a Sun or third-party JVM, this might not have been such a big deal. But when you can't count on having reasonable support on the platform with the second-biggest user base, the vaunted cross-platform compatibility meant little to application developers.
Why did apple do this? Does anybody have Apple or Sun inside info on this? I could understand abusing and discouraging Java after the success of the iPhone and the move toward being more of a walled playground- "use our API and our language or get lost" seems to have been the spiel since then-, but Apple's idiotic behavior in regards to Java started long before that point.