D's performance is not worse than C (older version of shoovtout since D's not in the most recent version). And it makes little sense to require the replacement language to be faster; except for things like runtime JIT optimizations, if there's a way to code it to run fast in any other language, you could, with sufficient effort, reproduce that performance with C code, though it might be a heckua lot more complicated.
Your arguments could just as well be used against the introduction of C and Fortran to replace programming directly in assembler: there were libraries in assembler which would be incompatible with some of what people did in C or Fortran, and if you can code something to run fast in C or Fortran you can, with sufficient effort you can get the same performance from code written directly in asm. But moving to higher-level languages had huge benefits for programmer efficiency and program safety, and a C developer may well write something which performs better than what an asm dev can write in the same amount of time. The same kind of advances can be realized by moving from C to a better language.
No, I'm not talking about variables. The main example here is functions. If I want foo() in foo.c to call bar(), in a modern language bar() can be declared after foo() in the same file, in any other source file with the proper visibility, or in any precompiled libraries which have the proper visibility. In C and C++, bar() has to be declared in the same source file as foo() and must be declared before foo(). The only way we can call functions defined in other files or in libraries is by pasting function declarations (usu. from.h files) into the body of foo.c using the preprocessor. If you have two functions in the same file which may need to call each other you need to have an empty declaration for one of them in the file, then write the real declaration of the other, then write the real declaration of the first.
For making a quick single-pass compiler on your PDP-7, this makes sense. It's a total anachronism in our day and age.
I'd like to see a scheme like the.xxx tld work well- simplifying things for people who don't want to encounter internet smut without error-prone filter setups and without futile attempts to keep that kind of stuff off the web entirely. But it looks like this is being done in the worst way possible.
Exorbitant registration fees will make it so this will never serve its intended purpose- most smut will be hosted on normal tlds just to save on fees. And the claimed "shakedown" racket makes no sense. If there's going to be porn which (ab)uses your trademark, it's not like registering a domain will wipe it out or even make it significantly harder to find. The best route for normal businesses would be to just ignore everything under that tld. It's not like the old whitehouse.com problem- if somebody says "I went to gerber.xxx and was SHOCKED to see what was there! For shame!" there's the easy rejoinder "What exactly were you doing looking up gerber.xxx, and what did you expect to find on an.xxx domain? Why would you think that's affiliated with us at all?" But this greedy registry wants to wring extra dough out of people by playing on their trademark paranoias.
Sure, the project hasn't gone anywhere for a while, and C# isn't going to be most people's choice for systems programming without a whole lot of changes. But we need to face the fact that C is outdated.
A lot of the basic tradeoffs made in its design are based on assumptions that are no longer true. An example: C's need to have everything declared in the same functional unit before use and reliance on preprocessor #includes. In 1970, saving compiler effort and putting this burden on the programmer rather than having a more complex system for resolving symbols may have been an acceptable tradeoff; with modern machines it's ridiculous. Many other C design decisions have been shown to cause problems, confusions, and common security-problem-inducing bugs.
In the past 40 years, a lot of new ideas have emerged which make writing software simpler, faster, and better-organized; some ideas which make code safer or allow the compiler etc to do better optimization have emerged too. Parallelization/multithreading and concurrency have come to the forefront of programming problems, and languages can do better at taking it into account.
All this time, we've been writing almost all our most critical software with the same language K&R designed 40 years ago, or with something like C++ which inherits all its problems and none of its simplicity. Sure, people can point out a handful of examples of OSes built in other high-level programming languages back in the day before C had major uptake. But just about every machine out there today runs on a C-based stack.
The industry needs to find a new direction sometime; we can't procrastinate it forever. Very few people have made serious efforts to replace C at the OS level with something more modern. Even D, which is one of the very few newer languages which really try to be able to replace C, has no major OS effort. We really need to get OS developers and language&compiler designers on the same page, find a better standard for systems programming, and create a platform which isn't dependent on the C legacy. I, for one, am not about to laugh at any project which attempts to undertake this daunting task.
One glorious day mobile pricing will be based entirely on bandwidth usage. Text messaging will be- for all intents and purposes- free, as the associated bandwidth costs carriers practically nil. Nobody will be punished for tethering their computer to their phone- data is data, however it gets consumed. You'll be able to use any phone/broadband modem/etc which adheres to standards with any carrier, and applications for your phone etc won't be under carrier control at all (goodbye to paying monthly fees for software which should be built in). Carriers will have to compete on price, and enough carriers will have coverage in any given area that prices will be much less painful (especially for light-bandwidth users)- they will better reflect the cost of providing service rather than the demands of monopoly profits.
Wireless coverage in Europe is already there on some of these counts. It will take a long hard battle to bring this kind of consumer-friendly atmosphere to the US. Blocking a merger like this which threatened to narrow competition down to two firms (Sprint would likely have been edged out and finally purchased by either the behemoth AT&T-mobile or Verizon) is only the beginning.
If Android were GPLv3 licensed not a single major manufacturer would have touched it and not a single major carrier would have offered such phones.
Google knew all these folks are way too obsessed with playing the patent game and way too distrustful of having to release all their code to use a GPL3-licensed platform. That's why just about everything in Android is Apache licensed (like BSD but with minimal patent licensing language).
The entirety of the rationale for this is in the bug's comment 3:
This feature is a priority of the Firefox UX lead and the Firefox Product lead.
Ass Dotzler and co have no real reason for doing this which they can communicate to others. They can only browbeat others into submission with titles.
Again, from the newsgroup, when someone said "I see little to no benefit by removing it (other than 'let's remove something else from the UI)'" Asa couldn't cite any real benefits but instead pulled rank to say "I'm more important than you, so there":
That is not the benefit that the UX and Product lead are after here and characterizing our intents like that is somewhat insulting. I expect that kind of nonsense from random slashdotters and trolls, but not from regular members of our community.
Because disagreeing with something Asa says and failing to comprehend that "DO AS I SAY, FOOLS" is sufficient reason for any change makes one a "troll."
I plan to "upgrade" my FF 5.0 with the latest 3.6.x version and hope that either Dotzler and the rest of those pushing pointless changes which are detrimental to the community are shown the door soon or that major corporate backers start a fork.
Almost every time there's a rival good- a finite resource which has to be allocated- setting a price on it is the fairest feasible solution. People who really need the resource will be willing to pay for it; those who don't need it as much will consume less of it than they would if it were free.
Bandwidth is such a resource. Just because you paid some third party like Netflix for the privilege of requesting their data over the 'net doesn't make it any easier on all the other people who want to use the same infrastructure for their communications. If the same network infrastructure can service either 100,000 business users or 1,000 Netflix users, you'd better believe the Netflix users should be paying the ISP 100x as much as the business users for access. Nothing else is remotely close to fair.
When you're broadcasting a TV signal on some part of the EM spectrum, as soon as you're actually transmitting using that frequency it makes no difference whether one person tunes in or everybody within reception range tunes in. It is a nonrival good. So paying by the minute for that doesn't make much sense.
It's nice to see people complaining about things ISPs do that are really worth complaining about for a change. I've been tired of hearing people on/. and elsewhere whining about ISPs charging for bandwidth usage ("All customers should get unlimited plans rather than per-GB rates, because bandwidth is free, right? It's so unfair that it'll cost me extra money to download all my dozens of GB of pirated movies!").
Of course this question would probably be better directed to one of the CERN folks, but...
Apparently the apps which actually do the work use a Scientific Linux base system with a bunch of software installed, and they don't want to try to port this whole stack so they're having people use VirtualBox and a VM image. But what about people who are already using Scientific Linux, people who'd be willing to run SL, or people who would be interested in dedicating a machine to the task? Wouldn't the speedups involved in removing the VM layer be significant enough to merit allowing this option?
(In addition, that would make it much simpler if they wanted to utilize GPGPU type resources in the future, since using a GPU under a VM can be pretty painful.)
Back when computers had very poor power management, that might have been borderline reasonable. But it's been almost a decade since dynamic frequency and voltage scaling became mainstream, and to do it now would be basically criminal (stealing considerable amounts of electricity for your own purposes, shortening folks' component lifespans due to higher temperature etc while you're at it).
If you can name a single desktop app which triggers the HotSpot bugs which this tempest in a teapot is all about, I'll be surprised.
Furthermore, Oracle won't push Java 7 via the auto-update before these bugs are fixed or indeed any time soon at all. In fact, I don't know that JRE 5 users were ever auto-updated to 6, and if they were, it was after JRE 5 was EOL'd (roughly three years after Java 6 was released, and long after most people had moved on of their own accord). The auto-updater is primarily for security fix purposes, so as long as security patches for the old version are still coming, users needn't be auto-upgraded.
I dislike the way Oracle has treated Apache and Google as much as anybody else, but false technical complaints don't help anybody's case.
No, but if you're a sysadmin you should read release notes before making major upgrades. Not too many end-users out there using Lucene or Solr. It's also not like Sun has pushed Java 7 to end users through Java Update either (I imagine it will be quite some time before they do that).
So only the dedicated early adopters who replace what all their enterprise search software is running on with a brand-new release branch immediately after its release without reading the release notes would be affected.
Nobody used aggressive optimizations? You're off your rocker. I think that's one of the first tweaks people go to when they're trying to tune Java performance. Yes, it wasn't used by the majority of people, but it would have been excusable to think that these options had seen enough testing from those enabling the option to catch any obvious bugs.
I don't see any sign that this is affecting many users other than the two Apache projects noted. The linked article says that the best case with the loop optimizations is a crash and worst case is incorrect behavior- but they're conveniently not mentioning how likely it is that your code would trigger this bug. I see no signs that the "Donâ(TM)t use Java 7 for anything" conclusion is anything other than totally overblown.
The fact that the bug is also present in Java 6 if you enable the (fairly common) non-default optimizations makes this whole thing sound basically non-newsworthy. "Some users have problems with new default options! News at 11!"
A bug which only affects a few existing pieces of software and can be worked around with a simple command line option doesn't seem to me to be a release blocker. I'd agree, though, that they should have put something in the release notes.
In related news, last month FreeDOS turned 17, and in September FreeDOS 1.0 will have been around for 5 years. They're finally gearing up for another release (low manpower and trouble with package management and the installer have hindered attempts to follow the "release early, release often" mantra), and could really use people's help testing and polishing off the 1.1 release.
Saying that a network which requires credentials linked to your identity "would do away with users' Fourth Amendment rights to privacy" is ridiculous. The only thing that the Fourth Amendment says about privacy is that the feds can't search your stuff without a warrant. What the devil does that have to do with when you choose to visit a site which won't work with you unless you reveal your true identity?
Extra, Extra! Read all about it! Gub'ment proposes new security technology for shops and inns, called "refusing to do business with you unless you tell us your real name." Union of patent medicine peddlers objects that it breaches their "right to privacy!"
Why do you say a blatant politically motivated lie "fits well"? Khrushchev made that up as part of his campaign to enforce state atheism; Gagarin and his family were Russian Orthodox. Many of the people involved in space exploration have been deeply religious; many have felt that their experience has deepened their appreciation for God's creation and that their relation to the Creator was a driving force in their quest for scientific discovery.
Two quotations from Werner von Braun, a Lutheran without whom we probably never would have put a man on the moon:
Science and religion are not antagonists. On the contrary, they are sisters. While science tries to learn more about the creation, religion tries to better understand the Creator. While through science man tries to harness the forces of nature around him, through religion he tries to harness the force of nature within him.
My experiences with science led me to God. They challenge science to prove the existence of God. But must we really light a candle to see the sun?
One of the main people responsible for the Shuttle program was Dr. James C. Fletcher, NASA administrator for 9 years, who was a faithful Mormon.
Atheists who fancy themselves armchair rocket scientists may not like it, but the space program has not only always been wrapped up in this "sentimental nonsense" - it would never have been possible without it. The men who had the vision to lead America to space were men of faith. In today's world, where militant and brash atheism is on the increase and where "spirituality" and saying "Lord, Lord" (cf Matt 7:21) have displaced real devotion and discipleship among many who claim to be religious, this nation no longer has the vision and the willpower to continue to blaze that trail.
I'll be building a mini-itx system this summer, and I find the cheaper (and possibly cooler) versions of Llano more interesting. Since the GPU side of the chip is rather bandwidth-limited, I wonder whether the lower-clocked and/or lower shader count (320 instead of 400) versions of the chip might perform almost as well as the highest-end chip all the sites I've seen have tested. Anybody seen reviews of any of the rest of the lineup?
Slashdot Mirror
D's performance is not worse than C (older version of shoovtout since D's not in the most recent version). And it makes little sense to require the replacement language to be faster; except for things like runtime JIT optimizations, if there's a way to code it to run fast in any other language, you could, with sufficient effort, reproduce that performance with C code, though it might be a heckua lot more complicated.
Your arguments could just as well be used against the introduction of C and Fortran to replace programming directly in assembler: there were libraries in assembler which would be incompatible with some of what people did in C or Fortran, and if you can code something to run fast in C or Fortran you can, with sufficient effort you can get the same performance from code written directly in asm. But moving to higher-level languages had huge benefits for programmer efficiency and program safety, and a C developer may well write something which performs better than what an asm dev can write in the same amount of time. The same kind of advances can be realized by moving from C to a better language.
No, I'm not talking about variables. The main example here is functions. If I want foo() in foo.c to call bar(), in a modern language bar() can be declared after foo() in the same file, in any other source file with the proper visibility, or in any precompiled libraries which have the proper visibility. In C and C++, bar() has to be declared in the same source file as foo() and must be declared before foo(). The only way we can call functions defined in other files or in libraries is by pasting function declarations (usu. from .h files) into the body of foo.c using the preprocessor. If you have two functions in the same file which may need to call each other you need to have an empty declaration for one of them in the file, then write the real declaration of the other, then write the real declaration of the first.
For making a quick single-pass compiler on your PDP-7, this makes sense. It's a total anachronism in our day and age.
I'd like to see a scheme like the .xxx tld work well- simplifying things for people who don't want to encounter internet smut without error-prone filter setups and without futile attempts to keep that kind of stuff off the web entirely. But it looks like this is being done in the worst way possible.
Exorbitant registration fees will make it so this will never serve its intended purpose- most smut will be hosted on normal tlds just to save on fees. And the claimed "shakedown" racket makes no sense. If there's going to be porn which (ab)uses your trademark, it's not like registering a domain will wipe it out or even make it significantly harder to find. The best route for normal businesses would be to just ignore everything under that tld. It's not like the old whitehouse.com problem- if somebody says "I went to gerber.xxx and was SHOCKED to see what was there! For shame!" there's the easy rejoinder "What exactly were you doing looking up gerber.xxx, and what did you expect to find on an .xxx domain? Why would you think that's affiliated with us at all?" But this greedy registry wants to wring extra dough out of people by playing on their trademark paranoias.
Sure, the project hasn't gone anywhere for a while, and C# isn't going to be most people's choice for systems programming without a whole lot of changes. But we need to face the fact that C is outdated.
A lot of the basic tradeoffs made in its design are based on assumptions that are no longer true. An example: C's need to have everything declared in the same functional unit before use and reliance on preprocessor #includes. In 1970, saving compiler effort and putting this burden on the programmer rather than having a more complex system for resolving symbols may have been an acceptable tradeoff; with modern machines it's ridiculous. Many other C design decisions have been shown to cause problems, confusions, and common security-problem-inducing bugs.
In the past 40 years, a lot of new ideas have emerged which make writing software simpler, faster, and better-organized; some ideas which make code safer or allow the compiler etc to do better optimization have emerged too. Parallelization/multithreading and concurrency have come to the forefront of programming problems, and languages can do better at taking it into account.
All this time, we've been writing almost all our most critical software with the same language K&R designed 40 years ago, or with something like C++ which inherits all its problems and none of its simplicity. Sure, people can point out a handful of examples of OSes built in other high-level programming languages back in the day before C had major uptake. But just about every machine out there today runs on a C-based stack.
The industry needs to find a new direction sometime; we can't procrastinate it forever. Very few people have made serious efforts to replace C at the OS level with something more modern. Even D, which is one of the very few newer languages which really try to be able to replace C, has no major OS effort. We really need to get OS developers and language&compiler designers on the same page, find a better standard for systems programming, and create a platform which isn't dependent on the C legacy. I, for one, am not about to laugh at any project which attempts to undertake this daunting task.
That's what this computer is good for.
One glorious day mobile pricing will be based entirely on bandwidth usage. Text messaging will be- for all intents and purposes- free, as the associated bandwidth costs carriers practically nil. Nobody will be punished for tethering their computer to their phone- data is data, however it gets consumed. You'll be able to use any phone/broadband modem/etc which adheres to standards with any carrier, and applications for your phone etc won't be under carrier control at all (goodbye to paying monthly fees for software which should be built in). Carriers will have to compete on price, and enough carriers will have coverage in any given area that prices will be much less painful (especially for light-bandwidth users)- they will better reflect the cost of providing service rather than the demands of monopoly profits.
Wireless coverage in Europe is already there on some of these counts. It will take a long hard battle to bring this kind of consumer-friendly atmosphere to the US. Blocking a merger like this which threatened to narrow competition down to two firms (Sprint would likely have been edged out and finally purchased by either the behemoth AT&T-mobile or Verizon) is only the beginning.
I agree with you that banning Asa would be a good idea (he's already had plenty of fair warning), but I don't think it's going to happen.
For some reason nobody in the upper echelons of Mozilla seems to be able to understand what a colossal liability to the project he's become.
Of course, make sure you've reviewed all of the compiler source code and bootstrapped the compiler from machine code you've reviewed as well.
If Android were GPLv3 licensed not a single major manufacturer would have touched it and not a single major carrier would have offered such phones.
Google knew all these folks are way too obsessed with playing the patent game and way too distrustful of having to release all their code to use a GPL3-licensed platform. That's why just about everything in Android is Apache licensed (like BSD but with minimal patent licensing language).
When you're talking about units, the plural of "stone" is "stone." Since a stone is 14lb, 50 lbs is 3 and 4/7 stone.
The entirety of the rationale for this is in the bug's comment 3:
Ass Dotzler and co have no real reason for doing this which they can communicate to others. They can only browbeat others into submission with titles.
Again, from the newsgroup, when someone said "I see little to no benefit by removing it (other than 'let's remove something else from the UI)'" Asa couldn't cite any real benefits but instead pulled rank to say "I'm more important than you, so there":
Because disagreeing with something Asa says and failing to comprehend that "DO AS I SAY, FOOLS" is sufficient reason for any change makes one a "troll."
I plan to "upgrade" my FF 5.0 with the latest 3.6.x version and hope that either Dotzler and the rest of those pushing pointless changes which are detrimental to the community are shown the door soon or that major corporate backers start a fork.
Almost every time there's a rival good- a finite resource which has to be allocated- setting a price on it is the fairest feasible solution. People who really need the resource will be willing to pay for it; those who don't need it as much will consume less of it than they would if it were free.
Bandwidth is such a resource. Just because you paid some third party like Netflix for the privilege of requesting their data over the 'net doesn't make it any easier on all the other people who want to use the same infrastructure for their communications. If the same network infrastructure can service either 100,000 business users or 1,000 Netflix users, you'd better believe the Netflix users should be paying the ISP 100x as much as the business users for access. Nothing else is remotely close to fair.
When you're broadcasting a TV signal on some part of the EM spectrum, as soon as you're actually transmitting using that frequency it makes no difference whether one person tunes in or everybody within reception range tunes in. It is a nonrival good. So paying by the minute for that doesn't make much sense.
It's nice to see people complaining about things ISPs do that are really worth complaining about for a change. I've been tired of hearing people on /. and elsewhere whining about ISPs charging for bandwidth usage ("All customers should get unlimited plans rather than per-GB rates, because bandwidth is free, right? It's so unfair that it'll cost me extra money to download all my dozens of GB of pirated movies!").
Of course this question would probably be better directed to one of the CERN folks, but...
Apparently the apps which actually do the work use a Scientific Linux base system with a bunch of software installed, and they don't want to try to port this whole stack so they're having people use VirtualBox and a VM image. But what about people who are already using Scientific Linux, people who'd be willing to run SL, or people who would be interested in dedicating a machine to the task? Wouldn't the speedups involved in removing the VM layer be significant enough to merit allowing this option?
(In addition, that would make it much simpler if they wanted to utilize GPGPU type resources in the future, since using a GPU under a VM can be pretty painful.)
Back when computers had very poor power management, that might have been borderline reasonable. But it's been almost a decade since dynamic frequency and voltage scaling became mainstream, and to do it now would be basically criminal (stealing considerable amounts of electricity for your own purposes, shortening folks' component lifespans due to higher temperature etc while you're at it).
If you can name a single desktop app which triggers the HotSpot bugs which this tempest in a teapot is all about, I'll be surprised.
Furthermore, Oracle won't push Java 7 via the auto-update before these bugs are fixed or indeed any time soon at all. In fact, I don't know that JRE 5 users were ever auto-updated to 6, and if they were, it was after JRE 5 was EOL'd (roughly three years after Java 6 was released, and long after most people had moved on of their own accord). The auto-updater is primarily for security fix purposes, so as long as security patches for the old version are still coming, users needn't be auto-upgraded.
I dislike the way Oracle has treated Apache and Google as much as anybody else, but false technical complaints don't help anybody's case.
No, but if you're a sysadmin you should read release notes before making major upgrades. Not too many end-users out there using Lucene or Solr. It's also not like Sun has pushed Java 7 to end users through Java Update either (I imagine it will be quite some time before they do that).
So only the dedicated early adopters who replace what all their enterprise search software is running on with a brand-new release branch immediately after its release without reading the release notes would be affected.
Nobody used aggressive optimizations? You're off your rocker. I think that's one of the first tweaks people go to when they're trying to tune Java performance. Yes, it wasn't used by the majority of people, but it would have been excusable to think that these options had seen enough testing from those enabling the option to catch any obvious bugs.
I don't see any sign that this is affecting many users other than the two Apache projects noted. The linked article says that the best case with the loop optimizations is a crash and worst case is incorrect behavior- but they're conveniently not mentioning how likely it is that your code would trigger this bug. I see no signs that the "Donâ(TM)t use Java 7 for anything" conclusion is anything other than totally overblown.
The fact that the bug is also present in Java 6 if you enable the (fairly common) non-default optimizations makes this whole thing sound basically non-newsworthy. "Some users have problems with new default options! News at 11!"
A bug which only affects a few existing pieces of software and can be worked around with a simple command line option doesn't seem to me to be a release blocker. I'd agree, though, that they should have put something in the release notes.
In related news, last month FreeDOS turned 17, and in September FreeDOS 1.0 will have been around for 5 years. They're finally gearing up for another release (low manpower and trouble with package management and the installer have hindered attempts to follow the "release early, release often" mantra), and could really use people's help testing and polishing off the 1.1 release.
Wouldn't that be kind of like having North Korea chair the Nuclear Disarmament Committee?
Saying that a network which requires credentials linked to your identity "would do away with users' Fourth Amendment rights to privacy" is ridiculous. The only thing that the Fourth Amendment says about privacy is that the feds can't search your stuff without a warrant. What the devil does that have to do with when you choose to visit a site which won't work with you unless you reveal your true identity?
Extra, Extra! Read all about it! Gub'ment proposes new security technology for shops and inns, called "refusing to do business with you unless you tell us your real name." Union of patent medicine peddlers objects that it breaches their "right to privacy!"
Why do you say a blatant politically motivated lie "fits well"? Khrushchev made that up as part of his campaign to enforce state atheism; Gagarin and his family were Russian Orthodox. Many of the people involved in space exploration have been deeply religious; many have felt that their experience has deepened their appreciation for God's creation and that their relation to the Creator was a driving force in their quest for scientific discovery.
Two quotations from Werner von Braun, a Lutheran without whom we probably never would have put a man on the moon:
For more about Von Braun's faith see here.
One of the main people responsible for the Shuttle program was Dr. James C. Fletcher, NASA administrator for 9 years, who was a faithful Mormon.
Atheists who fancy themselves armchair rocket scientists may not like it, but the space program has not only always been wrapped up in this "sentimental nonsense" - it would never have been possible without it. The men who had the vision to lead America to space were men of faith. In today's world, where militant and brash atheism is on the increase and where "spirituality" and saying "Lord, Lord" (cf Matt 7:21) have displaced real devotion and discipleship among many who claim to be religious, this nation no longer has the vision and the willpower to continue to blaze that trail.
That review, like all the others I've seen, only covered the A8-3850. Totally irrelevant to what I was asking.
I'll be building a mini-itx system this summer, and I find the cheaper (and possibly cooler) versions of Llano more interesting. Since the GPU side of the chip is rather bandwidth-limited, I wonder whether the lower-clocked and/or lower shader count (320 instead of 400) versions of the chip might perform almost as well as the highest-end chip all the sites I've seen have tested. Anybody seen reviews of any of the rest of the lineup?