A bit by bit comparison doesn't really make sense.
If you meant comparing binary audio data bit by bit, you'd be right, but "bit rate" here means, how big the resulting compressed file may be; how big compression ratio is achieved.
Since higher compression ratios trade quality to quantity (higher compress ratio means lower sound quality, without an exception for well-designed compressors),
it should be trivially obvious to anyone that bit-rate, then, is absolutely totally completely relevant here, as an input parameter. Comparing applets to apples; it's not fair to use 256 kbps for some formats and 64 kbps for others. The only possible case where different bit rates should be used, then, would be the "highest possible quality" if the formats have upper limit for input bit-rate... But that's bit silly, too, since the whole point of these formats is to compress.
Well... Personally, I have all my music (minus few LPs) on CD (which are, *gasp* actually purchased!), and I can (and already partially have) encode them in any new format (ogg vorbis in my case) I want. I consider mp3 files to be binaries, and originals (CD) to be the source. No one would de-compile binaries, then re-compile using a new better compiler... So why should anyone do the same with mp3 to ogg either (anyone ignorant enough to convert from lossy format to another lossy format deserves the piss-poor quality he gets). Ok, well, I know... people with tons of pirated mp3s from Napster might want to do it. Somehow I just don't feel for them, though.
Also... you are assuming all the world's music is already here, and in MP3. There'll be new music created that can be encoded using better formats, and of course not everyone has converted music to mp3 yet in the first place. There's plenty of room for new better formats.
Actually, my understanding is that everywhere ISPs (amongst other corporations) are desperately wanting to get into pay-for-content business. Now, the idea is (or IMO should be) like: "instead of user paying $10 / month for site subscription, we (ISP) pay site $0.5 for each user we have and charge users $1". And, in theory at least, if enough people do find this useful (I'd guess at least like 1/4 of ISP customers being regular readers), everybody would win. Assuming, of course, that other ISP customers would get some other content that they do read, for deeply "discounted" prices. ISP would earn more money, content providers most likely would earn more; not many people want to individually subscribe... And even if they do, for getting advertiser money, nominal 5x or 10x addition could easily allow them to charge less from readers themselves.
It's also good to note that the idea of per-ISP access is not new. Universities do have deals with sites like Webster or various scientific papers and magazines so that their faculty and students get "free" access to the services, when university pays a fixed sum, probably based on number of potential readers.
Even though I can see potential problems with paying for stuff you don't care about, that is exactly what you get with newspapers, magazines and TVs. Not all articles are interesting or good; you probably downright hate many of them. And still, there are good ones too, and those make it worth the subscription. Of course the power customers have in choosing what they want affects the success of these programs... But the basic idea might not be all that bad as many writers here have declared.
Besides; couldn't this be a new chance for smallers ISPs too? I would guess that even though big ISPs will get bigger discounts, smaller ISPs might be able to focus more closely on exactly what their customers want. Or, they could divide the IP-address space (including DHCP) so that they'd have "virtual ISP"s, if the IP-nubers are used for access/blocking, and their customers could choose which domain they want to be part of.
Well, anyway, it might be good to carefully consider all possibilities of the idea before
dismissing as yet another Corporate Plot.
Although it may be that 2 x Single-Processor system in many cases is better than 1 x Dual-processor, there are some benefits from having a SMP system:
You can share most other components; maintainability is better (one monitor, as many HDs as you need, one case, one motherboard even though it's more expensive etc.). And even though it's kind of a "single point of failure", it's no different really from having more systems, if they all have to be up for the service to be available (ie. no redundant backup systems)
For closely-coupled processes SMP is faster than UPs talking via Ethernet; most web-servers talk to databases, and direct communication is more efficient than talking via 100mb (or even gig) Ether. And DBs generally scale quite nicely to multiple SMP systems.
Bit irrelevant here, but I certainly enjoyed double-PII work station I had few years back... interactive response _is_ much better (on Linux too)
So... it's more convenient IMO to have dual/quadruple system than N single-CPU system.
Most important, though, is what everyone and their donkey has said; it all depends on what you plan to do with your system.
Yeah, I should have added a disclaimer like "then again, not all managers are good or average...". I think lately I've been lucky to have decent managers.
Funny story btw, it's always nice to hear from
real life PHBs (esp. if it's someone else having them as managers).
Don't forget the instructions that accompany crappy Made in Taiwan/China/Korea products! I wish I had some examples handy, they should be winners. And of course about any tech specs written by non-native english speakers for companies that use english as their official language (I've seen quite a few Nokia telephone exchange s/w software specs... they're hilarious... written by fellow finnish programmers).
I don't think that's what he meant actually. I do know very well how some very very skilled programmers have perversely inflated egos and unhealthy attitudes, and the thing is that at that point the technical genius is pretty much useless. There are things that are too big to be handled by single individual (no matter how smart and capable), and at that point Prima Donnas are to be avoided at all costs. And of course, the risk of losing a PD should be considered too. Having one huge rotten egg in your basket stinks, even more when it breaks...
There are so many ways to avoid writing crappy code that refusal should seldom be necessary. And good (even average) managers know better than to force-feed their implementation ideas to the guy that actually does the implementation and is most likely in better position to do the design. However, by same token, skilled professional programmers know, too, better than to refuse to do things they are asked to. What I mean is "what" is usually decided by other people than "how" (should be obvious of course).
One interesting thing to note is that there are more than one 'level of bundling' to magazines and newspapers.
You can buy a single copy, but you can't buy just one article. This doesn't seem to be a problem for most people; I can't remember anyone complaining about buying "just articles written by mr. Metcalfe" (ok ok poor example, replace the name with someone with a clue who writes articles), or even just one single article.
With www it would be possible to offer practically unlimited granularity for ordering things; from single articles (web pages, songs, whatever) to full-featured channel set subscriptsion (a la cable / satellite tv). Pricing scheme would most likely be somehow logarithmic, ie. ten times more content for twice the price (and vice versa); bundling seems to be a good way of marketing stuff. It's not a coincidence that you can't order just 2 channels you like from your cable provider.
Depending on how smart content providers are, they try hard to avoid at least one of the situations. Traditionally, monopolistic blood-sucking companies (no, not referring to billsoft, but rather telemonopolies) tried really hard to eliminate any chance anyone ever would get any free stuff. As a result, telephone exchange software is goddamn awfully complicated, compared to what would be needed for everything except for charging (and related things, keeping track of call durations etc... a professor once claimed that half of processing was directly related to keeping track of call times).
One wonders if they would actually have saved quite a bit by just using simpler s/w and accepting that occasionally they might miss a few chargable cycles.
I would guess, though, that succesful companies would put more effort in making sure no one ever pays for stuff they don't get, because that is sure to make people really mad. Losing few micropayments isn't a big deal as long as percentage is reasonably small. It can be considered reasonable overhead.
I think this is indeed a VERY good point. Instead of micro-payment, it might be good idea to consider 'macro-payments'. Although on surface it sounds like "channels-by-another-name", it need not repeat the push-technology hype-fiasco.
There was a good article about non-technical problems of micro-payments (namely that people hate the idea and are willing to pay more for fixed price than for cheaper on long run pay-as-you-use), and it did mention alternatives, of which one is newspaper - like subscriptions.
So, even though TV channels are not really a good analogy for web content, perhaps some version of syndication might work better than full micro subscriptions.
This is even more logical considering the situation of (TV) content providers. Not many people would subscribe to any of 'minority' TV-channels in USA, but since you'll get 50 or 100 or 200 channels bundled, you do get your jesus channel as well as spanish soap opera channel and n+1 tv shop channels (or "car and driver channel" etc. etc.). And that's a great deal for those 'small' channels; they don't get as much as more popular ones, but they do get much more than they would if they tried selling channels directly to customers.
It's nice that you have found the products you advocate useful. Fine. I was mostly commenting on your "XPress just sucks so bad no-one with half a brain should ever use it". I just hate seeing something that looks like Yet Another "love to hate Quark" comment; every time there's a mention about QuarkXPress there are n+1 trolls whining. I have to give you some credit for actually explaining things on this post, so I guess it's not the regular 13-on-dozen type of whine. Not that I should care, I have no special interest in Quark, and don't use XPress at this point.
As to specific limitations; you list some of them you are mistaken with. Scripting is there, although only on Mac, AppleScript... but that is _very_ extensive. Colour systems I thought were extensive but I guess depends on your needs. Mixing layouts... I'm not sure exactly what you mean, but I'd say using different masters for different pages is exactly that? Drop caps etc. I think are there (or was it just 5.0 alpha).
Of the rest, some are being fixed, some not (I have seen the list of 5.0 features, tables are there, kickass html, layers, links in PDF, more gfx input and output formats).
I've also seen top-20 wish list (was on their web-page at some point?), and of the things you mention, "multiple undo" certainly is nr. 1 (and also slated for 5.x, not for 5.0... it'll come but certainly it's way later than it should be). After multiple undo, tables and layers were next ones (which will be implemented) on that list.
Finally, like you say, many of the features are provided with extra packages. What is remarkable (IMO) is that these are provided by 3rd party companies, not Quark. Which is no minor feat, adding complex functionality using just a published API. From developer's point of view, this is one of strong features of XPress (I've heard InDesign has decent, although bit too complicated plug-in API as well). Even when it's a bitch to get these expansion sets, thing is, they at least _are available_. And for newspapers etc., having customized/-able extensions to create their classified ads directly from a database is very useful; and there's no reason why Quark should provide those. Others can, easily, both via scripting and 'native' XTension API, and that's why there are quite a few independent 'XPress developers' around.
Please remove your feet from your mouth before answering. QuarkXPress has its own weird UI, mostly because users who are (now) familiar with it, want it that way. Ever wonder why Adobe copied the whole UI verbatim (in 'compatibility mode' or whatever they call it)?
As to its power, its main power (kickass print output) is internal. And although 5.x is still not out, it actually has most missing common functionality (from tables and layers to decent html output, not InDesign's joke html...)
I'm not familiar enough with CD or Ventura to comment in length, but my guess is that you just don't understand business where XPress is _the_ tool; when actually creating complex layouts combining gfx and text, requiring professional quality print outs.
Drawing programs are good for 'pure' gfx (and simple text effects), word processors are good for 'pure' text editing and simple gfx. XPress combines both nicely, and, lo and behold, prints them out in quality most other applications can only dream of.
The biggest downside is the price tag, but that's usually not all that relevant for ad agencies etc.
Second reason is that GSM generally has smaller cell sizes and the U.S. has a
much larger geographic range to cover than Europe
While this may have affected the decision, it's
good to keep in mind that this didn't prevent very sparsely populated countries like Sweden, Finland and Norway (with population density similar to state of Colorado, and about half the average US population density) from building extensive GSM networks, in addition to their existing analog networks. It really is weird that these countries, even though the geography should be a big problem, have the least expensive calls, best plans, compared to bigger and "more dense" (perhaps not only in population...) countries.
Well, my memory may fail me but what I think used to happen was that every 64th bit on a digital line was used for (additional) signaling. So, raw bandwidth is/was 64 kbps, but alas, snatching that one bit meant not everything could be used. Worse, since technically there's no way to just disregard that one bit from every 8th octet (because there's no synchronization to tell which 'frame' you have on that basic channel), what is/was done was to disregard that bit position for the whole stream. Thus 56 kbps (7/8 * 64).
I think the reason for doing this interesting in-band signaling was the fact that with T1 all 24 channels were used for payload, whereas E1 uses one (or was it more?) of 32 channels exclusively for signalling. I'm sure this isn't 100% accurate description, it's been few years since I got through the telecomm courses... But it's something along those lines.:-)
Yeah, let's just waste everyone's money and time by doing "let's just not regulate anything". Those damn socialist europeans may have better more compatible networks, where competition is at least as fierce (depends on country) as in US, but we have our Freedom to do things stupid way. Why is it so hard to combine basic open market idea with some sane standardization? Way (too) many european countries (France being the worst) do things is too bureaucratic, too centralized, too heavy-weight; sure, but in case of GSM things worked out well.
The thing was that before GSM, all (at least big) nations had their very own home-grown (analog) mobile phone networks. The exception was NMT (Nordic Mobile Telephone) network, which was common to (small) scandinavian countries. Countries that didn't have enough resources to waste (or inflated ego to boost) to create a national non-compatible system. It worked out reasonably well... It's no coincidence companies like Nokia and Ericsson are located in those countries.
At that point a minor miracle happened; people with some (regulatory) power realized the stupidity of going Not-invented-here route, and GSM standards committee was formed. What's even more amazing, I guess, is that things worked out well. Committees have been known to decimate decent plans before.:-)
People should be more open-minded about learning from experiences others have had, both good and bad. In this particular case there's little doubt which way worked out better; complete laissez-faire (USA) or slightly more regulated (not heavily regulated; there was no mandatory use of GSM... but operators generally did choose it over other options) european co-operative way.
Just an idea (which probably is totally wrong); perhaps they view this as an opportunity for competitors like AMD to get their hands on useful compiler technology? And perhaps also they think that compiler implementation might give hints about internal chip design (far-fetched?).
Of course it could and may well be just good old-fashioned corporate culture, where giving away stuff is "so dot.com".:-)
I may sound like a troll of sorts or anti Intel, but when it comes to high end scientific
engineering does anyone actually use anything outside the realms of Sun, Irix, and Alpha?
That trio has traditionally been top pack for projects with enough money (I loved our alphastations), but like others say, price/performance ratio favours x86. In future, though, the biggest problem is that out of 3, only one seems to survive on medium term: Alpha will be discontinued (see other articles at./), and it seems to be only matter of time when same happens to SGI stuff (if not to the whole company, much like to DEC).
Also, what about HP-PA? It used to be a good performer on benchmarks at some point? Its future looks very bleak too, of course, but I'm just curious whether it was used by scientist (or just faithful HP customers running legacy accounting applications... that's where I saw it most often).
While true, the benefit of Java/.NET over gcc is that most people don't keep on recompiling their applications (or get the correct one installed, if there's a choice), whereas transparent recompilation JIT happens independent of users actions. Downside with (current, at least) Java JITs is that they do this every time application runs, which is unfortunate. Would be nice if they did cache the end result, perhaps just checking timestamps of bytecode files vs. native compilations (and save the native stuff in the first place).
Oh please. I doubt many experience s/w engineers love async operations (I/O or otherwise). Conceptually using blocking threads (like in Java) is _MUCH_ simpler, and therefore generally leads to code that actually works. Async operations means that operations have to be somehow polled if you want any concurrency. And if you don't just do the queuing on your threads.
Free Java implementations are starting to overshadow the JDK, especially in the Linux
community.
Hmmh. I'm a supporter of both Free and Open software (and have contributed few small patches for Kaffe), but really, without flaming, I'm interested in hearing which Free JDKs are overshadowing Sun JDKs? I can't think of any off-hand.
IBM has decent JVMs, but only their compiler (Jikes, which rocks) is really free; VM or key tools are not. Blackdown ports Sun's JDK and it's not really free (it doesn't cost you, but to get source you need to "sell your soul" like with vanilla Sun JDK). I haven't been closely following Classpath, Japhar or jgc, but certainly hope they mature. But, time is not quite yet.:-(
As far as I know, none of really free alternatives even have independent Swing implementation. I'd _love_ to see one, but I've been reading mailing lists enough to understand it's non-trivial thing to do (well, I've developed using Swing so that's kind of obvious). And before Swing is available... well, perhaps since right now Java is big on server side that's not all that fatal, but it seems really unfortunate that the key widget set of the language is missing.
But then again, keep in mind that Sun is not making any money directly with JDK (and not much for other tools like Forte either); it's more about mindshare and priced leadership in the arena. Originally JDK was supposed to be "just" the reference implementation. I guess Sun has never really decided if it should be more or not, though.
This was the Golden Age of French
literature, Voltaire, Hugo, Verne, all the great masters of literature knew they could
write great works of literature without having to dumb them down for the people, and
still make a decent living. Once the people revolted against their master though, they
threw the baby out with the bathwater and copyright was abolished. Instantly, French
literature began a race to the bottom of the cess pool from which it (and the other
French arts has never recovered).
...
Once authors realized that
they would work for years polishing their craft, and then never recoup a bit of their
investment, they stopped writing in French.
And so they started writing in what instead? English?! That sounds like an urban legend, actually; french people are rather proud of their culture, and have been both before and after Voltaire et al.
Abolishing copyrights may have been causing (and may cause) problems, but scenario like you suggest (which makes french literature and other culture sound like Hollywood-level garbage) sounds rather far-fetched.
Not that I'm all that against certain kind of copyrights (or other mechanisms for trying to support artits capability of earning their living from their work), but it's silly spouting nonsense like this to support your beliefs.
Also... What exactly did ex-president Clinton do different (in copyright front) than the war crazy national-debt-loving second rate actor Reagan? (here I am quoting a widely held french, or european, belief of mr. RR by the way)
What is interesting, though, is that according to a few studies, having mixed species forest is a benefit for lumber/paper industry too. Not only are those forests less vulnerable to various tree diseases, the trees also tend to grow faster (possibly related to better resistance).
This was studied quite a bit in Finland a while ago, and (hopefully) has changed the procedures used when re-planting cut down forest. The problem there, too, was that industry wanted pure pine forests, without leaf trees (like birches or aspends). The (only) downside is/was that it's slightly easier not to worry about 'wrong' trees when harvesting. Shouldn't be much of a problem now that most of the cuttings are partial ones (not the 'cut down everything' style that was popular earlier)
So... it may be that economy and ecology occasionally lead to same direction. Not common perhaps, but happens.
Definitely, second vote for LCTS, it's a great book. Tragic facts, touching scenes, and still furnished with DA's masterful humour (stories about buying condoms in China and such made my stomach hurt from laughing)
Slightly related to this article, too; there was a mention of another nearly extinct tree growing in Mauritius in that book, wasn't there? (or was it on some other island in Indian pacific, Maledives perhaps?)
Like an AC asked; how is that different from non-AS people? Biologists suspect indian tribes had actually managed to extinct a few large mammals long before europeans (of which english people were but a part) came. In Europe, all nations and tribes have succesfully gotten rid of large felines, most bears and hordes of other specii/genii.
The fact aussies and americans appear to have done more damage has more to do with vast land masses of these countries, than with any specific intrinsic drive to destroy. I'm afraid the same traits are present with all people, although ignorancy probably plays a bigger part than actual maliciousness.
Slashdot Mirror
A bit by bit comparison doesn't really make sense. If you meant comparing binary audio data bit by bit, you'd be right, but "bit rate" here means, how big the resulting compressed file may be; how big compression ratio is achieved. Since higher compression ratios trade quality to quantity (higher compress ratio means lower sound quality, without an exception for well-designed compressors), it should be trivially obvious to anyone that bit-rate, then, is absolutely totally completely relevant here, as an input parameter. Comparing applets to apples; it's not fair to use 256 kbps for some formats and 64 kbps for others. The only possible case where different bit rates should be used, then, would be the "highest possible quality" if the formats have upper limit for input bit-rate... But that's bit silly, too, since the whole point of these formats is to compress.
Also... you are assuming all the world's music is already here, and in MP3. There'll be new music created that can be encoded using better formats, and of course not everyone has converted music to mp3 yet in the first place. There's plenty of room for new better formats.
It's also good to note that the idea of per-ISP access is not new. Universities do have deals with sites like Webster or various scientific papers and magazines so that their faculty and students get "free" access to the services, when university pays a fixed sum, probably based on number of potential readers.
Even though I can see potential problems with paying for stuff you don't care about, that is exactly what you get with newspapers, magazines and TVs. Not all articles are interesting or good; you probably downright hate many of them. And still, there are good ones too, and those make it worth the subscription. Of course the power customers have in choosing what they want affects the success of these programs... But the basic idea might not be all that bad as many writers here have declared.
Besides; couldn't this be a new chance for smallers ISPs too? I would guess that even though big ISPs will get bigger discounts, smaller ISPs might be able to focus more closely on exactly what their customers want. Or, they could divide the IP-address space (including DHCP) so that they'd have "virtual ISP"s, if the IP-nubers are used for access/blocking, and their customers could choose which domain they want to be part of.
Well, anyway, it might be good to carefully consider all possibilities of the idea before dismissing as yet another Corporate Plot.
So... it's more convenient IMO to have dual/quadruple system than N single-CPU system.
Most important, though, is what everyone and their donkey has said; it all depends on what you plan to do with your system.
Funny story btw, it's always nice to hear from real life PHBs (esp. if it's someone else having them as managers).
Don't forget the instructions that accompany crappy Made in Taiwan/China/Korea products! I wish I had some examples handy, they should be winners. And of course about any tech specs written by non-native english speakers for companies that use english as their official language (I've seen quite a few Nokia telephone exchange s/w software specs... they're hilarious... written by fellow finnish programmers).
There are so many ways to avoid writing crappy code that refusal should seldom be necessary. And good (even average) managers know better than to force-feed their implementation ideas to the guy that actually does the implementation and is most likely in better position to do the design. However, by same token, skilled professional programmers know, too, better than to refuse to do things they are asked to. What I mean is "what" is usually decided by other people than "how" (should be obvious of course).
With www it would be possible to offer practically unlimited granularity for ordering things; from single articles (web pages, songs, whatever) to full-featured channel set subscriptsion (a la cable / satellite tv). Pricing scheme would most likely be somehow logarithmic, ie. ten times more content for twice the price (and vice versa); bundling seems to be a good way of marketing stuff. It's not a coincidence that you can't order just 2 channels you like from your cable provider.
I would guess, though, that succesful companies would put more effort in making sure no one ever pays for stuff they don't get, because that is sure to make people really mad. Losing few micropayments isn't a big deal as long as percentage is reasonably small. It can be considered reasonable overhead.
There was a good article about non-technical problems of micro-payments (namely that people hate the idea and are willing to pay more for fixed price than for cheaper on long run pay-as-you-use), and it did mention alternatives, of which one is newspaper - like subscriptions.
So, even though TV channels are not really a good analogy for web content, perhaps some version of syndication might work better than full micro subscriptions.
This is even more logical considering the situation of (TV) content providers. Not many people would subscribe to any of 'minority' TV-channels in USA, but since you'll get 50 or 100 or 200 channels bundled, you do get your jesus channel as well as spanish soap opera channel and n+1 tv shop channels (or "car and driver channel" etc. etc.). And that's a great deal for those 'small' channels; they don't get as much as more popular ones, but they do get much more than they would if they tried selling channels directly to customers.
As to specific limitations; you list some of them you are mistaken with. Scripting is there, although only on Mac, AppleScript... but that is _very_ extensive. Colour systems I thought were extensive but I guess depends on your needs. Mixing layouts... I'm not sure exactly what you mean, but I'd say using different masters for different pages is exactly that? Drop caps etc. I think are there (or was it just 5.0 alpha).
Of the rest, some are being fixed, some not (I have seen the list of 5.0 features, tables are there, kickass html, layers, links in PDF, more gfx input and output formats). I've also seen top-20 wish list (was on their web-page at some point?), and of the things you mention, "multiple undo" certainly is nr. 1 (and also slated for 5.x, not for 5.0... it'll come but certainly it's way later than it should be). After multiple undo, tables and layers were next ones (which will be implemented) on that list.
Finally, like you say, many of the features are provided with extra packages. What is remarkable (IMO) is that these are provided by 3rd party companies, not Quark. Which is no minor feat, adding complex functionality using just a published API. From developer's point of view, this is one of strong features of XPress (I've heard InDesign has decent, although bit too complicated plug-in API as well). Even when it's a bitch to get these expansion sets, thing is, they at least _are available_. And for newspapers etc., having customized/-able extensions to create their classified ads directly from a database is very useful; and there's no reason why Quark should provide those. Others can, easily, both via scripting and 'native' XTension API, and that's why there are quite a few independent 'XPress developers' around.
As to its power, its main power (kickass print output) is internal. And although 5.x is still not out, it actually has most missing common functionality (from tables and layers to decent html output, not InDesign's joke html...)
I'm not familiar enough with CD or Ventura to comment in length, but my guess is that you just don't understand business where XPress is _the_ tool; when actually creating complex layouts combining gfx and text, requiring professional quality print outs. Drawing programs are good for 'pure' gfx (and simple text effects), word processors are good for 'pure' text editing and simple gfx. XPress combines both nicely, and, lo and behold, prints them out in quality most other applications can only dream of.
The biggest downside is the price tag, but that's usually not all that relevant for ad agencies etc.
While this may have affected the decision, it's good to keep in mind that this didn't prevent very sparsely populated countries like Sweden, Finland and Norway (with population density similar to state of Colorado, and about half the average US population density) from building extensive GSM networks, in addition to their existing analog networks. It really is weird that these countries, even though the geography should be a big problem, have the least expensive calls, best plans, compared to bigger and "more dense" (perhaps not only in population...) countries.
I think the reason for doing this interesting in-band signaling was the fact that with T1 all 24 channels were used for payload, whereas E1 uses one (or was it more?) of 32 channels exclusively for signalling. I'm sure this isn't 100% accurate description, it's been few years since I got through the telecomm courses... But it's something along those lines. :-)
The thing was that before GSM, all (at least big) nations had their very own home-grown (analog) mobile phone networks. The exception was NMT (Nordic Mobile Telephone) network, which was common to (small) scandinavian countries. Countries that didn't have enough resources to waste (or inflated ego to boost) to create a national non-compatible system. It worked out reasonably well... It's no coincidence companies like Nokia and Ericsson are located in those countries.
At that point a minor miracle happened; people with some (regulatory) power realized the stupidity of going Not-invented-here route, and GSM standards committee was formed. What's even more amazing, I guess, is that things worked out well. Committees have been known to decimate decent plans before. :-)
People should be more open-minded about learning from experiences others have had, both good and bad. In this particular case there's little doubt which way worked out better; complete laissez-faire (USA) or slightly more regulated (not heavily regulated; there was no mandatory use of GSM... but operators generally did choose it over other options) european co-operative way.
Just an idea (which probably is totally wrong); perhaps they view this as an opportunity for competitors like AMD to get their hands on useful compiler technology? And perhaps also they think that compiler implementation might give hints about internal chip design (far-fetched?). Of course it could and may well be just good old-fashioned corporate culture, where giving away stuff is "so dot.com". :-)
That trio has traditionally been top pack for projects with enough money (I loved our alphastations), but like others say, price/performance ratio favours x86. In future, though, the biggest problem is that out of 3, only one seems to survive on medium term: Alpha will be discontinued (see other articles at ./), and it seems to be only matter of time when same happens to SGI stuff (if not to the whole company, much like to DEC).
Also, what about HP-PA? It used to be a good performer on benchmarks at some point? Its future looks very bleak too, of course, but I'm just curious whether it was used by scientist (or just faithful HP customers running legacy accounting applications... that's where I saw it most often).
While true, the benefit of Java/.NET over gcc is that most people don't keep on recompiling their applications (or get the correct one installed, if there's a choice), whereas transparent recompilation JIT happens independent of users actions. Downside with (current, at least) Java JITs is that they do this every time application runs, which is unfortunate. Would be nice if they did cache the end result, perhaps just checking timestamps of bytecode files vs. native compilations (and save the native stuff in the first place).
Oh please. I doubt many experience s/w engineers love async operations (I/O or otherwise). Conceptually using blocking threads (like in Java) is _MUCH_ simpler, and therefore generally leads to code that actually works. Async operations means that operations have to be somehow polled if you want any concurrency. And if you don't just do the queuing on your threads.
Hmmh. I'm a supporter of both Free and Open software (and have contributed few small patches for Kaffe), but really, without flaming, I'm interested in hearing which Free JDKs are overshadowing Sun JDKs? I can't think of any off-hand.
IBM has decent JVMs, but only their compiler (Jikes, which rocks) is really free; VM or key tools are not. Blackdown ports Sun's JDK and it's not really free (it doesn't cost you, but to get source you need to "sell your soul" like with vanilla Sun JDK). I haven't been closely following Classpath, Japhar or jgc, but certainly hope they mature. But, time is not quite yet. :-(
As far as I know, none of really free alternatives even have independent Swing implementation. I'd _love_ to see one, but I've been reading mailing lists enough to understand it's non-trivial thing to do (well, I've developed using Swing so that's kind of obvious). And before Swing is available... well, perhaps since right now Java is big on server side that's not all that fatal, but it seems really unfortunate that the key widget set of the language is missing.
But then again, keep in mind that Sun is not making any money directly with JDK (and not much for other tools like Forte either); it's more about mindshare and priced leadership in the arena. Originally JDK was supposed to be "just" the reference implementation. I guess Sun has never really decided if it should be more or not, though.
So? What does that have to do with fine arts? Do you think music on CD is not fine arts?
Once authors realized that they would work for years polishing their craft, and then never recoup a bit of their investment, they stopped writing in French.
And so they started writing in what instead? English?! That sounds like an urban legend, actually; french people are rather proud of their culture, and have been both before and after Voltaire et al. Abolishing copyrights may have been causing (and may cause) problems, but scenario like you suggest (which makes french literature and other culture sound like Hollywood-level garbage) sounds rather far-fetched.
Not that I'm all that against certain kind of copyrights (or other mechanisms for trying to support artits capability of earning their living from their work), but it's silly spouting nonsense like this to support your beliefs.
Also... What exactly did ex-president Clinton do different (in copyright front) than the war crazy national-debt-loving second rate actor Reagan? (here I am quoting a widely held french, or european, belief of mr. RR by the way)
This was studied quite a bit in Finland a while ago, and (hopefully) has changed the procedures used when re-planting cut down forest. The problem there, too, was that industry wanted pure pine forests, without leaf trees (like birches or aspends). The (only) downside is/was that it's slightly easier not to worry about 'wrong' trees when harvesting. Shouldn't be much of a problem now that most of the cuttings are partial ones (not the 'cut down everything' style that was popular earlier)
So... it may be that economy and ecology occasionally lead to same direction. Not common perhaps, but happens.
Slightly related to this article, too; there was a mention of another nearly extinct tree growing in Mauritius in that book, wasn't there? (or was it on some other island in Indian pacific, Maledives perhaps?)
The fact aussies and americans appear to have done more damage has more to do with vast land masses of these countries, than with any specific intrinsic drive to destroy. I'm afraid the same traits are present with all people, although ignorancy probably plays a bigger part than actual maliciousness.
But what do I know, I'm no anglo-saxon. :-)